Agent答错了，别急着换提示词：先接好执行轨迹

读者说：“这个资料助手昨天还会找答案，今天怎么只说没找到？”你打开后台，只看到一句“任务执行成功”和最终回复。模型没选搜索工具，还是搜索服务报错？返回了资料却没被使用，还是引用检查把结果挡住了？这几种情况，最后都可能长成同一句话。

Agent的可观测性，不是把聊天记录存得更长，而是给“它到底做了什么”留下能关联、能定位、又不过度暴露内容的证据。 本文只回答一个问题：一次任务失败后，怎样知道该修工具、检索、运行层还是回答检查，而不是先换提示词碰运气？

AI原创概念插画。微缩剧院中的金色小鸟、音乐盒、滑轮与圆镜由金线联系，前景另有松散黑线；这是对台前结果与幕后执行的艺术隐喻，不是实际系统拓扑或遥测界面。

一、先把三种记录分开Copy Anchor Link

“日志已经有了”还不够。可以先用三个问题区分它们：

• **指标（metrics）**回答整体怎样：任务失败率是否变化，哪类工具变慢。它适合发现异常，不一定能解释某一次异常。
• **日志或事件（logs/events）**回答发生了什么：某个时刻出现了权限拒绝、结果截断或验收失败。
• **轨迹（trace）**把一次工作的相关步骤联系起来：哪次模型请求触发哪次工具调用，子步骤归属于哪段操作，在哪里等待、在哪里结束。

OpenTelemetry将span定义为一个有起止的工作单元，通过共同的trace ID和父子关系组成轨迹；上下文传播使不同进程产生的步骤也能被关联。[1] 一个span可以是一次检索、一次模型调用，也可以是应用自行补上的结果核验。

这里的“上下文”是关联执行所需的信息，不是给模型看的全部聊天上下文。也不要把trace理解为模型真实内心活动的录像：它记录的是被埋点系统捕获的调用、状态与事件，无法证明未记录的动作没有发生。

Agent框架可能自动记录部分步骤。OpenAI Agents SDK当前文档就列有模型生成、函数工具、交接和护栏等span。[2] 但自动有工具span，并不代表你的业务验收已经被记录；后者常常需要应用自己补上。

二、一份报销问答，怎样留下“够用”的轨迹Copy Anchor Link

下面是手工构造的概念案例。没有调用真实Agent、报销系统或遥测服务，也不包含实测延迟与模型成功率。

用户问：“外地打车费能报吗？”应用的预期过程是：检索适用制度，依据证据生成回答，再检查结论是否有支持。运行层还应该区分“检索成功但证据不足”和“检索根本没有成功”。

可以为整次尝试建立一个随机的运行标识，并记录以下步骤。表中字段是本文建议的业务记录设计，不是OpenTelemetry或某家SDK的标准字段契约。

不必把原始问题、整份制度和回答全文复制到每个span。资料引用可以指向有权限控制、保留版本的证据存储；遥测里只留下安全的关联标识。引用是查证入口，不是访问许可。 排障人员仍须有相应授权。

工具HTTP返回成功时，也要记录应用如何解释结果。例如搜索返回了候选，但全部不适用于用户所在组织，这不是“搜索服务宕机”。反过来，超时被包装为空数组后，任务看似正常结束，才更难排查。

三、同一句“没找到”，可能要修三个不同地方Copy Anchor Link

回到这个概念案例，沿轨迹逐层检查：

情况A：没有检索步骤。 如果记录覆盖完整，可以检查工具是否被暴露、描述是否清楚、模型是否选择了直接回答。仅凭最终回复，无法在这几项之间下结论。

情况B：检索步骤出错，但后面生成正常结束。 重点应检查工具错误如何被传给模型、运行层是否把失败误转为空结果，以及是否明确向用户说明能力降级。此时只改回答风格，并没有修复数据入口。

情况C：检索成功，拿到了适用资料，核验却指出缺少具体条件。 应查看保留的资料版本与获授权的输出样本，判断是切片遗漏、材料本来不全，还是生成忽略了例外。轨迹把问题缩小到一个环节，不能替你自动作出内容判断。

还有第四种可能：你看到的轨迹本身不完整。 遥测没有导出、进程异常退出、采样没保留这次任务、跨服务关联丢失，都可能让某段步骤消失。因此，“没看到搜索span”不自动等于“没有搜索”。要同时查埋点覆盖、采样策略与导出健康状态。

这里不要求把每段时长简单相加。并发调用会重叠，排队、审批等待和实际执行也应尽量区分。看到总耗时高，不意味着模型生成一定慢。

四、别让排障系统变成第二份敏感资料库Copy Anchor Link

工具参数可能包含私人资料，错误文本可能回显请求内容，链接可能带临时签名。把这些原样传进遥测后台，等于增加了一个需要管理的副本。

OpenTelemetry的安全文档强调数据最小化，也明确指出：工具本身无法替实施者判断哪些数据在具体业务里敏感。[3] 它还提醒，对可预测、取值空间很小的用户标识做普通哈希，不一定达到所需的匿名化效果。不要把“变成一串字符”当成隐私已经解决。

一个可落地的顺序是：

1. 先定义允许采集的字段。 用固定的工具名、状态枚举、错误类别和安全版本号替代随意拼接的文本；span名称也不要直接使用用户问题。
2. 默认不收正文，再处理必要样本。 确有内容排障需要时，单独规定授权、访问、保留和删除政策；不能用“为改进体验”无限保存。
3. 在出口核对真实数据。 不只查看配置开关，还要检查实际将被送出的payload，覆盖异常消息、嵌套参数、自定义metadata和第三方埋点。
4. 脱敏失败时不要照常外发。 将脱敏与发送放在同一受控路径里；原始数据不能被旁路导出。

第四点有个容易忽略的具体例子：OpenAI Agents SDK当前文档说明，多个trace processor是独立观察者；在一个导出器前面加“脱敏processor”，并不意味着脱敏报错后其他导出器就收不到原数据。文档建议在要求成功脱敏后才能发送时，由应用自己的导出器把处理与交付组合起来，并替换默认处理链。[2]

这属于该SDK当前实现语境，不是所有遥测库都使用同一种机制。本文没有配置或运行该SDK。对于实际项目，应对照所用版本测试完整出口，而不是照搬一个开关名称就宣布安全。

五、轨迹能帮助验收，但不是业务收据Copy Anchor Link

一次“写入文档”工具span没有报错，不代表用户已经能读到正确文档。遥测系统记录了怎样执行，业务系统才保存实际对象。对有副作用的任务，仍要读取目标，核对版本、状态和必要字段，再记录独立的核验结果。

同样，可观测性不等于自动可重放。旧工具结果可能过期，重新执行可能产生新副作用，模型下一次也可能走不同路径。排障时保留安全的版本与产物关联，是为了减少猜测，不是给任意重跑提供授权。

与离线评测的区别也在这里：评测用一组规定任务判断系统是否满足标准；生产轨迹帮助你理解某次真实执行。两者可以相互提供线索，但一条漂亮的轨迹不能证明整体可靠，一组高分测试也不能代替上线后的观察。

六、上线前可复用的检查清单Copy Anchor Link

• 一次任务、一次尝试和一次工具调用，是否各有可区分的关联标识？重复尝试能否归回原任务，而不混成同一次执行？
• 模型、工具、权限等待与业务核验，是否能沿关联信息找到？异步任务若开启新轨迹，是否有显式关联？
• 能否区别未调用、调用失败、空结果、部分结果、被过滤和验收不通过？
• 应用、提示模板、工具契约和证据版本，是否能安全回查，而不把全文塞进日志？
• 轨迹缺失时，是否能检查采样、导出与埋点覆盖，而不是直接判定动作没发生？
• 遥测目的地、访问权限、保留期限与删除流程，是否明确？是否检查了实际出口数据？
• 脱敏失败、导出失败和业务失败是否分别可见？观测系统异常时，是否有符合业务风险的降级策略？
• 最终“完成”是否来自真实业务核验，而不是模型自述或span没有报错？

建议用“工具失败却被当空结果”“过滤后无候选”“核验拒绝”“遥测出口不可用”分别做受控测试。这是尚未执行的测试建议，不是本文已经通过的验收成绩。

最小可用的可观测性，往往不是收集最多内容，而是先接好关键关联：这次任务调用了什么，拿到了哪一版证据，在哪个边界停止，最后交付是否被核实。 当这几条线清楚时，你才知道下一次修改该落在哪儿。

来源与阅读范围Copy Anchor Link

本文由AI创作并核对公开资料。检索截止时间：2026年10月20日19:39 UTC。三份资料均实际获取公开HTML并阅读下述相关正文，不以搜索摘要替代。示例、表格与检查清单为本文综合的工程建议，不构成统一行业标准。

1. OpenTelemetry：Traces。页面标示最后修改于2026-01-14；阅读trace/span、关联传播、属性、事件、链接与状态等正文。用于解释通用追踪概念，不作为Agent业务成功的定义。
2. OpenAI Agents SDK：Tracing。持续更新文档，本页未标固定发布日期与发行版本；按检索时正文阅读默认埋点、敏感数据、处理器及导出前脱敏章节。产品行为限于该文档语境，未作SDK实测。
3. OpenTelemetry：Handling sensitive data。页面标示最后修改于2026-01-14；阅读实施者责任、最小化采集、处理器与哈希匿名化限制等正文。用于说明隐私处理原则，不代表满足某项具体法律要求。