基础软件的主要使用者，正从人类开发者迅速转向AI Agent。
以数据库为例，一个明确的信号是：在TiDB Cloud上，每天新创建的集群中，超过90%直接由AI Agent驱动，这已是生产环境的普遍现实。
持续观察这些Agent如何创建资源、读写数据、进行试错，我们学到了很多。AI的使用方式与人类开发者截然不同，并不断挑战我们过去对“数据库应如何被使用”的默认假设。
因此，我们开始尝试从一个更偏本体论的角度重新思考：当基础软件的核心用户变为AI时，它应具备哪些本质特征？以下是一些阶段性的思考。
心智模型：拥抱稳定而非发明新颖
首先需要注意，当使用者变为AI时，软件真正暴露给用户的不再是UI或API，而是其背后的心智模型。
大语言模型在训练过程中，已内化了大量隐含的假设和事实约定。在计算机世界，越靠近底层的东西——如文件系统、操作系统、编程语言——其核心思想、接口边界及背后假设，数十年来变化甚微。
当AI在训练中接触了海量代码和工程实践后，它看到的并非多彩世界，而是大量重复的模式：重复的抽象、重复的轮子、重复的错误修复方式。这些重复一旦足够多，便会沉淀为一种极强的先验。
因此，一个核心结论是：如果你希望设计“给AI Agent使用的软件”，就必须尽可能去贴合那些古老却被一再验证的心智模型。
这些模型并不新，它们往往已存在几十年，例如文件系统、Bash Shell、Python、SQL。它们的共同特点是：底层心智模型极其稳定，上层胶水非常灵活。
在这些稳定模型之上，人类构建了大量胶水代码。许多看似复杂的系统，拆解后本质上是围绕这些稳定抽象进行的组合与编排。
从这个角度看，设计给Agent使用的软件，并非发明一套“全新的正确接口”，而是要主动顺应那些已被训练进模型里的认知结构。换句话说，Agent更喜欢一个“它已经懂的系统”，然后用比人类娴熟千倍的效率编写胶水代码来扩展它。
可扩展性是优秀心智模型的基石
好的心智模型一定是可扩展的。
以文件系统为例，无论是Plan 9的9PFS，还是Linux的VFS，都做了一件关键的事：允许你在不破坏原有心智模型的前提下，引入全新的实现。
例如试验性文件系统agfs，它是一个可插拔的文件系统，你可以实现各种新奇的能力，只要满足文件系统的接口约束。以vectorfs为例：文件依然是文件，目录依然是目录，echo、cat、ls、cp -r等操作一切照旧。但在这个未改变的心智模型之下，vectorfs的实现“偷偷”做了很多事：拷贝进该文件夹的文档被自动切分、生成向量、并写入TiDB的向量索引；grep不再只是字符串匹配，而变成了语义相似度搜索。
$ cp ./docs/* /vectorfs/docs # 自动创建索引/上传S3/切分Chunk
$ grep -r “What‘s TiDB?” ./docs # 在TiDB的向量索引上搜索…
Linux VFS同理。你可以实现一个完全不同语义、不同后端的用户态文件系统，只要遵循POSIX约定，就能被挂载进现有系统，立刻成为其一部分。对上层，世界未变；对系统，它获得了持续演化的能力。这在AI时代尤为重要，因为Agent写代码的速度是人类的数千倍，系统的演进速度也相应加快。没有稳定约束容易失控，但若抽象是封闭的，又无法利用这种效率持续演化。
基于此，一个自然的推论是：软件生态、语法、协议这些看似像“八股文”的程序员偏好，在Agent时代还重要吗？
结论是：重要，也不重要。
“不重要”的一面在于，如果你的软件建立在正确的心智模型下，那么它与主流方案之间，很多时候只是语法差别。例如MySQL与PostgreSQL的语法选择，在人类开发者间可能争论不休，但从Agent角度看意义不大。Agent没有“偏好”，它不在乎语法是否优雅或社区文化，只要接口稳定、语义清晰、生态完备、文档丰富，它就能快速适配。
但它之所以“重要”，并非因为语法本身，而是因为流行软件往往对应着经典、稳固且广泛存在于LLM训练语料中的心智模型。无论是MySQL还是PostgreSQL，本质都是关系型数据库，背后都是SQL模型。SQL本身就是一个被反复验证的、极其稳定的抽象。
因此，在大的心智模型框架正确的前提下，使用MySQL还是PostgreSQL都能完成CRUD，保证一致性，并被Agent理解使用。语法和生态的差别，更像是方言问题，而非世界观的差别。真正重要的是软件背后的模型是否正确、稳固。只要模型站得住脚，Agent会自动跨过那些品味之争。
接口设计：自然语言、符号逻辑与确定性
如果说前面讨论的是“Agent更容易理解什么样的系统”，那么接口设计关注的是“Agent应如何与你的系统对话”。在Agent作为用户的时代，一个好的软件接口需同时满足三个条件：
- 可以被自然语言描述
- 可以被符号逻辑固化
- 能够交付确定性的结果
若第二条做得足够好，第三条自然完成。
首先，“接口能够被自然语言描述”的核心，并非“是否支持自然语言输入”，而是：你的软件接口本身，是否适合用自然语言来表达意图。
一个直观的例子是Cloud Code主动放弃了传统图形界面。原因很简单：图形界面很难被自然语言准确描述。你很难用一句话讲清“点哪里、拖到哪里、选中哪个状态”，一旦脱离视觉上下文，这套接口对Agent就几乎不可见。此外，当今模型本质仍是语言模型，让模型理解文字远比理解图片或隐含交互状态简单可靠得多。
因此，对Agent友好的接口设计是：系统的能力本身就可以被自然语言清楚地描述。
一个常见反对意见是：自然语言有歧义，不适合作为严肃系统的接口。但从Agent视角看，这个问题需重新思考。今天的LLM已非常擅长“猜出我们到底想做什么”，这不是因为语言变精确了，而是因为模型在训练中见过无数类似的意图表达、上下文约束和任务模式。成功率也许不是100%，但在绝大多数工程场景下已足够高。
人类在真实世界完成复杂工作的方式，本就高度依赖自然语言。我们的思考过程就是一连串带有歧义、上下文依赖、不断自我修正的自然语言描述。自然语言并非一种不精确的妥协，而是人类解决问题的原生表示。LLM所做的，只是将这种推理过程规模化和数字化。
所以，与其过分担心歧义，不如承认一个现实：当底层系统软件的心智模型正确、接口语义稳定、结果可验证时，上层调用者（Agent）的少量歧义并不会成为系统性问题。Agent可以通过上下文、反馈和反复尝试来消解它。
在数据库领域，Text-to-SQL已是一个很好的实践。它未必百分之百准确，但证明了一件事：如果你的系统抽象正确，那么它的能力天然就适合被语言描述。对于一个“设计正确”的系统，完成一个意图在大多数情况下只有一种正确方式，这样的系统自然也是语言友好的。
不过，正因为自然语言输入可能有歧义，系统内部必须尽早收敛到一个无歧义的中间表示。这正是第二点：系统的符号逻辑能被固化。
自然语言适合表达意图，但不适合承担执行语义。一旦任务需要被复用、组合和自动化验证，就必须被压缩成一种明确、稳定、可推理的形式。
几乎所有成功的系统，都会在“人类可读的输入”和“机器可执行的行为”之间放置一个中间层，例如：SQL、脚本、代码、配置文件。它们的共同点是一旦生成，就不再依赖上下文解释。
在Agent作为使用者的场景下，这个中间表示的意义被进一步放大。Agent可以容忍输入阶段的模糊，通过猜测和多轮修正来逼近意图。因此，一个Agent友好的系统接口设计要明确回答：“在什么时刻，歧义被彻底消除？”
当这个时刻被清晰定义，系统就获得了一种新能力：它可以将一次模糊的意图，冻结为一个确定的结构，可存储、可审计、可复用，也可被另一个Agent在未来重新加载并继续执行。自然语言负责探索空间，符号负责收敛空间。只有完成这一步后，“确定性的结果”才成为可能。
那么，什么样的逻辑符号描述是好的？一个评价标准是：这个中间表示是否可以用尽可能少的Token，实现最多的可能性。
目前（2025年底）最好的逻辑符号描述就是代码，即使对非编程Agent也是如此。这并非“节省成本”问题，而是一个认知密度问题。
例如，想为一万个单词的词表添加中文释义。最原始的方法是将整个词表发给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用极少的符号，描述了一个可无限重复执行的过程。
构建AI Infra的Infra：必要特征
当AI Agent成为基础软件的主要使用者后，许多过去理所当然的设计开始不再成立。
如今，基础软件的用户不再是会被长期维护的“人类开发者”，而是Agent：它们会极快地创建资源、试错、丢弃、重来。这种尝试的速度和效率是人类的成千上万倍，直接改变了基础软件应有的形态。
日抛型代码与工作负载
Agent产出的工作负载本质上是日抛型的。开箱即用、随时创建、失败后毫无负担地丢弃，这些都比“长期稳定运行”更重要。这意味着，基础软件的设计前提不能再是“一个集群很宝贵”。你必须假设实例本身便宜、生命周期短、数量增长极快。
观察AI Agent使用TiDB时有一个直观感受：它们喜欢同时拉起多个分支并行干活，只要一个分支跑通，其他基本可直接放弃。Agent写的SQL或生成的代码通常很“胶水”，不追求优雅，但只要能跑、能验证想法，就完全可以接受。
由此还有一个推论：由于AI Agent的出现，写代码的门槛已被拉得非常低，低到“写代码”本身不再是稀缺能力。许多过去需要工程师投入大量时间完成的事情，现在对Agent只是一次生成成本问题。
这意味着，大量过去被忽略、被认为“不值得做”的需求突然变得可行。无论是小功能、一次性工具，还是服务于极少数用户的场景，只要Agent能快速写、快速跑、快速验证，这些需求就不再需要被“筛选”掉。代码生产能力被极大释放，最终被服务的对象是更广泛、更长尾的真实需求。预计基础软件的可靠性和总租户数量会爆炸性增长，但对服务连续性和可靠性的需求并未下降。
极致的低成本与虚拟化
这里的“极致成本”并非简单意义上的“便宜”，而是在满足大量长尾需求的前提下，系统成本能否撑得住。AI让许多原本“不值得做”的需求变得可行，但这些需求通常访问频率极低。
如果你沿用传统模型，例如一个任务对应一个真实的基础软件环境，可以想象用户规模起来后，需要维护上百万个实例，管理进程、心跳、资源、状态本身的复杂性已是不可承受的开销，更不用说机器成本。
因此，在多租户和成本问题上，一个绕不过去的结论是：你不可能真的为每一个需求、每一个Agent提供一个真实的物理实例。你必须引入某种形式的虚拟化：虚拟数据库实例、虚拟分支、虚拟环境。它们在资源层面高度共享，但在语义层面又必须隔离。
真正难设计的地方在于：在实现极致资源复用的同时，还要在交互层面让Agent感觉“这是我自己的独立环境，我可以随便折腾”。
一个例子是Manus 1.5，其背后的Agent使用TiDB Cloud作为数据库方案。这些Agent可以建表、删表、跑实验、写垃圾SQL，而不会影响他人，也无需担心副作用。TiDB Serverless的设计正契合了此场景。如果做不到这一点，Agent就会被迫回到“谨慎使用资源”的模式，其并行探索、快速试错的灵活性优势将被彻底抹掉。这种“看起来像独占，实际上是虚拟化”的设计，并非优化项，而是构建可规模化、超低成本Agent基础软件的前提条件。
单位时间能撬动的算力
另一个常被忽略的点是：单位时间、单位任务，你到底能撬动多少算力？这个指标非常重要，因为它是Agent完成复杂任务必须关注的。
目前，大多数AI交互模式是：你问一句话，它发到某个API背后的GPU上做推理，再返回答案。你再问下一句，再来一轮。这意味着，从系统层面看，你单位时间能调动的算力资源，本质上被锁定在“单次请求对应的一块GPU”上。它工作方式更像是“串行对话”，而非“并行干活”。
现实世界的许多复杂任务需要团队分工合作。例如，快速阅读几百篇NeurIPS论文并挑出有意思的。传统的Agent逻辑大概率一篇篇顺序读。而如果将其视为一个“分布式Agent团队”问题，则完全不同：你可以把任务拆成几百个小块，分发给成百上千个Agent并行处理，再由一个汇总Agent做二次归纳。这是一种“广泛研究”式的工作流。
在这种模式下，你单位时间对一个任务能撬动的算力不再是一块GPU，而是一个可按需扩展的规模。这会反过来提出一个具体的基础软件问题：如果Agent天然倾向于并行探索，那你的系统是否能让它低成本快速地开启上千个“工位”？能否稳定地分发任务、收敛结果、去重、纠错？失败是否可控、可回放？成本是否实时可见？这里面蕴藏着巨大的基础设施机遇。
商业模式的转变：从消耗算力到沉淀服务
在商业模式上，第一个显著变化是：在Agent时代，许多过去不经济的商业模式突然变得合理了。
过去，一提“定制化需求”基本就是红灯：研发人力最贵，为一个小客户、一个没有普适性的场景投入研发不划算。例如，一个小超市老板想做一个库存管理系统或小网店。过去他很难拿出十几二十万雇开发团队，而软件公司也不可能为他一人投入团队。
需求一直都在，但它们被“经济性”挡在了门外。AI Agent改变的恰恰是这一点。它第一次把“计算”真正民主化了。写代码、试想法、做原型这些必须由专业工程师完成的事情，现在可被Agent以极低的边际成本实现。许多以前算不过账的事情，并非需求消失，而是成本终于降到足够低。
因此，一个真正成功的Agent公司，最终不应是一家“卖token的公司”。单纯卖token本身有结构性问题：随着用户增多、任务变复杂，模型调用次数和上下文长度会持续增长，而token的边际成本不会自动下降。只要卖得越多，成本也随之增长，这在商业上非常脆弱。许多靠大量消耗算力驱动的Agent公司，其商业模型本质上是站不稳的。
除非能将“每一次都要重新推理”的事情，转化为“一次构建、反复使用”的服务，否则规模一上来，成本迟早会反噬增长。
真正能跑通的模式，是一家成功的AI Agent公司更像一家把目标用户群体放大了百倍、千倍的云服务公司。关键不在于token成本，而在于能否将原本持续燃烧的token消耗，逐步沉淀成一些“枯燥”的在线服务，或进一步沉淀成静态、确定性、可复用的系统能力。一旦做到这一点，边际成本将被极大摊薄，甚至接近于零。
有趣的是，这并不意味着最终提供的东西是“全新形态”。云服务还是云服务，数据库还是数据库，很多底层能力本身都很传统。真正发生变化的，是使用这些服务的用户群体，被Agent放大了几个数量级。
结语
总而言之，Agent时代已然来临，许多我们作为程序员习以为常的前提，确实需要重新思考。代码不再稀缺，软件也不再是需要精心维护的珍品，系统的创建、试用、丢弃都将变得非常自然。
这并非意味着工程不再重要，恰恰相反。只是工程的重点变了：不再是把某一个系统打磨到极致，而是去设计那些能被AI大规模使用、反复试错、低成本运行的基础能力。
放下对“我是不是在写代码”、“我是不是在控制系统”的执念，反而更容易看清接下来要做什么。许多真正重要的事情，其实又回到了那些经典、稳固的老问题上。
世界已经切换到另一种使用方式，我们不妨坦然拥抱。
发表于 2025-12-24 03:15:33
|
查看: 67|
回复: 0
