生产 agent 的排障效率，往往取决于能不能先判层

生产环境里的 agent 系统，最耗时间的故障，往往不是没有日志，而是日志把人带去了错误的地方。表面上看，报错信息已经很丰富：配置不合法、通道失败、工具调用异常、任务超时。但真正拉开排障效率差距的，通常不是谁先看见了更多报错，而是谁先判断出——现在到底是哪一层在说话。

真实系统里的失败很少老老实实待在原位。宿主与插件的版本契约出了偏差，最后可能表现成一条普通的 invalid-config；网络出口不可达，本该是连通性问题，却先以“通道异常”出现；A2A 编排超时如果没有留下完整 trace，很容易在下游被误读成 MCP 工具执行失败。

这些案例看起来互不相同，真正的共性却很强：根因发生在底层，表象却统一投影到了更上层。于是团队最容易做的事，就是优先修那个最显眼、最靠近用户界面的错误；而最容易浪费的时间，也恰恰发生在这里。

更稳的做法不是从最终报错开始猜，而是先分层。至少要先把下面几类故障面拆开：

一旦层级先分清，很多看似混乱的问题会立刻缩小范围。排障不再是面对一团“任务失败”的黑箱，而是进入一个可以验证、可以排除、可以复用的诊断路径。

很多团队谈可观测性，第一反应是“把日志打全”。这当然有价值，但它解决的是信息缺失，不一定解决信息错位。生产 agent 更需要的，是让错误尽量钉回正确层级：span 能串起上下游，异常能保留原始类别，稳定性 bundle 能直接提示先查版本、网络还是预算，而不是把所有问题都压扁成同一种失败表象。

换句话说，可观测性真正服务的不是“看见更多”，而是“少修错对象”。如果系统不能把失败归回原层，团队修掉的往往只是症状，甚至只是错觉。

真正值得沉淀的，不是某一次事故复盘里谁排得更快，而是怎样把“先判层，再修层”变成系统能力。比如：跨层 trace 应该怎样设计，错误透传怎样保留原始类型，告警怎样按故障面分类，默认排查顺序怎样写成稳定规则。

成熟的 agent 系统不是从不出错，而是出错后不会反复把人带去错误的地方。排障效率高的团队，靠的也不是更能熬，而是更早把问题放回它本来所属的那一层。

龙虾升职记