Agent 7 — Multi-agent & Orchestration: khi nào nhiều agent thắng một

Mặc định là một agent, không phải nhiều

Bản năng kỹ sư khi gặp bài toán khó là "chia để trị": tách thành nhiều agent chuyên biệt, mỗi con một việc, cho chúng phối hợp. Nhưng lời khuyên đầu tiên của Anthropic trong "Building effective agents" (Anthropic Engineering, 12/2024) là "start simple" — bắt đầu bằng thứ đơn giản nhất, chỉ tăng độ phức tạp khi thực sự cần. Một agent đơn với augmented LLM (model + retrieval + tools + memory) giải quyết được phần lớn công việc, và dễ gỡ lỗi hơn nhiều.

Vậy multi-agent không phải nâng cấp miễn phí. Nó là một giao dịch đánh đổi: bạn tiêu nhiều token hơn hẳn để đổi lấy độ bao phủ rộng và khả năng chạy song song. Trước khi dựng, hãy hỏi: tác vụ này có đủ giá trị, có chia được thành phần độc lập, và có thật sự chạy song song được không?

Con số biết nói (theo Anthropic)

Bài "Building a multi-agent research system" (Anthropic Engineering, 2025) công bố những số liệu đáng ghim. Trích nguyên, ghi rõ theo Anthropic:

• Hệ multi-agent vượt single-agent Claude Opus 4 khoảng 90,2% trên một eval nghiên cứu nội bộ (dạng tác vụ nghiên cứu mở, nhiều nguồn).
• Token giải thích khoảng 80% phương sai hiệu năng giữa các cấu hình — nghĩa là phần lớn khác biệt "giỏi/dở" đến từ việc đổ bao nhiêu token vào bài toán, không phải mẹo kiến trúc tinh vi.
• Về chi phí: một agent tiêu khoảng 4× token so với chat thông thường; một hệ multi-agent tiêu khoảng 15× token so với chat.

Đọc ba con số này cùng nhau, kết luận rất rõ: multi-agent chỉ đáng dùng cho tác vụ giá trị cao, chia được thành phần độc lập, chạy được song song. Với việc lặp vặt hằng ngày, cái giá 15× token là lãng phí. Với việc rà soát báo cáo tháng ảnh hưởng số liệu nộp cơ quan quản lý, 15× token là rẻ.

Quy tắc chọn: nếu bài toán hẹp và tuần tự → single-agent (xem harness engineering). Nếu rộng, nhiều nhánh tìm kiếm song song, mỗi nhánh có thể làm độc lập → cân nhắc multi-agent.

Mẫu orchestrator–worker

Đây là mẫu lõi của hệ multi-agent nghiên cứu, còn gọi là lead agent + subagents. Một orchestrator (agent điều phối) không tự làm hết mà phân rã bài toán, fan-out (phát tán) nhiều subagent/worker chạy song song, rồi thu (fan-in) và tổng hợp kết quả, cuối cùng verify (kiểm chứng) trước khi chốt.

Vì sao mẫu này hiệu quả cho breadth (bề rộng) và nghiên cứu nhiều nguồn?

• Cô lập context. Mỗi worker có cửa sổ context riêng, chỉ chứa phần việc của nó. Điều này chống "context rot" (chất lượng giảm khi context quá dài/nhiễu) mà một agent đơn phải nhồi tất cả nguồn vào một cửa sổ sẽ dính. Sub-agent là một cách cô lập context hiệu quả.
• Song song thật. N nguồn tra cứu độc lập → N worker chạy đồng thời, tổng thời gian gần bằng worker chậm nhất thay vì tổng các phần.
• Đổ được nhiều token vào đúng chỗ. Vì token giải thích ~80% phương sai, chia việc cho nhiều worker cho phép mỗi nhánh "đào sâu" mà không làm nổ context chung.
• Orchestrator giữ vai trò trí tuệ. Nó quyết định phân rã thế nào, worker nào cần chạy, và cách khớp các mảnh — đây là phần khó nhất, nên giao cho một model mạnh với extended thinking.

Điểm mấu chốt: orchestrator–worker giỏi ở bề rộng (nhiều nhánh song song), không giỏi ở chiều sâu tuần tự (mỗi bước phụ thuộc kết quả bước trước). Việc phụ thuộc chuỗi thì dùng workflow tuần tự sẽ tốt hơn.

Bản đồ các mẫu (Building effective agents)

Anthropic phân biệt rõ workflow (luồng do code định sẵn, các bước cố định) với agent (model tự định hướng, tự quyết bước tiếp theo). Nhiều bài toán chỉ cần workflow — rẻ hơn, dễ đoán hơn, dễ audit hơn. Dưới đây là các mẫu chuẩn và khi nào dùng.

Khác biệt then chốt giữa parallelization-sectioning và orchestrator–workers: sectioning là code chia phần tĩnh (bạn biết trước có mấy phần); orchestrator chia phần động (model tự quyết cần bao nhiêu worker và làm gì). Nếu bạn luôn có đúng 5 phần cố định, đừng cần orchestrator — chỉ cần fan-out tĩnh, rẻ và dễ đoán hơn.

Vài mẫu thực chiến hay gặp

Ngoài danh mục chuẩn, thực tế thường phối hợp thành các biến thể sau (đây là kinh nghiệm ngành, không phải thuật ngữ chính thức của Anthropic):

• Pipeline không rào chắn giữa stage. Các stage nối tiếp, output stage trước chảy thẳng vào stage sau mà không có "cổng người duyệt" ở giữa — nhanh, hợp cho luồng đã ổn định và có kiểm chứng tất định ở cuối.
• Adversarial verify (phản biện đối kháng). Sau khi tổng hợp, một agent riêng có nhiệm vụ cố bác bỏ kết luận ("mặc định là sai nếu không chứng minh được đúng"). Bắt lỗi mà tác giả không tự thấy. Chi tiết ở kiểm chứng & eval.
• Judge panel (hội đồng chấm). Nhiều evaluator độc lập chấm theo các tiêu chí khác nhau rồi gộp — biến thể của voting, giảm thiên lệch của một judge đơn.
• Loop-until-dry (lặp tới cạn). Orchestrator lặp fan-out cho tới khi các worker không còn tìm ra thông tin/sai lệch mới — dừng theo hết việc thay vì đủ số vòng.

Thách thức của multi-agent

Nhiều agent không miễn phí. Những cái giá thật cần lường trước:

• Chi phí token. ~15× so với chat. Mỗi worker có system prompt, context, và vòng lặp tool riêng. Chi phí cộng dồn rất nhanh.
• Độ trễ và điều phối. Fan-out song song giúp giảm thời gian tường (wall-clock), nhưng bước tổng hợp phải đợi worker chậm nhất; và nếu có phụ thuộc chuỗi thì lợi thế song song mất.
• Quản trạng thái. Ai giữ "sự thật hiện tại"? Khi nhiều worker cùng đọc/ghi, trạng thái chia sẻ dễ lệch.
• Race condition. Hai worker cùng cập nhật một tài nguyên, hoặc kết quả về không đúng thứ tự → khớp nhầm mảnh. Với dữ liệu ngân hàng, đây là rủi ro thật.
• Khó gỡ lỗi & tái hiện. Chạy song song + tính bất định của model làm cùng một input có thể ra đường đi khác nhau. Cần tracing đầy đủ mới lần được.
• Lan truyền lỗi (error propagation). Một worker hiểu sai nhiệm vụ, kết quả sai của nó trôi vào bản tổng hợp và "nhiễm" kết luận cuối.

Mẹo giảm đau, rút từ thực tiễn của Anthropic:

1. Prompt subagent rõ ràng và đủ. Mỗi worker phải biết chính xác mục tiêu, phạm vi, định dạng output, và khi nào dừng. Worker mơ hồ sẽ đi lạc và đốt token.
2. Chia việc không chồng lấn. Ranh giới nhiệm vụ rạch ròi để hai worker không làm trùng (lãng phí) hoặc bỏ sót khe hở (thủng).
3. Tổng hợp + verify ở cuối. Đừng tin kết quả worker là đúng. Bước fan-in phải gom mâu thuẫn, và một lớp verifier (tất định nếu được, hoặc adversarial) phải chốt trước khi trả người dùng.
4. Cho worker trả kèm bằng chứng. Mỗi khẳng định đi kèm trích dẫn nguồn/số liệu để verifier soi lại được, thay vì tin lời.

Pseudocode: orchestrator fan-out N worker + verifier

Minh hoạ dựng bằng Anthropic SDK (Python). Đây là pseudocode minh hoạ, lược phần xử lý lỗi/tool để tập trung vào khung điều phối. Model mặc định claude-opus-4-8, extended thinking dùng thinking={"type": "adaptive"} (không dùng budget_tokens).

# MINH HOẠ — orchestrator fan-out N worker rồi verifier tổng hợp
import asyncio
from anthropic import Anthropic

client = Anthropic()
MODEL = "claude-opus-4-8"

def run_worker(task: dict) -> dict:
    """Một subagent: nhận nhiệm vụ hẹp, trả kết quả + bằng chứng."""
    resp = client.messages.create(
        model=MODEL,
        max_tokens=4096,
        thinking={"type": "adaptive"},
        system=(
            "Bạn là worker chuyên trách. Chỉ làm ĐÚNG nhiệm vụ được giao, "
            "không lấn phạm vi worker khác. Mọi khẳng định phải kèm bằng chứng "
            "(số liệu, dòng dữ liệu). Nếu không đủ dữ liệu, nói rõ 'không kết luận được'."
        ),
        messages=[{"role": "user", "content": task["prompt"]}],
    )
    return {"task_id": task["id"], "content": resp.content}

async def orchestrate(user_request: str) -> str:
    # 1) Orchestrator PHÂN RÃ thành N nhiệm vụ không chồng lấn
    plan = client.messages.create(
        model=MODEL, max_tokens=2048, thinking={"type": "adaptive"},
        system="Phân rã yêu cầu thành các nhiệm vụ ĐỘC LẬP, không chồng lấn. "
               "Trả về danh sách nhiệm vụ, mỗi nhiệm vụ có phạm vi rõ ràng.",
        messages=[{"role": "user", "content": user_request}],
    )
    tasks = parse_tasks(plan)  # -> [{"id":..., "prompt":...}, ...]

    # 2) FAN-OUT song song: chạy N worker đồng thời
    loop = asyncio.get_event_loop()
    results = await asyncio.gather(*[
        loop.run_in_executor(None, run_worker, t) for t in tasks
    ])

    # 3) FAN-IN: tổng hợp, khử trùng lặp, gom mâu thuẫn
    synthesis = client.messages.create(
        model=MODEL, max_tokens=4096, thinking={"type": "adaptive"},
        system="Tổng hợp kết quả các worker. Nêu rõ điểm mâu thuẫn giữa các nguồn, "
               "KHÔNG tự bịa để lấp khoảng trống.",
        messages=[{"role": "user", "content": format_results(user_request, results)}],
    )

    # 4) VERIFY: agent phản biện cố bác bỏ trước khi chốt
    verdict = client.messages.create(
        model=MODEL, max_tokens=2048, thinking={"type": "adaptive"},
        system="Bạn là verifier đối kháng. Cố tìm lý do bản tổng hợp SAI hoặc "
               "thiếu bằng chứng. Mặc định KHÔNG đạt nếu không chứng minh được đúng.",
        messages=[{"role": "user", "content": as_text(synthesis)}],
    )
    if not passed(verdict):
        return orchestrate_fix(synthesis, verdict)  # vòng sửa
    return as_text(synthesis)

Vài điểm đáng chú ý trong khung này: worker chạy qua asyncio.gather để song song thật; mỗi worker có system prompt cấm lấn phạm vi và bắt kèm bằng chứng; bước tổng hợp cấm bịa lấp khoảng trống; và verifier là đối kháng — mặc định không đạt. Đây chính là bốn mẹo giảm đau ở trên, đóng thành code.

Use case thực tế

Bối cảnh NCB. Cuối mỗi tháng, tổ báo cáo phải rà bộ báo cáo quản trị (hàng chục bảng: dư nợ, huy động, phân loại nợ, dự phòng...) trước khi trình lãnh đạo và trích xuất số nộp NHNN. Làm tay tốn 1,5–2 ngày công và vẫn lọt sai lệch. Ta dựng một hệ orchestrator + 5 worker + 1 verifier, chạy trên read-replica (bản sao chỉ đọc) để không đụng hệ thống giao dịch.

Phân rã (5 worker không chồng lấn):

Năm worker chạy song song (fan-out), mỗi con context riêng, trả kết quả kèm bằng chứng (bảng/dòng cụ thể). Orchestrator fan-in: gom phát hiện, khử trùng lặp (W2 và W3 có thể cùng chỉ ra một dòng), gắn mức nghiêm trọng. Cuối cùng verifier đối kháng soi lại từng cờ đỏ, loại false positive (báo động giả) rồi mới đẩy sang human-in-the-loop — cán bộ nghiệp vụ duyệt lần cuối. Mọi phát hiện ghi vào audit log.

Đánh đổi token (nói rõ là ước lượng). So với việc chạy một agent đơn rà tuần tự, hệ 5 worker + orchestrator + verifier tiêu khoảng 10–15× token cho một kỳ rà soát — trùng hướng với con số ~15× của Anthropic. Với NCB, một lần chạy đầy đủ ước tính vài đô-la token; so với 1,5–2 ngày công và rủi ro nộp sai số cho cơ quan quản lý, cái giá này rẻ.

Lợi ích (ước lượng nội bộ). Vì mỗi worker chỉ lo một góc và soi sâu, hệ bắt được nhiều sai lệch hơn so với agent đơn nhồi tất cả vào một context (chống context rot). Ước tính rút thời gian rà từ ~1,5 ngày xuống còn vài giờ, và số cờ đỏ hợp lệ phát hiện tăng rõ so với quy trình thủ công cũ — dù con số chính xác phụ thuộc từng kỳ và cần đo bằng bộ eval offline trước khi tin. Đúng tinh thần: đổi token lấy độ bao phủ, chấp nhận trả nhiều token để không lọt sai lệch đắt giá.

Một ví dụ kiểm tra tất định mà W1 dùng — đối chiếu tổng phát sinh theo loại giao dịch, chạy được trên sandbox:

-- ▶ Chạy được
SELECT a.currency, t.kind,
       COUNT(*) AS so_but_toan,
       ROUND(SUM(t.amount)::numeric, 2) AS tong_phat_sinh
FROM transactions t
JOIN accounts a ON a.id = t.account_id
GROUP BY a.currency, t.kind
ORDER BY a.currency, t.kind;

Ghi nhớ

• Mặc định single-agent, "start simple". Multi-agent là giao dịch đổi token lấy độ bao phủ/song song, không phải nâng cấp miễn phí.
• Số liệu theo Anthropic: multi-agent vượt single-agent Opus 4 ~90,2% trên eval nội bộ; token giải thích ~80% phương sai; agent ~4× token, multi-agent ~15× token so với chat ⇒ chỉ dùng cho tác vụ giá trị cao, chia được, chạy song song.
• Orchestrator–worker: lead agent phân rã → fan-out song song → fan-in tổng hợp → verify. Giỏi bề rộng/nhiều nguồn nhờ cô lập context; không giỏi chuỗi phụ thuộc tuần tự.
• Biết các mẫu và khi nào dùng: prompt chaining (bước cố định), routing (nhiều loại đầu vào), parallelization sectioning/voting (chia tĩnh/độ tin cậy), orchestrator–workers (chia động), evaluator–optimizer (có tiêu chí, lặp cải thiện).
• Phân biệt parallelization-sectioning (code chia tĩnh) với orchestrator (model chia động) — có 5 phần cố định thì đừng cần orchestrator.
• Thách thức: chi phí token, độ trễ, quản trạng thái, race condition, khó gỡ lỗi/tái hiện, lan truyền lỗi.
• Bốn mẹo giảm đau: prompt subagent rõ-đủ; chia việc không chồng lấn; tổng hợp + verify ở cuối; buộc worker trả kèm bằng chứng.
• Ở NCB: orchestrator + 5 worker + verifier rà báo cáo tháng, ~10–15× token nhưng bắt nhiều sai lệch hơn và rút thời gian rà xuống còn vài giờ — luôn kết bằng human-in-the-loop và audit log.

Nguồn tham khảo

• Anthropic Engineering — "Building a multi-agent research system" (anthropic.com/engineering): kiến trúc orchestrator–worker, các số liệu token và hiệu năng dẫn trong bài.
• Anthropic Engineering — "Building effective agents" (12/2024): phân biệt workflow vs agent và các mẫu prompt chaining, routing, parallelization, orchestrator–workers, evaluator–optimizer.
• Anthropic Engineering — "Effective context engineering for AI agents": cô lập context bằng sub-agent, compaction, just-in-time retrieval, hiện tượng context rot.
• Anthropic — Tài liệu Claude Agent SDK và repo anthropics/claude-agent-sdk-python: khung dựng agent chạy vòng lặp + tool + sub-agent.
• Anthropic — Messages API documentation (docs.anthropic.com): tool use loop, stop_reason, extended thinking, prompt caching.