Agent 时代的基础设施：读黄东旭两篇文章之后的思考
最近读了黄东旭的两篇文章——《如何做 AI Agent 喜欢的基础软件》和《正式介绍一下最近的工作：db9.ai》。两篇合在一起，是目前我读到的对 Agent 时代基础设施思考最深、最有实践支撑的判断。
黄东旭的身份很特殊——他既是 TiDB 的创始人，有十年以上构建数据库基础设施的经验，又在真实生产环境里观察了大量 Agent 使用数据库的行为，有直接的第一手数据。他说的不是预测，是已经在发生的事情。
读完之后，我反复在想一个问题：如果这些判断是对的，RobustMQ 应该是什么样子？
这篇文章是我的思考记录。
一个正在发生的切换
黄东旭观察到一个数据：在 TiDB Cloud 上，每天新创建的集群里，超过 90% 是由 AI Agent 直接创建的。这不是未来趋势，是今天的现实。
Infra 软件的主要用户，正在从人类开发者切换到 AI Agent。
这个切换看起来是渐进的，但对基础设施设计的影响是根本性的。人类开发者和 AI Agent 使用软件的方式完全不同——不同的使用频率、不同的资源消耗模式、不同的错误容忍度、不同的学习能力。如果还用设计给人类用的假设去构建基础设施，迟早会撞墙。
问题不是"要不要支持 Agent"，而是"当 Agent 成为主要用户时，基础设施应该从根本上长成什么样"。
心智模型：Agent 喜欢它已经懂的系统
黄东旭的第一个核心判断是：当使用者从人类变成 AI，软件真正暴露给用户的不再是 UI 和 API，而是它背后的心智模型。
LLM 在训练过程中接触了海量代码和工程实践，见过了无数重复的抽象、重复的模式、重复的选择。这些重复沉淀成了极其强的先验——SQL、文件系统、POSIX、Bash、Kafka API。这些东西几十年没有本质变化，已经被深深训练进了模型里。
Agent 不是在等一个更聪明强大的系统，而是更喜欢"它已经懂的系统"，然后用比人类娴熟千倍的效率在这个系统上写胶水代码扩展它。
这个判断有一个很重要的推论：发明新的抽象是危险的。新抽象需要学习成本，对人类来说已经是负担，对 Agent 来说更是如此——Agent 的偏好完全由训练语料决定，一个在语料里几乎没有出现过的新概念，Agent 用起来会非常别扭，错误率会很高。
他不看好 LangChain 这类新框架，原因就在这里：太新了，连程序员都懒得学，更何况 AI。
好的心智模型还必须是可扩展的。 以 Linux VFS 为例，它允许你在不破坏原有心智模型的前提下引入全新的实现。cp、ls、grep 的语义不变，但底层可以是任何东西——对象存储、向量索引、网络文件系统。接口稳定，实现可替换。在 Agent 以千倍于人类的速度演进系统时，这种"稳定约束 + 开放扩展"的设计尤其重要。
接口设计：自然语言探索，符号收敛执行
好的 Agent 友好接口需要同时满足三个条件：可以被自然语言描述、可以被符号逻辑固化、能够交付确定性结果。
自然语言描述意图——这里的核心不是"支不支持自然语言输入"，而是你的接口本身是否适合用自然语言来表达。图形界面很难被自然语言准确描述；命令行、API、SQL 天然就可以。
符号逻辑固化执行——一旦意图被明确，必须被压缩成明确、稳定、可推理的形式。代码、SQL、配置文件，这些中间表示一旦生成，就不再依赖上下文解释，可以被复用、审计、自动化验证。
黄东旭有一个很有意思的观点：最好的逻辑符号描述就是代码。不是因为节省 token，而是认知密度的问题——代码用极少的符号，描述了一个可以被无限重复执行的过程。
自然语言负责探索空间，符号负责收敛空间。 在这两者之间，有一个明确的转换点——歧义在这里被彻底消除。一个设计好的系统，必须清楚地回答：在什么时刻，模糊的意图变成了确定的执行？
Agent 的工作方式：日抛、并行、试错
Agent 的工作方式跟人类开发者根本不同。
人类开发者会认真规划资源，小心翼翼地维护系统，尽量避免破坏性操作。Agent 不是这样的——它会非常快地创建资源、试一把，不行就丢掉，换个方向重来。并行开多个分支同时探索，只要有一个跑通了，其他的直接放弃。这种试错速度是人类的成千上万倍。
黄东旭把这种工作负载叫做"日抛型"——实例的生命周期可能只有几秒到几分钟，创建和销毁的频率极高，数量爆炸性增长。
这意味着传统的基础设施假设必须被推翻：
- 传统假设：一个集群很宝贵，需要精心维护
- Agent 假设：实例是便宜的，生命周期是短的，数量是爆炸性的
如果 Infra 还在用传统假设运行，Agent 就会被迫回到"谨慎使用资源"的模式，并行探索和快速试错的优势会被彻底抹掉。
虚拟化：看起来像独占，实际上是共享
日抛型工作负载带来一个无法回避的问题：不可能为每个 Agent 提供一个真实的物理实例。
黄东旭的判断是：必须引入某种形式的虚拟化。每个 Agent 感觉自己有独立的、可以随意折腾的环境，但在资源层面是高度共享的。"看起来像独占，实际上是共享"——这不是优化项，是想要支撑 Agent 大规模使用的前提条件。
db9 就是这个思路的实践：每个 Agent 感觉自己有独立的 Postgres + 文件系统，底层是虚拟化的共享资源，成本是传统方案的 1/100。Agent 可以建表、删表、跑实验，完全不用担心影响别人。
db9 是什么：存储层的范本
db9 是黄东旭按照自己的理论做出来的产品，是他对"Agent 时代存储基础设施应该长什么样"的回答。
核心设计是把文件系统和 SQL 融合在同一套存储里。这两个是 Agent 最懂的心智模型，但在传统系统里是完全分裂的。db9 让它们打通：cp 进去的文件可以直接用 SQL 查询，SQL 写的数据可以直接当文件读。两个古老的心智模型，统一了底层，保留了各自的接口。
几个关键特征：
- 随开随用：支持匿名数据库，连注册都不需要
- 永不 pause：哪怕长时间没有流量，实例也不会被关掉
- 生命周期灵活：可短可长，Agent 不需要手动管理
- 成本极低：虚拟化支撑百亿级租户，传统方案 1/100 的成本
定位不是更好的数据库，而是 Agent 时代的存储基础设施。
对未来基础设施的判断
从两篇文章提炼出对未来基础设施的三个核心判断：
对 Agent 隐形。 Agent 不需要知道集群、节点、副本、分区。基础设施越好，越感觉不到它的存在。就像 HTTP 一样——你发一个请求到 URL，不需要知道背后是什么，只需要知道"发出去，会有响应"。
分级可选，不强制。 不同场景对基础设施的要求差异极大。好的设计是从最轻开始，按需升级，接口不变。存储从内存到持久化，安全从无鉴权到完整 ACL，用户按场景自由选择，系统跟着走。强制某种模式是对用户的约束，不是设计上的美德。
成本极低，规模极大。 Agent 把长尾需求变得经济可行——以前算不过账的事情，现在都值得做。基础设施必须能支撑这种规模的爆炸，同时把单位成本打到极低。这需要虚拟化、多租户、自动生命周期管理，三者缺一不可。
对 RobustMQ 的启示
读完这两篇文章，我对 RobustMQ 有了更清晰的判断。不是方向上的调整，而是更深刻地理解了为什么当前的方向是对的，以及还缺什么。
方向是对的，时间点是对的
MQTT、Kafka、NATS、AMQP——这四个协议全部是 Agent 已经深度内化的心智模型，大量存在于 LLM 的训练语料里。RobustMQ 没有发明任何新概念，原生 SDK、原生命令、原生语义，理解成本为零。
这完全贴合黄东旭说的"贴合古老但被反复验证的心智模型"。不是刻意为之，而是因为这些协议本身就是正确的抽象，经过了十几二十年的验证。
RobustMQ 在准备 2027 年的答案——当 Agent 成为通信基础设施的主要用户时，消息层应该长什么样。
隐形是终极目标
黄东旭说"基础软件越好，越感觉不到它的存在"。这对 RobustMQ 意味着什么？
Agent 对 RobustMQ 的感知，最终应该只有两件事：一个地址，一条消息。
send(address, message)
subscribe(address, callback, mode)集群有几个节点、存储用的是什么引擎、消息在哪个 partition、副本是否同步——这些全部应该被吸收掉，对 Agent 不可见。
今天的 Kafka 让工程师感知到了太多：partition、offset、consumer group、rebalance。MQTT 让工程师感知到了 QoS、retain、will。这些概念对人类工程师已经够复杂了，对 Agent 来说是不必要的噪音。RobustMQ 的目标是把这些全部吸收掉，只留一个干净的地址和消息。
这不是功能删减，而是把复杂性内化到系统里，不暴露给使用者。Agent 永远只看到最简单的接口，系统在背后处理所有细节。
轻量化是必答题
黄东旭说的日抛型工作负载，对 RobustMQ 提出了一个具体的问题：topic 的创建和销毁代价有多低？
传统 Kafka topic 很重——创建需要分配 partition、写入元数据、分配 leader、同步 replica。这是为"topic 是长期存在的宝贵资源"这个假设设计的。Agent 的假设完全相反：channel 是临时的、用完即弃的、可能只有几条消息的生命周期。
NATS 的设计给了正确答案：subject 不是资源，是地址。不需要创建，不需要管理，不需要销毁。发布即存在，无人订阅即消失。Agent 可以随意挥霍——用 job_id 生成临时 subject，任务完成自动消失，完全不需要关心清理。
RobustMQ 的 NATS 协议支持已经走在这个方向上。更进一步，TTL 和生命周期自动管理需要成为核心能力，不是可选项。消息的生命周期应该能跟业务语义绑定——任务完成，相关消息自动清理，Agent 完全不需要干预。
分级语义是真正的差异化
持久化不是二元的，是一个连续谱。Agent 在不同场景有不同的需求：
- 无持久化：临时任务通信，消息来了立刻处理，错过就错过，延迟最低
- 临时持久化：关键指令传递，Agent 可能短暂离线，消息不能丢，但任务完成后自动清理
- 中期持久化：IoT 数据上报，需要保留一段时间供分析回溯，按时间窗口滚动
- 长期持久化：数据管道、审计日志，需要长期保留，支持任意时间点回放
这四种需求，在 RobustMQ 里对应的是同一套接口，一个参数切换：
subscribe(address, callback, mode="realtime") // 无持久化
subscribe(address, callback, mode="reliable") // 临时持久化
subscribe(address, callback, mode="replay") // 长期持久化底层 Shard 存储的三种形态——Memory、RocksDB、File Segment——天然对应这三个层级。Agent 从最轻的开始用，业务复杂了直接升级语义，不需要迁移，不需要换 broker，接口不变。
这是 RobustMQ 独有的能力。NATS 做不到 Kafka 级别的持久化。Kafka 做不到 NATS 的零 topic 轻量模型。只有 RobustMQ 在同一套存储上把这条线从最轻拉到最重，中间没有断点。
安全也是同样的分级逻辑：
- 无鉴权：开发测试、内部系统、Agent 自声明租户 ID，完全信任环境
- 轻量 token：只验证合法性，不做复杂权限，适合大多数生产场景
- 完整 ACL：细粒度权限控制，企业级合规需求
用户按场景选择，默认最轻，需要安全时往上加一层，接口不变。这跟存储分级的设计哲学完全一致——从最轻开始，按需升级，始终在同一套系统里。
每个 Agent 感觉自己有独立的 broker
db9 做到了"每个 Agent 感觉自己有独立的数据库"。RobustMQ 需要回答的对应问题是：每个 Agent 是否感觉自己有独立的 broker？
多租户是这个问题的答案，但不只是协议层面的隔离。真正的体验是：Agent 告诉系统自己是哪个租户，在自己的租户空间里随意创建 subject、发布消息、订阅数据，完全感知不到其他租户的存在。底层是共享的存储和计算资源，但隔离是完整的。
轻量 token 提供最低限度的身份验证——不是为了复杂的权限控制，而是确保"你确实是你声称的那个租户"。Agent 不需要登录、不需要注册、不需要配置，拿到 token 直接用，成本趋近于零。
这个能力在 Agent 大规模部署时会变得非常关键。一个复杂的 Agent 系统可能同时运行数百个子 Agent，每个子 Agent 需要独立的通信空间，互不干扰。如果没有轻量的租户隔离，这种规模的部署会产生巨大的管理成本。
守住通信层，不越界
RobustMQ 只做一件事：消息可靠地从 A 到 B。
服务发现、Agent 协调、任务编排——这是上层框架的职责，不是消息层的职责。就像 TCP 不负责服务注册，HTTP 不负责负载均衡，基础设施不应该越界去做上层的事情。
$mq9.AI.API.* 的命名空间不是 RobustMQ 在做服务发现，而是提供了一个标准化的 subject 空间作为基础原语。上层框架可以在这个空间上构建自己的服务发现逻辑，RobustMQ 只负责消息的可靠传递。
管道归 RobustMQ，管道里流什么、谁在听，由上层决定。 这条边界清晰，就不会产生功能蔓延，也不会让 RobustMQ 变成一个什么都做、什么都不精的系统。
与 db9 是互补关系
db9 是存储层，RobustMQ 是通信层。两个加在一起，是一个完整的 Agent Infra 栈。
Agent 传递消息、协调任务 → RobustMQ Agent 存储状态、查询上下文 → db9
黄东旭在做 Agent 的神经元存储，RobustMQ 在做 Agent 的神经元通信。两个方向互补，不竞争。Agent 在同一个任务里可能同时需要两者——通过 RobustMQ 接收指令，把处理结果写入 db9，再通过 RobustMQ 通知下游。
这个组合如果做好，会是 Agent 时代基础设施栈里非常重要的两层。
下一代基础设施的核心命题：不是量，是多
这一代基础设施解决的核心问题是：大。大流量、高吞吐、低延迟、大数据量。Kafka 的核心竞争力是每秒百万级消息的吞吐，Redpanda 的核心竞争力是比 Kafka 更低的延迟、更高的吞吐。这条路可以一直卷下去，但卷的是同一个维度——量。在"量"这个维度上，当前的架构已经足够好了。Redpanda 用 C++ 重写 Kafka，性能提升数倍，但本质上还是在同一个范式里做优化。天花板清晰可见，无法形成击败性的优势。
下一代基础设施解决的核心问题是：多。不是一个用户发一亿条消息，而是一亿个用户各自发几条消息。
Agent 是自动的，机器人是自动的，IoT 设备是自动的。它们不需要人工干预，会自己创建连接、自己发消息、自己断开。用户数量的增长不是线性的，是指数的。每个 Agent、每个设备、每个机器人都是一个独立的用户，都需要自己的通信空间。这种"多"不是当前架构能通过优化解决的——它需要从根本上重新设计基础设施的假设。
"量"和"多"在架构上的要求完全不同。量的问题是优化单条消息的吞吐路径，减少延迟，提高并发。多的问题是支撑海量租户的轻量接入，极低的单租户成本，自动的生命周期管理——需要的不是更快的数据路径，而是更轻的租户模型。
Kafka 的架构为"量"设计，partition 是核心抽象，本质上是为高吞吐的数据管道服务的。它没有"租户"的概念，没有"轻量临时 channel"的概念，没有"用完即弃"的概念。在"多"的战场上，Kafka 和 Redpanda 的优势反而成了负担——它们的每一个设计决策都在假设"资源是宝贵的，需要精心管理"，而 Agent 时代需要的恰恰相反。
一个支持十亿租户但每个租户吞吐一般的系统，比一个支持一万租户但每个租户吞吐极高的系统，在 Agent 时代更有价值。
高可靠、多副本，没那么重要了
传统基础设施对高可靠的执念，来自一个根深蒂固的假设：每一条消息都很宝贵，丢了就丢了，无法重来。所以三副本、同步复制、Raft 共识，所有的复杂度都是为了"不丢"。这个假设在人类开发者手动写代码、精心维护系统的时代是成立的。
但 Agent 改变了这个假设。Agent 可以重试，可以重新生成，可以换个方向再来。一条临时任务消息丢了——重发一次就好。一个日抛型的探索分支失败了——直接开新的。消息的"价值密度"降低了，为每一条消息付出三副本的代价变得不划算。大量的 Agent 通信是临时的、探索性的、可以重来的，根本不需要高可靠。只有少数关键路径——任务最终结果、审计日志、跨系统的关键事件——才需要真正的可靠保证。
真正重要的不是高可靠，而是选择权：
- 这条消息值得三副本吗？——不值得，走内存，最轻，丢了重来
- 这条消息需要可靠传递吗？——需要，加一层持久化，保证不丢
- 这条消息需要长期保留吗？——需要，走 File Segment，冷数据归档
不同的消息，不同的语义，不同的代价。不是强制所有消息走同一条高可靠路径，而是让 Agent 按需选择，系统按配置执行。
RobustMQ 的存储分级——Memory、RocksDB、File Segment——本来是为性能和成本权衡设计的。但在这个框架下，它的意义更深：这是在给每一条消息提供可靠性的选择权。这不是功能上的灵活性，而是对下一代基础设施核心命题的正确回答。
结语
NATS 的"subject 是地址而非资源"、统一存储的轻量 Shard、多租户原生支持、TTL 自动生命周期管理——这些设计天然指向"多"的问题。不是在同一个维度上做得更好，而是在一个新的维度上定义竞争。
黄东旭说：Agent 时代的 Infra，不是发明新东西，而是用正确的方式重新组合已有的东西，然后把成本打到极低，把规模打到极大。RobustMQ 在通信层做的组合是：MQTT 的连接模型 + Kafka 的流语义 + NATS 的轻量路由 + 统一存储层。每一个都不是新发明，全部是已被验证的心智模型。组合的目标不是更快，而是更轻、更多、更大规模。
这是下一代通信基础设施真正需要回答的问题。