多 Agent 系统

IT_1024

96人浏览 · 2026-11-03 20:09:00

IT_1024 · 2026-11-03 20:09:00 发布

多 Agent 系统

1. 多 Agent 系统的常见拓扑结构有哪些？
1. 最简单的是主从结构，一个主 Agent 负责拆任务和汇总，子 Agent 各干一块，汇报后由主 Agent 收口。
2. 流水线结构像工厂流水线，Agent 按工序排成一条链，上一个的输出是下一个的输入，适合固定流程。
3. 群聊结构让所有 Agent 在一个共享会话里发言，互相看得见彼此的输出，由一个主持人或规则决定谁来接话。
4. 辩论结构让多个 Agent 针对同一问题各自作答再互相挑刺，多轮交锋后收敛，常用来提升答案质量。
5. 黑板结构借用了传统 AI 的思想，Agent 围绕一块共享数据区协作，谁有能力谁领走对应子问题。
6. 面试加分点：指出拓扑没有优劣只有适配，任务可分解性、步骤依赖关系和信息共享需求决定选型。
7. 常见误区是把多 Agent 等同于群聊模式，实际上生产里主从和流水线用得最多，群聊更多见于演示。

2. 主从模式和群聊模式有什么区别？
1. 主从模式信息流是星形的，子 Agent 只和主 Agent 通话，互相之间不通信，边界清晰好管控。
2. 群聊模式信息流是网状的，所有发言所有人可见，信息充分共享但上下文膨胀极快。
3. 责任归属差异明显，主从模式下主 Agent 对最终结果负全责，群聊模式下责任分散，出问题难定位。
4. 成本上群聊模式每个发言都要带全量历史，token 消耗常是主从的数倍，长会话尤其烧钱。
5. 主从模式适合任务边界清楚、子任务可独立完成的场景，群聊适合需要头脑风暴和视角碰撞的创意任务。
6. 工程复杂度也不同，主从要做任务拆解和结果验收，群聊要做发言秩序和终止判定。
7. 面试收尾可以给一个经验数字：生产系统里超过九成的多 Agent 落地是主从或其变体，群聊多为锦上添花。

3. 多个 Agent 之间怎么传递上下文才不丢信息？
1. 最粗暴的全量转发不可取，每个 Agent 都拿到完整历史，token 成本爆炸还会引入无关干扰。
2. 结构化交接是主流做法，上游 Agent 按约定模板输出交付物，比如结论、依据、待办三段式，下游按需消费。
3. 共享状态区是另一个思路，所有 Agent 读写同一份任务状态，比如一个结构化对象，避免信息在对话里传来传去。
4. 关键事实要做显式登记，任务目标、硬约束、已确认的决定放进一个不变的上下文头部，每个 Agent 都能看到。
5. 交接时附上原始依据的引用指针，下游有疑问能回查，而不是只拿到一个裸结论。
6. 面试加分点：强调信息丢失往往不是没传到，而是被淹没，传递的核心是信噪比而不是完整性。
7. 常见误区是迷信"上下文窗口够大就没事"，窗口大不等于注意力均匀，关键约束该置顶还是要置顶。

4. 什么时候该拆多 Agent，什么时候单 Agent 就够？
1. 第一判断标准是上下文隔离需求，子任务需要互不干扰的干净上下文时拆，比如并行调研多个竞品。
2. 第二是专业分工需求，不同子任务需要不同提示词、不同工具集甚至不同模型时，拆开各自调优更有效。
3. 第三是并行加速需求，子任务相互独立时多 Agent 并行能显著缩短总耗时，单 Agent 只能串行。
4. 不该拆的信号之一是子任务强依赖，A 的每个决定都要等 B 确认，拆了全是通信开销不如单 Agent 一条龙。
5. 不该拆的信号之二是任务本身简单，单 Agent 几轮就能收工，拆出协调成本得不偿失。
6. 还有一个隐性成本要讲：多 Agent 的调试和评测复杂度非线性上升，团队工程能力不够时慎拆。
7. 面试收尾观点：默认从单 Agent 起步，遇到明确的上下文污染或工具冲突证据再拆，拆分是演进出来的不是设计出来的。

5. 多 Agent 之间的消息协议该怎么设计？
1. 消息至少要带五要素：发送方、接收方、消息类型、载荷和关联的任务 ID，缺了任何一个排查都是灾难。
2. 消息类型建议最少分四种：任务指派、进度回报、结果交付、异常上报，类型化之后路由和监控才有抓手。
3. 载荷尽量结构化，用固定 Schema 而不是自由文本，下游才能稳定解析，Schema 演进要有版本号。
4. 要定义清楚消息的送达语义，至少一次还是恰好一次，重复消息到达时下游怎么幂等处理。
5. 异常消息常被忽略，Agent 干不下去了怎么上报、上报给谁、超时算失败还是算等待，都要写进协议。
6. 面试加分点：提一句可以参考 MCP、A2A 等公开协议的设计，内部协议没必要全部自研闭门造车。
7. 常见误区是协议过度设计，字段二十多个没人填得规范，先满足排障和验收两个刚需，再逐步加。

6. 多 Agent 系统里错误是怎么被放大的？
1. 第一条放大链是串行依赖，上游交付物有小错，下游基于错误继续工作，错到最后面目全非。
2. 第二条是职责推诿，子 Agent 遇到模糊处自行猜测继续干，谁都没上报，小歧义滚成大偏差。
3. 第三条是汇总稀释，主 Agent 验收十个子结果时注意力有限，个别离谱结果容易被平均掉混过去。
4. 第四条是重试风暴，一个子任务失败触发上游重试，连锁重试把系统打垮，故障从局部变成全局。
5. 防放大要靠卡点设计，关键交接处设验收检查，交付物不达标就地打回，不让错误过境。
6. 每个卡点配失败兜底，打回几次仍不过就降级处理或转人工，宁可交付打折扣也不交付错误结果。
7. 面试加分点：能类比微服务的错误传播和熔断机制，说明多 Agent 系统在工程上就是分布式系统的镜像。

7. A2A 这类 Agent 间协议解决什么问题？
1. A2A 是 Google 主导的 Agent 间通信协议，解决不同框架、不同厂商的 Agent 怎么互相发现和协作的问题。
2. 它和 MCP 是互补关系，MCP 管 Agent 连工具，A2A 管 Agent 连 Agent，一个向下接能力一个横向组队。
3. A2A 的核心抽象是 Agent Card，每个 Agent 公开一张能力名片，别人据此知道它会什么、怎么调它。
4. 它支持长任务的异步协作，任务可以跑很久，双方通过任务状态轮询或推送跟踪进度，不用一直挂着连接。
5. 协议不暴露各 Agent 的内部思考和记忆，只交换必要信息，天然照顾了各方的封装和隐私。
6. 面试加分点：指出这类协议的真正价值在跨组织协作，企业间的智能体互操作大概率要走协议化路线。
7. 也要客观说局限，A2A 生态还在早期，落地案例远少于 MCP，面试表态别把话说满。

8. 多 Agent 并行执行要注意什么？
1. 并行前先做依赖分析，画清子任务的依赖图，真正独立的部分才并行，有依赖的必须排好拓扑顺序。
2. 并发写共享状态要防冲突，两个 Agent 同时改一份文档会互相覆盖，要上锁或做合并策略。
3. 对下游服务的并发压力要算清，十个 Agent 同时打同一个 API，限流和配额瞬间打爆。
4. 并行任务的进度管理要单独设计，谁完成了谁卡住了要实时可见，不能等最后才发现有一个卡死。
5. 结果汇合处要做对齐，各路并行产出格式不一，需要一个标准化层统一后再交给汇总角色。
6. 成本上并行是放大器，某个分支陷入循环时烧钱速度乘以并发数，预算熔断要按分支单独设。
7. 面试加分点：强调并行收益最大的场景是搜索和调研类任务，结构性强的任务强行并行反而引入协调税。

9. 多 Agent 系统怎么调试？
1. 第一步是建全链路轨迹日志，每个 Agent 的输入输出、耗时、工具调用全部落盘，这是调试的地基。
2. 用任务 ID 串起一次执行的所有消息，能按时间线回放整个协作过程，定位卡点一目了然。
3. 单测每个 Agent，给定固定输入验证它的输出质量，隔离地保证个体正确，再测组合行为。
4. 失败分析要按交接边界分类，统计错误发生在哪个交接处，比泛泛看失败率有用得多。
5. 可视化工具很值钱，把 Agent 协作画成流程图或时序图，人看图找问题远快于翻日志。
6. 常见坑是环境不一致，本地单 Agent 正常、集成分发就坏，要用和生产一致的编排配置做联调。
7. 面试收尾观点：调试难的根源是状态分散在各 Agent 心里，治理之道是把隐性状态显性化、集中化。

10. 多 Agent 的成本是线性增长的吗？
1. 直觉上拆成 n 个 Agent 就是 n 倍成本，实际常远超线性，因为协调本身要消耗大量轮次。
2. 主从结构里主 Agent 的上下文随子任务数膨胀，汇总轮的输入是所有子结果之和，这一轮经常最贵。
3. 群聊模式更夸张，发言互相可见导致每个 Agent 都在为别人的话付 token，成本接近平方级。
4. 失败重试也是放大器，子任务失败率不变时，系统总失败率随链路长度上升，重试成本叠加。
5. 省钱的第一杠杆是砍通信量，结构化交接替代全量转发，通常能省一半以上 token。
6. 第二杠杆是模型分级，协调和汇总用强模型，执行子任务用便宜模型，成本能再降一档。
7. 面试收尾建议：上线前务必按任务类型做成本核算，把单任务成本拆到每个 Agent 每一轮，账算不清的业务别上多 Agent。

11. 生产里落地多 Agent 系统有哪些经验法则？
1. 法则一是少即是多，能用两个 Agent 解决就别上五个，每加一个角色都问一句它不可替代在哪。
2. 法则二是个体简单化，单个 Agent 的职责和提示词保持简单，复杂度放在编排层而不是塞进单个角色。
3. 法则三是不确定性前置，把最容易失败、最需要人判断的环节放在最前面，别等全跑完才发现方向错了。
4. 法则四是全程可观测，从第一天就上全链路日志和成本核算，出了事能五分钟内定位到具体交接。
5. 法则五是渐进演进，先主从后专项，先串行后并行，每次只改一个变量，改完跑回归评测。
6. 团队方面要有明确的 owner，多 Agent 系统没有总负责人就会退化成各自为政的七巧板。
7. 最后一条心法：多 Agent 不是目的而是手段，永远从任务和成本出发反推架构，而不是为了架构先进而上多 Agent。