推荐语
AI Agent正在重塑基础软件的使用方式，从人类开发者转向智能体，这背后隐藏着怎样的设计哲学？
核心内容：
1. AI Agent使用数据库等基础软件的现状与趋势
2. 设计给AI Agent使用的软件需遵循的心智模型
3. 稳定抽象与灵活胶水在AI时代的重要性
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
正好快圣诞节了，在美国，我周围已经弥漫着放假的气息，这几天正好有点时间，把最近我一直在反复思考一个问题写一写（放心，上一个系列还会写的。。。别催了别催了），主要是我最近越来越清晰地看到了一个趋势：Infra 软件的主要使用者，正在从开发者（人类）迅速转向 AI Agent。
例如数据库，我有直接的体感，在 TiDB Cloud 上，已经观察到一个非常明确的信号：我们每天新创建的 TiDB 集群里，超过 90% 是由 AI Agent 直接创建的，这已经是发生在生产环境里的现实。
持续观察这些 Agent 是如何使用数据库、如何创建资源、如何读写数据、如何试错，我学到了很多，AI 使用方式和人类开发者非常不同，也不断在挑战我们过去对“数据库应该如何被使用”的默认假设。
也正因为如此，我开始尝试从一个更偏本体论的角度重新思考：当基础软件的核心用户不再是人，而是 AI 时，它应该具备哪些本质特征？目前还只是一些阶段性的思考和结论，未必成熟，但我觉得值得先记录下来。
心智模型
第一个要注意的是，当使用者从人类变成 AI ，软件真正暴露给用户的不再是 UI 和 API，而是它背后的心智模型。
LLM 在训练过程中，已经内化了大量隐含的假设和事实约定。其实写代码那么多年，我越来越觉得计算机世界里最根本的东西，在被发明出来之后，其实就很少再发生本质性的变化了。尤其是越靠近底层的部分：文件系统、操作系统、编程语言、进程模型、I/O 抽象。这些东西几十年下来，形态在演进，但核心思想、接口边界，以及背后的假设，变化并不大。
当 AI 在训练过程中接触了海量代码（人类屎山）和工程实践之后，它看到的其实并不是多彩多样的世界，而是大量重复的模式：重复的抽象、重复的轮子、重复的选择、重复的错误修复方式。这些重复一旦足够多，就会沉淀为一种非常强的先验（毕竟人类的本质其实是复读机 LOL）
所以，我的一个结论是：如果你希望设计的是“给 AI Agent 使用的软件”，那你必须尽可能去贴合这些古老、却被一再验证的心智模型。
这些模型并不新，它们往往已经存在了几十年，例如文件系统，Bash Shell，Python，SQL...它们共同的特点是：底层心智模型极其稳定，上层胶水非常灵活。在这些心智模型之上，人类构建了大量胶水代码（我一直觉得真正的 IT 世界其实是由这些胶水组成的）。很多看起来复杂的系统，拆开之后，本质上只是围绕着这些稳定抽象做组合和编排。
从这个角度看，设计给 Agent 使用的软件，并不是去发明一套“全新的正确接口”（这也是我不看好以 LangChain 为代表的一系列新的 Agent 开发框架的原因，因为它太新了，连程序员都懒得学，更何况 AI 了），而是要主动去顺应这些已经被训练进模型里的认知结构。换句话说，Agent 不是在等待一个更聪明强大的系统，而是更喜欢一个“它已经懂的系统”然后用比人类娴熟1000倍的效率写胶水代码扩展它。
好的心智模型的特征是它一定是可扩展的。
以文件系统为例，这是我最近拿来反复思考的对象。无论是 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 的语法，比如 MongoDB 和其他一些 NoSQL 数据库之间的选择，这些问题在人类开发者之间经常能吵得头破血流，但从 Agent 的角度看，其实意义不大。Agent 并没有“偏好”。它不会在乎语法优不优雅，也不会在乎社区文化，更不会纠结“哪一个更像正统”。只要接口是稳定的、语义是清楚的，生态的是完备的，网上能找到丰富的文档，它就可以很快适配。这种偏好性的差异，在 Agent 这边会被完全磨平，几乎可以忽略。但这并不意味着生态完全不重要。
它之所以“重要”，并不是因为语法本身，而是因为流行的软件，往往对应着非常经典、非常稳固的心智模型，广泛存在与 LLM 的训练语料中。不管是 MySQL 还是 Postgres，本质上都是关系型数据库，背后都是 SQL 这个模型。而 SQL 本身，就是一个被反复验证过的、极其稳定的抽象，知识从 pg 迁移到 mysql 或者反过来都是很容易的事情。所以在这个大的心智模型框架是正确的前提下，你用 MySQL 还是 Postgres，其实都能做 CRUD，都能保证一致性，也都能被 Agent 理解和使用。语法和生态的差别，更像是方言问题，而不是世界观的差别。所以对我来说，真正重要的不是生态表层的差异，而是你软件背后采用的模型是不是对的、是不是足够稳固。只要这个模型站得住脚，Agent 会自动帮你跨过剩下的那些八股文似的品味之争。但是这也意味着一个悲伤的推论：今天要在范式级别创新是更加困难了，这也是在前面我不看好类似 Langchain 这样的编程框架的原因。接口设计
如果说前面讨论的是 “Agent 更容易理解什么样的系统”，那接口设计关注的就是另一个问题：Agent 应该如何与你的系统对话。在 Agent 作为用户的时代，一个好的软件接口，至少需要同时满足三个条件：
其中如果第二条做得足够好，第三条是自然完成的。
先展开说一下“接口能够被自然语言描述”这一点，我觉得这里的核心其实不是“要不要支持自然语言输入”，而是：你的软件接口本身，是否适合用自然语言来表达意图。
举一个很直观的例子，像 Cloud Code 就主动放弃了传统的图形界面。原因并不复杂，图形界面在很多时候，其实是很难被自然语言准确描述的。你很难用一句话把“点哪里、拖到哪里、选中哪个状态”讲清楚，而一旦脱离了视觉上下文，这套接口对 Agent 来说就几乎是不可见的，而编码绝大多数场景是在符号和语言打交道。
这里背后还有一个更现实的原因：我们今天使用的模型，本质上仍然是语言模型。让模型去理解一段文字，远比让它去理解一张图片或者一套隐含的交互状态要简单和可靠得多。所以，对 Agent 友好的接口设计是：你的系统能力，本身就可以被自然语言清楚地描述出来。
一个常见的反对意见是：自然语言是有歧义的，因此不适合作为严肃系统的接口。但站在 Agent 的视角，这个问题可能需要重新思考。
今天的 LLM，已经非常擅长“猜出我们到底想做什么”。这并不是因为语言突然变得精确了，而是因为模型在训练过程中已经见过了无数类似的意图表达、上下文约束和任务模式。成功率也许不是 100%，但在绝大多数工程场景下，它已经足够高。
例如，在最新的 Claude Code 中，已经开始加入预测你下一步会干啥的功能，我自己的使用经验是，大多数情况下，预测是很准确的。
其实人类在真实世界里完成复杂工作的方式，本身就是高度依赖自然语言的，无论是和同事讨论方案，还是在自己脑子里推演，我们的思考过程就是一连串带有歧义、上下文依赖、不断自我修正的自然语言描述。从这个角度看，自然语言并不是一种不精确的 tradeoff，而是人类解决问题时的原生表示。LLM 模型所做的，只是把这种原本发生在人类之间的推理过程规模化和数字化了。
所以啊，与其过分担心歧义，不如承认一个现实：当底层系统软件的心智模型是对的、接口的语义是稳定的、结果是可验证的时，上层调用者（Agent）的少量歧义并不会成为系统性问题。Agent 可以通过上下文、反馈和反复尝试来消解它（通常不会错得离谱），而不需要一开始就被迫进入一套过度严格的形式体系。
在数据库领域，这一点其实最近已经有了很好的实践，比如 Text-to-SQL。它未必百分之百准确，但它证明了一件事：如果你的系统抽象是对的，那么它的能力天然就适合被语言描述。
我甚至会觉得，对于一个“设计正确”的系统来说，完成一个意图大多数情况只有一种正确的方式，这样的系统也是很自然语言友好的。就像我很喜欢的 Go 语言就遵循这个设计哲学。很多人不喜欢这一点，但是我觉得这是一个相当有智慧的设计，极大的减少了产生歧义的空间。
不过也正因为自然语言输入可以是有歧义的，系统内部反而必须尽早收敛到一个无歧义的中间表示。这正是我想说的第二点：系统的符号逻辑能被固化。自然语言非常适合用来表达意图，但它并不适合承担执行语义。一旦任务要被复用，组合和自动化验证，就必须被压缩成一种明确、稳定、可推理的形式。这也是为什么，几乎所有成功的系统，都会在“人类可读的输入”和“机器可执行的行为”之间，放置一个中间层，例子仍然是： SQL，脚本，代码，配置文件。。。它们的共同点是一旦生成，就不再依赖上下文解释。在 Agent 作为使用者的场景下，这个中间表示的意义被进一步放大了。Agent 可以容忍输入阶段的模糊，通过猜测和多轮修正（与人类）来逼近意图。因此，一个 Agent 友好的系统接口设计要明确地回答一个问题：“在什么时刻，歧义被彻底消除？”当这个时刻被清晰地定义出来，系统就获得了一种新的能力：它可以将一次模糊的意图，冻结为一个确定的结构，可存储、可审计、可复用，也可以被另一个 Agent 在未来重新加载并继续执行。自然语言负责探索空间，符号负责收敛空间。而只有在完成这一步之后，“确定性的结果”才成为可能。
那什么样的逻辑符号描述是好的？我个人的一个评价标准是：这个中间逻辑符号描述表示是否可以用尽可能少的 Token，实现最多的可能性。而我认为目前（2025年底）最好的逻辑符号描述，就是代码，即使对于非编程 Agent 来说也是。
这并不是一个“节省成本”的问题，而是一个认知密度的问题。我举个例子，我最近想背单词，于是找了一份 10000 个单词的词表，但是这个词表只有英文单词，我希望用 LLM 给我生成一份有中英释义的版本。最土的办法，就是直接把整个词表发给 LLM，然后说：给每一行加上中文释义，最后让 LLM 输出整个带中英释义的词表。
但这个方式的问题非常明显：它对 Token 的使用极其低效。一个更好的方式，其实是把这个需求先固化成一段逻辑，也就是一段 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 的原因（我不喜欢疯狂堆 MCP Tool 的风气）。
构建给 Agent 使用的 Infra 的 Infra 的一些必要特征
AI Infra's Infra, 我承认这个标题有些拗口，但是你能理解这个意思就好。当 AI Agent 成为 Infra 的主要使用者之后，很多我们以前觉得理所当然的设计，其实都开始不太成立了。现在 AI Infra 的用户已经不是那种会被认真规划、长期维护的“人类开发者”了，而是 Agent：它们会非常快地创建资源、试一把，不行就丢掉，再换个方式重来。而且这种尝试的速度和效率，往往是人类的成千上万倍，这也直接改变了 Infra 应该长成什么样。先说一个很明显的点：Agent 产出的工作负载，本质上就是日抛型的。能不能开箱即用、能不能随时创建、失败了是不是可以毫无负担地扔掉，这些都比“长期稳定运行”重要得多。哪怕成功了，很多时候也只是阶段性结果，并不一定会被保留下来。
这意味着，Infra 的设计前提已经不能再是假设“一个集群很宝贵”。你必须假设实例本身是便宜的、生命周期很短、而且数量会涨得非常快。
我在观察 AI Agent 使用 TiDB 的时候，有一个特别直观的感受：它们很喜欢同时拉起多个 branch 并行干活，只要有一个分支跑通了，其他的基本就可以直接放弃了。Agent 写的 SQL 也好，生成的代码也好，看起来往往都挺“胶水”的，不追求优雅，但只要
能跑、能验证想法，就完全可以接受。
顺着这个思路，其实还有一个很自然的推论。
由于 AI Agent 的出现写代码的门槛已经被拉得非常低了，低到什么程度呢？低到“写代码”这件事本身，已经不再是稀缺能力了。很多在过去需要工程师投入大量时间才能完成的东西，现在对 Agent 来说只是一次生成成本的问题。
这件事意味着什么？我觉得一个很重要的变化是：大量过去被忽略、被认为“不值得做”的需求，其实都突然变得可行了。不管是某个很小的功能、一次性的工具，还是只服务于极少数用户的场景，只要 Agent 能快速写、快速跑、快速验证，这些需求就不再需要被“筛选”掉。
换句话说，代码的生产能力被极大地释放了，最终被服务的对象，也不再只是那一小撮“值得投入工程成本”的用户，而是更广泛、更长尾的真实需求，于是我预计对于基础软件的可靠性和总租户数量会爆炸性增长，但是对于服务连续性和可靠性的需求其实并没有下降（这也是为什么我认为Supabase 之类因为流量少而 Pause 实例控制成本的方式是不可取的，再小的在线服务，也是在线服务）。
不过这一点，我更想放到后面商业模式变化那一节里单独展开去说。因为当供给侧的成本几乎趋近于零时，整个价值分配方式，其实都会随之发生变化。
极致的低成本
这里说的“极致的成本”，并不是简单意义上的“便宜”，而是指在满足大量长尾需求的前提下，系统的成本还能不能撑得住。
前面提到，AI 把很多原本“不值得做”的需求都变得可行了。但这些需求有一个很典型的特点：访问频率非常低。可能一天就一两个请求，甚至几天才会被碰一次，但它们确实存在，而且确实有人（或者说有 Agent）在用。
如果你还沿用传统的模型，比如一个任务对应一个真实的 Infra 环境，或者像 Postgres 那样，一个 Agent 任务背后就是一个 pg 进程：你可以想象一下你的用户规模起来以后，你要维护上百万个这样的实例，光是管理这些进程、心跳、资源、状态，本身的复杂性就已经是一个不可承受的开销了，更不用说机器成本。
所以在多租户和成本这个问题上，我觉得有一个结论其实是绕不过去的：
你不可能真的为每一个需求、每一个 Agent，提供一个真实的物理实例。
你必须引入某种形式的虚拟化：虚拟数据库实例、虚拟分支、虚拟环境。它们在资源层面是高度共享的，但在语义层面，又必须是隔离的。
真正难设计的地方，其实就在这里：
在实现极致资源复用的同时，还要在交互层面让 Agent 感觉：这是我自己的独立环境，我可以随便折腾。
一个典型的例子来自于 Manus 1.5，他们背后的 Agent 其实在使用 TiDB Cloud 来作为数据库方案，于是这些 Agent 它可以建表、删表、跑实验、写垃圾 SQL，而不会影响别人，也不用担心副作用。TiDB X 其实就是为了这个场景设计的（虽然几年前我们在设计的时候没有预想今天 AI Agent 的一切，只能说有点歪打正着的幸运）。全栈的 Webapp （Manus 1.5）比 Frontend （Lovable）要更难做，主要的难点就是成本。
如果你做不到这一点，Agent 就会被迫回到“谨慎使用资源”的模式；而一旦 Agent 需要开始“省着用”，整个并行探索、快速试错，灵活性的优势就会被彻底抹掉。
从这个角度看，这种“看起来像独占，实际上是虚拟化”的设计，并不是一个优化项，而是想要构建一个可规模化、超低成本 Agent Infra 的前提条件。
单位时间能撬动的算力
还有一个点，我觉得现在很多人讨论 AI Agent Infra 的时候很少讨论：单位时间，单位任务，你到底能撬动多少算力？这个指标非常重要，因为这是 Agent 要完成复杂任务必须关注的。
举个简单的例子。现在不管是 ChatGPT，还是你在自己机器上跑的 Coding Agent，大多数交互模式都是一样的：你问一句话，它把这句话发到某个 API 背后（可能是 OpenAI，也可能是 Anthropic），在他们数据中心的某一块 GPU 上做推理，然后再把答案返回给你。你再问下一句，再来一轮。这意味着，从系统层面看，你单位时间能调动的算力资源，本质上就被锁定在“单次请求对应的一块 GPU”上。它当然很强，但它的工作方式更像是“串行对话”，而不是“并行干活”。我们从 2022 年 ChatGPT 开始就习惯了这样单机的基于人和机器一来一回对话的交互模式，而现实世界很多复杂任务是需要依靠大规模团队分工合作的。
想象一个最简单的场景：比如我想把今年 NeurIPS 的论文快速读一遍，可能是几百篇，然后挑出有意思的给我汇报。传统的 Agent 逻辑大概率就是一篇一篇读，最多做一点缓存或者总结模板，本质上还是顺序推进。而如果换一个思路，把它当成一个“分布式 Agent 团队”的问题，事情会完全不同。你可以把任务拆成几百个小块，直接分发给 100 个、1000 个 Agent 并行去读。它们读完以后，各自把摘要、关键结论、疑点和引用发回来，再由一个汇总的 Agent 去做二次归纳、交叉验证、结构化输出。你可以把它理解成一种“wide research”式的工作流，这是最简单的一种分布式模式。
在这种模式下，你单位时间对一个任务能撬动的算力就不再是一块 GPU，而是一个可以按需扩展的规模：刚才那个例子里，可能就是 100、1000，甚至更多。
而这恰恰会反过来提出一个非常具体的 Infra 问题：
如果 Agent 会天然倾向于这种并行探索，那你的系统是不是能让它低成本快速地开 1000 个工位？能不能稳定地分发任务、收敛结果、去重、纠错？失败是不是可控、可回放？成本是不是实时可见？这里面可能是一个 K8s 和 Hadoop 级别的机会。商业模式的转变
在商业模式这一块，我其实最想强调的第一个变化是：在 Agent 时代，很多过去不太经济的商业模式，突然变得合理了。
这个问题我们做基础软件、做数据库的人，其实体感非常强。过去只要一提“定制化需求”，基本就是一个 red flag: 我的人是最贵的，为了一个小客户、一个没有普适性的场景去投入研发是不行的。
举一个更容易理解的例子，假设有一个没有任何计算机背景的小超市老板，他其实一直都很想做一个库存管理系统，或者一个小小的网店，能帮他管商品、管订单。但现实是，过去他很难一下子拿出十几二十万，去雇一个开发团队，把这些东西按他的想法做出来，更别说后续的运维。
而从传统软件公司的角度看，这个需求同样是不成立的，我不可能为了你一个小超市去投入一个团队；更何况，即便做出来了，你的付费能力本身也是有限的。
所以在过去，需求其实一直都在，但它们被“经济性”挡在了门外。不是没有人需要，而是没有一种合理的方式，用足够低的成本去满足这些长尾的需求。我觉得 Agent 改变的，恰恰是这一点。AI Agent 第一次把“计算”这件事，真正意义上地民主化了。写代码、试想法、做原型，这些过去必须由专业工程师完成的事情，现在可以被 Agent 以极低的边际成本实现。很多以前算不过账的事情，并不是需求消失了，而是成本终于降到足够低了。所以我现在越来越觉得，一个真正成功的 Agent 公司，最终不应该是一家“卖 token 的公司”。仔细想一想就会发现，单纯卖 token 这件事，本身是有结构性问题的。随着用户越来越多、任务越来越复杂，模型调用次数和上下文长度都会持续增长，而 token 的边际成本并不会自动下降，哪怕 Token 单价在变得越来越便宜也好，只要你卖得越多，成本也随之增长（而且别的竞争对手也会降价），这在商业上其实是非常脆弱的。从这个角度看，很多现在靠大量消耗算力来驱动的 Agent 公司，本质上商业模型是站不稳的。除非能像前面说的那样，把“每一次都要重新推理”的事情，转化为“一次构建、反复使用”的服务，否则规模一上来，成本迟早会反噬增长。
于是真正能跑通的模式，或一家成功的 AI Agent 公司反而更像是一家把目标用户群体放大了 100 倍、1000 倍的云服务公司。关键不在于 token，成本，而在于你能不能把原本持续燃烧的 token 消耗，逐步沉淀成一些 “boring” 的在线服务，或者更进一步，沉淀成静态、确定性、可以被复用的系统能力。一旦做到这一点，边际成本就会被极大地摊薄，甚至接近于零。有意思的是，这并不意味着你最终提供的东西是“全新的形态”。云服务还是云服务，数据库还是数据库，很多底层能力本身都很传统。真正发生变化的，是使用这些服务的用户群体，被 Agent 放大了几个数量级。所以说到这里，我还是想再提一次Manus 1.5Full stack webapp 这个例子（不好意思，又是这个 case），最近他们正好官宣了 ARR 过 100M USD, 还是比较应景的。一方面，它确实是我们 TiDB Cloud 的客户；但更重要的是，我觉得它背后的商业模式设计，真的非常有意思，也非常有代表性。它并不是简单地在卖算力、卖 token，或者靠一次次推理去换收入，而是在努力把 Agent 的“单次关键推理成本”，转化成有规模化效应的传统云计算生意。
结尾
写到这里，也快要结尾了，其实说来说去，我的想法也挺简单的，Agent 时代来了，很多我们作为程序员习以为常的前提，确实需要重新想一想了。代码不再稀缺，软件也不再是需要精心维护的东西，系统被创建、试用、丢弃，都会变得非常自然。
这并不是说工程不重要了，恰恰相反。只是工程的重点变了：不再是把某一个系统打磨到极致，而是去设计那些能被 AI 大规模使用、反复试错、低成本运行的基础能力。放下对“我是不是在写代码”“我是不是在控制系统”的执念，反而会更容易看清接下来要做什么。很多真正重要的事情，其实都回到了老问题上。
世界已经切换到另一个使用方式了，没必要太抗拒。
Welcome to the machine。
粤ICP备14082021号
免费POC，
零成本试错
