先摆一组数字的反差。同批横评口径里，Claude Code 这类常驻 harness 单个会话占 386.6 MB 内存（PSS 口径），每多开一个会话再加约 212.7 MB【二手，jcode README 横评】；而 2026 年 10 月 23 日 AWS 开源的 agent 运行时 Infinity，一个等待中的 agent 只占约 100 KB【官方】。一边按几百 MB 计，一边按 100 KB 计，中间隔着约三个数量级。一个 agent 为什么能在等待时「降级成一段数据」？这 100 KB 有多少成色？本文把 Infinity（Apache-2.0，Rust）拆开看：挂起机制、serverless 底座、数字口径与社区批评。
先划边界：本文基于官方博客、GitHub 仓库与二手媒体评测的公开资料梳理，非亲自部署实测；关键数字均标注【官方】或【二手】出处；矛盾口径并列呈现、不做裁决；本文不构成技术选型建议。单体的深评之外，「挂起、隔离、常驻」三条路线怎么选，见文末延伸阅读的同批横评。
一、发布与仓库：不在 aws org 下，在 Hydro 项目里
2026 年 10 月 23 日，AWS Open Source Blog 发文《Introducing Infinity: a runtime for extreme agent concurrency》，署名 Shadaj Laddad（AWS Hydro 团队研究负责人）【官方】。这里先纠正一个流传中的误传：仓库不在 aws 组织下——aws/infinity 与 aws/hydro 实测都是 404，代码实际落在 hydro-project 组织下，仓库地址：github.com/hydro-project/infinity。Hydro 是 AWS 与 UC Berkeley 的合作项目，博客原话是「we're releasing Infinity under the Apache 2.0 open source license as part of the Hydro project, a collaborative effort between AWS and UC Berkeley」【官方】。
仓库本身的关键信息（GitHub API 2026-10-26 实测）：许可证为 Apache License 2.0（根目录 LICENSE.txt），主语言 Rust，25 stars、54 open issues（org 页快照显示 27 stars/30 issues，两页快照时间不同所致，口径不一，引用需注意）；创建于 2026-04-13，最后 push 停在 2026-10-23——发布当天仍在推送。仓库描述原文：「An agent runtime and tool protocol for principled agent concurrency」。
热度要说实话：截至 2026-10-26，25 的星数在「AWS 开源」的声量预期里低得反常；HN 上唯一的帖子 2 分 0 评论【二手，Algolia 检索】。官方自己的定位也是「an early research release, and we are sharing it to get early feedback」——这是一个早期研究发布，不是成熟产品。
二、挂起机制：agent 的贵不在思考，在等待
Infinity 的出发点是一笔等待的账。博客原话：「Agents spend much of their time waiting on tools. A coding agent may start a build that runs for twenty minutes, a triage agent may wait hours for the next pull request on a repository, and an assistant may wait until the next morning for an approval. While the agent waits, it holds a process and its memory, and it cannot respond to events that arrive in the meantime.」【官方】等一个 20 分钟的构建、等几小时的下一次 PR、等一晚上的审批——这段时间里，常驻架构的做法是让整个进程连内存一起「全款待机」，期间还接不到任何新事件。
Infinity 的核心判断是：agent 调用工具的那一刻，它的对话历史已经包含续跑所需的全部信息。博客原话：「At the moment an agent calls a tool, its conversation history contains everything needed to continue the agent once the result is available. If the runtime persists this history, it can discard all in-memory state, and any process with access to the store can resume it later.」【官方】落到执行顺序上就是：先派发工具调用，随后持久化对话历史，再丢弃全部内存状态，最后挂起；结果返回时，任何能访问存储的进程都能把它恢复起来继续跑。
技术上这接近 stackless coroutine 的思路。OS 线程或 stackful coroutine 等待时要把整个调用栈留在内存；而 stackless coroutine（Rust async fn 的实现方式）由编译器把函数变成状态机，只保存各 await 点相关的值，等待的内存成本可以压到极小【官方】。对 agent 来说，对话历史就是它的 continuation——「线程」不在了，但「程序计数器和局部变量」以数据形式还在。README 的比喻更直白：「Infinity does for agents what async did for threads: instead of blocking on slow tools, Infinity agents run them concurrently, yield while they wait, and cost nothing until the next event arrives.」
执行上，Infinity 把每个 agent 跑成一串有界的执行切片（slice）：每个切片内，运行时从可插拔存储加载对话历史、跑一次模型补全、持久化输出、最多派发一个工具调用，然后切片结束【官方】。工具调用即 await 点，切片内永不阻塞。一句话概括这套设计：「agent 的贵不在思考，在等待」——而 Infinity 把等待的成本砍到了近乎免费。
三、serverless 底座与合成工具调用
挂起之后，等待期间的计算成本是零；参考部署进一步把这个账落到了 serverless 上。博客原话：「Our reference deployment on AWS uses an SQS FIFO queue as the input queue, with one MessageGroupId per thread. Each delivery invokes an AWS Lambda function that runs one step and exits. Conversation histories are stored in Aurora DSQL and deduplication state in DynamoDB, and the sleep tools use SQS delivery delays and EventBridge Scheduler for their timers. The repository includes CDK constructs that provision these resources.」【官方】拆开看：SQS FIFO 做输入队列（每个 thread 一个 MessageGroupId），Lambda 每次投递跑一个切片就退出，Aurora DSQL 存对话历史，DynamoDB 存去重状态，SQS 延迟投递与 EventBridge Scheduler 实现定时器，仓库附带 CDK constructs 一键开资源。等三天的 CI 流水线期间，没有任何一台机器在为这个 agent 付费。
两个值得单独说的机制：
合成工具调用 receive_event__injected。 模型 API 要求每次工具调用恰好对应一个结果，外部事件（比如 GitHub 的 pull_request/opened）到达时，并没有一个「告知新事件」的干净入口。Infinity 的做法是插入一个模型从未发起的 assistant tool call，名为 receive_event__injected，后跟携带事件内容的 tool result；参数里带 original_tool_name、original_tool_call_id、original_args 锚定事件归属，__injected 后缀标明这是运行时注入——运行时绝不把这个名字作为工具提供给模型，模型若试图调用会被拒绝【官方】。
agent 间通信。 父线程用内置的 spawn_thread 创建子线程，子线程的报告以合成事件的形式返回父线程，避免子线程上下文塞爆父线程；输入队列按 thread_id 串行、跨线程并行，类似 actor 系统的消息语义【官方】。
另外，README 还介绍了 Reactive Agent Protocol（RAP）——不经持久连接，把工具结果与订阅事件按就绪时机送达，甚至可以投递给当前没有任何进程在跑的 agent，规范开放、任何人可自行实现（出处：GitHub README/文档站）。
四、数字成色：两道限定词必须保住
现在回到 100 KB 和 7.5 万。官方基准的完整口径是【官方】：80,000 个 agent、每个 20 轮、共 320 万次 completions；每轮里模型流式输出约 1.2 KB 的补全并调用一个工具，工具结果经输入队列返回，再用第二次补全结束该轮；硬件为单线程 AMD EPYC 9R14；存储用 in-memory stores；模型是模拟模型（simulated model），不是真实模型 API。
两道限定词，转述时哪一道都不能丢：
第一，模拟模型。 官方博客明写基准用的是 simulated model。真实模型 API 的响应更大、更慢、更贵，长上下文下的真实表现这个测试没有覆盖。这是最容易被媒体摘要吃掉的限定词——「8GB 跑 7.5 万个 agent」的标题之下，测的是模拟模型下的内存行为。
第二，推算值。 「Resident memory grew linearly, at about 100 KB per idle agent. At this rate, about 75,000 agents fit in 8 GB, which is the memory of a Raspberry Pi 5.」【官方】7.5 万是按 100 KB/agent 推算出来的（8 GB ÷ 约 103 KB ≈ 7.8 万，官方取整口径），测试并没有跑在树莓派上——树莓派 5 只是内存容量的类比。注意原话措辞是「per idle agent」，且「Most of this memory is taken up by the conversation histories」——大头是随对话长度线性增长的对话历史，上下文越长，单个 agent 越重。
还有一笔官方没解释清楚的账：每轮 1.2 KB × 40 次补全 ≈ 48 KB，与 100 KB 的差值博客没有给出构成说明【存疑】。项目文档另有一个口径——20 轮工具调用后约 103 KB/agent、80,000 个常驻空闲 agent 共 8.4 GB——但这是二手转引，原文页未直接核验【二手】。数字自洽性上，「80,000 × 20 轮 × 每轮两次补全 = 320 万」是能对上的；真实模型 API 与真实数据库下的对应数字，官方未公布。
五、与常驻派的量级对比：三个数量级的账怎么算
把 Infinity 的 100 KB 和常驻 harness 的几百 MB 放在一起，差距约三个数量级【二手口径，两者测量方式不同】。jcode README 的九款 coding harness 内存横评（PSS 口径）：单会话 Claude Code 386.6 MB、OpenCode 371.5 MB、Copilot CLI 333.3 MB、Cursor Agent 214.9 MB、Codex CLI 140.0 MB；每新增一个会话的增量，Claude Code 约 212.7 MB、Codex CLI 约 21.6 MB；10 个会话时 Claude Code 约 2.3 GB——vendor 自测，未独立核验【二手】。另一份带探针数据的实测（apiad/aegis issue #415）给出 Claude Code harness 常驻 235–319 MB RSS，并有「一个协调者带十几个角色 lead，什么都不干也占着 3 到 4 GB 进程内存」的描述【二手】。
对比之前必须说清口径差异：常驻 harness 的几百 MB 里含运行时本体与本地状态，Infinity 挂起后的 100 KB 里只剩对话历史——这不是同一件东西的两种测法，而是两种架构路线的代价结构。常驻 agent 等待时全款占内存；挂起 agent 等待近乎免费。代价是：常驻的会话状态就在本地进程里，挂起的会话状态依赖外部持久化存储的可用性与延迟——省下的内存，以存储 I/O 压力的形式还回来。
顺带一提路线对照：Google Cloud 在 10 月 22 日官宣的 Agent Compute Engine（ACE）走的是另一条路——每个 agent 一个硬件隔离 microVM（Cloud Hypervisor、独立 Hyperdisk 与短期凭据），空闲时 fast checkpoint/restore 暂停【官方，各自口径】。ACE 回答「跑得安全」，Infinity 回答「等得便宜」；媒体观点认为生产栈两者并用：外层 microVM 隔离加内层切片调度【二手】。三条路线怎么选不展开，见延伸阅读的同批横评。
六、短板与批评：先泼五盆冷水
社区目前没有形成大规模讨论（HN 唯一帖 2 分 0 评论），但媒体评测已经把主要批评摆出来了，逐条如实记录：
一，模拟模型基准不够硬。 tsnmedia 的评语一针见血：「It measures memory, with a simulated model, on a server, and real agents spend money and time on model calls that the test left out. ... The figures are AWS's own and have not been independently checked.」【二手】对话历史是内存大头，长上下文下挂起内存会显著大于 100 KB。
二，树莓派是类比非实测。 「the test did not run on one. The Pi is a comparison of memory size.」【二手】任何把「树莓派上跑 7.5 万个 agent」当实测结果的转述都是错的。
三，持久化 I/O 成为新瓶颈。 techbytes 指出：空闲内存降到 100 KB，代价是数万 agent 的切片启停对持久化存储的高频读写，落地前必须验证数据库后端扛得住高 I/O 速率【二手】。
四，生态错位。 主流 agent 生态偏 Python，Infinity 是 Rust；是否会出原生 Python bindings，要看后续版本【二手】。对以 Python 为主的团队，接入成本真实存在。
五，竞态没有消失，只是搬家。 stackademic 的观点：「Race conditions do not disappear; they move to message ordering guarantees per thread_id」；可观测性也需要按切片边界追踪而非按 HTTP 请求追踪【二手】。工程门槛同样不低：需要可插拔会话存储、持久队列、幂等工具实现，工具作者要把同步返回改造成异步派发加回写队列【二手】。
最后是市场检验的缺席本身：25 stars、54 open issues、HN 零实质讨论、官方自述 early research release——所有信号都指向同一个结论：它还没被真实世界的生产负载检验过。这不是缺点，是现状。
七、上手：README 快速开始
README 给的最小示例（逐字引用）：
let system = AgentSystemBuilder::new_local(
InMemoryConversationStore::new(),
InMemoryStateStore::new(),
StaticModel::new(provider, "global.anthropic.claude-sonnet-4-6").await?,
).start();
let mut thread = system.thread_builder().launch().await;
thread.send_user_text("Write a haiku about Rust").await?;README 把项目拆成三大组件：Infinity Runtime（含 Lambda serverless 部署文档与 CDK constructs）、Reactive Agent Protocol（RAP）、以及 Infinity Code——「A coding agent built on the runtime」，后台跑构建与测试、并行线程编辑、以 diff 交付。MCP 兼容层的原话是：「Existing MCP servers run unchanged through a compatibility layer, and anyone can implement the open specification.」注意出处：MCP 兼容层与 Infinity Code 只出现在 GitHub README 与文档站，官方博客正文没有提——引用时请分开标注出处。文档站在 infinity.hydro.run，仓库地址再贴一次：github.com/hydro-project/infinity。
常见问题
Q1：「8GB 跑 7.5 万个 agent」是实测结果吗？ A1：不是实测，是推算。官方基准在单线程 AMD EPYC 9R14 服务器上测得空闲 agent 约 100 KB/个，7.5 万是按 8 GB ÷ 约 103 KB 推算的取整值；且基准用模拟模型、in-memory stores，测试没有跑在树莓派上——8 GB 只是树莓派 5 的内存容量类比【官方】。
**Q2：**挂起后 agent 的状态存在哪？恢复会不会丢上下文？ A2：存在可插拔的会话存储里。挂起时 agent 只剩对话历史，无进程、无栈、无连接；结果返回时，任何能访问该存储的进程都能恢复它继续跑。上下文不丢，但「不丢」的前提是外部存储的可用性——这也是把内存压力换成存储 I/O 压力的代价所在【官方】。
**Q3：**Infinity 和 microVM 隔离方案（如 Google ACE）是二选一吗？ A3：不是。ACE 回答「跑得安全」：每个 agent 一个硬件隔离 microVM，空闲时快照暂停、恢复时仍是 microVM 形态；Infinity 回答「等得便宜」：挂起后 agent 降级为一段数据，无进程无栈无连接。媒体观点认为生产栈可两者并用——外层 microVM 隔离加内层切片调度。路线选型对比见延伸阅读。
**Q4：**现有的 MCP server 能直接接进来吗？ A4：按 README 的说法可以：「Existing MCP servers run unchanged through a compatibility layer。」但注意该表述出自 GitHub README/文档站而非官方博客正文；且在 Infinity 的异步切片模型下，工具作者通常需要把同步返回改造成异步派发加回写队列【二手】。
**Q5：**现在能上生产吗？ A5：官方定位是 early research release，Apache-2.0 开源；25 stars、HN 零实质讨论，尚未经过市场检验。建议的关注姿势：跟踪仓库 push 节奏与 open issues 演化，在非关键路径上做 PoC，重点验证真实模型 API 与真实数据库后端下的延迟与 I/O 压力——这两项数字官方未公布。
参考来源
【官方】
- AWS Open Source Blog：《Introducing Infinity: a runtime for extreme agent concurrency》，Shadaj Laddad，2026-10-23（动机、挂起机制、执行切片、基准数字、serverless 部署、early research release 定位均出自此帖）
- GitHub 仓库 hydro-project/infinity（2026-10-26 API 实测：LICENSE.txt 为 Apache-2.0、Rust、25 stars、54 open issues、created 2026-04-13、pushed 2026-10-23）；README（快速开始、三大组件、MCP 兼容层、stackless 类比原话）；文档站 infinity.hydro.run
- Google Cloud Blog：《Introducing Agent Compute Engine and expanding agent governance》，2026-10-22（ACE 对照段，官方各自口径）
【二手】
- tsnmedia.org（模拟模型基准批判、树莓派类比澄清）；toast.com.cn（中文转述，含 ACE 对照）
- techbytes.app（持久化 I/O 瓶颈、Python 生态错位）；stackademic.com（竞态转移、工程门槛、双栈并用观点）
- txtmix.com 转述 jcode README（九款 coding harness 内存横评，PSS 口径，vendor 自测未独立核验）
- github.com/apiad/aegis issue #415（Claude Code harness 235–319 MB RSS 实测，2026-10-15）
- datastudios.org（项目文档 103 KB/8.4 GB 口径转引，原文页未直接核验）；HN Algolia 检索（唯一相关帖 2 分 0 评论，2026-10-24）
延伸阅读
- 挂起、隔离还是常驻：Agent 并发运行时怎么选——同批横评。本文管 Infinity 单体深评，三条路线的选型对比在那篇。
- 给 Claude Code 配沙箱的运行时 SOP——同批实操手册，常驻派给本机 agent 加安全边的自救指南。
- Agent 隔离方案五强横评——本站 2026-08-19 旧文，Firecracker、CubeSandbox、agent-sandbox、E2B、Daytona 的隔离选型。
本文基于公开资料整理（仓库数据截至 2026-10-26），关键数字均标注【官方】或【二手】出处，为代表性梳理而非亲自部署实测，不构成技术选型建议。