Trả lời ngắn: Multi-Agent Workflow chia một việc cho nhiều agent và quy định cách bàn giao. Agent nghiên cứu giao bảng nhận định, nguồn và trạng thái; agent biên tập chỉ bắt đầu khi bảng đủ cột. Dùng nhiều agent không tự động làm kết quả thông minh hơn; cách này tăng công phối hợp và số chỗ có thể lỗi.

Đọc xong, bạn sẽ hiểu:

  • Khi nào một agent là đủ và khi nào nên tách nhiều agent.
  • Pipeline, manager-worker, fan-out/fan-in và peer handoff khác nhau thế nào.
  • Handoff contract, shared state, ownership lease và verifier phối hợp ra sao.
  • Cách chặn vòng lặp, làm trùng, ghi đè và chi phí chạy mất kiểm soát.

Lưu ý giáo dục: Bài tập chỉ thiết kế trên Markdown hoặc Sheet, không gọi model, API hay công cụ thật. Trong production, không trao quyền ghi/xoá rộng cho agent chỉ vì nó có vai trò chuyên gia.

1. Multi-Agent Workflow là gì?

a. Không phải thêm nhiều “nhân vật” vào phòng chat

Một agent có thể tự lập kế hoạch, tìm dữ liệu, viết và kiểm tra. Multi-agent chỉ đáng dùng khi chuyên môn hoá tạo lợi ích lớn hơn chi phí bàn giao.

OpenAI khuyến nghị trước hết nên tối đa hoá khả năng của một agent. Tách nhiều agent khi logic nhiều nhánh làm instruction khó duy trì, hoặc các tool giống nhau khiến agent thường chọn nhầm. Đây là nguyên tắc quan trọng: đừng dùng sơ đồ tổ chức để che một prompt hoặc tool contract còn mơ hồ.

Trong workflow đúng, agent không “trò chuyện cho tới khi thấy ổn”. Chúng nhận task ID, input, quyền, deadline và acceptance criteria; sau đó trả artifact, evidence, status và next action. Một cạnh trong đồ thị là hợp đồng bàn giao, không phải câu nói tự do.

b. Công thức dễ nhớ

Goal Contract + Task Graph + Typed Handoff + Shared State + Ownership Lease + Verifier + Stop Policy.

  • Goal Contract chốt mục tiêu, phạm vi, tiêu chí xong và điều cấm.
  • Task Graph cho biết task nào phụ thuộc task nào.
  • Typed Handoff chuẩn hoá vật được chuyển.
  • Shared State là nguồn trạng thái chung có version.
  • Ownership Lease chỉ cho một owner sửa artifact tại một thời điểm.
  • Verifier kiểm output độc lập.
  • Stop Policy giới hạn vòng, thời gian, token, tiền và điều kiện gọi người.

Hình 1 — Fan-out tạo các nhánh chuyên trách; fan-in chỉ hợp nhất artifact đã qua hợp đồng và kiểm tra.

2. Khi nào nên dùng một agent, pipeline, manager hay peer handoff?

a. Bắt đầu với single agent

Dùng một agent nếu task ngắn, tool ít và khác biệt rõ, context vừa cửa sổ, một người có thể kiểm output. Lợi ích là ít latency, ít token, trace đơn giản và không mất thông tin khi bàn giao.

Chỉ tách khi có ít nhất một lý do đo được: hai nhánh độc lập có thể chạy song song; prompt có các miền xung đột; quyền tool phải cô lập; một verifier cần độc lập với producer; hoặc context chuyên môn của một nhánh làm nhiễu nhánh khác.

b. Bốn topology phổ biến

Topology Hợp khi Rủi ro chính
Sequential pipeline Output A là input bắt buộc của B Sai sớm truyền xuống cuối
Manager-worker Một orchestrator giữ mục tiêu và tổng hợp Manager thành nút nghẽn
Fan-out/fan-in Nhiều nhánh thật sự độc lập Trùng nguồn, merge xung đột
Peer handoff Chuyên môn thay đổi theo trạng thái Mất owner, chuyền vòng

Manager pattern giữ một agent tiếp xúc người dùng và gọi specialist như tool. Decentralized pattern chuyển quyền giữa các peer. Anthropic dùng orchestrator-worker cho research: lead lập chiến lược, subagent tìm các mặt độc lập rồi trả artifact để tổng hợp. Cách này tăng token và đòi hỏi giao task rõ.

c. Chọn bằng ma trận nhỏ

Hỏi bốn câu:

  1. Các nhánh có input/output độc lập không?
  2. Có cần quyền tool khác nhau không?
  3. Có tiêu chí verify riêng cho từng nhánh không?
  4. Lợi ích latency/chất lượng có bù token và debugging không?

Nếu phần lớn câu trả lời là “không”, giữ single agent.

3. Một task đi qua handoff, shared state và verification ra sao?

a. Goal Contract và task graph

Ví dụ mục tiêu giả: tạo hướng dẫn trồng cây trên ban công. Contract ghi audience, độ dài, nguồn được phép, không tư vấn hoá chất nguy hiểm và hoàn tất khi facts có nguồn, draft đúng outline, verifier pass.

Orchestrator tạo graph:

goal_contract → [outline || research] → join(outline, claim_ledger) → draft → verify → publish_candidate. Draft phải chờ Claim Ledger. Publish candidate phải chờ verifier. Dependency được máy kiểm, không dựa vào việc agent “nhớ”.

b. Handoff Envelope

Một bàn giao tối thiểu:

{
  "task_id": "research-03",
  "artifact_uri": "artifacts/claim-ledger-v2.json",
  "evidence": ["source-A", "source-B"],
  "state_version": 7,
  "owner": "researcher",
  "status": "ready_for_review",
  "next_action": "verify_claims"
}

Artifact nằm trong store; message chỉ trỏ tới nó. Schema validator chặn thiếu field. Evidence cho verifier biết dựa vào đâu. state_version ngăn output cũ ghi đè state mới.

Hình 2 — Bàn giao tốt chuyển artifact kiểm được, không chỉ chuyển một đoạn hội thoại.

c. Shared state, lease và idempotency

Shared state không có nghĩa mọi agent được sửa mọi thứ. Orchestrator cấp ownership lease: Researcher sở hữu Claim Ledger trong một khoảng; Writer chỉ đọc. Khi Writer tạo draft, nó giữ lease của draft-v1.

Hai worker cùng sửa một file là lỗi thiết kế. Version check kiểu “chỉ ghi nếu version vẫn là 7” chặn lost update. Nếu worker timeout rồi chạy lại, idempotency key bảo đảm không tạo hai artifact hoặc gửi hai email.

AutoGen Core dùng event-driven và asynchronous messaging. Vì vậy cần trace, correlation ID, retry policy và observability như hệ thống phân tán.

d. Verifier và merge

Producer không tự tuyên bố “approved”. Verifier đọc acceptance criteria, artifact và evidence; trả:

  • approved
  • needs_revision kèm issue ID cụ thể
  • blocked kèm payload thiếu
  • rejected khi vi phạm scope/safety

Fan-in dedupe theo claim/source, phát hiện mâu thuẫn và ghi provenance. Orchestrator chỉ merge phần đã pass; không chọn câu trả lời dài nhất hoặc tự tin nhất.

4. Lỗi phổ biến: context trôi, làm trùng, vòng lặp và “đám đông cùng sai”

a. Tám lỗi hay gặp

  1. Task mơ hồ: “nghiên cứu thêm” không có output schema.
  2. Context drift: mỗi handoff tóm tắt khác goal ban đầu.
  3. Duplicate work: nhiều worker tìm cùng một nhánh.
  4. Conflicting write: hai owner sửa chung artifact.
  5. Error amplification: agent sau tin claim sai của agent trước.
  6. Circular handoff: A chuyển B, B trả A không có điều kiện dừng.
  7. Permission sprawl: mọi worker có quyền ghi production.
  8. Runaway budget: fan-out/retry/reflection tăng token và latency.

Ba agent đồng ý không tạo thành sự thật nếu cả ba dùng cùng nguồn sai. Cần verifier kiểm evidence.

b. Stop Policy phải là dữ liệu

Ví dụ: tối đa 2 revision/task, 4 worker song song, 20 phút, budget 100 đơn vị, không retry lỗi validation, retry tối đa 2 lần cho lỗi mạng, và chuyển human khi cùng issue xuất hiện lần ba.

Phân biệt:

  • Deadlock: các task chờ nhau, không task nào chạy được.
  • Livelock: agent vẫn nhắn/chỉnh nhưng state không tiến.
  • Blocked: thiếu quyền hoặc payload bên ngoài.
  • Failed: đã có lỗi xác định và runbook xử lý.

Hình 3 — Workflow đáng tin cần control plane giới hạn quyền, số vòng và đường escalation.

c. Checklist production

  • Goal, done criteria và forbidden actions có test được?
  • Mỗi node có input/output schema, owner và timeout?
  • Edge chuyển artifact/evidence hay chỉ chuyển lời kể?
  • Shared state có version, lease và audit log?
  • Retry có idempotency; side effect có approval/guardrail?
  • Verifier độc lập và issue có ID cụ thể?
  • Fan-out có giới hạn, dedupe và merge policy?
  • Trace có task ID, parent ID, model/tool/cost/latency?
  • Có max loop, budget, stop, rollback và human escalation?
  • Evals so sánh single-agent baseline với multi-agent không?

Theo NIST AI RMF, ngoài chất lượng cần đo handoff failure, duplicate, revision loop, merge conflict, cost/task và time-to-escalate.

5. Bài tập 15 phút: thiết kế workflow ba agent trên giấy

a. Chuẩn bị

Dùng Markdown hoặc Sheet. Mục tiêu giả: viết hướng dẫn 500 từ “trồng rau thơm trên ban công”. Ba vai trò: Planner, Researcher, Writer; Verifier là checklist deterministic do bạn đóng vai. Không gọi API.

b. Năm bước

  1. Viết Goal Contract: audience, output, nguồn, điều cấm, done criteria.
  2. Vẽ 5 node và dependency.
  3. Gán owner/lease cho từng artifact.
  4. Viết hai Handoff Envelope.
  5. Chạy verifier; tối đa 2 revision rồi chuyển human.

c. Mẫu đối chiếu đã điền

Task Input Output/handoff Stop
plan-01 goal-v1 outline-v1, version 1 thiếu audience→blocked
research-01 outline-v1 claim-ledger-v1, 3 nguồn claim thiếu nguồn→revise
write-01 outline+ledger draft-v1, 500±50 từ không tự thêm claim
verify-01 draft+ledger approved/issues 2 vòng→human

Handoff mẫu: task_id=research-01, artifact=claim-ledger-v1, evidence=3 URLs, state_version=2, owner=researcher, status=ready_for_review, next_action=verify_claims.

d. Kết quả mong đợi

Bạn phải chỉ được ai có quyền sửa artifact nào, verifier kiểm gì và lúc nào workflow dừng. Thử tạo lỗi: Writer thêm một claim không có ledger. Kết quả đúng là issue cụ thể, không phải Researcher và Writer tranh luận vô hạn.

6. Tổng kết: chia chuyên môn, không chia trách nhiệm

a. Năm ý chính

  • Bắt đầu bằng single agent; chỉ tách khi có lợi ích đo được.
  • Multi-agent là task graph và hợp đồng artifact, không phải group chat tự do.
  • Shared state cần version, ownership lease và idempotency.
  • Producer tạo output; verifier độc lập quyết định acceptance.
  • Budget, max loop, stop và human escalation là phần của kiến trúc.

b. Câu hỏi tự kiểm tra

  • Khi nào manager-worker hợp hơn peer handoff?
  • Vì sao message không nên chứa toàn bộ artifact?
  • Ownership lease giải quyết lỗi gì?
  • Ba agent cùng đồng ý có đủ để merge không?

c. Gợi ý đáp án

Xem gợi ý câu 1Khi cần một owner giữ mục tiêu, giao specialist như tool và tổng hợp một trải nghiệm thống nhất. Xem mục 2.
Xem gợi ý câu 2Artifact store có version và provenance; message chỉ trỏ URI giúp handoff nhỏ, kiểm được và tránh tóm tắt làm mất dữ liệu. Xem mục 3.
Xem gợi ý câu 3Nó ngăn hai agent cùng sửa một artifact và gây lost update; kết hợp version check để phát hiện output cũ. Xem mục 3.
Xem gợi ý câu 4Chưa đủ. Họ có thể dùng cùng nguồn sai. Cần evidence, độc lập phù hợp và verifier theo acceptance criteria. Xem mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Orchestrator Thành phần phân công và tổng hợp.
Worker Agent xử lý một task có ranh giới.
Task Graph Đồ thị task và dependency.
Handoff Contract Schema bàn giao artifact và trạng thái.
Shared State Nguồn trạng thái chung có version.
Ownership Lease Quyền sửa tạm thời một artifact.
Fan-out/Fan-in Chia nhánh song song rồi hợp nhất.
Verifier Thành phần kiểm output độc lập.
Idempotency Chạy lại không tạo side effect trùng.
Stop Policy Giới hạn vòng, thời gian và ngân sách.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Trading Agent #47 để thấy risk, execution và reconciliation được tách thành các owner riêng. Học tiếp AI System Design #49 — ghép model, context, tools, state, data, evals, guardrails và vận hành thành một hệ thống hoàn chỉnh.

Nhắc lại giáo dục: Nhiều agent làm tăng token, latency, quyền và bề mặt lỗi. Chỉ trao quyền tối thiểu; external write cần idempotency, guardrail và audit; mọi workflow phải có người chịu trách nhiệm và đường dừng rõ.