Multi-agent: song song hóa việc đọc, giữ việc ghi ở một luồng

Ngày 12/6/2025, Walden Yan của Cognition đăng bài có tiêu đề thẳng thừng: “Don’t Build Multi-Agents”. Ngày hôm sau, Anthropic công bố hệ thống Research gồm một agent chính chạy Claude Opus 4 điều phối các subagent Sonnet 4. Theo eval nội bộ về nghiên cứu của chính Anthropic, hệ thống này vượt single-agent Opus 4 tới 90,2%.

Hai công ty cùng xây agent, hai kết luận trái ngược, cách nhau 24 giờ. Nếu bạn đang làm FDE, câu hỏi này sẽ đến từ khách hàng sớm thôi: “Bên em có nên dùng multi-agent không?”

Trả lời sai theo hướng nào cũng tốn kém. Từ chối khi bài toán thật sự cần thì khách bỏ lỡ một mức cải thiện chất lượng đáng kể. Đồng ý khi không cần thì bạn để lại một hệ thống đắt gấp nhiều lần, hỏng một cách khó đoán, và người phải debug nó lúc 2 giờ sáng rất có thể là bạn.

Hai phe không thật sự cãi nhau

Đọc kỹ thì Anthropic chưa bao giờ nói multi-agent tốt cho mọi thứ. Bài của họ viết rằng kiến trúc này mạnh ở những tác vụ có giá trị cao và cần song song hóa nhiều. Ngay trong bài, họ còn thừa nhận phần lớn tác vụ lập trình có ít phần thật sự chạy song song được hơn so với nghiên cứu.

Cognition, công ty làm agent viết code, thì nhìn từ phía ngược lại. Lập luận của Walden Yan là khi nhiều agent cộng tác, context và quyết định bị phân tán, kết quả là hệ thống mong manh.

Nguyên tắc thứ hai của ông giải thích vì sao: mỗi hành động mang theo những quyết định ngầm, và các quyết định ngầm xung đột nhau thì cho ra kết quả tồi.

Bài của LangChain, đăng ba ngày sau bài của Anthropic, giúp hai quan điểm này khớp lại. Nhận định của họ: hành động đọc vốn dễ song song hóa hơn hành động ghi. Nhìn hai bài kia theo cách chia này thì mọi thứ rõ ràng: nghiên cứu là đọc, viết code là ghi.

Thử hình dung một ví dụ. Một agent con đi đọc tài liệu về nhà cung cấp A, agent khác đọc về nhà cung cấp B. Hai việc này không giẫm chân nhau, vì đọc xong không làm thay đổi thế giới.

Nhưng nếu agent con thứ nhất viết hàm xử lý ngày tháng theo múi giờ UTC, agent thứ hai viết phần giao diện ngầm giả định giờ địa phương, cả hai đều “đúng” khi đứng riêng và sai khi ghép lại. Đó chính là những quyết định ngầm mà Cognition nói tới.

Cái giá không chỉ nằm ở hóa đơn

Mức khoảng 15 lần token so với chat mà Anthropic công bố dễ hình dung hơn qua một phép tính giả định: một lượt hỏi đáp tốn 10.000 token sẽ thành khoảng 150.000 token. Với một báo cáo phân tích thị trường mà analyst mất cả ngày, con số đó rẻ; với chatbot tra cứu chính sách nghỉ phép, nó vô lý.

Hóa đơn token còn là phần dễ thấy. Từ cuối 2024, Anthropic đã cảnh báo rằng tính tự chủ của agent kéo theo chi phí cao hơn và nguy cơ lỗi cộng dồn. Phép tính giả định thứ hai: nếu mỗi bước của agent đúng 95%, một chuỗi 10 bước phụ thuộc nhau chỉ còn đúng khoảng 60% (0,95 mũ 10).

Thêm agent là thêm bước, thêm điểm bàn giao, thêm chỗ để lỗi nhân lên.

Vì sao debug khó hơn hẳn

Với phần mềm thường, bạn chạy lại cùng input và thấy cùng lỗi. Agent thì không như vậy. Anthropic viết rằng agent ra quyết định động và không tất định giữa các lần chạy, kể cả với prompt giống hệt nhau.

Nhân điều đó lên nhiều agent nói chuyện với nhau, bạn có một hệ thống mà lỗi hôm qua có thể không tái hiện hôm nay. Anthropic cũng thừa nhận agent LLM hiện chưa giỏi điều phối và giao việc cho agent khác theo thời gian thực. Nghĩa là phần khó nhất của kiến trúc lại là phần model yếu nhất.

Cognition cũng nói về trace, nhưng ở một góc khác. Nguyên tắc đầu tiên của họ là chia sẻ context: chuyển cho agent khác toàn bộ trace của agent, chứ không chỉ từng tin nhắn. Với Anthropic, trace là công cụ để kỹ sư tìm lỗi; với Cognition, trace là thứ agent cần để không ra quyết định trong khi thiếu thông tin.

Hai mục đích khác nhau, nhưng cùng gợi ý một điều: thứ cần giữ lại là cả chuỗi bước, không chỉ câu trả lời cuối.

Mẫu đang chạy được: nhiều mắt đọc, một tay ghi

Tháng 4/2026, Cognition quay lại chủ đề với một bài cập nhật mềm mỏng hơn tiêu đề năm trước. Kết luận của họ: multi-agent hiện chạy tốt nhất khi việc ghi vẫn nằm ở một luồng duy nhất. Kết luận này trùng với cách LangChain chia đọc và ghi.

Mẫu cụ thể đáng học nhất từ bài này là reviewer có context sạch. Theo Cognition, một reviewer như vậy bắt được những bug mà chính agent viết code không nhìn thấy. Lý do dễ hiểu: agent đã viết code mang theo toàn bộ giả định của nó, còn reviewer chỉ đọc kết quả, không bị lối nghĩ cũ dẫn dắt, và quan trọng là nó không ghi gì cả.

Gộp các nguồn lại, có thể dựng một bảng quyết định mà không bài nào tự đưa ra đầy đủ:

Tình huống ở khách hàng	Đọc hay ghi	Kiến trúc hợp lý	Lý do
Tổng hợp thông tin từ nhiều nguồn độc lập	Chủ yếu đọc	Agent chính + subagent song song	Tách được, giá trị đủ cao để bù chi phí token
Sửa code trên nhiều file	Ghi	Một agent tuyến tính	Quyết định ngầm của nhiều agent sẽ xung đột
Kiểm tra code agent vừa viết	Đọc	Thêm reviewer context sạch	Bắt bug mà agent viết không thấy, không đụng vào luồng ghi
Hỏi đáp, tra cứu đơn giản	Đọc ít	Một lần gọi model hoặc một agent	Đơn giản nhất là đủ, chi phí không tương xứng

Dòng cuối là nơi nhiều dự án dễ sai nhất. Lời khuyên của Anthropic từ bài “Building effective agents” vẫn đúng: tìm giải pháp đơn giản nhất có thể, chỉ tăng độ phức tạp khi thật sự cần.

Ở site khách hàng, bắt đầu từ đâu?

Giả sử một công ty bảo hiểm muốn agent vừa đọc hồ sơ bồi thường, đối chiếu điều khoản, vừa cập nhật trạng thái hồ sơ trong hệ thống lõi. Bước đầu tiên của bạn không phải vẽ sơ đồ năm agent. Hãy liệt kê mọi hành động và đánh dấu: đọc hồ sơ, đọc điều khoản, tra lịch sử khách là đọc; cập nhật trạng thái là ghi.

Từ đó kiến trúc gần như tự hiện ra. Các bước đọc độc lập có thể giao cho subagent chạy song song nếu khối lượng đủ lớn. Bước ghi vào hệ thống lõi do đúng một agent đảm nhận, với toàn bộ context trong tay. Nếu sai sót tốn kém, thêm một reviewer chỉ đọc, kiểm tra trước khi ghi.

Và trước khi viết dòng code agent đầu tiên, hãy dựng tracing. Khi khách gọi báo “hôm qua nó duyệt sai một hồ sơ”, thứ bạn cần là trace đầy đủ của đúng lần chạy đó, không phải lời hứa sẽ thử tái hiện.

Kể quyết định, đừng kể số agent

Nếu bạn gặp “kinh nghiệm multi-agent” trong một JD, đừng hiểu đó là yêu cầu phải xây hệ thống càng nhiều agent càng tốt. Một người phỏng vấn hiểu chuyện rất có thể sẽ hỏi ngược: vì sao bạn không dùng một agent?

Vì thế, khi viết CV hay kể dự án, hãy kể quyết định, không kể số lượng agent. Một dòng như “tách bước tra cứu tài liệu thành subagent song song, giữ bước cập nhật dữ liệu ở một agent, thêm reviewer và tracing” cho thấy bạn hiểu cả lợi lẫn giá.

Nếu từng gỡ một hệ thống multi-agent về single-agent và nó ổn định hơn, đó còn là câu chuyện phỏng vấn tốt hơn.

Kỹ năng nên luyện song song là đọc trace. Nếu bạn từng lần theo một chuỗi tool call và chỉ ra được chỗ hai quyết định ngầm va nhau, đó là một ví dụ cụ thể để kể trong phỏng vấn, thuyết phục hơn nhiều so với một danh sách framework điều phối.

Hơn một năm sau hai tiêu đề đối đầu của tháng 6/2025, câu trả lời không nằm ở phe nào. Nó nằm ở một dòng phân loại đơn giản mà bạn có thể làm ngay ở buổi discovery đầu tiên: việc này đọc hay ghi?