摘要
1) 一句话总结 随着基础软件的核心用户从人类开发者转向 AI Agent，系统设计必须顺应经典的底层心智模型，提供自然语言与代码结合的确定性接口，并构建能够支持海量、日抛型并发任务的极致低成本虚拟化基础设施。
2) 核心要点
- 用户群体发生根本转移：Infra 软件的主要使用者正迅速从人类转向 AI Agent（例如 TiDB Cloud 生产环境中超 90% 的新集群已由 Agent 创建）。
- 顺应经典心智模型：Agent 偏好其训练语料中已存在的、极其稳定的底层抽象（如文件系统、POSIX、SQL），而非全新的开发框架（如 LangChain）。
- 生态与语法差异被抹平：只要底层心智模型正确且接口稳定，Agent 并不在乎语法偏好（如 MySQL 与 Postgres 的差异），方言级别的生态差异对 AI 而言意义不大。
- 自然语言友好的接口：系统能力应能被自然语言清晰描述，Agent 能够通过上下文和多轮试错来消解自然语言的轻微歧义。
- 代码是最佳的中间表示：模糊的自然语言意图必须尽早收敛为无歧义的符号逻辑（如 Python 脚本、SQL 等代码形式），以极少的 Token 消耗实现逻辑固化、复用和确定性结果。
- 适应“日抛型”工作负载：Agent 倾向于拉起多个分支并行试错，Infra 必须支持开箱即用、生命周期极短、失败可毫无负担丢弃的资源调度模式。
- 基于虚拟化的极致低成本：面对 AI 释放的海量长尾低频需求，Infra 必须采用深度虚拟化技术（如 TiDB X），在底层资源高度共享的同时保持语义隔离，避免为每个任务分配物理实例。
- 支持大规模并行算力调度：Infra 需要支持 Agent 从单机“串行对话”模式向“分布式团队”模式转变，提供能低成本、稳定分发并收敛成百上千个并发任务的基础能力。
- 商业模式向云服务演进：AI 极大地降低了代码生产成本，使得过去不经济的长尾定制需求变得可行；成功的 Agent 公司将类似于云服务商，把单次推理成本转化为可复用的在线服务。
3) 风险与不足（原文明确提及）
- 纯 Token 商业模式的脆弱性：单纯靠售卖 Token 或消耗算力驱动的商业模式存在结构性缺陷，随着调用量和上下文增加，边际成本不会自动下降，规模扩大后成本迟早会反噬增长。
- 创新范式的接受度风险：在范式级别进行创新（如推出全新的 Agent 编程框架）极其困难，因为脱离了模型已有的认知结构，连人类都不愿学习，更难被 AI 高效使用。
- 缺乏虚拟化导致的灵活性丧失：如果 Infra 无法实现低成本的资源隔离，Agent 会被迫回到“谨慎使用资源”的模式，从而彻底丧失并行探索和快速试错的优势。
- 牺牲服务连续性的降本策略不可取：为了控制成本而采用“流量少就暂停实例（Pause）”的策略（如 Supabase 的某些做法）是不可取的，因为再小的长尾在线服务也需要保障连续性和可靠性。
正文
最近我越来越清晰地看到了一个趋势：基础软件（Infra）的主要使用者，正在从人类开发者迅速转向 AI Agent。
在 TiDB Cloud 上，我已经观察到一个非常明确的生产环境信号：每天新创建的 TiDB 集群里，超过 90% 是由 AI Agent 直接创建的。持续观察这些 Agent 如何使用数据库、创建资源、读写数据和试错，不断挑战着我们过去对“数据库应该如何被使用”的默认假设。
当基础软件的核心用户不再是人，而是 AI 时，它应该具备哪些本质特征？以下是我从本体论角度得出的一些阶段性思考。
核心心智模型：顺应 AI 的“先验”认知
当使用者从人类变成 AI，软件真正暴露给用户的不再是 UI 和 API，而是它背后的心智模型。
LLM 在训练过程中，内化了大量隐含的假设和事实约定。计算机世界里最根本的东西——文件系统、操作系统、编程语言、进程模型、I/O 抽象——在被发明出来后，核心思想和接口边界很少发生本质变化。当 AI 接触了海量代码和工程实践后，它看到的其实是大量重复的模式。这些重复沉淀为一种非常强的先验。
因此，设计“给 AI Agent 使用的软件”，必须尽可能贴合这些古老且被一再验证的心智模型（如 Bash Shell、Python、SQL）。Agent 不是在等待一个更聪明强大的全新系统，而是更喜欢一个“它已经懂的系统”，然后用比人类娴熟 1000 倍的效率写胶水代码去扩展它。这也是我不看好以 LangChain 为代表的新 Agent 开发框架的原因——它太新了，连程序员都懒得学，更何况 AI。
好的心智模型一定是可扩展的。
以文件系统为例，无论是 Plan 9 的 9PFS 还是 Linux 的 VFS，都允许在不破坏原有心智模型的前提下引入全新实现。比如我最近折腾的试验性文件系统 agfs 中的 vectorfs：文件依然是文件，echo、cat、ls、cp 等操作一切照旧。但在底层，cp 进去的文档会被自动切分、生成向量并写入 TiDB 的向量索引；grep 不再是字符串匹配，而是语义相似度搜索。
$ cp ./docs/* /vectorfs/docs # 自动创建索引/上传S3/切分Chunk
$ grep -r "What's TiDB?" ./docs # 在TiDB的向量索引上搜索只要遵循 POSIX 约定，它就可以被挂载进现有系统。这对 AI 时代尤其重要：Agent 写代码和系统演进的速度是人类的几千倍，如果没有稳定的约束很容易失控；但如果抽象是封闭的，又无法利用这种效率持续演化。
软件生态和语法偏好还重要吗？ 重要，也不重要。 不重要在于，Agent 没有“偏好”或“品味”。它不在乎 MySQL 和 Postgres 的语法差异，只要接口稳定、语义清楚、文档丰富，它就能迅速适配。 重要在于，流行的软件往往对应着极其稳固的心智模型（如关系型数据库背后的 SQL），广泛存在于 LLM 的训练语料中。只要模型站得住脚，Agent 会自动帮你跨过表层的语法差异。这也意味着，今天要在范式级别进行创新变得更加困难了。
接口设计：自然语言与符号逻辑的结合
在 Agent 作为用户的时代，一个好的软件接口需要同时满足三个条件：
- 可以被自然语言描述
- 可以被符号逻辑固化
- 能够交付确定性的结果（如果第二条做得好，第三条自然成立）
接口本身是否适合用自然语言表达意图？ 像 Cloud Code 主动放弃传统图形界面，是因为图形界面很难用自然语言准确描述。脱离了视觉上下文，GUI 对 Agent 几乎是不可见的。今天的模型本质上仍是语言模型，让它理解文字远比理解图片或隐含交互状态可靠。
很多人担心自然语言有歧义，不适合作为严肃系统的接口。但今天的 LLM 已经非常擅长结合上下文“猜出意图”。人类在真实世界解决问题，本身也高度依赖带有歧义和自我修正的自然语言。只要底层系统的心智模型正确、接口语义稳定，Agent 完全可以通过上下文和反复尝试来消解少量歧义（例如 Text-to-SQL 的实践）。像 Go 语言那样“完成一个意图大多数情况只有一种正确方式”的设计哲学，对自然语言是非常友好的。
在什么时刻，歧义被彻底消除？ 自然语言适合表达意图，但不适合承担执行语义。一旦任务需要复用、组合和自动化验证，就必须被压缩成明确、稳定、可推理的形式（如 SQL、脚本、代码、配置文件）。
Agent 友好的系统必须明确定义“歧义消除的时刻”。此时，模糊的意图被冻结为确定的结构，可存储、可审计、可复用。自然语言负责探索空间，符号负责收敛空间。
最好的逻辑符号描述是代码。 评价中间逻辑符号的标准是：能否用最少的 Token 实现最多的可能性。目前最好的逻辑符号描述就是代码。 例如，给一份 10000 个英文单词的词表生成中文释义。最笨的方法是把整个词表发给 LLM 让它逐行翻译，这极其浪费 Token。更好的方式是让 LLM 写一段 Python 脚本：
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")模型只需要理解一次“代码规则”，就能应用到任意规模的数据上。Agent 用极少的符号描述了一个可无限重复执行的过程。这就是为什么我认为编程是最好的 Meta Tool。
面向 Agent 的 Infra 特征
当 AI Agent 成为 Infra 的主要使用者，很多理所当然的设计不再成立。Agent 会快速创建资源、试错、丢弃，效率是人类的成千上万倍。
1. 日抛型工作负载 Agent 产出的工作负载本质上是日抛型的。能不能开箱即用、随时创建、失败了毫无负担地扔掉，比“长期稳定运行”重要得多。Infra 的设计前提必须假设实例是廉价的、生命周期极短且数量暴增。Agent 喜欢同时拉起多个分支并行干活，只要跑通一个，其他的直接放弃。
2. 极致的低成本与虚拟化 AI 把写代码的门槛拉到了极低，大量过去被认为“不值得做”的长尾需求（如极少数用户的微型工具）变得可行。这些需求访问频率极低，如果沿用传统模型（一个任务对应一个物理实例或进程），管理开销和机器成本将不可承受。 因此，必须引入虚拟化（虚拟数据库、虚拟分支）。在资源层面高度共享，在语义层面完全隔离。要让 Agent 感觉拥有独立环境可以随便折腾，同时实现极致的资源复用。如果做不到这一点，Agent 被迫“省着用资源”，其并行探索和快速试错的优势就会被抹杀。
3. 单位时间能撬动的算力 目前大多数交互仍是“单次请求对应一块 GPU”的串行对话模式。但现实世界的复杂任务需要分布式协作。 想象让 Agent 读完 NeurIPS 的几百篇论文。传统模式是一篇篇读；而分布式模式是瞬间开启 1000 个 Agent 并行阅读，最后由汇总 Agent 进行交叉验证和结构化输出。Infra 必须解决这个问题：能否让 Agent 低成本快速开启 1000 个工位？能否稳定分发任务、收敛结果、控制失败并让成本实时可见？这里面蕴含着 K8s 和 Hadoop 级别的机会。
商业模式的重塑：从卖算力到卖云服务
在 Agent 时代，很多过去不经济的商业模式变得合理了。
过去，为一个小超市老板定制库存管理系统是不经济的，因为研发成本远超客户的付费能力。现在，Agent 以极低的边际成本实现了代码的民主化，这些长尾需求终于可以被满足。
因此，一个真正成功的 Agent 公司，最终不应该是一家“卖 token 的公司”。单纯卖 token 存在结构性问题：随着任务变复杂，模型调用和上下文持续增长，成本也会随之飙升。靠消耗算力驱动的商业模型是非常脆弱的。
真正能跑通的模式，是像云服务公司一样，把原本持续燃烧的 token 消耗，沉淀为静态、确定性、可复用的系统能力或在线服务。一旦做到这一点，边际成本就会接近于零。底层能力（云服务、数据库）依然传统，真正变化的是被 Agent 放大了几个数量级的用户群体。例如 Manus 1.5，他们努力将 Agent 的“单次关键推理成本”，转化为具有规模化效应的传统云计算生意。
结语
Agent 时代已经到来，代码不再稀缺，软件也不再是必须精心维护的艺术品。系统被创建、试用、丢弃，都将变得非常自然。
这并不是说工程不重要了，而是工程的重点变了：不再是把某一个系统打磨到极致，而是去设计那些能被 AI 大规模使用、反复试错、低成本运行的基础能力。放下对“我是不是在写代码”的执念，反而更容易看清未来的方向。
世界已经切换到另一种使用方式了，没必要太抗拒。Welcome to the machine。