OpenClaw：把零散 agent 命令变成可追踪的自动化系统

Why this project exists

使用 AI agent 一段时间后，我发现一个模式：每次执行的任务都是类似的——读取文件、修改代码、运行测试、提交变更。但因为没有标准化，每次都要重新描述上下文，重新解释要求。

OpenClaw 的出发点很简单：如果 agent 工作流本身可以被记录、复用和追踪，会发生什么？

Starting point

最初只是一些零散的 shell 脚本和 prompt 模板。比如：

• "帮我生成一个项目详情页"
• "检查这个 JSON 文件是否合法"
• "部署后验证线上状态"

这些命令有用，但彼此孤立。没有统一的输入格式，没有标准的输出结构，也没有版本历史。

First principles

工作流即代码：agent 的执行步骤应该像代码一样被版本控制、被测试、被复用。 阶段即检查点：每个工作流必须拆成阶段，阶段之间可以暂停、恢复、审查。 报告即状态：每个阶段结束后必须生成结构化报告，报告本身就是系统状态的一部分。 可复用 > 一次性：设计工作流时要考虑复用价值，而不是只解决当前问题。

Key decisions

本地优先：工作流定义和报告都存储在本地文件系统中，通过 Git 版本控制。不依赖外部平台。 JSON 数据驱动：工作流的输入输出都用 JSON 描述，这样不同工作流之间可以互相组合。 feature flags：新功能通过 feature flag 控制，可以逐步启用，降低风险。 与 Hermes 的关系：OpenClaw 是工作流实验场，Hermes 是执行环境。OpenClaw 中验证有效的工作流模式会被集成到 Hermes 中。

System architecture

OpenClaw 的核心是一个轻量级工作流引擎：

工作流定义：JSON 文件描述工作流的阶段、输入、输出、验证规则。 阶段执行器：按顺序执行每个阶段，记录日志和结果。 报告生成器：每个阶段结束后生成 Markdown 报告。 状态管理器：跟踪工作流的执行状态，支持暂停和恢复。

Phase timeline

Phase 0：概念验证。验证 agent 是否可以按结构化步骤执行任务。 Phase 1：工作流模板。建立标准化的工作流定义格式和报告模板。 Phase 2：阶段化执行。引入检查点机制，支持长任务的分段执行。 Phase 3：与项目系统集成。让工作流可以直接操作 conanxin.com 的数据文件和构建脚本。 当前：作为实验项目持续迭代，验证新的 agent 协作模式。

What changed

从"每次重新描述"变成了"选择模板、填入参数、执行、验证"。

具体变化：

• 从零散命令升级为标准化工作流
• 从临时执行升级为可追踪的执行历史
• 从单一任务升级为可组合的任务链
• 从人工验证升级为自动化验证

Current status

当前状态：active / 实验阶段。

OpenClaw 目前是一个实验性质的项目，主要验证以下假设：

• agent 工作流可以被标准化和复用
• 阶段化执行可以降低长任务的风险
• 结构化报告可以提高可追溯性

这些假设在 conanxin.com 的 HP 系列中得到了验证。

Impact

对个人工作流的影响：建立了一种"先设计工作流，再执行任务"的习惯。不再随意给 agent 下命令，而是先思考这个任务应该分几个阶段、每个阶段的验收标准是什么、可能的风险在哪里。

复用价值：OpenClaw 中验证的工作流模式已经被应用到 Hermes 和 conanxin.com 的维护中。

What I learned

关于标准化：标准化不是限制，而是解放。当基础模式确定后，可以把注意力集中在真正需要思考的部分。 关于实验：不是所有实验都需要"成功"。OpenClaw 的很多尝试被证明不适用，但这些失败本身就是有价值的记录。 关于追踪：可追踪性比自动化更重要。即使不能完全自动化，只要有完整的执行记录，就能大幅提高效率。

Next

• 继续探索更复杂的 agent 协作模式
• 验证工作流在多项目场景下的复用性
• 考虑把工作流引擎从实验项目升级为独立工具