Blog / Series AI Agents Thực Chiến

Từ chatbot → AI Agent: kiến trúc tối thiểu để tự động hoá (và tránh ảo giác)

Vì sao thị trường hay nhầm chatbot với agent?

Trong hai năm qua, gần như mọi sản phẩm dùng LLM đều muốn gắn cho mình chữ “agent”. Lý do khá dễ hiểu: từ này gợi cảm giác chủ động, thông minh và gần với hình dung về một “đồng nghiệp số”. Nhưng nếu nhìn kỹ vào nhiều sản phẩm được gọi là agent, phần lớn trong số đó vẫn chỉ là chatbot có thêm một vài tool gọi theo kịch bản.

Một chatbot có thể rất thuyết phục trong hội thoại. Nó trả lời nhanh, giữ giọng điệu tốt, nhớ được vài lượt trao đổi trước đó, thậm chí biết gọi API tra cứu thông tin. Nhưng như vậy vẫn chưa đủ để gọi là agent. Lý do rất đơn giản: trả lời một câu hỏi và hoàn thành một công việc là hai bài toán khác nhau.

Khi hệ thống bước vào thế giới công việc thật, tiêu chí đánh giá thay đổi hoàn toàn. Người dùng không còn hỏi “mô hình này viết có hay không?”, mà bắt đầu hỏi:

• Yêu cầu này có được xử lý trọn vẹn không?
• Hệ thống có tự nhớ trạng thái giữa các bước không?
• Nếu một tool lỗi giữa chừng, quy trình có phục hồi được không?
• Nếu tác vụ nhạy cảm, hệ thống có biết dừng để chờ phê duyệt không?

Chính ở điểm này, ranh giới giữa chatbot và agent mới hiện ra rõ nét. Agent không chỉ tạo ra văn bản. Nó phải vận hành như một hệ thống bán tự động có thể chịu được trạng thái, lỗi và rủi ro thực tế.

5 khác biệt cốt lõi giữa chatbot và agent

1) Chatbot tối ưu hội thoại, agent tối ưu hoàn thành mục tiêu

Chatbot được đánh giá chủ yếu bằng chất lượng câu trả lời: có đúng ý, có mượt, có tự nhiên hay không. Agent thì khác. Nó được đánh giá bằng việc một mục tiêu có được hoàn thành hay không, mất bao lâu, phải nhờ con người can thiệp bao nhiêu lần, và hậu quả của sai sót là gì.

2) Chatbot có thể gần như stateless, agent phải có state

Một chatbot có thể hoạt động khá ổn với ngữ cảnh ngắn. Nhưng agent thường phải đi qua nhiều bước: đọc yêu cầu, lập kế hoạch, gọi công cụ, chờ phản hồi, lưu trạng thái giữa chừng, rồi tiếp tục ở thời điểm khác. Không có state, agent gần như không thể làm việc nghiêm túc.

3) Chatbot chủ yếu trả lời, agent phải hành động

Đây là khác biệt dễ thấy nhất. Agent phải nối với công cụ, dữ liệu và hệ thống ngoài. Chính vì vậy, những bài toán như MCP và tool calling không phải phần “trang trí thêm”, mà là lõi hạ tầng.

4) Chatbot có thể sai mà chỉ gây khó chịu, agent sai có thể gây thiệt hại

Nếu chatbot hiểu sai một câu hỏi, người dùng chỉ cần hỏi lại. Nếu agent hiểu sai và tự cập nhật nhầm dữ liệu CRM, gửi nhầm email, hoặc mở quyền sai trong hệ thống, cái giá phải trả lớn hơn nhiều. Vì vậy, agent bắt buộc phải có bước verification và policy check.

5) Chatbot dễ demo, agent khó vận hành

Một chatbot tốt có thể gây ấn tượng ngay trong 30 giây. Một agent tốt thường không “wow” mạnh bằng trong demo đầu tiên, nhưng sẽ thể hiện giá trị sau 30 ngày chạy ổn định. Đây cũng là lý do rất nhiều sản phẩm demo agent rất đẹp nhưng khi vào production lại tạo ra thêm việc cho đội vận hành thay vì giảm việc.

Use case thật: trợ lý xử lý yêu cầu vận hành nội bộ

Hãy lấy một use case thực tế hơn “đặt lịch” hay “tóm tắt email”: một công ty muốn có trợ lý nội bộ để xử lý yêu cầu vận hành theo kiểu chat.

Người dùng gửi một yêu cầu như sau:

Nếu đây chỉ là chatbot, hệ thống có thể trả lời bằng vài giả thuyết nghe hợp lý: có thể do deploy, có thể do database, có thể do timeout upstream. Nhưng một agent thật phải làm nhiều hơn thế:

1. Truy vấn hệ thống giám sát để lấy biểu đồ lỗi theo thời gian.
2. Đối chiếu với lịch sử deploy hoặc release log.
3. Lọc log tương ứng khoảng thời gian 22h.
4. Tóm tắt các dấu hiệu chính.
5. Nếu thỏa điều kiện, tạo ticket ở hệ thống issue tracking.
6. Gắn priority phù hợp và đính kèm chứng cứ.
7. Chỉ gửi draft hoặc yêu cầu approval nếu thao tác có rủi ro cao.

Đây không còn là bài toán hội thoại. Đây là bài toán điều phối trạng thái + dữ liệu + quyền hạn + hành động. Một chatbot có thể trả lời hay, nhưng không có kiến trúc đủ để xử lý chuỗi này một cách tin cậy.

Kiến trúc tối thiểu để agent chạy được việc

Nếu bóc mọi lớp trang trí đi, một agent chạy được việc thường cần ít nhất 6 thành phần.

1) Intent layer: hiểu yêu cầu theo ngôn ngữ công việc

Lớp đầu tiên không chỉ để phân loại ý định kiểu FAQ. Nó phải biến câu nói tự nhiên thành một mục tiêu tác vụ có thể thực thi: mục tiêu là gì, điều kiện thành công là gì, có ràng buộc nào, và cần môi trường nào để làm.

2) Planning layer: tách mục tiêu thành bước

Rất nhiều hệ “agent” thất bại vì nhảy thẳng từ câu hỏi sang tool execution mà không có bước hoạch định. Planning không nhất thiết phải là một sơ đồ quá phức tạp, nhưng tối thiểu phải giúp hệ thống xác định thứ tự bước, phụ thuộc dữ liệu, và điều kiện dừng.

3) Tool layer: hành động lên thế giới thật

Tool layer là nơi agent chạm vào email, ticketing, database, browser, script hoặc dịch vụ nội bộ. Đây là chỗ cần thiết kế schema rõ, audit tốt và kiểm soát quyền chặt. Với các hệ thống nghiêm túc, lớp này thường đi cùng một chuẩn kết nối như MCP để giảm độ chắp vá.

4) Verification layer: kiểm tra trước khi commit

Nhiều đội kỹ thuật đầu tư rất nhiều vào planner nhưng lại thiếu verifier. Hệ quả là agent làm được 80% chặng đường rồi hỏng ở bước cuối. Verification có thể là rule-based, model-based, hoặc kết hợp cả hai. Điều quan trọng là hệ thống phải có một cơ chế độc lập để hỏi lại: “kết quả này có thật sự thỏa điều kiện thành công chưa?”

5) Memory/state layer: giữ mạch công việc

State ngắn hạn giúp agent nhớ đang ở bước nào trong workflow. Memory dài hạn giúp hệ thống nhớ preference, quy ước, quyết định trước đó hoặc tri thức nền tảng. Nếu gom tất cả vào một context khổng lồ, hệ thống sẽ vừa đắt vừa khó kiểm soát. Nếu không có memory, agent sẽ cư xử như người mới vào ca ở mỗi lượt gọi.

6) Policy/approval layer: giới hạn quyền lực của mô hình

Phần này thường bị xem nhẹ ở giai đoạn đầu vì nó làm giảm cảm giác “tự động hoàn toàn”. Nhưng production không quan tâm cảm giác. Production quan tâm việc hệ thống có làm sai, có gây hậu quả, có lộ dữ liệu, có đốt chi phí vô ích hay không. Đây là lý do mọi agent nghiêm túc cuối cùng đều phải chạm đến bài toán security, approval và least-privilege.

“Ảo giác” trong agent thực ra xuất hiện ở đâu?

Khi nói đến AI, người ta hay dùng từ “hallucination” theo nghĩa hẹp: model bịa thông tin. Với agent, khái niệm này cần mở rộng hơn. Một agent có thể không bịa nội dung, nhưng vẫn “ảo giác” ở cấp hệ thống theo nhiều cách khác:

• Ảo giác về trạng thái: tưởng một bước đã chạy xong nhưng thực ra tool bị lỗi giữa chừng.
• Ảo giác về nguyên nhân: thấy tương quan rồi kết luận quan hệ nhân quả mà không đủ chứng cứ.
• Ảo giác về quyền hạn: cho rằng mình được phép làm điều gì đó trong khi policy không cho phép.
• Ảo giác về hoàn thành: trả lời như thể tác vụ đã hoàn tất, nhưng thực ra mới dừng ở bản nháp.

Đó là lý do không thể giải quyết toàn bộ vấn đề bằng một prompt “hãy cẩn thận và không bịa”. Muốn giảm ảo giác ở cấp agent, phải xử lý bằng kiến trúc: có verifier, có logging, có state machine hợp lý, có approval gate và có nguyên tắc rõ ràng cho việc tool nào được gọi ở thời điểm nào.

Đo agent bằng gì nếu không muốn bị demo đánh lừa?

Nếu chỉ dựa vào cảm giác “nó nói nghe hợp lý”, gần như chắc chắn hệ thống sẽ bị đánh giá sai. Agent cần được đo như một hệ vận hành, không phải như một chatbot giải trí.

Một bộ chỉ số thực dụng thường nên có:

• Task success rate: bao nhiêu phần trăm tác vụ hoàn thành đúng tiêu chí.
• Mean time to completion: mất bao lâu để hoàn thành mỗi loại việc.
• Human intervention rate: tỷ lệ phải nhờ người can thiệp.
• Error taxonomy: lỗi do dữ liệu, do planning, do tool, do policy hay do UX.
• Rollback cost: khi làm sai, sửa lại tốn bao nhiêu.

Điểm đáng chú ý là nhiều hệ agent thất bại không phải vì model quá yếu, mà vì đội ngũ không hề biết đang đo cái gì. Họ tối ưu prompt trong khi vấn đề nằm ở tool schema. Họ đổi model trong khi lỗi nằm ở state handling. Họ thêm context trong khi failure đến từ policy không rõ. Nếu không có khung đo lường đúng, mọi tối ưu hóa đều dễ lạc hướng.

Lộ trình nâng từ chatbot lên agent mà không tự làm hỏng hệ thống

Con đường tốt nhất thường không phải là nhảy thẳng từ chatbot sang “agent toàn quyền”. Cách thực tế hơn là mở dần từng lớp năng lực.

Giai đoạn 1: đọc và giải thích

Bắt đầu bằng các tool read-only: tra tài liệu, đọc ticket, xem metric, đọc lịch sử giao dịch. Mục tiêu ở giai đoạn này là để hệ thống hiểu miền dữ liệu và người dùng thấy giá trị mà chưa phải trả giá cho lỗi ghi dữ liệu.

Giai đoạn 2: lập kế hoạch và gợi ý hành động

Tiếp theo, để agent đề xuất kế hoạch hành động, tạo draft hoặc chuẩn bị dữ liệu đầu vào cho con người xác nhận. Đây là cách tốt để huấn luyện kỳ vọng và quan sát failure modes trước khi mở quyền mạnh hơn.

Giai đoạn 3: hành động có approval

Khi chất lượng đã đủ tốt, hệ thống có thể được phép tạo ticket, gửi email nội bộ, cập nhật trạng thái hoặc chạy workflow giới hạn. Mọi tác vụ có hậu quả rõ nên có approval gate hoặc cơ chế dry-run trước.

Giai đoạn 4: tối ưu hóa vận hành

Lúc này bài toán không còn là “agent có làm được không”, mà là “hệ có chạy ổn định, dễ bảo trì và dễ mở rộng không”. Đây là giai đoạn phải đầu tư nhiều hơn vào workflow, retries, memory strategy, cron jobs, sub-tasks và observability. Với những ai triển khai trên OpenClaw hoặc hệ tương tự, đây chính là lớp vấn đề thuộc về workflow và reliability 24/7.

Kết luận

Bước chuyển từ chatbot sang agent không phải là chuyện thêm vài tool rồi đổi tên sản phẩm. Nó là bước chuyển từ một hệ thống tối ưu cho hội thoại sang một hệ thống tối ưu cho hoàn thành công việc trong môi trường có trạng thái, rủi ro và trách nhiệm.

Khi nhìn theo hướng đó, kiến trúc của agent cũng trở nên rõ ràng hơn nhiều. Cần planning, cần tool layer, cần verification, cần memory, cần policy, cần đo lường. Nếu thiếu những lớp này, hệ thống vẫn có thể “trông giống agent” ở bề mặt, nhưng dưới tải công việc thật nó sẽ lộ ra bản chất chatbot nâng cấp.

Ngược lại, nếu xây đúng nền, giá trị của agent không chỉ nằm ở việc trả lời nhanh hơn. Giá trị nằm ở chỗ một phần công việc bắt đầu được xử lý như một quy trình có thể quan sát, đo lường, kiểm soát và cải tiến liên tục. Và đó mới là điểm khiến AI agents đáng để đầu tư nghiêm túc.