2026年10月23日，AWS 在开源博客介绍了与加州大学伯克利分校合作推出的智能体运行时 Infinity：它不把智能体当成一直占着机器的常驻进程，而是把工具调用当作挂起点。智能体发出工具调用后就先挂起、存好对话历史，等结果回来再恢复执行，思路类似编程里的无栈协程。这一改动瞄准的正是智能体最烧钱的一面：大量时间其实花在等工具、等审批、等外部事件上，而不是在推理。
挂起时到底省了什么
传统做法里，正在等结果的智能体也要占着进程和内存，等的任务一多，机器先被空闲任务拖满。Infinity 把等待期的状态收起来，只留一份轻量记录，恢复时再把对话历史和待办接回去。对开发者来说，调用方式不用大改，变的是运行时对“等待”的处理：等，不再等于占着资源。
官方给出的数字很直观：在 8GB 内存的树莓派 5 上，Infinity 可同时承载 7.5 万个并发智能体，单个空闲智能体大约只占 100KB。但要分清两笔账：这个数字讲的是“能同时挂着多少个”，不是“能同时跑多快”，模型调用本身的成本和延迟还在。
无服务器上也能这样跑
Infinity 可以在本地进程里跑，也能跑在 Lambda 这样的无服务器平台上，配合 SQS 和 Aurora DSQL：智能体等待期间不需要占用算力，结果到达后再被唤醒。这对等构建完成、等人工确认、等外部系统回包的长周期任务很友好，不用再为“等着”长期租机器。
多智能体协作也被放进了运行时。Infinity 提供 spawn_thread 和 report_to_parent 这类内置工具，让父智能体派生子线程、子线程把结果汇报回来；事件默认在子线程里处理，避免把所有中间结果塞进父智能体的上下文。模型接口本身不支持异步事件时，它用合成工具调用来投递异步事件。
谁会先用上，哪里还要留心
最先受益的是智能体数量多、等待时间长的团队，客服、监控、批量处理、长时间跟进的任务，都不用再按峰值并发预留一整片常驻算力。对个人开发者来说，树莓派级别的演示也降低了试错门槛。
但也要留心三处：挂起省的是等待期的计算资源，不是模型调用费；异步流程变多后，某个子线程卡住、事件迟到，排障会更像查分布式任务；智能体本身的判断质量、工具权限和安全边界，仍然要靠上层设计和审核兜底。把它理解成“让智能体等得起的基础设施”，比理解成“智能体变聪明了”更准确。
