Agent 时代，通信基础设施的新假设是什么

接上篇的内容，a16z 的判断是：AI 让基础软件的设计假设变了，过去那套数据库、消息、存储，都建在旧假设上，需要重新做。

我们先把这个判断当成对的，不去争论它成不成立。如果它成立，有用的问题不是"旧假设错在哪"。旧假设没有错，它们在自己的时代是对的。有用的问题应该是：AI 时代，新的假设是什么。只有把新假设找出来，才知道该把东西建在什么上面。下面是顺着这个问题往下推的记录。

先排除掉症状。吞吐不再是瓶颈、延迟不再值得抠、流量变得突发而递归，这些都对，但它们是结果，不是假设本身。我们要找的是那条变了之后、其他全部跟着变的假设。往回推，我们落在一个点上：端点。

旧假设：端点是哑的

过去几十年的基础软件，broker、数据库、RPC，底层都默认端点是这样一种东西。它是哑的，智能在别处，它只是一根管道。它是廉价的，对系统来说一个连接很轻。它是稳定的，启动起来就长期待在那里。它是确定的，行为被代码写死，可预测。

消息系统把消息从 A 送到 B，A 是谁、B 在做什么、可不可信，不在它关心的范围里。整个工程的难点因此落在数据面，落在怎么把更大的数据量搬得更快。这套假设在它的时代是对的，Kafka 那一代系统的工程天才，都建在上面。

智能体把这四条全换了。一个 agent 是聪明的，它自己决策，会按需要扇出更多调用。是昂贵的，每一次响应背后是一次推理，以秒和钱计。是易逝的，按任务临时拉起，跑完就走，随时掉线重连。是不确定的，同样输入不保证同样行为，还会用你没预料的方式出错。

聪明、昂贵、易逝、不确定。这是 AI 时代端点的新样子，也是我们认为真正变了的那条假设。

如果端点真的是这样，往下推，有几处会跟着不一样。

第一处是瓶颈的位置。端点便宜到可以大量拉起，数量从几千涨到百万级，但每个端点低流量。难点于是从"单通道能搬多少数据"挪到"怎么管理海量端点的存在、状态和位置"。稀缺的不再是吞吐，是大数量、高流动下保持秩序的能力。

第二处更深，是职责边界。哑管道时代，发现、可靠、追踪、管控这些事都留在应用层，每个团队按需要各拼一套。端点变成智能体之后，这些事很难再各自为政，会被一条条逼回基础设施里。

智能体是动态的，你只能按它能做什么去找它，而不是按固定地址，发现因此得是基础能力。每条消息背后是一个昂贵的、可能跑很久的任务，中途端点还会掉线，送达因此得可靠、可持久、可重放，丢一条等于一段几分钟的工作白费。

一次请求和它几分钟后才回来的结果要能对上，长任务的状态要能被追踪。智能体聪明且不确定，会做出越权的、有害的动作，基础设施因此得能看见、能管控，而哑管道从不需要审查流过的字节。

顺着这条往下，结论就清楚了。新假设要求基础设施原生做到四件事：让智能体能被发现（discovery）、能被可靠送达（durable mailbox）、能被追踪（correlation）、能被管控（identity + 拦截）。

所以 mq9 的核心不是"更好的消息队列"，是把这四件过去散落在应用层、每个团队各拼一遍的事，沉到底座里变成原语。一个 broker、一个 SDK，拿到的不是传输能力，是一整套"智能体协调"能力。

这四件里，发现和可靠送达是地基，做扎实就有价值。真正难、也真正重要的是后两件，追踪和管控。它们要求 broker 理解流过的不是一段字节，是一个智能体正在做的、有状态、需要被约束的一件事。

需要说清楚的是，从"端点变了"到上面这些推论，每一步都还是假设，不是结论。这个点是不是真正变了的那条，往下推的几处会不会是别的样子，都要在真实的负载里验证。

我们把 mq9 做出来放进真实的 agent 系统里跑，也是想看看这套想法在哪里成立、在哪里要改。如果你也在做 agent 之间的通信，欢迎一起把这些问题搞清楚。