我不知道我有没有资格起一个这么宏大的标题，我只是个 nobody，计算机爱好者，还没入行。
行业里的大部分人如今都在焦虑自己的饭碗，因为他们担心基于大语言模型的智能体最终会取代他们。也许是五年后，也许是明年，甚至就在明天。但我的经验告诉我这并不现实。
软件归根到底在做什么？在我看来，是对现实的建模。从这个角度看，Excel 表格与其中的演算公式也是软件，手工计算的报表亦然。学生时代我们写过无数管理系统、信息系统，数据库设计（或任何形式的数据结构设计）贯穿始终。
这些系统都依托于结构——可能是数据库 schema，也可能是程序内部的 interface、structure、modules。编程即操作结构，而结构的复杂度随建模对象变化。我们当然可以设计简单系统，仅需简单的结构；但随着建模对象日趋复杂，我们不得不发展出适应这种复杂性的编程范式。
从变量开始，这就是一种”结构”。计算机中只有内存地址与数据，变量是我们发明的抽象，让我们以特定方式操控内存。由此衍生出过程、函数、类、模块——所有抽象都是为了更好地处理结构，为了更好地建模。从数据封装到结构组织，这正是基础设施演进的全部历史。复杂度不会消失，而是会转移。如果你不管理内存了，那不是因为内存不用管理了，而只是因为编程语言的运行时会帮你管理。
所有软件都包含两种逻辑：操作逻辑与业务逻辑。前者支撑软件运行——错误处理、日志、内存管理；后者体现建模意图——处理异常订单、计算金额、管理流程。高级编程语言的演进始终致力于简化前者，通过语言特性与生态让我们更轻松地处理技术细节。但没有任何技术敢说”用了我，你就不必处理业务逻辑”——这在逻辑上说不通：你不告诉计算机如何对现实建模，计算机又如何处理呢？
直到大语言模型出现。
表面上看，大语言模型确实能生成对常见场景的建模。但问题在于，一旦对象变得复杂，模型便难以承受这种复杂性，开始堆砌代码。或许你会说我们很少遇到如此复杂的问题，但谁能保证一个简单问题不会随需求变更而变得复杂？既然我们知道建模对象终将因需求演变而日趋复杂，我们真敢把一切交给大模型吗？
另一个值得质疑的现象是：既然大模型如此强大，为何不能利用已有基础设施？它完全可以阅读 man page 和 README.md，何必单独发明 Agents.md、skills 等”新技术”？如果说这些面向智能体的技术故意设计得复杂冗余（大概没多少人会认真阅读 Agents.md），以至于只有智能体能处理，那么我们就被锁定在以大模型为核心的生态中，直到再也找不到人类可读的文档与代码。
所以我觉得人还是有价值的，我们能通过理解业务逻辑对它建模，能根据业务的要求针对性的优化程序，能明白什么是可维护的、什么是不好的设计。在大模型摘得某个领域的 low hanging fruit 之后还剩下什么呢？我想和软件历史上出现的所有新技术一样，它会成为我们在开发中的一部分，如今的 Agentic 软件还存在着安全性、可复现性和成本等方面的诸多问题，我们会正视它，思考如何把它规范化、标准化。正如我们习惯了自动内存管理、包管理、语言服务器一样，没有人想再回去，但也没有人会说这就是软件的终结。