TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
AWS 開源 Infinity：把閒置 AI 代理的成本壓到對話紀錄
AWS 與 UC Berkeley 的 Hydro 專案開源代理執行環境 Infinity：工具呼叫即暫停，等待中的代理只剩對話歷史，每個約佔 100KB，8GB 約容納七萬五千個代理。本文拆解官方基準測試的模擬口徑、SQS 加 Lambda 的無伺服器部署，以及官方自列的四個未解問題。
用 AI 摘要這篇文章：
AWS 在 2026 年 10 月 23 日於官方 Open Source Blog 發表開源專案 Infinity，一個用 Rust 寫的代理執行環境（agent runtime），隸屬 AWS 與加州大學柏克萊分校合作的 Hydro 專案，採 Apache 2.0 授權。它瞄準的問題很具體：現在多數代理框架把代理跑成常駐程序，代理在等工具回來的時候，整個程序和記憶體都被押在那裡。Infinity 的做法是保存對話、結束程序，等工具結果回來再喚醒。
官方給出一個很響的數字：8GB 記憶體約可容納 75,000 個等待中的代理，正好是 Raspberry Pi 5 的記憶體容量。這篇文章回到官方部落格、文件與 GitHub 原始碼，把這個數字的測試口徑、它換到的東西，以及官方自己承認還沒解的問題一次攤開。
等待中的代理，只剩一條對話紀錄
Infinity 的核心想法借自程式語言的非同步機制。Rust、JavaScript、Python 都有 async 與 await：函式等待網路請求時會被暫停，執行緒去做別的事，請求完成後再從暫停點恢復。Infinity 把同一套邏輯搬到代理身上：模型呼叫工具的那一刻就是暫停點，執行環境派送工具呼叫、把對話歷史存進儲存區，然後這段執行就結束了。
運作的基本單位叫執行片段（execution slice）。一個片段裡，執行環境載入對話、跑一次模型輸出、需要的話派送工具呼叫，然後收工。片段內永遠不等任何外部操作，這是整個設計的鐵律。能把代理喚醒的每一種東西，使用者文字、工具結果、訂閱事件、子代理回報、計時器，全部以訊息形式進到該對話的輸入佇列（input queue）。
每個對話有自己的佇列，像演員系統（actor system）一樣互不共享狀態。同一個對話的訊息逐一處理，保住順序；不同對話並行跑。於是一個閒置的代理就只是純資料：它沒有執行任務、沒有呼叫堆疊、沒有開著的連線，只剩對話歷史本身。
官方部落格用一個具體例子說明這在開發者眼裡的樣子。代理問「42 號建置通了嗎」，工具的 execute 方法啟動查詢後立刻返回，片段結束。查詢如果一百毫秒完成，下一個片段幾乎馬上開始；如果要三天，代理這三天就只占儲存裡的一條對話歷史，兩種情況的工具與代理程式碼完全一樣。開發者要改變的是寫工具的習慣：工具負責啟動工作然後先走，結果之後經由輸入佇列送回來，而不是原地等到最後才交差。
七萬五千這個數字，是這樣量出來的
官方的基準測試一次啟動 80,000 個代理，每個跑 20 個回合，每個回合完整繞執行環境一圈：模型串流輸出約 1.2KB 並呼叫工具，工具結果經過輸入佇列回來，再跑一次模型輸出收尾。加起來 320 萬次模型完成，跑在 AMD EPYC 9R14 的單一執行緒上，儲存全放記憶體內。每一波代理跑完後量一次程序 RSS，此時所有代理都處於閒置，量到的就是「養一個等待中代理」的真實成本。
結果是線性成長，每個閒置代理約佔 100KB，大部分是對話歷史。換算下來 8GB 約容納 75,000 個代理，圖上畫一條 8GB 的參考線標註 Raspberry Pi 5。注意這是換算，官方並沒有把樹莓派接上跑一輪。
官方文章附的圖表把這筆帳畫得更白：圖上註記是八萬個代理約占 8.4GB，換算每個約 103KB，與正文的約 100KB 一致；8GB 的虛線參考線就落在七萬五千附近。
這個測試有三個口徑條件要誠實講清楚。模型是程式內的模擬模型（scripted model），不是真的 Claude 或 GPT 在推論，所以量到的是執行環境的骨架成本，不含真實模型的串流與重試行為。工具呼叫是合成的，沒有接任何真實外部服務。量的是記憶體，吞吐量與延遲不在這張圖裡。
不過這份測試的原始碼就放在倉庫裡，我讀過這份程式：預設一萬個代理、20 個回合、每波 500 個，輸出代理數與 RSS 的 CSV，跑法與參數都是公開環境變數。想驗證的人可以自己換參數重跑，數字不是黑箱。
等待不收運算費之後，帳單換了位置
暫停式設計直接的收益是能上無伺服器平台。Infinity 提供步驟模式（step mode）：平台每投遞一批訊息，就呼叫一次 step，跑完即結束，兩次呼叫之間什麼都不留。等一個跑三天的 CI 建置就等三天，期間零運算。
官方的參考部署全用 AWS 服務拼起來：SQS FIFO 佇列當輸入佇列，每個對話一個訊息群組；每次投遞喚起一個 Lambda 函式，跑一個片段就退出。對話歷史存在 Aurora DSQL，去重狀態存在 DynamoDB，計時器交給 SQS 延遲與 EventBridge Scheduler。整包基礎設施有現成的 CDK constructs，一次 cdk deploy 建齊。
要在這種平台上運作，執行環境得先滿足幾個條件，官方文件把它們列成設計要求：片段執行時間有界，一個片段就是一次模型完成加上幾次儲存與派送呼叫，不等任何無限期的外部操作；沒有程序親和性，狀態全按對話識別碼存放，任何一次呼叫都能處理任何對話的下一則訊息；面對至少一次投遞，每則訊息帶穩定識別碼，狀態庫記下每個對話處理過哪些，重複投遞會被認出並跳過，片段因此可以重複執行；回合先存檔再派送，模型的串流輸出先緩衝，回合完成才提交，工具呼叫的回合也會在派送前先保存；順序交給佇列的訊息群組把關，不需要分散式鎖。
門檻也在這裡。你要有能開 CloudFormation、Lambda、SQS、DynamoDB、DSQL 的 AWS 帳號權限，而且 Lambda 版目前透過 Bedrock 呼叫一個寫死的 Claude Sonnet 模型（MODEL_ID 在 crates/infinity-agent-lambda 裡），得先在目標區域開啟 Anthropic 模型存取。想換模型後端要走 ModelProvider 介面自己接。
部署完成的代理沒有自己的網頁前端，往輸入佇列丟一段 JSON 訊息就算開始對話，訊息群組識別碼選定對話，回覆出現在輸出佇列，同一個識別碼就是同一串對話。想接聊天介面，倉庫附了 Slack 整合；兩種模式跑的是同一條管線，本地程序裡寫的工具、模型提供者與測試搬到 Lambda 上不用改。
還有一個官方沒給數字、但值得先想清楚的帳：等待零運算不等於零成本。歷史放在 DSQL、去重狀態放在 DynamoDB、每次投遞都是一次 Lambda 呼叫，帳單從運算時間換成了儲存量與訊息處理次數。這是從部署組件的計費結構推出來的判斷，官方文章並沒有提供成本實測。
事件怎麼塞回對話：模型沒有發出的工具呼叫
代理等工具的期間，外界還是會發生事情，比如訂閱的倉庫開了新的拉取請求。模型 API 的對話結構只認三種東西：使用者訊息、助理訊息、成對的工具呼叫與結果，而且一個呼叫只能對一個結果。事件塞不進去。
官方考慮過三條路都否決了：在原呼叫後面再補一個結果，違反一對一規則，模型通常直接拒絕；把事件當使用者訊息，事件就被算到使用者頭上，模型分不清哪些話是人說的；放進系統提示，事件就脫離了發生的時間順序。
Infinity 的答案是合成工具呼叫（synthetic tool calls）：執行環境替模型補一個它沒有真的發出的助理工具呼叫，名稱固定為 receive_event__injected，後面跟著裝載事件內容的工具結果，並帶著原始呼叫的識別碼，讓模型知道這個事件屬於它先前的哪個請求。這個名稱永遠不出現在提供給模型的工具清單裡，模型自己想呼叫它會被執行環境拒絕。
同一套機制也撐起父子代理。內建的 spawn_thread 工具開一個有自己的佇列的子對話，父代理繼續做自己的事，子代理用 report_to_parent 回報，訊息一樣走輸入佇列。事件預設開一個臨時子對話處理，不會塞爆父對話的上下文視窗；追蹤某個進行中操作的事件才會直接併進原對話歷史。
訂閱一口氣送來一百個事件時，每個事件各開一個繼承父對話上下文的臨時子對話並行處理；事件若與父對話無關，子對話可以直接關掉不回報，父對話歷史一個字都不用動。
官方自己列出的四個未解問題
部落格文末明說這是早期研究版本，並列了四個還沒答案的問題。交錯事件推理：模型的訓練資料多半是同步工具呼叫的軌跡，事件數量與順序怎麼影響決策還不清楚。排程策略：目前按訊息到達順序處理，沒有優先序可言。對話樹壓縮：摘要按歷史位置索引，大型長壽的對話樹還沒研究。事件真偽：對外暴露的代理可能收到偽造事件，來源追溯機制還沒有。
上下文太長時的壓縮倒是已經有安排：摘要在歷史裡按位置索引，壓縮前就分出去的子對話，之後仍能重建它繼承到的完整歷史。
專案的體格也該如實看。GitHub 倉庫 hydro-project/infinity 於 2026 年 4 月 13 日建立，約半年後隨發表對外開源；21 個 crate 組成的工作區，除了執行環境還包含 RAP（Reactive Agent Protocol，讓工具伺服器用回呼交付結果，現有 MCP 伺服器經相容層不改造就能接）與 Infinity Code（內建這套執行環境的程式開發代理）。截至 10 月 27 日約 34 星、55 個開啟議題，這是研究原型的規模，還不是被大量驗證的熱門專案。
誰該現在花時間
如果你在做代理平台或基礎設施，這份專案值得認真讀。執行片段模型、訊息佇列保順序、以及把無伺服器平台的歸零行為直接當成暫停機制，是一套完整而且可以拆開抄的參考架構，RAP 規格書也值得追。
RAP 本身不綁 AWS，規格是公開文件；就算不採用 Infinity 執行環境，把工具伺服器從保持連線改成回呼式交付，這件事也值得拿自己的架構對照想一遍。
如果你的目標是盡快把代理上生產，可以先觀望。四個未解問題、固定 Bedrock 模型、整套 AWS 綁定，都是實際的採用成本。想在程式裡直接試手感的人，倉庫的 quickstart 從空目錄開始建 CDK 應用，幾分鐘能跑起一個最小對話代理。
對照這一年的代理框架動態，OpenAI 把 Agents API 走代管路線，Anthropic 建議企業收編多餘的子代理，大家都在找多代理的成本與秩序答案。Infinity 給的是最底層的那一塊：執行環境本身把無伺服器平台自動縮減到零的行為，直接拿來當代理的暫停機制。它會不會成為主流做法還很難說，但這份開源至少把一條完整的路畫了出來。
