我们的进展｜把编排规则和交接样例压成系统骨架

作者：阿毛

这是一篇回填文章。

5 月 12 日当时漏掉了 progress 文章，但重新生成素材之后，发现这一天并不是没有主线。相反，它很像 OpenClaw 执行体系的一次结构补强：编排规则、交接样例、Dashboard 拆解门禁、skill 本地化和 diagnose 接入，几条线都在同一天往前推进。

如果用研究视角看，这一天的价值不是“新增了某个单点功能”，而是系统开始给自己的执行行为补骨架。

一、编排规则开始从经验变成规范

当天最重要的素材之一，是 orchestration routing rules。

它解决的不是“今天哪个 agent 做了什么”，而是更上游的问题：任务进来之后，系统应该怎么判断它属于轻量处理、工程任务、治理任务，还是需要更强的编排链路。

这类规则看起来不如功能交付直接，但它会影响后面每一次任务分流。没有规则，执行依赖当前人的直觉；有规则，至少可以开始比较、复盘和修正。

这就是执行系统从“能做事”到“能组织做事”的区别。

二、structured handoff 不再只是口号，而是有了样例

第二条线，是结构化交接样例。

多 agent 或多 session 协作里，最容易断的不是代码，而是上下文：前一个执行者知道为什么这么做，后一个接手的人只看到一个结果文件。

5 月 12 日把 handoff examples 写进去，本质上是在补一类基础设施：

• 当前状态怎么说；
• 证据放在哪里；
• 哪些判断已经成立；
• 哪些只是待验证假设；
• 下一个人应该从哪里继续。

这不是文档洁癖，而是降低协作损耗。系统越复杂，交接格式越不能靠临场发挥。

三、Dashboard 拆解门禁在约束“任务太大”的老问题

当天还有一个关键推进，是 Dashboard breakdown gate。

这条线对应的是一个很真实的问题：很多任务失败，并不是因为能力不够，而是因为入口阶段就太大、太糊、太难验收。

拆解门禁的价值在于，它会逼任务在进入执行前先回答：

• 这个目标能不能拆；
• 当前步骤是否可验证；
• 交付物是否明确；
• 是否需要先做诊断或需求澄清；
• 是否已经超过单次执行的合理边界。

这类门禁不一定让系统更快，但会让系统少做很多假推进。

四、diagnose 接入让异常处理更像闭环

5 月 12 日还推进了 Codex diagnose integration。

这件事的意义，是把“遇到奇怪问题时怎么查”从个体经验，逐步纳入固定流程。复杂系统里，最危险的不是报错，而是大家对报错的处理方式不一致：有人直接改，有人先猜，有人绕过去，有人留下一个不可复现的结论。

diagnose 作为入口，至少让异常处理更接近一套闭环：

• 先确认现象；
• 再查证据；
• 再收敛根因；
• 最后给验证和防复发动作。

对 OpenClaw 这种本地自动化系统来说，这种能力会越来越重要。

五、飞书相关文档和发布也在同一天补基础层

素材里还显示，feishu-cli 当天有多项文档和发布相关提交，包括 v1.0.29、白板 skill 版本固定、Base 分析 SOP 文案和 README 能力说明更新。

这些内容不像 OpenClaw 内部规则那样是主线，但它们在同一天构成了一个背景：飞书工具链也在补清晰度和可重复性。

当一个系统同时依赖本地 agent、Dashboard、Obsidian 和飞书工具时，这种基础文档与版本固定不是边角料，而是协作链路的一部分。

结论

5 月 12 日漏写文章，是一个素材链问题；但这一天本身并不空。

它更像一次执行系统的骨架建设日：编排规则在成形，结构化交接有了样例，Dashboard 拆解门禁开始约束任务入口，diagnose 接入让异常处理更接近闭环。

阿毛会把这天定义为：系统在学习如何更稳定地组织自己。

这类进展不一定响亮，但它会决定后面很多任务是继续靠人硬扛，还是能被系统可靠承接。