树莓派也能跑7.5万智能体：AWS Infinity入门 - 追梦学习库-知识赋能，点缀梦想

AWS Infinity开源智能体运行时，最近成了科技圈热议：2026年10月23日，AWS 与加州大学伯克利分校（UC Berkeley）合作的 Hydro 项目，以 Apache 2.0 协议发布了这款面向「极端并发」的智能体（agent）运行时。官方宣称：空闲智能体大约只占 100 KB 量级内存，按这个密度，8 GB（约等于一块树莓派 5 的内存）能塞下约 7.5 万个并发智能体。

对普通人来说，这不是又一个难啃的云术语，而是在回答一个很实际的问题：智能体大部分时间都在等工具返回，为什么还要一直占着进程和算力？ 下面用大白话讲清它是什么、为什么重要，以及谁该试、怎么入门。

智能体真正贵的，往往是「干等」

写代码的智能体可能一等编译二十分钟；分诊类智能体可能要等几个小时才有新的 Pull Request；助理类智能体甚至会等你第二天早上点「同意」。

多数智能体框架把循环写成阻塞步骤：调模型 → 调工具 → 干等结果 → 再继续。等的时候，进程和内存还挂着，中间来了新事件也不好接。

Infinity 换了思路：借鉴编程语言里挂起、恢复异步函数的做法（类似无栈协程 / stackless coroutine）。智能体一调用工具，运行时就派发这次调用、持久化对话，然后把智能体挂起；工具结果回来后，再从保存的状态恢复。

一句话：等待中的智能体，尽量变成「纯数据」，而不是一直占着活进程。

为什么说「树莓派也能塞 7.5 万」

官网与 AWS 开源博客给出的基准测试大致是这样：

在单线程、内存存储的条件下，启动约 8 万个智能体，每个跑二十轮；
合计约 320 万次补全（completion）；
常驻内存近似线性增长，空闲智能体约 100 KB 量级；
按这个速率，约 7.5 万个智能体可装进 8 GB——也就是树莓派 5 那档内存的量级。

这不等于「一块树莓派就能当生产集群」，而是用一个好懂的尺子说明：挂起后几乎不背「进程税」，规模化并发才变得现实。站点上也写过：二十轮工具调用后，单个空闲智能体大约 103 KB 量级——和博客里的「约 100 KB」是同一量级的说法。

无服务器也能跑：等三天也不烧算力

因为一次执行切片（slice）不会阻塞在外部操作上，状态又从存储加载，Infinity 适合跑在无服务器平台上。它提供 step 模式：平台每投递一批消息就调用一次 step，调用之间不必在内存里留任务。

AWS 参考部署大致组合是：

SQS FIFO 作为输入队列（按线程做 MessageGroupId）；
Lambda 每次投递跑一步后退出；
Aurora DSQL 存对话历史；
DynamoDB 做去重等状态。

效果很直观：智能体在等三天 CI 流水线时，等待期间不必占着计算——结果来了再唤醒。仓库还带了 CDK 构造，方便把这套参考栈拉起来。同一份智能体代码，既可以在本机常驻进程里跑，也可以上云按步执行。

合成工具调用：把「异步事件」塞进模型对话

模型 API 通常假定：一次工具调用对应恰好一个结果。但现实里，订阅仓库、流式命令输出、父子智能体汇报，都会产生一串事件。

Infinity 用 合成工具调用（synthetic tool calls） 解决：运行时注入一个模型并没有真正发出的调用，名字是 receive_event__injected，再跟上带事件内容的工具结果。这样既保持对话结构合法，又让模型用「读工具结果」的习惯去理解外部事件。同一种机制也用于智能体之间通信：父线程可用内置的 spawn_thread 拉起子线程，子线程通过汇报把结果以事件形式送回。

另外，现有 MCP 服务可通过兼容层接入；协议侧还有 Reactive Agent Protocol（RAP），强调工具可经网络回调投递结果，不必一直占着连接。仓库示例里还有基于该运行时的编码智能体 Infinity Code（后台跑构建测试、并行编辑、用 diff 交结果等）。

谁适合现在就试

这是 早期研究版，官方明确是为了收集反馈，作者为 AWS Hydro 研究负责人 Shadaj Laddad（此前在 UC Berkeley 攻读博士并参与 Hydro 设计）。更适合：

想做多智能体 / 长等待工作流的开发者（构建、审批、Webhook、定时唤醒）；
关心成本与密度的平台同学（空闲不占算力、可按消息唤醒）；
已有 MCP 工具、想试兼容层的团队；
对 Rust 智能体运行时、无服务器编排感兴趣的学习者。

若你只是偶尔聊聊天机器人，暂时不必跟风上生产；若你已经在为「一万个智能体干等工具」发愁，这篇新闻才真正和你有关。

怎么上手（轻量路径）

官方入口：

文档站：https://infinity.hydro.run（含 Runtime 概览、Quickstart、无服务器部署说明）
代码仓库：https://github.com/hydro-project/infinity
AWS 开源博客原文：Introducing Infinity

建议按这个顺序摸：

1. 先读 Quickstart，跑通本地 demo

README 里的本地模式大致是：用 AgentSystemBuilder::new_local 配上内存对话存储、状态存储和模型提供方，launch 一个线程，再 send_user_text，然后循环 recv 事件。目标不是抄代码，而是感受「工具返回前切片结束、结果回来再开新切片」。

2. 自己写一个「不阻塞」的工具

博客示例强调：工具的 execute 启动工作后立刻返回；真正结果稍后写入输入队列。这样无论工具要一百毫秒还是三天，智能体侧写法一致，等待期只保留历史。

3. 需要上云再看 step 模式 + CDK

本机跑通后，再对照文档里的 Lambda / SQS FIFO 参考架构。先验证「挂起—恢复—事件注入」是否符合你的业务，再谈大规模并发。

4. 有 MCP 工具可先走兼容层

不必一上来重写全部工具；先让现有 MCP 服务通过兼容层接入，确认事件与订阅行为是否符合预期。

普通人怎么理解这件事

可以把 Infinity 想成给智能体装上了「异步休眠」：

干活时醒来，调模型、派工具；
一等结果就休眠，内存近似只剩对话；
结果或事件到了再醒。

和 Google 等厂商同期推进的「智能体专用算力 / 隔离环境」放在一起看，行业共识越来越清晰：智能体贵的不只是「想」，更是「等」。Infinity 把「等」从进程成本里抠出来，所以才会出现「8 GB 约 7.5 万」这种反差感数字。

小结

AWS Infinity 是 Hydro（AWS + UC Berkeley）在 2026 年 10 月 23 日开源的早期研究型智能体运行时：用挂起对话、按消息恢复的方式支撑高并发，并给出无服务器参考部署与合成事件机制。数字很吸睛，但更值得记住的是产品方向——让等待中的智能体接近零算力占用。想试的话，从官网 Quickstart 和 GitHub 仓库入手即可；生产落地请按早期研究版心态评估，并持续关注官方反馈通道。

参考来源

AWS Open Source Blog：Introducing Infinity: a runtime for extreme agent concurrency（Shadaj Laddad，2026-10-23）
https://aws.amazon.com/blogs/opensource/introducing-infinity-a-runtime-for-extreme-agent-concurrency/
GitHub：hydro-project/infinity
https://github.com/hydro-project/infinity
文档站：https://infinity.hydro.run
行业综述摘录：AI Daily Digest · October 25, 2026（DEV）
https://dev.to/hiroki-ii-ai/ai-daily-digest-october-25-2026-openai-trains-offline-google-ships-a-million-tpus-agent-3dlg