介绍：Cloudflare Agents
Nevi Shah, Matt Simpson, 和 Fred Schott
我们正在整合在 Cloudflare 上部署和管理托管代理所需的一切，从可观测性开始。
过去九年，我们一直在构建开发者平台，而代理正是完美的用例。它们实际上只是另一种类型的应用程序，但构建它们所需的一切——模型访问、持久运行时、编排、沙箱执行、持久存储——恰好正是我们已经构建好的。
现在，我们让在 Cloudflare 上部署和管理代理变得更加容易。Cloudflare Agents 将你所有已部署的代理会话整合到一个体验中，展示关键信息和洞察，帮助你了解代理在大规模运行时的表现。
第一站：代理追踪
我们推出了代理追踪，以便更直接地观察和洞察代理行为。借助代理感知的追踪，你现在可以准确了解代理在做什么以及成本是多少：每一次模型调用、工具执行和令牌消耗都会在这里被测量和呈现。代理追踪今天上线，支持兼容 OpenTelemetry 的代理框架，包括Think、Flue和AI SDK等。
代理追踪只是开始。一旦你能够观察代理的思考过程和实际行为，就可以开始分析这些数据并做出真正的改进。将这些数据接入你的代理开发生命周期，你就能拥有自主、自我改进的代理。这就是 Cloudflare Agents 的愿景：一个地方，用于部署、观察并持续改进你运行的每一个代理。
让代理可观测
一个代理可能返回 HTTP 200，但仍然失败。它可能选择了错误的工具，将过时的上下文传递给子代理，或者在重试循环中消耗令牌。传统的应用遥测可能显示 API 请求或数据库查询，但不会显示导致这些行为的代理行为。
代理级遥测应该回答以下问题：
- 时间花在了哪里：模型、工具还是基础设施？
- 这一轮是否因审批而暂停？
- 代理调用了哪个模型，这一轮使用了多少令牌？
- 代理是否选择了正确的工具？
- 当工具调用外部 API 时，是收到了成功响应还是超时？
- 哪个子代理执行了工作，该工作如何影响最终响应？
Workers 追踪 已经覆盖了基础设施层，包括 fetch 调用、KV 读取和 D1 查询，但到目前为止，在 Workers 上运行的代理的追踪只包含这些基础设施跨度，而没有围绕它们的代理操作。代理追踪填补了这一空白，在已捕获的 Workers 数据之外，增加了代理调用、模型调用、工具执行、审批事件以及受支持的子代理调用的跨度。您还可以获得附加为元数据的上下文，例如模型和令牌使用情况。
Flue将代理追踪发送到 Cloudflare，让您可以在仪表板中可视化它们，或将其导出到受支持的
AI SDK
OpenTelemetry 兼容目的地。## 所有代理集中在一处
Cloudflare 仪表板现在有一个专门的 Agents 视图，列出观察到的代理及其追踪，以及运行、会话、实例和报告的令牌使用情况。
当您打开一个代理时，您可以通过两种方式可视化、理解和调试它的行为：
重放会话以查看所有轮次中捕获的上下文查看追踪以检查每一轮的执行情况
重放会话
消息选项卡组装了给定轮次的完整对话：系统指令、用户消息、模型的思考、工具调用及其参数和结果，以及最终响应。这是对记录数据的重放，而不是对代理的重新执行。这使您可以捕获格式错误的工具参数，查看选择工具时可用的上下文，理解对子代理的交接，或识别早期轮次如何影响后续结果。
在此示例中，用户要求计划一次为期两天的里斯本之旅。您可以看到模型的推理，观察它调用 destination_researcher
两次（它重试了），读取工具结果，并跟随它的思考过程，因为它继续构建行程。如果代理做出了错误的决定，您可以在这里找到它。
具体记录什么取决于您的 harness 或框架。对于 Think、Flue 和 AI SDK，storeMessages
和 storeTools
控制是否捕获消息和工具负载。当这些数据可能包含个人信息、秘密或其他敏感数据时，您可以关闭 负载记录。
检查追踪
追踪选项卡显示执行瀑布，您可以在其中确定时间如何花费，并将代理操作连接到 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
:每一层的模型调用，附有持续时间和提供商报告的令牌使用情况。第一次调用（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、服务绑定和fetch调用等绑定进行了检测，因此工具使用的Cloudflare基础设施会出现在触发它的代理操作下。当子工作在当前追踪上下文中运行时，受支持的子代理调用会嵌套在父代理下。这使您可以从父代理开始，通过委派的工作，跟踪到每个代理使用的Cloudflare资源。
D1## 如何启用代理追踪
首先，在Worker的项目配置文件wrangler.jsonc中启用追踪：```
{
"observability": {
"traces": {
"enabled": true, }
}
}
之后的设置取决于技术栈
|
|
---|---|
通过其追踪集成发出代理、对话、轮次、模型和工具遥测数据。 | |
使用 Cloudflare 的包装 SDK | |
使用我们的
OpenTelemetry 的生成式 AI 语义约定 |
### 很快，任何符合 OpenTelemetry 的工具包都将直接可用
我们正在努力在 Workers 内部直接支持 OpenTelemetry API。这意味着已经发出 OpenTelemetry [生成式 AI 语义约定](https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/) 跨度（spans）的框架将能够在 Agents 视图中可视化这些跨度，而无需等待 Cloudflare 特定的适配器。当这些跨度包含标准的代理和对话标识符时，Agents 视图可以像我们的内置集成一样将它们分组为代理和会话。Cloudflare 已经可以导出 OpenTelemetry 数据；这增加了另一个方向，即接受在 Workers 内部生成的标准遥测数据。
## 使用 OpenTelemetry 导出追踪
您的代理遥测数据并不局限于 Cloudflare。您可以通过在 Worker 的 Wrangler 中配置 [导出追踪到任何兼容 OTLP 的提供商](https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/)
[__目标__](https://dash.cloudflare.com/?to=/:account/observability/destinations)
[。由于每个追踪都是结构化的，帮助您调试代理的相同数据也可以用于评估、分析和令牌使用报告。这意味着追踪不仅是在出现问题时检查的工具，也是改进代理质量、性能和成本的反馈循环。](https://dash.cloudflare.com/?to=/:account/observability/destinations)
__配置文件__## 定价
代理追踪基于 Workers 追踪构建，因此定价简单明了。Agents 视图显示代理的操作，但完整的 Worker 追踪可能包含来自 SDK 内部和其他 Worker 级操作的额外跨度。要查看完整追踪，请点击“在 Observability 中查看”。
每个跨度都计为一次可观测性事件，而不仅仅是 Agents 视图中可见的那些。目前所有追踪在测试期间都是免费的。从 2026 年 10 月 1 日开始，追踪定价将包含在现有的 Workers Observability 定价中：
|
|
|
---|---|---|
| 每天 200,000 | 3 天 |
| 每月包含 2000 万；每额外 100 万事件 $0.60 | 7 天 |
## 开始使用
追踪是我们持续将 Cloudflare Agents 打造成一个让您轻松部署、观察和持续改进您运行的每个代理的地方的第一部分。
准备好查看您的代理在做什么了吗？查看我们的 [文档](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/) 以在您的代理上启用可观测性，并前往
[Agents 仪表板](https://dash.cloudflare.com/?to=/:account/agents) 检查您的第一个追踪或重放会话。