为什么我把团队 SOP 升级成了状态机，而不是继续靠默契

这次我决定把团队 SOP 升级一下。

不是因为我突然迷上了流程管理，也不是因为“多智能体协作”这个词最近听起来很热闹。更实际一点：原来那套做法虽然能跑，但越来越依赖聊天记录、临场判断和一点点默认共识。任务一小还好，任务一长、角色一多、需要 review 和回溯时，问题就开始冒头。

最典型的情况不是“做不出来”，而是：做到哪了、谁该接手、为什么这次算完成、如果 review 不通过该退回哪一步，这些事情越来越说不清。

所以这次升级，核心不是把流程变复杂，而是给失控加护栏。

旧问题不在于 agent 不够聪明，而在于边界和状态太模糊

回头看，之前那套流程最大的问题其实挺朴素：很多关键东西都默认靠人脑补。

比如角色边界。谁都能多做一点，听起来很灵活，实际结果往往是：谁都可能越权一点。实现的人顺手改了计划，审查的人顺手补了代码，主控的人在 review 还没真正过的时候先把任务往“差不多完成”上靠。单看每一步都不算离谱，连起来就开始失真。

再比如 review。如果 review 只是一个建议位，而不是一个真正的 gate，那么它本质上就只是“看了一眼”。一旦节奏赶起来，系统自然会倾向于把“没有明显问题”误判成“可以收口”。

还有过程不可观测的问题。很多时候并不是任务真的复杂到无法理解，而是状态表达得太含混。research 结束了吗？plan 是草稿还是最终版？builder 现在是在实现、在自测，还是已经卡住了？如果这些都只能靠聊天上下文猜，流程就很难稳定。

说白了，问题不只是能力问题，而是系统没有把责任、边界、证据和回退路径写清楚。

这次升级，真正新增的不是步骤，而是一个可执行的状态机

这轮 SOP 最大的变化，是从“按顺序走几步”变成了“任何正式任务都必须处在一个明确状态里”。

现在一项正式任务会落在这些状态之一：

• Intake
• Research
• Plan
• Approval Pending
• Implement
• Verify
• Review Gate
• Ready to Report
• Done
• Blocked
• Cancelled

这听起来像是把流程写得更像制度了，但真正有用的地方不是形式感，而是它让每个任务在任何时刻都能回答四个问题：

1. 现在在哪一层
2. 上一步是什么
3. 下一步应该是什么
4. 如果失败，应该退回哪里

这四个问题以前不是没人知道，而是经常只有局部知道。main 可能知道，builder 可能以为自己也知道，review 又是另一套理解。等任务跨了几个回合之后，大家对“现在到底进行到哪”会慢慢出现细微偏差。真正出问题的，往往就是这些细微偏差。

把流程写成状态机以后，最少有两件事变得更诚实了。

第一，Approval Pending 不再是空气墙。计划没有得到明确确认，就不能进入 Implement。不是“差不多默认开工”，而是必须停住。

第二，Blocked 和 Cancelled 变成了合法状态。过去很多任务实际上已经卡住了，但系统里没有“卡住”这个正式出口，于是大家会用各种模糊表达继续维持一种“还在推进”的假象。现在至少可以明确：卡住了，为什么卡，等谁解除，解除后回到哪一层。

我越来越觉得，Blocked 不是失败，假装没 blocked 才是。

Review 不再只是建议，而是硬闸门

这次我最想收紧的一点，其实是 review。

以前最危险的地方就在这里：review 说了点意见，但系统层面没有真正的阻断力。最后 main 还是可能在“看起来问题不大”的氛围里，先把任务往完成态推进。

现在的规则更直接：

• 没有 Verify 证据，review 不得 PASS
• Review Gate 没有 PASS，任务不能进入 Ready to Report
• review FAIL 时，任务必须显式回退到 Implement 或 Plan
• review 不是装饰，它就是一道闸门

这件事看起来像是在加流程，其实是在减少幻觉式成功。

在工程协作里，最麻烦的一种错误不是明显失败，而是“其实没过，但大家都当它过了”。对 agent 工作流来说，这种错误尤其危险，因为 agent 很擅长生成“已经像完成”的文本，但文本的完成感和交付的完成度不是一回事。

如果 review 不是 gate，它就只是意见。

文档这次不是附属品，而是协议本身

这轮升级里，我还把任务卡、计划模板和 review verdict 模板都固定了下来。

这不是为了文档好看，而是因为我越来越确认：如果希望后续 agent 稳定执行，关键规则必须写成固定字段、固定模板、固定输出格式。否则每次 handoff 都在重新发明协议。

所以现在正式任务至少会有这些东西：

• 一张任务卡
• 一份可执行 Plan
• 一份 Verify 结果摘要
• 一份 Review Verdict

任务卡最重要的价值，不是留档，而是让任务可接手、可追踪、可回放。聊天上下文当然也有价值，但聊天记录天然偏流动、偏局部、偏瞬时。任务卡更像一块稳定的落点，至少不会因为上下文变长、线程变多、参与者变化而失去主干。

我这次特别在意“单一事实源”这件事。不是因为它听起来高级，而是因为只要没有单一事实源，流程迟早会回到各说各话。

SOP 不是写完就算，必须落到真实的角色边界和工具权限上

如果规则只停留在文档里，那它最多算一篇态度端正的说明文。

所以这次升级，我同时把 agent 结构和工具边界也重做了一轮。核心工程链被收敛成五个角色：

• main：做 intake、汇总、确认、收口
• scout：做 research 和信息整理
• brain：做架构、计划和约束
• builder：做实现和最小自测
• review：做审计和 PASS/FAIL 复核

creator 还在，但它被放回外围位置，主要负责写作和媒体内容，不再混进正式工程主链。deputy 暂时保留成 PM 备援，但我也不想让它继续无限镜像 main。

更重要的是权限边界的重划。

这次最有价值的改动，可能恰好是“谁不能再做什么”：

• builder 不再有 gateway
• review 不再有 edit
• brain 获得了真正能沉淀设计资产的 write/edit
• scout 从一组不够稳定、也不够好验证的 web 工具名，转向更可复核的 research 工具链

这类改动不华丽，但很关键。很多流程问题，本质上不是提示词问题，而是权限设计问题。SOP 里写得再清楚，如果运行时的角色边界没有一起收紧，最后还是会漏回“谁方便谁先做”。

当然，真实世界比文档更顽固一点。我们在 smoke test 里很快就看到一件事：就算 builder 没有 gateway 这个 tool，只要它还有 exec，它依然可能通过 CLI 间接接触到 gateway 相关能力。

这件事反而提醒我，制度约束和技术隔离不是一回事。前者我已经开始做了，后者还得继续补。

模型策略也一起重做了，但主角不是“最强模型”

这次另一个顺手但必要的动作，是把 agent 的模型路由也一起重构了。

原因并不复杂：如果角色边界变清晰了，但模型策略还是“哪个强就都上哪个”，那系统稳定性还是会受制于单点故障和角色错配。

所以这轮调整里的原则很简单：

• 按角色匹配模型特性，而不是按排行榜分配
• 给关键岗位保留异构 fallback
• 尽量跨 provider，避免一处拥堵拖垮整条链

比如 architect、review 这类角色更需要稳定推理和长文组织；builder 更看重代码任务适配；scout 更需要轻快、低摩擦的整理能力；creator 则更该偏向语言表达，而不是硬挂在不顺手的 code-first 模型上。

这背后其实不是模型选择洁癖，而是系统设计思维。真正怕的，不是某次回答没那么惊艳；真正怕的是某个 provider 一抖，整个链路某一环直接瘫掉。

顺便说一句，这类问题也不是假设。我在小测试里已经遇到过 scout 因为特定模型路径高峰期表现不稳定而拖时，后面就把主路径切到了更稳的备选上。这种调整看似琐碎，但它才是流程真正开始“可运行”的地方。

这次升级最重要的，不是规范本身，而是让人和 agent 都更诚实

我越来越觉得，很多协作问题都不是因为大家不努力，而是因为系统鼓励了一种含混。

比如：

• “已经做完了”，其实只是“我觉得差不多了”
• “还在推进”，其实已经卡住，只是没有明说
• “review 过了”，其实只是“看起来问题不大”
• “顺手一起改了”，其实 scope 已经悄悄扩散

这次 SOP 想做的，不是把所有人管得更死，而是把这些模糊状态变成显式决定：

• 是否批准开工
• 是否真的进入 Verify
• Review 是否 PASS
• 当前是不是 Blocked
• 这次到底算不算 Done

如果一个流程能逼着参与者更诚实一点，它通常就已经比“靠气氛维持”更接近可靠系统了。

我刻意没有把它做成一套很重的管理机器

这轮设计我一直提醒自己：不要上头。

所以我刻意没有做几件事：

• 没有继续扩角色数量
• 没有把每个任务都拖进沉重审批流
• 没有试图一次性解决所有 agent orchestration 问题
• 没有因为“流程化”就否定 Quick Mode
• 没有急着删掉 creator 和 deputy，而是先做定位收敛

一个流程最容易失控的时候，不只是它太松，也包括它突然变得过重。真正好的升级，应该是把必要的约束补上，但别把每一次动作都搞成仪式。

所以至少在现在，我更愿意把 v1.1 看成一份 draft executable spec：先拿真实任务去跑，再根据摩擦点继续修，而不是一开始就幻想自己写出了某种终极范式。

对流程最好的尊重，不是把它写得漂亮，而是拿真实任务去跑，看看它到底是减摩擦，还是制造新摩擦。

最后：AI 团队协作并没有逃出那些老问题

折腾到最后，我反而更确定一件事：不管协作者是人还是 agent，工程协作终究绕不开那些老问题——责任、边界、证据、回退。

模型会换，工具会换，甚至角色名字也会换，但真正决定系统稳不稳的，通常不是“最强模型是谁”，而是：

• 谁能做什么
• 什么时候算完成
• 出问题时怎么回退
• 谁来给 PASS，凭什么给 PASS

这次我升级团队 SOP，本质上不是在发明新东西，而是在把这些老问题重新补齐。

它不会让我一夜之间变成一个完美的编排大师，但至少会让我少一点靠默契撑流程，多一点靠制度保护交付。

这已经很值了。