DeepSeek Super-Agent：它是什麼，它是如何運作的，以及仍然缺少什麼3 min read

一下子打開三個編碼代理就可以感覺到問題了。一個正在等待決定，一個在二十分鐘前完成，而您已經忘記了哪個具有身份驗證修復。 DeepSeek 的 Harness 團隊給出了一個數字：根據其經驗，一個人一次只能專注於三到五個活躍的代理會話。過了這個點，模型就不再是瓶頸了。你是。

2026 年 10 月 31 日，團隊發表了一篇名為「超級代理商」的設計文章，並開源了一個名為 dsh-superagent 的原型。它是一個 GitHub 儲存庫的主動編碼代理。一個長期存在的路由器會話與人們交談並分發工作，每個接受的請求都有自己的工作會話，以拉取請求或問題結束。該存儲庫在大約兩天內就超過了 12,000 顆星。它的自述文件直言不諱地說這是研究代碼而不是官方的 DeepSeek 產品。

本指南適用於想要了解原型的作用、路由器和工作器設計如何運作、基準測試資料能證明什麼和不能證明什麼以及在將其指向真實儲存庫之前需要檢查什麼的工程師和團隊領導。

在詳細資訊之前先註釋一下。工作人員對「修復此錯誤」的回答是拉取請求，而 GitHub 是一個很好的家。代理程式圍繞程式碼產生的其餘內容更難放置：根本原因記錄、測試摘要、審查者要求​​的比較表。AgentGrid.io是一個共享工作空間，人們和人工智慧代理可以在其中建立、編輯和共享文件、應用程式和文件，並具有即時版本、歸屬和歷史記錄。我們回到接近尾聲的地方。

什麼是 DeepSeek Super-Agent？

两件事同时出现。第一篇是一篇很長的設計文章，「探索超級代理設計：邁向更自治的代理系統」。 Harness 團隊用中文編寫了它，並於 11 月 1 日在 X 上發布了機器翻譯的英文版本。該版本的瀏覽量已超過 220 萬次。第二个是代码：deepseek-ai/dsh-superagent-原型，根據麻省理工學院許可發布。

探索超級代理商設計：邁向更自治的代理系統

https://t.co/gwwIHtyCRQ

– DeepSeek 安全帶（@DeepSeekHarness）2026 年 11 月 1 日

這不是一個新模型。 dsh-superagent 是一個捆綁包DeepSeek 线束，DeepSeek 的開源代理工具，該公司將其描述為在全球範圍內公開預覽。該捆綁包監視一個 GitHub 儲存庫，如果您將其打開，Feishu 會進行聊天。當允許清單中的某人向代理請求工作時，它會打開一個工作項，在自己的會話和目錄中運行它，並在原始對話中進行回答。網路面板僅顯示需要人員的內容。

這個名字比聽起來更容易。 DeepSeek 產品部門的崔天一（也是該文章的最終審稿人之一）在知乎貼文中解釋說，「超級」的意思是上標與下標。超級代理在執行工作的代理上方添加了一層，與子代理相反，子代理在其下方添加了一層。這並不是聲稱擁有卓越的智力。

自述文件開頭有一條值得完整閱讀的警告：「研究原型僅供參考，不是官方 DeepSeek 產品。」它補充說，大部分工程是由編碼代理完成的，代碼可能包含錯誤，並且文章中的一些設計是未來工作的方向，並未實現。

另一個 DeepSeek 掉落：dsh-superagent

一個代理框架，可與多個代理並行處理存儲庫的 GitHub 問題和 PR，旨在盡可能減少人工關注，同時提供盡可能多的價值。

pic.twitter.com/XR73mLvA0V

– 萊安德羅‧馮‧韋拉 (@lvwerra)2026 年 10 月 31 日

為什麼DeepSeek說瓶頸是人類注意力？

文章從一個簡單的觀察開始。在過去的一年裡，編碼代理已經足夠好了，單一任務受到模型的限制。但是，一旦您同時執行多個任務，限制就會轉移到您身上。每個會話都是隔離的，因此您可以手動在它們之間切換並追蹤每個會話所了解的內容。將 CLI、MCP 或聊天連接器連接到一個本地會話可以讓它聽到新事件，但它仍然會阻塞長命令，混合來自不同任務的上下文，並在筆記型電腦休眠時停止。

DeepSeek 的答案是停止將會話視為您管理的單位。它列出了超級特工應具備的四個特質：

• 連續的。您可以在已經工作的地方與它交談，例如聊天或 GitHub 評論，它的行為就像一個代理。如果您在聊天中詢問計劃 A 並在拉取請求評論中切換到計劃 B，則會出現以下情況。
• 富有成效。它並行運行多個複雜任務，並在最後一個指令完成之前執行下一條指令。
• 積極主動。它觀察事件，對值得處理的事情採取行動，否則保持安靜。
• 堅持不懈。它會保持在線狀態並從故障中恢復，而無需您重新啟動它。

作者認為，沒有一個 ReAct 循環可以提供所有四個功能，因此品質必須來自模型周圍的架構。這是本文的真正主題，Hesam 分享的下面的視覺解釋器是在一頁上查看整個設計的快速方法。

這是 DeepSeek 關於超級代理的文章的直觀解釋：https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)2026 年 11 月 1 日

路由器和worker設計如何運作？

想像一下一位優秀的工程經理，他在站立期間從不寫程式碼。的路由器是一個長期會話，接收來自每個通道的每個訊息。它不運行任務。它決定訊息的要求，將新工作交給工作人員，並將每個回應寫給相關人員。文章稱它完全可以在沒有 shell 工具的情況下運行，並且更輕、更快的模型通常就足夠了。

一個勞工是一個單獨的會話，具有隔離的上下文和一整套工具，專門用於一項任務。工人從不直接與人交談。它們向路由器報告狀態，路由器以一種聲音進行答案。在原型中，每個票證都有自己的會話和自己的目錄（通常是 git 工作樹），並且工作人員數量是有上限的。預設值是一次三個，可在 1 到 16 之間調整，並保留一個額外的插槽，以便一個人的消息始終可以通過。

有兩個細節使其不僅僅是一個任務隊列。

後續跳過路由器。一旦工作人員擁有拉取請求或聊天線程，它就會訂閱該線程。後面的評論直接進入它，沒有在路由器上進行額外的模型呼叫。如果評論結果是關於其他事情，工作人員會將其退回。

突發被分批處理。在一個模型期間到達的觸發器會排隊並一起注入到下一個呼叫中。作者測量了效果，我們來看看下面的數字。

又一個對比點。本文將其與代理團隊區分開來。在代理團隊中，領導者將一項複雜的任務分解為多個步驟並協調處理該任務的角色，這是一項繁重的推理負擔。超級代理路由器僅分派獨立任務並追蹤它們如何在高層關聯。它不會分解工作本身。

當沒人問時它會做什麼？

這就是該項目的理念變得實用的地方。儲存庫中的第一個文件用一句話闡述了這個原則：盡可能少地關注人類，並提供盡可能多的價值。代理人發送的每個訊息都會引起同事的注意，因此只有當一個人必須採取行動或可以使用結果時它才會說話，並且只有在被詢問或團隊編寫的規則允許時才會採取行動。

強制執行此操作的門是純程式碼，而不是模型。它檢查誰在團隊的允許清單中提出請求，並記錄請求的強度：

觀察模式是我最喜歡的部分。代理首先記錄它會做什麼，這樣團隊就可以在 Eval 選項卡上讀取這些記錄，並僅在它們看起來正確時擴大其權限。訊息、評論和引用的文件被視為決策的輸入。他們不能改變代理人被允許做的事情。

設計文章展示了主動工作在實踐中的樣子。在內部 DeepSeek Harness 使用者群組中，團隊配置了「靜默重現和修復」策略。當有人報告問題或討論提議的更改時，代理會嘗試重現該問題並在後台找到修復程序，並且只有在確認問題並找到簡單的修復程序後才會提供結果。否則它會保持安靜。文章也對聊天頻道給出了一條直言不諱的規則，作者稱他們已經驗證過：每個回應的字數上限為 100 個字。相較之下，在 GitHub 上，拉取請求應該是密集的，包含問題背景、變更描述和驗證結果。

預設情況下，代理程式發布的每個 GitHub 訊息都以「這是由自動代理程式發送，而不是人類發送的」行開頭。团队可以编辑该内容以及其余提示。

基准数字是否成立？

這篇文章包括一個小實驗，作者謹慎地稱其僅供參考。四種設計在群組聊天和 CI 訊息流上並排運行：每次運行約 300 個訊息，其中大約 20 個是實際工作請求，每次運行 5 次。編碼工作是透過一個簡單消耗時間的工具來模擬的，因此測試衡量的是調度和協調，而不是任何人程式碼的品質。

請閱讀該表格兩遍，因為標題並不是故事的全部。路由器設計將 p95 完成時間減少到單一會話的一半左右，但它使用了大約兩到四倍的快取讀取令牌。最有趣的一行是第二行：刪除直通快捷方式並不會使任務完成得更快或更慢，它只是使路由器多做約 30% 的決策並多消耗 37% 的代幣。

我的解讀是，真正的發現位於單一會話行中。在中性提示的情況下，該模型在五次運行中從未呼叫過子代理程式。它自己完成工作，新訊息不斷打斷它，最慢的任務需要 29.5 分鐘。在提示讓它進行委派的情況下，它在五次運行中進行了四次委派，在剩餘的運行中，模型判斷工作「小」並自行完成。单次训练取决于模特的心情。不允許運行程式碼的路由器不會犯這樣的錯誤。

僅對路由器進行單獨的壓力測試就將需要做出決策的事件的到達率從每分鐘約 1 個提高到約 40 個。平均批次從 1.0 個事件成長到 2.8 個事件，每個請求的時間僅從 2.5 秒增加到 3.9 秒，每個決策的攤餘時間從 6.4 秒下降到 1.6 秒。事件堆積得越多，每個事件的成本就越低，作者表示，其上限取決於上下文長度以及模型在一輪中可以準確處理的事件數量。

DeepSeek剛剛開源了其超級代理原型。一個路由器會話與人們交談並分發工作，獨立的工作人員在 GitHub 事件之外並行運行任務。在他們自己的測試中，與使用子代理的單一會話相比，p95 完成時間從 29.5 分鐘下降到 15.7 分鐘。

鯨魚再次開源。pic.twitter.com/mS4sRbHmyx

– 胖胖的（@kimmonismus）2026 年 11 月 1 日

這些都是綜合工作的自我報告結果。他們表明調度想法是合理的。它們並沒有表明原型可以更快地修復錯誤。

熟悉該計畫的人士對其限制有何評價？

發布後不久，來自DeepSeek產品部門、設計文章最終審稿人之一的崔天一寫下了他對設計的看法。他的框架很有用，因為它很謙虛。他將核心權衡稱為任務的連續性與任務吞吐量。

對於限制，審查是直接的。該原型僅實現了所提議設計的一部分。根據他的審查，DeepSeek Harness 沒有跨會話的內建長期記憶。而且該系統僅在公司內部的小型可信環境中得到驗證。本文自己的開放問題部分列出了路由器的擴展、幾個月的記憶體、無會話工作、代理之間的上下文邊界以及隔離的代理應如何相互通信以及安全性。

運行前應該檢查什麼？

該文件比大多數發布貼文更加坦率，值得將其警告視為要求。

• 工人有廣泛的接觸機會。路由器和工作人員的兩個權限預設都運行danger-full-access作為運營商的作業系統用戶。帳戶包裝器選擇代理程式使用的 GitHub 憑證，但文件稱它們是預設值，而不是安全邊界，因為工作人員仍然可以透過絕對路徑運行程式或讀取您的主目錄。建議使用僅儲存代理憑證的專用作業系統帳戶。
• 不受信任的輸入是開放的安全問題。該文章警告說，如果即時注入或伺服器入侵損害了雲端代理循環，則每個連接的設備都可能被訪問，並且進入模型上下文的憑證可能會洩漏。
• 人類預設會合併。代理程式永遠不會在自己的帳戶下啟用自動合併。自動合併需要在交付要求提示中指定第二個帳戶的 CLI，並且預設說明僅允許在 200 行更改以下的小型、已批准的拉取請求。
• 它是圍繞一個存儲庫構建的。每個設定都會監視一個 GitHub 儲存庫，而 Feishu（中國常見的工作場所聊天工具）是另一個一流的來源。
• 您需要 DeepSeek 線束和模型提供者。安裝程式列出 Node.js 22.19 或更高版本、pnpm、git 2.32 或更高版本、tmux、Python 3.8 或更高版本以及 GitHub CLI 2.48 或更高版本。配置模型提供者是操作員步驟。
• 噪音是一種成本。哲學文件說不要使用代理人來產生體積。大量拉取請求和廣播訊息使您的團隊付出的代價比他們付出的要多。

您將如何嘗試而不冒主儲存庫的風險？

設定有很多步驟，因此該專案要求您讓編碼代理與您一起完成。根據自述文件，代理一次詢問一個簡短的問題，顯示完整的計劃，然後安裝和配置所有內容。謹慎的第一次運行如下所示：

1. 選擇一個一次性儲存庫以及專用機器使用者或作業系統帳戶。不要使用您自己的登入名稱。
2. 為代理程式建立單獨的 GitHub 帳戶。它所寫的所有內容都出現在該名稱下。
3. 在編碼代理中開啟儲存庫並貼上下面的提示。一次回答一個問題。
4. 將允許的清單保留給自己並將接受模式保留為觀察。
5. 要求一些小東西。從允許的帳戶發表評論@<agent login> <request>在一個問題上。大約一分鐘內，票證就會出現在面板的概述中。
6. 閱讀 Eval 選項卡一周。僅當「願意接受」記錄看起來正確時才擴大清單或切換到自動。

Read SETUP.md in this repository and set up dsh-superagent with me.

該專案的理念文件為運營商提供了四個值得重複的規則：開始範圍狹窄，調整噪音較小，不要使用代理來產生音量，並以您的名義擁有它所說的一切。

代理的其餘工作該去哪裡？

假設一名工作人員花了一個小時進行不穩定的整合測試。拉取請求就是修復。但背後的調查，哪些測試失敗了，哪些假設被排除了，時間表顯示了什麼，不屬於 PR 描述，而這正是審稿人想要挑戰的。如果這只存在於聊天回覆中，那麼下一個代理商或隊友將從頭開始。

AgentGrid.io是為這種切換而建構的。人類和人工智慧代理處理相同的即時文件、應用程式和文件，具有一個穩定的地址、受控的存取和版本歷史記錄。 AgentGrid.io 的文檔描述了透過執行來連接具有命令功能的代理npx @animaapp/cli@latest login。人工批准代理的名稱、團隊及其可以執行的操作：閱讀、寫作、分享或發布。之後，代理程式的變更會以自己的名義出現在歷史記錄中。原型沒有內建的 AgentGrid.io 集成，因此請將其視為與其工作人員一起嘗試的模式，而不是錄製的功能。

在實踐中，工作人員將其調查寫入 Markdown 文件，審閱者對錶行進行評論，另一位助手收緊摘要，拉取請求鏈接到一個當前版本而不是三個粘貼的副本。

有關多人共享一個代理的另一種看法，請參閱我們的指南Grok Bot 團隊機器人。如果您想知道託管代理程式下面運行什麼，我們的指南Claude Managed Agents看看 Anthropic 的相同大腦和雙手分裂的版本，DeepSeek 的文章引用了這一點。

什麼時候應該使用 dsh-superagent，什麼時候該使用其他東西？

• 使用dsh-superagent從嚴肅的、記錄的設計中學習，在低風險儲存庫上運行包含的實驗，或藉用其想法：從不運行程式碼的路由器、具有規定範圍的票證、在自動模式之前的觀察模式。
• 使用單一互動式編碼代理當您一次執行一項任務並希望逐步指導時。超級代理是針對相反的情況而建構的。
• 使用 AgentGrid.io當輸出是文件、報告或應用程式時，需要多個人員和代理進行審查、編輯和發布，無論是哪個代理程式產生的。

常見問題

什麼是 DeepSeek Super-Agent？

它是一個名為 dsh-superagent 的研究原型，由 DeepSeek 的 Harness 團隊於 2026 年 10 月 31 日在 MIT 許可下發布。它是一個 GitHub 儲存庫的主動編碼代理。長期存在的路由器會話接收請求並將每個接受的請求分配給自己的工作會話，該工作會話在原始對話中進行應答，通常使用拉取請求。

DeepSeek Super-Agent是DeepSeek官方產品嗎？

不。自述文件稱其為僅供參考的研究原型，而不是官方的 DeepSeek 產品，並表示在您自己的環境中使用它之前要對其進行審查和調整。它也與內部版本或設計文章所描述的實現不同。

超級代理與次級代理有何不同？

子代理程式在工作代理程式下面增加了一層。超級代理在其之上添加了一層。在這種設計中，路由器位於許多工作人員之上，與人們交談並分派任務，而每個工作人員獨立處理一項任務。這個名字是關於地位的，而不是聲稱更高的智慧。

需要Feishu還是只需要GitHub？

單獨使用 GitHub 就足夠了。 Feishu 是可選的第二來源，文件稱 Feishu 設定失敗僅停用 Feishu 來源。

在公司儲存庫上運作安全嗎？

不是原樣。文件稱，工作人員以操作員作業系統使用者的完全存取權運行，且包裝器帳戶不是隔離邊界。他們建議使用專用作業系統帳戶、GitHub 上的專用代理帳戶、簡短的允許清單和觀察模式，同時您可以了解代理的行為方式。

它比單一編碼代理會話更快嗎？

在作者自己的模擬測試中，路由器設計使用更多令牌，在 15.7 分鐘內完成了最慢的任務，而使用子代理工具的單一會話則需要 29.5 分鐘。該測試使用模擬編碼工作，每個設計運行五次，因此它顯示了調度優勢，而不是程式碼品質。