考察点
这道题考的是系统性排障能力。很多人排查 agent 问题靠「拍脑袋改 prompt 试试」，面试官想看的是你能不能分层隔离变量：先定位问题发生在哪一层，再用可控实验验证假设。追问通常往「用什么工具拿 trace」「eval 集怎么搭」「线上线下表现不一致怎么查」走。
参考答案
先建立分层模型
Agent 的失败基本可以归因到四层：工具层，工具本身有 bug、返回格式不符合预期、超时或被限流；上下文层，指令模糊、关键信息没进上下文、工具描述有误导性；模型能力层，推理跟不上、指令遵循差、幻觉；流程设计层，架构问题，比如该拆的子任务没拆、单个 agent 挂了太多工具导致选择困难。这个分层不是理论洁癖，是因为不同层的修法完全不同——prompt 层的问题你换十个模型也没用，流程层的问题你改一百版 prompt 也只是碰运气。
第一步：拿到完整 trace
没有 trace 不谈调试。用 LangSmith、Langfuse 或者 OpenTelemetry 把每一次 run 的每步模型输入输出、工具调用的参数和返回、耗时、token 消耗全部落盘。拿到 bad case 之后，顺着 trace 找「第一个偏离预期的决策点」，而不是盯着最终输出倒推。我的经验是，八成的问题顺着 trace 看一遍就能定位到层，剩下两成才需要做实验。最常见的错误是看到最终答案错了就直接改系统提示——答案错往往是第三步的检索就歪了，你改的是第五步的 prompt。
分层验证
怀疑工具层，就把那一步的工具调用抠出来，用同样的参数直接调一遍。结果不对或超时，就是工具问题，和模型无关。这一步五分钟就能完成，永远最先做。
怀疑上下文层，去检查模型在那一步实际收到的完整消息列表——是你以为它收到的那些吗？实际踩过的坑包括：系统提示被截断策略裁掉了、检索结果根本没拼进去、历史消息里混入了上一个任务的残留内容、工具描述写得让模型误以为参数是另一个含义。验证方法是固定输入、只改 prompt 重放，看输出是否改善。
怀疑模型能力层，用同一个 prompt 换更强的模型重放。强模型能过、弱模型不过，说明摸到了能力边界，对策是在这个步骤路由到强模型，或者降低这一步的推理负担——把复杂判断拆成两步、给 few-shot 示例、让输出格式更简单。如果强模型也不过，那大概率不是模型问题，回头重查上下文层和流程层。
怀疑流程层，看 case 分布：如果多个 bad case 集中失败在同一个节点，而且换模型、改 prompt 都改善有限，基本就是架构问题。典型症状是一个 agent 挂着二十个工具，选错率居高不下——这时该做的是拆职责、加路由层，而不是继续在 prompt 里喊「请仔细选择工具」。
从 debug 到 eval
修完单个 case 不算完。把每个 bad case 收进回归集，攒上几十个典型场景就有了 eval 集：可以对中间步骤设检查点，用规则或 LLM-as-judge 打分——工具选对没有、检索结果够不够、最终答案是否满足 rubric。之后每次改 prompt、升模型、调流程，先跑 eval 再上线，防止按下葫芦浮起瓢。debug 解决点的问题，eval 解决面的问题，两个都要有。
一个实战例子
我们一个搜索 agent 经常答非所问。trace 一看，它第一轮检索直接拿用户原话当 query，里面全是口语表达，专有名词一个没命中，检索结果为空，然后模型开始凭印象编。这是流程设计问题——缺 query 改写步骤。加了一个 rewrite 节点把口语查询改写成检索友好的形式，这一类 case 直接消失。教训就一条：找到第一个分叉点，别在下游打补丁。
可能的追问
- 线上和离线表现不一致怎么查？ 重点查上下文差异：线上有历史对话、用户画像注入、实时变化的检索结果。拿线上的真实输入完整重放到离线环境，差异自然会暴露。
- 模型升级后效果反而退化怎么办？ prompt 是针对旧模型的行为特点调出来的，新模型的指令遵循方式变了，旧 prompt 里的「哄模型」话术可能起反作用。用 eval 集灰度验证，针对新模型重新调 prompt 再全量。
- LLM-as-judge 可信吗？ 评判标准要写成具体 rubric 而不是「好不好」，上线前先抽样和人工标注对一致性，一致率达标才能当回归信号，别拿 judge 当绝对真理。