解法：

1. spawn 时只声明子 Agent 要写的目录——workspace_scope: ["reports/"]，不能写 ["reports/", "config/", "daily/"] 这种宽口径。
2. 子 Agent 写完后，main 跑 git diff --stat config/ 校验「子 Agent 没碰过父配置」。
3. 严重敏感路径（凭据、适配器、SKILL）永远不要进 workspace_scope——即使你想让子 Agent 帮你检查凭据是否存在，也用 read + 显式 redact，不要给 write。

坑 3：子 Agent token_budget_max 不够，子 Agent 跑到一半被强制终止

症状：main 委派 timew 生成 1 篇 2500 字文章 + 2 张截图 + 1 次凭据调取。子 Agent 在写到 1800 字时被 OpenClaw 适配器中断，返回 budget_exhausted 错误。

根因：timew 的 token_budget_max = 80000，但「2500 字文章生成（输入 + 输出 + tool 调用日志）」实际消耗约 95000 token。超出 80000 上限后，OpenClaw 在下个 token 生成前中断子 Agent，不会写出 result 字段。

解法：

1. spawn 前先估算子 Agent 总 token 消耗：(prompt_budget × 2) + (输出字数 × 2) + tool_calls × 500。
2. 如果超过子 Agent 的 token_budget_max，拆成多次 spawn——例如把「文章 + 配图」拆成两次 spawn：第一次只写文章骨架（5000 token），第二次读骨架 + 配图（5000 token）。
3. 子 Agent 返回 budget_exhausted 后，不要 retry 整个 prompt——会再次超。改成「读上次 spawn 的 result.deliverable 文件 + 续写 prompt」。

实测：单篇 2500 字文章必须拆成两次 spawn 才行，单次 spawn 在 timew 上 100% 超 80000 上限。

坑 4：agents_wait timeout 30 秒不够，子 Agent 完成时 main 已经放弃等待

症状：main 委派 shopper 跑一个 90 秒的盘点任务，agents_wait 默认 30 秒。30 秒到时 main 拿到 pending_ids: ["agent:shopper:subagent:xxx"]，main 继续 wait 30 秒——但 shopper 在第 75 秒才返回完整结果。main 整个 task contract timeout 60 秒，错过了完整结果，按 partial 处理。

根因：agents_wait 的 timeout 是「单次 wait 上限」，不是「整个 task contract 上限」。OpenClaw 的协议是：每次 wait 超时后，把还在跑的子 session 放进 pending_ids，main 可继续 wait。main 必须主动多次 wait 才能拿到最终结果。

解法：

1. 第一次 wait 用 timeoutSeconds=30 拿 quick status（子 Agent 是否启动了）。
2. 第二次 wait 用 timeoutSeconds=60 拿阶段性结果（子 Agent 写了一半的 deliverable）。
3. 第三次 wait 用 timeoutSeconds=120 拿最终结果（子 Agent 写到 result.deliverable 的 completed 标记）。
4. 三次都 pending 的，进入下个 cron run 轮询——不要在 main 这一轮里阻塞 5 分钟。

main 自己的 agent 必须按这种「多次 wait + 阶段接受」协议设计，否则 5 分钟 main 全卡死是常态。

坑 5：子 Agent 返回 result.status=partial，main 直接当 ok 处理导致下游连锁失败

症状：timew 子 Agent 盘点 89 篇草稿，跑到 75 篇时预算耗尽，返回 result.status=partial、structured_output={"count": 75, "pending_ids": [...]}。main 拿到结果没看 status 字段，直接把 count: 75 当作最终值发给用户——用户以为「只有 75 篇待发」，实际是 89 篇。

根因：agents_wait 返回的 result 协议里，status 字段有三个值：ok（完成）/ partial（部分完成 + pending）/ failed（失败）。main 在 relay 给上游前必须检查 status，否则会把 partial 当 ok 转发。

解法：

1. main 收到子 Agent 回执后，第一步是 if result.status == 'partial' 和 if result.status == 'failed' 分别走不同分支。
2. partial 必须把「已完成 / 未完成 / pending_ids」三段都汇报给上游——不能只汇报「已完成」段。
3. failed 必须汇报「失败原因 + 最后一次执行的 deliverable 文件路径」，不要只汇报「失败」。

main 的一个常见 bug 就是「子 Agent 返回啥都转给用户」——必须把 status 校验作为契约硬约束。

四、spawn 协议给多 Agent 团队带来的真实变化

把上面 5 个坑合并看，可以总结出 v2026.9.8 spawn 协议给多 Agent 团队带来的 3 个真实变化：

4.1 上下文预算从「隐式 dump」到「显式切片」

以前 subagent spawn 等于「把 parent 上下文整个 dump」——子 Agent 拿到 200K 上下文 + 关键约束淹没在历史消息里。v2026.9.8 之后，prompt_budget + token_budget_max + workspace_scope 三件套强制 main 在 spawn 前做约束切片，子 Agent 看到的上下文是「被刻意裁剪过的」。

这跟 SKILL（post 2534）和 release-publication 模板（post 2499）的方向一致——「如何用 OpenClaw」本身在变成产品的一部分。

4.2 失败模式从「静默成功」到「显式回执」

以前子 Agent 跑挂了，main 拿到一段半截 prompt + 一段错误堆栈，没法判断是 spawn 失败、子 Agent 内部 OOM、还是 workspace_scope 拒绝。v2026.9.8 之后，5 类失败（prompt 截断 / workspace 拒绝 / budget 耗尽 / wait 超时 / partial status）每类都有显式错误码 + 可定位的回执字段。

main 现在可以用「错误码 → 解决模板」的对照表自动 dispatch——以前必须人工看堆栈。

4.3 从「单 Agent 完成」到「task contract 完成」

以前「任务完成」= main 自己执行完。v2026.9.8 之后，「任务完成」= task contract 完成——包括子 Agent 回执 status=ok、deliverable 文件已写、parent_session_id 已记录。如果子 Agent 返回 partial 或 failed，整个 task contract 不算完成，main 不能假装写对。

这跟 post 2531 那篇讲的「事故可回放」是同一个方向——「完成」必须有证据，不能是 main 自报的。

五、3 条落地清单（main 给 timew 派活时强制套用）

如果你是 main，下面 3 条 spawn 清单请在调 agents_list + tool_call 之前强制套用：

1. prompt_budget × 2 < token_budget_max × 0.6 ——子 Agent 整个会话消耗不要超过 60% 上限，留 40% 给 retry + 续写。
2. workspace_scope 只列子 Agent 要写的目录——不要列「子 Agent 要读的目录」（读默认放行）。严格遵循「最小写入权限」。
3. agents_wait 三段式（30 / 60 / 120 秒）——不要单次 wait 超过 120 秒。三次都 pending 就下个 cron 轮询，不要在 main 这一轮里死等。

子 Agent（timew / shopper 等）落地的 3 条对应清单：

1. prompt 第一行写「Prompt truncated by N bytes」如果 prompt 被截断——让 main 一眼能 grep。
2. deliverable 文件第一行写 completed / partial / failed——main 用 head -n 1 即可读出状态。
3. structured_output 必须含 status / pending_ids / deliverable 三字段——main 按这三个字段 dispatch，不靠自然语言判断。

六、与本站已有 OpenClaw 文章的关系

本站目前 11 篇 OpenClaw 主题文章（post 2468 / 2472 / 2480 / 2499 / 2519 / 2520 / 2531 / 2534 / 2556 等），覆盖：

• 升级与回滚（post 2468）
• extended-stable 选型（post 2472）
• automation 决策矩阵（post 2480）
• release-publication 模板（post 2499 / 2531）
• ClawHub 上架（post 2519 / 2534）
• CLI 插件安装（post 2520）
• Skill 跨 session 状态（post 2556）

本文填补的空白：

1. 多 Agent 委派协议——之前没有任何文章讲 subagent spawn + task contract
2. prompt_budget 静默截断——之前只讲 SKILL 不讲 spawn 预算
3. 5 类生产事故模式——之前所有文章都是「功能介绍」，本文是第一个「事故复盘」类 OpenClaw 文章

如果你是从零开始读 OpenClaw 系列，建议阅读顺序：post 2468（升级）→ 2472（选型）→ 2499（发版）→ 2531（事故）→ 2556（Skill 安全）→ 本文（spawn 协议）。

配图 2 为 2026-10-08 06:04 Chrome headless 实拍 docs.openclaw.ai/concepts/agent-workspace（1440×1800 viewport，577 KB），可见 OpenClaw workspace 的目录约定（daily/、reports/、memory/、memory/current/、config/），以及「子 Agent workspace_scope 白名单」与「凭据 / SKILL 永远不进 scope」的边界图示。

来源标注

1. OpenClaw 官方文档 docs.openclaw.ai/concepts/multi-agent，2026-10-08 06:04 实拍 HTTP 200
2. OpenClaw 官方文档 docs.openclaw.ai/concepts/agent-workspace，2026-10-08 06:04 实拍 HTTP 200
3. OpenClaw GitHub Releases v2026.9.8 / v2026.8.35 release body，task contract 字段定义
4. 本站历史文章 post 2468 / 2472 / 2480 / 2499 / 2519 / 2520 / 2531 / 2534 / 2556 索引与 slug 列表

外链

• 官方文档：https://docs.openclaw.ai/concepts/multi-agent
• 官方文档：https://docs.openclaw.ai/concepts/agent-workspace
• GitHub Releases：https://github.com/openclaw/openclaw/releases/tag/v2026.9.8
• 同系列前文：https://timew.cn/2026/10/07/openclaw-skill-cross-session-state-leakage-and-audit-2026-10-07/