本地模型上的多步驟 AI 代理：架構與模式

單步驟 AI 代理是一個已解決的問題。用戶說一些事情，模型選擇一個工具，工具返回一個結果。微調的 7B 模型可靠地處理這個問題——我們在工具呼叫微調指南中已經深入介紹了這一點。

多步驟代理是不同的。模型需要規劃一系列動作、在步驟之間追蹤狀態、處理鏈中的錯誤，並決定任務何時完成。這是小型模型歷來崩潰的地方：它們失去上下文、重複步驟、產生工具呼叫幻覺或無限循環。

但「歷來」在那句話中承擔了很多工作。通過正確的架構模式，多步驟代理今天在本地 7B-14B 模型上可靠地運行。本指南涵蓋三種已驗證的模式、真實基準測試，以及使其有效的工程細節。

核心挑戰：為什麼多步驟對小型模型很難

單步驟代理需要一項技能：將用戶意圖映射到工具呼叫。多步驟代理至少需要四項：

1. 規劃 — 將目標分解為有序步驟
2. 執行 — 在每個步驟使用正確的參數呼叫正確的工具
3. 狀態追蹤 — 將步驟 N 的結果帶入步驟 N+1
4. 錯誤恢復 — 偵測失敗並在重試、跳過或升級之間做出決定

通用 7B 模型掙扎，因為它們是在廣泛的任務上訓練的，而不是在順序推理鏈上。在 2-3 個步驟後，注意力視窗變得嘈雜。模型「忘記」了它已經做了什麼或計劃做什麼。

解決方法不是更大的模型。解決方法是更好的架構。

模式 1：微調專家鏈

不是讓一個模型做所有事情，而是將代理分成專門角色：

用戶請求 → 路由器 → 規劃器 → 執行器 → 驗證器 → 回應

每個模型都很小，但專注：

• 路由器（分類）：確定請求類型。這是訂單嗎？支援查詢嗎？資料查詢嗎？這是一個簡單的分類任務——即使是 1B 模型也能處理。
• 規劃器（分解）：接受分類的請求並輸出有序步驟列表。在你的特定工作流程上微調，它不需要規劃任意任務——只需要你的任務。
• 執行器（工具呼叫）：一次處理一個步驟並產生工具呼叫。這是單步驟工具呼叫——已解決的問題。
• 驗證器（驗證）：檢查累積的結果。所有必需的字段都存在嗎？輸出是否與預期架構匹配？標記重試或升級的問題。

為什麼這在小型模型上有效

每個專家都在狹窄的任務上微調。路由器看到數千個「這種輸入類型映射到這個類別」的例子。規劃器看到數千個「這個類別分解為這些步驟」的例子。沒有單個模型需要保持完整的推理鏈。

權衡

延遲。四個序列的模型呼叫意味著單次呼叫推理時間的 4 倍。在本地 GPU 上，每次 7B 模型推理需要 200-500ms（取決於上下文長度和量化）。4 步鏈總共是 0.8-2.0 秒。

對於大多數業務工作流程，這沒問題。對於實時聊天，這是明顯的。緩解方法：在依賴圖允許的地方並行運行專家。

基準測試：專家鏈 vs 單一模型

單一微調模型比通用模型改善，但鏈架構是一個質的飛躍。每個專家做一件事，做得很好。

模式 2：帶暫存器的單一模型（CoT 微調）

並非每個團隊都想維護四個獨立的模型。模式 2 使用單一模型，但對其進行微調以在採取行動之前逐步思考。

關鍵洞察：你訓練模型在輸出工具呼叫之前產生「暫存器」——一個明確的推理追蹤。這是思維鏈（CoT）微調，但特別針對你的規劃任務。

訓練資料格式

{
  "input": "處理 acme-corp 客戶的 #4521 訂單",
  "output": "<scratchpad>\n第 1 步：驗證 #4521 訂單存在且處於待處理狀態\n第 2 步：檢查所有行項目的庫存\n第 3 步：根據客戶位置計算運輸費用\n第 4 步：確認訂單並發送通知\n當前步驟：1\n</scratchpad>\n<tool_call>{\"function\": \"validate_order\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

每次工具結果後，模型接收更新的上下文並產生下一個暫存器：

{
  "input": "[之前的上下文 + 工具結果：訂單有效，狀態：待處理]\n繼續處理。",
  "output": "<scratchpad>\n第 1 步：驗證訂單——完成（有效，待處理）\n第 2 步：檢查所有行項目的庫存\n當前步驟：2\n</scratchpad>\n<tool_call>{\"function\": \"check_inventory\", \"params\": {\"order_id\": 4521}}</tool_call>"
}

為什麼這有效

暫存器將模型的「工作記憶」外部化。不是隱式追蹤它做了什麼和接下來的事情（小型模型會失去追蹤），計劃字面上在輸出中。模型在每個步驟閱讀自己之前的推理。

在你的特定工作流程的 500-1,000 個例子上微調，教模型你的步驟模式。它不需要規劃任意任務——只需要你的代理處理的 5-15 種工作流程類型。

何時使用模式 2 而不是模式 1

• 你有少於 5 種不同的工作流程類型
• 延遲很重要（一次模型呼叫 vs 四次）
• 你想要更簡單的部署（一個模型服務，而不是四個）
• 你的步驟大多是順序的（有限的並行機會）

基準測試：暫存器 vs 普通微調

CoT 模型每步使用約 2.7 倍的 token（因為暫存器），但準確率提升是值得的。如果你在本地運行，token 是免費的。

模式 3：混合——本地模型 + 前沿回退

有時誠實的答案是：你的本地模型處理 85% 的請求，但剩餘的 15% 確實需要更多能力。模式 3 明確了這一點。

用戶請求 → 本地路由器（分類複雜性）
  ├── 簡單/已知 → 本地代理（模式 1 或 2）
  └── 複雜/模糊 → 前沿 API（GPT-4、Claude）僅用於規劃
       └── 計劃 → 本地執行器（在本地執行工具）

工作原理

本地路由器在兩個軸上分類每個請求：

1. 複雜性：多少步驟？步驟來自已知模板還是新穎的？
2. 模糊性：用戶的意圖清晰嗎？有多個有效的解釋嗎？

已知模板、意圖明確的請求完全在本地進行。新穎或模糊的請求僅將規劃步驟發送到前沿 API。前沿模型產生步驟計劃。本地模型執行每個步驟（工具呼叫）。

費用計算

假設每天 1,000 次代理請求：

• 完整前沿 API：1,000 x $0.03 平均 = $30/天 = $900/月
• 完整本地：1,000 x $0.00 每次查詢 = $0/天（僅硬體費用）
• 混合（85/15 分割）：150 x $0.01（僅規劃，更短的提示）= $1.50/天 = $45/月

混合方法比完整 API 便宜 95%，並處理本地模型會出錯的邊緣案例。

費用上限和護欄

為前沿回退設置硬月預算。達到時，所有請求都路由到帶有置信度標誌的本地模型。應用程式可以決定：帶有免責聲明提供本地結果，或將請求排隊以便後續處理。

步驟之間的狀態管理

無論你使用哪種模式，多步驟代理都需要狀態管理。以下是有效的方法：

對話上下文對象

{
  "session_id": "abc-123",
  "original_request": "處理 acme-corp 的 #4521 訂單",
  "current_step": 2,
  "total_steps": 4,
  "completed_steps": [
    {"step": 1, "tool": "validate_order", "result": {"valid": true, "status": "pending"}, "latency_ms": 340}
  ],
  "pending_steps": ["check_inventory", "calculate_shipping", "confirm_order"],
  "error_count": 0,
  "max_errors": 3
}

將此對象（或壓縮版本）作為上下文傳遞給每次模型呼叫。模型不需要記憶——狀態是明確的。

背景視窗預算

帶有 4,096 個 token 背景視窗的 7B 模型，當你包含工具架構 + 之前的結果 + 暫存器時，會很快填滿。預算：

• 系統提示 + 工具架構：約 800 個 token（固定）
• 當前步驟上下文：約 200 個 token
• 之前步驟結果（壓縮）：每步約 150 個 token
• 暫存器輸出：約 120 個 token

對於 5 步任務：800 + 200 + (4 x 150) + 120 = 1,720 個 token。在 4K 內很舒適。對於更長的鏈，摘要舊的步驟結果而不是包含原始輸出。

錯誤處理：第 3 步失敗時

多步驟代理將在鏈中失敗。問題是接下來發生什麼。

重試邏輯

步驟失敗 → 檢查錯誤類型
  ├── 暫時的（超時、速率限制）→ 重試同一步驟（最多 2 次重試）
  ├── 輸入錯誤（錯誤的參數）→ 使用錯誤上下文重新生成工具呼叫
  └── 邏輯錯誤（不可能的狀態）→ 升級

對於「重新生成」路徑，將錯誤消息附加到模型的上下文：

之前的工具呼叫失敗："inventory_check 返回 404：在 warehouse_east 中找不到 order_id 4521"
調整你的方法並重試。

當你的訓練資料包含錯誤恢復例子時，微調模型會很好地處理這個問題。在你的訓練集中包含 10-15% 的錯誤場景。

升級

當重試失敗或錯誤是邏輯錯誤時，升級：

1. 到前沿模型：通過 GPT-4/Claude 以完整上下文重新運行失敗的步驟
2. 到人工：在審閱隊列中標記帶有完整步驟歷史的請求
3. 優雅降級：完成成功的步驟，返回帶有清楚說明失敗原因的部分結果

護欄：防止無限循環和失控費用

最大步驟數

硬限制。如果你最長的已知工作流程是 6 步，將 max_steps 設置為 8。如果模型達到第 9 步，終止鏈並升級。

MAX_STEPS = 8
STEP_TIMEOUT_MS = 5000

for step in range(MAX_STEPS):
    result = execute_step(context, timeout=STEP_TIMEOUT_MS)
    if result.status == "complete":
        return result
    if result.status == "error" and context.error_count >= MAX_ERRORS:
        return escalate(context)

return escalate(context, reason="max_steps_exceeded")

費用上限（混合模式）

對於模式 3，每小時、每天和每月追蹤前沿 API 支出。在預算的 50%、80% 和 100% 時設置警報。在 100% 時，停止路由到前沿並記錄每個本來應該路由的請求——這成為你下一次迭代的微調資料集。

人機協作

對於高風險工作流程（金融交易、醫療保健決策、法律行動），在最終行動之前添加確認步驟：

步驟 1-3 完成 → 向人工呈現摘要 → 人工批准 → 步驟 4 執行

這在非同步（基於隊列）和同步（基於聊天）介面中自然地工作。

何時多步驟在 7B 上有效，何時需要 14B 以上

分界線：如果模型需要決定做什麼（動態規劃），使用 14B 以上。如果模型遵循帶有小變化的已知模式，7B 在正確的架構下是可以的。

示例：4 步訂單處理代理

以下是使用模式 2（暫存器）在微調的 Qwen 2.5 7B 上的具體實施：

第 1 步——驗證訂單

輸入："處理 acme-corp 的 #4521 訂單"
暫存器："需要 4 個步驟：驗證 → 庫存 → 運輸 → 確認。從驗證開始。"
工具呼叫：validate_order(order_id=4521, customer="acme-corp")
結果：{valid: true, items: [{sku: "W-100", qty: 50}, {sku: "W-200", qty: 25}]}

第 2 步——檢查庫存

暫存器："訂單有效。2 個行項目。檢查兩個 SKU 的庫存。"
工具呼叫：check_inventory(skus=["W-100", "W-200"], quantities=[50, 25])
結果：{W-100: {available: 200, allocated: 50}, W-200: {available: 30, allocated: 25}}

第 3 步——計算運輸費用

暫存器："所有物品可用。acme-corp 客戶在倉庫東區。計算運輸費用。"
工具呼叫：calculate_shipping(order_id=4521, zone="east", weight_kg=37.5)
結果：{method: "ground", cost: 42.50, eta_days: 3}

第 4 步——確認訂單

暫存器："運輸費用已計算。所有檢查通過。確認訂單。"
工具呼叫：confirm_order(order_id=4521, shipping_method="ground", shipping_cost=42.50)
結果：{confirmed: true, confirmation_id: "CNF-88421"}

在 RTX 4090 上所有四個步驟的總延遲：1.8 秒。API 總費用：$0.00。

相同的流程在 GPT-4 上每個訂單花費約 $0.04。以每天 500 個訂單計算，那是每天 $20 或每月 $600——而本地模型在不到 2 秒內完成同樣的工作。

開始

在本地模型上使用多步驟代理的最快路徑：

1. 映射你的工作流程。 列出你的代理處理的每個多步驟過程。大多數團隊有 3-8 種不同的類型。
2. 選擇你的模式。 不到 5 種工作流程類型帶線性步驟？模式 2。更多多樣性或需要並行性？模式 1。需要安全網？模式 3。
3. 構建訓練資料。 每種工作流程類型 200-500 個例子，包括 10-15% 的錯誤場景。
4. 使用 LoRA 微調。 在 Ertas 的單個 GPU 上，7B 模型在一小時內完成微調。
5. 端對端測試鏈在部署之前。運行你的完整工作流程套件，測量逐步準確率，而不只是最終結果準確率。

延伸閱讀

• 工具呼叫微調：如何構建可靠的 AI 代理 — 模式 1 的執行器使用的單步驟工具呼叫基礎
• 7B 模型何時優於 API 呼叫 — 顯示小型模型匹敵前沿效能的基準測試
• 微調小型模型 vs GPT-4：小模型何時獲勝 — 特定任務微調優於通用模型背後的資料