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

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

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

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

---

為什麼架構很重要

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

1. 高延遲 — 客戶等待 8 秒才得到回應,對話就此終結。
2. 不受控制的幻覺 — 代理編造價格、時間、政策。
3. 上下文丟失 — 客戶 2 天後回來,代理「忘記」了一切。
4. 成本失控 — 每次長對話都會填滿提示詞,你要為代幣支付巨額費用。

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

---

一輪的週期(6 個階段)

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

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

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

worker 執行三項任務:

1. 驗證 webhook 的簽名(針對 WABA 密鑰的 HMAC)。
2. 識別租戶,通過接收者的電話號碼(按 to_number 多租戶)。
3. 規範化 有效負載 — 音訊轉為轉錄文字、圖片轉為描述、位置轉為 {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 個回合)的典型成本為: