Agent 出错不能只看日志：Trace、工具调用和失败凭证怎么讲

Agent 调用工具失败，日志里只剩一句“执行异常”。面试官接着问：它收到什么任务、选了哪个工具、参数是否被改写、失败前状态是什么、重试有没有重复写入、用户最后看见什么？如果这些问题答不上来，日志再多也只是碎片。

Agent 可观测性的目标，是在不默认泄露敏感内容的前提下，重建一次任务的可观测执行事实。它帮助定位偏离，却不能声称读懂模型隐藏推理，也不能单靠一条 Trace 证明因果。

只有一行 Error，为什么定位不了 Agent 事故

普通服务错误常能落在一个请求和调用栈里，Agent 任务却可能跨多个模型调用、工具、策略检查和状态更新。最后抛错的是数据库，不代表第一次偏离发生在数据库；可能更早的模型输出了错误参数，路由选错工具，或重试复用了过期状态。

第一层回答要区分日志与 Trace：日志是事件，Trace 用共同身份和父子关系把事件组织成一次任务。第二层追问要说明边界：Trace 只能展示系统记录下来的输入、输出、时间与状态，不能自动解释模型“为什么这样想”，也不能省掉实验和复现。

面试中可以先定义三类问题：发生了什么；第一次在哪里偏离；影响了谁和什么数据。后续字段、采样和保留策略都应服务这三类问题，而不是“能采的全部采下来”。

一次任务 Trace 要串起哪些调用与状态

任务级 Trace 至少要有稳定的 task id、开始与结束时间、调用关系、组件和版本、状态迁移、最终结果。模型 span 可以记录所用模型或配置标识、输入输出引用、用量和延迟；工具 span 记录工具名、参数摘要、权限结果、返回状态和副作用标识；策略 span 记录允许、拒绝或要求人工确认。

第一层回答画树：任务是根，模型、工具、策略、检索和存储是子 span。第二层追问画状态：待规划、执行中、等待审批、重试、完成、失败或取消。只有调用树而没有状态迁移，仍然看不出为什么同一个工具被调用三次。

上下文来源也要可追踪，但不等于保存全文。可以记录文档标识、版本、选择原因和脱敏后的摘要。若要进一步理解任务、权限与状态怎样成为可治理对象，可结合 Agent 控制平面系统设计，但长期记忆设计不属于本文的主线。

工具调用必须成为显式 Span 和状态变化

工具不是模型回答里的一个字符串，而是可能读写外部世界的动作。可观测设计应区分“模型建议调用”“策略允许调用”“执行器开始调用”“外部系统确认完成”四个事件。否则看到成功响应时，仍不知道动作是否真正提交，或重试是否造成第二次写入。

第一层回答应包含工具身份、输入摘要、权限上下文、开始结束、结果类别、重试次数和幂等标识。第二层追问则处理副作用：工具超时但外部系统已成功，Agent 能否查询操作状态，而不是盲目再发一次？审批在重试期间过期，旧授权是否还能沿用？

Span 关系要能表达并发与依赖。两个并行检索失败一个，可能仍可降级完成；付款和通知则可能有严格顺序。面试中不要只说“都打日志”，要说明哪些状态是不变量，哪些步骤失败后允许继续，哪些必须停止。

失败凭证里应该保留什么、删掉什么

失败凭证是让另一个工程师能够复核事故的最小证据包。它可包含任务与 Trace 标识、时间线、组件版本、输入来源引用、输出状态、工具参数摘要、权限决定、重试、延迟、用量或成本、错误类别、用户可见结果，以及数据是否已脱敏。

不应默认保存密钥、访问令牌、完整个人资料、整段私密对话或无关工具返回。需要正文才能复现时，也应先确认目的和权限，优先使用字段级脱敏、受控引用或短期隔离存储，而不是把敏感内容复制进所有日志平台。

第一层回答说“足够定位，最少暴露”。第二层追问要给治理机制：采集前脱敏、按角色授权、访问审计、明确保留期、删除路径和环境隔离。NIST AI RMF 1.0 是自愿采用且在本文发布时正在修订的风险治理框架，它不会替你的具体系统决定该保存哪个字段。

用 Trace 回答第一次偏离发生在哪里

定位不能从最后一行错误倒推故事，而要把预期状态与实际状态对齐。先确定任务不变量，例如未经审批不能写入、同一动作只能提交一次、被取消回合不能再产生输出。然后从 Trace 起点向后找第一个违反不变量或偏离预期分支的 span。

第一层回答可以讲“最早异常事件”。第二层追问要排除假相关：延迟最高的 span 不一定是根因，最后失败的工具也不一定最先出错。应结合相同版本的成功样本、失败切片、可控复现和变更记录验证假设。

例如用户收到重复通知，最后两次通知调用都成功。真正的第一次偏离可能是模型重试时没有继承已提交状态，也可能是执行器超时后未查询外部结果。Trace 帮你缩小范围，但因果结论仍要靠状态证据和复现实验支撑。Guardrails 与 Evals 面试指南可以补充如何把这类事故变成回归样本。

可调试性、隐私和成本怎样一起设计

全量记录所有正文看似最容易调试，却会扩大敏感数据暴露、存储成本和访问面。完全不记录又无法复盘。强答案会先按风险分层：高风险副作用保留更完整的结构化凭证，低风险成功请求可降低采样，所有密钥和明确个人数据都在进入观测系统前处理。

第一层回答给三道门：什么允许采集、谁能查看、保存多久。第二层追问谈采样偏差：只保留失败会失去成功对照，只保留随机样本又可能漏掉低频高风险事件。可采用错误与高风险事件优先保留，再配少量成功基线和关键切片，但具体比例必须按业务风险与成本验证。

OpenTelemetry 的 GenAI 语义约定目前处于 Development 状态，字段与结构仍可能变化，不能作为稳定最终标准，也不能笼统假设所有继承字段具有同一稳定性。OpenAI Agents SDK Tracing 和 Langfuse Tracing 也只是各自实现参考。采用时要核验默认采集内容和版本变化，最好通过版本化内部观测模型做映射，避免外部字段直接成为永久数据合同。