Vừa mới, DeepSeek công bố ý tưởng harness agent thế hệ tiếp theo

Tiêu đề gốc: Khám Phá Thiết Kế Super-agent: Hướng Tới Hệ Thống Agent Tự Chủ Hơn

Tác giả gốc: Bộ Phận Sản Phẩm DeepSeek

1. Super-agent

Trong năm qua, các Agent đơn nhiệm đại diện cho Coding Agent đã chứng minh rằng mô hình có thể sử dụng công cụ để giải quyết các vấn đề phức tạp, và ngày càng ít cần sự giám sát và can thiệp liên tục của con người. Trong khi đó, khả năng hợp tác của mô hình đa Agent cũng đang được cải thiện, khiến cho việc tổ chức và điều phối xuyên suốt các phiên trở nên khả thi. Khi sự tham gia của con người trong việc thực hiện các tác vụ cơ bản giảm bớt, vai trò của con người đang dần chuyển lên các quyết định và chấp nhận ở cấp độ cao hơn.

Sự nâng cao này của khả năng mô hình cũng đã thúc đẩy sự xuất hiện của các hình thức ứng dụng mới. Gần đây, các trợ lý cá nhân (Personal Agent) bắt đầu xuất hiện nhiều hơn, chúng trực tiếp kết nối với các tin nhắn hàng ngày, lịch trình, email và nền tảng công việc, liên tục theo dõi dòng thông tin và hỗ trợ xử lý các công việc. Mô hình làm việc liên tục trực tuyến, dựa trên sự kiện này không chỉ giới hạn trong các tình huống cá nhân, trợ lý cá nhân chỉ là một loại ứng dụng; trong các tình huống thương mại như phát triển phần mềm, nó cũng rất có giá trị.

Tuy nhiên, thiết kế Agent hiện tại vẫn khó có thể hỗ trợ mô hình này ở quy mô đa nhiệm và hợp tác nhóm. Cách làm việc của Agent vẫn dựa trên phiên đơn lẻ làm đơn vị cơ bản, các phiên khác nhau hoàn toàn độc lập với nhau. Khi người dùng tiến hành nhiều công việc song song, họ phải chuyển đổi thủ công và nhớ bối cảnh của từng phiên, và theo quan sát của chúng tôi, một người thường chỉ có thể theo dõi từ 3 đến 5 phiên hoạt động cùng lúc. Trong thiết kế này, giới hạn của nhiệm vụ đơn lẻ phụ thuộc vào khả năng của mô hình, trong khi giới hạn của đa nhiệm phụ thuộc vào sự chú ý của con người.

Nếu chỉ mở rộng đơn giản trên Agent phiên đơn địa phương hiện có bằng CLI, MCP hoặc các kết nối bên ngoài, Agent mặc dù có thể kết nối với thông điệp bên ngoài, nhưng vẫn bị hạn chế bởi sự đồng bộ phiên đơn bị chặn, sự lộn xộn trong bối cảnh đa nhiệm, và việc thiết bị địa phương ngừng hoạt động khi ngoại tuyến, cần rất nhiều sự bảo trì thủ công.

Để vượt qua những hạn chế này, cần phải phá vỡ sự ràng buộc giữa Agent và phiên thủ công đơn lẻ, biến nó thành một thực thể liên tục có thể duy trì bối cảnh xuyên suốt các phiên, đồng thời tiến hành nhiều nhiệm vụ phức tạp mà không gây cản trở lẫn nhau. Chúng tôi gọi hình thức Agent này và kiến trúc hệ thống của nó là Super-agent.

Ví dụ, trong một ví dụ Super-agent chạy trên DeepSeek Harness của chúng tôi, cùng một nhiệm vụ phát triển có thể được tiến hành liên tục giữa IM và GitHub; ví dụ này cũng sẽ liên tục theo dõi phản hồi trong các cuộc trò chuyện nhóm công cộng, chủ động xác định nguyên nhân gốc rễ và gửi Pull Request sửa lỗi mà không cần ai @:

Cùng một nhiệm vụ được tiến hành liên tục giữa cuộc trò chuyện nhóm IM và đánh giá Pull Request trên GitHub

Liên tục theo dõi cuộc trò chuyện nhóm công cộng, chủ động xác định lỗi và gửi Pull Request sửa lỗi mà không cần ai @

Cụ thể, chúng tôi cho rằng Super-agent có bốn đặc điểm cơ bản sau:

• Liên tục: Người dùng có thể tương tác trực tiếp với nó trong các giao diện làm việc quen thuộc như trò chuyện IM, bình luận GitHub, cảm giác như chỉ có một Agent tồn tại, không cần phải nghĩ "Thông tin Y có trong bối cảnh phiên X không". Ví dụ, người dùng trước tiên đưa ra phương án A trên IM, sau đó trong bình luận Pull Request trên GitHub chuyển sang phương án B, nó có thể hiểu và điều chỉnh hướng thực hiện.

• Hiệu quả: Phản hồi tương tác nhanh chóng, đồng thời có thể hoàn thành nhiều nhiệm vụ phức tạp một cách song song và chất lượng cao. Không cần chờ lệnh hoặc nhiệm vụ trước đó hoàn thành, có thể nhận lệnh tiếp theo ngay lập tức.

• Chủ động: Không cần chờ người dùng ra lệnh từng lệnh một, có thể liên tục theo dõi các sự kiện môi trường và chủ động tiến hành các vấn đề cần xử lý, giữ im lặng khi không cần can thiệp.

• Bền vững: Luôn trực tuyến, kết nối trực tiếp với môi trường làm việc thực tế của người dùng, và tự động phục hồi khi gặp bất thường trong quá trình hoạt động lâu dài.

Một vòng ReAct đơn lẻ không thể hỗ trợ đồng thời bốn đặc điểm trên, cần một kiến trúc tương ứng ở cấp độ cơ sở. Các ràng buộc thiết kế tương tự sẽ dẫn đến các lựa chọn kiến trúc tương tự. Chúng tôi cho rằng, dù là trợ lý hướng tới cá nhân hay Agent hướng tới các tình huống thương mại như phát triển phần mềm, nếu mục tiêu là xây dựng một hệ thống luôn trực tuyến, phản hồi đồng thời các sự kiện môi trường, thì ở cấp độ cơ sở có thể sẽ áp dụng kiến trúc tương tự. Đồng thời, nhiều vấn đề mà quá trình này gặp phải có sự tương đồng cao với các vấn đề mà hệ thống máy tính truyền thống đã thảo luận lâu dài, vì vậy nhiều tư tưởng thiết kế cổ điển trong hệ thống máy tính cũng áp dụng ở đây.

Trong việc triển khai cụ thể, kiến trúc này sẽ có các biến thể khác nhau, nhưng chúng tôi cho rằng năm mô-đun sau đây cấu thành khung cơ bản hỗ trợ bốn đặc điểm cơ bản trên: thông qua kiến trúc hai lớp (Mục 2) để cân bằng tương tác liên tục và hiệu suất đồng thời, thông qua sự điều khiển dựa trên sự kiện (Mục 3) để đạt được phản hồi chủ động, thông qua tương tác hướng tới con người (Mục 4) để đồng thời đạt được tính liên tục và hiệu quả trong quá trình tương tác, và thông qua sự tách biệt giữa tính toán, trạng thái và môi trường (Mục 5) cùng với Watchdog (Mục 6) để đạt được tính liên tục và tự phục hồi bất thường giữa các thiết bị.

Hình dưới đây trình bày kiến trúc hệ thống tổng thể của Super-agent, các số hiệu trong hình từ [2] đến [6] tương ứng với các Mục 2 đến Mục 6 dưới đây:

Kiến trúc hệ thống tổng thể của Super-agent, số hiệu từ [2] đến [6] tương ứng với các Mục 2 đến Mục 6 dưới đây

2. Kiến Trúc Hai Lớp

Để đồng thời thực hiện tương tác liên tục xuyên kênh và hiệu suất đồng thời cho đa nhiệm, hệ thống ở cấp độ cơ sở phải đối mặt với sự đánh đổi cơ bản giữa tính liên tục và thông lượng (Trade-off).

Nếu mỗi sự kiện đều được giao cho cùng một phiên xử lý, mặc dù bối cảnh liên tục nhất, nhưng bị giới hạn bởi tốc độ tối đa của việc thực hiện tuần tự của một ReAct Loop, thời gian hoàn thành nhiệm vụ dài, thông lượng thấp, và các chi tiết giữa các nhiệm vụ đa nhiệm cũng sẽ ảnh hưởng đến hiệu quả hoàn thành.

Ngược lại, nếu mỗi sự kiện đều mở một phiên độc lập mới để xử lý, mặc dù thông lượng đồng thời cao nhất, nhưng một khi các nhiệm vụ không hoàn toàn độc lập, thiếu bối cảnh toàn cầu sẽ khiến kết quả của các phiên bị cắt rời nhau, đồng thời nhiều phiên phản hồi cho người dùng cũng sẽ gây ra sự lộn xộn trong tương tác.

Để cân bằng tính liên tục và thông lượng, chúng tôi có thể tách "duy trì tính liên tục toàn cầu" và "thực hiện đồng thời cao" thành hai cấp độ khác nhau: một lớp Router thường trực (Mục 2.1) tiếp nhận toàn bộ tương tác của con người và phối hợp toàn cầu, và một lớp Worker (Mục 2.2) cách ly bối cảnh để thực hiện các nhiệm vụ cụ thể đồng thời, như hình dưới đây:

Kiến trúc hai lớp: Lớp Router chịu trách nhiệm thống nhất về định tuyến và tương tác bên ngoài, nhiều phiên Worker cách ly thực hiện nhiệm vụ đồng thời

Thông qua kiến trúc hai lớp này, hệ thống đã tiếp quản việc quản lý bối cảnh và thực hiện đồng thời ở cấp độ cơ sở, từ đó làm mờ sự tồn tại của các phiên ở phía người dùng, khiến người dùng luôn đối mặt với cùng một Super-agent. Từ góc độ này, việc để người dùng quản lý phiên một cách thủ công, phần lớn là di sản của thiết kế từ API LLM ở cấp độ cơ sở; phiên nên là chi tiết thực hiện của hệ thống, chứ không phải gánh nặng nhận thức của người dùng.

Trong thiết kế hiện tại, phiên đồng thời đảm nhận cả việc quản lý bối cảnh về mặt kỹ thuật và quản lý dự án hướng tới người dùng. Sau khi tách rời hình thức sản phẩm và phiên ở cấp độ cơ sở, quản lý dự án hướng tới người dùng không còn bị giới hạn bởi phiên, việc tiết lộ cho người dùng cách tương tác và quản lý nhiệm vụ trở thành một vấn đề sản phẩm độc lập. Chúng tôi sẽ thảo luận về vấn đề này trong phần sau.

"Kiến trúc hai lớp" ở đây là sự phân chia trách nhiệm về mặt logic, mỗi lớp trong việc thực hiện không nhất thiết phải giới hạn ở một phiên đơn lẻ, mà có thể có cấu trúc nội bộ riêng. Dưới đây sẽ lần lượt giới thiệu thiết kế của lớp Router và lớp Worker.

2.1 Lớp Router

Lớp Router là lớp định tuyến toàn cầu thường trực, chịu trách nhiệm tiếp nhận tất cả các tương tác của con người từ các đầu vào. Tất cả thông tin và quyết định xuyên nhiệm vụ đều được tổng hợp tại lớp Router, nơi nó đóng vai trò như một điểm thứ tự toàn cầu (Sequence Point), điểm phối hợp và bộ nhớ. Để tránh điểm toàn cầu này trở thành nút thắt cổ chai về hiệu suất của hệ thống, lớp Router trong thiết kế không trực tiếp thực hiện các nhiệm vụ cụ thể, chỉ chịu trách nhiệm cho tương tác của con người và phân phối nhiệm vụ, thậm chí có thể không trang bị công cụ Bash.

Cấu trúc này, trong đó một nút trung tâm phân phối nhiều nút thực hiện, bề ngoài có vẻ tương tự như một Nhóm Agent thông thường, nhưng trọng tâm của hai bên khác nhau. Nhóm Agent thông thường chủ yếu được sử dụng để phân tách các bước và hợp tác vai trò trong một nhiệm vụ phức tạp đơn lẻ, do các bước con thường liên kết chặt chẽ, Team Lead thường cần hiểu sâu về chi tiết nhiệm vụ, lập kế hoạch cho các nhiệm vụ con và phối hợp các thành viên với tần suất cao, tự mình gánh vác một khối lượng suy luận nặng nề. Trong khi đó, trong Super-agent, lớp Router chỉ xử lý các mối liên hệ và phân phối cấp cao giữa các nhiệm vụ, không cần can thiệp vào việc phân tách nội bộ của nhiệm vụ đơn lẻ; ngược lại, nếu thông qua từ khóa ràng buộc một phiên chính của Nhóm Agent không tự thực hiện nhiệm vụ cụ thể, chỉ chịu trách nhiệm cho tương tác bên ngoài và phân phối các nhiệm vụ khác nhau cho các thành viên tiến hành độc lập, thì nó cũng có thể được coi là kiến trúc hai lớp này. Từ thực tiễn của chúng tôi, nhiệm vụ của lớp Router thường không phức tạp như tưởng tượng, sử dụng mô hình nhẹ hơn thường có thể cân bằng giữa tốc độ và hiệu quả.

Trong việc thực hiện nội bộ, lớp Router cũng không nhất thiết phải giới hạn ở một phiên đơn lẻ, thậm chí một số logic có thể không cần gọi LLM. Chúng tôi đã chọn một phiên LLM thường trực đơn lẻ trực tiếp làm thực hiện cốt lõi của lớp Router, và nhận thấy rằng nó không dễ dàng trở thành nút thắt cổ chai về thông lượng như bề ngoài, vì các sự kiện môi trường đến trong thời gian suy luận trước đó (tức là Trigger trong Mục 3) sẽ tích tụ lại, được xử lý cùng nhau trong vòng tiếp theo, tạo thành xử lý theo lô (Batching), và chi phí bổ sung cho việc xử lý gộp rất nhỏ:

• Khi dòng sự kiện bên ngoài ổn định, Trigger sẽ lần lượt vào phiên Router, lúc này độ trễ phản hồi một lần khá thấp;

• Khi các sự kiện dồn dập xuất hiện và Router Session bắt đầu gặp tắc nghẽn, nhiều Trigger bị tồn đọng trong vòng suy diễn trước đó sẽ tự động được hợp nhất và được tiêm vào trong lần gọi LLM tiếp theo. Router Session chỉ thực hiện các tương tác và phân phối nhẹ, mỗi bước thường là đầu vào dài, đầu ra ngắn. Việc hợp nhất nhiều Trigger bị tồn đọng vào một lần gọi API LLM sẽ được tính toán song song trong giai đoạn Prefill, thời gian tăng lên cho mỗi yêu cầu đơn lẻ chậm hơn nhiều so với kích thước lô. Do đó, trong một phạm vi nhất định, càng nhiều tồn đọng, thời gian suy diễn phân bổ cho mỗi quyết định càng thấp; giới hạn phụ thuộc vào độ dài ngữ cảnh và số lượng Trigger mà mô hình có thể xử lý chính xác trong một vòng.

Chúng tôi sẽ trình bày định lượng hiệu quả của cơ chế xử lý lô này thông qua thí nghiệm trong phần 7.2. Cùng với các cơ chế đăng ký và thông qua mà sẽ được giới thiệu sau đây cũng như hồi tưởng chuỗi (xem phần 3.2, 3.3), một Router Session thường trú đơn lẻ đã đủ dùng trong quy mô đội ngũ hiện tại của chúng tôi trong khi vẫn duy trì tính liên tục của ngữ cảnh.

Khi quy mô tiếp tục mở rộng và một phiên đơn lẻ thực sự không đủ để chịu tải, lớp Router cũng có thể được thiết kế thành cấu trúc lọc nhiều lớp, hoặc phân chia theo chiều ngang (Sharding) thành nhiều phiên. Lúc này, thiết kế nội bộ của lớp Router về cơ bản là sự cân bằng giữa tính liên tục và thông lượng. Độ phân chia càng nhỏ, thông lượng đồng thời của lớp Router càng cao, nhưng trí nhớ và tính liên tục của ngữ cảnh giữa các phân đoạn sẽ càng thấp. Trước khi vấn đề trí nhớ toàn cầu được giải quyết, sự cân bằng này luôn tồn tại.

2.2 Lớp Worker

Lớp Worker bao gồm các phiên chịu trách nhiệm thực hiện cụ thể, mỗi Worker đều được cách ly ngữ cảnh với nhau, gắn kết đầy đủ công cụ thực hiện, tập trung hoàn thành một nhiệm vụ duy nhất trong ngữ cảnh độc lập. Do Worker Session trực tiếp quyết định kết quả nhiệm vụ và chất lượng mã, thường cần cấu hình mô hình mạnh nhất.

Worker sẽ không tương tác trực tiếp với con người, quá trình suy diễn và gọi công cụ của nó sẽ không được xuất ra kênh bên ngoài mà sẽ báo cáo trạng thái cho lớp Router, lớp Router sẽ thống nhất phản hồi cho người dùng, từ đó đảm bảo độ đồng thời và chất lượng giao hàng trong khi tránh sự hỗn loạn do nhiều phiên tự phản hồi.

Trong khi thực hiện nhiều nhiệm vụ đồng thời, các Worker độc lập thúc đẩy nhiệm vụ, các Worker cùng lớp thường cũng không cần giao tiếp trực tiếp. Nhiều Worker trong quá trình thực hiện cụ thể thường xảy ra xung đột trong cùng một Pull Request hoặc môi trường làm việc chia sẻ; chỉ cần chúng đều đăng ký Thread tương ứng, chúng sẽ nhận được thông báo sự kiện giống nhau (xem phần 3.2), từ đó có cơ hội tự phát hiện và giải quyết xung đột, một số phối hợp giữa các nhiệm vụ sẽ được chuyển tiếp bởi lớp Router.

Tương tự như lớp Router, mỗi Worker Session cũng không nhất thiết phải giới hạn trong một phiên đơn lẻ: trong khi thực hiện nhiệm vụ đơn phức tạp, Worker có thể tạo ra Subagent bên trong, hoặc có thể tự nó là một Nhóm Agent, những điều này vẫn giữ nguyên tính minh bạch với lớp Router phía trên. Cấu trúc này phù hợp với các tình huống hợp tác mã (tiến hành nhiều vấn đề độc lập, đánh giá Pull Request và phát triển tính năng mà không bị chặn), cũng như các tình huống trợ lý cá nhân: mặc dù trợ lý cá nhân thường chỉ cung cấp một trang trò chuyện phiên đơn trên giao diện, nhưng khi người dùng thảo luận nhiều chủ đề khác nhau trong cùng một hộp thoại, trang trò chuyện đơn lẻ phía trước sẽ chịu trách nhiệm duy trì tính liên tục của tương tác, trong khi lớp dưới có thể phân công Worker cho mỗi chủ đề, thúc đẩy nhiệm vụ và soạn thảo phản hồi song song.

3. Động lực sự kiện

Để Super-agent có tính chủ động, trước tiên cần thay đổi cách thức điều khiển hệ thống. Đầu vào chính điều khiển Agent không còn là các từ gợi ý mà con người nhập từng dòng trong phiên, mà là các sự kiện bán cấu trúc phát sinh từ môi trường. Trong Super-agent, tin nhắn nhóm, email và nhắc nhở lịch trình, bình luận đánh giá mã, kết quả chạy CI và các sự kiện môi trường khác được gọi là Trigger. Bằng cách lắng nghe và phản hồi Trigger, Agent không còn phải chờ con người ra lệnh để thực hiện một lần như trong chế độ phiên đơn.

Xung quanh vòng đời của một sự kiện môi trường từ khi vào đến khi xử lý, dưới đây sẽ lần lượt thảo luận bốn vấn đề tiến triển: làm thế nào để lọc bỏ lượng tiếng ồn lớn thông qua sự kết hợp giữa chương trình và mô hình (phần 3.1), làm thế nào để định tuyến sự kiện đến Worker thông qua cơ chế đăng ký và thông qua (phần 3.2), làm thế nào để sử dụng Inline & Spill và hồi tưởng chuỗi để tiêm vào mô hình ngữ cảnh với mật độ cao và hồi tưởng theo nhu cầu (phần 3.3), và làm thế nào để sử dụng thực thi suy đoán để hành động trước theo tín hiệu môi trường (phần 3.4).

3.1 Lọc sự kiện

Sau khi kết nối với các nhóm trò chuyện thực tế và nền tảng mã, dòng sự kiện môi trường thể hiện đặc điểm rõ rệt của "tiếng ồn cao, tỷ lệ kích hoạt thấp", hầu hết các tin nhắn hàng ngày không cần sự can thiệp của Agent. Nếu gọi mô hình lớn để đánh giá từng sự kiện, độ trễ và chi phí tính toán sẽ khó có thể chấp nhận. Dựa trên tư tưởng Fast Path / Slow Path trong hệ thống máy tính, suy diễn mô hình lớn có thể được coi là một Slow Path linh hoạt nhưng tốn kém, trong khi việc cố định các đánh giá tần suất cao đã rõ ràng và ổn định thành mã xác định sẽ tạo thành Fast Path với độ trễ thấp và chi phí thấp.

Do đó, bước đầu tiên khi sự kiện vào hệ thống là lọc, mục tiêu là sử dụng chiến lược xác định để loại bỏ tiếng ồn trước khi gọi mô hình lớn, chỉ đưa các sự kiện ứng cử cần hiểu ngữ nghĩa cho mô hình đánh giá. Chúng tôi áp dụng cơ chế lọc hai cấp kết hợp giữa chiến lược chương trình và mô hình lớn:

• Chiến lược cấp chương trình (như Fast Path): Đối với nguồn sự kiện, phạm vi nhóm, danh sách trắng người dùng hoặc robot và các điều kiện xác định khác, thực hiện kiểm tra nhanh qua mã, chẳng hạn như thiết lập "chỉ phản hồi yêu cầu rõ ràng", "như sự kiện ứng cử" hoặc "bỏ qua trực tiếp" cho các nguồn khác nhau, nhằm lọc bỏ hầu hết các tin nhắn không liên quan trước khi gọi mô hình.

• Chiến lược cấp ngữ nghĩa (như Slow Path): Các sự kiện ứng cử đã được chấp thuận qua cấp chương trình sẽ được chuyển cho LLM, nó sẽ đánh giá xem có cần hành động hay không dựa trên chiến lược được viết bằng từ gợi ý và ngữ cảnh. Cấp ngữ nghĩa cũng đồng thời là điểm mở rộng ngôn ngữ tự nhiên hướng đến con người, thuận tiện cho việc bật tắt hoặc thêm chiến lược mới bất cứ lúc nào thông qua từ gợi ý, như hình dưới đây:

Lọc hai cấp: trước tiên lọc hầu hết các tin nhắn không liên quan qua chiến lược cấp chương trình, sau đó để chiến lược cấp ngữ nghĩa đánh giá

3.2 Định tuyến sự kiện

Lớp Router toàn cầu được giới thiệu trong phần 2 chịu trách nhiệm duy trì tính liên tục giữa các kênh, nhưng nếu mỗi sự kiện tiếp theo đã được phân công nhiệm vụ vẫn cần được chuyển tiếp qua lớp Router, nút toàn cầu này vẫn sẽ chịu tải lớn, làm tăng độ trễ phản hồi của hệ thống. Do đó, Fast / Slow Path cũng áp dụng cho định tuyến sự kiện đã được lọc. Lớp Router toàn cầu chỉ chịu trách nhiệm khởi động lạnh cho nhiệm vụ mới và phối hợp giữa các nhiệm vụ, trong khi các sự kiện tiếp theo đã xác định mối quan hệ thuộc về sẽ được gửi trực tiếp đến phiên Worker tương ứng mà không cần chuyển tiếp qua lớp Router.

Trong quy trình làm việc thực tế, các sự kiện liên tiếp trong cùng một Pull Request GitHub, cùng một chủ đề IM hoặc cùng một chuỗi email sẽ tạo thành một dòng sự kiện, tức là Thread:

Ví dụ về Thread: Các Trigger liên tiếp trong cùng một chủ đề IM hoặc cùng một Pull Request GitHub tạo thành một Thread

Sau khi lớp Router tạo Worker Session dựa trên sự kiện ban đầu của một Thread nào đó, Worker đó sẽ trực tiếp đăng ký Thread tương ứng, từ đó định tuyến sự kiện chia thành hai con đường như hình dưới đây:

• Đã đăng ký (Fast Path): Các sự kiện tiếp theo trong cùng một Thread sẽ được chương trình gửi thẳng đến Worker đã đăng ký, không cần lớp Router gọi công cụ để chuyển tiếp một lần nữa. Nếu sự kiện mới vượt quá phạm vi nhiệm vụ hiện tại, Worker cũng có thể hủy đăng ký hoặc trả lại cho lớp Router để phân công lại.

• Chưa đăng ký (Slow Path): Lớp Router vẫn có thể quan sát tất cả các sự kiện để nắm bắt trạng thái toàn cầu, nhưng chỉ chịu trách nhiệm đánh giá và phân công các sự kiện mới chưa được đăng ký.

Đăng ký và thông qua: Sự kiện ban đầu được lớp Router tạo Worker và thiết lập đăng ký, các sự kiện tiếp theo trong cùng một Thread được gửi trực tiếp đến Worker đó

Ngoài ra, mối quan hệ đăng ký giữa Thread và Worker là mối quan hệ nhiều-mối. Một Worker có thể đồng thời đăng ký nhiều Thread liên quan, và một Thread cũng có thể được nhiều Worker đăng ký. Khi nhiều Worker xảy ra giao thoa trong cùng một môi trường làm việc hoặc thảo luận, các sự kiện mới dưới Thread đó sẽ được gửi thẳng đến tất cả các Worker đã đăng ký, giúp chúng không cần giao tiếp điểm-điểm và có cơ hội biết được hoạt động của nhau và tự giải quyết xung đột. Trong khi ở phía đầu ra, Worker vẫn sẽ báo cáo các kết luận quan trọng cho lớp Router, lớp Router sẽ thống nhất phản hồi cho người dùng và đồng bộ trí nhớ toàn cầu.

3.3 Tổ chức ngữ cảnh

Khi các sự kiện đã qua lọc và định tuyến, vào phiên mục tiêu, câu hỏi tiếp theo là nên tiêm bao nhiêu thông tin vào cửa sổ ngữ cảnh của mô hình. Do đầu vào của hệ thống chuyển từ các từ gợi ý hạn chế của con người sang các sự kiện bán cấu trúc phát sinh liên tục từ môi trường, thiết kế cấu trúc gọi công cụ và tiêm sự kiện trở nên quan trọng hơn. Tiêm quá nhiều sẽ chiếm dụng cửa sổ, làm loãng sự chú ý của mô hình, trong khi tiêm quá ít sẽ buộc mô hình phải gọi công cụ nhiều lần để đọc, tăng số bước thực hiện. Lãng phí cửa sổ ngữ cảnh là lãng phí trí thông minh của mô hình.

Vì vậy, chúng tôi có thể quản lý cửa sổ ngữ cảnh hạn chế như một Cache. Dựa trên khái niệm tối ưu hóa biên dịch và hệ thống máy tính, thiết kế tiêm ngữ cảnh có thể được tóm tắt thành hai thao tác cơ bản. Inline có nghĩa là tiêm trực tiếp thông tin có khả năng được sử dụng trong thời gian gần vào cửa sổ ngữ cảnh hiện tại, nhằm tiết kiệm việc gọi công cụ đi lại thêm. Spill có nghĩa là giữ lại thông tin đầy đủ vượt quá ngân sách cửa sổ hoặc sử dụng ít tần suất bên ngoài cửa sổ ngữ cảnh, chỉ giữ lại tham chiếu hoặc tóm tắt trong cửa sổ, để mô hình đọc theo nhu cầu.

Kết hợp với tư tưởng địa phương hóa (Locality) cổ điển trong thiết kế hệ thống máy tính, chúng tôi có thể dần tối ưu hóa việc tiêm sự kiện và gọi công cụ bằng Inline & Spill:

1. Bắt đầu từ thông tin tối thiểu: ban đầu chỉ cung cấp ID và tóm tắt nội dung của đối tượng hiện tại.

2. Dần dần Inline thông tin liên quan thông qua địa phương hóa: tiêm thông tin có khả năng được sử dụng trong thời gian gần vào ngữ cảnh, trước tiên đính kèm ID của đối tượng liên quan chặt chẽ, sau đó kèm theo nội dung không gian và thời gian gần nhau, chẳng hạn như 50 ký tự đầu tiên của nội dung, các tin nhắn IM liền kề và tin nhắn được phản hồi, hoặc các bình luận trong cuộc thảo luận đánh giá mã mà bình luận đang ở đó.

3. Vượt quá giới hạn thì Spill: Đối với nội dung dài không thể hoàn toàn Inline, thiết lập giới hạn chiều dài nhỏ hơn, phần vượt quá sẽ Spill ra ngoài cửa sổ. Một cách đơn giản và trực tiếp là cắt ngắn phần vượt quá và giữ lại điểm truy cập để tiếp tục đọc, mô hình sẽ gọi công cụ để đọc khi cần nội dung đầy đủ.

Ngoài ra, khi có nhiều sự kiện tiếp theo trực tiếp đến Worker, và hệ thống đã tích lũy nhiều nhiệm vụ lịch sử trong quá trình hoạt động lâu dài, lớp Router vừa không thể đưa toàn bộ lịch sử nhiệm vụ vào cửa sổ ngữ cảnh của mình, vừa cần tìm lại ngữ cảnh khi người dùng nhắc đến một nhiệm vụ cũ qua các kênh khác nhau. Khi áp dụng nhất quán Inline & Spill cho các loại đối tượng trong hệ thống, ta có được một cơ chế truy xuất nhiều bước theo nhu cầu, tức là chuỗi hồi tưởng (Chain of Recall). Quá trình hồi tưởng chuỗi này giảm thiểu vấn đề mất thông tin trước đó của lớp Router trong quá trình dài, như hình dưới đây:

Hồi tưởng chuỗi: Mỗi đối tượng được hồi tưởng đều nội tuyến ID của đối tượng liên quan tiếp theo, hỗ trợ mở rộng ngữ cảnh theo từng bước theo mối quan hệ tham chiếu

Cụ thể, hệ thống gán ID duy nhất cho các đối tượng như Trigger, Thread và Worker Session, và khi tiêm vào, nội tuyến ID của các đối tượng liên quan chặt chẽ, khiến các đối tượng này tạo thành một đồ thị tham chiếu ở cấp độ cơ sở. Bởi vì mỗi lần gọi công cụ để hồi tưởng đối tượng cũng tuân theo Inline & Spill, kết quả trả về sẽ nội tuyến tóm tắt và ID của đối tượng liên quan tiếp theo, mô hình có thể bắt đầu từ sự kiện hiện tại, lần lượt hồi tưởng ngữ cảnh theo nhu cầu theo mối quan hệ tham chiếu.

Ví dụ, từ một tin nhắn hiện tại đọc Thread mà nó thuộc về, sau đó từ ID nội tuyến của Thread theo dõi đến Worker Session liên quan, và tìm thấy một Thread đánh giá mã khác liên quan đến Worker đó.

3.4 Hành động trước

Lấy cảm hứng từ ý tưởng thực thi suy đoán (Speculative Execution) trong hệ thống máy tính, Agent có thể thử nghiệm trước trong nền tảng khi chưa chắc chắn kết quả có được chấp nhận hay không, dựa trên tín hiệu môi trường, bằng cách tiêu tốn thêm sức mạnh tính toán nền để giảm thiểu thời gian chờ đợi và chi phí can thiệp của con người. Kết quả có giá trị sẽ được giao nộp, không có giá trị sẽ bị loại bỏ.

Trong bối cảnh trợ lý cá nhân, khi nhận được một email mời họp hoặc thông báo công việc, Agent có thể kiểm tra xung đột lịch trình, thu thập tài liệu liên quan và chuẩn bị bản nháp phản hồi trong nền tảng, sau khi người dùng xem xét có thể xác nhận gửi ngay. Trong bối cảnh hợp tác phát triển cũng tương tự, ví dụ, chúng tôi đã cấu hình một chiến lược "Tái hiện và sửa chữa im lặng" trong nhóm người dùng nội bộ của công ty DeepSeek Harness: Khi có ai đó phản hồi vấn đề hoặc thảo luận về kế hoạch thay đổi trong nhóm, Agent sẽ thử nghiệm và tìm kiếm giải pháp sửa chữa trong nền tảng, chỉ khi xác nhận vấn đề và tìm thấy giải pháp sửa chữa đơn giản, mới giao nộp kết quả cho người dùng, nếu không sẽ giữ im lặng suốt quá trình.

Ví dụ về thực thi suy đoán: Khi nhóm vẫn đang thảo luận về giải pháp, Super-agent đã gửi Pull Request sửa chữa trong nền tảng

4. Tương tác hướng tới con người

Kiến trúc hai lớp ở phần 2 đảm bảo tính liên tục giữa các kênh, nhưng để đạt được cả tính liên tục và hiệu quả trong trải nghiệm tương tác giữa người và máy, cần giải quyết hai vấn đề về cách thức tương tác và kênh tương tác: một là làm thế nào để loại bỏ các thao tác tốn thời gian trong nền tảng khỏi việc chặn cuộc hội thoại thông qua vòng lặp ReAct bất đồng bộ, cho phép cuộc hội thoại không cần chờ lệnh hoặc nhiệm vụ trước đó hoàn thành mà có thể nhận lệnh mới bất cứ lúc nào (phần 4.1); hai là khi tương tác diễn ra trên các kênh làm việc khác nhau mà người dùng quen thuộc, làm thế nào để cách thức đầu ra của hệ thống phù hợp với băng thông của kênh tương ứng và thói quen sử dụng của con người (phần 4.2).

4.1 Tương tác song công

Trong vòng lặp ReAct cổ điển, sau khi mô hình khởi động một lần gọi công cụ đồng bộ run (), vòng lặp sẽ bị chặn lại cho đến khi công cụ hoàn thành và trả về kết quả cuối cùng, trong thời gian này cuộc hội thoại không thể phản hồi bất kỳ đầu vào mới nào từ người dùng. Để loại bỏ sự chặn này, cần chuyển cuộc hội thoại từ chế độ bán song công hỏi đáp sang chế độ song công hoàn toàn, như hình dưới đây:

So sánh vòng lặp ReAct cổ điển và vòng lặp ReAct bất đồng bộ: Gọi bất đồng bộ ngay lập tức trả về thông báo Bắt đầu, trong khi công cụ chạy ở nền vẫn có thể phản hồi tin nhắn mới

Để làm điều này, chúng tôi đã chuyển các lệnh tốn thời gian và gọi công cụ nhiệm vụ con thành start () và stop () bất đồng bộ, tạo thành vòng lặp ReAct bất đồng bộ. Sau khi mô hình gọi start (), ngay lập tức nhận được phản hồi "Đã bắt đầu (Started)", vòng lặp không còn chờ đợi công cụ đó; khi công cụ ở nền hoàn thành, hệ thống sẽ gửi kết quả cuối cùng như một tin nhắn sự kiện mới vào cuộc hội thoại; đồng thời, mô hình cũng có thể gọi stop () để chủ động kết thúc các lệnh nền có thời gian thực thi quá dài.

Do đó, phản hồi cuộc hội thoại ở phía trước và thực thi nhiệm vụ ở nền được tách rời, Agent có thể phản hồi đầu vào của con người trong khi vẫn chạy các nhiệm vụ tốn thời gian ở nền. Đầu vào mới sẽ được xử lý ngay sau khi bước suy diễn hiện tại kết thúc, không cần chờ công cụ ở nền hoàn thành.

Cơ chế nhiệm vụ bất đồng bộ này đã được triển khai trong DeepSeek Harness, nhưng chưa được bật mặc định.

4.2 Tương tác đa kênh

Các kênh làm việc khác nhau có mật độ thông tin và thói quen tương tác khác nhau, đầu ra của hệ thống cần phải phù hợp với điều đó. Nếu mang cách tương tác hướng tới một người dùng đơn lẻ vào nhóm trò chuyện, xuất ra nguyên văn quá trình suy diễn dài dòng và các cuộc gọi công cụ dày đặc, sẽ dễ dàng gây quá tải thông tin trong hợp tác nhiều người.

Trong Super-agent, kiến trúc hai lớp đã giải quyết một phần vấn đề: quá trình suy diễn dài dòng và các cuộc gọi công cụ dày đặc trong nhiệm vụ cụ thể đều được cách ly trong Worker Session, không được xuất ra trực tiếp vào kênh bên ngoài, mà do lớp Router chịu trách nhiệm tương tác bên ngoài. Trên cơ sở đó, hệ thống còn cần kết nối với các môi trường làm việc mà người dùng thường xuyên sử dụng, và thông qua các từ khóa tùy chỉnh quy tắc tương tác cho các kênh khác nhau:

• Kênh nhắn tin tức thời như IM: Tập trung vào giao tiếp nhẹ nhàng ít làm phiền, giống như đồng nghiệp con người chỉ gửi thông báo khi cần quyết định hoặc xác nhận, chỉ hỏi các câu hỏi trực tiếp, đưa ra kết luận ngắn gọn. Một quy định cứng mà chúng tôi đã xác minh là mỗi phản hồi không vượt quá 100 từ.

• Kênh bất đồng bộ như GitHub, email và tài liệu: Tập trung vào việc giao hàng bất đồng bộ có cấu trúc và mật độ thông tin cao, chẳng hạn như khi tạo hoặc cập nhật Pull Request, viết đầy đủ bối cảnh vấn đề, mô tả thay đổi và kết quả xác minh theo quy định của dự án, hoặc trong bối cảnh trợ lý cá nhân, trực tiếp soạn thảo tóm tắt tài liệu và email có cấu trúc.

5. Tách biệt tính toán, trạng thái và môi trường

Agent hiện tại mặc định gắn kết tính toán thúc đẩy vòng lặp Agent, trạng thái cuộc hội thoại cần được lưu trữ lâu dài, cũng như kho mã và chuỗi công cụ địa phương trên cùng một thiết bị. Một khi thiết bị ngủ hoặc ngoại tuyến, Agent sẽ ngừng hoạt động và không thể truy cập môi trường trên các thiết bị khác. Để Super-agent có thể duy trì kết nối và linh hoạt truy cập các môi trường làm việc thực tế, chúng tôi có thể tham khảo ý tưởng tách biệt tính toán và lưu trữ (Compute-Storage Separation) trong hệ thống máy tính, tách rời ba yếu tố này theo hai bước: bước đầu tiên là tách biệt tính toán thúc đẩy vòng lặp Agent với trạng thái cuộc hội thoại cần lưu trữ lâu dài, giúp Agent thoát khỏi giới hạn vòng đời của một máy đơn, đạt được kết nối lâu dài trên đám mây (phần 5.1); bước thứ hai là tách biệt vòng lặp Agent trên đám mây với môi trường thực thi có trạng thái nặng, để môi trường làm việc thực tế ở lại chỗ cũ và hỗ trợ truy cập giữa các thiết bị (phần 5.2).

5.1 Tách biệt tính toán và trạng thái

Tính toán thúc đẩy vòng lặp Agent có thể được thực hiện mà không có trạng thái, trạng thái cuộc hội thoại cần được lưu trữ lâu dài. Do đó, bước tách biệt đầu tiên là đưa tính toán thúc đẩy vòng lặp Agent vào trong một container tính toán đàn hồi không có trạng thái trên đám mây, trong khi lưu trữ trạng thái lâu dài như Session vào cơ sở dữ liệu. Container tính toán không có trạng thái có thể mở rộng theo chiều ngang, khởi động lại hoặc thay thế, trong khi tính liên tục của cuộc hội thoại và nhiệm vụ được đảm bảo bởi lưu trữ lâu dài, từ đó giúp Agent thoát khỏi giới hạn vòng đời của một thiết bị địa phương, đạt được kết nối lâu dài trên đám mây.

5.2 Tách biệt tính toán và môi trường thực thi

Khi vòng lặp Agent và trạng thái cuộc hội thoại thường trú trên đám mây, vấn đề tiếp theo là làm thế nào để truy cập môi trường thực thi cần thiết cho nhiệm vụ. Một phần lớn ngữ cảnh mà mô hình làm việc cần phải được lấy từ kho mã, tệp địa phương, dịch vụ phụ thuộc và các môi trường thực thi khác thông qua các cuộc gọi công cụ, từ góc độ này, ngữ cảnh rộng cũng bao gồm chính môi trường thực thi.

Xung quanh vấn đề này, có hai hướng suy nghĩ phổ biến: một là khởi động sandbox trên đám mây, kéo mã và cố gắng tái tạo và đồng bộ hóa môi trường, nhưng do môi trường làm việc thực tế thường chứa các thay đổi địa phương chưa được cam kết, thông tin xác thực riêng tư, dịch vụ nội bộ phụ thuộc và phần cứng hoặc chuỗi công cụ cụ thể, về mặt kỹ thuật, việc đồng bộ hóa môi trường như vậy không chỉ tốn kém mà còn dễ dẫn đến thiếu sót thông tin; hướng còn lại là yêu cầu người dùng từ bỏ môi trường địa phương và chuyển sang làm việc trên đám mây, nhưng đối với nhiều người dùng, chi phí chuyển đổi quá cao.

Vì khó khăn trong việc sao chép và đồng bộ hóa là chính môi trường, không cần phải để môi trường thực thi theo vòng lặp Agent lên đám mây. Bước tách biệt thứ hai là để vòng lặp Agent chạy trên đám mây, trong khi để môi trường thực thi có trạng thái nặng ở lại chỗ cũ, chỉ cần triển khai một daemon nhẹ không lưu trữ trạng thái cuộc hội thoại ở phía đầu, nó chỉ chịu trách nhiệm thực thi lệnh và trả về kết quả, tương đương với việc giữ môi trường thực thi bên ngoài đám mây, để Agent đọc ngữ cảnh bên trong theo nhu cầu.

Hướng đi này nhất quán với ý tưởng "tách biệt não khỏi tay" (Decoupling the brain from the hands) mà Anthropic đã đề xuất, cũng giữ cho harness không có trạng thái, lưu trữ nhật ký cuộc hội thoại bên ngoài harness, và thông qua giao diện thống nhất để truy cập môi trường thực thi theo nhu cầu. Sự khác biệt giữa hai bên là bối cảnh. Bài viết đó mô tả dịch vụ được quản lý, chủ yếu thảo luận về sandbox được tạo theo nhu cầu và tài nguyên trong VPC của khách hàng; ở đây, điều đầu tiên cần kết nối là máy cá nhân mà người dùng thường xuyên sử dụng, có thể trực tuyến không liên tục, với các thay đổi chưa được cam kết và thông tin xác thực địa phương. Do đó, thiết kế này không chỉ hỗ trợ BYOM (Bring Your Own Machine), tức là kết nối máy phát triển hoặc máy tính cá nhân mà người dùng thường xuyên sử dụng với Agent trên đám mây, mà còn hỗ trợ kết nối với máy chủ được quản lý trên đám mây hoặc môi trường tính toán được tạo theo nhu cầu.

Do đó, một Agent không còn bị giới hạn bởi một máy đơn, mà có thể chuyển đổi giữa các thiết bị thực thi khác nhau, chọn môi trường để thực thi lệnh và lấy ngữ cảnh trong môi trường theo nhu cầu. Nó thậm chí có thể hỗ trợ các thiết bị trực tuyến không liên tục, chẳng hạn như sau khi một thiết bị cá nhân của người dùng trực tuyến trở lại, Agent trên đám mây sẽ tự động kích hoạt và hoàn thành các nhiệm vụ cần thực hiện trên thiết bị đó. Hình dưới đây cho thấy cấu trúc sau khi tách biệt tính toán, trạng thái lâu dài và các môi trường thực thi khác nhau thành hai lớp:

Tách biệt lưu trữ và tính toán với môi trường thực thi: Vòng lặp Agent và trạng thái bền vững được tách biệt trên đám mây, và thông qua daemon ở đầu cuối để kết nối các môi trường thực thi theo nhu cầu

6. Giám sát

Để đạt được trạng thái trực tuyến liên tục, ngoài việc tách biệt lưu trữ và tính toán ở phần 5, hệ thống cũng cần có khả năng tự phục hồi từ các bất thường trong quá trình hoạt động lâu dài. Hệ thống phân tán trực tuyến rất khó chỉ dựa vào logic nội bộ của hệ thống chính để đảm bảo hoạt động đáng tin cậy lâu dài, cần phải đưa vào một vòng điều khiển bên ngoài độc lập, tức là Vòng điều khiển (Control Loop).

Đồng thời, trong hệ thống Agent, chỉ dựa vào việc phát hiện sự sống của tiến trình truyền thống hoặc các kịch bản giám sát là không đủ, vì nhiều bất thường không phải do tiến trình bị sập, mà là mô hình bị mắc kẹt trong vòng lặp không hiệu quả hoặc lệch khỏi mục tiêu. Do đó, hệ thống Agent hoạt động lâu dài không chỉ cần giám sát sự sống của cơ sở hạ tầng mà còn cần giám sát tiến trình của chính nhiệm vụ.

Chúng tôi đã cấu hình một Phiên Giám sát (Watchdog Session) độc lập bên ngoài hệ thống chính, được điều khiển bởi các thông điệp định kỳ, tạo thành Vòng điều khiển bên ngoài. Ngoài việc xử lý lỗi giao diện, phục hồi trạng thái thất bại và các sự cố cơ sở hạ tầng khác, Giám sát còn đánh giá xem từng Worker có tiến triển thực sự hay không, và hướng đi có lệch khỏi mục tiêu tổng thể hay không. Khi phát hiện bất thường, Giám sát sẽ can thiệp kịp thời để sửa chữa, và khi gặp sự cố ngẫu nhiên bên ngoài sẽ tiếp tục kiểm tra cho đến khi phục hồi bình thường.

Vì Giám sát cũng là một Phiên Agent có đầy đủ khả năng công cụ, người bảo trì có thể hỏi nó về nguyên nhân sự cố bằng ngôn ngữ tự nhiên, và cũng có thể yêu cầu nó sửa đổi hành vi của hệ thống chính trực tuyến, chẳng hạn như thêm hoặc xóa từ gợi ý, điều chỉnh quy tắc kích hoạt.

7. Thí nghiệm sơ bộ

Để đánh giá thiết kế lập lịch và định tuyến cốt lõi đã nêu ở trên, chúng tôi đã thực hiện thí nghiệm sơ bộ từ hai khía cạnh: đầu tiên là so sánh giữa kiến trúc hai lớp, kết nối trực tiếp và giải pháp một phiên (7.1), sau đó là kiểm tra riêng lẻ lớp Router với xử lý theo lô (7.2). Do thí nghiệm dựa trên tải tổng hợp và môi trường đơn giản hóa, một số cài đặt có thể được thực hiện nghiêm ngặt hơn, kết quả dưới đây chỉ mang tính tham khảo sơ bộ.

7.1 Thí nghiệm loại bỏ

Chúng tôi đã sử dụng nhóm trò chuyện và luồng thông điệp GitHub CI để đồng thời điều khiển bốn giải pháp đầu cuối: mỗi thí nghiệm bao gồm khoảng 300 thông điệp, trong đó khoảng 20 thông điệp là yêu cầu công việc, phần còn lại là trò chuyện, theo dõi, dừng lại và thông điệp CI. Công việc lập trình được thay thế bằng một công cụ chỉ tiêu tốn thời gian, do đó thí nghiệm đo lường khả năng lập lịch và hợp tác của hệ thống, chứ không phải khả năng thực thi của một nhiệm vụ đơn lẻ. Mỗi giải pháp được chạy lặp lại 5 lần.

Bốn giải pháp so sánh bao gồm Super-agent, Super-agent không có kết nối trực tiếp, và hai cấu hình từ gợi ý dưới dạng một phiên + công cụ Subagent.

Trong đó, gợi ý trung lập được viết là "Sử dụng một subagent cho một công việc khi thích hợp…"

Gợi ý ưu tiên phân công được viết là "Mỗi thông điệp của cuộc trò chuyện đều đến với bạn, vì vậy công việc bạn tự thực hiện liên tục bị dừng lại để nhận thông điệp mới. Hãy ưu tiên giao mỗi công việc cho một subagent của riêng nó, và chỉ làm những việc nhỏ một mình…"

Đường cong tích lũy yêu cầu công việc và đường cong hoàn thành tích lũy của bốn giải pháp (trung bình 5 lần chạy thí nghiệm; khoảng cách giữa các thông điệp và thời gian làm việc được thu nhỏ theo tỷ lệ 1/4, thời gian gọi mô hình là giá trị thực)

Mỗi giải pháp được chạy lặp lại 5 lần; thời gian hoàn thành nhiệm vụ chỉ thời gian từ yêu cầu công việc đến thông điệp kết quả.

Xét về thời gian hoàn thành nhiệm vụ, p50 và p95 của Super-agent lần lượt là 12,4 phút và 15,7 phút, vượt trội hơn hẳn so với phiên đơn có công cụ Subagent. Nguyên nhân là do phiên đơn có Subagent bị ảnh hưởng lớn bởi gợi ý trong bối cảnh thí nghiệm, phiên chính thường quyết định tự thực hiện nhiệm vụ, dẫn đến tổng thời gian hoàn thành dài và hiệu suất không ổn định. Dưới gợi ý trung lập, mô hình không gọi Subagent trong 5 lần chạy, tất cả công việc đều được thực hiện trong phiên chính và liên tục bị thông điệp mới làm gián đoạn, p95 đạt 29,5 phút; khi chuyển sang gợi ý ưu tiên phân công, mô hình đã thực hiện phân công trong 4 lần chạy, thời gian hoàn thành có giảm nhưng tổng thể vẫn chậm hơn Super-agent, và trong 1 lần còn lại, nó đánh giá công việc "rất nhỏ" và chọn tự thực hiện, tạo ra đuôi dài màu tím trong biểu đồ. So với việc phụ thuộc vào kỹ thuật gợi ý và đánh giá tình huống trong phiên đơn, kiến trúc hai lớp đã giảm thiểu vấn đề này bằng cách không để Router thực hiện công việc cụ thể, Worker chỉ nhận thông điệp từ các Thread đã đăng ký.

Xét về chi phí hệ thống, do duy trì nhiều phiên độc lập, số token bộ nhớ đọc trong thí nghiệm của Super-agent cao hơn phiên đơn, đổi lại là tiêu tốn nhiều token hơn để có thời gian hoàn thành ngắn và ổn định hơn. Khi loại bỏ cơ chế kết nối trực tiếp bên trong Super-agent, thời gian hoàn thành nhiệm vụ gần như tương đương với phiên đầy đủ, nhưng quyết định mà Router cần đưa ra trong thí nghiệm đã tăng khoảng 30%, tổng số token bộ nhớ đọc từ 23,23 triệu tăng lên 31,77 triệu, tăng khoảng 37%. Điều này cho thấy trong tải thí nghiệm, cơ chế kết nối trực tiếp không cải thiện chất lượng và tốc độ hoàn thành nhiệm vụ, nhưng đã tiết kiệm được một lượng token và chi phí suy diễn đáng kể cho phiên Router.

7.2 Xử lý theo lô ở lớp Router

Để xác minh giới hạn thông lượng của một phiên Router thường trú được đề cập ở phần 2.1 và cơ chế xử lý theo lô, chúng tôi đã thực hiện kiểm tra áp lực riêng cho lớp Router: cho Router gọi mô hình thực tế, Worker sử dụng mô hình giả lập, và tăng dần tốc độ đến của Trigger từ khoảng 1 thông điệp mỗi phút lên khoảng 40 thông điệp, quan sát kích thước lô trung bình, thời gian yêu cầu mỗi lần và thời gian suy diễn phân bổ cho mỗi quyết định.

Kích thước lô, thời gian yêu cầu mỗi lần và thời gian suy diễn phân bổ cho mỗi quyết định của phiên Router ở các tốc độ đến Trigger khác nhau

8. Vấn đề mở

Năm mô-đun được giới thiệu từ phần 2 đến phần 6 cấu thành kiến trúc cơ bản hỗ trợ hoạt động của Super-agent, thí nghiệm ở phần 7 cũng xác nhận hiệu quả của cơ chế lập lịch và định tuyến cốt lõi trong bối cảnh đa nhiệm đồng thời. Hệ thống này có thể hoạt động với độ phức tạp tương đối thấp phần lớn là nhờ vào việc chúng tôi đã thực hiện một loạt các đơn giản hóa kỹ thuật và bối cảnh ở giai đoạn hiện tại. Khi vượt ra ngoài phạm vi áp dụng của những đơn giản hóa này, vẫn còn một số vấn đề cần giải quyết trong việc mở rộng kiến trúc hai lớp (phần 8.1), hợp tác giữa người và máy sau khi rời khỏi phiên (phần 8.2), ranh giới ngữ cảnh và A2A (phần 8.3), cũng như an toàn và quyền riêng tư (phần 8.4).

8.1 Làm thế nào để mở rộng kiến trúc hai lớp

Trước đó, thông qua sự kết hợp đơn giản "Một phiên Router thường trú + Kết nối trực tiếp + Worker không giao tiếp trực tiếp", chúng tôi đã bao phủ hầu hết các nhiệm vụ hàng ngày của mình với chi phí kỹ thuật nhỏ. Nhưng khi quy mô nhiệm vụ mở rộng và độ kết nối tăng lên, vượt quá khả năng chịu đựng của một phiên Router đơn, cấu trúc cụ thể bên trong vẫn chưa có kết luận rõ ràng, thời điểm nào lớp Router cần được chia tách theo chiều ngang, cách phân chia độ lớn như thế nào, và khi nào cần đưa vào giao tiếp trực tiếp giữa các Worker cùng lớp, cũng như loại hình hợp tác nào, vẫn cần được kiểm nghiệm trong nhiều bối cảnh hơn. Đồng thời, thiết kế phối hợp giữa hệ thống và mô hình (Co-design) cũng là một hướng đáng khám phá, đào tạo chuyên biệt cho các nhiệm vụ như phân loại sự kiện, phân phối theo lô và hồi tưởng ngữ cảnh ở lớp Router có thể nâng cao thêm thông lượng và hiệu suất quyết định của lớp Router.

Trong khi đó, lớp Router thường trú kết hợp với hồi tưởng chuỗi dựa trên đồ thị chủ yếu giải quyết việc truy xuất theo nhu cầu các nhiệm vụ gần đây và lịch sử cuộc trò chuyện. Khi chu kỳ hoạt động kéo dài đến hàng tháng hoặc thậm chí lâu hơn, trí nhớ dài hạn trở thành nút thắt chính hạn chế khả năng mở rộng.

8.2 Làm thế nào để hợp tác với Agent sau khi rời khỏi phiên

Trước đó, thông qua kiến trúc hai lớp, chúng tôi đã ẩn quản lý nhiều phiên ở cấp độ thấp khỏi người dùng, khiến phiên không còn là vấn đề chính trong thiết kế sản phẩm; nhưng khi các phiên thực thi ở cấp độ thấp không còn tương ứng trực tiếp với các phiên trên giao diện người dùng, cách trình bày nhiệm vụ cho người dùng và cung cấp hình thức tương tác và quản lý dự án tự nhiên trở thành một vấn đề mới. Chúng tôi cho rằng, tương tác dựa trên cửa sổ trò chuyện ở một mức độ nào đó là kết quả của sự phụ thuộc vào con đường. Tương tác có thể diễn ra nhiều hơn trong các giao diện tương tác chuyên biệt theo lĩnh vực, chẳng hạn như để Super-agent làm việc trực tiếp trong các Vấn đề và Yêu cầu kéo (Pull Request) của GitHub như trong ví dụ của bài viết này; phiên cũng có thể được giữ lại trên giao diện vì thói quen sử dụng của người dùng, nhưng một phiên mà người dùng thấy không nhất thiết chỉ tương ứng với một phiên ở cấp độ thấp.

Đồng thời, trước đó chủ yếu thảo luận về sự tương tác của con người trong giai đoạn khởi xướng nhiệm vụ và xác nhận kết quả; nhưng trong giai đoạn chuyển tiếp khi khả năng của mô hình phát triển nhanh chóng, nhiều nhiệm vụ vẫn cần sự tham gia của con người giữa chừng, cách cân bằng giữa sự can thiệp dần dần của người dùng vào các chi tiết quan trọng và hiệu suất tự động tiến triển ở hậu trường, chẳng hạn như cho phép người dùng can thiệp, tiếp quản hoặc làm việc cùng Agent theo thời gian thực trong quá trình thực hiện ở hậu trường, cũng rất đáng để khám phá.

Tổng thể, hình thức quản lý dự án và tương tác mà người dùng cần có liên quan chặt chẽ đến lĩnh vực công việc cụ thể và phong cách cá nhân, hình thức cuối cùng rất có thể là tùy chỉnh cao; trong khi đó, DeepSeek Harness do áp dụng thiết kế kiến trúc mở cũng dễ dàng hỗ trợ loại tùy chỉnh này.

8.3 Làm thế nào để phân chia ranh giới ngữ cảnh và thực hiện hợp tác A2A

Những gì đã thảo luận trước đó chủ yếu là thiết kế bên trong của một phiên Super-agent đơn lẻ, mặc định rằng thông tin trong phạm vi dịch vụ của nó được tổng hợp trong cùng một ngữ cảnh toàn cầu. Nhưng khi phạm vi sử dụng mở rộng từ cá nhân hoặc nhóm nhỏ đến các tổ chức lớn hơn, tổ chức khi quyết định cách trang bị Super-agent thực tế đang phân chia ranh giới chia sẻ và cách ly ngữ cảnh. Phạm vi cần chia sẻ ngữ cảnh sẽ sử dụng cùng một phiên, trong khi phạm vi cần cách ly sẽ được trang bị độc lập.

Xem thêm, một khi trong tổ chức hoặc giữa các tổ chức có nhiều trường hợp cách ly lẫn nhau, chẳng hạn như giữa trợ lý cá nhân của từng thành viên và Super-agent dùng chung của nhóm, thì sự hợp tác xuyên biên giới lúc này chính là giao tiếp giữa các Agent (A2A, không chỉ định một giao thức cụ thể nào). Dưới điều kiện không chia sẻ ngữ cảnh cơ bản, mỗi bên đại diện cho các ranh giới quyền hạn khác nhau, cách thức thực hiện giao tiếp và hợp tác A2A an toàn, đáng tin cậy vẫn cần được khám phá thêm.

8.4 Làm thế nào để đảm bảo an toàn và quyền riêng tư

Thiết kế dựa trên sự kiện trong phần 3 cho phép Agent được điều khiển bởi môi trường rộng hơn, nhưng cũng làm tăng rủi ro tiếp xúc với đầu vào không đáng tin cậy. Nếu không có cách nào giải quyết tốt vấn đề an toàn và quyền riêng tư, thì Super-agent chỉ có thể hoạt động trong một phạm vi rất nhỏ và đáng tin cậy.

Ví dụ, phần 5 triển khai Agent Loop trên đám mây và cài đặt daemon nhẹ trên các thiết bị thực thi khác nhau, thiết kế này mặc định dựa trên giả định rằng môi trường đám mây và thiết bị đầu cuối là đáng tin cậy với nhau. Nhưng khi Agent Loop trên đám mây liên tục kết nối với các sự kiện môi trường bên ngoài, trong khi trên thiết bị đầu cuối lại có mã riêng, dữ liệu nhạy cảm và thông tin xác thực cục bộ, thì kết nối giữa các thiết bị này sẽ mang lại những rủi ro an toàn và quyền riêng tư đáng kể. Một khi Agent Loop trên đám mây gặp phải xâm nhập từ máy chủ hoặc tiêm từ khóa và bị tấn công, tất cả các thiết bị đầu cuối kết nối với nó đều phải đối mặt với rủi ro tiềm ẩn bị kiểm soát.

Hơn nữa, ngay cả khi đám mây không bị xâm nhập, chỉ cần thông tin xác thực trong môi trường đầu cuối có thể vào ngữ cảnh của mô hình, thì trong quá trình thực hiện bình thường cũng có rủi ro rò rỉ thông tin xác thực; do đó, cần thiết kế cơ chế tương ứng để Agent có thể sử dụng thông tin xác thực mà không tiếp xúc trực tiếp với thông tin xác thực đó. Nếu kiến trúc này muốn hướng tới ứng dụng rộng rãi hơn, thì cần giải quyết các vấn đề an toàn và quyền riêng tư đã nêu trong khi vẫn có thể thu hồi ngữ cảnh từ các môi trường đa dạng.

9. Kết luận

Nhìn lại toàn bộ thiết kế, chúng tôi không đưa ra lý thuyết hoàn toàn mới, mà áp dụng các tư tưởng kỹ thuật cổ điển trong hệ thống máy tính vào việc xây dựng hệ thống Agent. Cách thức thực hiện cụ thể sẽ tiến hóa theo sự phát triển của công nghệ, nhưng chúng tôi tin rằng tư duy thiết kế hệ thống đứng sau có giá trị tham khảo lâu dài hơn. Hiện tại, chúng tôi đã xây dựng một ví dụ Super-agent nội bộ dựa trên tư duy này và DeepSeek Harness đang hoạt động liên tục, tham gia vào việc tái hiện và sửa chữa vấn đề hàng ngày, phản hồi kiểm tra mã và tự phát triển DeepSeek Harness.

Như đã đề cập ở phần mở đầu, khi các mô hình lớn ngày càng ít cần can thiệp của con người để thực hiện một nhiệm vụ đơn lẻ, thì nút thắt hạn chế sự gia tăng năng suất đang chuyển sang sự chú ý của con người. Thông qua kiến trúc hai lớp, điều khiển dựa trên sự kiện, tương tác đa kênh không đồng bộ, tách biệt lưu trữ và tính toán cùng với Watchdog bên ngoài, hệ thống đã tiếp quản việc quản lý phiên và đồng bộ ngữ cảnh phức tạp ở cấp độ cơ sở, cho phép con người chuyển từ các chi tiết thực hiện cụ thể lên các quyết định và chấp nhận ở cấp cao hơn.

Trong hình thức này, Agent không còn chỉ là một cửa sổ đối thoại thụ động chờ lệnh, mà đã tiến hóa thành một cộng tác viên tự chủ trực tuyến liên tục trong môi trường số: đối với cá nhân, nó có thể là trợ lý cá nhân hỗ trợ xử lý các công việc hàng ngày trên nhiều thiết bị; đối với nhóm, nó tích hợp vào quy trình làm việc phát triển, đảm nhận và thúc đẩy các nhiệm vụ cụ thể. Chúng tôi tin rằng, với sự tiến hóa đồng thời của khả năng mô hình và kiến trúc hệ thống cơ sở, cách làm việc tự chủ hơn này có khả năng trở thành trạng thái bình thường trong hợp tác giữa người và máy.

Một phần thiết kế trong bài viết này đã được thực hiện trong dsh-superagent-prototype. Plugin này chỉ là một nguyên mẫu được cung cấp để xác minh lộ trình công nghệ, không phải là sản phẩm chính thức của DeepSeek.

Tác giả & Lời cảm ơn

Bài viết này xuất phát từ thực hành chung của đội ngũ DeepSeek Harness. Yujia Qiao đã hoàn thành việc triển khai hệ thống và viết bài này, Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, C.C. Yu, Ziya Zhang, F. Zhou và những người khác đã tham gia xem xét thảo luận và cung cấp phản hồi. Việc triển khai hệ thống và hình thành bài viết không thể thiếu sự giao tiếp và tích lũy hàng ngày của đội ngũ.