有两组公开的实验数据值得放在一起看。一组是：在多智能体根因分析系统中引入一个专门负责"证伪"的角色后，单服务故障场景的定位准确率从 21.3% 提升到 33.3%。另一组是：2026 年一篇针对云环境根因分析智能体的实证研究，把失败归因到三处不透明——控制器对遥测数据的解读不透明、智能体之间用自然语言摘要交接导致细节丢失、运行时内核状态在智能体视野之外。
两组数据指向同一个结论：瓶颈不在模型，在诊断链路上有没有足够的观测结构。行业里流传的另一个说法——"模型越强，根因越准"——需要被拆开重新检验。
一、一个常见说法：模型越强，根因越准
这个说法的推理链条是：根因分析本质上是模式匹配，模型参数量越大、上下文越长，能消化的指标、日志与调用链越多，结论自然越准。顺着这条推理，采购决策会变成对模型档位的比拼。
工程上的事实是另一回事。同一个故障场景在不同时期需要不同的分析路线，而路线选择与模型能力并不单调相关：
| 路线 | 实现方式 | 依赖的数据 | 失效条件 |
|---|---|---|---|
| 固定编排 | 预定义分析流程，按序调用观测数据 | 指标、日志、链路 | 故障形态超出编排范围 |
| 领域模型 | 调用领域模型读取分析结果 | 上述数据 + 知识图谱 + 领域模型 | 领域模型不完整 |
| 大模型编排 | 由模型自动编排、解析与总结 | 上述数据 + 智能体编排 + 知识库 | 可变性高，必须配证据链 |
数据库死锁这类形态稳定的问题，固定编排又快又准；"某条业务链路成功率突然下降"这种开放式问题，才需要走到大模型编排。判断标准不是"能不能给出答案"，而是"答案能不能追到证据，并且错了能被发现"。
二、这个说法在什么条件下才成立
"模型越强越准"要成立，需要三个前提同时满足。
前提一：同一个对象在三个入口是同一个对象。 指标库里的服务名、日志主题里的服务名、配置项记录里的服务名必须能对齐到同一个实例。做法是为指标数据关联模型标识与实例标识，为链路数据关联服务标识与实例标识，再用统一标识把资源拓扑与调用拓扑关联起来；确实缺失统一标识的部分，按 IP、端口、MAC 这类物理主键兜底匹配。
前提二：数据被组织成有向图，而不是一堆并列的时序。 节点代表系统组件（服务、容器、主机、数据库），边代表依赖或调用关系，边上附加调用延迟、QPS、拓扑类型（同步调用或异步消息）。有了这张图，"传播方向"才是可计算的，才能区分是上游影响了下游还是下游拖垮了上游。缺少拓扑感知时，证伪环节会把下游故障误当作反驳上游假设的证据，反而把正确假设否掉。
前提三：时间维度对齐。 按时间窗口聚合，确保"同一时刻"的指标、调用、日志对应同一系统状态。很多看起来离谱的根因推荐，根源是把五分钟前的慢查询与当前的资源抖动关联在了一起。
三条前提不满足时，模型拿到的是三份互不隶属的数据，只能做概率性的关联猜测。参数量再大，也只是把猜测说得更流畅。
三、被忽略的部分：三个隐含假设
假设一：输入端噪声可以忽略。 实际上输入质量直接决定结论上限。指标侧，固定阈值在周期性波动的曲线上几乎必然误报；较稳妥的做法是先对曲线做自适应分类——波动型、趋势型、季节型——再为每类曲线选择适配算法，同一类曲线用两种以上算法检测并投票决策，模型基于过去 14 天历史数据构建、用网格法选择超参。
日志侧同理。把每一行日志当作独立文本时，任何相似度的暴增都会被判为异常。正确做法是先做模板提取：分离常量与变量，常量提取为事件模板、变量提取为参数，再通过前缀树预过滤、倒排列表与降级匹配找到相似度最高的日志键。这样异常判据是"出现了从未见过的新模式"，而不是"行数变多了"。
假设二：模型会主动怀疑自己。 不会。模型天然倾向于寻找支持自身假设的证据。缺少反向检查（"如果是 A 导致的，那么 B 指标应当同步异常，事实上没有"），很容易把巧合当成因果。这是为什么证伪角色带来的提升比增加智能体数量更显著——研究数据表明，单纯增加智能体数量并不提升准确率，多角色的价值主要在可调试性与可审计性。
假设三：证据不足时会说不知道。 默认不会。真正的排查应当在证据不充分时返回上一步补充取证，或输出 Top-K 个方向并明确标记缺失了哪些证据，同时保留人工介入入口。"证据不足就承认不足"是评估系统是否可用的硬指标——一个永远给出确定答案的系统，比偶尔说"还需要查 XX 才能确认"的系统更危险。
四、更准确的模型：证据链、反证与四类验收检查
把上面三条摊开后，一个可被采纳的根因结论应当满足四项检查，且每一项都能在真实故障事件上当场验证。
结论可回溯。 每个根因结论必须能展开到具体数据项：哪些指标、哪些日志模板、哪条调用链、哪次变更。无法展开到数据项的结论，无论措辞多确定，都不应进入生产决策流程。
推理路径可见。 每一步执行轨迹应当可查看：调用了哪个工具、读了哪段数据、基于什么判断进入下一步。这既是排错依据，也是安全审计要求。2026 年逐渐收敛的做法是用 GenAI 语义约定为 invoke_agent、execute_tool 这类操作定义统一的 span 名称，让智能体的行为变成可追踪的遥测——规范目前仍标记为开发中，属性名会变动，但方向已经明确。
变更与历史故障在同一条证据链里。 绝大多数生产故障由变更引发。根因推荐系统如果不查询发布、配置修改与扩缩容记录，候选集先天残缺。
能说明"为什么排除"。 让系统解释"为什么不是那个看起来很像的方向"。能回答这个问题的系统通常具备反证机制；答不上来的，多半只做了相似度匹配。
配套的一件事是告警快照：在告警产生的瞬间固化一份现场，覆盖对象的业务与应用信息、拓扑关联、服务调用、指标与日志、关联告警、Dump 与 Profile、变更工单与作业记录、知识库条目。凌晨三点的告警早上八点复盘时，容器已经重启、堆栈已经丢失，没有快照就无法判断当时的结论对不对。告警回溯时间轴是另一个对照工具：把智能体给出的传播路径与时间轴对照，顺序不一致就说明推理链路本身有问题。
五、如何用实验区分这两种理解
区分"模型决定论"与"证据链决定论"，只需要一组对照实验，不需要相信任何宣传口径。
实验一：同一批告警，人与系统同时查。 选择故障频次较高、形态稳定的场景，让智能体与值班人员同时分析同一批告警，统计三个数字：结论一致率、系统给出而人工忽略的正确项、人工给出而系统漏掉的项。这一阶段通常持续 2 至 3 个月，目标是积累对可信度的量化认识。
实验二：回归测试集。 把历史故障当作智能体的单元测试。已经定性的事故及其证据链构成一组回归用例，每次模型或编排改动后重跑，看结论是否稳定。这是目前少有的能证明投资回报的办法。
实验三：噪声注入。 故意让时间窗错位、让标识对齐失效，观察系统是否仍输出确定结论。会输出的系统说明它没有证据充分性判断，应当直接淘汰。
六、仍然存在的边界
有三件事还没解决。其一，写入类操作必须保留在人的手里。稳妥的分工是：智能体负责解释与建议，人负责判断与决策，平台负责管控与追溯。分级放开的顺序是从低风险操作（日志清理、临时文件释放、已知异常服务重启）开始，高风险操作始终保留人工决策，每一档放开前都要确认误报率处于可接受区间。
其二，智能体本身成了需要被运维的对象。它的接口返回可能完全正常，但决策链里藏着一个幻觉；它可能陷入工具调用循环烧出意外成本；多个智能体的错误联动可以制造出传统混沌工程从未覆盖的故障模式。运维的对象从"服务是否可用"扩展到"决策是否可靠"，相应的度量体系还不成熟。
其三，数据基础的完整度决定上线周期。对象模型与采集已就绪时，从接入到产生第一个可信结论在数周量级；需要先整理对象模型与拓扑的，通常要额外数月。顺序上应当先把事件本身治理干净——先丰富告警字段、按变更窗口与网络割接期做时间屏蔽、对已知高频抖动做抑制——再谈让智能体来判断。反过来做，智能体学到的是一个噪声环境。一组公开项目口径的数据可作参照：在完成字段丰富与时间屏蔽后，告警自动转工单比例达到 90%，告警抑制率达到 60%。
