产品经理如何重构面向 AI Agent 的软件设计逻辑

从TiDB Cloud的后台数据中，90%的数据库集群创建已由AI Agent自主完成，这一趋势迫使产品经理重新思考软件的心智模型、接口交互与商业逻辑。本文将深入探讨如何为AI时代重构设计范式，供大家参考。

———— / BEGIN / ————

最近我越来越清晰地捕捉到了一个令我脊背发凉的趋势：我们的核心用户，正在从「人类开发者」迅速切换为「AI Agent」。

这不是未来的预测，而是正在发生的现实。在 TiDB Cloud 的后台数据中，我观察到一个极其明确的信号：每天新创建的数据库集群里，超过 90% 是由 AI Agent 直接发起并创建的。

当这一比例突破临界点时，我意识到，我们过去十几年积累的关于「如何设计好软件」、「如何优化用户体验（UI/UX）」的默认假设，正在面临前所未有的挑战。持续观察这些 Agent 如何笨拙或高效地创建资源、读写数据、反复试错，让我不得不从本体论的角度重新思考一个问题：当软件的主要使用者不再是人，而是 AI 时，产品应该具备哪些本质特征？

今天，我想跳出具体的某个功能，聊聊在这个新时代，我们该如何重新设计软件的「心智模型」、「接口交互」以及「商业逻辑」。

发现问题：UI 已死，心智模型永生

第一个需要重塑的认知是：当使用者从人类变成 AI，软件真正暴露给用户的不再是 UI 和 API，而是它背后的「心智模型」。

我们在设计产品时，往往痴迷于创造新的概念、新的交互方式。但 LLM 在训练过程中，通过阅读海量的人类代码（也就是所谓的「屎山」和最佳实践），已经内化了大量隐含的假设。计算机世界里最根本的东西——文件系统、操作系统、进程模型、I/O 抽象——在过去几十年里，虽然形态在演进，但核心思想和接口边界几乎没有本质变化。

AI 看到的不是一个多姿多彩的创新世界，而是一个充满了「重复模式」的世界：重复的抽象、重复的轮子、重复的错误修复。这些重复沉淀为一种极强的先验知识。

因此，我的第一个结论是：如果你希望设计的是「给 AI Agent 使用的软件」，请停止发明新概念，尽可能去贴合那些古老、却被一再验证的心智模型。

比如文件系统、Bash Shell、SQL。它们的共同特点是：底层心智模型极其稳定，上层胶水极其灵活。Agent 不是在等待一个它从未见过的「更聪明」的系统（这也是我为什么不看好许多试图发明全新接口的 Agent 开发框架的原因），它更喜欢一个「它已经懂的系统」，然后用比人类娴熟 1000 倍的效率写胶水代码去扩展它。

以文件系统为例。无论是 Plan 9 还是 Linux 的 VFS，本质上都是允许你在不破坏「文件/目录」这一心智模型的前提下，引入全新的实现。我在实验性项目中的尝试也印证了这一点：如果你设计一个 vectorfs，让向量索引看起来像是一个普通的文件夹，让语义搜索看起来像是 grep 命令，Agent 就能立即上手使用，而不需要学习任何新的 API。

对上层来说，世界并没有改变；对系统本身来说，它却获得了持续演化的能力。 在 AI 时代，系统演进速度是人类的几千倍，如果没有这种封闭且稳定的抽象约束，系统很容易失控。

在此基础上，关于「软件生态」的争论也有了新的答案。Agent 并不在乎语法是否优雅，也不在乎社区文化（比如 MySQL vs Postgres）。只要接口稳定、语义清晰、文档丰富，Agent 就能适配。生态的重要性不在于表层的语法差异，而在于其背后是否对应着 LLM 训练语料中广泛存在的、稳固的心智模型。 只要模型站得住脚，Agent 会自动帮你跨过那些人类程序员纠结的品味之争。

了解问题：自然语言与符号逻辑的「双重奏」

如果说心智模型解决了「AI 如何理解系统」的问题，那么接口设计则关注「AI 如何与系统对话」。

在 Agent 作为用户的时代，一个好的软件接口必须同时满足三个条件：

1. 可以被自然语言描述。

2. 可以被符号逻辑固化。

3. 能够交付确定性的结果。

我们习惯的图形界面（GUI）在 Agent 时代几乎是不可见的。你很难用一句话把「点哪里、拖到哪里」讲清楚。而 「设计正确」的系统，其能力天然就适合被自然语言描述。

很多人担心自然语言的歧义性。但站在 Agent 视角，现在的 LLM 已经非常擅长从上下文中「猜」出意图。这并不是因为语言变精确了，而是模型见过了无数类似的任务模式。对于系统设计者来说，只要底层模型是对的，上层的少量歧义可以通过 Agent 的自我修正来消解。

然而，自然语言适合表达「意图」，却不适合承担「执行」。这就引出了第二个关键点：系统的符号逻辑必须能被固化。

一旦任务需要被复用或自动化，歧义必须被消除。我们需要在「人类可读的输入」和「机器可执行的行为」之间，放置一个中间层——代码。

我认为，代码是目前最好的逻辑符号描述。 这不是为了省钱，而是为了提高「认知密度」。

举个例子，如果你想让 AI 给一万个单词翻译释义。最土的办法是把一万个词都塞进 Prompt 里；而最高效的办法，是让 AI 写一段 Python 脚本来处理这个文件。模型只需要理解一次「代码规则」，Agent 就能用极少的符号，描述一个可以被无限重复执行的过程。

因此，一个 Agent 友好的系统接口设计，核心在于明确回答：「在什么时刻，歧义被彻底消除？」 当这个时刻被定义为「代码生成的瞬间」，系统就获得了将模糊意图冻结为确定性结构的能力。

同类问题：需要具备哪些特征？

当 AI Agent 成为主要用户，基础设施的设计哲学也必须随之改变。现在的用户不再是那些会做长期规划的人类架构师，而是「用完即走」的 Agent。

1. 日抛型代码与极致的低成本

Agent 的工作负载本质上是「日抛型」的。它们会快速创建资源、试错，不行就扔掉。这意味着 Infra 的设计前提不能再假设「实例很宝贵」。你必须假设实例是廉价的、短命的、且数量会爆炸式增长。

这直接推导出对 「多租户和成本控制」 的极致要求。你不可能为 Agent 的每一次尝试都提供一个真实的物理数据库实例。你必须引入「虚拟化」：在资源层面高度共享，在语义层面严格隔离。

这就像 Manus 或 Lovable 背后的数据库方案，Agent 可以在里面建表、删表、写垃圾 SQL，完全感觉不到其他租户的存在。如果你做不到这一点，Agent 就被迫要「省着用」，那么其快速试错、并行探索的优势就会被成本抹杀。

2. 单位时间撬动的算力杠杆

人类干活是串行的，Agent 干活天然倾向于并行。

传统的交互模式是：你问一句，AI 答一句，算力被锁定在单次推理上。但面对复杂任务（比如读完几百篇论文），Agent 的最佳策略是分裂成 100 个子 Agent 并行处理。

这对 Infra 提出了新的挑战：你的系统能不能让 Agent 低成本地瞬间拉起 1000 个工位？ 能不能稳定地分发任务、收敛结果？这里面蕴含着一个 K8s 或 Hadoop 级别的系统机会——一个专门为 Agent 并行工作流设计的调度与执行环境。

解决问题的思路：商业模式的代际转移

最后，我想谈谈商业模式。Agent 的出现，第一次真正实现了「计算能力的民主化」。

写代码、做原型的边际成本趋近于零，这意味着大量过去因为「不划算」而被忽略的长尾需求（比如小超市老板的库存系统、一次性的数据分析脚本）突然变得可行了。代码的生产能力被释放，服务对象从少数头部客户扩展到了海量的长尾场景。

在这个背景下，一个真正成功的 Agent 公司，绝不应该是一家「卖 Token 的公司」。

卖 Token 的商业模型是脆弱的：用户越多，成本越高，且边际成本不会自动下降。真正能跑通的模式，是把 Agent 的「单次关键推理成本」，转化为「一次构建、反复使用」的云服务生意。

你需要把那些持续燃烧的 Token 消耗，沉淀为一些「无聊」但确定的在线服务（Boring Service）。一旦做到这一点，边际成本就会被极大地摊薄。云服务还是云服务，数据库还是数据库，但使用者的数量级被 Agent 放大了 100 倍。

结语

写到这里，我的核心观点其实很简单：世界已经切换了轨道，我们没必要抗拒。

代码不再稀缺，系统被创建、试用、丢弃将成为常态。这并不意味着工程不重要了，恰恰相反，工程的重点从「打磨单个系统」转移到了「设计能被 AI 大规模使用、低成本运行的基础能力」上。

放下对「我是不是在写代码」、「我是不是在控制一切」的执念，回归到那些古老而稳固的心智模型上，去为这个即将到来的机器洪流，修筑最坚实的河床。

本文来自公众号：靠谱瓦叔 作者：靠谱瓦叔

想要第一时间了解行业动态、面试技巧、商业知识等等等？加入产品经理进化营，跟优秀的产品人一起交流成长！