AI Agent 在故障排查场景中生成错误建议时，如何用证据约束、置信度、人审/拒答、工具校验和回归评测避免误导用户？｜滴滴 AI 应用开发面经解析

60 秒回答模板

我会先把故障排查 Agent 的输出分级：低风险的信息整理可以自动生成；中风险的排查建议要附带证据和可回滚步骤；高风险的变更、删除、扩容、重启、封禁等操作必须经过人审或工具权限控制。Agent 不能只凭模型记忆回答，它应基于日志、指标、trace、告警、变更单、知识库和工具实时查询结果生成建议，并在答案中区分事实、推断和建议。没有证据或证据冲突时，应该降低置信度、提出下一步采集信息，甚至拒答。落地上我会做三层约束。第一是输入和检索约束：把用户问题结构化成服务、时间窗口、现象、影响范围和已知变更，检索只使用有权限、时效明确、来源可信的证据。第二是生成约束：要求每条建议关联证据、风险等级、预期现象、验证命令和回滚方式，禁止输出未经授权的破坏性动作。第三是评测和运营：建设历史故障 case、反事实 case、工具异常 case 和红线 case，离线看证据引用准确率、建议可执行性、误导率和拒答率，线上看采纳率、人工纠错、事故后复盘和误操作事件。这样 Agent 才是排查助手，而不是不受控的自动运维专家。

考点 故障排查 Agent 必须区分事实、推断、建议和操作

难度 真实面经题

回答目标 让候选人能把故障排查 Agent 从聊天能力提升到可信工程系统，覆盖证据、工具、权限、拒答、人审和评测闭环。

深入解析

风险分级

故障排查建议有不同风险。查看日志、汇总现象风险低；建议扩容、重启、回滚、删除数据风险高。不同风险要对应不同权限、人审和确认机制。

证据约束

Agent 应基于监控、日志、trace、变更记录、工单和知识库作答，并标出事实来源。没有证据时只能提出假设和下一步检查，不能把猜测包装成结论。

工具校验

对关键判断要用工具验证，例如服务健康、错误率、依赖状态、最近发布、容量水位和告警关联。工具返回异常时要暴露不确定性，而不是继续生成确定建议。

置信度和拒答

置信度应由证据完整性、证据一致性、历史相似度和工具可用性决定。证据不足、权限不足、风险过高或问题超出系统边界时，要拒答或请求人工介入。

人审与权限

高风险动作要通过审批、双确认、最小权限和审计日志控制。Agent 可以生成 runbook 草案，但不能绕过现有变更流程直接执行危险操作。

评测闭环

评测集要覆盖真实事故、相似误导样例、过期知识、工具失败和诱导性问题。指标不能只看回答流畅度，还要看证据正确率、建议有效性、风险控制和人工纠错率。

易错点

只说提升 prompt，忽略证据、工具和权限控制。
把模型生成的解释当作事实，不区分事实和推断。
没有风险分级，让低风险总结和高风险操作走同一流程。
没有拒答机制，证据不足时仍然输出确定结论。
离线评测只看相似度或人工打分，不看误导率和安全事件。
忽略工具权限和审计，无法追踪谁触发了什么建议或操作。

面试官追问

如果用户要求 Agent 直接重启线上服务，怎么处理？

先判断权限和风险。Agent 可以检查服务状态、影响范围和变更窗口，给出重启前检查清单与回滚方案，但实际重启应走授权工具、人审或现有发布流程，并记录审计。

如何判断一个建议有没有证据支撑？

看建议是否绑定了具体数据来源、时间窗口和验证结果，例如某服务 P99 在发布后升高、某依赖错误率同步上升。只有泛泛说可能是缓存或网络，不算证据支撑。

拒答会不会降低用户体验？

盲答才是更大的体验和安全风险。好的拒答不是一句不能回答，而是说明缺少哪些证据、下一步该查什么、需要哪些权限或人工角色介入。

线上如何发现 Agent 正在误导用户？

可以监控低置信高采纳、人工纠错、建议执行后未改善、用户负反馈、事故复盘命中和高风险建议比例，并把这些样例加入回归评测。