多 Agent 协作基础
Q：多智能体怎么协作？比如一个写代码一个审查
来源：Agent 岗面试高频题
新手答：“一个写完发给另一个看就行。”
高手答：
多 Agent 协作的核心是角色隔离 + 通信规范 + 冲突收敛，不是简单的“你写我看”。
- 角色定死，职责不交叉：每个 Agent 的 System Prompt 里明确限定职责和输出格式。比如“程序员”只负责写代码和解释设计意图，“审查员”只负责指出问题和给出修改建议——绝不让审查员自己改代码，否则职责边界模糊，输出会乱
- 通信用结构化消息：Agent 之间不传自然语言长文，而是用 JSON 消息体，带上
task_id、role、action、payload等字段。这样既方便下游解析，也方便事后追踪和调试 - 协作拓扑按场景选：简单任务用顺序链（写完 → 审查 → 修改）；复杂任务用分治（多个程序员并行写不同模块，汇总后统一审查）；需要讨论的场景用多轮对话（程序员和审查员来回交互，限定最多 3 轮）
- 冲突必须有收敛机制：审查员和程序员意见不一致时，不能无限来回。设计一个仲裁者角色（可以是更强的模型，也可以是规则引擎），或者关键步骤直接升级到人工介入
差距在哪：新手的回答是一个最简单的两步流程——没有考虑通信格式、冲突处理、拓扑选择。高手的回答覆盖了四个工程维度：角色隔离（谁做什么）、通信规范（怎么传递）、拓扑选择（怎么编排）、冲突收敛（意见不一致怎么办）。面试官考的是“你有没有设计过需要多个组件协作的系统”——多 Agent 协作和微服务架构的思路是相通的。
Q：多 Agent 系统里，怎么防止 Agent 之间“踢皮球”或死循环？
来源：Agent 岗面试高频题
新手答：“加个超时就行。”
高手答：
超时是最后一道防线，但不能只靠它。踢皮球和死循环的根因是职责模糊或终止条件不明确：
- 职责判定前置：在任务分发层做意图路由，明确判断“这个任务该归谁”。如果路由不确定，直接交给一个“兜底 Agent”处理，而不是让多个 Agent 互相推诿
- 交互轮次硬限制：任意两个 Agent 之间的交互最多 N 轮（比如 3 轮），超过就强制输出当前最优结果，不再来回。这个限制写在编排层，Agent 自己不能覆盖
- 状态机驱动流转：用状态机管理任务流转，每个状态只能转向有限的下一个状态，不存在“回到原点”的环路。状态转移规则在编排层硬编码，模型无法篡改
- 全局超时兜底：整个多 Agent 流程设一个总超时（比如 60 秒），到点不管走到哪一步，都输出当前已有的最优结果并通知用户
差距在哪：新手只有超时——这是事后补救。高手的思路是从源头预防：职责判定防踢皮球、轮次限制防无效循环、状态机防非法跳转、超时兜底防极端情况。面试官考的是“你理不理解分布式系统里的活锁问题”，多 Agent 协作本质上就是分布式系统。
Q：多 Agent 之间需要共享状态吗？怎么设计？
来源：Agent 岗面试高频题
新手答：“放 Redis 里，大家都能读写。”
高手答：
需要共享，但绝不能裸读写，否则会出现状态冲突和覆盖问题。我们用黑板模式（Blackboard Pattern）：
- 中央状态存储：一个所有 Agent 都能访问的共享空间（可以是 Redis、数据库、甚至内存字典），存储当前任务的全局状态——任务进度、中间结果、关键决策
- 读写权限分离：每个 Agent 只能写自己职责范围内的字段。程序员只能写
code_output，审查员只能写review_comments，互不干扰 - 事件驱动触发：Agent 不轮询黑板，而是通过事件机制——当某个字段被更新时，自动通知订阅了这个字段的下游 Agent。比如
code_output写入后，自动触发审查员开始工作 - 版本化防覆盖：关键字段带版本号，更新时做乐观锁检查，防止并发写入覆盖
差距在哪：新手的“放 Redis”解决了存储问题，但没考虑并发冲突、权限隔离、触发机制。高手的黑板模式是一个经典的多智能体架构模式——有读写隔离、事件驱动、版本控制。面试官考的是“你有没有多组件共享状态的设计经验”，如果你做过消息队列或事件总线系统，这道题的思路是一样的。