Bất kỳ team nào đã từng giao một feature thật cho coding agent đều từng gặp cùng một bức tường: agent làm rất tốt trong hai mươi phút đầu, rồi bắt đầu quên mất quyết định đã đưa ra mười phút trước, đọc lại file đã đọc rồi, và âm thầm ghi đè lên một fix nó vừa tạo trước đó trong cùng session. Đây không phải vấn đề chất lượng model — đây là vấn đề kiến trúc. Một agent đơn lẻ xử lý một task nhiều phần sẽ tích lũy context cho tới khi chính context trở thành nút thắt cổ chai: quá nhiều để suy luận, quá nhiều nhiễu không liên quan chen vào thứ thực sự quan trọng ngay lúc đó.

Câu trả lời của Claude Code, được mô tả khá rõ trong một bài viết gần đây của Devika Nekkalapu, là ngừng coi đây là một agent chạy dài liên tục, và bắt đầu coi nó như một team nhỏ: một Lead Agent nắm giữ kế hoạch tổng thể, một nhóm Specialist Agent mỗi con chỉ phụ trách một phần thực thi hẹp, một Shared Task System theo dõi ai đang làm gì, và cơ chế Context Isolation giữ cho cửa sổ context của từng specialist luôn sạch. Đây là một sự phản chiếu có chủ đích của cách các team kỹ thuật đã vận hành từ trước tới giờ — và chính vì vậy nó đáng để tech lead để tâm: những failure mode nó khắc phục cũng chính là những failure mode bạn đã quản lý ở con người.

Bốn thành phần

Lead Agent. Giữ mục tiêu tổng thể, chia nhỏ thành các đơn vị công việc rời rạc, và quyết định specialist nào xử lý phần nào. Nó không tự làm việc implement — công việc của nó là phân rã và điều phối, giống hệt công việc một tech lead làm khi scope một sprint.

Specialist Agent. Mỗi con được khởi tạo cho một phần việc có ranh giới rõ — “implement API endpoint,” “viết migration,” “nối form ở frontend” — chỉ với đúng context cần cho phần việc đó. Nó không kế thừa toàn bộ lịch sử của Lead Agent, và cũng không thấy các specialist khác đang làm gì theo thời gian thực.

Shared Task System. Lớp điều phối. Các specialist báo cáo trạng thái và kết quả qua hệ thống này thay vì qua một bản transcript hội thoại chung ngày càng phình to. Đây là phiên bản có cấu trúc của một bảng ticket: trạng thái nằm trong hệ thống, không nằm trong đầu ai cả.

Context Isolation. Phần thực sự giải quyết vấn đề gốc. Vì cửa sổ context của mỗi specialist chỉ chứa những gì liên quan tới đúng task của nó, không con nào bị nhấn chìm trong nhiễu tích lũy từ mọi thứ đã xảy ra trước đó. Lead Agent cũng nhẹ hơn, vì nó theo dõi trạng thái task và kết quả, không phải chi tiết implementation đầy đủ.

Điểm mà mô hình này thực sự tạo ra giá trị

Bài viết gốc đưa ra hai ví dụ đáng để dừng lại suy nghĩ, vì chúng ánh xạ rất rõ vào tình huống team thực tế:

Triển khai feature song song. Một feature chạm cả backend, database, và frontend được chia thành ba nhánh specialist chạy song song thay vì tuần tự — đúng như cách bạn sẽ phân công nếu có ba kỹ sư thay vì một. Lead Agent không cần giữ chi tiết implementation backend trong đầu để điều phối phần database và frontend; nó chỉ cần biết mỗi nhánh đã tạo ra gì và đã xong chưa.

Debug song song. Thay vì một agent test từng giả thuyết một theo một chuỗi suy luận duy nhất, nhiều specialist điều tra các giả thuyết khác nhau cùng lúc — có phải race condition, cache cũ, hay migration lỗi — rồi báo cáo lại. Đây chính xác là cách một quy trình incident response tốt vận hành: bạn không giao một người kiểm tra tuần tự mọi giả thuyết, bạn chia giả thuyết cho từng người rồi họp lại.

Bài học cốt lõi không phải “càng nhiều agent càng tốt.” Mà là độ tin cậy đến từ nhiều vòng lặp suy luận nhỏ, phạm vi rõ ràng, được điều phối bởi một chủ sở hữu rõ ràng, chứ không phải từ một vòng lặp khổng lồ cố ôm hết mọi thứ. Đây là nguyên tắc quen thuộc — cũng là lý do bạn không muốn một người ôm trọn một feature cross-cutting một mình.

Hướng dẫn triển khai: Áp dụng vào công việc công ty và dự án cá nhân

Đây là chỗ kiến trúc này ngừng là kiến thức thú vị để đọc, và trở thành thứ bạn có thể thực sự triển khai. Hai hướng: quy trình kỹ thuật của team, và công việc cá nhân của bạn.

Ở công ty

1. Audit lại chỗ agent hiện tại của bạn đang đâm vào bức tường context. Nhìn vào các session Claude Code / Copilot / Cursor của team trên bất kỳ task nào chạy quá vài lượt. Nếu thấy agent đọc lại file đã đọc, mâu thuẫn với quyết định trước đó, hoặc quên mất cái gì đã xong — đó là triệu chứng context-overload của single-agent, và là tín hiệu để bạn phân rã task.
2. Phân rã theo ranh giới sở hữu, không theo loại file. Cách chia specialist tự nhiên nhất phản chiếu đúng ranh giới sở hữu hiện có của team: backend/API, tầng dữ liệu, frontend, infra/CI. Nếu team bạn đã có sẵn các ranh giới này cho công việc của con người, đó cũng chính là ranh giới đúng cho công việc của agent — đừng phát minh lại sơ đồ phân rã từ đầu.
3. Viết task contract trước khi song song hóa. Shared Task System chỉ hoạt động nếu mỗi đơn vị công việc của specialist có input rõ, output rõ, và định nghĩa “xong” rõ ràng — cùng kỷ luật như viết một ticket tốt. Nếu bạn không viết được contract đó trong hai câu, task chưa sẵn sàng để tách ra cho specialist.
4. Bắt đầu pilot đầu tiên với debugging, không phải feature work. Debug song song theo giả thuyết ít rủi ro hơn triển khai feature song song — các specialist không cần tích hợp kết quả thành một hệ thống chạy được, chỉ cần báo cáo phát hiện. Đây là cách dễ nhất để chứng minh mô hình này với một team còn hoài nghi, trước khi tin tưởng giao việc thật sẽ ship.
5. Giữ một con người làm “Lead Agent của Lead Agent,” ít nhất là ban đầu. Vẫn cần ai đó review kế hoạch mà Lead Agent tạo ra trước khi các specialist bắt đầu thực thi — cùng loại review bạn muốn có trước khi ba kỹ sư bắt đầu chạy ba nhánh song song. Đừng bỏ qua bước review kế hoạch chỉ vì người lập kế hoạch là agent.
6. Theo dõi chi phí điều phối, không chỉ lợi ích song song hóa. Chia task thành specialist tốn chi phí — tích hợp, chuyển giao context, việc Lead Agent phải suy luận cách chia việc. Với task đơn giản đến mức xong trong một lượt tập trung, một agent đơn vẫn nhanh hơn. Dành mô hình multi-agent cho công việc thực sự nhiều phần.

Cho dự án cá nhân

1. Dùng mô hình này cho bất kỳ việc gì trải dài qua các tầng bạn tự context-switch. Nếu bạn tự làm side project một mình và thấy mình mất dấu quyết định khi chuyển qua lại giữa backend và frontend trong một session dài, đó chính là triệu chứng context-overload ở quy mô cá nhân — hãy chia việc thành các session specialist có phạm vi rõ, giống cách bạn sẽ chia cho một team.
2. Coi task list của bạn là Shared Task System. Dù bạn dùng gì — file markdown, một tracker nhẹ — kỷ luật vẫn giống nhau: trạng thái nằm ngoài bất kỳ session agent đơn lẻ nào, để bạn có thể quay lại một luồng công việc mà không phải suy luận lại từ đầu xem mình đã dừng ở đâu.
3. Đừng chạy mọi thứ trong một mega-session chỉ vì tiện. Rất dễ giữ một chat dài liên tục vì việc chuyển đổi cảm giác như overhead. Nhưng failure mode context-overload xuất hiện ở công việc cá nhân y hệt như ở team — cách khắc phục vẫn là cùng một kỷ luật, chỉ áp dụng cho một team gồm một người.

Ranh giới cần giữ

Rủi ro của bất kỳ mô hình multi-agent nào là áp dụng quá đà — khởi tạo specialist cho công việc chưa bao giờ đủ phức tạp để cần phân rã, và trả chi phí điều phối một cách vô ích. Dùng đúng bài test bạn sẽ dùng cho một team con người: nếu công việc thực sự có các phần độc lập, song song hóa được, với ranh giới sở hữu rõ ràng, hãy phân rã. Nếu đó là một chuỗi suy luận liên tục không chia tách gọn được, một agent tập trung — hay một kỹ sư tập trung — vẫn thắng một ủy ban.

Tuần này: chọn một task lặp lại mà setup agent hiện tại của bạn đang đâm vào bức tường context, phân rã theo đúng ranh giới sở hữu thật của team, và chạy thử một lần theo mô hình Lead + Specialist. Bạn sẽ biết ngay trong một lần chạy liệu chi phí điều phối có đáng hay không.

Nguồn: Inside Claude Code’s Multi-Agent Architecture của Devika Nekkalapu.