一个Agent即使返回HTTP 200，也不意味着它运行正常。它可能选择了错误的工具，将过时的上下文交给Subagent，或者在重试循环中不断消耗Token。而应用层遥测通常只能告诉你发生了一次API请求或数据库查询，却无法解释究竟是什么Agent行为导致了这些问题。
这正是Cloudflare推出Agent Tracing要解决的问题。作为Cloudflare Agents的首个组件，Agent Tracing提供了集中查看已部署Agent会话的统一Dashboard，在现有Workers Tracing基础上增加了Agent级别的Span，并附带明确的收费时间表：Beta期间免费，2026年10月1日起纳入Workers Observability计费体系。
从基础设施追踪到Agent行为追踪
此前，Workers Tracing已经能够对基础设施层进行追踪，包括Fetch调用、KV读取和D1查询等。但直到现在，在Workers上运行的Agent，其Trace中只有这些基础设施Span，缺少Agent自身行为的信息。Agent Tracing新增了Agent调用、模型调用、工具执行和审批等Span，并将模型信息和Token使用量作为元数据附加到其中。
每一轮交互都会生成一条Trace，结构大致如下：
- invoke_agent（Agent类调用）
- chat（模型调用）
- execute_tool（工具执行）
- tool_approval（工具审批）
Subagent的工作会嵌套在调用它的操作之下。如果一个父Agent将任务交给Subagent，而Subagent又调用模型、执行工具、查询D1并写入KV，整个过程就会以一条完整的瀑布流呈现，覆盖两个层级。
三个字段用于关联Agent与Dashboard：Agent name标识逻辑实现，Agent ID标识具体实例，Conversation ID标识会话。Cloudflare特别提醒，不要根据请求或用户标识符动态生成Agent name，否则Dashboard中会出现大量不同的Agent。
开发者怎么看？调试视图是最大吸引力
这种关联方式正是开发者关注这一功能的原因。在Cloudflare的X平台公告下，Mykyta Pavlenko留言称：
"我想在Hermes上试试这个功能，就为了看Trace瀑布流——能够直接看到模型调用下面紧接着出现一个错误的工具参数，这正是我想要的调试视图。"
不过，Approval Span本身存在一个值得注意的限制。文档指出，这类Span表示Worker invocation内部的生命周期事件，并不会记录用户跨多个invocation进行响应时所等待的时间。换句话说，Human-in-the-loop延迟（或许是审批流程中最值得关注的指标）并不是这个Span所记录的内容。
不同框架的Payload默认记录策略差异巨大
真正需要团队特别关注的是Payload记录，因为不同开发框架的默认行为并不一致。Think默认不会保存消息或工具Payload，除非在Agent class中设置storeMessages和storeTools；wrapAISDK()的行为也相同。而Flue默认会保存消息、系统指令、工具定义、参数和结果，需要设置content: false才能停止记录。
也就是说，同一平台提供的这一功能，根据团队所使用的Harness不同，默认隐私策略可能完全相反。而消息Payload中又经常包含个人数据或Secret。
限制与计费：Trace不是无损记录
文档列出的限制同样值得关注。Cloudflare明确表示，Trace并不是完整且无损的会话记录；Payload数据受到Span大小限制，因此较长的消息、推理过程、工具参数和工具结果都可能被截断。此外，Session Replay不会显示图片。如果团队把Replay当作审计记录，而不仅仅是调试工具，那么这些限制意味着它可能无法完全胜任。
计费细节也值得仔细阅读，因为实际计费单位与Agents视图中显示的内容并不完全一致。Cloudflare按Span数量计费，而Agents视图中的每个Trace可能包含多个Span，这意味着最终费用可能高于直观预期。
具体配置方式取决于使用的技术栈。Think和Flue v2及更高版本会自动对每轮交互进行埋点。直接调用AI SDK时，则需要使用wrapAISDK()进行封装，它支持v6及更高版本。
热门跟贴