Cloudflare 推出 Agents 平台：统一管理大规模 Agent 会话

我们在过去九年里一直在构建一个开发者平台，而 Agent 正是完美的用例。Agent 其实就是一种应用类型，但构建它所需的一切——模型访问、持久化运行时、编排、沙箱执行、持久化存储——恰好正是我们已经构建好的能力。

现在，我们让在 Cloudflare 上部署和管理 Agent 变得更加容易。Cloudflare Agents 将你所有已部署的 Agent 会话汇聚到统一的体验中，呈现关键信息和洞察，帮助你了解 Agent 在规模化场景下的表现。

第一站：Agent 追踪

我们推出 Agent 追踪功能，带来更直接的可见性和对 Agent 行为的洞察。通过 Agent 感知的追踪，你现在可以精确了解 Agent 在做什么、花费了多少成本：每一次模型调用、工具执行和 token 消耗都被记录并在此呈现。Agent 追踪今天正式发布，支持 OpenTelemetry 兼容的 Agent 框架，包括 Think、Flue 和 AI SDK，后续还会有更多。

Agent 追踪只是起点。一旦你能够观察 Agent 的思维过程和真实世界行为，就可以开始分析这些数据并进行真正的改进。将这些数据接入 Agent 开发生命周期，你就拥有了自主的、自我改进的 Agent。这就是 Cloudflare Agents 的愿景：一个统一的地方来部署、观察并持续改进你运行的每一个 Agent。

让 Agent 可观测

一个 Agent 可能返回 HTTP 200 但仍然失败了。它可能选错了工具、向子 Agent 传递了过时的上下文，或者在重试循环中消耗了 token。传统的应用遥测可能只显示 API 请求或数据库查询，但看不到导致这一结果背后的 Agent 行为。

Agent 级别的遥测应该回答以下问题：

时间花在哪里了：是模型、工具还是基础设施？

这一轮是否因需要审批而暂停？

Agent 调用了哪个模型，这一轮消耗了多少 token？

Agent 是否选择了正确的工具？

当工具调用外部 API 时，收到了成功响应还是超时了？

哪个子 Agent 执行了工作，这些工作如何影响了最终响应？

Workers 追踪已经覆盖了基础设施层，包括 fetch 调用、KV 读取和 D1 查询，但直到现在，运行在 Workers 上的 Agent 的追踪只包含那些基础设施 span，而没有包裹它们的 Agent 操作。Agent 追踪填补了这个空白，在已捕获的 Workers 数据基础上新增了 Agent 调用、模型调用、工具执行、审批事件和支持的子 Agent 调用等 span。你还可以获得附加在元数据上的模型和 token 使用量等上下文信息。

从今天开始，使用 Think、Flue 和 AI SDK 构建的 Agent 将向 Cloudflare 发送 Agent 追踪，让你可以在仪表板中可视化它们，或将它们导出到支持的 OpenTelemetry 兼容目标。

你所有的 Agent，尽在一处

Cloudflare 仪表板现在有了专门的 Agents 视图，列出已观察的 Agent 及其追踪，以及运行、会话、实例和报告的 token 使用量。

当你打开一个 Agent 时，可以通过两种方式可视化、理解和调试它的行为：

重放一个会话，回顾所有轮次中捕获的上下文

查看一条追踪，检查每一轮的执行过程

Messages（消息）标签页为给定轮次整合了完整的对话：系统指令、用户消息、模型的思考过程、工具调用及其参数和结果，以及最终响应。这是对记录数据的重放，不是对 Agent 的重新执行。这让你能够发现格式错误的工具参数、查看工具被选中时可用的上下文、理解向子 Agent 的移交，或识别早期轮次如何影响了后续结果。

在这个例子中，用户要求规划一次为期两天的里斯本之旅。你可以看到模型的推理过程，观察它调用 destination_researcher 两次（它重试了），阅读工具结果，并跟随它的思考继续构建行程。如果 Agent 做出了错误的决定，你就在这里找到答案。

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

Traces（追踪）标签页展示了执行瀑布图，你可以在其中确定时间花费在哪里，并将 Agent 操作与 Workers 基础设施关联起来。

在这条追踪中，一个 Travel_Planner Agent 委托给一个 itinerary_builder 子 Agent，后者调用了模型、运行了工具、访问了 D1 并写入 KV——所有这些都在一个瀑布图中可见：

invoke_agent TravelPlanner：父 Agent 调用，总耗时 2.72 分钟。附加了 Agent 类、会话和 Durable Object 的标识符，以便你在不同追踪之间进行关联。

invoke_agent itinerary_builder：子 Agent，嵌套在父 Agent 下，耗时 1.83 分钟。

chat @cf/zai-org/glm-4.7-flash：各层的模型调用，附加了耗时和提供商报告的 token 使用量。第一次调用（17.59 秒）是父 Agent 的路由决策；子 Agent 在其下有自己的调用。

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 基础设施会显示在触发它的 Agent 操作下方。当子工作运行在活跃追踪上下文中时，支持的子 Agent 调用会嵌套在父级下方。这让你能够跟随一轮对话，从父 Agent 开始，穿过委托的工作，直达每个 Agent 使用的 Cloudflare 资源。

如何启用 Agent 追踪

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

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

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

通过追踪集成发出 Agent、对话、轮次、模型和工具遥测。

用 Cloudflare 的 wrapAISDK() 适配器包装 SDK。

使用我们的自定义 span API 并遵循 OpenTelemetry 的生成式 AI 语义约定来为你的 Agent 插桩。

很快，任何 OpenTelemetry 兼容的工具包都将开箱即用

我们正在努力在 Workers 内部直接支持 OpenTelemetry API。这意味着已经发出 OpenTelemetry 生成式 AI 语义约定 span 的框架将能够直接在 Agents 视图中可视化它们，无需等待 Cloudflare 特定的适配器。当这些 span 包含标准的 Agent 和会话标识符时，Agents 视图可以将它们分组为 Agent 和会话，就像我们的内置集成一样。Cloudflare 已经可以导出 OpenTelemetry 数据；这补充了另一个方向——接受在 Workers 内部生成的标准遥测。

用 OpenTelemetry 导出追踪

你的 Agent 遥测数据不会被锁定在 Cloudflare 中。通过在 Worker 的 Wrangler 配置文件中配置目标，你可以将追踪导出到任何 OTLP 兼容的提供商。因为每条追踪都是结构化的，帮助你调试 Agent 的相同数据也可以驱动评估、分析和 token 使用量报告。这意味着追踪不仅仅是出了问题才检查的东西，也是改进 Agent 质量、性能和成本的反馈循环。

Agent 追踪构建在 Workers 追踪之上，所以定价简单明了。Agents 视图显示你的 Agent 操作，但完整的 Worker 追踪可能包含来自 SDK 内部和其他 Worker 级操作的额外 span。要查看完整追踪，请点击"View in Observability"。

每个 span 都被计为一条可观测事件，而不仅仅是 Agents 视图中可见的那些。所有追踪目前在 beta 阶段免费。2026 年 10 月 1 日起，追踪定价将纳入现有 Workers Observability 定价中：

每月包含 2000 万次；超出部分每百万事件 0.60 美元

追踪只是第一步，我们将持续构建 Cloudflare Agents，让它成为你轻松部署、观察并持续改进每一个 Agent 运行的地方。

准备好了解你的 Agent 在做什么了吗？查看我们的文档来为你的 Agent 启用可观测性，然后前往 Agents 仪表板检查你的第一条追踪或重放一个会话。