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

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

AI 對話代理究竟如何運作？逐輪實際操作是怎樣的？本文將打開 OpenClaw 的黑盒子：從客戶在 WhatsApp 發送訊息的那一刻，到代理回覆文字的整個過程。內容會比較技術性。如果你負責產品架構決策、打算購買解決方案並想深入評估，或者單純好奇對話背後發生了什麼，這篇文章值得一讀。

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

---

為什麼架構很重要

對話代理在演示中看起來運作正常，但在生產環境中崩潰，通常是因為以下 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 個回合）的典型成本為：