如何評估 DeepSeek 超級智慧體修 Bug：4 個驗證重點

DeepSeek Harness 團隊描述過一個內部協作案例：工程師在群組訊息中回報問題、討論修改方向時，Super-agent 會在背景嘗試重現缺陷、尋找簡單修法；只有判斷問題成立且找到可行修補，才提交 Pull Request（PR，合併請求）供人檢視。這是團隊分享的內部使用經驗，說明系統想把「看到事件、開始調查、交付修補」串起來，並非獨立測試證實它能穩定修好程式。

對正在使用 AI 程式工具的團隊來說，值得追問的是：它怎麼在不同任務間保留脈絡？提出的 PR 有沒有重現原始錯誤、通過測試並符合權限規範？DeepSeek 把這種持續在線、事件驅動與多工執行的設計稱為 Super-agent（超級智慧體）。理解這個名稱，不如先拆解背後的任務分工與驗收方式。若要先從低風險工作開始，也可參考如何挑選適合先試的 AI 代理任務。

團隊案例呈現的是協作流程，還不是修補成效保證

團隊案例顯示，代理可以被設計成持續接收開發事件、背景調查並把候選修補交回原工作渠道；它沒有提供足以證明修補正確率或生產環境可靠性的獨立數據。

傳統對話式程式代理通常等工程師貼上錯誤訊息，再按指示逐步處理。DeepSeek 團隊的設計探索則想讓 Agent（代理）持續接收群組訊息、GitHub Issue、程式碼審查留言或 CI（持續整合）結果等事件。當群組正在討論 Bug 時，系統可先在背景進行重現與診斷，將結果整理成 PR，再回到原有的對話或 GitHub 工作流程。這種「投機執行」是先做可丟棄的準備，最後只交付值得人處理的結果。

DeepSeek Harness 團隊表示，內部 Super-agent 已參與日常問題重現與修復、程式碼審查回覆，以及 Harness 本身的迭代。這些是團隊自述，未揭露成功率、失敗案例或人工返工量，不能當成獨立效能評測。

公開的 dsh-superagent 原型範圍較窄。DeepSeek AI 的 README 將它定位為研究原型，並非正式產品；公開版本經過調整，與內部實作不同，部分設計也尚未實作。原型可監看單一 GitHub 儲存庫、選擇接入飛書，並在授權者提出請求後建立工作項目，在獨立工作階段和目錄處理，再回覆原對話。詳見官方原型說明。

因此，「團隊用過」不代表其他團隊可直接部署。採用前仍須檢查依賴、授權、權限、工作環境與維護方式；設計文章也不代表所有功能都已出現在公開程式碼裡。

Router 與 Worker 分工，讓對話不中斷並行工作

Router 維持跨任務的整體脈絡並負責判斷與派工；Worker 各自在隔離的工作階段中執行特定任務，再把狀態和結果交回 Router。

Router 接收各渠道事件、判斷是否形成任務，再把工作交給 Worker。若它親自執行長時間測試，對話和派工都可能等待；因此設計讓 Router 維持全域資訊、負責協調，Worker 專注執行，最後由 Router 統一回覆。

Worker 在隔離脈絡下並行處理不同 Issue、PR 審查或功能開發，避免任務細節混在同一對話。若多項工作碰到同一 PR 或檔案，仍可能衝突；訂閱討論串可同步更新，但不能取代工作流規則與人工檢查。

Trigger（觸發事件）可來自群組訊息、郵件、行事曆提醒、程式碼審查留言或 CI 結果。程式規則先過濾，再由代理判斷是否派工。Worker 訂閱 Thread（討論串）後，可直接收到後續留言，不必每次回到 Router；但訂閱或範圍判斷錯誤，也可能讓資訊進入錯誤脈絡。

設計文章以初步實驗檢視排程。一組合成負載約有 300 則訊息，約 20 則是工作請求，其餘為閒聊、追問、取消和 CI 通知。每個方案跑 5 次，程式工作以耗時工具代替。

Super-agent 的任務完成時間中位數為 12.4 分鐘、p95 為 15.7 分鐘；使用中性提示詞的單一 Session 加 Subagent 方案，p95 為 29.5 分鐘。這組數字反映合成環境中的排程與協作時間，不是程式修補正確率，也不是正式產品實測。若想理解沙盒如何限制代理接觸程式碼和工具，可延伸閱讀AI 代理沙盒的權限設計與限制。

「Research prototype for reference only」是 DeepSeek AI 對公開程式庫的定位，適合當作架構參考，不等於可直接上線的產品。

修 Bug 要從重現問題走到可審查的 PR

修 Bug 的交付至少要重現原問題、驗證修補與回歸情況，再由有權限的人審查 PR；代理提出改動本身不代表可以合併。

一個可檢查的流程從問題描述開始。Worker 應先整理使用者看到的錯誤、發生條件與預期結果，再在隔離分支或工作目錄重現問題。若無法重現，應回報需要補充的環境或步驟，而不是直接改動程式。重現成功後，代理需要說明根因假設、修改範圍與可能受影響的模組，並執行能覆蓋原問題的測試。

測試需回答兩個不同問題：原本失敗的案例是否轉為通過？新增修補是否讓既有功能出現回歸？CI 綠燈只能說明特定測試集通過，不能證明所有使用情境都正確。PR 描述應清楚列出重現方式、改動內容、測試結果和仍未知的風險，讓維護者能快速判斷是否需要補測或要求修改。

授權也要與任務綁定。這類代理可能讀取原始碼、Issue、群組訊息，並操作憑證或執行環境。應只開放必要的儲存庫與指令權限，避免把秘密直接放進模型可讀內容，並記錄觸發來源、執行命令、檔案變更和外部操作。事件驅動會接觸更多不可信輸入，像是 Issue 文字或留言內的提示注入內容；代理不能因讀到一段訊息，就把它當成提升權限或外傳資料的指令。

官方執行文件將每個 Ticket 配置給獨立的 Executor Session 與工作目錄，也說明狀態、背景工作、重試和重啟恢復。文件提醒，命令包裝器和目錄不能取代安全邊界。工作階段可能以操作系統使用者身分執行命令，部署前要確認帳號可讀寫的路徑、工具和憑證注入方式。試行前也要檢查授權條款、相依項目與維護狀態。PR 應受分支保護、必要審查與回復程序管理。

DeepSeek 原型執行文件提醒，命令包裝器與目錄「establish defaults, not a security boundary」，權限隔離必須由實際執行環境落實。

設計文章的實驗與公開原型有明確邊界

目前資料能說明特定合成負載下的排程表現，以及公開原型預定的工作方式；它們沒有測量跨專案修 Bug 正確率、長期可靠性或完整導入成本。

另一組 Router 壓力測試以真實模型處理 Router、以模擬模型處理 Worker，將需判斷的 Trigger 從每分鐘約 1 則增至約 40 則。團隊報告平均批次由 1.0 增至 2.8，每次請求耗時由 2.5 秒增至 3.9 秒，每個決策分攤的推理時間則由 6.4 秒降至 1.6 秒。測試呈現事件合併處理的可能性，沒有測量程式修補能力。

團隊也列出擴充 Router、跨月記憶、代理間共享邊界等未解問題。雲端協調程式連上含私有原始碼、憑證或內網服務的環境後，提示注入或權限錯誤可能擴大影響；這些風險尚不能視為已由公開原型解決。

還要看設計與公開實作的落差。設計文章包含跨渠道工作、持續在線、非同步任務和 Watchdog 等方向；公開原型的 README 則明確提醒，有些文章中的設計是未來方向，沒有實作於該版本。執行文件可協助理解 Ticket、工作目錄、背景任務、重試及恢復方式，但產品成熟度、不同專案表現、維運成本和安全性，仍需團隊自行評估。

導入前先用低風險任務量出品質與成本

從單一儲存庫與容易重現、影響範圍小的 Bug 開始，將代理限制在隔離分支和最小權限，保留人工審查，再用可比較的指標決定是否擴大。

1. 挑任務：選取有明確重現步驟、測試環境和預期結果的低風險 Issue，排除涉及個資、金流、權限系統或重大服務的改動。
2. 設權限：以隔離分支或工作目錄執行，授予讀取必要程式碼、執行測試與建立 PR 的權限；先關閉自動合併，檢查憑證和外部網路存取。
3. 記錄基準：逐案記下問題重現成功與否、測試是否覆蓋原錯誤、CI 通過情況、人工審查時間、返工次數、失敗恢復情況，以及維護這套整合所花的工時。
4. 對照人工流程：以類似難度的任務比較交付時間與審查成本，同時檢視代理是否產生多餘改動、漏報失敗或重複執行外部操作。
5. 訂擴大門檻：只有在修補品質、權限紀錄、錯誤回復和整體成本都符合團隊要求後，才增加任務種類或並行數；每次改動權限或接入新渠道，都重新檢查風險。

評估修補率、人工審查與返工時間、失敗恢復能力，以及授權與維護成本。只看 PR 產量會把產出誤當品質；省下的編碼時間若被查錯和維護流程抵銷，就沒有實際效益。

DeepSeek 的架構探索將跨任務協調交給 Router，讓 Worker 專注執行。團隊可先用一個範圍小、可重現、可回復的 Bug，檢查代理能否走完重現、修補、測試與審查，再以數據判斷是否擴大。

• 公開原型是研究參考，部分設計尚未實作。
• 排程實驗不等同修 Bug 正確率評測。
• 先以隔離分支、最小權限和人工審查試行。

常見問題

Q1: DeepSeek 超級智慧體是已正式推出的產品嗎？

DeepSeek AI 公開的 dsh-superagent 標示為研究原型，供參考使用，並非正式產品；官方也提醒公開版本與內部實作不同，部分設計尚未實作。

Q2: Router 和 Worker 有什麼差別？

Router 維持整體任務脈絡、判斷事件並派工；Worker 在隔離的工作階段處理特定任務，再回報結果。這是設計上的職責分工，實際部署仍要檢查狀態同步與權限設定。

Q3: 代理提出 PR 後可以自動合併嗎？

不宜只因代理提出 PR 就自動合併。應先確認問題重現、測試與人工審查結果，並由分支保護規則與回復機制控制合併權限。

Q4: 怎麼判斷是否適合導入？

用低風險、可重現的 Bug 試行，記錄修補正確率、測試通過、人工審查與返工時間、失敗恢復及整合維護成本，再與既有人工流程比較。