Cloudflare 发布智能体会话与追踪平台
8 月 4 日的产品组合把本地调试、部署后追踪与软件交付工作流接到同一 Workers 底座。
本文要点
- 已部署 Worker 智能体从仅有基础设施 spans，扩展为可查看 agent、模型、工具和子智能体操作的 trace。
- 本地 Worker 调试从依靠临时日志反复定位，扩展为可由 Local Explorer API 查询的本地 traces 与关联日志。
- Cloudflare 将 beta 期间免费 tracing 明确为截至 2026-10-01，之后纳入 Workers Observability 套餐。
阅读辅助
先看数字、证据和来源，再读正文。
Cloudflare Agents 新增的是已部署智能体的会话与追踪入口，而非对所有智能体框架的通用托管承诺。
2026-08-04 · Cloudflare 当日发布 Agents 视图与 agent tracing，覆盖会话回放、运行、实例和 token 使用信息。
Cloudflare 在 8 月 4 日为 Workers 生态新增了一组智能体可观测性入口，覆盖运行时、控制台和开发工具。对把模型调用、工具调用和持久化状态放进 Workers 的团队，这次更新把上线后的执行记录放到与基础设施 trace 同一条排障路径上。
可以确认的事实是：Cloudflare 在 2026 年 8 月 4 日发布了 Cloudflare Agents，并在 dashboard 增加 Agents view；它可列出已观测的 agents、runs、sessions、instances 和报告的 token 使用。当天的公告还称，agent tracing 已支持 Think、Flue 与 AI SDK 等首批集成；在 trace 中，模型调用、工具执行、批准事件和受支持的子智能体调用可与 KV、D1、Durable Objects、fetch 等 Workers 基础设施 spans 一起查看。
仍有明确边界。上述产品能力、首批框架支持与价格均来自 Cloudflare 的一手公告，尚不是跨所有智能体框架、所有云或所有本地环境的兼容性结论。会话回放所含消息与工具 payload 也不是必然全量记录：官方说明 Think、Flue 与 AI SDK 可通过 storeMessages、storeTools 控制是否采集相关 payload，涉及个人信息、密钥或其他敏感数据时可关闭。
最先受影响的是已经使用 Workers 构建智能体的开发团队：一次失败不必只看 HTTP 200、应用日志或单个数据库 span，而可把“哪次模型调用、哪个工具、哪个子智能体、哪段 Worker 资源”串在一次执行中检查。企业买方则需要把这项便利与数据留存、权限、事件量和 2026 年 10 月 1 日后的套餐成本一起评估。
8 月 4 日究竟新增了哪些环节
Cloudflare Agents 的公告把已部署智能体的运行信息集中到一个 Agents view。其 Messages tab 用录制的上下文拼接某个 turn 中的系统指令、用户消息、模型思考、工具调用及参数和结果、最终回复；这是一份已捕获数据的回放，并非重新执行一次智能体。Traces tab 则以瀑布图呈现该 turn 的时长和调用关系，便于向下追到模型、工具与 Workers 绑定。
这一点解决的是传统应用 telemetry 的盲区。一个智能体可以返回 HTTP 200，却因选错工具、向子智能体传入过期上下文，或者在重试中耗尽 token 而没有完成任务。Workers tracing 原先能显示 fetch、KV 读写或 D1 查询等基础设施调用；本次 2026-08-04 的 Agents 更新在这些 spans 外加入 agent invocation、model call、tool execution、approval event 以及支持的 subagent call。公告强调，完整 Worker trace 还可能含 SDK 内部和其他 Worker 操作，所有 span 都按 observability event 计数，而不只是 Agents view 中可见的条目。
同日的 Agent Development Lifecycle（ADLC）文章给了这套能力更宽的产品叙事：Cloudflare 希望让智能体不只生成代码，还能参与计划、实现、测试、部署、维护等环节。不过这是 Cloudflare 提出的开发生命周期框架和一组平台原语，并不能证明不同厂商或运行环境中的智能体已可接管完整软件生命周期。文章列举的具体配套包括 @cloudflare/ci、Cloudflare Workflows、预览 URL、远程绑定、Workers Logs 和 Agent Traces；它们在同一天被作为相互配合的更新说明。
本地追踪也是 2026-08-04 的独立更新，不能被写成早已普遍存在的通用能力。Cloudflare 称 wrangler dev 和 vite dev 对本地 Worker 调用自动生成 OpenTelemetry traces；开发服务器识别到受支持的 coding-agent session 后，会提示 Local Explorer API。该 API 提供 OpenAPI schema，智能体可在运行时发现端点，并经只读 observability endpoint 查询 traces 和关联 logs，再查看本地 D1、KV、R2、Durable Objects 与 Workflows 状态。
| 8 月 4 日更新 | 已公布的具体能力 | 适用范围与边界 | 对本次主题的作用 |
|---|---|---|---|
| Cloudflare Agents | Agents view、会话回放、执行 trace、token 使用信息 | 首批强调 Think、Flue、AI SDK；更多 OpenTelemetry 兼容工具仍在推进 | 让部署后的智能体运行可查 |
| Agent Development Lifecycle | 将 CI、工作流、本地开发、部署与维护列为智能体可参与的环节 | 是 Cloudflare 的平台方法与愿景，不等同于自动接管所有 SDLC | 说明产品组合如何衔接 |
| 本地追踪 | wrangler dev、vite dev 自动产生本地 trace；Local Explorer API | 面向本地 Workers 开发及受支持 coding-agent session | 让修复能在部署前被复核 |
| CI Workflows | 为平台方运行可扩展 CI/CD 工作流的方案 | 是同日配套更新，不能当作 Agents 的单一内置功能 | 提供自动化交付背景 |
| Astro issue 分诊案例 | 隔离子智能体处理复现、诊断、验证和修复；官方称 open issues 降低 85% | 单一项目的 Cloudflare 案例，未构成通用效果基准 | 展示流程自动化的应用示例 |
表中的 Astro 数字同样需要克制解释。Cloudflare 的 8 月 4 日案例称，Astro 维护者以 GitHub Actions 中的隔离 AI 子智能体替换部分人工 issue 验证，open issue count 降低 85%。这是一项官方项目案例，不是对 Agents view、local tracing 或其他团队可复制收益的独立测量；它更能证明 Cloudflare 正把“可审计的分阶段自动化”作为产品叙事的一部分。
追踪数据如何连接一次失败
Cloudflare 给出的生产 trace 例子展示了层级关系：父智能体先做路由，子智能体继续调用模型和工具，工具随后访问 D1 或写入 KV。此时父子调用会嵌套在同一活动 trace context 中；对于支持的子智能体调用，读者可以从最终回复回到 delegated work，再回到每个智能体实际使用的 Cloudflare 资源。公告中的示例时长如父调用 2.72 分钟、子智能体 1.83 分钟，是说明 trace 字段如何呈现的样例，不能被当成产品性能承诺。
本地追踪的示例则把问题前移到部署前：一个订单接口从 KV 读取购物车、向 D1 写入结账信息、再发送队列消息；schema 变更后返回 500。没有 trace 时，开发者或 coding agent 往往要在 KV、D1 与队列周围加临时日志、重跑请求、再逐层猜测。Cloudflare 的例子中，Local Explorer 的 trace 显示 KV 读取成功、D1 因缺少 delivery_window 列而失败、队列没有被调用；智能体随后检查本地 D1 schema、应用遗漏的 migration，再次发送请求并查询新的 trace 验证。
这里真正的工程变化不是“让智能体知道更多日志”，而是让它获得可查询、有关联关系的执行证据。Cloudflare 表示 workerd 已内建 fetch、绑定调用与 handler 调用的 instrumentation，Miniflare 将本地运行时事件和 console 输出汇成 OpenTelemetry traces 与关联日志，并写入一个内部 SQLite-backed Durable Object 作为本地 trace store。开发者可在本地服务上按 e 或访问 /cdn-cgi/explorer 打开 Local Explorer；该界面运行在 localhost，而不是 Cloudflare dashboard。
对接方式也有分层。公告要求在部署后 agent tracing 中先在 wrangler.jsonc 启用 tracing：observability.traces.enabled: true。Think 和 Flue 通过各自 tracing integration 发出 agent、conversation、turn、model、tool telemetry；AI SDK 使用 Cloudflare 的 wrapAISDK() adapter；自定义 harness 则需要 custom spans 并遵循 OpenTelemetry 的 Generative AI semantic conventions。Cloudflare 还称正在支持 Workers 内的直接 OpenTelemetry API，使已经产生这些标准 spans 的框架将来无需等待专用 adapter。这是一个明确的“正在推进”状态，不应写成已经全面可用。
免费 beta 之后，成本口径看什么
价格是此次公告中最容易被过度简化的部分。Cloudflare 的原话是：所有 tracing 当前在 beta 期间免费；自 2026-10-01 起，tracing pricing 将作为既有 Workers Observability pricing 的一部分计入。因此，“beta 免费”只描述截至该日的产品状态，不等于无限期免费，也不能脱离 Workers Free 与 Workers Paid 的不同范围理解。
| 套餐范围 | 公告中的事件量 | 留存期 | 2026-10-01 后的解释 |
|---|---|---|---|
| Workers Free | 20 万 observability events/日 | 3 天 | 适用于 Workers Free 的 tracing 口径 |
| Workers Paid | 2,000 万 events/月包含量 | 7 天 | 超出后为 $0.60/额外百万 events |
| Agents view 可见操作 | 不是独立计费口径 | 取决于底层 trace | 完整 Worker trace 中 SDK 内部与其他 Worker spans 同样计为 events |
这个表只复述 8 月 4 日公告的定价说明，并没有替代未来的账单或合约条款。尤其是会话和工具链较长的智能体，单次可见的 agent operation 背后可能产生多条 Worker、SDK、外部 fetch 与存储 spans。团队若只按“智能体执行次数”估算预算，可能漏掉事件计量；若只看免费期，也会忽略切换日后的 Free/Paid 配额、留存差异和超额事件价格。
Cloudflare 这组 8 月 4 日更新的重点，是把智能体从“能调用模型和工具”的应用，推进到需要被记录、复盘并与部署底座一起排障的运行单元。对于 Workers 用户，控制台会话回放、生产 trace 与本地 Local Explorer 形成了一个相邻的证据链：本地先找到故障和验证修复，部署后再用同类追踪检查真实执行与成本。
这种闭环的优势是集成深：工具调用能够看到 D1、KV、fetch 等同一平台资源，开发者不用先把跨层数据拼接起来。限制也同样清楚：它首先服务于 Cloudflare 的运行时和首批集成，跨框架的标准 OpenTelemetry 接入仍处于扩展中；保存消息、工具结果及模型思考相关内容时，安全与最小化采集不能交给默认设置。
更值得警惕的是成本和治理错配。一个 trace 能帮助定位重试循环和无效工具调用，也会把更多执行细节变成需留存、授权和计费的数据。beta 的免费状态截至 2026-10-01，而 Workers Free 与 Workers Paid 的事件量和留存不同。团队应先定义哪些 payload 允许记录、哪些 trace 进入评估，以及每次修复闭环可接受的事件预算，再把它当作生产智能体的默认能力。
需要用实际指标回答的后续问题
接下来不应只观察 Agents view 是否增加更多卡片或框架名称，而要看可复核的运行结果。第一，Cloudflare 对直接 OpenTelemetry API 的支持何时落地，以及非 Think、Flue、AI SDK 的工具能否被稳定归组为 agents 与 sessions；这决定标准化接入是否真能降低迁移成本。第二，平台是否进一步说明会话回放中不同 payload 的采集、加密、脱敏、保留和组织内访问控制，尤其是在工具结果可能含客户数据或密钥时。
第三，本地追踪的价值需要在真实团队中由“定位到失败原因的时间”“部署前复现率”“修复后回归率”等指标检验，而不是只凭一个订单接口示例下结论。第四，到了 2026-10-01，使用者需要按实际 Worker trace 的 event 数量核对 Free/Paid 配额和留存是否足够；届时的成本曲线比 beta 阶段的启用门槛更能决定它是否会成为默认配置。
最后，ADLC、CI Workflows 与 Astro 分诊案例表达的是 Cloudflare 对软件工厂的方向：让工作流承接更长的自动化链路，并把执行证据留给人和后续智能体检查。该方向的可行性不取决于“智能体是否能自动写更多代码”，而取决于权限、回滚、可观测性和人工升级点能否在每个高风险环节被具体实现。8 月 4 日的发布提供了其中一段可见链路，但距离跨环境、跨组织的通用结论仍有待实际部署数据验证。