第一个智能体原生编程语言会是什么？

编程语言，最初是为了让人类向机器下达指令而设计的。

它们的语法映射着这段历史。我们使用可读的变量名、好记的关键字、缩进、注释、文件、类，以及契合人类心智模型的各种抽象。编译错误是写给人看的。文档是按人的习惯组织的。代码仓库的结构，是为了让人能在其中穿行。

但人类正在迅速地不再负责真正写下那些代码。

通过 Senternet——我打造产品、试验 AI 辅助开发的软件工作室——我如今的大部分软件，都是靠指挥编码智能体做出来的。我描述我想要什么，审阅结果，测试行为，再把出错的地方打回去让智能体修。智能体依然产出 TypeScript、Python、SQL 和别的常规源代码，但这越来越像是现有生态遗留的产物，而不是这项工作本身的要求。

智能体之所以写人类可读的代码，主要是因为我们的编译器、库、操作系统、API、包管理器和部署基础设施都期待它这么做。

这引出了一个我停不下来去想的问题：

第一个主要为智能体而非人类设计的编程语言，会是什么样子？

人类可读的代码，正在变成一种中间格式

在计算史的绝大部分时间里，源代码有两类受众。

第一类是将要编译或解释它的计算机。第二类是日后可能需要理解、调试、维护或扩展它的每一个人。

第二类受众，塑造了几乎所有重大的语言设计决策。

Python 强调可读性。Ruby 力求自然而富有表现力。TypeScript 增加了结构，帮助大群人一起理清 JavaScript。Rust 把所有权和内存安全显式化，好让开发者能理解并掌控那些在别的语言里可能被藏起来的行为。

这些都是有价值的特性，因为长久以来，稀缺资源一直是人的注意力。

智能体式编程改变了这笔账。

智能体不需要好打的语法。它不需要好记的关键字。它不需要一门能在一个学期里教完、或者用一书架的书讲清楚的语言。它在庞大的代码仓库里穿行不会疲劳。它能处理那些对人来说冗长、繁琐甚至不可理解的表示形式。

它可能受益于一套截然不同的属性：

• 无歧义的语义
• 紧凑的 token 表示
• 显式的依赖与副作用
• 确定性的变换
• 形式化验证
• 自动并行化
• 机器可读的诊断信息
• 内建的溯源
• 增量编译
• 针对硬件的优化
• 对约束与测试的直接表达

一旦智能体成为软件的主要作者，人类可读性就不再是核心的设计约束。

它并没有变得毫无价值，而是变成了一种被生成出来的界面。

机器原生的表示可能成为事实来源，而人类则按当下最需要的形式获得一个视图：一段解释、一张图、一份行为规格、一份安全报告、一套测试计划，甚至一份生成出来的 TypeScript。

人类可读的代码，最终或许并不比数据库模式的图形视图更根本。

为什么智能体仍在写 Python 和 TypeScript

任何新语言面临的最大障碍，都不是它的语法。

是生态。

一门新语言需要编译器、调试器、库、文档、包管理、编辑器支持、部署工具、安全分析，以及接入既有平台的能力。开发者不情愿采用一门逼着他们把已有的一切重造一遍的语言。

智能体消灭不了这个问题，但可能大幅缩小它。

从历史上看，一门新语言还必须说服数以百万计的人去学它。开发者需要培训、示例、书籍、社区支持，以及足够的信心，才敢把职业生涯和公司押在陌生技术上。

智能体不需要几个月的培训。一旦某个模型或编码系统能可靠地产出某门语言，该系统的每一位用户都立刻获得了它。

这就移走了语言普及道路上最大的历史障碍之一。

生态问题依然存在，这意味着第一门成功的智能体原生语言，多半不会一口气取代 Python、JavaScript、Rust 和 C++。它会把它们吸收进来。

它可能经由 LLVM 编译、以 WebAssembly 为目标、调用现有的 C 接口、导入当下的包，并与既有的 API 通信。它可能一开始只是藏在某个编码智能体底下的中间表示，而不是一门开发者有意识挑选的语言。

这场转变，可能在大多数人毫无察觉的情况下发生。

其中一部分已经在发生

目前还没有一门被广泛采用、主要由智能体书写和消费的通用编程语言。但已经有若干早期项目在朝那个方向走。

2025 年，研究者提出了 Quasar，作为一门服务于大语言模型智能体所执行之代码动作的语言。智能体在需要调用工具或构造控制流时，通常会生成 Python，但研究者认为，Python 缺乏这类工作所需的性能、安全与可靠性特性。

Quasar 增加了自动并行化、不确定性追踪，以及用于校验潜在不安全动作的机制。在当前实现中，模型写的是一个受限的 Python 子集，再被转译成 Quasar。研究者报告称，在可并行的情形下执行时间减少了 42%；在其安全机制生效时，所需的人工批准交互减少了 52%。

Quasar 并不是智能体原生语言的最终形态。智能体依然吐出类似 Python 的代码。但它把压力摆得很清楚：为人设计的语言，未必是适合智能体的最佳执行模型。

Pel 是另一门实验性语言，专为编排 AI 智能体而生。它采用极简的文法，强调受约束的生成、能力控制、智能体间通信、安全执行和自动并行化。

Pel 受到 Lisp、Elixir、Gleam 和 Haskell 等语言的影响，但它的设计有一个前提：模型能否可靠而轻松地生成它，本身就是一项语言特性。

这是优先级上一次意味深长的转变。传统的语言设计者会问：这套语法对人来说好懂吗？而智能体原生语言的设计者也许会问：模型能不能稳定地生成它、机械地校验它，并在无人干预的情况下从错误中恢复？

编码智能体也开始表明，它们并不需要像人类那样去学一门陌生的语言。

在一项 2026 年关于编码智能体处理奥秘编程语言的研究 中，顶尖智能体频频改为编写 Python 程序，用它来生成并调试那门陌生的目标代码。当研究者禁止这种元编程策略时，表现大幅下滑。

那是我所描述的未来的一种粗糙但重要的雏形。

智能体可以推断出一种目标表示，为它造一个生成器，测试结果，再修改生成器。它并不需要以人类的方式去理解或维护那份目标代码。目标语言，不过是它能操纵的另一种机器表示罢了。

第一门智能体原生语言，可能看起来根本不像一门语言

当人们设想一门新的编程语言时，通常设想的是新的语法。

那也许是其中最不重要的部分。

一门智能体原生语言，可能是对以下内容的结构化表示：

• 期望的行为
• 接口
• 约束
• 权限
• 不变量
• 测试
• 资源上限
• 性能目标
• 安全策略
• 可接受的失败模式

至于这些要求该如何实现，可以由编码智能体和编译器共同决定。

对某一类负载，结果也许是原生机器码；对另一类，也许是 WebAssembly；再换一类，也许是一份数据库查询计划、一个 GPU 内核、一个无服务器函数，或者若干现有服务的组合。

可能根本不存在一份与该实现相对应的、长期留存的源文件。

真正持久的产物，将是意图本身，以及「该实现满足了这份意图」的证据。

这暗示着一条分三个阶段的演进路线。

第一阶段：智能体书写人类的编程语言

这就是我们眼下所处的位置。智能体产出的代码，看起来像是某位人类开发者可能写出来的东西。

第二阶段：智能体书写面向机器的中间表示

人类主要审阅行为、测试、规格、生成的解释，以及能力上的变化。底层实现在日常评审中变得不那么重要。

第三阶段：智能体直接生成可执行系统

事实来源变成了一组意图、策略、接口、约束和验证证据。智能体按需生成、再生成可执行的实现。

到那一步，追问一个应用「是用什么编程语言写的」，可能就不太说得通了。

人类可读，并不等于人类可审计

反对这一未来的最有力论点是：源代码并不只用于写软件。

它还用于调试、审计、治理、安全评审、维护和问责。

我们不能安全地运行那些无人能够检视其行为的重要系统。

但可读的源代码，本来就已经是「真正理解」的一个孱弱替身。一个大型的现代应用，可能包含数百万行第一方代码，并通过各种包、生成文件、云服务、操作系统和固件，依赖着另外数百万行。几乎没有人理解整个系统。

代码可以是可读的，而系统仍然不可理解。

一个智能体原生的系统，必须提供比一堆源文件更强的检视手段。它可以生成：

• 对特定行为的解释
• 数据流动的地图
• 对重要性质的证明
• 权限与能力报告
• 依赖关系的历史
• 对拟议变更的模拟
• 可执行的测试
• 每个决策为何如此的记录
• 必要时给出的人类可读实现

目标不该是不惜一切代价保住可读的代码。

目标应该是保住人类的掌控。

这两件事并不相同。

对人类友好的代码，有其环境代价

智能体最终可能越过今日编程语言的另一个理由是：能耗。

一项被广泛引用的 2017 年关于 27 门编程语言能效的研究，在十道基准题上比较了运行时间、内存占用与能耗。

在其归一化的结果中，Python 消耗的能量约为 C 的 76 倍，所需执行时间约为 72 倍。在受测语言里，Python 的能效排在接近末尾的位置。

这个结果常被简化成一句话：Python 是对环境最不友好的编程语言之一。

实情要复杂得多。

一项 2024 年对编程语言能效的再分析 发现，这类比较可能把语言本身，与它的实现、基准程序的质量、活跃处理器核心数、库的行为、内存活动以及其他执行细节混为一谈。

在控制住这些因素之后，研究者的结论是：除去执行时间的影响，编程语言的实现对能耗并没有显著作用。

核心问题并不是某门语言的语法会莫名其妙地多耗电。而是更慢的程序通常消耗更多总能量，因为硬件保持活跃的时间更长。

这个区分并不能让问题消失。

在计算密集的工作上，标准 Python 往往比优化过的编译代码慢得多。一个完成同样任务却耗时长出许多的程序，可能消耗多得多的能量——哪怕处理器在执行期间的功率相仿。

好消息是，这份低效并非不可避免。

一项 2025 年关于 Python 编译实现的研究 把 CPython 与若干编译和优化系统作了比较，包括 PyPy、Numba、Codon、Cython、Nuitka、Mypyc 和 Pyston-lite。

研究者发现，编译能够显著改善执行时间、内存占用和能耗。在部分受测负载上，Codon、PyPy 和 Numba 带来的速度与能耗改善超过 90%。

更准确的结论，并不是 Python 天生对环境有害。

而是人类在挑选编程语言时，往往依据的是人的生产力，把执行效率当成次要的考量。

Python 之所以成功，是因为它可读、富有表现力、宽容，并且背靠一个庞大的生态。在许多组织里，省下开发者的时间，值得多花一些计算时间。

智能体并不面对同样的权衡。

编码智能体不需要友好的语法来维持产出。它不需要一门好教、好打、好记的语言。它可以针对具体负载生成一种表示，为可用的硬件编译它，测量结果，并在出现更高效的实现时把它换掉。

能耗可以成为编程的一等属性，而不是等软件写完之后才尝试去做的优化。

这一点之所以要紧，是因为智能体不会只是一行一行地替换人写的代码。它们很可能会抬高被生产和被执行的软件总量。

智能体可以生成几十种实现、跑上千次测试、为单个任务造出一次性程序，并持续地重新生成可运行的系统。当软件还由人类缓慢产出时尚可容忍的低效，在机器能生成近乎无限的代码之后，后果就严重得多。

因此，第一门智能体原生语言优化的，可能不止是正确性和速度。它或许还会考量：

• 总能耗
• 预期的执行频率
• 可用的处理器与加速器
• 内存搬运
• 编译成本
• 可用电力的碳强度
• 某项负载能否被延后或迁移
• 某份实现是只跑一次，还是要跑上十亿次

也许并不存在一种放之四海皆优的表示。

一次性的数据转换，可能更看重把编译开销压到最低。一个预计要处理十亿次请求的服务，则值得做激进的原生优化。跑在电池设备上的负载，可能会把能耗置于延迟之上。数据中心里的作业，则可以围绕低碳电力的可用时段来调度。

这些决定，智能体可以自动做出。

也许真正的环境错误，并不是让智能体去写不可读的代码。而是仅仅因为人类喜欢读 Python，就逼着它们一直写下去。

那程序员会变成什么？

这一切并不意味着人类不再构建软件。

它意味着我们的工作向上移动了。

我们不再把大部分时间花在用一套为编译器设计的语法去描述实现步骤，而会花更多时间去定义：

• 这个系统应当达成什么
• 它绝不能做什么
• 哪些取舍是可以接受的
• 谁可以访问什么
• 成功如何衡量
• 失败应当如何处理
• 上线之前需要哪些证据

这依然是编程。

在很多意义上，这比亲手把那些决定翻译成循环、类、函数和配置文件，更直接地是在编程。

程序员的角色，将更少地关乎产出源代码，而更多地关乎确立意图、约束、架构与判断。这也是我总会回到那个想法的又一个原因：一旦「造」这件事本身变得廉价，品味就成了瓶颈。

软件开发的难处，从来都不是敲下语法。难处在于决定应该发生什么。

智能体正在把中间那层翻译拿掉。

它会由谁创造出来？

第一门真正的智能体原生语言，可能不会在某场开发者大会上被发布。

它可能没有一个巧妙的名字，没有公开的规范，也没有一群人在争论它的语法。

它可能悄无声息地诞生在某个智能体平台内部，作为一种私有的中间表示，用于规划、生成、验证、优化和编译软件。它起初也许仍以常规语言和既有工具链为目标，然后逐步绕开越来越多的东西。

等到人类意识到它是一门编程语言时，智能体或许已经在用它写下世界上相当一部分软件了。

胜出者未必是人类最爱读的那门语言。

而会是这样一种表示：智能体能用它造出最可靠、最安全、最高效、最可验证的系统，同时依然把对结果的实质掌控留给人类。

编程语言被发明出来，是为了让人类能告诉计算机该做什么。

下一门，也许是为了让计算机能告诉它们自己。