aws 報的 75,000 個 agent 同時使用，看起來很牛逼是不是？但是實際上你不能這樣看。這裏說的是停放 75,000 個，而不是同時運行 75,000 個。這差異就非常大了。但是你要說這東西有沒有價值？那麼我認爲有，而且我還挺看好的。因爲它解決的正好就是 agent 最貴的那個毛病：等。
爲什麼說等是 agent 最貴的毛病？你想一下就明白了。一個 agent 真正幹活的時間其實不多，大部分時間它都在等。查個數據庫要等結果，調一個慢工具要等工具返回，等另一個 agent 幹完，還要等真人去點那個批准。它明明什麼都沒幹，可整段對話還得攤在內存裏放着，而內存這個東西是按秒收錢的。你就放一兩個 agent 在那兒等，無所謂。可你要是同時放一萬個在那兒等，賬單就很難看了。錢就是這麼花掉的，而且花得你都沒什麼感覺。
那 infinity 是怎麼解決這個問題的呢？說白了，它就是把等着的 agent 先存起來。agent 一開始等，它就把這段對話打包存進數據庫，內存裏的位子騰出來，給真正有活幹的 agent 用。等結果回來了，它再把對話原封不動地搬回來，agent 就從剛纔停下的那句話接着往下說，中間就像沒斷過一樣。這麼一存，一個等着的 agent 就只剩下 100kb 左右的一個小包袱。你算一下，100kb 乘上 75,000，那就是七個多 gb。一臺內存 8gb 的樹莓派 5，正好塞得下，aws 的演示就是這麼演示出來的。當然了，你要是讓這 75,000 個同時醒過來幹活，樹莓派肯定當場就趴下了，這個沒什麼好吹的。可是話又說回來，哪個車隊裏的 agent 不是大部分時間停着的呢？真正的負載，本來就是這個樣子。
其實這招一點都不新鮮。操作系統幾十年前就是這麼幹的：進程大部分時間在睡覺，那就先把睡着的挪出去，機器留給醒着的用。後來大家慢慢就不這麼幹了，因爲進程太便宜了，全都醒着放那兒也花不了幾個錢，省事。可是 agent 不一樣，agent 貴。老辦法就又值錢了。連怎麼把 agent 叫醒，都是現成的套路：外面有消息要找它，infinity 就把這條消息扮成一個工具返回的結果，塞給它。它一收到，醒過來接着幹活，根本不知道自己剛纔睡過一覺。
你再往遠了想一層。等待要是真的不要錢了，agent 的用法就完全不一樣了。它就不再是跑完一趟就關掉的那種活了，它可以掛在那兒，掛上幾天、幾週都行，絕大部分時間睡着，偶爾因爲一個工具的結果、一條新消息，或者一個真人點的批准，醒過來幹一會兒，然後接着睡。到了那個時候，真正難的問題就不是怎麼把 agent 跑起來，而是排班：一萬個睡着的 agent，哪一個該先醒？醒過來的那一個，還記不記得自己睡着之前幹到哪一步了？
話說回來，其實這東西本身就不是給普通用戶和開發者使用的，因爲我們通常一般同時用的 agent 也最多就是幾十個就了不起了。真正需要這玩意的是 AI 行業的公司，或者內部已經開始大規模使用 AI agent 的那類企業。他們可能會同時運行成千上萬的 agent，那麼如何節省內存開銷就成爲了很實際的一個問題。所以，如果你是 AI 行業的從業者，或者你本身的工作涉及這塊，我強烈建議你可以花一個下午的時間去試試看。如果你是和我一樣的普通人，那麼有時間可以閱讀下它的代碼，學習下它的思路，也不錯。
最後想問問跑生產環境的人：你們的 agent 數量有多少？你們統計過那些 agent 真正醒着並幹活的時間麼？能佔到一成嗎？
出處：AWS 開源博客《Introducing Infinity》，2026 年 10 月 23 日，https://aws-news.com/article/2026-10-23-introducing-infinity-a-runtime-for-extreme-agent-concurrency