引言
AI Agent 大规模走向生产的这一年，工程团队最先撞上的墙往往不是模型能力，而是可观测性：一个 Agent 从接收指令到调用模型、执行工具、读写文件，中间隔着几十次跨进程、跨网络的调用，一旦行为异常，排查基本靠翻日志加猜。
主流方案要求“先改代码再说”：接入 LangSmith、Langfuse 或 OpenTelemetry 的 SDK，在应用层打埋点。这在 demo 阶段没问题，进了生产环境就变成持续的负担，框架在换、语言不止一种、第三方组件没有源码可改。
8 月 21 日，Hacker News 的 Show HN 板块出现了一个新项目 AgentSight，一句副标题说清了定位：eBPF observability for AI agents, no code changes。它托管在阿里巴巴的开源仓库 Anolisa 中，思路是把观测点从应用层下沉到操作系统内核。
事件要点
- AgentSight 由阿里团队开源，代码与文档位于 Anolisa 仓库的 agent-observability 模块，8 月 21 日经 Show HN 发布，目前讨论尚少，但方向足够新鲜。
- 核心主张是零侵入：利用 eBPF 在内核挂载探针，捕获 Agent 相关进程的网络请求、进程执行与文件访问等事件，还原行为链路，全程不触碰应用代码。
- 它切入的正是当下最热的交叉赛道：Agent 工程化 × eBPF 可观测性。
为什么是 eBPF
eBPF 是 Linux 内核的一套安全沙箱机制，允许经过验证的小程序挂载到内核探针点上，在不改内核、不重启系统的前提下采集系统行为。过去几年它已经重塑了云原生观测：Cilium 用它做网络，Pixie、Inspektor Gadget 用它做零侵入诊断，后者的核心卖点同样是“不改代码就能看到服务间调用”。
把这套思路搬到 Agent 上，逻辑成立。Agent 的本质行为拆开看无非是：向模型 API 发 HTTPS 请求、起子进程执行工具、读写文件与配置。这些动作都会经过内核，网络走 socket，进程走 exec，文件走 open。eBPF 在这些节点布点，就能在应用毫无感知的情况下，拼出“这个 Agent 什么时候调了哪个模型、起了什么进程、碰了哪些文件”。
至于加密流量，这类工具的常规做法是在 OpenSSL、Python ssl 等加密库上挂 uprobe，在数据加密前抓取明文，这也是 Cilium、DeepFlow 等项目验证过的成熟路线。
应用层方案的痛点
对比应用层观测，零侵入的价值会更清楚：
其一，改不动。生产环境的 Agent 往往混合了自研代码、开源框架与第三方 SaaS 组件，后者没有源码可埋点。
其二，跟不住。Agent 框架迭代极快，SDK 埋点绑死框架版本，换一次框架等于观测层重写一遍。
其三，看不见全貌。应用层埋点只覆盖接了 SDK 的部分，而内核层看到的是整台机器的真实行为，包括那些“本不该发生”的调用。这一点对安全尤其关键：Agent 遭遇提示词注入后对外发起的异常请求，应用日志未必如实记录，但内核层的抓包不会说谎。当 Agent 开始替人执行真实操作，这种独立于应用自身的审计视角，几乎是刚需。
局限同样明显
eBPF 不是银弹。内核层看得到字节，看不懂语义：HTTP 报文里哪段是系统提示、哪次工具调用失败导致 Agent 走偏，仍需结合上层的链路追踪才能判断；token 计费、会话归因这类精细指标，SDK 方案依然更顺手。此外，uprobe 依赖具体加密库的实现与版本，容器里静态编译的二进制或自带解释器都可能让探针落空，对内核版本也有门槛。更现实的判断是两者互补：eBPF 兜底全局真相，SDK 负责语义细节。
简短点评
AgentSight 的意义未必在工具本身，而在于信号：AI 观测正在从“框架插件”演进为“系统问题”。当 Agent 真正在生产环境里执行操作，它的行为审计就不能只依赖它自己（或它的框架）自觉上报，这正是 eBPF 这些年一直在解决的问题：让基础设施自己开口说话。
对国内开源生态而言，阿里把 AI 观测做进系统层仓库，延续了从 Dragonwell 到 DeepFlow 的一贯路数：在基础设施与 AI 的交叉地带卡位。这条路能走多远，取决于 Agent 观测需求的真实刚性，但方向本身，值得每个在做 Agent 工程的团队花十分钟了解一下。