對話式 AI 代理內部運作原理

對話式 AI 代理的內部運作原理(OpenClaw 架構)

對話式 AI 代理如何運作?在實際應用中,每個回合是如何進行的?本文將揭開 OpenClaw 的黑盒子:從客戶訊息抵達 WhatsApp 的那一刻,到代理回覆的文字。內容會比較技術性。如果您負責產品架構決策、正在評估採購解決方案並想深入了解,或者只是想知道對話背後發生了什麼,這篇文章值得一讀。

TL;DR: 每個回合經過 6 個階段 — 接收、解析上下文、選擇技能、決定下一步行動、執行並設置防護欄、持久化記憶。整個週期在 Cloudflare 邊緣運行,耗時 <2 秒,無需固定伺服器。

---

為什麼架構很重要

在演示中看似運作良好但在生產環境中崩潰的對話式代理,通常存在以下 4 個問題之一:

1. 高延遲 — 客戶等待 8 秒才得到回應,對話就此中斷。
2. 無法控制的幻覺 — 代理編造價格、時間、政策。
3. 上下文丟失 — 客戶 2 天後回來,代理「忘記」了一切。
4. 成本失控 — 每次長對話都會填滿提示詞,您需要為大量 token 付費。

這 4 個問題都是架構選擇的結果,而非模型的限制。OpenClaw 的構建目標就是避免這 4 個問題 — 而理解的方法就是查看一個回合的週期。

---

一個回合的週期(6 個階段)

假設客戶剛剛發送了訊息 「我想預約星期六早上」。從「已接收」到代理回應之間發生了什麼?

階段 1 — 接收(邊緣 worker,<50ms)

WhatsApp 訊息透過 Meta 的 webhook 直接抵達地理位置最近的 Cloudflare Worker 存在點(PoP)。在巴西,這意味著聖保羅或里約,網路延遲 < 20ms。

worker 執行三件事:

1. 驗證 webhook 的簽名(使用 WABA 密鑰進行 HMAC 驗證)。
2. 識別租戶,根據接收者的電話號碼(透過 to_number 進行多租戶識別)。
3. 標準化 payload — 音訊轉為文字記錄、圖片轉為描述、位置轉為 {lat,lng}、文字保持原樣。

階段 1 結束時,您會得到一個 {tenant_id, conversation_id, user_message} 物件,準備進入下一步。

階段 2 — 解析上下文(D1 + KV,~80ms)

代理在做決定之前需要 3 個上下文資訊:

• 對話的近期歷史記錄(最近 N 個相關回合)。
• 客戶的長期記憶(偏好設定、購買歷史、備註)。
• 代理狀態(角色、已啟用的技能、規則)。

所有這些都來自 D1(Cloudflare 的分散式 SQLite)。D1 取代了傳統的 Postgres/Mongo——無需維護資料庫伺服器,從 worker 存取只需幾毫秒,透過 tenant_id 實現多租戶。

關鍵點:我們不會在提示中載入整個對話。OpenClaw 的 Memory Manager v2(在我們的內部文件中描述)只選擇與當前回合相關的回合(最近 N 個 + N 個高語義相關性的回合)。這使得即使在 100 多個回合的對話中,token 成本也能保持可預測。

階段 3 — 技能選擇(策略引擎,約 20ms)

每個代理都有一組可用的技能——它可以呼叫的函數。例如:consultar_calendario、criar_evento、gerar_link_pagamento、consultar_pedido、chamar_humano。

給定訊息 "quero marcar pra sábado de manhã",策略引擎會篩選:

• 與檢測到的意圖相容的技能(排程)。
• 在對話的這個階段允許的技能(並非所有技能都始終可用)。
• 此租戶啟用的技能(只有在租戶整合時才會出現日曆)。

最終你會得到一個傳遞給模型的小型技能子集——不是 50 個可能的技能,只有 4 個在這裡有意義的技能。這大大降低了模型呼叫錯誤技能的機會。

階段 4 — 決策(LLM 呼叫,400-1200ms)

現在模型登場了。OpenClaw 對前沿 LLM(Anthropic Claude、OpenAI GPT、Google Gemini——可按租戶配置)進行一次呼叫,包含:

• 系統提示 = 代理的角色 + 規則 + 可用技能。
• 歷史記錄 = 階段 2 中選擇的回合。
• 使用者訊息 = 當前回合的訊息。

模型回應以下兩種情況之一:

• 最終回應(直接給客戶的文字)。
• 工具呼叫(請求執行具有參數的特定技能)。

在範例 "quero marcar pra sábado de manhã" 中,模型通常會返回:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

階段 5 — 帶護欄的執行(可變,約 100-500ms)

技能不是在模型中執行的。它在我們的程式碼中執行,該程式碼:

1. 驗證參數（date_range 格式是否正確?是否符合租戶規則?）。
2. 檢查權限（此代理是否有權查詢此行事曆?）。
3. 執行呼叫（在此情況下為 Google Calendar API）。
4. 回傳結構化結果給模型。

為什麼這很重要?因為模型永遠不會捏造結果。如果行事曆回傳 [10h, 11h],那就是會傳遞到下一次呼叫的確切內容。如果技能失敗,模型會知道失敗了。代理「編造」9點有時段的風險為零,當實際上沒有時。

對於涉及敏感資訊(價格、期限、客戶名稱)的情況,流程會強制執行 tool call — 不讓模型從自己的「知識」中回答。這消除了最常見的幻覺類別,在商業代理中。

階段 6 — 回應與持久化 (~50ms)

掌握技能結果後,模型進行第二次呼叫 — 現在是為客戶形成最終回應。例如:

"我有星期六 10 點和 11 點。您偏好哪個?"

同時,worker:

1. 發送訊息回 WhatsApp API。
2. 持久化完整回合(user + assistant + tool calls + 持續時間)到 D1。
3. 更新長期記憶,如果回合產生新事實(例如:「客戶偏好星期六」)。
4. 發出可觀察性事件(延遲指標、token 成本、升級率)。

所有這些都並行運行。持久化不會阻塞訊息發送 — 客戶不會等待 D1。

---

防禦幻覺的機制在哪裡

在生產環境中產生幻覺的代理會迅速失去信任。OpenClaw 有 4 道防線:

1. **強制真實來源。**事實數據(價格、時間、名稱)總是來自技能,永遠不會單獨來自模型。
2. **敏感數據雙重驗證。**預約在持久化之前會與客戶確認。付款在授予存取權限之前會確認。
3. **明確的否定規則。**每個代理的角色包括「永遠不要編造 X、Y、Z」— 模型會遵守。
4. **人工後備方案。**當沒有技能涵蓋問題時,代理會說 "讓我與團隊確認"並開立工單 — 不會猜測。

在我們過去 6 個月進行的審計中(手動審查真實對話),事實幻覺率低於回合的 0.3% — 幾乎所有案例都是由於配置問題(租戶忘記啟用相關技能),而非模型錯誤。

---

每次對話的成本

好的架構是隱形的,直到你看到帳單。考慮到每個回合會進行 1-2 次 LLM 呼叫 + D1 查詢,每次完整對話(10-15 個回合)的典型成本為: