DeepSeek 開源 dsh-superagent 原型：平時不打擾，寫完程式碼直接提 PR

用過 AI 寫程式碼的人，大概都體會過那種被訊息轟炸的疲憊。AI 改兩行程式碼就彈一個確認，報錯了要你切視窗看日誌，多開幾個會話之後，程式設計師反而成了給 AI 跑腿的專職客服和記事本。

DeepSeek 團隊開源的 dsh-superagent-prototype，想解決的就是這個痛點。它是一個面向單個 GitHub 倉庫的智慧體實驗原型，核心邏輯非常簡單：平時在後臺安安靜靜待命，只有真需要人類拿主意，或者程式碼寫完準備提交 PR 時，才出來吱一聲。

別把程式設計師當成會話切換器

現在的程式碼智慧體能力越來越強，但大多停留在「一個會話處理一個任務」的模式。這個視窗修 Bug，那個視窗看 CI，一旦並行任務多起來，人的注意力就被徹底切碎了。

DeepSeek Harness 團隊給出的解法是 Super-agent 架構。使用者只需要面對一個統一的入口，底層由系統去調配多個獨立的 Worker 在隔離的會話和目錄裡幹活。

它接入了 GitHub，還可以選配飛書通知，並帶有一個網頁管理面板。只要有許可權的團隊成員下達需求，或者觸發了提前寫好的自動化規則，它就會默默開工。

研究團隊在內部測試過一個場景：群聊裡有人反饋了 Bug，哪怕完全沒有艾特它，智慧體也能識別出問題，嘗試在後臺復現、修程式碼，並直接把修復後的 PR 提上來。整個過程只要不需要人做決策，它就絕不亂髮訊息刷存在感。

還是研究原型，坑還不少

雖然聽起來很省心，但官方把話說得很坦白：這只是一個參考性的研究原型，絕對不是 DeepSeek 的正式產品。

有意思的是，這個專案大部分工程程式碼本身就是由 AI 編寫的。官方直言裡面的程式碼風格並不統一，可能到處藏著 Bug，需要開發者自己審查和調整。

此外，論文構想中的部分能力在這個原型裡還沒完全落地。團隊驗證的重點是任務排程與多工協作效率，並不是說底層模型寫程式碼的水平突然突飛猛進。

他們也列出了一長串還沒解決的硬傷，比如跨月的長程記憶、大規模 Worker 協同、許可權隔離、提示詞注入攻擊，以及雲端智慧體控制本地環境可能帶來的安全隱患。

為什麼重要

我們認為，DeepSeek 這個原型最聰明的地方，在於它把精力從「死磕程式碼生成正確率」挪開了一點，轉向了真正卡住工程落地的「人類注意力瓶頸」。

當模型推理能力達到及格線之後，如何讓 AI 像個靠譜同事一樣低調幹活，遠比它一秒回十條訊息更重要。對於中小團隊或獨立開發者來說，這種「無事不擾、有結果直接提 PR」的工作流，才是智慧體該有的樣子。

但目前它顯然不適合直接扔進生產環境。不僅許可權控制和安全隔離機制還不成熟，雲端接入本地倉庫的風險也不容忽視。現在去試它的開發者，最好把它當成一套探索非同步研發協作的架構參考，而不是開箱即用的自動化工具。