1. 为什么我把编排器拆了openclaw 多 Subagent 协作的真实痛点如果你正在用 openclaw 跑多仓库重构、内容流水线或者研究冲刺这类活儿大概率遇到过同一个瓶颈主会话变成了交通警察。每来一个任务主智能体都要判断该派给谁、进度到哪了、谁被谁卡住了上下文越滚越大响应越来越慢最后你发现自己不是在管项目而是在管一个记性越来越差的调度员。Autonomous Project Management 这个用例的核心思路很直接把中央编排器干掉让 Subagents 通过一个共享的 STATE.yaml 文件自己协调。主会话只做 CEO 该做的事——定策略、派活、收结果执行细节全部下沉。我实测下来这套模式在 openclaw 里落地并不复杂关键是把 STATE.yaml 的结构和 sessions_spawn 的调用方式配对好。这篇笔记就围绕两件事展开一份可以直接复制的 STATE.yaml 配置骨架以及 sessions_spawn 的调用示例和验证方法。适合已经在用 openclaw、想从单会话手动操作升级到多子代理自治协作的开发者。读完你能在自己的项目里搭起一个能跑的项目管理雏形而不是停留在概念层面。2. TaoToken 前置给 openclaw 的 Subagents 配一个稳定的模型入口openclaw 本身是编排框架Subagents 干活时还是要调模型。多子代理并行意味着并发请求量比单会话高不少如果模型入口不稳定STATE.yaml 的状态回写就会断断续续整个自治流程直接卡死。我试过在高峰期用不稳定的入口跑三个并行 PM结果两个子代理的进度更新丢了STATE.yaml 里任务状态和实际执行完全对不上。所以前置这一步不能省。TaoToken 在这里的角色是给 openclaw 提供一个统一的模型调用入口支持多模型切换方便你在不同 Subagent 上分配不同能力的模型——比如负责代码重构的 PM 用强推理模型负责内容迁移的 PM 用长上下文模型。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要先拿到 API Key然后配置到 openclaw 的环境变量里。具体操作路径是登录后进入控制台在 API Keys 页面创建一个新 Key复制保存。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 页面是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言的调用示例配置前扫一眼能省不少排错时间。注意API Key 不要硬编码在 STATE.yaml 或 AGENTS.md 里用环境变量注入。STATE.yaml 是要提交到 git 的Key 泄露了很麻烦。3. 可复制配置STATE.yaml 骨架与 AGENTS.md 委托规则3.1 STATE.yaml 配置骨架这份骨架是我在实际项目里跑通的版本字段做了精简保留了协调必需的部分。你可以直接复制到项目根目录改掉 project 名和任务列表就能用。# STATE.yaml - 项目协调文件 project: website-redesign updated: 2026-02-10T14:30:00Z main_session: ceo-mode tasks: - id: homepage-hero status: in_progress owner: pm-frontend started: 2026-02-10T12:00:00Z notes: 响应式布局调整中断点 768/1024 已覆盖 depends_on: [] - id: api-auth status: done owner: pm-backend completed: 2026-02-10T14:00:00Z output: src/api/auth.ts depends_on: [] - id: content-migration status: blocked owner: pm-content blocked_by: api-auth notes: 等待新 endpoint schema 确认 depends_on: [api-auth] next_actions: - pm-content: api-auth 已完成恢复迁移任务 - pm-frontend: 与设计团队确认 hero 区域字段说明用表格对照更清楚字段作用是否必填project项目标识与 label 前缀对应是updated最后更新时间用于判断状态新鲜度是tasks[].id任务唯一标识是tasks[].statuspending/in_progress/done/blocked是tasks[].owner负责的 Subagent label是tasks[].depends_on依赖的任务 id 列表否tasks[].blocked_by当前阻塞来源否next_actions主会话下轮检查时的行动建议否3.2 AGENTS.md 委托规则AGENTS.md 是 openclaw 读取的代理行为配置。把下面这段放进项目根目录的 AGENTS.md主会话就会进入 CEO 模式。## PM 委托模式 主会话 仅协调器。所有执行交给 Subagents。 工作流程 1. 新任务到达 2. 检查 PROJECT_REGISTRY.md 寻找现有 PM 3. PM 存在 → sessions_send(labelpm-xxx, message[task]) 4. 新项目 → sessions_spawn(labelpm-xxx, task[task]) 5. PM 执行更新 STATE.yaml回报 6. 主会话向用户总结 规则 - 主会话最多 0-2 次工具调用仅 spawn/send - PM 拥有自己的 STATE.yaml 文件 - PM 可为并行子任务生成子子代理 - 所有状态变更提交到 git3.3 sessions_spawn 调用示例主会话派活时sessions_spawn 的参数要写清楚 label 和 task。label 用pm-{project}-{scope}格式方便后续追踪和 sessions_send 定位。# 主会话中派发新 PM sessions_spawn( labelpm-auth-refactor, task重构 auth 模块并更新文档。在 STATE.yaml 中跟踪任务分解和进度。完成后提交 git 并回报。 )如果 PM 已经存在用 sessions_send 追加任务避免重复 spawn# 向已有 PM 追加任务 sessions_send( labelpm-auth-refactor, message[task] 补充为 auth 模块添加单元测试覆盖 token 刷新路径。 )PM 子代理内部再拆并行子任务时可以继续 spawn 子子代理但 label 要加层级前缀比如pm-auth-refactor-test否则状态回写会串。4. 验证请求确认任务分发与状态回写生效配置写完不代表能跑。你需要验证两件事子代理任务分发是否到位STATE.yaml 状态回写是否及时。下面是我用的验证流程。第一步触发一个测试任务观察主会话是否只做了 spawn 调用。在 openclaw 里发一条指令User: 重构 auth 模块并更新文档预期主会话行为检查 PROJECT_REGISTRY.md没有活跃的 pm-auth调用 sessions_spawn然后回复类似「已派发 pm-auth-refactor完成后回报」。如果主会话自己开始改代码说明 AGENTS.md 的委托规则没生效回去检查规则段落是否被正确加载。第二步检查 STATE.yaml 是否被 PM 创建并写入。等几秒后查看文件cat STATE.yaml你应该看到 tasks 列表里出现了 auth 相关的任务分解status 从 pending 变为 in_progress。如果文件没变化可能是 PM 没有文件系统写权限或者 STATE.yaml 路径不在 PM 的工作目录内。第三步验证状态回写的时间戳。PM 每次更新都应该刷新 updated 字段。你可以用 git log 看提交历史git log --oneline -- STATE.yaml每次状态变更对应一条提交这就是审计日志。如果提交信息里能看到任务 id 和状态变化说明回写链路是通的。第四步测试阻塞解除。把 api-auth 标记为 done 后观察 pm-content 是否自动从 blocked 转为 in_progress。这一步验证的是依赖解析逻辑如果没触发检查 blocked_by 和 depends_on 字段是否写对。5. 本篇常见错排查5.1 STATE.yaml 写入冲突多个 Subagent 同时写同一个 STATE.yaml 会互相覆盖。openclaw 本身不提供文件锁你需要靠约定规避每个 PM 只写自己 owner 的任务条目不要整文件重写。如果必须整写在 PM 的 task 描述里加一句「写入前先读取最新版本合并后再写」。5.2 sessions_spawn label 重复label 重复会导致 sessions_send 发错对象。派发前先查 PROJECT_REGISTRY.md确认没有同名活跃 PM。如果 PM 已完成但没清理注册表下次 spawn 会冲突。建议 PM 完成时在注册表里标记 status: done而不是直接删除保留追踪记录。5.3 状态回写延迟导致误判PM 更新 STATE.yaml 有延迟主会话如果立刻读取可能看到旧状态。验证时等 3-5 秒再读或者让 PM 在回报消息里带上当前状态快照。生产环境里可以在 STATE.yaml 加一个 version 字段每次写入递增主会话比对 version 判断是否拿到最新。5.4 模型调用超时中断回写Subagent 调模型超时后如果直接退出STATE.yaml 里的任务会卡在 in_progress。在 PM 的 task 描述里要求「异常退出前将任务状态改为 blocked 并记录原因」。另外 TaoToken 的接入文档里有超时和重试配置说明地址是 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配一下能减少这类中断。5.5 git 提交遗漏PM 忘记提交 STATE.yaml状态只存在本地其他代理读不到。在 AGENTS.md 规则里明确「所有状态变更提交到 git」并在 PM 的 task 里把提交作为完成条件之一。验证时用 git status 确认没有未提交的 STATE.yaml 变更。6. 长期编码与 Agent 场景的 CTA如果你打算把这套模式用在长期编码项目或者常驻 Agent 上单次 API 调用按量计费可能不太划算。TaoToken 的 Coding Plan 适合这种持续跑 Subagents 的场景地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 里面有套餐说明。模型对话调试入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 接入过程中遇到报错先去接入文档对照参数大部分问题在文档里都有示例。最后说一个我踩过的坑STATE.yaml 的 tasks 列表不要无限增长。项目跑久了任务条目会堆到几百条PM 每次读取都消耗大量上下文。我的做法是每周归档一次把 done 超过 7 天的任务移到 STATE_archive.yaml主文件只保留活跃任务。这个归档动作可以交给一个专门的 pm-archive 子代理定时执行主会话完全不用管。