Multi-Agent 要想“更高效”，关键不是多放几个 Agent，而是：
把一个复杂任务拆给最适合的人，并减少他们之间没必要的沟通。
很多人第一次搭 Multi-Agent 容易犯一个错误：
Agent A ↔ Agent B ↔ Agent C ↔ Agent D
↖________________________↗
让几个 Agent 不停互相讨论。
看起来很高级，实际上经常出现：
Token 消耗爆炸、重复劳动、互相传错信息、速度反而比一个 Agent 更慢。
真正高效的 Multi-Agent，更像一家管理良好的公司，而不是“10 个人同时开会”。
一、先理解 Multi-Agent 为什么可能更高效
假设你让一个 AI 做：
“全面分析一家上市公司。”
一个 Agent 要同时完成：
查财报
+
读财报
+
算财务指标
+
研究行业
+
搜新闻
+
分析竞争对手
+
估值
+
找风险
+
写报告
它实际上在不断切换角色。
就像让一个员工同时：
当会计 + 行业研究员 + 数据分析师 + 新闻记者 + 投资经理。
Multi-Agent 的思想是把它拆掉：
Manager
│
┌────────────┼────────────┐
↓ ↓ ↓
财务Agent 行业Agent 新闻Agent
↓ ↓ ↓
Python Web Search
│ │ │
└────────────┼────────────┘
↓
Reviewer
↓
Final Report
最大的效率来源在这里：
三个本来互不依赖的任务，可以同时执行。
如果财务分析 5 分钟、行业分析 5 分钟、新闻分析 5 分钟，一个 Agent 串行可能接近 15 分钟；三个 Agent 并行，理论上可能接近最慢那个任务的时间，再加上汇总时间。
这才是真正值得做 Multi-Agent 的情况。
二、最推荐的高效架构：Manager + Specialists + Reviewer
对绝大多数个人项目，我最推荐你不要一开始搞十几个 Agent。
先做这种：
用户目标
↓
Manager Agent
↓
拆分任务 + 分配
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Agent A Agent B Agent C
专业任务 专业任务 专业任务
↓ ↓ ↓
└─────────────┼─────────────┘
↓
Manager 汇总
↓
Reviewer 检查
↓
最终结果
Manager 不应该自己把所有活都干了。
它主要负责：
理解目标 → 拆任务 → 判断依赖关系 → 分配 Agent → 汇总结果。
Specialist 只做好一个领域。
Reviewer 最后负责 Reflection：
有没有冲突？有没有证据不足？有没有遗漏？有没有计算错误？
这个结构已经能覆盖绝大多数 Multi-Agent 项目。
三、真正影响效率的是“任务怎么拆”
假设任务：
分析某家公司投资价值。
一种很差的拆法：
Agent A：分析公司
Agent B：也分析公司
Agent C：再分析公司
最后三个人做了三遍差不多的工作。
非常浪费。
更好的拆法：
Agent A
财务
Agent B
商业模式 + 行业
Agent C
竞争对手
Agent D
新闻 + 政策
Agent E
估值
Agent F
风险挑战
关键原则是：
每个 Agent 的工作边界尽可能互斥。
也就是：
A负责A
B负责B
C负责C
而不是：
A、B、C
都做70%相同的事情
四、能并行的任务一定尽量并行
这是 Multi-Agent 最大的效率优势之一。
例如：
Manager
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
财报 行业 新闻
↓ ↓ ↓
同时执行 ← Parallel → 同时执行
因为：
查新闻不需要等待财务分析完成。
所以三个任务应该同时做。
但下面这种就不能完全并行：
获取财报
↓
提取数据
↓
计算ROIC
↓
根据ROIC分析
↓
估值
因为后一步依赖前一步。
所以 Manager 最重要的能力之一其实是：
区分“可以并行”和“必须串行”的任务。
这和项目管理非常像。
五、Agent 之间不要传整段聊天，传“结构化结果”
这是非常重要的工程优化。
假设财务 Agent 工作了 20 分钟，产生一大堆：
思考过程、搜索记录、网页文字、代码结果……
不要全部发给 Manager。
最好只返回：
{
"revenue_growth": "18%",
"gross_margin": "31%",
"roic": "16%",
"fcf_trend": "下降",
"main_risk": "CapEx快速增加",
"confidence": 0.82
}
Manager只需要：
结论 + 数据 + 来源 + 置信度。
这样上下文会缩小很多。
可以把它想成真正公司：
老板不会要求员工把：
“你今天从早上9点到下午5点脑子里想了什么”
全部汇报。
老板需要的是：
结果。
六、给 Agent 设计“输入输出合同”
这是让 Multi-Agent 稳定的一个关键。
例如财务 Agent 必须输出：
公司：
时间范围：
Revenue：
Net Income：
FCF：
ROE：
ROIC：
核心发现：
1.
2.
3.
风险：
Sources：
竞争 Agent 也有自己固定格式。
这叫：
Structured Output / Schema
好处是 Manager 非常容易把几个 Agent 的结果拼起来。
否则：
Agent A 写三千字文章。
Agent B 给一个表格。
Agent C 写几句话。
Manager 就很难稳定处理。
七、不要让所有 Agent 拥有所有 Tools
这是很多 Agent 系统的另一个问题。
例如：
每个Agent：
Web
Python
Email
Database
RAG
Browser
Files
Shell
……
模型每一步都得判断：
“我到底应该用哪个？”
反而增加复杂度。
应该根据角色限制。
比如：
财务Agent
→ PDF + Python + 财务数据库
新闻Agent
→ Web Search
知识Agent
→ RAG
代码Agent
→ Shell + GitHub
Reviewer
→ 基本不需要执行工具
这样会同时提升：
速度、可靠性、安全性和成本效率。
八、共享一个“黑板”，而不是互相疯狂聊天
这是一个非常经典的 Multi-Agent 思想：
Blackboard Architecture（黑板架构）
想象公司办公室里有一块公共白板。
财务 Agent 完成以后写：
财务分析：DONE
ROIC：16%
FCF：下降
行业 Agent 写：
行业：DONE
行业增速：12%
竞争加剧
Manager 随时读取。
而不是：
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent C
……
共享状态可以存在：
数据库、JSON、Redis、PostgreSQL、共享 Memory。
这样 Multi-Agent 系统就会清晰很多。
九、Memory 也不要所有 Agent 各自乱记
你刚才问过长期 Memory，这里就能连起来了。
一个比较好的设计是：
Shared Memory
↑ ↓
┌───────────┼───────────┐
↓ ↓ ↓
Agent A Agent B Agent C
但不同记忆可以分层。
例如：
Global Memory
所有Agent共享的重要事实
Agent Memory
某个Agent自己的专业经验
Task Memory
当前项目的临时状态
比如公司研究：
“公司 2026 年收入 800 亿”
属于 Shared Memory。
而：
“分析现金流时容易遗漏股权激励”
可能属于财务 Agent 的经验 Memory。
这样不会让整个系统越来越乱。
十、一定设置“谁有最终决定权”
Multi-Agent 最大的问题之一就是：
A说值得投资。
B说不值得。
C说看情况。
然后怎么办？
所以一定需要一个：
Aggregator / Manager / Judge
例如：
财务Agent：Positive
行业Agent：Positive
风险Agent：Negative
估值Agent：Negative
↓
Investment Manager
↓
综合证据
↓
最终判断
不要让几个 Agent 无限辩论。
可以允许：
1轮质疑 → 1轮回应 → Manager裁决。
否则极其浪费 Token。
十一、Reflection 最好放在“最后”，而不是每一步都反思
例如你做：
财务Agent
↓
Reflection ×3
行业Agent
↓
Reflection ×3
新闻Agent
↓
Reflection ×3
Manager
↓
Reflection ×3
成本可能直接翻好几倍。
更现实的方法：
各Agent完成专业任务
↓
Manager汇总
↓
Reviewer检查最终结果
↓
发现重大问题
↓
只让有问题的Agent重做
注意最后一句：
只重做出问题的部分。
这叫 selective retry。
非常重要。
十二、做 Multi-Agent 时我建议你遵守一个非常实用的原则
你可以记住这 7 条：
- 能一个 Agent 做好的，不要强行 Multi-Agent。
- 只有任务确实存在不同专业角色时才拆 Agent。
- 能并行就并行，存在依赖就串行。
- Agent 之间传结果，不传大量过程。
- 每个 Agent 有固定输入、输出和 Tool 权限。
- 一个 Manager 负责状态和最终决策。
- 只在重要节点 Reflection，不无限讨论。
这是比“Agent 数量越多越好”重要得多的思想。
十三、给你一个非常实用的 4-Agent 模板
如果你以后第一次真正搭 Multi-Agent，我反而建议只做：
Manager
│
拆任务、维护状态
↓
┌────────────┴────────────┐
↓ ↓
Research Agent Analysis Agent
收集资料 深度分析
↓ ↓
└────────────┬────────────┘
↓
Critic Agent
专门找问题
↓
Manager
↓
最终输出
只有 4 个角色。
已经足够你理解 Multi-Agent 的核心机制。
等这个版本确实出现瓶颈，再增加：
财务 Agent、代码 Agent、市场 Agent、知识库 Agent……
而不是一开始就创建 15 个。
十四、例如一个真正高效的“投资研究 AI 团队”
最后把你前面学到的知识全部串起来：
用户：
“研究这家公司”
↓
Manager
Plan-and-Execute
↓
┌───────┼────────┬─────────┐
↓ ↓ ↓ ↓
财务 行业 新闻 竞争
Agent Agent Agent Agent
↓ ↓ ↓ ↓
Python RAG Web Web
└───────┼────────┴─────────┘
↓
Shared Memory
↓
估值 Agent
↓
Critic Agent
Reflection
↓
Manager
↓
最终研究报告
↓
Memory
保存重要经验
这时候你之前问我的概念就真正串在一起了：
Prompt：你交代任务。
Plan：Manager 拆任务。
Multi-Agent：专业化分工。
Tools：每个员工的工具。
RAG：查资料库。
ReAct：工作中根据结果调整。
Reflection：Reviewer 查漏洞。
Memory：把结果和经验留下来。
真正高效的 Multi-Agent，核心其实不是“有很多 AI”。
而是：
分工 + 并行 + 结构化沟通 + 统一协调 + 最少必要协作。
这和优秀公司的组织设计，本质上非常相似。