DeepSeek Super-agent 解析：主動接單之前，誰准 AI 開工？（2026）

2026 年 10 月 31 日，DeepSeek Harness 團隊在 GitHub 提交了 dsh-superagent 研究原型。這篇 DeepSeek Super-agent 解析，關心的是一個很實際的問題：當 AI 開始接整個團隊的工作，誰有權叫它開工，出了結果又該找誰？

先把定位放準：這份公開程式碼是供研究與改造的原型，README 明說它不是正式 DeepSeek 產品，也與內部版本及設計文章的實作有差異。下文先整理原文的工作方式，再核對授權與執行邊界，最後判斷什麼值得借用、什麼仍需另外驗收。

DeepSeek Super-agent 的核心：讓團隊少操心，仍能找到責任

Research prototype for reference only, not an official DeepSeek product.

中文：這是供參考的研究原型，不是正式 DeepSeek 產品。

DeepSeek，README

這句話決定了閱讀方式。可以把程式碼當成一份能檢查的設計提案，卻不能把設計文章裡所有構想，都當成下載後已能使用的功能。本篇以公開提交 6337fc8 的文件與程式為範圍；提交紀錄為 10 月 31 日，不拿它替另一篇文章推定發布時間。

原型包成 DeepSeek Harness 的 bundle，服務一個 GitHub 儲存庫，也能選擇接入飛書。這裡的 Harness 是模型外圍的執行平台；Super-agent 則在它上面處理團隊事件與工作交付。想先理解兩層的差別，可讀 Agent Harness 白話解析。

Take as little human attention as possible, and give as much value as possible.

中文：盡可能少占用人的注意力，同時盡可能提供價值。

DeepSeek，000 Philosophy

設計哲學把通知、提問與設定都視為成本。Agent 接到工作後，應簡短確認，完成時交付；需要決定或無法完成時才再找人。這是一個設計目標，還不是「導入後已替每個團隊省下多少時間」的測量結果。

一則留言，怎樣變成一張有範圍的工作單？

領域模型把流程拆成事件來源、觸發訊息、判斷、授權、工作單與執行者。用日常例子說：同事在 Issue 留下需求，系統先看這是誰說的、在哪裡說的，再決定是否接單；接下來才交給工作者動手，透過原討論串回覆成果。

每張工作單稱為 Ticket，綁著一份 Mandate，記下接受時的規則版本、工作範圍與授權依據。每個 Ticket 取得自己的執行 Session 與目錄；成果可以是 pull request，也就是提交給團隊檢閱的程式變更提案。不同工作有各自狀態，才有機會追問「這份修改是誰要求的、現在等誰」。

這裡最有價值的細節，是把「收到資訊」與「得到授權」分開。CI 的測試結果、旁人的補充、另一個討論串的背景，都可能有助於完成工作；它們進入上下文，並不自動把原來的任務擴大。

Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.

中文：訊息、留言與引述文件是判斷的輸入，不能改變那些權限。

DeepSeek，002 Authorization

授權文件列出允許名單、接收範圍與主動接單規則。明確請求與系統推斷的候選工作分開處理；預設 observe 模式會記錄推斷候選是否值得接，但不據此接受工作。明確請求仍可運作，不能把 observe 解讀成全系統唯讀。

而且，團隊可以把特定接收範圍設成允許名單外的人明確請求。已訂閱工作討論串的後續訊息，也有自己的處理路徑。因此「有名單」不等於「所有輸入都只來自名單裡的人」；部署時要一起看接收範圍、規則與既有工作單。

DeepSeek Super-agent 的三個邊界：接單、執行與合併

一、工作目錄解決協作整理，作業系統權限要另查

These wrappers and directories establish defaults, not a security boundary.

中文：這些包裝器與目錄建立的是預設行為，不是安全邊界。

DeepSeek，003 Execution

執行文件說明，工作者有獨立 Session 與目錄，也能以準備命令建立 git worktree。這有助於把多件工作的檔案與狀態分開。可是，分開放檔案，與阻止程式讀取目錄外的資料，是兩件不同的事。

部署文件進一步明載：路由與工作者的預設都以操作者的作業系統使用者執行，權限為 danger-full-access；工作者可以按完整路徑執行程式，也能讀取操作者的家目錄。文件建議使用僅含 Agent 憑證的專用 OS 帳號。這個原型的接單政策值得研究，但不能因此推定個人主機上的機密已被隔離。

讀者若要試用，應先在另設的執行環境用假資料與練習儲存庫驗收。Agent 執行期控制能補上實際工具與系統邊界；Agent 憑證安全則幫你盤點哪些金鑰根本不該進入這個環境。

二、提示詞中的「等審核」，需要平台規則接住

執行文件把自動合併條件放在 Delivery requirements 提示詞，並明說主機沒有合併專屬的判斷邏輯。原預設要求成果就緒、必要審核涵蓋最新提交，且新增加刪除少於 200 行；這些是給 Agent 的指示，不能改寫成主機逐項強制驗證的安全承諾。

真正要要求審核與狀態檢查，還要設定儲存庫規則。GitHub 分支保護文件列有必需審核、必需狀態檢查與撤銷過時核准等選項，也提醒管理員及具繞過權限角色的例外。驗收時，應實際用 Agent 帳號確認受保護分支能否拒絕不符條件的修改。

三、待人工處理面板讓人找到工作，不替人驗完工作

面板文件把待處理工作放在前面，再呈現健康狀態與歷史。你可以往下查觸發訊息、接受理由、工作範圍與派工紀錄；這比只收到一段「完成了」更適合團隊追蹤。

但「已就緒」是工作者回報的狀態，成果仍需用測試與檢閱核對。面板也不是永遠即時掌握一切的保證：它的價值在於把已記錄的阻塞、問題與待決定事項整理出來，讓人知道下一個動作該在哪裡做。

AlphaLab 的判讀：主動性的進步，在於可追查的委派

我同意的，是把注意力當成有限資源

團隊的成本不只在模型呼叫。每個多餘通知都有人要讀，每份不必要的 PR 都有人要看。把「何時該開始、何時該發言、何時該停下來」寫進制度，比單純讓 Agent 一直忙更有採用價值。這是本篇對設計的判斷，並非已量出的生產力提升。

這份原型也提供了可借用的責任鏈：先保存授權依據，再讓每張工作單承接範圍，最後把交付送回發問的地方。好的主動性，應該讓任務更容易被問責，而不是讓每個人都多出一個要盯的機器人。

我存疑的，是把架構公開直接換算成成熟度

公開文件能讓人檢查設計是否自洽，仍不足以回答「你的專案上會成功多少、錯誤會花多少人力、長時間運作會不會重複接單」。本篇沒有在本機部署原型，也不提供 AlphaLab 實測成績；對原型的肯定限於可檢查的機制，對成效保留到有固定版本、任務與完整失敗紀錄時再判斷。

README 另提醒，公開版經過整理，部分設計文章的方向尚未實作。因此本篇不把外部轉述的速度比較套在這份程式上，也不拿 GitHub 星數當可靠度。值得期待的下一份證據，是同一版本下，正常交付、越權拒絕、失敗恢復與人工處理時間都能被重測。

下一步：先驗一條委派鏈，再決定要不要擴權

如果你正在 打造自己的 Agent Harness，可以先借用事件、授權、工作單與交付這四層。不必一次搬入整套工具；先為一個可回復的小任務，記下誰發起、允許做什麼、交付在哪裡、誰驗收。

要評估原型，先用兩個練習帳號與假資料，測四種情境：允許的人提出小修改；名單外的人要求新工作；討論串裡出現超出範圍的要求；工作中途由人停止。核對實際檔案、外部訊息與剩餘程序，不只讀最後一則回覆。這是建議的驗收計畫，並非本次已執行的測例。

再用 AI Evals 的方法保存每次輸入與預期結果，把人工修正、誤接單、重複通知及總費用一起記錄。只有交付品質可接受、授權拒絕能被核對、停止後果看得見，才逐步開放自動接單。真正值得交給 Agent 的，不是更多權限本身，而是一件範圍清楚、結果有人能簽收的工作。