Các hệ thống Multi-agent và sự điều phối (Orchestration)

Orchestrator và Subagents: Vai trò, ủy quyền, tổng hợp

Một multi-agent system bao gồm 2 vai trò:

• Orchestrator (Bộ điều phối):

  Nắm giữ mục tiêu chung (owns the goal). Nó phân rã công việc, quyết định phần nào cần ủy quyền (delegate), và tổng hợp (synthesize) các kết quả thành một câu trả lời duy nhất. Orchestrator không bao giờ tự mình thực hiện các tác vụ con; công việc của nó thuần túy là ủy quyền và tổng hợp.

• Subagents (Agent phụ):

  Nắm giữ các tác vụ con trong phạm vi xác định (scoped sub-tasks). Mỗi subagent chạy trong context riêng của nó, hoàn thành một phần việc và trả về kết quả.

Có 3 điều bắt buộc phải được thiết kế chủ động chứ không thể mặc định:

1. Cách phân rã công việc thành các tác vụ con.

2. Cách cấu trúc kết quả của từng subagent để orchestrator có thể kết hợp chúng.

3. Cách orchestrator xử lý các xung đột hoặc khoảng trống dữ liệu khi nhận lại kết quả.

Mô hình thực tế: Fan-out trên một khối lượng công việc lớn

Hình thái multi-agent phổ biến nhất là fan-out (mở rộng song song).

Ví dụ: Một parent agent đối mặt với một khối lượng công việc quá lớn cho một context đơn lẻ: kiểm tra một codebase 400 files, tóm tắt tập tài liệu 200 trang, hoặc đối soát một hồ sơ pháp lý với 50 quy định.

Orchestrator sẽ chia nhỏ công việc thành các đơn vị độc lập, phân phát cho mỗi subagent một đơn vị (chạy song song (in parallel) nếu các đơn vị không phụ thuộc lẫn nhau), sau đó tổng hợp các kết quả trả về thành một sản phẩm hoàn chỉnh (deliverable).

Lợi ích ở đây là kép (twofold): mỗi subagent làm việc trong một context sạch sẽ vừa vặn với đơn vị công việc của nó, và các công việc độc lập được thực thi đồng thời (concurrently).

Khôi phục lỗi: Nơi có thể bắt được thất bại, và nơi không thể

Trong một multi-agent system, câu hỏi kiến trúc cần đặt ra là: "Mỗi failure mode có thể khôi phục ở đâu?"

• Một thất bại ở subagent thường có thể khôi phục: Nếu một đơn vị công việc bị lỗi, orchestrator có thể thử lại (retry), chuyển hướng (route) đi nơi khác, hoặc bỏ qua và ghi nhận khoảng trống đó, trong khi phần việc còn lại vẫn tiếp tục chạy.

• Một thất bại ở orchestrator thường không thể khôi phục: Nếu agent nắm giữ mục tiêu chính và luồng tổng hợp bị mất vết (loses its thread), toàn bộ lượt chạy sẽ thất bại, và kết quả từ các subagents có thể bị bỏ dở (stranded).

Hãy thiết kế cho sự bất đối xứng này: làm cho công việc của subagent mang tính idempotent (thực thi lại nhiều lần không làm thay đổi kết quả) và có thể thử lại (retryable), đồng thời bảo vệ trạng thái (state) của orchestrator.

Mô hình Checkpoint Human-in-the-loop cho Agent Workflows

Một multi-agent system có thể thực hiện nhiều hành động trước khi con người nhìn thấy đầu ra, điều này khiến việc bố trí checkpoint trở thành một quyết định thiết kế chủ động.

Một checkpoint human-in-the-loop là một cánh cổng (gate) tạm dừng thực thi để con người xem xét, được đặt dựa trên mức độ rủi ro (risk) và tính khả đảo (reversibility) của hành động sắp diễn ra. Hãy đặt một gate trước bất kỳ hành động không thể đảo ngược hoặc rủi ro cao nào mà subagent định tự động thực thi; lấy mẫu (sample) các hành động ít rủi ro hơn thay vì chặn ở từng hành động một. Gate là một phần của thiết kế điều phối (orchestration design), chứ không phải là thứ gắn thêm vào sau.

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Các hệ thống multi-agent nhân bản chi phí token: mỗi subagent có context riêng, và orchestrator tốn chi phí để tổng hợp. Chỉ chọn pattern này khi khối lượng công việc thực sự vượt quá một context, không dùng làm mặc định.

• Độ phức tạp (Complexity): Mỗi agent thêm vào là một ranh giới lỗi khác cần theo dõi và quản trị. Kỷ luật ở đây là dùng số lượng agents ít nhất có thể để đáp ứng yêu cầu, với quyền sở hữu mục tiêu rõ ràng.

• Rủi ro (Risk): Thất bại nguy hiểm nhất là thất bại trong im lặng: một subagent bỏ sót một đơn vị công việc và orchestrator tự tin tổng hợp một câu trả lời trông có vẻ hoàn chỉnh trên dữ liệu thiếu sót. Hãy kiểm tra phạm vi bao phủ (validate coverage), đừng mặc định là nó đã đủ.