DeepSeek Harness 團隊於 10 月 31 日晚間發表長文〈Super-agent 設計探索：邁向更自主的 Agent 系統〉，提出一套雙層 Agent 架構，並在 GitHub 公開原型 dsh-superagent-prototype。團隊在文中註明，這個原型是用來驗證技術路線，並非 DeepSeek 的正式產品。
文章的出發點是一個很樸素的觀察：模型單獨完成一項任務所需的人工介入越來越少，卡住生產力的變成了人的注意力。依團隊的說法，一個人通常只能同時追蹤 3 到 5 個活躍 Session，任務一多就得手動來回切換、自己記住上下文。
Session 應該是系統的實作細節，不該是使用者的認知負擔。
Router 管對話，Worker 管幹活
架構分為兩層。常駐的 Router 層負責接收人的訊息、維護全域上下文、分派任務，它不帶 Bash 這類執行工具，可以用輕量模型驅動。Worker 層由多個上下文彼此隔離的 Session 組成，掛載完整工具、使用最強的模型，各自專注於一件事並行執行。Worker 不直接回覆使用者，狀態與結果都先回報給 Router，由 Router 統一對外說話。
另外幾塊設計圍繞著「讓 Agent 一直在線」展開：
- 事件驅動：群組訊息、電子郵件、行程提醒、程式碼審查留言、CI 結果都算 Trigger，先用程式規則濾掉大部分雜訊，剩下的才交給模型判斷要不要行動；已分派過的 Thread，後續事件由程式直接投遞給對應的 Worker，不再經過 Router。
- 非同步 ReAct Loop：耗時的工具呼叫拆成 start() 和 stop()，背景任務啟動後立刻回傳 Started，前台繼續接使用者的話，結果則作為新事件回到 Session。
- 運算、狀態與環境分離：Agent Loop 和狀態放在雲端，執行環境可以留在使用者本機，只跑一個輕量 daemon，支援自帶機器（BYOM）。
- Watchdog：一個獨立的 Session 定時醒來，除了檢查程序是否還活著，也讓模型判斷每個 Worker 有沒有實質進展、方向有沒有跑偏。
文中還舉了「投機執行」的例子：群組裡有人回報了一個 bug，Agent 先在背景嘗試重現並修復，修好了才開口，沒修好就不打擾人。
數字只來自合成負載
團隊做了一組對照實驗：每輪約 300 則訊息，其中約 20 則是工作請求，其餘是閒聊與雜訊，每種方案重複 5 次。Super-agent 完成任務的耗時 p50 為 12.4 分鐘、p95 為 15.7 分鐘；對照組「單一 Session 加 Subagent」在中性提示下 p95 為 29.5 分鐘。拿掉事件直通機制後，Router 的決策次數多出約 30%，快取讀取 token 多出約 37%。
Router 壓力測試中，Trigger 從每分鐘約 1 則增加到約 40 則，平均批次大小從 1.0 升到 2.8，單次請求耗時從 2.5 秒漲到 3.9 秒，攤到每個決定上的推論時間反而從 6.4 秒降到 1.6 秒。
限制也寫得很直白：實驗使用的是合成負載與簡化環境，只衡量調度與協作，不衡量單一任務做得好不好；Super-agent 的 token 開銷高於單一 Session 方案，但總量並未揭露。開源原型目前只面向單一 GitHub 儲存庫，跨裝置、雲端常駐和 Watchdog 都沒有完整實作。
從 dsh 到 Super-agent
把時間線串起來看，DeepSeek 在 Agent 這條線上是先釋出框架、再釋出調度思路。今年 8 月前後，它以 MIT 授權開源了 Agent 框架 DeepSeek Harness（命令列名稱 dsh），檔案系統、Shell、模型適配、Web UI 和子代理都做成可替換的外掛；隨後幾個月，V4.1 Flash 等模型陸續上線，第三方程式開發工具也開始拿它當主力模型。
這次的長文又往上走了一層，討論的已經是「一個 Agent 實例怎樣同時盯著幾十件事」。團隊透露，文中的非同步任務機制已經寫進 DeepSeek Harness，只是預設沒有開啟；基於同一思路的內部實例一直在運行，用來重現與修復問題、回應程式碼審查，也用來迭代 Harness 本身。
團隊列出的待解問題包括 Router 層如何隨任務量擴展、跨月的長程記憶、多個 Agent 實例之間的通訊。安全一項寫得最具體：雲端 Agent Loop 一旦被提示詞注入，接入的本機裝置可能遭到控制，放進模型上下文的憑證也可能在正常執行中外洩。這些風險要如何防範，文中並未給出完整方案。
參考來源：DeepSeek Harness 團隊技術長文與 dsh-superagent-prototype 儲存庫說明、IT之家、CocoLoop、鳳凰網科技；實驗耗時、壓力測試數據以團隊公布的合成負載結果為準。