AgentSight 上线:eBPF 给 AI Agent 做可观测性,以及内核层 Agent 监控新基线

eBPF 正在成为 2026 年 AI Agent 可观测性的内核层基线。AgentSight 这类工具把传统应用层 APM 触及不到的 Agent 运行时行为——文件读写、网络出站、进程派生、凭证访问——全部下沉到 Linux 内核层做观测,补齐了 MCP 协议层与应用 APM 层之上的「真相源底层」。本文从工程价值、企业落地路径、常见误区、整体趋势四个维度,梳理 eBPF 给 AI Agent 可观测性带来的新基线。

AI Agent 可观测性已与微服务彻底分化

AI Agent 的可观测性,在 2026 年的工程社区里已经与传统微服务的可观测性彻底分化。传统微服务的可观测性主要看 HTTP 请求、数据库调用、消息队列消费这三类外部交互;AI Agent 的可观测性则要看 LLM 调用、工具调用、文件写入、网络出站、进程派生这五类混合事件,而且每一类事件的语义都比传统微服务更脆弱——LLM 调用可能因为模型判断错误而反复重试,工具调用可能因为上游服务不稳定而走 fallback,网络出站可能因为 prompt injection 而触达白名单外的域名。这一切意味着,传统的应用层 APM(Application Performance Monitoring)对 AI Agent 来说远远不够,工程社区开始把目光投向更底层的可观测性方案:eBPF。

eBPF:跨语言、跨框架、跨模型的内核层观测

eBPF(extended Berkeley Packet Filter)是一项允许在 Linux 内核中安全运行沙箱程序的技术,无需修改内核源码、无需加载内核模块,就能在内核层拦截系统调用、网络包、安全事件、进程事件。当前最知名的 eBPF 可观测性项目包括 Cilium 旗下的 Tetragon、Datadog 的 USM、AWS 的 Inspector、Meta 自家的 bpftop 等。eBPF 在 AI Agent 可观测性场景里的核心优势是:无论 Agent 跑在 Python / TypeScript / Rust / Go 哪种语言栈,无论 Agent 走 stdio / HTTP / SSE / WebSocket 哪种通信协议,无论 Agent 调用的是 Anthropic / OpenAI / Mistral / 自托管哪一种模型,所有 Agent 的运行时行为——文件打开、网络连接、进程派生、环境变量读取、密钥访问——都会在内核层留下 system call 与 socket event,eBPF 程序可以在不修改 Agent 代码的前提下完整观测到。这是应用层 APM 永远做不到的「跨语言、跨框架、跨模型」一致可观测性。

eBPF 在 Anthropic defense-in-depth 框架里的三层补位

把 AgentSight 这类基于 eBPF 的 Agent 可观测性方案与 Anthropic 在 2026-07-30 containment 报告里给出的 defense-in-depth 框架对位,可以看到 eBPF 在工程上补齐了三层能力。

• 运行时监控:eBPF 能在 Agent 进程的每一次文件打开、每一次网络连接、每一次进程派生时实时打点,这些事件可以与 Agent 的 MCP 工具调用 trace 直接对位——例如 Agent 在 13:42:15 调用了 send_email 工具,eBPF 同时记录到 13:42:15.003 进程打开了 ~/.aws/credentials,13:42:15.012 发起了到 smtp.sendgrid.net:587 的 TCP 连接,这两条内核事件与 LLM 层的 send_email 工具调用形成完整链路。
• 违规行为告警:eBPF 可以在 Agent 触达任何不在白名单上的网络目的地时立即触发告警,这与 Anthropic containment 报告里强调的「任何 Agent 触达沙箱外实体都应当被实时检测并触发暂停」完全对位。
• 事故回放:所有 eBPF 拦截到的事件可以持久化存储,事故发生后工程团队可以像翻录像一样回放 Agent 在事故窗口期内的每一条内核行为,这与「containment 的可观测性必须先于 containment 的执行隔离」这条工程共识高度一致。

eBPF 在 Agent 场景的五类监控对象

eBPF 在 AI Agent 可观测性场景下的具体监控对象可以分为五类:

• 文件事件:open / read / write / unlink / rename 全部系统调用,以及对应的路径与权限位;任何 Agent 写入 ~/.* 配置文件、读取 /etc/passwd、写入 ~/.ssh/ 都会被即时记录。
• 网络事件:connect / accept / sendto / recvfrom 全部 socket 调用,以及对应的目标地址、目标端口、TLS 握手指纹;任何 Agent 出站到白名单外的域名都会被即时告警。
• 进程事件:execve / fork / clone / exit 全部进程生命周期调用,以及对应的命令行参数、父进程、退出码;任何 Agent 派生子进程运行 curl / wget / nc / python -c 都会被即时记录。
• 凭证事件:对 ~/.aws/credentials、~/.netrc、~/.config/gh/hosts、~/.kube/config 等已知凭证路径的访问都会被即时记录。
• 加密事件:对 OpenSSL / GnuTLS / NSS / BoringSSL 的读写都会被 hook,用于在不解密的前提下审计 Agent 对外发起的 TLS 握手。

MCP 协议层、应用层、内核层构成多层真相源

把 AgentSight 这类基于 eBPF 的 Agent 可观测性方案放进 MCP 协议的坐标里看,它补齐的是 MCP Memory 与 MCP 工具调用之上的「内核层真相源」。传统 MCP 服务器的可观测性只能看到 Tools / Resources / Prompts 三类原语的调用与返回;应用层 APM 只能看到 HTTP 请求的 URL 与 body;eBPF 能看到的是这一切背后真正发生的内核行为——每一次文件写入对应的 inode 与字节数、每一次网络连接对应的 socket 与目标 IP、每一次进程派生对应的 command line 与父 PID。当 MCP 协议层、应用层、内核层三个观测源同时存在时,任何「Agent 行为偏离预期」的判断都能在三个层面交叉验证,这是 2026 年之前任何单层可观测性都做不到的「多层真相源」架构。

可观测性的去所有权化:从 Agent 团队扩展到平台与安全团队

理解 AgentSight 这类工具的工程价值,关键在于它把「可观测性」从「Agent 团队的职责」扩展到了「平台 / 安全团队的职责」。传统 APM 是 Agent 团队自己埋点、自己读 trace、自己排查;eBPF 监控可以在平台 / 安全团队完全独立部署,Agent 团队不需要改一行代码,平台 / 安全团队就能拿到 Agent 运行时行为的完整真相源。这种「可观测性的去所有权化」与 Anthropic containment 报告里强调的 defense-in-depth 思路一脉相承——containment 不应该由 Agent 团队单独承担,必须由平台、网络、安全、审计多团队共同承担,eBPF 监控正好提供了让这些团队独立接入 Agent 运行时真相源的能力。

企业落地 eBPF Agent 监控的四步流程

把视线从工程价值拉到企业落地路径。任何想把 eBPF Agent 监控纳入企业安全运营的项目,在落地时通常会走四步流程:

• 基线建立:在所有跑 Coding Agent / 业务流程 Agent 的服务器与开发机上部署 eBPF Agent(以 Cilium Tetragon 为例),生成 24 小时的事件基线,确认每个 Agent 在正常状态下的文件访问、网络出站、进程派生模式。
• 白名单对齐:把基线数据与组织级 Agent 触达白名单做差集,识别出当前端点上有哪些 Agent 在「越界触达」,有哪些行为在「不应发生」。
• 告警与阻断:为每类越界事件配置告警规则——文件写入到 ~/.ssh/ 直接阻断、网络出站到白名单外域名直接阻断、进程派生到 curl / wget 直接阻断、凭证文件读取告警并写入审计日志。
• 响应流程:把告警事件接入企业 SOC(安全运营中心)的标准响应流程,与现有的人员身份、设备指纹、网络出口审计打通。

从应用层下沉到内核层:云原生可观测性的演进路径

AgentSight 这类 eBPF 工具的设计哲学,与最近几年云原生可观测性领域「从应用层下沉到内核层」的演进一脉相承。在 Kubernetes 监控领域,eBPF 已经从 Cilium 的网络可观测性,扩展到了服务网格的可观测性、安全可观测性、合规可观测性等多个维度;在 AI Agent 监控领域,eBPF 同样会沿着这条路径演进——从最初的「Agent 网络出站监控」,扩展到「Agent 文件与凭证监控」「Agent 进程与派生监控」「Agent 加密与 TLS 监控」,最终覆盖 Agent 在内核层留下的全部行为痕迹。这种「一切 Agent 行为皆可观测」的工程基线,是 2026 年下半年企业级 Agent 项目最值得投入的可观测性基础设施。

企业落地 eBPF Agent 监控的三个常见误区

把视线从工程细节拉到企业落地的几个常见误区。

• 只部署不告警:很多团队部署了 eBPF Agent 但只把它当作 trace 收集器,没有配置任何告警规则;结果事故发生时仍然需要事后翻 trace 才能定位,这与 containment 工程里强调的「实时检测并触发暂停」严重不符。
• 告警过载:把 eBPF 拦截到的所有事件都生成告警,结果告警风暴淹没了真正重要的安全事件;正确做法是只对「白名单偏离」「凭证文件访问」「非业务进程派生」这三类高信号事件生成告警。
• 绕过合规:eBPF 监控能捕获 Agent 的文件读写与网络出站,但这本身也是对企业员工工作内容的强观测;部署前必须与法务、合规、员工代表沟通清楚边界,避免被认定为过度监控。

可观测性远难于训练与部署:2026 Agent 工程的整体趋势

把视线从企业落地拉回到 AI Agent 工程的整体趋势。2026 年的 Agent 可观测性讨论里,有一个反复出现但很少被明说的判断:Agent 的可观测性,远难于 Agent 的训练与部署。训练侧可以通过 RLHF、Constitutional AI、self-critique 持续推进;部署侧可以通过 Docker、Kubernetes、IaC 工具标准化;但可观测性则是「MCP 协议层 + 应用 APM 层 + eBPF 内核层」三层叠加,任何一层失守,事故真相都无法还原。Anthropic containment 报告里强调的 defense-in-depth 思路,本质就是要求这三层全部落地——而不是依赖单层真相源。下一阶段的 Agent 工程,会越来越围绕「多层真相源 + 持续运行时合规」这两个轴心展开;AgentSight 这类 eBPF Agent 监控工具的真正意义,正是给这个趋势补齐最底层的那块拼图。

工程基线:Agent 运行时真相源必须交给平台与安全团队

最后回到工程基线本身。Agent 可观测性的真正教训,从来不是「eBPF 是银弹」「APM 没用」,而是「企业把 Agent 部署上线后,却没有把 Agent 运行时行为的真相源同步交给平台与安全团队」。把可观测性的所有权下放给 Agent 团队单独承担,是 2026 年企业 Agent 项目最常见的责任盲区;真正落地的项目,无一不是把 MCP 协议层 + 应用 APM 层 + eBPF 内核层三层都纳入统一的安全运营面板,由平台、网络、安全、审计多团队共同承担观测与响应责任。AgentSight 这类工具的工程价值,正是给这条责任下放路径提供最底层的真相源。