Openflow：面向CLI Agent的动态工作流编排引擎

Rust编写的开源工作流编排工具，将复杂请求转化为验证过的DAG工作流，支持并行Agent执行、独立结果验证，并以文件形式持久化运行状态。

• 原作者/维护者：Grail-Computer
• 来源平台：github
• 原始标题：openflow
• 原始链接：https://github.com/Grail-Computer/openflow
• 来源发布时间/更新时间：2026-06-08T21:12:36Z

原作者与来源

• 原作者/维护者：Grail-Computer
• 来源平台：github
• 原始标题：openflow
• 原始链接：https://github.com/Grail-Computer/openflow
• 来源发布时间/更新时间：2026-06-08T21:12:36Z 原作者与来源\n\n- 原作者/维护者： Grail-Computer\n- 来源平台： GitHub\n- 原始标题： openflow\n- 原始链接： https://github.com/Grail-Computer/openflow\n- 发布时间： 2026年6月8日\n\n---\n\n背景：单Agent模式的局限性\n\n当前的大语言模型Agent在处理聚焦型任务时表现出色，但在面对需要多阶段协作的复杂请求时，单Agent模式开始显现明显的局限性。典型的复杂场景包括：\n\n- 多子系统检查：需要同时检查代码库的多个模块\n- 独立发现对比：比较不同路径的探索结果\n- 结果验证：在采纳前验证每个中间结果\n- 综合合成：将多个独立发现整合为最终答案\n- 中断恢复：长时间任务需要支持暂停和恢复\n\n在这些场景下，简单的顺序执行或单轮对话往往难以保证结果质量，也无法提供足够的可审计性和可恢复性。\n\n---\n\n项目概述：工作流编排的新思路\n\nOpenflow是一个用Rust编写的开源动态工作流编排引擎，专门设计用于CLI Agent harness（如Codex、Kimi等）。它的核心理念是将一个宽泛的请求转化为经过验证的工作流DAG（有向无环图），然后并行运行Agent工作节点，独立验证结果，并将整个运行过程保存为普通文件，以便检查、恢复和共享。\n\n与简单的任务队列不同，Openflow强调的是闭环控制：明确的任务边界、显式依赖关系、评估门控，以及清晰的报告输出。\n\n---\n\n核心架构：闭环控制循环\n\nOpenflow将工作流视为围绕Agent工作节点的控制器系统，其架构包含以下关键组件：\n\n期望状态与观察状态\n\n- 期望状态（Desired State）：工作流目标和生成的plan.json\n- 观察状态（Observed State）：状态文件、先前任务结果、验证器输出、日志和state.json\n\n这种区分使得系统能够基于实际执行情况动态调整，而不是盲目执行预定义步骤。\n\n执行器与门控\n\n- 执行器（Actuator）：Codex或其他CLI harness，运行规划器、工作节点和验证器提示\n- 门控（Gate）：对抗性验证器，在证据缺失或超出范围时"故障关闭"\n\n验证器的设计特别值得注意——它采用"故障关闭"（fail closed）策略，这意味着如果没有足够证据支持，任务会被标记为失败，而不是冒险通过。\n\n刹车与记忆\n\n- 刹车（Brake）：--brake-file、审批门控和补丁队列，防止工作节点自行应用变更\n- 记忆（Memory）：报告、事件和工件保存在.openflow/runs/<run-id>/目录下\n\n文件化的持久化设计意味着整个运行历史都是可审计的，支持事后分析和复现。\n\n---\n\n工作流生命周期：从规划到应用\n\nOpenflow定义了清晰的工作流生命周期：\n\n1. 规划阶段（Plan）\n\nbash\nopenflow plan \"workflow: migrate this app from Next 14 to Next 15\" --template migration\n\n\n规划器将自然语言请求转化为结构化的工作流计划（plan.json），包含任务分解和依赖关系。\n\n2. 审批阶段（Approve）\n\nbash\nopenflow approve\n\n\n在执行前提供人工检查点，确保工作流计划符合预期。这对于写操作尤其重要。\n\n3. 执行阶段（Resume/Run）\n\nbash\nopenflow resume 继续已批准的运行\n或\nopenflow run \"workflow: ...\" --template audit --concurrency 8\n\n\n支持并行执行（--concurrency）和最大重试次数（--max-retries）配置。\n\n4. 报告与验证\n\nbash\nopenflow report --print\nopenflow validate\n\n\n生成人类可读报告并验证运行状态的一致性。\n\n5. 应用阶段（Apply）\n\nbash\nopenflow apply\n\n\n对于写操作，变更以补丁形式保存在隔离的git worktree中，只有通过apply命令才会合并到主工作区。\n\n---\n\nAgent Harness合约：灵活的执行后端\n\nOpenflow当前内置支持Codex预设，但通过--agent-command参数可以接入任何CLI Agent。命令模板支持以下占位符：\n\n| 占位符 | 说明 |\n|--------|------|\n| {prompt} | 完整提示文本 |\n| {prompt_file} | 包含提示的文件路径 |\n| {output_file} | Agent应写入最终答案的路径 |\n| {schema_file} | JSON Schema路径（期望结构化输出时） |\n| {sandbox} | 只读或工作区写入权限 |\n| {cwd} | 工作目录 |\n| {model} | 通过--model传入的模型值 |\n| {agent} | Agent名称 |\n| {agent_bin} | Agent二进制路径/名称 |\n\n使用自定义Agent的示例：\n\nbash\nopenflow run \"workflow: audit this repo for auth bugs\" \\\n --template audit \\\n --agent kimi-k2 \\\n --agent-command 'kimi-k2-cli run --prompt-file {prompt_file} --output {output_file}' \\\n --concurrency 8\n\n\n这种设计使得Openflow可以适应不同的Agent生态系统，而不局限于特定供应商。\n\n---\n\n安全设计：可逆的写操作\n\nOpenflow在安全性方面的设计尤为周到。所有写操作都遵循"可逆设计"原则：\n\n1. 隔离执行：工作节点在独立的git worktree中运行\n2. 补丁捕获：变更以补丁文件形式保存在.openflow/runs/<run-id>/patches/\n3. 显式应用：只有通过openflow apply命令，变更才会进入主工作区\n4. 状态验证：openflow validate检查运行状态、计划、任务结果、验证器输出、补丁文件、工作日志和报告的内部一致性\n\n这种设计防止了Agent的"自主失控"——即使Agent工作节点试图直接修改文件，由于运行在隔离环境中，也无法影响主工作区。\n\n---\n\n本地控制循环集成\n\nOpenflow还可以作为本地Codex运行的控制器。通过维护一个状态对象并定期刷新，可以实现确定性的观察状态：\n\nbash\nmkdir -p .codex-loop\n{\n git status --short\n printf '\\nCheck\\n'\n npm test -- --runInBand 2>&1\n} > .codex-loop/status.md\n\nopenflow run \"workflow: fix the failing test with the smallest safe change\" \\\n --template migration \\\n --status-file .codex-loop/status.md \\\n --brake-file .codex-loop/brake\n\n\n状态文件会被复制到.openflow/runs/<run-id>/state.json，包含在规划器、工作节点和验证器提示中，渲染在report.md中，并由openflow validate检查。这为控制循环提供了持久的"观察状态"，而不是仅依赖对话历史。\n\n如果.codex-loop/brake文件存在且包含文本，Openflow会在启动下一批任务前阻塞，提供了人工干预的机会。\n\n---\n\n模板系统：可定制的工作流模式\n\nOpenflow内置了多种工作流模板：\n\n- audit：只读审计，检查代码库中的特定问题\n- migration：迁移任务，支持版本升级等场景\n- pr-review：PR审查，分析代码变更的风险\n\n通过openflow init命令可以初始化可编辑的项目模板，创建：\n\n\n.openflow/workflows/audit.md\n.openflow/workflows/migration.md\n.openflow/workflows/pr-review.md\n\n\n用户可以根据项目需求自定义这些模板，定义特定领域的检查规则和最佳实践。\n\n---\n\n实际意义与生态价值\n\nOpenflow的出现代表了Agent编排工具向更成熟、更可控方向发展的趋势。它的价值体现在：\n\n可审计性：所有运行状态都以文件形式保存，支持事后分析和合规审计。\n\n可恢复性：中断的运行可以无缝恢复，不会因为网络波动或资源限制而丢失进度。\n\n可共享性：运行结果以标准文件格式保存，可以方便地在团队间共享和复现。\n\n供应商无关：通过Agent Harness合约设计，不绑定特定Agent供应商，支持Codex、Kimi等多种后端。\n\n安全优先：隔离执行、补丁捕获、显式应用等设计体现了安全优先的理念。\n\n---\n\n总结与展望\n\nOpenflow为CLI Agent生态系统带来了一个重要的缺失环节：可靠的工作流编排。它不是要取代Agent本身，而是为Agent提供一个更可控、更可审计、更可恢复的执行环境。\n\n对于需要处理复杂多阶段任务的团队来说，Openflow提供了一种介于完全自动化和完全人工审核之间的平衡方案。它允许并行探索、独立验证、渐进式审批，同时保持整个过程的可审计性。\n\n随着Agent在软件开发、数据分析、系统运维等领域的深入应用，类似Openflow这样的编排工具将变得越来越重要。它代表了Agent技术从"玩具"走向"生产就绪"的关键一步——当我们可以可靠地控制、验证和审计Agent的行为时，才能真正放心地将关键任务交给它们处理。