多 Agent 协同选通信还是共识?

30 秒回答

1. 明确协同机制的核心设计（角色定义、通信协议、任务分解）
2. 能对比至少两种协同模式的优劣
3. 给出具体可落地的场景案例
4. 提及冲突解决或容错机制

回答与解析

答案要点

• 明确协同机制的核心设计（角色定义、通信协议、任务分解）
• 能对比至少两种协同模式的优劣
• 给出具体可落地的场景案例
• 提及冲突解决或容错机制
• 体现对开源框架（如AutoGen、CrewAI）的了解

我介绍一种基于角色分工+消息队列的层级协同机制，这是工业界较成熟的方案：

核心架构

三层角色设计

• 规划者（Planner）：接收用户请求，拆解任务子图，决定执行顺序
• 执行者（Worker）：多个专业agent（如代码生成、数据分析、文档检索），只处理特定子任务
• 验证者（Verifier）：检查结果质量，触发重试或反馈修正

通信协议

• 使用共享内存+消息队列（如Redis Stream），而非直接RPC调用
• 消息格式标准化：{from, to, task_id, payload, context_window, deadline}

关键机制

应用场景：智能研报生成

用户输入："分析宁德时代Q3财报，对比比亚迪，输出投资评级"

Planner拆解 → 1) 财报数据提取 2) 财务指标计算 3) 竞品对比 4) 风险评估 5) 报告撰写
            ↓
Worker并行：财报Agent调API取数据 → 计算Agent做比率分析 → 搜索Agent查行业动态
            ↓
Verifier校验数据一致性 → 汇总生成最终报告

与单Agent对比

多Agent适合任务边界清晰、需多领域知识、可并行化的场景；单Agent+工具更适合简单链式调用。字节跳动的内容审核、飞书智能助手都采用了类似的分层架构。

口语版讲法(约4分钟)

• 这道题本质问的是如何拆解复杂任务、协调多个AI agent，而不是堆砌框架
• 我倾向基于角色分工加消息队列的层级协同，规划者拆任务、执行者干具体活、验证者保质量
• 拿智能研报生成举例，财报分析、竞品对比这些子任务可以并行，但数据一致性是坑
• 边界上，多agent适合任务边界清晰、可并行的场景，单agent加工具适合简单链式调用，落地常混合用
• 更关注失败场景和前提，比如任务耦合度高时协调成本反而高，上线前我会特别关注上下文传递和冲突仲裁

这道题我觉得本质不是在问你会几个框架，而是你怎么把一个复杂问题拆成多个AI agent能协作的子任务，并且让它们高效地配合不出乱子。我比较倾向的方案是基于角色分工加消息队列的层级协同，工业界用得比较多，也相对成熟。

具体来说，我会把agent分成三类。最上层是规划者，它接收用户请求，把任务拆成子图，决定执行顺序。中间是执行者，就是多个专业agent，比如代码生成、数据分析、文档检索，每个只处理自己擅长的子任务。底层是验证者，检查结果质量，如果不行就触发重试或者反馈修正。

通信这块，我不太用直接RPC调用，而是用共享内存加消息队列，比如Redis Stream。消息格式标准化，带上from、to、task id、payload这些字段，还有一个重要的context window，用来携带上游的关键结论，避免把全量历史都传下去，否则上下文会越来越长，性能扛不住。

举个例子，智能研报生成。用户说“分析宁德时代Q3财报，对比比亚迪，输出投资评级”。规划者拆成五步：财报数据提取、财务指标计算、竞品对比、风险评估、报告撰写。然后财报agent调API取数据，计算agent做比率分析，搜索agent查行业动态，这些可以并行跑。最后验证者校验数据一致性，比如利润率算的对不对，再汇总成最终报告。

这里有个坑，就是上下文传递和冲突解决。如果上游agent算错了，下游直接拿错误数据，结果肯定崩。所以我会让验证者做仲裁，用多数投票或者置信度加权，实在达不成共识就升级到人工。另外，消息队列的好处是执行者可以动态扩缩，根据负载自动增减实例，高峰期多开几个agent并行处理。

说到边界，多agent不是万能的。它适合任务边界清晰、需要多领域知识、可以并行化的场景，比如内容审核、研报生成。但如果任务简单，比如就是链式调用几个工具，单agent加工具反而更轻量，协调成本低。真正落地的时候，往往是混合用，复杂任务用多agent拆解，简单子任务让单agent快速搞定。

不过，我最近在思考一个问题：当任务耦合度特别高的时候，比如子任务之间有强依赖，规划者拆出来的子图可能深度很大，协调成本反而会超过并行带来的收益。这种情况下，是不是应该考虑用GraphRAG那种图结构来建模任务依赖，而不是简单的层级结构？这个我还在探索。

所以整体上，我会把多agent协同看成一种架构选择，前提是任务能拆、子任务边界清晰、通信成本可控。如果这些不满足，硬上多agent反而会失败。上线前我会特别关注消息队列的延迟和验证者的仲裁效率，确保整个系统不会因为一个agent卡住就全挂掉。我更倾向于先小规模验证，再逐步扩大，而不是一开始就设计一个很复杂的框架。

关键一句:当任务耦合度特别高时，层级协同的协调成本可能超过并行收益，是否应该考虑用图结构建模任务依赖

面试官还可能这样问

1. 问法 1 · 场景切入

   我们有个智能研报生成的需求，需要多个助手协作。假设要抓取财报、做分析、写报告，你怎么设计这些AI助手之间的分工和沟通？

2. 问法 2 · 层层追问

   多个Agent一起干活时，你怎么协调它们？……如果任务可以并行，但结果可能冲突，你怎么办？……能具体讲一种你用过的协同机制和场景吗？

3. 问法 3 · 直球架构

   请描述多智能体系统中一种具体的协同工作机制，包括角色定义、通信协议和任务分解，并举例说明应用场景。