AWS 让等待的智能体不占内存，账单还在模型

智能体等工具结果的时候，可以不再占着一个进程：等二十分钟的构建，等三天的审批，中间只剩一段存起来的对话记录。这是 AWS 和加州大学伯克利分校 10 月 23 日开源的研究版运行时 Infinity 想改变的事。

先说结论。顾行的读法是拿一件具体的事来量：一个智能体启动了一次要跑二十分钟的构建，然后等。今天多数框架里，它会占着进程和内存干等；Infinity 让它存档、退出，构建结果到了再从存档里接着干。这确实省掉了等待时的常驻成本。我们的看法是，对多数企业而言，让智能体长期挂着的大头开销不在内存，而在每次醒来都要重新跑的模型调用，以及越积越长的对话历史，这笔账 Infinity 没有改。它真正值得注意的地方，是把「智能体等事件、事件到了再醒」做成了运行时的默认写法。

发生了什么

据 AWS Open Source Blog 的发布文章（企业宣称），Infinity 以 Apache 2.0 许可证开源，属于 AWS 与伯克利合作的 Hydro 项目，官方定位是「早期研究版本」，目的是收集反馈。

它的做法借自编程语言里的异步函数：智能体调用工具的那一刻，对话历史里已经包含了继续往下做所需的一切，所以运行时把历史存下来，就可以把内存里的状态全部丢掉。每一轮执行被切成有边界的一小段：读出历史，跑一次模型补全，存下输出，最多派出一个工具调用，然后这一段结束。工具不再「做完再返回」，而是立刻返回，做完后把结果投递到这个智能体的输入队列，队列里的消息再触发下一段。

AWS 给出的参考部署是：SQS 先进先出队列当输入队列，每次投递触发一次 Lambda 函数，跑完一段就退出；对话历史存在 Aurora DSQL，去重状态存在 DynamoDB，定时唤醒用 SQS 延迟投递和 EventBridge Scheduler。博客的说法是，一个等三天 CI 流水线的智能体，在结果回来之前不占用任何计算。

最常被转述的数字是「树莓派 5 的 8 GB 内存里能放下 75,000 个智能体」。博客写明了这个数是怎么来的：他们在一颗 AMD EPYC 9R14 的单个线程上、用内存存储和模拟模型跑了 80,000 个智能体，共 320 万次补全，测得每个空闲智能体约占 100 KB，按这个速率推算 8 GB 约能放 75,000 个。也就是说，这是在服务器上测、按线性外推到树莓派的数，不是在树莓派上实测的，而且模型是模拟的，不含真实的模型调用延迟和费用。

为什么重要

顾行关心的问题一直是：智能体真正把事做成，要等多久、等什么、在哪里需要人接手。等待恰恰是长时任务里最常见的状态。博客自己列的场景就是三种：编程智能体等构建，分诊智能体等下一个合并请求，助手等第二天早上的审批。

过去这类等待通常有两种处理办法：让进程一直挂着，或者定时轮询。Infinity 换了第三种：订阅一个事件源，事件来了就唤醒。博客还说明了一个细节：模型接口里没有「异步事件」这种消息，于是 Infinity 由运行时代替模型补写一次「接收事件」的工具调用，把事件当作工具结果塞进对话，好让模型沿用它熟悉的处理工具结果的方式。父智能体派出子智能体、子智能体回报结果，也走同一套机制。

据 GitHub 上的 hydro-project/infinity 仓库（官方文件），README 把它概括为「等待中的智能体免费休眠，下一条消息来了再醒」，并附带一个网络工具协议，说明现有的 MCP 服务器可以通过兼容层不改代码接入，另有一个基于这套运行时的编程智能体，在后台跑构建和测试，改动以差异的形式交给人审。

分析推断：这里的「免费」要读准范围。依据是博客自己的描述，每一段执行都要从存储里读出完整历史、再跑一次模型补全，所以智能体每醒一次，模型就要重新读一遍越来越长的上下文。省下的是等待期间的进程与内存，醒来那一刻的模型费用并没有变，历史越长，每次醒来越贵，博客把长期运行下的历史压缩列为尚未研究清楚的问题。

现在有多少人在用

还很少，这一点可以核对。截至 10 月 24 日，GitHub 仓库显示约 22 个星标、4 个分叉，仓库 4 月就已创建；据 crates.io 上 infinity-agent-core 的页面（已证实），核心库最新版本 0.2.0，9 月 3 日首次发布，累计下载约 120 次。这些数字说明它还处在研究者和早期试用者手里，没有任何公开的生产使用案例。

最强反方

最有力的反驳是：对平台方来说，内存和常驻进程恰恰是大钱。一家要给几百万用户各挂一个长期助手的公司，如果每个助手都要占一个进程等事件，成本和运维压力都很真实；而据 AWS 博客的说法，传统运行时放在无服务器平台上时，每次调用都要一直开着等工具返回，在按运行时长计费的平台上，等待时间本身就成了账单的一部分。Infinity 把这部分降到接近零，对平台方的意义可能比我们说的大。

我们在这里让步一半：对托管大量智能体的平台方和云厂商，这确实是一笔可观的节省，分析推断：AWS 以 Lambda 和 SQS 做参考部署，说明它看重的正是这个场景，依据是博客只给出了这一种云上部署方案。但我们的看法是，对一个企业里跑几十、几百个智能体的团队，账单的大头仍是模型调用（依据是上文：每次唤醒都要重读历史、重跑补全，而空闲智能体每个只占约 100 KB）；而且这个研究版还没有任何生产数据，节省多少目前只能看博客里的模拟测试。我们仍坚持：它改变的是「等」的成本，不是「想」的成本。

我们不知道什么

• 真实模型下的表现：基准测试用的是模拟模型，接上真实模型后，唤醒延迟、失败重试和费用会怎样，博客没有给数据。
• 模型能不能处理好交错到来的事件：博客承认，模型大多是在同步工具调用的记录上训练的，多个事件以什么顺序、多少数量插进对话会怎样影响决策，团队还在研究。
• 事件的真假：博客把「事件真实性」列为开放问题，一个暴露在公网的智能体可能收到伪造的事件，运行时怎么证明事件来源、谁为据此采取的动作负责，目前没有答案。分析推断：这正是长时智能体里人需要接手的位置，依据是博客对该开放问题的描述。
• AWS 是否会把它做成正式服务，博客和仓库都没有提到。

接下来看什么

一是有没有团队公开在真实模型上跑长时任务的数据，尤其是每次唤醒的模型费用；二是事件来源校验有没有落进协议；三是其他智能体框架会不会采用「工具立刻返回、结果走队列」的写法。只要第一个数据出来，我们会回到这篇的判断上对账。