Cloudflare 推出 Agents 平台，率先上线智能体追踪功能

我们正在把在 Cloudflare 上部署和管理托管智能体所需的一切整合到一起，首先从可观测性开始。

过去九年，我们一直在构建开发者平台，而智能体正是最理想的应用场景。它们本质上只是另一种类型的应用，但构建它们所需的一切——模型访问、持久化运行时、编排、沙箱执行、持久存储——恰好都是我们已经构建好的能力。

现在，我们要让在 Cloudflare 上部署和管理智能体变得更加容易。Cloudflare Agents 将你所有已部署的智能体会话整合到单一体验中，呈现关键信息和洞察，让你了解智能体在规模化运行时的表现。

第一站：智能体追踪

我们正式推出智能体追踪功能，为智能体行为提供更直接的可见性和洞察。借助智能体感知的追踪，你现在可以准确了解智能体在做什么以及它的成本：每一次模型调用、每一次工具执行、每一个 token 都会被计量并呈现在这里。智能体追踪今日上线，支持兼容 OpenTelemetry 的智能体框架，包括 Think、Flue 和 AI SDK，未来还会支持更多。

智能体追踪只是开始。一旦你能够观测到智能体的思考过程和真实行为，就可以开始分析这些数据并做出真正的改进。把这些数据接入你的智能体开发生命周期，你就能拥有自主、自我改进的智能体。这就是 Cloudflare Agents 的愿景：一个地方，部署、观测并持续改进你运行的每一个智能体。

让智能体可观测

一个智能体可能返回 HTTP 200，但仍然失败。它可能选错了工具，把过期的上下文传给子智能体，或者在重试循环中浪费 token。传统的应用遥测可能会显示 API 请求或数据库查询，但不会显示导致这些行为的智能体决策。

智能体级别的遥测应该能回答这样的问题：

• 时间花在了哪里：模型、工具，还是基础设施？
• 这一轮是否因审批而暂停？
• 智能体调用了哪个模型，这一轮用了多少 token？
• 智能体是否选对了工具？
• 当工具调用外部 API 时，它收到的是成功响应还是超时？
• 具体是哪个子智能体执行了这项工作，以及这项工作如何影响了最终回复？

Workers 追踪此前已覆盖基础设施层，包括 fetch 调用、KV 读取和 D1 查询，但在此之前，运行在 Workers 上的智能体追踪只包含这些基础设施跨度，而缺少围绕它们的智能体操作。智能体追踪填补了这一空白，在已捕获的 Workers 数据之外，新增了智能体调用、模型调用、工具执行、审批事件以及受支持的子智能体调用等跨度。你还可以获得附加为元数据的上下文信息，例如模型和 token 用量。

从今天起，使用 Think、Flue 和 AI SDK 构建的智能体将把智能体追踪发送到 Cloudflare，让你可以在仪表盘中可视化这些追踪，或将其导出到受支持的 OpenTelemetry 兼容目的地。

所有智能体汇聚一处

Cloudflare 仪表盘现在新增了专门的 Agents 视图，可列出被观测到的智能体及其追踪，同时展示运行、会话、实例和报告的 token 用量。

当你打开某个智能体时，可以通过两种方式可视化、理解并调试它的行为：

• 回放会话，以查看所有轮次中捕获的上下文
• 查看追踪，以检查每一轮的执行情况

回放会话

Messages 标签页会汇总某一轮次的完整对话：系统指令、用户消息、模型的思考过程、带参数和结果的工具调用，以及最终回复。这是对已记录数据的回放，而非重新执行智能体。这样你可以发现格式错误的工具参数、查看选择工具时可用的上下文、理解向子智能体的交接过程，或识别早期轮次如何影响了后续结果。

在这个示例中，用户要求规划一次里斯本两日游。你可以看到模型的推理过程，观察它两次调用 destination_researcher（它重试了一次），阅读工具结果，并跟随它的思路进入行程规划阶段。如果智能体做出了错误决策，你就能在这里找到原因。

具体记录哪些内容取决于你所用的 harness 或框架。对于 Think、Flue 和 AI SDK，`storeMessages` 和 `storeTools` 控制是否捕获消息和工具负载。当这些数据可能包含个人信息、密钥或其他敏感数据时，你可以关闭负载记录功能。

查看 trace

Traces 选项卡展示执行瀑布图，你可以据此判断时间花在了哪里，并将智能体操作与 Workers 基础设施关联起来。

在此 trace 中，一个 Travel_Planner 智能体将任务委派给 itinerary_builder 子智能体，后者调用模型、运行工具、访问 D1 并写入 KV——所有这些都在同一个瀑布图中清晰可见：

• invoke_agent TravelPlanner：父智能体的调用，总计 2.72 分钟。智能体类、会话和 Durable Object 的标识符均已附加，便于你在多个 trace 之间进行关联。
• invoke_agent itinerary_builder：嵌套在父调用下的子智能体，占用了其中 1.83 分钟。
• chat @cf/zai-org/glm-4.7-flash：每一层的模型调用，附有耗时和提供商报告的 token 用量。第一次调用（17.59 秒）是父智能体的路由决策；子智能体在其下进行了自己的调用。
• execute_tool record_itinerary_builder_execution：工具执行，耗时 104ms。
• cloudflare-d1 run d1_run：由该工具触发的 D1 查询，同样耗时 104ms。
• execute_tool record_respond_ready：工具执行，耗时 232ms。
• cloudflare-kv put kv_put：由后续工具触发的 KV 写入，耗时 232ms。

Workers tracing 已经对 KV、D1、Durable Object、service binding 和 fetch 调用等绑定进行了插桩，因此工具所使用的 Cloudflare 基础设施会显示在触发它的智能体操作之下。当子任务在活动 trace 上下文中运行时，受支持的子智能体调用会嵌套在父调用之下。这样你就可以从父智能体出发，经由委派的工作，一路追踪到每个智能体所使用的 Cloudflare 资源。

如何启用智能体 tracing

首先，在 Worker 的项目配置文件 wrangler.jsonc 中启用 tracing：

{
  "observability": {
    "traces": {
      "enabled": true,
    }
  }
}

之后的设置取决于你所用的技术栈

很快，任何符合 OpenTelemetry 标准的工具包都能直接使用

我们正在努力在 Workers 内部直接支持 OpenTelemetry API。这意味着，那些已经能生成 OpenTelemetry 生成式 AI 语义约定 spans 的框架，将无需等待 Cloudflare 专属适配器，就能直接在 Agents 视图中可视化这些数据。当这些 spans 包含标准的智能体和会话标识符时，Agents 视图就能像处理我们的内置集成一样，将它们分组到智能体和会话中。Cloudflare 已经能够导出 OpenTelemetry 数据；这次新增的是反向支持，即接收在 Workers 内部生成的标准遥测数据。

使用 OpenTelemetry 导出追踪数据

你的智能体遥测数据不会锁定在 Cloudflare 内。你可以通过在 Worker 的 Wrangler 配置文件中配置目标地址，将追踪数据导出到任何兼容 OTLP 的提供商。由于每条追踪都是结构化的，这些帮助你调试智能体的数据同样可以用于评估、分析和 token 用量报告。这意味着追踪数据不仅是在出问题时才查看的工具，更是持续改进智能体质量、性能和成本的反馈闭环。

定价

智能体追踪基于 Workers 追踪构建，因此定价很简单。Agents 视图显示你的智能体操作，但完整的 Worker 追踪可能包含来自 SDK 内部和其他 Worker 级操作的额外 spans。要查看完整追踪，请点击“在可观测性中查看”。

每个 span 都计为一次可观测性事件，而不仅仅是 Agents 视图中可见的那些。目前所有追踪在测试版期间均免费。从 2026 年 10 月 1 日起，追踪定价将纳入现有的 Workers 可观测性定价中：

追踪功能只是第一步，我们将持续把 Cloudflare Agents 打造成一个让你轻松部署、观测并持续改进所运行每一个智能体的平台。

准备好查看你的智能体都在做什么了吗？查阅我们的文档，为你的智能体启用可观测性，然后前往 Agents 仪表盘，查看你的第一条追踪记录或回放某个会话。