Cloudflare于8月4日推出Cloudflare Agents，把已部署的AI Agent会话、运行记录和追踪数据集中到同一个管理界面。平台第一阶段重点上线Agent Tracing，用于记录模型调用、工具执行、Token消耗、审批事件以及支持的子Agent调用。
传统应用监控主要观察HTTP状态、数据库查询和基础设施延迟，但Agent即使返回200状态也可能选错工具、使用过期上下文或在重试循环中持续消耗Token。Cloudflare这次补充的是Agent行为层，而不是再提供一套只看服务器CPU和请求耗时的普通监控。
Agents视图集中展示远程会话
Cloudflare控制台新增独立的Agents视图，可列出已经被观察到的Agent、运行、会话、实例、追踪记录和上报的Token用量。团队不必先从多套日志中拼接某次任务发生了什么。
打开具体Agent后，运维人员可以选择回放会话，查看一个任务各轮次记录的上下文，也可以进入Trace页面分析单轮执行瀑布。会话回放读取的是已记录数据，并不会重新执行Agent或再次调用外部工具。
平台当前以可观测性作为入口，Cloudflare对后续方向的描述是部署、观察和持续改进。也就是说，现阶段最成熟的新增能力是追踪与诊断，不能把此次发布理解为所有Agent框架都已经获得完全托管和自动优化。
模型调用和工具执行进入同一条Trace
Agent Tracing会为Agent调用、模型请求、工具执行、审批事件和支持的子Agent调用增加追踪跨度，并附带模型名称、Token用量和持续时间等元数据。
Cloudflare原有Workers Tracing已经能够记录fetch、KV、D1、Durable Objects和服务绑定等基础设施操作。新能力把这些底层跨度放回触发它们的Agent和工具调用之下，让一次任务可以从父Agent追到子Agent，再追到数据库或键值存储。
这种关联对故障定位很关键。团队能够区分延迟来自模型、工具还是云端资源，也能看到工具调用外部API后究竟成功、超时还是触发重试，避免只根据最终响应时间猜测原因。
首批支持三类Agent框架
Agent Tracing首批支持Think、Flue和AI SDK等OpenTelemetry兼容工具链。Think与Flue通过各自的追踪集成上报Agent、会话、轮次、模型和工具数据，AI SDK则需要使用Cloudflare提供的适配器。
使用自定义Agent框架的团队可以通过自定义跨度API，并按照OpenTelemetry生成式AI语义约定接入。Cloudflare还计划在Workers中直接支持OpenTelemetry API，让能够输出标准跨度的框架以后不必等待专用适配。
目前仍存在兼容边界。子Agent只有在活跃追踪上下文内运行时才能正确嵌套，实际能记录多少消息和工具负载也取决于框架配置，部署前需要验证会话关联是否完整。
会话回放同时带来敏感数据风险
Messages页面可以组合系统指令、用户消息、模型过程、工具参数与结果以及最终响应，帮助团队发现错误参数、上下文污染、子任务交接异常和重复调用。
这些数据也可能包含个人信息、密钥、内部URL和业务记录。Think、Flue与AI SDK提供消息和工具负载记录开关，涉及敏感数据时可以关闭对应载荷采集，只保留必要的结构化追踪。
团队启用前需要重新审视日志保留、访问权限和脱敏策略。Agent可观测性越深入，记录的数据越接近真实任务上下文，不能沿用只保存状态码和耗时的普通监控权限模型。
测试期免费将在10月进入计费
Cloudflare表示，Agent Tracing测试期间暂时免费，从2026年10月1日起纳入现有Workers Observability计费。每个跨度都会计为一次可观测事件，不只是Agents页面中直接显示的操作。
官方公布的额度为Workers Free每天20万事件并保留3天，Workers Paid每月包含2000万事件，超出部分每100万事件0.60美元，保留7天。复杂Agent一次任务可能产生大量模型、工具与基础设施跨度，估算成本时不能只按对话次数计算。
追踪数据可以导出到兼容OTLP的外部平台，用于评估、分析和Token成本报告。正式启用前更稳妥的做法，是先在少量Agent上测量每轮任务产生的跨度数量和敏感数据范围，再决定采样率、保留策略与全量接入规模。
