在 QCon AI Boston 2026 的一場演講裡，Mad Labs 創辦人暨執行長 Manju Rajashekhar 從一個幾乎每個團隊都遇過的場景談起：Agent 的展示版本在受控環境中表現亮眼，推理流程順暢、工具呼叫正常、答案即時返回，於是被推進正式環境。然而一旦真實使用者湧入，工具呼叫開始變慢，模型供應商回報額度用盡並施加速率限制，使用者在 Agent 還沒跑完時就不斷追問，背景工作進程還可能在中途被重啟。原本看似單純的請求與回應，突然變成一場難以收拾的執行期難題。
Rajashekhar 的資歷讓這個觀察有相當份量。他早年任職 Twitter 工程團隊，負責分散式快取，把系統從五千萬使用者規模推進到兩億；之後創辦 Blackbird AI，公司被 Etsy 收購後，他在 Etsy 擔任工程副總裁八年，主管搜尋、廣告、推薦、個人化引擎、機器學習基礎設施與實驗平台。目前他帶領 Mad Labs，投入能長時間可靠執行、token 效率高且具治理結構的 Agent 平台。在他看來，多數 Agent 架構失效的原因並非某個元件寫錯，而是打從一開始就把問題歸類錯了。
從演示到生產，問題的形狀變了
演示環境與生產環境的差異，核心在於「問題的形狀」被改變。首先是時間。在展示環境裡，工具幾乎立刻回傳結果，整體感覺就像微服務的請求與回應週期；但在生產環境，工具呼叫可能耗時數分鐘，模型供應商會施加速率限制，有時還得停下等待使用者回饋，而使用者可能隔天才回應。用函式呼叫來抽象「現在開始、結果在不確定條件下稍後出現」的工作，顯然不夠。
其次是互動。使用者不會因為 Agent 正在執行就消失。他們會追問、要求查看狀態、索取部分結果，甚至根據新資訊改變執行方向。Agent 迴圈不再是一次性的請求與回應，而是一個持續接收資訊的長壽進程。
第三是委派。過去的系統多半執行一連串事先定義好的步驟，Agent 卻是在過程中不斷學到新資訊、即時生成步驟。執行結構因此不再是直線，而會長成樹狀，更精確地說是圖狀。
第四是失敗。工具呼叫失敗、模型呼叫失敗、工作進程被重啟、外部 API 被限流、佇列重複投遞訊息，族繁不及備載。展示環境把例外當成事後補救，生產環境則把例外視為正常運作的一部分。
當這四件事同時發生，原本的展示架構就開始橫向增生。對話狀態存在一處，工作流程狀態存在另一處；佇列知道有工作待辦，卻不知道使用者真正想要什麼；資料庫記錄了進度，卻不一定記錄工作的續行意圖；重試狀態散落各處；崩潰恢復邏輯最後變成第二套完整實作。每個元件單獨看都合理，問題是整個系統缺乏單一的執行模型：Agent 在某個部分被當成聊天，在另一個部分被當成工作流程或背景任務，在第三個部分又被當成一套恢復程序。這才是生產環境真正的痛點：Agent 所承載的工作單元，被拆散到多個互不相干的執行概念裡。
Agent 其實是分散式系統
一旦換個角度，把生產環境的 Agent 視為執行期問題，一個熟悉的系統就會浮現：Agent 其實是偽裝成應用程式的分散式系統。它是有狀態的、並行的、長時間執行的，會與其他元件通訊，可以部分失敗、獨立重啟，而且必須在工作進行中接受新資訊。
參與者模型（actor model，也常譯作演員模型，以下稱 actor 模型）正好提供了一套描述這類系統的方式。這個概念並不新，一九七〇年代便在人工智慧與並行研究中被提出，真正讓它在大規模系統中落地的是 Erlang 與 OTP。Erlang 曾以超過兩百萬行 Erlang 程式碼的系統，維持二十年、九個九（99.9999999%）的可用性，證明高度並行、容錯與永遠在線可以同時成立。
要理解 actor 模型，可以先跳脫「函式呼叫函式」的單一控制流思維。真實系統同時有多條控制流，許多事情並行發生，各部件在不共享內部細節的前提下溝通，而且可以獨立失效。此時真正的難題不再是「我該呼叫哪個函式」，而是「誰擁有狀態」、「其他部件如何與它溝通」、「某個部件壞掉時會怎樣」。actor 模型把基本單位從函式、類別或執行緒，換成一個獨立的計算單元。這個單元擁有私有狀態，只能透過訊息與外界互動；因為要接收訊息，它必須可被定址，因而擁有信箱。收到訊息後，它完全依據本地狀態決定下一步：更新狀態、發送訊息給其他 actor、建立子 actor、失敗、停止或重啟。
這帶出四個基礎原則。第一，狀態有擁有者。共享記憶體系統靠鎖、互斥鎖、交易與防禦性複製維持一致性，actor 模型則反過來問「哪個 actor 擁有這份狀態」，只有擁有者能改變它，其他人只能送訊息。第二，一切都是訊息。程式碼呼叫程式碼的前提是呼叫者與被呼叫者共享執行脈絡與堆疊；改成訊息之後，發送者送完即可離開，接收者準備好再處理，結果也以另一則訊息回來。單一 actor 內部循序執行，狀態本地化，推理也本地化；跨 actor 之間則完全並行。actor 模型沒有讓並行消失，而是替它畫出邊界。第三，actor 像一個可存活的實體，能被建立、接收多則訊息、記住狀態、建立子 actor、崩潰、重啟，最後停止。第四，失敗有邊界。與其在各處散落 try-catch 與重試迴圈，actor 模型追問的是「失敗的邊界在哪裡」，並以監督（supervision）處理：監督者對工作者失敗套用策略，可以重啟、停止、升級給人類，或帶著部分結果升級給系統。重點不在哪一種策略才對，而在架構清楚知道失敗發生在哪裡、由哪個邊界吸收。
從 actor 到 agent task actor
把這個模型套到 Agent 上，可以先看一個電子商務的例子。購物車結帳涉及品項、付款狀態與運送資訊，誰擁有這筆訂單的真相？在 actor 式設計裡，答案是一個訂單 actor。付款元件不會直接改動訂單，而是送出「付款成功」訊息；物流元件同樣只送出「運送完成」或「運送失敗」。取消與逾時也是訊息。快樂路徑與不快樂路徑共用同一個介面，這正是 actor 模型開始發揮作用的地方。
把訂單 actor 換成「Agent 任務 actor」，映射就清楚了。狀態必須包含目標，因為目標賦予任務連續性，單次模型呼叫可以來去，任務仍要朝目標前進。狀態也包含脈絡，也就是讓任務隨著新資訊推進的所有累積狀態，而不只是提示詞裡的一段文字。狀態還要包含進行中的工具呼叫：工具可能跑上數分鐘，任務必須記住哪些呼叫尚未返回、目的為何、期待什麼結果、適用什麼逾時。最後是子任務：父任務不必擁有子任務的每個細節，但必須擁有彼此的關係，包括為何建立、期待什麼結果、失敗時怎麼辦、結果如何整合。
通訊面則更單純。使用者請求、工具結果、執行中的追加指示、取消與逾時，全部變成送入信箱的訊息。在非 actor 系統裡，這些可能分別走對話通道、工作流程通道與取消通道；在 actor 系統裡，它們都是同一個執行中任務的訊息，信箱成為唯一接收點，側通道被移除。順著這個對應，actor 的身分變成執行中工作的持久句柄，讓工作隨時可被定址；子 actor 對應委派子任務、工具呼叫或專責 Agent；監督則對應失敗邊界。
五個生產模式
第一個模式是把任務當成通用的執行原語。無論是對話、工作流程、工具呼叫、委派子問題，或等待人類輸入，全都建模為任務 actor。重點不是這些任務做的事情相同，而是它們共享同一套執行契約：身分、信箱、狀態、生命週期與監督。
第二個模式是寫穿狀態（write-through state）。actor 的狀態是本地且只能經由訊息修改，因此每次有意義的狀態轉換都能在發生當下持久化。行程崩潰後，系統從持久狀態重建 actor 並繼續執行，恢復與正常續行變成同一條路徑，任務不必靠散落各處的副作用去猜自己原本在做什麼。
第三個模式是間接續延（indirect continuation）。工具可能跑數分鐘，人類可能隔天回覆，子任務可能再開出多個任務。錯誤做法是在堆疊上等待，因為呼叫堆疊只是暫時的執行結構，不是儲存工作流程狀態的地方。正確做法是任務委派工作、記錄續延，等訊息到達才恢復。續延不是被阻塞的執行緒，而是任務擁有的另一份狀態，記錄的是「意圖」而非堆疊框架。這個轉變細微卻關鍵：系統保存的不再是堆疊，而是目的。
第四個模式是可變執行圖。工作不再綁在堆疊上之後，就能表示為任務圖。傳統工作流程的步驟多半事先已知，可以建模成靜態有向無環圖；Agent 則是在執行中發現步驟，找到缺口就開新子任務、呼叫新工具、要求澄清，結果回來後再改計畫。執行圖不是只被執行，而是被 Agent 一邊執行一邊發現，執行期因此必須同時表示當前步驟與演化中的工作結構。
第五個模式是監督邊界。監督不同於例外處理。例外處理問的是「哪裡出錯、我該怎麼補救」；監督問的是「這部分系統失敗了，這個邊界該套用什麼策略」。重啟、重試、升級給父任務、保留部分結果、詢問使用者，全都是架構層級的決策。畫出監督邊界之後，失敗就從全域問題變成帶有本地策略的事件。
這些模式合起來，形成一套前後一致的生產 Agent 執行期架構：任務 actor 提供工作單元，寫穿狀態讓它持久且可恢復，間接續延讓它等待而不佔用堆疊，可變執行圖讓工作單元生出更多工作單元，監督則替整棵工作樹提供失敗邊界。
代價與回報
必須說明的是，actor 模型不會讓 Agent 變得好建。生產 AI 本質上是在非確定性的模型之上建立正確執行，這本來就難；外部系統不可靠、模型效能可能退化、同一個輸入可能得到不同輸出，這些問題不會因為換了架構就消失。actor 模型做的是把困難的部分明確化，替它們命名、畫出邊界。
它的回報在於四件事。系統狀態不再四處散落，每個工作單元有單一位置可供查詢與決策；執行中的 Agent 有可定址的身分，使用者能回來追問、取消、送出子任務結果；失敗成為本地策略而非全域災難；崩潰恢復與正常續行共用同一條路徑。Rajashekhar 也給出一份設計檢查清單：系統裡有哪些 actor？每個 actor 擁有什麼狀態？它們交換什麼訊息？什麼可以獨立失敗？誰監督誰？
一個極簡的編碼 Agent 範例
為了讓抽象概念落地，他以一個刻意極簡的編碼 Agent 作示範，程式以 Rust 撰寫，可連接本地 Qwen 或 OpenAI、Anthropic 及相容模型。這個範例包含四個 actor：監督者負責生命週期與失敗策略，不負責寫程式；LLM actor 控制對模型的傳輸；工具註冊表 actor 負責派發工具呼叫；Agent actor 則是緊湊的代理迴圈，擁有目標、對話紀錄、計畫、子任務與續延狀態。這個設計想傳達的是，不是每個 actor 都必須具備代理能力，不同 actor 有不同角色。
演講最後，他借用 Greenspun 第十定律的口吻下了註腳：任何足夠複雜的 Agent 迴圈，最終都會包含一套臨時拼湊、規格不清、滿是錯誤的半個 actor 系統。換句話說，只要 Agent 會長時間持有狀態、接收新資訊、委派工作、呼叫工具、從失敗中恢復並持續執行，它在本質上就是 actor 形的；差別只在於，這是無意間長成的，還是有意識設計的。
會後的問答也補充了幾個實務觀察。對於 actor 模型為何在 Agent 領域不普及，他推測與主流 Agent 開發語言有關：Python 與 TypeScript 是當前最熱門的選擇，而 actor 模型需要夠健全的執行期支撐；許多框架其實在重新發現 actor 模型的零件，只是以半成品的形式存在。至於 Agent 之間傳遞大量脈絡，他認為脈絡仍以訊息形式傳送，重點是狀態擁有權依然清楚，必要時可傳遞資料副本的指標以節省網路頻寬，但不能讓兩個 actor 同時控制同一份狀態。被問到現有框架能否直接套用時，他表示不熟悉有哪個框架能直接插入這套做法，這也是他公開範例程式碼的原因，因為從頭建立其實不難；真正該做的是先想清楚執行期的心理模型，再讓工具去實作。至於 Erlang 是否是解方，他認為 BEAM 虛擬機很好，但 Agent 生態與 Erlang、Elixir 世界至今尚未真正交會，而他的範例選擇 Rust，正是因為 Rust 能妥善實作 actor 模型。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。