真实面经题目 · 原创解析
这题考的是 Agent 工具调用失败后的分层定位能力。好的回答不能只说看日志，而要把一次请求拆成意图识别、工具检索与选择、参数生成、执行前校验、工具服务调用、结果解释几个 span，并让每一层都有输入、输出、置信度、候选集、错误码、耗时和重试信息。定位时先判断用户意图是否被理解错，再看工具候选和最终选择是否合理，然后检查参数 schema、枚举、时间范围、权限上下文等是否正确，最后才归因到工具服务的网络、鉴权、超时、限流或业务错误。
我会把工具调用失败当成一条可回放的 trace 来分析，而不是只看最终报错。一次 Agent 请求至少要记录 root trace、用户输入、对话上下文摘要、意图识别结果、候选工具列表、最终工具选择理由、参数生成 JSON、schema 校验结果、工具请求、工具响应、重试和降级链路。定位时我会按四层排除。第一层是意图识别：看用户原始问题和模型识别出的 intent 是否一致，是否把查询、写入、取消、总结这类动作混淆，是否因为历史上下文污染导致目标对象错了。第二层是工具选择：看 top-k 候选工具、各工具描述、选择分数和拒选理由，判断是工具 registry 描述不清、retrieval 召回错、权限过滤错，还是 planner 选了语义相近但能力边界不同的工具。第三层是参数生成：看模型生成的参数是否符合 schema，必填字段、类型、枚举、单位、时区、ID 解析、用户权限和幂等键是否正确；很多失败不是工具坏了，而是参数里传了自然语言、过期 ID 或错误时间范围。第四层才是工具服务本身：看 HTTP/RPC 状态码、业务错误码、超时、限流、鉴权、依赖异常、服务日志和链路追踪。如果失败发生在工具服务内，就要把 agent trace 的 tool_call_id 传到后端日志和分布式 trace，关联具体实例、下游依赖和错误栈。最后要做闭环：把错误归类成 intent_error、tool_selection_error、argument_error、tool_service_error、policy_error、postprocess_error，并把典型样本加入回归集，用离线评测和线上告警验证同类问题不再重复。
每次 Agent 请求都要有稳定的 trace_id，下面挂意图识别、规划、工具检索、工具选择、参数生成、参数校验、工具执行、结果解释这些 span。每个 span 记录输入、输出、模型版本、prompt 版本、耗时、token、候选集、置信度、错误码和重试信息。没有这种结构，最终只能看到工具调用失败，无法知道失败是在哪一层被引入的。
先对比用户原话、历史上下文摘要和识别出的 intent。典型错误包括把查询识别成修改，把取消识别成创建，把当前轮目标对象继承成上一轮对象，或者忽略否定词和条件约束。若 intent 错了，后续工具和参数即使形式正确也会做错事，因此这是第一优先级。
工具选择问题要看候选工具 top-k，而不只看最终工具。需要记录每个候选的名称、能力描述、匹配分数、权限过滤结果和最终选择理由。如果正确工具根本没有进入候选集，多半是工具描述、索引召回或权限过滤问题；如果正确工具在候选里但没选中，问题更可能在 planner 的选择策略或工具边界描述。
参数生成是模型把自然语言转成结构化请求，参数校验是系统判断请求是否符合 schema 与业务前置条件。trace 里要同时保存原始生成参数、规范化后参数和校验错误。常见问题是类型错、枚举错、单位错、时区错、ID 未解析、必填字段缺失、数组为空、权限主体错或幂等键缺失。
工具服务返回失败不等于服务掉线。要区分网络超时、连接失败、5xx、限流、鉴权失败、参数非法、业务状态冲突、资源不存在和下游依赖异常。工程上最好把 HTTP/RPC 状态码、业务错误码、错误消息、重试次数和服务端 trace_id 一起记录，避免把可修复的参数问题误判成平台稳定性问题。
tool_call_id、trace_id、user_id、request_id 要从 Agent 传到工具网关和具体服务。这样在 Agent 平台看到失败后，可以直接跳到服务日志、APM trace 和指标面板，定位是某个实例超时、某个依赖失败、某个租户被限流，还是所有请求都受影响。没有关联 ID，跨系统排查会退化成按时间猜测。
每个失败样本应该归到 intent_error、tool_selection_error、argument_error、tool_service_error、policy_error、postprocess_error 等稳定类别，并记录证据。分类要能驱动动作：意图错改 prompt 或训练集，工具错改 registry 和选择策略，参数错加强 schema 和校验，服务错进入后端稳定性治理。
线上 trace 中的典型失败要脱敏后进入回归集，用固定模型版本和工具 mock 做离线回放，再用真实工具沙箱做集成回放。修复后观察同类错误率、参数校验失败率、工具超时率、重试成功率和人工接管率，证明问题真的被修复，而不是只修了一个样本。
先看模型生成参数是否违反已有 schema，比如类型、枚举、必填字段或格式明显错误；这类通常是参数生成错或校验提示不够强。如果模型生成的是用户自然表达中合理存在的字段，但 schema 没有表达清楚单位、时区、默认值、ID 解析规则或互斥字段，那就是工具契约设计问题。还要看同类错误是否集中在某个字段，集中出现通常说明 schema 描述或示例不足。
先确认工具 registry 是否注册了正确工具，再看工具描述、标签、embedding 索引、权限过滤和租户可见性。若用户意图正确但正确工具未召回，多半是工具描述和检索特征不够；若正确工具被权限过滤掉，要检查用户身份、角色、资源范围和环境配置；若 registry 本身缺失，则是发布或配置问题。
要关注上下文构造和指代消解。trace 里应保存本轮用户输入、被注入的历史摘要、被引用的实体、上一轮工具结果和最终解析出的目标对象。很多多轮错误不是工具选择能力差，而是系统把上一轮的订单、用户、时间或操作意图错误继承到了当前轮。
每次重试都应作为独立 span，记录重试原因、间隔、幂等键、请求参数摘要、返回码和最终是否成功。对于写操作，要明确是否使用幂等键，避免服务第一次实际成功但响应超时，Agent 重试后造成重复写入。
可以按错误类别和工具维度建立指标，例如 intent_error_rate、tool_selection_error_rate、argument_validation_failed_rate、tool_timeout_rate、tool_5xx_rate 和 manual_takeover_rate。告警要区分模型侧错误和服务侧错误，否则同一个 tool failed 指标会让模型团队和后端团队都难以行动。
