面试题 · Agent
请阐述多Agent系统设计中有哪些核心方法论和设计原则？
1. 角色定义与职责边界
2. 主流协作架构
| 模式 | 特点 | 适用场景 |
|---|---|---|
学习内容与项目面试，在同一条路上。
| 平等协商，共享目标 |
| 复杂决策、头脑风暴 |
| 层次式 | 中央调度+执行Agent | 任务流明确、需严格管控 |
| 竞争式 | 多方案PK，择优采纳 | 创意生成、策略优化 |
| 市场式 | 基于"拍卖"机制动态分配 | 资源调度、负载均衡 |
3. 通信机制设计
4. 任务分解与动态规划
5. 关键设计原则
多Agent的本质是**"分而治之+协同治理"**——先合理拆分认知负载，再通过机制设计保证系统收敛到正确解。
场景切入
假设我们要做一个电商客服多Agent系统，有导购、订单查询、售后等Agent。用户问了一句‘我的快递到哪儿了’，你觉得该由哪个Agent处理？如果用户接着问‘那我还能改地址吗’，这时候怎么协调？
层层追问
多Agent系统你了解吧？……那如果多个Agent一起干活，怎么分任务？……如果两个Agent给的结果冲突了怎么办？……再往深了说，如果其中一个Agent挂了，整个系统怎么保证不崩？
直球架构
设计一个多Agent系统，要求Agent角色明确、能动态协作、并且容错。请直接讲你的核心方法论和设计原则，比如角色怎么划分、协作模式选哪种、通信怎么搞、故障怎么处理。
这道题我觉得本质上是在问，当系统里不止一个[[智能体]]的时候，怎么让它们各司其职又拧成一股绳，说白了就是 分而治之加协同治理。
先说角色划分。每个Agent职责必须单一，比如有的专门做规划，有的做执行，有的做验证，还有的做反思。这就像团队里产品、开发、测试各管一摊，不能一个人又写代码又测自己的bug。实现上我习惯用[[System Prompt]]把行为固化下来，避免能力重叠。
再一个就是协作模式。常见的有协作式、层次式、竞争式、市场式，但真正落地很少只用一种。举个例子，在电商客服退款场景里，用户发起退款，我会用层次式：一个调度Agent拆任务，然后分给执行Agent去查订单、算金额、审凭证，这些执行Agent之间又是协作式，共享上下文。如果遇到争议，再让两个Agent竞争出不同方案，调度Agent择优。所以 模式是混搭的，关键看业务流。
通信这块，我常用两种：消息协议和黑板架构。消息协议就是标准化的JSON-RPC，带上sender、receiver、task_id这些字段，适合实时同步调用。黑板架构更像公共白板，Agent们自己上去写、异步读，适合解耦。比如在订单异常处理里，多个Agent可以同时往黑板上写审核意见，最后由仲裁Agent汇总。这里有个坑：如果黑板不加版本控制，很容易读到过期信息导致决策不一致，所以我上线会特别关注 共享内存的读写锁和版本号。
任务分解我倾向用[[ReAct]]加Reflection，Agent在执行中不断自我评估，失败了要么重规划，要么上报。这样能动态调整，不用一开始就把所有子任务定死。
最后是容错和一致性。容错方面，我会给每个Agent设超时熔断，如果某个Agent卡死，调度Agent直接降级到单Agent模式兜底，或者预留人工介入节点。一致性更难，关键决策比如退款金额，我会让验证Agent复核，或者多Agent投票。但投票也有代价，延迟会变高，所以 只在高风险节点用，其他节点信任单个Agent的结果。
其实还有一个方向我没展开，就是当Agent数量超过几十个时，整个系统的收敛性会变差，这时候光靠规则调度就不够了，可能需要引入[[Tree-of-Thoughts]]做搜索剪枝，或者用强化学习动态编排。这个我还在摸索，但我觉得是生产环境必须面对的挑战。
所以整体上，我更倾向于把多Agent设计看成 先合理拆分认知负载，再通过机制设计保证系统收敛到正确解。上线前我会重点压测容错路径，确保单个Agent挂掉不会拖垮全局。