我最近越来越清晰地看到了一个趋势：Infra 软件的主要使用者，正在从开发者（人类）迅速转向 AI Agent。

例如数据库，我有直接的体感，在 TiDB Cloud 上，已经观察到一个非常明确的信号：我们每天新创建的 TiDB 集群里，超过 90% 是由 AI Agent 直接创建的，这已经是发生在生产环境里的现实。

持续观察这些 Agent 是如何使用数据库、如何创建资源、如何读写数据、如何试错，我学到了很多，AI 使用方式和人类开发者非常不同，也不断在挑战我们过去对“数据库应该如何被使用”的默认假设。

也正因为如此，我开始尝试从一个更偏本体论的角度重新思考：当基础软件的核心用户不再是人，而是 AI 时，它应该具备哪些本质特征？

目前还只是一些阶段性的思考和结论，未必成熟，但我觉得值得先记录下来。

1. 心智模型

第一个要注意的是，当使用者从人类变成 AI，软件真正暴露给用户的不再是 UI 和 API，而是它背后的心智模型。

LLM 在训练过程中，已经内化了大量隐含的假设和事实约定。

其实写代码那么多年，我越来越觉得计算机世界里最根本的东西，在被发明出来之后，其实就很少再发生本质性的变化了。

尤其是越靠近底层的部分：文件系统、操作系统、编程语言、进程模型、I/O 抽象。

这些东西几十年下来，形态在演进，但核心思想、接口边界，以及背后的假设，变化并不大。

当 AI 在训练过程中接触了海量代码（人类屎山）和工程实践之后，它看到的其实并不是多彩多样的世界，而是大量重复的模式：重复的抽象、重复的轮子、重复的选择、重复的错误修复方式。

这些重复一旦足够多，就会沉淀为一种非常强的先验。

所以，我的一个结论是：如果你希望设计的是“给 AI Agent 使用的软件”，那你必须尽可能去贴合这些古老、却被一再验证的心智模型。

这些模型并不新，它们往往已经存在了几十年，例如文件系统、Bash Shell、Python、SQL……它们共同的特点是：底层心智模型极其稳定，上层胶水非常灵活。

在这些心智模型之上，人类构建了大量胶水代码。

很多看起来复杂的系统，拆开之后，本质上只是围绕着这些稳定抽象做组合和编排。

从这个角度看，设计给 Agent 使用的软件，并不是去发明一套“全新的正确接口”，而是要主动去顺应这些已经被训练进模型里的认知结构。

换句话说，Agent 不是在等待一个更聪明强大的系统，而是更喜欢一个“它已经懂的系统”，然后用比人类娴熟 1000 倍的效率写胶水代码扩展它。

2. 好的心智模型的特征是它一定是可扩展的

以文件系统为例，这是我最近拿来反复思考的对象。

无论是 Plan 9 的 9PFS，还是 Linux 的 VFS，本质上都做了一件非常重要的事情：允许你在不破坏原有心智模型的前提下，引入全新的实现。

一个典型的例子是我最近折腾的试验性文件系统 agfs（https://github.com/c4pt0r/agfs），简单来说这是个可插拔的文件系统，你可以实现各种各样稀奇古怪的能力，只要满足文件系统的接口约束就行。

一个典型的例子：vectorfs，在 vectorfs 里，文件依然是文件，目录依然是目录，echo、cat、ls、cp -r 这些操作一切照旧；但在这个完全没有改变的心智模型之下，vectorfs 的实现偷偷做了很多事：

cp 进这个 vectorfs 的文件夹中的文档被自动切分、生成向量、写入 TiDB 的向量索引；grep 不再只是字符串匹配，而变成了语义相似度搜索。

$ cp ./docs/* /vectorfs/docs  #自动创建索引/上传S3/切分Chunk
$ grep -r "What's TiDB?" ./docs   #在TiDB的向量索引上搜索…

Linux VFS 也是一样道理，你可以实现一个完全不同语义、完全不同后端的用户态文件系统，但只要它遵循 POSIX 约定，就可以被挂载进现有系统，立刻成为系统的一部分。

对上层来说，世界并没有改变；对系统本身来说，它却获得了持续演化的能力。

这个在 AI 的时代尤其重要，因为 AI Agent 写代码的速度是人类的几千倍，系统的演进速度也是人类的几千倍，如果没有稳定的约束很容易就飞了，但是如果抽象是封闭的，那么又没办法利用这个效率持续演化。

在这个基础上，其实还有一个很自然的推论：软件生态到底还重不重要？

语法、协议，这些在 Agent 时代看起来很像旧时代八股文的程序员偏好的东西，到底还值不值得纠结？

我的结论是：重要，也不重要。

先说“不重要”的那一面。

如果你的软件是建立在一个正确的心智模型之下，那么它和主流方案之间，很多时候真的只是语法差别。

比如 MySQL 的语法和 Postgres 的语法，这些问题在人类开发者之间经常能吵得头破血流，但从 Agent 的角度看，其实意义不大。

Agent 并没有“偏好”。

只要接口是稳定的、语义是清楚的，生态是完备的，网上能找到丰富的文档，它就可以很快适配。

但这并不意味着生态完全不重要。

它之所以“重要”，并不是因为语法本身，而是因为流行的软件，往往对应着非常经典、非常稳固的心智模型，广泛存在于 LLM 的训练语料中。

不管是 MySQL 还是 Postgres，本质上都是关系型数据库，背后都是 SQL 这个模型。

所以在一个大的心智模型框架是正确的前提下，你用 MySQL 还是 Postgres，其实都能被 Agent 理解和使用。

语法和生态的差别，更像是方言问题，而不是世界观的差别。

所以对我来说，真正重要的不是生态表层的差异，而是你软件背后采用的模型是不是对的、是不是足够稳固。

3. 接口设计

如果说前面讨论的是“Agent 更容易理解什么样的系统”，那接口设计关注的就是另一个问题：Agent 应该如何与你的系统对话。

在 Agent 作为用户的时代，一个好的软件接口，至少需要同时满足三个条件：

• 可以被自然语言描述
• 可以被符号逻辑固化
• 并且能够交付确定性的结果

其中如果第二条做得足够好，第三条是自然完成的。

先展开说一下“接口能够被自然语言描述”这一点，这里的核心其实是：你的软件接口本身，是否适合用自然语言来表达意图。

举一个很直观的例子，像 Claude Code 就主动放弃了传统的图形界面。

因为图形界面很难被自然语言准确描述。

而对 Agent 友好的接口设计是：你的系统能力，本身就可以被自然语言清楚地描述出来。

一个常见的反对意见是：自然语言是有歧义的。

但站在 Agent 的视角，今天的 LLM，已经非常擅长“猜出我们到底想做什么”。

其实人类在真实世界里完成复杂工作的方式，本身就是高度依赖自然语言的，我们的思考过程就是一连串带有歧义、上下文依赖、不断自我修正的自然语言描述。

从这个角度看，自然语言并不是一种不精确的 tradeoff，而是人类解决问题时的原生表示。

LLM 模型所做的，只是把这种原本发生在人类之间的推理过程规模化和数字化了。

所以，与其过分担心歧义，不如承认一个现实：当底层系统软件的心智模型是对的、接口的语义是稳定的、结果是可验证的时，上层调用者（Agent）的少量歧义并不会成为系统性问题。

Agent 可以通过上下文、反馈和反复尝试来消解它。

在数据库领域，这一点其实最近已经有了很好的实践，比如 Text-to-SQL。

它证明了一件事：如果你的系统抽象是对的，那么它的能力天然就适合被语言描述。

不过也正因为自然语言输入可以是有歧义的，系统内部反而必须尽早收敛到一个无歧义的中间表示。

这正是我想说的第二点：系统的符号逻辑能被固化。

自然语言非常适合用来表达意图，但它并不适合承担执行语义。

一旦任务要被复用、组合和自动化验证，就必须被压缩成一种明确、稳定、可推理的形式。

这也是为什么，几乎所有成功的系统，都会在“人类可读的输入”和“机器可执行的行为”之间，放置一个中间层，如：SQL、脚本、代码、配置文件。

在 Agent 作为使用者的场景下，自然语言负责探索空间，符号负责收敛空间。

那什么样的逻辑符号描述是好的？

我个人的一个评价标准是：这个中间逻辑符号表示是否可以用尽可能少的 Token，实现最多的可能性。

而我认为目前（2025 年底）最好的逻辑符号描述，就是代码，即使对于非编程 Agent 来说也是。

代码并不是一个“节省成本”的问题，而是一个认知密度的问题。

模型只需要理解一次“代码规则”，然后把它应用到任意规模的数据上，Agent 只用极少的符号，描述了一个可以被无限重复执行的过程。

这就是为什么我坚持编程其实是最好的 Meta Tool 的原因。

def enrich_vocab(src, dst, llm_translate):
    with open(src) as f, open(dst, "w") as out:
        for word in map(str.strip, f):
            if not word:
                continue
            zh = llm_translate(word)
            out.write(f"{word}\t{zh}\n")

4. 构建给 Agent 使用的 Infra 的 Infra 的一些必要特征

当 AI Agent 成为 Infra 的主要使用者之后，很多我们以前觉得理所当然的设计，其实都开始不太成立了。

现在 AI Infra 的用户已经不是那种会被认真规划、长期维护的“人类开发者”了，而是 Agent：它们会非常快地创建资源、试一把，不行就丢掉，再换个方式重来。

日抛型代码

Agent 产出的工作负载，本质上就是日抛型的。

能不能开箱即用、能不能随时创建、失败了是不是可以毫无负担地扔掉，这些都比“长期稳定运行”重要得多。

这意味着，Infra 的设计前提已经不能再是假设“一个集群很宝贵”。

你必须假设实例本身是便宜的、生命周期很短、而且数量会涨得非常快。

由于 AI Agent 的出现，写代码的门槛已经被拉得非常低了。

这意味着：大量过去被忽略、被认为“不值得做”的需求，其实都突然变得可行了。

最终被服务的对象，不再只是那一小撮“值得投入工程成本”的用户，而是更广泛、更长尾的真实需求。

4.1. 极致的低成本

这里说的“极致的成本”，是指在满足大量长尾需求的前提下，系统的成本还能不能撑得住。

这些需求有一个很典型的特点：访问频率非常低。

如果你还沿用传统的模型，光是管理这些进程、资源、状态的复杂性就已经是一个不可承受的开销了。

所以在多租户和成本这个问题上，我觉得有一个结论其实是绕不过去的：你不可能真的为每一个需求、每一个 Agent，提供一个真实的物理实例。

你必须引入某种形式的虚拟化：虚拟数据库实例、虚拟分支、虚拟环境。

它们在资源层面是高度共享的，但在语义层面，又必须是隔离的。

4.2. 单位时间能撬动的算力

还有一个点：**单位时间、单位任务，你到底能撬动多少算力？**这个指标非常重要。

传统的 Agent 交互模式更像是“串行对话”，而不是“并行干活”。

而现实世界很多复杂任务是需要依靠大规模团队分工合作的。

想象一个“分布式 Agent 团队”：你可以把任务拆成几百个小块，直接分发给 100 个、1000 个 Agent 并行去干。

这种模式下，你单位时间对一个任务能撬动的算力不再是一块 GPU，而是一个可以按需扩展的规模。

而这恰恰会反过来提出一个非常具体的 Infra 问题：**如果 Agent 会天然倾向于这种并行探索，那你的系统是不是能让它低成本快速地开 1000 个工位？**能不能稳定地分发任务、收敛结果、去重、纠错？

5. 商业模式的转变

在 Agent 时代，很多过去不太经济的商业模式，突然变得合理了。

过去“定制化需求”基本就是一个 red flag，因为人力成本太贵。

而 Agent 改变了这一点，AI Agent 第一次把“计算”这件事，真正意义上地民主化了。

写代码、试想法、做原型，现在可以被 Agent 以极低的边际成本实现。

所以我现在越来越觉得，一个真正成功的 Agent 公司，最终不应该是一家“卖 token 的公司”。

单纯卖 token 是有结构性问题的，边际成本并不会自动下降。

真正能跑通的模式，是把原本持续燃烧的 token 消耗，逐步沉淀成一些在线服务，或者沉淀成静态、确定性、可以被复用的系统能力。

一旦做到这一点，边际成本就会被极大地摊薄，甚至接近于零。

云服务还是云服务，数据库还是数据库，很多底层能力本身都很传统。

真正发生变化的，是使用这些服务的用户群体，被 Agent 放大了几个数量级。

6. 结尾

Agent 时代来了，代码不再稀缺，软件也不再是需要精心维护的东西，系统被创建、试用、丢弃，都会变得非常自然。

这并不是说工程不重要了，恰恰相反。

只是工程的重点变了：不再是把某一个系统打磨到极致，而是去设计那些能被 AI 大规模使用、反复试错、低成本运行的基础能力。

放下对“我是不是在写代码”的执念，反而会更容易看清接下来要做什么。

世界已经切换到另一个使用方式了，没必要太抗拒。

Welcome to the machine。