Điều phối tác nhân AI: Lỗi, phê duyệt và thử lại

Việc có nhiều tác nhân cùng làm việc trên một dự án nghe có vẻ cực kỳ hiệu quả. Một tác nhân lên kế hoạch công việc, một tác nhân khác đảm nhận thiết kế và tác nhân thứ ba viết mã. Mọi thứ đều ổn cho đến khi gặp trục trặc. Và lỗi xảy ra thường xuyên hơn bạn mong muốn.

Để ngăn chặn những lỗi này, cần thiết kế quy trình làm việc một cách cẩn thận. Vì vậy, hãy cùng phân tích điều gì khiến các quy trình làm việc được điều phối trở nên thiếu tin cậy và khám phá các phương pháp hay nhất về điều phối để đảm bảo độ tin cậy trong môi trường vận hành thực tế.

Điều phối tác nhân AI phối hợp nhiều tác nhân AI, mô hình và công cụ để hoàn thành một nhiệm vụ gồm nhiều bước. Nhưng vẫn cần có ai đó — hoặc thứ gì đó — quyết định tác nhân nào chạy trước, tác nhân đó nhận được thông tin gì và điều gì xảy ra sau khi tác nhân hoàn thành. Đây là vai trò của bộ điều phối — một tác nhân AI đóng vai trò người quản lý hoặc một lớp thực thi được điều khiển bằng phần mềm.

Nói một cách đơn giản, một lớp điều phối chia nhỏ một mục tiêu thành các nhiệm vụ nhỏ hơn, theo dõi các phụ thuộc, ủy thác việc thực thi cho đúng tác nhân, quản lý ngữ cảnh dùng chung và tổng hợp các kết quả đầu ra.

Sơ đồ bộ máy thực thi điều phối: mục tiêu và kế hoạch, định tuyến đến các tác nhân, thực thi công cụ trong môi trường biệt lập, kết quả có cấu trúc, trạng thái quy trình làm việc được lưu trữ lâu dài và bước xác thực và quyết định để thử lại, quay lại, tạm dừng, chờ hoặc chuyển sang nhiệm vụ tiếp theo.

Hãy cùng xem điều gì xảy ra sau khi bạn giao một nhiệm vụ cho bộ điều phối.

Hãy xem xét một ví dụ từ hội thảo Computer của Perplexity: xây dựng bảng điều khiển thông tin khách hàng bằng dữ liệu từ Salesforce, Snowflake, email, lịch và tin tức gần đây.

Hiểu mục tiêu và lên kế hoạch công việc. Bộ điều phối bắt đầu từ kết quả được yêu cầu và phân tách thành các nhiệm vụ với các phụ thuộc rõ ràng. Trong ví dụ về bảng điều khiển của chúng ta, việc này bao gồm thu thập thông tin từ các nguồn khác nhau và biến thông tin đó thành một sản phẩm hoàn chỉnh. Bộ lập kế hoạch xác định những bước nào phụ thuộc vào các bước khác và những bước nào có thể chạy độc lập.
Định tuyến nhiệm vụ đến các tác nhân phù hợp. Bộ điều phối xác định các nhiệm vụ đã được đáp ứng phụ thuộc và ủy thác công việc cho các tác nhân hoặc mô hình chuyên biệt. Các nhiệm vụ phụ thuộc sẽ chờ các điều kiện tiên quyết của chúng. Perplexity Computer sử dụng nhiều mô hình tiên tiến hàng đầu, định tuyến các phần khác nhau của quy trình làm việc đến những hệ thống phù hợp với từng nhiệm vụ đó. Điều này cũng cho phép các công việc độc lập chạy song song.
Thực thi lệnh gọi công cụ trong môi trường được kiểm soát. Các tác nhân tương tác với môi trường thông qua công cụ, chẳng hạn như tìm kiếm trên web, API, ứng dụng được kết nối, thao tác với tệp hoặc thực thi mã. Lớp thực thi chạy các hành động này và trả kết quả về cho các tác nhân.
Chuyển kết quả và ngữ cảnh giữa các tác nhân. Khi một tác nhân hoàn thành nhiệm vụ, tác nhân tiếp theo ở hạ nguồn cần kết quả đầu ra liên quan để tiếp tục. Một bản ghi bàn giao có thể chứa ID nhiệm vụ, tham chiếu đầu ra, phiên bản lược đồ và siêu dữ liệu nguồn. Bộ điều phối phối hợp các lần bàn giao này đồng thời duy trì ngữ cảnh cần thiết cho các bước tiếp theo. Điều quan trọng là các tác nhân không phải mang theo toàn bộ lịch sử công việc của mọi tác nhân khác trong cửa sổ ngữ cảnh của riêng mình.
Ghi lại trạng thái thực thi tách biệt với ngữ cảnh của tác nhân. Khi các tác nhân bắt đầu, hoàn thành hoặc thất bại ở các nhiệm vụ, bộ máy thực thi sẽ cập nhật một bản ghi quy trình làm việc được lưu trữ lâu dài với trạng thái nhiệm vụ, các lần thử thực thi, tham chiếu đầu ra và công việc còn lại. Bản ghi này cho phép bộ điều phối theo dõi tiến độ và tiếp tục sau khi bị gián đoạn mà không cần dựa vào LLM để tái dựng quy trình làm việc từ lịch sử hội thoại.
Xác thực kết quả và quyết định bước tiếp theo. Khi một nhiệm vụ trả về, lớp điều phối sẽ kiểm tra xem kết quả đầu ra có đáp ứng đặc tả dự kiến hay không và các phụ thuộc của nhiệm vụ tiếp theo đã được đáp ứng hay chưa. Nếu phát hiện vấn đề, quy trình làm việc có thể quay lại một bước trước đó để khắc phục hoặc bị tạm dừng. Nếu không, quy trình sẽ tiếp tục tiến tới hoàn tất.

Đằng sau thứ có vẻ chỉ là điều phối tác nhân AI đơn giản là rất nhiều thành phần vận hành. Cách bạn tổ chức sự phối hợp giữa các tác nhân quyết định mức độ kiểm soát của bạn đối với quá trình thực thi. Và tất nhiên, tất cả sự phối hợp đó đều làm tăng chi phí vận hành. Vì vậy, không phải lúc nào cũng đáng.

Hãy cân nhắc điều phối đa tác nhân khi các phần khác nhau của nhiệm vụ cần chuyên môn riêng biệt, các công việc độc lập có thể chạy song song hoặc bạn không thể xác định trước bước tiếp theo.

Do đó, điều phối hữu ích trong ba trường hợp:

Các nhiệm vụ đòi hỏi những chuyên môn khác nhau. Ví dụ: một dự án lập trình có thể được hưởng lợi từ các tác nhân riêng biệt cho việc lập kế hoạch, thiết kế, phát triển và đánh giá.
Các nhiệm vụ độc lập có thể chạy song song. Thay vì để một tác nhân hoàn thành mọi thứ theo tuần tự, nhiều tác nhân có thể làm việc đồng thời và trả kết quả về cho bộ điều phối.
Vấn đề có tính mở. Các tác nhân có thể cần khám phá các cách tiếp cận khác nhau, đưa ra quyết định và cộng tác thay vì tuân theo một trình tự định sẵn.

Ngoài những trường hợp đó, điều phối chỉ là một xu hướng tốn kém. Nhiều tác nhân hơn cũng đồng nghĩa với nhiều công việc phối hợp hơn và chi phí token có thể cao hơn.

“Tôi thường bắt đầu với phương án đơn giản nhất rồi phát triển dần từ đó. Nếu chúng tôi biết các bước và chúng có thể lặp lại, thì đó có lẽ là một quy trình làm việc. Tôi chỉ thấy lý do để đưa nhiều tác nhân vào khi chúng có trách nhiệm, quyền hạn hoặc người dùng khác nhau,” Josh Spilker, trưởng bộ phận marketing tìm kiếm tại AirOps, cho biết.

Ngay cả khi đó, hãy cân nhắc lợi ích so với các lệnh gọi mô hình, lần bàn giao, độ trễ và điểm lỗi phát sinh thêm.

Có ba cách phổ biến để cấu trúc sự phối hợp giữa các tác nhân: điều phối tập trung, phi tập trung và phân cấp. Việc chọn đúng kiến trúc quy về một câu hỏi: Ai kiểm soát công việc và các tác nhân phối hợp với nhau như thế nào?

Trong điều phối tập trung, một bộ điều phối duy nhất quản lý quy trình. Bộ điều phối chia nhỏ nhiệm vụ, ủy thác công việc cho các tác nhân chuyên biệt, theo dõi tiến độ của chúng và tổng hợp kết quả.

Sơ đồ điều phối tập trung: một bộ điều phối nhận yêu cầu của người dùng và ủy thác cho các tác nhân nghiên cứu, phân tích và thiết kế, mỗi tác nhân sử dụng công cụ riêng, và kết quả của chúng được kết hợp thành một bảng điều khiển cuối cùng.

Sự đánh đổi: Phối hợp tập trung giúp dễ dàng theo dõi quá trình thực thi và áp dụng các quy tắc chung tại một điểm kiểm soát duy nhất. Tuy nhiên, bộ điều phối có thể trở thành điểm nghẽn và lỗi của nó có thể làm gián đoạn toàn bộ quy trình làm việc trừ khi hệ thống hỗ trợ khôi phục.

Trong điều phối phi tập trung, các tác nhân phối hợp trực tiếp hơn với nhau thay vì dựa vào một người quản lý để đưa ra mọi quyết định. Các tác nhân có thể trao đổi thông điệp, đọc trạng thái dùng chung và tự xác định các bước tiếp theo của mình.

Sơ đồ điều phối phi tập trung: các tác nhân nghiên cứu, phân tích, thiết kế và đánh giá giao tiếp trực tiếp với nhau cũng như với trạng thái và công cụ dùng chung để tạo ra một bảng điều khiển cuối cùng.

Sự đánh đổi: Các tác nhân có thể hoạt động mà không cần chờ bộ lập kế hoạch trung tâm, giúp cách tiếp cận này hữu ích cho công việc khám phá và các đóng góp độc lập. Nhưng việc phối hợp trở nên khó khăn hơn khi các tác nhân bất đồng, cập nhật thông tin dùng chung hoặc cần đạt được một kết quả nhất quán.

Điều phối phân cấp mở rộng cách tiếp cận dựa trên người quản lý ra nhiều cấp. Một bộ điều phối cấp cao nhất ủy thác trách nhiệm cho các bộ điều phối cấp dưới, và các bộ điều phối này phối hợp các nhóm tác nhân chuyên biệt của riêng mình.

Hãy hình dung một quy trình làm việc của doanh nghiệp có sự tham gia của các nhóm bán hàng, tài chính và pháp lý. Một bộ điều phối cấp cao nhất có thể ủy thác từng luồng công việc cho một bộ phối hợp chuyên trách theo lĩnh vực. Sau đó, các bộ phối hợp này sẽ quản lý các tác nhân chuyên biệt của riêng mình và báo cáo kết quả tổng hợp.

Cấu trúc này có thể hữu ích khi quy trình làm việc quá rộng để một bộ điều phối duy nhất có thể quản lý hiệu quả.

Sơ đồ điều phối phân cấp: một bộ điều phối cấp cao nhất ủy thác cho các bộ điều phối bán hàng, tài chính và pháp lý, mỗi bộ điều phối quản lý hai tác nhân chuyên biệt, và công việc của chúng được kết hợp thành một kết quả đầu ra tổng hợp.

Sự đánh đổi: Cấu trúc phân cấp cho phép các nhóm phân chia trách nhiệm phối hợp và có thể xử lý lỗi trong từng nhánh riêng lẻ. Tuy nhiên, cấu trúc này tạo thêm các lần bàn giao, khiến việc quản lý trạng thái phức tạp hơn và làm tăng chi phí vận hành. Khả năng khôi phục cục bộ cũng phụ thuộc vào cách triển khai điểm kiểm tra và trạng thái thực thi.

So sánh các kiến trúc này:

Tiêu chí	Tập trung	Phi tập trung	Phân cấp
Quyền sở hữu việc thực thi	Một bộ điều phối kiểm soát việc ủy thác	Các tác nhân phối hợp thông qua tác nhân ngang hàng hoặc trạng thái dùng chung	Trách nhiệm được phân bổ trên các cấp điều phối
Tính nhất quán của trạng thái	Dễ phối hợp hơn thông qua một điểm kiểm soát	Đòi hỏi đồng bộ hóa và xử lý xung đột rõ ràng	Đòi hỏi phối hợp trong và giữa các nhánh
Cô lập lỗi	Bộ điều khiển trung tâm có thể trở thành một phụ thuộc quan trọng	Từng tác nhân có thể gặp lỗi độc lập, nhưng cơ sở hạ tầng dùng chung vẫn đóng vai trò then chốt	Lỗi có thể được khoanh vùng trong từng nhánh nếu được thiết kế để khôi phục
Thực thi chính sách	Các biện pháp kiểm soát chung có thể được áp dụng tập trung	Chính sách phải được thực thi nhất quán giữa các bên tham gia	Các biện pháp kiểm soát có thể được áp dụng ở cấp toàn cục và cấp miền
Độ phức tạp vận hành	Thường thấp hơn	Độ phức tạp điều phối cao hơn	Độ phức tạp cao hơn do có nhiều lớp điều phối

Còn một điểm khác biệt nữa đáng để tìm hiểu. Kiến trúc quyết định ai điều phối các tác nhân. Mẫu thực thi quyết định các tác vụ của chúng tiến triển như thế nào.

Dưới đây là ba mẫu thực thi:

Quy trình làm việc tuần tự: Các tác nhân làm việc theo thứ tự định sẵn, kết quả của tác nhân này trở thành đầu vào của tác nhân khác.
Thực thi song song: Các tác nhân độc lập làm việc đồng thời.
Thực thi dựa trên chuyển giao: Quyền điều khiển được chuyển giữa các tác nhân chuyên biệt khi tác vụ tiến triển. Cách này hữu ích khi một tác nhân khác có năng lực tốt hơn để xử lý bước tiếp theo, tuy nhiên mỗi lần chuyển giao đều phải giữ lại thông tin cần thiết để tiếp tục.

Các mẫu này không loại trừ lẫn nhau và cũng không tương ứng một-một với các kiến trúc điều phối. Mục tiêu là chọn cấu trúc đơn giản nhất đáp ứng được các phụ thuộc, yêu cầu điều phối và chi phí vận hành chấp nhận được của quy trình làm việc.

Bất cứ điều gì cũng có thể trục trặc khi điều phối, từ những sơ suất đơn giản đến các trở ngại phức tạp. Đôi khi, một tác nhân thậm chí có vẻ làm đúng việc của mình trong khi toàn bộ quy trình làm việc lại thất bại. Dựa trên kinh nghiệm của những người làm thực tế, chúng tôi đã tổng hợp một số sai lầm phổ biến khiến các quy trình làm việc được điều phối trở nên thiếu tin cậy — hãy lưu ý đến chúng:

Chuyển giao giữa các tác nhân bị mất thông tin. Trình điều phối chuyển một kế hoạch tóm tắt cho tác nhân chuyên biệt, nhưng bản tóm tắt lại bỏ sót các ràng buộc, phụ thuộc hoặc chi tiết triển khai.
Gộp kết quả (fan-in) quá sớm. Một tác nhân hạ nguồn bắt đầu tổng hợp kết quả trước khi tất cả các tác vụ thượng nguồn hoàn tất.
Cập nhật trạng thái dùng chung không tất định. Các tác nhân song song ghi vào cùng các khóa trạng thái mà không có ngữ nghĩa hợp nhất được xác định rõ ràng. Tùy vào cách framework xử lý cập nhật, điều này có thể dẫn đến mất dữ liệu ghi, dữ liệu trùng lặp, đầu ra phụ thuộc vào thứ tự hoặc các thay đổi xung đột.
Sai lệch giữa điểm kiểm tra và tác dụng phụ. Một tác vụ thực hiện thao tác bên ngoài, nhưng việc thực thi thành công của nó chưa được ghi lại bền vững trước khi worker gặp sự cố. Khi khôi phục, trình điều phối thấy một tác vụ chưa hoàn tất và chạy lại tác vụ đó.
Tranh chấp khi tiếp tục sau bước phê duyệt của con người. Việc tạm dừng và tiếp tục thực thi phát sinh những vấn đề đồng bộ hóa riêng.
Vòng lặp ủy quyền và khuếch đại thử lại. Các tác nhân liên tục chuyển công việc cho nhau vì trách nhiệm của chúng chồng chéo, các phụ thuộc tạo thành vòng tròn hoặc điều kiện hoàn thành không rõ ràng.
Nhầm lẫn các biện pháp kiểm soát ở cấp chỉ dẫn với bảo mật thực thi. Trình điều phối có thể yêu cầu các tác nhân không truy cập một số tài nguyên nhất định hoặc không thực hiện các hành động nhạy cảm, nhưng chỉ dẫn cho mô hình không thể thực thi quyền của hệ điều hành, các hạn chế mạng hay ranh giới ủy quyền. Nghiên cứu kỹ thuật bảo mật của Perplexity chỉ ra lý do vì sao các tác nhân có thể vượt qua ranh giới bảo mật khi theo đuổi các mục tiêu chính đáng, ngay cả khi không có chỉ dẫn độc hại

Hãy để ý xem các lỗi này khác nhau đến mức nào. Một lần chuyển trạng thái quá sớm của bộ lập lịch hay một thao tác ghi bên ngoài không rõ ràng đều có thể dẫn đến kết quả sai, nhưng chúng bắt nguồn từ những phần khác nhau trong vòng đời thực thi. Đó là lý do vì sao điều phối đáng tin cậy đòi hỏi nhiều hơn việc cải thiện prompt hay thêm cơ chế thử lại.

Mục tiêu mơ hồ và định nghĩa hoàn thành không rõ ràng thường dẫn đến những kết quả đáng thất vọng do tác nhân tạo ra. Giải pháp là một hợp đồng prompt (phạm vi công việc dành cho tác nhân): thống nhất về mục tiêu, ràng buộc, định dạng đầu ra và điều kiện thất bại trước khi bắt đầu thực thi.

Ví dụ, đây là cách bạn có thể xác định hợp đồng cho một tác nhân chịu trách nhiệm sửa một bài kiểm thử tích hợp thỉnh thoảng lại thất bại:

Mục tiêu: Xác định và khắc phục nguyên nhân khiến bài kiểm thử tích hợp API checkout hoạt động chập chờn.
Đầu vào: Mã nguồn kiểm thử, nhật ký lỗi CI, các commit gần đây và mã ứng dụng liên quan.
Ràng buộc: Không vô hiệu hóa kiểm thử, không nới lỏng các assertion và không sửa đổi hành vi không liên quan của ứng dụng.
Đầu ra mong đợi: Một bản vá mã, phần giải thích nguyên nhân gốc rễ và kết quả chạy kiểm thử.
Tiêu chí chấp nhận: Bài kiểm thử trước đây thất bại nay vượt qua trong 10 lần chạy liên tiếp và bộ kiểm thử hồi quy liên quan đều đạt.
Điều kiện thất bại: Không xác định được nguyên nhân gốc rễ, bản sửa lỗi gây ra lỗi hồi quy hoặc môi trường kiểm thử cần thiết không khả dụng.

Nhưng còn một phần quan trọng khác: khi nào tác nhân nên dừng lại?

Tác nhân không nên lặp đi lặp lại vô thời hạn chỉ vì chưa tạo ra được kết quả thỏa đáng. Hãy xác định thế nào là hoàn thành thành công, khi nào nên trả về một tác vụ đã hoàn thành một phần và khi nào nên dừng lại vì không thể đáp ứng một yêu cầu. Hãy đặt độ sâu ủy quyền tối đa và giới hạn số lần lặp hoặc ngân sách thực thi để các tác vụ chưa được giải quyết không trở thành vòng lặp vô tận.

Quay lại ví dụ CI của chúng ta. Bạn có thể xác định các điều kiện dừng sau:

Thành công: Bản sửa lỗi vượt qua 10 lần chạy kiểm thử liên tiếp và bộ kiểm thử hồi quy liên quan.
Giới hạn số lần lặp: Tác nhân chỉ được thử tối đa hai bản sửa lỗi đề xuất.
Ngân sách thực thi: Tác nhân phải dừng sau 60 phút, ngay cả khi vấn đề vẫn chưa được giải quyết.
Giới hạn ủy quyền: Tác nhân có thể ủy quyền công việc cho một tác nhân chuyên biệt và không được ủy quyền tiếp cho tác nhân con nào khác.
Hoàn thành một phần: Nếu cả hai lần thử đều thất bại hoặc hết thời gian cho phép, tác nhân sẽ trả về các phát hiện, những thay đổi đã thử và kết quả kiểm thử.
Thực thi bị chặn: Nếu môi trường kiểm thử không khả dụng, tác nhân sẽ dừng và báo cáo trở ngại thay vì tuyên bố thành công.

Đôi khi các nhà phát triển giao cho trình điều phối quá nhiều trách nhiệm, và thay vì điều phối các tác nhân chuyên biệt, nó bắt đầu tự viết mã, gỡ lỗi hoặc thực hiện các đánh giá chi tiết. Điều này tạo ra nút thắt cổ chai: trình điều phối tiêu tốn ngân sách ngữ cảnh vào chi tiết triển khai, trì hoãn việc ủy quyền và làm mờ trách nhiệm đối với kết quả.

Vì vậy, hãy để trình điều phối làm đúng việc của mình và áp dụng cơ chế chuyển giao bằng cách tham chiếu đến các tạo phẩm cụ thể: tác vụ ban đầu, đầu vào liên quan, tạo phẩm đầu ra, trạng thái thực thi và mọi vấn đề chưa được giải quyết.

Hãy xem ví dụ sau: status: completed đề cập đến công việc được giao cho tác nhân, không phải toàn bộ quy trình làm việc. Vì các bài kiểm thử vẫn đang ở trạng thái pending, trình điều phối không nên phê duyệt kết quả cuối cùng.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Lịch sử hội thoại của tác nhân không phải là bản ghi đáng tin cậy về tiến độ của quy trình làm việc. Khi cửa sổ ngữ cảnh đầy, cơ chế nén tự động có thể làm mất các chi tiết quan trọng. Và nếu một worker gặp sự cố, tác nhân tiếp theo cần biết những bước nào thực sự đã hoàn tất.

Ví dụ, nếu tác nhân lập trình tạo ra một bản vá rồi gặp sự cố, worker tiếp theo nên truy xuất tạo phẩm đã lưu và tiếp tục từ trạng thái quy trình làm việc đã ghi nhận. Nhưng nếu tác nhân đó cũng đã kích hoạt một lần chạy CI bên ngoài, trình điều phối phải đối chiếu riêng lần chạy đó trước khi lặp lại hành động

Vì vậy, hãy tách trạng thái thực thi khỏi ngữ cảnh làm việc của tác nhân. Lưu trạng thái tác vụ, các lần thử thực thi, các bước đã hoàn thành và tham chiếu tạo phẩm vào bộ lưu trữ bền vững. Đồng thời, chỉ nạp các chỉ dẫn, đầu vào và kết quả liên quan đến tác vụ hiện tại của tác nhân thay vì nhồi toàn bộ lịch sử thực thi vào cửa sổ ngữ cảnh của nó.

Giả sử tác nhân CI của bạn kích hoạt một lần chạy kiểm thử, nhưng yêu cầu API bị hết thời gian chờ. Lần chạy kiểm thử đã không khởi động được, hay dịch vụ CI đã đưa nó vào hàng đợi rồi làm mất phản hồi?

Hết thời gian chờ không nhất thiết có nghĩa là thao tác đã thất bại. Vì vậy, bạn cần phân biệt các loại lỗi trước khi quyết định bước tiếp theo:

Lỗi tạm thời (429, 503): Thử lại với cơ chế backoff lũy thừa có giới hạn và jitter, tuân thủ Retry-After khi có.
Lỗi kiểm tra hợp lệ hoặc lỗi quyền (400, 403): Dừng lại hoặc khắc phục vấn đề gốc thay vì lặp lại cùng một yêu cầu.
Kết quả không rõ ràng (hết thời gian chờ sau một thao tác ghi có thể đã diễn ra): Kiểm tra xem thao tác đã thành công hay chưa trước khi thử lại.

Lưu ý: Ngay cả các lỗi có thể thử lại cũng cần có giới hạn. Đặt thời gian chờ cho mỗi lệnh gọi công cụ, giới hạn số lần thử lại và tổng thời gian thử lại, đồng thời áp dụng hạn chót chung cho toàn bộ quy trình làm việc để các tác nhân lồng nhau không thể liên tục khởi động lại cùng một thao tác. Nếu một phụ thuộc liên tục thất bại, hãy dùng circuit breaker để tạm thời ngừng gửi yêu cầu.

Với các thao tác có tác dụng phụ bên ngoài, hãy gán một khóa idempotency ổn định cho mỗi hành động logic và tái sử dụng khóa đó qua các lần thử lại. Nếu API hỗ trợ khử trùng lặp phía máy chủ, nó có thể nhận ra các yêu cầu lặp lại mà không thực hiện hành động hai lần. Nếu không, hãy truy vấn hệ thống bên ngoài bằng ID tương quan (correlation ID) hoặc một tham chiếu có thẩm quyền khác.

Khi không thể xác định điều gì đã xảy ra, hãy dừng lại và chuyển cấp xử lý.

Ví dụ về logic thử lại cho tác nhân CI của chúng ta, được thể hiện bằng mã giả:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Ghi chú về mã: Ví dụ này giả định API CI hỗ trợ tra cứu các lần chạy theo ID yêu cầu. Trường request_id chỉ ngăn trùng lặp nếu nhà cung cấp đảm bảo rõ ràng tính idempotency. bounded_retry() chỉ là mã giả minh họa. Trong môi trường production, số lần thử lại nên được giới hạn bởi cả ngân sách thử lại cho mỗi thao tác (số lần thử tối đa hoặc thời gian đã trôi qua) lẫn hạn chót chung của quy trình làm việc.

Với các quy trình làm việc dài hơn trải rộng trên nhiều dịch vụ, hãy cân nhắc mẫu Saga để điều phối các hành động bù trừ khi các bước sau thất bại. Chỉ cần nhớ rằng bù trừ không phải lúc nào cũng là khôi phục hoàn toàn. Bạn có thể đảo ngược một bản cập nhật cơ sở dữ liệu, nhưng không thể thu hồi một email đã gửi.

Có hai yếu tố cần cân bằng ở đây: mỗi tác vụ cần năng lực mô hình đến mức nào và bạn có thể chạy đồng thời bao nhiêu tác vụ. Sai ở bất kỳ yếu tố nào, bạn đều có nguy cơ khiến các tác nhân tranh giành hạn mức API dùng chung hoặc chỉ dựa vào các mô hình suy luận đắt đỏ.

Với việc lựa chọn mô hình, hãy điều chỉnh năng lực mô hình và mức độ suy luận cho phù hợp với độ phức tạp của tác vụ — đơn giản nhưng lại khá thường bị bỏ qua. Lưu ý rằng bạn có thể tự cấu hình quy tắc định tuyến và đánh giá mô hình, hoặc dùng một nền tảng điều phối tự động lựa chọn mô hình cho bạn.

Ví dụ, Effort Mode của Perplexity Computer cho phép bạn chọn mức nỗ lực mà một tác vụ cần mà không phải tự chọn mô hình. Hãy chọn Light, Standard, High hoặc Ultra, và Perplexity sẽ tự động chọn mô hình điều phối cùng mức suy luận của mô hình đó. Sau đó, trình điều phối này ủy quyền các tác vụ con cho các tác nhân hỗ trợ, vốn có thể dùng mô hình từ nhiều nhà cung cấp khác nhau.

Perplexity đánh giá các cấu hình mô hình về chất lượng và chi phí, ưu tiên những lựa chọn rẻ hơn nhưng mang lại kết quả tương đương. Bạn cũng có thể dùng các tùy chọn Custom nếu muốn tự chọn mô hình và mức suy luận.

Với khả năng song song, giới hạn nên xuất phát từ cơ sở hạ tầng và các phụ thuộc bên ngoài của bạn. Hãy kiểm tra giới hạn tốc độ yêu cầu và token của các API dùng chung, sau đó kiểm thử tải quy trình làm việc với mức đồng thời tăng dần. Theo dõi xem thông lượng có cải thiện hay các yêu cầu bắt đầu phải xếp hàng, chậm lại hoặc trả về lỗi 429.

Để mức tiêu thụ tài nguyên luôn dễ dự đoán, hãy áp dụng giới hạn tài nguyên và các biện pháp kiểm soát lập lịch:

Kiểm soát mức đồng thời và tốc độ yêu cầu: Giới hạn số lệnh gọi đang xử lý cho mỗi dịch vụ và đưa phần việc vượt mức vào hàng đợi. Hãy nhớ rằng chỉ giới hạn mức đồng thời thôi sẽ không áp đặt được giới hạn số yêu cầu mỗi phút hay số token mỗi phút.
Theo dõi ngân sách token và chi phí: Tính toán mức sử dụng trên toàn bộ quy trình làm việc, bao gồm cả các tác nhân con, và ngừng khởi chạy công việc mới khi ngân sách còn lại không đủ.
Áp dụng hạn chót thực thi: Đặt giới hạn thời gian cho tác vụ và quy trình làm việc, đồng thời truyền tín hiệu hủy đến các tác nhân đang chạy nếu được hỗ trợ.
Tôn trọng các phụ thuộc: Chỉ khởi động các tác vụ hạ nguồn khi đầu vào cần thiết của chúng đã sẵn sàng, thay vì khởi chạy mọi tác nhân cùng lúc.

Đừng bao giờ yêu cầu mô hình tự quyết định xem hành động của chính nó có an toàn hay không. Thay vào đó, hãy cấp cho tác nhân quyền tối thiểu cần thiết và thực thi các quy tắc phê duyệt dựa trên rủi ro trong mã ứng dụng. Nếu tác nhân thực thi mã, hãy cô lập việc thực thi đó khỏi môi trường máy chủ của bạn và hạn chế quyền truy cập vào tệp, mạng và thông tin xác thực. Điều này giúp hạn chế thiệt hại nếu tác nhân mắc lỗi hoặc thực thi mã không an toàn.

“Tôi hoài nghi về các hệ thống đa tác nhân quá phức tạp, đặc biệt là khi các tác nhân đánh giá và phê duyệt công việc của nhau. Bạn có thể gặp tình huống nhiều tác nhân cùng tự tin chuyển tiếp một sai sót mà không ai thực sự phát hiện ra,” Spilker cảnh báo.

Sơ đồ quy trình phê duyệt: tác nhân đề xuất một thao tác kèm tham số, tài nguyên đích và phiên bản trạng thái; con người phê duyệt hoặc từ chối thao tác đó; các thao tác được phê duyệt sẽ được xác thực lại và chạy trong môi trường cô lập với quyền truy cập hạn chế vào tệp, mạng và thông tin xác thực. Các yêu cầu bị từ chối hoặc hết hạn sẽ bị đóng, còn các yêu cầu đã thay đổi cần được phê duyệt lại.

Với các hành động cần con người phê duyệt, hãy tạm dừng thực thi và lưu lại chính xác thao tác được đề xuất:

các tham số của thao tác
tài nguyên đích của thao tác
commit hoặc phiên bản trạng thái của thao tác
quyết định của người đánh giá

Ngoài ra, hãy xác định điều gì sẽ xảy ra nếu yêu cầu phê duyệt bị từ chối, hết hạn hoặc cần chuyển cấp xử lý. Điều này đặc biệt quan trọng với các framework có khả năng tiếp tục thực thi, vì khi tiếp tục một nút bị gián đoạn, mã sẽ được thực thi lại từ đầu nút đó. Mọi tác dụng phụ trước điểm gián đoạn đều có thể chạy lại.

Vì vậy, nếu yêu cầu phê duyệt bị từ chối hoặc hết hạn, yêu cầu sẽ bị đóng. Nếu commit đích, tham số hoặc quyền thay đổi trước khi thực thi, hãy vô hiệu hóa phê duyệt đó và yêu cầu phê duyệt mới.

Spilker cũng không ủng hộ quan điểm coi các tác nhân hoàn toàn tự chủ, xử lý trọn vẹn từ đầu đến cuối là mục tiêu cần hướng tới. “Với tôi, cách tiếp cận tốt hơn là xây dựng một vài tác nhân tập trung với trách nhiệm rõ ràng, quyền hạn được xác định và có con người đánh giá ở đúng thời điểm. Bạn vẫn đạt được hiệu quả mà không phải từ bỏ toàn quyền kiểm soát,” anh kết luận.

Bạn đã bao giờ gặp tác nhân báo cáo Success trong khi thực tế lại thất bại chưa? Điều đó thật khó chịu, thậm chí bực bội, và việc khắc phục không hề nhanh vì thông điệp cuối cùng của tác nhân chưa chắc đã cho bạn biết sự cố nằm ở đâu.

Để điều tra, hãy truy vết những gì đã xảy ra trong quá trình thực thi và xác minh kết quả một cách độc lập. Vậy hãy dành chút thời gian để khoanh vùng và giải quyết vấn đề.

Trước khi gỡ lỗi prompt của tác nhân, hãy ghi lại toàn bộ đường đi thực thi. Bạn cần một bản truy vết (trace) kết nối các lần gọi tác nhân, lệnh gọi công cụ, lỗi và các lần thử lại trong cùng một lần chạy quy trình làm việc.

Quy ước ngữ nghĩa GenAI của OpenTelemetry cung cấp một cách chuẩn hóa để mô tả các thao tác này. Ví dụ, invoke_workflow xác định việc thực thi quy trình làm việc, invoke_agent xác định một lần gọi tác nhân và execute_tool xác định một lệnh gọi công cụ. Mỗi thao tác có thể được ghi lại dưới dạng một span kèm thời gian, trạng thái và siêu dữ liệu liên quan.

Bước này cung cấp cho bạn bản truy vết đường đi thực thi, giúp bạn xác định tác nhân gặp trục trặc ở đâu.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Một bản truy vết thực thi minh họa.

Hãy dùng các bước kiểm tra bằng chương trình bất cứ khi nào có thể. Xác thực đầu ra theo JSON schema, chạy kiểm thử đơn vị và kiểm thử tích hợp, kiểm tra xem các tạo phẩm bắt buộc có tồn tại hay không và truy vấn các hệ thống bên ngoài để xác nhận các hành động thực sự đã thành công.

Với những đầu ra cần đánh giá chủ quan — và do đó không thể kiểm tra bằng chương trình — hãy bổ sung một tác nhân đánh giá độc lập. Một cách tiếp cận là vòng lặp triển khai–đánh giá–xử lý, trong đó một tác nhân tạo ra tạo phẩm, một tác nhân đánh giá với ngữ cảnh mới xác định các vấn đề, và một tác nhân xử lý khắc phục chúng trước khi bước xác thực chạy lại.

Bạn vẫn cần xác thực các phát hiện của tác nhân đánh giá khi có thể, và nếu đang dùng bộ chấm điểm dựa trên LLM cho các lần đánh giá lặp lại, hãy hiệu chỉnh nhận định của chúng dựa trên các ví dụ đã được con người đánh giá.

Đến đây, bạn đã truy vết những gì các tác nhân đã thực thi và kiểm tra xem đầu ra của chúng có chính xác hay không. Nhưng điều gì sẽ xảy ra khi một worker gặp sự cố giữa chừng khi đang thực hiện tác vụ, hoặc một API hết thời gian chờ sau khi đã chấp nhận yêu cầu? Điều đáng ngạc nhiên là quy trình làm việc của bạn có thể hoạt động hoàn hảo trong điều kiện bình thường nhưng lại thất bại trong quá trình khôi phục.

Để kiểm thử điều này, hãy chủ động đưa lỗi vào một môi trường kiểm thử:

Mô phỏng tình trạng API hết thời gian chờ
Làm worker gặp sự cố giữa các thao tác ghi vào hệ thống bên ngoài và các điểm kiểm tra (checkpoint)
Trả về đầu ra công cụ sai định dạng
Cho các phê duyệt hết hạn

Sau mỗi lần kiểm thử, hãy xem xét dấu vết thực thi để biết những bước nào đã chạy, quy trình làm việc đã tiếp tục từ đâu và có hành động nào bị lặp lại hay bị bỏ qua không. Sau đó, hãy xem xét kết quả thực tế.

Giả sử tác nhân CI của bạn gửi yêu cầu bắt đầu một lượt chạy kiểm thử, nhưng phản hồi của API bị hết thời gian chờ. Tác nhân thử lại, nhận được phản hồi thành công và báo cáo Thành công. Mọi thứ có vẻ ổn cho đến khi bạn kiểm tra dịch vụ CI và phát hiện rằng hai lượt chạy kiểm thử đã được tạo thay vì chỉ một.

Đó là lý do bạn nên xác minh cả trạng thái được ghi nhận của quy trình làm việc lẫn những thay đổi thực tế trong các hệ thống bên ngoài. Một bài kiểm thử khôi phục chỉ nên được coi là đạt khi quy trình làm việc đạt đến trạng thái mong đợi mà không gây ra tác dụng phụ ngoài ý muốn.

Hãy bổ sung các lỗi bạn phát hiện được vào bộ kiểm thử hồi quy để những thay đổi sau này không làm chúng xuất hiện trở lại.

Suy cho cùng, thành công có nghĩa là quy trình làm việc đã vượt qua các bước kiểm tra bắt buộc và các kết quả bên ngoài của nó đã được xác minh.

Các tác nhân biệt lập có thể hoàn thành chính xác từng tác vụ riêng của mình nhưng khi kết hợp lại thì tạo ra kết quả không nhất quán. Hãy hình dung một tác nhân bán hàng truy xuất điều khoản của khách hàng lúc 10:00, một tác nhân định giá tính báo giá dựa trên mức giá đã cập nhật lúc 10:05 và một tác nhân pháp lý kiểm tra một hợp đồng đã thay đổi lúc 10:07. Mỗi tác nhân làm việc với một ảnh chụp nhanh khác nhau về tình hình doanh nghiệp, nên đầu ra của chúng có thể mâu thuẫn với nhau.

Vấn đề này càng trở nên rõ rệt ở quy mô doanh nghiệp vì các tác nhân tương tác với nhiều hệ thống cập nhật độc lập với nhau, hoạt động với các quyền khác nhau và không nhất thiết chia sẻ ngữ cảnh hay trạng thái thực thi.

Hãy đặt giới hạn ở nhiều cấp độ: số lần thử lại lệnh gọi công cụ tối đa, số vòng lặp tối đa của tác nhân, độ sâu ủy quyền và thời hạn chung cho toàn bộ quy trình làm việc. Phân loại lỗi trước khi thử lại. Với các phản hồi 429 tạm thời, hãy tuân theo Retry-After nếu có. Nếu không, hãy dùng cơ chế chờ tăng theo cấp số nhân (exponential backoff) có giới hạn, kèm độ trễ ngẫu nhiên (jitter).

Ngừng thử lại các yêu cầu không thay đổi sau khi gặp lỗi kiểm tra tính hợp lệ hoặc lỗi quyền. Nếu một dịch vụ hạ nguồn liên tục gặp lỗi, cơ chế ngắt mạch (circuit breaker) có thể ngăn các tác nhân tạo thêm tải.

Cơ chế khôi phục phụ thuộc vào môi trường thực thi (runtime) của bạn. Với LangGraph, một checkpointer lưu trữ bền vững như PostgresSaver sẽ lưu trạng thái đồ thị theo một thread_id, cho phép tiếp tục thực thi từ trạng thái đã lưu. Với Temporal, một worker khác có thể dựng lại quy trình làm việc bằng cách phát lại lịch sử sự kiện của nó. Trong quá trình phát lại, worker sẽ tái sử dụng các kết quả activity đã được ghi nhận trước đó.

Nếu ứng dụng được triển khai lại trong khi các quy trình làm việc vẫn đang chạy, trạng thái đã lưu và lịch sử thực thi có thể không còn tương thích. Temporal giải quyết vấn đề này bằng Worker Versioning và workflow patching. Với các hệ thống dựa trên điểm kiểm tra, hãy lên kế hoạch di chuyển lược đồ và kiểm thử khả năng khôi phục với các trạng thái đã lưu hiện có trước khi triển khai các thay đổi không tương thích.

Chạy cùng các tác vụ tiêu biểu nhiều lần và phân biệt pass@k (liệu có ít nhất một trong k lần thử thành công hay không) với pass^k (liệu tất cả k lần thử có đều thành công hay không)

Đo lường kết quả theo danh mục tác vụ và phiên bản quy trình làm việc thay vì chỉ dựa vào một tỷ lệ thành công tổng hợp duy nhất. Theo dõi tỷ lệ thành công ngay từ lần thử đầu tiên, tính nhất quán giữa các lần chạy lặp lại, độ trễ p95, chi phí cho mỗi tác vụ hoàn thành và tỷ lệ tác vụ cần con người can thiệp. Báo cáo cỡ mẫu và khoảng bất định cho các tỷ lệ thành công.

Điều phối tác nhân AI là gì?

Cách thức hoạt động của điều phối tác nhân AI: Bên trong bộ máy thực thi

Khi nào bạn nên sử dụng điều phối tác nhân AI?

Các kiến trúc điều phối tác nhân AI và những đánh đổi của chúng

Điều phối tập trung

Điều phối phi tập trung

Điều phối phân cấp

Thực thi tuần tự, song song và dựa trên chuyển giao

Các lỗi thường gặp khi điều phối tác nhân AI

7 phương pháp hay nhất khi điều phối tác nhân AI để đảm bảo độ tin cậy trong môi trường production

1. Xác định rõ hợp đồng tác vụ, tiêu chí chấp nhận và điều kiện dừng

2. Giữ trình điều phối gọn nhẹ và áp dụng cơ chế chuyển giao có cấu trúc

3. Lưu trữ bền vững trạng thái quy trình làm việc và kiểm soát sự gia tăng ngữ cảnh

4. Thiết kế cơ chế thử lại có nhận biết lỗi và cách thực thi công cụ có thể khôi phục

5. Định tuyến và song song hóa công việc với ngân sách tài nguyên rõ ràng

6. Áp dụng quy trình phê duyệt và cô lập việc thực thi của tác nhân

7. Xác minh đầu ra một cách độc lập và kiểm thử hành vi khôi phục

Truy vết quy trình làm việc để xác định sự cố

Đánh giá đầu ra một cách độc lập

Chèn lỗi để kiểm thử khả năng khôi phục

Câu hỏi thường gặp về điều phối tác nhân AI

Vì sao các tác nhân AI hoạt động biệt lập lại gặp trục trặc ở quy mô doanh nghiệp?

Làm thế nào để ngăn vòng lặp thử lại vô hạn ở các tác nhân AI?

Làm thế nào để tiếp tục quy trình làm việc của tác nhân AI sau khi gặp sự cố?

Làm thế nào để kiểm thử độ tin cậy của việc điều phối tác nhân AI?