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

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

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-08T21:12:36.000Z
- 最近活动: 2026-06-08T21:20:00.775Z
- 热度: 118.9
- 关键词: 工作流编排, Agent, CLI工具, Rust, Codex, 闭环控制, DAG, 并行执行, 验证器, 可审计性
- 页面链接: https://www.zingnex.cn/forum/thread/openflow-cli-agent
- Canonical: https://www.zingnex.cn/forum/thread/openflow-cli-agent
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：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\n**Openflow**是一个用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\n### 1. 规划阶段（Plan）\n\n```bash\nopenflow plan \"workflow: migrate this app from Next 14 to Next 15\" --template migration\n```\n\n规划器将自然语言请求转化为结构化的工作流计划（`plan.json`），包含任务分解和依赖关系。\n\n### 2. 审批阶段（Approve）\n\n```bash\nopenflow approve\n```\n\n在执行前提供人工检查点，确保工作流计划符合预期。这对于写操作尤其重要。\n\n### 3. 执行阶段（Resume/Run）\n\n```bash\nopenflow resume  # 继续已批准的运行\n# 或\nopenflow run \"workflow: ...\" --template audit --concurrency 8\n```\n\n支持并行执行（`--concurrency`）和最大重试次数（`--max-retries`）配置。\n\n### 4. 报告与验证\n\n```bash\nopenflow report --print\nopenflow validate\n```\n\n生成人类可读报告并验证运行状态的一致性。\n\n### 5. 应用阶段（Apply）\n\n```bash\nopenflow apply\n```\n\n对于写操作，变更以补丁形式保存在隔离的git worktree中，只有通过`apply`命令才会合并到主工作区。\n\n---\n\n## Agent 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\n```bash\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\n```bash\nmkdir -p .codex-loop\n{\n  git status --short\n  printf '\\n## Check\\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\n**Openflow**为CLI Agent生态系统带来了一个重要的缺失环节：可靠的工作流编排。它不是要取代Agent本身，而是为Agent提供一个更可控、更可审计、更可恢复的执行环境。\n\n对于需要处理复杂多阶段任务的团队来说，Openflow提供了一种介于完全自动化和完全人工审核之间的平衡方案。它允许并行探索、独立验证、渐进式审批，同时保持整个过程的可审计性。\n\n随着Agent在软件开发、数据分析、系统运维等领域的深入应用，类似Openflow这样的编排工具将变得越来越重要。它代表了Agent技术从"玩具"走向"生产就绪"的关键一步——当我们可以可靠地控制、验证和审计Agent的行为时，才能真正放心地将关键任务交给它们处理。