多 Agent 工作流如何落到真实代码？OpenFlow 可视化编排与安全边界
把“规划—实现—审查”拆给多个 AI Agent，听起来很自然；真正运行时，却会遇到角色配置、并行执行、模型凭据和文件写入权限等一串工程问题。OpenFlow 是一个基于 OpenCode 引擎的可视化多 Agent 工作流应用：在画布上放置角色卡片、连接流程，再让真实 Agent 执行。它适合想实验多角色协作、又希望把执行过程保留在本机项目中的开发者，但它不是无需审查的自动改代码按钮。
它是什么，不是什么
OpenFlow 是 OpenCode 的独立分支项目，不隶属于 OpenCode 团队。仓库说明，OpenCode 的无头服务 opencode serve 负责底层 Agent 引擎，OpenFlow 自己的实现位于 packages/flow。因此它的价值主要是工作流画布和运行管理，而不是另造一个模型或通用 Agent SDK。
项目文档描述了多种编排方式：按依赖关系执行的 pipeline、同伴式 swarm，以及由一个 Agent 将工作交给可见角色的 orchestration。具体适用性取决于所选流程与角色配置；不要只因为界面里能连线，就认为多个 Agent 会自动得到正确上下文或产出可靠结果。
本地启动：先把边界设清楚
仓库当前要求 Bun 1.3+ 和 Git。README 给出的基本步骤是：
git clone https://github.com/SeeRay11/OpenFlow.git cd OpenFlow bun install bun openflow.ts
启动器会运行引擎与画布，文档默认引擎端口为 4096、画布端口为 5174。默认可先尝试 OpenCode 的免费模型；使用其他模型时，需要在应用的 API keys 面板配置对应凭据。免费额度共享，遇到 429 或模型请求错误时，文档建议换一个 -free 模型测试，而非立刻认定安装损坏。
在开始运行前，指定工作目录尤其重要。通过 OPENFLOW_PROJECT 或启动器的项目参数，可以选择 Agent 读取和写入的仓库。项目文档明确提醒：Agent 会编辑真实文件。第一次使用建议指向临时克隆或干净的 Git 分支，先检查 diff，再决定是否合并；不要把生产工作树当成试验沙箱。
另一个容易忽略的边界是网络暴露。OpenFlow 的 /flow/api 会写入工作区文件、保存运行日志并合并 Agent 配置；文档指出这些接口没有认证。因此服务默认限制为 loopback。不要为了方便远程访问就随手设置 FLOW_ALLOW_REMOTE=1：只有在自行补齐可信网络隔离和访问控制后，才应考虑非本机绑定。
让流程可调试，而不是只看画布
一个稳妥的试验流程可以从三个角色开始：规划者输出任务拆分，执行者只实现其中一个明确任务，审查者检查 diff 与测试结果。每个节点都写清楚输入、输出和停止条件；先用小改动验证上下文传递，再扩大任务。若把同一份模糊需求同时交给多个 Agent，得到的可能是重复编辑和互相覆盖，而不是并行提速。
OpenFlow 文档还说明，引擎会在启动时读取项目中的 opencode.json 并缓存配置；新合并的 Agent 若没有出现在运行环境中，需要重启引擎。启用 FLOW_MANAGE_SERVER=1 后，画布可以管理引擎并提供重启入口。配置变更后先确认实际加载的 Agent 与模型，再启动完整任务，能减少“画布里有角色、执行时却找不到”的困惑。
需要排查端口冲突时，文档建议先确认 4096 和 5174 的占用者。不要盲目执行 kill -9：它会终止任何占用这些端口的进程，并不只针对 OpenFlow。若碰到 database is locked，原因也可能是另一个 OpenCode 引擎实例正在使用共享数据库；应定位并停止对应实例，而非反复清理端口。
适用场景与取舍
OpenFlow 适合需要反复试验角色分工、希望可视化查看流程，并愿意在本地管理运行环境的开发者。相较于直接在终端手工启动多个 Agent，画布能把角色和依赖关系显式化；代价是需要安装较大的 Bun 工作区，并理解 OpenCode 服务、模型凭据与项目权限之间的关系。它是应用而非 npm 包，不能把 bun install 当作安装一个全局 CLI。
更重要的是，编排不等于验证。为每次运行保留 Git 分支、检查代码差异、执行项目测试，并把高风险操作设为人工确认，仍是必要流程。若目标只是一次性问答，单 Agent 更简单；若要让多 Agent 改真实项目，先限制工作目录和权限，再讨论并发数量，通常更稳妥。
相关链接