AWS在2026年公开了Infinity智能体运行时，提出将等待中的智能体状态保存并挂起以节省常驻执行资源的方案，面向长期会话与高并发场景展开探索。该项目为早期研究版本，强调状态容量优化而非推理吞吐量，并提出无栈协程式的暂停/恢复、无服务器部署与异步事件处理等设计，同时对可靠性与安全性问题保持谨慎态度。
AWS于2026年10月23日公开介绍智能体运行时Infinity，探索一种面向长期任务的执行方式：智能体调用外部工具后，保存对话状态并挂起执行，待结果或新事件到达，再恢复工作。它试图减少的不是大模型推理本身的开销，而是大量智能体等待工具、定时器或人工回应时，占用常驻执行资源的成本。
根据AWS开源博客的公告，Infinity属于AWS与加州大学伯克利分校参与的Hydro合作项目，以Apache 2.0许可证开放。AWS明确将此次公开版本定位为“早期研究版本”，希望收集反馈，而不是宣布一项已经验证成熟度的托管服务。
公告中最醒目的说法，是8GB内存可以容纳约7.5万个并发智能体。但这里的“容纳”主要指保存智能体对话状态，并不意味着一台树莓派能够同时完成7.5万路真实大模型推理。
等待工具时，为什么还要保持智能体运行？
智能体的工作并不总是连续计算。编程助手可能等待一次持续二十分钟的构建，代码审查助手可能等待下一次拉取请求，业务助手则可能等到第二天才收到人工批准。
AWS在公告中指出，许多智能体执行框架采用串行循环：调用模型、调用工具、等待结果，再进入下一轮。如果整个等待期间都保留进程及其运行状态，智能体数量增加后，资源消耗也会累积。
Infinity借鉴无栈协程的思路，把外部工具调用视为可以暂停的边界。无栈协程并不为每项等待中的任务保留完整调用栈，而是保存恢复执行所需的状态；对Infinity中的智能体而言，对话历史承担了类似角色。
按照AWS描述的基本流程，运行时读取历史、请求模型生成、保存输出、分派工具调用，随后结束当前执行片段。工具完成后，将结果送回输入队列，后续执行再从存储中恢复状态。用户消息、工具结果和定时唤醒，都可以成为重新启动工作的消息。
这也改变了工具接口的设计重点：工具不必让智能体一直等到工作完成，而是先启动任务，再通过消息返回结果。不过，挂起的是智能体这一侧的执行；编译、测试或其他外部工作如果仍在进行，承担这些工作的系统依然需要资源。
项目架构文档还说明，某些能够迅速完成的内置工具可以同步执行，并在同一片段内继续请求模型。因此，不能把其架构概括成所有工具都必须异步，或任何片段都严格只有一次模型调用。核心原则是避免为了等待长时间外部操作而维持智能体执行。
7.5万个智能体，是状态容量而非推理吞吐量
AWS披露的基准在AMD EPYC 9R14处理器的单个线程上进行，使用模拟模型和内存存储，共运行8万个智能体，累计产生320万次模型生成。每个智能体执行二十轮工具交互，每轮包含一次发起工具调用的生成，以及工具结果返回后的另一次生成。
测试观察到，常驻内存随智能体数量近似线性增加，每个空闲智能体约占100KB。AWS据此推算，约7.5万个智能体的状态可以放入8GB内存，并用树莓派5的内存规格作参照。项目网站给出的图示口径更具体，约为每个智能体103KB。
这些数据支持的是一种较轻量的状态保存与调度方式，而不是低成本推理能力的证明。模拟模型不能代表真实模型服务的响应延迟、限流和费用；内存存储测试也不能直接说明云端数据库、消息队列和网络调用的生产表现。
同样，“并发智能体”不等于“所有智能体同时活跃”。大量会话可以处于等待状态，真正的活跃吞吐量仍取决于模型、工具、存储及调度能力。本报道未部署Infinity，也未独立复测上述性能。
无服务器部署，把长期会话拆成短期执行
Infinity的另一项探索，是让长期存在的智能体会话运行在短生命周期的函数之上。会话可以持续数天，但负责处理一次消息的函数不必持续运行数天。
AWS参考部署使用SQS FIFO消息队列组织输入，以会话线程作为消息分组；Lambda收到消息后运行一个处理步骤，再退出。对话历史保存在Aurora DSQL中，消息去重状态保存在DynamoDB中。短期延迟和较长定时任务则分别利用SQS延迟机制与EventBridge Scheduler。
这种设计需要处理的不只是暂停与恢复。同一会话的消息必须串行处理，否则两个执行片段可能同时读取旧历史，并覆盖彼此写入的内容；不同会话则可以并行推进。队列也可能重复投递消息，运行时因此要记录稳定的消息标识并识别重投。
AWS还称，模型流式输出会先进入缓冲区，待一轮完整结束后才提交；工具调用则先写入历史，再分派出去。这些机制旨在让会话记录在失败和重试时保持一致，但不能仅凭输入消息去重，就认定外部业务操作天然具有“只执行一次”的保障。
官方部署文档提供了CDK组件和Lambda部署路径，也要求相应的云资源权限及Bedrock模型访问能力。开发者无需让等待中的会话持续占用Lambda执行时间，不代表整套系统没有成本：状态存储、队列、模型调用、工具执行及事件接收处理仍需分别核算。
这一点与智能体沙箱的资源问题有关，但并不相同。此前Modal采用Vera CPU运行智能体沙箱的报道关注工具实际运行时的CPU争用和吞吐量；Infinity更侧重工具运行期间，等待结果的智能体是否还需要保留活跃执行。前者优化工作怎么跑，后者优化等待怎么管，两者不能互相替代。
让异步事件进入模型，也带来新的安全问题
长期智能体还会遇到另一类困难：一次工具订阅可能不断产生事件，而不只是返回一个最终结果。例如，后台命令持续输出日志，代码仓库不断出现新的拉取请求，子智能体也可能陆续汇报进展。
Infinity采用“合成工具调用”呈现这类消息：运行时在对话中加入一条并非模型主动发起的工具调用，再接上包含事件内容的工具结果，并关联原始请求。其目的是在现有模型熟悉的工具调用结构中表达异步事件，而不是把机器事件冒充为用户指令。
父子智能体也使用同一消息机制。父智能体创建子线程后可以继续工作，子线程的汇报随后以事件形式返回。为避免大量原始事件挤占主会话上下文，运行时默认可以创建临时子线程处理订阅事件，仅在需要时向父线程报告；与当前操作紧密关联的事件，也可以直接进入订阅线程。
但结构正确不等于内容可信。AWS将事件真实性列为尚待研究的问题：即使事件关联到某次工具请求，来自互联网的载荷仍可能不真实。来源验证、权限边界和操作追踪，不能由这种消息格式本身替代。
此外，模型主要接受同步工具调用轨迹训练，异步事件的数量、顺序及处理位置会怎样影响决策，仍缺乏充分研究。任务优先级调度，以及长时间运行的父子会话树如何压缩上下文，也都在官方列出的开放问题之中。
Infinity目前提供的是一个可以检查实现、尝试部署的研究方向：公开代码库展示了如何把智能体从常驻执行循环，转为由消息唤醒、从存储恢复的任务。它能否在真实业务中降低总成本并保持可靠性，还需要结合实际模型调用、外部工具副作用、故障恢复和长期会话质量来验证，而不能只看可保存多少个空闲智能体。