把分身接成一条会自己流动的线：subagent-orchestrator 的诞生、补丁与发布前夜

type

Post

status

Published

date

Mar 7, 2026

slug

subagent-orchestrator-story-cyber-protocol-debug-clawhub

summary

一篇关于 subagent-orchestrator 如何从连续任务漏接、协议收敛、任务线板改造，到修补执行闸门与准备发布 ClawHub 的科技赛博风纪实。

把分身接成一条会自己流动的线：`subagent-orchestrator` 的诞生、补丁与发布前夜

一开始我们以为，只要会派分身，系统就能自己跑。后来才发现，真正会掉线的不是模型能力，而是任务接力本身。

01｜为什么要做这个 skill

OpenClaw 的分身很好用。

主控发任务，分身去执行，做完回来汇报。看起来像一套已经足够聪明的并行系统。

但当任务从“单轮查一个问题”升级成“连续推进一个工程”时，裂缝就出来了。

比如 UI 线做完一轮，理论上下一轮应该自动去接素材接入；代码线补完一批题型，理论上应该马上交给验证；档案线补完世界观，理论上应该继续去承接图鉴文案。可在真实运行里，经常出现一种很像赛博城市断电的瞬间：

这一轮确实完成了；

汇报也确实回来了；

但是下一轮没有人接；

任务没有死，只是静静停在上下文阴影里。

这就是为什么 `subagent-orchestrator` 必须被做出来。

它不是为了“让分身更多”，而是为了**让持续任务真正形成闭环**。它要解决的核心不是生成内容，而是让主控知道：什么时候该续派、续给谁、按什么状态推进、什么时候不能再靠感觉判断。

换句话说，这个 skill 是给 autopilot 装上轨道，而不是再加一台马达。

02｜为什么 autopilot 连续任务特别容易漏接

`autopilot` 这件事，最危险的地方在于它表面上看起来“已经定义清楚了”。

只要任务说明里写了“持续推进”“自动接力”“直到完成”，人会天然觉得系统已经理解了连续性。可机器执行时，真正被看见的常常只有**本轮完成**。

也就是说，系统容易把下面两件事混为一谈：

**一个 run 完成了**

**整条任务线完成了**

这是 autopilot 最常见的漏接源头。

连续任务之所以容易漏，是因为它本质上不是一个任务，而是很多个小任务首尾相接：

每个节点都需要一个明确 owner；

每次回传都要说明此刻处在任务线的哪个位置；

主控必须在**当前这一轮**就决定下一跳，而不是把“稍后继续”交给模糊记忆；

一旦没有显式协议，系统就会退回最保守的解释：**这轮做完了，那就先停。**

所以 autopilot 失败，不是因为不会做，而是因为没有把“继续”变成强制动作。

03｜协议是怎么长出来的：从模糊汇报到 `tag / line / goal_status / next_role / node`

这个 skill 不是先有一个完美设计图，再照着搭出来。它更像是在连续调度里，被 bug 一层层倒逼出来的协议。

第一层：先把“这轮是什么性质”说清

最早需要解决的是：分身回来的结果，到底代表什么？

于是先有了 `tag`：

`autopilot`：这轮结束了，但整条线大概率没结束

`done`：整条线真的结束

`idle`：先等别的线推进

`blocked`：被卡住，不能安全自动继续

`handoff`：下一棒已经明确

`need_user`：必须等用户决策

这一层像给回传包先打了一个交通灯。没有它，主控根本不知道该冲、该停，还是该转交。

第二层：只知道“该继续”还不够，还得知道是哪条线

于是有了 `line`。

因为真实项目里同时会有 UI、代码、侦察、验证、档案多条主线并发。没有 `line`，主控只能看自然语言猜“这段汇报属于谁”，这在单线时还能凑合，多线同时跑就一定会串线。

所以 `line` 负责把结果挂回具体任务线，比如：

`ui-autopilot`

`code-autopilot`

`scout-art`

`archive-worldview`

从这一步开始，autopilot 不再是一句口头承诺，而是被绑定到一条可追踪的线。

第三层：状态值必须收敛，否则自动化会失真

再往后，问题变成了：即使知道是这条线，主控也未必读得懂“完成到了什么程度”。

因为不同分身会自然写出不同词：

`half_done`

`in_progress`

`almost there`

`done for now`

这些词对人类来说能看懂，对自动续派来说却是噪音。

于是 `goal_status` 被收敛成四个值：

`partial`

`complete`

`waiting`

`blocked`

这一步很关键。因为一套会执行的系统，第一原则不是表达丰富，而是**状态有限且稳定**。

第四层：只知道状态也不够，还得知道下一棒倾向交给谁

于是补上了 `next_role`。

它不是死枚举，而是自由角色名。这样设计的原因很现实：项目协作不是永远固定的，有时是 `ui`，有时是 `verify`，有时是 `archive`，甚至可能是临时角色。

所以 `next_role` 的作用不是替主控做最后决定，而是给出**生产现场最接近事实的接棒意图**。

第五层：最后发现还差一个致命坐标——当前节点

当 `tag / line / goal_status / next_role` 都有了，系统还是会出错。因为主控依然可能知道“该继续这条线”，但不知道**当前到底走到了哪个节点**。

于是 `node` 被补了进来。

这一下协议终于落地到可流转状态：

`line` 决定是哪条线

`node` 决定当前在线上的哪个位置

`goal_status` 决定这个位置完成到什么程度

`next_role` 提供下一棒建议

`tag` 决定主控该采取什么类型的动作

至此，协议不再只是“汇报格式”，而成了主控可计算的接力结构。

04｜为什么任务板必须升级成任务线板

最早的任务板更像一个静态看板：记录有哪些任务、谁在做、现在大概到哪。

它适合人类扫一眼，但不适合机器持续接力。

因为连续任务真正要解决的，不是“现在有什么”，而是“下一步去哪”。

于是任务板被升级成了**任务线板**。

关键变化不在名字，而在结构：

`line`

`current_node`

`end_node`

`nodes`

这意味着主控不再靠“看完一段回传后自己判断要不要继续”，而是按节点流转：

当前节点完成；

查它的 `next_on_done`；

推进 `current_node`；

如果还没到 `end_node`，就在同一轮直接续派。

这一步是整个 orchestrator 从“有规则”变成“可执行”的分水岭。

因为在旧模式里，任务板更像会议纪要；在新模式里，任务线板更像状态机。

05｜测试里暴露出来的 bug，比文档诚实得多

这次 skill 真正成型，不是因为写完了说明书，而是因为在连续测试里被一连串 bug 反复拍脸。

Bug 1：没有自动续派

最典型的问题：分身已经按要求回来了，甚至写了 `autopilot`，但主控只是总结一下这轮完成了什么，并没有继续派发下一轮。

这说明一个很残酷的事实：

**“支持 autopilot” 这句话，如果没有强制的主控动作规则，就只是一个叙事，不是执行。**

Bug 2：状态值不统一

有人写 `done`，有人写 `half_done`，有人写“已完成当前阶段”。

对人来说问题不大，对主控来说问题非常大。因为自动化只要面对模糊状态，就只能退回人工理解，自动续派就会松掉。

所以 `goal_status` 最后被强制统一成固定四值，宁可牺牲表达弹性，也要换来控制稳定性。

Bug 3：只写了规则，不等于系统会执行

这是最隐蔽也最关键的 bug。

一开始我们以为，只要把规则写进 skill：

回传要带什么字段；

主控应该怎么理解；

任务线该如何推进；

系统自然就会照着走。

但真实情况是：**文档是文档，执行是执行。**

如果主控在收到结果的同一轮里，没有完成“更新任务线 → 推进 current_node → 续派 next_on_done”，那这条线依旧会掉在地上。

所以最后必须补上最硬的一层：

收到 `autopilot + line + node` 回传后，主控必须在同一轮完成节点推进和下一跳派发，不能只汇报，不接力。

这一条，等于把“建议”改成了“闸门”。

06｜怎么一层层修补到真正可执行

回头看，这次修补大致经历了五层递进。

第一层：定义 autopilot 不是单轮任务

先把概念纠正：

带 `autopilot` 的任务，不是“做一轮再说”；

它是持续任务线；

不带 `autopilot` 的，才是单轮执行。

先把语言边界切清，才有后面的结构化约束。

第二层：加回传协议，压缩歧义

把分身回传收敛到统一头字段：

`tag`

`line`

`node`

`goal_status`

`next_role`

再配合短报告格式，只保留目标、完成项、文件、状态、下一步、风险。

这样一来，回传不再是聊天记录，而是接力包。

第三层：把任务板改造成状态机

新增 `current_node / end_node / nodes`，让每条主线都能被明确推进。

这一步之后，主控终于可以少靠“理解全文”，多靠“读取状态”。

第四层：补 anti-drop guard

也就是防漏接守卫。

每次 `autopilot` 回传，主控都必须验证三件事：

这条线存在；

这条线还没结束；

已经发生了以下之一：

或显式改成 `idle`

或显式改成 `blocked`

或显式改成 `need_user`

或显式改成 `done`

如果这五者都没发生，就说明这一轮其实没完成。

第五层：补 mandatory node advancement

这是最后一刀。

不是“看情况推进”，而是必须执行：

解析 `line`

定位 `node`

把 `current_node` 推进到 `next_on_done`

若没到 `end_node`，同轮直接续派

到这一步，skill 才从“知道该怎么做”变成“逼着系统真的这么做”。

07｜它最终变成了什么

最终的 `subagent-orchestrator`，本质上不是一个花哨的自动化玩具，而是一层主控纪律。

它做的事情可以被概括成一句话：

**把连续任务从“记得继续”改造成“必须流转”。**

这会带来几个直接变化：

UI、代码、验证、侦察、档案不再只是并行存在，而是能彼此衔接；

分身 session 可以清理，但任务状态不会丢；

memory 记录的是结果和节点，不是冗长过程；

用户不需要一轮轮提醒“继续做下一个”。

换句话说，系统终于开始表现出一点真正的 autopilot 气质：

不是会自己乱跑，而是会沿着定义好的轨道继续前进。

08｜ClawHub 发布准备：最不像技术问题的，往往最卡发布

做到这里，理论上 skill 已经能发布到 ClawHub。

准备工作本身并不复杂：

`SKILL.md` 整理完成；

`README.md` 补齐定位与协议说明；

`package.json` 元数据就位；

references 内保留 canonical 协议文件；

真正卡住发布的，不是 skill 内容，而是外部平台节奏。

这次记录里就明确踩到了一个点：**GitHub API rate limit exceeded**。

也就是说，认证本身是通过的，skill 内容也准备好了，但在 `clawhub publish` 过程中，外部依赖链路触发了速率限制，导致发布失败。

这类问题很典型，也很赛博：

你的系统已经准备好；

你的协议已经闭环；

你的文档已经能解释自己；

但你仍然会被上游平台的一道配额阈值拦住。

所以发布准备除了内容完整，还要把这种现实条件写进 runbook：

避开高频发布窗口；

遇到 rate limit 不伪造成功；

记录失败原因与重试建议；

把“认证通过但发布失败”与“内容有问题”严格区分。

这一步很重要，因为一个工程系统的成熟，不体现在它从不失败，而体现在**失败时能留下准确坐标**。

09｜这次建立 skill 的真正收获

如果只看表面，这次像是在做一个分身调度 skill。

但再往深一点看，真正完成的是一件更底层的事：

我们把“多轮协作”从口头流程，压成了可执行协议；把“任务管理”从静态板，升级成了任务线状态机；把“应该继续”从经验判断，变成了主控当轮必须完成的动作。

这也是为什么这个 skill 值得被记录。

因为很多系统一开始都死在一个幻觉里：

以为规则写出来，系统就会照做。

但工程世界不是这样。

工程世界里，只有被状态收敛、被字段编码、被流程闸门强制执行的规则，才算真正存在。

10｜结语：不是让 AI 更会说，而是让系统更不掉线

`subagent-orchestrator` 的价值，不在于它创造了一个新名词，而在于它解决了一个真实且反复出现的问题：

**连续任务会在漂亮汇报之后悄悄断线。**

现在，这条线被重新焊接起来了。

它经过了协议形成、任务板重构、回传收敛、bug 暴露、执行补丁、发布准备和限流阻断，最后长成一套更像系统、而不是更像说明书的东西。

如果说这次工作留下了一点赛博感，那不是因为用了多少术语，而是因为我们终于承认：

在多分身协作的城市里，真正重要的从来不是某个节点有多聪明，而是电流是否能穿过每一段线路，继续往前。

附：文中提到的关键文件

`skills/subagent-orchestrator/SKILL.md`

`skills/subagent-orchestrator/README.md`

`skills/subagent-orchestrator/references/SUBAGENT_RECORD_PROTOCOL.md`

`AGENT_TASK_BOARD.md`

`SUBAGENT_RECORD_PROTOCOL.md`

`MEMORY.md`

`.learnings/ERRORS.md`

附：一句话总结

`subagent-orchestrator` 不是在教分身如何工作，而是在规定主控什么时候绝不能松手。