考察点
这道题出自腾讯混元 AI 产品经理实习二面,是技术理解+工程协作的复合题。Agent 系统的失败和传统软件不同:链路长、每步有随机性、错误会沿链路放大——第一步理解错意图,后面五步做得再对也是白做。面试官想看的是你有没有在真实项目里排查过这类问题:能不能说出「先让每一步可观测,再按失败特征分类,最后倒推根因」的方法论,而不是笼统地说「看日志」。这题也隐含考察产品经理和算法的协作界面——归因清楚了,才知道这个 bug 该提给谁。追问一般往「日志具体记什么」「各类问题的占比经验」「能不能自动归因」方向走。
参考答案
归因的前提:链路上每一步都可观测
先说一个大多数 Agent 项目的通病:只在最终结果失败时报警,中间过程是黑盒,出了问题只能回放整个对话瞎猜。我的做法是在设计阶段就要求每个节点输出结构化 trace:这一步的输入、模型的原始输出、解析后的结构化结果、调用了哪个工具、工具返回的状态和数据、耗时、以及这一步的「决策依据」(模型为什么选这个工具,如果有 reasoning 的话)。
有了这个 trace,归因就从「猜」变成「查」。这里产品经理要推动的事是把 trace 做成调试界面,而不是埋在服务器日志里——bad case 复盘时,运营和标注同学也得能看懂,不能每次都麻烦工程师捞日志。
四类问题的典型特征
归因时我按失败模式往四类上套:
Prompt 问题:特征是「模型能力够,但被带偏了」。表现为输出格式偶发不合规、指令被部分忽略(让输出 JSON 却夹带解释文字)、few-shot 示例被机械模仿。验证方法很直接:换个表达方式或补充约束重跑同一条 case,修好了就是 prompt 问题。这类修复成本最低,通常半天能上线。
模型能力问题:特征是「换什么 prompt 都不行」。复杂推理步骤多了就丢条件、长上下文里找不到已经给出的信息、领域专业知识张口就来但全是错的。验证方法是把 case 拿去问更强的模型(比如换个旗舰模型重跑),如果强模型能做对而当前模型稳定做错,就是能力边界,解法要么是路由到更强模型,要么是拆小任务,要么承认这个场景模型还接不住、产品上做降级。
工具问题:特征最干净——模型决策是对的,坏在执行。API 超时、返回字段缺了、返回了脏数据(空结果、错误码)、权限不足。看 trace 里工具调用的返回码和数据就能定位。这类问题占比往往比大家预想的高,我见过的项目里能占失败的三到四成,因为外部依赖的稳定性从来不是 Agent 团队能控制的。
逻辑编排问题:特征是每一步单看都对,连起来是错的。该循环的地方只跑了一次、分支条件覆盖了大部分情况但漏了边界、状态没传递(第二步要用第一步的结果,结果没存)。这类问题要靠端到端的 case 回放才能发现,单步测试测不出来。
归因流程:从最后一个错往前倒推
实际操作时我的顺序是:先看最终结果错在哪,找到链条上第一个偏离预期的节点——注意是「第一个」不是「最后一个」,Agent 的错误会放大,最后一个节点的错常常是前面传的脏数据导致的。在第一个出错节点上做三分判断:工具返回正常吗(不正常→工具问题)?返回正常,那模型的输出和输入匹配吗(指令被遵守了吗,没遵守→先怀疑 prompt)?prompt 改了几版都不行→模型能力问题。如果每个单点都对、连起来不对,就是编排问题。
归因完别急着修,先统计:把一段时间内(比如两周)的 bad case 全归因一遍,看分布。修复优先级按「占比 × 修复成本」排——工具超时占 35% 就加重试和降级,prompt 问题占 20% 就系统性地重写 prompt 加评测集防回归。凭感觉修最大的那个 case,是 Agent 调试最常见的浪费。
防回归:归因的终点是进评测集
每一个归因过的 bad case,修复后都要进回归评测集。Agent 系统最大的工程风险是「修了 A 坏了 B」——prompt 改一个字,原来好的 case 可能劣化。我们的纪律是:任何 prompt、工具描述、编排逻辑的变更,上线前必须过一遍全量回归集,核心指标(任务成功率、工具调用准确率)不降才放行。这套机制建起来之后,归因数据还有个副产品:哪类问题占比长期居高不下,就是下一轮模型迭代或架构升级的需求输入,产品经理拿着这个数据去和算法谈,比空谈「体验不好」有力得多。
可能的追问
- trace 具体记哪些字段,全记会不会成本太高? 答:核心字段是每步的输入摘要、原始输出、工具名+参数+返回码、耗时;全量 trace 只在灰度和采样流量(比如 5%)里记详细版,线上记轻量版,出错的会话自动升级成详细记录。
- 各类问题的占比有没有经验值? 答:项目早期工具和编排问题占大头(能到五六成),稳定期 prompt 和模型能力问题占比升上来;如果工具问题长期超过三成,说明依赖治理欠账太多。
- 能不能用模型自动归因? 答:可以半自动——用一个分类模型按 trace 特征做初判(工具返回码异常这类硬特征很好判),但 prompt 和能力问题的区分目前还得靠人复核,自动归因的准确率本身要监控,别再造一个不靠谱的黑盒。
- 归因清楚但短期修不了(比如模型能力边界)怎么办? 答:产品兜底——这个场景降级到人工、或缩小任务范围、或在交互上管理预期(「这个问题我还在学习」)。承认边界并设计好退路,比硬撑着一个 60 分的能力强。