DeepSeek Harness 團隊喺 10 月 31 日發表技術文章《Super-agent 設計探索：邁向更自主的 Agent 系統》，講一個「超級 AI 代理」點樣指揮另外幾個 AI 幫你做嘢。重點唔係模型有多勁，而係整個代理系統點樣從「你問佢答」變成「佢自己發現問題、自己排工、自己交貨」。
一個 AI 當主管，多個 AI 同時開工
呢個架構嘅核心係「Router + Worker」兩層設計。Router 係長駐嘅協調節點，接住群組、GitHub、Email 等平台嘅訊息，判斷任務要分俾邊個 Worker，然後維護跨任務嘅上下文。Worker 有獨立嘅上下文同工具，負責具體執行——復現 Bug、審代碼、開發功能，甚至可以再呼叫 Sub-agent。
用户看到嘅永遠係同一個「AI 助手」，但背後可能已經有好幾個獨立 Agent 同時運行。為咗省 Token，DeepSeek 仲引入訂閲機制：某個 Worker 接手咗某個 GitHub Pull Request，後續評論可以直接送到佢，唔使再經 Router。
無人 @，佢自己識做
最惹眼嘅，係所謂「主動性」：群組訊息、Email、CI 測試結果都係觸發 Agent 行動嘅「Trigger」。DeepSeek 用咗兩級過濾——程式規則先斬無關訊息，再交大模型判斷係咪需要回應。更進一步，佢哋引入「投機執行」：喺結果未確定時，先用後台算力試嚇，有價值嘅先出街。
內部有一個「靜默復現並修復」策略：當群組有人報 Bug 或討論改動，Super-agent 會喺後台預先復現問題、分析原因、揾修復方案。只有確認問題存在、且修復路徑簡單，先會提交結果俾開發者，否則全程靜默。佢哋展示嘅案例係：團隊仲喺討論，Super-agent 已經喺後台提交咗修復 Pull Request。
關機都繼續，但費 Token
為解決「電腦離線任務就斷」嘅問題，DeepSeek 將執行迴圈放喺雲端，會話狀態存資料庫，本地只需一個輕量 daemon。電腦重新上線，任務可以繼續。另外仲有獨立嘅 Watchdog——一個 AI 監督員，專偵測任務有冇進展、係咪陷入死循環，發現異常就嘗試修復。
效能測試方面，佢哋用模擬嘅群組 + GitHub CI 訊息流（約 300 條訊息，其中約 20 條係真正工作請求），各重複跑五次。Super-agent 嘅 p50 完成時間係 12.4 分鐘、p95 係 15.7 分鐘；傳統單 Session 加 Sub-agent 嘅 p95 係 29.5 分鐘。但代價係：取消事件直通後，Router 嘅決策量增加約 30%，總快取讀取從 2,323 萬增加到 3,177 萬 Token，增幅約 37%。
阿調搞兩下
呢個設計嘅邏輯很清楚：人負責定目標同驗收，AI 負責排工同執行。問題係，當 Router 本身係由一個 LLM 驅動，「判斷任務應分配」呢個決定嘅可靠性點樣保證？仲有，投機執行雖然慳時間，但後台算力消耗算邊個？呢個係 DeepSeek 嘅內部工程探索，仲非獨立產品，部分設計有開源原型。值得跟住睇佢哋點樣將呢套架構產品化，以及 Router 嘅決策透明化做到幾深。
