当一个大模型不够用时我们需要一群大模型一起工作。6.1 为什么需要多 Agent在深入架构之前先回答一个根本问题单 Agent 不够吗单 Agent 的天花板单个 LLM Agent 面临三重约束约束说明上下文窗口即使 200K token 的窗口面对大型代码库或长文档也捉襟见肘注意力稀释任务越多、指令越复杂模型越容易顾此失彼——这是 LLM 的丢失中间Lost in the Middle现象能力边界一个模型擅长写代码不一定擅长做代码审查擅长创意不一定擅长逻辑验证多 Agent 的破局点多 Agent 的核心思想朴素而强大分工 协作。专精化每个 Agent 只做一件事做到极致并行化独立子任务同时推进线性时间做指数级的事纠错机制多个视角交叉验证降低幻觉和偏见可扩展新增能力 新增一个 Agent而不是重新训练一个更大的模型这就是为什么从 AutoGen、CrewAI 到 LangGraph多 Agent 框架在过去一年里密集涌现。6.2 多 Agent 系统架构一个典型的多 Agent 系统由以下核心组件构成关键组件1. Orchestrator编排器大脑角色。接收用户意图 → 分解为子任务 → 分发给合适的 Agent → 收集结果 → 汇总输出。可以用一个指挥型LLM 实现也可以用确定性的规则引擎如 DAG 工作流。2. Agent 池一组具有明确角色定义和专业能力的 Agent。每个 Agent 有自己的 system prompt、工具集、甚至不同的底层模型如代码生成用 Opus、简单分类用 Haiku。3. 通信层Agent 之间如何传递消息常见方案共享黑板Blackboard所有 Agent 读写同一个结构化空间消息队列点对点或发布/订阅模式共享记忆向量数据库 结构化存储支持长期上下文4. 工具层Agent 可以调用的外部能力——代码执行器、搜索引擎、数据库、API 调用等。5. 人机交互层Human-in-the-Loop关键决策点暂停等待人类确认。这在生产环境中至关重要。6.3 多 Agent 协作模式三种经典模式覆盖了 90% 的实际场景。模式 1层级结构Hierarchical工作流程Manager 收到复杂任务将其拆解为子任务Manager 根据 Worker 的能力矩阵分配任务Worker 各自执行结果上报 ManagerManager 审查、整合不合格则退回重做最终结果返回用户适用场景任务可被清晰分解且子任务间依赖明确需要一个裁判角色来做质量把关典型的软件开发流程架构师 → 开发者 → 测试者优点结构清晰质量可控责任明确缺点Manager 成为单点瓶颈串行决策引入延迟模式 2平等协作Collaborative所有 Agent 地位平等通过讨论达成共识工作流程任务广播给所有 Agent每个 Agent 从自身视角给出分析Agent 之间自由讨论、辩论、补充通过投票或共识机制得出最终结论适用场景需要多视角的头脑风暴代码审查、方案评审没有唯一正确答案的开放式问题优点视角多元创意丰富不易产生单一偏见缺点可能陷入无限讨论通信开销大难以收敛模式 3流水线Pipeline工作流程每个阶段有严格的输入/输出契约上一个 Agent 的输出 下一个 Agent 的输入阶段之间可以设置质量门禁quality gate某个阶段失败时回退到上游重试适用场景工序明确、有先后依赖的任务链数据处理 ETL 流程CI/CD 中的自动化审查链文档翻译提取 → 翻译 → 校对 → 格式化优点流程清晰易于追踪每阶段独立可测缺点缺乏灵活性前一阶段的错误会级联放大并行度有限模式选择指南你的情况推荐模式任务复杂、需要统一协调层级结构需要多方观点碰撞平等协作流程固定、步骤明确流水线实际场景最常见三者混合实际情况中很少有系统只使用单一模式。比如一个软件工程团队顶层是层级结构PM 分配任务中间是流水线需求→设计→开发→测试具体环节引入协作模式代码审查时多个 Reviewer 讨论。6.4 实战案例智能软件开发团队让我们设计一个能端到端交付功能的多 Agent 开发团队。团队配置角色定义PM Agent— 需求分析师System Prompt你是一位经验丰富的产品经理擅长将用户需求转化为可执行的技术任务输入用户的自然语言需求输出结构化的任务列表含优先级、依赖关系、验收标准工具项目管理工具、知识库检索Architect Agent— 系统架构师System Prompt你是资深系统架构师专注技术方案设计遵循 SOLID 原则输入PM 拆分后的任务输出技术方案接口定义、数据模型、文件结构工具代码库搜索、设计模式库Developer Agent— 开发者System Prompt你是一名注重代码质量的软件工程师遵循项目编码规范输入Architect 的技术方案输出可运行的代码 单元测试工具代码编辑器、编译器/解释器、Git模型选择代码生成用 Opus简单重构用 SonnetQA Agent— 测试工程师System Prompt你是一名严谨的测试工程师善于发现边界情况和潜在 bug输入Developer 的代码 PM 的验收标准输出测试报告通过/失败、发现的 bug、改进建议工具测试运行器、Linter、静态分析工具Reviewer Agent— 代码审查者System Prompt你是项目的守门员确保代码质量和架构一致性输入Developer 的代码 QA 的测试报告 Architect 的设计方案输出审查意见Approve / Request Changes评判维度正确性、安全性、性能、可维护性、一致性一次典型协作流程核心启示角色定义是灵魂每个 Agent 的 system prompt 要精确包含角色、职责边界、输出格式工具决定能力Developer Agent 没有代码执行工具就是一个只会说不会写的顾问失败要能回退QA 发现问题 → Developer 修复 → QA 再测 → 形成闭环人机协同Reviewer 的 Approve 只是建议合并到主分支前留有人工确认环节6.5 多 Agent 的关键挑战漂亮的理论背后工程落地有三座大山。挑战 1通信开销现象单 Agent: 用户 → Agent → 结果 (1 轮) 3 Agent 协作: 用户 → A → B → C → B → A → 用户 (6 轮)每一轮都是一次 LLM API 调用意味着延迟翻倍6 轮调用即使每轮 2 秒也要 12 秒成本翻倍每次调用都消耗 input output token上下文膨胀Agent 间的对话历史不断累积后面的 Agent 背负越来越重的上下文包袱应对策略结构化中间输出Agent 间不传自然语言传 JSON/结构化数据上下文裁剪只传递下游需要的信息不搬运完整对话并行化无依赖的 Agent 调用同步发出不等串行缓存相同的 system prompt 和工具定义利用 LLM 的 prompt cache挑战 2死锁和循环依赖典型案例Agent A: 我需要 B 先给出接口定义才能开始写代码 Agent B: 我需要 A 先告诉我需要什么接口才能定义 → 两个 Agent 互相等待系统卡死或者更隐蔽的Developer 写出代码 → QA 发现问题 → Developer 修改 → QA 又发现新问题 → Developer 再修改 → QA 又发现... → 无限修改-反馈-修改循环应对策略超时机制任何等待超过阈值 → 升级给 Orchestrator 或人类最大重试次数同一子任务的重做轮数封顶超过后标记为需人工介入依赖预声明任务开始前Orchestrator 检查依赖图中是否存在环降级策略当双方僵持时允许某一方做假设先行推进我先假设接口长这样你按此实现挑战 3结果冲突场景 1事实冲突Agent A查询数据库: 用户表有 10,000 条记录 Agent B查询数据库: 用户表有 9,987 条记录 → 谁是对的可能 A 查了包含软删除的B 没含场景 2方案冲突Agent A: 用 Redis 缓存性能最优 Agent B: 用本地内存缓存减少依赖 → 各说各有理如何决策场景 3格式冲突Agent A 输出: { name: 张三, age: 25 } ← age 是 string Agent B 期望: { name: 张三, age: 25 } ← age 是 number → Pipeline 模式的接口契约被破坏应对策略强制 Schema 校验所有 Agent 间通信使用 JSON Schema 严格验证置信度标注每个 Agent 的输出附带置信度分数Orchestrator 按置信度加权决策少数服从多数 异议记录投票机制决定采用哪个方案但记录少数意见供人工复查版本化接口Pipeline 中各阶段的输入/输出 Schema 带版本号不兼容时自动拒绝总结多 Agent 设计的核心原则单一职责一个 Agent 只做一件事定义清晰的输入/输出边界拥抱不确定性LLM 本质上是概率性的——用重试、投票、校验来对抗人机协同是底线关键路径上永远保留人工确认点先简单后复杂能用流水线解决的就不要上层级结构能用一个 Agent 完成就不要用多个可观测性每个 Agent 的决策过程可追溯、可审计——否则出问题时你无从排查多 Agent 不是银弹。它增加了系统的复杂度和成本但对于真正需要多个专业视角协同的复杂任务它是目前最有效的范式。关键在于知道何时用、知道用哪种模式、知道如何兜底。本系列持续更新中