Multi-Agent Collaboration hoạt động thế nào? #14

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Multi-Agent Collaboration là cách nhiều AI agent cùng đạt một mục tiêu qua task contract, ownership, shared state và cổng tích hợp rõ ràng. Nó hữu ích khi công việc có các nhánh chuyên môn hoặc độc lập; nếu thiếu ranh giới, nhiều agent chỉ tạo thêm việc trùng, xung đột ghi và lỗi truyền dây chuyền.

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

• Khi nào nên chia cho nhiều agent và khi nào một agent đủ tốt.
• Cách khóa owner, artifact, state và handoff cho từng nhánh.
• Cách phát hiện duplicate work, conflict và lỗi tích hợp trước khi publish.

1. Multi-Agent Collaboration là gì, và khi nào đáng dùng?

Nhiều agent không có nghĩa là mở một group chat rồi để năm bot tự bàn. Một role là trách nhiệm chuyên môn, như dựng timeline hay kiểm nguồn; role không tự cấp quyền đọc, ghi hoặc publish. Owner là agent chịu trách nhiệm cuối cho một task hoặc artifact cụ thể.

Hình dung bếp nhà hàng. Bếp nóng, bếp bánh và người đứng pass có phần việc khác nhau. Họ không cùng khuấy một nồi. Mỗi món có ticket, người làm, nguyên liệu, trạng thái và một cổng kiểm trước khi ra bàn. Multi-agent tốt cũng cần kỷ luật như vậy.

Nó đáng dùng khi task có ít nhất một trong ba đặc điểm:

• Có các nhánh độc lập chạy song song, như tìm nguồn ở ba thị trường.
• Cần chuyên môn hoặc tool permissions khác nhau.
• Cần reviewer độc lập để kiểm artifact trước tích hợp.

Một agent thường tốt hơn nếu task nhỏ, tuần tự, context chia sẻ dày hoặc chi phí phối hợp cao hơn work chính. Viết lại một đoạn ngắn không cần ba agent giao ca. Thêm agent chỉ vì “nghe mạnh hơn” là thiết kế theo số lượng, không theo dependency.

AutoGen trình bày một framework nơi nhiều agent tùy chỉnh có thể hội thoại và phối hợp LLM, human input và tools qua các interaction behaviors. CAMEL nghiên cứu role-playing cho cooperation và instruction following. Hai công trình cho thấy nhiều pattern khả thi; chúng không chứng minh mọi task sẽ tốt hơn khi thêm agent.

Điều chắc chắn là hai writer cùng sửa một file cần lock hoặc merge policy. Điều chỉ nói có điều kiện là parallel workers có thể giảm elapsed time nếu nhánh thật sự độc lập và integration cost không nuốt phần tiết kiệm.

2. Năm khối nền: role, ownership, task contract, shared state và integration gate

Task contract là hợp đồng giao việc gồm objective, scope, inputs, output schema và done criteria. Nó biến câu “nghiên cứu phần impact nhé” thành một nhiệm vụ có thể kiểm.

Hình 1 — Chia việc chỉ có ý nghĩa khi mỗi artifact có owner, contract và cổng tích hợp rõ.

Năm khối phải đi cùng nhau:

1. Role: agent phụ trách loại công việc nào.
2. Unique owner: ai được ghi artifact và chịu trách nhiệm giao nó.
3. Task contract: input, scope, output và điều kiện hoàn tất.
4. Shared state: trạng thái chung tối thiểu, có version và source of truth.
5. Integration gate: phép kiểm trước khi ghép hoặc phát hành.

Shared state không nên là toàn bộ chat history. Nó là một board ngắn:

State cần timestamp hoặc version vì một message “xong rồi” có thể stale sau khi artifact đổi. Source of truth phải rõ: board quyết định status; artifact version quyết định nội dung; source IDs quyết định evidence. Không dùng kết luận trong chat làm nguồn mới.

Integration gate giống người đứng pass kiểm món đủ, đúng bàn và không vi phạm dị ứng. Với bài postmortem giả, gate phải kiểm đủ timeline, impact, actions, citations, conflicts và review state. External publish vẫn là hành động riêng cần human approval.

3. Ba topology phối hợp và case postmortem giả

Topology là cách agents kết nối và chuyển việc. Không có topology thắng mọi task.

Hình 2 — Chọn topology theo dependency và ownership, không theo số agent muốn dùng.

Sequential pipeline

Agent A giao B, B giao C. Pattern này hợp khi output trước là input bắt buộc của bước sau, như draft → review → format. Nó dễ audit nhưng có thể chậm và lỗi đầu dễ truyền xuống.

Orchestrator–worker

Một agent điều phối chia task cho workers, theo dõi state và tích hợp. Pattern hợp khi có các nhánh độc lập. Bài Anthropic Engineering về multi-agent research mô tả lead agent giao nhánh nghiên cứu cho subagents và cũng nêu failure modes như vague delegation, duplicate work và spawning quá nhiều. Đây là kinh nghiệm của một hệ thống cụ thể, không phải lời hứa performance chung.

Peer collaboration

Agents ngang hàng trao artifacts theo protocol. Pattern linh hoạt nhưng dễ vòng message, tranh owner hoặc không ai chịu trách nhiệm final. Nó chỉ hợp khi shared-state và conflict policy thật rõ.

Case của ta tạo draft postmortem cho incident giả:

• L1: alert lúc 09:02.
• T1: ticket ghi start lúc 09:05.
• L2: rollback lúc 09:07.
• Agent A sở hữu timeline.md.
• Agent B sở hữu impact.md.
• Agent C sở hữu actions.md.
• Reviewer chỉ đọc, sở hữu review.md.
• Integrator sở hữu postmortem.md.

A/B/C có thể làm song song vì ghi artifact khác nhau. Reviewer chỉ bắt đầu phần tương ứng khi artifact có version và source IDs. Integrator chờ gate: mọi nhánh phải done hoặc done_with_conflict, không nhánh nào blocked mà không có exception.

MetaGPT nghiên cứu việc mã hóa standard operating procedures và role specialization trong collaborative software tasks. Ta mượn ý tưởng SOP và artifact ownership, không suy ra role label tự tạo isolation hay production safety.

4. Handoff protocol: giao việc mà không làm rơi ngữ cảnh

Handoff là gói chuyển giao có output, evidence, blockers và next owner. “Timeline xong rồi nhé” chưa phải handoff vì Integrator không biết bản nào, dựa trên nguồn nào và còn conflict gì.

Hình 3 — Handoff tốt chuyển cả evidence, điều chưa rõ và trạng thái; không chỉ gửi một câu kết luận.

Một envelope nên có tám trường:

task_id
objective
scope
artifact + version
source IDs
conflicts / unknowns
done criteria result
next owner

Mẫu A → Integrator:

task_id: TL-1
objective: dựng timeline incident giả
scope: chỉ L1, T1, L2
artifact: timeline.md@v1
sources: L1 09:02; T1 09:05; L2 09:07
conflict: start_time 09:02 vs 09:05
unknown: customer-visible start
done: mọi timestamp có citation
next_owner: Integrator

Integrator không được tự hòa 09:02 và 09:05 thành 09:03. Artifact phải ghi alert time và ticket-reported time là hai khái niệm khác nhau, hoặc giữ conflict để human quyết định.

Handoff cũng phải fail closed. Nếu B ghi impact 2.000 users nhưng thiếu M2 scope, Reviewer chuyển state blocked_missing_scope và next owner về B. Không đưa con số đó vào final chỉ vì hai agent khác “đồng ý”. Majority vote không sửa được cùng một nguồn sai.

5. Sai lầm, giới hạn và rủi ro phối hợp

Sai lầm đầu tiên là chia theo role mơ hồ: “A nghiên cứu, B cũng nghiên cứu”. Hai agent lặp cùng nguồn trong khi một mảng bị bỏ trống. Task contract phải chia theo objective hoặc coverage có thể đối chiếu.

Sai lầm thứ hai là shared write. A và Integrator cùng sửa postmortem.md có thể ghi đè hoặc trộn version. Quy tắc đơn giản: một artifact có một writer; người khác gửi patch, comment hoặc handoff.

Sai lầm thứ ba là cascade error. A đưa timestamp sai, Integrator viết narrative sai, Reviewer chỉ sửa câu chữ. Gate phải kiểm evidence, không chỉ format. Sai lầm thứ tư là communication loop: agents gửi status cho nhau mà không tạo artifact mới hoặc quyết định mới.

Write conflict là hai agent cạnh tranh ghi cùng artifact. Coordination overhead là chi phí message, chờ, merge và verify ngoài work chính. Với task nhỏ, overhead có thể lớn hơn lợi ích parallel. Với task phụ thuộc context chung dày, chia nhỏ còn làm mỗi agent thiếu bức tranh.

Giới hạn khác là isolation không tự xuất hiện từ role name. Agent “Reviewer” vẫn có thể ghi file nếu tool permission cho phép. Muốn read-only phải khóa bằng hệ thống. Shared state cũng có thể lộ PII hoặc secret nếu handoff không lọc scope.

6. Checklist và bài tập 15 phút

Checklist triển khai:

1. Viết một goal chung và success criteria.
2. Chia task theo dependency hoặc coverage, không theo số agent.
3. Gắn unique owner và artifact cho từng task.
4. Viết contract có inputs, scope, schema và done criteria.
5. Khóa tool/data permissions theo từng role.
6. Tạo shared board có version, sources, blocker và next owner.
7. Dùng handoff envelope, không dùng câu kết luận trống.
8. Tách Reviewer read-only khỏi Integrator writer.
9. Chạy integration verifier trước external side effect.
10. Đo duplicate work, handoff failures, conflicts và final task success.

Hãy đứng ngoài khi không tách được ownership, mọi nhánh phải dùng cùng context liên tục hoặc chưa có integration verifier. Dừng khi hai agents cùng ghi, source IDs biến mất, state loop không tiến hoặc publish gate bị vượt.

Bài tập 15 phút

Dùng spreadsheet và text editor miễn phí. Chỉ dùng incident giả; không kết nối production, không gửi thông báo thật.

• 3 phút: chia A/B/C/Reviewer/Integrator và unique artifacts.
• 3 phút: ghi contract cho A timeline.
• 3 phút: tạo shared board.
• 3 phút: viết handoff A → Integrator với L1/T1/L2.
• 3 phút: chạy integration check và giữ publish blocked.

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

Kết quả đúng là postmortem.md vẫn waiting vì RV-1 blocked. Kết quả sai là Integrator bỏ qua M2 scope rồi publish. Chưa dùng dữ liệu hay tiền thật.

7. Tổng kết và bài học tiếp theo

a. Năm ý chính

• Nhiều agent chỉ hữu ích khi task có ranh giới và lợi ích rõ.
• Role mô tả trách nhiệm; owner và permission mới khóa quyền.
• Shared state cần tối thiểu, có version và source of truth.
• Handoff phải mang artifact, evidence, conflict, blocker và next owner.
• Integration gate kiểm task result trước publish, không chỉ kiểm message “done”.

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

• Role và owner khác nhau ở đâu?
• Vì sao A/B/C có thể parallel nhưng Integrator phải chờ?
• Handoff “timeline xong” thiếu những gì?
• Khi nào nên quay về single-agent?

c. Gợi ý đáp án

Xem gợi ý câu 1

Role là trách nhiệm; owner chịu trách nhiệm cuối cho task/artifact. Xem mục 1–2.

Xem gợi ý câu 2

A/B/C ghi artifact riêng; Integrator cần đủ state và review để ghép. Xem mục 3.

Xem gợi ý câu 3

Thiếu version, sources, conflict, done result và next owner. Xem mục 4.

Xem gợi ý câu 4

Khi task nhỏ, context chung dày hoặc coordination overhead vượt lợi ích. Xem mục 1 và 5.

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

e. Nguồn tham khảo

• AutoGen — arXiv
• CAMEL — arXiv
• MetaGPT — arXiv
• Anthropic Engineering — Multi-agent research system

Bài trước, Agent Planning #13, dựng action graph cho một agent. Bài này chia graph thành ownership và handoff. Bài sau, Supervisor Agent #15, sẽ đi sâu vào vai trò điều phối, giám sát và quyết định khi workers lệch plan.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.