Từ một đơn hàng gấp, nhìn lại cách giao việc, chia sẻ dữ liệu và xử lý bất đồng để nhiều AI agent phối hợp đáng tin cậy.
Chiều thứ Sáu, một khách hàng nhắn cho nhà phân phối: “Tôi cần 40 bộ thiết bị giao trước sáng thứ Hai. Bên anh xác nhận giúp nhé.”
Hãy xem đây là một tình huống giả định. Doanh nghiệp đã có đội AI khá đầy đủ: một agent kiểm tra kho, một agent đối chiếu công nợ, một agent tìm chuyến xe và một agent chăm sóc khách hàng.
Agent kho trả lời: “Có 40 bộ.” Agent vận chuyển tìm được xe. Agent chăm sóc khách hàng lập tức soạn lời xác nhận. Nhưng agent công nợ đang đánh dấu đơn hàng cần người phụ trách xem xét. Chưa kể, 10 bộ trong kho đã được giữ cho một đơn khác.
Từng agent đều làm được một phần việc. Cả đội lại đứng trước nguy cơ đưa ra một lời hứa không thể thực hiện.
Vấn đề nằm ở khoảng trống giữa các phần việc: ai được quyền kết luận, dữ liệu nào là căn cứ và khi có bất đồng thì quy trình phải dừng ở đâu?
Một hệ thống đa agent — nhiều tác nhân AI có khả năng dùng công cụ và thực hiện nhiệm vụ — không tự trở thành một đội ngũ chỉ vì chúng cùng xuất hiện trong một ứng dụng. Giống một doanh nghiệp có nhiều phòng ban, nó cần kiến trúc phối hợp trước khi cần thêm nhân sự.
Đội AI cần chung một đích đến, nhưng không cần mọi thành viên có cùng nhiệm vụ hoặc cùng quyền hạn.
1. Đừng gọi cả đội khi chỉ cần đúng một người
Ở quầy tiếp nhận của một bệnh viện, người hướng dẫn không khám thay bác sĩ. Công việc của họ là hiểu người đến cần gì và đưa họ tới đúng nơi. Agent Router đóng vai trò tương tự: phân tích ý định rồi chuyển yêu cầu tới agent có năng lực phù hợp.
Với tin nhắn của khách hàng, hệ thống cần phân biệt “hỏi tình trạng đơn hàng” với “đặt đơn mới” và “xin thay đổi lịch giao”. Một từ khóa như “giao hàng” chưa đủ để xác định công việc.
Cách thiết kế rõ ràng hơn là chuyển lời nhắn thành thông tin có cấu trúc: hành động cần làm, đối tượng liên quan, số lượng, thời hạn và những dữ kiện còn thiếu. Sau đó, bộ định tuyến đối chiếu với danh mục năng lực đã đăng ký.
Nếu chưa biết khách hàng muốn tạo đơn hay chỉ hỏi khả năng đáp ứng, hệ thống hỏi lại. Nếu không có năng lực xử lý yêu cầu, nó chuyển người phụ trách thay vì tự dựng ra một agent “có vẻ làm được”.
Điểm cần tách bạch là năng lực không đồng nghĩa với quyền hạn. Một agent biết đọc dữ liệu kho không vì thế được phép sửa tồn kho. Việc kiểm tra quyền phải diễn ra ở lớp công cụ và dịch vụ, không chỉ trong lời nhắc dành cho mô hình.
Cùng nguyên tắc ấy, bài đưa AI agent vào GitHub mà không tự động hóa nhanh hơn năng lực kiểm soát mở rộng câu chuyện về quyền hạn hẹp và đường lui cho con người trong một môi trường thực thi khác.
Định tuyến tốt giúp tránh gọi sai người. Nhưng đơn hàng gấp vẫn cần nhiều chuyên môn. Khi ấy, câu hỏi tiếp theo là: ai giữ nhịp cho cả đội?
2. Chọn cách tổ chức theo công việc, không theo độ “ngầu” của công nghệ
Supervisor: một đầu mối điều phối
Trong mô hình Supervisor, một bộ điều phối nhận mục tiêu, chia việc, theo dõi trạng thái và tổng hợp kết quả từ các agent chuyên trách.
Quay lại đơn hàng 40 bộ thiết bị: bộ điều phối có thể yêu cầu kiểm tra lượng hàng khả dụng, điều kiện công nợ và phương án vận chuyển. Những việc độc lập được làm song song. Nhưng lời xác nhận cho khách chỉ được gửi khi các điều kiện bắt buộc đã hoàn tất.
Đây không phải “siêu agent” làm mọi thứ. Người trưởng ca không cần tự bốc hàng, lái xe và đối chiếu sổ sách. Nếu bộ điều phối ôm cả nghiệp vụ, hệ thống chỉ chuyển từ một ứng dụng khó bảo trì sang một agent khó bảo trì.
Mô hình tập trung có lợi thế về trách nhiệm và khả năng lần lại sự cố. Đổi lại, bộ điều phối có thể trở thành điểm nghẽn. Vì vậy, trạng thái cần được lưu sau các bước quan trọng để khi hệ thống gián đoạn, công việc có thể tiếp tục thay vì bắt đầu lại từ đầu.
Swarm: tự nhận việc theo trạng thái chung
Trong mô hình Swarm, các agent có thể theo dõi bảng công việc rồi nhận nhiệm vụ phù hợp. Agent nghiên cứu hoàn tất phần dữ liệu; agent phân tích thấy đầu vào đã sẵn sàng và tiếp tục; agent biên tập nhận bản thảo khi đến lượt.
Cách này hữu ích khi đường đi của công việc khó biết trước. Nhưng tự tổ chức không có nghĩa là không cần luật. Bảng công việc vẫn phải có trạng thái rõ ràng, cơ chế nhận việc tránh trùng lặp, thời hạn và cách kết thúc. Nếu bảng dùng chung là một dịch vụ duy nhất không có dự phòng, hệ thống vẫn có điểm lỗi tập trung dù không có một agent chỉ huy.
Với đơn hàng gấp, để các agent tự thương lượng toàn bộ quy trình có thể tạo thêm chi phí phối hợp mà chưa đem lại lợi ích tương xứng.
Hybrid: giữ khung chung, linh hoạt bên trong
Một cách dung hòa là giữ bộ điều phối cho các mốc nghiệp vụ bắt buộc, đồng thời cho một nhóm agent tự tìm phương án trong phạm vi được giao. Chẳng hạn, nhóm vận chuyển có thể tìm tuyến và so sánh nhà xe, nhưng không được tự bỏ qua điều kiện công nợ.
Phân tán không mặc nhiên tốt hơn tập trung. Cách tổ chức phù hợp là cách giải quyết được điểm nghẽn thực tế với mức phức tạp mà đội vận hành có thể quản lý.
Đừng chọn kiến trúc theo số lượng agent. Hãy chọn theo mức ổn định của quy trình và nơi cần quyền quyết định.
3. Kế hoạch chung và dữ liệu chung là hai việc khác nhau
Một đội có thể cùng đọc một hồ sơ mà vẫn không biết ai làm gì. Ngược lại, phân công rất rõ nhưng mỗi người đọc một bản dữ liệu khác nhau thì kết quả vẫn lệch.
Kế hoạch chung trả lời “làm gì, theo thứ tự nào”. Dữ liệu chung trả lời “chúng ta đang biết điều gì, từ đâu”.
Vẽ quan hệ phụ thuộc trước khi chạy song song
Trong đơn hàng giả định, việc kiểm tra công nợ có thể chạy cùng lúc với việc tìm chuyến xe. Nhưng giữ hàng phải dựa trên lượng hàng khả dụng, không phải lượng hàng hiện diện trong kho. Xác nhận giao hàng phải dựa trên kết quả tổng hợp, không phải kết quả đầu tiên trả về.
Mỗi nhiệm vụ nên có đầu vào, người hoặc agent phụ trách, đầu ra cần đạt, điều kiện hoàn thành và thời hạn. Đầu ra như “mọi thứ ổn” không đủ để bước sau xử lý. Thông tin cần cụ thể hơn: số lượng khả dụng, tình trạng kiểm tra, nguồn dữ liệu, thời điểm cập nhật và lý do chưa thể tiếp tục.
Chạy song song giúp rút ngắn những phần việc độc lập. Nó không xóa được quan hệ phụ thuộc giữa các bước.
Dùng “bảng trắng” khi lời giải phải hình thành dần
Blackboard là một không gian chung để các agent đóng góp dữ kiện và giả thuyết. Nó giống bảng trắng trong phòng điều hành: bên kho cập nhật số hàng chưa giữ chỗ; bên vận chuyển cập nhật chuyến xe; người phụ trách bổ sung điều kiện chấp thuận ngoại lệ.
Điều quan trọng không phải “đổ tất cả vào một chỗ”, mà là phân biệt dữ kiện đã kiểm chứng, giả thuyết và quyết định đã được duyệt. Mỗi đóng góp cần nguồn, phiên bản và trạng thái. Dữ liệu hết hạn phải được đánh dấu; hai agent cùng cập nhật một đơn hàng phải có cơ chế kiểm soát xung đột.
Blackboard phù hợp khi thông tin đến dần và cần kết hợp nhiều góc nhìn. Với một yêu cầu đơn giản như tra trạng thái giao hàng, một lệnh gọi công cụ có thể đã đủ; không cần dựng cả phòng điều hành.
Kho tri thức dài hạn lại có vai trò khác. Nó giữ những kinh nghiệm có thể tái sử dụng giữa nhiều lần xử lý, chẳng hạn cách nhận diện một lỗi tích hợp từng được xác minh. Lưu thêm tri thức không đồng nghĩa mô hình tự được huấn luyện lại, và chia sẻ dữ liệu cũng không có nghĩa mọi agent được xem toàn bộ thông tin khách hàng.
4. Khi agent bất đồng, hãy xác định chúng bất đồng về điều gì
Nói “cho các agent tranh luận để tìm câu trả lời tốt nhất” nghe hấp dẫn, nhưng chưa phải một quy tắc vận hành.
Trong tình huống đơn hàng, có ít nhất ba loại bất đồng cần xử lý khác nhau.
Bất đồng về dữ kiện: agent kho thấy 40 bộ, agent xử lý đơn thấy chỉ 30 bộ chưa giữ chỗ. Cần kiểm tra định nghĩa và nguồn dữ liệu. Không nên lấy trung bình thành 35 bộ. Đồng thuận ở đây là thống nhất cách hiểu lượng hàng khả dụng, không phải bỏ phiếu xem con số nào được nhiều agent thích hơn. Nhiều agent cùng lặp lại một nguồn sai vẫn có thể đồng ý với nhau.
Bất đồng về ưu tiên: một agent muốn dành chuyến xe cho đơn gấp, agent khác muốn dùng xe đó cho chuyến đã lên lịch. Đây là bài toán phân bổ nguồn lực hoặc thương lượng: có thể đổi giờ, đổi xe hay chia chuyến trong giới hạn cho phép không? Nếu dùng ưu tiên, cần tránh để công việc ít khẩn cấp bị chờ mãi.
Bất đồng về hành động: agent chăm sóc khách hàng muốn xác nhận ngay, trong khi trạng thái công nợ yêu cầu xem xét. Đây là xung đột cần giải quyết bằng chính sách. Trong ví dụ này, doanh nghiệp quy định phải có chấp thuận trước khi xác nhận đơn. Không agent nào được thương lượng để xóa điều kiện ấy.
Một giao thức xử lý bất đồng cần trả lời bốn câu hỏi:
Căn cứ nào được dùng để kiểm tra lại?
Ai có quyền quyết định nếu chưa thống nhất?
Sau bao nhiêu vòng hoặc bao lâu thì phải dừng?
Khi chuyển cho con người, cần bàn giao những dữ kiện nào?
Nhật ký nên lưu các phương án, bằng chứng, chính sách áp dụng và lý do quyết định ở mức có thể kiểm tra. Một bản giải thích ngắn, gắn với dữ liệu cụ thể, hữu ích hơn một chuỗi hội thoại dài nhưng không cho biết điều gì đã được xác minh.
Kết quả nhanh nhất chưa chắc là kết quả đủ điều kiện để hành động. Điểm kiểm soát phải nằm trước lời hứa với khách hàng.
5. Đừng để một lỗi nhỏ kéo cả đội xuống
Giả sử công cụ tra chuyến xe không phản hồi. Nếu không có thời hạn chờ, bộ điều phối có thể đứng yên. Nếu thử lại liên tục, chi phí tăng mà công việc vẫn chưa tiến triển.
Supervision Tree — cây giám sát — giúp tách trách nhiệm phục hồi theo từng nhánh. Nhánh vận chuyển gặp lỗi thì nhánh đó được xử lý; không nhất thiết phải khởi động lại phần kiểm tra kho đã hoàn tất. Cần giới hạn số lần thử, giãn khoảng cách thử lại và chuyển sang phương án dự phòng hoặc người phụ trách khi vượt ngưỡng.
Tuy nhiên, khởi động lại agent không tự làm cho hành động trước đó an toàn. Nếu dịch vụ đã giữ hàng nhưng phản hồi bị mất, gọi lại có thể giữ thêm lần nữa. Những thao tác làm thay đổi trạng thái cần mã yêu cầu để chống thực thi trùng, cùng cách kiểm tra kết quả trước khi thử lại.
Tool Routing bổ sung một ranh giới khác: mỗi agent chỉ được dùng công cụ cần thiết cho vai trò của mình. Agent tra lịch vận chuyển không cần quyền sửa công nợ. Agent soạn phản hồi không nhất thiết có quyền gửi phản hồi. Tách bước “đề xuất” khỏi bước “thực thi” giúp đặt điểm kiểm soát đúng nơi có tác động thật.
Để đi từ quy định viết trong lời nhắc tới cơ chế kiểm soát thực thi, có thể đọc thêm từ hướng dẫn đến “lan can”: kiểm soát AI Agent bằng Hooks.
Khi có nhiều agent cùng đủ khả năng làm một việc, Contract-Net có thể hỗ trợ lựa chọn qua đề xuất về chi phí, thời gian và năng lực. Nhưng với nhiệm vụ cố định và đơn giản, việc tổ chức “đấu thầu” có thể tốn công hơn việc định tuyến trực tiếp. Điểm tự tin do agent tự báo cũng cần đối chiếu với kết quả thực tế, không nên xem là bảo chứng.
Nếu hệ thống mở rộng sang đội robot hay drone, việc phối hợp còn bao gồm duy trì vị trí và khoảng cách — Formation Control. Đây là bài toán điều khiển cần kiểm thử riêng, không phải chỉ cho chatbot trao đổi thêm với nhau. Kiến trúc nên bổ sung mẫu phối hợp khi xuất hiện nhu cầu tương ứng, không phải vì muốn sưu tập đủ tên gọi.
6. Bắt đầu nhỏ, đo ở cấp quy trình
Trước khi bổ sung agent mới, hãy thử viết trên một trang giấy: mục tiêu đầu cuối là gì, những bước nào bắt buộc, dữ liệu nào có thẩm quyền và ai xử lý ngoại lệ. Đây cũng là lý do nên chốt mục tiêu, phạm vi và người quyết định trước khi bắt đầu dự án AI.
Với một thử nghiệm như đơn hàng gấp, có thể bắt đầu bằng một bộ điều phối, một vài agent chuyên trách và một kho trạng thái rõ ràng. Những bước cố định như đối chiếu mã hàng hoặc tính lượng khả dụng vẫn có thể dùng hàm và dịch vụ thông thường; không phải mỗi ô trong lưu đồ đều cần một LLM.
Sau đó, kiểm thử cả đường thuận lợi lẫn các tình huống gây ma sát: dữ liệu kho đã cũ, hai yêu cầu cùng giữ hàng, công cụ phản hồi chậm, kết quả công nợ chưa đủ, bộ điều phối dừng giữa chừng và một hành động đã thành công nhưng mất phản hồi.
Đừng chỉ đo agent trả lời có hay không. Hãy đo ở cấp toàn quy trình:
Đơn hàng được xử lý đúng điều kiện hay chưa?
Thời gian đầu cuối và thời gian chờ giữa các bước là bao lâu?
Có hành động trùng, sai quyền hoặc phải sửa lại không?
Chi phí cho mỗi đơn hoàn tất là bao nhiêu?
Bao nhiêu trường hợp cần con người, và hồ sơ bàn giao có đủ để họ quyết định không?
So sánh với phương án đơn giản hơn — một agent dùng công cụ hoặc một quy trình tự động cố định. Chỉ thêm cơ chế phối hợp khi chất lượng, thời gian hoặc khả năng phục hồi thực sự cải thiện so với phần phức tạp mới tạo ra.
Quay lại chiều thứ Sáu. Kết quả tốt không nhất thiết là một câu “đã xác nhận” gửi trong vài giây. Nó có thể là lời phản hồi rõ ràng: hiện chỉ có 30 bộ khả dụng; phần còn lại cần phương án bổ sung; điều kiện công nợ đang chờ người phụ trách; doanh nghiệp sẽ xác nhận khi đủ căn cứ.
Một lời hứa chậm hơn nhưng có thể thực hiện thường có giá trị hơn một lời hứa nhanh mà bộ phận vận hành phải chạy theo sửa chữa.
Đội AI đáng tin cậy không phải đội có nhiều thành viên nhất. Đó là đội biết giao việc đúng, chia sẻ đúng dữ kiện và dừng đúng lúc.
Trong quy trình của doanh nghiệp bạn, điểm dễ đứt nhịp nhất đang nằm ở đâu: giao việc, bàn giao dữ liệu hay quyền quyết định khi có bất đồng?
Ở doanh nghiệp bạn, agent thường mất nhịp tại điểm nào: dữ liệu không cùng phiên bản, bàn giao nhiệm vụ hay quyền quyết định khi bất đồng? Nếu chỉ được sửa một điểm trong quy trình hiện tại, bạn sẽ chọn điểm nào — và dùng chỉ số gì để biết việc phối hợp đã tốt hơn?