Cloudflare Agents 推出：先从智能体可观测性开始
概览
Cloudflare 正在把部署和管理托管智能体所需的能力整合到一个统一体验中，第一步是可观测性。
在 Cloudflare 看来，智能体本质上也是一种应用，但它们依赖的能力包括模型访问、持久运行时、编排、沙箱执行和持久化存储。Cloudflare 认为这些能力已经存在于其开发者平台之中，因此进一步推出 Cloudflare Agents，用于集中呈现已部署的智能体会话，并提供关于智能体大规模运行情况的关键信息和洞察。
首个能力：agent tracing
Cloudflare 发布了面向智能体的追踪能力，用于更直接地观察和理解智能体行为。
通过 agent-aware traces，开发者可以看到智能体正在做什么，以及相关成本构成，包括：
- 每一次模型调用
- 每一次工具执行
- Token 使用情况
- 智能体调用和子智能体调用
- 审批事件
- 与 Workers 基础设施相关的调用
该能力现已支持兼容 OpenTelemetry 的智能体框架，包括 Think、Flue、AI SDK 等。
Cloudflare 表示，智能体追踪只是起点。一旦能够观察智能体的推理过程和真实行为，开发者就可以进一步分析这些数据，并将其纳入智能体开发生命周期，用于改进智能体质量、性能和成本表现。
为什么传统可观测性不够
智能体即使返回 HTTP 200，也可能在任务层面失败。例如：
- 选择了错误的工具
- 将过期上下文传递给子智能体
- 在重试循环中消耗大量 Token
- 外部 API 超时却没有被正确处理
- 子智能体的中间行为影响最终结果
传统应用遥测通常能显示 API 请求、数据库查询等基础设施层事件，但不一定能解释导致这些事件的智能体行为。
面向智能体的遥测需要回答的问题包括：
- 时间主要花在模型、工具还是基础设施上？
- 某一轮交互是否因为等待审批而暂停？
- 智能体调用了哪个模型，使用了多少 Token？
- 智能体是否选择了正确的工具？
- 工具调用外部 API 时，是成功响应还是超时？
- 哪个子智能体执行了具体工作，它如何影响最终响应？
Workers tracing 已经覆盖 fetch 调用、KV 读取、D1 查询等基础设施层事件。新的 agent tracing 则在这些基础设施 span 之外，补充智能体调用、模型调用、工具执行、审批事件和受支持的子智能体调用，并附带模型、Token 使用等元数据。
统一的 Agents 视图
Cloudflare 控制台新增了专门的 Agents 视图，用于列出已观测到的智能体及其 traces，并展示运行、会话、实例和上报的 Token 使用情况。
打开某个智能体后，可以通过两种方式理解和调试其行为：
- 回放会话：查看每一轮交互中记录下来的上下文。
- 查看 trace：检查每一轮执行过程的瀑布图。
会话回放：查看当时发生了什么
Messages 标签页会汇总某一轮交互的完整对话内容，包括：
- 系统指令
- 用户消息
- 模型思考过程
- 工具调用及其参数和结果
- 最终响应
这里的回放是对已记录数据的展示，并不是重新执行智能体。
这可以帮助开发者发现：
- 工具参数是否格式错误
- 智能体选择工具时可见的上下文是什么
- 是否发生了向子智能体的移交
- 早期某轮对话如何影响后续结果
具体记录哪些内容取决于所使用的框架。对于 Think、Flue 和 AI SDK，storeMessages 与 storeTools 控制是否记录消息和工具 payload。如果数据可能包含个人信息、密钥或其他敏感内容，可以关闭 payload 记录。
Trace 视图：把智能体行为和基础设施连接起来
Traces 标签页展示执行瀑布图，开发者可以用它分析时间分布，并把智能体操作与 Workers 基础设施事件关联起来。
例如，一个旅行规划智能体可以委派给行程构建子智能体；子智能体调用模型、运行工具、查询 D1，并写入 KV。这些步骤都可以在同一个瀑布图中呈现。
可见的事件类型包括：
- 父智能体调用
- 子智能体调用
- 模型调用及耗时、Token 使用
- 工具执行
- D1 查询
- KV 写入
- Durable Object、service binding、fetch 等 Workers 相关操作
由于 Workers tracing 已经为 KV、D1、Durable Object、service binding 和 fetch 调用提供 instrumentation，因此工具触发的 Cloudflare 基础设施操作会显示在对应智能体操作之下。受支持的子智能体调用也会嵌套在父智能体调用下，使开发者能够从父智能体一路追踪到委派工作和具体资源使用。
如何启用 agent tracing
启用方式首先需要在 Worker 项目的 wrangler.jsonc 配置中开启 tracing。后续配置取决于所使用的技术栈或框架。
Cloudflare 还表示，正在推进在 Workers 内直接支持 OpenTelemetry API。未来，已经发出 OpenTelemetry 生成式 AI 语义约定 spans 的框架，将有机会无需 Cloudflare 专用适配器，就在 Agents 视图中完成可视化。
当这些 spans 包含标准化的智能体和会话标识时，Agents 视图可以像内置集成一样，将它们归类到具体智能体和会话中。
支持导出到 OpenTelemetry 兼容平台
Cloudflare 表示，智能体遥测数据不会被锁定在 Cloudflare 内部。开发者可以通过配置 Worker 的目标端，将 traces 导出到任何兼容 OTLP 的服务。
由于每条 trace 都是结构化数据，它不仅可以用于排查故障，也可以用于评估、分析和 Token 使用报告，进而形成改进智能体质量、性能和成本的反馈循环。
定价信息
Agent traces 基于 Workers tracing 构建。Agents 视图展示智能体相关操作，但完整 Worker trace 可能包含 SDK 内部 span 和其他 Worker 层操作。
计费口径上，每个 span 都会被计为一个 observability event，不限于 Agents 视图中可见的 span。
目前 tracing 在 beta 期间免费。Cloudflare 表示，从 2026 年 10 月 1 日开始，tracing 价格将纳入现有 Workers Observability 定价体系。
小结
Cloudflare Agents 的第一步是智能体可观测性：通过统一的 Agents 视图、会话回放和 agent tracing，让开发者能够看到智能体的模型调用、工具执行、Token 使用、子智能体行为以及底层基础设施调用。
对正在把智能体部署到生产环境的团队来说，这类能力的价值在于把“请求成功”与“任务真正完成”区分开，并为后续调试、评估和持续改进提供结构化数据基础。