eBPF 深度解析：从内核观测到 AI Agent 实时管控——是什么、能做什么、怎么用、Agent 安全怎么管

写在前面

沙箱防逃逸，审批防越权，但 Agent 拿到合法权限后的行为——没人看得见。

上个月披露的 TrapDoor 攻击，攻击者在 .cursorrules 里埋零宽 Unicode 字符，Agent 读取后自动遍历文件系统外发密钥。这个月 Miasma Wave 2 更进一步——后门配置文件直接丢进项目目录，你克隆仓库、打开项目，后门就激活了。没有弹窗，没有告警，沙箱也不触发。攻击完全发生在授权边界内，Agent 只是”按配置工作”。

所有传统防御措施都在解决”安装前”的问题：扫描依赖、审核 registry、提醒用户只装可信来源。但一旦恶意配置进了你的环境，Agent 开始运行之后——它实际在做什么，没人知道。

这就是 eBPF 登场的背景。

一、eBPF 是什么？

1.1 从 BPF 到 eBPF：三十年演进

1992 年，Steven McCanne 和 Van Jacobson 在 USENIX 发表《The BSD Packet Filter》，提出 Berkeley Packet Filter（BPF）——一个运行在内核的虚拟机，用于高效过滤网络数据包。cBPF 只有 2 个寄存器，32 位设计，功能局限在网络过滤。

2014 年，Alexei Starovoitov 向 Linux 内核提交了 eBPF（extended BPF）补丁集，在 Linux 3.18 中合入。核心改进：

• 寄存器从 2 个增加到 10 个 64 位寄存器
• 引入 BPF_CALL 指令，可调用内核 Helper 函数
• 引入 JIT 编译器，将字节码翻译为本机指令
• 引入 验证器（Verifier），确保程序安全
• 支持 eBPF Maps，实现内核态与用户态的数据交换

此后里程碑：

• 2016：XDP（eXpress Data Path）引入——网卡驱动层直接处理包
• 2017：Brendan Gregg 称 eBPF 为”Linux 的超级力量”
• 2020：可休眠 BPF 程序（Sleepable BPF）
• 2021：Windows 开始实现 eBPF
• 至今：eBPF 成为 Linux 内核最活跃的子系统之一

1.2 核心架构：沙箱中的安全内核编程

eBPF 的本质是：在不修改内核、不加载内核模块的前提下，在内核态安全执行自定义程序。

验证器（Verifier）——安全性的基石

每个 eBPF 程序在加载前必须通过严格的静态分析：

结论：eBPF 程序崩溃不会影响内核稳定性——验证器保证。

JIT 编译器

将 eBPF 字节码翻译为 x86-64、ARM64、RISC-V、s390 等硬件架构的原生机器码。性能接近原生编译的内核代码。无 JIT 时回退到解释器模式。

eBPF Maps——数据交换中枢

Maps 是 eBPF 程序与用户态共享数据的核心数据结构：

Hook 类型——程序挂载点

eBPF 是事件驱动的，必须附着到特定 Hook：

网络类：

• XDP：网卡驱动层，数据包刚到达时执行，性能最高（线速）
• TC：网络栈 ingress/egress 分类器
• Socket Filter：socket 级别过滤

追踪类：

• kprobe/kretprobe：动态内核函数探测（入口/返回）
• uprobe/uretprobe：用户空间函数探测
• tracepoint：静态内核跟踪点（稳定 ABI，推荐优先使用）
• fentry/fexit：BPF Trampoline 框架，比 kprobe 更快

安全类：

• LSM（BPF-LSM）：Linux Security Module 钩子，实现 MAC 强制访问控制

其他：

• cgroup 系列：按控制组做网络/设备策略
• SYSCALL：直接挂载系统调用

1.3 CO-RE + BTF：编译一次，到处运行

传统 eBPF 程序需要针对特定内核编译。每次内核升级，结构体字段偏移变化，程序必须重新编译。

BTF（BPF Type Format） 是 DWARF 的轻量级替代方案，以紧凑二进制格式描述内核数据结构布局。Linux 5.2+ 默认启用。

CO-RE 工作机制：

1. 编译一次：Clang 生成带 BTF 重定位信息的 ELF 文件
2. 运行时重定位：libbpf 根据当前内核 BTF 自动修正字段偏移
3. 无需重新编译：同一份 BPF ELF 可在不同内核版本上运行

二、eBPF 能解决什么问题？

2.1 网络：性能提升 10-100 倍

Cilium（CNCF 毕业项目）是 eBPF 在网络领域最成功的案例：

• CNI 插件：基于 eBPF 的扁平 L3 网络
• kube-proxy 替换：eBPF 哈希表负载均衡，相比 iptables 延迟降低 90%+，CPU 降低 10-100 倍
• 基于身份的安全策略：L3-L7，支持 HTTP/gRPC/Kafka
• Cluster Mesh：跨集群安全互联

2.2 可观测性：< 1% 开销的全景视图

Pixie（CNCF Sandbox）：使用 eBPF 自动采集全量请求体、资源指标、网络指标、性能 Profile（火焰图），CPU 使用率 < 2-5%。

Hubble（Cilium 内置）：eBPF 驱动的服务拓扑、流量监控、DNS 分析。

传统可观测性工具需要代码埋点，eBPF 的方案做到了零侵入——不改一行代码。

2.3 运行时安全：从检测到执行

关键区别：Falco 看到异常只能告警，Tetragon 和 KubeArmor 可以实时阻断。

2.4 性能分析：定位瓶颈

bpftrace 一行命令即可挂载 tracepoint/kprobe 分析性能瓶颈，无需修改应用代码。

三、怎么用 eBPF？

3.1 开发工具链对比

3.2 实战：用 bpftrace 监控 Claude Code

sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_openat {
    if (comm == "claude") {
      printf("OPEN: pid=%d, file=%s\\n", pid, str(args->filename));
    }
  }'

输出示例：

OPEN: pid=8842, file=/home/user/.claude/settings.json
OPEN: pid=8842, file=/home/user/project/src/main.rs
OPEN: pid=8842, file=/home/user/project/.env

关键点：信息由内核直接报告，不经过 Agent 日志系统。即使 Agent 被注入”不要记录文件访问”的指令，内核依然如实上报。

3.3 生产环境：Tetragon TracePolicy

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: ai-agent-monitor
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchNames:
      - namespace: "ai-agents"

四、AI Agent 时代的 eBPF：从观测到管控

4.1 为什么传统安全工具在 Agent 场景失效

Web 服务器的行为是可预测的：监听 80/443，读写特定目录，连特定的数据库。你可以写一条 Falco 规则——”除了连 redis:6379 和 postgres:5432 之外的网络连接都告警”——这个规则完美有效。

但 AI Agent 的行为不是确定的。同一个 Agent，上午的任务是”分析销售数据”，下午的任务是”爬取竞品信息”。前者只读本地 CSV，后者可能连几十个外部域名。

4.2 三层观测模型

┌──────────────────────────────────────────────────┐
│ L1: Agent 日志 —— "它打算做什么"                  │
│    (stdout, callback, 自打 log)                  │
│    ⚠ 不可信：Agent 被注入后可选择性报告/伪造日志   │
├──────────────────────────────────────────────────┤
│ L2: OTel 链路 —— "它调了什么 API"                │
│    (OpenTelemetry: LLM→Tool 调用链)              │
│    ⚠ 不完整：只看到应用层约定好的交互              │
├──────────────────────────────────────────────────┤
│ L3: eBPF 内核 —— "它实际做了什么"                 │
│    (syscalls: open/connect/execve)              │
│    ✅ 不可篡改、零侵入、开销 < 3%                  │
└──────────────────────────────────────────────────┘

eBPF 能观测到每个系统调用：

4.3 语义鸿沟：eBPF 知道”做了什么”，不知道”为什么做”

假设客服 Agent 收到含间接 prompt injection 的工单，让 Agent 从 PII 表拉数据、POST 到外部端点：

这就是 AgentSight 论文（arXiv:2508.02736, UC Berkeley）提出的 语义鸿沟（Semantic Gap）：

• Intent stream：Agent 在 LLM 通信中的意图（可截获 TLS 解密后内容）
• Action stream：Agent 的系统调用
• 断层：内核知道动作不知道意图；LLM 通信有意图但缺关联

AgentSight 的因果关联引擎将两者实时关联，用副 LLM 做语义分析。overhead < 3%。

4.4 对 Agent 的实时管控架构

现实：LLM 推理延迟 500ms-2s，不适合做系统调用级实时拦截。AgentSpec 结论——”LLM-as-Judge 缺乏可靠的实时执行能力”。

可行架构：LLM 离线生成规则 + 轻量引擎实时执行

ARMO Application Profile DNA——不是记录”Agent 通常做什么”的静态快照，而是记录”Agent 在不同任务下的行为分布”，随时间演化。当 Agent 行为分布显著偏离基线时触发告警。

groundcover——K8s 集群里跑 eBPF sensor，自动识别 OpenAI/Anthropic 的流量，把 LLM 调用转成 OTel trace 作为 span，无需 SDK 埋点。

4.5 已知攻击的 eBPF 防御

五、eBPF 不是银弹

必须诚实地说：

eBPF 解决的是”看见”的问题，不是”理解”的问题。

它能告诉你 Agent 在 14:23:05 连了 104.18.32.47:443，但不能告诉你这是正常 API 调用还是数据外泄。你需要：

• 应用层上下文：HTTP body 里是什么？（需 L7 探针或 AgentSight 式 TLS 截获）
• 业务语义：IP 是否在白名单？（需对接业务系统）
• 因果链：行为由哪个 prompt 触发？（需 OTel 链路追踪）

正确架构是三层叠加，不是单层替代。 L1 给你业务语义，L2 给你调用链，L3 给你不可抵赖的系统行为证据。三者交叉验证，才能回答那个真正重要的问题：Agent 有没有做它不该做的事？

Futurum 2026 年初调研显示，AI Agent 可观测性已进入企业采购优先级 Top 10。

六、速查：eBPF 里程碑时间线

七、如果你现在就想动手

1. 快速验证：装一个 bpftrace，跑上面的脚本，看看你的 Agent 实际在做什么
2. 建立基线：用 Tetragon 在测试环境跑 1-2 周，记录 Agent 行为分布
3. 打通三层：把 L1 日志 + L2 OTel + L3 eBPF 三层联动，交叉验证异常行为
4. 渐进式执行：从纯监控开始，逐步增加 TracePolicy 阻断规则

eBPF 不是银弹，但它至少让你看见了之前看不见的东西——在 Agent 安全的战场上，看不见等于失守。

参考资料

• 原文：MP 文章 mp.weixin.qq.com/s/Z0pR-xaAG1LqYxI1bg30oA
• eBPF 官方文档 ebpf.io

• Cilium / Tetragon cilium.io

  tetragon.io

• Falco falco.org
• KubeArmor kubearmor.io
• AgentSight arXiv:2508.02736 github.com/agentsight/agentsight
• ARMO Application Profile DNA armosec.io
• groundcover groundcover.com