🛰️ 可观测性 · 技术发布
Cloudflare 推出 Agent Tracing：HTTP 200 不代表 Agent 正常，AI 运维迎来"行车记录仪"
Cloudflare 今日发布 Agent Tracing——Cloudflare Agents 平台的首个组件。它在 Workers Tracing 之上新增 Agent 调用、模型调用、工具执行、审批四类 Span，让开发者用统一 Dashboard 看清 Agent 的真实行为。Beta 免费，2026 年 10 月 1 日起纳入 Workers Observability 计费。
来源：综合公开信息•
2026-07-22•
全文约 4 分钟读完
#Cloudflare
#AI 可观测性
#Agent
#开发者工具
4 类
新增 Agent 级 Span：调用 / 模型 / 工具 / 审批
2 层
Subagent 嵌套瀑布流覆盖父子层级
$0.60
超出部分每百万 Event 计费单价
注：以上数字来自官方发布公告；计费细则以 2026 年 10 月 1 日生效的 Workers Observability 定价页为准。
⚡ 30 秒速览
- 是什么：Cloudflare Agents 首个组件，基于 Workers Tracing 增加 Agent 级 Span，统一 Dashboard 集中查看已部署会话。
- 解决什么：HTTP 200 ≠ 运行正常。选错工具、上下文过期、重试烧 Token——这些 Agent 行为，传统遥测一概看不见。
- 怎么看：每轮交互生成一条 Trace，Subagent 嵌套成瀑布流；Agent name / ID / Conversation ID 三字段关联会话。
- 坑一：Payload 默认记录策略因框架而异——Think 默认不存、Flue 默认全存，而消息里常带着个人数据或 Secret。
- 坑二：10 月 1 日起计费，复杂 Harness 的 Span 量可能让实际成本明显高于 Dashboard 观感。
01为什么需要它：HTTP 200 的陷阱
Cloudflare 这次推出的，不是新模型，也不是新运行时，而是一层专门为 Agent 行为打造的"观测镜"。它把已经部署的 Agent 会话，集中到一个统一 Dashboard。每一轮交互，生成一条 Trace。
传统应用层遥测
告诉你"发生了一次 API 请求、一次数据库查询"；却无法解释，究竟是哪个 Agent 行为导致了问题。
Agent Tracing
新增 Agent 调用、模型调用、工具执行、审批四类 Span，把"Agent 做了什么"变成可检索、可回放的数据。
它想解决的问题，被一个状态码掩盖住了。
一个 Agent 即使返回 HTTP 200，也不意味着运行正常。它可能选错了工具，把过时的上下文丢给 Subagent，或者卡在重试循环里不断消耗 Token。应用层遥测只能告诉你"请求成功了"，Agent 的真实行为，仍然是一团黑箱。
02它如何工作：一次调用，一棵树
每一轮交互都会生成一条 Trace，调用链上的每一环都有对应的 Span。模型信息与 Token 使用量，会作为元数据附加在 Span 上：
invoke_agent {agent class}
├── chat {model}
└── execute_tool {tool}
└── tool_approval {tool}
结构示意：Subagent 的工作会嵌套在调用它的操作之下。父 Agent 与子 Agent 之间的调用、模型选择、工具结果，以完整瀑布流跨层级呈现。
要把 Trace 映射回业务场景，靠三个字段：
Agent name标识逻辑实现
Agent ID标识具体实例
Conversation ID标识一次会话
⚠️ 不要根据请求或用户标识符动态生成 Agent name。否则 Dashboard 会出现大量"一次性"Agent，会话关联会被稀释到失去意义。
03开发者拿它做什么：瀑布流的魅力
一个评论，比官方文档更能解释这东西为什么值得用。
💬 "我想在 Hermes 上试试这个功能，就为了看 Trace 瀑布流"
- 在 Cloudflare 的官方公告下，开发者 Mykyta Pavlenko 留言。
- 原话："能够直接看到模型调用下面紧接着出现一个错误的工具参数，这正是我想要的调试视图。"
这条评论指向的核心场景：错误定位不再靠猜——模型调用与工具参数错误在瀑布流中相邻呈现，问题一目了然。
Trace 解决"这一轮发生了什么"。Session Replay 则更进一步——跨多个交互轮次，把消息、推理过程、带参数和结果的工具调用、Subagent 活动重新组合起来。
🔄
重放 ≠ 重跑
Cloudflare 明确指出：Replay 只是重新组合已经记录的数据，并不会重新执行 Agent。它是对会话的"录像"，不是沙盘推演。
接入方式取决于技术栈，不同框架的埋点方式差异不小：
Think / Flue v2+自动埋点，每轮交互默认生成 Trace
直接调用 AI SDK需 wrapAISDK() 封装，支持 v6 / v7，每次调用必须提供身份字段
自定义 Harness使用 Workers Custom Spans API + OpenTelemetry GenAI 参考实现
与标准同步的另一面：Span 属性遵循 OpenTelemetry 的生成式 AI 语义约定，Trace 可以导出到任意 OTLP Endpoint。Workers 目前还不直接支持 OpenTelemetry API，Cloudflare 表示正在开发——完成后，能生成标准 Span 的框架可直接接入，无需手动埋点。
04诚实的注脚：默认策略相反，计费另有玄机
真正需要团队逐字阅读的，是 Payload 记录策略。同一个功能，不同框架的默认行为可能完全相反：
| 框架 | 默认 Payload 记录行为 |
|---|
| Think / wrapAISDK() | 默认不保存消息或工具 Payload；需在 Agent class 中显式设置 storeMessages 与 storeTools 才会记录 |
| Flue | 默认保存消息、系统指令、工具定义、参数和结果；需设置 content:false 才会停止记录 |
也就是说：默认隐私策略取决于团队选择的技术栈。而消息 Payload 中，经常包含个人数据或 Secret。
文档列出的限制同样值得逐行过目：
- Trace 不是完整且无损的会话记录——Payload 数据受 Span 大小限制，较长消息、推理过程、工具参数和工具结果都可能被截断；
- Session Replay 不显示图片；
- Approval Span 只记录 Worker invocation 内部的生命周期事件，不会记录用户跨多个 invocation 响应前等待的时间——而这通常是人审流程中最值得关注的指标。
如果团队把 Replay 当作审计记录，这些限制意味着它可能无法完全胜任。
计费细节同样有"隐藏项"。计费单位是 Observability Event，不是 Trace 的数量。SDK 内部产生的 Span、其他 Worker 层面的操作，即使不会显示在 Agents 视图中，同样计费。
20万Event/天 · Workers Free 免费额度
2000万Event/月 · Workers Paid 包含
$0.60超出的每百万 Event 单价
3–7 天数据保留期（Free 3 天 / Paid 7 天）
一个产生大量 Span 的复杂 Harness，实际成本可能高于 Dashboard 给人的直观印象；需要追踪长期趋势的团队，3–7 天的保留期也相对有限。
05一个趋势：Agent 需要自己的遥测层
这次发布不是孤立事件。各家云厂商在做同一件事：
微软 Agent Framework默认启用 OpenTelemetry
→
Azure API ManagementToken 指标导出至 Datadog / Grafana
→
Cloudflare Agent Tracing新增 Agent 级 Span
注：三家路径不同，但指向同一个结论——Agent Runtime 需要自己的遥测层，仅靠基础设施 Span 无法解释 Agent 究竟做了什么。
基础设施 Span 能告诉你服务活着没有，却说不清 Agent 为什么这么做。Agent 的行为，第一次有了可以被检索、被回放、被审计的语言。
Cloudflare 把 Tracing 描述为"构建能够持续自我改进的 Agent 的一步"——未来，结构化 Trace 数据可以用于模型评估与 Agent 开发生命周期。这是它画出的方向。而眼前已经实现的是：每个开发者都能看到，每一轮交互调用了哪个模型、消耗了多少 Token、选择了哪个工具，以及时间到底花在了哪里。
编辑核心判断
可观测性正在成为 Agent 平台的分水岭——先让每一次工具选择、每一笔 Token 消耗都被看见，然后才谈得上优化、审计与信任。Cloudflare 把 Agent 的每一轮思考变成了可检视的瀑布流，这一步走对了。但 Payload 默认策略的割裂说明，这个领域仍在"各家定义各家的规矩"。标准真正落地之前，最值得被观测的，是观测工具自己。