多 Agent

什么时候需要多个 Agent

不是越多 Agent 越好。大多数时候一个就够了。但确实有三种场景,一个 Agent 独木难支。搞清楚什么时候真的需要分工。

三种真实场景
并行加速
同时搜索 5 个来源,比一个一个搜快 5 倍
点击展开案例
真实案例:新闻简报
用户要求整理今日 AI 新闻。一个 Agent 要依次搜索 5 个网站,总耗时 25 秒。

改成 5 个子 Agent 同时去搜,每个负责一个来源,最后主 Agent 汇总,总耗时 5 秒。

关键:这些搜索互不干扰,天然适合并行。
角色分工
一个写代码,一个审代码,互相制衡
点击展开案例
真实案例:代码审查
让同一个 Agent 写完代码再审自己的代码,它很难发现自己的错误,就像自己检查自己的作文。

分成两个 Agent:Writer 写代码,Reviewer 审代码。Reviewer 不知道 Writer 的思考过程,只看最终代码,更容易发现问题。

关键:角色隔离让审查真正有效。
风险隔离
子任务出错不影响主任务
点击展开案例
真实案例:复杂文档处理
主 Agent 在整理一份 50 页的报告。其中需要解析几个 PDF 附件。

如果 PDF 解析出错(格式损坏、超时),直接在主 Agent 里做会导致整个任务崩溃。

分出子 Agent 单独处理 PDF:成功了就汇报结果,失败了就报告「这个文件有问题」,主 Agent 继续工作不受影响。

关键:子任务的失败被隔离了。
并行加速的流程示意

一个任务拆成多个子 Agent 并行执行

主 Agent
分发任务
同时执行
搜索 A
搜索 B
搜索 C
汇总结果
判断标准:在你加第二个 Agent 之前,先问自己:
① 一个 Agent 真的做不到吗?(很多时候只是 Prompt 没写好)
② 增加的复杂度值得吗?(多 Agent 意味着更多协调成本、更多出错可能)
③ 有没有更简单的方案?(比如用工具并行调用就能解决,不必真的分 Agent)
不是越多 Agent 越好,大多数时候一个就够了。搞清楚什么时候真的需要分工。只有并行加速、角色制衡、风险隔离这三种明确需求时,才值得引入多 Agent。
多 Agent

并发的代价:谁能同时跑

「看」可以并行:多个搜索同时跑不会冲突。「改」必须排队:两个 Agent 同时改同一个文件会出事。判断一个操作能否并发,关键就一条:它是只读的吗?

可并行 vs 必须串行
可并行(只读操作)
搜索网页
读取文件
查询 API
数据分析
数据库查询
读取笔记

这些操作不修改任何东西,多个同时跑互不影响。10 个 Agent 同时搜索不会冲突。

必须串行(写操作)
写入文件
发送邮件
执行命令
删除资源
支付操作
编辑笔记

这些操作会改变外部状态。两个 Agent 同时改同一个文件 = 数据覆盖、内容丢失。

时间线对比

同一个任务:3 次搜索 + 1 次写入

3 个搜索并行,写入排在最后
搜索 A
2s
搜索 B
3s
搜索 C
2s
写入
1s
0s2s4s6s
总耗时:~4 秒 ✓
判断规则
一条规则判断能否并发:
这个操作执行完,世界有没有变?没变 → 可以并行
这个操作执行完,世界有没有变?变了 → 必须排队
两个「写」操作如果改的是不同的东西(不同文件、不同数据库表)→ 也可以并行

简单说:冲突发生在多个操作修改同一个资源的时候。只要目标不同,写操作之间也可以并行。

并行能省时间,但只有只读类操作才安全,涉及「写」的操作必须排队。设计多 Agent 系统时,第一步就是把工具分成「读」和「写」两类。
多 Agent

脑暴:让多个 AI 吵架

和人类开会一样:一个人想到死不如多个人独立思考再汇总。脑暴模式就是把同一个问题扔给多个 Agent,让它们各自回答,最后由主持人整合共识与分歧。

脑暴过程模拟
❓ 「如何提高用户留存率?」
A
产品视角
B
数据视角
C
用户视角
Agent A · 产品视角
优化新手引导流程,减少首日流失。增加个性化推荐,让用户更快找到价值。
Agent B · 数据视角
分析流失节点数据,第 3 天和第 7 天是关键。建议针对这两个节点设计召回策略。
Agent C · 用户视角
用户反馈最多的是「不知道能干什么」。功能并不少,核心问题是价值传递不到位。

主持人汇总

三个 Agent 独立思考后,主持人整合出:

共识:核心问题是价值传递,用户没感受到产品能帮他什么
共识:新手引导是最高优先级改进点
⚡ 分歧:用数据驱动(B)还是用户访谈驱动(C)来确定改进方向
⚡ 分歧:先做个性化推荐(A)还是先简化核心流程(C)
点击开始,观察 3 个 Agent 独立思考的过程
为什么比一个 Agent 想到底更好

避免思维定式

一个 Agent 会沿着一条线想下去。多个 Agent 从不同角色出发,天然产生不同视角。

发现盲区

Agent A 想不到的东西,Agent B 可能正好擅长。多角度覆盖让盲区更少。

⚖️ 分歧即价值

如果三个 Agent 意见一致,说明方向明确。如果有分歧,说明这个问题值得更深入讨论。

⚡ 并行高效

三个 Agent 同时思考,总时间 = 最慢那个的时间,不会翻三倍。思考类任务天然可并行。

实践要点:每个 Agent 必须独立思考,不能看到其他 Agent 的答案。就像人类脑暴的规则:「先各自写,再一起讨论」。如果 Agent B 能看到 A 的答案,它会被带偏,脑暴就失去意义了。
和人类开会一样:多个独立思考再汇总,比一个人想到死要好。脑暴模式的关键是独立和汇总:每个 Agent 独立回答,主持人负责提炼共识、标注分歧。
多 Agent

定时任务的成本陷阱

让 Agent 每小时整理一次新闻,听起来简单。但如果复用旧会话,上下文每次都在增长,24 小时后你的成本会爆炸。一个选择就能让月账单差 10 倍。

复用会话 vs 新建会话
复用旧会话
第 1 次第 12 次第 24 次
$7.20
24h 总成本
$0.60
最后一次成本
每次新建会话
第 1 次第 12 次第 24 次
$0.72
24h 总成本
$0.03
每次成本
拖动「运行天数」看差异

成本计算器

7
24
$50.4
复用会话总成本
$5.0
新建会话总成本
10x
成本倍数差
为什么复用会话成本会滚雪球

上下文累积过程

1
第 1 次执行:上下文 = System Prompt + 本次对话 ≈ 2,000 token
2
第 2 次执行:上下文 = 第 1 次的全部 + 本次对话 ≈ 4,000 token
3
第 10 次执行:上下文 = 前 9 次全部 + 本次 ≈ 20,000 token
4
第 24 次执行:上下文 = 前 23 次全部 + 本次 ≈ 48,000 token。每次请求都要为这些历史 token 付费!
新建会话 = 每次都从零开始。第 24 次的成本和第 1 次一模一样,因为不带任何历史上下文。定时任务不需要记忆:每次整理当前的新闻就够了,不需要知道昨天整理过什么。
定时任务每次新建会话,别复用旧的。这个选择可以让月账单差 10 倍。大多数定时任务不需要上下文记忆,新建会话既便宜又稳定。
1 / 4