智能体干活的时候，大部分时间不在思考，在等。
一个编程智能体起一次构建，二十分钟；一个分诊智能体等仓库里来下一个合并请求，可能几个小时；一个助理等你第二天早上批一笔报销，一晚上就这么过去了。
现在的智能体运行框架基本是阻塞的：调模型，调工具，等工具返回，再来一轮。等的那段时间，进程还在，内存还占着，而这段时间里发生的事它接不到。
十月二十三日，AWS 在开源博客上发了一个叫 Infinity 的东西，专治这段等待。Apache 2.0 许可，Rust 写的，属于 Hydro 项目——AWS 和加州大学伯克利分校的合作。作者是 Hydro 团队的研究负责人 Shadaj Laddad，代码放在 GitHub 的 hydro-project 组织下。官方说得很明白：早期研究版本，不是托管服务，没有服务水平承诺。
它把工具调用当成了 await
思路借自编程语言挂起异步函数的那套办法。
关键洞察是：智能体调工具的那一刻，它的对话历史里已经包含了「结果回来之后怎么接着干」的全部信息。所以运行时可以把这个调用派发出去，把对话存进存储，然后把智能体整个挂起——内存里的状态全部丢掉。工具结果回来，任何一个能读到这份存储的进程都能把它接上。
执行被切成一个个有界的「片」：从存储载入历史，跑一次模型补全，把输出落盘，最多派发一个工具调用，这一片就结束。
一片从不阻塞。工具结果、用户新消息、定时器到期，全都作为消息进入一个共享的输入队列。队列把待处理的事件吸收掉，运行时就不需要在等待期间养着这个智能体。
同一个对话的消息按顺序处理，一片一片来；不同对话的片并行跑。每个消息带着线程号，标出它属于哪个对话。
七万五千这个数字，得说清口径
这是全文最该较真的地方。
AWS 的说法是：八 GB 内存能放下约七万五千个并发智能体。八 GB 是树莓派 5 的内存。
测试怎么做的：八万个智能体，每个跑二十轮，总共三百二十万次补全，跑在一颗 AMD EPYC 9R14 处理器的单个线程上，用内存存储，模型是模拟的。算下来每个空闲智能体约占一百 KB。
要提醒三点。
第一，测试没跑在树莓派上。 八 GB 只是拿来做内存量的类比，树莓派在这里是个单位，不是台机器。
第二，模型是模拟的。 真实的工具延迟分布、真实的厂商限流、真实的模型抖动，都没进这个测试。挂起机制省的是等待期的资源，省不了推理本身。
第三，这些数字是 AWS 自己的，没有第三方复现。 研究预览阶段，这种谨慎是应该的。
所以正确的读法是：这个数量级证明「挂起之后，空闲的智能体几乎不占资源」，而不是「你的生产环境能扛七万五千个并发」。前者是架构结论，后者是营销结论。
落到无服务器，账单的形状变了
因为一片不等任何东西，运行时可以跑在标准无服务器平台上：一个函数起来干一片活，干完就退。
AWS 给的参考部署很具体：SQS 的先进先出队列当输入队列，Lambda 跑每一片，Aurora DSQL 存对话历史，DynamoDB 记录哪些消息已经处理过。定时器用 SQS 的投递延迟加 EventBridge 调度器实现。仓库里带 CDK 模板，能直接拉起来。
作者举的例子值得抄下来：一个智能体在等三天的持续集成流水线，在流水线报出结果之前，一点算力都不花。
这句话对做产品的人意味着什么，不用多解释。过去的计费模型是按「一直开着」付，新的模型是按「想了几次」付。这两种模型对同一件事的报价，能差两个数量级。
给模型塞事件：一个不优雅但管用的办法
模型接口有条硬规矩：每一次工具调用，必须有且只有一个结果。这就带来一个麻烦——流水线跑完了、有人开了合并请求，这类事件怎么告诉智能体？
Infinity 的办法是造一个「合成」工具调用：模型从来没发过这个调用，运行时替它插进去，名字叫 receive_event__injected，紧跟一个装着事件内容的结果。对模型来说，这就是一次正常的工具返回，不需要改任何模型接口。
父子智能体走的是同一套机制。父线程用内置的 spawn_thread 开一个子线程，自己继续干别的；子线程的报告以后面这种合成事件的形式回来，挂在当初那个调用上。好处是父线程的上下文窗口不会被子的全过程撑爆。
另外它定义了一个反应式智能体协议，让工具以网络方式提供而不必一直挂着连接；仓库里说现有的 MCP 服务器通过一个兼容层可以不改就跑——站内八月写过 MCP 协议刚把会话和握手删掉，这类兼容层的价值会越来越大。还有一个基于这个运行时写的编程智能体，叫 Infinity Code，可以当参考实现读。
代价：它把「等」的问题换成了「状态」的问题
这不是免费午餐，作者自己列了几条，值得逐条看。
要可持久化的存储，要耐用的队列。 原来在内存里的事，现在全得落盘。这一步的成本不在钱，在你得先有一套靠得住的存储和消息系统。
消息是至少投递一次，所以要自己做去重。 同一条消息处理两遍，智能体可能就重复调了一次工具。
同一个线程必须串行。 一片一片来，否则顺序就乱了。并发度靠线程数拿，不靠并行处理同一对话拿。
切片必须有界。 模型万一不调工具、开始长篇输出，一片就结束不了。所以要有轮次上限、时间上限。
竞态没有消失，只是搬了家。 从「多个线程抢内存」变成「消息顺序有没有保证」。后一种更难查，因为它不在本地复现。
可观测性也得跟着改。按 HTTP 请求埋点在这里基本没用，得按片的边界埋：哪一片载入了什么、跑了什么、派发了什么、结果什么时候回来的。
它还留了四个开放问题：主要拿一步一步工具调用训练出来的模型，遇到乱序进来的事件会怎么反应；运行时怎么确认一个进来的事件是真的；多个智能体的调度优先级怎么定；跨智能体树的上下文怎么压缩。
同一天，另一家选了另一条路
Infinity 发布的前一天，谷歌云发布了智能体计算引擎：每个智能体一个微虚拟机，闲置的暂停，卖点是凭证隔离。
两条路的分工其实很清楚：一个管「等待不该收费」，一个管「执行必须隔离」。 真实的栈大概率两个都要——闲的时候便宜，跑的时候安全。
站内此前写过 AWS 的另一条线：九月 AgentCore 运行时把冷启动从三十秒压到两秒，那是把「启动」做便宜；这次是把「等待」做便宜，方向完全不同。也写过 Vercel 的 durable-harness：那个解决崩溃之后怎么接着跑，这个是主动挂起、把状态交给队列——一个是被动恢复，一个是主动让位，边界要分清。
什么情况下你不该换
判断标准就一条：你的智能体有没有大量时间花在等外部。
几秒钟就结束的问答式智能体，不需要这个。给它套上挂起恢复，只会多一层存储和消息队列要维护，收益为零。
真正合适的是这几类：等构建、等测试、等人工审批的编码流水线；一个客服会话可能停三天才等来回信的场景；给每个客户开一个常驻智能体、但九成时间在待命的 SaaS；还有按事件触发的分诊、监控、运维智能体。
还有一个信号：当你开始按「每个客户一个常驻容器」报价、并且算下来大部分时间在空转，就该看这类方案了。
老达点评
一、这不是性能优化，是计费模型的重构。 过去智能体的成本结构里，「等」是一笔死账，谁都默认要付。Infinity 把「等」从算力账单里挪走，挪到了存储和消息队列账单里——后者便宜得多。这类改动比跑分提升更值钱，因为它改的是商业模型。
二、七万五千这个数字的传播力，大于它的技术含量。 八 GB、树莓派、七万五千个，三个词凑在一起太适合转发了。但真实世界里，模型推理的延迟和费用一分没省，你只是不再为「等」付费。做技术选型时把这句话记住，能省很多钱。
三、合成工具调用是全文最脏也最聪明的一段。 模型接口要求一调用一结果，它没有去改接口，而是伪造一次模型没发过的调用，把事件塞进去。这是工程上的现实主义：标准不给口子，就在标准的缝里过。代价是模型可能被这种它没发过的调用搞糊涂，这也是作者自己列出的开放问题。
四、研究预览，别急着上生产。 没有服务水平承诺，测试用模拟模型，数字没被第三方复现。但架构值得现在就开始想：如果你的智能体里有一半时间在等，那么把它切成片、把状态外置，这件事本身今天就能做——哪怕你用的是自己的数据库和自己的队列。
想把智能体这条线从头理一遍，可以看 AI 智能体与自动化专题；如果你更关心工具层面的横向选择，AI 工具评测专题里的对比更直接。
