从「改不动业务代码」到「看见 AI 在干什么」

企业把大模型接入业务系统之后,第一个被问住的问题往往不是「模型准不准」,而是「它到底在背后跑了什么」。一个 Agent 在一次工单处理里调了哪几次搜索、读了哪几个内部接口、HTTP 调用超时了几次、上下文塞进了多少 token——这些信息在日志里散落在不同服务、不同进程、不同用户的视角里,出问题时拼不回一条完整的轨迹。

过去两年,业内给 LLM 应用做的可观测性大多走应用内插桩(SDK instrumentation):在代码里 import 一个追踪库,手动包裹每一步调用。这种方式对单体应用可以,但对真实业务系统里的 Agent 不友好——业务代码不能随便改,改动成本要由业务方拍板;多 Agent 协同、跨进程工具调用、外部 MCP 接口一并出现时,插桩点散落、追踪断链、链路对不齐,反而成了排查事故时最大的盲区。

这种背景下,2026 年 8 月 21 日 Hacker News 上出现的一条 Show HN 引起了不少工程团队注意——AgentSight:用 eBPF 在 Linux 内核侧零侵入地采集 AI Agent 的运行时轨迹,不需要在业务代码里加任何 import,也不需要重启服务,装上就能看到 Agent 跑了什么。与此同时,arXiv 上长期被引用的多 Agent 协同论文 AgentOrchestra(arXiv:2506.12508,2026 年 5 月 28 日第六版)提出的 Tool-Environment-Agent 协议,正在把「执行环境、工具版本、Agent 状态」三者作为一等公民资源管理,试图让可观测性从「贴上去的检测」变成「协议层原生能力」。两条线索拼在一起,正好勾勒出 2026 年 AI Agent 可观测性的两条主流路线——内核侧零侵入采集,以及协议侧全生命周期管理。

AgentSight:eBPF 在内核侧把 AI Agent 的行为「录」下来

AgentSight 的核心思路来自 eBPF(extended Berkeley Packet Filter)在现代 Linux 内核里的能力扩展。简单理解:业务进程在用户态跑 AI Agent,内核态允许挂载一段沙箱程序,在不中断业务、不改业务源码的前提下,观察进程发出的系统调用、网络连接、文件读写、共享内存读写,以及和 OpenTelemetry/Prometheus 这类已有遥测通道的兼容输出。

具体落到 AI Agent 场景,AgentSight 在内核侧识别出三类高价值事件:

  • 进程与文件事件:Agent 进程何时 fork、何时读 .env / 凭证文件、何时写 /tmp 下的临时文件——这些是评估「Agent 是否越权访问敏感资源」的硬证据。
  • 网络事件:Agent 何时连 OpenAI/Anthropic/自托管 vLLM、何时连企业内网 API、何时连外网不可信域名——网络侧的拓扑本身就是 Agent 行为的指纹。
  • 运行时符号与库调用:对于运行在 CPython/Node 解释器里的 Agent,通过 uprobe 探测 requests/httpx/aiohttp 等关键库函数,可以还原出每一次 LLM 调用前后的 prompt/response 长度、token 数、是否走了缓存。

这种做法对企业的实际意义在于,业务方终于不用为了「让 AI 可观测」去改一行业务代码。在传统 SaaS 化 SDK 路线里,任何插桩都要走代码评审、版本管理、灰度上线;在多 Agent、跨语言、跨进程的复杂业务系统里,这意味着追踪覆盖率永远追不上代码迭代速度。eBPF 路线把追踪点下沉到内核,只要业务进程跑在 Linux 上、Agent 用了标准库,几乎都能被覆盖。

从工程落地看,AgentSight 这类工具也带来三个新的复杂性:

  • 需要特权容器:eBPF 程序加载要求 CAP_BPF / CAP_PERFMON 之类能力,Kubernetes 集群里通常以特权 Pod 或 DaemonSet 方式部署,安全团队需要明确放权范围。
  • 数据噪声大:内核侧事件是原始字节流,「一次 LLM 调用」在事件流里可能拆成几十个 read/write/connect/close,需要二次聚合才能还原成业务语义。
  • 协议耦合深:想从内核事件里识别「这一次是 Tool 调用还是 Memory 写入」,必须对 LangChain / LangGraph / CrewAI / AutoGen 等主流框架的运行时行为有针对性建模,框架一升级就要重新适配。

这是为什么 AgentSight 在 HN 上拿到 17 个赞、引发三十多条讨论的原因——它解决了一个真问题,但也带来了新约束。工程团队在落地时,要把这条路线作为「可观测层」的一块拼图,而不是唯一答案。

AgentOrchestra:把可观测性写进协议层

arXiv:2506.12508 提出的 AgentOrchestra 走的是另一条路。它把 Agent 系统的运行拆成三个一等公民资源:Tool(工具)、Environment(执行环境)、Agent(代理)。三者的版本、生命周期、调用关系都被显式建模成可寻址的对象,而不是隐式藏在某个框架的内存里。

这套抽象叫做 TEA 协议(Tool-Environment-Agent Protocol)。在 TEA 里,一次 Agent 调用对应一段完整的版本化资源链:

  • 哪个版本的检索工具被调用;
  • Agent 跑在哪个执行环境镜像上(系统包、Python 版本、依赖);
  • 上下文里塞进的 prompt 模板、memory 索引、tool 描述分别是哪个 commit。

这种显式建模直接带来可观测性的两个好处。第一,任何一次失败都可以精确回溯到「工具 X 版本 Y 在环境 Z 上被 Agent 调用失败」,而不是「昨天还好好的今天怎么挂了」。第二,既然 Tool/Environment/Agent 都是版本化资源,Agent 本身的「自演化」就有了可审计的轨迹——Agent 在跑的过程中更新了自己的 prompt 模板或检索索引,这次更新本身也是一次可被记录的事件,而不是悄悄发生的黑盒操作。

论文里在四个公开基准(GAIA Test、Humanity's Last Exam 等)上做了对比,AgentOrchestra 在 GAIA Test 上达到 89.04% 的成绩,优于多数强基线。但对工程团队来说,更值得关注的不是 benchmark 名次,而是它给出的事实:多 Agent 协同的可观测性,如果不从协议层设计,光靠应用层日志和事后审计,根本追不上系统的演化速度。

两条路线在企业落地时如何取舍

把 AgentSight 的内核侧采集和 AgentOrchestra 的协议侧管理放在一起看,2026 年企业做 AI Agent 可观测性实际上有三种主流路径:

  • 路径 A:内核侧 eBPF 采集为主。适合业务系统已经成型、不允许改业务代码、Agent 框架多样的场景。代价是要解决特权容器、数据噪声、协议耦合三个新问题,适合运维平台团队主导落地。
  • 路径 B:协议层显式管理为主。适合 Agent 框架自研、Tool 与 Environment 都受控的场景。代价是要把 Tool/Environment/Agent 三类资源的版本化基建先建起来,适合 Agent 平台团队主导落地。
  • 路径 C:混合落地。协议层给关键 Tool/Agent 打版本锚点,eBPF 在内核侧补齐协议未覆盖的盲区(如第三方 SDK 内部调用、外网 API 异常)。这是大多数中大型企业在 2026 年最务实的选择。

无论走哪条路径,有几个判定标准是不变的:

  • 是否能在不重启业务的前提下补齐追踪;
  • 是否能把一次 LLM 调用的工具调用链、上下文构成、token 消耗完整还原;
  • 是否能区分「Agent 主动行为」与「外部触发的副作用」,避免把告警归因到错的对象;
  • 是否能把版本变更(模型升级、prompt 改写、工具替换)作为可观测事件记录,而不是悄悄发生。

对正在推进 AI Agent 落地的企业来说,「可观测性」从一开始就不应该是上线之后才补的工程债,而应该是协议设计与系统集成阶段就被讨论清楚的契约。AgentSight 证明内核侧有可挖的空间,AgentOrchestra 证明协议侧有可设计的空间——两件事并不冲突,真正的难点在于把两者放进同一个 Harness(承载层)里,让业务方既不需要改业务代码,也不需要放弃对 Agent 行为的可控性。

结语:可观测性是 Agent 走进生产的入场券

过去一年,AI Agent 从 demo 走到生产环境的最大阻碍,不是模型不够聪明,而是出了问题没人能说清楚「刚才那一秒到底发生了什么」。AgentSight 用 eBPF 给出了一种零侵入的答案,AgentOrchestra 用 TEA 协议给出了一种全生命周期的答案。两条路线指向同一个结论:可观测性不是 Agent 系统的可选项,而是从 demo 走向生产的入场券。任何想在企业里长期运行 Agent 的团队,在选型框架之前,先回答清楚「Agent 出问题时,你能不能在 5 分钟内还原完整轨迹」,比模型选 GPT 还是 Claude 更影响业务能不能真用起来。