So sánh Single Agent và Multi-Agent trong giải pháp AI Sales Agent

Khi bắt tay vào xây dựng một AI Sales Agent, ngoài việc lựa chọn model NLU, quyết định về kiến trúc hệ thống monolithic (Single-Agent) hay microservices (Multi-Agent) là một trong những lựa chọn kỹ thuật ảnh hưởng sâu sắc đến khả năng mở rộng (scalability), khả năng bảo trì (maintainability) và tốc độ phát triển của dự án.

Bài viết này sẽ đi sâu vào phân tích các đánh đổi (trade-offs) của hai kiến trúc này dưới góc độ lập trình viên và xem xét một cách triển khai tham khảo qua kiến trúc của BizChatAI.

Kiến trúc Monolithic - Single Agent (AI Agent đơn)

Về cơ bản, Single-Agent là một kiến trúc monolithic. Toàn bộ logic nghiệp vụ, từ xử lý ngôn ngữ tự nhiên, quản lý state hội thoại đến thực thi hành động đều nằm trong một tiến trình (process), một codebase duy nhất.

Luồng xử lý (Execution Flow):

Một request của user sẽ đi qua một pipeline tuần tự bên trong agent:

User Input -> NLU Pipeline -> Dialogue State Tracker -> Policy Network -> Action Execution -> Response Generation

Toàn bộ pipeline này là một khối duy nhất, liên kết chặt chẽ (tightly coupled). State của cuộc hội thoại được giữ trong bộ nhớ (memory) của chính agent đó.

Những nỗi đau của dân Dev:

• Bảo trì: Toàn bộ logic được gói trong một cục khổng lồ. Việc muốn sửa một luồng nhỏ, ví dụ cập nhật logic khuyến mãi, có thể ảnh hưởng đến toàn bộ hệ thống. Rất dễ tạo ra spaghetti logic mà không ai dám động vào sau một thời gian.
• Khả năng mở rộng: Bạn chỉ có thể scale theo chiều dọc (vertical scaling - tăng CPU/RAM cho con server chứa agent). Scale theo chiều ngang (horizontal scaling) cực kỳ khó khăn vì vấn đề quản lý state. Mỗi instance của agent là một nhóm riêng, không chia sẻ state với nhau.
• Lỗi sai duy nhất (SPOF): Một bug nhỏ, một ngoại lệ không được xử lý trong logic có thể làm sập toàn bộ service. Hệ thống không có khả năng tự phục hồi (resilience).
• Chu trình triển khai chậm: Bất kỳ thay đổi nhỏ nào cũng yêu cầu kiểm thử lại và triển khai lại toàn bộ ứng dụng. Rủi ro cực kỳ cao.

Đây là kiến trúc phù hợp cho các PoC (Proof of Concept), MVP hoặc các chatbot có scope cực kỳ hẹp và nghiệp vụ không thay đổi. Đối với một hệ thống phức tạp như AI Sales Agent, nó nhanh chóng trở thành một món nợ kỹ thuật (technical debt) khổng lồ.

Kiến trúc Microservices - Multi-Agent (AI Agent đa tác nhân)

Multi-Agent System (MAS) là một cách tiếp cận kiến trúc microservices cho AI. Thay vì một khối monolithic, chúng ta chia nhỏ hệ thống thành các agent độc lập, chuyên biệt. Mỗi agent là một service, có logic nghiệp vụ riêng, có thể được triển khai độc lập và giao tiếp với nhau qua một cơ chế được định nghĩa rõ ràng.

Thành phần kiến trúc:

• Agents: Các microservice độc lập. Mỗi agent chịu trách nhiệm cho một domain nghiệp vụ hẹp. Ví dụ:
• ProductInfo Agent: Service chuyên truy vấn thông tin sản phẩm (có thể được backend bởi một vector database).
• PricingAgent: Service xử lý logic về giá, mã khuyến mãi.
• Booking Agent: Service tích hợp với các hệ thống lịch bên ngoài (Google Calendar, Outlook) qua API.
• Dispatcher Agent (API Gateway/Orchestrator): Đây là điểm vào (entry point) của hệ thống. Nó nhận tất cả yêu cầu, chạy NLU để phân loại intent và định tuyến (route) yêu cầu đến agent service phù hợp.
• Agent Communication Language (ACL): Giao thức giao tiếp giữa các agent. Đây chính là API contract giữa các service. Nó có thể đơn giản là các REST API call hoặc phức tạp hơn là sử dụng message queue (RabbitMQ, Kafka) để giao tiếp bất đồng bộ.
• Kho lưu trữ State/Ngữ cảnh chung: Một database chung (như Redis, MongoDB) để lưu trữ state của cuộc hội thoại, cho phép bất kỳ agent nào cũng có thể vào xử lý mà vẫn giữ được ngữ cảnh.

Ưu điểm từ góc nhìn kỹ thuật:

• Tách biệt (Decoupling) và gắn kết cao: Mỗi agent là một codebase riêng, tập trung vào một nghiệp vụ duy nhất. Team có thể phát triển, kiểm thử và triển khai Pricing Agent mà không cần quan tâm đến ProductInfo Agent.
• Khả năng mở rộng độc lập: Nếu hệ thống bị quá tải ở phần tư vấn sản phẩm, chúng ta chỉ cần scale số lượng instance của ProductInfo Agent mà không ảnh hưởng đến các agent khác.
• Cô lập lỗi (Fault Isolation): BookingAgent bị sập? Các agent khác vẫn hoạt động bình thường. Dispatcher Agent có thể triển khai logic fallback (ví dụ: thông báo cho người dùng hoặc chuyển cho nhân viên). Hệ thống có tính ổn định cao.
• Linh hoạt về Ngăn xếp công nghệ (Tech Stack Flexibility): ProductInfo Agent có thể viết bằng Python để tận dụng các thư viện ML, trong khi BookingAgent có thể viết bằng Go hoặc Node.js để tối ưu xử lý I/O.

So sánh Single Agent và Multi-Agent trong vận hành

Cách BizChatAI tối ưu vận hành trong AI Sales Agent

BizChatAI là một ví dụ thực tế về việc áp dụng kiến trúc Multi-Agent. Dưới đây là cách luồng yêu cầu được xử lý trong hệ thống của họ:

Tiếp nhận và phân loại Intent

Yêu cầu từ người dùng đi vào một Dispatcher Agent. Agent này không chỉ là một NLU service đơn thuần mà còn hoạt động như một API Gateway.

Nó xác định intent chính và các entities. Ví dụ: text: "Con lap top X giá sao shop, có cài win 11 không?" -> intents: ['get_price', 'query_tech_spec'], entities: {'product': 'lap top X', 'os': 'win 11'}.

Ủy quyền và điều phối Service

Dispatcher Agent sẽ quyết định agent nào cần được gọi và theo thứ tự nào. Nó có thể gọi PricingAgent trước, sau đó dùng phản hồi đó làm đầu vào để gọi tiếp ProductInfoAgent. 

Quá trình này không phải là một chuỗi if-else cứng nhắc, mà là một chính sách có thể được huấn luyện hoặc cấu hình, cho phép luồng hội thoại linh hoạt.

Giao tiếp bất đồng bộ giữa các Agent

Đối với các tác vụ phức tạp, các agent giao tiếp với nhau bất đồng bộ qua một message bus.

Ví dụ: Sau khi tư vấn xong, ProductInfoAgent có thể gửi một tin nhắn {'event': 'demo_requested', 'user_id': 'xyz', 'context': {...}}.

BookingAgent, vốn đang lắng nghe topic này, sẽ nhận được tin nhắn và chủ động bắt đầu một luồng hội thoại mới với người dùng để đặt lịch. Điều này giúp hệ thống phản hồi nhanh và không bị chặn (blocking).

Các Agent Stateless và State tập trung

Các agent được thiết kế để trở nên stateless. Toàn bộ state của cuộc hội thoại (user ID, các thông tin đã thu thập, lịch sử chat) được lưu vào một kho lưu trữ chung như Redis.

Điều này giúp việc scale các agent trở nên đơn giản. Bất kỳ trường hợp nào của PricingAgent cũng có thể xử lý yêu cầu miễn là nó có session_id để truy vấn ngữ cảnh từ Redis.

Khi cần chuyển giao cho người, HandoverAgent chỉ cần đẩy session_id này vào hàng đợi của nhân viên vận hành. Giao diện của nhân viên sẽ lấy toàn bộ ngữ cảnh từ Redis và hiển thị đầy đủ, đảm bảo trải nghiệm liền mạch.

Kết luận

Từ góc nhìn của developer, hệ thống Single-Agent chỉ nên được xem xét cho các dự án nhỏ, thử nghiệm. Đối với một sản phẩm thực tế, có vòng đời dài và yêu cầu nghiệp vụ phức tạp như AI Sales Agent, đầu tư vào kiến trúc Multi-Agent theo mô hình microservices là một quyết định chiến lược.

Nó có thể đòi hỏi chi phí thiết lập ban đầu cao hơn (về CI/CD, infrastructure, monitoring), nhưng những lợi ích về tốc độ phát triển, khả năng mở rộng và sự ổn định của hệ thống trong dài hạn là không thể bàn cãi. Vấn đề cuối cùng không phải là xây dựng một con bot, mà là thiết kế một hệ thống phân tán, có khả năng chịu lỗi và có thể tiến hóa cùng với sự phát triển của hoạt động kinh doanh.