Vừa mới, DeepSeek công bố triết lý 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 liên tục và can thiệp từng bước từ con người. Trong khi đó, khả năng hợp tác đa Agent của mô hình cũng đang được cải thiện, khiến việc tổ chức và lập lịch xuyên suốt các cuộc hội thoại trở nên khả thi. Khi sự tham gia của con người trong việc thực hiện ở cấp độ cơ sở 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 khả năng của mô hình này 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 quan sát 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 trong những 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 một 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 thúc đẩy 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 thúc đẩy liên tục giữa IM và GitHub; ví dụ này cũng sẽ liên tục quan sát 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 thúc đẩy liên tục giữa cuộc trò chuyện 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 duy nhất, không cần phải nghĩ "Thông tin Y có trong bối cảnh của Phiên X không". Ví dụ, người dùng trước tiên đề xuất sử dụng phương án A trên IM, sau đó thay đổi thành phương án B trong bình luận Pull Request trên GitHub, 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 bước, có thể liên tục quan sát các sự kiện môi trường và chủ động thúc đẩy các vấn đề cần xử lý, không cần can thiệp thì sẽ giữ im lặng.

• Bền vững: Luôn trực tuyến, trực tiếp kết nối 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 sự cố 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ẽ sử dụng kiến trúc tương tự. Đồng thời, nhiều vấn đề mà quá trình này phải đối mặt 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, do đó nhiều ý 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 (Phần 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ự kiện điều khiển (Phần 3) để đạt được phản hồi chủ động, thông qua tương tác hướng tới con người (Phần 4) để đồng thời đạt được liên tục và hiệu quả trong quá trình tương tác, và thông qua việc tách biệt tính toán, trạng thái và môi trường (Phần 5) và Watchdog (Phần 6) để đạt được khả năng duy trì liên tục và tự phục hồi trên nhiều 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 của các mô-đun trong hình [2] đến [6] tương ứng với các phần từ 2 đến 6 dưới đây:

Kiến trúc hệ thống tổng thể của Super-agent, số hiệu [2] đến [6] tương ứng với các phần từ 2 đến 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ị tách biệt, đồ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 ta 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ú (Phần 2.1) tiếp nhận đồng nhất các tương tác của con người và điều phối toàn cầu, và một lớp Worker (Phần 2.2) tách biệt bối cảnh thực hiện các nhiệm vụ cụ thể một cách đồ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 tách biệt 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 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 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 thủ công, phần lớn là di sản 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, không nên là 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 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. 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 sẽ 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ấn đề này trong phần sau.

Ở đây, "hai lớp" là sự phân chia trách nhiệm về mặt logic, mỗi lớp trong thực hiện không nhất thiết phải giới hạn ở một Phiên duy nhất, mà có thể có cấu trúc nội bộ riêng. Phần 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ú, 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ấ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 tuần tự toàn cầu (Sequence Point), điểm điều phối 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 nhiệm vụ cụ thể, chỉ chịu trách nhiệm về 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, với 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 phổ biến, nhưng trọng tâm của hai bên khác nhau. Nhóm Agent phổ biến 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à điều phối 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 lớn. Trong khi đó, trong Super-agent, lớp Router chỉ xử lý 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 về 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, việc sử dụng mô hình nhẹ hơn thường có thể vừa đảm bảo tốc độ vừa đảm bảo 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 duy nhất, thậm chí một số logic chưa chắc đã cần gọi LLM. Chúng tôi đã chọn một Phiên LLM thường trú đơn giản nhất 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ư vẻ 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 Phần 3) sẽ được tích lũy lại và 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ẽ vào Phiên Router từng cái một, 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ình trạng 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 của 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 trong phần 7.2 thông qua các thí nghiệm. Cùng với cơ chế đăng ký và thông qua mà sẽ được giới thiệu trong phần sau, 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ứa đựng, 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ác 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 các kênh bên ngoài mà sẽ báo cáo trạng thái về lớp Router, từ đó lớp Router sẽ đồng nhất phản hồi cho người dùng, nhằm đả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ụ, thường không cần giao tiếp trực tiếp giữa các Worker cùng lớ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ý theo 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 qua 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, bên trong Worker có thể tạo ra Subagent, hoặc có thể là một Agent Team, 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ư 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. Sự kiện điều khiể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 Session, mà là các sự kiện bán cấu trúc phát sinh từ môi trường. Trong Super-agent, các 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 mới 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ý, phần dưới 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 chiến lược hai cấp 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 một cách dày đặc và hồi tưởng ngữ cảnh theo nhu cầu (phần 3.3), và làm thế nào để sử dụng thực thi đầu cơ để 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 và nền tảng mã thực tế, 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 một, độ trễ và chi phí tính toán sẽ khó có thể chịu đựng. Dựa trên ý 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ễ 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 gốc 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 bằng mã, ví dụ 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ỏ phần lớn 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 ở cấp chương trình sẽ được chuyển cho LLM, nó sẽ quyết định có cần hành động hay không dựa trên chiến lược và ngữ cảnh được viết bằng từ gợi ý. Cấp ngữ nghĩa cũng đồng thời là điểm mở rộng ngôn ngữ tự nhiên hướng tới con người, thuận tiện để bật tắt hoặc thêm chiến lược mới bất cứ lúc nào, như hình dưới đây:

Lọc hai cấp: trước tiên lọc bỏ phần lớn tin nhắn không liên quan bằng 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 phải đượ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 các nhiệm vụ mới và điều phối 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ùng một Pull Request trên GitHub, cùng một chủ đề IM hoặc chuỗi email liên lạc liên tiếp 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 dưới cùng một chủ đề IM hoặc cùng một Pull Request trên 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 dưới 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 dưới 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à cùng 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, đồng thời 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, từ đó lớp Router sẽ đồ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, vấn đề 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 liên tục phát sinh 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 chính là lãng phí trí tuệ của mô hình.

Để làm điều này, chúng tôi có thể quản lý cửa sổ ngữ cảnh hạn chế như một Cache. Vay mượn các khái niệm tối ưu hóa biên dịch và trong 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 thời gian gọi công cụ bổ sung. 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ưởng kinh điển về tính cục bộ (Locality) trong thiết kế hệ thống máy tính, chúng tôi có thể từng bước 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 bằng cách sử dụng tính cục bộ: 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 các đối tượng liên quan chặt chẽ, sau đó kèm theo nội dung gần kề về không gian và thời gian, 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 gần kề trong cuộc thảo luận đánh giá mã.

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 một giới hạn độ 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 lối vào để 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 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, nhưng cần phải tìm lại ngữ cảnh khi người dùng đề cập đế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 vào các đối tượng khác nhau trong hệ thống, ta có được một cơ chế truy xuất đa bước theo nhu cầu, tức là chuỗi hồi tưởng (Chain of Recall). Quá trình chuỗi hồi tưởng 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:

Chuỗi hồi tưởng: 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 những đối tượng này tạo thành một đồ thị tham chiếu ở mức độ 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, theo mối quan hệ tham chiếu để từng bước hồi tưởng ngữ cảnh theo nhu cầ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

Dựa trên ý 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 đi ngay lập tức. Trong bối cảnh hợp tác phát triển cũng tương tự, ví dụ như chúng tôi đã cấu hình một chiến lược "Tái hiện và sửa chữa lặng lẽ" trong nhóm người dùng nội bộ của công ty DeepSeek Harness: Khi có người phản hồi vấn đề hoặc thảo luận về phương án thay đổi trong nhóm, Agent sẽ thử nghiệm tái hiện và tìm kiếm phương án sửa chữa trong nền tảng, chỉ khi xác nhận vấn đề và tìm thấy phương án 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 trong 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 trong phần 2 đảm bảo tính liên tục qua 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ộ, để cuộc hội thoại có thể nhận lệnh mới bất cứ lúc nào mà không cần chờ lệnh hoặc nhiệm vụ trước đó hoàn thành (phần 4.1); hai là khi tương tác xảy ra trong 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 xướng một cuộc 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 và đáp sang chế độ song công hoàn toàn, như hình dưới đây:

So sánh giữa 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 trong 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 (), sẽ 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ụ trong 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.

Nhờ đó, phản hồi cuộc hội thoại ở phía trước và thực thi nhiệm vụ ở phía 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 trong 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 vẫn 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 chuyển cách tương tác hướng tới một người dùng đơn lẻ vào trò chuyện nhóm, đưa ra quá trình suy diễn dài dòng và các cuộc gọi công cụ dày đặc mà không thay đổi, rất dễ 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 đề này: 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 cho tương tác bên ngoài. Trên cơ sở đó, hệ thống cũng 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à tùy chỉnh quy tắc tương tác cho các kênh khác nhau thông qua từ khóa:

• 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 chấp nhận, chỉ hỏi những câu hỏi trực tiếp và đư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, ví dụ 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

Các Agent hiện tại mặc định liê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ị. 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 ta 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 thành 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à 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 qua 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ần 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 đó, lớp 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 linh hoạt 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 cần thiết cho công việc của mô hình phải được lấy từ môi trường thực thi như kho mã, tệp địa phương, dịch vụ phụ thuộc thông qua các cuộc gọi công cụ, từ nghĩa 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 cách tiếp cận 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ộ môi trường, nhưng vì 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ư, phụ thuộc dịch vụ nội bộ và phần cứng hoặc chuỗi công cụ cụ thể, việc đồng bộ hóa môi trường như vậy không chỉ tốn kém mà còn dễ xảy ra thiếu sót thông tin; cách tiếp cận khác 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ì vậy, khi 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 thiết phải để môi trường thực thi theo vòng lặp Agent lên đám mây. Lớp 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 thiết bị, 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 để 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.

Cách tiếp cận này nhất quán với ý tưởng "tách rời 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 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, cũng 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 lẻ, 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, ví dụ như 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 theo nhu cầu với các môi trường thực thi khác nhau.

6. Giám sát

Để đạt được tính 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 có tính liên tục rất khó đảm bảo hoạt động đáng tin cậy lâu dài chỉ dựa vào logic nội bộ của hệ thống chính, 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 là do tiến trình bị sập, mà là do 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, thất bại trong phục hồi trạng thá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, 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, 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 Agent Session 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ố thiết lập 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 mã hóa đượ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 tính đượ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 trong cuộc trò chuyện đế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. Ưu tiên giao mỗi công việc cho một subagent riêng, 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 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 từ 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 tính, 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ị gián đoạn bởi các thông điệp mới, 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 rút ngắn 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 từ gợi ý và phán đoán của mô hình trong phiên đơn, kiến trúc hai lớp đã giảm thiểu vấn đề này bằng cách để Router không thực hiện công việc cụ thể, Worker chỉ nhận thông điệp từ 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. Trong khi đó, 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 thực hiện 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ô của 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 và cơ chế xử lý theo lô đã nêu ở phần 2.1, chúng tôi đã thực hiện kiểm tra áp lực riêng cho lớp Router: để 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 lần mỗi phút lên khoảng 40 lần, 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 dưới 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 trong 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ực + Kết nối trực tiếp + Worker không giao tiếp trực tiếp với nhau", 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, độ liên kết tăng lên, vượt quá khả nă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, thời điểm nào lớp Router cần được chia tách theo chiều ngang, cách phân chia độ phân giải 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, sử dụng 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 cho 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ực trước đó kết hợp với hồi tưởng chuỗi dựa trên đồ thị tham chiếu, 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ử phiên. Khi chu kỳ hoạt động kéo dài đến nhiều tháng hoặc thời gian dài 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, việc quản lý nhiều phiên ở cấp độ thấp đã được ẩn đi 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 tự nhiên và quản lý dự án trở thành vấn đề mới. Chúng tôi cho rằng, tương tác xoay quanh 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ể xảy 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ư trong ví dụ của bài viết này, cho phép 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; 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 ở cấp độ thấp chưa chắc chỉ tương ứng với một phiên.

Đồ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 phát nhiệm vụ và xác nhận kết quả; nhưng trong giai đoạn chuyển tiếp nhanh chóng của khả năng mô hình, 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 thúc đẩy ở phía sau trong thiết kế sản phẩm, 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 trong quá trình thực hiện ở phía sau, cũng rất đáng để khám phá.

Nhìn chung, 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ợ sự 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 tổ chức lớn hơn, tổ chức trong việc 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ử dụng cùng một phiên, trong khi phạm vi cần cách ly thì được trang bị độc lập.

Xem xét sâu hơn, một khi trong tổ chức hoặc giữa các tổ chức có nhiều trường hợp tách biệt với 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ơ sở, mỗi bên đại diện cho các ranh giới quyền hạn khác nhau, làm thế nào để 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 tiếp nhận sự kiện từ 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 nguy cơ tiềm ẩn bị kiểm soát.

Hơn nữa, ngay cả khi đám mây không bị tấn công, 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 thi 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ể gọi lạ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à là áp dụng những 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 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 hàng ngày vào việc tái hiện và sửa chữa vấn đề, 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ế 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 quản lý phiên và đồng bộ ngữ cảnh phức tạp ở mức cơ sở, giúp con người có thể chuyển từ các chi tiết thực thi 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ố: hướng tới cá nhân, nó có thể là một trợ lý cá nhân giúp xử lý các công việc hàng ngày qua nhiều thiết bị; hướng tới nhóm, nó hòa nhậ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ế của 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 tiễn chung của đội ngũ DeepSeek Harness. Yujia Qiao đã hoàn thành việc thực hiện 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à nhiều người khác đã tham gia xem xét thảo luận và cung cấp phản hồi. Việc thực hiện hệ thống và hình thành bài viết không thể tách rời khỏi sự giao tiếp và tích lũy hàng ngày của đội ngũ.