你同时安排十位同事查资料。有人在等邮件，有人在等审批。如果每个人等待时都占着会议室，人数一多，现场很快失控。多 Agent 系统也有类似问题：Agent——能调用模型和工具完成任务的软件角色——经常要等待外部工具，却仍可能占用执行资源。Infinity 想做的，就是给这群 Agent 安排一套运行规矩。
它是 hydro-project 用 Rust 构建的运行时框架。Rust 是一种强调内存安全和性能的系统编程语言；运行时框架则负责启动 Agent、保存状态、分派事件和接收工具结果，并不替代负责推理的语言模型。以下能力和性能数字均来自项目仓库，尚无论文、第三方测试或可复现实验交叉验证。
等待时，先把位置让出来
Infinity 把异步运行引入 Agent：一个 Agent 调用慢速工具后，不必停在那里干等。它会让出执行权，让系统继续推进其他任务；工具结果或新事件到来后，再恢复工作。所谓并发，也不是所有任务真的同时完成，而是许多任务在同一时段交替向前。
关键在于，Agent 在两个轮次之间会被保存为“纯数据”。项目方称，此时只保留对话历史，不保留正在运行的任务、调用栈或开放连接。可以把它理解为：人先离开会议室，只把会议记录存档；下一封消息到了，再拿着记录回来。
项目方据此声称，一台 Raspberry Pi 的内存可以容纳 7.5 万个 Agent。不过仓库没有说明设备型号、内存容量、单个 Agent 的状态大小和测量口径。因此，这个数字更适合看作设计目标的展示，不能当作已经独立验证的性能结论。
不只管 Agent，也管工具怎么回来
Infinity 还提出 Reactive Agent Protocol（RAP）。它允许 Agent 调用网络工具后关闭连接，结果准备好时再异步送达；订阅的事件也可以用同样方式抵达，哪怕当时没有承载该 Agent 的常驻进程。
项目方称，现有 MCP servers——按 MCP 协议向 Agent 提供工具的服务——可以通过兼容层直接运行在 RAP 上，RAP 本身也是任何人都能实现的开放规范。这一步值得注意：多 Agent 系统不只会在“怎么调度”上失控，也会卡在“工具结果如何可靠送回”上。Infinity 试图把两件事放进同一套执行规则里。
同一套 Agent 代码还被设计为既能运行在笔记本上的常驻进程中，也能部署到 AWS Lambda 这类 serverless 平台。Serverless 指开发者不必长期管理固定服务器、由平台按请求启动计算资源的方式。Infinity Runtime 提供了相应的 CDK constructs——用代码描述云端部署资源的组件。
从分布式程序，走到 Agent 群
据 AWS Open Source Blog 与 Hydro Project，Infinity 来自 UC Berkeley 分布式系统研究项目 Hydro 的一次转向。Shadaj Laddad 在读博期间设计了 Hydro 及其语义；2025 年毕业后，他与数名项目成员加入 AWS。到 2026 年，AWS 与 Berkeley 仍共同维护 Hydro。Infinity 延续了其中“让并发行为更容易推理”的思路，只是管理对象从分布式程序变成了 Agent。
仓库还展示了 Infinity Code：一个建立在该运行时之上的编码 Agent。按项目介绍，它能在后台运行构建和测试，持续传回输出；也能借助带堆叠沙箱的并行线程编辑代码，并把每项结果整理成 diff——也就是代码修改前后的差异——交给用户审阅。这让 Infinity 不只是底层框架，也有了一个具体应用样例。
为什么值得关注
Agent 数量增加后，难题未必只是模型够不够聪明。谁在等待、谁能继续、状态存在哪里、工具结果送给谁，这些执行层问题同样决定系统能否稳定扩展。Infinity 的价值正在这里：它没有再造一个推理模型，而是在尝试规定大群 Agent 的作息、通信和恢复方式。
局限与未知
- 所有信息来自同一 GitHub 仓库，缺少第三方基准与复现实验；“7.5 万 Agent”等数字仍待验证。
- “本地与 AWS Lambda 无需修改”“MCP servers 不经修改运行”等表述，可能受运行环境和兼容层覆盖范围限制。
- 材料未说明版本、许可证状态、RAP 的成熟度，也无法确认 Infinity Code 所列能力是否都已稳定发布。等待期间仍可能产生内存、持久化、消息传递、冷启动和云服务费用，不宜把项目方的“免费休眠”按字面理解。