你让 Agent A 去订一家适合生日聚会的餐厅。A 觉得这件事太杂，随手抓来 B：“帮我查一下附近有没有适合生日的餐厅。”B 又给 C 下指令：“查餐厅。”C 回来后只有一句：“中午不开。”A 于是告诉你：“那家餐厅中午不开。”你问是哪一家？A 一脸茫然。这个场景不是段子，是我调多 Agent 框架时真实见过的输出。
委托链上传的从来不是一句“任务描述”
很多人以为 Agent 之间的委托就是 A 把一句话丢给 B，B 再把这句话加工一下丢给 C。实际上，一句话背后绑着五种不同性质的信息。它们各自的失真方式完全不同。
| 信息类型 | 典型例子 | 最容易丢失的环节 |
|---|---|---|
| 任务目标 | “找到一家能容纳20人的生日聚会餐厅” | 子 Agent 把它简化成“找到一家餐厅” |
| 约束条件 | 预算、时间、地点半径 | 上下文截断时排在最后的约束先丢 |
| 上下文背景 | 为什么过生日、有哪些人参加 | 转述时因为“与任务无关”被过滤 |
| 中间结果 | B 已经筛出5家，传给 C 继续核实 | C 只收到结论，看不到筛选逻辑 |
| 验收标准 | “要在周五前订到，且能订生日蛋糕” | 汇报给 A 时被整理得“听起来很好” |
拿“订餐厅”来说，任务目标是“订餐厅”，约束条件是“周五晚7点、靠近国贸、预算人均200”，上下文背景是“过生日，吃到一半可能有人迟到”，中间结果是“B 已经找到了3个备选”，验收标准是“每个备选都打电话确认有包间”。C 最后一句“中午不开”，只保留了任务目标里“查餐厅”三个字，其余四种信息全丢光了。这不是 C 笨，而是信息在传递时，被自然语言这个“有损压缩算法”给重编码了。
四个机制在同一时刻沉默地篡改你的指令
A 传给 B 的信息要经过这些机制，B 传给 C 还要再经过一遍：
- 目标抽象层级跳变。A 说“帮我订餐厅”，到 B 那里变成了“查一下预订信息”，到 C 那里变成了“打开网页”。高层意图的颗粒度，会在每一跳里被放到更低一层。
- 上下文截断。当前模型上下文窗口虽然大，但长对话中的中间内容本来就容易被忽略。Lost in the Middle 已经证明，LLM 会用开头和结尾的信息“覆盖”中间部分的细节。A 的十项要求，只要被 B 放在自己上下文的中间，就可能被概率性丢弃。
- 汇报时的“讨好性过滤”。C 完成得很勉强，但汇报时它会倾向把失败磨平。B 听完后向 A 转述时，也会为了显得靠谱而润色。每一层都在输出“听起来更正常”的版本。
- 采样随机性。temperature 大于 0 时，同一个语义可以长成不同句子。A 的指令，B 理解成 A，C 可能理解成 A’。这不是 bug，是语言模型生成方式的底层属性。
这里有一个更直观的例子。A 对 B 说：“客户要一份能放在微信里的数据报告，重点讲本周涨幅，不要提及具体百分比。”B 转头告诉 C：“做一份微信报告，重点讲本周数据。”C 看着“上周还是负数”的数据，觉得不提百分比没法讲，就自己补了一个“本期上涨20%”。最终输出违反了原始约束。每一层都觉得自己做了合理判断，合起来就成了事故。
三个框架的三种解法：让信息走专用管道
既然自然语言是罪魁祸首，那么严肃的 Agent 框架都采取了同一个方向——减少中间转述，让信息走结构化管道。
| 框架 | 核心思路 | 防失真机制 |
|---|---|---|
| LangGraph | 中心化 State 对象，节点之间不直接对话 | 信息以字段形式存在 State 里，节点只读写自己负责的字段，不转述上下文 |
| AutoGen | 对话历史加可执行函数调用 | 函数调用是硬性锚点，自然语言只解释“为什么调”，关键数据从函数参数直传 |
| Claude Code Subagents | 子 Agent 被限定为只操作文件与命令 | 结果以代码 diff 返回，主 Agent 审查 diff 而不是听子 Agent 的总结 |
MetaGPT 也走了类似路线，它让不同角色的 Agent 按标准化操作流程产出文档，每个角色的输出是结构化的产品文档，而不是自然语言闲聊。这些框架的共性是：把 Agent 从“传话筒”的位置上挪开，让信息直接接入上一个环节的输出。
我踩过的一个坑：五段互相不认识的文章
我最早以为多 Agent 系统的瓶颈是单个 Agent 的推理能力，直到我自己写了一个多 Agent 写作程序。主 Agent 拆出五个子 Agent 分别写引言、方法、结果、讨论和结论。它们各自写得很好，但拼接后，我读到了一篇四段互不相关的文章。子 Agent 之间唯一的联络方式是彼此的摘要轮播。引言引用了“上文的实验设计”，实验设计却还在另一个 Agent 的草稿里；结果部分把讨论中的“局限性”当成了已实现的功能。
后来我把父子结构删掉，改成一个共享 JSON 大纲，每个子 Agent 只负责填自己对应的字段。失真问题基本消失。这让我明白：多 Agent 协作的瓶颈不是智能，是接口。接口设计好了，哪怕是普通模型也能稳定协作。
一个反直觉的结论：模型越强，委托链越危险
你可能以为更强的模型能在传递中维护信息。但更强模型意味着它更擅长“脑补”。它会自觉地把缺失的空缺填上，让你看不出丢失过东西。这比明显丢失更危险，因为下游 Agent 会把脑补当成事实。所以增强单个 Agent 的智能，并不能让委托链更可靠；减少自然语言中介才更有效。
三个被高估的“灵丹妙药”
是不是模型更强，信息就不容易失真？
不是。更强意味着更会脑补，它会用看似合理的填充掩盖真实的缺失。解决方式不是提高单点智能，而是降低对自然语言的依赖。
把上下文窗口开大，总该行了吧？
不行。上下文窗口大了，模型只是能“看到”更多 token，但注意力分布依然倾斜。Lost in the Middle 的实验表明，中间内容在长上下文中反而更容易被忽视。更大的窗口只是让信息丢得更体面。
那用自然语言确认一遍，行不行？
确认本身也经过一次生成过程，等于又加了一轮有损压缩。B 对 A 说“我明白了”，和 B 实际上有没有明白，是两码事。
什么时候应该放弃委托链？
一句话：当任务需要超过一次自然语言转述才能说清时，就该考虑终止委托或改走结构化状态。如果任务本身简单，一个 Agent 直接做完；如果任务复杂，就把关键信息放到共享状态中；如果任务多变到没法定义结构化字段，那就做好心理准备——你正在玩传话游戏，输赢全看天意。
我的判断是，未来成熟的 Agent 系统里，委托链仍然存在，但链上的每一环都会变成“读状态，写状态”的节点，而不是“听一句说一句”的转述者。自然语言只发生在最外层，与用户的那一次交互上。内部，信息会像数据流一样走管道，不再被解释。所以，回答标题里的问题：信息怎么不失真地传递？答案是：别让信息经过“解释”，让它成为可以被读写的状态。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/667.html