AI 协作工程化 01：别把 Agent 当流水线，为什么需求协作需要状态机
一条看似顺畅的 Agent 流水线，常常在第二次继续执行时失效：设计已经写了一半，开发改了几处代码，审查留下了问题，但没有人能准确回答“现在该谁接手、该带什么上下文、什么情况下才算结束”。这不是模型能力不足，而是把协作系统误当成了提示词拼接。
需求协作需要的是一个能恢复、能审计、能拒绝错误交接的状态机。本文讨论的不是某个产品的实现，而是一套将需求设计、开发和审查组织为确定性流程的工程方法。
提示词串联为什么不够
最朴素的协作链路是：需求输入交给设计 Agent，设计结果交给开发 Agent，代码再交给审查 Agent。它在一次完整、无中断的演示中工作得很好，但现实会很快出现三个断点。
- 中断不可恢复：会话被打断后，系统只能根据自然语言猜测进度，容易重复设计或跳过审查。
- 角色边界会漂移：开发 Agent 发现设计缺口时，可能直接改计划；审查 Agent 也可能在报告中自行指定下一位执行者。
- “做了什么”替代了“是否完成”：写出草稿、跑过命令、生成了报告，都可能被误报为一个阶段已完成。
解决思路不是继续增加提示词，而是把流程的状态压缩为一个小而稳定的控制模型：每个需求只有一个活跃工作单，角色只处理与该工作单匹配的责任，只有合法交付才会推动状态变化。
一个最小状态机
下面的模型有五个专业阶段：设计、设计审查、开发、实现审查、验收审查。它并不要求所有需求都一次通过，但要求每一条回路都有明确语义。
这张图最关键的部分不是阶段数量，而是路由规则：下游由当前阶段和交付结果共同决定，而不是由某个 Agent 的主观建议决定。换句话说，角色可以说明问题和证据，但不能修改流程控制权。
工作单比会话更可靠
一个工作单至少需要表达四件事：唯一 ID、当前阶段、责任角色和本次关注范围。入口设计额外携带完整的用户原始输入；后续角色则从稳定 ID 和引用进入对应事实。
id: WO-017
phase: developer
role: developer
focus:
- table: task
row_ids: [TASK-007]这类结构带来两个直接收益。
第一，恢复不再是“请继续刚才的工作”。系统重新进入时，只要发现存在活跃工作单，就把相同工作单再次交给相同角色。中间草稿不是完成标志；除非角色明确等待用户输入、确认、授权或外部前置条件，否则它必须继续处理。
第二，旧交付天然失效。一个 Return 只有在其 work_order_id 与当前活跃工作单一致时才可能被接受。当前工作单已经轮换后，迟到的旧 Return 不会覆盖后续状态。
状态机如何处理追加需求
“追加”常被实现成在原文档末尾补一段文字，这会让历史设计、历史验收与新范围纠缠在一起。更稳妥的做法是：已完成需求收到追加时，创建新的入口设计工作单，并标记它属于 append 运行；旧事实仍是只读背景，新发现的问题用新的需求点、设计项和任务承载。
这避免了两个典型误区：
- 为了修一个历史问题，直接改写旧台账，使当时的审查结论失去语境。
- 因为是“追加”，就绕过设计和审查，直接让开发修改代码。
追加不是一个特殊捷径，而是新的受控变更入口。
串行是约束，也是保护
一个需求只保留一个活跃工作单，看上去牺牲了并行度，实际保护了三个不变量：当前负责人唯一、状态写入唯一、回退原因唯一。设计还没有通过时，开发不能假装自己只是“先做一点”；验收已经打回时，也不能同时让设计和开发分别修改不同版本的事实。
这并不意味着所有工作都必须串行。角色内部的只读调查、资料检索、测试准备可以并行，真正需要串行的是会改变需求事实或流程状态的决策。
TIP
判断能否并行，不要问“有几个 Agent 可用”，而要问“两个动作是否会竞争同一份事实的解释权或写入权”。
常见反模式
| 反模式 | 表面上的好处 | 实际后果 |
|---|---|---|
| 用聊天摘要保存进度 | 写得快 | 不能机械恢复，也无法判断摘要是否过期 |
| 允许角色直接跳阶段 | 少一次交接 | 绕过质量门，责任无法追溯 |
| 把“已开始”当作结束 | 进度看起来积极 | 工作单悬空，下一次恢复容易断链 |
| 同一需求并行多个写入角色 | 吞吐量高 | 范围、证据与验收基线相互覆盖 |
小结
把 Agent 当流水线时，系统依赖上下文连续和角色自觉；把需求协作设计为状态机时，系统依赖明确状态、固定路由和可验证交接。前者适合一次性辅助，后者才适合长期演进的工程流程。
下一篇会继续拆解状态机的控制面：谁有权改状态，为什么 Handoff 与结构化 Return 要彼此配合。
系列导航：