Cloudflare Agents 正式发布：统一代理可观测性与追踪

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

过去九年，我们一直在构建开发者平台，而智能体正是它的绝佳用例。智能体本质上只是另一类应用，而构建它们所需要的——模型访问、持久化运行时、编排、沙箱化执行、持久存储——恰好就是我们已经构建好的东西。

现在，我们让在 Cloudflare 上部署和管理智能体变得更加容易。Cloudflare Agents 把你所有已部署的智能体会话汇集到同一个体验中，呈现关键信息，并洞察你的智能体在大规模运行时的表现。

第一站：智能体追踪

我们推出 智能体追踪，让你更直接地看清智能体的行为。借助感知智能体的追踪，你现在可以准确了解智能体在做什么、花了多少钱：每一次模型调用、工具执行和 token 都会在这里被度量并呈现。智能体追踪今天上线，支持兼容 OpenTelemetry 的智能体套件（harness），包括 Think、Flue 和 AI SDK 等。

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

让智能体可观测

一个智能体即使返回 HTTP 200，也可能失败。它可能选错了工具，把过时的上下文传给了子智能体，或者在重试循环里耗费 token。传统的应用遥测也许能显示 API 请求或数据库查询，却看不到引发它们的智能体行为。

智能体层面的遥测应当能回答这样一些问题：

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

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

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

你所有的智能体，集中一处

Cloudflare 仪表盘现在有了专门的 Agents 视图，列出被观测到的智能体及其追踪，以及运行（run）、会话、实例和上报的 token 用量。

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

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

回放会话

Messages 标签页会还原指定一轮的完整对话：系统指令、用户消息、模型的思考、带有参数和结果的工具调用，以及最终响应。这是对已记录数据的回放，而不是重新执行智能体。这让你能够发现格式错误的工具参数，看到选择某个工具时可用的上下文，理解向子智能体的交接，或者弄清较早的一轮如何影响了后面的结果。

在这个例子中，用户要求规划一次为期两天的里斯本之旅。你可以看到模型的推理过程，看它两次调用 destination_researcher（它重试了一次），阅读工具返回的结果，并跟随它的思路继续构建行程。如果智能体做了糟糕的决定，你就能在这里找到原因。

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

查看追踪

Traces 标签页展示执行瀑布图，你可以据此判断时间是如何花掉的，并把智能体操作与 Workers 基础设施关联起来。

在这条追踪中，一个 Travel_Planner 智能体委派给一个 itinerary_builder 子智能体，后者调用模型、运行工具、访问 D1，并写入 KV——全部呈现在同一张瀑布图中：

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

Workers 追踪已经为 KV、D1、Durable Object、服务绑定（service-binding）和 fetch 调用等绑定做了埋点，因此工具所用的 Cloudflare 基础设施会出现在触发它的智能体操作之下。当子级工作在活跃的追踪上下文中运行时，受支持的子智能体调用会嵌套在父级之下。这样你就能顺着一轮对话，从父智能体，经由被委派的工作，一路追踪到每个智能体所用的 Cloudflare 资源。

如何启用智能体追踪

首先，在 Worker 的项目配置 wrangler.jsonc 中启用追踪：

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

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

很快，任何符合 OpenTelemetry 的工具包都能开箱即用

我们正在努力在 Workers 内部直接支持 OpenTelemetry API。这意味着，已经输出 OpenTelemetry 生成式 AI 语义约定 span 的框架，无需等待 Cloudflare 专用适配器，就能在 Agents 视图中将其可视化。当这些 span 包含标准的智能体和对话标识符时，Agents 视图就能像对待我们内置的集成一样，把它们归并成智能体和会话。Cloudflare 目前已经可以导出 OpenTelemetry 数据；这一改动补上了另一个方向，即接收在 Workers 内部生成的标准遥测数据。

使用 OpenTelemetry 导出追踪

你的智能体遥测数据不会被锁定在 Cloudflare 内。你可以在 Worker 的 Wrangler 配置文件中配置一个目的地，将追踪导出到任何兼容 OTLP 的提供方。由于每条追踪都是结构化的，帮助你调试智能体的同一份数据，也可以用于评估、分析和 token 用量报表。这意味着追踪不只是出问题时才去查看的东西，也是改进智能体质量、性能和成本的反馈回路。

定价

智能体追踪建立在 Workers 追踪之上，因此定价很简单。Agents 视图显示的是你的智能体的操作，但完整的 Worker 追踪可能还包含来自 SDK 内部和其他 Worker 级操作的额外 span。要查看完整追踪，请点击“View in Observability”。

每个 span 都算作一次可观测性事件，而不仅仅是 Agents 视图中可见的那些。目前处于测试阶段，所有追踪均免费。自 2026 年 10 月 1 日起，追踪定价将并入现有的 Workers Observability 定价：

开始使用

追踪是第一块拼图，我们将继续把 Cloudflare Agents 打造成一个让你轻松部署、观察并持续改进所运行的每一个智能体的地方。

想看看你的智能体在做什么？请查阅我们的文档，为你的智能体启用可观测性，然后前往 Agents 仪表盘检查你的第一条追踪，或回放一次会话。