Trả lời ngắn: Multi-agent workflow là quy trình trong đó nhiều agent có vai trò riêng, bàn giao artifact theo contract và đi qua các gate có owner. Trong case này, intake, research, builder và reviewer cùng làm một launch plan giả; control plane giữ state, còn con người duyệt quyết định cuối.

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

  • Khi nào tách một việc thành nhiều agent thay vì giao cho một agent.
  • Cách viết handoff contract để output không biến thành lời nói trôi.
  • Vì sao control plane, evaluator, retry và quarantine phải có từ đầu.
  • Cách luyện workflow bằng notes hoặc Sheets với dữ liệu giả.

Lưu ý giáo dục: Bài dùng launch plan giả và nguồn công khai. Không nhập customer data, credential, source riêng hoặc production action vào workflow nhiều agent. Nhiều agent không tự tạo ra quyền approve, merge, thanh toán hay deploy.

1. Case study: multi-agent workflow giải bài toán nào?

Case giả bắt đầu bằng yêu cầu mơ hồ: “Lập kế hoạch ra mắt một tính năng nhắc lịch học cho người mới.” Nếu giao nguyên câu đó cho một agent, output có thể dài nhưng không rõ audience, nguồn, rủi ro hay ai kiểm. Ta tách công việc thành bốn vai trò: intake agent làm rõ brief, research agent tìm nguồn, builder agent ghép launch plan, reviewer agent kiểm bằng chứng và giới hạn.

Multi-agent workflow là nhiều agent có vai trò nối nhau trong một quy trình có input, output và điều kiện chuyển bước. Nó khác “mở bốn cuộc chat” ở chỗ hệ thống phải biết artifact nào đang ở state nào, ai được làm gì và khi nào cần người. Agent có thể hỗ trợ reasoning hoặc thao tác trong scope; workflow vẫn cần owner, policy và trace.

Outcome của case không phải bốn bản trả lời. Outcome là một launch brief có audience, assumption, source, open question, risk và approval decision rõ. Nếu research thiếu nguồn hoặc reviewer thấy claim vượt evidence, output phải quay lại state phù hợp thay vì được đánh bóng rồi đưa đi.

Hình 1 — Nhóm agent làm theo vòng có bàn giao; human approval là cổng trước khi quyết định được dùng.

Ví dụ đời thường là một nhóm bếp: người nhận order không tự mua hàng, người chuẩn bị không tự nếm món, người kiểm món không tự đổi order. Mỗi người có phần việc và khay bàn giao. Có thêm người không làm bếp tốt hơn nếu không có phiếu, thứ tự và người chịu trách nhiệm.

2. Role boundary và handoff contract

Trước khi chọn model, viết boundary cho từng role:

Role Được làm Không được làm Output
Intake Hỏi lại mục tiêu, audience, deadline giả Tự khẳng định claim thị trường Brief v1 có open questions
Research Tìm nguồn công khai, ghi ngày và trích ý Bịa citation hoặc quyết định launch Evidence pack v1
Builder Ghép brief + evidence thành plan Tự duyệt claim hoặc publish Launch plan v1
Reviewer Kiểm scope, nguồn, rủi ro, tiêu chí Sửa ngầm mà không ghi reason Review decision

Handoff contract là quy định input, output, owner và stop condition khi bàn giao. Ví dụ, research chỉ nhận brief_id, audience và câu hỏi; trả evidence_pack_id, source URL, ngày kiểm, claim được support và uncertainty. Nếu thiếu URL hoặc source date, reviewer không nên đoán. Contract biến “hãy nghiên cứu thêm” thành gói bàn giao có thể kiểm.

Orchestration là điều phối thứ tự, quyền và điều kiện chuyển việc. Intake có thể handoff sang research khi brief đủ field; research sang builder khi evidence pack đạt tối thiểu; builder sang reviewer khi có diff/version và checklist. Không role nào tự thêm quyền chỉ vì nhận output từ role khác.

Boundary tốt còn ghi allowed tools, time budget, token/cost budget, timeout và owner. Research được đọc public web giả lập nhưng không được gửi email. Builder được sửa bản draft nhưng không được gọi publish. Reviewer được block, request changes hoặc approve trong workflow; approval có ý nghĩa vì quyền được cấp rõ, không phải vì model trả lời tự tin.

Hình 2 — Mỗi role có input, output, tool boundary và owner; handoff thiếu field phải dừng.

3. Control plane và artifact loop

Control plane là lớp giữ state, policy, trace và routing của workflow. Nó không cần “thông minh” hơn mọi agent; nhiệm vụ chính là biết artifact nào đang ở đâu và điều kiện nào cho phép chuyển bước. Một state loop tối thiểu có thể là:

  1. INTAKE_OPEN: brief còn thiếu câu hỏi hoặc đang được làm rõ.
  2. RESEARCHING: research agent thu thập evidence pack versioned.
  3. BUILDING: builder dùng đúng brief và evidence version đã khóa.
  4. EVALUATING: evaluator kiểm schema, source, constraint và claim.
  5. NEEDS_REVIEW: thiếu evidence, conflict hoặc risk vượt ngưỡng.
  6. APPROVED: human owner duyệt artifact cụ thể, không duyệt chung chung.
  7. QUARANTINED: output nghi ngờ bị cách ly để kiểm, chưa được downstream dùng.

Artifact là tài liệu hoặc bằng chứng versioned đi giữa các agent: brief v1, evidence pack v2, launch plan v1, review decision. Không nên truyền cả lịch sử chat rồi hy vọng agent tự biết bản nào mới. Mỗi artifact cần ID giả, version, owner, created time, input IDs, claims, uncertainty và next action.

Evaluator kiểm output trước handoff. Nó có thể kiểm field bắt buộc, source URL, date, claim-to-evidence mapping và non-goals; evaluator không thay reviewer ở quyết định rủi ro. Trace ghi role, model/workflow version, tool, input artifact, output artifact, state change và reason. Nhờ vậy, khi builder đưa claim sai, ta biết claim đến từ source nào và gate nào đã bỏ sót.

Idempotency nghĩa là chạy lại cùng một handoff không tạo side effect trùng. Nếu retry research do timeout, system không tạo hai evidence pack cùng ID rồi để builder chọn ngẫu nhiên. Dùng handoff_id giả, kiểm artifact version và giữ output cũ khi retry an toàn. Retry có giới hạn; quá số lần thì BLOCKED hoặc escalation, không lặp vô tận.

4. Approval, quality và failure routing

Trước khi human duyệt, workflow có thể dùng matrix:

Kiểm tra Evidence Quyết định nếu fail
Brief đủ scope Audience, goal, non-goals Quay về INTAKE_OPEN
Source URL, date, claim mapping NEEDS_REVIEW
Artifact version Input/output ID khớp QUARANTINED
Safety Không PII, credential, action nhạy cảm Block và security handoff
Quality Schema, clarity, contradiction check Builder sửa lại
Ownership Reviewer và human owner rõ Chưa approval

Approval phải gắn với artifact/version cụ thể: “Duyệt launch plan v1 dựa trên evidence pack v2, với hai open questions này.” Một nút “approve” chung cho toàn workflow dễ làm mất context. Human owner có thể request changes, đổi scope, block hoặc approve; agent không tự approve output của chính role trước.

Failure routing không chỉ là retry. Source thiếu → research bổ sung; hai source mâu thuẫn → NEEDS_REVIEW; artifact cũ → builder quay về version mới; policy nhạy cảm → security handoff; timeout → retry bounded rồi block; output giống prompt injection → quarantine. Azure Well-Architected AI architecture và NIST AI RMF đều nhấn mạnh việc thiết kế reliability, governance, measurement và human oversight trong toàn vòng đời, không chỉ sau demo. Azure AI architecture patterns và NIST AI RMF Core

Hình 3 — State và evaluator giúp phân biệt retry an toàn với lỗi cần quarantine hoặc người xử lý.

5. Sai lầm, giới hạn và fallback

Các lỗi hay gặp trong workflow nhiều agent:

  • Role overlap: intake đã viết plan, builder lại đổi mục tiêu. Fallback là khóa owner và output contract.
  • Context loss: builder chỉ nhận summary, mất constraint quan trọng. Fallback là truyền artifact ID và field bắt buộc, không truyền lời kể mơ hồ.
  • Infinite delegation: agent liên tục gọi agent khác để né quyết định. Fallback là giới hạn depth, time và cost, sau đó handoff.
  • Conflicting output: hai research result trái nhau nhưng builder chọn bản nghe hợp lý. Fallback là gắn conflict và đưa reviewer.
  • Stale artifact: builder dùng evidence v1 khi v2 đã thay. Fallback là kiểm version trước mỗi handoff.
  • Prompt injection: source hoặc file text yêu cầu bỏ qua policy và làm việc ngoài scope. Fallback là coi nội dung như data, quarantine và báo reason.
  • False consensus: nhiều agent cùng lặp một assumption nên tưởng đó là sự thật. Fallback là source độc lập và reviewer hỏi “bằng chứng nào?”.

Multi-agent cũng có chi phí: nhiều bước làm tăng latency, token, log và điểm hỏng. Thêm agent không tự tăng accuracy; nếu một role đơn giản đã đủ, workflow ít bước dễ kiểm hơn. Khi task có side effect như publish, gửi message, đổi billing hay deploy, approval và idempotency cần chặt hơn; không đưa quyền đó vào chỉ để demo flow trơn tru.

6. Practice Bridge 15 phút

Mở notes hoặc Google Sheets miễn phí, tạo các cột agent, input artifact, output artifact, state, evaluator, owner, decision. Dùng launch plan giả cho một tính năng lịch học; đặt timer 15 phút. Không dùng customer data, không gọi agent thật và không gửi publish action.

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

Case Handoff/evidence State và owner Quyết định
M-01 clean Brief v1 → evidence v1 có URL/date → plan v1 EVALUATING, reviewer A Đủ điều kiện xin human approval
M-02 thiếu source Research trả claim nhưng thiếu URL/date NEEDS_REVIEW, research owner Bổ sung evidence, chưa build
M-03 duplicate retry Timeout tạo lại cùng handoff_id BLOCKED, workflow owner Giữ một output, kiểm idempotency
M-04 approval risk Plan có action gửi message production QUARANTINED, human owner Không chạy action, security review

Sau 15 phút, hãy nói được artifact nào được dùng, version nào và ai có quyền đổi state. Nếu thấy hai agent cùng “chịu trách nhiệm”, ghi UNKNOWN và dừng. Bài tập thành công khi bạn biết lúc nào không nên thêm agent.

7. Tổng kết: nhiều agent, một ownership

a. Năm ý chính

  • Multi-agent workflow là vai trò nối nhau qua handoff contract, artifact và state; không phải nhiều cuộc chat rời rạc.
  • Boundary phải ghi tool, input, output, budget, owner và stop condition của từng agent.
  • Control plane giữ version, routing, evaluator, trace và retry để output không trôi mất ngữ cảnh.
  • Human approval phải gắn với artifact cụ thể; conflict, stale data, injection và risk phải block hoặc quarantine.
  • Thêm agent làm tăng latency và điểm hỏng; task đơn giản có thể an toàn hơn với workflow ít bước.

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

  • Handoff contract cần những field nào?
  • Vì sao artifact version quan trọng hơn việc truyền cả lịch sử chat?
  • Khi retry tạo cùng handoff hai lần, state và cách xử lý nên là gì?
  • Khi nhiều agent đồng ý nhưng thiếu source độc lập, reviewer cần hỏi gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Contract cần input, output, owner, tool boundary và stop condition; có thể thêm version, budget và timeout. Xem lại mục 2.

Xem gợi ý câu 2

Version giúp biết builder đang dùng evidence nào và chặn artifact cũ; lịch sử chat dài không bảo đảm đúng bản. Xem lại mục 3.

Xem gợi ý câu 3

Kiểm `handoff_id`, giữ một output, không tạo side effect trùng; retry bounded rồi block nếu vẫn không rõ. Xem lại mục 3 và mục 4.

Xem gợi ý câu 4

Hỏi claim dựa trên source độc lập nào, assumption nào còn mở và reviewer nào chịu trách nhiệm. Xem lại mục 5.

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

Thuật ngữ Giải thích ngắn
Multi-agent workflow Nhiều agent có vai trò nối nhau trong một quy trình.
Orchestration Điều phối thứ tự, quyền và điều kiện chuyển việc.
Handoff contract Quy định input, output, owner và stop condition khi bàn giao.
Control plane Lớp giữ state, policy, trace và routing.
Artifact Tài liệu hoặc bằng chứng versioned đi giữa các agent.
Evaluator Bộ kiểm output theo tiêu chí trước khi chuyển bước.
Idempotency Chạy lại cùng handoff không tạo side effect trùng.
Quarantine Cách ly output nghi ngờ để kiểm, chưa đưa vào flow.
Escalation Chuyển case tới người có quyền hoặc chuyên môn hơn.

e. Nguồn tham khảo

Bài trước là Case Study: Coding Agent #16. Bài tiếp theo là Case Study: AI System Failure Analysis #18.

Lưu ý giáo dục: Giữ workflow nhiều agent ở fixture giả và read-only cho tới khi role, artifact version, evaluator, owner, approval và rollback rõ. Không cấp production action chỉ để demo việc handoff.