Kiến trúc multi-agent thực chiến: orchestrator, peer-to-peer, bộ nhớ và khôi phục sự cố

Kiến trúc multi-agent nên bắt đầu từ bài toán kinh tế và hệ thống: vì sao một agent hay một quy trình là chưa đủ? Lý do xác đáng gồm nhiều nhánh khảo sát độc lập có thể chạy song song, tác tử chuyên trách có công cụ, ngữ cảnh và quyền hạn riêng, lượng thông tin vượt quá cửa sổ ngữ cảnh, hoặc ranh giới tổ chức buộc các agent độc lập phải hợp tác. Lý do sai lầm là muốn có sơ đồ ấn tượng, hy vọng các agent tự sửa sai cho nhau, hoặc chỉ vì khung phần mềm cho phép tạo thêm agent. Mỗi agent bổ sung đều làm tăng số lượt gọi mô hình, giao ước giao tiếp, định danh, trạng thái, ngân sách, kịch bản lỗi và bài toán đánh giá. Xây dựng mốc đo ban đầu với phương án đơn giản là yêu cầu bắt buộc trước khi chạy thử nghiệm (pilot).

Có ba mô hình cấu trúc chính. Mô hình quản lý giữ bộ điều phối nắm toàn bộ hội thoại, sản phẩm đầu ra cuối cùng và gọi tác tử chuyên trách như công cụ; phù hợp khi cần tổng hợp tập trung. Mô hình bàn giao chuyển tác tử phụ trách phiên trao đổi trực tiếp, phù hợp khâu phân loại và chuyên môn hóa theo lĩnh vực. Mô hình ngang hàng trao đổi tác vụ, thông điệp và sản phẩm đầu ra giữa các agent độc lập, thích hợp hợp tác liên phòng ban hoặc xuyên tổ chức nhưng việc quản lý tin cậy, quyền sở hữu trạng thái và kiểm soát vòng lặp là khó nhất. Quy trình khung bằng mã lập trình giúp kiểm soát trạng thái, phê duyệt và xác nhận giao dịch, trong khi mô hình ngôn ngữ lớn (LLM) chỉ lập kế hoạch trong các nút tác vụ giới hạn. Mô hình lai thường tốt hơn việc gượng ép mọi tương tác vào một cấu trúc duy nhất.

Bộ điều phối không chỉ là một câu lệnh bảo AI hãy chia việc. Nó cần xác thực ý định và rủi ro, tạo đồ thị tác vụ có quản lý phiên bản, chọn tác tử đã được duyệt, phân bổ ngân sách và thời hạn chót, điều phối theo quan hệ phụ thuộc, theo dõi tiến độ, xử lý xung đột hoặc sự cố và kết thúc quy trình. Giao ước tác tử gồm mục tiêu, phạm vi, cấu trúc dữ liệu đầu vào và đầu ra, công cụ, định danh, giới hạn tài nguyên, bảng phân loại lỗi và tiêu chí nghiệm thu. Các nhánh song song chỉ được mở khi độc lập; bước hợp nhất phải kiểm tra sản phẩm đầu ra, loại bỏ bằng chứng trùng lặp, phát hiện xung đột hay lỗ hổng bao phủ và truy vết nguồn gốc. Câu trả lời cuối không được che giấu sự cố của nhánh con hoặc biến biểu quyết đa số thành sự thật.

Bộ nhớ cần được phân tầng rõ ràng: ngữ cảnh mô hình là tạm thời; trạng thái phiên chạy và điểm lưu (checkpoint) dùng để tiếp tục sau ngắt quãng; sản phẩm đầu ra là kết quả có phiên bản; bộ nhớ dài hạn là dữ liệu dẫn xuất có thể bị lỗi thời; nguồn sự thật là kho CRM, ERP hoặc quy định chính sách; còn bằng chứng ghi lại điều đã xảy ra. Mỗi tầng cần có không gian định danh, người phụ trách, cổng kiểm soát ghi, thời hạn lưu (TTL), nguồn gốc, quyền hạn, cơ chế đính chính và xóa bỏ. Các tác tử nên trao đổi sản phẩm đầu ra thay vì toàn bộ bản ghi hội thoại. Bộ nhớ dài hạn không cấp quyền và không tự ý ghi nhận dữ kiện kinh doanh. Khôi phục từ điểm lưu phải xác thực lại quyền và đối soát tác động ngoại vi trước khi thử lại.

Khôi phục sự cố là công việc của hệ thống phân tán. Hàng đợi thường hoạt động theo cơ chế gửi ít nhất một lần, nên bên nhận và lệnh gọi ra ngoài đều cần khả năng chống xử lý trùng. Thử lại chỉ dành cho lỗi tạm thời, có độ trễ giãn cách ngẫu nhiên và thời hạn chót; bộ ngắt mạch và vách ngăn giúp chặn đứng bão tải. Tác vụ cha phân biệt rõ nhánh tùy chọn hay nhánh trọng yếu; lưu giữ sản phẩm đầu ra giúp tránh làm lại từ đầu. Lệnh hủy được gửi xuống các tác tử con nhưng yêu cầu gửi ra bên ngoài có thể đã ghi nhận thành công, vì vậy đối soát với hệ thống lưu trữ gốc là bước chốt chặn cuối cùng. Hết thời gian chờ chỉ là trạng thái chưa xác định chứ không phải bằng chứng thất bại. Con người can thiệp khi có tác động ngoại vi chưa rõ, xung đột dữ liệu hoặc quyết định rủi ro cao.

Vận hành đòi hỏi truy vết toàn bộ đồ thị tác vụ, phân cấp ngân sách, diễn tập tiêm lỗi và đánh giá kết quả thực chất. Hãy so sánh giải pháp multi-agent với một agent đơn lẻ hoặc quy trình thông thường về chất lượng, tỷ lệ đạt chuẩn nghiệm thu, chu kỳ hoàn thành, tổng token và công cụ sử dụng, công sức kỹ thuật và trực vận hành, hành vi không an toàn và kết quả kinh doanh đối soát được. Điển cứu từ nhà cung cấp chỉ là bằng chứng tham khảo trong phạm vi hẹp; mục tiêu của doanh nghiệp vẫn cần kiểm chứng bằng số liệu chạy thử thực tế. Thiết kế chuẩn mực luôn có cơ chế giảm bớt số lượng tác tử, thậm chí quay lại mô hình một agent nếu mô hình AI hoặc quy trình mới đạt cùng kết quả với độ phức tạp thấp hơn.

Lạm dụng điều phối (over-orchestration) xảy ra khi mọi bước đều bị biến thành agent. Một bộ kiểm tra hợp lệ, bộ tính toán, bộ phân luồng theo quy tắc hoặc cổng chuyển đổi API thường nên là mã lập trình hoặc công cụ có tính xác định cố định. Nếu để mô hình AI lập kế hoạch cho cả các bước chuyển tiếp cố định, sự cố sẽ rất khó tái hiện và chi phí tăng vọt. Quyết định kiến trúc cần ghi rõ nút nào linh hoạt do chứa tính bất định, nút nào chạy mã cố định để kiểm soát chặt. Số lượng agent không phải là chỉ số KPI. Thu gọn tối đa ranh giới trung gian giúp giảm độ trễ, thu hẹp bề mặt tấn công an ninh và tinh gọn kiểm thử. Chạy thử nghiệm phải chứng minh tính chuyên trách hoặc xử lý song song mang lại lợi ích thật sự so với mốc đo ban đầu, chứ không chỉ dừng ở việc chạy thử thành công một bản minh họa.

Phân rã công việc yếu tạo ra công việc trùng lặp và khoảng trống bao phủ. Câu lệnh ngắn như nghiên cứu thị trường khiến ba tác tử cùng tìm nguồn phổ biến trong khi bỏ qua rủi ro pháp lý. Tác vụ con bắt buộc phải có phạm vi và các điểm loại trừ, cấu trúc dữ liệu đầu ra, ràng buộc về nguồn dữ liệu, tiêu chí nghiệm thu và thời hạn chót. Bảng ma trận bao phủ và danh mục sản phẩm đầu ra giúp bộ điều phối biết nhánh nào đã làm gì. Quá trình tự tinh chỉnh kế hoạch phải có giới hạn. Tác tử được phép trả về trạng thái không thể hoàn thành hoặc yêu cầu thêm thông tin đầu vào, thay vì bị hệ thống ép buộc phải viết ra những đoạn văn xuôi bóng bẩy. Đánh giá phải đo lường mức độ trùng lặp, phần việc bị bỏ sót và phần việc thừa bị loại bỏ, chứ không chỉ nhìn vào độ trôi chảy của sản phẩm cuối.

Dùng chung toàn bộ bản ghi hội thoại toàn cục là một mẫu thiết kế sai lầm phổ biến. Nó khiến các agent nhìn thấy dữ liệu cá nhân, thông tin bảo mật, kết quả công cụ không liên quan và nguy cơ bị tiêm câu lệnh; ngữ cảnh phình to nhanh chóng và xóa nhòa quyền sở hữu trạng thái. Mỗi tác tử chỉ cần ngữ cảnh tối thiểu được phân quyền, còn các mối phụ thuộc được truyền qua sản phẩm đầu ra có định kiểu hoặc tham chiếu rõ ràng. Bộ điều phối chỉ lưu kế hoạch và danh mục sản phẩm đầu ra, không lưu toàn bộ quỹ đạo thao tác thô của từng tác tử. Khi bàn giao phải lọc và che giấu dữ liệu nhạy cảm. Bảng tin chia sẻ nếu dùng phải có phiên bản, phân vùng dữ liệu, khóa đồng thời và phân loại bản ghi có cấu trúc. Bộ nhớ không thể thay thế cho ủy quyền. Bản chụp nhanh ngữ cảnh chỉ hỗ trợ chạy lại và đánh giá, không ghi nhật ký chuỗi suy nghĩ nội bộ.

Thử lại mà thiếu khả năng chống xử lý trùng sẽ tạo ra tác động ngoại vi trùng lặp. Tác tử gặp lỗi hết thời gian chờ sau khi đã gửi email hoặc tạo hóa đơn, rồi tự động thử lại với mã khóa mới vì không rõ kết quả trước đó. Hướng đi đúng là dùng khóa chống xử lý trùng theo ngữ nghĩa nghiệp vụ, sổ cái ghi lệnh hoặc hộp thư đi (outbox), tra cứu trạng thái nhà cung cấp và đối soát kỹ. Chính sách thử lại phân biệt lỗi kết nối tạm thời với lỗi nghiệp vụ, lỗi quy định hay sai cấu trúc dữ liệu, đồng thời tuân thủ ngân sách tác vụ cha và dừng kịp thời. Cần kiểm thử khả năng chịu lỗi bằng cách mô phỏng sự cố sập trước hoặc sau các lệnh gọi ra ngoài và ghi nhận trạng thái. Không được giả định hệ thống tự xử lý chính xác một lần. Hành động đền bù phải là thao tác riêng có phê duyệt và bằng chứng rõ ràng, không phải nút hoàn tác toàn năng.

Điểm lưu trạng thái thường bị nhầm lẫn với bộ nhớ và bản sao lưu dữ liệu. Bản chụp nhanh trạng thái đồ thị cho phép tiếp tục chạy sau gián đoạn, nhưng có thể chứa đặc quyền hết hạn, token cũ, tác động ngoại vi đang chờ dở dang và cấu trúc dữ liệu cũ. Khi khôi phục phải xác thực lại định danh, chính sách, thời hạn chót và phiên bản phần mềm; lấy lại khóa bảo mật; đối soát kết quả chưa rõ ràng từ bên ngoài. Lưu trữ môi trường vận hành cần mã hóa, phân vùng theo khách hàng (tenant), quy định thời hạn lưu, hỗ trợ chuyển đổi dữ liệu và diễn tập phục hồi. Bộ lưu trạng thái trên bộ nhớ tạm chỉ dùng trong phát triển. Bản thân điểm lưu không tự bảo đảm tính toàn vẹn khi gọi công cụ. Sản phẩm đầu ra thành công có thể tái sử dụng, nhưng nhánh bị hủy hoặc lỗi thời tuyệt đối không được gộp vào. Bằng chứng khôi phục phải kết nối giữa phiên chạy cũ và mới.

Mạng lưới ngang hàng mở rộng nhanh hơn năng lực quản trị. Các agent tự phát hiện nhau, tiếp tục ủy quyền công việc và tạo ra vòng lặp vô tận, bùng nổ tác vụ hoặc gửi dữ liệu sang nhà cung cấp chưa được duyệt. Cấu trúc ngang hàng cần sổ đăng ký, cổng kiểm soát, định danh, danh sách agent và kỹ năng được phép trao đổi, phân loại cấp độ dữ liệu và hành động, giới hạn số bước nhảy (hop), thời hạn chót, ngân sách và quy định cấm ủy quyền tiếp. Giao thức tương tác giữa các tác tử (A2A) không thay thế cho thẩm định nhà cung cấp hay phê duyệt nghiệp vụ. Trung tâm kiểm soát chính sách tập trung vẫn có thể duy trì dù việc lập kế hoạch được phân tán. Nếu doanh nghiệp không cần quyền tự chủ xuyên biên giới tổ chức, bộ điều phối hoặc kết nối API trực tiếp thường dễ kiểm soát hơn.

Bước tổng hợp cuối cùng dễ che giấu sự thật trong vận hành. Bộ điều phối biến kết quả dở dang hoặc thất bại của các tác tử thành câu trả lời mượt mà, bỏ qua nguồn trích dẫn hoặc tự tin hòa giải các mâu thuẫn. Bước hợp nhất cần cấu trúc dữ liệu chuẩn xác, mã băm, trạng thái thực thi, quy tắc xử lý xung đột và thiếu sót dữ liệu, phương pháp tổng hợp số học cố định và nguồn gốc rõ ràng. Sản phẩm đầu ra cuối cùng phải ghi rõ các phiên bản tài liệu thành phần. Thất bại ở nhánh phụ được ghi nhận là suy giảm chất lượng; thất bại ở nhánh trọng yếu phải chặn quy trình lại. Người dùng cần thấy rõ các lưu ý cảnh báo. Bộ kiểm tra dùng chung mô hình AI không phải sự bảo đảm độc lập. Nghiệm thu sản phẩm đầu ra có rủi ro cao thuộc về người phụ trách kết quả kinh doanh qua con người duyệt, không phải bộ điều phối tự chấm điểm.

Khả năng quan sát nếu chỉ dừng lại ở từng lượt gọi mô hình là không đủ. Khi xảy ra sự cố, cần đồ thị liên kết phiên chạy, tác vụ con, tác tử thực thi, công cụ, sản phẩm đầu ra, trạng thái, số lần thử lại, phiên bản, ngân sách và tác động ngoại vi. Chỉ số đo lường cần tính đến tính song song hữu ích, hiệu quả phân luồng và phân rã việc, trùng lặp công việc, số lần thử lại, vòng lặp, độ lỗi thời của bộ nhớ, hiệu quả phục hồi và đối soát dữ liệu. Nhật ký vết truy vết không thể thay thế cho định danh bảo mật hay nhật ký kiểm toán kinh doanh. Dữ liệu nhạy cảm phải được che giấu. Tỷ suất lợi nhuận (ROI) cần dựa trên kết quả nghiệm thu và đối soát thực tế đặt cạnh tổng chi phí, gồm cả các lệnh gọi thất bại, sản phẩm bị loại bỏ và công sức trực vận hành.

Bốn ngộ nhận cần loại bỏ

• ⦿Nhiều agent không mặc định mang lại kết quả tốt hơn một agent đơn lẻ.
• ⦿Chia sẻ toàn bộ bản ghi hội thoại không phải là kiến trúc quản lý bộ nhớ.
• ⦿Cơ chế thử lại đơn thuần không thể tạo ra tác động ngoại vi chính xác một lần.
• ⦿Tác vụ hoàn thành về kỹ thuật không đồng nghĩa với kết quả kinh doanh đã được đối soát.

1. Kiến trúc đa tác tử (multi-agent) chỉ thực sự hợp lý khi tác vụ có thể phân rã rành mạch, ranh giới chuyên môn của từng tác tử mang lại giá trị rõ rệt, quyền hạn công cụ và ngữ cảnh cần được tách biệt, hoặc có nhiều nhánh công việc độc lập cần chạy song song. Nếu một agent đơn lẻ kết hợp công cụ và quy trình cố định đã giải quyết được cùng kết quả, việc bổ sung thêm agent sẽ chỉ làm tăng số lượt gọi mô hình, các bước chuyển trạng thái, độ trễ, nguy cơ lỗi và chi phí đánh giá. Quyết định kiến trúc phải bắt đầu từ mốc đo ban đầu của giải pháp một agent hoặc quy trình thông thường, giá trị kinh tế của tác vụ và đồ thị phụ thuộc. Nghiên cứu tìm kiếm theo chiều rộng với nhiều nhánh độc lập thường phù hợp với mô hình đa tác tử hơn là quy trình đòi hỏi mọi tác tử cùng chỉnh sửa tuần tự một đối tượng dữ liệu. Mọi khẳng định về hiệu quả đều phải gắn với khối lượng công việc cụ thể. Kết quả nội bộ của một hệ thống nghiên cứu không thể coi là chuẩn đo lường chung cho mọi bài toán. Mục tiêu cốt lõi luôn là nâng cao chất lượng, rút ngắn chu kỳ và giảm thiểu rủi ro, chứ không phải chạy theo số lượng tác tử.

2. Đồ thị tác vụ biểu diễn công việc dưới dạng các nút tác vụ, quan hệ phụ thuộc, dữ liệu đầu vào, giao ước đầu ra, tác động ngoại vi, người phụ trách, thời hạn chót, ngân sách và tiêu chí nghiệm thu. Bộ điều phối có thể lập kế hoạch linh hoạt, nhưng môi trường thực thi đồ thị phải giới hạn chặt chẽ các loại nút, công cụ, mức độ mở rộng nhánh và các bước chuyển tiếp. Những bước xác định như kiểm tra tính hợp lệ, tính toán số học, phê duyệt và ghi nhận dữ liệu nên được xử lý bằng mã lập trình hoặc quy trình tự động, tuyệt đối không giao cho mô hình AI quyết định tùy tiện. Các nút linh hoạt chỉ nên áp dụng ở những khâu mà tính bất định mang lại giá trị sáng tạo. Đồ thị cần có mã định danh tác vụ ổn định và quản lý phiên bản; mọi thay đổi kế hoạch phải ghi rõ phần khác biệt và lý do. Cần phân biệt rõ đường găng trọng yếu với các nhánh song song. Điều kiện hợp nhất phải quy định rõ: đợi tất cả, chỉ cần một nhánh, đạt biểu quyết tối thiểu hay ngưỡng định trước. Chính sách kiểm soát chu trình giúp phát hiện và ngăn chặn vòng lặp. Một danh sách việc cần làm viết bằng văn bản thông thường là hoàn toàn không đủ để khôi phục hoặc kiểm toán một hệ thống phân tán.

3. Quyết định về cấu trúc hệ thống phải dựa trên quyền sở hữu kiểm soát. Mô hình quản lý giữ quyền kiểm soát giao tiếp với người dùng và gọi các tác tử chuyên trách như những công cụ, phù hợp khi cần tổng hợp thông tin, áp dụng rào chắn an toàn chung và đưa ra câu trả lời duy nhất. Mô hình bàn giao chuyển tác tử phụ trách phiên tương tác cho tác tử chuyên trách, phù hợp khâu phân loại ban đầu khi tác tử chuyên trách sẽ đảm nhận toàn bộ phần còn lại của cuộc trò chuyện. Mô hình ngang hàng cho phép các agent tự chủ trao đổi tác vụ qua giao thức và cổng trung gian, phù hợp hợp tác liên lĩnh vực hoặc xuyên tổ chức nhưng việc quản lý trạng thái, mức độ tin cậy và kiểm soát vòng lặp là phức tạp nhất. Đường ống xử lý bằng mã lập trình phù hợp với những quy trình có lộ trình cố định. Kiến trúc lai có thể dùng mã lập trình cho máy trạng thái vòng ngoài và dùng mô hình ngôn ngữ lớn (LLM) bên trong các nút tác vụ có giới hạn. Doanh nghiệp không nên gọi mọi mạng lưới là mô hình ngang hàng; cấu trúc kiến trúc cần ghi rõ quyền kiểm soát, trạng thái, định danh, điều kiện kết thúc và bằng chứng kiểm tra.

4. Mô hình quản lý theo hướng tác tử làm công cụ (Agents-as-Tools) trao cho bộ điều phối quyền quản lý toàn bộ hội thoại và bước tổng hợp cuối cùng. Tác tử chuyên trách nhận dữ liệu đầu vào theo cấu trúc định sẵn và chỉ trả về sản phẩm đầu ra hoặc kết quả hẹp, không nhận toàn bộ lịch sử trò chuyện theo mặc định. Bộ điều phối lựa chọn tác tử thực thi, kích hoạt xử lý song song khi các nhánh độc lập, kiểm tra đầu ra và quyết định bước tiếp theo. Ưu điểm là tập trung hóa chính sách, ngân sách và trải nghiệm người dùng; nhược điểm là dễ tạo điểm nghẽn, áp lực dung lượng ngữ cảnh và rủi ro sập toàn bộ nếu bộ điều phối gặp sự cố. Bộ điều phối không được tự ý viết lại bằng chứng thành sự thật tuyệt đối mà phải giữ nguyên nguồn gốc và trích dẫn. Định danh và quyền hạn công cụ của từng tác tử phải tách biệt. Các tầng điều phối lồng nhau phải bị giới hạn về độ sâu. Nếu bộ điều phối bị hết thời gian chờ, các điểm lưu trạng thái và sản phẩm đầu ra sẽ cho phép tiếp tục phiên chạy. Bộ công cụ phát triển phần mềm OpenAI Agents SDK mô tả mẫu thiết kế này cho trường hợp bộ quản lý cần nắm quyền kiểm soát và kết hợp kết quả; tuy nhiên đây chỉ là một mẫu thiết kế của bộ công cụ chứ không phải quy chuẩn áp dụng cho mọi hệ thống.

5. Cơ chế bàn giao (handoff) chuyển quyền điều khiển tương tác sang một agent khác. Bộ phân luồng hoặc phân loại ban đầu sẽ chọn tác tử chuyên trách; tác tử tiếp nhận sở hữu chỉ dẫn, công cụ riêng và có thể xem lịch sử trao đổi theo cấu hình. Việc lọc và ẩn danh lịch sử là cực kỳ quan trọng vì toàn bộ bản ghi trò chuyện có thể chứa dữ liệu cá nhân, khóa bí mật, nguy cơ bị tiêm câu lệnh hoặc ngữ cảnh không cần thiết. Cấu trúc đầu vào bàn giao chỉ chứa siêu dữ liệu do mô hình tạo ra tại thời điểm chuyển giao, không thể thay thế cho trạng thái ứng dụng hay quyền xác thực. Việc phân quyền bắt buộc phải được kiểm tra trong các hàm xử lý trước khi kích hoạt bất kỳ tác động ngoại vi nào; rào chắn công cụ không mặc nhiên tự áp dụng vào quá trình bàn giao. Cần quy định rõ người sở hữu trạng thái, hướng quay lại và lộ trình báo cáo vượt cấp. Tránh tình trạng chuyển qua chuyển lại vô tận bằng cách quy định các bước chuyển hợp lệ và giới hạn số bước nhảy. Cơ chế bàn giao chỉ dùng khi tác tử chuyên trách cần trực tiếp trả lời người dùng, chứ không dùng để tạo tính song song giả tạo hay thoái thác trách nhiệm về sản phẩm đầu ra cuối cùng.

6. Mô hình ngang hàng (peer-to-peer) cho phép các agent độc lập trao đổi tác vụ, thông điệp và sản phẩm đầu ra, đồng thời duy trì vòng đời riêng biệt. Chuẩn kết nối giữa các tác tử (A2A) hoặc các giao ước tương tự hỗ trợ việc tìm kiếm và ngữ nghĩa tác vụ, nhưng môi trường doanh nghiệp vẫn bắt buộc phải có sổ đăng ký được phê duyệt, định danh, ủy quyền đối tượng, ngân sách, ranh giới tin cậy, đầu mối liên hệ sự cố và bằng chứng kiểm tra. Mô hình ngang hàng không có bộ não trung tâm, do đó cổng chính sách hoặc mặt phẳng điều khiển cần thực thi nghiêm ngặt danh sách tác tử được phép, kỹ năng, độ sâu ủy quyền, thời gian chờ tối đa, cùng các cấp độ dữ liệu và hành vi. Sự đồng thuận hoặc tranh luận giữa các agent không tự động tạo ra chân lý; nhiều agent hoàn toàn có thể lặp lại cùng một định kiến sai lệch. Trạng thái biến đổi dùng chung sẽ gây xung đột tài nguyên và tranh chấp; hãy ưu tiên sản phẩm đầu ra, thông điệp có phiên bản và quyền sở hữu rõ ràng. Mô hình ngang hàng chỉ đáng dùng khi tính tự chủ tổ chức hoặc khả năng tương thích liên hệ thống là yêu cầu bắt buộc, chứ không phải vì sở thích sơ đồ mạng lưới đẹp mắt.

7. Kiến trúc lai (hybrid) thường là phương án thực tế nhất trong doanh nghiệp. Một quy trình khung cố định bằng mã lập trình sẽ kiểm soát trạng thái, ngân sách, các điểm phê duyệt và ghi nhận giao dịch; bộ điều phối dùng mô hình ngôn ngữ lớn (LLM) để phân rã các yêu cầu mở; các tác tử chuyên trách thực hiện các tác vụ con có giới hạn; cơ chế bàn giao chỉ áp dụng trong phạm vi hội thoại; giao thức ngang hàng dùng cho tác tử bên ngoài; còn chuẩn MCP và các công cụ nằm ở tầng năng lực thực thi. Mỗi ranh giới kết nối đều có giao ước và ánh xạ xử lý lỗi rõ ràng. Mặt phẳng điều khiển không phụ thuộc vào mô hình AI để thực thi thời hạn chót, lệnh hủy hay xác thực định danh. Mặt phẳng dữ liệu lưu trữ sản phẩm đầu ra có cấu trúc chuẩn và nguồn gốc. Mặt phẳng sự kiện truyền tải trạng thái. Mặt phẳng bằng chứng kết nối xuyên suốt toàn bộ đồ thị tác vụ. Kiến trúc lai tránh gượng ép một cấu trúc duy nhất giải quyết mọi bài toán nhưng sẽ làm tăng bề mặt tích hợp; danh mục kiến trúc cần nêu rõ mẫu thiết kế nào được dùng tại điểm kết nối nào, chứ không quảng bá chung chung là hệ thống đa tác tử. Các bài kiểm thử toàn trình chuẩn mực sẽ xác nhận tính nhất quán về ngữ nghĩa xuyên suốt các tầng hệ thống.

8. Trách nhiệm của bộ điều phối bao gồm: xác thực ý định, phân loại mức độ rủi ro, tải chính sách và ngữ cảnh liên quan, phân rã công việc, lựa chọn các tác tử thực thi đã được phê duyệt, phân bổ thời hạn chót và ngân sách, điều phối tác vụ, giám sát tiến độ, giải quyết quan hệ phụ thuộc, đánh giá sản phẩm đầu ra, tổng hợp câu trả lời, yêu cầu con người can thiệp và kết thúc quy trình. Bộ điều phối không được nắm giữ thông tin đăng nhập quản trị tối cao, không được vượt mặt chính sách bảo mật của tác tử thực thi và không tự ý ghi nhận các tác động ngoại vi rủi ro cao chỉ vì các tác tử con đều đồng thuận. Kế hoạch và các quyết định cần có cấu trúc đủ chặt chẽ để truy vết mà không cần ghi lại chuỗi suy nghĩ nội bộ. Hệ thống cần ghi nhận rõ các giả định, tiêu chí nghiệm thu, tham chiếu bằng chứng và các yếu tố bất định chưa giải quyết. Cơ chế thử lại và phương án dự phòng phải nằm trong chính sách vận hành của hệ thống, chứ không thể phụ thuộc vào câu lệnh prompt đơn thuần. Sức khỏe của bộ điều phối, khả năng chịu áp lực tải và cơ chế chuyển đổi dự phòng khi máy chủ điều phối gặp sự cố phải được thiết kế trước. Nếu bộ điều phối là điểm nghẽn có nguy cơ gây sập toàn bộ hệ thống, thì trạng thái bền vững và khả năng khôi phục an toàn qua việc chạy lại là yêu cầu bắt buộc.

9. Chất lượng phân rã tác vụ quyết định trực tiếp đến hiệu quả của cả hệ thống. Mỗi tác vụ con bắt buộc phải có mục tiêu rõ ràng, phạm vi và các điểm loại trừ, tham chiếu đầu vào, cấu trúc dữ liệu đầu ra, ràng buộc về nguồn dữ liệu và công cụ, thời hạn chót, ngân sách, tiêu chí nghiệm thu và quan hệ phụ thuộc. Một câu lệnh mơ hồ sẽ khiến các tác tử làm việc trùng lặp, tạo ra lỗ hổng bỏ sót hoặc tự do tìm kiếm vô định. Bộ điều phối nên sử dụng ma trận bao phủ để đảm bảo các nhánh công việc không trùng lặp và bao quát toàn diện, nhưng không gượng ép phân rã khi các mối quan hệ phụ thuộc quá chằng chịt. Việc tự động tinh chỉnh kế hoạch dựa trên phát hiện mới phải có giới hạn mở rộng nhánh. Tác tử thực thi phải được phép trả về trạng thái không thể hoàn thành, yêu cầu thêm thông tin hoặc ghi chú cảnh báo thay vì cố tình bịa đặt thông tin. Tác vụ cha phải nhận biết được bằng chứng nào là mới, lỗi thời hay đang xung đột. Đánh giá chất lượng phải đo lường độ bao phủ, mức độ trùng lặp và phần việc lãng phí. Các mẫu quy trình do con người thiết kế cho các nghiệp vụ lặp lại thường mang lại kết quả vượt trội so với việc để AI tự do phân rã hoàn toàn. Việc quản lý phiên bản kế hoạch giúp nhận diện chính xác các sản phẩm đầu ra thuộc về những nhánh công việc đã bị hủy bỏ.

10. Giao ước tác tử thực thi bao gồm: phiên bản tác tử hoặc kỹ năng ổn định, cấu trúc đầu vào được chấp nhận, cấu trúc sản phẩm đầu ra, danh mục công cụ và tài nguyên được phép dùng, phân loại tác động ngoại vi, định danh và phạm vi quyền hạn, giới hạn số bước, thời gian và chi phí tối đa, cấp độ bảo mật dữ liệu, bảng phân loại lỗi, cơ chế chống xử lý trùng và tiêu chuẩn chất lượng. Bản mô tả bằng ngôn ngữ tự nhiên chỉ hỗ trợ phân luồng ban đầu chứ không thể là giao ước duy nhất. Phản hồi của tác tử cần tách bạch rõ: kết quả xử lý, bằng chứng và nguồn gốc, các giả định, độ tin cậy và lưu ý cảnh báo, mức tài nguyên tiêu thụ và trạng thái hoàn thành. Chi tiết dung lượng lớn phải lưu vào kho sản phẩm đầu ra, tác vụ cha chỉ nhận bản tóm tắt hoặc đường dẫn tham chiếu. Khả năng tương thích của giao ước phải được kiểm thử trước khi nâng cấp. Tác tử không được tự ý sinh thêm tác tử mới nếu chính sách an toàn không cho phép. Một tác tử sử dụng mô hình hay nhà cung cấp khác vẫn phải tuân thủ cùng một giao ước nghiệp vụ. Khi dữ liệu đầu ra bị thiếu hoặc không hợp lệ, hệ thống phải báo lỗi rõ ràng và giới hạn số lần sửa chữa; bộ điều phối tuyệt đối không được tự ý diễn giải văn bản thô theo cảm tính rồi ghi nhận giao dịch.

11. Xử lý song song chỉ áp dụng cho các nhánh công việc độc lập hoặc có liên kết lỏng lẻo. Môi trường thực thi phải tính toán đồ thị có hướng không chu trình (DAG) về quan hệ phụ thuộc, giới hạn mức độ đồng thời theo từng khách hàng, tài nguyên hệ thống, nhà cung cấp mô hình và đường găng trọng yếu. Việc tìm kiếm hoặc rà soát song song có thể giúp rút ngắn thời gian thực tế; nhưng các thao tác ghi dữ liệu song song vào cùng một đối tượng sẽ gây xung đột và trùng lặp. Giới hạn tần suất gọi công cụ của nhà cung cấp và công suất xử lý hạ tầng phải được tính vào khâu tiếp nhận tác vụ. Việc chạy suy đoán trước chỉ nên thực hiện khi giá trị vượt xa chi phí và sản phẩm đầu ra bị loại bỏ không để lại tác động ngoại vi. Cần lập tức hủy bỏ các nhánh không được chọn sau khi bước hợp nhất đạt điều kiện tối thiểu. Các kết quả đến muộn phải mang theo phiên bản kế hoạch và tác vụ con; sản phẩm đầu ra lỗi thời tuyệt đối không được sáp nhập vào kết quả chung. Mỗi nhánh công việc phải có thời hạn chót ngắn hơn tác vụ cha. Dữ liệu đo đạc mở rộng và gom nhánh cần đo lường tỷ lệ công việc hữu ích so với công việc trùng lặp. Anthropic từng báo cáo mức tăng hiệu quả lớn cho bài toán nghiên cứu theo chiều rộng đi kèm mức tiêu thụ token cao hơn; vì vậy doanh nghiệp bắt buộc phải tự đo lường lại trên chính nghiệp vụ của mình.

12. Bước hợp nhất và tổng hợp không đơn thuần là việc ghép nối các đoạn văn bản trả lời lại với nhau. Hợp nhất là quá trình kiểm tra tính hợp lệ về cấu trúc dữ liệu, tính toàn vẹn và trạng thái thực thi, loại bỏ các bằng chứng trùng lặp, chuẩn hóa thực thể, thời gian và đơn vị đo lường, phát hiện mâu thuẫn và đối chiếu mức độ bao phủ so với kế hoạch ban đầu. Đối với điều kiện đợi tất cả các nhánh, việc thiếu một nhánh trọng yếu sẽ chặn toàn bộ quy trình hoặc đánh dấu là chưa hoàn thành; trong khi điều kiện chỉ cần một nhánh hoặc đạt biểu quyết tối thiểu phải có chính sách kiểm soát rủi ro và độ tin cậy rõ ràng. Khâu tổng hợp phải trích dẫn sản phẩm đầu ra nguồn và bảo toàn các ý kiến bất đồng hoặc lưu ý cảnh báo. Một tác tử kiểm chứng độc lập có thể thẩm định các tuyên bố, nhưng việc dùng chính mô hình cũ tự đánh giá lại không thể coi là sự bảo đảm độc lập. Các phép tính số học phải được xử lý bằng các hàm tổng hợp xác định bằng mã lập trình. Phiên bản sản phẩm đầu ra cuối cùng phải liên kết với mã băm của từng tài liệu thành phần. Nếu kết quả giữa các tác tử xung đột, bộ điều phối phải căn cứ vào thẩm quyền nguồn dữ liệu, tính cập nhật thời gian hoặc báo cáo lên cấp cao hơn, chứ không được nhắm mắt biểu quyết theo số đông. Bước hợp nhất có thể được thiết lập điểm lưu trạng thái để khi cần thử lại khâu tổng hợp sẽ không phải chạy lại các tác tử tốn kém chi phí. Quyền nghiệm thu các tác vụ có rủi ro cao bắt buộc phải thuộc về người phụ trách kết quả kinh doanh bằng sự kiểm duyệt trực tiếp của con người.

13. Máy trạng thái phiên chạy bao gồm các trạng thái: đã lập kế hoạch, đang trong hàng đợi, đang chạy, chờ dữ liệu đầu vào hoặc phê duyệt hoặc nhánh phụ thuộc, đang thử lại, hoạt động suy giảm, đã hoàn thành, thất bại, đã hủy và đã bù trừ khi cần. Các tác vụ con có trạng thái riêng nhưng tác vụ cha sẽ suy luận trạng thái tổng thể một cách thận trọng; sự cố ở một nhánh phụ không nhất thiết làm hỏng toàn bộ phiên chạy. Các bước chuyển đổi trạng thái hợp lệ, chủ thể thực hiện, lý do, số thứ tự phiên bản và mốc thời gian đều phải được ghi nhận minh bạch. Trạng thái kết thúc mang tính bất biến ngoại trừ trường hợp có sự kiện đính chính đặc biệt. Cơ chế kiểm soát đồng thời lạc quan hoặc mô hình lưu trữ sự kiện giúp ngăn chặn các bản cập nhật lỗi thời. Cần phân biệt rõ việc hết thời gian chờ khác với thất bại hoàn toàn; lệnh hủy bỏ là nỗ lực tối đa; và việc hoàn tất kỹ thuật khác với nghiệm thu nghiệp vụ. Trạng thái bền vững phải tồn tại an toàn kể cả khi tiến trình hệ thống bị khởi động lại. Giao diện người dùng phải hiển thị trạng thái thực tế thay vì chỉ hiện biểu tượng vòng tròn chờ đợi. Kịch bản kiểm thử cần bao quát các tình huống hoàn thành hoặc hủy bỏ đồng thời, tác tử phản hồi muộn, sự kiện bị trùng lặp, sự cố sập giữa lúc gọi công cụ và ghi trạng thái, cùng khả năng khôi phục sau lỗi. Trạng thái phiên chạy phản ánh sự thật về mặt vận hành, trong khi hệ thống kinh doanh cốt lõi mới là cơ quan thẩm quyền duy nhất xác nhận các tác động ngoại vi đã được ghi nhận.

14. Ngữ nghĩa truyền thông điệp cần định nghĩa tách biệt giữa lệnh thực thi, sự kiện, truy vấn, phản hồi và tham chiếu sản phẩm đầu ra. Cơ chế chuyển giao qua hàng đợi thường hoạt động theo chuẩn gửi ít nhất một lần; do đó bên tiếp nhận xử lý phải có khả năng chống xử lý trùng và chỉ xác nhận đã nhận tin sau khi dữ liệu đã được lưu trữ bền vững. Phong bì thông điệp bao gồm mã định danh của thông điệp, tác vụ, phiên chạy và tác vụ con, bên phát hành và phiên bản phần mềm, khách hàng (tenant), quan hệ nguyên nhân và tương quan, cấu trúc dữ liệu, thời hạn chót, số lần thử và siêu dữ liệu kiểm tra tính toàn vẹn—tuyệt đối không gửi kèm khóa bảo mật hoặc toàn bộ bộ nhớ theo mặc định. Thứ tự tin nhắn chỉ nên đảm bảo ở những nơi thật sự cần thiết qua phân vùng hoặc số thứ tự; vì duy trì thứ tự toàn cục tốn kém chi phí rất lớn. Hàng đợi thư chết phải có chính sách phân loại, quy trình chạy lại và bảo vệ an toàn cho dữ liệu bên trong. Các thông điệp lỗi độc hại không được phép lặp lại vô tận. Áp lực tải ngược và thời gian ẩn thông điệp cần được tinh chỉnh hợp lý. Sổ đăng ký cấu trúc dữ liệu giúp quản lý sự thay đổi phiên bản. Việc phát lại sự kiện không làm lặp lại các tác động ngoại vi bên ngoài nhờ cơ chế chống xử lý trùng, cùng mô hình hộp thư đi và hộp thư đến. Việc máy chủ hàng đợi nhận tin thành công không đồng nghĩa với việc tác tử đã hoàn thành công việc.

15. Ranh giới ngữ cảnh trả lời câu hỏi cốt lõi: mỗi tác tử cần biết thông tin gì ngay tại thời điểm hiện tại. Bộ điều phối nắm giữ mục tiêu chung, kế hoạch, chính sách an toàn và danh mục sản phẩm đầu ra; trong khi tác tử thực thi chỉ nhận mục tiêu giới hạn, các nguồn dữ liệu tin cậy liên quan, ràng buộc quy định và cấu trúc dữ liệu đầu ra. Không bao giờ chia sẻ toàn bộ bản ghi hội thoại toàn cục theo mặc định. Mỗi mục thông tin trong ngữ cảnh cần gắn kèm nguồn gốc, mốc thời gian, mức độ tin cậy, độ nhạy cảm và phân quyền truy cập. Bộ lọc đầu vào có nhiệm vụ loại bỏ kết quả công cụ không liên quan, dữ liệu cá nhân, thông tin bảo mật và các dấu hiệu bị tiêm câu lệnh độc hại. Các bản tóm tắt phải dẫn liên kết tới tài liệu gốc và ghi rõ các điểm lưu ý cảnh báo. Bộ tạo dựng ngữ cảnh phải tuân thủ phân quyền đối tượng, phân vùng khách hàng và ngân sách token cho phép. Tác tử thực thi trả về các phát hiện cô đọng hoặc sản phẩm đầu ra có cấu trúc thay vì gửi toàn bộ quỹ đạo thao tác thô. Bản chụp nhanh ngữ cảnh và phiên bản trong vết truy vết hỗ trợ việc đánh giá hiệu năng mà không cần ghi lại chuỗi suy nghĩ nội bộ. Bộ nhớ đệm câu lệnh prompt tuyệt đối không được lưu giữ những nội dung đã bị thu hồi quyền hoặc lỗi thời. Ngữ cảnh tinh gọn giúp giảm nhiễu và hạn chế lộ lọt dữ liệu nhưng có thể vô tình bỏ sót các phần việc phụ thuộc; vì vậy giao ước phải quy định rõ các tài liệu tham chiếu bắt buộc và cung cấp lộ trình để tác tử yêu cầu cấp thêm ngữ cảnh khi cần.

16. Phân loại bộ nhớ phân định rạch ròi giữa: ngữ cảnh mô hình, trạng thái phiên chạy và điểm lưu trạng thái (checkpoint), sản phẩm đầu ra của tác vụ, bộ nhớ dài hạn (gồm bộ nhớ ngữ nghĩa, bộ nhớ sự kiện và bộ nhớ quy trình), bản ghi của hệ thống nguồn sự thật và bằng chứng kiểm toán. Các tầng này khác biệt hoàn toàn về thẩm quyền, phạm vi, tần suất cập nhật, thời hạn lưu giữ và quyền riêng tư. Ngữ cảnh là dữ liệu đầu vào tạm thời. Điểm lưu trạng thái cho phép tiếp tục phiên chạy sau gián đoạn, chứ không phải cơ sở dữ liệu thực tế. Sản phẩm đầu ra là kết quả tác vụ cần được nghiệm thu. Bộ nhớ dài hạn là dữ liệu dẫn xuất có nguy cơ bị lỗi thời. Hệ thống nguồn mới là nơi nắm giữ thẩm quyền chuẩn xác nhất về khách hàng, đơn hàng và các chính sách quy định. Bằng chứng kiểm toán ghi lại trung thực những gì đã diễn ra. Việc gộp chung tất cả các khái niệm này dưới tên gọi bộ nhớ sẽ dẫn đến những thao tác ghi và truy xuất dữ liệu mất an toàn. Mỗi tầng dữ liệu cần có cấu trúc chuẩn, người phụ trách, không gian định danh, chính sách truy cập, thời hạn lưu giữ tối đa (TTL), nguồn gốc dữ liệu, cơ chế đính chính, xóa bỏ và kế hoạch sao lưu. Tác tử không thể tự tiện nâng một phỏng đoán trong hội thoại thành nguồn sự thật chỉ bằng cách lưu nó lại.

17. Ngữ cảnh làm việc tồn tại bên trong một lượt tương tác hoặc một phiên chạy và phải được tinh chọn gắt gao. Nó bao gồm mục tiêu hiện tại, các ràng buộc, phần kế hoạch đang thực thi, cấu trúc công cụ, những quan sát mới nhất và tham chiếu đến sản phẩm đầu ra. Toàn bộ lịch sử trao đổi phải được tóm tắt và cô đọng khi cần thiết, đồng thời bảo toàn các quyết định, vấn đề tồn đọng, phê duyệt và liên kết bằng chứng. Kết quả từ công cụ được coi là chưa đáng tin cậy cho đến khi được kiểm tra hợp lệ. Độ dài của ngữ cảnh không phải là bộ nhớ miễn phí; càng nhiều token sẽ càng làm tăng chi phí, độ trễ và gây phân tâm cho mô hình AI. Mỗi tác tử sở hữu một cửa sổ ngữ cảnh độc lập giúp các tác tử chạy song song mở rộng năng lực xử lý, nhưng việc sao chép ngữ cảnh chung trùng lặp sẽ nhân bội chi phí. Cần thiết lập ngân sách ngữ cảnh cho từng vai trò và tác vụ, kết hợp truy xuất thông tin theo nhu cầu thực tế. Dữ liệu thô nhạy cảm nên được giữ an toàn phía sau các công cụ bất cứ khi nào có thể. Khi bàn giao tác vụ, bộ lọc rõ ràng sẽ kiểm soát chặt chẽ những nội dung được phép chuyển giao. Việc khôi phục khi mất ngữ cảnh phải dựa vào các điểm lưu trạng thái và sản phẩm đầu ra, chứ không trông cậy vào khả năng nhớ lại mơ hồ của mô hình.

18. Điểm lưu trạng thái (checkpoint) chụp lại trạng thái đồ thị và phiên chạy tại một ranh giới nhất quán: trạng thái từng nút, các lệnh đang chờ xử lý, tham chiếu sản phẩm đầu ra, phiên bản kế hoạch, ngân sách, thông tin phê duyệt và khóa chống xử lý trùng. Điểm lưu cần tránh việc nhúng trực tiếp các token đang hoạt động, kết nối mạng trực tiếp hoặc các kết quả thô có dung lượng khổng lồ. Khoảng cách giữa các lần lưu trạng thái phải cân bằng giữa chi phí làm lại công việc, dung lượng lưu trữ và tính nhất quán dữ liệu; các thời điểm trước và sau khi kích hoạt tác động ngoại vi đòi hỏi mô hình giao dịch chặt chẽ hoặc bước đối soát, bởi việc đảm bảo tính toàn vẹn tuyệt đối xuyên suốt giữa mô hình, công cụ và kho lưu trữ là rất khó khăn. Khung phát triển LangGraph cung cấp tài liệu về các bộ lưu trạng thái cho luồng trao đổi, sự can thiệp của con người và khả năng chịu lỗi; tuy nhiên việc triển khai trên môi trường thực tế vẫn đòi hỏi tính bền vững, mã hóa dữ liệu và chính sách lưu giữ nghiêm ngặt. Việc ghi nhận thành công các bước trước đó sẽ ngăn chặn việc chạy lại các nút đã hoàn tất. Quá trình nâng cấp cấu trúc dữ liệu và kiểm thử phục hồi đóng vai trò sống còn. Mã luồng hoặc mã điểm lưu không thể thay thế cho cơ chế ủy quyền. Khi khôi phục từ điểm lưu, hệ thống bắt buộc phải xác thực lại định danh, chính sách an toàn và thời hạn chót, chứ không thể nhắm mắt kích hoạt lại những đặc quyền đã lỗi thời.

19. Sản phẩm đầu ra của tác vụ (artifact) là những đơn vị bàn giao bền vững: ghi chú nghiên cứu, bảng biểu có cấu trúc, bản vá mã nguồn, bản kế hoạch, bảng tính toán, báo cáo kiểm tra hợp lệ hoặc biên bản quyết định. Mỗi sản phẩm đầu ra đều có mã định danh, phiên bản, cấu trúc dữ liệu, mã băm nội dung, phiên bản của tác tử, mô hình và công cụ tạo ra nó, tham chiếu nguồn và bằng chứng, mức độ nhạy cảm, định danh khách hàng (tenant), trạng thái (bản nháp, đã xác thực, đã nghiệm thu hoặc đã bị thay thế) và thời hạn lưu giữ. Các tác tử thực thi ghi dữ liệu vào kho lưu trữ sản phẩm đầu ra và chỉ trả về một đường dẫn tham chiếu cô đọng. Các phiên bản mang tính bất biến giúp ngăn chặn việc các tác tử vô tình ghi đè lên nhau; quá trình hợp nhất sẽ tạo ra một phiên bản mới đi kèm chuỗi truy vết nguồn gốc. Các tệp nhị phân hoặc tập tin dung lượng lớn phải được quét mã độc, xử lý trong môi trường cô lập và cung cấp đường dẫn có ràng buộc quyền truy cập. Tiêu chí nghiệm thu và bộ phận kiểm tra hợp lệ phải tách biệt độc lập với tác tử tạo ra sản phẩm. Sản phẩm đầu ra hỗ trợ việc phát lại, tiếp tục phiên chạy và nén gọn ngữ cảnh. Chúng không đương nhiên trở thành bộ nhớ dài hạn hay được ghi nhận trực tiếp vào hệ thống nguồn sự thật. Mọi sự đính chính phải bảo toàn lịch sử nguồn gốc và lập tức hủy bỏ giá trị của các bên tiếp nhận phía sau khi có thay đổi quan trọng.

20. Bộ nhớ dài hạn phải được kiểm soát quyền ghi một cách nghiêm ngặt. Bộ nhớ ngữ nghĩa lưu trữ các dữ kiện và sở thích; bộ nhớ sự kiện tóm tắt các cuộc tương tác trong quá khứ; bộ nhớ quy trình lưu lại các hướng dẫn hoặc khuôn mẫu đã đúc kết được. Mỗi mục nhớ đều phải gắn kèm nguồn gốc, chủ thể, độ tin cậy, trạng thái quan sát thực tế hay dẫn xuất suy luận, thời gian có hiệu lực, thời hạn hết hạn và lịch sử đính chính. Sở thích của người dùng có thể được lưu trữ với tính minh bạch và quyền kiểm soát rõ ràng; nhưng dữ kiện kinh doanh bắt buộc phải dẫn chiếu tới nguồn dữ liệu có thẩm quyền. Quá trình trích xuất bộ nhớ phải chạy qua cấu trúc chuẩn, bộ lọc kiểm duyệt và thường cần có khâu rà soát ngầm, chứ không thể đổ toàn bộ bản ghi hội thoại thô vào kho lưu trữ. Trước khi sử dụng, việc truy xuất phải dựa trên khách hàng, người dùng, mục đích sử dụng, phân quyền, độ liên quan, tính cập nhật và mức độ tin cậy; các ký ức mâu thuẫn hoặc lỗi thời phải được xử lý triệt để. Bộ nhớ không thể tự cấp quyền hạn. Dữ liệu nhạy cảm phải được tối thiểu hóa và mã hóa an toàn. Các yêu cầu xóa bỏ hoặc đính chính phải được lan truyền đồng bộ. Cần đánh giá bộ nhớ dựa trên tính hữu ích, độ chính xác, nguy cơ gây hại do dữ liệu cũ và quyền riêng tư—chứ không dựa trên số lượng bản ghi bộ nhớ được lưu trữ.

21. Nguồn sự thật gốc của doanh nghiệp vẫn luôn là hệ thống CRM, ERP, sổ đăng ký văn bản, kho lưu trữ chính sách hoặc các hệ thống nghiệp vụ chuyên dụng đã được phê duyệt. Các tác tử chỉ được phép đọc dữ liệu qua những công cụ có kiểm soát và chỉ ghi nhận giao dịch thông qua các lệnh đã được xác thực hợp lệ. Bộ nhớ hay sản phẩm đầu ra của hệ thống đa tác tử tuyệt đối không được phép tự ý âm thầm ghi đè lên các bản ghi chủ. Mỗi tác động ngoại vi đều phải sử dụng phiên bản đối tượng dữ liệu, thông tin ủy quyền, cơ chế chống xử lý trùng và xác thực quy tắc nghiệp vụ; nếu phát sinh xung đột, hệ thống phải trả về để lập lại kế hoạch. Sau khi giao dịch được xác nhận, bộ đối soát sẽ ghi nhận mã định danh, phiên bản và trạng thái thực tế. Bộ nhớ đệm, chỉ mục tìm kiếm và kho lưu trữ vector cần có cơ chế quản lý độ tươi mới, hủy bỏ bản ghi hết hạn và liên kết chặt chẽ với nguồn gốc dữ liệu. Nếu hệ thống nguồn đính chính dữ liệu, các sản phẩm đầu ra và bộ nhớ dẫn xuất liên quan phải lập tức bị đánh dấu là lỗi thời. Tính nhất quán sau cùng của dữ liệu cần được công bố minh bạch. Trong các lĩnh vực tài chính và pháp lý, bản ghi có thẩm quyền và quy tắc phê duyệt bắt buộc phải tuân thủ các biện pháp kiểm soát chuyên ngành. Thiết kế kiến trúc phải phân biệt rạch ròi giữa đề xuất thay đổi với thay đổi đã được ghi nhận chính thức trên cả giao diện người dùng lẫn bằng chứng kiểm toán.

22. Chính sách ghi bộ nhớ xác định rõ ràng tác tử nào được phép ghi vào tầng dữ liệu nào. Tác tử thực thi thông thường chỉ được ghi các sản phẩm đầu ra hoặc điểm lưu trạng thái cục bộ; bộ điều phối có quyền đề xuất nội dung lưu vào bộ nhớ; trong khi bộ kiểm tra và cổng chính sách sẽ rà soát cấu trúc dữ liệu, nguồn gốc, sự trùng lặp, độ tin cậy, tính nhạy cảm, sự đồng ý của chủ thể dữ liệu, thời hạn lưu giữ (TTL) và các xung đột tiềm ẩn trước khi đưa vào kho bộ nhớ dài hạn. Mọi thao tác ghi vào hệ thống nguồn sự thật bắt buộc phải thông qua công cụ nghiệp vụ chuyên dụng và quy trình phê duyệt. Nội dung bộ nhớ trích xuất từ văn bản bên ngoài luôn bị xem là chưa đáng tin cậy; tuyệt đối không lưu giữ những chỉ dẫn bị nhúng ngầm dưới dạng quy trình vận hành. Thao tác ghi phải có tính chống xử lý trùng và quản lý phiên bản; mọi cập nhật đều phải tạo ra chuỗi truy vết nguồn gốc. Bộ nhớ quy trình có tầm ảnh hưởng lớn bắt buộc phải có sự kiểm duyệt và đánh giá của con người vì nó có thể làm thay đổi hành vi của hệ thống trong tương lai. Quá trình hợp nhất bộ nhớ chạy ngầm phải đảm bảo cách ly theo khách hàng (tenant) và tuân thủ ngân sách tính toán. Những đề xuất bị từ chối chỉ được lưu giữ ở mức tối thiểu hoặc loại bỏ hoàn toàn. Người dùng có quyền kiểm tra, chỉnh sửa hoặc xóa bỏ sở thích cá nhân khi thích hợp. Dữ liệu đo từ xa về việc ghi bộ nhớ cần đo lường tỷ lệ chấp thuận và tính hữu ích hoặc nguy cơ gây hại sau đó. Không một tác tử nào được phép tự ý ghi vào bộ nhớ toàn cục dùng chung chỉ vì nó nghĩ rằng mình vừa học được một điều gì đó mới mẻ trong một phiên chạy đơn lẻ.

23. Lựa chọn giữa bộ nhớ dùng chung và bộ nhớ cục bộ là một quyết định về phạm vi ảnh hưởng. Vùng nháp cục bộ của tác tử thực thi giúp tránh gây nhiễu và có thể hủy bỏ ngay sau khi hoàn thành nhiệm vụ. Trạng thái dùng chung trong một phiên chạy chứa kế hoạch, danh mục sản phẩm đầu ra và các mối phụ thuộc đã được xác thực; việc ghi dữ liệu phải thông qua bộ điều phối hoặc dịch vụ quản lý trạng thái có kiểm soát đồng thời. Bộ nhớ theo người dùng hoặc theo khách hàng (tenant) có thể kéo dài qua nhiều phiên chạy nhưng bắt buộc phải có phân quyền, mục đích sử dụng rõ ràng và vòng đời quản lý. Tri thức của tổ chức phải được lưu trữ trong các hệ thống quản trị tri thức hoặc hệ thống nguồn chuẩn mực, chứ không thể nằm rải rác trong bộ nhớ tự do của các tác tử. Bộ nhớ toàn cục dùng chung xuyên suốt giữa các khách hàng khác nhau bị nghiêm cấm theo mặc định. Mô hình bảng tin chia sẻ (blackboard) có thể giúp điều phối các tác tử ngang hàng nhưng cần có các bản ghi định kiểu rõ ràng, quyền sở hữu, khóa đồng thời, kiểm soát phiên bản hoặc chuỗi sự kiện chỉ ghi thêm, đi kèm chính sách xử lý xung đột và dọn dẹp định kỳ. Các bên đọc dữ liệu phải lọc thông tin theo vai trò và tác vụ. Thông báo về các thay đổi sẽ ngăn chặn các quyết định dựa trên dữ liệu lỗi thời. Việc nhân bản dữ liệu đôi khi còn an toàn hơn việc chia sẻ một ngữ cảnh biến đổi dùng chung cho các nhánh công việc độc lập. Thiết kế kiến trúc tối ưu luôn ưu tiên cơ chế truyền tải sản phẩm đầu ra có cấu trúc thay vì cho phép đọc và ghi tự do trên toàn bộ bản ghi trò chuyện.

24. Mô hình nhất quán dữ liệu phải được quy định rõ ràng. Tính nhất quán mạnh được áp dụng cho phân quyền, quản lý ngân sách, khóa chống xử lý trùng, xác nhận giao dịch và một số khâu phê duyệt; trong khi tính nhất quán sau cùng phù hợp cho phân tích, chỉ mục tìm kiếm, bộ nhớ ngữ nghĩa và kho dữ liệu vector. Sản phẩm đầu ra và các điểm lưu trạng thái đòi hỏi cơ chế đọc chính những gì vừa ghi hoặc đọc đơn điệu trong cùng một phiên chạy để tác tử và bước hợp nhất không gặp phải trạng thái thụt lùi. Bản chụp nhanh và quản lý phiên bản của bộ điều phối giúp ngăn chặn xung đột tương tranh. Xung đột giữa hai thao tác ghi trên bảng tin chia sẻ được giải quyết bằng cơ chế khóa, kiểm tra phiên bản lạc quan hoặc nhật ký chỉ ghi thêm. Nếu hệ thống phía sau chỉ đạt tính nhất quán sau cùng, tác tử không được mặc định rằng dữ liệu đọc lại ngay sau khi ghi sẽ hiển thị tức thì; mà cần truyền phiên bản rõ ràng hoặc nhận kết quả trả về trực tiếp. Giao tiếp với đối tác bên ngoài phải tuân thủ ranh giới giao dịch nghiệp vụ; áp dụng mô hình chuỗi giao dịch bù trừ (saga) thay vì cơ chế cam kết hai pha phức tạp và khó duy trì. Mọi tầng dữ liệu đều phải có tài liệu quy định rõ mức độ bảo đảm.

25. Quyền riêng tư và cách ly khách hàng (tenant) phải áp dụng xuyên suốt đồ thị tác vụ. Cần phân tách không gian định danh riêng cho từng khách hàng đối với ngữ cảnh, điểm lưu trạng thái, sản phẩm đầu ra, bộ nhớ, hàng đợi, bộ nhớ đệm, vết truy vết, môi trường cô lập, bộ sưu tập vector và khóa ủy quyền công cụ. Không để rò rỉ dữ liệu chéo giữa các khách hàng là yêu cầu bắt buộc tối thiểu. Các tác tử xử lý tác vụ nhạy cảm phải chạy trong bộ chứa hoặc môi trường cô lập riêng; mã truy cập công cụ chỉ có giá trị trong phiên làm việc của khách hàng và người dùng đó. Bộ lọc che giấu dữ liệu phải loại bỏ thông tin cá nhân và khóa bí mật trước khi ghi nhật ký hoặc trích xuất bộ nhớ. Phân loại dữ liệu quyết định nhà cung cấp mô hình AI nào được phép sử dụng; việc chuyển dữ liệu ra nước ngoài hoặc cho bên thứ ba phải tuân thủ quy định và sự đồng ý của chủ thể dữ liệu. Khi khách hàng ngừng dịch vụ hoặc yêu cầu xóa dữ liệu, quy trình dọn dẹp phải xóa sạch điểm lưu, sản phẩm đầu ra, bộ nhớ dẫn xuất, nhật ký và dữ liệu tinh chỉnh theo đúng lịch trình lưu giữ. Áp dụng mã hóa cấp khách hàng bằng khóa do khách hàng tự quản lý khi có yêu cầu. Kiểm toán cách ly phải bao gồm cả việc kiểm thử các đòn tấn công tiêm câu lệnh nhằm truy cập trái phép bộ nhớ của khách hàng khác.

26. Bảng phân loại lỗi giúp tách bạch giữa: mô hình từ chối hoặc trả ra kết quả không hợp lệ, lỗi công cụ hoặc nghiệp vụ, hết thời gian chờ hoặc vượt hạn mức của bên phụ thuộc, bị từ chối do phân quyền hoặc chính sách, tác tử thực thi bị sập, bộ điều phối bị sập, sự cố hàng đợi hoặc cơ sở dữ liệu, sai lệch cấu trúc dữ liệu, xung đột thông tin, vượt ngân sách hoặc thời hạn chót, người dùng phản hồi quá hạn và nội dung đầu ra thiếu an toàn. Mỗi lỗi phải có mã số, khả năng thử lại, phạm vi trách nhiệm, thông báo an toàn cho người dùng, bằng chứng và hành động xử lý tiếp theo. Một thông báo mơ hồ như tác tử thất bại là hoàn toàn không thể xử lý. Việc từ chối hợp lệ theo quy định phải khác biệt với sự cố kỹ thuật. Kết quả một phần có thể được chấp nhận kèm cảnh báo hoặc bắt buộc phải báo lỗi tùy tình huống. Ranh giới xử lý lỗi ngăn chặn việc làm lộ dấu vết ngăn xếp kỹ thuật hoặc khóa bí mật. Tác vụ cha ánh xạ lỗi của tác vụ con nhưng không xóa bỏ nguồn gốc ban đầu. Thống kê theo phân loại lỗi sẽ chỉ rõ vấn đề nằm ở câu lệnh prompt, giao ước dữ liệu hay hạ tầng kỹ thuật. Sổ tay vận hành ánh xạ từng triệu chứng với phương án khoanh vùng và khắc phục. Các lỗi chưa xác định phải được đưa về trạng thái an toàn theo mặc định và chuyển sang khâu kiểm duyệt, thay vì để hệ thống tự sửa sai vô hạn.

27. Chính sách thử lại phải được thiết kế riêng cho từng loại thao tác. Chỉ thử lại đối với các lỗi mạng tạm thời, lỗi HTTP 429/5xx đi kèm cơ chế giãn cách tăng theo cấp số nhân, độ trễ ngẫu nhiên, thời hạn chót và số lần thử tối đa; tuyệt đối không thử lại khi gặp lỗi sai cấu trúc dữ liệu, bị chính sách từ chối hoặc xung đột nghiệp vụ cố định mà không có sự thay đổi. Việc thử lại mô hình AI cần điều chỉnh câu lệnh prompt, ngữ cảnh hoặc chiến lược trong giới hạn cho phép và phải ghi nhận từng lần thử; việc lấy mẫu lặp đi lặp lại không phải bằng chứng chứng minh đã sửa được sai. Thử lại khi gọi công cụ đòi hỏi phải có khóa chống xử lý trùng và nắm rõ trạng thái giao dịch. Ngân sách thử lại phải được phân cấp để các tác tử con không tiêu tốn vô hạn ngân sách của tác vụ cha. Cơ chế gửi lệnh dự phòng chỉ áp dụng cho các thao tác đọc an toàn và phải lập tức hủy nhánh chậm hơn. Ngăn chặn bão thử lại bằng bộ ngắt mạch và khâu tiếp nhận có kiểm soát. Khi đã cạn số lần thử, hệ thống phải chọn phương án dự phòng, chấp nhận kết quả một phần, chuyển cho con người hoặc báo lỗi dứt khoát. Các lần thử lại dùng chung nguyên nhân nhưng phải có mã định danh riêng biệt. Các chỉ số theo dõi gồm tỷ lệ khôi phục thành công, tác động ngoại vi bị trùng lặp, độ trễ phát sinh và chi phí tăng thêm. Lệnh hủy từ người dùng phải lập tức dừng mọi lịch thử lại đã lên.

28. Khả năng chống xử lý trùng mang ý nghĩa nghiệp vụ chứ không đơn thuần là một tiêu đề HTTP. Khóa chống trùng được tạo từ khách hàng (tenant), tác vụ, hành động, đối tượng và phiên bản, đồng thời được giữ nguyên xuyên suốt các lần thử lại hoặc chuyển đổi dự phòng; tài nguyên sẽ lưu giữ kết quả và trạng thái một cách trọn vẹn. Nếu cùng một khóa nhưng gửi kèm nội dung khác nhau thì phải báo lỗi xung đột. Thao tác đọc nhìn chung là an toàn nhưng việc gọi lặp lại vẫn gây tốn kém chi phí và chạm hạn mức. Các thao tác gửi email, thanh toán, tạo mới hoặc cập nhật trên CRM và xuất bản tệp tin đều cần cơ chế chống trùng từ nhà cung cấp hoặc phải có sổ cái ghi nhận lệnh nội bộ và bước đối soát. Doanh nghiệp không nên kỳ vọng hệ thống tự đạt chuẩn gửi tin chính xác một lần; mục tiêu thực tế là đạt hiệu quả tác động ngoại vi chỉ xảy ra một lần duy nhất. Hộp thư đi ghi nhận sự kiện dự kiến cùng giao dịch; hộp thư đến chịu trách nhiệm lọc trùng các lệnh nhận được. Tác tử hoặc mô hình AI tuyệt đối không được tự ý tạo ra một mã khóa mới khi gặp lỗi hết thời gian chờ để thử lại. Thời gian lưu trữ khóa phải bao quát toàn bộ khoảng thời gian phát lại và phục hồi tối đa. Các bài kiểm thử sự cố sập phải diễn ra ngay trước và sau khi gửi yêu cầu, nhận phản hồi hoặc ghi trạng thái. Hành động đền bù phải là một thao tác độc lập với khóa chống trùng và bằng chứng riêng.

29. Khôi phục từ điểm lưu trạng thái và phát lại giúp tái lập trạng thái bền vững gần nhất, xác thực phiên bản phiên chạy và tác vụ, quyền hạn hiện tại, thời hạn chót, ngân sách và các mối phụ thuộc, sau đó chỉ lên lịch cho những nút tác vụ an toàn chưa hoàn thành. Các sản phẩm đầu ra đã thành công và các thao tác ghi đang chờ sẽ được tái sử dụng. Các lệnh gọi ra bên ngoài có kết quả chưa rõ ràng phải được đối soát kỹ lưỡng trước khi thử lại. Khả năng phát lại xác định chỉ khả thi đối với các bước chuyển đổi mã lập trình và sự kiện, chứ không áp dụng cho kết quả của mô hình AI trừ khi toàn bộ đầu vào, phiên bản mô hình được ghi lại và dịch vụ có tính tái hiện tuyệt đối; tốt nhất hãy sử dụng sản phẩm đầu ra đã ghi nhận thay vì giả định AI sẽ tái tạo lại y hệt. Khóa bảo mật và mã token phải được cấp mới lại. Kế hoạch bị lỗi thời hoặc tác tử bị thu hồi quyền sẽ kích hoạt việc lập lại kế hoạch hoặc chuyển sang con người rà soát. Kiểm thử khôi phục phải bao gồm cả việc chuyển đổi cấu trúc dữ liệu và chuyển đổi vùng dự phòng. Các quy định về mã hóa, thời hạn lưu giữ điểm lưu và phân quyền khách hàng phải được áp dụng nghiêm ngặt. Sự kiện phục hồi cần liên kết giữa phiên chạy cũ với phiên chạy mới và giải thích rõ các điểm khác biệt. Không cần ghi lại chuỗi suy nghĩ nội bộ; trạng thái vận hành và các quyết định cốt lõi là hoàn toàn đầy đủ.

30. Xử lý lỗi cục bộ bắt đầu bằng việc phân loại mức độ trọng yếu của từng nhánh công việc và quy tắc hợp nhất. Sự cố ở một tác tử tùy chọn có thể dẫn đến một sản phẩm đầu ra cuối cùng ở mức hoạt động suy giảm đi kèm ghi chú rõ ràng về phạm vi bị thiếu; trong khi sự cố ở nhánh trọng yếu bắt buộc phải chặn đứng việc hoàn thành quy trình. Cần bảo toàn các sản phẩm đầu ra đã thành công để tránh phải chạy lại lãng phí. Tác vụ cha có thể quyết định thử lại, chọn phương án dự phòng đã duyệt, phân chia lại công việc, tham vấn ý kiến con người hoặc dừng hẳn quy trình. Cơ chế biểu quyết đa số chỉ áp dụng khi các tác tử thực sự độc lập và tiêu chuẩn đánh giá cho phép; những lỗi tương quan do dùng chung mô hình hay nguồn dữ liệu sẽ khiến việc biểu quyết trở nên sai lệch nghiêm trọng. Khâu tổng hợp phía sau tuyệt đối không được che giấu những bằng chứng bị thiếu hoặc bị lỗi. Giao diện người dùng và trạng thái hệ thống phải hiển thị rõ mức độ suy giảm. Những nhánh có tác động ngoại vi đã thực hiện thành công có thể cần hành động đền bù nếu toàn bộ chuỗi nghiệp vụ thất bại. Hạch toán chi phí phải tính cả những nhánh công việc bị bỏ dở. Mức độ nghiêm trọng của sự cố phải đo bằng tác động kinh doanh thực tế chứ không phải số lượng nút báo đỏ trên sơ đồ. Bản thân quyết định phục hồi cũng phải được kiểm toán và giới hạn thời gian rõ ràng.

31. Thời gian chờ tối đa, thời hạn chót và lệnh hủy bỏ phải được lan truyền đồng bộ dọc theo đồ thị tác vụ. Tác vụ cha quy định một thời hạn chót tuyệt đối; tác vụ con sẽ nhận một khoảng thời gian ngắn hơn để chừa thời gian dự phòng cho bước hợp nhất và tổng hợp. Các lệnh gọi công cụ phải có thời gian chờ kết nối, đọc dữ liệu, thực thi và hỗ trợ cơ chế hủy bỏ. Trạng thái hủy sẽ ngăn chặn việc phân phối tác vụ mới, gửi tín hiệu dừng tới các tác tử đang hoạt động, thu hồi các quyền hạn gắn với tác vụ và tiến hành đối soát sản phẩm đầu ra cùng các tác động ngoại vi. Một yêu cầu mạng đã bị hủy vẫn có thể đã hoàn tất giao dịch ở hệ thống từ xa, vì vậy cơ chế chống xử lý trùng và bước đối soát là bắt buộc. Nhịp tim định kỳ hoặc cơ chế thuê bao quyền của tác tử giúp phát hiện các tác vụ mồ côi mà không tạo ra nhiều bên cùng nhận quyền sở hữu. Kết quả gửi về muộn bị đánh dấu là lỗi thời và không được sáp nhập trừ khi có quy trình phục hồi rõ ràng. Thời gian chờ con người phê duyệt phải có hạn định hết hạn và cơ chế chuyển tiếp cấp cao hơn. Khi vượt quá thời hạn chót, hệ thống có thể trả về sản phẩm đầu ra an toàn một phần thay vì cố tình ngụy tạo kết quả hoàn chỉnh. Các thông điệp trong hàng đợi đã quá hạn phải bị loại bỏ hoặc chuyển vào hàng đợi thư chết. Cam kết chất lượng dịch vụ (SLO) cần đo lường tốc độ lan truyền lệnh hủy và hiệu quả dọn dẹp các tác vụ mồ côi.

32. Bộ ngắt mạch (circuit breaker) bảo vệ các hệ thống phụ thuộc và toàn bộ mạng lưới tác tử. Cần theo dõi tỷ lệ lỗi và thời gian chờ theo từng nhà cung cấp, mô hình AI, công cụ, tác tử, khách hàng và loại thao tác; bộ ngắt mạch sẽ tự động mở ra khi vượt ngưỡng cho phép, từ chối yêu cầu hoặc chuyển hướng sang phương án dự phòng an toàn, sau đó thăm dò ở trạng thái mở một nửa và đóng lại khi hệ thống đã hồi phục. Việc bị từ chối do chính sách bảo mật hoặc dữ liệu đầu vào không hợp lệ không được phép làm ngắt mạch hệ thống phụ thuộc. Trạng thái bộ ngắt mạch được chia sẻ giữa các máy chủ nhưng phải giới hạn phạm vi ảnh hưởng theo từng khách hàng và tài nguyên. Cần tuân thủ thời gian chờ trước khi thử lại theo phản hồi của hệ thống. Vách ngăn sự cố giúp cô lập các cụm tác tử và ngân sách để sự cố của một agent không làm kiệt quệ tài nguyên toàn hệ thống. Bộ giới hạn tần suất, thùng chứa token và cờ hiệu kiểm soát đồng thời phải được áp dụng trước khi điều phối tác vụ. Khâu kiểm tra sức khỏe hệ thống phải đảm bảo an toàn và không gây ra tác động ngoại vi. Phương án dự phòng phải được phê duyệt trước với mức kiểm soát tương đương hoặc chấp nhận suy giảm có chủ đích; tuyệt đối không hạ thấp chính sách bảo mật dữ liệu hoặc định danh chỉ để duy trì thời gian hoạt động. Cảnh báo, sổ tay vận hành và quyền can thiệp thủ công phải được kiểm toán và giới hạn thời gian. Các bài kiểm thử hỗn loạn cần kiểm tra kỹ lưỡng các cuộc đua trạng thái giữa mở mạch, mở một nửa và phục hồi.

33. Phương án dự phòng và suy giảm chất lượng có kiểm soát phải được thiết kế từ trước. Các phương án gồm: chuyển sang mô hình AI nhỏ hơn hoặc mô hình thay thế cho các tác vụ trích xuất ít rủi ro, sử dụng dữ liệu nguồn trong bộ nhớ đệm có gắn nhãn thời gian, áp dụng quy tắc hoặc quy trình cố định bằng mã lập trình, chuyển sang tác tử hoặc nhà cung cấp thay thế đã được phê duyệt, quay về lộ trình một agent đơn lẻ, chuyển vào hàng đợi chờ con người xử lý hoặc trả về kết quả ở chế độ chỉ đọc. Mỗi phương án đều phải có điều kiện áp dụng dựa trên tác vụ, loại dữ liệu, mức độ rủi ro và cảnh báo chất lượng rõ ràng. Cấu trúc dữ liệu đầu ra và nguồn gốc của phương án dự phòng phải đủ tương đồng để phục vụ bước hợp nhất. Không được âm thầm chuyển đổi vùng địa lý hoặc nhà cung cấp nếu điều đó làm thay đổi quy định lưu trữ dữ liệu hoặc điều khoản hợp đồng. Tuyệt đối không dùng phương án dự phòng để vượt qua sự từ chối phân quyền. Bộ nhớ đệm lỗi thời không bao giờ được dùng cho các quyết định trọng yếu nếu thiếu chính sách cho phép. Chế độ suy giảm phải tắt bỏ các tác động ngoại vi hoặc đòi hỏi quy trình phê duyệt nghiêm ngặt hơn. Cần so sánh chất lượng và chi phí của phương án dự phòng trong các đợt đánh giá. Khi hệ thống chính phục hồi, việc chuyển hướng lưu lượng phải tiến hành từng bước qua nhóm nhỏ thử nghiệm để tránh gây quá tải dồn dập. Người dùng cần được thông báo minh bạch về những hạn chế thực tế và có quyền lựa chọn chờ đợi hệ thống hồi phục hoàn toàn.

34. Sự can thiệp của con người được kích hoạt khi xuất hiện sự mơ hồ, ủy quyền công cụ có ảnh hưởng lớn, mâu thuẫn dữ liệu, độ tin cậy thấp, yêu cầu phê duyệt theo chính sách, sự cố lặp lại nhiều lần hoặc khi khôi phục với tác động ngoại vi chưa rõ ràng. Hồ sơ kiểm duyệt trình lên con người bao gồm: ý định ban đầu, bản kế hoạch, các tác tử tham gia, dữ liệu và bằng chứng liên quan, bản xem trước hành động dự kiến, các điểm xung đột, lịch sử các lần thử, chi phí, thời gian và các phương án lựa chọn—tuyệt đối không hiển thị chuỗi suy nghĩ nội bộ thô của mô hình. Quyết định phê duyệt phải gắn liền với phiên bản phiên chạy, tác vụ, sản phẩm đầu ra, hành động cụ thể và thời hạn hiệu lực. Hệ thống phải kiểm tra vai trò, thẩm quyền và nguyên tắc bốn mắt phê duyệt độc lập. Con người có quyền chỉnh sửa dữ liệu đầu vào có cấu trúc, phê duyệt, từ chối, hủy bỏ hoặc điều hướng lại; mọi thay đổi sẽ lập tức làm vô hiệu hóa các sản phẩm đầu ra cũ phía sau. Hàng đợi phê duyệt phải có cam kết thời gian xử lý (SLA), cơ chế chuyển tiếp cấp cao hơn và thông báo an toàn. Ý kiến phản hồi của người duyệt sẽ trở thành dữ liệu đánh giá và đính chính có gắn nhãn, chứ không tự động biến thành chỉ dẫn dài hạn cho mô hình. Trải nghiệm người dùng cần ngăn chặn tình trạng phê duyệt chiếu lệ bằng cách làm nổi bật những điểm khác biệt và rủi ro chính yếu, đồng thời tinh gọn chính sách để giảm bớt các câu hỏi kiểm duyệt không cần thiết.

35. Đối soát phục hồi tiến hành tra vấn các hệ thống có thẩm quyền để xác định chính xác các tác động ngoại vi thực tế trước khi phát lại hoặc thực hiện hành động đền bù. Hệ thống so sánh lệnh dự kiến và khóa chống xử lý trùng với trạng thái, phiên bản và lịch sử thực tế của hệ thống bên ngoài. Phân loại trạng thái thành: đã ghi nhận, đang chờ xử lý, thất bại, chưa xác định hoặc xung đột. Nếu đã ghi nhận thành công, hệ thống lưu lại sản phẩm đầu ra cùng kết quả và bỏ qua bước chạy lại. Nếu đang chờ xử lý, hệ thống sẽ chờ đợi hoặc gửi lệnh thăm dò. Nếu thất bại, quy trình tiếp tục thử lại hoặc báo lỗi theo chính sách. Nếu chưa xác định, vụ việc phải chuyển lên con người hoặc kích hoạt lệnh thăm dò đối soát an toàn. Nếu hệ thống bên ngoài thiếu cơ chế chống trùng, việc đối soát phải dựa trên quy tắc nghiệp vụ chuyên ngành, mốc thời gian, mã định danh tương quan và nhật ký kiểm toán. Bộ đối soát vận hành bất đồng bộ hoặc đóng vai trò như một cổng kiểm soát trước khi tiếp tục quy trình làm việc. Bằng chứng kiểm toán phải liên kết chặt chẽ giữa hành động dự kiến, truy vấn đối soát và kết quả đã được xác minh. Báo cáo đối soát sẽ làm rõ các giao dịch ảo bị ghi nhận nhầm lẫn hoặc các bản cập nhật bị thất lạc.

36. Kiểm soát ngân sách bao quát toàn bộ các yếu tố: số lượng token và lượt gọi mô hình, chi phí công cụ và API, số lượng tác tử, số bước thực hiện, thời gian thực tế, tài nguyên tính toán, lưu trữ, truyền tải dữ liệu, công sức kiểm duyệt của con người và các tác động ngoại vi ra bên ngoài. Hệ thống phân cấp ngân sách gồm: khách hàng (tenant) đến phiên chạy, tác vụ con và tác tử thực thi. Cảnh báo mềm sẽ kích hoạt thông báo hoặc lập lại kế hoạch; hạn mức cứng sẽ lập tức dừng việc điều phối và thu hồi quyền hạn của các tác vụ đang hoạt động. Ngân sách linh hoạt được phân bổ dựa trên độ phức tạp của tác vụ, giá trị kinh tế và dữ liệu lịch sử của các phiên chạy trước. Tác vụ con tuyệt đối không được tiêu tốn vượt quá phần ngân sách được tác vụ cha chia sẻ. Phần ngân sách chưa dùng hết sẽ được hoàn trả về quỹ chung của tác vụ cha. Hệ thống có thể chuyển sang mô hình AI tiết kiệm hơn khi ngân sách sắp cạn để ưu tiên bảo toàn bước tổng hợp quan trọng. Ngân sách thời gian thực tế phải tính đến độ trễ mạng, thời gian chờ hàng đợi, thời gian sinh văn bản của mô hình và thời gian thực thi công cụ. Chi phí truyền dữ liệu ra ngoài và lưu trữ được theo dõi theo từng sản phẩm đầu ra. Hệ thống phát hiện bất thường chi phí sẽ gắn cờ cảnh báo các vòng lặp vô tận, sự bùng nổ tác vụ con và các lần thử lại công cụ tốn kém. Dữ liệu đo đạc chi phí được cập nhật theo thời gian thực và hiển thị minh bạch cho đội ngũ vận hành.

37. Quản lý độ trễ và áp lực tải ngược đòi hỏi thiết kế hàng đợi và xử lý đồng thời bài bản. Việc chạy song song chỉ giúp giảm thời gian thực tế khi các nhánh công việc thật sự độc lập, đồng thời các mối phụ thuộc và công suất của nhà cung cấp cho phép. Khâu lập kế hoạch của bộ điều phối, thời gian khởi động nguội, quá trình sinh token, gọi công cụ, bước hợp nhất và sự phê duyệt của con người đều cộng thêm các giai đoạn xử lý. Doanh nghiệp cần đo lường trên đường găng trọng yếu và phần việc song song bị lãng phí, chứ không chỉ nhìn vào thời gian gọi mô hình trung bình. Kiểm soát tiếp nhận ưu tiên các tác vụ quan trọng; đảm bảo tính công bằng giữa các khách hàng giúp ngăn chặn tình trạng một bên làm nghẽn toàn bộ hệ thống. Độ dài, độ trễ của hàng đợi và mức độ sử dụng tác tử sẽ điều phối việc tự động mở rộng hạ tầng trong khuôn khổ ngân sách. Áp lực tải ngược phải được truyền tải rõ ràng ra giao diện người dùng và API kèm thời gian hoàn thành dự kiến hoặc hướng dẫn thử lại; tác tử không được phép tự ý sinh thêm worker để đối phó với sự chậm chạp. Tiến trình cập nhật liên tục sử dụng các sự kiện bền vững nhưng nội dung một phần chưa thể coi là kết quả cuối cùng. Lịch điều phối dựa trên thời hạn chót có thể chủ động hủy bỏ các nhánh công việc có giá trị thấp. Các bài kiểm thử tải và kiểm thử sức chịu đựng dài hạn phải tính cả hạn mức của nhà cung cấp mô hình và cơ sở dữ liệu lưu trữ điểm lưu trạng thái.

38. Khả năng quan sát truy vết toàn bộ chuỗi: phiên chạy đến tác tử, tác tử con, mô hình AI, công cụ, bàn giao, sản phẩm đầu ra và trạng thái với mã định danh ổn định, mốc thời gian, số lần thử, phiên bản, lượng token, chi phí, phê duyệt chính sách và bảng phân loại kết quả. Ngữ cảnh truy vết phân tán không được coi là dữ liệu tin cậy và không thể thay thế cho định danh bảo mật. Nội dung gói tin được ẩn danh và lấy mẫu theo phân loại dữ liệu; tuyệt đối không lưu khóa bí mật hoặc chuỗi suy nghĩ nội bộ. Dòng thời gian sự kiện tái hiện chính xác việc mở rộng nhánh, hợp nhất, thử lại, hủy bỏ và phục hồi sự cố. Hệ thống chỉ số bao quát độ chính xác khi ủy quyền, mức độ trùng lặp hoặc bao phủ của nhánh, tính song song hữu ích, kết quả không hợp lệ, số lần thử lại, vòng lặp, tác vụ mồ côi, tần suất đọc và ghi cùng độ lỗi thời của bộ nhớ, hiệu quả khôi phục từ điểm lưu và kết quả đối soát nghiệp vụ. Nhật ký hệ thống và kho lưu trữ bằng chứng phục vụ các mục đích hoàn toàn khác biệt. Bảng điều khiển phân loại theo cấu trúc kiến trúc, tác tử thực thi, phiên bản và khách hàng. Trình xem dấu vết giúp gỡ lỗi, nhưng các tuyên bố về hiệu quả vận hành thực tế phải căn cứ trên dữ liệu đối soát tổng hợp. Cần thiết lập cảnh báo cho các sự kiện đơn lẻ nghiêm trọng kết hợp với tốc độ tiêu hao ngân sách.

39. Quy trình đánh giá sử dụng các bộ bài kiểm tra đại diện cho quyết định cấu trúc, phân rã công việc, phân luồng tác vụ, chất lượng tác tử, khâu tổng hợp, quản lý bộ nhớ, khả năng khôi phục và kết quả cuối cùng. Doanh nghiệp cần so sánh với mốc đo ban đầu của giải pháp một agent hoặc quy trình thông thường dưới cùng điều kiện nghiệm thu và tiêu chuẩn bảo mật. Các chỉ số gồm: tỷ lệ thành công của tác vụ, độ bao phủ công việc, tính chuẩn xác của dữ kiện và bằng chứng, khả năng giải quyết xung đột, độ chính xác và độ phủ của khâu ủy quyền, mức độ trùng lặp, độ trễ, chi phí token, công cụ và công sức con người, tần suất hành động thiếu an toàn và tính chính xác khi khôi phục lỗi. Kỹ thuật tiêm lỗi mô phỏng việc chủ động ngắt tiến trình tác tử, làm rơi, nhân đôi hoặc đảo lộn thứ tự thông điệp, làm sai lệch cấu trúc dữ liệu, gây trễ công cụ, thu hồi quyền truy cập và thay đổi dữ liệu nguồn. Đánh giá bộ nhớ đo lường khả năng truy xuất hữu ích, nguy cơ rò rỉ dữ liệu lỗi thời hoặc sai lệch và mức độ cách ly giữa các khách hàng. Chuẩn hóa thang điểm đánh giá của con người theo từng nghiệp vụ chuyên ngành. Quản lý phiên bản chặt chẽ cho mọi mô hình, câu lệnh prompt, công cụ, tác tử, cấu trúc kiến trúc và bộ dữ liệu. Triển khai thử nghiệm trực tiếp trên nhóm nhỏ với rủi ro thấp; tuyệt đối không lựa chọn số liệu có lợi để báo cáo. Mọi kết quả công bố nội bộ từ các nhà cung cấp giải pháp đều phải được gắn nhãn là chỉ có giá trị trên khối lượng công việc thử nghiệm cụ thể đó.

40. Ranh giới an ninh phải được thiết lập riêng cho từng bộ điều phối, tác tử thực thi, công cụ, bộ nhớ và các tác tử ngang hàng bên ngoài. Mỗi khối lượng công việc phải có định danh và quyền hạn tối thiểu; quyền hạn khi ủy quyền tiếp theo phải luôn bị thu hẹp dần. Công cụ của tác tử thực thi bị giới hạn đúng theo mục tiêu tác vụ; mã lập trình, tệp tin và kết nối mạng phải được cách ly trong môi trường cô lập; áp dụng danh sách trắng cho các kết nối ra ngoài. Nội dung chưa được kiểm chứng tuyệt đối không được phép tự sinh thêm agent, thay đổi phân luồng, sửa đổi chính sách hoặc ghi vào bộ nhớ. Sổ đăng ký tác tử và sản phẩm đầu ra phải được ký số và kiểm tra tính toàn vẹn khi thích hợp. Bộ lọc bàn giao giúp giảm thiểu tối đa lượng dữ liệu truyền đi. Các điểm cuối kết nối ngang hàng và giao thức A2A phải xác thực và phân quyền cho từng tác vụ và đối tượng dữ liệu. Cần xây dựng mô hình đe dọa chi tiết đối với các nguy cơ tiêm câu lệnh, lợi dụng quyền hạn ủy thác, leo thang đặc quyền, rò rỉ bộ nhớ chéo giữa các khách hàng và hành vi đánh cắp dữ liệu ngầm ẩn giấu trong sản phẩm đầu ra. Giới hạn ngân sách và số bước nhảy giúp ngăn chặn tấn công từ chối dịch vụ hoặc khuếch đại tải. Các tác động ngoại vi rủi ro cao phải được tập trung kiểm soát phía sau chính sách xác định và quy trình phê duyệt của con người, ngay cả khi việc lập kế hoạch được phân tán. Chuỗi cung ứng phần mềm cần cố định phiên bản bộ công cụ phát triển (SDK), mô hình AI, công cụ, bộ chứa và thực hiện quét mã độc định kỳ.

41. Kiến trúc triển khai hạ tầng tách biệt các máy thực thi không lưu trạng thái khỏi các tầng lưu trữ trạng thái bền vững bất cứ khi nào có thể. Hàng đợi, bộ lập lịch, kho lưu trạng thái phiên chạy và điểm lưu trạng thái, kho sản phẩm đầu ra, kho bộ nhớ, sổ đăng ký chính sách, hệ thống quản lý định danh và khóa bí mật, hạ tầng quan sát và bộ đối soát đều phải có người phụ trách và cam kết chất lượng dịch vụ (SLO) rõ ràng. Các tác tử tự động mở rộng theo năng lực và tài nguyên, bố trí các cụm tác tử cô lập cho các công cụ tiềm ẩn rủi ro. Vùng lưu trữ dữ liệu và tính gắn kết máy chủ phải tuân thủ chính sách dữ liệu chứ không dựa vào phiên làm việc dính trên bộ nhớ tạm. Việc nâng cấp cấu trúc dữ liệu phải tương thích ngược trong suốt quá trình triển khai cuốn chiếu; các tác tử cũ được để hoàn tất nốt việc hoặc được rút cạn dần. Sử dụng cờ tính năng theo khách hàng, cấu trúc kiến trúc và phiên bản tác tử. Triển khai thử nghiệm nhóm nhỏ và quay về bản trước phải bảo toàn tính tương thích của trạng thái. Kịch bản kiểm thử sao lưu và khôi phục phải bao gồm điểm lưu, sản phẩm đầu ra, bộ nhớ, bằng chứng kiểm toán và các khóa mã hóa. Môi trường phát triển và thử nghiệm chỉ sử dụng dữ liệu tổng hợp và khóa giả lập. Kế hoạch công suất phải dự phòng cho các đợt tăng đột biến khi mở rộng nhánh và hạn mức của nhà cung cấp mô hình. Tuyệt đối không sử dụng bộ lưu trạng thái trên bộ nhớ tạm của bất kỳ khung phần mềm nào làm giải pháp lưu trữ bền vững trên môi trường thực tế nếu chưa qua kiểm duyệt.

42. Quy trình ứng phó sự cố bắt đầu từ việc rà soát đồ thị phiên chạy và đánh giá tác động kinh tế: nhanh chóng cô lập tác tử, công cụ, cấu trúc hoặc khách hàng bị ảnh hưởng thông qua công tắc ngắt khẩn cấp, dừng ngay việc điều phối tác vụ mới, thu hồi thông tin xác thực của tác vụ, bảo toàn trạng thái, sản phẩm đầu ra, bằng chứng kiểm toán và tra vấn hệ thống lưu trữ gốc. Xác định rõ các tác vụ đang chạy, tác vụ mồ côi, các tác động ngoại vi đã hoàn thành và vùng dữ liệu bị ảnh hưởng. Tiến hành đối soát, thực hiện hành động bù trừ hoặc đính chính, đồng thời thông báo cho người phụ trách, người dùng và các nhà cung cấp liên quan. Tuyệt đối không xóa bỏ quỹ đạo thực thi bị lỗi vì đó là dữ liệu sống còn phục vụ điều tra; phải thiết lập quyền truy cập và lưu giữ an toàn. Khôi phục lại phiên bản mô hình AI, câu lệnh prompt, công cụ, chính sách và bản dựng phần mềm đã được xác nhận an toàn trước đó, rồi thử nghiệm thận trọng trên một phạm vi hẹp. Xây dựng sổ tay vận hành cho các sự cố bùng nổ chi phí do vòng lặp, tác tử bị xâm nhập, nhiễm độc bộ nhớ, rò rỉ dữ liệu chéo giữa các khách hàng, ghi trùng lặp, phát lại hàng đợi, hỏng điểm lưu trạng thái và mất kết nối nhà cung cấp. Báo cáo phân tích sau sự cố phải cập nhật giao ước, bổ sung bài kiểm thử, siết chặt giới hạn và làm rõ trách nhiệm, chứ không chỉ sửa đổi mỗi câu lệnh prompt. Định kỳ tổ chức diễn tập ứng phó sự cố trên bàn giữa các phòng ban nội bộ và các đối tác liên quan.

43. Dự án chạy thử nghiệm có giới hạn nên chọn tác vụ giá trị cao với hai hoặc ba nhánh tách rời rõ ràng, chủ yếu đọc dữ liệu và có tiêu chí nghiệm thu rõ. Hãy xây dựng mốc đo ban đầu với giải pháp một agent hoặc quy trình thông thường trước. Thiết lập một bộ điều phối và các tác tử chuyên trách đã duyệt, không mở tìm kiếm ngang hàng tự do; cố định độ mở rộng nhánh, độ sâu, ngân sách và thời hạn chót; chỉ dùng bộ nhớ cục bộ; áp dụng sản phẩm đầu ra, điểm lưu bền vững và con người nghiệm thu. Dùng dữ liệu tổng hợp hoặc đã ẩn danh. Kiểm thử luồng chuẩn, xung đột, nhánh thiếu, đầu ra lỗi, hết giờ, thông điệp trùng, sự cố sập và khởi động lại, lệnh hủy, thu hồi quyền, tiêm câu lệnh và đối soát khôi phục. Quan sát tính song song hữu ích, chất lượng và chi phí. Tác động ngoại vi nên tắt hoặc chạy giả lập. Điều kiện hoàn thành: lợi ích đo lường được vượt trội độ phức tạp; đạt chuẩn an ninh, phục hồi và bằng chứng; đội trực và sổ tay vận hành sẵn sàng. Nếu không, hãy giữ kiến trúc đơn giản hơn.

44. Khung đánh giá hiệu quả đầu tư (ROI) giúp phân định rạch ròi giữa hiệu năng đạt được với lượng token tiêu hao. Lợi ích tiềm năng có thể bao gồm: độ bao phủ công việc rộng hơn, rút ngắn chu kỳ xử lý nhờ chạy song song, tính chuyên trách và khả năng tái sử dụng, cô lập ngữ cảnh và tăng sức chống chịu của hệ thống; trong khi chi phí bao gồm: token và lượt gọi công cụ gia tăng, chi phí điều phối và tổng hợp, hạ tầng quản lý trạng thái, hàng đợi, lưu trữ, quản trị định danh và bảo mật, chi phí đánh giá kiểm thử, giám sát hệ thống, cùng công sức can thiệp của con người và xử lý sự cố. Anthropic từng ghi nhận rằng mô hình đa tác tử nghiên cứu tiêu tốn nhiều token hơn đáng kể nhưng mang lại bước tiến lớn trên bài kiểm tra nội bộ của họ, song những con số đó hoàn toàn không phải là bảo chứng tài chính cho mọi doanh nghiệp. Hãy đo lường kết quả kinh doanh được nghiệm thu và đối soát trên mỗi đồng chi phí hoặc mỗi giờ làm việc, chứ không đếm số lượng câu trả lời. Năng lực làm việc được giải phóng chỉ thực sự là lợi ích nếu nó được hiện thực hóa thành giá trị cụ thể. Giá trị gia tăng về chất lượng cần được lượng hóa bằng việc giảm thiểu công việc phải làm lại phía sau, giảm thiểu rủi ro và tăng doanh thu đi kèm bằng chứng rõ ràng. Thực hiện phân tích độ nhạy theo quy mô sản lượng, giá trị kinh tế của tác vụ và chi phí khắc phục lỗi. Doanh nghiệp chỉ nên mở rộng quy mô đa tác tử cho các tác vụ vượt qua ngưỡng hiệu quả kinh tế; còn những tác vụ đơn giản hãy tiếp tục phân luồng cho một agent đơn lẻ xử lý.

45. Nhịp điệu vòng đời giữ hệ thống vận hành nhất quán. Hàng ngày: rà soát sự cố nghiêm trọng, vòng lặp, an ninh, đối soát và phiên chạy bị treo. Hàng tuần: đánh giá phân luồng, phân rã việc, chất lượng tác tử, thử lại, chi phí, tác vụ mồ côi và đề xuất bộ nhớ. Hàng tháng: kiểm tra quyền truy cập, sổ đăng ký, công cụ, mô hình, prompt, phụ thuộc, thời hạn lưu, cam kết dịch vụ (SLO) và lợi ích thực tế. Hàng quý: diễn tập mô hình đe dọa, phục hồi thảm họa, rủi ro phụ thuộc nhà cung cấp, quyền riêng tư và tinh gọn kiến trúc. Mọi thay đổi trọng yếu về mô hình, tác tử, công cụ, cấu trúc dữ liệu, cấu trúc hệ thống hay chính sách bộ nhớ đều kích hoạt kiểm thử hồi quy và thử nghiệm nhóm nhỏ. Cho nghỉ hưu tác tử không dùng bằng cách dừng phân luồng, rút cạn hoặc hủy tác vụ dở dang, thu hồi định danh, công cụ, lưu trữ hoặc xóa trạng thái, bộ nhớ theo quy định, cập nhật kế hoạch, kiểm thử và tài liệu. Định kỳ đánh giá xem mô hình đơn lẻ hay quy trình mới đã đủ thay thế hệ thống đa tác tử phức tạp chưa. Kiến trúc tốt luôn loại bỏ bớt tác tử khi giá trị không còn.