A2A và Multi-Agent: Khi Nào Nên Dùng Nhiều Agent?

Hai agent gọi nhau nghe hấp dẫn hơn một agent. Nhưng mỗi agent thêm vào là một lời gọi model, một bộ tool, một chỗ có thể sai và thêm một tầng latency. Bài này nói về A2A v1.0.0 — giao thức để các agent trao đổi task với nhau — và về câu hỏi thực tế hơn: khi nào không nên dùng nhiều agent.

Cập nhật 2026

• A2A v1.0.0 đã được hiến cho Linux Foundation và gia nhập Agentic AI Foundation ngày 2026-08-27. Đây là bản 1.0 đầu tiên, không còn là bản nháp thử nghiệm.
• MCP 2026-07-28 là bản stateless: không initialize, không session. MCP lo agent ↔ tool; A2A lo agent ↔ agent. Hai giao thức bổ sung, không cạnh tranh.
• Hỗ trợ A2A trong framework không đồng đều: Microsoft Agent Framework có A2AAgent, Google ADK expose/consume được; nhiều framework khác chưa có first-class support (xem bảng bên dưới, các ô ? nghĩa là chưa có tài liệu).
• Chạy nhiều agent vẫn là quyết định về chi phí và độ tin cậy, không phải về “trí tuệ tập thể”.

MCP và A2A: hai bài toán khác nhau

MCP chuẩn hoá cách một ứng dụng AI khám phá và gọi năng lực bên ngoài: tool, resource, prompt. Nó trả lời câu “làm sao để agent dùng được database, search, ticketing mà không phải viết tích hợp riêng cho từng framework”.

A2A trả lời câu khác: “làm sao để agent của tôi giao việc cho agent của bạn mà không chia sẻ memory, tool hay code”. Hai bên trao đổi task, không chia sẻ nội bộ. Vì vậy A2A không thay thế MCP, và cũng không nên nhét A2A vào một MCP server chỉ để “cho hiện đại”.

A2A v1.0.0: mô hình dữ liệu

Bốn khái niệm cần nắm:

• AgentCard — mô tả công khai của agent: nó làm được gì, endpoint ở đâu, hỗ trợ binding nào, yêu cầu auth gì. Đây là thứ để agent khác quyết định có thuê nó hay không.
• Task — đơn vị công việc có vòng đời. Trạng thái: submitted, working, completed, failed, canceled, input-required, rejected, auth-required.
• Message và Part — nội dung trao đổi, chia thành các phần (text, file, structured data tuỳ implementation).
• Artifact — kết quả đầu ra của task, tách khỏi message để client lấy về và lưu trữ.

Ba binding: JSON-RPC, gRPC, HTTP+JSON. Có streaming và webhook push với ngữ nghĩa at-least-once — nghĩa là webhook có thể đến trùng, và code nhận phải idempotent.

Dưới đây là AgentCard rút gọn. Các field như skills, defaultInputModes nằm trong spec nhưng tên chính xác của một số field phụ thuộc bản spec bạn pin; hãy đối chiếu với a2a-protocol.org/latest/specification/ trước khi hard-code.

// AgentCard — dạng rút gọn, field phụ đánh dấu (?) cần đối chiếu spec v1.0.0
{
  "name": "invoice-auditor",
  "description": "Đối soát hoá đơn với hợp đồng và bảng giá",
  "url": "https://agents.example.com/invoice-auditor",
  "version": "1.4.0",
  "capabilities": {"streaming": true, "pushNotifications": true},
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text", "application/json"],
  "skills": [
    {"id": "audit-invoice", "name": "Đối soát hoá đơn",
     "tags": ["finance", "reconciliation"]}
  ]
}

Một task A2A chạy như thế nào

Luồng điển hình gồm năm bước:

1. Client lấy AgentCard từ endpoint đã biết (well-known path hoặc registry nội bộ — registry A2A không thuộc phạm vi bài này).
2. Client gửi message kèm yêu cầu tạo task.
3. Server trả task ở trạng thái submitted, rồi working.
4. Client theo dõi bằng streaming, polling hoặc webhook push.
5. Task kết thúc ở completed kèm artifact, hoặc một trạng thái dừng khác.

// Task — dạng rút gọn; tên field id/contextId/status.message (?) đối chiếu spec
{
  "id": "task_01HQ...",
  "contextId": "ctx_invoice_2026_11",
  "status": {"state": "working", "timestamp": "2026-11-08T09:14:03Z"},
  "artifacts": [],
  "history": []
}

Hai trạng thái hay bị bỏ qua khi thiết kế: input-required và auth-required. Cả hai đều là task chưa xong, không phải lỗi. Nếu client coi chúng là thất bại rồi retry, bạn sẽ tạo task trùng và đôi khi trả tiền hai lần cho cùng một việc.

Bốn mô hình multi-agent

Kiến trúc multi-agent không có nghĩa là “nhiều agent ngang hàng”. Có bốn mô hình thực dụng:

Supervisor là mô hình dễ vận hành nhất vì có một chỗ để log, đặt budget và dừng. Handoff rẻ nhất về token nếu bạn thật sự kết thúc nhánh cũ, nhưng nếu bạn giữ nguyên toàn bộ transcript qua mỗi lần handoff thì context phình ra nhanh. Swarm không có điểm kiểm soát trung tâm, nên chỉ dùng khi bạn đã có tracing tốt. Debate nhân chi phí lên bằng số agent tham gia — ba agent tranh luận nghĩa là ba lần sinh output cho mỗi vòng.

Chia sẻ context: chỗ mọi thứ hỏng

Lỗi phổ biến là để các agent chia sẻ nguyên một transcript. Cách đó có ba hệ quả: token tăng theo bình phương số vòng, thông tin nhiễu từ agent này làm lệch agent kia, và prompt injection từ một tool output lan sang mọi agent còn lại.

Quy tắc thực dụng: context isolation theo mặc định, chia sẻ có chủ đích. Mỗi agent con nhận một brief ngắn gồm mục tiêu, ràng buộc, schema đầu ra và dữ liệu tối thiểu. Kết quả trả về cho supervisor là artifact có cấu trúc, không phải lời kể lại toàn bộ quá trình. Nếu cần lịch sử, truyền bản tóm tắt đã kiểm soát — cùng ý tưởng với nén và quên bộ nhớ của agent.

Lợi ích phụ: artifact có schema là thứ test được. Một đoạn văn tự do thì không.

Chi phí và lỗi nhân lên, không cộng thêm

Giả sử một task một agent có xác suất thành công 0,95 và 4 bước. Thêm ba agent, mỗi agent hai bước, tổng thành 10 lời gọi model có phụ thuộc: nếu mỗi lời gọi vẫn 0,95 thì xác suất toàn bộ thành công còn khoảng 0,95^10 ≈ 0,60. Bạn vừa trả gấp đôi token vừa giảm một nửa độ tin cậy. Con số thật phụ thuộc vào việc lỗi có được retry hay không, nhưng hướng của phép tính thì luôn đúng.

Chi phí cũng không tuyến tính theo số agent. Mỗi agent có system prompt riêng, tool schema riêng, và reasoning token bị tính như output. Trên các model flagship, output đắt gấp 5 lần input; reasoning token cũng vào hoá đơn như output. Bốn agent suy luận là bốn luồng output, không phải một luồng dài.

Latency thì cộng theo chuỗi phụ thuộc. Supervisor gọi ba agent song song vẫn phải chờ agent chậm nhất, rồi thêm một vòng tổng hợp. p95 luôn tệ hơn p50 nhiều hơn bạn tưởng, và người dùng cảm nhận p95.

Khi một agent hoặc workflow tốt hơn

Nguyên tắc: nếu một hàm làm được việc, bỏ agent đi. Nếu quy trình cố định, dùng workflow. Multi-agent đáng giá khi các nhánh cần quyền khác nhau, tool khác nhau, hoặc ngân sách khác nhau — tức là khi ranh giới quyền trùng với ranh giới agent.

Bảo mật: danh tính, tin cậy, phê duyệt

Trong multi-agent, mỗi hop là một ranh giới tin cậy mới. Bốn điểm phải xử lý:

• Danh tính agent — agent gọi agent phải có identity riêng, không dùng chung service account. Token scope theo task và theo tenant; A2A có trạng thái auth-required chính vì việc uỷ quyền là bình thường, không phải ngoại lệ.
• AgentCard không phải chứng nhận — card là mô tả tự khai. Một agent từ bên ngoài có thể khai năng lực hay hơn thực tế, hoặc mô tả tool chứa chỉ dẫn độc hại. Coi mọi nội dung từ agent lạ là đầu vào không tin cậy, đúng như với tool output.
• Phê duyệt cho hành động không thể đảo — chuyển tiền, ghi production, xuất dữ liệu, đổi quyền. Ghi lại ai duyệt, tham số gì, quyết định gì. Phê duyệt không phải idempotency: người duyệt hai lần vẫn tạo hai side effect nếu tool không có key.
• Egress và secret — allowlist đích đến, chặn cloud metadata, không nhét credential vào message A2A. Secret nằm ngoài context và được inject ngắn hạn ở biên.

Đây là các biện pháp trong OWASP LLM Top 10: LLM01 prompt injection (qua card, message, artifact), LLM06 excessive agency (agent có quá nhiều quyền), LLM10 unbounded consumption (vòng lặp agent gọi agent). Không có biện pháp nào thay được việc cắt quyền trước khi thêm guardrail model.

Hỗ trợ A2A trong framework

Các ô ? không có nghĩa là không thể; nghĩa là bạn phải tự viết adapter hoặc dùng HTTP client. Đừng giả định một framework có A2A chỉ vì nó có multi-agent.

Cạm bẫy

• Dùng A2A cho tool call nội bộ — thêm một giao thức mạng vào chỗ chỉ cần gọi hàm. Dùng MCP hoặc function calling.
• Giữ nguyên transcript qua mọi hop — token tăng, nhiễu tăng, injection lan rộng.
• Không xử lý input-required — retry sinh task trùng. Phải idempotent theo task id.
• Webhook không idempotent — A2A push là at-least-once; nhận trùng là chuyện sẽ xảy ra.
• Đo chất lượng bằng cảm giác — multi-agent thường trông “thông minh hơn” trong demo nhưng thua single agent trên task success rate. Đo bằng bộ eval, không bằng ấn tượng.
• Không đặt budget theo task — vòng lặp agent gọi agent là dạng unbounded consumption điển hình.

Checklist trước khi thêm agent thứ hai

1. Viết lý do tách: quyền khác, tool khác, hay ngân sách khác. Nếu không nêu được, giữ một agent.
2. Vẽ chuỗi phụ thuộc và tính lại p95 cùng chi phí token cho toàn task, không phải cho từng agent.
3. Chốt schema artifact giữa các agent; chỉ truyền brief và artifact, không truyền transcript.
4. Đặt idempotency key cho mọi task và mọi side effect; xử lý webhook trùng.
5. Scope token theo task/tenant; coi AgentCard và message là đầu vào không tin cậy.
6. Đặt max steps, max token và một kill switch tước quyền tool, không chỉ dừng process.

Hướng tới 2027

A2A đã vào Linux Foundation và Agentic AI Foundation, nên phần giao thức sẽ ổn định; phần còn thiếu là danh tính agent và registry tin cậy. Khi framework hợp nhất cùng một cách expose/consume A2A, chi phí tích hợp sẽ giảm, nhưng chi phí vận hành multi-agent thì không — nó phụ thuộc vào việc bạn có trace và budget hay không.

Đọc tiếp: MCP 2026-07-28 và quan hệ với A2A, các framework agent, quản lý bộ nhớ và tóm tắt context, và prompt injection và sandboxing.