如何做 AI Agent 喜欢的基础软件

---TITLE---
AI Agent时代的基础软件设计原则：心智模型、接口与成本考量
---TAGS---
AI Agent,基础软件,数据库,云原生,心智模型
---CONTENT---
随着AI Agent日益成为基础设施软件的主要使用者，一个明确的趋势正在发生：Infra软件的核心用户正从人类开发者转向AI。以数据库为例，在生产环境中，超过90%的新集群创建请求直接来自AI Agent，这已不是未来展望，而是当下现实。

观察Agent如何使用数据库、创建资源、读写数据并试错，我们发现其使用方式与人类开发者截然不同，这迫使我们重新思考“软件应如何被使用”的底层假设。当核心用户变为AI时，基础软件应具备哪些本质特征？

心智模型：拥抱稳定与可扩展的古老抽象

当使用者变为AI，软件真正暴露给用户的并非UI或API，而是其背后的心智模型。大型语言模型在训练中内化了海量隐含的假设与事实约定。越靠近底层的基础设施——如文件系统、操作系统、编程语言——其核心思想与接口边界在过去几十年间变化甚微。

AI在训练中接触了海量代码与工程实践，它所“看到”的是大量重复的模式：重复的抽象、重复的轮子、重复的选择。这些重复沉淀为一种强大的先验知识。因此，设计给Agent使用的软件，关键在于主动贴合这些已被反复验证、根植于模型认知中的古老心智模型，如文件系统、Bash Shell、Python、SQL等。它们的共同特征是底层模型极其稳定，而上层“胶水”非常灵活。

设计给Agent的软件，不是去发明一套“全新的正确接口”，而是要顺应这些已被内化的认知结构。 Agent更擅长使用一个“它已经懂的系统”，并以远超人类的效率编写胶水代码来扩展它。

可扩展性是优秀心智模型的核心

以文件系统为例，无论是Plan 9的9PFS还是Linux的VFS，其核心设计都允许在不破坏原有心智模型的前提下引入全新实现。例如，一个试验性的文件系统agfs，允许实现各种新奇能力，只要满足文件系统接口约束。

以vectorfs为例：文件依然是文件，目录依然是目录，echo、cat、ls等操作一切照旧。但在此心智模型之下，vectorfs的实现可以自动完成文档切分、向量化并写入类似TiDB的向量索引；grep操作则变为语义相似度搜索。

$ cp ./docs/* /vectorfs/docs  # 自动创建索引/上传对象存储/切分Chunk
$ grep -r “What‘s TiDB?” ./docs   # 在TiDB的向量索引上搜索…

云原生/IaaS 领域的虚拟文件系统设计哲学与此一脉相承。只要遵循POSIX等稳定约定，新系统就能被无缝集成，上层世界无需改变，而系统本身获得了持续演化的能力。这在AI时代尤为重要：Agent的代码生产效率是人类的数千倍，系统演进速度极快。没有稳定约束容易失控，但若抽象过于封闭，又无法利用这种高效演化。

由此引申出一个问题：软件生态的“语法”和“协议”在Agent时代还重要吗？结论是辩证的。

• 不重要的一面：如果软件建立在正确的心智模型下，它与主流方案之间往往只是语法差异。Agent没有人类开发者的“偏好”，不关心语法优雅或社区文化。只要接口稳定、语义清晰、生态完备、文档丰富，它就能快速适配。
• 重要的一面：流行软件往往对应着非常经典、稳固且大量存在于LLM训练语料中的心智模型。例如，MySQL和Postgres本质上都是关系型数据库，共享SQL这一稳定抽象。因此，重要的不是生态表层的差异，而是软件背后的模型是否正确、稳固。只要模型站得住脚，Agent会自动跨过那些“方言”式的品味之争。

接口设计：自然语言、符号逻辑与确定性

如果说心智模型关乎“Agent理解什么”，那么接口设计则关乎“Agent如何与系统对话”。在Agent作为用户的时代，一个好的软件接口需同时满足：可被自然语言描述、可被符号逻辑固化、能够交付确定性结果。

1. 可被自然语言描述

核心并非“是否支持自然语言输入”，而是软件接口本身是否适合用自然语言来表达意图。图形界面（GUI）往往难以用语言精确描述交互过程，对依赖语言上下文的Agent而言几乎不可见。相反，编码绝大多数是在与符号和语言打交道。

今天的LLM已非常擅长从带有歧义的自然语言中“猜出意图”。这并非因为语言变得精确，而是模型见过海量的意图表达与任务模式。在绝大多数工程场景下，其成功率已足够高。当底层系统的心智模型正确、接口语义稳定、结果可验证时，上层的少量歧义不会成为系统性问题。Agent可以通过上下文、反馈和试错来消解它。

2. 可被符号逻辑固化

自然语言适合表达意图，但不适合承担执行语义。任务一旦需要被复用、组合或自动化验证，就必须被压缩成一种明确、稳定、可推理的形式。几乎所有成功系统都会在“人类可读的输入”与“机器可执行的行为”之间设置一个中间层，如SQL、脚本、代码或配置文件。它们的共同点是一旦生成，便不再依赖上下文解释。

在Agent场景下，这个中间表示的意义被放大。Agent可以容忍输入阶段的模糊，通过多轮交互逼近意图。因此，系统设计必须清晰地定义：“在什么时刻，歧义被彻底消除？” 当意图被冻结为确定的结构，它就变得可存储、可审计、可复用。自然语言负责探索可能性，符号逻辑负责收敛并固化。

那么，什么是好的逻辑符号描述？一个评价标准是：能否用尽可能少的Token，实现最多的可能性。目前，代码仍是认知密度最高的形式。

例如，需要为10000个英文单词添加中文释义。低效的方式是将整个词表发送给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使用的Infra的特征

当AI Agent成为主要使用者，许多传统设计前提不再成立。Agent会快速创建资源、试错、丢弃并重试，其速度和规模远超人类。

日抛型工作负载与极致的低成本

Agent产出的工作负载本质上是“日抛型”的。开箱即用、随时创建、无负担丢弃，这些特性比“长期稳定运行”更重要。Infra的设计前提必须改变：实例本身应是便宜的、生命周期短的、数量增长极快的。

这导致两个关键推论：

1. 代码生产能力爆炸：过去因成本过高而被忽略的长尾、小众、一次性需求，现在对Agent而言变得可行。这预示着基础软件服务的总租户数量将爆炸性增长。
2. 虚拟化成为必选项：为海量低频访问的需求提供独立的物理实例在成本和管理上均不可行。必须在实现极致资源复用的同时，让Agent在交互层面感觉拥有独立的、可随意折腾的环境。这要求底层架构是高度多租户和资源池化的，例如通过虚拟数据库实例、分支或环境来实现。数据库/中间件 领域的Serverless数据库正是为了应对此类场景而设计。

单位时间可撬动的算力

当前多数AI交互仍是“串行对话”模式，单位时间能调动的算力受限于单次请求。然而，复杂任务往往需要“分布式Agent团队”并行工作。例如，同时分发数百篇论文给多个Agent并行阅读与总结。

这就要求底层系统能支持Agent低成本、快速地创建大量并行“工位”，并能稳定地分发任务、收敛结果、管理失败与成本。这背后可能孕育着新一代任务调度与分布式系统的基础设施机会。

商业模式的转变

Agent时代最深刻的转变之一，是让许多过去不经济的商业模式变得合理。AI Agent极大地民主化了“计算”和“开发”能力，将满足长尾需求的边际成本降至极低。

一个真正成功的AI Agent公司，其商业模式不应止步于“售卖Token”。随着任务复杂化，单纯消耗Token的成本会线性增长，商业模式脆弱。可持续的路径在于，将一次性的、持续燃烧的Token消耗，逐步沉淀为可反复调用、边际成本趋近于零的“枯燥”的在线服务或系统能力。

成功的模式可能更像一家将目标用户群体放大数百倍的云服务公司。核心不在于Token本身，而在于能否将Agent的能力转化为具有规模化效应的传统云计算服务。云服务、数据库等底层能力形态或许传统，但其服务的用户范围和规模将被Agent重新定义。

结语

Agent时代的到来，要求我们重新审视许多作为开发者习以为常的前提。代码不再稀缺，软件的创建、试用与丢弃将变得非常自然。工程的重点随之转变：从将单一系统打磨到极致，转向设计能被AI大规模使用、支持快速试错、实现低成本运行的基础能力与心智模型。迎接变化，回归本质，或许是这个新时代的开始。