Agent 工具调用链路的决策失效：从误触发到分层治理的工程复盘

故障现象

2026 年 3 月，某内部智能运维平台上线 Agent 工具调用能力后，出现一类典型故障：用户提问“帮我查一下昨天晚高峰期间 A 集群的 CPU 使用率”，Agent 未调用监控查询工具，而是直接生成一段看似合理但完全错误的文本回复，如“A 集群 CPU 使用率为 72%，处于正常范围”。该回复未附带数据来源、时间戳或查询条件，用户无法验证其真实性，导致后续操作决策失误。

此类问题并非偶发，在两周内累计触发 17 次，涉及监控查询、日志检索、配置变更三类工具。更严重的是，系统未记录“未调用工具”的决策过程，运维侧长期处于盲区，直到用户反馈才暴露问题。

业务目标与架构分层

该系统的核心目标是：在用户自然语言请求下，Agent 能准确判断是否需要调用外部工具，并确保调用链路可靠执行。为此，架构被拆分为四层：

1. 意图识别层：解析用户输入，提取关键实体（如“A 集群”、“昨天晚高峰”）和动作类型（查询、变更、巡检）。
2. 决策层：基于规则与模型评分，判断是否调用工具、调用哪个工具、传递哪些参数。
3. 执行层：通过 MCP 协议与后端工具服务通信，处理超时、重试、结果格式化。
4. 反馈层：将工具返回结果注入 LLM 上下文，生成最终回复，并记录决策日志。

理想状态下，链路应严格遵循“识别 → 决策 → 执行 → 反馈”流程。但实际运行中，决策层频繁跳过执行层，直接生成幻觉答案。

链路状态与问题拆解

通过日志审计与流量回放，发现三类典型失效模式：

• 模式一：参数模糊导致决策回避
  用户输入“查一下 A 集群的负载”，未明确时间范围。决策层因“缺少必要参数”而放弃调用，转而依赖 LLM 内部知识生成估算值。

• 模式二：工具置信度阈值僵化
  系统设定“仅当工具匹配度 > 0.8 时才调用”，但监控查询工具的匹配度常落在 0.75–0.79 区间，被错误过滤。

• 模式三：上下文记忆干扰决策
  用户连续提问时，Agent 误将前次工具结果作为当前依据，未重新触发查询，导致数据过期。

进一步分析发现，决策层依赖单一评分模型，缺乏对“不确定性”的显式处理机制。当输入模糊或工具匹配度不高时，系统默认选择“生成回答”而非“请求澄清”或“强制调用兜底工具”。

核心原因：决策机制缺乏分层与兜底

根本问题不在于模型能力不足，而在于工程层面对“何时调用工具”的决策逻辑设计粗糙。具体表现为：

1. 无显式不确定性处理：系统未定义“输入模糊”或“工具匹配度低”时的 fallback 策略，默认行为是生成回答，而非报错或澄清。
2. 阈值静态化：工具调用阈值固定为 0.8，未根据工具类型、用户历史行为或上下文风险动态调整。
3. 缺乏决策可观测性：未记录“未调用工具”的原因（如参数缺失、阈值未达、模型拒绝），导致故障难以归因。
4. 反馈闭环断裂：用户未对错误回答提供负反馈，系统无法学习修正决策偏差。

这些问题在测试环境中难以暴露，因测试用例通常构造完整输入，而生产环境中用户表达高度自由，模糊请求占比超过 40%。

实现方案：构建分层决策与兜底机制

1. 引入三级决策策略

将工具调用决策拆分为三级：

• 强触发：输入包含明确工具关键词（如“查监控”、“查日志”）且参数完整，强制调用对应工具。
• 弱触发：输入模糊但可推测意图（如“A 集群怎么样”），触发澄清流程：“您想查看 A 集群的哪项指标？CPU、内存还是网络？”
• 兜底调用：弱触发未获响应，或匹配度 > 0.7 但 < 0.8，自动调用通用查询工具（如“集群状态概览”），返回结构化数据供 LLM 引用。

2. 动态阈值调整

根据工具类型设置差异化阈值：

• 高风险工具（如配置变更）：阈值提升至 0.85，避免误操作。
• 只读查询工具（如监控、日志）：阈值降至 0.65，提升调用覆盖率。
• 结合用户历史行为：若用户过去 7 天频繁调用某工具，则其匹配度权重 +0.1。

3. 增强决策可观测性

在决策层新增四类日志：

• decision_type：强触发 / 弱触发 / 兜底调用 / 拒绝调用
• rejection_reason：参数缺失 / 阈值未达 / 模型拒绝 / 用户取消
• tool_confidence：原始匹配度与调整后值
• user_clarification：澄清问题内容与用户响应

日志接入统一监控平台，设置告警规则：当“拒绝调用”率 > 15% 或“兜底调用”率 > 30% 时触发巡检。

4. 构建反馈闭环

在 UI 层增加“此回答是否准确？”按钮，用户点击“否”时：

• 记录负反馈至训练集
• 自动重放该请求，强制调用工具并对比结果
• 若工具结果与 LLM 回答差异 > 20%，标记为“幻觉案例”，用于后续模型微调

风险与边界

• 性能开销：澄清流程增加交互轮次，可能影响用户体验。需设置超时机制（如 30 秒无响应则降级为兜底调用）。
• 工具覆盖不全：通用查询工具无法覆盖所有场景，需定期评估工具集完整性，补充高频未覆盖意图。
• 用户教育成本：部分用户习惯直接提问，需通过引导文案（如“告诉我更多细节，我能查得更准”）培养交互习惯。
• 模型偏差放大：若 LLM 在澄清问题中引导错误方向（如将“查 CPU”误导向“查内存”），需引入澄清结果校验机制。

落地建议

1. 优先实现决策日志与监控：即使不改动决策逻辑，先记录“未调用工具”的原因，可快速定位高频失效场景。
2. 分阶段上线兜底策略：先对只读工具开放兜底调用，验证稳定性后再扩展至写操作。
3. 建立工具调用健康度指标：定义“工具调用率”、“澄清成功率”、“幻觉检出率”三项核心指标，纳入系统 SLO。
4. 定期进行模糊输入压力测试：构造 100+ 类模糊请求（如省略时间、模糊实体、口语化表达），验证决策鲁棒性。

技术补丁包

1. 三级决策策略实现 原理：基于输入完整性与工具匹配度划分决策层级，强触发强制调用，弱触发引导澄清，兜底调用保障最低信息量。 设计动机：解决模糊输入下系统默认生成幻觉的问题，提升工具调用覆盖率。 边界条件：兜底调用仅适用于只读操作，写操作必须强触发或人工确认。 落地建议：在决策层新增DecisionRouter模块，集成规则引擎与模型评分，输出决策类型与执行指令。

2. 动态阈值调整机制 原理：根据工具风险等级、用户历史行为、上下文紧急度动态调整调用阈值。 设计动机：避免静态阈值导致高价值工具被过滤或低风险工具过度调用。 边界条件：高风险工具阈值不得低于 0.8，用户行为权重需设置上限（如 +0.15）防止偏差放大。 落地建议：在工具注册时标注risk_level字段，决策层读取用户画像服务获取历史调用频次。

3. 决策可观测性增强 原理：记录决策全过程关键节点，包括触发类型、拒绝原因、置信度变化。 设计动机：提供故障排查与模型优化的数据基础，实现从“黑盒决策”到“白盒治理”的转变。 边界条件：日志需脱敏处理用户输入，避免泄露敏感信息；日志量较大时需采样存储。 落地建议：定义ToolDecisionLog结构体，通过 APM 系统上报至监控平台，设置聚合看板。

4. 用户反馈闭环构建 原理：将用户对回答准确性的评价转化为训练数据与系统调优信号。 设计动机：打破“生成-幻觉-无反馈”的恶性循环，实现系统自进化。 边界条件：负反馈需人工审核后再用于训练，避免恶意点击污染数据。 落地建议：在回复卡片添加反馈按钮，后端实现FeedbackCollector服务，定期导出负样本至标注平台。

5. 模糊输入压力测试框架 原理：自动化生成涵盖省略、歧义、口语化等场景的测试用例，验证决策链路健壮性。 设计动机：提前暴露生产环境中因表达多样性导致的决策失效。 边界条件：测试用例需覆盖业务核心场景，避免过度泛化；测试频率建议每周一次。 落地建议：构建FuzzyInputGenerator工具，集成常见模糊模式模板，输出测试报告并关联故障工单。

总结

Agent 工具调用的核心挑战不在于“能否调用”，而在于“何时调用”的决策质量。本次故障暴露了工程层面在决策机制、可观测性与反馈闭环上的系统性缺失。通过引入分层决策策略、动态阈值、增强日志与用户反馈，不仅修复了当前问题，更构建了面向长期演进的治理框架。未来需持续优化工具覆盖度与决策模型，但首要任务是建立“决策可解释、失败可追溯、改进可闭环”的工程基础。