Cloudflare 推出 Agent Tracing：看见 Agent 如何思考、调用与消耗

导语

Agent 返回 HTTP 200，并不代表它真的完成了正确工作。它可能选错工具、把过时上下文交给 Subagent，或者在重试循环中持续消耗 Token。传统应用遥测能够显示 Fetch、KV、D1 或数据库请求，却很难回答“Agent 为什么这样做”。Cloudflare 近期推出的 Agent Tracing，正是为了补上这一层运行时可观测性。

从基础设施追踪到 Agent 行为追踪

Agent Tracing 建立在 Workers Tracing 之上，为每轮交互增加 Agent 级别的 Span。一次调用可以呈现为 Agent 调用、模型调用、工具执行和工具审批等嵌套步骤，并附带模型信息和 Token 使用量。父 Agent 委托给 Subagent 后，后者继续调用模型、工具或访问 D1、KV，相关活动也会嵌入同一条瀑布流中。

Dashboard 通过三个字段关联数据：Agent name 标识逻辑实现，Agent ID 标识具体实例，Conversation ID 标识会话。Cloudflare 建议不要根据请求或用户标识动态生成 Agent name，否则会造成 Agent 列表碎片化。

除了实时 Trace，Session Replay 可以跨多个交互轮次重新组织已记录的消息、推理过程、工具参数与结果，以及 Subagent 活动。它只是重放数据，不会重新执行 Agent。需要注意的是，Approval Span 只记录 Worker invocation 内部的生命周期，不包含用户跨多个 invocation 进行响应时产生的等待时间，因此不能直接代表完整的人在回路延迟。

Payload 默认策略是关键风险

不同 Harness 的默认记录行为并不统一：

• Think 默认不保存消息和工具 Payload，需要在 Agent class 中启用 storeMessages 与 storeTools。
• wrapAISDK() 的默认行为与 Think 相同。
• Flue 默认保存消息、系统指令、工具定义、参数和结果，需要设置 content: false 才能停止记录。

这些 Payload 可能包含个人数据、内部指令或 Secret。团队不能只打开追踪功能，还应逐项确认记录范围、脱敏方式与访问权限。

限制与成本不能忽略

Cloudflare 明确表示，Trace 不是完整、无损的会话档案。受 Span 大小限制影响，较长消息、推理过程、工具参数和结果可能被截断；Session Replay 也不显示图片。因此，它更适合调试和排障，不能天然等同于审计记录。

Think、Flue v2 及更高版本会自动埋点；直接使用 AI SDK 时需要通过 wrapAISDK() 封装，且每次调用都要提供身份字段。自定义 Harness 则需要使用 Workers Custom Spans API，并参考 OpenTelemetry 的 GenAI 语义约定。Trace 可以导出到 OTLP Endpoint，但 Workers 当前还不直接支持 OpenTelemetry API，Cloudflare 表示正在开发相关支持。

Beta 期间免费，2026 年 10 月 1 日起纳入 Workers Observability 计费。Workers Free 每天包含 20 万次 Event，保留 3 天；Workers Paid 每月包含 2000 万次 Event，保留 7 天，超出部分按每 100 万次 0.60 美元计费。计费单位是所有 Span 产生的 Observability Event，并不只对应 Agents 视图中的内容。

意义与影响

Agent Tracing 说明，Agent 系统需要独立于基础设施的运行时遥测。开发者终于可以沿着一条调用链观察模型选择、工具参数、审批节点和 Token 消耗，从而定位“结果错误”背后的行为原因。不过，默认 Payload 策略、截断、审批等待时间缺失以及事件计费，也意味着可观测性设计必须与隐私、成本和长期留存策略一起规划。

来源：InfoQ 中文