介绍：Cloudflare 代理
我们将为您提供在 Cloudflare 上部署和管理托管代理所需的一切，首要的是可观察性。
在过去的九年中，我们构建了一个开发者平台，而代理正是一个完美的用例。它们实质上只是另一种类型的应用程序，构建它们所需的——[模型访问](https://developers.cloudflare.com/ai-gateway/)、[持久化运行时](https://developers.cloudflare.com/durable-objects/)、[编排](https://developers.cloudflare.com/workflows/)、[沙箱执行](https://developers.cloudflare.com/sandbox/)和[持久存储](https://developers.cloudflare.com/r2/)——正是我们已经构建的内容。
现在，我们使得在 Cloudflare 上部署和管理您的代理变得更加简单。Cloudflare 代理将所有已部署的代理会话汇聚到一个单一的体验中，呈现关于您的代理如何在规模上表现的关键信息和见解。
## 第一站：代理追踪
我们推出了 [**代理追踪**](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/)，为您提供更直接的可见性和对代理行为的洞察。通过对代理的追踪，您现在可以准确了解您的代理正在做什么以及其成本：每一个模型调用、工具执行和令牌都被测量并在这里呈现。代理追踪今天推出，支持 OpenTelemetry 兼容的代理工具，包括 [Think](https://developers.cloudflare.com/agents/harnesses/think/)、[Flue](https://flueframework.com/docs/ecosystem/deploy/cloudflare/) 和 [AI SDK](https://ai-sdk.dev/)，以及更多。
代理追踪只是个开始。一旦您能够观察到代理的思维过程和现实世界的行为，您便可以开始分析这些数据，并进行真正的改进。将这些数据插入您的 [代理开发生命周期](http://blog.cloudflare.com/agent-development-lifecycle)，您便拥有了自主学习、自我改善的代理。这就是 Cloudflare 代理的愿景：一个可以部署、观察和不断改进您运行的每个代理的地方。
## 让代理可观察
一个代理可能返回 HTTP 200，但仍然会失败。它可能选择了错误的工具，将过时的上下文传递给子代理，或者在重试循环中消耗令牌。传统的应用遥测可能显示 API 请求或数据库查询，但并不会揭示导致这些请求的代理行为。
代理级别的遥测应该回答如下问题：
- 时间是如何消耗的：模型、工具，还是基础设施？
- 回合是否暂停等待批准？
- 代理调用了哪个模型，并且这个回合使用了多少令牌？
- 代理选择了正确的工具吗？
- 当工具调用外部 API 时，它是成功响应还是超时？
- 哪个子代理执行了这个工作，这个工作对最终响应有何影响？
[Workers 追踪](https://developers.cloudflare.com/workers/observability/traces/) 已经覆盖了基础设施层，包括获取调用、KV 读取和 D1 查询，但直到现在，运行在 Workers 上的代理的追踪只包含这些基础设施的跨度，而没有代理操作。代理追踪填补了这一空白，增添了代理调用、模型调用、工具执行、批准事件以及支持的子代理调用的跨度，连同已经捕获的 Workers 数据。您还将获得附加的元数据，如模型和令牌使用情况。
从今天开始，使用 [Think](https://developers.cloudflare.com/agents/harnesses/think/)、[Flue](https://flueframework.com/docs/ecosystem/deploy/cloudflare/) 和 [AI SDK](https://ai-sdk.dev/) 构建的代理将向 Cloudflare 发送代理追踪，让您在仪表板中可视化它们，或导出到支持的 [OpenTelemetry 兼容目标](https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/)。
## 所有代理集中管理
Cloudflare 仪表板现在提供了一个专门的代理视图，列出了观察到的代理及其追踪信息，配合运行、会话、实例和报告的令牌使用情况。
当您打开一个代理时，可以通过两种方式可视化、理解和调试它的工作：
- **重播会话**，回顾所有回合中的上下文
- **查看追踪**，检查每个回合的执行情况
### 重播会话
**消息**标签整合了给定回合的全部对话：系统指令、用户消息、模型的思维、工具调用及其参数和结果，以及最终响应。这是历史数据的重播，而不是代理的重新执行。这使您能够捕捉到错误的工具参数，查看在选择工具时可用的上下文，理解子代理之间的交接，或识别前一个回合如何影响后一个结果。
在这个例子中，用户请求规划一次到里斯本的两日旅行。您可以看到模型的推理过程，观察它调用了两次 `destination_researcher`（它进行了重试），读取工具结果，并跟随它的思维过程，构建行程。如果代理做出了错误的决定，这正是您会发现它的地方。
确切记录哪些内容取决于您的工具或框架。对于 Think、Flue 和 AI SDK，`storeMessages` 和 `storeTools` 控制是否捕获消息和工具有效负载。您可以在该数据可能包含个人信息、机密或其他敏感数据时关闭 [有效负载记录](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/#store-payloads-1)。
### 检查追踪
追踪标签显示执行流水线，您可以确定时间的消耗情况，并将代理操作与 Workers 基础设施连接起来。
在这个追踪中，一个 `Travel_Planner` 代理委托给一个 `itinerary_builder` 子代理，该子代理调用一个模型、运行一个工具、命中 D1，并写入 KV——所有这些在一个单一的流水线中可见：
- `invoke_agent TravelPlanner`: 父代理调用，总共 2.72 分钟。附带代理类、对话和持久对象的标识符，以便您可以在追踪中关联。
- `invoke_agent itinerary_builder`: 子代理，嵌套在父代理下，耗时 1.83 分钟。
- `chat @cf/zai-org/glm-4.7-flash`: 在每个级别的模型调用，附带时长和供应商报告的令牌使用情况。首次调用（17.59s）是父代理的路由决定；子代理在其下做了自己的调用。
- `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 追踪已经仪器化如 [KV](https://developers.cloudflare.com/kv/)、[D1](https://developers.cloudflare.com/d1/) 、持久对象、服务绑定和获取调用这样的绑定，因此工具使用的 Cloudflare 基础设施在触发它的代理操作下出现。支持的子代理调用在父代理的活动追踪上下文中嵌套。当您跟随一个回合的父代理、委派的工作，以及每个代理使用的 Cloudflare 资源时，这种方式将帮助您理解整个过程。
## 如何启用代理追踪
首先，在 `wrangler.jsonc` 中[启用追踪](https://developers.cloudflare.com/workers/observability/traces/)，这是 Workers 的项目配置：
首次设置之后，依据框架的堆栈的具体设置而有所不同。
### 很快，任何兼容 OpenTelemetry 的工具包都可以正常工作
我们致力于在 Workers 中直接支持 OpenTelemetry API。这意味着已经发出 OpenTelemetry [生成 AI 语义约定](https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/) 的框架将能够在代理视图中可视化它们，而无需等待 Cloudflare 特定的适配器。当这些跨度包含标准的代理和对话标识符时，代理视图能将它们分组为代理和会话，就像我们的内置集成那样。Cloudflare 已经能够导出 OpenTelemetry 数据；这通过接受在 Workers 内部生成的标准遥测添加了另一个方向。
## 使用 OpenTelemetry 导出追踪
您的代理遥测并未锁定在 Cloudflare 中。您可以 [将追踪导出到任何兼容 OTLP 的](https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/) 提供商，通过在您的 Worker 的 Wrangler [配置文件](https://dash.cloudflare.com/?to=/:account/observability/destinations) 中配置一个 [目标](https://dash.cloudflare.com/?to=/:account/observability/destinations)。由于每个追踪都是结构化的，帮助您调试代理的数据也能用于评估、分析和令牌使用情况报告。这意味着追踪不仅是您在出现问题时检查的内容，同时也是一个反馈回路，帮助您提高代理的质量、性能和成本。
## 定价
代理追踪基于 Workers 追踪，因此定价很简单。代理视图显示您代理的操作，但完整的 Worker 追踪可能包括来自 SDK 内部和其他 Worker 级操作的额外跨度。要查看完整的追踪，请单击“在可观察性中查看”。
每个跨度都被视为一次可观察性事件，而不仅仅是代理视图中可见的事件。所有追踪目前在 beta 期间是免费的。自 2026 年10月1日起，追踪定价将作为现有 Workers 可观察性定价的一部分纳入：
## 开始使用
追踪是我们不断将 Cloudflare 代理构建为轻松部署、观察和持续改进每个您运行的代理的地方的第一步。
准备好了解您的代理在做什么了吗？查看我们的 [文档](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/) 以启用您的代理可观察性，并前往 [Agents 仪表板](https://dash.cloudflare.com/?to=/:account/agents) 检查您的第一次追踪或重播会话。
---
原文链接：[点击查看](https://blog.cloudflare.com/agents-on-cloudflare/)
在过去的九年中，我们构建了一个开发者平台，而代理正是一个完美的用例。它们实质上只是另一种类型的应用程序，构建它们所需的——[模型访问](https://developers.cloudflare.com/ai-gateway/)、[持久化运行时](https://developers.cloudflare.com/durable-objects/)、[编排](https://developers.cloudflare.com/workflows/)、[沙箱执行](https://developers.cloudflare.com/sandbox/)和[持久存储](https://developers.cloudflare.com/r2/)——正是我们已经构建的内容。
现在，我们使得在 Cloudflare 上部署和管理您的代理变得更加简单。Cloudflare 代理将所有已部署的代理会话汇聚到一个单一的体验中，呈现关于您的代理如何在规模上表现的关键信息和见解。
## 第一站：代理追踪
我们推出了 [**代理追踪**](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/)，为您提供更直接的可见性和对代理行为的洞察。通过对代理的追踪，您现在可以准确了解您的代理正在做什么以及其成本：每一个模型调用、工具执行和令牌都被测量并在这里呈现。代理追踪今天推出，支持 OpenTelemetry 兼容的代理工具，包括 [Think](https://developers.cloudflare.com/agents/harnesses/think/)、[Flue](https://flueframework.com/docs/ecosystem/deploy/cloudflare/) 和 [AI SDK](https://ai-sdk.dev/)，以及更多。
代理追踪只是个开始。一旦您能够观察到代理的思维过程和现实世界的行为，您便可以开始分析这些数据，并进行真正的改进。将这些数据插入您的 [代理开发生命周期](http://blog.cloudflare.com/agent-development-lifecycle)，您便拥有了自主学习、自我改善的代理。这就是 Cloudflare 代理的愿景：一个可以部署、观察和不断改进您运行的每个代理的地方。
## 让代理可观察
一个代理可能返回 HTTP 200，但仍然会失败。它可能选择了错误的工具，将过时的上下文传递给子代理，或者在重试循环中消耗令牌。传统的应用遥测可能显示 API 请求或数据库查询，但并不会揭示导致这些请求的代理行为。
代理级别的遥测应该回答如下问题：
- 时间是如何消耗的：模型、工具，还是基础设施？
- 回合是否暂停等待批准？
- 代理调用了哪个模型，并且这个回合使用了多少令牌？
- 代理选择了正确的工具吗？
- 当工具调用外部 API 时，它是成功响应还是超时？
- 哪个子代理执行了这个工作，这个工作对最终响应有何影响？
[Workers 追踪](https://developers.cloudflare.com/workers/observability/traces/) 已经覆盖了基础设施层，包括获取调用、KV 读取和 D1 查询，但直到现在，运行在 Workers 上的代理的追踪只包含这些基础设施的跨度，而没有代理操作。代理追踪填补了这一空白，增添了代理调用、模型调用、工具执行、批准事件以及支持的子代理调用的跨度，连同已经捕获的 Workers 数据。您还将获得附加的元数据，如模型和令牌使用情况。
从今天开始，使用 [Think](https://developers.cloudflare.com/agents/harnesses/think/)、[Flue](https://flueframework.com/docs/ecosystem/deploy/cloudflare/) 和 [AI SDK](https://ai-sdk.dev/) 构建的代理将向 Cloudflare 发送代理追踪，让您在仪表板中可视化它们，或导出到支持的 [OpenTelemetry 兼容目标](https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/)。
## 所有代理集中管理
Cloudflare 仪表板现在提供了一个专门的代理视图，列出了观察到的代理及其追踪信息，配合运行、会话、实例和报告的令牌使用情况。
当您打开一个代理时，可以通过两种方式可视化、理解和调试它的工作：
- **重播会话**，回顾所有回合中的上下文
- **查看追踪**，检查每个回合的执行情况
### 重播会话
**消息**标签整合了给定回合的全部对话：系统指令、用户消息、模型的思维、工具调用及其参数和结果，以及最终响应。这是历史数据的重播，而不是代理的重新执行。这使您能够捕捉到错误的工具参数，查看在选择工具时可用的上下文，理解子代理之间的交接，或识别前一个回合如何影响后一个结果。
在这个例子中，用户请求规划一次到里斯本的两日旅行。您可以看到模型的推理过程，观察它调用了两次 `destination_researcher`（它进行了重试），读取工具结果，并跟随它的思维过程，构建行程。如果代理做出了错误的决定，这正是您会发现它的地方。
确切记录哪些内容取决于您的工具或框架。对于 Think、Flue 和 AI SDK，`storeMessages` 和 `storeTools` 控制是否捕获消息和工具有效负载。您可以在该数据可能包含个人信息、机密或其他敏感数据时关闭 [有效负载记录](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/#store-payloads-1)。
### 检查追踪
追踪标签显示执行流水线，您可以确定时间的消耗情况，并将代理操作与 Workers 基础设施连接起来。
在这个追踪中，一个 `Travel_Planner` 代理委托给一个 `itinerary_builder` 子代理，该子代理调用一个模型、运行一个工具、命中 D1，并写入 KV——所有这些在一个单一的流水线中可见：
- `invoke_agent TravelPlanner`: 父代理调用，总共 2.72 分钟。附带代理类、对话和持久对象的标识符，以便您可以在追踪中关联。
- `invoke_agent itinerary_builder`: 子代理，嵌套在父代理下，耗时 1.83 分钟。
- `chat @cf/zai-org/glm-4.7-flash`: 在每个级别的模型调用，附带时长和供应商报告的令牌使用情况。首次调用（17.59s）是父代理的路由决定；子代理在其下做了自己的调用。
- `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 追踪已经仪器化如 [KV](https://developers.cloudflare.com/kv/)、[D1](https://developers.cloudflare.com/d1/) 、持久对象、服务绑定和获取调用这样的绑定，因此工具使用的 Cloudflare 基础设施在触发它的代理操作下出现。支持的子代理调用在父代理的活动追踪上下文中嵌套。当您跟随一个回合的父代理、委派的工作，以及每个代理使用的 Cloudflare 资源时，这种方式将帮助您理解整个过程。
## 如何启用代理追踪
首先，在 `wrangler.jsonc` 中[启用追踪](https://developers.cloudflare.com/workers/observability/traces/)，这是 Workers 的项目配置：
首次设置之后，依据框架的堆栈的具体设置而有所不同。
### 很快，任何兼容 OpenTelemetry 的工具包都可以正常工作
我们致力于在 Workers 中直接支持 OpenTelemetry API。这意味着已经发出 OpenTelemetry [生成 AI 语义约定](https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/) 的框架将能够在代理视图中可视化它们，而无需等待 Cloudflare 特定的适配器。当这些跨度包含标准的代理和对话标识符时，代理视图能将它们分组为代理和会话，就像我们的内置集成那样。Cloudflare 已经能够导出 OpenTelemetry 数据；这通过接受在 Workers 内部生成的标准遥测添加了另一个方向。
## 使用 OpenTelemetry 导出追踪
您的代理遥测并未锁定在 Cloudflare 中。您可以 [将追踪导出到任何兼容 OTLP 的](https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/) 提供商，通过在您的 Worker 的 Wrangler [配置文件](https://dash.cloudflare.com/?to=/:account/observability/destinations) 中配置一个 [目标](https://dash.cloudflare.com/?to=/:account/observability/destinations)。由于每个追踪都是结构化的，帮助您调试代理的数据也能用于评估、分析和令牌使用情况报告。这意味着追踪不仅是您在出现问题时检查的内容，同时也是一个反馈回路，帮助您提高代理的质量、性能和成本。
## 定价
代理追踪基于 Workers 追踪，因此定价很简单。代理视图显示您代理的操作，但完整的 Worker 追踪可能包括来自 SDK 内部和其他 Worker 级操作的额外跨度。要查看完整的追踪，请单击“在可观察性中查看”。
每个跨度都被视为一次可观察性事件，而不仅仅是代理视图中可见的事件。所有追踪目前在 beta 期间是免费的。自 2026 年10月1日起，追踪定价将作为现有 Workers 可观察性定价的一部分纳入：
## 开始使用
追踪是我们不断将 Cloudflare 代理构建为轻松部署、观察和持续改进每个您运行的代理的地方的第一步。
准备好了解您的代理在做什么了吗？查看我们的 [文档](http://developers.cloudflare.com/agents/runtime/operations/observability/tracing/) 以启用您的代理可观察性，并前往 [Agents 仪表板](https://dash.cloudflare.com/?to=/:account/agents) 检查您的第一次追踪或重播会话。
---
原文链接：[点击查看](https://blog.cloudflare.com/agents-on-cloudflare/)
评论
暂无评论。