博客

从单 Agent 到多 Agent：实用迁移指南

大多数开发者一开始只用一个 AI Agent。本文讲讲如何扩展到多个并行工作的 Agent，以及这为什么会改变一切。

今天大多数使用 AI 编码工具的开发者，都是一次只运行一个 Agent。你打开 Claude Code，给它一个任务，等它完成，再给它下一个。它能用，但这是顺序执行。

当你第一次把两个 Agent 并行起来时，事情会发生变化。你不再是一个等待输出的打字员，而变成了一个编排者 - 分配工作、路由结果，并把注意力放在最关键的地方。

这篇文章会讲清楚如何从单 Agent 过渡到多 Agent 开发，以及让这种方式真正高效的心智模型转变。

单 Agent 的瓶颈

单个 AI Agent 不管多强，都有一个根本限制：它一次只能做一件事。Claude Code 在重构你的认证模块时，就不能同时给 API 层写测试。你只能等。

数学很简单。如果每个任务需要 5 分钟的 Agent 工作，而你有 10 个任务，单 Agent 需要 50 分钟。两个 Agent 只要 25 分钟。但真正的收益不只是墙上时钟时间 - 还有反馈回路。

当两个 Agent 处理相关代码时，Agent A 的重构输出可以立刻进入 Agent B 的审查流程。问题更快暴露，信息更新鲜，你能在几分钟内而不是几小时后发现集成问题。

不是所有任务都适合并行。最适合并行的通常是：

最糟糕的是紧耦合任务 - 两个 Agent 同时改同一个文件，一定会冲突。

一个很实用的经验法则：如果你会把这两个任务分配给两个不同的开发者，那它们也可以交给两个不同的 Agent。

基于标签页的工作流在多个 Agent 面前会失灵。你不可能同时看三个终端标签页 - 它们会互相遮挡，你会丢失上下文，还会忘记每个标签页到底在做什么。

这就是空间排布重要的原因。在画布上，你可以把 Agent 摆在看得到的位置。左边是终端 A，右边是终端 B，中间放一个 note 图块记录计划。你一眼就知道所有东西的状态。

空间模型不只是好看，它是认知上的优化。关于外部认知的研究表明，把信息以空间方式外化到环境中，可以减轻工作记忆负担。画布是你心智模型的延伸。

多个 Agent 需要一套信息流动方案。常见的有三种模式：

Agent A → Agent B → Agent C

每个 Agent 的输出都会流向下一个。例子：A 写代码 → B 审查 → C 写测试。

        → Agent B →
Agent A                 Agent D
        → Agent C →

一个 Agent 分发工作，多个 Agent 并行执行，结果再汇合。例子：A 把任务拆成子任务 → B 和 C 各自处理一个子任务 → D 整合结果。

Agent A ⇄ Agent B

两个 Agent 在同一份工作上反复迭代。A 写，B 审，A 改。收敛速度往往比你想象中更快 - 通常 2 到 3 轮。

多 Agent 工作里最大的摩擦，是交接。手动复制 Agent A 的输出，把它重写成提示词，再粘贴给 Agent B，既麻烦又容易出错。

自动路由可以消除这种摩擦。当 Agent A 完成后，系统会：

转换这一步非常关键。原始终端输出很吵 - ANSI 代码、进度条、详细日志。好的路由系统会提取语义内容，并把它包装成可执行指令。

多 Agent 工作需要不同的注意力模式。你不再盯着一个 Agent 的输出深度思考，而是横向扫描多个 Agent，关注：

可视化指示器会非常有帮助。颜色编码的状态指示器（工作中、等待中、已停止）让你一眼就能分拣注意力。脉冲动画会把你的视线吸引到活跃的 Agent。画布边缘的发光提示会提醒你有画外活动。

目标是降低监控的认知开销，让你把注意力放在真正有创造性的决策上 - 做什么、怎么架构、应该把精力投在哪。

多 Agent 工作最深层的变化，不是技术，而是你如何看待自己的角色。

单 Agent 时，你是一个 pair programmer。你和 Agent 一起关注同一件事。

多 Agent 时，你更像一个 tech lead。你设定方向、分配工作、审查结果，并做架构决策。Agent 负责执行。

这个转变一开始会不舒服。你会觉得自己应该逐行盯着每个 Agent 的输出看。但这无法扩展。你需要学会信任流程，在需要时介入，把精力放在真正需要你判断的决策上。

如果你今天还在用单 Agent，不妨试试：

这就是最朴素的多 Agent 开发。其他一切 - 自动路由、画布组织、状态检测 - 都只是为了让这个基本模式变得毫不费力的基础设施。