AWS 开源 Infinity 运行时：8GB 内存塞下 75000 个智能体

一句话结论，AWS 与加州大学伯克利分校 Sky Computing Lab 联合开源的智能体运行时 Infinity，用编程语言里挂起异步函数的办法处理工具调用，让等待中的智能体几乎不占内存，官方基准显示一块 8GB 内存的树莓派 5 能同时容纳约 75000 个智能体。

智能体这套东西现在卡在哪，大家都清楚。模型推理的成本被反复讨论，工具调用的等待时间却经常被算进架构设计的盲区里。一个编码智能体点了构建命令，构建要跑二十分钟；一个运维分诊智能体等仓库里下一个拉取请求，可能要等几个小时；一个审批助手干脆等到第二天早上才有人签字。这类等待不产生任何 token，也不产生任何价值，但传统 harness 的写法让它们持续消耗进程和内存。

Infinity 换了个思路。它的核心动作是把工具调用当成一个挂起点，模型调用完工具之后运行时立刻把这一轮状态落盘、进程退出，等结果回来再从落盘状态恢复。这个机制在编程语言里有现成的对应物，就是 Rust 那套 async 机制里的无栈协程，编译器把每个 async 函数编译成状态机，只在 await 点保留必要状态。Infinity 把对话历史当成智能体继续运行所需的全部状态，其余一概不留。

这篇是 10 月 23 日 AWS 开源博客原文的深度拆解，外加仓库里的实现细节。Infinity 目前是一个早期研究版本，作者自己写明目的是收集反馈，还不是正式发布的服务，这一点在评估它的时候得放在前面。

阻塞式 harness 到底浪费了什么

先看问题本身。多数智能体 harness 把智能体循环写成一系列阻塞步骤，harness 调模型、调工具、等工具返回，然后重复。等待期间，进程活着，内存占着，同时这段时间内到达的外部事件它一概处理不了。工具慢的时候，harness 就成了整条链路上最贵的那个等待者。

AWS 与伯克利 Sky Computing Lab 的合作项目叫 Hydro，Infinity 是其中一部分，仓库在 GitHub 上的 hydro-project/infinity，用 Rust 写，Apache 2.0 许可，10 月 25 日仍有提交。仓库描述一句话说清了定位，这是一个面向原则化智能体并发的运行时与工具协议。

解决思路借用的是编程语言挂起与恢复异步函数的技术。操作系统线程和有栈协程在等待期间保留整个调用栈，内存占用大；Rust 用的无栈协程让编译器把函数转成状态机，每个 await 点只保存相关变量，执行器的负担因此轻得多。

智能体恰好可以用同样的方式挂起。智能体调用工具的那一刻，它的对话历史里已经包含了恢复运行所需的全部信息。只要运行时把这段历史持久化，内存里的其它状态就可以全部丢弃，之后任何一个能访问存储的进程都能把它恢复过来。这个前提一旦成立，等待就变成了纯粹的数据问题。

执行切片：一个智能体的一步到底有多短

Infinity 把智能体的执行切成一段段有界的执行切片。一个切片里，运行时从可插拔存储读取该智能体的对话历史，跑一次模型补全，把输出写回，然后最多派发一个工具调用，切片随即结束。

工具调用在这个模型里扮演 await 点的角色，切片不会为工具、定时器或任何外部操作而阻塞。这意味着一个状态查询花一百毫秒，下一个切片几乎立刻开始；花三天，智能体在这三天里只占自己的历史存储。

所有能唤醒智能体的东西都走同一条路径，作为消息进入共享输入队列，用户文本和工具结果都在其中。队列吸收待处理事件，运行时就不必在等待期间维持智能体存活。运行时从队列取出一条消息时，才启动一个切片，重新载入该智能体状态并处理这条消息。

线程模型借鉴的是 actor 系统。每个对话线程有自己的输入队列，线程之间不共享可变状态，通信只靠往彼此队列投递消息，每条消息带一个标识目标线程的 ID。运行时保证同一个线程的消息按序处理，一次一个切片，不同线程的切片则并行跑。同一线程内有序是正确性要求，两个切片同时读写同一段历史会互相覆盖轮次；不同线程之间没有任何需要协调的地方。

进程内模式还会为每个活跃线程配一个通道和一个轻量任务，调度方式跟异步执行器调度 future 一样。线程没有排队消息也没有待处理工具结果时，任务直接退出，等下一条消息到达时再起一个新的。

75000 个智能体的内存账是怎么算出来的

官方基准是这个项目最硬的一块数字。团队写了一个基准，用模拟模型和内存内存储，在单个 AMD EPYC 9R14 线程上分批拉起 80000 个智能体，累计跑出 320 万次补全。每个智能体跑 20 轮，每一轮完整往返一次：模型流式输出约 1.2 KB 并发起一个工具调用，工具结果经输入队列返回，第二次补全结束这一轮。

结果是常驻内存随智能体数量线性增长，每个空闲智能体约占用 100 KB。按这个速率，8GB 内存的树莓派 5 可以容纳约 75000 个智能体。绝大部分内存被对话历史占掉，空闲智能体本身没有任务、没有调用栈、也没有连接。

这个数字要和另一条路线对照着看。谷歌的 Agent Compute Engine 走的是微型虚拟机底座路线，官方说法是 20 万智能体、500 毫秒挂起恢复，那套方案里等待中的智能体同样几乎不占资源，但每个智能体的载体是一台微虚机。两边共同的前提都是让等待不产生成本，区别在于底座形态一个是微虚机、一个是可插拔存储上的纯数据。

合成工具调用：把异步事件塞进模型认识的结构里

工具调用可以被当挂起点，还有一个前提要解决。智能体等待期间发生的外部事件，怎么告诉模型。

难点在于模型 API 的会话结构。一段对话由用户轮次、助手轮次和成对的工具调用与工具结果组成，每个工具调用必须恰好对应一个结果。而一个长跑命令会持续产出输出，一个仓库订阅每次开 PR 都会产生一个事件，单次工具调用对应的是一串结果而不是一个。

官方团队评估了几种塞法。给原工具调用追加第二个结果违反一调一果规则，模型通常直接拒绝。把事件当成用户消息发出去在 API 层可行，但事件被归到用户头上，模型再也分不清哪句是用户说的、哪句是工具报的。把事件放到对话之外，比如塞进系统提示词，会破坏历史顺序，而模型恰恰依赖这个顺序判断事情发生的先后。

Infinity 的解法是合成工具调用。事件到达时，运行时补上一条模型其实没有发起过的助手工具调用，紧跟着一条承载事件内容的结果。

有两个细节决定了这套机制的严谨程度。调用参数里标识出产生该事件的原始工具调用，模型因此知道事件属于自己的哪一个请求。调用使用一个专用名称而不是重复原工具名，模型能区分事件与一次新的工具调用。这个名称带一个后缀表示由运行时创建，运行时从不把它作为工具暴露给模型，模型真去调用它会被直接拒绝。

这样做的收益是保留了模型后训练时习得的能力，也就是解读工具结果并决定下一步动作。用事件的形式送达，模型看到的就是自己熟悉的那种结构。

订阅机制跟事件同构。工具产出事件的方式与产出第一个结果相同，往智能体的输入队列发消息。工具把第一个结果标记为订阅开始，运行时据此知道同一个调用后面可能还有结果。智能体可以在事件之间休眠，事件到达时被唤醒，一个订阅在等待期间同样不占用任何运行中的东西。

spawn_thread 与父子智能体的通信

同一套异步工具调用与事件模型，顺带解决了智能体之间的通信。Infinity 给每个智能体内置了 spawn_thread 工具，创建一个带独立输入队列的子线程。

调用立即返回，父线程继续做自己的事，子线程的汇报稍后以事件形式送达。默认情况下事件在临时子线程里处理，子线程继承父级上下文，可以执行后向父级汇报，也可以判定与当前任务无关直接关闭而不汇报。子线程能发多次汇报，最终汇报也走同样的路径。

这个设计有个直接后果，运行时不需要为智能体单独搭一套消息系统。创建子线程和向父线程汇报都是普通工具调用，结果与事件顺着输入队列流动，顺序保证的规则原样适用。父线程与子线程作为独立线程在同一个智能体系统里并发运行。

事件该由谁来处理，运行时给了两种策略，工具发送事件时可以选。默认是线程式，每个事件开一个临时子线程，子线程继承订阅线程的上下文，自己判断要不要处理，要处理就汇报给父级，不相关就直接关闭，订阅线程的历史保持原样。多个事件密集到达时，每个事件各有自己的子线程，并发处理。

另一种是关联式，运行时把合成调用直接加进订阅线程的历史。这适用于更新智能体正在跟踪的某个操作，比如后台跑起来的测试任务吐出的输出。

跑在 AWS 上的参考部署

官方给的参考部署全部落在 AWS 托管服务上，配置直接写在仓库里。

这套架构要满足几项约束。第一，切片由一次补全加少量存储与派发调用组成，不等待任何不可限时长的操作。第二，全部状态按线程 ID 存储，任何一次调用都能处理任何线程的下一条消息。第三，队列可能重投消息，所以每条输入带稳定 ID，状态存储记录每个线程已处理过的 ID，运行时识别并跳过重投消息，这使处理一个切片具备幂等性。把状态完全外置之后，存储层的读取延迟就直接变成智能体恢复速度，这一点和 OpenAI Habitat 把读取延迟压到 10 毫秒那条路线 指向同一个要害。

第四，流式模型输出先缓冲，整轮完成才提交，流中途失败则丢弃缓冲重试补全。工具调用结束一轮时，运行时先持久化这一轮再派发调用，保证调用记录一定早于它的结果抵达。

第五，FIFO 消息组在队列层把同一线程的切片串行化，Lambda 也不会同时处理同一个消息组的两次调用，运行时因此不需要分布式锁。这条约束和 Vercel 的 durable-harness 解决的是同一类问题，只是那边靠的是断点续跑机制，这边靠的是把等待整体移出进程。

效果很直接。一个等待三天 CI 流水线的智能体，在流水线报结果之前不消耗任何算力。仓库还提供 step 模式，平台每投递一批消息调一次 step，调用之间不保留任何内存状态，与本地常驻模式跑的是同一条流水线，工具、模型供应商和测试代码在两种模式下无需改动。两种模式的差别在调度器，运行时用它处理所有该延后的事，比如定时唤醒或发给另一个线程的消息，step 模式下调度器写入持久队列，消息在后续投递时回来。

仓库 README 里提到 Infinity 的另外两层。Reactive Agent Protocol 是一套把工具放到网络上服务而不必维持连接的协议，结果和订阅事件在准备好时送达，哪怕目标智能体当时根本没有进程，现有的 MCP 服务器通过兼容层可以直接跑。Infinity Code 是基于这个运行时做的编码智能体，后台跑构建与测试、输出流式接入，在带堆叠沙箱的并行线程里编辑文件，每份结果以 diff 形式交给人审阅。

作者自己列出的四个未解问题

官方博客结尾留了四个开放问题，这部分对判断技术成熟度很有用。

合成工具调用保持了会话结构良好，但模型的训练轨迹里工具调用绝大多数是同步的。事件的数量与顺序如何影响智能体决策，线程式与关联式两种处理方式该怎么选，作者说还想继续研究。

运行时目前按消息到达顺序处理线程，智能体系统通常是有优先级的，用户交互线程本可以排在后台事件处理之前，调度器该把这些因素算进来。

压缩摘要按其在历史中的位置建立索引，压缩前派生的子线程仍能重建它继承的历史，但长时间运行的大型会话树该怎么压缩，还没有研究结论。

每个事件都锚定到它的原始请求，但暴露在互联网上的智能体可能收到伪造载荷。运行时如何在保持无状态架构的前提下建立事件来源的可追溯与可问责，是第四个问题。

再加上项目本身的状态：早期研究版本、Apache 2.0 许可、26 个 star、5 个 fork、54 个未关闭 issue，文档站 infinity.hydro.run。把它当成一条值得跟踪的技术路线，而不是可以直接替换现有生产 harness 的组件，是更合适的定位。

FAQ

Infinity 和普通的多智能体框架有什么区别

区别在等待期间发生了什么。多数框架里每个智能体是一个长期存活的进程或协程，等待时照样占着内存；Infinity 把等待中的智能体压缩成一段对话历史，进程可以完全退出。这带来两个直接后果：同一台机器能挂的智能体数量高出一个量级，工具等三天和等三毫秒在算力成本上没有区别。

它能在生产环境用吗

现在还早。作者明确说明这是早期研究版本，目的是收集反馈而非发布可用服务。仓库里有真实可跑的代码、CDK 构造和文档，但对于需要 SLA 的生产链路，更合适的用法是读它的设计并在自己的 harness 里试挂起与恢复这一层，而不是整体切换运行时。

合成工具调用会不会让模型产生幻觉

运行时对这个风险有明确防护。合成调用使用专用名称，运行时从不把它暴露给模型，模型主动调用这个名称会被拒绝；参数里标注了来源请求，模型能知道事件对应自己的哪次调用。设计前提是模型在后训练中学到的解读工具结果的能力继续可用。真正未被验证的是模型对同步训练轨迹之外的事件顺序的反应，这一点官方也列在开放问题里。

小结

Infinity 的贡献不在于某个新的调度算法，而在于换了一个提问方式。智能体等待的时候，究竟应该占着什么。它给出的答案是只占对话历史，其余一概不占。这个答案一旦成立，很多数字都会跟着变，75000 个智能体装进 8GB 树莓派 5 是其中最直观的一个，其余体现在无服务器平台上等待期间的算力账单趋近于零。

技术细节里最值得记住的是三点。工具调用即挂起点，切片有界且不阻塞。全部状态按线程 ID 外置存储，这让任何一次调用都能处理任何线程，也让重投消息可以靠稳定 ID 去重。事件通过合成工具调用送达，复用了模型已经掌握的工具结果解读能力，而不是另造一套通道。

它还有四个作者自己承认的开放问题、54 个未关闭的 issue，也明确写着这是研究版本。但作为一个把等待不产生成本这件事推到底的工程样本，它值得被放进技术评估清单里读一遍。

相关阅读

• 谷歌 Agent Compute Engine，20 万智能体 500 毫秒挂起恢复
• Vercel 开源 durable-harness，5 个编码智能体框架崩溃续跑机制拆解
• 微软开源 Agensh，1024 智能体协同通过率 55.06%
• OpenAI Habitat 深度，500 PB 存储与 10 毫秒读取延迟