Agent-to-Agent (A2A) & Monolith vs Multi-Agent
Chiến lược Monolith-first, phòng tránh sự cố GOTO trong giao tiếp đa tác tử, thiết kế Agent Card và xây dựng hợp đồng kinh doanh Agent-as-a-Service.
Chỉ chuyên môn hóa sau khi monolith cho thấy ranh giới nằm ở đâu
Tài liệu gốc so sánh sự tiến hóa này với Infrastructure as Code, AutoML, và bước chuyển dịch từ kiến trúc monolith sang microservices: các cấu hình thủ công cấp thấp nhường chỗ cho quy trình điều phối dựa trên mục đích (intent-based orchestration), để rồi các hộp đen (black box) đã chứng minh được giá trị được phân tách thành các giai đoạn có thể quan sát được. Phép so sánh này đóng vai trò trợ giúp quyết định, chứ không phải là lý do để chia tách sớm hệ thống. Hãy yêu cầu bằng chứng cho thấy việc chuyên môn hóa thực sự làm giảm lỗi tìm kiếm tool, hiện tượng phân tán sự chú ý (attention dilution) hoặc tải trọng ngữ cảnh (contextual load) đủ nhiều để bù đắp cho chi phí điều phối phát sinh.
Các sản phẩm agent giai đoạn đầu thường bắt đầu dưới dạng một agent duy nhất với một prompt rộng và nhiều tool. Đó là một bản prototype hợp lý vì nó giữ độ trễ, trạng thái và việc debug nằm gọn trong một runtime. Sơ đồ dưới đây thể hiện một thiết kế trung gian: các specialist agent đã xuất hiện, nhưng chúng vẫn dùng chung process và bộ nhớ.
Kiến trúc Multi-Agent kiểu Monolith
Các specialist agent đã xuất hiện, nhưng vẫn dùng chung một process và một bộ nhớ.
Chọn một node để xem nó mang lại gì và vẫn còn gắn chặt điều gì
Coordinator
Định tuyến yêu cầu tới đúng specialist và giữ phần điều phối cục bộ đơn giản trong prompt của agent cha.
Tỷ lệ chọn sai tool và mức sử dụng context là bao nhiêu trước khi thêm bất kỳ specialist nào?
Chuyên môn hóa nội bộ có thể thu hẹp không gian tìm kiếm (search space). Research specialist chỉ nhìn thấy các tool nghiên cứu; analytics specialist chỉ nhìn thấy các tool truy vấn. Mỗi prompt trở nên tập trung hơn, trong khi agent cha (parent agent) vẫn duy trì sự điều phối cục bộ đơn giản. Xét về mặt vận hành, đây vẫn là một monolith: một đợt triển khai, một runtime, và thường chỉ có một vùng rủi ro (failure domain) nắm giữ toàn bộ trải nghiệm.
Đừng vội chia tách chỉ vì quy trình công việc trải qua nhiều bước. Chỉ chia tách khi các bằng chứng cho thấy đã xuất hiện một ranh giới ổn định, ví dụ như:
- Một domain đòi hỏi các cơ chế kiểm soát truy cập hoặc an ninh khác biệt.
- Một team bắt buộc phải triển khai và đánh giá năng lực của họ một cách độc lập.
- Ngữ cảnh của task này làm suy giảm rõ rệt chất lượng thực hiện của task khác.
- Một capability cần tới một model, mục tiêu độ trễ hoặc cấu hình mở rộng (scaling profile) khác biệt.
- Một đơn vị bên ngoài nắm giữ chuyên môn và chu kỳ bảo trì riêng.
Hãy áp dụng tư duy quyết định tự dựng hay đi mua (build-vs-buy) cho từng specialist được đề xuất.
Vendor agent sẽ làm cho lựa chọn này trở nên cụ thể hơn. Lúc đầu, parent agent có thể tự mình áp dụng một bộ tiêu chuẩn kiểm tra tuân thủ (compliance rubric) ngắn. Nếu các chỉ dẫn tuân thủ bắt đầu làm lấn áp công việc phân tích vendor, việc tạo một internal specialist trong cùng runtime sẽ giúp giảm không gian tìm kiếm. Nếu team compliance trung ương phải phát hành chính sách của họ một cách độc lập, specialist đó có thể tách ra thành một service từ xa (remote service). Nếu một nhà cung cấp chính thức đã duy trì sẵn bộ quy chuẩn pháp lý ngay gần dữ liệu nguồn, việc sử dụng (consume) service đó có thể rẻ hơn tự xây dựng lại-nhưng chỉ khi có đầy đủ , quy trình review dữ liệu, phương án dự phòng (fallback) và lối thoát (exit path).
| Lựa chọn | Ưu tiên khi | Chi phí ngầm hoặc rủi ro | Bằng chứng cần có trước khi cam kết |
|---|---|---|---|
| Giữ một agent | Quy trình còn ở giai đoạn đầu, gắn kết chặt chẽ và một team nắm trọn vẹn vòng lặp | Giới hạn của Monolith: nhầm lẫn tool, quá tải context và chung một vùng rủi ro (failure domain) | Lỗi chọn tool, hiệu suất dùng context, độ trễ và việc không thể tách biệt đợt release |
| Internal specialist trong cùng runtime | Đã có ranh giới tư duy/tool ổn định nhưng việc chia sẻ trạng thái và độ trễ thấp vẫn quan trọng | Trông có vẻ mô-đun hóa nhưng việc triển khai, bộ nhớ và sự cố vẫn bị gắn chặt với nhau | Chất lượng cải thiện nhờ thu hẹp không gian tìm kiếm mà không phát sinh thêm chi phí mạng |
| Tự dựng remote specialist | Capability tạo ra sự khác biệt chiến lược và tổ chức đủ sức làm chủ prompt, tool, eval, an ninh cùng chu kỳ thay đổi | Chi phí bảo trì liên tục và phải vận hành một dịch vụ độc lập | Giá trị chiến lược, team chịu trách nhiệm rõ ràng, ưu thế về eval, SLO và 3 năm |
| Sử dụng official remote specialist | Bên sở hữu domain khác có chuyên môn sâu hơn và duy trì capability gần hệ thống nguồn | Phụ thuộc vào vendor, thay đổi giá, truyền tải dữ liệu và sự cố dịch vụ | Độ phù hợp về capability/eval, contract, lối thoát, review dữ liệu, SLO và fallback |
Một khi specialist vượt qua ranh giới mạng hoặc ranh giới tổ chức, sản phẩm sẽ trở thành một hệ thống phân tán (distributed system). Bộ điều phối (orchestrator) lúc này sẽ giao việc cho một participant từ xa-bên có khả năng tự duy trì task state, đặt câu hỏi làm rõ và tự khôi phục khi gặp sự cố.
Kiến trúc Multi-Agent Phân tán
Một khi specialist vượt qua ranh giới mạng hoặc ranh giới tổ chức, sản phẩm trở thành hệ phân tán.
Chọn một node để xem ranh giới mạng bổ sung thêm điều gì
Ranh giới mạng
Biến một lệnh gọi hàm cục bộ thành lệnh gọi dịch vụ, kèm độ trễ, xác thực và các kiểu lỗi một phần.
Identity và quyền nào đi kèm mỗi request, và điều gì xảy ra khi kết nối đứt giữa chừng?
Mô hình phân tán đem lại sự linh hoạt, nhưng cũng bổ sung thêm các điểm rủi ro về lỗi mạng, quản lý phiên bản (versioning), danh tính (identity), tính sẵn sàng của dịch vụ và sự phụ thuộc vào vendor. Product Manager phải quyết định xem người dùng sẽ nhìn thấy gì trong lúc remote agent đang xử lý, parent agent sẽ chờ trong bao lâu, bằng chứng nào cần được trả về, và điều gì sẽ xảy ra nếu specialist ngừng hoạt động giữa chừng.
Bounded tool, unbounded collaboration và sự cố GOTO
Tool hoạt động tốt nhất trong một ranh giới khép kín (bounded domain): một request đã được kiểm tra, dạng kết quả có thể dự đoán và lệnh gọi diễn ra trong thời gian ngắn. Một specialist agent lại hoạt động trong một miền giải quyết vấn đề mở (unbounded domain). Nó có thể phát hiện mâu thuẫn, yêu cầu người dùng lựa chọn điểm đánh đổi (trade-off), tạm dừng vì thiếu thông tin, điều chỉnh lại plan, hoặc kết thúc mà không tạo ra artifact như dự kiến ban đầu.
Lệnh gọi getVendorEvidence(vendorId) mang tính chất bounded: bên gọi cung cấp một ID và nhận về một schema. Trong khi đó, yêu cầu "Hãy quyết định xem các điều khoản lưu trữ dữ liệu của vendor này có đạt chính sách của công ty không" thì hoàn toàn không bounded. Compliance participant có thể phát hiện thiếu thỏa thuận xử lý dữ liệu (DPA), hỏi xem dữ liệu sẽ lưu ở khu vực (region) nào, chờ ý kiến từ bộ phận pháp lý, rồi mới đưa ra kết luận cuối cùng. Nếu coi cuộc hội thoại đó như một lệnh gọi tool thông thường sẽ làm che khuất đi trạng thái tạm dừng và buộc parent agent phải đoán xem sự im lặng đó có nghĩa là đang xử lý, bị nghẽn (blocked), thất bại hay đã bị bỏ dở (abandoned).
Nhét kiểu cộng tác này vào một wrapper dạng tool chạy kiểu fire-and-forget sẽ tạo ra một sự cố GOTO tương đương trong kiến trúc agentic. Luồng điều khiển rời khỏi workflow có cấu trúc của parent agent rồi có thể quay trở lại muộn hơn, quay lại ở một trạng thái khác, hoặc không bao giờ quay lại vì người dùng đã bỏ ngang tác vụ. Prompt của parent agent sau đó sẽ phải phình ra với hàng loạt chi nhánh tùy chỉnh để xử lý sự ngắt quãng (interruption), làm rõ (clarification), khôi phục (resumption) và hủy bỏ (cancellation).
Hãy giữ cho MCP luôn đóng khung (bounded) và có thể dự đoán. Hãy chuyển phần trách nhiệm thực sự mang tính đa lượt (multi-turn) sang A2A-nơi mà toàn bộ lifecycle được hiển thị minh bạch. Nếu một capability luôn trả về đúng một câu trả lời hợp lệ theo schema mà không cần qua thương lượng, có lẽ nó vẫn chỉ là một tool; đừng cố tạo ra một remote agent chỉ để chạy theo trào lưu kiến trúc.