agfs的作者dongxu是PingCAP的CTO和Co-founder，他们公司的主要产品为TiDB douxu大佬曾经写过一篇文章：《如何做 AI Agent 喜欢的基础软件》，当时读起来受益匪浅。 本文重新回顾一下这篇文章的核心思想，并学习一下agfs的代码实现。

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

  • 观点：越来越清晰的趋势是Infra 软件的主要使用者，正从开发者（人类）迅速转向 AI Agent。

    • 支撑：TiDB Cloud上每天新创建的 TiDB 集群里，超过 90% 是由 AI Agent 直接创建的。
    • 说明：作者持续去观察Agent的轨迹，看看Agent是如何使用DB、如何创建资源、如何读写数据、如何试错的。

  • 核心：从本体论角度思考——当Infra软件的用户不是人，而是AI时，应该具备哪些本质特征。

    • 心智模型：Agent更容易理解什么样子的系统

      心智模型是你大脑中对外部世界运行规律的“非正式缩略版”解释。它不是教科书上的严谨定义，而是你基于过往经验形成的直觉认知。 它决定了我们认为一件东西是如何工作的，以及如何操作它来达成我们的目标。

      • ​观点：使用者的转变使得软件真正暴露的不是UI或Api，而是心智模型​。受LLM训练数据的影响，软件的心智模型要尽可能贴合​古老的、被一再验证的心智模型​。例如：文件系统、Bash Shell、Python、SQL。
        • ​例子​：
          • LangChain等开发框架试图去发明一套“全新的正确接口”，连程序员都懒得学。
          • 文件系统允许在不破坏原有心智模型的前提下引入全新的实现。Linux VFS允许在遵循POSIX约定的情况下实现不同后端的用户态文件系统。
            • e.g. echo, ls, cat, cp -r的语义不变，但是背后做了很多事情。例如将cp背后改成自动切分和生成向量。例如将grep从字符串匹配改成语义搜索。
      • ​观点​：软件生态，包括语法、协议这些东西在Agent时代既重要也不重要。
        • 不重要：如果软件建立在正确的心智模型下面，那么方案之间只是语法差距。不同于开发者之间为语法“吵来吵去”，在Agent看来都没区别。
          • 例子：MySQL和Pg都建立SQL这个被反复验证、极其稳定的抽象上面。
        • 重要：流行的软件往往对应着非常经典、稳固的心智模型。

    • 接口设计：Agent如何与系统进行交互

      • ​观点​：Agent时代好的软件接口要同时满足「​可以被自然语言描述​」「​可以被符号逻辑固化​」「​能够交付确定性的结果​」这三个条件。
        • **可以被自然语言描述：**关键不在于是否是自然语言输入，而是能否容易通过自然语言来表述。
          • 例子：ClaudeCode通过放弃了难被自然语言描述的图形界面。
          • 论证：人类在完成复杂工作的方式也是高度依赖自然语言的。无论是和同事讨论方案，还是在自己脑子里推演，我们的思考过程就是一连串带有歧义、上下文依赖、不断自我修正的自然语言描述。从这个角度看，自然语言并不是一种不精确的 tradeoff，而是人类解决问题时的原生表示。LLM 模型所做的，只是把这种原本发生在人类之间的推理过程规模化和数字化了。
        • ​系统的符号逻辑能被固化​：自然语言适合用来表达意图，但不适合承担执行语义。一旦任务要被复用，组合和自动化验证，就必须被压缩成一种明确、稳定、可推理的形式。目前最好的逻辑符号描述就是代码，​因为认知密度最高​。
          • ​说明​：一个 Agent 友好的系统接口设计要明确地回答一个问题：“在什么时刻，歧义被彻底消除？”当这个时刻被清晰地定义出来，系统就获得了一种新的能力：它可以将一次模糊的意图，冻结为一个​确定的结构，可存储、可审计、可复用​，也可以被另一个 Agent 在未来重新加载并继续执行。
          • ​例子​：SQL，脚本，代码，配置文件的共同点都是一旦生成就不依赖于上下文解释。
          • 例子：疯狂堆砌MCP本质上是错误的。

    • AI Infra's Infra的特征

      • 观点：日抛型代码——大量过去被忽略的长尾需求可以被开发了，这导致对于基础软件的可靠性和总租户数量会爆炸性增长，但是对于服务连续性和可靠性的需求其实并没有下降
        • 说明：Agent产出的工作负载本质上是日抛型的。比起“长期稳定运行”，Agent更关注“开箱即用”，“随时创建”，“随时丢弃”。必须假设实例很便宜，生命周期很短，数量会飞涨。
        • 例子：Agent在TiDB干活的时候会拉多个branch兵法做。
        • 说明：代码的生产能力被极大地释放了，最终被服务的对象，也不再只是那一小撮“值得投入工程成本”的用户，而是更广泛、更长尾的真实需求。
      • 观点：极致的低成本——不可能真的为每一个需求、每一个 Agent，提供一个真实的物理实例。必须引入某种形式的虚拟化：虚拟数据库实例、虚拟分支、虚拟环境。它们在资源层面是高度共享的，但在语义层面，又必须是隔离的。真正难设计的地方，其实就在这里：在实现极致资源复用的同时，还要在交互层面让 Agent 感觉：这是我自己的独立环境，我可以随便折腾。
        • 说明：长尾需求的访问频率非常低。可能一天就一两个请求，甚至几天才会被碰一次，但它们确实存在，而且确实有人（或者说有 Agent）在用。
        • **例子：**如果你还沿用传统的模型，比如一个任务对应一个真实的 Infra 环境，或者像 Postgres 那样，一个 Agent 任务背后就是一个 pg 进程：你可以想象一下你的用户规模起来以后，你要维护上百万个这样的实例，光是管理这些进程、心跳、资源、状态，本身的复杂性就已经是一个不可承受的开销了，更不用说机器成本。
        • 例子：Manus1.5采用TiDB Cloud作为数据库方案。
      • 观点：单位时间能撬动的算力——复杂Agent必须关注的指标。
        • 例子：Wide Research场景下可能会启动Multi-agent并行干活。系统应该让它低成本快速干活。需要回答：能不能稳定地分发任务、收敛结果、去重、纠错？失败是不是可控、可回放？成本是不是实时可见？

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

      • **真正能跑通的模式，或一家成功的 AI Agent 公司反而更像是一家把目标用户群体放大了 100 倍、1000 倍的云服务公司。**关键不在于 token，成本，而在于你能不能把原本持续燃烧的 token 消耗，逐步沉淀成一些 “boring” 的在线服务，或者更进一步，沉淀成静态、确定性、可以被复用的系统能力。一旦做到这一点，边际成本就会被极大地摊薄，甚至接近于零。
      • 云服务还是云服务，数据库还是数据库，很多底层能力本身都很传统。真正发生变化的，是使用这些服务的用户群体，被 Agent 放大了几个数量级。
      • 例子：Manus努力把 Agent 的“单次关键推理成本”，转化成有规模化效应的传统云计算生意。

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

Reference

https://mp.weixin.qq.com/s/BZcRwgGZNinBK9K2L38LYg?mpshare=1&scene=1&srcid=1221D2lNYLdgfISFt8EjX7kv&sharer_shareinfo=7069946a6c298b3ae127d68425332144&sharer_shareinfo_first=b79e03ff29cc1ddef17417575f322652&version=5.0.0.99730&platform=mac#rd