AI · 协作 · 流水线

代理人团队

当 AI 学会分工协作从单人 AI 到代理人军团——Chain、Parallel、Interactive 三种多 Agent 编排模式实战

上下文过长导致"遗忘"：当对话超过 50 轮，AI 开始忘记它在第 10 轮分析的架构约束。修改模块 A 的时候，它已经忘了模块 A 为什么要这么设计。角色混淆导致"敷衍"：同一个 AI 写的 Spec，让它自己去实现——它能客观判断 Spec 的质量吗？自己审查自己的代码，能发现逻辑漏洞吗？不能。就像你不会让同一个程序员既写代码又做 Code Review，这不叫审查，叫自我安慰。

模式：上一个 Agent 的输出，自动成为下一个 Agent 的输入。流程：需求 → Scout 调研代码库 → Planner 制定方案 → Worker 编码实现 → Reviewer 审查代码 → 完成适用场景：需求明确的中大型任务。每个环节的输出质量直接影响下一个环节。如果 Planner 的方案有问题，Worker 会执行错误——所以 Scout 和 Planner 的质量是整个链路的瓶颈。实例：上个月我在一个项目中新增了 OAuth2 认证模块。Scout 花了 3 分钟读完了现有的中间件体系和用户模型；Planner 输出了 200 行的实现方案（涉及 8 个文件的改动）；Worker 按方案依次修改了每个文件；Reviewer 发现 Planner 遗漏了 token 刷新策略——如果不是独立审查，这个遗漏会直接上线。

模式：同一个任务拆成多个互不依赖的子任务，每个交给一个独立的 Agent 并行执行。流程：需求 → 拆分为 3 个子任务 → Worker A 实现模块 A + Worker B 实现模块 B + Worker C 编写测试 → 全部完成后合并适用场景：可以拆分为独立模块的任务。比如前后端分离的项目：一个 Worker 写后端 API，另一个 Worker 写前端页面，第三个 Worker 写集成测试——三个 Agent 同时工作，总耗时等于最慢的那个，而不是三个累加。关键前提：任务拆分必须正确，模块之间没有隐藏依赖。如果模块 A 依赖模块 B 的输出，却放在并行里执行——结果就是两个 Agent 各自工作后无法合并。

pi-interactive-shell 扩展让 pi-agent 不只是调用内置的 subagents——它还能在终端中启动外部的 CLI Agent：Claude Code、Cursor CLI、Gemini CLI、Codex CLI。为什么需要这个？每个 CLI Agent 有自己的特长。Claude Code 擅长复杂架构分析，Cursor 擅长多文件重构，Gemini 擅长长文本理解。pi-agent 作为"指挥中心"，根据任务类型调度最合适的工具。使用方式：在 pi-agent 的上下文中，说"让 Claude Code 分析这个模块的架构问题"，pi 就会在后台启动 Claude Code，把当前代码作为输入，等它完成后再把结果拿回来。你不需要手动操作——pi 自动管理不同 CLI 之间的上下文传递和结果收集。

当 Planner 给出多种实现方案时，如何对比选择？pi-design-deck 会在 macOS 上打开一个原生的方案对比窗口——左栏是方案 A，右栏是方案 B，中间是差异对比。代码 diff、Mermaid 架构图、UI 预览——三种形式同时呈现。这比在纯文本里看"方案 A 的优势是……方案 B 的优势是……"直观得多。特别是涉及架构决策时，一张图胜过千言万语。

在把需求交给 Planner 之前，需要先把需求澄清清楚。pi-interview 弹出一个交互式表单——单选、多选、文本框——让你在开始之前就把模糊的需求变成具体的约束。比如"我要加个权限系统"——这在 Planner 看来太模糊了。但经过 interview 的引导："角色有几种？继承关系是怎样的？是否需要动态权限？审计日志要做到什么粒度？"——需求就变成了 Planner 能直接执行的规格说明。

一个好的 Spec 胜过 10 轮对话纠偏。一个独立的 Reviewer 比自审可靠 10 倍。一支编排得当的代理人团队，让一个人的产出媲美一个小团队。