#流水线式多 Agent 协作

#提出问题

不是所有多 Agent 都需要动态调度。很多任务看起来复杂，但阶段顺序很稳定。

例如写一份行业研究报告、完成一次代码迁移、处理一批合规材料、生成一次数据分析结论，通常都有清楚的阶段：

收集资料 -> 生成方案 -> 产出初稿 -> 校验事实 -> 修改定稿

这类任务更适合流水线式多 Agent。它不追求 Agent 自由协商，而是让不同 Agent 负责不同阶段，每个阶段交付明确产物。

#场景

看一个代码迁移助手。

用户输入：

把项目里的旧版状态管理迁移到新的 store 方案，保留行为，补测试，并写迁移说明。

这件事可以拆成稳定流水线：

每个阶段都可以独立定义输入输出：

• Discovery 输出使用点清单和风险。
• Plan 输出迁移步骤和不改动范围。
• Implement 输出 diff。
• Test 输出测试结果和覆盖说明。
• Review 输出阻断问题和建议。
• Docs 输出迁移说明。

这比让多个 Agent 同时讨论“怎么迁移”更稳定。

#分析问题

#流水线的价值

流水线式多 Agent 的核心优势，是把复杂任务变成可观察的阶段流转。

流水线式协作本质上接近 Workflow，只是每个节点可以由不同 Agent 承担。

#阶段契约

流水线成败取决于阶段契约。每个阶段都要定义：

• 输入是什么。
• 输出是什么。
• 输出必须包含哪些证据。
• 哪些错误会阻断下一阶段。
• 哪些结果可以降级继续。
• 是否允许修改上游产物。

例如 Discovery 阶段输出可以是：

{
  "files": ["src/store/user.ts", "src/pages/settings.tsx"],
  "usagePatterns": ["direct import", "selector helper"],
  "risks": ["settings 页面依赖初始化顺序"],
  "unknowns": ["旧 store 是否被插件动态引用"],
  "recommendedNextStep": "先迁移 user store，再处理 settings 页面"
}

如果 Discovery 只输出一段自然语言，后续 Plan Agent 很难可靠接上。

#阶段门禁

每个阶段之间应该有门禁，而不是上一个 Agent 说完成就自动进入下一步。

常见门禁包括：

门禁可以由程序、Reviewer Agent 或人工承担。高风险任务最好不要让同一个 Implement Agent 自己放行自己。

#收益和成本判断

流水线式多 Agent 的收益：

• 控制流稳定，容易理解和复盘。
• 每个阶段可以用最适合的模型和工具。
• 失败可以定位到具体阶段。
• 输出产物可以沉淀为文档、清单和测试。
• 比自由协作更适合生产流程。

成本：

• 阶段契约需要设计。
• 串行阶段会增加总耗时。
• 上游错误会传递到下游。
• 阶段太细会产生过多管理开销。
• 后续阶段可能需要回到上游重新修正。

#列举方案

#固定串行流水线

最简单的流水线是固定顺序。

Research -> Draft -> Review -> Revise -> Final

适合内容生产、报告生成、文档审核等任务。优点是简单，缺点是并行空间小。

#带并行分支的流水线

当某些阶段互不依赖，可以并行。

这种方式适合研发任务。并行前要先有共享契约，例如 API schema 或文件边界。

#可回退流水线

复杂任务中，Review 可能发现问题，需要回到上游。

Implement -> Test -> Review
                  ├── pass -> Final
                  └── fail -> Plan / Implement

这时要记录阶段版本。否则下游修改会覆盖上游假设，系统很难知道应该回退到哪里。

#人机混合流水线

高风险阶段可以插入人工确认：

Agent Research -> Agent Plan -> Human Approve -> Agent Implement -> Agent Review

适合采购、合同、合规、财务和生产代码发布等场景。多 Agent 不意味着全自动，阶段门禁越清楚，自动化越可靠。

#决策判断

#方案选型表

#反模式

第一种反模式：阶段只有名字，没有产物。

“研究阶段”“实现阶段”只是标签。没有输入输出契约，就无法判断阶段是否完成。

第二种反模式：所有阶段共享同一上下文。

流水线应该传递阶段产物，而不是把所有中间对话都堆给下一个 Agent。下游需要的是结构化摘要、证据和约束。

第三种反模式：没有门禁。

上游输出错误时，下游 Agent 会把错误当事实继续放大。阶段之间必须有校验。

第四种反模式：阶段过细。

每个小动作都拆成 Agent 会制造调度噪音。阶段应该按产物和责任拆，而不是按自然语言动作拆。

第五种反模式：Review 只在最后发生。

如果任务很长，最后才 Review 会导致返工巨大。高风险节点应该早放门禁。

#结论收束

流水线式多 Agent 是最接近生产工作流的多 Agent 形态。

它适合阶段稳定、产物明确、需要逐步验收的任务。相比自由协作，它牺牲一部分灵活性，换来更好的可观测性、可恢复性和质量控制。

#工程清单

• 阶段定义：每个阶段是否有清楚职责。
• 输入输出：阶段产物是否结构化、可校验。
• 证据传递：下游是否能看到上游依据，而不只是结论。
• 门禁策略：哪些条件阻断进入下一阶段。
• 回退机制：Review 失败后回到哪个阶段。
• 并行边界：并行分支是否避免写入冲突。
• 上下文压缩：是否传阶段摘要而不是完整对话。
• 人工确认：高风险阶段是否有人类批准。
• 状态记录：阶段状态、产物、版本是否持久化。
• Eval：是否分别评估研究、方案、实现、测试和 Review 质量。