Hầu hết các nhóm AI muốn cải thiện hiệu suất tác nhân đều tìm đến những đòn bẩy quen thuộc: cửa sổ ngữ cảnh lớn hơn, nhiều tài liệu hơn, câu lệnh thông minh hơn. Bài viết này cho rằng đó hoàn toàn là một phản xạ sai lầm. Thành phần còn thiếu không phải là thêm thông tin. Mà là khả năng kiểm soát. Một lớp kiểm soát được thiết kế tốt tạo nên khác biệt giữa tác nhân chỉ hoạt động trong bản minh họa và tác nhân hoạt động được ở môi trường sản xuất.
Cấp cho tác nhân AI bộ nhớ lớn hơn, nhiều tài liệu hơn hoặc cửa sổ ngữ cảnh dài hơn không làm nó thông minh hơn mà chỉ khiến nó chậm và tốn kém hơn. Cải thiện thực sự đến từ việc dạy tác nhân lựa chọn thứ nó cần vào đúng lúc, thay vì tiếp nhận mọi thứ cùng một lúc.
Độ tin cậy đến từ vòng lặp, không phải mô hình. Điểm khác biệt giữa tác nhân gây ấn tượng trong bản minh họa và tác nhân vận hành vững vàng trong môi trường sản xuất không nằm ở chất lượng AI mà ở việc hệ thống có tự kiểm tra công việc hay không. Các tác nhân biết lập kế hoạch, hành động, quan sát và xác minh ở mỗi bước sẽ tự phát hiện lỗi thay vì tự tin đưa ra kết quả sai.
Hầu hết tác nhân AI hiện nay về cơ bản chỉ là chatbot có thêm vài bước; chúng không có cơ chế để biết mình có đang đi đúng hướng không, khi nào nên dừng hoặc khi nào nên thử cách khác. Việc bổ sung một lớp kiểm soát thích hợp—tiêu chí thành công rõ ràng, trạng thái có cấu trúc và các bước xác thực—sẽ biến một thứ mang dáng dấp tác nhân thành hệ thống thực sự đáng tin cậy.
Hôm qua bạn ăn gì vào bữa trưa?
Có lẽ bạn không phát lại mọi ký ức từng có cho đến khi tìm thấy “hôm qua + bữa trưa”. Bạn đi thẳng đến phần trải nghiệm chứa những khái niệm đó. Đây là một mô hình tư duy hữu ích để xây dựng tác nhân:
Một cửa sổ ngữ cảnh khổng lồ không phải là bộ nhớ.
Một đống tài liệu được truy xuất không phải là sự thấu hiểu.
Một chuỗi tư duy dài không đồng nghĩa với độ tin cậy.
Đó chỉ là các thành phần. Nhưng điều khiến một tác nhân thực sự giống tác nhân cũng chính là điều giúp bộ não không phải vét cạn toàn bộ lịch sử cuộc đời: khả năng kiểm soát.
Một khảo sát gần đây—Agentic Reasoning for Large Language Models—đã tóm lược (và đặt tên) rất hay cho sự chuyển dịch mà nhiều người trong chúng ta cảm nhận khi xây dựng hệ thống: từ suy luận bên trong mô hình sang suy luận thông qua tương tác. Bài viết này không phải là bản tóm tắt của nghiên cứu đó. Đây là nỗ lực chuyển sự thay đổi ấy thành thiết kế hệ thống thực tế:
Nếu xây dựng tác nhân như chatbot có công cụ, bạn sẽ tiếp tục gặp các dạng lỗi của chatbot, chỉ khác là sai lầm sẽ tốn kém hơn.
Trong một thời gian, phương án mặc định để “làm mô hình thông minh hơn” về cơ bản là: câu lệnh tốt hơn, chuỗi tư duy, tính nhất quán nội tại/cải thiện dựa trên lấy mẫu và đôi khi thêm khả năng tìm kiếm.
ReAct là một bước ngoặt vì nó khiến quy trình “suy nghĩ → hành động → quan sát” trở nên tự nhiên. Nhưng hãy lưu ý ràng buộc ngầm: phần lớn cách làm này vẫn chỉ là “suy luận một mẫu nhưng dùng nhiều token hơn”. Cách diễn giải của khảo sát sắc bén hơn: suy luận tác nhân nhấn mạnh việc mở rộng tương tác tại thời điểm kiểm thử—biến suy luận thành một quy trình lặp, trong đó mô hình, bộ nhớ và môi trường đều luôn tham gia vào vòng lặp.
Nếu bạn từng xây dựng (hoặc sử dụng) tác nhân gây ấn tượng trong bản minh họa nhưng mong manh trong quy trình thực tế, bài viết này dành cho bạn.
Để tôi mô tả một mô hình mà mình đã thấy rất nhiều lần (và chắc chắn chính tôi cũng từng xây dựng vài phiên bản):
Chọn một mô hình trò chuyện tốt
Thêm vài công cụ (tìm kiếm, truy vấn cơ sở dữ liệu, có thể cả thực thi mã)
Thêm RAG
Thêm câu lệnh hệ thống “you are an autonomous agent”
Gói tất cả trong vòng lặp while cho đến khi nó dừng hoặc hết thời gian
Xin chúc mừng, bạn đã có một thứ mang dáng dấp tác nhân. Nhưng nó thường thất bại theo những cách có thể đoán trước:
Ngữ cảnh phình to: mọi quan sát đều được nối thêm; câu lệnh trở thành những tầng khảo cổ.
Dùng công cụ loạn xạ: “chọn sai công cụ nhưng vẫn đầy tự tin” trở thành dạng lỗi mặc định.
Không có điều kiện dừng: nó tiếp tục vì có thể, chứ không phải vì nên làm vậy.
Không có kỷ luật đảm bảo tính có căn cứ: nó không nhận ra mình sai trừ khi bạn buộc nó kiểm tra.
Bộ nhớ = lịch sử trò chuyện: về cơ bản là ghi nhật ký rồi gọi đó là học hỏi.
Đây là lý do “tác nhân” thường có vẻ kỳ diệu trong bản minh họa nhưng hỗn độn ở môi trường sản xuất. Kinh nghiệm đưa các hệ thống tác nhân vào môi trường sản xuất của chúng tôi cũng phản ánh điều này: khi không còn đánh giá một mô hình mà là cả hệ thống, các dạng lỗi sẽ bao gồm điều hướng, kỷ luật dùng công cụ, tinh gọn ngữ cảnh và thiết kế đánh giá—chứ không chỉ là “mô hình có trả lời đúng không”.
Vậy câu hỏi trở thành: tác nhân đúng nghĩa là gì?
Để bớt trừu tượng, đây là một quy trình mẫu mà hầu hết mọi người đều có thể hình dung: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Một cách triển khai phổ biến “mang dáng dấp tác nhân” thường như sau:
Lập tức truy xuất hàng loạt tài liệu về chính sách hàng không/du lịch (ngay cả khi chưa cần đến).
Gọi công cụ tìm kiếm, dán một danh sách dài kết quả vào câu lệnh rồi “chọn một kết quả”.
Đặt vé quá sớm mà không xác minh các ràng buộc (giờ đến/hành lý/chỗ ngồi/chính sách).
Nếu thất bại, nó sẽ thử lại theo một cách hơi khác nhưng không xác định rõ điều gì đã thay đổi hoặc đã học được gì.
Vấn đề không phải là mô hình không thể suy luận, mà là hệ thống không kiểm soát quy trình làm việc.
Phiên bản mang tính tác nhân hơn sẽ coi tác vụ là một quy trình tương tác có trạng thái và bước kiểm tra rõ ràng:
LẬP KẾ HOẠCH: nêu lại các ràng buộc và liệt kê thông tin còn thiếu (ví dụ: “which airport preference?” / “is 1 stop ok?”).
HÀNH ĐỘNG: gọi chức năng tìm chuyến bay bằng truy vấn có cấu trúc (khoảng ngày, giới hạn giờ đến, ngân sách).
QUAN SÁT: lưu kết quả vào một đối tượng trạng thái cô đọng (5 lựa chọn hàng đầu kèm giá/giờ đến/số điểm dừng), thay vì dán vào một khối dữ liệu khổng lồ.
CẬP NHẬT: tinh chỉnh truy vấn nếu chưa đáp ứng ràng buộc (ví dụ: “arrival before 6pm is too strict—widen time window or raise budget?”).
XÁC MINH: chạy các trình xác thực (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
DỪNG: chỉ khi API đặt vé trả về xác nhận và mọi bước xác thực đều đạt yêu cầu.
Thay đổi này tuy tinh tế nhưng mang tính quyết định. Việc truy xuất diễn ra có điều kiện (không phải phản xạ), ngữ cảnh được quản lý (trạng thái có cấu trúc thay vì tích tụ) và việc xác minh nằm trong vòng lặp (không phó mặc cho người dùng). Thay “đặt vé máy bay” bằng “tạo đơn mua hàng”, “hoàn tiền”, “thay đổi cấu hình môi trường sản xuất” hoặc “phát hành một PR”, câu chuyện vẫn vậy: khi tác nhân có thể hành động, vòng lặp quan trọng hơn câu lệnh.
Khảo sát nêu trên chia suy luận tác nhân thành ba lớp: nền tảng (lập kế hoạch/sử dụng công cụ/tìm kiếm), tự phát triển (phản hồi + bộ nhớ) và tập thể (phối hợp đa tác nhân).
Nhưng ý tưởng sâu xa hơn là: suy luận trở thành nguyên tắc tổ chức cho việc lập kế hoạch, ra quyết định và xác minh, chứ không chỉ tạo ra một chuỗi tư duy có vẻ hợp lý. Điều đó nghe có vẻ trừu tượng cho đến khi bạn đối chiếu nó với những thay đổi trong kiến trúc của mình. Có ba điểm cốt lõi cần nhớ:
Một tác nhân tốt không nên coi truy xuất là việc “luôn phải làm”. Truy xuất là một quyết định, không phải phản xạ.
Đây là một nguyên tắc kinh nghiệm thực tế:
Nếu hệ thống truy xuất ở mọi lượt, bạn chưa xây dựng chức năng truy xuất mà chỉ tạo ra một khoản thuế ngữ cảnh.
Điều này xuất hiện liên tục trong công việc thực tế. Khi gỡ lỗi một sự cố trong môi trường sản xuất, bạn không đổ toàn bộ nhật ký vào ngữ cảnh; bạn quyết định sẽ lấy chỉ số/nhật ký nào tiếp theo dựa trên giả thuyết hiện tại. Đó là “truy xuất mang tính tác nhân”. Dưới đây là một quy trình cụ thể hơn:
Quyết định xem có cần truy xuất không
Nếu có: soạn truy vấn, tìm nạp, đọc lướt, trích xuất
Nếu bằng chứng mâu thuẫn: tìm nạp lại
Chỉ sau đó mới tổng hợp
Đây cũng là lúc “RAG mang tính tác nhân” bắt đầu khác với RAG truyền thống: truy xuất trở thành một bước suy luận có chủ đích, thay vì một giai đoạn mặc định trong quy trình.
Ngay khi bạn ngừng đánh giá “một mô hình” và bắt đầu đánh giá “một hệ thống”, việc theo dõi trạng thái và truy vết sẽ trở nên quan trọng.
Đến nay, ngành này đã chú trọng rõ ràng hơn đến khả năng quan sát quy trình làm việc của tác nhân. Ví dụ: Agents SDK của OpenAI tích hợp sẵn tính năng truy vết và bảng điều khiển Traces để ghi lại các lần chạy của tác nhân (nội dung được tạo, lệnh gọi công cụ, bàn giao, biện pháp bảo vệ, sự kiện tùy chỉnh), giúp bạn gỡ lỗi và kiểm tra từng bước đã diễn ra.
Đó không phải là tính năng “có thì tốt”. Nó tạo nên khác biệt giữa một hệ thống có thể gỡ lỗi và một hệ thống chỉ có thể đánh giá bằng cảm tính.
Theo tôi, phần dễ áp dụng nhất của khảo sát là cách nó đề cập thẳng thắn đến phản hồi. Khảo sát chia phản hồi thành ba cơ chế: phản hồi phản tư (tạo → phê bình → sửa đổi), thích nghi tham số (học qua tinh chỉnh/RL) và phản hồi dựa trên trình xác thực (thử lại cho đến khi vượt qua bước xác thực).
Hầu hết các nhóm nên bắt đầu với phản hồi dựa trên trình xác thực vì cách này tuy nhàm chán nhưng hiệu quả. Nếu có thể viết bất kỳ trình xác thực nào để kiểm thử đơn vị, kiểm tra lược đồ, áp dụng quy tắc/ràng buộc kinh doanh (“không hoàn tiền quá X nếu chưa chuyển cấp xử lý”) hoặc xác minh tính xác thực (“bắt buộc có trích dẫn”), bạn có thể biến đầu ra bất định của mô hình thành thứ thực sự đáng tin cậy.
Một thay đổi thuộc loại “điều ta không biết là mình chưa biết” ở đây rất đơn giản: trong thế giới tác nhân, độ tin cậy thường đến từ vòng lặp nhiều hơn là từ mô hình.
Đây là quy trình vòng lặp tối giản nhất mà tôi nhận thấy có thể cải thiện hành vi một cách ổn định mà không cần huấn luyện:
Thực hiện theo từng bước: Lập kế hoạch → Hành động → Quan sát → Cập nhật,
Sau mỗi bước Hành động, tóm tắt phần Quan sát trong 1–3 gạch đầu dòng,
Dừng khi đã đáp ứng tiêu chí thành công hoặc chạm giới hạn ngân sách; trả về kết quả tốt nhất hiện có cùng những điểm còn chưa chắc chắn.
Mục đích không phải là khiến mô hình dài dòng. Mục đích là làm cho hệ thống dễ hiểu và buộc nó phải “đối chiếu với thực tế” ở mỗi bước. Một ví dụ rất gần gũi với kỹ sư là quy trình khép kín có căn cứ theo kiểu CI:
Lập kế hoạch: đề xuất danh sách thay đổi
Hành động: chạy kiểm thử/lint
Quan sát: phân tích lỗi
Cập nhật: vá lỗi và thử lại
Một vài câu hỏi thường giúp phát hiện thiết kế tác nhân ngoài ý muốn:
“Tác nhân của tôi có tự chọn nội dung cần truy xuất không, hay tôi luôn thực hiện truy xuất?”
Nếu luôn truy xuất vô điều kiện, bạn sẽ phải trả giá bằng độ trễ, chi phí, ngữ cảnh bị loãng và nguy cơ “rác vào, rác ra” cao hơn.
“Tác nhân của tôi có nhận ra khi nó sai không?”
Nếu tín hiệu phản hồi duy nhất của tác nhân là “người dùng bực mình”, bạn đang thực hiện RL bằng sự khó chịu của con người. Vòng lặp thử lại dựa trên trình xác thực là cách gọn gàng nhất để giúp nó đối chiếu với thực tế.
“Bộ nhớ có thể ghi được không và có cải thiện theo thời gian không?”
Nếu “bộ nhớ” chỉ là việc nối thêm lịch sử trò chuyện, về cơ bản bạn chỉ đang ghi nhật ký. Cách khảo sát định nghĩa bộ nhớ rất quan trọng: bộ nhớ trở thành một ngữ cảnh phát triển linh hoạt mà các tác nhân tinh chỉnh theo thời gian, chứ không chỉ là bản ghi hội thoại.
Nhật ký cho biết điều gì đã xảy ra, còn bộ nhớ cho biết lần sau nên làm gì. Lịch sử trò chuyện là bản ghi hội thoại. Bộ nhớ là một chính sách không ngừng phát triển về những điều đáng lưu lại cho tương lai.
Một cách khởi đầu thực tế là tạo bảng “bài học kinh nghiệm” nhỏ, với khóa gồm loại tác vụ, công cụ và dạng lỗi; còn giá trị ghi lại điều hiệu quả và điều cần tránh. Mục tiêu không phải là xây dựng một đồ thị tri thức hoàn hảo. Mục tiêu là tạo ra hành vi cải thiện tích lũy: bộ nhớ kết hợp với phản hồi sẽ biến tác nhân từ “trợ lý không trạng thái” thành hệ thống ngày càng tốt hơn.
Ta thường muốn bổ sung thêm tác nhân để giải quyết vấn đề, nhưng cách này thường làm tăng gấp bội chi phí phối hợp. Một mô hình “nhóm khả dụng tối thiểu” hiệu quả:
Điều phối viên: phân rã + phân công
Bên thực thi: gọi công cụ/thực hiện thay đổi
Bên phản biện/đánh giá: kiểm tra tính đúng đắn/rủi ro
Bên quản lý bộ nhớ: ghi chép/chắt lọc bài học
Nếu không thể giải thích trách nhiệm của từng tác nhân, có lẽ bạn chưa cần nhiều tác nhân.
Nếu thực sự tin vào sự chuyển đổi mô hình này, có lẽ chúng ta sẽ ngừng nhồi mọi thứ vào câu lệnh, coi thất bại là đầu ra cuối cùng và đánh giá tác nhân như chatbot. Thay vào đó, chúng ta bắt đầu nhìn nhận đúng bản chất của tác nhân: những hệ thống phần mềm dùng ngôn ngữ làm mặt phẳng điều khiển—và độ tin cậy đến từ vòng lặp.
Trước khi thêm một mô hình nữa, hãy thêm một vòng lặp đánh giá. Trước khi truy xuất mọi thứ, hãy biến việc truy xuất thành có điều kiện. Hãy phát hành một trình xác thực trước khi phát hành mười trình. Hãy coi bộ nhớ là các quyết định chính sách, không phải cơ sở dữ liệu. Và khi chuyển sang đa tác nhân, hãy bắt đầu với hai tác nhân chứ không phải hai mươi. Đây không phải là quy tắc mà là những mô hình đã đứng vững trong môi trường sản xuất.