Một tác nhân lập trình được xây dựng để xử lý nhiều công việc cùng lúc
Nhóm Harness của DeepSeek công bố thiết kế Super-agent ngày 31 tháng 10 năm 2026, cùng với một nguyên mẫu nghiên cứu được cấp phép MIT, biến các yêu cầu dành cho kho GitHub thành những phiên lập trình riêng biệt. Mục tiêu là giúp nhiều công việc được tiến hành đồng thời, đồng thời giảm thời gian nhà phát triển phải chuyển qua lại giữa các cuộc trò chuyện và kiểm tra tiến độ.
Nội dung
- Một tác nhân lập trình được xây dựng để xử lý nhiều công việc cùng lúc
- Vì sao DeepSeek muốn ẩn việc quản lý phiên
- Một Router điều phối, nhiều Worker thực thi
- Cách tin nhắn trở thành tác vụ mà không gây gián đoạn liên tục
- Chủ động xử lý sớm, chỉ lên tiếng khi hữu ích
- Giữ ngữ cảnh cũ và chỉ dẫn mới luôn sẵn có
- Điều phối trên đám mây, thực hiện công việc trên máy tính cá nhân
- Thử nghiệm đã đo lường điều gì
- Điều phối nhanh hơn đồng nghĩa dùng nhiều token được lưu đệm hơn
- Quyền truy cập cục bộ khiến bảo mật trở thành mối quan tâm trọng yếu
- Điểm chính
Thử nghiệm sơ bộ của nhóm sử dụng khoảng 300 tin nhắn mô phỏng, chứa gần 20 yêu cầu công việc. Super-agent hoàn thành một nửa số tác vụ trong 12,4 phút và 95% trong 15,7 phút. Hệ thống đối chiếu, sử dụng một phiên chính có quyền truy cập tác nhân trợ giúp, mất 29,5 phút để đạt mốc 95% với chỉ dẫn trung tính.
Kho nguyên mẫu công khai của DeepSeek, mang tên dsh-superagent-prototype, giới thiệu một bản phát hành thực tiễn với phạm vi hẹp hơn: một tác nhân lập trình chủ động dành cho một kho GitHub, được đóng gói dưới dạng bundle cho DeepSeek Harness. Tác nhân theo dõi GitHub và tùy chọn cả Feishu, mở một mục công việc khi người được ủy quyền yêu cầu, rồi phản hồi trong cuộc trò chuyện ban đầu, có thể kèm theo một pull request đề xuất thay đổi mã.
README cũng đưa ra cảnh báo rõ ràng. Mã được công bố khác với hệ thống nội bộ và một số phần trong bài luận thiết kế. Một số tính năng đề xuất vẫn đang được phát triển; DeepSeek mô tả bản phát hành này là mã nghiên cứu, không phải sản phẩm hoàn chỉnh.
Nhóm DeepSeek Harness, đơn vị duy trì nguyên mẫu, nêu rõ trạng thái dự án trong README:
Nguyên mẫu nghiên cứu chỉ để tham khảo, không phải sản phẩm chính thức của DeepSeek.
Với các nhà phát triển, bản phát hành cung cấp mã để xem xét và điều chỉnh. Thử nghiệm cốt lõi tập trung vào cách một tác nhân tổ chức công việc, ghi nhớ các cuộc trò chuyện có liên quan và quyết định khi nào cần người tham gia.
Vì sao DeepSeek muốn ẩn việc quản lý phiên
Thiết kế của DeepSeek bắt đầu từ một quan sát trong quá trình làm việc của chính họ: một người thường chỉ có thể theo dõi cùng lúc ba đến năm phiên tác nhân đang hoạt động. Mỗi phiên có lịch sử trò chuyện riêng, nên nhà phát triển phải nhớ tác vụ nào thuộc về phiên nào và mỗi tác nhân đã nhận những chỉ dẫn gì.
Harness là phần mềm bao quanh một mô hình AI, quản lý công cụ, tệp, cuộc trò chuyện và quá trình thực thi. Mô hình suy luận về tác vụ; harness quyết định tác vụ được chuyển đến mô hình như thế nào và các hành động của mô hình được thực thi ra sao. Super-agent chuyển thêm trách nhiệm điều phối nhiều công việc sang phần mềm bao quanh này.
Nhóm đặt ra bốn mục tiêu: duy trì tính liên tục giữa các cuộc trò chuyện, thực thi song song hiệu quả, phản hồi chủ động trước các sự kiện và vận hành liên tục với khả năng phục hồi khi gặp lỗi. Một ví dụ là nhà phát triển chọn kế hoạch trong cuộc trò chuyện rồi thay đổi kế hoạch đó sau này trong bình luận trên GitHub. Hệ thống cần liên kết các trao đổi này và điều chỉnh cùng một tác vụ.
Bản phát hành tiếp nối thử nghiệm ngày 3 tháng 10 của DeepSeek về khả năng tương thích với tiện ích mở rộng Claude Code trong Harness v0.2.1-alpha.1. Bản cập nhật đó thử nghiệm một cầu nối cho các tiện ích mở rộng; Super-agent khám phá cách bản thân harness có thể điều phối công việc đang diễn ra. Yujia Qiao được ghi nhận là người triển khai hệ thống và viết bài luận thiết kế, cùng 15 người khác tham gia đánh giá và thảo luận.
Một Router điều phối, nhiều Worker thực thi
Super-agent phân chia trách nhiệm giữa một Router hoạt động thường trực và các Worker riêng biệt. Router tiếp nhận tương tác của con người, duy trì thông tin dùng chung giữa các tác vụ và phân công công việc. Router không trực tiếp lập trình, nhờ đó vẫn có thể đảm nhiệm vai trò điều phối trong khi các phiên khác bận xử lý công việc.
Worker xử lý từng công việc riêng lẻ. Mỗi Worker có ngữ cảnh trò chuyện và công cụ thực thi riêng, cho phép việc điều tra lỗi, phản hồi đánh giá mã và thay đổi tính năng diễn ra đồng thời. Worker báo cáo kết quả cho Router, rồi Router giao tiếp với mọi người thay vì để nhiều phiên tự trả lời riêng rẽ.
DeepSeek cho rằng một mô hình nhẹ hơn thường có thể đảm nhiệm việc định tuyến, trong khi các mô hình mạnh hơn xử lý những công việc quyết định chất lượng mã. Worker cũng có thể tạo các tác nhân trợ giúp cho nhiệm vụ phức tạp. Router quản lý mối quan hệ giữa các công việc thay vì lập kế hoạch cho mọi bước bên trong từng công việc.
Nguyên mẫu cấp cho mỗi mục công việc một phiên và thư mục riêng; các phiên được khởi chạy đồng thời đến giới hạn đã cấu hình. Vì vậy, người vận hành có thể kiểm soát số lượng công việc bắt đầu cùng lúc. Lịch sử trò chuyện riêng giúp giảm nguy cơ chi tiết của tác vụ này lấn át tác vụ khác, trong khi Router duy trì cái nhìn tổng thể dùng chung.
Cách tin nhắn trở thành tác vụ mà không gây gián đoạn liên tục
Tin nhắn trò chuyện, bình luận đánh giá mã và kết quả kiểm thử tự động trở thành các sự kiện có thể kích hoạt hành động. Thiết kế rộng hơn cũng xem xét email và nhắc lịch. Tích hợp liên tục, hay CI, là các bước kiểm tra tự động để xây dựng hoặc kiểm thử mã sau một thay đổi, tạo ra kết quả mà tác nhân có thể phản hồi.
DeepSeek lọc các sự kiện qua hai giai đoạn. Trước tiên, các quy tắc chương trình thông thường kiểm tra những yếu tố như nguồn, nhóm và người dùng được ủy quyền. Sau đó, một mô hình đánh giá các sự kiện còn lại dựa trên ngữ cảnh và chính sách bằng văn bản. Cách này giảm số lần gọi mô hình đối với những tin nhắn thường lệ không cần hành động.
Các sự kiện liên quan được gom thành một Thread, chẳng hạn như các bình luận dưới cùng một pull request hoặc một chủ đề trò chuyện. Khi Worker nhận nhiệm vụ, nó đăng ký theo dõi Thread đó. Các bình luận và kết quả kiểm thử về sau có thể được chuyển thẳng đến Worker mà không cần Router phân công lại.
Các đăng ký theo dõi có thể chồng lấn. Nhiều Worker cùng xử lý một pull request có thể nhận cùng bản cập nhật, nhờ đó phát hiện những thay đổi ảnh hưởng đến công việc của mình. Worker cũng có thể theo dõi nhiều Thread liên quan hoặc gửi sự kiện lại cho Router nếu sự kiện nằm ngoài nhiệm vụ được giao.
Chủ động xử lý sớm, chỉ lên tiếng khi hữu ích
DeepSeek cho biết một Super-agent nội bộ đã vận hành liên tục, tái hiện và sửa lỗi, phản hồi các đợt đánh giá mã và hỗ trợ phát triển chính Harness. Một quy tắc bằng văn bản cho phép tác nhân điều tra lỗi được nhắc đến trong cuộc trò chuyện nhóm ngay cả khi không ai gọi đích danh tác nhân.
Quy tắc yêu cầu trước tiên âm thầm điều tra. Tác nhân cố gắng tái hiện vấn đề được báo cáo và tìm cách sửa đơn giản, sau đó đưa ra kết quả hữu ích. Trong một ví dụ, khi các nhà phát triển đang bàn về lỗi dấu ngã hiển thị thành định dạng gạch ngang, tác nhân đã mở một pull request đề xuất cách khắc phục.
Nhóm Harness mô tả nguyên tắc vận hành trong README:
thu hút sự chú ý của con người ít nhất có thể và mang lại giá trị nhiều nhất có thể.
Nguyên mẫu chỉ hành động khi có yêu cầu từ người được ủy quyền hoặc khi một quy tắc do nhóm đặt ra cho phép. Bảng điều khiển web liệt kê các mục công việc cần con người chú ý. Nhờ vậy, giao diện tập trung vào các quyết định và kết quả có thể sử dụng, thay vì mọi lần gọi công cụ hay suy nghĩ trung gian.
Giữ ngữ cảnh cũ và chỉ dẫn mới luôn sẵn có
Thiết kế của DeepSeek xem cửa sổ ngữ cảnh của mô hình, tức lượng thông tin giới hạn mà mô hình có thể xem xét cùng lúc, như một bộ nhớ đệm. Tài liệu thường xuyên cần dùng được giữ gần; phần lịch sử dài hơn hoặc ít liên quan hơn nằm ngoài cửa sổ cho đến khi được yêu cầu.
Bài luận gọi các thao tác này là Inline và Spill. Inline đưa trực tiếp chi tiết hữu ích vào ngữ cảnh hiện tại, chẳng hạn tin nhắn trò chuyện gần đó, mã định danh hoặc bản xem trước ngắn. Spill để nội dung dài hơn ở nơi khác, kèm một tham chiếu mà mô hình có thể dùng để đọc thêm.
Chain of Recall liên kết các tham chiếu đó. Sự kiện, Thread và phiên Worker được gán mã định danh duy nhất, cho phép tác nhân chuyển từ tin nhắn hiện tại sang cuộc thảo luận của tin nhắn đó, rồi đến Worker liên quan và một đợt đánh giá mã khác. Mục tiêu là khôi phục một tác vụ cũ qua nhiều kênh mà không phải tải đi tải lại toàn bộ lịch sử.
DeepSeek cũng xử lý một vấn đề gián đoạn tức thời hơn: một lệnh chạy lâu có thể khiến tác nhân thông thường không thể phản hồi. Cơ chế bất đồng bộ khởi chạy công việc ở chế độ nền và gửi kết quả trở lại dưới dạng sự kiện mới. Người dùng có thể tiếp tục đưa ra chỉ dẫn, kể cả yêu cầu tác nhân đổi hướng hoặc dừng lại.
Nhóm cho biết cơ chế này đã được triển khai trong DeepSeek Harness nhưng không được bật theo mặc định. Quy tắc giao tiếp cũng khác nhau tùy kênh: thiết kế giới hạn một câu trả lời tức thời qua tin nhắn ở mức 100 từ, trong khi pull request và tài liệu có phần giải thích thay đổi và xác minh có cấu trúc hơn.
Điều phối trên đám mây, thực hiện công việc trên máy tính cá nhân
DeepSeek tách biệt phần tính toán chạy tác nhân, lịch sử phiên được lưu trữ và máy thực thi lệnh. Vòng lặp tác nhân được đề xuất chạy trong các container đám mây, trạng thái phiên nằm trong cơ sở dữ liệu, còn một dịch vụ cục bộ nhẹ thực thi lệnh và trả kết quả về.
Cách bố trí này hỗ trợ Bring Your Own Machine, hay BYOM (sử dụng máy tính của riêng bạn). Nhà phát triển có thể kết nối một máy tính sẵn có chứa kho mã, công cụ và các thay đổi chưa hoàn tất, thay vì chuyển mọi thứ sang một môi trường từ xa mới. Việc điều phối trên đám mây vẫn có thể duy trì khi máy tính đó ngắt kết nối, còn các tác vụ cần đến máy sẽ chờ thiết bị kết nối lại.
Một phiên Watchdog độc lập kiểm tra lỗi và công việc bị đình trệ. Mục đích của nó không chỉ là phát hiện thông báo lỗi: Watchdog dùng khả năng đánh giá của mô hình để xem Worker có thực sự tiến triển hay đang đi chệch mục tiêu, rồi tìm cách khôi phục khi cần.
DeepSeek xem những thành phần này là một phần trong quá trình khám phá kiến trúc rộng hơn. README cảnh báo rằng bundle công khai và bản triển khai nội bộ khác nhau, vì vậy nhà phát triển cần kiểm tra mã được phát hành trước khi dựa vào một tính năng thiết kế cụ thể.
Thử nghiệm đã đo lường điều gì
DeepSeek lặp lại mỗi thiết lập thử nghiệm năm lần, so sánh Super-agent với một phiên bản không có khả năng chuyển sự kiện trực tiếp và hai cấu hình của một phiên đơn có tác nhân trợ giúp. Khối lượng công việc dùng tin nhắn tổng hợp và một công cụ mô phỏng công việc lập trình kéo dài. Khoảng cách giữa các tin nhắn và thời lượng công việc được rút xuống còn một phần tư.
Trung vị 12,4 phút có nghĩa là một nửa số tác vụ hoàn thành trước mốc đó. Phân vị thứ 95 ở mức 15,7 phút nghĩa là 95% hoàn tất trong khoảng thời gian này. So với mốc 29,5 phút ở phân vị thứ 95 của phiên đơn với chỉ dẫn trung tính, Super-agent rút ngắn chỉ số này 13,8 phút, tương đương khoảng 47%.
Hành vi ủy quyền giúp lý giải kết quả. Với chỉ dẫn trung tính, phiên đơn không lần nào gọi tác nhân trợ giúp trong cả năm lượt chạy. Khi được yêu cầu ưu tiên ủy quyền, phiên này giao việc cho tác nhân trợ giúp trong bốn lượt và tự xử lý ở lượt còn lại. Super-agent biến sự tách biệt giữa điều phối và thực thi thành lựa chọn trong cấu trúc hệ thống.
Các bài kiểm thử đánh giá khả năng lên lịch và điều phối với quá trình thực thi mô phỏng. Chất lượng lập trình thực tế, các phép đo hiệu năng độc lập và số lượng người dùng đang hoạt động chưa được công bố, trong khi nhóm gọi các số liệu này là sơ bộ. DeepSeek chưa đưa ra ngày phát hành sản phẩm chính thức.
Điều phối nhanh hơn đồng nghĩa dùng nhiều token được lưu đệm hơn
Khả năng chạy đồng thời của Super-agent đi kèm mức sử dụng đầu vào được lưu đệm cao hơn. Hệ thống đọc 23,23 triệu token được lưu đệm, so với 6,05 triệu và 10,82 triệu ở hai cấu hình phiên đơn. Token là đơn vị văn bản nhỏ mà mô hình xử lý; lượt đọc từ bộ nhớ đệm tái sử dụng đầu vào được giữ lại từ các yêu cầu trước.
Việc bỏ chuyển sự kiện trực tiếp làm số lượt đọc được lưu đệm tăng từ 23,23 triệu lên 31,77 triệu, tức khoảng 37%, và số quyết định của Router tăng khoảng 30%. Vì vậy, chuyển các trao đổi tiếp theo thẳng đến Worker được phân công giúp giảm khối lượng điều phối trong thiết kế chạy song song.
Gom nhóm giúp Router xử lý lưu lượng lớn hơn. Khi lượng sự kiện đến tăng từ khoảng một lên 40 lần kích hoạt mỗi phút, kích thước lô trung bình tăng từ 1,0 lên 2,8 và thời lượng yêu cầu tăng từ 2,5 lên 3,9 giây. Thời gian suy luận được báo cáo cho mỗi quyết định của Router giảm từ 6,4 xuống 1,6 giây.
Đánh đổi thực tế là giảm thời gian chờ của con người nhưng tăng lượng xử lý của mô hình qua các phiên riêng. Số liệu token không thể hiện hóa đơn bằng tiền; các nhóm cân nhắc triển khai cần tính đến giá mô hình, thiết lập mức độ đồng thời và khối lượng công việc thực tế.
Quyền truy cập cục bộ khiến bảo mật trở thành mối quan tâm trọng yếu
Tài liệu thực thi của nguyên mẫu cho biết các lệnh của Worker chạy mà không cần phê duyệt, dưới tài khoản hệ điều hành của người vận hành. Lệnh shell chạy ở tiền cảnh được chuyển sang chạy nền sau năm giây; tác vụ nền có thể chạy tối đa 30 phút mỗi lượt. Những thiết lập này khiến quyền của tài khoản người vận hành trở thành vấn đề cụ thể cần cân nhắc khi triển khai.
Máy tính được kết nối có thể lưu thông tin xác thực, mã riêng tư và các tệp nhạy cảm. Tấn công chèn lệnh vào prompt, trong đó nội dung độc hại tìm cách hướng tác nhân đi theo một hướng khác thông qua tài liệu mà tác nhân đọc, trở nên đặc biệt nghiêm trọng khi tin nhắn đến hoặc nội dung trong kho mã có thể ảnh hưởng đến các lệnh trên máy đó.
DeepSeek xác định bảo mật và quyền riêng tư, khả năng mở rộng của Router, ghi nhớ trong thời gian dài và giao tiếp giữa các phiên tác nhân là những lĩnh vực còn chưa hoàn thiện. README đề nghị người dùng xem xét và điều chỉnh mã, đồng thời cảnh báo có thể vẫn còn lỗi và các quy trình kỹ thuật thiếu nhất quán. Phần lớn công việc kỹ thuật của dự án cũng do các tác nhân lập trình thực hiện.
Đợt ra mắt nhanh chóng thu hút sự chú ý, trong đó có bài đăng của Leandro von Werra, trưởng bộ phận nghiên cứu tại Hugging Face. Diễn biến cho thấy nguyên mẫu lan truyền nhanh đến mức nào:
- Ngày 31 tháng 10 năm 2026, lúc 09:32 UTC: kho GitHub được tạo.
- Ngày 31 tháng 10: nhóm Harness công bố bài luận thiết kế; đến 22:10 UTC, kho có 2.046 lượt gắn sao và 172 lượt fork.
- Ngày 1 tháng 11, lúc 04:20 UTC: kho đạt 3.433 lượt gắn sao.
Với các nhóm kỹ thuật, quyết định trước mắt là có nên xem xét và điều chỉnh một hệ thống điều phối thử nghiệm hay không. Sức hấp dẫn của hệ thống nằm ở triển vọng xử lý nhiều công việc hơn với ít gián đoạn hơn; yêu cầu vận hành bao gồm rà soát mã, thiết lập quyền truy cập và xác định hành động nào cần có người tham gia.
Điểm chính
- DeepSeek phát hành một nguyên mẫu nghiên cứu được cấp phép MIT dành cho công việc lập trình trong một kho GitHub, có tích hợp Feishu tùy chọn.
- Router đảm nhiệm việc điều phối, còn các Worker riêng biệt thực thi tác vụ đồng thời.
- Hệ thống nội bộ có thể điều tra lỗi được báo cáo theo các quy tắc bằng văn bản mà không cần được gọi đích danh.
- Thử nghiệm tổng hợp ghi nhận thời gian hoàn thành trung vị 12,4 phút và phân vị thứ 95 là 15,7 phút, cùng mức sử dụng token được lưu đệm cao hơn các phương án phiên đơn.
- Worker thực thi lệnh dưới tài khoản của người vận hành mà không cần phê duyệt, khiến quyền truy cập và thông tin xác thực trở thành mối quan tâm trọng yếu.
- Mã công khai khác với hệ thống nội bộ và vẫn là nguyên mẫu nghiên cứu, không phải sản phẩm chính thức của DeepSeek.






