Bài 10: Kiến Trúc Multi-Agent — Vai Trò & Giao Tiếp

Mở đầu: Track B bắt đầu — khi 1 agent không còn đủ

Track C (Bài 7–9) xây một Agent hoàn chỉnh: có tool, có memory, biết tự suy luận từng bước. Nhưng nhiều bài toán thực tế cần chia nhỏ theo VAI TRÒ — một agent lên kế hoạch, một agent viết code, một agent phản biện — thay vì nhồi tất cả trách nhiệm vào 1 agent duy nhất. Bài này mở Track B: điều phối nhiều agent cùng lúc.

Từ bài này, series dùng file dùng chung mới aisys-orchestrator.js — tách biệt khỏi aisys-agent-kernel.js của Track C, vì đây là một lớp trách nhiệm khác: điều phối GIỮA các agent, không phải logic BÊN TRONG 1 agent.

1. Vì Sao Một Agent Không Đủ Cho Task Phức Tạp

Khi giao 1 agent duy nhất một nhiệm vụ nhiều bước (lên kế hoạch, viết code, tự kiểm tra lại), nó phải "đóng nhiều vai" trong cùng 1 lượt suy luận — dễ bỏ sót bước (ví dụ quên tự phản biện code của chính mình, vì không có góc nhìn "bên ngoài"). Chia theo vai trò (Planner/Executor/Critic) giúp mỗi agent tập trung đúng 1 trách nhiệm, và quan trọng hơn: Critic đóng vai trò kiểm tra ĐỘC LẬP, không bị "thiên vị" bởi chính lý luận đã dùng để viết ra code đó.

2. Message Passing Giữa Agent

Các agent không gọi hàm trực tiếp lẫn nhau — chúng giao tiếp qua message: một cấu trúc dữ liệu có người gửi, người nhận, và nội dung. Đây là nền tảng để sau này (Bài 11) nhiều agent có thể ghi vào một trạng thái chung (blackboard) mà không phụ thuộc cứng vào lời gọi hàm của nhau:

class MessageBus {
  constructor() { this.log = []; }
  send(from, to, content) {
    const msg = { id: this.log.length, from, to, content };
    this.log.push(msg); // toàn bộ lịch sử giao tiếp được ghi lại — dễ audit
    return msg;
  }
  history() { return this.log; }
}

3. Điều Phối Tập Trung vs Phi Tập Trung

Có 2 cách tổ chức luồng giao tiếp: tập trung — mọi message đi qua 1 "orchestrator" trung gian quyết định ai nói với ai tiếp theo; và phi tập trung — các agent gửi thẳng cho nhau, tự thoả thuận thứ tự:

function relay(bus, from, to, content, mode) {
  if (mode === "centralized") {
    bus.send(from, "Orchestrator", content); // agent -> orchestrator
    bus.send("Orchestrator", to, content);   // orchestrator -> agent đích
  } else {
    bus.send(from, to, content); // gửi thẳng, 1 message duy nhất
  }
}

Ví dụ kiến trúc thật: AutoGen (Microsoft) nghiêng về mô hình "group chat" phi tập trung hơn, trong khi CrewAI có chế độ "hierarchical" gần với điều phối tập trung — cả hai sẽ được so sánh sâu hơn ở Bài 12.

4. Cạm Bẫy: Over-Engineering Multi-Agent

function estimateOverhead(agentCount, avgLatencyMsPerAgent, routingMode) {
  const messagesPerRound = routingMode === "centralized" ? agentCount * 2 : agentCount;
  const totalLatencyMs = messagesPerRound * avgLatencyMsPerAgent;
  return { messagesPerRound, totalLatencyMs };
}

// 1 agent đơn xử lý xong trong 1 bước ~ avgLatencyMs.
// 3 agent phi tập trung: 3x message, ~3x độ trễ.
// 3 agent tập trung: 6x message, ~6x độ trễ — GẤP ĐÔI so với phi tập trung,
// cho CÙNG một công việc — cái giá cụ thể của "dễ giám sát hơn" ở mục 3.

5. Thực hành tương tác: Planner–Coder–Critic

Chạy 1 vòng phối hợp 3 agent viết hàm cộng 2 số kèm validate — Coder cố tình "quên" validate ở lần đầu để bạn thấy rõ vòng phản hồi (feedback loop) khi Critic từ chối. Đổi chế độ điều phối để so sánh số lượng message:

import { MessageBus, definePlanner, defineCoder, defineCritic, runMultiAgentRound } from "./aisys-orchestrator.js";

const bus = new MessageBus();
const steps = runMultiAgentRound(bus, { planner, coder, critic }, task, routingMode);
// centralized luôn tốn ĐÚNG GẤP ĐÔI số message so với decentralized

Bài 11 sẽ thêm Blackboard — một không gian trạng thái CHUNG mà mọi agent cùng đọc/ghi, thay vì chỉ gửi message điểm-tới-điểm như bài này.