对话式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 个相关轮次）。
• 客户的长期记忆（偏好、购买历史、备注）。
• Agent 状态（人设、已启用的 skills、规则）。

所有这些都来自 D1（Cloudflare 的分布式 SQLite）。D1 取代了传统的 Postgres/Mongo——无需维护数据库服务器，从 worker 访问仅需几毫秒，通过 tenant_id 实现多租户。

关键点： 我们不会将整个对话加载到 prompt 中。OpenClaw 的 Memory Manager v2（详见我们的内部文档）仅选择与当前轮次相关的对话轮次（最近 N 轮 + N 轮高语义相关性的轮次）。这使得即使在 100+ 轮的对话中，token 成本也保持可预测。

阶段 3 — Skills 选择（策略引擎，约 20ms）

每个 agent 都有一组可用的 skills——它可以调用的函数。例如：consultar_calendario、criar_evento、gerar_link_pagamento、consultar_pedido、chamar_humano。

给定消息 "quero marcar pra sábado de manhã"，策略引擎会过滤：

• 与检测到的意图（预约）兼容的 skills。
• 在该对话阶段允许使用的 skills（并非所有 skill 在任何时候都可用）。
• 该租户已启用的 skills（只有当租户集成了日历功能时，calendar 才会出现）。

最终你会得到一个小的 skills 子集传递给模型——不是全部 50 个可能的 skills，而只是在此场景下有意义的 4 个。这大幅降低了模型调用错误 skill 的概率。

阶段 4 — 决策（LLM 调用，400-1200ms）

现在模型登场。OpenClaw 向前沿 LLM（Anthropic Claude、OpenAI GPT、Google Gemini——可按租户配置）发起一次调用，包含：

• System prompt = agent 的人设 + 规则 + 可用 skills。
• History = 阶段 2 中选择的对话轮次。
• User message = 当前轮次的消息。

模型会返回以下两种之一：

• 最终回复（直接发送给客户的文本）。
• Tool call（请求执行特定 skill 并附带参数）。

在 "quero marcar pra sábado de manhã" 的例子中，模型通常会返回：

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

阶段 5 — 带护栏的执行（可变，约 100-500ms）

Skill 不会在模型中运行。它运行在我们自己的代码中，该代码会：

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 个回合）的典型成本为：