当一个 Agent 变成多个 Agent 协同工作，如何设计它们之间的配合方式？图为分布式系统协调的抽象表示。
背景：从”单兵作战”到”团队配合”
如果你用 AI Agent 做开发，大概经历过这个场景：让它帮你改一个文件、等它完成、再让它改下一个文件。这是典型的”单兵作战”模式——一个 Agent 对着你一个人，从头干到尾。
但如果你同时有 8 个任务要处理呢？比如：给 4 个模块加错误处理、扩展测试覆盖率、更新文档、清理 CLI 代码。如果还是让一个 Agent 顺序处理，你的时间等于”所有任务时间的总和”。
有没有可能让多个 Agent 同时开工？
这正是过去几个月 AI 领域最活跃的探索方向之一：如何让多个 AI Agent 协同工作，变成一个”球队”而不是一个”独行侠”。
为什么需要多 Agent 系统？
单 Agent 的瓶颈
单 Agent 面临几个核心限制：
注意力分散：当一个 Agent 同时处理多个任务时，上下文窗口会被不同任务的片段填满，导致推理质量下降
缺乏专业化：一个 Agent 很难同时是”代码专家”+”文档专家”+”测试专家”。让它同时做这些，结果往往是每个都做得一般
容错性差：一个任务失败，整个流程就卡住了。没有”备选”或者”补位”机制
扩展性差：任务变多时，只能靠延长等待时间来解决，没有”加人手”的选项
多 Agent 的价值
多 Agent 系统的核心价值在于：
- 并行处理：8 个任务同时开工，你的总时间取决于”最慢的那个任务”，而不是”所有任务时间的总和”
- 专业化分工：可以让一个 Agent 专门写测试，另一个专门改文档，第三个专门做代码重构
- 容错与补位：一个 Agent 失败了，其他 Agent 可以接管它的任务
- 可扩展性：任务变多时，只需要增加 Agent 数量
这也是为什么 Andrej Karpathy 最近提出，AI Coding 在 December 2025 跨越了一个”质变点”——从”脆弱的演示”变成了可以”持续完成长周期任务”的系统。其中一个关键推动力就是多 Agent 架构的成熟。
实践方案一：Terminal Stampede——用 tmux + 文件系统做”轻量级”并行
Terminal Stampede 用简单的 tmux + 文件系统实现了 8 个 Agent 并行工作。图为终端多路复用的抽象表示。
如果你觉得那些复杂的 Agent 框架（LangGraph、CrewAI、AutoGen）太重，Terminal Stampede 是一个值得关注的”轻量级”方案。
它的核心思路极其简洁：不用 Redis，不用 HTTP，不用 Docker，不用云服务。只需要 tmux + 文件系统。
工作原理
-
任务队列是文件：每个待处理的任务是一个 JSON 文件，放在
.stampede/$RUN_ID/queue/目录下 -
任务认领是原子操作：Agent A 想认领任务时，执行
mv queue/task-001.json claimed/task-001.json。如果文件已经不存在（被其他 Agent 抢走了），mv 会失败，Agent 就去抢下一个。没有锁，没有数据库，文件系统保证原子性 -
每个 Agent 是独立的 tmux pane：每个 Agent 运行在独立的 tmux 窗格中，有自己的 200K token 上下文窗口。它们之间不共享内存，完全隔离
-
协调器监控进度：一个主脚本监控所有 Agent 的状态，如果某个 Agent 意外退出，它会把这个任务重新放回队列，让其他 Agent 接管
-
自动合并：所有 Agent 完成后，一个 merger agent 负责把结果合并到主分支。它会按变更大小排序（从小到大），逐个合并，并尝试用 AI 解决冲突
它解决了什么问题？
- 零基础设施：不需要部署复杂的多 Agent 框架，几个 shell 脚本就搞定
- 人类全程可见：每个 Agent 在独立的 tmux pane 中运行，你可以随时”zoom in”看它在做什么，甚至直接和它对话
- 资源利用率高：8 个 Agent 并行，总共 1.6M token 上下文（8 × 200K），而不是单 Agent 的 200K
- 容错机制：Agent 挂了？任务自动重新入队，其他 Agent 会补上
适用场景
- 本地开发、代码重构、大规模测试覆盖
- 不想部署复杂基础设施的小团队
- 需要”可视化”看到每个 Agent 在做什么的场景
实践方案二：Mission Control——分布式任务编排系统
如果你需要的不只是”本地 8 个 Agent 并行”，而是”跨多台机器的分布式 Agent 协作”，Mission Control 是个更完善的方案。
这是一个用 PostgreSQL + LISTEN/NOTIFY 做实时同步的分布式任务编排系统，最初为 OpenClaw 定制，但思路可以迁移到其他 Agent 系统。
核心架构
Mission Control 的架构有几个关键组件：
共享状态层（PostgreSQL）：所有 Agent 共享同一个任务数据库，包括：
- 任务表（tasks）：任务描述、状态、优先级
- Agent 表（agents）：哪些 Agent 可用、它们的角色和技能
- 任务队列（jobs）：待执行的任务，支援分布式锁
- 审计日志（audit）：所有操作的完整记录
实时同步（LISTEN/NOTIFY）：PostgreSQL 内置的发布-订阅机制。任何一个 Agent 更新了任务状态，其他 Agent 会立即收到通知，不需要轮询
角色分工：
- Master：负责任务分发、调度、监控
- Worker：实际执行任务的 Agent
质量门（Quality Gates）：重要任务需要”审批”才能继续。Master 可以配置单审或双审流程
它解决了什么问题？
- 多实例协同：可以在多台机器上运行多个 Agent 实例，共享同一个任务池
- 实时可见性：任务状态变化立即同步，不需要等待刷新
- 故障恢复：任务可以配置重试策略和死信队列（DLQ），失败的任務不会丢失
- 审计合规：所有操作都有记录，适合企业场景
适用场景
- 需要跨多台机器协调的复杂项目
- 有合规要求的企业级部署
- 需要任务审批流程的团队
实践方案三：Perplexity Computer——编排优先的产品实践
如果说上面两个是”框架/工具”，那 Perplexity Computer 代表的是”产品级”的实现。
Perplexity 最近发布的”Computer”产品，核心卖点是“编排优先”（Orchestration-First）。它的架构有几个关键特征：
1. 多模型路由（Model Routing）
不同任务用不同的模型：
- Research Agent：用专门优化的研究模型
- Coding Agent：用代码能力强的模型
- Media Agent：用多模态模型
模型选择不是固定的，而是根据任务类型动态路由。
2. 并行子 Agent + Coordinator
不是让一个 Agent 顺序处理所有步骤，而是：
- 一个 Coordinator（协调器） 模型负责规划和拆分任务
- 多个 ** Specialist（专家）** Agent 并行执行各自的专业任务
- Coordinator 负责汇总结果、处理依赖关系、决定下一步
这就像一个项目经理（Coordinator）把任务分配给不同的专家（Specialist），专家们并行工作，项目经理负责协调进度和质量。
3. 成本控制
- 使用量计费：不是固定月费，而是按实际消耗
- 子 Agent 模型选择：你可以选择用哪个级别的模型处理哪个任务
- 花费上限：可以设置每月最高消费限额
4. 隔离与沙箱
每个 Agent 运行在独立的沙箱环境中，避免”一个 Agent 发疯影响全局”的问题。
核心挑战：多 Agent 不只是”多开几个”
看到这里，你可能会觉得”多 Agent 很简单嘛，不就是同时跑多个实例”。
但实际上，多 Agent 系统面临几个独特的挑战，这些挑战在单 Agent 场景下根本不存在：
1. 任务分配：谁来干？
简单的均分不够——有些任务简单（5 分钟），有些任务复杂（50 分钟）。如果随机分配，可能会出现：
- Agent A 干完了没事做，等了 45 分钟
- Agent B 还在苦逼地处理复杂任务
更好的方式：预先估计每个任务的复杂度，或者让 Agent 们自己”抢任务”（谁先处理完谁拿下一个）。
2. 依赖管理：谁先谁后？
任务之间经常有依赖关系：任务 B 必须等任务 A 完成才能开始。
常见方案：
- 在任务描述中明确标记依赖
- 协调器（Coordinator）负责分析依赖图并排序
- 后面的任务等前面的完成后再启动
3. 冲突检测：谁改了我的文件？
8 个 Agent 同时工作，很可能出现这种情况：Agent A 和 Agent B 都修改了 src/auth.py。
Terminal Stampede 的方案：合并前检查冲突，如果两个 Agent 修改了同一个文件，标记为冲突并尝试 AI 解决。
更完善的方案：在任务分配阶段就尽量把”可能冲突”的任务分给同一个 Agent，或者在任务描述中限定”作用域”。
4. 结果汇总：谁说的对？
8 个 Agent 给了 8 个不同的答案听谁的？
Perplexity Computer 的方案：Coordinator 负责汇总多个 Agent 的结果，做最终判断。
Terminal Stampede 的方案：Shadow Scoring——在合并时对每个 Agent 的工作做多维度评分（完成度、冲突友好度、代码质量），作为合并顺序的参考。
5. 失败传播：一个挂了会怎样？
一个 Agent 处理任务时失败了，后面依赖它的任务怎么办？
常见方案：
- 自动重试：失败后重新入队，让其他 Agent 尝试
- 熔断机制：连续失败 N 次后停止调度，避免浪费资源
- 死信队列（DLQ）：多次重试都失败的任務进入特殊队列，等待人工处理
行业趋势：从”聊天壳层”到”分布式工程系统”
回到我们最初的话题：AI Agent 正在从”聊天壳层”变成”分布式工程系统”。
这意味着什么？
过去：Agent 是一个”对话界面”——你问它答，你命令它执行。单线程、串行处理。
现在：Agent 是一个”工程系统”——有任务队列、有调度器、有监控、有容错、有审计。就像一个成熟的微服务架构。
这个转变带来的变化是：
- 可靠性比单轮效果更重要：一个 Agent 连续工作 8 小时不出错，比”第一次回答很惊艳”更有价值
- 可观测性成为必选件：你需要知道每个任务在哪一步花了多长时间、哪个 Agent 在处理、哪个任务失败了
- 编排能力成为核心竞争力：未来的竞争不在于”模型有多聪明”，而在于”谁能更优雅地调度多个 Agent”
一个有趣的类比：足球队
想象一下多 Agent 系统的运作方式：
- 单 Agent 足球队：11 个球员都听教练的，教练说什么就做什么。这是”集中式”架构
- 多 Agent 足球队：前锋自己判断什么时候射门，中场自己决定什么时候传球，后卫自己决定什么时候铲球。它们通过”默契”（共享上下文）协调。这是”分布式”架构
现在的多 Agent 系统更接近第一种——有一个 Coordinator 负责统筹。但随着技术发展，第二种”分布式默契”会越来越常见。