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

AI 對話代理的內部運作原理（OpenClaw 架構）

AI 對話代理究竟是如何運作的？每一輪對話的實際流程是什麼？這篇文章將打開 OpenClaw 的黑盒子：從客戶在 WhatsApp 上發送訊息的那一刻起，到代理回覆文字為止。內容會偏技術性。如果你負責產品架構決策、正在評估採購方案想深入了解底層，或者單純對對話背後的機制感到好奇，這篇文章值得一讀。

TL;DR： 每一輪對話經過 6 個階段——接收、解析上下文、選擇技能、決定下一步動作、在防護機制下執行、持久化記憶。整個循環在 Cloudflare 邊緣節點上以 <2 秒完成，無需固定伺服器。

---

為什麼架構很重要

對話代理在 demo 中看起來運作正常，但在生產環境中崩潰，通常是因為以下 4 個問題之一：

1. 高延遲 ——客戶等了 8 秒才收到回覆，對話就此中斷。
2. 不受控的幻覺 ——代理捏造價格、營業時間、政策。
3. 上下文遺失 ——客戶 2 天後回來，代理「忘記」了一切。
4. 成本失控 ——每段長對話塞滿 prompt，你在 token 上花費驚人。

這 4 個問題都是架構選擇的結果，而非模型的限制。OpenClaw 的設計就是為了避免這 4 個問題——而理解的途徑就是觀察一輪對話的循環。

---

一輪對話的循環（6 個階段）

假設客戶剛剛發送了訊息 "quero marcar pra sábado de manhã"。從「已接收」到代理回覆之間，發生了什麼？

階段 1 — 接收（edge 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 — 技能選擇（policy engine，約 20ms）

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

當收到訊息 "quero marcar pra sábado de manhã" 時，policy engine 會篩選：

• 與偵測到的意圖（預約排程）相容的技能。
• 在該對話階段中被允許的技能（並非所有技能在任何時候都可用）。
• 該租戶已啟用的技能（只有當租戶整合了行事曆，calendar 才會出現）。

最終，只有一小部分技能會傳遞給模型——不是全部 50 個可能的技能，而是在此情境下有意義的 4 個。這大幅降低了模型呼叫錯誤技能的機率。

階段 4 — 決策（LLM 呼叫，400-1200ms）

現在模型登場。OpenClaw 對前沿 LLM（Anthropic Claude、OpenAI GPT、Google Gemini——可依租戶配置）發出單次呼叫，包含：

• System prompt = 代理的角色設定 + 規則 + 可用技能。
• History = 階段 2 中選取的回合。
• User message = 當前回合的訊息。

模型會回傳以下兩種結果之一：

• 最終回覆（直接傳送給客戶的文字）。
• Tool call（請求以特定參數執行某個技能）。

以 "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 個回合）的典型成本為：