Multi-Agent Workflow Runtime: Cách xây dựng các nhóm tác nhân (agent) không biến thành các cuộc họp AI

Một hệ thống đa tác nhân hữu ích giống một môi trường thực thi (runtime) hơn là một cuộc họp: bao gồm các vai trò, trạng thái, định tuyến, cổng và đo lường từ xa (telemetry). AI đa tác nhân nghe có vẻ mạnh mẽ cho đến khi bản demo đầu tiên trở thành năm chatbot lịch sự chuyển tiếp công việc cho nhau. Một tác nhân yêu cầu tác nhân khác nghiên cứu. Nhà nghiên cứu yêu cầu người lập kế hoạch làm rõ. Người lập kế hoạch yêu cầu người đánh giá xác thực. Mười lượt sau, hệ thống đã tiêu tốn tiền, tạo ra nhật ký và vẫn không có đầu ra đáng tin cậy. Vấn đề hiếm khi nằm ở chỗ các mô hình yếu. Vấn đề là nhóm đã xây dựng một cuộc trò chuyện thay vì một môi trường thực thi. Năm 2026, các nhà phát triển có những công cụ tốt hơn một đống lời nhắc (prompts). Các framework như Agent Development Kit của Google, LangGraph và OpenAI Agents SDK đều chỉ ra cùng một hướng: các tác nhân cần trạng thái, định tuyến, chuyển giao, công cụ, theo dõi và đánh giá. Những người chiến thắng sẽ không phải là các nhóm có nhiều tác nhân nhất. Họ sẽ là các nhóm có hợp đồng môi trường thực thi rõ ràng nhất. Hướng dẫn này dành cho các nhà phát triển, nhà sáng lập, kỹ sư AI và trưởng nhóm kỹ thuật muốn xây dựng các quy trình làm việc đa tác nhân có thể tồn tại với người dùng thực. Chúng ta sẽ đề cập đến khi nào kiến trúc đa tác nhân đáng giá, cách thiết kế môi trường thực thi, những gì cần ghi nhật ký, nơi đặt con người và cách tránh mô hình phản diện tốn kém mà tôi gọi là cuộc họp AI. Ý định tìm kiếm đằng sau các quy trình làm việc đa tác nhân đã thay đổi Một năm trước, nhiều nhà phát triển tìm kiếm các framework tác nhân vì họ muốn biết công cụ nào đang thịnh hành. Ngày nay, câu hỏi hữu ích hơn và cụ thể hơn là: làm thế nào để nhiều tác nhân phối hợp mà không mất kiểm soát? Các cuộc thảo luận gần đây của nhà phát triển về các framework tác nhân, tác nhân mã hóa, máy chủ Giao thức Ngữ cảnh Mô hình (Model Context Protocol) và công cụ quy trình làm việc AI vẫn xoay quanh những điểm khó khăn tương tự: Ai sở hữu câu trả lời cuối cùng khi nhiều tác nhân đóng góp? Làm thế nào để ngăn các tác nhân lặp lại nhau? Trạng thái chia sẻ nên nằm ở đâu? Làm thế nào để gỡ lỗi một lần chuyển giao kém? Khi nào một tác nhân nên gọi trực tiếp một công cụ thay vì hỏi một tác nhân khác? Làm thế nào để giữ chi phí và độ trễ không tăng vọt? Những câu hỏi đó không được giải quyết bằng cách đặt tên các tác nhân là "người lập kế hoạch", "người phê bình" và "người thực thi". Chúng là những câu hỏi về thiết kế môi trường thực thi. Một hệ thống đa tác nhân không phải là một cuộc trò chuyện nhóm. Đó là một quy trình làm việc phân tán, trong đó mỗi tác nhân cần một hợp đồng, ngân sách, ranh giới trạng thái và điều kiện thoát. Sự thay đổi đó cũng tạo ra một cơ hội SEO thực tế. Các từ khóa rộng như "tác nhân AI" và "hệ thống đa tác nhân" đã bão hòa. Nhưng các tìm kiếm đuôi dài như "môi trường thực thi quy trình làm việc đa tác nhân", "các mẫu điều phối đa tác nhân", "thiết kế chuyển giao tác nhân AI" và "cách gỡ lỗi quy trình làm việc đa tác nhân" vẫn còn chỗ cho nội dung kỹ thuật, ưu tiên triển khai. Đầu tiên, hãy quyết định xem bạn có thực sự cần nhiều tác nhân hay không Hầu hết các dự án đa tác nhân thất bại đều bắt đầu muộn một bước. Nhóm hỏi, "Chúng ta nên tạo ra những tác nhân nào?" trước khi hỏi, "Tại sao một tác nhân lại không đủ?" Một tác nhân duy nhất với lời nhắc mạnh mẽ, công cụ tốt, truy xuất, đầu ra có cấu trúc và đánh giá thường đơn giản hơn, rẻ hơn và dễ gỡ lỗi hơn. Chỉ thêm nhiều tác nhân khi công việc có sự phân tách mối quan tâm thực sự. Sử dụng nhiều tác nhân khi quy trình làm việc có các chế độ đánh giá khác nhau. Thiết kế đa tác nhân bắt đầu có ý nghĩa khi cùng một nhiệm vụ yêu cầu các phong cách suy luận khác nhau đáng kể. Ví dụ, một trợ lý mua sắm có thể cần một tác nhân để phân tích chính sách, một tác nhân để so sánh rủi ro nhà cung cấp và một tác nhân để soạn thảo đề xuất mua hàng. Một quy trình làm việc bảo trì phần mềm có thể cần một tác nhân để kiểm tra một vấn đề, một tác nhân để thực hiện thay đổi mã và một tác nhân để xem xét sự khác biệt so với kiến trúc. điều lệ cấu trúc. Điều cốt yếu không phải là chức danh công việc. Điều cốt yếu là liệu mỗi vai trò có bối cảnh, công cụ, tiêu chí đánh giá hoặc quyền hạn khác nhau hay không. Tránh sử dụng nhiều tác nhân khi bạn chỉ muốn có câu trả lời tốt hơn Nếu lý do duy nhất của bạn là “nhiều tác nhân hơn có thể thông minh hơn”, hãy tạm dừng. Bạn có thể cần một bản tóm tắt nhiệm vụ tốt hơn, thiết lập truy xuất, lựa chọn mô hình hoặc vòng lặp đánh giá. Thêm một tác nhân phê bình vào một quy trình làm việc mơ hồ thường tạo ra sự bất đồng tự tin thay vì chất lượng. Sử dụng bộ lọc nhanh này: Nếu các tác nhân cần các quyền công cụ khác nhau, việc tách biệt có thể hữu ích. Nếu các tác nhân cần bối cảnh riêng tư khác nhau, việc tách biệt có thể hữu ích. Nếu các tác nhân tạo ra các tạo phẩm khác nhau, việc tách biệt có thể hữu ích. Nếu các tác nhân chỉ lặp lại cùng một hướng dẫn, hãy giữ một tác nhân. Nếu các tác nhân không thể được đánh giá độc lập, hãy giữ thiết kế đơn giản hơn. Hợp đồng thời gian chạy: Lớp còn thiếu Một hợp đồng thời gian chạy định nghĩa cách các tác nhân đi vào quy trình làm việc, những gì họ nhận được, những gì họ có thể làm, những gì họ phải trả lại và khi nào hệ thống dừng lại. Nếu không có hợp đồng đó, các tác nhân của bạn sẽ thương lượng quy trình làm việc trong khi thực hiện công việc. Đó là nơi chi phí, độ trễ và sự mơ hồ phát sinh. Một hợp đồng thời gian chạy đa tác nhân thực tế có bảy phần. 1. Phong bì nhiệm vụ Mỗi tác nhân nên nhận một phong bì nhiệm vụ, không phải một lịch sử trò chuyện lỏng lẻo. Phong bì nên bao gồm mục tiêu, các ràng buộc, các công cụ có sẵn, lược đồ đầu ra bắt buộc, ngân sách, thời hạn và bất kỳ trạng thái trước đó nào mà tác nhân được phép xem. { "task_id": "support-refund-0421", "role": "policy_checker", "goal": "Determine whether this refund request is allowed", "input_refs": ["ticket", "order", "refund_policy"], "allowed_tools": ["policy_search", "order_lookup"], "blocked_tools": ["send_email", "issue_refund"], "max_tool_calls": 5, "required_output": "policy_decision_v1" }Cấu trúc này giúp tác nhân tập trung. Nó cũng cung cấp cho nhật ký của bạn một cái gì đó có ý nghĩa để lập chỉ mục sau này. 2. Ranh giới vai trò Một ranh giới vai trò nói lên những gì tác nhân chịu trách nhiệm và những gì nó không được quyết định. Ví dụ, một người kiểm tra chính sách có thể phân loại yêu cầu hoàn tiền nhưng không thể thực hiện việc hoàn tiền. Một người đánh giá mã có thể gắn cờ rủi ro kiến trúc nhưng không thể viết lại sự khác biệt trừ khi quy trình làm việc rõ ràng định tuyến lại cho một tác nhân triển khai. Ranh giới vai trò giảm sự trôi dạt. Chúng cũng giúp dễ dàng thay thế một tác nhân mà không cần viết lại toàn bộ hệ thống. 3. Mô hình trạng thái chia sẻ Trạng thái chia sẻ là nơi nhiều hệ thống đa tác nhân bị hỏng. Nếu mọi tác nhân đều thấy toàn bộ cuộc trò chuyện, ngữ cảnh sẽ phát triển nhanh chóng và các sự kiện quan trọng bị chôn vùi. Nếu các tác nhân thấy quá ít, thì