Cách Một Agent AI Đàm Thoại Hoạt Động Bên Trong

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

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

TL;DR: mỗi lượt đi qua 6 giai đoạn — ingest, phân giải ngữ cảnh, 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 server cố định.

---

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

Agent hội thoại trông có vẻ hoạt động trong demo nhưng hỏng trong production thường có một trong 4 vấn đề sau:

1. Độ trễ cao — khách hàng chờ 8 giây để có phản hồi, cuộc hội thoại 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" hết.
4. Chi phí mất kiểm soát — mỗi cuộc hội thoại dài làm đầy prompt và bạn trả cả 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 model. 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 "quero marcar pra sábado de manhã". Đ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 từ WhatsApp đến qua webhook của Meta trực tiếp vào một Cloudflare Worker tại điểm hiện diện (PoP) gần nhất về mặt địa lý. Tại 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 đối chiếu với secret của WABA).
2. Xác định tenant theo số điện thoại người nhận (multi-tenant theo to_number).
3. Chuẩn hóa payload — audio chuyển thành phiên âm, hình ảnh chuyển thành mô tả, vị trí chuyển 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 — Phân giải ngữ cảnh (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, skills đượ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 duy trì server cơ sở dữ liệu, truy cập trong vài ms từ worker, multi-tenant theo tenant_id.

Điểm mấu chốt: 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 những lượt có liên quan cho lượt hiện tại (N lượt gần nhất + N lượt có độ liên quan ngữ nghĩa cao). Điều này giữ chi phí token có thể dự đoán được ngay cả trong các cuộc hội thoại hơn 100 lượt.

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

Mỗi agent có một tập hợp skills 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:

• Skills tương thích với ý định được phát hiện (đặt lịch).
• Skills được phép cho giai đoạn này của cuộc hội thoại (không phải mọi skill đều khả dụng mọi lúc).
• Skills 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 con nhỏ các skills được truyền cho mô hình — không phải 50 skills có thể, chỉ 4 skills có ý nghĩa ở đây. Điều này giảm đáng kể khả năng mô hình gọi sai skill.

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

Bây giờ mô hình vào cuộc. 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 + skills 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 gửi trực tiếp cho khách hàng).
• Tool call (yêu cầu thực thi một skill 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 (thời gian thay đổi, ~100-500ms)

Skill không chạy trong mô hình. Nó chạy trong code của chúng tôi, với các bước:

1. Xác thực tham số (date_range có đúng định dạ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 thi lệnh gọi (Google Calendar API trong trường hợp này).
4. Trả về kết quả có cấu trúc cho model.

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

Đối với các trường hợp liên quan đến thông tin nhạy cảm (giá cả, thời hạn, tên khách hàng), pipeline buộc phải dùng tool call — không cho phép model trả lời từ "kiến thức" của chính nó. Điều này loại bỏ lớp ảo giác phổ biến nhất ở 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, model thực hiện lệnh gọi thứ hai — lần này để 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?"

Song song đó, worker:

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

Tất cả những đ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 phải chờ D1.

---

Hệ thống phòng chống ảo giác nằm ở đâu

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

1. Nguồn sự thật bắt buộc. Dữ liệu thực tế (giá cả, lịch hẹn, tên) luôn luôn đến từ skill, không bao giờ từ model một mì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. 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 X, Y, Z" — model tuân thủ.
4. Fallback cho con người. Khi không có skill nào xử lý được câu hỏi, agent nói "để tôi kiểm tra với đội ngũ" và mở một ticket — không đoán bừa.

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

---

Chi phí mỗi cuộc hội thoại

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