更高一层抽象：我们与 AI Agent 时代

本博客聊 AI Agent 的问题聊得比较少 —— 这通常不是我所关注的问题。但搜索 AI 也能搜出若干提到的文章；我也从不避讳，我几乎所有代码都已经是 AI 写出来的了。

由上一篇文章 Bun 官方：PR #30412 - Rewrite Bun in Rust / #30683 - Remove .zig source files 可知，我并不喜欢整日鼓吹 AI 推翻行业、软件工程领域过去的积累如何无用、AI 如何取代所有程序员之类的暴论。

但是很不意外地，我也在见证另一群有趣的朋友。他们固执地认为 AI 写代码会让自己丧失编码能力、失去对自己程序的掌控，因而坚持传承 “古法手作软件” 这一非物质文化遗产。。。

Abstraction Stack

我们今天的软件工程世界，建立在一层又一层的抽象与封装之上，从下至上，构成了我们的 “技术栈”。在物理世界之上，我们抽象封装出了逻辑电路元件；组装这些电路元件，我们封装出了 CPU；对 CPU 与各种硬件资源集中调度，我们有了操作系统；抹平各种平台的差异，我们有了各式各样的虚拟机。每一个最终面向用户的业务软件正常运转，都依赖从业务逻辑层向下所有层都有人在做着大量的工作。

当 C 语言把程序员从和硬件高度绑定的助记符种释放出来的同时，也有人会担心这会让程序员离机器越来越远。COBOL 刻意做成接近英文、面向商业数据处理的语言，宣称目让业务人员、审计人员、管理者也能读懂程序。再往后，诸多昙花一现或轰动一时的技术都反复许诺过类似的未来：让用户描述“想要什么”，而不是一步一步告诉机器“怎么做”。1991 年 Visual Basic 发布，把拖拽控件、事件驱动和快速构建 Windows 桌面应用的体验带给了大量非传统意义上的系统程序员。后来 Python、Ruby、PHP、JavaScript 的流行，也让“每个人都可以写程序”“编程应该成为基础素养”这样的口号反复出现。

这些口号今天听起来并不陌生。面临的争议在今天看起来也格外的熟悉。

不管面临怎样的争议，以上抽象大多最终稳固地建立起来了。并且一旦建立，大多数人对下一层的关注，就从“我要完全掌控它”变成了“它如何更好地服务上一层”。从此。每个业务开发者不再每天手写汇编、手动管理寄存器、亲自规划内存布局。有了 C 语言等高级编程语言之后，大多数能使用 C 或者更高级语言书写的逻辑，都不会有人再回到汇编语言去写。

然而，我们仍然需要有人去懂硬件、研究汇编，因为我们需要有编译器 —— 抽象和封装不能无缘无故地工作，C 语言的一切都建立在编译器之上。显然，做编译器的人需要对汇编、ABI、链接器、目标平台硬件有足够的熟悉。现在我们再回头看，显然不会再说使用 C 语言写操作系统内核和系统级组件让我们失去了对硬件的掌控力。相反，大多数时候手写出来的汇编不一定有编译器生成的效率高。你并不知道 gcc 和 clang 在为你做着多么努力的优化。

AI Agent 是新的抽象层

如果你认为当前这场进行中的软件工程革命（中性词，我只是在客观描述，大家开发程序的方式就是在发生巨变）闻所未闻，让你感到惶恐，怀疑程序员（自己）的价值、怀疑行业的未来，那我推荐你不妨把 AI Agent 理解成这样一种东西 —— 如同从前的每一层抽象诞生，如今 AI Agent 把我们编程的抽象层再向上抬升了一层。

曾经我们告诉汇编器：把这些助记符变成机器码。

曾经我们告诉编译器：把这些 C、Java、TypeScript 代码变成更底层的可执行形式。至于变成了什么，我们无人再去关心。

后来我们告诉框架：我声明这些组件、这些路由、这些数据依赖，请框架全权组织渲染、状态更新、构建产物和运行时行为。学习前端的人不计其数，又有多少人在关心 React 和 Vue 在我们简单的声明之下又做了多少工作呢。（需要面试前端岗背八股的应该在关心（））

现在我们开始告诉 Agent：我要实现这个功能，要遵守这些约束，要兼容这些历史行为，要通过这些测试。

如果 AI Agent 有一天（我不好说这一天有没有已经到来，至少在大多数业务代码代码库上已经到来了）可以稳定地承担大量机械性的实现、迁移、补测试、查文档、整理上下文、修复 bug 的工作，那么它就和历史上那些最终建立起来的抽象一样：把人类程序员从某些低层细节里解放出来，让我们把精力挪到更高一层的问题上。

掌控力与未来

程序员退化？

我反感无脑 Vibe Coding，只是要坚定的捍卫一下我们的软件工程 —— 「工程」需要做工程的态度。工程经验从来不会消失，没有需求拆解、架构决策、测试策略、代码审查、上线回滚和长期维护，AI 只会帮你用更快的速度生成屎山。权利与义务在现实层面格外的对等 —— 当你不去动脑子关注某个细节，你就无权（没有能力）无关注某些角落。正如你不能一方面把自己的旅游规划全盘交给旅行社代为制定，又希望沿途所有的交通、餐饮、住宿都如自己的意。反之，如果要说依赖 AI Agent 和程序员都在退化，都失去了对系统的掌控力，那使用高级语言是在退化，使用框架是在退化，使用有 GC 语言的垃圾回收是在退化，使用数据库是在退化，使用云服务也是在退化。可惜，软件工程史恰恰不是这样展开的。我们一直在把重复、稳定、可形式化的部分向下沉淀，把人的注意力推向更复杂、更开放、更难被完全形式化的问题。

对软件的掌控力

很多人也会担心，AI Agent 会让我们失去对软件的掌控力，很多部分对我们从此变成了黑盒。

对程序的掌控力可能是个抽象的概念，我们在前 Agent 时代的 “掌控感” 究竟从何而来？毕竟那个时候绝大多数 Web 程序员就已经不关心硬件、不关心操作系统、不关心内存管理，甚至前端开发者使用框架之后不再关心 DOM 管理。我觉得就是有一个「可靠」的边界帮我们封装了从此以下的所有细节，所谓「可靠」是我们知道 JS 代码和 Vue 框架的工作（几乎）不会出错，操作系统和浏览器的工作（几乎）不会出错，由于它们都是久经考验的基础设施，我们日常使用开发过程中也很难碰到 bug，于是我们理所当然的认为从此往下不会出错，我们只关心这个封装层之上我们自己的工作。

但是 AI Agent 可能给不了我们如此高可靠的心理预期，这是我们会觉得「不可控」的核心原因。这就必须得承认，这一层抽象与往上所有抽象的不同之处，大模型不是一个人工书写出来的转换逻辑，大模型的内部原理对人类就是黑盒，这甚至不是能拿去修复的 bug。所以「失去对软件的掌控力」这一层担忧绝对是有道理的。

但是这种不可靠并不完全是大模型本身所带来的。这一层抽象允许我们用自然语言去表达，工程素质良莠不齐的开发者都可以参与到开发中，有些人所勾勒出的业务图景本身就没有穷尽细节，或者语义不详、存在多种理解可能，甚至有可能业务的状态机都是矛盾的，因为没有细想（或者没有能力细想）而不自知。没有了编译器之类的东西，当我们自己的工程素质不够的时候，我们甚至得不到报错的硬性反馈。于是我们就破防了，觉得 AI Agent 不可靠，索性抛弃之，这个时候发现自己效率下降了 100 倍不止，抛弃不掉，根本抛弃不掉。

不管是写详细的设计文档、PRD，还是 Skills，目前看来我们还是有很多手段可以去「Harness」大模型的，大模型的不稳定和带来的效率提上，至少在业务代码这一层是绝对值得的。Harness 手段没有银弹，和你具体做的业务和使用的技术栈紧密相关 —— 如我上一段所说，Agent 时代对工程师的素质要求可能是更高了。Agent 只是让我们在各个方向的关注不再那么细粒度，但是并不能让我们整体屏蔽掉对某一块业务或者技术的关注。

不管在哪一层做工程的人，我想都可以称之为「工程师」—— 我们是熟悉且热爱自己工作的“层”，并且能够根据需要灵活的下探到下一层来服务自己的“层”的人。