群裡有人說了個 bug，AI 已經遞上修復程式碼。沒人 @ 它。
這是 DeepSeek Harness 團隊展示的內部案例。AI 持續讀群聊，發現問題後在後台復現、修復，再把 Pull Request 交給開發者審查。
Pull Request 就是等人審閱的程式碼改動。提交了，不等於合併了。
10 月 31 日，團隊公開了這套超級智能體（Super-agent）的設計思路，並放出部分原型程式碼。
它要接管的，是人手動切窗口、轉述要求、盯住進度的活。一個人面對同一個助手，背後可以有多個 AI 同時做事。
這篇講的是團隊怎樣設計這套系統。下面順著群聊裡的這條 bug，看它怎樣從一句反饋走到程式碼審查。
誰接話，誰幹活
可以把這套 AI 想成一個小團隊。一條反饋先到主管那裡：他記著大家手頭的活，決定交給誰，再統一回覆人。這個角色叫 Router。
實際幹活的是 Worker，像各有分工的同事：一個復現 bug，一個審程式碼，一個開發功能。每個都有自己的工作記錄。
修 bug 時碰到的報錯、試過的辦法，都留在這個任務裡，不會擠進其他任務的記錄。Worker 忙不過來，還能再找 AI 幫手。
主管留在前台接話。修復交給同事去跑，人來問進度時，就不用等一條耗時命令先跑完。
常見的 AI 團隊，是幾個人合做一件難事。這裡先給不同的事各找一個負責人；每件事需不需要再分工，由負責人決定。
官方認為，負責派活的 Router 往往用輕量模型就夠，幹活的 Worker 則需要更強的執行能力。這是配置思路，不是必須照抄的組合。
後續評論直接找經手者
群裡的閒聊、問題回報，先經過程序規則。程序先按來源、群組範圍和允許名單，濾掉不符條件的消息。
剩下需要理解意思的消息，再交給模型決定是否行動。系統不用為每句閒聊都認真想一遍。
等修復任務有了負責的 Worker，相關 GitHub 評論也會不斷進來。每條都找 Router 重新分派，就有點像每次追問都得先找總台。
DeepSeek 把同一個話題、同一個 PR 下的消息歸成一串，叫 Thread。像給工單貼上標籤，負責這件事的 Worker 可以訂閱這串消息。
之後有人追問或補充，程序就直接把消息送給經手的 Worker。事情變了、超出原任務範圍，再找主管重新安排。
Router 仍能看到全域，Worker 的關鍵結果也仍向它匯報。消息少繞一程，不等於取消授權或各自對外發言。
“之前那件事”怎樣找回來
人不會每次都貼全聊天記錄。到了 GitHub，可能只留一句：按群裡剛才說的改。
系統得先弄清“剛才”是那段，負責的人又做到那裡了。
它不會把所有歷史一直攤在窗口裡。近期可能用到的資訊直接帶上；太長、暫時用不上的，留下摘要和編號。
真要找細節，就順著編號翻：這條消息是那張工單裡的，工單交給誰，那位同事又收到了那條程式碼審查意見。
每次讀到的內容，都帶著下一步的線索。像從一張工單翻到相關記錄，不必先搬來整個檔案櫃。
人從群聊換到 GitHub 後，系統仍有辦法追到原來的任務。
工具在跑，人還能改要求
任務執行中，如果人又說：先別修了，換個方案。
常見的呼叫方式是，模型發出一條耗時命令，等命令結束後才繼續。新的要求也跟著排隊。
非同步呼叫就像把下載放到後台：啟動工具後先回一句“已啟動”，工具繼續跑，對話不用一直等著。做完後，結果再送回來。
這樣，AI 想完眼前這一步，就能接著看你的新消息，不必等後台命令跑完。模型也能發出停止指令。
模型正在想的一步，仍要等它想完。省掉的是等工具的時間。
官方說，這套非同步任務機制已經在 Harness 中實現，但還沒有默認開啟。
同樣，AI 主動修 bug 也要先有規則。內部群裡配置了“靜默復現並修復”：先嘗試，有可用結果才交，沒有就保持安靜。
關了電腦，任務停在那裡？
可以把它想成遠端辦公：AI 在雲端安排下一步，工作進度存進資料庫；程式碼、檔案和幹活的軟體，仍在實際工作的電腦上。
電腦上留一個小程序接活：收到雲端的命令就在本機執行，再把結果送回去。
這樣做有個現實原因：本地可能有沒提交的修改、私有憑據和內部網路服務。把環境完整複製上雲，本身就很麻煩。
但電腦離線後，依賴這台電腦的命令仍要等它重新上線。雲端線上，不會讓關機的電腦繼續運行程式碼。
後台還要有個巡檢員。這個獨立的 AI 會話叫 Watchdog，定時醒來看看：事情往前走了嗎？有沒有跑偏，或一直重複同一件事？
傳統監控能發現處理程序死了，卻未必看得出 AI 一直忙、工作毫無進展。這裡要檢查的是事情有沒有往前走。
快在那裡，實驗給了線索
團隊用約 300 條合成消息模擬群聊和 GitHub CI，其中約 20 條是工作請求，每種方案跑了 5 次。
消息間隔與工作時長按四分之一縮放，模型呼叫耗時則是真實值。
這裡比較的是：從收到請求到發回結果，那些等得久的任務有多慢。圖裡的 p95，表示約 95% 的任務耗時不超過這個位置。
與中性提示下的單會話加子智能體工具相比，Super-agent 的長尾等待明顯更短。
中性提示方案跑了 5 次，一次也沒委派，所有活都留給自己做。
把提示改成優先委派後，5 次裡有 4 次派了出去，耗時有所改善，整體仍慢於 Super-agent。
另一次，它覺得工作很小，還是自己做了。
差別出在誰來派活：這套設計提前說好，主管專心分派，同事負責執行，少了模型臨場糾結“這次要不要自己幹”。
開源了，那些還不能照單全收
實驗把編碼換成只消耗時間的工具，測的是調度協作。它沒有證明程式碼修得更好，此次也沒有找到獨立復現。
跨月記憶、外部消息注入、雲端與本地憑據安全，仍被官方列為開放問題。
X 使用者 Henk Nie 擔心，Router 記錯一件事，後面並行越多，錯誤可能擴得越快。這是個人擔憂，尚非故障實測。
部署文件寫明，Router 和 Worker 都按“全訪問”運行（danger-full-access）。你這個系統帳號能碰的檔案，它們也能碰。
單獨的 GitHub 帳號不會隔離本機檔案，官方建議用專用系統帳號。
多個 AI 一起幹活，也更費用量。官方實驗中，Super-agent 讀取快取的 token 更多，也就是反覆取用已有材料的量更大。
關閉直通後，Router 多做約三成決定，讀快取量明顯增加，完成時間卻基本相同。
直通省的是轉發與推理開銷。模型用量加上部署開銷，才是實際成本；目前沒有完整帳單能下性價比結論。
原型從一個倉庫開始
公開的 dsh-superagent-prototype 用 MIT 許可證，面向單個 GitHub 倉庫，飛書可選。
README 明說，它與內部版本不同，沒有實現文章的全部設計。雲端與端側分離，也不能直接當作這個原型的完整部署能力。
想試用，要準備 DeepSeek Harness、模型提供方、GitHub 專用帳號和允許名單，按倉庫 SETUP.md 配置。它不是新模型的 API，也不是網頁裡打開一個開關。
默認的 observe（觀察）模式，相當於先記一份“我會怎麼做”，不真正動手執行主動發現的任務；符合規則的明確請求仍會執行。飛書默認唯讀 @ 消息。
回到開頭那個 PR。程式碼可以先交，人仍要驗收；要不要合併、允許它主動做到那一步，還得有人負責。(AI范兒)