——「HTTP 200 不代表 Agent 正常」时代的调试基座)
本文基于 2026-08-22 情报快照,数据以原文为准。摘要:一个 Agent 即使返回 HTTP 200,也可能选错工具、把过时上下文交给子 Agent、或在重试循环里持续烧 Token——传统 HTTP 遥测对此一无所知。Cloudflare 在 8 月初的 Agents Week 上线 Agent Tracing,阿里则在 8 月 21 日开源 AgentSight:前者把 Agent 行为做成平台内置的标准 Span,后者用 eBPF 在内核层零侵入观测。本文拆解两条路线的机制、限制与选型建议。一、痛点:为什么传统遥测看不到 Agent传统可观测性观测的是「服务」,不是「行为」。一次 API 请求返回 200,只能说明请求被处理完了,不能说明 Agent 的任务成功了。InfoQ 在报道 Cloudflare Agent Tracing 时把这个问题说得最直白:「一个 Agent 即使返回 HTTP 200,也不意味着它运行正常。它可能选择了错误的工具,将过时的上下文交给 Subagent,或者在重试循环中不断消耗 Token。」这类失败有一个共同特征:它们发生在 HTTP 语义之外。模型选错了工具、工具参数拼错、子 Agent 拿到过期上下文、SSE 流中途截断但网关仍回了 200、一次重试循环烧掉上千 Token——应用层遥测只能告诉你「发生过一次 API 请求或数据库查询」,却无法回答「是哪个 Agent 行为导致了这一切」。想象一次典型的排查:业务方报告「订票 Agent 又没订上票」,后端日志显示请求全部成功,HTTP 200、数据库写入正常,但你不知道模型在哪一步做了错误决策、调用了哪个工具、消耗了多少 Token、以及它有没有把任务委托给一个状态异常的 Subagent。在 Agent 化之前,这类问题根本不存在——单体服务的行为就是代码路径,看日志就能还原;Agent 的行为是模型在运行时生成的,代码路径只能告诉你「它可能做什么」,不能告诉你「它实际做了什么」。Cloudflare 的 Workers Tracing 此前已经覆盖基础设施层(Fetch、KV、D1),但 Agent 跑在 Workers 上时,trace 里只有这些基础设施 Span,唯独缺 Agent 自身的行为。8 月 21 日至 22 日,两条情报几乎同时刷屏:InfoQ 详细报道了 Cloudflare 的 Agent Tracing(该功能 8 月 4 日随 Agents Week 上线),阿里开源项目 anolisa 发布了基于 eBPF 的 AgentSight。两条路线一「内置」一「旁路」,恰好构成 Agent 可观测性的双雄格局。二、路线一:平台内置 —— Cloudflare Agent TracingAgent Tracing 是 Cloudflare 在 2026 年 8 月 4 日 Agents Week 上随 Cloudflare Agents 一起发布的第一个组件(官方博客原话:「First stop: agent tracing」),InfoQ 中文站在 8 月 22 日做了详细报道。它的思路是在现有 Workers Tracing 之上增加 Agent 级 Span,让每一轮交互生成一条结构化的 Trace:invoke_agent {agent class} ├── chat {model} └── execute_tool {tool} └── tool_approval {tool}模型信息与 Token 用量作为元数据附加在 Span 上;子 Agent 的工作会嵌套在调用它的操作之下。官方博客给了一个 Travel_Planner 的例子:父 Agent 把行程规划委派给 itinerary_builder 子 Agent,整个调用链 2.72 分钟,其中 1.83 分钟花在子 Agent 上——子 Agent 的模型调用(如 cf/zai-org/glm-4.7-flash)、工具执行、D1 查询与 KV 写入全部出现在同一条瀑布流里。三个字段用于身份关联:Agent name(逻辑实现)、Agent ID(具体实例)、Conversation ID(会话);Cloudflare 特别提醒不要用请求或用户标识动态生成 Agent name,否则 Dashboard 会塞满碎片化的 Agent 条目。社区对瀑布流视图的反响相当直接:有开发者在 Cloudflare 的 X 公告下留言,想在自己的 Agent 框架(Hermes)上试用这个功能,理由正是「能直接看到模型调用下面紧接着一个错误的工具参数」。接入成本按技术栈分化:Think 与 Flue v2 自动埋点;直接调 AI SDK 需用wrapAISDK()封装(v6/v7);自定义 Harness 则走 Workers Custom Spans API 并遵循 OpenTelemetry GenAI 语义约定——Workers 目前还不直接支持 OpenTelemetry API,官方称正在开发。开启方式也简单,在 wrangler 配置里打开开关即可:// wrangler.jsonc(官方文档示例) { observability: { traces: { enabled: true } } }Span 属性遵循 OTel 生成式 AI 语义约定,可导出到任意 OTLP 端点,这让 trace 不只是调试工具,还能喂给评测与成本报表,构成官方所说的「自改进 Agent」闭环的数据基础。值得警惕的是三点限制。其一,Payload 默认策略因框架而异:Think 与wrapAISDK()默认不保存消息/工具 Payload(需显式开storeMessages/storeTools),而 Flue 默认保存消息、系统指令、工具定义、参数与结果(需设content: false关闭)——同一平台,默认隐私策略可能完全相反,而消息 Payload 里又经常夹带个人数据或 Secret。其二,计费以 Span 为单位:每个 Span 计一次 Observability Event,包括 Agents 视图里看不到的 SDK 内部 Span;Beta 免费,2026 年 10 月 1 日起纳入 Workers Observability 计费(Free 每天 20 万事件、保留 3 天;Paid 每月 2000 万、保留 7 天,超出部分每百万 0.60 美元),复杂 Harness 的 Span 数量可能远超 Dashboard 给人的直观印象。其三,官方明确 trace 不是完整无损的会话记录:长消息、推理过程、工具参数与结果可能被截断,Session Replay 不显示图片,审批 Span 只表示 Worker invocation 内部的生命周期事件,并不记录用户跨 invocation 响应的人工等待时长——而 HITL 审批延迟恰恰是团队最想观测的指标之一。三、路线二:内核零侵入 —— 阿里 AgentSight(eBPF)与 Cloudflare 相反,阿里的 AgentSight 不依赖任何 Agent 框架。它属于 alibaba/anolisa(Agentic OS 定位的 Rust 开源项目,Apache-2.0,2026-08-22 实测 381 星、97 fork,最近仍在提交)的可观测性组件,于 8 月 21 日以 Show HN 形式发布。方案核心一句话:基于 eBPF 在内核层捕获 LLM API 调用、Token 消耗与进程行为,不改一行 Agent 代码——官方文档的原话是「从内核向上看 Agent 运行」(See an Agent run from the kernel up)。捕获能力分四块:Token 多维度计账(按 Agent、任务、模型)、行为审计(LLM 调用与进程执行全链路)、Agent 自动发现(扫描系统中运行的 Agent 进程)、Web Dashboard(localhost:7396,远程访问需 Token 鉴权)。最具产品价值的是中断检测清单,五种异常各有判定规则与严重级别:类型判定规则默认级别llm_errorHTTP 400 或 SSE body 含错误highsse_truncatedSSE 流未以 finish_reasonstop 结束highcontext_overflow上下文长度超限highagent_crashAgent 进程会话中消失criticaltoken_limitfinish_reasonlength 且输出接近上限medium零侵入是有代价的:前置条件为 Linux、内核 5.8(BTF 支持)、root 或 CAP_BPF 权限,macOS 上没有 eBPF(只提供扫描本地 JSONL 会话文件的 trace 命令与 Dashboard serve)。安装与日常查询都走 CLI(均出自官方文档):# 安装(需 root,Linux x86_64)sudoanolisainstallagentsightsudosystemctlenable--nowagentsight.service# 日常查询:Token 用量与中断事件sudoagentsight token--periodweek--comparesudoagentsight interruption list--typecontext_overflow服务启动后 Dashboard 监听localhost:7396,agentsight audit则覆盖行为审计查询。在 anolisa 的生态里,AgentSight 还承担「成本度量器」的角色:与 Tokenless 组件联动展示省下的 Token 数,官方 README 提到某次编码任务基于 AgentSight 测量省了 31.7 万 Token(40.5%),并可与 Copilot Shell 对话式查询「今天用了多少 Token」。需要说明的是,官方文档未公布 eBPF 探针的性能开销基准,目前能看到的量化信号只有运行时上限(如 eBPF Ring Buffer 32MB、事件通道容量 1 万、数据库超过 200MB 自动清理)——对生产环境压测时需自行验证。四、落地建议:三条路怎么选平台集成(Cloudflare 系)。如果 Agent 已经跑在 Workers/Think/Flue 上,Agent Tracing 是零成本选择:开observability.traces.enabled即可拿到 Span 级语义与统一 Dashboard。代价是绑定平台、按 Span 计费,且要按框架确认 Payload 默认策略。eBPF 旁路(AgentSight 系)。适合自托管、多框架混合、或 K8s 上跑了一堆互不相关的 Agent 的团队——不侵入代码意味着对存量系统零改造,任何框架(LangChain、Claude Code、自研 harness)只要发 LLM API 请求就能被捕获。代价是内核版本与权限要求,以及尚未公布的性能开销。自插桩(OTel 路线)。需要跨平台统一语义、或要把 trace 送进自建监控体系时,直接按 OTel GenAI 语义约定埋点最稳;Cloudflare 也在补这块,未来任意 OTel 兼容框架有望免埋点接入。三者的取舍可以浓缩为一张表:维度平台内置(CF)eBPF 旁路(AgentSight)自插桩(OTel)侵入性框架内集成零侵入需改代码框架范围Think/Flue/AI SDK任意 LLM 调用任意环境要求Cloudflare WorkersLinux 5.8/root无语义标准OTel GenAI 约定自研事件模型OTel GenAI 约定无论哪条路,建议先盯五个指标:Token 用量与成本、工具成功率、审批延迟(注意 Cloudflare Approval Span 的局限)、中断率(SSE 截断/上下文溢出)、子 Agent 耗时占比。对治理与审计而言,两条路线都提供了此前没有的抓手:AgentSight 的 audit 命令与中断清单适合做运维闭环,Cloudflare 的 trace 可导出 OTel 喂给评测——但双方都明确 trace 不是无损审计记录,payload 截断与隐私策略决定了它不能直接当合规日志用,把它当作「调试与成本观测」而非「完整证据链」是更稳妥的定位。总结两条路线殊途同归:「Agent Runtime 需要自己的遥测层,仅靠基础设施 Span 无法解释 Agent 究竟做了什么」——InfoQ 用这句话概括了包括微软 Agent Framework 默认开启 OpenTelemetry、Azure APIM AI Gateway 导出 Token 指标在内的整个行业趋势。平台内置赢在语义标准与开箱即用,输在平台绑定与按 Span 计费;eBPF 旁路赢在零侵入与框架无关,输在内核依赖与开销未明。接下来值得盯的三件事:Cloudflare 的 OTel API 直接支持何时落地、AgentSight 是否补上性能开销基准、以及行业能否在 Agent 遥测语义上走向统一——那才是「HTTP 200 不代表 Agent 正常」真正被解决的一天。参考链接Cloudflare 官方博客《Introducing: Cloudflare Agents》:https://blog.cloudflare.com/agents-on-cloudflareCloudflare Agents 文档 · Tracing:https://developers.cloudflare.com/agents/runtime/operations/observability/tracing/InfoQ 中文《Cloudflare 推出 Agent Tracing:支持截断限制,不同框架的 Payload 默认记录策略存在差异》(2026-08-22):https://www.infoq.cn/article/IBYDTeu3rse9tH3549wfalibaba/anolisa 仓库:https://github.com/alibaba/anolisaAgentSight 官方文档(英文):https://github.com/alibaba/anolisa/blob/main/docs/user-guide/en/agent-observability/agentsight.mdAgentSight 官方文档(中文):https://github.com/alibaba/anolisa/blob/main/docs/user-guide/zh/agent-observability/agentsight.mdShow HN:AgentSight(2026-08-21):https://news.ycombinator.com/item?id49389493Cloudflare Agents Week 总结:https://blog.cloudflare.com/agents-week-review-august-2026/
本文基于 2026-08-22 情报快照,数据以原文为准。摘要:一个 Agent 即使返回 HTTP 200,也可能选错工具、把过时上下文交给子 Agent、或在重试循环里持续烧 Token——传统 HTTP 遥测对此一无所知。Cloudflare 在 8 月初的 Agents Week 上线 Agent Tracing,阿里则在 8 月 21 日开源 AgentSight:前者把 Agent 行为做成平台内置的标准 Span,后者用 eBPF 在内核层零侵入观测。本文拆解两条路线的机制、限制与选型建议。一、痛点:为什么传统遥测看不到 Agent传统可观测性观测的是「服务」,不是「行为」。一次 API 请求返回 200,只能说明请求被处理完了,不能说明 Agent 的任务成功了。InfoQ 在报道 Cloudflare Agent Tracing 时把这个问题说得最直白:「一个 Agent 即使返回 HTTP 200,也不意味着它运行正常。它可能选择了错误的工具,将过时的上下文交给 Subagent,或者在重试循环中不断消耗 Token。」这类失败有一个共同特征:它们发生在 HTTP 语义之外。模型选错了工具、工具参数拼错、子 Agent 拿到过期上下文、SSE 流中途截断但网关仍回了 200、一次重试循环烧掉上千 Token——应用层遥测只能告诉你「发生过一次 API 请求或数据库查询」,却无法回答「是哪个 Agent 行为导致了这一切」。想象一次典型的排查:业务方报告「订票 Agent 又没订上票」,后端日志显示请求全部成功,HTTP 200、数据库写入正常,但你不知道模型在哪一步做了错误决策、调用了哪个工具、消耗了多少 Token、以及它有没有把任务委托给一个状态异常的 Subagent。在 Agent 化之前,这类问题根本不存在——单体服务的行为就是代码路径,看日志就能还原;Agent 的行为是模型在运行时生成的,代码路径只能告诉你「它可能做什么」,不能告诉你「它实际做了什么」。Cloudflare 的 Workers Tracing 此前已经覆盖基础设施层(Fetch、KV、D1),但 Agent 跑在 Workers 上时,trace 里只有这些基础设施 Span,唯独缺 Agent 自身的行为。8 月 21 日至 22 日,两条情报几乎同时刷屏:InfoQ 详细报道了 Cloudflare 的 Agent Tracing(该功能 8 月 4 日随 Agents Week 上线),阿里开源项目 anolisa 发布了基于 eBPF 的 AgentSight。两条路线一「内置」一「旁路」,恰好构成 Agent 可观测性的双雄格局。二、路线一:平台内置 —— Cloudflare Agent TracingAgent Tracing 是 Cloudflare 在 2026 年 8 月 4 日 Agents Week 上随 Cloudflare Agents 一起发布的第一个组件(官方博客原话:「First stop: agent tracing」),InfoQ 中文站在 8 月 22 日做了详细报道。它的思路是在现有 Workers Tracing 之上增加 Agent 级 Span,让每一轮交互生成一条结构化的 Trace:invoke_agent {agent class} ├── chat {model} └── execute_tool {tool} └── tool_approval {tool}模型信息与 Token 用量作为元数据附加在 Span 上;子 Agent 的工作会嵌套在调用它的操作之下。官方博客给了一个 Travel_Planner 的例子:父 Agent 把行程规划委派给 itinerary_builder 子 Agent,整个调用链 2.72 分钟,其中 1.83 分钟花在子 Agent 上——子 Agent 的模型调用(如 cf/zai-org/glm-4.7-flash)、工具执行、D1 查询与 KV 写入全部出现在同一条瀑布流里。三个字段用于身份关联:Agent name(逻辑实现)、Agent ID(具体实例)、Conversation ID(会话);Cloudflare 特别提醒不要用请求或用户标识动态生成 Agent name,否则 Dashboard 会塞满碎片化的 Agent 条目。社区对瀑布流视图的反响相当直接:有开发者在 Cloudflare 的 X 公告下留言,想在自己的 Agent 框架(Hermes)上试用这个功能,理由正是「能直接看到模型调用下面紧接着一个错误的工具参数」。接入成本按技术栈分化:Think 与 Flue v2 自动埋点;直接调 AI SDK 需用wrapAISDK()封装(v6/v7);自定义 Harness 则走 Workers Custom Spans API 并遵循 OpenTelemetry GenAI 语义约定——Workers 目前还不直接支持 OpenTelemetry API,官方称正在开发。开启方式也简单,在 wrangler 配置里打开开关即可:// wrangler.jsonc(官方文档示例) { observability: { traces: { enabled: true } } }Span 属性遵循 OTel 生成式 AI 语义约定,可导出到任意 OTLP 端点,这让 trace 不只是调试工具,还能喂给评测与成本报表,构成官方所说的「自改进 Agent」闭环的数据基础。值得警惕的是三点限制。其一,Payload 默认策略因框架而异:Think 与wrapAISDK()默认不保存消息/工具 Payload(需显式开storeMessages/storeTools),而 Flue 默认保存消息、系统指令、工具定义、参数与结果(需设content: false关闭)——同一平台,默认隐私策略可能完全相反,而消息 Payload 里又经常夹带个人数据或 Secret。其二,计费以 Span 为单位:每个 Span 计一次 Observability Event,包括 Agents 视图里看不到的 SDK 内部 Span;Beta 免费,2026 年 10 月 1 日起纳入 Workers Observability 计费(Free 每天 20 万事件、保留 3 天;Paid 每月 2000 万、保留 7 天,超出部分每百万 0.60 美元),复杂 Harness 的 Span 数量可能远超 Dashboard 给人的直观印象。其三,官方明确 trace 不是完整无损的会话记录:长消息、推理过程、工具参数与结果可能被截断,Session Replay 不显示图片,审批 Span 只表示 Worker invocation 内部的生命周期事件,并不记录用户跨 invocation 响应的人工等待时长——而 HITL 审批延迟恰恰是团队最想观测的指标之一。三、路线二:内核零侵入 —— 阿里 AgentSight(eBPF)与 Cloudflare 相反,阿里的 AgentSight 不依赖任何 Agent 框架。它属于 alibaba/anolisa(Agentic OS 定位的 Rust 开源项目,Apache-2.0,2026-08-22 实测 381 星、97 fork,最近仍在提交)的可观测性组件,于 8 月 21 日以 Show HN 形式发布。方案核心一句话:基于 eBPF 在内核层捕获 LLM API 调用、Token 消耗与进程行为,不改一行 Agent 代码——官方文档的原话是「从内核向上看 Agent 运行」(See an Agent run from the kernel up)。捕获能力分四块:Token 多维度计账(按 Agent、任务、模型)、行为审计(LLM 调用与进程执行全链路)、Agent 自动发现(扫描系统中运行的 Agent 进程)、Web Dashboard(localhost:7396,远程访问需 Token 鉴权)。最具产品价值的是中断检测清单,五种异常各有判定规则与严重级别:类型判定规则默认级别llm_errorHTTP 400 或 SSE body 含错误highsse_truncatedSSE 流未以 finish_reasonstop 结束highcontext_overflow上下文长度超限highagent_crashAgent 进程会话中消失criticaltoken_limitfinish_reasonlength 且输出接近上限medium零侵入是有代价的:前置条件为 Linux、内核 5.8(BTF 支持)、root 或 CAP_BPF 权限,macOS 上没有 eBPF(只提供扫描本地 JSONL 会话文件的 trace 命令与 Dashboard serve)。安装与日常查询都走 CLI(均出自官方文档):# 安装(需 root,Linux x86_64)sudoanolisainstallagentsightsudosystemctlenable--nowagentsight.service# 日常查询:Token 用量与中断事件sudoagentsight token--periodweek--comparesudoagentsight interruption list--typecontext_overflow服务启动后 Dashboard 监听localhost:7396,agentsight audit则覆盖行为审计查询。在 anolisa 的生态里,AgentSight 还承担「成本度量器」的角色:与 Tokenless 组件联动展示省下的 Token 数,官方 README 提到某次编码任务基于 AgentSight 测量省了 31.7 万 Token(40.5%),并可与 Copilot Shell 对话式查询「今天用了多少 Token」。需要说明的是,官方文档未公布 eBPF 探针的性能开销基准,目前能看到的量化信号只有运行时上限(如 eBPF Ring Buffer 32MB、事件通道容量 1 万、数据库超过 200MB 自动清理)——对生产环境压测时需自行验证。四、落地建议:三条路怎么选平台集成(Cloudflare 系)。如果 Agent 已经跑在 Workers/Think/Flue 上,Agent Tracing 是零成本选择:开observability.traces.enabled即可拿到 Span 级语义与统一 Dashboard。代价是绑定平台、按 Span 计费,且要按框架确认 Payload 默认策略。eBPF 旁路(AgentSight 系)。适合自托管、多框架混合、或 K8s 上跑了一堆互不相关的 Agent 的团队——不侵入代码意味着对存量系统零改造,任何框架(LangChain、Claude Code、自研 harness)只要发 LLM API 请求就能被捕获。代价是内核版本与权限要求,以及尚未公布的性能开销。自插桩(OTel 路线)。需要跨平台统一语义、或要把 trace 送进自建监控体系时,直接按 OTel GenAI 语义约定埋点最稳;Cloudflare 也在补这块,未来任意 OTel 兼容框架有望免埋点接入。三者的取舍可以浓缩为一张表:维度平台内置(CF)eBPF 旁路(AgentSight)自插桩(OTel)侵入性框架内集成零侵入需改代码框架范围Think/Flue/AI SDK任意 LLM 调用任意环境要求Cloudflare WorkersLinux 5.8/root无语义标准OTel GenAI 约定自研事件模型OTel GenAI 约定无论哪条路,建议先盯五个指标:Token 用量与成本、工具成功率、审批延迟(注意 Cloudflare Approval Span 的局限)、中断率(SSE 截断/上下文溢出)、子 Agent 耗时占比。对治理与审计而言,两条路线都提供了此前没有的抓手:AgentSight 的 audit 命令与中断清单适合做运维闭环,Cloudflare 的 trace 可导出 OTel 喂给评测——但双方都明确 trace 不是无损审计记录,payload 截断与隐私策略决定了它不能直接当合规日志用,把它当作「调试与成本观测」而非「完整证据链」是更稳妥的定位。总结两条路线殊途同归:「Agent Runtime 需要自己的遥测层,仅靠基础设施 Span 无法解释 Agent 究竟做了什么」——InfoQ 用这句话概括了包括微软 Agent Framework 默认开启 OpenTelemetry、Azure APIM AI Gateway 导出 Token 指标在内的整个行业趋势。平台内置赢在语义标准与开箱即用,输在平台绑定与按 Span 计费;eBPF 旁路赢在零侵入与框架无关,输在内核依赖与开销未明。接下来值得盯的三件事:Cloudflare 的 OTel API 直接支持何时落地、AgentSight 是否补上性能开销基准、以及行业能否在 Agent 遥测语义上走向统一——那才是「HTTP 200 不代表 Agent 正常」真正被解决的一天。参考链接Cloudflare 官方博客《Introducing: Cloudflare Agents》:https://blog.cloudflare.com/agents-on-cloudflareCloudflare Agents 文档 · Tracing:https://developers.cloudflare.com/agents/runtime/operations/observability/tracing/InfoQ 中文《Cloudflare 推出 Agent Tracing:支持截断限制,不同框架的 Payload 默认记录策略存在差异》(2026-08-22):https://www.infoq.cn/article/IBYDTeu3rse9tH3549wfalibaba/anolisa 仓库:https://github.com/alibaba/anolisaAgentSight 官方文档(英文):https://github.com/alibaba/anolisa/blob/main/docs/user-guide/en/agent-observability/agentsight.mdAgentSight 官方文档(中文):https://github.com/alibaba/anolisa/blob/main/docs/user-guide/zh/agent-observability/agentsight.mdShow HN:AgentSight(2026-08-21):https://news.ycombinator.com/item?id49389493Cloudflare Agents Week 总结:https://blog.cloudflare.com/agents-week-review-august-2026/
