# Cloudflare 推出 Agents 平台，率先上线智能体追踪功能 - 来源：Cloudflare Blog - 作者：Nevi Shah - 发布时间：2026-08-04 21:00 - AIHOT 分数：66 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmseq167r12m1ro2eqjsdn6wd - 原文链接：https://blog.cloudflare.com/agents-on-cloudflare ## 精选理由 Agent tracing 的价值在于把模型调用和工具执行与 Cloudflare 基础设施 span 关联，代理开发中常见的选择错误工具或重试循环问题现在可直接定位。 ## AI 摘要 Cloudflare 推出 Cloudflare Agents，将部署在平台上的智能体会话统一到一个视图中，并率先上线 agent tracing 功能。该功能支持 OpenTelemetry 兼容的 Think、Flue 和 AI SDK 等智能体框架，可测量每次模型调用、工具执行和 token 消耗。 ## 正文 我们正在把在 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： 之后的配置取决于你所用的技术栈 很快，任何符合 OpenTelemetry 标准的工具包都能直接开箱即用。 我们正在努力在 Workers 中直接支持 OpenTelemetry API。这意味着，已经发出 OpenTelemetry 生成式 AI 语义约定 span 的框架，无需等待 Cloudflare 特定的适配器，就能在 Agents 视图中可视化这些 span。当这些 span 包含标准的智能体和对话标识符时，Agents 视图可以像处理我们的内置集成一样，将它们分组为智能体会话。Cloudflare 已经可以导出 OpenTelemetry 数据；这次新增的是另一个方向——接受在 Workers 内部生成的标准遥测数据。 使用 OpenTelemetry 导出追踪 你的智能体遥测数据不会被锁定在 Cloudflare 中。你可以通过在 Worker 的 Wrangler 配置文件中配置目标地址，将追踪导出到任何兼容 OTLP 的提供商。由于每条追踪都是结构化的，帮助你调试智能体的同一份数据，也可以用于评估、分析和 token 用量报告。这意味着，追踪不只是出问题时才检查的东西，更是改进智能体质量、性能和成本的反馈循环。 定价 智能体追踪基于 Workers 追踪构建，因此定价很直接。Agents 视图显示智能体的操作，但完整的 Worker 追踪可能包含来自 SDK 内部和其他 Worker 级操作的额外 span。要查看完整追踪，请点击“在可观测性中查看”。 每个 span 都计为一次可观测性事件，而不仅仅是 Agents 视图中可见的那些。目前，所有追踪在测试期间均免费。从 2026 年 10 月 1 日起，追踪定价将纳入现有的 Workers 可观测性定价中： 追踪只是我们持续将 Cloudflare Agents 打造成一个让你轻松部署、观测并持续改进所运行的每一个智能体的平台的第一步。 准备好查看你的智能体在做什么了吗？查看我们的文档，为你的智能体启用可观测性，然后前往 Agents 仪表盘检查你的第一条追踪或重放一个会话。