面试题 · Agent
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在多Agent系统中，如何通过Agent协同合作来提高复杂推理任务的正确率？请描述主要的技术架构和协作机制。
复杂推理任务往往涉及多维度验证、长链条推导，单Agent容易陷入"思维盲区"。多Agent通过角色专业化+交叉验证提升可靠性。
1. 层级式架构（Manager-Worker）
2. 对等式架构（Peer-to-Peer）
按学习路线查看教程、项目和面试题。
3. 竞争-优化架构
| 机制 | 作用 |
|---|---|
| 任务分解 | 将复杂查询拆为可并行子任务 |
| 共享记忆 | 全局黑板（Blackboard）或向量数据库存放中间结论 |
| 结果聚合 | 多数投票、置信度加权、或LLM-based综合判断 |
| 迭代精炼 | 多轮讨论直到共识或达到轮次上限 |
实际案例：代码生成场景可拆为"架构设计Agent→代码编写Agent→测试Agent→安全审计Agent"流水线，错误率显著低于单Agent端到端生成。
场景切入
我看你做过电商客服。假设用户问一个复杂的退换货问题，涉及订单状态、物流、库存多个环节，一个Agent经常答不全或出错。你会怎么设计多个Agent配合来把这事搞准？
层层追问
复杂推理任务用单个Agent做，准确率经常卡住，你觉得问题在哪？……如果用多Agent，怎么让他们分工协作？……那多个Agent意见不一致时怎么处理？
直球架构
多Agent系统中，为了提高复杂推理任务的正确率，你会采用哪种协作架构？具体说说任务怎么拆、结果怎么合、Agent之间怎么通信，以及怎么保证最终答案可靠。
这道题其实问的是，当单[[Agent]]在复杂推理里容易陷入思维盲区的时候，怎么通过多个Agent的分工和交叉验证来兜底。说白了，核心就两个词：专业化和纠错。
先说架构。我一般会先分清楚场景。如果任务本身有清晰的层级，比如生成代码，我倾向用层级式，也就是Manager-Worker模式。Manager负责任务拆解和最终裁决，Worker各管一摊，比如一个专攻数学计算，一个专攻事实检索，一个专攻逻辑校验。这种结构好处是职责分明，坏处是Manager容易成为瓶颈。另一种是对等式，Agent之间地位平等，通过消息传递或者辩论来推进。比如让三个Agent对同一个问题独立推理，然后投票或者共识决策。这种适合开放性更强、没有标准答案的任务，像创意写作或者策略分析。但真正落地的时候，我往往会把两者混着用，比如层级式里加一个辩论环节，让Worker先吵一轮再汇报给Manager。
再往下说协作机制。最关键的是三块：任务分解、共享记忆、结果聚合。任务分解是把一个复杂查询拆成可以并行干的子任务，比如把“分析某公司财报风险”拆成“提取财务指标”“对比行业均值”“识别异常波动”。共享记忆我常用全局黑板或者 [[Vector Database]]，让Agent能读到彼此的中间结论，避免重复劳动。结果聚合我偏向置信度加权，而不是简单多数投票，因为不同Agent的专长领域可能导致置信度差异很大。
提升正确率的具体手段，我重点讲两个。一个是异构设计，就是让不同Agent用不同的模型或提示策略，比如一个用 [[Chain-of-Thought]]，一个用 [[Self-Consistency]]，这样能降低系统性错误。另一个是回溯机制，比如某个Agent算出来结果明显异常，就触发其他Agent重新分析或者Manager重新分解任务。这里有个坑：如果Agent之间通信太频繁，延迟会爆炸，所以上线前我会特别关注每轮通信的上限和超时处理。
不过说实话，多Agent不是万能的。前提是任务本身能被合理分解，而且子任务之间依赖不能太强。如果任务高度耦合，比如需要连续推理几十步，单Agent的 [[Reflexion]] 或者 [[Tree-of-Thoughts]] 可能反而更高效。另外，多Agent的容错设计也很关键，比如某个Agent挂了，系统能不能优雅降级，而不是全员卡死。
所以整体上，我更倾向于把多Agent看成一种系统工程，而不是单纯的模型堆叠。核心是角色划分和容错设计，而不是一味追求Agent数量。如果让我选，我宁可用三个精心设计的Agent，也不要十个随便拼起来的。