本文翻译自 Hypothesis: LLM agents are the new high-level programming language，原载于 Hacker News。
核心假说
LLM 智能体正在成为新的高级编程语言。
如果这个假说成立，那么 LLM 智能体对编程语言的影响，就像当年 C 语言对汇编语言、Java 对 C、JavaScript/Python/Perl 对 Java 一样——这是一个全新的抽象层跃迁。
什么是 LLM 智能体？
我所说的 LLM 智能体，是指人类开发者的主要技术栈很快会变成：
- 多重性（Multiple）：多个智能体并行工作
- 自主性（Autonomous）：这些智能体只需要偶尔获得人类反馈，大部分时间自主工作
如何验证这个假说？
如何判断这个假说是否成立？如果一个人类开发者使用多个自主智能体，能够比不使用它们多构建一个数量级（10x）的功能输出，那么这个假说就是真的。
截至 2026 年 1 月，我还不敢确定，但我正在认真考虑这种可能性。
常见质疑
对于许多在软件行业摸爬滚打多年的人来说，这个想法会引发无数质疑。让我们先解决那些容易应对的：
质疑 1：10x 代码量不等于 10x 产出，那只是垃圾代码
回应：衡量标准应该是实际交付的功能输出，而不是代码行数。如果按照这个假说，真正的”代码行数”其实是你给 LLM 的指令。
质疑 2：LLM 只是给不会编程的人用的
回应：虽然 LLM 会带来许多新程序员，但这不代表有经验的程序员无法从中受益。证据显示，许多有经验的程序员正在因为 LLM 而获得更高的产出。
质疑 3：LLM 是给不想思考/不想工作的人用的
回应：如果你用 LLM 做比以前更多的事情，你必须思考和得工作得更多，而不是更少。管理一群智能体要求更高，而且你需要设计更多东西（因为你需要在相同时间内构建 x 倍的功能）。
质疑 4：LLM 会让我们的编码技能退步
回应：很可能。但在工作中，我们通常不会担心自己的汇编或 C 语言技能退步（如果有的话）。大多数人会在业余时间练习这些技能，因为我们无法证明在工作中使用汇编或 C 语言会更高效（对于大多数类型的软件开发而言）。
质疑 5：LLM 生成的代码比我写的差得多
回应：几乎肯定是这样。但这对你的汇编代码或 C 代码也同样适用。只要 LLM 生成的代码足够高效，它就能运行并且已经可用。系统会更丑陋，但它仍然能工作。
质疑 6：使用 LLM 智能体很贵
回应：如果它们能给你带来 50% 的生产力提升，而你的薪水是平均水平，那么它们并不贵。而且 LLM 只会越来越便宜。它们只是绝对成本高，相对成本并不高。
质疑 7：我试了一个下午 LLM 智能体，浪费了我时间
回应：这涉及到学习曲线。掌握与多个 LLM 智能体协作需要时间。想想你在与自己编程工具和语法搏斗时花费的小时和天数，直到你或多或少掌握它。
（以上所有质疑在我看来都站不住脚，尽管在情感上它们并不容易被接受）
两个核心问题
现在让我们讨论两个触及问题本质的质疑：
质量（Quality）
LLM 生成的代码不会很快变成一场灾难吗？我们不是在沙堆上建造城堡吗？
可理解性（Understandability）
LLM 不会生成多到我们永远无法理解的代码吗？即使系统正常工作，我们不是永远处于无法控制它们的危险中吗，因为我们不理解它们？
我认为应该将质量和可理解性作为任何可接受的 LLM 编程框架的目标。从经济角度来说，只有质量作为目标是站不住脚的。可理解性可能是一个浪漫的梦想或一个好的长期赌注（我选择后者，但你当然可以保持怀疑）。
LLM 的独特性
LLM 比以前的高级语言具有更强的非确定性。它们还能以一种以前任何抽象层都无法做到的方式帮助你理解高层问题（描述）。
未来图景
让我们试着勾勒这个不久的将来的共同要素：
文档（Documentation）
一组包含系统规范的 Markdown 页面：目的、主要实体、端点、约束、核心流程、编码标准。
实现（Implementation）
代码库加上所有数据。这是运行的东西和保存状态的东西。代码库应该可以从文档重建，数据应该与文档中的描述一致。
对话（Dialogs）
多个智能体在各自的任务上忙碌工作。它们在思考解决方案时产生文本，其中一些是代码：这就是对话（可以表达为 Markdown 页面）。人类可以随时检查这个文本流、代码更改和命令；人类也可以进入对话。某些对话可能在等待人类输入。当智能体完成工作时，对话不再活跃，但仍然可以访问。
任务（Tasks）
一组动态的离散工作片段，表达为 Markdown 页面。它们应该可以从文档 + 代码库的现有状态重建。任务应该可以嵌套。它们有状态（完成、待办、进行中、等待人类交互、完成）。
观察这个结构，我们看到两个”存量”（stocks）和两个”流量”（flows）。两个存量是”文档”和”实现”，这是系统的积累。我们还看到两个流量，即对话和任务。对话和任务构建文档和实现。人类也可以直接修改文档和实现，但这不会经常发生，因为大多数流程是智能体的，人类会将大部分时间用于与智能体交互。
智能体如何组织？
由于智能体可以扮演多个角色（因为底层模型是通用的），我认为我们可以在这里留出尽可能多的自由。如果任何智能体都可以进入任何对话，任何人类都可以进入任何对话，我们可以让人类尝试不同的可能性：
- 独立处理任务到完成的智能体
- 负责编排下一步的管理智能体
- 尝试破坏新功能的 QA 智能体
- 获取新的未合并功能并在没有构建者上下文的情况下审查它的审查智能体
- 解决冲突的合并智能体
重要的是人类可以手动或自动地使用指令启动智能体，这些指令可以是一次性的或文档的一部分。
MCP：打破应用孤岛的机会
这里有一个新型万维网的机会——或者更确切地说，让现有的网络更加自由和网状，打破应用的孤岛。这个机会就是 MCP（Model Context Protocol）。
MCP（LLM 工具调用的标准）——每个人都在争先恐后地支持它——可以被视为通用的 XMLHTTPRequest。这打开了让 AI 智能体获取孤立在现有应用中的任何功能和数据，并将其放在你自己选择的动态画布上的可能性。
我最初对 cell 的设想是一个你可以完全理解并且已经部署的代码和数据网格（数据空间）。这还不够。这只会是”网格”。围绕着网格将是一组动态页面，其中文档和功能结合在一起。
文档不仅仅是文档：你将能够嵌入功能，无论是来自你自己的应用（将在网格中支持）还是来自外部应用。你可以拥有可以全屏显示的小型仪表板或小部件。或者你可以导航到另一个页面。你的 cell 将是一组页面，加上网格，加上正在处理它的智能体。其中很多可以从外部访问。
为什么仍然需要服务器？
这仍然需要服务器，原因如下：
- 当你不在线时接收请求
- 持久化数据
- 保持智能体工作
- 由于安全原因，许多调用无法直接从浏览器进行，因此需要服务器来发出请求
质量和可理解性的解决方案
如果我们不使用庞大的技术栈，而是使用良好的底层（substrate），LLM 输出的代码行数会少得多，也更容易理解。如果是这样，我们可以大大提高我们构建的系统的质量和性能。
系统的前端现在是文档和智能体；后端是技术栈/底层。
未解决的问题
- 我们如何将文档和对话与实现一起存储？
- 我们如何使用版本控制系统？
总结
LLM 智能体可能正在成为新的高级编程语言抽象层。就像 C 语言取代汇编、Java 简化 C 开发一样，多个自主智能体的并行协作有望为开发者带来 10x 的生产力提升。
关键在于：
- 不要抗拒：每个技术进步都会伴随质疑，但趋势难以阻挡
- 拥抱变化：学会管理和编排智能体将成为新的核心技能
- 关注价值：最终衡量标准是交付的功能价值，而非代码行数或技术纯粹性
- 新的编程范式：文档即代码，对话即过程，智能体即执行者
未来已来，只是分布不均。我们正在见证编程范式的又一次跃迁。
译者注：这篇文章提供了一个非常清晰的视角来理解 LLM 智能体在编程历史中的位置。作者通过与编程语言演进历史的类比，揭示了 LLM 智能体作为新抽象层的必然性。特别值得注意的是，作者强调了这不是要取代程序员，而是要求程序员掌握更高层次的抽象和协作能力——与智能体协作。这对中国开发者来说是一个重要的信号：未来竞争的不是谁能写更多代码，而是谁能更好地设计和指挥智能体团队。