设计题 06：Agent 的失败排查与可观测性

权重：★★　形式：45 分钟系统设计轮
素材来源：Own — QueWI 的网关日志与链路追踪、意图识别线上误判回流（「埋点字段要能对上训练需要的字段」这条约束）
相关知识点：06-agent-infra/observability.md、05-agent-evaluation/agent-eval.md、llm-as-judge.md、06-agent-infra/gateway-routing.md

1. 题干#

「我们做了一个多步 agent，demo 里跑得挺好，上线以后隔三差五就有用户说它做错了事、或者卡在那里不动。我们看日志也看不出什么，而且这些失败复现不了。你帮我们搞清楚它到底哪里坏了。」

注意这个题干有多模糊：没说多频繁、没说哪一步、没说「做错」具体是什么、没说任务有没有客观终态、也没说「复现不了」到底卡在哪里。这不是题干写得差，这是刻意的。 面试官在看你会不会把「失败」和「复现不了」这两个糊在一起的词拆开。

2. 第一步：澄清（这一轮最重要的动作）#

绝对不要听完就开始讲 trace 和 span。开场第一句应该是：

「在搭可观测性之前我想先确认几件事 —— 因为这几个答案会决定记什么、记多久、以及这套东西最后能不能真的定位问题。」

必问清单（按对方案的影响排序）#

面试技巧：先问 1、2、3。第 3 问是这题的题眼 —— 用户说「复现不了」，但真正缺的往往是归因：就算让他复现一百次，他也不知道该看哪一步。

3. 参考架构#

假设澄清后得到：任务有客观终态、失败集中在工具调用、有 PII 合规要求、需要工程师排障 + 训练回流两个消费者。

┌─ 埋点 + 采集 ─────────────────────────────────────────┐
│  agent 循环里每一步自动开 span（不靠人手写），异步上报    │
│  LLM / 工具 / 检索 / 路由 / 判断 / 人工介入 六类 span    │
│  PII 脱敏 · 分级采样（失败全记 / 成功按比例）            │
│  大 payload 截断或外链对象存储（trace 只留引用）          │
└───────────────────────────────────────────────────────┘
                        ↓
┌─ 存储 ────────────────────────────────────────────────┐
│  Session（多轮容器）→ Trace（一次运行）→ Span（一步）    │
│  版本 tag：模型 / prompt / 工具 schema / 代码版本        │
└───────────────────────────────────────────────────────┘
                        ↓
┌─ 使用 ────────────────────────────────────────────────┐
│  ① 排障：按 session / user / 时间 查某一次运行           │
│  ② 归因：从终态往回找第一个偏离正常的分叉                │
│  ③ 聚合：单步成功率 / 步数 / token / 成本 / 无效调用率   │
│  ④ 回放：用历史输入重跑新版本 → 回归评测                 │
│  ⑤ 回流：失败 case → 评测集 / 训练数据                   │
└───────────────────────────────────────────────────────┘

画图时要讲的三个点：

• ① 排障和⑤回流是同一套数据，但要在一开始就一起设计。 最常见的失败是「上线三个月后想捞路由误判 case，才发现 trace 里根本没记路由判定结果」。埋点设计要回头问一句「这些字段将来能用来干什么」 —— 没有这一问，数据存了也白存。
• ② 归因和聚合是两种读法，缺一不可。 单次运行要能整条拉出来给人看（纵向），全局要能按步骤聚合成功率（横向）。只有纵向的是调试工具，只有横向的是仪表盘。
• ④ 回放依赖「版本 tag」。 trace 里如果没有模型版本、prompt 版本、工具 schema 版本，回放就只能测出「环境变了」，测不出「我的改动是好是坏」。

4. 关键决策与权衡#

4.1 为什么日志不够（这题必须答得具体）#

一句话：日志回答「系统做了什么」，trace 回答「这一次为什么失败」。

4.2 每一步记什么#

按 span 类型分（面试要能当场列出来）：

必须有的版本 tag：模型版本、prompt 版本、工具 schema 版本、代码版本。少了任何一个，「改完之后是变好还是变差」这个问题就无法回答。

要主动提出的工程约束（这些说出来就比「我会埋点」高一层）：

• PII 与合规：prompt 里常有用户隐私 —— 「全都记下来」和「什么都不记」都是错的。
• 采样：分级 —— 失败与异常全记，成功按比例采样。
• 大 payload：长文档、大返回值要截断或外链对象存储，trace 里只留引用。
• 关联：trace 必须能关联到 user id、session id、版本号，否则无法做对比与排障。
• 开销：埋点本身要异步、批量，不能在关键路径上做重活。

4.3 怎么把失败归因到某一步（本题核心）#

第一步：没有参照就没有归因。 先定义「正常」，三条参照按可靠性排序：① 环境终态断言（最可靠）—— 跑完后直接检查环境状态（数据库那行改对了没、文件生成了没、接口返回对不对），它与路径无关，因此不会把「走了另一条合法路径」误判成失败；② 单步期望状态 —— 给定正确的前序状态，这一步的合理输出集合是什么（工具选对了吗？参数填对了吗？检索召回了该召回的 chunk 吗？）；③ 与成功运行的共同路径对比，找出第一个分叉点（first divergence）。

第二步：从终态往回找第一个偏离正常的分叉。 为什么往回找 —— 因为错误会传播：第 1 步就偏了，第 7 步才崩，最后报的错通常不是根因。

第三步：按失败类型分层用不同手段（可靠性递减，能自动化的优先）：

第四步：用单步粒度指标做 credit assignment（从 trace 里算出来，也是回流评测的依据）：工具选择准确率、参数/字段正确率、无效调用率、冗余与循环调用、错误恢复率（工具报错后能否自行纠正）、该弃权/该提问时是否正确收手。

误差累积解释了为什么「长任务失败率高」不能归因到某一步：若每步独立地有概率 p 做对，n 步全对的概率量级是 p^n —— 单步 95% 在 10 步任务上约剩 60%，在 30 步任务上会崩到很低。所以正确的问法不是「哪一次崩在哪」，而是「哪一步的单步可靠性最低」。

必须主动说出的边界（这一节最能体现诚实）：① 不是所有失败都能归因到单一步骤 —— 有些是多个近似正确的步骤组合出的偶发失败，没有单一根因；② 必须把「模型失败」和「环境失败」分开 —— 网络抖动、第三方 API 限流、工具本身有 bug 都会污染结论，否则你会去优化一个不存在的模型问题（工具本身的单测与契约测试应当先于 agent 评测）；③ judge 做的语义归因是代理指标不是 ground truth，需要校准，且部分维度覆盖不到。

4.4 PII 与留存（FDE 必备意识）#

trace 里必然包含用户输入和工具返回值，也就必然包含 PII。做法：

• 脱敏或引用式存储：正文放受控存储，trace 里只留引用与结构化摘要。
• 分级采样：失败全记（高信息量、低频），成功按比例（高频、低信息量）。
• 留存期限与访问审计：明确谁能看、看多久。
• 跨境合规：香港客户要问清数据能不能出境、能不能交给第三方 SaaS —— 数据合规往往是一票否决项，优先于功能选型。 用词也要准确：区分「脱敏」（可逆）和「匿名化」（不可逆），不要声称做过匿名化除非确实不可逆。

4.5 什么不该建（资深信号）#

• 不要一开始自建全套平台（存储、查询、可视化）。先用现成 SDK + 简单的按 trace 查询，验证「真的能定位问题」再投入。
• 不要全量原始存储、也不要为了「零缺失」而不采样。 存储成本随流量线性增长，叠加合规风险 —— 成本和合规双输。
• 不要在关键路径上做同步埋点重活。 观测不能拖慢 agent，否则用户会为了可观测性付出体验代价。
• 不要把用户反馈率当质量指标。 反馈有严重的选择偏置（点踩的人更有表达欲，沉默的大多数不反馈）。
• 不要只记最终输出。 只记结果，等于放弃了归因、回放和评测三种用途。
• 但也不要「先随便记，以后再说」。 埋点字段与将来用途脱节是最常见的断点 —— 上线后才想要「路由误判 case」，却发现没记判定结果与置信度。

4.6 闭环：从生产失败回到评测与训练#

线上 trace 采集（每步输入输出 + 结果 + 反馈）
   ↓ 失败聚类与归因（路由 / 检索 / 工具 / 生成 / 用户输入本身）
   ↓ 人工标注 / 构造样本（评测样本 + 训练样本 + 偏好对）
   ↓ 改进 prompt / 工具描述 / 换模型 / SFT 补能力 / DPO 补偏好
   ↓ 回归评测（新版本在 golden set 上不能退化）
   ↓ 灰度上线 → 继续采集 trace

这个闭环最容易断的四环：

1. 埋点与训练需求脱节 —— 字段没记，case 捞不出来（见 4.5 最后一条）。
2. 失败没有分类 —— 一堆 case 无从下手，必须先能按系统边界归类。
3. 闭环不闭合 —— 只采集不回流（白存），或回流了但不做回归评测（等于拿线上做实验）。
4. 合规与分布偏置 —— 生产数据用于评测/训练要过脱敏与授权；而且线上暴露的问题只是全部问题的一个子集，长尾样本少，直接当评测集会带来偏置。

5. 容量与成本直觉#

面试官常问「记这么多要多少存储」。不要求精算，但要有量级感觉：

• trace 体积 ≈ 每次运行的 span 数 × 每 span 的 payload。 其中 payload 是主项 —— 长的工具返回和检索上下文会让单条 trace 大得离谱，所以大 payload 必须外链，trace 里只留引用与摘要。
• 采样是必须的，不是优化选项。 失败全记 + 成功按比例，能砍掉绝大部分存储同时保住信号。存储还要分层：近期数据可全量可查，老数据降级为聚合或低比例采样。
• 回放的成本最容易被低估。 回放一次 agent 任务 = 十几次模型调用 + 十几次工具调用 + 一个可重置的沙箱，所以回放要抽样做，选有代表性的失败/成功 case 子集，不要全量重跑。
• 归因是持续的人工作业。 给失败 case 分类要花人；优先级按「该类失败的出现频率 × 是否可自动判定」排 —— 先做高频且能自动判定的那一类。
• 一句面试话术：「可观测性的目标不是存得最全，而是能定位、能回流。」

6. 面试官会怎么往下挖#

第一层：澄清与动机#

• Q：你会先问什么？ ← 见第 2 节。核心是把「失败」和「复现不了」这两个模糊词拆开
• Q：日志为什么不够？ ← 见 4.1，要说 agent 的三个具体特性，不要笼统说「日志不好用」
• Q：为什么不先把所有 prompt 全量存下来，以后慢慢分析？ ← 成本与合规双输（见 4.5 与 5）；正确做法是分级采样 + 预先设计字段。价值侧也承认完整数据最有分析余地，所以失败 case 全量保留

第二层：技术细节#

• Q：trace 里你会记哪些字段？ ← 见 4.2 的表格，并且要主动带上版本 tag 与工程约束
• Q：怎么确定是哪一步坏的？ ← 见 4.3：先有参照（终态断言 / 单步期望状态），再从终态往回找第一个偏离的分叉；然后用单步指标做 credit assignment
• Q：过程对不对怎么判？ ← 优先环境终态断言（与路径无关）；其次只比对关键约束（是否调用了必需工具、是否包含必需参数、是否触发危险动作）；不要做完整轨迹的严格匹配 —— 正确路径不唯一，会产生大量假阴性
• Q：怎么区分「模型失败」和「环境失败」？ ← 在 span 上打错误类型标签，把环境类单列统计，不让它污染模型结论。前提是工具本身先有单测与契约测试 —— 工具返回不稳定时 agent 评测毫无意义

第三层：工程与生产#

• Q：失败率百分之几算高？ ← 信息不够。要分桶（高频路径上的失败远比长尾严重）、分类（哪一类失败）、看趋势而非绝对值。agent 还要看 pass^k 而不是单次成功率 —— 一个 pass@10 很高但 pass^10 很低的 agent，在用户手里就是不可用的
• Q：怎么知道新版本没有变差？ ← 用历史 trace 回放做回归评测，按版本 tag 聚合线上指标做对比。注意回放的环境要与当时一致，否则测出来的是环境差异而不是模型差异
• Q：用户投诉了某一次对话，你怎么查？ ← trace 必须能按 user / session / 时间检索到完整的那一次运行 —— 这是所有归因的前提，也是为什么埋点一开始就要关联会话与用户 id
• Q：怎么让埋点不影响性能？ ← 异步、批量、采样、不在关键路径做重活；埋点 SDK 自己失败要能降级，不能因为观测挂了导致业务挂

第四层：反思与边界#

• Q：这套东西什么时候会不够用？ ← ① 无法在沙箱重建的环境（真实世界副作用、外部系统状态已变）；② 非确定性导致同一输入本来就不可复现；③ 「正确路径不唯一」让语义归因天然带噪声；④ 无法断言终态的主观任务只能靠 judge + 人工
• Q：客户说「任何用户内容都不允许落盘」，你怎么做可观测性？ ← 保留结构化元数据（模型、token、耗时、工具名、成败、错误类型、路由决策），内容用引用式存储或即时匿名化；可以留即时抽样的匿名样本用于评测，但会牺牲一部分语义归因能力（看不到「它答错了什么」）。把这个代价明确说给客户，让他选 —— 这是 FDE 该做的
• Q：如果只能做一件事，你做哪件？ ← 把失败 case 全量留档、并能按 session 查到完整 trace。 因为失败是稀缺且高信息量的信号，成功 case 可以采样甚至不记；而「能不能定位一次具体失败」是整套可观测性的价值兑现点

7. 自测#

1. 为什么 agent 的可观测性必须用 trace 而不是日志？

2. 一次运行失败了，你怎么确定是哪一步坏的？

3. trace 里哪些字段是「上线时想不到、以后一定会要」的？举两例并说明后果。

4. 客户要求「任何用户内容都不能落盘」，你怎么设计可观测性？牺牲了什么？

5. 怎么把线上失败变成评测集和训练数据？这个闭环最容易断在哪？