DeepSeek Super-Agent: Nó là gì, hoạt động như thế nào và còn thiếu những gì41 min read
Reading Time: 17 minutesMở ba tác nhân mã hóa cùng một lúc và bạn có thể cảm nhận được vấn đề. Một cái đang chờ quyết định, một cái đã hoàn thành cách đây hai mươi phút và bạn đã quên cái nào có bản sửa lỗi xác thực. Nhóm Khai thác của DeepSeek đã đưa ra một con số: theo kinh nghiệm của mình, một người chỉ có thể theo dõi ba đến năm phiên đại lý đang hoạt động cùng một lúc. Qua thời điểm đó, mô hình không còn là nút thắt cổ chai nữa. Bạn là.
Vào ngày 31 tháng 10 năm 2026, nhóm đã xuất bản một bài viết thiết kế cho cái mà họ gọi là Siêu tác nhân và lấy nguồn mở nguyên mẫu có tên dsh-superagent. Nó là một tác nhân mã hóa chủ động cho một kho lưu trữ GitHub. Một phiên bộ định tuyến tồn tại lâu sẽ trao đổi với mọi người và phân công công việc, đồng thời mọi yêu cầu được chấp nhận sẽ có phiên riêng của nó và kết thúc bằng một yêu cầu kéo hoặc một câu hỏi. Kho lưu trữ đã vượt qua 12.000 sao trong khoảng hai ngày. README của nó nói thẳng rằng đây là mã nghiên cứu chứ không phải sản phẩm DeepSeek chính thức.
Hướng dẫn này dành cho các kỹ sư và trưởng nhóm muốn biết nguyên mẫu làm gì, thiết kế của bộ định tuyến và công nhân hoạt động như thế nào, các số điểm chuẩn chứng minh được điều gì và không chứng minh được điều gì cũng như những điều cần kiểm tra trước khi đưa nó vào kho lưu trữ thực sự.
Một lưu ý trước khi chi tiết. Câu trả lời của nhân viên cho việc “sửa lỗi này” là một yêu cầu kéo và GitHub là nơi lý tưởng cho điều đó. Phần còn lại của những gì tác nhân tạo ra xung quanh mã khó đặt hơn: bản ghi nguyên nhân gốc rễ, bản tóm tắt kiểm tra, bảng so sánh mà người đánh giá yêu cầu.AgentGrid.iolà không gian làm việc chung, nơi mọi người và tác nhân AI tạo, chỉnh sửa và chia sẻ tài liệu, ứng dụng và tệp với một phiên bản trực tiếp, ghi công và lịch sử. Chúng tôi quay trở lại nơi nó phù hợp gần cuối.
DeepSeek Super-Agent là gì?
Hai thứ xuất hiện cùng nhau. Đầu tiên là một bài viết thiết kế dài, “Khám phá thiết kế siêu tác nhân: Hướng tới một hệ thống tác nhân tự chủ hơn”. Nhóm Harness đã viết nó bằng tiếng Trung và đăng phiên bản tiếng Anh do máy dịch trên X vào ngày 1 tháng 11. Nó đã được xem hơn 2,2 triệu lần. Thứ hai là mã:Nguyên mẫu deepseek-ai/dsh-superagent, được phát hành theo giấy phép MIT.
Khám phá thiết kế siêu tác nhân: Hướng tới một hệ thống tác nhân tự chủ hơn
– Khai thác DeepSeek (@DeepSeekHarness)Ngày 1 tháng 11 năm 2026
Nó không phải là một mô hình mới. dsh-superagent là gói dành choDây nịt DeepSeek, Khai thác tác nhân nguồn mở của DeepSeek, được công ty mô tả là ở bản xem trước công khai trên toàn thế giới. Gói này theo dõi một kho lưu trữ GitHub và nếu bạn bật nó lên, Feishu sẽ trò chuyện. Khi ai đó trong danh sách được phép yêu cầu tổng đài viên làm việc, nó sẽ mở một mục công việc, chạy mục đó trong phiên và thư mục riêng của nó, đồng thời trả lời trong cuộc hội thoại ban đầu. Một bảng điều khiển web chỉ hiển thị những gì một người cần.
Cái tên này dễ hơn âm thanh. Cui Tianyi, từ bộ phận sản phẩm của DeepSeek và là một trong những người đánh giá cuối cùng của bài viết, đã giải thích trong một bài đăng trên Zhihu rằng “siêu” có nghĩa là chỉ số trên và chỉ số dưới. Siêu tác nhân thêm một lớp phía trên tác nhân thực hiện công việc, ngược lại với tác nhân phụ, thêm một lớp bên dưới nó. Đó không phải là một tuyên bố về trí thông minh vượt trội.
README mở đầu bằng một cảnh báo đáng đọc đầy đủ: “Nghiên cứu nguyên mẫu chỉ để tham khảo, không phải sản phẩm DeepSeek chính thức.” Nó nói thêm rằng phần lớn kỹ thuật được thực hiện bởi các tác nhân mã hóa, mã có thể chứa lỗi và một số thiết kế trong bài viết là hướng dẫn cho công việc trong tương lai và không được triển khai.
| Trong nháy mắt | Nguyên mẫu dsh-superagent |
|---|---|
| Nó là gì | Tác nhân mã hóa chủ động cho một kho lưu trữ GitHub, được đóng gói dưới dạng gói Khai thác DeepSeek |
| Trạng thái | Nguyên mẫu nghiên cứu, “phần mềm chưa sẵn sàng sản xuất” theo README |
| Giấy phép | MIT |
| Ngôn ngữ | Kiểu chữ |
| Nghe | Sự cố GitHub, yêu cầu kéo, nhận xét và CI. Trò chuyện Feishu là tùy chọn |
| Đã tạo | Ngày 31 tháng 10 năm 2026. Hơn 12.000 ngôi sao và 1.200 fork tính đến ngày 2 tháng 11 |
| Làm thế nào để thiết lập nó | Yêu cầu tác nhân mã hóa của bạn đọc SETUP.md và cùng bạn thiết lập nó |
Một lần thả DeepSeek khác: dsh-superagent
Một khung tác nhân hoạt động song song thông qua các vấn đề GitHub của repo và PR với nhiều tác nhân, được thiết kế để thu hút ít sự chú ý của con người nhất có thể trong khi mang lại nhiều giá trị nhất có thể.
– Leandro von Werra (@lvwerra)Ngày 31 tháng 10 năm 2026
Tại sao DeepSeek cho biết nút thắt là sự chú ý của con người?
Bài viết bắt đầu từ một quan sát đơn giản. Trong năm qua, các tác nhân mã hóa đã đủ tốt để một nhiệm vụ duy nhất bị giới hạn bởi mô hình. Nhưng khi bạn thực hiện nhiều nhiệm vụ cùng một lúc, giới hạn đó sẽ thuộc về bạn. Mỗi phiên được tách biệt nên bạn có thể chuyển đổi giữa chúng theo cách thủ công và theo dõi những gì mỗi phiên biết. Việc gắn CLI, MCP hoặc trình kết nối trò chuyện vào một phiên cục bộ cho phép nó nghe về các sự kiện mới, nhưng nó vẫn chặn các lệnh dài, trộn lẫn ngữ cảnh từ các tác vụ khác nhau và dừng khi máy tính xách tay của bạn ở chế độ ngủ.
Câu trả lời của DeepSeek là ngừng coi phiên là đơn vị bạn quản lý. Nó liệt kê bốn đặc điểm mà một Siêu đặc vụ nên có:
- Liên tục.Bạn nói chuyện với nó ở nơi bạn đã làm việc, chẳng hạn như trò chuyện hoặc nhận xét GitHub và nó hoạt động giống như một tổng đài viên. Nếu bạn yêu cầu kế hoạch A trong cuộc trò chuyện và chuyển sang kế hoạch B trong nhận xét yêu cầu kéo, thì kế hoạch đó sẽ như sau.
- Năng suất.Nó chạy song song một số tác vụ phức tạp và nhận lệnh tiếp theo trước khi lệnh cuối cùng kết thúc.
- Chủ động.Nó theo dõi các sự kiện, hành động theo những gì đáng xử lý và giữ im lặng nếu không.
- Kiên trì.Nó vẫn trực tuyến và phục hồi sau các lỗi mà không cần bạn khởi động lại.
Các tác giả lập luận rằng không có vòng lặp ReAct nào có thể cung cấp cả bốn, vì vậy chất lượng phải đến từ kiến trúc xung quanh mô hình. Đó chính là chủ đề thực sự của bài viết và phần giải thích bằng hình ảnh bên dưới do Hesam chia sẻ là một cách nhanh chóng để xem toàn bộ thiết kế trên một trang.
đây là phần giải thích trực quan về bài viết của DeepSeek về Siêu đặc vụ:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)Ngày 1 tháng 11 năm 2026
Thiết kế bộ định tuyến và công nhân hoạt động như thế nào?
Hãy nghĩ về một người quản lý kỹ thuật giỏi, người không bao giờ viết mã trong thời gian chờ. cácbộ định tuyếnlà một phiên tồn tại lâu dài nhận mọi tin nhắn từ mọi kênh. Nó không chạy nhiệm vụ. Nó quyết định nội dung tin nhắn yêu cầu, giao công việc mới cho công nhân và viết mọi câu trả lời cho những người liên quan. Bài báo nói rằng nó có thể chạy mà không cần công cụ shell và một mẫu nhẹ hơn, nhanh hơn thường là đủ cho nó.
Acông nhânlà một phiên riêng biệt với bối cảnh riêng biệt và bộ công cụ đầy đủ, dành riêng cho một nhiệm vụ. Công nhân không bao giờ nói chuyện trực tiếp với mọi người. Họ báo cáo trạng thái cho bộ định tuyến và bộ định tuyến này sẽ trả lời bằng một giọng nói. Trong nguyên mẫu, mỗi vé có phiên riêng và thư mục riêng, thường là cây công việc git và số lượng nhân viên bị giới hạn. Mặc định là ba ô cùng một lúc, có thể điều chỉnh từ 1 đến 16, với một khe bổ sung được giữ trống để tin nhắn của một người luôn có thể được gửi qua.
Hai chi tiết làm cho việc này không chỉ là một hàng đợi nhiệm vụ.
Theo dõi bỏ qua bộ định tuyến.Khi một nhân viên sở hữu một yêu cầu kéo hoặc một chuỗi trò chuyện, nó sẽ đăng ký vào chuỗi đó. Các nhận xét sau đó sẽ đi thẳng vào nó mà không cần gọi thêm mô hình nào tới bộ định tuyến. Nếu một nhận xét hóa ra là về điều gì khác, nhân viên sẽ trả lại nó.
Các vụ nổ được chia theo đợt.Các trình kích hoạt đến trong một mô hình sẽ lần lượt xếp hàng và được đưa vào cuộc gọi tiếp theo. Các tác giả đã đo lường hiệu quả và chúng tôi xem xét những con số bên dưới.

Thêm một điểm tương phản nữa. Bài báo phân biệt điều này với Nhóm đại lý. Trong một nhóm tổng đài viên, người đứng đầu sẽ chia một nhiệm vụ phức tạp thành các bước và điều phối các vai trò thực hiện nhiệm vụ đó, đây là một công việc nặng nhọc về lý luận. Bộ định tuyến siêu tác nhân chỉ gửi các tác vụ độc lập và theo dõi mối liên hệ của chúng ở mức cao. Nó không tự phân hủy tác phẩm.
Nó làm gì khi không có ai hỏi?
Đây là nơi triết lý của dự án trở nên thực tế. Tài liệu đầu tiên trong kho nêu rõ nguyên tắc trong một dòng: thu hút càng ít sự chú ý của con người càng tốt và mang lại càng nhiều giá trị càng tốt. Mỗi tin nhắn mà tác nhân gửi đều tiêu tốn sự chú ý của đồng nghiệp, do đó, nó chỉ nói khi một người phải hành động hoặc có thể sử dụng một kết quả và nó chỉ hành động khi được yêu cầu hoặc khi quy tắc mà nhóm đã viết cho phép.
Cổng thực thi điều này là mã đơn giản, không phải mô hình. Nó kiểm tra xem ai đang yêu cầu dựa trên danh sách được phép của nhóm và ghi lại mức độ mạnh mẽ của yêu cầu:
| sức mạnh | Ví dụ từ các tài liệu | Chuyện gì xảy ra |
|---|---|---|
| rõ ràng | Một người trong danh sách được phép đề cập đến đại lý hoặc theo dõi một chủ đề đã có vé | Đại lý nhận công việc ở mọi chế độ |
| Suy ra | Một bot trong danh sách bot của Nguồn hoặc người theo dõi của một người chưa được liệt kê. Một tin nhắn không có địa chỉ mà nhóm đã chọn nhận | Đánh giá dựa trên các quy định bằng văn bản của đội. Ở chế độ quan sát mặc định, nó chỉ được ghi là “sẽ chấp nhận” |
| Không được thừa nhận | Bất kỳ bot nào khác, bất kỳ thứ gì mà bảng nhập học bỏ qua | Bị loại bỏ trước khi bất kỳ mô hình nào được gọi |
Chế độ quan sát đó là phần tôi thích nhất. Tác nhân bắt đầu bằng cách ghi lại những gì lẽ ra nó đã làm, để nhóm có thể đọc những bản ghi đó trên tab Đánh giá và chỉ mở rộng quyền của nó khi họ nhìn đúng. Tin nhắn, nhận xét và tài liệu được trích dẫn được coi là đầu vào cho một quyết định. Họ không thể thay đổi những gì người đại diện được phép làm.
Bài viết thiết kế cho thấy công việc chủ động trông như thế nào trong thực tế. Trong nhóm người dùng DeepSeek Harness nội bộ, nhóm đã định cấu hình chính sách “tái tạo và sửa lỗi một cách âm thầm”. Khi ai đó báo cáo sự cố hoặc thảo luận về một thay đổi được đề xuất, nhân viên sẽ cố gắng tái tạo nó và tìm cách khắc phục ở chế độ nền, đồng thời nó chỉ đưa ra kết quả sau khi đã xác nhận sự cố và tìm thấy cách khắc phục đơn giản. Còn không thì nó vẫn im lặng. Bài báo cũng đưa ra một quy tắc thẳng thắn đối với các kênh trò chuyện mà tác giả cho biết họ đã xác minh: giới hạn mỗi câu trả lời ở mức 100 từ. Ngược lại, trên GitHub, các yêu cầu kéo phải dày đặc, có nền tảng vấn đề, mô tả thay đổi và kết quả xác minh.
Theo mặc định, mọi tin nhắn GitHub mà nhân viên đăng đều bắt đầu bằng dòng “Đây là do tác nhân tự động thực hiện, không phải do con người thực hiện”. Các nhóm có thể chỉnh sửa nội dung đó cùng với các lời nhắc còn lại.
Các số liệu chuẩn có giữ vững không?
Bài viết bao gồm một thử nghiệm nhỏ và các tác giả cẩn thận gọi nó chỉ mang tính biểu thị. Bốn thiết kế chạy cạnh nhau trên một luồng tin nhắn trò chuyện nhóm và CI: khoảng 300 tin nhắn mỗi lần chạy, khoảng 20 trong số đó là yêu cầu công việc thực tế, mỗi lần 5 tin nhắn. Công việc viết mã được mô phỏng bằng một công cụ đơn giản chỉ tiêu tốn thời gian, do đó, bài kiểm tra đo lường việc lập kế hoạch và phối hợp chứ không phải chất lượng mã của bất kỳ ai.
| Thiết kế | Thời gian hoàn thành nhiệm vụ, p50/p95 (phút) | Mã thông báo đọc bộ đệm mỗi lần chạy |
|---|---|---|
| Siêu đại lý | 12,4 / 15,7 | 23,2 triệu |
| Siêu đại lý không có thông qua | 12,6 / 15,5 | 31,8 triệu |
| Phiên duy nhất với công cụ tác nhân phụ, lời nhắc trung lập | 20,4 / 29,5 | 6,1 triệu |
| Phiên duy nhất với công cụ đại diện phụ, lời nhắc ủy quyền | 13,8 / 29,0 | 10,8 triệu |
Hãy đọc bảng hai lần vì tiêu đề không phải là toàn bộ câu chuyện. Thiết kế bộ định tuyến đã cắt giảm thời gian hoàn thành p95 xuống còn khoảng một nửa thời gian của một phiên duy nhất, nhưng nó sử dụng khoảng hai đến bốn lần số mã thông báo đọc bộ đệm. Và hàng thú vị nhất là hàng thứ hai: việc loại bỏ phím tắt chuyển tiếp không làm cho tác vụ hoàn thành nhanh hơn hoặc chậm hơn, nó chỉ khiến bộ định tuyến thực hiện nhiều quyết định hơn khoảng 30% và đốt thêm 37% mã thông báo.
Tôi đọc được rằng phát hiện thực sự nằm ở các hàng trong một phiên. Với lời nhắc trung lập, mô hình không bao giờ gọi tác nhân phụ trong bất kỳ lần chạy nào trong năm lần chạy. Nó tự thực hiện công việc, các tin nhắn mới liên tục làm gián đoạn và các tác vụ chậm nhất mất 29,5 phút. Với lời nhắc yêu cầu nó ủy quyền, nó đã ủy quyền bốn trong số năm lần chạy và trong lần chạy còn lại, mô hình đánh giá công việc là “nhỏ” và tự thực hiện. Một phiên duy nhất phụ thuộc vào tâm trạng của người mẫu. Một bộ định tuyến không được phép chạy mã thì không thể mắc lỗi đó.
Chỉ riêng một bài kiểm tra căng thẳng riêng biệt trên bộ định tuyến đã nâng tỷ lệ xuất hiện của các sự kiện cần đưa ra quyết định từ khoảng 1 lên khoảng 40 mỗi phút. Lô trung bình tăng từ 1,0 lên 2,8 sự kiện, thời gian mỗi yêu cầu chỉ tăng từ 2,5 lên 3,9 giây và thời gian khấu hao cho mỗi quyết định giảm từ 6,4 xuống 1,6 giây. Càng nhiều sự kiện chồng chất, mỗi sự kiện càng rẻ, đạt đến giới hạn mà các tác giả cho biết phụ thuộc vào độ dài ngữ cảnh và số lượng sự kiện mà một mô hình có thể xử lý chính xác trong một lượt.
DeepSeek vừa cung cấp nguyên mẫu Siêu tác nhân có nguồn mở. Một phiên bộ định tuyến sẽ trao đổi với mọi người và phân công công việc, đồng thời các nhân viên bị cô lập sẽ chạy các tác vụ song song ngoài các sự kiện GitHub. Trong thử nghiệm của riêng họ, thời gian hoàn thành p95 giảm từ 29,5 xuống 15,7 phút so với một phiên sử dụng tác nhân phụ.
Cá voi lại mở nguồn.pic.twitter.com/mS4sRbHmyx
– Mũm mĩm (@kimmonismus)Ngày 1 tháng 11 năm 2026
Đây là những kết quả tự báo cáo về công việc tổng hợp. Họ cho thấy ý tưởng lập kế hoạch là đúng đắn. Chúng không cho thấy rằng nguyên mẫu sửa lỗi của bạn nhanh hơn.
Những người thân cận với dự án nói gì về giới hạn của nó?
Ngay sau khi phát hành, Cui Tianyi, từ bộ phận sản phẩm của DeepSeek và là một trong những người đánh giá cuối cùng của bài báo thiết kế, đã viết ra cách anh ấy nhìn nhận thiết kế. Việc đóng khung của anh ấy rất hữu ích vì nó khiêm tốn. Ông đặt tên cho sự cân bằng trọng tâm là tính liên tục giữa các nhiệm vụ so với thông lượng nhiệm vụ.
Về giới hạn, việc xem xét là trực tiếp. Nguyên mẫu chỉ thực hiện một phần của thiết kế được đề xuất. Theo đánh giá của anh ấy, DeepSeek Harness không có bộ nhớ dài hạn tích hợp trong các phiên. Và hệ thống chỉ được xác thực trong một môi trường nhỏ, đáng tin cậy trong công ty. Phần các vấn đề mở của bài viết liệt kê việc mở rộng bộ định tuyến, bộ nhớ trong nhiều tháng, hoạt động không có phiên, ranh giới ngữ cảnh giữa các tác nhân và cách các tác nhân bị cô lập nên nói chuyện với nhau cũng như bảo mật.
Bạn nên kiểm tra những gì trước khi chạy nó?
Tài liệu này thẳng thắn hơn hầu hết các bài đăng khởi chạy và đáng để coi các cảnh báo của nó là yêu cầu.
- Người lao động có quyền truy cập rộng rãi.Cả hai cài đặt trước về quyền, cho bộ định tuyến và cho nhân viên, đều chạy với
danger-full-accessvới tư cách là người dùng hệ điều hành của nhà điều hành. Trình bao bọc tài khoản chọn thông tin xác thực GitHub mà tác nhân sử dụng, nhưng tài liệu cho biết chúng là mặc định chứ không phải ranh giới bảo mật, vì một nhân viên vẫn có thể chạy chương trình theo đường dẫn tuyệt đối hoặc đọc thư mục chính của bạn. Đề xuất là một tài khoản hệ điều hành chuyên dụng chỉ chứa thông tin xác thực của đại lý. - Đầu vào không đáng tin cậy là câu hỏi bảo mật mở.Bài viết cảnh báo rằng nếu một thao tác tiêm nhắc hoặc xâm nhập máy chủ làm tổn hại đến vòng lặp tác nhân đám mây thì mọi thiết bị được kết nối đều có thể bị truy cập và thông tin xác thực đi vào ngữ cảnh của mô hình có thể bị rò rỉ.
- Con người hợp nhất theo mặc định.Đại lý không bao giờ cho phép tự động hợp nhất trong tài khoản của chính mình. Tự động hợp nhất cần có CLI của tài khoản thứ hai có tên trong lời nhắc Yêu cầu phân phối và hướng dẫn mặc định chỉ cho phép điều đó đối với các yêu cầu kéo nhỏ, được phê duyệt dưới 200 dòng đã thay đổi.
- Nó được xây dựng xung quanh một kho lưu trữ.Mỗi thiết lập theo dõi một kho lưu trữ GitHub duy nhất và Feishu, một công cụ trò chuyện tại nơi làm việc phổ biến ở Trung Quốc, là nguồn hạng nhất khác.
- Bạn cần Bộ khai thác DeepSeek và nhà cung cấp mô hình.Danh sách thiết lập Node.js 22.19 trở lên, pnpm, git 2.32 trở lên, tmux, Python 3.8 trở lên và GitHub CLI 2.48 trở lên. Định cấu hình nhà cung cấp mô hình là một bước của người vận hành.
- Tiếng ồn là một chi phí.Tài liệu triết học nói không sử dụng tác nhân để sản xuất khối lượng. Các yêu cầu kéo hàng loạt và tin nhắn quảng bá khiến nhóm của bạn tốn nhiều tiền hơn những gì họ đưa ra.
Bạn sẽ thử nó như thế nào mà không gây rủi ro cho kho lưu trữ chính của mình?
Quá trình thiết lập có nhiều bước nên dự án yêu cầu bạn để một nhân viên mã hóa thực hiện việc đó cùng bạn. Theo README, nhân viên sẽ hỏi mỗi lần một câu hỏi ngắn, hiển thị toàn bộ kế hoạch một lần, sau đó cài đặt và định cấu hình mọi thứ. Lần chạy đầu tiên thận trọng trông như thế này:
- Chọn một kho lưu trữ dùng một lầnvà một người dùng máy chuyên dụng hoặc tài khoản hệ điều hành. Không sử dụng thông tin đăng nhập của riêng bạn.
- Tạo tài khoản GitHub riêng cho đại lý.Mọi thứ nó viết đều xuất hiện dưới cái tên đó.
- Mở kho lưu trữ trong tác nhân mã hóa của bạn và dán lời nhắc bên dưới.Trả lời từng câu hỏi một.
- Giữ danh sách được phép cho riêng mìnhvà để chế độ chấp nhận ở trạng thái quan sát.
- Yêu cầu một cái gì đó nhỏ.Từ một tài khoản được phép, bình luận
@<agent login> <request>về một vấn đề. Một yêu cầu sẽ xuất hiện trên phần Tổng quan của bảng điều khiển trong vòng khoảng một phút. - Đọc tab Đánh giá trong một tuần.Mở rộng danh sách hoặc chỉ chuyển sang tự động khi bản ghi “sẽ chấp nhận” có vẻ ổn.
Tài liệu triết lý của dự án cung cấp cho người vận hành bốn quy tắc đáng được nhắc lại: bắt đầu thu hẹp, điều chỉnh để ít tiếng ồn hơn, không sử dụng tác nhân để tạo âm lượng và sở hữu những gì nó nói trong tên của bạn.
Phần công việc còn lại của đại lý nên đi đâu?
Giả sử một công nhân dành một giờ cho bài kiểm tra tích hợp không ổn định. Yêu cầu kéo là cách khắc phục. Nhưng cuộc điều tra đằng sau nó, thử nghiệm nào thất bại, giả thuyết nào bị loại trừ, bảng thời gian cho thấy gì, không thuộc mô tả PR và đó chính xác là điều mà người đánh giá muốn thách thức. Nếu nội dung đó chỉ tồn tại trong câu trả lời trò chuyện thì nhân viên hỗ trợ hoặc đồng đội tiếp theo sẽ bắt đầu lại từ đầu.
AgentGrid.iođược xây dựng cho sự chuyển giao đó. Con người và tác nhân AI làm việc trên cùng một tài liệu, ứng dụng và tệp trực tiếp với một địa chỉ ổn định, quyền truy cập được kiểm soát và lịch sử phiên bản. Tài liệu của AgentGrid.io mô tả việc kết nối một tác nhân có khả năng ra lệnh bằng cách chạynpx @animaapp/cli@latest login. Con người phê duyệt tên, nhóm của tác nhân và những gì nó có thể làm: đọc, viết, chia sẻ hoặc xuất bản. Sau đó, những thay đổi của tác nhân sẽ xuất hiện trong lịch sử dưới tên riêng của nó. Nguyên mẫu không có tích hợp AgentGrid.io tích hợp, vì vậy hãy coi đây là một mẫu để thử với các nhân viên của nó chứ không phải một tính năng được ghi lại.
Trong thực tế, nhân viên viết cuộc điều tra của mình dưới dạng tệp Markdown, người đánh giá nhận xét trên một hàng trong bảng, một trợ lý khác thắt chặt phần tóm tắt và yêu cầu kéo liên kết đến một phiên bản hiện tại thay vì ba bản sao được dán.
Đối với một trường hợp khác về việc nhiều người chia sẻ một đại lý, hãy xem hướng dẫn của chúng tôi vềBot nhóm Grok Bot. Và nếu bạn thắc mắc điều gì chạy bên dưới một tác nhân được lưu trữ, hướng dẫn của chúng tôi vềClaude Managed Agentsxem xét phiên bản phân chia não và tay tương tự của Anthropic, mà bài báo của DeepSeek đã trích dẫn.
Khi nào bạn nên sử dụng dsh-superagent và khi nào khác?
- Sử dụng dsh-superagentđể học hỏi từ một thiết kế nghiêm túc, được ghi lại, để chạy thử nghiệm có sẵn trên kho lưu trữ có rủi ro thấp hoặc mượn ý tưởng của nó: bộ định tuyến không bao giờ chạy mã, vé có phạm vi đã nêu, chế độ quan sát trước chế độ tự động.
- Sử dụng một tác nhân mã hóa tương tác duy nhấtkhi bạn làm từng việc một và muốn chỉ đạo từng bước một. Siêu đặc vụ được xây dựng cho tình huống ngược lại.
- Sử dụng AgentGrid.iokhi đầu ra là một tài liệu, báo cáo hoặc ứng dụng mà nhiều người và đại lý cần xem xét, chỉnh sửa và xuất bản thì bất kỳ đại lý nào sản xuất ra nó.
Câu hỏi thường gặp
DeepSeek Super-Agent là gì?
Nó là nguyên mẫu nghiên cứu có tên dsh-superagent, được phát hành bởi nhóm Khai thác của DeepSeek vào ngày 31 tháng 10 năm 2026 theo giấy phép MIT. Nó là một tác nhân mã hóa chủ động cho một kho lưu trữ GitHub. Một phiên bộ định tuyến tồn tại lâu dài sẽ nhận các yêu cầu và chỉ định mỗi yêu cầu được chấp nhận cho phiên hoạt động riêng của nó, phiên này sẽ trả lời trong cuộc hội thoại ban đầu, thường bằng một yêu cầu kéo.
DeepSeek Super-Agent có phải là sản phẩm DeepSeek chính thức không?
Không. README gọi nó là nguyên mẫu nghiên cứu chỉ để tham khảo chứ không phải là sản phẩm DeepSeek chính thức, đồng thời yêu cầu xem xét và điều chỉnh nó trước khi sử dụng nó trong môi trường của riêng bạn. Nó cũng không giống với phiên bản nội bộ hoặc cách triển khai mà bài viết thiết kế mô tả.
Siêu đại lý khác với đại lý phụ như thế nào?
Tác nhân phụ thêm một lớp bên dưới tác nhân đang hoạt động. Một siêu tác nhân thêm một lớp phía trên nó. Trong thiết kế này, bộ định tuyến nằm phía trên nhiều công nhân, nói chuyện với mọi người và phân công nhiệm vụ, trong khi mỗi công nhân xử lý một nhiệm vụ riêng biệt. Cái tên này nói về chức vụ chứ không phải tuyên bố về trí thông minh cao hơn.
Nó cần Feishu hay chỉ GitHub?
Chỉ GitHub là đủ. Feishu là nguồn thứ hai tùy chọn và tài liệu cho biết lỗi thiết lập Feishu chỉ vô hiệu hóa nguồn Feishu.
Có an toàn khi chạy trên kho lưu trữ của công ty không?
Không như hiện tại. Các tài liệu cho biết các công nhân chạy với toàn quyền truy cập với tư cách là người dùng hệ điều hành của nhà điều hành và các tài khoản trình bao bọc không phải là ranh giới biệt lập. Họ đề xuất một tài khoản hệ điều hành chuyên dụng, một tài khoản đại lý chuyên dụng trên GitHub, một danh sách ngắn được phép và chế độ quan sát trong khi bạn tìm hiểu cách hành xử của đại lý.
Nó có nhanh hơn một phiên tác nhân mã hóa không?
Trong thử nghiệm mô phỏng của chính tác giả, thiết kế bộ định tuyến đã hoàn thành các tác vụ chậm nhất trong 15,7 phút so với 29,5 phút cho một phiên duy nhất bằng công cụ tác nhân phụ, sử dụng nhiều mã thông báo hơn. Thử nghiệm sử dụng công việc mã hóa mô phỏng và năm lần chạy cho mỗi thiết kế, do đó, nó cho thấy lợi ích về việc lập kế hoạch chứ không phải chất lượng mã.

Figma
Adobe XD


