工程经验2026 年 10 月 15 日7 分钟阅读AI 产品 · 产品测试 · 系统可靠性

Agent 的运行记录，够不够支持产品判断？

Claude 新增 OpenTelemetry 导出后，排查 Agent 多了一条路径。但记录可能缺失、重复或截断。先确认自己看到了什么，再决定改模型、改工具，还是补验收。

文章目录

用户说慢，先别急着换模型#

假设一个客服助手查完订单，又查物流，最后才回答用户。用户只说“太慢了”，团队却可能给出完全不同的解释：模型想得久、订单接口卡住，或是同一个查询重复执行。

如果只保存最终回答，这些猜测很难分开。产品经理想判断该改哪里，需要看到一次任务经过了哪些步骤，也需要知道这份记录缺了什么。

Anthropic 在 2026 年 10 月 14 日的更新中发布了 OpenTelemetry 导出测试版，覆盖 Messages API 请求和 Managed Agents 会话。OpenTelemetry 可以简单理解为一套通用的运行观测标准，让不同系统的步骤更容易放到一起查看。

我的判断是：接入记录只是开始。只有确认记录的覆盖范围、统计口径和内容边界，才适合用它决定下一次产品改动。

官方总览区分了应用侧 SDK 和服务端 API 的覆盖：由 SDK 工具执行器运行的客户端工具靠前者记录，服务端的模型运行和工具靠后者记录。它们不是两套任选其一、就能看全的窗口。

回到客服例子，我会先画一条很朴素的任务线：收到问题、查询订单、查询物流、生成回答、用户看见结果。然后逐段问：现在能看到哪一步？哪一步只有开始，没有结束？哪一步根本没有记录？

这条任务线是本文的设计示意，不是 Anthropic 公布的客服案例。它的作用是避免把应用自己等待数据库的时间，全部算成模型的等待时间。

官方 API 接入说明也保留了平台边界：Claude Platform on AWS 暂不支持用于关联链路的 traceparent 请求头，其 API 记录会另起一条链路。因此，“后台已经有数据”不等于“同一件事已经串起来”。

API 文档明确说明，导出可能重复，也可能丢失，丢失的记录无法重新发送。接收状态 Healthy 只表示最近一次投递成功；连续 24 小时全部投递失败，目的地会被停用。

这对产品分析很要紧。假设某类慢请求更容易在中途丢掉记录，那么只分析留下来的任务，结果就可能显得过于乐观。这是一个需要验证的风险，不是文档已经证明发生的现象。

我会让仪表盘同时展示“观察到的结果”和“这批结果覆盖了多少任务”。缺少关键步骤的样本先标为不完整，不直接归到成功，也不悄悄丢掉。如果异常集中在某个版本或工具，就先查采集是否失效，再讨论模型是否退步。

总览提醒，同一请求的 token 用量可能出现在多个层级，不能把 SDK、API 和父子步骤全部相加；重复投递也要去重。完整用量应以 Usage API 等相应接口核对，不能只依赖导出记录。

因此，我会先让研发和产品约定统计对象：算的是一次模型调用，还是用户完成一次咨询所需的全部调用？重试、工具等待和人工接管分别放在哪里？这个口径不确定时，换一个图表并不会让成本比较更准确。

另一方面，状态定义中的 OK 表示步骤完成。它并没有替业务回答“订单是否查对”“承诺是否符合规则”。一个工具顺利返回过期信息，整段流程也可能没有技术报错。

我会从真实失败任务中抽取经授权、去除敏感信息的样本，另设质量检查：答案有没有依据、是否遗漏限制、该转人工时有没有转。运行记录帮助定位问题，业务验收决定结果是否能交给用户。

总览说明，默认导出元数据；开启完整内容后会包含提示词与回答。每个步骤的内容默认最多 0.75 MB，超过会截断并加标记，图片和文档仅以类型出现。这个数字是导出限制，不是模型上下文容量。

所以，调试页面里看不到某句话，不能立刻推断模型从未收到它。先确认记录是否截断，也别把只有附件类型的记录当作完整输入重放。

我的上线建议是先用必要的时间、状态和用量信息解决定位问题。确实需要正文样本时，再明确哪些任务允许采集、谁能看、多久删除。接收平台也有自己的访问和保留规则，不能因为模型服务配置过保留策略，就默认整条数据路径都满足同样要求。

这不是要求少看数据，而是先说明每一份内容为什么值得留下。调试收益说不清楚时，不应把保存全部对话当成默认答案。

我会选一条边界清楚的客服流程做试点，主动安排工具超时、重复请求、用户中断和长内容截断，检查团队能否从记录中区分这些情况。这里不预设漂亮的通过率，先要求同一个失败能被稳定识别、复现和解释。

之后再用相同任务和验收标准比较改动前后：合格回答有没有变多，用户实际等待有没有缩短，是否减少了不必要的重试。若只是日志更丰富，而问题仍然无法定位，就继续补覆盖；若定位清楚但答案仍错，就回到资料、工具和质量评测。

好的运行记录，不是让后台看起来更热闹。它应该帮助团队少做一次错误归因，更有把握地决定下一步。

发布时间：Anthropic，Claude Platform release notes，2026 年 10 月 14 日。本文讨论 OpenTelemetry export beta，不是新模型能力发布。
对象与设置：Anthropic，OpenTelemetry 总览，2026 年 10 月 15 日读取。客户端与服务端分工、统计去重、内容模式及 0.75 MB 默认限制来自该页；未把文档读取日期当作首次发布日期。
交付限制：Anthropic，API 接入文档，同日读取。AWS 链路限制、可能丢失与重复、Healthy 含义及连续失败停用规则来自该页。
状态含义：Anthropic，Span reference，同日读取。它定义步骤状态，并提示测试版中的名称和属性可能变化。
证据强度：以上是接口设计和行为说明，没有提供上线前后故障率、延迟或节省成本的对照实验，也没有证明接入后必然改善业务质量。本文没有运行该功能。
本文判断：客服场景、覆盖检查、样本验收和试点顺序是产品设计建议。文中的假设用于解释风险，不是个人项目经历或已经发生的实验结果。