DeepSeek 最近公開的 dsh-superagent（通稱 Super Agent）被不少媒體寫成「超級代理」「下一世代寫碼機械人」。只看標題，很容易以為是聊天式 bot、或 Grok／Manus 一類「對話就辦事」產品。
實際上卻完全不一樣：Super Agent其實是掛在 DeepSeek Harness（dsh） 上的研究原型外掛，不是成熟的產品，只針對單一 GitHub 倉庫做主動式 coding 自動化——聽取 Issue／@ 提及（可選擇利用字節跳動（ByteDance）開發的 AI 辦公協同與企業管理平台飛書）作監視、依 Policy 開 Ticket、建立獨立 session 與目錄執行，再以留言或 Pull Request 回覆。
按照 Super Agent 的 README 形容：Research prototype for reference only, not an official DeepSeek product。本文依官方原型說明，以及編輯部在 Apple Silicon Mac Mini（16 GB）上安裝，以考察其實用性，並對照 Cursor（包括 Cloud Agents）與 OpenAI Codex 這類已進入日常寫碼流程的框架——研究目標不是說「誰更強」，而是研究 Super Agent 想解決什麼問題、能不能取代現在的源碼開發環境。
Super Agent 回應什麼：長任務，不是另一個聊天 bot
近一年，寫碼 AI 的競賽軸線從「單次補全」移到「長跑」：任務要跨多檔、多步驟、可中斷再續，又不能把整個上下文一次塞爆。OpenAI Codex 與 Claude Code 等產品／工具鏈，都在強化「自行長跑、少中斷」能力。DeepSeek 賭注則押在 Harness 外掛 + Router／Worker 分 session：主路徑負責路由與治理，worker 在獨立目錄跑執行，用 Ticket／Mandate 把「誰准許、做了什麼、要人接手」寫進可監督的狀態機，不少人說 Harness 已死，因為大模型已吃掉 Harness 不少功能， Super Agent 卻要讓 Harness 再次重生。
因此，若以 Super Agent 跟「開對話框就能當助理」消費級 agent 比較，可以說風馬牛不相及，用戶要具備一定編程能力。Super Agent 的產品更接近於以下流程：先綁定單一庫的 GitHub ops／coding 自動化，預設安靜，先從最簡單的範圍開始自動化，而且自動化工具平時要保持安靜，只有在真正發生嚴重錯誤時才打擾人類——以少佔用人類注意力、只在規則允許或有人明確呼叫， Super Agent 才會進場，實際上與「日常主編寫環境」並不重疊，更不是取代。
工作流：Source → Eval → Ticket → Executor → Channel
文件與實機設定的循環大致以下：
- Source：以 GitHub 為主（可選監聽飛書的用戶要求），監聽 Issue、留言、@ bot。觸發條件成立時，自己在背景「獨立開闢工作目錄」去默默幹活，自動嘗試重現 Bug、修改程式碼、跑測試，最後直接提交 Pull Request (PR) 等待人類審查。
- Trigger／Eval：對照 Policy、允許名單與 accept mode（
off／observe／auto）。初測通常只建議會用observe模式：系統可以判斷「會不會接單」，或者只記 would accept，並不真正馬上開工，降低誤接與短時間內大量發送重複、相同或無意義的訊息。 - Ticket／Mandate：通過後才開工作單，賦予可審核的任務邊界。
- Executor：每個 Ticket 有獨立 worker session 與工作目錄；Router preset 負責任務調度，Worker 跑長命令（前景指令逾時會轉背景，以便繼續收訊息）。
- Channel：回到原對話以留言或 PR 交付；Web Panel 列出「需要人」「健康狀態」「單件歷程」。
名單內用戶明確 @ bot 時，各 accept mode 通常仍可進場——這把「默認安靜」與「人要時能叫到」拆開，是設計裡少數寫得像營運手冊、而不只像 demo 的地方。
Mac Mini 實機：跑得通，營運工作量不輕
編輯在 Mac Mini（Apple Silicon、16 GB、環境已備 Node 22／pnpm／tmux／GitHub CLI）把 dsh 與 prototype，驗證這條營運鏈是否可落地：
換句話說：在 16 GB 本機上，「專用 profile + bot + 測試庫 + health ready」已可重現；但依賴 tmux、本機常駐進程、金鑰與邀請流程——更像給團隊一個營運小型服務，不是下載即用的寫碼碼客戶端。利用 Harness，本機記憶體不足，問題也隨之出現。
優勢：邊界、治理、注意力經濟
若只用「能不能幫我寫功能」衡量，Super Agent 未必贏過你已在用的 Cursor／Codex。比較有說服力的，是把幾件寫源碼 agent 常忽略的事情，寫進了架構：
- 單庫的工作邊界很清楚，只是集中單程式庫——適合「Issue → 修補 → PR」的自動化，而不是同時橫跨十個客戶項目同時工作。
- Policy／admission／Mandate——誰可以發起、以什麼模式接單，可以審核。
- observe 先行——先看會不會亂接單，再打開 auto。
- Dedicated bot identity——機器人留言與人類貢獻者分開，審計上較清楚。
- Supervision panel——適合加入「需要人接手」的營運情況，不是完全自動化。
- Harness plugin 模型——orchestrator 與 worker 分 session，對長任務與上下文膨脹是有意識的工程選擇（見 Harness）。
Super Agent 的產品標語是：Take as little human attention as possible, and give as much value as possible. 在 agent 動輒 @ 全頻道的年代，系統把「安靜」寫成預設，本身就是一種立場，需要時才介入。
限制：原型、單庫、不是完整 IDE
直按說其弱點，我們要避免 Super Agent 研究原型寫當成是正式產品，離正式發佈 還有距離：
- 官方自標 research prototype，非 production-ready；——離代表「裝得起來」與「穩到可託付生產庫」仍有距離。
- 單 repo；跨庫日常編排非不如 Cursor Cloud Agents 的完整。
- 營運的工作負擔過重：tmux、bot GitHub、金鑰、invite、專用 profile，學習曲線都高於利用普通的 IDE agent。
- 本機進程：離線與記憶體是約束因素。
- Observe-first 意味著真實閉環往往要人
@bot；不會魔法式地「自己把公司所有 Issue 做完」。 - 能力偏向 coding／GitHub 自動化，與「寫碼主環境」重疊有限——這不是缺陷，而是定位。
對標 Cursor／Codex：重疊在 PR，市場定位並不相同
Super Agent 可能不是 Cursor／Codex 作為「主寫碼環境」的對手。 三者都可能「自主開 PR」，但產品要回答的主問題不同。
| 維度 | Super Agent | Cursor（含 Cloud Agents） | OpenAI Codex |
|---|---|---|---|
| 型態 | Harness 研究原型；本地專用 profile | 商業 IDE + Agent；雲端 VM | CLI／編輯器／雲端／整合 |
| 主場景 | 一庫 issue／@ → Ticket → PR | 編輯器寫碼 + 並行 agent、多庫 | 終端迴圈、CI、雲端任務 |
| 治理 | 獨立 bot + Policy／observe | 產品側帳號／環境較完整 | ChatGPT／API／工作區管控 |
| 介面 | Harness Web panel | IDE + Web／行動等 | Terminal／IDE／雲端 UI |
| 成熟度 | 自標 research | 持續產品擴充 | 開源 CLI + 商業雲端 |
公開文件可對照：dsh-superagent-prototype、Cursor Cloud Agent、OpenAI Codex。若問「會不會取代我每天開的編輯器」，依目前證據傾向否，仍是有一段距離；若問「單一關鍵庫要不要試一個由 issue 驅動的安靜 bot」，答案可以是值得實驗——前提是你接受風險與本機營運的成本。
這也解釋為何媒體若只用「對標 Claude Code／Codex」框架報導，容易高估短期替代性、低估中期的治理與注意力設計參考價值。後者，才是 DeepSeek 這次開源原型較可能留下的東西——尤其對已在用 DeepSeek 模型、又想把 agent 行為關進倉庫邊界的開發團隊。
DeepSeek 能帶來真正差異嗎？架構有沒有前途？
短期產品差異：有限。 在「穩定、好裝、能當日常主環境」上，Cursor／Codex 仍遙遙領先；Super Agent 也明確不是要填那個坑，解決那個未知難題，將其說成「擊敗某某」無公開對照實驗，也不符合產品的 README 自述。
中期架構差異：值得觀察的是以下幾點。 Router／Worker、Ticket 狀態機、observe 預設、獨立 bot 身分———回應了「長任務如何少崩潰、少刷屏、可審計」。若 Harness 把外掛與監督面板產品化，DeepSeek 比較可能做出差異化產品，另外是開源可改的 repo 級營運層，而不是再做一個聊天窗。
實用性判斷可以總結如下：
- 面向單一 GitHub 倉庫的主動式 coding agent 原型，以 Ticket／Policy／Panel 組織人機協作。
- 「少佔用人類注意力」寫進架構：默認 observe、允許名單、獨立 bot。
- 與 Cursor／Codex 重疊的 issue／PR 自動化功虯；若問能否取代主要的 AI 開發源碼環境，現時答案仍傾向於否定。