本篇是《智能体演化史》系列第 6 篇
系列主线不是"某年出现了某技术"，而是"因为上一步崩了，所以下一步才出现"。
全系列共用一个从 34 行长到 216 行的 tiny-agent，本篇是它的 v0.6。

---

手、循环、脑子、记忆都装上了，于是你给它加了第 30 个工具、第 40 个……然后它开始把两个名字很像的工具搞混。这不是变笨，是认知过载。

怎么读这篇

• 🚶 12 分钟版：只看「崩坏现场」「一句话原理」和三种拓扑那张表，知道你的场景该选哪种。
• 🏃 40 分钟版（推荐）：加读工具混淆曲线、交接信封四件套和 v0.6 实现，你会得到一个能直接照抄的拆分方案。
• 🤿 深潜版：想清楚最后一节——为什么"拆"没有减少复杂度，以及它到底换来了什么。

---

01 · 崩坏现场：47 个工具，它开始乱点

一个内部效率 Agent，功能一路加：查代码、查文档、查工单、查订单、发消息、建任务、跑 SQL、读日志、看监控……到最后，它挂着 47 个工具。

然后几件怪事同时出现：

• 用户说"查一下上周的订单"，它调了 search_messages——因为工单系统里也有"订单"两个字。
• 它开始"不敢下手"：一次对话里连着三轮在问自己该用哪个工具，最后挑了个最像的，还是错的。
• 延迟明显变长。47 个详细 schema 常驻上下文，每轮都是一笔固定开销（见 P1：50 个详细型 schema = 每轮 11,650 token）。
• 最要命的是：没人敢删工具。 每次想删一个，都会有人说"万一某个场景用得上呢"。

团队一开始以为是提示词没写好，改了三轮措辞，收效甚微。后来有人做了个实验：只给它 8 个工具，同样的任务，成功率明显上升。

这不是模型变笨，是候选集变大。 让一个人在 5 把钥匙里挑对的，和让他从 47 把里挑，难度不是线性关系。工具混淆（tool confusion）是认知过载，不是能力问题——换更强的模型只能缓解，不能根治。

---

02 · 一句话原理

拆多个 agent 并没有减少复杂度，
它只是把复杂度搬到了可单独测试、可单独替换的地方。

如果有人告诉你"拆了就简单了"，他大概率没上线过。拆完之后你要面对分布式系统那一整套老问题：通信、一致性、可观测性、部分失败。真正的收益不是"变简单"，是"变可控"。

---

03 · 为什么要拆：候选集越大，选错的越多

假设任意两个语义相近的工具之间，模型发生混淆的概率是固定的 1%；混淆发生时，有一半概率选错。那么错选率 = [1−(1−q)^(n−1)] × 0.5：

候选工具数	5	10	20	30	47	80
错选率	2.0%	4.3%	8.7%	12.6%	18.5%	27.4%
准确率	98.0%	95.7%	91.3%	87.4%	81.5%	72.6%

形态推演，非实测。曲线形状（加速下弯）比具体数值重要。数据来源 calc_metrics_2.py，参数可改。

47 个工具 ≈ 每 5 次选错 1 次。 现在看拆分的效果（同一假设下）：

方案	候选数	单步准确率	额外成本
一个上帝 agent	47	81.5%	无
拆成 3 个专职 agent	各 16	93.0%	多一次路由判断 + 交接开销
拆成 6 个专职 agent	各 8	96.5%	路由本身开始成为新瓶颈

注意第三行的陷阱。 拆得越细，单个 agent 越准，但路由（triage）这一步本身的准确率成了新的上限——分错类，后面全对也没用。这是拆分的第一条收益递减规律。

---

04 · 三种拓扑：怎么连，比拆不拆更重要

拆完之后，先别写代码，先画连接图。工程上真正跑得起来的就三种：

三种拓扑。红色那行才是选型时真正要看的——每种拓扑都有自己的"怎么死"，选它就得接受它的死法。

三种拓扑的完整对照

拓扑	怎么连	适合	失败模式	成本	可测性
路由型	一个分诊 → N 个专家	任务类型清晰可分	分错类全盘皆输	1×	高
流水线型	A → B → C 依次交接	有稳定工序	上游错，下游全污染	1×（串行）	高（可单测每段）
辩论型	多个并行产出后交叉评审	高风险决策	互相说服，假共识	3-5×	中
全互连（Swarm）	任意 agent 交给任意 agent	探索性研究	不可预测 + 攻击面最大	不可控	低

红色那行才是选型时真正要看的——每种拓扑都有自己的"怎么死"，选它就得接受它的死法。

最后一行是我真正想提醒的。 「Swarm / 全互连」在 demo 里最酷，在生产里最难收场：它既没有可测性，又是 P8 那个横向劫持攻击的最佳土壤。除非你在做研究，否则别上全互连。

---

05 · 交接协议：信封里必须装这四样

拆完之后，90% 的 bug 出在交接处。典型症状：下游 agent 收到一句"请参考上面的分析"，然后开始自由发挥。

解决办法是强制一个信封格式。四件套，缺一不可：

交接信封四件套。payload 和 done 是功能性的，from 和 trace_id 是工程性的——后者在 demo 里没用，在生产里救命。

字段	作用	为什么必须
from	谁交的	出问题时能追责，也能做权限校验（见 P8）
payload	交给什么	必须是结构化数据，禁止"请参考上文"这种指代
done	什么叫做完	可判定的验收标准，不是"做好就行"
trace_id	链路追踪号	线上排障时你唯一能抓住的线头

payload 和 done 是功能性的，from 和 trace_id 是工程性的——后者在 demo 里没用，在生产里救命。

坏写法	后果	应该改成
“请参考上面的分析”	下游看不到"上面"，开始编	把结论复制进 payload
不写验收标准	下游永远觉得还能再改	“输出 ≤300 字，含一张数据表”
交接自然语言长文	信息在传递中失真累积	交接 JSON / 表格
没有 trace_id	线上出错，无法复现是哪一环	每次交接生成并透传

---

06 · 最小实现：拆成检索员 / 分析员 / 汇报员

v0.6 的关键不是"提示词写得更好"，而是每个 agent 只领自己那一小撮工具（完整代码 109 行）。

AGENTS = {
    "researcher": {"system": "只负责找到原始材料，不做分析",
                   "tools": [READ_FILE],  "dispatch": {"read_file": read_file}},
    "analyst":    {"system": "基于材料做计算与验证",
                   "tools": [RUN_PY],    "dispatch": {"run_python": run_python}},
    "reporter":   {"system": "把结论写成报告，不新增信息",
                   "tools": [WRITE_REP], "dispatch": {"write_report": write_report}},
}

def handoff(source, payload, done_criteria):
    return {"from": source, "payload": payload,
            "done": done_criteria,   # ← 验收标准，不是"做好就行"
            "trace_id": f"{source}-{int(time.time()*1000)%100000}"}

# 流水线：每段只关心自己的信封，各段独立设步数上限
r1 = run_agent("researcher", handoff("user", GOAL, "列出候选文件与耗时"), budget)
r2 = run_agent("analyst",    handoff("researcher", r1, "最慢的三个 + 验证结果"), budget)
r3 = run_agent("reporter",   handoff("analyst", r2, "300 字以内报告"), budget)

三个设计细节值得单独说：

问题	答案
为什么工具是"分给" agent 的？	候选集变小才是准确率提升的原因。三个 agent 共享全部 47 个工具，拆分就只剩开销
为什么每个 agent 单独限步数？	一个 agent 跑飞不该吃掉全局预算。每段独立上限 = 故障隔离
"汇报员不新增信息"怎么写？	明确写"只使用 payload 里的内容，不得补充"。禁止性指令比鼓励性指令有效得多
什么时候别拆？	总步数 < 6 步、或步骤顺序本身不固定时。固定开销会吃掉全部收益

---

07 · 拆分换来了什么：复杂度去了哪里

维度	单体应用	微服务	单体 Agent	多智能体
复杂度位置	代码耦合处	服务间的网络与契约	上下文与提示词	交接协议与编排
局部失败	整进程崩	可熔断、可降级	一步错，全程污染	可隔离、可重试单段
单独替换	牵一发动全身	换一个服务	改提示词撞别的功能	换掉一个 agent
单独测试	集成测试为主	契约测试	只能端到端测	每段可单测
新增成本	—	运维、可观测性	—	编排、追踪、一致性
调试难度	断点就够	要分布式追踪	看上下文就行	要链路还原

这张表不是类比游戏——它是同一场戏演了三次。软件史上每一次"拆"，代价和收益的结构都一模一样：你换来的是隔离性和可替换性，付出的是可观测性和一致性。

拆分真正换来的，是三件很具体的东西：

1. 故障隔离 —— 检索员跑飞，分析员的预算不受影响。
2. 可单独替换 —— 汇报员写得不好，换掉它，其它两段的评测结果不变。
3. 可单独测试 —— 你可以只给分析员喂 100 组材料，单独测它的准确率。这一条是 P7 评测能落地的前提。

什么时候绝对不该拆： 任务总步数少于 6 步，或步骤顺序本身不固定。判断标准很简单：先量一下单 agent 的成功率，只有它明显受"工具太多"拖累时，才值得拆。

---

08 · 现实对照：一个人管全公司 vs 分部门

现象	一个人管全公司	分了部门
决策速度	快（不用开会）	慢（要交接、要对齐）
专业度	每件事都懂一点，都不精	每个部门有专精
出错影响	他一个人判断错，全公司跟着错	一个部门错，其它部门还在跑
换人成本	换掉他 = 公司失忆	换一个部门总监即可
背锅	只有他一个人能背	能定位到具体部门
新增成本	—	会议、流程、跨部门沟通

没有哪个公司因为"沟通成本高"就退回一个人管全公司。因为规模一到某个点，专业度和故障隔离的价值就超过了沟通成本。 Agent 也是同一个临界点——只是这个临界点来得比你以为的早。

---

09 · 下一篇

现在你有 3 个 agent，要接 10 个数据源。每个 agent 接每个源都得写一套适配器——3 × 10 = 30 套。加到 12 个 agent、50 个源，就是 600 套。

这个 M×N 的乘法，就是 MCP 出现的直接原因。它承诺把它变成 M+N。但天下没有免费的午餐——便宜了集成，就一定贵了别的什么。

下一篇：P7《MCP：智能体世界的 USB-C，和它偷偷收的过路费》。

思考题： 你的 Agent 现在挂了几个工具？如果超过 20 个，试着把它们按使用场景分成几组，看看有没有一个工具在两组里都出现——那个就是最容易混淆的元凶。

---

系列导航

编号	篇目	状态
P1	Agent演化史（一）剥掉营销话术后，智能体只剩 34 行代码	已完稿
P2	Agent演化史（二）模型从没碰过你的工具：Function Calling 只是一份申请书	已完稿
P3	while True 的威力与恐怖：循环与四道刹车	已完稿
P4	上下文工程的诞生，为什么"提示词工程"这个岗位消失了	已完稿
P5	从RAG到记忆图谱，同一个坑踩十次，它每次都踩得同样认真	已完稿
P6	一个上帝模型不够用，47 个工具，它每 5 次就选错 1 次	本篇

---

本篇资产

• tiny-agent-v0.6.py —— 109 行，三专职 agent + 交接协议 + 全局预算可在资料库进行下载
• calc_metrics_2.py —— 工具混淆曲线（形态推演）与拆分收益对照，参数可改
• 数据说明：混淆曲线属形态推演（假设 q=1%），用于说明"加速下弯"的形状，非某次实测；请以你自己线上评测的数字替换

本文为盘子工具站生态原创技术专题系列，转载请注明出处。