從「一段跑在記憶體裡的 Agent Loop」升格成「一個要對外提供 API、可並發、會當機重啟、有 SLA 的正式後端服務」。

前一篇《LLM 應用編排與 Agent 模式》把 Agent Loop 講成一個概念上的迴圈：Thought → Action → Observation 反覆到收斂。那是理解要不要用 Agent 的心智模型。但當這段迴圈要真的上線——被許多使用者同時呼叫、跑到一半機器重啟、要計費、要保證回應時間——它就不再是「一段 while 迴圈」，而是一個必須認真設計的後端服務。本篇談的正是這件事：把單一 Agent 當成正式後端服務來設計。

核心的視角轉換只有一句話，但它改變了後面所有的工程決策：

順著這個視角，一個正式的 Agent Runtime 要處理的工程關切可以收斂成四塊，剛好對應本篇後續章節：

而「模型怎麼選、工具能不能碰、協定長什麼樣」這些，刻意不歸本篇管——它們是鄰篇的守備範圍。先把邊界畫清楚，才不會把 runtime 寫成一顆什麼都塞的巨石：

本篇定位一句話：服務骨架與可靠性。凡是「模型側」「工具側安全」「協定格式」，一律 externalize 給鄰篇。

把 Agent 編排篇那段概念上的 while 迴圈顯式化成一台狀態機——這是整個 runtime 的骨幹；本章 Demo 接著量化它：這台狀態機在你設的護欄下，跑得完的機率有多少。

Agent 編排篇的 Agent Loop 若直接寫成程式，長得像這樣：

while not done:
    reply = call_llm(context)          # 推理
    if reply.has_tool_calls:
        results = run_tools(reply)      # 執行
        context += results              # 觀察回寫
    else:
        done = True                     # 收斂

這在 demo 裡沒問題，但作為後端服務它有個致命缺陷：狀態全藏在區域變數與呼叫堆疊裡。機器一重啟，這個 while 迴圈連同它的 context 就蒸發了；你也無法從外部知道「這個請求現在跑到哪」、無法中途取消它、無法在另一台機器上接手。解法是把這個隱式迴圈顯式化成一台狀態機，讓「現在在哪個狀態」成為一份可以被讀取、儲存、恢復的資料。

stateDiagram-v2
    [*] --> pending
    pending --> running: 排程取件
    running --> tool_calls: 輸出 tool call
    tool_calls --> running: 結果回寫
    running --> final: 不含 tool call
    running --> timed_out: 撞 wall-clock
    running --> cancelled: 取消旗標
    tool_calls --> failed: 重試耗盡
    final --> [*]

看 running ⇄ tool_calls 這條雙向邊——它跑幾圈事前不可知，正是後面所有護欄（迭代上限、逾時預算）存在的理由；右側三個旁支都是終態，但善後方式各不相同。

• pending：請求已受理、job 已建立（含 idempotency key），還沒開始跑。
• running：正把當前 context 送進 LLM（經 LLM Gateway）推理下一步。
• tool_calls：LLM 決定呼叫工具，runtime 正在執行它們並準備回寫結果。running 與 tool_calls 之間可以來回多次——這就是 Agent Loop。
• final：模型輸出不含 tool call 的最終答案，終態，job 可回收。
• 旁支終態：timed_out（撞逾時預算）、cancelled（使用者取消）、failed（不可回復錯誤）——都是「終止」，但語意與善後各不相同（本篇談可靠性的那一節詳談）。

有了顯式狀態，接著要決定怎麼把結果交給呼叫端。這取決於請求會跑多久：

短任務同步就好，別過度設計；一旦請求可能長到分鐘級，就該切成非同步 job——這也是第 7 節選型階梯的第一道分岔。

狀態機畫得出來，不代表它跑得完。running ⇄ tool_calls 要來回幾次事前不可知，於是「這一次請求到底會不會抵達 final、要花多少、最慢多慢」變成一個機率問題——而它的答案，完全由你設的護欄與成本參數決定。下面的 Demo 把這些參數做成旋鈕，把整棵結果樹確定性地列舉一遍算給你看：

「狀態」這個詞在 Agent 裡被過度重載——先把三個常被混為一談的層次拆開，儲存選型才有依據。

第 2 節的狀態機在「一次請求內」推進；但一個對話式 Agent 的狀態其實有三個時間尺度，各有不同的生命週期與儲存位置。分不清它們，就會犯「把長期記憶塞進單輪 context」或「每輪都重載整段歷史」這類昂貴的錯：

由內而外三圈：working state 活在一次請求裡、session 活在一條對話串裡、memory 活在使用者身上。搞混層次，成本與正確性都會出事。

Agent 編排篇談 Agent Loop 時留了一個伏筆：context 隨迴圈膨脹——每輪都把歷史全文重送，token 成本與延遲逐步疊加。在 runtime 這一層，這不是一句提醒，而是一組必須實作的context window 管理策略：

實務常組合使用：sliding window 保近況、summarization 壓中段、externalize 收長期記憶。目標都是同一個——別讓 context 無上限膨脹。

Agent 編排篇說「模型只決定、runtime 才執行」；本章談的就是「執行」這一側，作為服務該有的編排與韌性。

當狀態機走到 tool_calls，runtime 拿到的是模型輸出的一批 tool call 意圖。把它們穩妥地執行、把結果正確回寫，是這一步的全部工作。看似簡單，但一旦當成服務，就有三個必須處理的細節。

其一：一輪可能不只一個 tool call，要決定串行還是並行。現代模型常在單輪輸出多個 tool call。若彼此無依賴（例如同時查訂單與查庫存），並行執行能大幅砍掉延遲——這正是 Agent 編排篇工程挑戰表裡「工具串行導致延遲累加」的解法。但若後者依賴前者的結果（先查到物流單號才能查物流），就只能串行，甚至得回到 running 讓模型看到第一個結果後再決定下一步。

其二：結果回寫的順序與結構要對得上。每個 tool 結果必須用它的 tool_call_id 對應回原來的呼叫，模型才知道哪個結果對應哪個請求：

# 一輪並行兩個工具後，回寫 context 的訊息結構（概念示意）
{ "role": "assistant", "tool_calls": [
    { "id": "call_1", "name": "get_order",  "arguments": {"order_id": "A1234"} },
    { "id": "call_2", "name": "get_stock",  "arguments": {"sku": "X-9"} }
] }
{ "role": "tool", "tool_call_id": "call_1", "content": "status=已出貨, tracking=SF123" }
{ "role": "tool", "tool_call_id": "call_2", "content": "in_stock=true, qty=42" }

關鍵是 tool_call_id 的配對：並行執行、順序回寫，模型靠 id 而非位置來對應結果。

其三：每個 tool call 是一個有自己 timeout 與 retry 的子作業，且工具會失敗。外部 API 會逾時、會回 500、會限流。此時的關鍵決策是：要讓整個請求失敗，還是把錯誤當成一則 observation 回餵給模型？

「把錯誤回餵給模型」是 Agent 相對傳統 pipeline 的韌性來源——它能讀懂錯誤並改道（呼應 Agent 編排篇工程挑戰表裡「工具錯誤回饋給模型重試」）。但別無限重試，否則就撞上第 5 節的逾時與迭代護欄。

這是把 Agent 從「能跑」推到「敢上線」的分水嶺——在重試、當機、使用者反悔的現實下，仍然正確。

前面的狀態機在「一切順利」時很漂亮。但正式服務要面對的是：client 會重試、機器會當機重啟、使用者會中途反悔。這三件事單獨看都不難，難在它們都會撞上 Agent 的一個本質特性——每個 tool call 都可能是不可逆的副作用（扣款、送信、建單）。三個機制正是為此而生。

① Idempotency（冪等）——為什麼 Agent runtime 特別需要它？因為有三條路徑都會導致「同一件事被做兩次」：

• client 重試整個請求：網路抖動、沒收到回應，前端就再送一次——若沒有去重，訂單就下了兩張。
• runtime 當機後重放狀態機：從 checkpoint 恢復時，可能重跑「當機前其實已經執行過」的那一步 tool call。
• 工具層自動重試：第 4 節的退避重試，若工具非冪等，重試就等於重複副作用。

對應也是三層防線，由外而內：

呼應 Agent 編排篇「執行點就是風險點」：副作用工具是風險的最深處，冪等要一路守到那裡。三層只要漏掉最內層，前兩層擋不住的那條路徑就會真的扣兩次款。

② 超時（Timeout）——不是一個逾時，是一組分層預算。Agent 的耗時來自多個嵌套的來源，每一層都要有自己的上限，否則一個慢工具就能拖垮整個請求：

wall-clock 與 max-iterations 是兩把不同的尺：前者防「單步很慢」，後者防「步數失控（鬼打牆）」——兩者要並存。

把 runtime 的上下游契約畫清楚——這一章專門負責「什麼不該由 runtime 做」，也就是本系列的分工地圖。

一個好的 Agent Runtime，定義它的不只是「它做什麼」，更是「它把什麼交出去」。runtime 的職責應該收斂在三件事：決策編排（跑狀態機）、狀態管理（第 3 節）、可靠性（第 5 節）。其餘一律透過清楚的邊界委外。把這張圖記在心裡，就不會把 runtime 寫成一顆什麼都塞的巨石：

runtime 站在中央調度，但每個方向都有一條明確的接縫。Tool Gateway 篇、MCP 篇與 LLM Gateway 篇，正好各自展開其中一條接縫。

最值錢的判斷不是「會不會搭 Agent Runtime」，而是「知道什麼時候不需要把它做這麼重」。

Agent 編排篇的準則是「能用 Workflow 就別上 Agent」。本篇在服務層再加一級遞進：就算決定用 Agent，也不代表你需要一整套非同步、狀態持久化的重型 runtime。先問這個請求會不會長、會不會有不可逆副作用、要不要能恢復——答案決定你該停在哪一階：

選型階梯：能停在同步就別上非同步，能用輕量狀態就別上重型持久化——與 Agent 編排篇「能用 Workflow 就別上 Agent」是同一種節制的紀律。