Agent 返回 200 不代表成功——Cloudflare 把 Agent 装上 CT 扫描仪

92% 的企业已经在生产环境跑 Agent，但 80% 的团队还在用传统 APM 监控这些 Agent。HTTP 200 跑得通，账单却翻了三倍。没人能说清楚 Agent 在每个 turn 里到底做了什么——直到 Cloudflare 把这件事摆到了台面上。

2026 年 8 月 4 日，Cloudflare 在自家博客发布 Cloudflare Agents——一个面向生产 Agent 的统一观测平台。它没有发布新模型，没有抢 Agent 框架的饭碗，而是补上行业最疼的一块拼图：让 Agent 自己的每一步行为都可被看到、可被评估、可被自动化改进。

这不是产品新闻。这是 Agent 工程的成人礼。

Agent 失败的样子，不是 5xx

传统应用的故障是显式的：404、500、超时。监控大盘把这三类错误画几条折线，问题八九不离十。

Agent 不一样。Agent 失败的样子是沉默地跑偏。

Cloudflare 在发布博客里写了一句会被引用一整年的话：

"An agent can return HTTP 200 and still fail. It may choose the wrong tool, pass stale context to a subagent, or spend tokens in a retry loop."

（来源：blog.cloudflare.com/agents-on-cloudflare，"Making agents observable" 段落）

翻译成工程师语言：一个 Agent 可以完美地把响应送回前端，但选错了工具、把上一轮的脏 context 传给子 agent、陷入 retry 循环把 token 烧光——传统监控完全看不到，因为这些都是跑在 CPU 里的"思考"，不是 HTTP 边界。

结果是：你以为 Agent 在干活，其实它在烧钱 + 输错答案。唯一知道这件事的，是用户在 Slack 里甩出的截图。

Agent 真正的故障不在 5xx，在 200 和"对"之间的灰带。 这才是这次 Cloudflare 发布要解决的事。

Trace + Replay：Agent 的 CT 扫描仪

Cloudflare 把过去九年攒下来的基础设施重新打包：Workers 负责隔离执行、Durable Objects 维持会话状态、Workflows 编排长任务、AI Gateway 调度模型调用、Sandbox 提供沙箱、R2 持久化存储。单独看每一项都不新鲜，但叠在一起形成的"Agent 第一公民"开发体验，是 Cloudflare 给自己的 9 年资历打包变现。

Cloudflare Agents 平台的第一步，是 Agent Tracing——针对 Agent 行为级、而非基础设施级的可观测：

• 每一轮 invoke_agent（包括嵌套子 Agent）、每次 chat 模型调用、每个 execute_tool、所有 approval 暂停事件、token 用量，全部被打成 span
• Think、Flue、AI SDK 三大 Agent 框架开箱即用，OpenTelemetry GenAI semantic conventions 兼容，其它框架按 OTLP 标准可以直接导
• Beta 期完全免费，2026 年 10 月 1 日起按现有 Workers Observability 定价（来源：原文 Pricing 段落）

落地有两种调试视角：

——把一次完整会话按 turn 重放：系统指令、用户消息、模型思考、工具调用参数、工具结果、最终响应，一字不漏地列出来。