Cách Hoạt Động của Một Agent AI Hội Thoại Bên Trong

Cách Hoạt Động của Agent AI Hội Thoại Bên Trong (Kiến Trúc OpenClaw)

Cách hoạt động của agent AI hội thoại trong thực tế, từng lượt một? Bài viết này mở hộp đen của OpenClaw: từ thời điểm tin nhắn của khách hàng đến WhatsApp cho đến văn bản mà agent viết lại. Sẽ khá kỹ thuật. Đáng đọc nếu bạn quyết định kiến trúc sản phẩm, nếu bạn sẽ mua một giải pháp và muốn đánh giá kỹ lưỡng, hoặc nếu bạn thích biết điều gì đang diễn ra phía sau cuộc trò chuyện.

TL;DR: mỗi lượt trải qua 6 giai đoạn — ingest, resolve context, chọn skills, quyết định hành động tiếp theo, thực thi với guard-rails, lưu trữ bộ nhớ. Toàn bộ chu trình chạy trong <2 giây trên edge của Cloudflare, không cần máy chủ cố định.

---

Tại sao kiến trúc quan trọng

Agent hội thoại có vẻ hoạt động trong demo nhưng gặp sự cố trong production thường có một trong 4 vấn đề này:

1. Độ trễ cao — khách hàng chờ 8 giây để nhận phản hồi, cuộc trò chuyện chết.
2. Ảo giác không kiểm soát — agent bịa giá, giờ, chính sách.
3. Mất ngữ cảnh — khách hàng quay lại sau 2 ngày và agent "quên" mọi thứ.
4. Chi phí mất kiểm soát — mỗi cuộc trò chuyện dài làm đầy prompt và bạn trả một gia tài cho token.

Cả 4 đều là lựa chọn kiến trúc, không phải giới hạn của mô hình. OpenClaw được xây dựng để tránh cả 4 — và cách để hiểu là nhìn vào chu trình của một lượt.

---

Chu trình của một lượt (6 giai đoạn)

Hãy tưởng tượng khách hàng vừa gửi tin nhắn "tôi muốn đặt lịch cho sáng thứ bảy". Điều gì xảy ra giữa "received" và phản hồi của agent?

Giai đoạn 1 — Ingest (edge worker, <50ms)

Tin nhắn WhatsApp đến qua webhook của Meta trực tiếp vào Cloudflare Worker tại điểm hiện diện (PoP) gần nhất về mặt địa lý. Ở Brazil, điều này có nghĩa là São Paulo hoặc Rio, độ trễ mạng < 20ms.

Worker thực hiện ba việc:

1. Xác thực chữ ký của webhook (HMAC với secret của WABA).
2. Xác định tenant qua số điện thoại người nhận (multi-tenant theo to_number).
3. Chuẩn hóa payload — audio thành phiên âm, hình ảnh thành mô tả, vị trí thành {lat,lng}, văn bản giữ nguyên.

Cuối giai đoạn 1, bạn có một object {tenant_id, conversation_id, user_message} sẵn sàng cho bước tiếp theo.

Giai đoạn 2 — Resolve context (D1 + KV, ~80ms)

Agent cần 3 phần ngữ cảnh trước khi quyết định:

• Lịch sử gần đây của cuộc hội thoại (N lượt gần nhất có liên quan).
• Bộ nhớ dài hạn của khách hàng (sở thích, lịch sử mua hàng, ghi chú).
• Trạng thái của agent (persona, các kỹ năng được kích hoạt, quy tắc).

Tất cả đều đến từ D1 (SQLite phân tán của Cloudflare). D1 thay thế Postgres/Mongo truyền thống — không cần máy chủ cơ sở dữ liệu để duy trì, truy cập trong vài ms từ worker, đa tenant theo tenant_id.

Điểm quan trọng: chúng tôi không tải toàn bộ cuộc hội thoại vào prompt. Memory Manager v2 của OpenClaw (được mô tả trong tài liệu nội bộ của chúng tôi) chỉ chọn các lượt có liên quan cho lượt hiện tại (N lượt cuối + N lượt có độ liên quan ngữ nghĩa cao). Điều này giữ cho chi phí token có thể dự đoán được ngay cả trong các cuộc hội thoại 100+ lượt.

Giai đoạn 3 — Lựa chọn kỹ năng (policy engine, ~20ms)

Mỗi agent có một tập hợp các kỹ năng khả dụng — các hàm mà nó có thể gọi. Ví dụ: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Với tin nhắn "quero marcar pra sábado de manhã", policy engine lọc:

• Các kỹ năng tương thích với ý định được phát hiện (đặt lịch).
• Các kỹ năng được phép cho giai đoạn này của cuộc hội thoại (không phải kỹ năng nào cũng khả dụng mọi lúc).
• Các kỹ năng mà tenant này đã kích hoạt (calendar chỉ xuất hiện nếu tenant đã tích hợp).

Cuối cùng bạn có một tập hợp con nhỏ các kỹ năng được truyền cho mô hình — không phải 50 kỹ năng có thể, chỉ 4 kỹ năng có ý nghĩa ở đây. Điều này giảm đáng kể khả năng mô hình gọi sai kỹ năng.

Giai đoạn 4 — Quyết định (LLM call, 400-1200ms)

Bây giờ mô hình tham gia. OpenClaw thực hiện một lần gọi duy nhất đến một LLM tiên tiến (Anthropic Claude, OpenAI GPT, Google Gemini — có thể cấu hình theo tenant) với:

• System prompt = persona của agent + quy tắc + các kỹ năng khả dụng.
• History = các lượt được chọn ở giai đoạn 2.
• User message = tin nhắn của lượt hiện tại.

Mô hình phản hồi một trong hai thứ:

• Phản hồi cuối cùng (văn bản trực tiếp cho khách hàng).
• Tool call (yêu cầu thực thi một kỹ năng cụ thể với các tham số).

Trong ví dụ "quero marcar pra sábado de manhã", mô hình thường trả về:

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

Giai đoạn 5 — Thực thi với guard-rails (biến đổi, ~100-500ms)

Kỹ năng không chạy trong mô hình. Nó chạy trong mã của chúng tôi, mã này:

1. Xác thực tham số (date_range có định dạng đúng không? có nằm trong quy tắc của tenant không?).
2. Kiểm tra quyền (agent này có quyền truy vấn lịch này không?).
3. Thực hiện cuộc gọi (Google Calendar API trong trường hợp này).
4. Trả về kết quả có cấu trúc cho mô hình.

Tại sao điều này quan trọng? Bởi vì mô hình không bao giờ tự tạo kết quả. Nếu lịch trả về [10h, 11h], đó chính xác là những gì được chuyển đến cuộc gọi tiếp theo. Nếu skill thất bại, mô hình biết rằng nó đã thất bại. Không có rủi ro agent "bịa đặt" rằng có giờ lúc 9h khi không có.

Đối với các trường hợp liên quan đến thông tin nhạy cảm (giá, thời hạn, tên khách hàng), pipeline buộc phải tool call — không để mô hình trả lời từ "kiến thức" của chính nó. Điều này loại bỏ loại ảo giác phổ biến nhất trong các agent thương mại.

Giai đoạn 6 — Phản hồi và lưu trữ (~50ms)

Với kết quả từ skill trong tay, mô hình thực hiện cuộc gọi thứ hai — bây giờ để tạo phản hồi cuối cùng cho khách hàng. Ví dụ:

"Tôi có thứ Bảy lúc 10h và 11h. Bạn thích giờ nào?"

Đồng thời, worker:

1. Gửi tin nhắn trả lại qua API của WhatsApp.
2. Lưu trữ toàn bộ lượt (user + assistant + tool calls + thời lượng) trong D1.
3. Cập nhật bộ nhớ dài hạn nếu lượt tạo ra sự kiện mới (ví dụ: "khách hàng thích thứ Bảy").
4. Phát sự kiện khả năng quan sát (chỉ số độ trễ, chi phí token, tỷ lệ leo thang).

Tất cả điều này chạy song song. Việc lưu trữ không chặn việc gửi tin nhắn — khách hàng không chờ D1.

---

Phòng thủ chống ảo giác ở đâu

Agent ảo giác trong môi trường production sẽ mất lòng tin nhanh chóng. OpenClaw có 4 tuyến phòng thủ:

1. Source-of-truth bắt buộc. Dữ liệu thực tế (giá, giờ, tên) luôn luôn đến từ skill, không bao giờ chỉ từ mô hình.
2. Xác minh kép với dữ liệu nhạy cảm. Lịch hẹn được xác nhận với khách hàng trước khi lưu trữ. Thanh toán được xác nhận trước khi cấp quyền truy cập.
3. Quy tắc phủ định rõ ràng. Persona của mỗi agent bao gồm "không bao giờ bịa đặt X, Y, Z" — mô hình tuân theo.
4. Fallback cho con người. Khi không có skill nào bao phủ câu hỏi, agent nói "để tôi kiểm tra với nhóm" và mở ticket — không đoán.

Trong các cuộc kiểm toán mà chúng tôi đã thực hiện trong 6 tháng qua (các cuộc trò chuyện thực được xem xét thủ công), tỷ lệ ảo giác thực tế dưới 0,3% số lượt — và hầu hết các trường hợp là do cấu hình (tenant quên kích hoạt skill liên quan), không phải lỗi của mô hình.

---

Chi phí mỗi cuộc trò chuyện

Kiến trúc tốt là vô hình cho đến khi bạn nhìn vào hóa đơn. Với mỗi lượt thực hiện 1-2 lần gọi LLM + tra cứu trong D1, chi phí điển hình cho một cuộc hội thoại hoàn chỉnh (10-15 lượt) là: