TROISINH
Harness EngineeringMulti-Agent Architecture

Agent Communication: Mailbox, shared state, event bus

Hiểu cách AI agent 'nói chuyện' với nhau qua Mailbox, Shared State, Event Bus. Phân tích kiến trúc multi-agent từ Claude Code và Anthropic với trade-off chi...

Định nghĩa

Agent Communication là cơ chế trao đổi thông tin giữa các AI agent trong hệ thống multi-agent, bao gồm ba pattern chính: Mailbox (hộp thư bất đồng bộ), Shared State (bộ nhớ chung đồng bộ), và Event Bus (bus sự kiện phân phối).

Giải thích chi tiết

Mailbox: Giao tiếp bất đồng bộ và giải coupling

Mailbox hoạt động như hệ thống email nội bộ giữa các agent. Agent A gửi message vào hộp thư của Agent B, không cần chờ B xử lý xong ngay lập tức. Pattern này phù hợp với tác vụ dài hạn hoặc khi agent cần độc lập hoàn toàn về thời gian thực thi.

Ưu điểm chính là decoupling: Agent A không block cho đến khi B hoàn thành. Điều này cực kỳ quan trọng trong kiến trúc như Claude Code Subagent Fork pattern, nơi parent agent spawn child agent để chạy test suite, có thể mất 5-10 phút. Parent có thể làm việc khác hoặc xử lý kết quả từ agent khác trong thời gian chờ.

Shared State: Bộ nhớ chung và đồng bộ hóa

Shared State là vùng nhớ (thường là file system, database, hoặc context window) mà nhiều agent cùng đọc/ghi. Khác với Mailbox (message passing), đây là shared memory architecture.

Trong Anthropic 3-agent pattern (Planner → Generator → Evaluator), Shared State thường là checkpoint file chứa plan, code generated, và evaluation results. Planner viết plan vào state, Generator đọc plan từ state và viết code, Evaluator đọc code và ghi kết quả đánh giá.

Rủi ro chính là race conditionconflict resolution. Khi hai agent cùng ghi vào một file, cần mechanism lock hoặc atomic write. Lợi ích là observability cao — developer có thể mở file để xem agent đang nghĩ gì thay vì đọc log message.

Event Bus: Kiến trúc publish-subscribe

Event Bus là pattern mà agent không giao tiếp trực tiếp mà thông qua một "bus" trung gian. Agent publish sự kiện (ví dụ: code_generation_completed), các agent khác subscribe và phản ứng.

Pattern này scale tốt khi số lượng agent lớn (trên 5-10 agents), vì thêm agent mới không cần sửa code agent cũ — chỉ cần subscribe thêm event. Tuy nhiên, debug trở thành ác mộng: flow execution nằm rải rác trong nhiều event handler, không còn linear nữa. Bạn không thể "step through" bằng cách đọc code từ trên xuống.

Trade-off chi phí và độ phức tạp

Đây là điểm mà nhiều team bị sốc: communication overhead có thể biến task 9(singleagent)thaˋnh9 (single agent) thành 200 (multi-agent with complex orchestration). Mỗi lần agent gọi LLM API là tiền. Khi Planner gọi LLM để viết plan, Generator gọi để viết code, Evaluator gọi để review — đã là 3 calls. Thêm communication protocol (serialization, state sync, error retry) — là infrastructure cost ẩn.

Chưa kể latency: Mailbox và Event Bus thêm độ trễ do polling hoặc queue processing. Shared State thêm latency do disk I/O hoặc database roundtrip. Single agent với context window lớn có thể chậm hơn về inference nhưng nhanh hơn về end-to-end time do không có coordination overhead.

Ví dụ thực tế

Claude Code: 3 mô hình Subagent Communication

Claude Code (của Anthropic) implement 3 communication pattern chính tương ứng với 3 nhu cầu khác nhau:

Fork Pattern (Mailbox model): Khi cần chạy lệnh nguy hiểm hoặc dài (ví dụ: npm test chạy 1000 test cases), Claude spawn subagent mới với Worktree riêng. Parent gửi "job" vào mailbox của child (thường là stdin hoặc message queue), child chạy và trả kết quả (pass/fail + logs) qua stdout/file. Trong thời gian chờ, parent có thể làm việc khác hoặc idle — decoupling hoàn toàn về thời gian.

Teammate Pattern (Shared State): Hai agent cùng làm việc trên cùng một Worktree (git branch). Họ chia sẻ file system làm shared state. Agent A sửa file X, Agent B đọc file X để tiếp tục. Điều này đòi hỏi coordination — thường thông qua "session state" hoặc explicit handoff protocol để tránh cùng sửa một dòng code.

Worktree Pattern (Hybrid): Mỗi agent có sandbox riêng (isolated state như branch git riêng), nhưng kết quả cuối cùng được merge vào shared branch. Đây là cách triệt tiêu race condition mà vẫn giữ được parallelism. Communication ở đây là "final result passing" — giống Mailbox nhưng với payload lớn (cả codebase thay vì message text).

Anthropic v2: Planner-Generator-Evaluator với Shared State

Trong kiến trúc mới nhất của Anthropic cho software engineering:

  • Planner viết plan.md vào shared directory (state)
  • Generator đọc plan.md, viết code vào src/, ghi status: done vào state.json
  • Evaluator kiểm tra state.json, chạy test, ghi evaluation.json

Communication ở đây là pull-based: mỗi agent poll shared state để biết khi nào đến lượt mình. Đơn giản, debug dễ (bạn có thể mở plan.md để xem Planner nghĩ gì), nhưng latency cao hơn event-driven. Trade-off được chấp nhận vì observability quan trọng hơn speed trong coding task.

Chi phí thực tế: 9vs9 vs 200

Một case study triển khai feature tương tự trên codebase 50k dòng:

  • Single agent: Một GPT-4 call duy nhất, context window lớn chứa toàn bộ codebase. Giá: khoảng $9. Risks: hallucination, không chạy được test, "tuyên bố xong sớm" (premature completion).
  • Multi-agent với Mailbox/State: Planner (Claude 3.5 Sonnet) + Generator (Claude 3.5 Sonnet) + Evaluator (GPT-4 mini). Mỗi agent 3-4 turns, thêm cost storage, serialization, retry logic. Giá: khoảng $200. Benefit: pass rate cao hơn 40%, code maintainable, dễ debug khi fail (biết chính xác agent nào fail ở step nào).

Con số 200sovi200 so với 9 là lý do bạn không nên dùng multi-agent cho mọi thứ — chỉ khi quality và reliability quan trọng hơn cost.

Ứng dụng

AI Engineer xây dựng Harness

Khi thiết kế ACI (Agent-Computer Interface), bạn cần chọn communication pattern dựa trên task duration:

  • Task dưới 30 giây: Direct call (synchronous) — đơn giản nhất, không cần Mailbox phức tạp.
  • Task 30 giây đến 5 phút: Mailbox với timeout và retry logic, cho phép parent agent làm việc khác.
  • Task song song: Shared State với atomic operations hoặc Worktree isolation để tránh conflict.

Tech Lead thiết kế hệ thống

Quyết định "Shared State vs Message Passing" ảnh hưởng đến team structure và debug workflow:

  • Shared State (file-based) dễ debug cho developer vì họ có thể cat plan.md để xem agent nghĩ gì — phù hợp với team ít người, cần inspectability cao.
  • Event Bus phù hợp với microservices mindset, nhưng đòi hỏi centralized logging (OpenTelemetry) để trace execution flow — phù hợp enterprise, nhưng overhead cao.

Developer sử dụng Claude Code/AI IDE

Hiểu pattern giúp bạn chọn đúng tool mode:

  • Dùng Fork khi cần chạy test song song (parallel agents) hoặc thao tác nguy hiểm cần rollback dễ dàng.
  • Dùng Teammate mode khi pair programming với AI, nhưng cẩn thận với race condition khi cả hai cùng sửa một file — nên dùng explicit "bạn sửa file A, tôi sửa file B" protocol.

So sánh

PatternCouplingLatencyDebug dễScalabilityChi phí hạ tầng
Direct CallChặtThấpDễKém (1-to-1)Thấp
MailboxLỏngCao (async)Trung bìnhTốtTrung bình (queue)
Shared StateChặt (data)Thấp-Trung bìnhDễTrung bìnhCao (storage, lock)
Event BusRất lỏngCaoKhó (distributed)Rất tốtCao (infra, logging)

Kết luận: Không có pattern nào tối ưu cho mọi trường hợp. Hệ thống production thường hybrid: Planner-Generator dùng Shared State (cần đọc/ghi nhanh, cần inspect), trong khi Evaluator và Reporting Agent dùng Mailbox (không cần real-time). Event Bus chỉ nên dùng khi bạn có hơn 5 agents hoặc cần hot-swap agent mà không restart hệ thống — đồng thời invest mạnh vào observability từ ngày đầu.

Bài viết liên quan

Cùng cụm

Đọc tiếp

State & Session Management

Nền tảng để hiểu cách agent lưu trữ và đồng bộ shared state giữa các session

Security & Guardrails

Communication tạo attack surface mới: prompt injection qua shared state, eavesdropping trên event bus

Harness Fundamentals

Quay lại nền tảng: ACI là gì, tại sao communication chỉ là một phần của harness engineering

On this page