**
Một ý tưởng kiến trúc được lan truyền rộng rãi trong cộng đồng AI đang dẫn dắt nhiều nhóm đi lạc hướng.
Kết Luận Trước Tiên
Nếu bạn đang cân nhắc đặt tên cho nhiều AI Agent là "Product Manager", "Architect" và "Test Engineer", rồi bảo chúng chuyền tài liệu và cộng tác như các phòng ban trong công ty—hãy dừng lại.
Mô hình này có vẻ trực quan và hợp lý về mặt logic, nhưng nó có những sai sót cơ bản trong kỹ thuật. Quan trọng hơn, không ai trong số ba nhà cung cấp lớn—Anthropic, OpenAI và Google—sử dụng mô hình này khi xây dựng hệ thống Agent của riêng họ.
Đây không phải là sự trùng hợp ngẫu nhiên.
Kiến Trúc "Ba Phòng Sáu Ban" Là Gì?
Phép ẩn dụ này đề cập đến một lớp ý tưởng thiết kế đa tác nhân phổ biến trong cộng đồng, được biết đến với nhiều tên gọi khác nhau trong các framework và bài viết: tác nhân dựa trên vai trò, nhóm ảo, phân công lao động kiểu CrewAI, hoặc tổ chức kiểu MetaGPT. Bài viết này gọi chung chúng là mô hình "Phân Ban" (Departmentalized).
Mô hình cốt lõi là: phân rã một tác vụ phức tạp thành nhiều chức năng, mỗi Agent đóng một vai trò—PM cho yêu cầu, Tech Lead cho kiến trúc, Dev cho triển khai và QA cho kiểm thử. Các tác vụ chảy giữa các Agent như một dây chuyền lắp ráp.
Mô hình này trông rất đẹp trên sơ đồ. Nó thỏa mãn trực giác của con người về "phân công lao động" và làm cho khái niệm "nhóm AI" trở nên cụ thể và dễ giải thích. Các framework như CrewAI đã thu hút được nhiều người dùng nhờ điều này.
Vấn đề là, nó giải quyết các nút thắt của con người, chứ không phải nút thắt của AI.
Tại Sao Sự Tương Tự Này Sai Về Cơ Bản
Con người cần phân công lao động vì:
- Một người có khả năng tập trung hạn chế và không thể xử lý tất cả thông tin cùng lúc.
- Con người có rào cản chuyên môn và chi phí học tập/chuyển đổi cao.
- Con người cần giao diện để phối hợp với nhau.
Nhưng đặc điểm của LLM hoàn toàn khác:
- Cùng một mô hình có thể viết cả PRD và code; không có "ranh giới chuyên môn".
- Nút thắt của mô hình không phải là khả năng tập trung, mà là độ sâu suy luận và tính toàn vẹn thông tin.
- Mô hình thiếu "văn hóa" và "sự hiểu ngầm" để bù đắp cho sự mất mát thông tin.
Gắn nhãn một Agent là "Product Manager" không làm cho nó chuyên nghiệp hơn—mà làm cho nó từ chối vượt ranh giới. Một Agent bị đóng khung vào vai trò "Test Engineer" có thể bỏ qua một vấn đề kiến trúc vì "nó không nằm trong phạm vi của tôi." Suy luận có giá trị nhất thường xảy ra ở các ranh giới, và mô hình Phân Ban đóng kín khả năng này ở cấp độ hệ thống.
Việc đóng vai tạo ra các ranh giới giả tạo. Đây là vấn đề đầu tiên.
Vấn Đề Thứ Hai: Thông Tin Chết Trong Quá Trình Truyền Tải
Trong mô hình Phân Ban, Agent A tạo ra một tài liệu và chuyển nó cho Agent B.
Quá trình này chuyển kết luận, chứ không phải quá trình suy luận.
B nhận tài liệu, hiểu lại nó và xây dựng lại ngữ cảnh. Ý định ban đầu bị suy giảm, các giả định ẩn bị mất, và mỗi lần bàn giao tích lũy lỗi. Quy trình càng dài, đầu ra cuối cùng càng trở nên "đúng cục bộ nhưng sai toàn cục"—mỗi nút trông có vẻ hợp lý, nhưng tổng thể đã lệch khỏi mục tiêu ban đầu.
Các tổ chức con người dựa vào các cuộc họp, văn hóa và giao tiếp không chính thức để bù đắp cho sự mất mát thông tin này. Các Agent không có các cơ chế này.
Có một phản biện phổ biến: Chẳng phải các giải pháp từ ba nhà cung cấp lớn (progress.txt, spec files, runbooks) cũng liên quan đến "chuyền file" sao? Khác biệt ở chỗ nào?
Sự khác biệt nằm ở ai viết, viết cho ai và cách nó được cập nhật.
Luồng thông tin trong mô hình Phân Ban là bàn giao một chiều giữa các vai trò: A hoàn thành và đưa cho B; B không nhìn lại, và A không biết B đã sử dụng tài liệu như thế nào. Thông tin bị nén thành kết luận, quá trình suy luận bị mất, và bàn giao là một điểm ngắt.
Các file trạng thái bên ngoài là nhật ký gia tăng của cùng một tác vụ: Thực thể thực thi thêm vào cùng một bản ghi tại mỗi điểm kiểm tra, và phiên tiếp theo đọc toàn bộ lịch sử của tác vụ, chứ không phải kết luận đầu ra của một "đồng nghiệp" trước đó. Người viết trạng thái và người đọc trạng thái là cùng một vai trò, chỉ khác thời điểm. Thông tin không bị "nén và chuyển"; nó được "tích lũy liên tục."
Sự khác biệt này quyết định liệu chuỗi suy luận có thể duy trì tính liên tục qua các phiên hay không.
Một lượng lớn token bị lãng phí vào "file bàn giao" giữa các Agent thay vì suy luận thực tế. Bạn có một hệ thống mô phỏng hành vi công ty, chứ không phải một hệ thống giải quyết vấn đề.
Cách Ba Nhà Cung Cấp Lớn Thực Sự Làm
Đáng chú ý là khi Anthropic, OpenAI và Google xây dựng hệ thống Agent cấp sản xuất của họ, các tài liệu kỹ thuật của họ hầu như không bao giờ đề cập đến "đóng vai" hay "phân chia phòng ban."
Anthropic: Kỹ Thuật Ngữ Cảnh + File Trạng Thái Rõ Ràng
Anthropic đã nâng cấp "Kỹ thuật Prompt" lên thành "Kỹ thuật Ngữ cảnh": Câu hỏi không phải là làm thế nào để viết một prompt tốt, mà là cấu hình token nào tạo ra hành vi mong muốn tốt nhất.
Khi xây dựng hệ thống Claude Code và Research, thách thức cốt lõi của họ là: Các Agent phải làm việc trong các phiên rời rạc, và mỗi phiên mới không có bộ nhớ về những gì đã xảy ra trước đó. Phép ẩn dụ của họ là "kỹ sư ca kíp"—mỗi ca kỹ sư mới không biết gì về công việc của ca trước.
Giải pháp không phải là bắt các Agent đóng các vai trò khác nhau, mà là:
- claude-progress.txt: Nhật ký công việc xuyên phiên mà Agent cập nhật vào cuối mỗi phiên và đọc vào đầu phiên tiếp theo.
- Lịch sử Git: Đóng vai trò là điểm neo trạng thái, ghi lại mọi thay đổi gia tăng.
- Initializer Agent: Chỉ chạy trong phiên đầu tiên để thiết lập môi trường, mở rộng danh sách tính năng và viết runbook cho tất cả các phiên tiếp theo.
Hiểu biết chính: Tính liên tục của chuỗi suy luận không phụ thuộc vào việc mô hình "nhớ"; nó phụ thuộc vào trạng thái bên ngoài rõ ràng để neo giữ nó.
Họ cũng phát hiện ra rằng việc mã hóa cứng "các giả định về khả năng của mô hình" vào harness là nguy hiểm. Sonnet 4.5 có "sự lo lắng về ngữ cảnh"—nó sẽ kết thúc sớm khi gần đến giới hạn ngữ cảnh, vì vậy họ đã thêm một bước reset ngữ cảnh vào harness. Nhưng trong Opus 4.5, hành vi này biến mất và việc reset trở thành gánh nặng vô ích. Điều này cho thấy harness cần phải phát triển cùng với mô hình; bất kỳ "giải pháp vĩnh viễn" nào cũng chỉ là một sự thỏa hiệp kỹ thuật cho giai đoạn hiện tại.
Trong các hệ thống Research đa tác nhân, kiến trúc của Anthropic là orchestrator-worker: một tác nhân chính phân rã tác vụ và điều phối các tác nhân phụ, chúng khám phá các hướng khác nhau song song, với kết quả chảy ngược về tác nhân chính để tổng hợp. Họ phát hiện ra rằng chỉ riêng mức tiêu thụ token đã giải thích 80% sự khác biệt về hiệu suất—giá trị của đa tác nhân không phải là "phân công lao động," mà là sử dụng nhiều token hơn để bao phủ một không gian tìm kiếm lớn hơn.
Có một điểm gây nhầm lẫn ở đây: Các tác nhân phụ của Anthropic có thể trông giống như "phân công lao động," nhưng bản chất là khác. Phân Ban là phân chia chức năng—các vai trò khác nhau xử lý các loại công việc khác nhau (PM đến Dev đến QA). Các tác nhân phụ của Anthropic là song song hóa chức năng—nhiều tác nhân giống hệt nhau tìm kiếm các hướng khác nhau đồng thời, không có "bàn giao tiếp theo," và tất cả kết quả hội tụ về cùng một orchestrator. Cái trước là chạy tiếp sức; cái sau là thả lưới rộng.
OpenAI: Nén + Kỹ Năng + File Spec Có Cấu Trúc
Các nguyên tắc của OpenAI cho các tác vụ dài hạn thậm chí còn trực tiếp hơn: lên kế hoạch cho tính liên tục ngay từ đầu tác vụ.
Trong các thí nghiệm Codex, các kỹ sư đã cung cấp cho agent một file spec (đóng băng mục tiêu để ngăn agent tạo ra thứ gì đó "ấn tượng nhưng sai hướng"), yêu cầu nó tạo ra một kế hoạch dựa trên các cột mốc, và sau đó sử dụng một file runbook để hướng dẫn agent cách vận hành. Runbook này cũng là một bộ nhớ dùng chung và nhật ký kiểm toán.
Kết quả: GPT-5.3-Codex chạy liên tục trong khoảng 25 giờ, hoàn thành một công cụ thiết kế đầy đủ trong khi duy trì tính mạch lạc xuyên suốt.
Việc nén phía máy chủ đóng vai trò là một nguyên hàm mặc định, không phải là một phương án dự phòng khẩn cấp. Trong các tác vụ nhiều bước, previous_response_id cho phép mô hình tiếp tục làm việc trong cùng một luồng thay vì xây dựng lại ngữ cảnh mỗi lần.
Họ cũng giới thiệu khái niệm Skills—các bộ hướng dẫn có thể tái sử dụng, có phiên bản, được gắn vào các container, cung cấp cho các agent các tiêu chuẩn vận hành ổn định cho các tác vụ cụ thể. Đây không phải là "vai trò"; chúng là công cụ và quy trình vận hành, về cơ bản là khác.
Google: Ngữ Cảnh 1M + Phát Triển Dựa Trên Ngữ Cảnh
Hướng đi của Google là mở rộng cửa sổ một cách mạnh mẽ: Ngữ cảnh 1M token của Gemini là một chiến lược khác biệt hóa rõ ràng. Logic của họ là các kỹ thuật trước đây bị ép buộc như cắt RAG và loại bỏ tin nhắn cũ có thể được thay thế bằng "chỉ cần bỏ tất cả vào" với một cửa sổ đủ lớn.
Nhưng họ thừa nhận ngay cả điều này cũng chưa đủ. Google đã ra mắt tiện ích mở rộng Conductor cho Gemini CLI, với ý tưởng cốt lõi giống hệt Anthropic: chuyển ý định dự án ra khỏi cửa sổ trò chuyện và vào các file Markdown cố định trong codebase. Triết lý: "Đừng dựa vào lịch sử trò chuyện không ổn định; hãy dựa vào các file spec và kế hoạch chính thức."
Gemini 3 cũng giới thiệu Thought Signatures: lưu các nút chính của chuỗi suy luận trong các phiên dài để ngăn chặn "sự trôi dạt suy luận"—vấn đề về sự không nhất quán logic trong các ngữ cảnh dài.
Các Nguyên Tắc Kiến Trúc Thực Sự Là Gì?
Từ các thực tiễn kỹ thuật của ba công ty này, có thể rút ra một số nguyên tắc chung:
Chuỗi suy luận không thể bị phá vỡ; nó chỉ có thể phân nhánh và hợp nhất. Cách sử dụng đúng của đa tác nhân không phải là dây chuyền lắp ráp, mà là một tác nhân chính giữ toàn bộ ý định, sử dụng các lệnh gọi phụ để đào sâu vào các vấn đề con, và kết quả chảy ngược về tác nhân chính, không phải chuyển cho tác nhân tiếp theo.
Trạng thái bên ngoài rõ ràng, đừng dựa vào bộ nhớ của mô hình. Cho dù đó là progress.txt, lịch sử git, file spec hay cơ sở dữ liệu—hình thức không quan trọng. Nguyên tắc là: các nút chính của chuỗi suy luận phải được ngoại hóa vào bộ nhớ vĩnh viễn.
Giá trị của đa tác nhân là bao phủ song song, không phải phân công lao động. Kết luận từ hệ thống Research của Anthropic rất rõ ràng: lợi ích về hiệu suất đến từ "chi tiêu nhiều token hơn," chứ không phải từ "phân công lao động tốt hơn." Đa tác nhân phù hợp cho các tác vụ ưu tiên chiều rộng—các kịch bản yêu cầu khám phá đồng thời các hướng độc lập. Chúng không phù hợp cho các kịch bản yêu cầu suy luận liên tục và phụ thuộc sâu vào ngữ cảnh.
Verifier Agent là người phủ nhận, không phải người chạy tiếp sức. Nếu sử dụng đa tác nhân để kiểm soát chất lượng, thiết kế đúng là có một Agent chuyên tìm vấn đề trong công việc của Agent khác, thay vì "chuyển giao kết quả công việc." Kiểm thử đối kháng, không phải chuyển giao dây chuyền.
Công cụ là công cụ, không phải vai trò. Bạn trang bị cho Agent những công cụ gì (bash, file I/O, tìm kiếm, thực thi code) quan trọng hơn nhiều so với nhãn bạn dán lên nó. Công cụ quyết định Agent có thể làm gì; nhãn vai trò chỉ giới hạn những gì nó sẵn sàng làm.
Tại Sao Mô Hình "Phân Ban" Lại Phổ Biến?
Bởi vì nó dễ giải thích.
"Agent này là PM, Agent kia là QA"—bất kỳ ai cũng có thể hiểu. Nó thỏa mãn mong muốn của con người về khả năng giải thích của hệ thống AI và trí tưởng tượng của ban quản lý về "AI làm việc như một nhóm."
Nó cũng dễ trình diễn. Được vẽ thành một sơ đồ luồng với các phòng ban, mũi tên và bàn giao, nó rất trực quan.
Nhưng dễ giải thích và trình diễn khác với việc có giá trị kỹ thuật.
Một lý do sâu xa hơn là hầu hết các nhóm áp dụng mô hình này chưa thực sự đối mặt với vấn đề "mất ngữ cảnh trong quá trình chuyển giao đa tác nhân." Các tác vụ của họ có thể chưa đủ phức tạp, hoặc vấn đề bị che lấp bởi các yếu tố khác. Một khi độ phức tạp của tác vụ tăng lên và hệ thống bắt đầu xuất hiện các lỗi "đúng cục bộ nhưng sai toàn cục," vấn đề sẽ lộ ra.
Lời Khuyên Thực Tế
Hệ thống đa tác nhân tốt nhất không giống một công ty. Nó giống nhiều bản nháp của một người suy nghĩ hơn—cùng một bộ não mở rộng suy luận trên các khía cạnh khác nhau và cuối cùng hợp nhất chúng thành một kết luận mạch lạc.
Dựa trên nguyên tắc này:
Đừng hỏi "Tôi cần bao nhiêu Agent?"; hãy hỏi "Cấu trúc phụ thuộc thông tin của tác vụ này là gì?"
Nếu một tác vụ yêu cầu suy luận liên tục và phụ thuộc nhiều vào ngữ cảnh (ví dụ: viết tài liệu thiết kế cho một tính năng phức tạp), một Agent duy nhất + kỹ thuật ngữ cảnh tốt thường vượt trội hơn so với đa tác nhân.
Nếu một tác vụ yêu cầu khám phá đồng thời các hướng độc lập (ví dụ: nghiên cứu 10 đối thủ cạnh tranh cùng lúc), song song hóa đa tác nhân là hợp lý—tác vụ của mỗi tác nhân phụ là độc lập và chi phí mất mát thông tin được giảm thiểu.
Nếu một tác vụ kéo dài nhiều phiên, các file trạng thái bên ngoài là bắt buộc. Một file trạng thái hiệu quả nên chứa bốn loại thông tin:
- Mục tiêu Tác vụ (Bất biến, đọc khi bắt đầu phiên để ngăn trôi dạt)
- Các Bước Đã Hoàn Thành (Được thêm vào, không ghi đè, để giữ toàn bộ lịch sử)
- Trạng Thái Hiện Tại (Được ghi đè để phản ánh tiến độ mới nhất)
- Cạm Bẫy Đã Biết (Được thêm vào để tránh lặp lại sai lầm trong phiên tiếp theo)
Bốn loại thông tin này, được duy trì riêng rẽ và kết hợp lại, cung cấp đầy đủ ngữ cảnh cần thiết cho "bản thân trong tương lai."
Nếu thêm một bước xác minh, hãy làm cho Verifier Agent có nhiệm vụ duy nhất là tìm ra vấn đề, chứ không phải "cầm gậy tiếp sức và chạy tiếp." Kiểm thử đối kháng, không phải chuyển giao dây chuyền.
Cuối cùng: Khả năng của mô hình đang được cải thiện nhanh chóng. Các giải pháp tạm thời cần thiết trong harness hôm nay có thể trở thành gánh nặng vô ích trong sáu tháng tới. Anthropic đã chứng minh điều này—sự lo lắng về ngữ cảnh của Sonnet 4.5 đã biến mất trong Opus 4.5. Duy trì khả năng tiến hóa của kiến trúc quan trọng hơn việc chọn một "kiến trúc hoàn hảo."
Phân Ban là một ảo ảnh dễ chịu nhưng tốn kém về mặt kỹ thuật. Chi phí thực sự của nó không phải là thất bại trực tiếp, mà là làm cho hệ thống của bạn suy giảm theo những cách khó chẩn đoán khi độ phức tạp tăng lên—nơi mọi nút "trông như đang hoạt động," nhưng tổng thể đang trôi dạt.
Đến khi bạn tìm ra vấn đề, dây chuyền lắp ráp đã rất dài rồi.
Tham khảo: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
