线上系统出问题时最磨人的往往不是改代码而是先弄清楚哪里坏了。日志里一堆报错监控曲线刚好抖了一下工单又说用户只在某种配置下遇到。工程师要在几套系统之间来回翻还得靠老同事记得“去年好像出过一次”。Panasonic Avionics 把这段排查拆给了不同 Agent。它服务的是飞机上的娱乐与联网系统规模和普通公司的应用差得很远。不过那条拆分思路很实在别让一个万能助手从头猜到尾让每个 Agent 只负责一种能核对的工作。第一个找异常第二组查原因最后一个讲人话第一层是趋势分析器。它盯着关键指标和服务变化先回答“哪里开始不正常”。这比等工单堆起来再查多了一点提前量。发现异常后三类诊断 Agent 同时开工一个找相同配置之间的关联一个核对系统状态和已知维护记录一个把当前日志和过去的故障模式做匹配。最后才轮到大模型。它把几路结果整理成根因假设、影响范围和处理建议。换成日常话就是有人负责发现有人分头查证有人把证据写成一份看得懂的报告。这里有个容易被忽略的细节团队没有让大模型包办全部判断。公开案例写明生成模型主要用在总结和错误推理能用固定规则核对的地方仍交给确定性的程序。重要故障的修复动作也不会自动放行。AI 给出证据和建议工程师审阅后再决定是否处理。系统上线前自动结果还要和人工专家的判断对齐。普通团队先学这张排障卡不必照搬航空系统也不用先搭多智能体平台。先把一次真实排障记录成七格异常信号什么指标、从什么时候开始变化关联范围哪些环境、版本或客户一起出现已知变化最近是否发布、改配置或做维护历史相似过去有没有相同症状和处理结果当前假设怀疑什么依据是什么下一步动作还要查哪条证据批准人谁能决定回滚、重启或修改生产配置。AI 最适合先填前六格的草稿人负责最后一格也负责删掉证据不足的猜测。每个判断后面最好带上日志位置、指标截图或工单编号不让一句顺口的解释变成“已经找到根因”。Panasonic 的内部测试把部分调查从几小时降到几分钟目标场景的运营效率提高了 20%—40%。但公开材料没有给出样本量和准确率具体数值这组结果只能说明他们的内部案例不能当成任何系统都能复制的承诺。这套案例里最好借走的其实只是分工方式能规则化的先规则化能并行查的同时查需要表达和归纳的最后交给大模型。遇到会改数据、停服务或影响客户的动作仍然让人按下最后那个按钮。