跳到主内容Agent 线上答错一次，怎样用 Trace 和 Replay 定位到底哪一步坏了 · AlgoMooc面试题 · Agent 项目面试题
Agent 线上答错一次，怎样用 Trace 和 Replay 定位到底哪一步坏了
一条 Trace 应该怎样建模
根任务至少有 trace_id、任务类型、用户与租户的受控标识、开始结束状态、入口版本和最终结果引用。
每个 span 有 span_id、parent_span_id、节点类型、开始结束时间、状态、错误分类、输入输出引用、配置版本和资源摘要。并行工具调用通过同一父 span 关联，重试使用 attempt 并保留首次失败。
State 更新作为一等事件，记录读取版本、写入版本、变更字段摘要和冲突结果。否则工具正确但状态合并错误时无法定位。
工件使用稳定 ID、版本与哈希。Trace 不必复制整篇网页、代码和报告，只记录受控引用。必要时根据权限访问原始工件。
人工确认也进入轨迹：请求了什么批准，用户看到什么摘要，批准令牌对应哪个动作，最终是否执行。
模型调用应该记录什么
记录模型供应或路由标识、模型版本、Prompt 模板版本、工具集合版本、结构化输入摘要、上下文长度、输出状态、解析结果、Token 使用和耗时分解。
不要只保存最终文本。若模型输出 tool call，需要记录工具名、参数摘要、调用 ID、解析与 Schema 校验结果。若模型建议停止，需要记录结构化完成理由和随后验证器结果。
原始 Prompt 可能含敏感数据，日志应支持脱敏、字段级访问和保留期限。可以保存内容哈希、模板、变量清单和受控快照，而不是把全部用户数据放进普通日志系统。
也不应把隐藏的原始思维过程作为可观测性的前提。排障真正需要的是可验证的计划、动作、Observation、决策理由摘要和状态变化。结构化规划比不可控的自由推理文本更适合作为工程证据。
工具调用应该记录什么
工具 span 记录工具 Registry 版本、调用 ID、参数摘要、权限决策、幂等键、开始结束、返回状态、重试性、结果工件和错误类型。
参数可能包含密钥和个人信息，按字段脱敏。结果正文可能很大，保存哈希、Schema、大小、状态和工件引用。
需要区分调用成功、执行成功与业务成功。HTTP 200 只说明外层请求，工具可能返回空、部分结果或业务拒绝。Trace 保存三层状态，避免监控把“接口正常但任务没完成”算作成功。
重试不能覆盖第一次失败。保留每次 attempt 的输入差异、退避、备用工具与最终结果，才能判断恢复机制是否真实有效。
State 与上下文变化为什么必须记录
Agent 的下一步由当前 State 决定。只记录模型和工具，仍可能漏掉最关键的错误。
例如工具返回日期范围正确，但 reducer 合并时保留了旧字段；Checkpoint 恢复后重复执行已完成步骤；摘要压缩丢掉否定条件；记忆检索把另一个项目的历史注入上下文。
State event 应记录节点、前后版本、变更键、来源 span 和冲突处理。硬约束、计划、开放问题、工件和错误分别存，不把全部状态序列化到普通日志。
上下文构造记录使用了哪些消息、摘要、记忆和工件引用，以及它们的版本。这样可以回答“模型为什么看到了这条旧信息”。
每一层记录可定位字段，同时避免把所有敏感正文复制进日志。
Trace 怎样控制隐私与存储成本
全量记录所有正文既昂贵也危险。可以把元数据与内容分层：Trace 主体保存 ID、状态、版本、哈希和统计；敏感快照进入受控存储，按角色和事件需要访问。
参数和结果使用字段级脱敏。密钥永不记录，个人信息按用途最小化。对高风险工具保留必要审计，对普通成功请求可以按策略采样，但错误与关键边界样本优先保留。
采样不能破坏因果链。决定保留一个根任务时，其必要子 span 应完整；不能只留下工具失败却没有上游参数来源。
保留期限按数据类型不同。审计、调试快照和产品分析不是同一用途，不能都永久保存。用户删除、租户隔离和访问审计同样适用于 Trace。
成本指标本身也来自 Trace，但必须定义口径。Token、模型调用、工具费用、存储和计算是否都纳入，要写清楚。本文不提供任何真实线上成本数字。
Trace Schema 怎样兼容系统升级
可观测事件本身也需要版本。今天的工具结果只有 status，下个版本增加调用层、执行层和业务层状态；如果没有事件版本，旧回放器可能误读新字段。
每类事件可以有稳定公共字段和类型专属 payload。公共字段负责 trace、span、父节点、时间、状态、版本和引用，模型、工具、State 再扩展各自内容。消费者遇到未知可选字段时保持兼容，遇到无法理解的关键版本时明确拒绝回放。
Prompt、工具 Schema、状态机和解析器版本不能只写一个应用发布号。同一次发布里它们可能独立变化，排障需要知道真正影响行为的是哪一层。
迁移旧轨迹时不要伪造缺失字段。可以标记 unknown 或 unavailable，让评测排除无法公平比较的维度。把未知写成默认成功，会让历史回放产生虚假结论。
事件时钟也要谨慎。并行节点的墙钟时间可能交错，因果关系主要靠 parent、依赖和 State 版本，而不是仅按日志时间排序。
这套 Schema 是可观测协议，不是业务 State 的完整副本。只记录定位与回放所需信息，避免两套事实源长期漂移。
Replay 不等于原样重跑
模型有随机性，外部网页和 API 会变化，即使相同输入也未必得到同一输出。真正可用的回放至少分三种。
第一种是记录回放。复用历史模型输出和工具 Observation，只重跑状态机、解析、合并、验证和最终组装。它适合定位代码逻辑与状态错误，结果最可重复。
第二种是受控重放。固定 Prompt、模型路由、工具 Schema、随机配置和输入快照，重新调用模型或只读工具，比较与历史的差异。它验证问题是否可复现，但不能保证字面一致。
第三种是影子回放。把历史任务输入和工具结果交给新 Prompt、模型或状态机，在不影响用户的环境中运行，比较结果与轨迹。它适合版本回归。
每次回放要声明哪些部分使用历史工件，哪些重新执行。否则“修复后通过”可能只是外部数据变化。
副作用工具为什么不能在 Replay 中直接调用
发送消息、下单、修改数据库和发布内容如果在回放中再次执行，会造成重复副作用。
默认策略是用历史 Observation 或模拟器替代真实执行。回放验证 Agent 是否选择了正确动作和参数，不真正提交。
必须验证真实集成时，使用测试环境、专用账号和明确批准，并让工具支持 Dry-run 与幂等。即使有幂等，也不能把生产重放当常规调试手段。
回放框架应把工具分成纯读、外部变化、可模拟副作用和禁止回放几类。执行前由代码策略检查，不让模型决定“这次可以真的发”。
怎样从 Trace 找最早分歧点
先从用户可见失败定义期望。例如最终答案引用了错误年份。沿依赖反查：最终生成使用了哪条证据；证据来自哪个工具结果；工具参数的时间范围从哪次规划产生；规划读取了哪个 State 和上下文。
如果工具返回已错误，检查参数和外部服务。参数错，继续查意图解析或计划。工具结果正确但最终没用，检查 State 合并、上下文截断或生成忠实度。
修复应针对最早确定的错误层，而不是只在最终 Prompt 加一句“请更准确”。
对比一条成功轨迹和失败轨迹也很有用，但要控制任务和版本。查看第一处状态、路由、参数或 Observation 差异，再验证该差异是否导致后续失败。
根因结论必须通过回放或新测试样本验证。一次人工阅读得到的猜测，不等于稳定复现。
一个工具超时后答错的排障例子
用户问一个需要搜索和访问网页的问题，最终答案缺少关键来源。Trace 显示规划生成了正确子问题，搜索工具返回候选，访问工具第一次超时。
Agent 随后重试，但 State reducer 把第二次成功结果写入了新字段，而报告节点仍读取旧字段。最终答案使用搜索摘要，没有引用网页正文。
若只看工具成功率，会看到最终重试成功；只看最终答案，会以为模型不会引用。完整 Trace 才能看到首次超时、第二次成功、State 版本变化和报告节点读取路径。
记录回放复用两次工具 Observation，只重跑 reducer 与报告节点，稳定复现字段问题。修复后同一轨迹通过，再加入状态版本和重试成功样本做回归。
从用户失败反查依赖，找到最早错误，再用受控回放验证。
Trace 与 Replay 怎样用于版本发布
Prompt、模型、工具 Schema、状态机和记忆策略更新都可能改变行为。发布前从代表性轨迹库选择任务做影子回放，覆盖成功、失败、长任务、工具异常和高风险路径。
比较不能只看最终文本相似。要看任务完成、引用、工具选择、参数、循环、错误恢复、人工确认和资源使用。开放答案使用 rubric 与人工抽检，结构化动作使用规则。
新版本若修复一种 Badcase，却增加无效调用或跳过权限门禁，应被发现。关键安全断言设置硬失败，不能被综合分数抵消。
历史轨迹会过时。工具和业务规则变化后，需要标记适用版本和更新样本，避免回放只奖励旧行为。
怎样验收可观测系统
让规划选错工具、工具返回格式变化、State 写冲突、摘要丢约束、记忆越权、模型输出不可解析和最终答案忽略 Observation，验证 Trace 能定位首个失败层。
制造并行、重试和 Checkpoint 恢复，检查父子关系、attempt、版本和幂等凭证是否完整。
对同一轨迹执行记录回放、受控重放和影子回放，确认三种模式明确标记数据来源，副作用工具不会真实执行。
权限测试验证不同租户不能读取对方 Trace，敏感参数被脱敏，调试快照有审计和过期。
完整性测试检查采样后根任务与必要子 span 不断链。故障测试覆盖追踪服务不可用时业务如何降级，不能因为埋点失败阻塞全部请求，也不能悄悄丢失高风险审计。
能看见、能还原、能安全回放并能验证修复，才算完整。
面试官会怎样连续追问
追问一：有日志为什么还需要 Trace
日志是离散事件，Trace 用父子 span 还原同一任务的依赖、并行与耗时。Agent 多步链路只看日志很难找到因果顺序。
追问二：是否要保存模型完整思维过程
不以原始隐藏推理为前提。保存结构化计划、动作、Observation、决策摘要、状态变化和完成证据，更可控也更适合审计。
追问三：相同输入为什么回放不一定一致
模型随机、外部数据、路由和依赖版本都会变化。要区分复用历史结果的记录回放、固定版本的受控重放和新版本影子回放。
追问四：回放怎样避免重复下单或发消息
副作用工具默认使用历史 Observation 或模拟器，禁止生产执行。真实集成测试只在隔离环境并使用 Dry-run、幂等和审批。
追问五：Trace 太大怎么办
元数据和内容分层，正文用受控工件引用，字段脱敏，按风险采样和分层保留，同时保证被选中的根轨迹不缺必要子 span。
追问六：怎样证明修复真的有效
用导致问题的历史轨迹稳定回放，修复最早错误层，再加入同类和难负例做回归，最后观察新版本影子结果。
用一条失败链路讲清 Trace 与 Replay
Agent 可观测我会做指标、结构化日志、Trace 和 Replay 四层。每个任务一个 trace_id，模型、工具、State、工件和人工确认分别做 span，记录父子关系、输入输出摘要、版本、耗时、Token、错误和 attempt。重点保存结构化计划、动作、Observation 与状态变化，不依赖原始隐藏推理。排障从最终失败沿依赖反查最早分歧。回放分记录回放、固定版本受控重放和新版本影子回放，并标明哪些结果来自历史、哪些重新执行。副作用工具只读历史 Observation 或模拟器，不能生产重放。Trace 内容分层存储、脱敏、按权限和期限访问。发布前用代表性轨迹比较任务完成、工具选择、恢复、引用和成本口径。
Trace 能否支持定位与回放：十项核验
- 是否用 trace_id、span_id 和父子关系串起完整任务。
- 模型、工具、State、工件、人工确认是否都有独立事件。
- 是否记录 Prompt、模型、工具 Schema、状态和工件版本。
- 是否保留首次失败与所有重试，不被最终成功覆盖。
- 是否用结构化计划和决策摘要，而非依赖原始隐藏推理。
- 敏感参数、结果和快照是否分层、脱敏、有权限和期限。
- 是否区分记录回放、受控重放与影子回放。
- 副作用工具是否默认模拟，不在回放中真实执行。
- 根因是否定位到最早错误层，并通过回放与回归验证。
- 追踪系统故障时是否有业务降级和关键审计保障。
- 没有真实线上数据时，是否避免虚构 Trace 覆盖率、故障率和成本。
Agent 的可观测性最终要交付三种能力：每个结论能追到输入、工具、状态和版本，一次失败能被安全复现，一次修复能由同样的证据证明。页面上的漂亮链路只是展示，不是验收结果。
