从“能跑”到“可治理”：OpenClaw OCDS 平台与近期开发历程（脱敏版）

本文只讨论设计方法与演进思路，不包含账号、密钥、主机地址、任务 ID、群组信息、内部路径等敏感内容。

很多团队把自动化系统做起来后，会先经历一段“高效率蜜月期”。任务能跑，提醒能发，数据也在动，看起来一切正常。再过一段时间，问题开始叠加：

• 任务越来越多，但没人说得清每条任务为什么存在；
• 失败时只能靠人肉回溯日志，缺少结构化证据；
• 定时、执行、巡检、告警混在一起，改一处动全身；
• 页面有很多数字，但很难支持决策。

我们这次做 OCDS，不是为了再做一个“更漂亮的面板”。目标很直接：给 OpenClaw 补上“治理层”，让自动化系统从“能跑”走到“可控、可审计、可进化”。

一、我们先承认 OpenClaw 的优点，也承认它的缺口

OpenClaw 的执行能力已经很强：调度、会话、工具调用、代理分工都很完整。问题不是“做不了事”，问题是“做完后怎么治理”。在真实连续运行里，主要有四类缺口：

1) 语义缺口
“计划、触发、执行、巡检、优化”边界不清。系统能运行，但团队很难统一认知。

2) 证据缺口
执行结果散落在多个位置。你能知道“刚刚好像跑了”，但很难快速回答“跑了什么、产出了什么、质量如何”。

3) 调度认知缺口
页面显示与真实调度状态可能不同步，管理者会失去信任。

4) 演进缺口
系统偏差出现后，缺少标准化“修复/进化”入口，改进动作容易靠临时操作，无法复盘。

这四类缺口，不会立刻让系统崩掉，但会慢慢侵蚀系统可靠性。

二、OCDS 的目标：不是替代执行层，而是补齐治理层

我们把定位讲得很克制：

• OpenClaw 负责执行；
• OCDS 负责持久化、可视化、决策支持；
• OCDS 不侵入核心执行引擎。

这样设计有个好处：执行引擎可以升级，治理层可以迭代，两边互不绑死。

三、核心语义先定死，再写代码

这次我们先做的是“词典统一”，不是“组件先行”。关键语义如下：

• Plan：定义业务目标与节奏（为什么做）
• Cron：定义触发时间（什么时候做）
• Agent/Worker：执行动作（怎么做）
• task_runs：执行事实账本（每次发生了什么）
• plan_task_queue：修复/进化任务队列（下一步要做什么）
• Heartbeat：巡检与裁决（要不要处理）

这里最重要的一条是：

定时业务通常由 Cron 直接触发执行并写入 run 账本，不默认走队列。
队列主要承载 repair/evolution 任务，不承载每次常规触发。

这个边界一旦清楚，很多争论会自动消失。

四、双闭环：生产闭环 + 治理闭环

很多自动化系统只有生产闭环：到点执行、产出结果。短期看够用，长期看会失控。我们这次明确做成双闭环：

1) 生产闭环（Deliver）

Plan → Cron → Run → Artifact

这条链路解决“稳定产出”。它回答：系统有没有按时跑、有没有生成结果。

2) 治理闭环（Improve）

Heartbeat → 偏差识别 → repair/evolution 任务 → 再验证

这条链路解决“持续变好”。它回答：系统偏差有没有被识别、有没有被有序修复。

当这两条闭环同时存在，系统才有长期稳定的可能。

五、近期开发历程（脱敏版）

阶段 A：先把“能跑但混乱”变成“语义可解释”

最早的问题不是功能不够，而是语义乱。比如文档写的能力和脚本真实能力不一致，队列表存在两套实现，页面能看到一部分状态但看不到完整上下文。团队沟通成本很高。

这阶段的动作很明确：

• 统一 Plan/Cron/Task/Heartbeat 定义；
• 把队列命令收敛为可执行、可验证的一套；
• 给关系画出“职责边界”，避免不同人按不同理解操作。

阶段 B：把“分散事实”收敛成可审计账本

我们把执行事实与治理事实分开记录：

• 每次执行写入 run；
• 关键产物写入 artifact；
• 巡检判断写入 heartbeat 结果；
• 修复任务通过队列管理状态流转。

这样做之后，复盘不再靠记忆，直接看证据链就行。

阶段 C：把“能看数据”升级为“能做决策”

页面不是给工程师炫技的，是给管理者做判断的。我们把看板重点从“堆指标”改成“决策信号”：

• 当前计划是否堵塞；
• 哪些任务是异常恢复；
• 哪些问题需要人工闸门；
• 下一步推荐动作是什么。

也就是说，从“展示发生了什么”升级到“告诉你该先做什么”。

阶段 D：把调度语义和治理语义彻底解耦

我们把业务定时触发统一迁移到更清晰的执行语义，Heartbeat 只做巡检，不再直接驱动业务脚本。调度、执行、巡检三条线分工清晰后，系统可预测性明显提升。

六、关键能力是怎么组合起来的

用“定时内容摘要”这个通用场景举例（不涉及任何具体账号与渠道）：

1. Plan 定义目标：时效、成功率、噪音控制；
2. Cron 到点触发 Agent 执行；
3. 执行结果写入 run，正文类结果写入 artifact；
4. Heartbeat 定期检查 SLA 与质量信号；
5. 如果偏差持续，生成 repair/evolution 任务入队；
6. 队列执行后再回写结果，形成闭环。

这个组合有两个现实价值：

• 业务输出不中断；
• 质量问题不会长期堆积。

七、为什么说这是“补位设计”而不是“重复造轮子”

如果只看“能不能执行任务”，OpenClaw 已经做得很好。OCDS 解决的是另一层问题：

• 让执行变得可解释；
• 让异常处理有标准入口；
• 让优化动作被记录、被复盘；
• 让管理者看得懂、决策快。

一个偏执行，一个偏治理。两者不是替代关系，而是组合关系。

八、脱敏策略与发布边界

这篇内容在发布前按三层做了脱敏：

• 身份层：不出现账号、群组、人员定位信息；
• 系统层：不出现可定位系统的密钥、地址、内部路径；
• 执行层：不出现具体任务 ID、回调标识、内部命令细节。

保留的是方法论、架构边界、演进路径。这样能分享经验，同时不暴露关键细节。

九、我们做过的三个关键取舍

第一，没有把 OCDS 做成“万能调度器”。
它只做治理，不抢执行权。执行仍在 OpenClaw，这样故障域更清晰。

第二，没有追求一步到位的“大而全”。
先把最关键的语义与证据链打通，再扩展模块。这样上线节奏更稳，也更容易验证价值。

第三，没有为了自动化而自动化。
有些场景保留人工闸门是必要的。系统要提高效率，但不能把风险外包给“默认自动执行”。

这三个取舍让平台少了很多“看起来很高级”的功能，但换来了可维护性和可解释性。

十、当前仍在推进的点

体系已经可用，但还有两块值得继续做：

• 把“自然语言口令 → 自动判断 Plan 还是 Task”做成真正的路由器，而不是只停在文档规则；
• 把更多跨计划的质量信号聚合成统一健康分层，减少人工解释成本。

十一、一句话收尾

自动化系统最怕的不是偶发失败，而是长期不可治理。
OCDS 这套设计，本质上是在给自动化系统加“可控进化能力”：先把边界讲清楚，再把证据链补完整，最后让系统自己进入稳定迭代。