设想你是一家工厂的维护负责人。循环水泵 P-204 近期出现振动趋势升高，研发团队接入的 Agent 很快生成了一份报告：列出了可能的故障部位，附上手册引用，最后建议安排维修。

报告写得专业，格式也完整。但你真正需要判断的是：它说的是眼前这台设备吗？这些证据支持这个结论吗？班组拿到建议后，是否知道下一步该做什么？

设备维护中的可靠性，就藏在这些具体问题里。我们沿着这份报告逐步检查，看看一条看起来合理的建议，要经过什么，才能成为值得采用的工作依据。

一、先把结论拆开，看看每句话从哪里来

假设报告里有一句：“振动持续升高，可能与轴承问题有关，建议更换轴承。”读起来很顺，但其中实际上连接了三个不同层次的判断。

“振动持续升高”应当来自可核对的数据；“可能与轴承问题有关”是一种待验证解释；“建议更换轴承”则进一步影响维修安排。前一句成立，并不意味着后两句已经得到足够支持。

因此，验收这份报告的起点，是拆开它的主张。用于判断的趋势来自哪台设备、哪个测点、什么时间？数据是否完整，前后的测量方式是否一致？引用的手册是否对应这台泵的型号与配置？这些看起来基础的关联，一旦出错，后续解释越详细，偏差可能越难被发现。

例如，Agent 查到一份同系列设备的手册，却没有核对配置差异。这份资料可以提供调查线索，但不能直接成为当前设备的维修依据。此时首先需要补齐身份与适用范围，继续润色报告并不能解决问题。

让关键结论带上来源位置，会使检查更有效率。维护人员可以直接打开对应记录，而不用重新翻查整份资料库。需要核对的也不仅是有没有引用，还包括被引用的内容是否真的支持这句话。

一份报告的第一道检验，由此变得很明确：重要判断能否回到正确的设备、时间和证据。通过了这一步，才有基础继续讨论建议是否合理。

二、证据补齐以后，仍然要保留不确定性

接着往下检查，维护人员发现了两份需要一起解释的材料：运行记录显示近期工况调整过，历史工单里也曾记录过一次振动异常。Agent 如果只取其中一份，都可能得到过早的结论。

工况变化提示我们，前后数据未必具有相同的比较条件；过去出现过类似现象，也不代表这一次原因相同。两份材料的作用，是帮助缩小调查方向，而不是替代当前检查。

在这个阶段，一份可用的报告应当让读者分清三件事：已经确认的情况、仍然可能的解释，以及下一步需要补什么证据。它们可以出现在同一页里，但不能使用同样确定的语气。

例如，报告可以明确说明，现有记录中能看到趋势变化，但可比工况和现场检查信息尚不完整，因此当前材料不足以支持具体部件更换。随后再说明需要由谁补充哪些记录，以及这些记录将帮助判断什么。

这种表达并没有降低建议的价值。维护工作的一个重要结果，就是把不确定性缩小到可以继续处理的范围。无依据地指定一个故障部位，看起来更果断，却可能把调查和备件准备带向错误方向。

同样，模型给出的置信度不能代替验证。没有经过实际任务校准的“高可信”标签，很难告诉班组应该如何安排工作。清楚的依据与缺口，比孤立的信心数字更有用。

如果目前确实缺少决定性资料，明确停留在检查建议阶段，就是一种合格输出。系统的目标不应迫使每次告警都以一份确定维修方案结束。

三、建议有了依据，还要让现场接得住

经过前两步，报告已经不再直接指定更换部件，而是提出一项有范围的检查建议。接下来要问：这条建议能被现场理解和接续吗？

“建议进一步检查”过于宽泛。班组还需要知道对象是谁、当前问题是什么、已经获得哪些证据、哪些事项尚未确认，以及检查结果应该怎样返回。否则现场人员仍需重新询问背景，Agent 的整理没有减少多少工作。

可执行性也受到真实条件约束。设备是否具备安排检查的条件，是否需要协调维护窗口，相关人员和资料是否可用，都可能影响计划。Agent 可以整理这些依赖，但具体运行处置和维修执行应由有权限的人员依据现场制度决定。

这时，可以给报告安排不同类型的检查。设备编号、文件版本、时间范围和必填字段，适合由程序核对；主张与引用是否一致、是否遗漏用户要求，可以让模型辅助评审；设备判断和现场可行性，则需要维护人员结合专业知识把关。

几类检查的职责需要说清楚。程序发现字段齐全，不意味着维修判断正确；另一个模型觉得文字合理，也不能证明故障已被确认。模型评审可以帮助筛出值得复核的位置，但不能成为给自己结论盖章的唯一渠道。

最后，建议应与确认后的版本绑定。如果班组正在看的报告仍引用旧工况，即使此前已经审核过，也需要重新核对受影响的结论。可采用的对象始终是某个具体版本的建议，不能泛化为系统以后说什么都可信。

四、判断系统好不好，需要看一批不同的建议

一份报告经过复核，不代表系统已经可以稳定工作。要决定是否扩大使用，还需要让它面对不同任务：资料齐全的情况、记录冲突的情况、现场反馈延迟的情况，以及没有足够依据形成维修结论的情况。

这些任务可以来自经过整理的真实历史，也可以用解释性案例补充边界，但必须有可核对的背景与验收依据。对于已有事后结论的案例，只能把当时可获得的信息交给 Agent，避免把维修结果提前泄露给它。

评价时，值得分别观察几类结果：重要异常有没有被遗漏，不需要维修的情况是否被过度升级，建议有没有混淆设备或工况，缺少证据时能否合理保留判断，以及现场是否容易接续。不能只统计报告有没有生成。

其中，误报、漏报和不必要维修都需要谨慎标注。设备暂时没有发生故障，不足以证明告警一定无意义；维修后指标改善，也不能单独证明维修建议完全正确。需要结合检查记录、时间范围与专业复核，形成有依据的判定。

成本则要覆盖整段工作。一个方案生成文字很快，但要求人员反复查证不相关材料，实际可能更耗时。另一个方案多做了一次资料核对，却减少了大量返工，综合成本可能更合理。

比较两个 Agent 方案时，应尽量使用同样的任务和可见信息，并记录工具、预算及环境差异。若一个方案多调用了数倍资源，不能只凭更完整的报告，就把收益全部归因于模型更强或协作更好。

五、一次判断偏差，要能追到具体环节

评估发现某些建议过度倾向部件更换，接下来就需要回到产生建议的过程。仅仅追加一句“不要过度维修”，很难知道问题是否真正解决。

对 P-204 这类任务，可以依次检查：系统有没有取得正确设备资料，是否对齐工况，历史记录有没有被当成当前事实，模型是否跳过了等待中的检查结果，以及最终表达有没有把可能性写成确认结论。

假如偏差起于引用了错误版本的手册，优先修正资料匹配与检索规则；如果所需证据已经提供，模型仍反复把关联写成因果，就需要继续检查提示方式、评审标准或模型能力。不同位置的问题，应当有不同的处理方式。

执行轨迹在这里提供依据。保存必要的输入、工具结果、任务版本与最终报告，就有机会复核首次偏离，而不是只能看到最后那句错误建议。记录的范围也应与任务和权限相匹配，不必为了排查保存无关信息。

修订后，既要重看出过问题的任务，也要检查其他类型的建议有没有退化。例如强调谨慎以后，系统是否变得凡事只会要求更多资料，连已具备证据的任务也无法推进？降低过度判断和保持工作效率，需要一起检验。

对于维护人员，一份值得采用的建议，应当让事实、推测、缺口与下一步清楚可见。对于开发团队，一套值得持续使用的 Agent，还应当能把每次偏差带回具体环节，证明改进确实让后续工作更可靠。

参考来源与编辑说明

本文依据李博杰《深入理解 AI Agent：设计原理与工程实践》2.0 版相关内容进行主题改写。