原文标题：《Tam Tư Lục Phần Vô Thực: Tại sao Mô Hình Nhiều Agent Kiểu "Công Ty Ảo" không Thực Tế trong Kỹ Thuật》
原文作者：SagaSu, Nhà Khởi Nghiệp AI

Một phương pháp thiết kế mạng lưới rộng rãi trong cộng đồng AI đang khiến nhiều nhóm đi sai đường.

Đầu tiên, hãy nói về kết luận

Nếu bạn đang cân nhắc đặt tên cho nhiều AI Agent khác nhau là "Quản Lý Sản Phẩm", "Kiến Trúc Sư", "Kỹ Sư Kiểm Thử", để chúng hoạt động như các bộ phận công ty, truyền tải tài liệu và cộng tác để hoàn thành nhiệm vụ—xin hãy dừng lại.

Mô hình này có vẻ rất dễ hiểu, logic lý trí, nhưng nó có nhược điểm cơ bản trong kỹ thuật. Quan trọng hơn, khi xây dựng hệ thống Agent của riêng mình, các công ty Anthropic, OpenAI, Google không ai sử dụng mô hình này.

Điều này không phải là ngẫu nhiên.

Những gì là "Tam Tư Lục Phần"

So sánh này chỉ đề cập đến một loại suy nghĩ thiết kế nhiều Agent phổ biến trong cộng đồng, với các tên khác nhau trong các khung và bài viết khác nhau: role-based agents, virtual team, phân cấp CrewAI, tổ chức MetaGPT — trong bài viết này được gọi chung là "Tam Tư Lục Phần".

Mô hình cốt lõi là: chia một nhiệm vụ phức tạp thành nhiều chức năng, mỗi Agent đảm nhận một vai trò—PM chịu trách nhiệm yêu cầu, Tech Lead chịu trách nhiệm kiến trúc, Dev chịu trách nhiệm thực hiện, QA chịu trách nhiệm kiểm thử. Nhiệm vụ chuyển giao giữa các Agent, như một dây chuyền sản xuất.

Mô hình này trông rất hấp dẫn trên sơ đồ. Nó đáp ứng nhu cầu "phân công cộng tác" của con người, cũng khiến khái niệm "đội AI" trở nên rõ ràng và dễ giải thích. Các khung công việc CrewAI chẳng hạn đã thu hút một lượng lớn người dùng vì điều này.

Vấn đề là, mô hình này giải quyết vấn đề chậm trễ của con người, không phải là vấn đề chậm trễ của AI.

Tại sao so sánh này từ cơ bản đã sai

Con người cần phân công, bởi vì:

· Sự chú ý của một người đơn không đủ, không thể xử lý đồng thời tất cả thông tin

· Con người có rào cản chuyên môn, chi phí chuyển đổi cao

· Cần có giao diện giữa con người và con người để phối hợp

Nhưng tính chất của LLM hoàn toàn khác biệt:

· Cùng một mô hình có thể viết PRD và viết mã, không có "Ranh giới nghề nghiệp"

· Chòm sao của mô hình không phải là độ rộng tập trung, mà là sâu suy luận và đầy đủ thông tin

· Giữa các mô hình không có "Văn hóa" và "Hiểu biết" để bù đắp sự mất mát thông tin

Đánh dấu Agent với nhãn "Quản lý Sản phẩm" sẽ không làm cho nó chuyên nghiệp hơn — nhưng sẽ làm cho nó từ chối vượt quá ranh giới. Một Agent bị kẹt trong vai trò "Kỹ sư kiểm thử", có thể bỏ qua ngay vấn đề tại tầng kiến trúc, vì "Nằm ngoài phạm vi trách nhiệm của tôi". Suy luận có giá trị nhất thường xảy ra ở biên giới, và mô hình ba châu sáu bộ đã phong kín mức này.

Việc đóng vai hóa tạo ra ranh giới giả. Đây là vấn đề đầu tiên.

Vấn đề thứ hai: Thông tin chết trong quá trình lưu thông

Trong mô hình ba châu sáu, Agent A tạo ra một tài liệu, chuyển giao cho Agent B.

Quá trình này truyền đạt là kết luận, không phải là quá trình suy luận.

B nhận tài liệu, hiểu lại, xây dựng ngữ cảnh trở lại. Ý định ban đầu đang giảm sút, giả định ngầm định đang mất, mỗi lần truyền giao đều tích luỹ sai số. Càng dài quy trình làm việc, kết quả cuối cùng càng "phần nào đúng cái cục nhưng toàn thể dịch chuyển" — Mỗi nút trông có vẻ hợp lý, nhưng tổng thể đã bị mất mục tiêu ban đầu.

Tổ chức con người dựa vào cuộc họp, văn hóa, truyền thông không chính thức để bù đắp cho việc mất mát thông tin này. Giữa các Agent không có cơ chế này.

Đây là một biện pháp phản biện phổ biến: Giải pháp của ba nhà sản xuất (tập tin tiến trình, tập tin mô tả, sổ tay vận hành) cũng chỉ là "Truyền tập tin" phải không? Sự khác biệt ở điểm nào?

Sự khác biệt nằm ở ai viết, viết cho ai, cách cập nhật như thế nào.

Quá trình lưu thông thông tin trong ba châu sáu là Giao tiếp một chiều giữa các vai trò: A viết xong chuyển giao cho B, B không quay trở lại nữa, A cũng không biết B đã dùng tài liệu này 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, việc truyền đạt trở thành điểm dừng.

Tệp trạng thái bên ngoài là nhật ký tăng dần của cùng một nhiệm vụ: thực thể thực thi nối tiếp vào cùng một bản ghi tại mỗi điểm kiểm tra, phiên tiếp theo đọc lịch sử đầy đủ của nhiệm vụ, không phải kết luận đầu ra của "đồ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ỉ là khác thời gian. Thông tin không được "nén chuyển tiếp", mà là "tích luỹ liên tục".

Sự khác biệt này quyết định xem chuỗi suy luận có thể duy trì liên tục qua các phiên hay không.

Một lượng lớn token đã bị lãng phí cho "tệp trao đổi" giữa các Agent, thay vì được sử dụng cho suy luận thực tế. Bạn nhận được là hệ thống mô phỏng hành vi công ty, chứ không phải là hệ thống giải quyết vấn đề.

Cách ba công ty thực sự thực hiện

Đáng chú ý là khi Anthropic, OpenAI, Google xây dựng các hệ thống Agent sản xuất của họ, gần như không thể tìm thấy "vai trò chơi đóng" hoặc "phan nhánh bộ phận" trong tài liệu kỹ thuật của họ.

Anthropic: Kỹ thuật Ngữ cảnh + Tệp trạng thái rõ ràng

Anthropic nâng cấp "Kỹ thuật Gợi ý" nội tại lên thành "Kỹ thuật Ngữ cảnh": Vấn đề không phải là làm thế nào để viết một câu gợi ý tốt, mà là cấu hình token nào có thể tạo ra hành vi mong muốn nhất.

Khi xây dựng hệ thống Claude Code và Research, thách thức cốt lõi mà họ đối mặt là: Agent phải hoạt động trong các phiên rời rạc, mỗi phiên mới không có bất kỳ bộ nhớ nào về những gì đã xảy ra trước đó. Ông họa của họ là "Kỹ sư ca": Mỗi kỹ sư ca mới bắt đầu ca làm việc không biết gì về công việc của ca trước đó.

Giải pháp không phải là để Agent đóng vai trò khác nhau, mà là:

· claude-progress.txt: Một nhật ký công việc liên tục qua các phiên, Agent cập nhật khi mỗi phiên kết thúc, và đọc khi bắt đầu phiên tiếp theo

· Lịch sử Git: Là điểm mốc trạng thái, ghi chép mỗi thay đổi tăng dần

· Đại Lý Khởi Tạo: Chỉ chạy trong session đầu tiên, thiết lập môi trường, triển khai danh sách tính năng, viết sổ runbook để tất cả session sau này sử dụng

Thông tin Quan Trọng: Sự Liên Tục của Chuỗi Suy luận không phải dựa vào việc mô hình "nhớ" mà dựa vào trạng thái bên ngoài rõ ràng để mốc nối.

Họ cũng nhận ra rằng việc cứng mã hóa "giả định khả năng của mô hình" vào harness là nguy hiểm. Sonnet 4.5 có "lo âu về ngữ cảnh" - kết thúc sớm khi gần đến giới hạn ngữ cảnh, do đó, harness đã thêm đặt lại ngữ cảnh.

Nhưng Hành vi này đã biến mất trong Opus 4.5, đặt lại đã trở thành trở ngại cứng . Điều này cho thấy: harness cần tiến triển theo sự tiến hóa của mô hình, bất kỳ "giải pháp vĩnh viễn" nào đều chỉ là sự thỏa hiệp kỹ thuật ở giai đoạn hiện tại.

Trong hệ thống Nghiên cứu của nhiều Đại lý, kiến trúc của Anthropic là orchestrator-worker: một đại lý chính phân rã công việc, điều phối các đại lý phụ, các đại lý phụ khám phá các hướng khác nhau đồng thời, kết quả trở về đại lý chính để tổng hợp.

Họ nhận thấy rằng lượng token tiêu tốn chính nó giải thích 80% sự khác biệt về hiệu suất - Giá trị của nhiều Đại lý không phải là "chuyên môn hóa", mà là sử dụng nhiều token để bao phủ không gian tìm kiếm lớn hơn.

Ở đây có một điểm dễ nhầm lẫn: Đại lý phụ của Anthropic dường như cũng giống như "chuyên môn hóa", nhưng bản chất hoàn toàn khác biệt. Ba bang sáu bộ là chuyên môn hóa chức năng - các vai trò khác nhau đảm nhận các công việc khác nhau, PM hoàn thành và chuyển cho Dev, Dev hoàn thành và chuyển cho QA, mỗi vai trò chỉ xử lý một phần của dòng chảy công việc.

Đại lý phụ của Anthropic là chuyên môn hóa chức năng - nhiều đại lý cùng loại hoạt động tìm kiếm các hướng khác nhau cùng một lúc, không có "gậy kế tiếp", kết quả đều được sản sinh trở lại orchestrator duy nhất để tổng hợp. Mô hình này giống như đồng loạt tung lưới, không phải là cuộc chạy tiếp sức.

OpenAI: Tích hợp + Kỹ năng + Tệp Spec có cấu trúc

Nguyên tắc nhiệm vụ dài hạn mà OpenAI đưa ra trực tiếp hơn: lập kế hoạch cho tính liên tục ngay từ khi bắt đầu nhiệm vụ.

Trong thử nghiệm Codex của họ, các kỹ sư cung cấp cho agent một tệp spec (mục tiêu đóng băng, ngăn agent "tạo ra một cái gì đó ấn tượng nhưng hướng đi sai"), để agent tạo kế hoạch dựa trên các mốc thời gian, sau đó sử dụng một tệp runbook để hướng dẫn agent hoạt động. Tệp runbook này cũng là bộ nhớ chia sẻ và nhật ký kiểm toán.

Kết quả: GPT-5.3-Codex chạy liên tục khoảng 25 giờ, hoàn thành một công cụ thiết kế hoàn chỉnh, duy trì tính liên tục suốt quá trình.

Tích hợp trên máy chủ được coi là nguyên tắc cơ sở mặc định, không phải là phương án dự phòng khẩn cấp. Trong các nhiệm vụ đa 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ì phải tái tạo ngữ cảnh mỗi lần.

Họ cũng giới thiệu khái niệm Kỹ năng - một bộ chỉ thị có thể tái sử dụng, có phiên bản, được gắn kết vào container, giúp agent thực hiện nhiệm vụ cụ thể với quy trình hoạt động ổn định. Điều này không phải là "vai trò", mà là công cụ và quy trình hoạt động, một thứ khác biệt về bản chất.

Google: 1 triệu ngữ cảnh + Phát triển dựa trên ngữ cảnh

Hướng đi của Google là mở rộng cửa sổ cứng: Ngữ cảnh 1 triệu mã thông báo của Gemini là chiến lược phân biệt rõ ràng. Lập luận của họ là: Các công nghệ trước đây như RAG slices, loại bỏ tin nhắn cũ đã được "đặt trực tiếp vào đó" trong cửa sổ đủ lớn.

Nhưng họ cũng công nhận điều này không đủ. Google đã giới thiệu tiện ích Conductor trong CLI của Gemini, với ý tưởng cốt lõi giống hệt Anthropic: di dời ý định dự án khỏi cửa sổ trò chuyện, đưa vào tệp Markdown bền vững trong cơ sở code. Triết lý là: "Không phụ thuộc vào nhật ký trò chuyện không ổn định, mà phụ thuộc vào tệp spec và kế hoạch chính thức."

Gemini 3 cũng giới thiệu cơ chế Thought Signatures: lưu giữ các điểm quan trọng của chuỗi suy luận trong một session dài, ngăn chặn việc 「reasoning drift」— vấn đề mất tính nhất quán logic trong một bối cảnh dài.

Nguyên tắc kiến trúc thực sự là gì

Từ thực tiễn kỹ thuật của ba công ty, có thể rút ra một số nguyên tắc chung:

Chuỗi suy luận không thể bị đứt, chỉ có thể bị chia và sau đó hợp nhất lại. Sử dụng đúng đắn của Nhiều Agent không phải là dòng chảy công việc, mà là một Agent chính giữ toàn bộ ý định, cuộc gọi con dùng để đào sâu vào một vấn đề con nào đó, kết quả được trả về cho Agent chính, không phải chuyển giao cho Agent tiếp theo.

Trạng thái bên ngoài rõ ràng, không phụ thuộc vào việc mô hình ghi nhớ. progress.txt, lịch sử Git, tệp spec, cơ sở dữ liệu—dạng thức không quan trọng, nguyên tắc là: các điểm quan trọng của chuỗi suy luận phải được bên ra vào lưu trữ vĩnh cửu, không phụ thuộc vào việc mô hình 「nhớ」 trong cửa sổ bối cảnh.

Giá trị của Nhiều Agent đến từ việc phủ song song, không phải từ việc phân chia công việc. Kết luận từ Hệ thống Nghiên cứu về Người, rõ ràng: cải thiện hiệu suất chủ yếu đến từ 「dùng nhiều token hơn」, không phải từ 「phân chia công việc hợp lý hơn」. Nhiều Agent thích hợp cho nhiệm vụ dạng đi theo chiều rộng—cần khám phá đồng thời nhiều hướng độc lập. Không thích hợp cho những tình huống yêu cầu suy luận liên tục, phụ thuộc sâu vào ngữ cảnh.

Agent Xác thực là người phủ định, không phải người tiếp tục. Nếu muốn sử dụng Nhiều Agent để kiểm soát chất lượng, thiết kế đúng là để một Agent chỉ tìm lỗi cho một Agent khác, không phải 「chuyển giao kết quả công việc」. Kiểm tra theo phong cách xung đối, không phải dòng chảy công việc.

Công cụ chỉ là công cụ, không phải là vai trò. Đưa cho Agent cái công cụ gì (bash, đọc viết tệp, tìm kiếm, thực thi mã) quan trọng hơn rất nhiều so với dán nhãn cho nó vai trò gì. Công cụ quyết định Agent có thể làm gì; nhãn vai trò chỉ hạn chế điều nó muốn làm thôi.

Tại sao Tam Tỉnh Lục Bộ lại phổ biến?

Bởi vì nó dễ giải thích.

「Người này là Agent PM, người kia là QA」 —— Câu này ai cũng hiểu được. Nó đáp ứng nhu cầu của con người về tính minh bạch của hệ thống AI, cũng như nguyện vọng của ban quản trị về việc 「AI làm việc như một nhóm」.

Nó cũng tốt cho việc trình bày. Vẽ bằng sơ đồ quy trình, có bộ phận, mũi tên, phối hợp, rất trực quan.

Nhưng tính minh bạch tốt và việc trình bày tốt, và việc hiệu suất kỹ thuật có thực sự đứng vững không phải là một vấn đề.

Lý do sâu xa hơn là: Đa số các nhóm áp dụng mô hình này không thực sự đối mặt với vấn đề 「sự mất mát trong việc truyền đạt ngữ cảnh giữa nhiều Agent」. Công việc của họ có lẽ chưa đủ phức tạp, hoặc vấn đề đã bị các yếu tố khác che đi. Khi mức độ phức tạp tăng lên, hệ thống bắt đầu xuất hiện hiện tượng 「đúng địa phương, sai tổng thể」 thì vấn đề mới được phơi bày.

Khuyến nghị Thực hành

Hệ thống nhiều Agent tốt nhất không giống như một công ty. Nó giống như nhiều bản dự thảo của một người tư duy — cùng một bộ não, trải qua lý luận ở các chiều không gian khác nhau, cuối cùng hội tụ thành một kết luận mạch lạc.

Xuất phát từ 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 công việc này là gì」.

Nếu công việc yêu cầu lý luận liên tục, phụ thuộc ngữ cảnh cao (ví dụ như viết một tài liệu thiết kế chức năng phức tạp), một Agent + kỹ thuật kỹ thuật ngữ cảnh tốt thường ưu việt hơn nhiều Agent.

Nếu công việc yêu cầu khám phá cùng một lúc nhiều hướng độc lập (ví dụ như nghiên cứu cùng một lúc 10 mô-đun khác nhau của đối thủ), việc sử dụng nhiều Agent song song là hợp lý — công việc của mỗi subagent là độc lập lẫn nhau, chi phí mất mát thông tin là nhỏ nhất. Đây chính là lý do đằng sau sự khác biệt hiệu suất 80% được giải thích bằng lượng mã thông báo hệ thống nghiên cứu Anthropi: Đó không phải là việc phân công làm cho nó tốt hơn, mà là vùng tìm kiếm lớn hơn làm cho nó tốt hơn.

Nếu công việc bao gồm nhiều session, tệp trạng thái bên ngoài là bắt buộc. Một tệp trạng thái hợp lý nên bao gồm bốn loại thông tin:

· Mục tiêu nhiệm vụ (bất biến, đọc khi bắt đầu session, ngăn chặn độ dịch chuyển)

· Bước đã hoàn thành (bổ sung, không ghi đè, giữ nguyên lịch sử đầy đủ)

· Tình trạng hiện tại (Bao gồm, phản ánh thông tin mới nhất)

· Các vấn đề đã biết (Bổ sung để tránh việc lặp lại trong session tiếp theo)

Bốn loại thông tin này được duy trì riêng biệt, khi kết hợp lại sẽ tạo thành ngữ cảnh đầy đủ mà "bản thân tiếp theo" cần.

Nếu muốn thêm bước xác thực, đưa nhiệm vụ duy nhất của Điều Phối Viên xác thực là tìm vấn đề, không phải là "tiếp tục công việc". Kiểm tra đối đầu, không phải là truyền dẫn trên dây chuyền sản xuất.

Cuối cùng: Khả năng của mô hình đang tăng nhanh chóng, những cách xử lý tạm thời cần thiết trong harness hôm nay có thể trở thành gánh nặng vào sau sáu tháng. Anthropic đã chứng minh điều này - nỗi lo lắng về ngữ cảnh của Sonnet 4.5 đã biến mất trong Opus 4.5, và việc thiết kế lại ngữ cảnh đó đã trở thành mã không còn cần thiết. Để tạo ra một kiến trúc có thể tiến hóa, quan trọng hơn là lựa chọn một "kiến trúc hoàn hảo".

Bảy Lựa Chọn ba Việc là một ảo tưởng làm bạn cảm thấy hài lòng nhưng với một chi phí kỹ thuật cao. 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 một cách không thể chẩn đoán được khi phức tạp hóa - mỗi nút mạng đều "dường như hoạt động" nhưng tổng thể đang trôi dạt.

Khi bạn phát hiện sự cố, dây chuyền sản xuất đã trở nên rất dài.

Tham khảo:

Anthropic Engineering Blog (Xây dựng Điều Phối Viên Hiệu Quả, Kỹ Thuật Ngữ Cảnh Hiệu Quả, Hệ Thống Nghiên Cứu Đa Tác Nhân, Harness Hiệu Quả cho Điều Phối Viên Chạy Lâu dài, Điều Phối Viên Được Quản Lý); OpenAI Developers Blog (Chạy Nhiệm Vụ Trải Dài Với Codex, Shell + Kỹ Năng + Nén); Google Developers Blog (Kiến Trúc Khung Tác Nhân Đa Tác Nhân Hiệu Quả Về Ngữ Cảnh, Conductor: Phát Triển Dựa Trên Ngữ Cảnh Hiệu Quả Cho Gemini CLI)

Liên kết Gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia