本文地址：https://www.ebpf.top/post/bpf-agentic-era

在 2026 年的 LSFMM+BPF 峰会上，BPF 子系统核心维护者 Alexei Starovoitov 发表了一场不像报告的报告——更像是一声警醒：如果 BPF 不主动变革，它将在 LLM 与编程智能体驱动的浪潮中被边缘化。

1. 问题的本质：BPF 的反馈回路太长

编程智能体（Coding Agents）的工作模式高度依赖短反馈回路—写代码、看错误、改代码。回路越短，智能体越高效。这也是它们擅长大规模重构等繁琐工作的原因：错误信息即时、清晰、可操作。

BPF 的现状恰恰相反。要充分测试一段 BPF 代码，开发者往往需要启动虚拟机；即便程序成功加载进内核，验证器（verifier）抛出的错误信息也极度晦涩——大量输出淹没了真正的问题根源。Starovoitov 直言，写 BPF 代码是他见过的唯一一种会让 LLM 直接放弃、而不是硬凑出答案的场景。

这不只是用户体验问题，而是一个生存问题：如果智能体无法高效使用 BPF，下一代系统工程师就不会选择它。

2. 核心矛盾：安全边界不可妥协，但体验必须改变

BPF 的设计哲学是「永远不崩内核」，这正是它的独特价值所在。验证器必须存在，且必须在内核中运行——用户空间不可信。这个约束无法绕开。

但 Starovoitov 指出，当前验证器承担了两个本可分离的职责：

  1. 找出程序员的错误（可以在用户空间做）
  2. 充当安全边界（必须在内核做）

这两者被耦合在一起，导致所有错误信息都来自内核的「安全视角」，对普通开发者几乎没有指导意义。解耦这两个职责，是改善体验的关键路径。

3. 解法一：让 Rust 成为 BPF 的天然护城河

Starovoitov 提出的核心方向是：让合法的 Rust BPF 程序不再触碰验证器错误。

逻辑很清晰——任何能通过 Rust 编译器、且没有滥用 unsafe 或内联汇编的程序，按道理也应该通过 BPF 验证器。Rust 编译器本身就是一道严格的用户空间过滤网，足以拦下绝大多数良性程序员的错误。

实现路径有两条：进一步改造验证器，或为 BPF 引入运行时检查作为补充。他对此充满信心，并承诺「几个月内，用 Rust 写 BPF 就再也不用跟验证器死磕」——这项工作已在进行中。

此外，可以在用户态 Linux（User-mode Linux）中运行验证器，让开发者在无需启动完整虚拟机的情况下快速获得反馈，大幅缩短回路。

4. 解法二：向 Rust 学习如何写错误信息

错误信息的质量，是 Starovoitov 另一个着力点。他的评价毫不客气：

「register is not init」——程序员拿这种提示能干什么？

他明确以 Rust 为标杆，不仅是因为 Rust 错误信息清晰，更因为它的排版格式本身就是可读性的典范。他甚至说：「你们都是恐龙；Rust 作为一门语言已经赢了——部分原因就在于错误信息的质量。」

目标状态：验证器错误几乎不再出现；偶尔出现的，必须写清楚出了什么问题、该怎么修。

5. 解法三：拆掉验证器的技术天花板

除了体验层面，BPF 验证器还有一批硬性限制拖累了表达能力，Starovoitov 列出了必须解除的约束：

  • 函数参数不能超过六个
  • 不支持间接函数调用
  • 不支持按值返回结构体
  • 不支持 128 位整数
  • 程序栈大小受限
  • 调用链深度受限
  • 存在百万条指令上限
  • 不允许长跳转
  • 静态函数与全局函数在验证上存在差异

这些限制对人类程序员就已经是负担，对智能体生成的代码更是直接的障碍。解除它们的部分路径是将更多数据迁入 BPF arena（一种扁平地址空间），从而让内存管理大幅简化。

循环处理是另一个重大突破点。他提出「拓宽」（widening）方案：当验证一个循环需要迭代过多轮时，主动泛化验证器状态，以覆盖更大范围的循环变量取值。代价是引入更多运行时检查，但换来的是验证器能处理所有具有固定上限迭代次数的循环。早期结果「非常好」，但距离生产可用还有工作量。

值得一提的是，BPF 子系统近期还引入了基于 rhashtable 的 map 类型，但 Starovoitov 认为这应是最后一种需要新增的 map 类型——BPF arena 已能满足绝大多数场景。

6. 更大的视角：保持在 LLM 的「训练分布内」

Starovoitov 提出了一个更底层的洞察：改造现有工具，而非发明新工具，可能是让 BPF 对智能体友好的唯一可持续路径。

LLM 的训练数据覆盖了大量现有工具的用法，但对小众或新创的工具几乎一无所知。bpftrace 和 DTrace 的领域特定语言对人类友好，对 LLM 却是障碍。相比之下，drgn 这类沿用标准语言语法（Python）、只做扩展的调试工具，天然更适合智能体使用。

他的终极愿景是：对编程智能体说一句「找出这个内核上的性能问题」，由它借助 BPF 和 drgn 自主定位并调试。实现路径包括：为现有工具写好智能体友好的文档与示例，以及把内核函数与类型信息编码成可自动检查的格式（如 vmlinux.rs）——类似于 drgn 已提供的内核对象访问接口，但面向 Rust 生态。

7. 代码审查的危机与应对

BPF 子系统正被 LLM 生成的低质量补丁淹没——commit log 写得漂亮，代码质量参差不齐。Starovoitov 的应对方式是：直接忽略 commit log，只看补丁本身。

更根本的问题是：维护者无法线性扩展。他的解法是呼吁所有提交补丁的人也参与审查，并引入 LLM 做初步过滤（如 Sashiko），不经过 LLM 评论的补丁他不会先行审查。

讨论中也暴露了更深的分歧：

  • 新人培养：如果简单审查都由 LLM 代劳，新贡献者如何学会审代码？Starovoitov 的回应是「新人本就精通智能体编程，补丁都是智能体写的」——这降低了参与门槛，但 Rostedt 认为贡献者数量增加而代码质量不变，并非好事。
  • LLM 依赖的可持续性：云端 LLM 不是无限免费的，商业模式尚未成熟。讨论中有人提议让 CNCF 等基金会为开源开发者提供 LLM 访问许可（实际上 CNCF 已向项目维护者发放此类许可），Starovoitov 则押注于开源模型和本地推理的长期可行性。

8. 洞察总结

BPF 面临的困境，是一个更普遍问题的缩影：为人类设计的工具，在智能体时代需要重新审视。

Starovoitov 的思路有几个值得记住的层次：

  1. 体验即生存：反馈回路的长短，直接决定工具在智能体时代是否有未来。
  2. 解耦是捷径：把「找错误」和「保安全」分开，能在不破坏内核安全模型的前提下大幅改善开发体验。
  3. 利用存量，而非另起炉灶：改造现有工具比发明新语言更可持续，因为 LLM 的能力边界由训练数据决定。
  4. 维护者瓶颈是结构性问题：LLM 在补丁生成侧降低了门槛，却在审查侧加剧了压力，两者必须同步解决。

「手动写代码的时代结束了，未来一切都是智能体。」这或许是过于绝对的断言，但它背后的方向判断值得认真对待：当工具的主要用户从人类变为智能体，工具本身的设计哲学就需要跟着变。BPF 选择主动拥抱这个转变，而不是等待被取代。

参考资料