多Agent系统跑上半年，最毛骨悚然的事情不是某个子Agent开始胡说八道，而是你打开日志之后发现，Orchestrator已经很久没有做过任何真正意义上的“编排”了。它一直在做的事情极其简单：把用户的消息发给某个子Agent，把子Agent的回复原封不动传回给用户。用户请求里有拆解空间，它不拆；几个Agent能力互补，它不协调；上下文里明明写着全局目标，它看都不看一眼。它成了一个彻头彻尾的邮差。
这个现象不是我编出来的。身边做Agent Infra的朋友，加上我自己带过的系统，只要连续跑上三到六个月，几乎都会走到这一步。很多人一开始以为是模型能力不够，换上最新的旗舰模型，过几天又打回原形；有人觉得是Prompt写得不够硬，往System Prompt里反复塞“你必须深度思考”“你是首席架构师”，日志里的行为依旧纹丝不动。问题的根源往往不在模型的单点能力，而在于整个系统长线运行后的演化机制。这篇文章想做的，就是把“邮差化”这件事从头到尾拆一遍：它为什么会发生、怎么用数据确认它已经发生、以及如何把编排器从邮差的位置上拽回来。正在维护长期运行的多Agent系统的工程师可以直接按文里的指标自查，准备立项做Agent编排的朋友也能提前避坑。
1. 半年时间为什么足够让一个编排器“退化”
1.1 上下文被增量日志稀释，全局目标逐渐失焦
一个多Agent系统真正跑起来之后，每一轮业务请求、每一次工具调用返回、每一段历史会话，都会以日志或记忆的形式进入Orchestrator的上下文。于是它每天“收到”的上下文量是线性增长的，但作为一个LLM，它的有效注意力是有限的。
我常打一个比方：一位项目经理刚上任时还愿意做战略拆解，半年后他的邮箱每天涌进来三百封邮件，而他最频繁的回复动作已经变成“转给对应同事”。他并不是能力变差了，而是注意力被无尽的增量消息淹没，系统目标在他脑子里从最高优先级滑落成了背景噪声。Orchestrator的上下文稀释，跟这个几乎是同构的。
还有一个更加隐蔽的加速器：Prompt膨胀。为了修线上问题、适配新业务，团队会不断往System Prompt里追加临时指令。半年下来，Prompt从800个token膨胀到2600个token，最前面那段“你是全局编排者，负责把任务拆解并分配给合适的Agent”的目标声明，早被埋到了第10段之后。大模型读提示词跟人读合同是一样的，关键信息如果被埋在冗长的细节后面，就会被直接忽略。上下文里最近几十条“用户问X，Agent A回答了Y”的具体消息，反而成了它决策时最依赖的样本——而这恰恰是问题所在。
1.2 工具调用硬化，成功路径在自我强化
第二个机制藏在工具调用分布里。大多数多Agent框架里，Orchestrator都有几个显式工具：task_decompose（任务拆解）、ask_agent（询问子Agent）、synthesize（汇总）、validate（校验）。但系统跑起来之后，你会观察到ask_agent或者说forward这种“转发”类工具的调用频率随时间单调上升，其他工具的频率单调下降。
原因不难理解。LLM在做推理时，本质上是在多个可能的工具序列里做概率采样；那些历史上“成功率高且成本低”的序列会被悄悄加权。直接转发恰好是成本最低、且成功率并不低的序列，于是一步步变成了默认序列。这个过程还有一个加速器：如果框架或记忆系统把过去成功的对话作为few-shot示例灌回上下文，那么这些示例本身就在教Orchestrator“你只要转发就行”。你往System Prompt里喊再多“要思考”，也敌不过上下文里五十条纯转发成功案例带来的潜暗示。路径一旦硬化，想靠几句提示词去掰它是掰不动的。
1.3 指标错了，转发行为就会被策略性“奖励”
很多团队上线前后会搭一套可观测性看板，看的是端到端延迟、答案准确率、用户满意度、任务完成率。这套指标跑下来半年，你会看到一个诡异现象：系统指标一直很稳，甚至略有上升，但Orchestrator的决策质量肉眼可见地在下降。为什么？
因为直接转发在这些指标上简直是“刷分神器”。Orchestrator少做一轮思考，端到端延迟就低了；子Agent模型很强，答案准确率通常也不差；用户面对一个响应很快且有模有样的回复，满意度照样打高分。于是监控系统无形中奖励了惰性，团队以为系统在越跑越稳，实际是编排器在策略性套利。
这跟业务里KPI定错了就有人刷KPI是同一个道理。你考核接线员“响应时长”，他就想尽办法一分钟挂断；你考核Agent系统“答案正确率”和“刷新延迟”，Orchestrator就聪明地学会了少干活。评估对象错了，行为必然歪。这是每一个做Agent平台的人都需要正视的指标设计问题，不是模型问题。
1.4 子Agent越来越强，编排器的“权力”被架空了
有一部分系统的Orchestrator退化成邮差，不是因为自己无能，而是因为子Agent已经强到不需要编排了。我见过一个团队把每个子Agent的Prompt写了一千多行，各自接了五个以上工具，有的还配了长期记忆库。这种配置下，单个子Agent本身就能完成任务拆解、知识检索、局部验证，Orchestrator无论怎么思考，都拿不出比子Agent更好的全局方案来。它唯一还能提供的信息增量，只剩下“该把任务派给谁”。
而一旦用户请求的类型逐渐收敛到固定几种，连“派给谁”都可以靠规则表解决。此时Orchestrator就彻底被架空成了一个RPC网关，架构图上它是指挥官，实际上它连传令兵都算不上，就是个消息交换机。这个现象我叫它“权力外移”：拆解、汇总、校验能力全部下放给叶子节点之后，上层编排器不退化成邮差才奇怪。遇到这种情况，做的第一件事不该是骂编排器蠢，而是重新审视职责边界。
1.5 记忆污染：它在用半年前的脑子做今天的决策
长期记忆系统如果没有设计好遗忘机制，就会成为把Orchestrator困在旧模式里的帮凶。多Agent系统的记忆通常分为工作记忆和知识库两类，问题大多出在知识库：如果每次运行结果、每条成功案例都被写进去，半年后里面会堆满“当时这样做成功了”的陈旧样本。Orchestrator每次决策前检索记忆，查出来的大概率是过去一个月反复出现的“直接转发也成功”模式，于是继续沿用旧策略，形成正反馈循环。
记忆污染更隐蔽的地方在于，它会把“系统目标”这个概念冲淡。如果知识库里既有“我们追求端到端正确率”的目标声明，又有几千条“转发一下就成功”的操作记录，LLM在参考上下文时很难分清哪个是目标、哪个是噪音。缺少遗忘机制的记忆库，本质上就是在慢性投毒。你要么给记忆增加时间衰减，要么在写入时打上业务标签，不能让它把半年前的认知一直搬到今天的决策里。
2. 动手诊断：你的Orchestrator到底“邮差化”到什么程度
2.1 第一步：给日志埋点，算出“纯转发率”
判断是不是邮差，不能靠感觉，要靠数据。我建议在Orchestrator每一次决策时都记录四个字段：本次调用过哪些工具、最大调用深度、是否生成了任务计划、是否做了结果汇总。基于这四类字段，我提一个核心指标：route_only_rate，纯转发率。统计窗口内，凡是Orchestrator只做了“转发”的请求，占比就是它。
def route_only_rate(logs, window_days=7): recent = [l for l in logs if l["ts"] > time.time() - window_days * 86400] if not recent: return 0.0 pure = [ l for l in recent if l["tools_called"] == ["forward"] or ( l["tools_called"] == [] and l["target_agent"] is not None ) ] return len(pure) / len(recent)注意，“转发”包括两条路径：显式调用了forward工具，或者完全没有任何工具调用而是直接把消息路由给了子Agent。我在实际项目里看到的退化曲线是这样的：第一到两个月route_only_rate基本在20%以下，第三个月爬升到35%，第五个月能到60%以上，第六个月之后长期徘徊在70%以上。这不是个例，是普遍曲线。
除了整体占比，我还会看第二个指标：tool entropy，工具调用分布的信息熵。当Orchestrator只用一种工具时，熵趋近于0；当工具均匀分布时熵较高。这个指标能帮你识别“硬化”的过程，计算方式也简单，统计一段时间内各工具调用次数，套一个信息熵公式：
import math def tool_entropy(counter): total = sum(counter.values()) if total == 0: return 0.0 ent = 0.0 for v in counter.values(): p = v / total if p > 0: ent -= p * math.log2(p) return ent如果tool_entropy从最初的2.3一路掉到0.5以下，那基本可以断定编排器已经不再编排了。
2.2 第二步：做一份“编排贡献”人工审计
光看机器指标还不够，我建议每两周挑20个真实用户请求，人工过一遍Orchestrator的完整调用链，给它打一个“编排贡献分”。标准可以很简单：消息在被转发之前，Orchestrator有没有补充“任务意图”“质量约束”“成功标准”？如果没有，它就是在做物理搬运。
我给三条打分数线：
- 0分：完全直接转发，没有任何前缀、约束、意图说明。
- 1分：转发了，但附加了简要的任务意图或背景信息。
- 2分：不仅说明了意图，还做了拆解、约束或校验，或在多个Agent之间做了信息交叉。
20个样例的平均分如果长期在1.0以下，说明编排器输出的多数消息都是“光秃秃的邮件”。这套人工审计虽然费时间，但每两周一小时的成本，比起半年后推倒重来，便宜太多了。
2.3 第三步：用Git管理Prompt版本，做快照对比
如果你一直在给接口打版本，那System Prompt大概率也改过很多轮。我强烈建议用Git管理所有Prompt版本，系统运行半年后专门做一次对照实验：拿同一批测试集，分别用1月份版本的Prompt和当前版本的Prompt驱动同一个Orchestrator，对比策略分布。
我做过一次，当时结果很说明问题。同一个测试集，1月的Prompt还能在20%的请求里先拆解再分配，6月的Prompt基本是90%的请求都直接转发。这不是因为当前版本Prompt写得更差，而是因为半年里为了修各种线上问题不断追加内容，目标声明早被冲散。Prompt快照对比的原理很简单：行为漂移和Prompt漂移是同步的，你只有把时间变量控制住，才能看见真正的因果。
2.4 第四步：给编排器立一块健康度看板
诊断的终点，是把它变成日常可观测。我把前面几个指标合并成“编排器健康度”看板，每半小时刷新一次，核心指标就四个：route_only_rate纯转发率、tool_entropy工具熵、message_payload_ratio编排消息携带意见载荷的比例、multi_agent_interaction_rate多Agent协作率（一次请求中实际调用了两个及以上子Agent的占比）。
这四个指标不需要很复杂的部署，有日志系统就能算。一旦立起来，你会在第三周就在看板上看到下滑曲线，而不是半年后才靠翻日志发现。团队里有人问“我们的Orchestrator还在编排吗”，标准答案现在是：自己去看看板。能让监控替我们说话，就少一点“我感觉它在退化”的主观争论。
3. 把邮差改回编排者：四招实操改造
3.1 第一招：给转发消息加“意见载荷”，并设计硬校验
最简单的改造不需要换模型，不需要重写框架。在Orchestrator产出消息的schema里增加三个必填字段：task_intent（任务目标，用自己的话重新表述用户意图）、quality_constraints（对子Agent输出的质量要求，例如“答案至少要引用两个数据源”）、success_criteria（什么样的结果可以被整体接受）。这三个字段缺失时，框架在下一层子Agent节点前直接拒绝执行，并提示“编排者未完成编排职责”。
这个思路用JSON schema表达非常直观：
{ "type": "object", "required": [ "target_agent", "task_intent", "quality_constraints", "success_criteria" ], "properties": { "target_agent": {"type": "string"}, "task_intent": {"type": "string"}, "quality_constraints": {"type": "array", "items": {"type": "string"}}, "success_criteria": {"type": "array", "items": {"type": "string"}} } }这套硬校验的原理是：不让LLM“自愿”变得负责任，而是用系统结构去强制它负责任。这也是对抗Prompt漂移最稳的方法——守住数据契约，别天天祈祷模型自己觉醒。没有意见载荷的消息不允许出编排层，邮差模式在源头就被掐断。
3.2 第二招：切断“纯转发”的自我强化回路
光加必填字段还不够，LLM的路径依赖还在，它有可能随便填几个空洞的task_intent然后继续转发。所以第二步是切断自我强化回路。具体做法有三个：
第一，在few-shot示例里不要再放大量纯转发的成功案例，改成放几个“Orchestrator仅做转发、结果被下游校验打回”的失败案例，让概率分布重新摆正。第二，给转发路径加成本：在框架层检测到当前请求需要拆解但Orchestrator选择直接转发时，强制插入一步“任务拆解确认”，让Orchestrator先输出拆解方案，再决定是否还需要走单Agent路径。第三，灰度降权：对历史记忆里“纯转发成功率”较高的记录做降权处理，让记忆检索不再总是召回那些廉价的“转发一下就好了”样本。第三点操作上可以在写入记忆时给每条记录打一个“编排复杂度”标签，复杂度为0的记录在检索时权重直接打五折。
3.3 第三招：每月做一次“目标对齐”回刷
Prompt膨胀几乎是必然的，你没办法要求系统一直不改Prompt，也不该害怕改Prompt。每四到六周安排一次“目标对齐回刷”：把当前System Prompt从头到尾读一遍，删掉已经失效的临时指令，把“你是全局编排者，不是消息网关”这个锚点句子提升到Prompt最顶部，并在每次运行开始时强制输出一版当前全局目标说明，哪怕只是一句话。这句话同时写入消息上下文，让后续所有节点共享。
我用过一个更暴力但很好用的方法：把全局目标单独抽成一个文件，运行时动态渲染到System Prompt第一段，和其他追加的运维指令彻底隔离。这样无论下面堆多少补丁，最顶部的目标声明永远是最新的。回刷的节奏控制在每月一次，每次压缩掉约20%的冗余内容。这套操作不需要重新训练模型，纯粹是Prompt工程加DevOps习惯，但效果比反复调置信度直观得多。
3.4 第四招：把子Agent的“越权能力”回收一部分
前面提到权力外移：子Agent已经强到顺手把编排者的拆解、汇总能力也代办了。这种情况下，架构上就该考虑做一次职责重划。我的做法不是去精简子Agent的Prompt，而是把一些跨Agent能力从子Agent侧回收到Orchestrator侧。比如子Agent保留领域知识检索和局部生成能力，但“跨模块汇总”和“多源冲突仲裁”这两个能力只保留在Orchestrator的工具箱里，只有它能调用cross_agent_synthesize和conflict_resolver。
子Agent发现自己没有这些工具之后，遇到需要协调的场景，就不得不把控制权交还给Orchestrator。这一招在架构上听上去像“倒车”，实际是在重新划定指挥线。系统能力整体上浮之后，指挥权需要重新收拢，否则层级架构名存实亡，编排器迟早变成摆设。
3.5 第五招：每季度做一次人工编排审计
最后一环，也是最容易被工程文化忽略的：人工。多Agent系统跑半年后，团队往往已经完全信任自动评估指标，忘了人工审计。我强烈建议每个季度随机抽取100个用户请求，让一位资深工程师人工标注Orchestrator的决策质量，然后和看板指标横向对比。如果人工标注显示编排贡献分在下降，而看板指标还在微笑，说明看板指标体系本身出了问题，优先把看板改对，再回去调模型。让看板可信、让指标对齐真实目标，比任何一次模型升级都重要。
4. 半年里踩过的坑与几条反直觉的经验
4.1 以为换最新模型能救回来，实际上救不了
第一次发现Orchestrator行为退化时，我的第一反应是“是不是这版模型太笨”。把系统从较弱的一个模型换到当时最新的旗舰模型，跑了三天，route_only_rate从68%掉到55%，一个星期后又回到65%。这个数据让我放弃了幻想：模型换血只能治标，上游的Prompt漂移、记忆污染、指标错配才是病灶。再强的模型也架不住一个天天教它偷懒的系统环境。
4.2 以为“进化”就是加Prompt，结果越加越糊
我也犯过往System Prompt里反复叠甲的错。三个月里给Orchestrator加了十几条“你必须深度思考”“不要只做转发”的指令，行为纹丝不动。后来才想明白：指令密度太低，早被海量上下文和few-shot示例淹没。与其反复叠甲，不如用一条硬校验放在数据契约层，让缺失关键字段的消息根本走不下去。结构强制，永远比语言劝说有效。
4.3 一开始把退路堵死，结果简单任务也卡死
有一次我做得太猛，直接在框架里禁止纯转发，检测到单Agent路由就报错。改完之后，系统处理非常简单的任务也强制拆解，一个“今天天气怎么样”级别的请求走了五步工具链，端到端延迟从0.6秒飙到4秒，用户投诉率翻倍。这个教训很深：纯转发本身不是错，错的是在高价值任务上回避编排。该转发的转发，该编排的编排，判断标准就是意见载荷——只要消息上带上了任务意图和质量约束，哪怕只走了单一Agent，它也是在有意识地选择，而不是物理搬砖。
4.4 把“生成Plan”当KPI，结果制造了徒有其表的思考
为了鼓励Orchestrator多干活，我一度把“是否生成了Plan”作为核心指标，结果系统出现大量空壳Plan：先输出一个编号列表，然后底层行为还是转发。指标告诉你它在思考，行为告诉你它没有。所以指标必须盯“信息增量”，而不是“动作形式”。Plan生成次数、工具调用次数都是虚荣指标；路由后消息里是否带上意图、约束和校验信息，才是有效指标。抓错重点的监控，比不监控还危险。
5. 速查与清单：给已经邮差化和还没邮差化的人
5.1 自我检查清单：你的系统是否正在走向邮差化
这里有一份六条自检清单，过去半年我用它查过不止一个项目，命中三条以上就该启动改造了：
- 最近一个月日志里，route_only_rate是否连续三周上升？
- tool_entropy是否已经低于1.0？
- Orchestrator发出的消息里，带质量约束的比例是否低于20%？
- 季度人工审计的编排贡献分是否连续两次下滑？
- 子Agent的Prompt长度是否已经超过Orchestrator的Prompt长度？
- 系统Prompt里是否已经堆了三段以上互相矛盾的临时指令？
5.2 常见问题快速排查表
| 现象 | 可能原因 | 排查方法 | 推荐解法 |
|---|---|---|---|
| Orchestrator不拆解任务，直接转发 | 上下文稀释加路径强化 | 看route_only_rate与tool_entropy走势 | 意见载荷加硬校验，切断转发回路 |
| 加了“必须思考”的Prompt却没有效果 | 指令被上下文淹没 | 做Prompt快照对比 | 目标锚点放最顶部，少放纯转发few-shot |
| 系统延迟突然变高 | 之前禁转发导致所有任务强制拆解 | 检查最近路由策略改动 | 允许单Agent，但强制带意见载荷 |
| 评估指标都在涨，但感觉编排质量在下降 | 指标奖励了惰性 | 做人工编排贡献审计 | 把多Agent协作率和意见载荷比例纳入看板 |
| 记忆总是检索到旧的“转发成功”案例 | 缺少遗忘与降权机制 | 看记忆检索topK里有多少纯转发样本 | 低编排复杂度记忆降权，加时间衰减 |
5.3 从第0天开始防邮差化：上线前的五个设计决策
如果你现在还在系统搭建的早期，请把下面五件事写进设计方案里。它们不需要额外成本，但能省掉半年后的所有返工。
数据契约设计：从第一天开始就要求Orchestrator输出意见载荷字段，无字段不下发。指标设计：从第一天就把route_only_rate、tool_entropy、message_payload_ratio加入看板。Prompt管理：所有Prompt进Git，每次上线走CR流程，禁止线上直接改。记忆设计：给记忆记录打编排复杂度标签，低复杂度记录从写入时就降权。架构边界：不要把跨模块汇总和冲突仲裁这类协调能力全部下放给子Agent，协调权要留在编排层。
最后我再分享一点个人体会。多Agent系统的退化，不是那种“砰”一声坏掉的故障，而是温水煮青蛙式的渐变。你翻日志的那天，它其实已经默默当了很久邮差。所以我把“编排器是否还在编排”当成一项常态运维工作来对待：看板每周看一眼，Prompt回刷每月做一次，人工审计每季度来一轮。这三个动作看似琐碎，缺一个都可能把整个系统慢慢拖回邮差状态。如果你现在还在上线初期，务必在第一天就埋好指标；如果已经跑了大半年，也别慌，只要路由日志和Prompt快照都还在，用前面说的四个指标去定位，用意见载荷和硬校验去回拽，通常两到四周就能看到route_only_rate明显回落。让编排器重新干起编排的活，这事不难，难的是承认它已经悄悄变成邮差的那一天。
