大家好，這裡是最佳夥伴，我是大飛。你是否覺得，隨著程式碼編寫越來越流暢，我們開發人員反而變得越來越忙了？
在過去一年裡，編碼代理的受歡迎程度呈現爆炸性成長。從 Cursor 到 Devin，從 CloudCode 到各種開源解決方案，模型可以做的事情越來越多——編寫程式碼、修復錯誤，並且連續數小時運行測試而無需停止。
但在實際操作中，許多人發現自己同時打開了五到六個聊天窗口，每個窗口都有一個人工智慧在運作。您需要不斷在這些視窗之間切換，以檢查任務進度，查看是否需要人工干預錯誤，或確定哪個任務已準備好進行審核。人工智慧最初是為了減輕我們的工作量，結果卻為我們創造了新的工作。
我們如何管理人工智慧？DeepSymmetry 團隊於 10 月 31 日發表了一篇文章，專門討論了這個問題。他們認為，隨著人工智慧能力的增強，瓶頸不在於模型本身，而在於人類的注意力。一個人通常只能同時追蹤三到五個活躍的聊天窗口，這意味著會話之間的技術隔離問題完全由人腦來處理。
會話模式的局限與「超級代理」的提出
我們將人工智慧代理的當前狀態稱為「會話模式」，其中每個會話都是一個獨立的聊天窗口，它們之間互不通訊。你給它下達指令，它執行完畢，就這麼簡單。下次你們聊天時，它已經忘記你們之前聊過什麼了。
但現實世界的軟體開發並非如此。一項任務可能始於 GitHub Issue，然後是程式碼變更、PR 審查和 CI 測試。同時，開發人員今天可能會添加需求，明天添加限制，後天可能改變對同一個 PR 的想法。這些都屬於同一個項目，但在會話模式下，您必須手動複製和貼上每個步驟的上下文。
因此，DeepSymmetry 團隊提出了一種他們稱之為「超級代理」的東西。簡而言之，就是將人工智慧從一個等待指令的工具轉變為一個全天候主動跨平台工作的持續實體。您無需擔心它屬於哪個會話；它可以獨立同時處理多個任務。
今天，我們來談談這個框架。DS 列出了超級特工的四個特徵：
- 第一個特點是「連續性」——無論你是在群組聊天還是在 GitHub PR 評論區改變主意，你始終面對的是同一個能夠理解上下文的代理。
- 第二點是「效率」，它允許多個複雜任務並行運行，因此耗時的任務不會阻止您發送新指令。
- 然後還有「主動性」和「堅持性」。「主動性」意味著不斷監控周圍的工作環境，並在出現問題時主動尋求幫助。「持久性」意味著即使設備離線，它也能繼續運行，並且如果出現問題，它可以自行恢復。
單一 ReAct 循環顯然無法滿足這四個特性。DPS 團隊的解決方案很有意思；他們並沒有發明新的理論，而是藉鑒了幾十年前電腦系統的經典設計，並將它們逐一引入到代理架構中。
核心設計：路由器與工作者的雙層架構
我們先來談談核心設計，也就是雙層架構。這個概念很簡單：它將全域連續性的維護與高並發執行分開到兩個層次。
頂層稱為路由器層，它是一個常駐的全域調度節點，負責接收所有人類互動。無論訊息來自聊天還是 GitHub 評論，都會先發送到路由器。但是，路由器有一個原則：它本身並不做任何工作；你甚至不需要為它配備工具。它只專注一件事：這項任務應該分配給誰？用他們自己的話來說，路由層通常不像人們想像的那樣複雜，並且可以在輕量級模型上運行。
最底層稱為工作層。每個 Worker 都是獨立的執行單元，配備全套開發工具和最強大的推理模型，專注於在其自身上下文中完成單一任務。工人們遵守嚴格的紀律：他們絕不會貿然跳出來直接與人交談。所有中間推理細節和工具錯誤都保留在內部。完成工作後，Worker 會向外部路由器報告，由外部路由器處理與使用者的所有通訊。
這樣，使用者感覺自己始終在與同一個了解全局的助手溝通，而實際上，後台有多個工作人員正在並行編寫程式碼。在他們的內部範例中，同一個開發任務可以在群組聊天和 GitHub PR 之間不斷推進。如果使用者在聊天中建議方案 A，之後又在評論中將其變更為方案 B，則路由器會理解這是同一個任務，並自動調整 Worker 的執行方向。
訂閱機制與批量處理
但如果只是雙層架構，路由層很容易成為瓶頸。所以，DeepSeek 還實現了另外兩項功能。
一種是訂閱和傳遞機制；例如，一旦一個工作進程獲取了一個 GitHub PR，它就會直接訂閱該 PR 的所有後續評論。之後，如果有人提出更改建議，訊息將直接傳遞給該工作進程進行處理，而無需路由器再次轉發。他們進行了實驗，光是這一項功能就幫助路由器節省了約 30% 的決策步驟和 37% 的讀取快取令牌。
另一種方法是批量處理。當大量外部訊息到達時，路由器在前一個推理週期中累積的多個事件會自動合併。由於下一個週期只處理輸入和輸出較短的輕量級分發，因此累積的事件越多，分配給每個決策的推理時間就越少。DeepSeek 進行了壓力測試：隨著觸發事件的到達率從每分鐘 1 次增加到每分鐘 40 次，分配給每個單獨決策的推理時間從 6.4 秒下降到 1.6 秒。
事件驅動與快慢路徑過濾
當然，僅僅採用直通架構是不夠的。要使智能體具有主動性，其輸入必須從人為輸入的提示轉變為環境不斷產生的事件。因此，群組聊天訊息、程式碼審查評論、測試結果和電子郵件提醒在 SuperAgent 中統稱為「觸發器」。
然而，一個實際問題是，現實世界的事件流通常噪音高、觸發率低。如果每個訊息都送到 LLM 進行判斷，計算資源將會耗盡，人類將會被垃圾郵件淹沒。因此，DeepSeek 採用了電腦系統中經典的「快路徑和慢路徑」設計，創建了一個兩級過濾器。
第一層由程式碼規則組成，它是一種低成本的快速路徑，對事件來源、群組範圍和白名單執行嚴格的邏輯檢查。例如，來自未經授權使用者的訊息將被忽略，不在白名單上的群組聊天將被跳過。這樣一來，就不會執行任何一行 LLM 推理程式碼。
第二層由語義規則組成，它們充當高級慢速路徑。只有透過程式碼檢查的訊息才會被送到模型進行讀取，然後模型會根據自然語言策略判斷是否應該實際採取行動。
上下文管理：內聯、溢出與鏈式召回
情境管理也是一項棘手的任務。即使事件經過正確過濾和路由後，一旦進入目標代理，應該在模型的上下文視窗中填充多少資訊？內容過多會浪費上下文視窗並分散注意力；資訊量太少會導致模型重複調用工具讀取訊息，從而增加執行步驟。DeepSeek 的態度非常直接：浪費上下文視窗就是浪費模型的智慧。
他們借鑒了編譯器最佳化中的兩個概念：內聯和 S-pilling（溢出）。
內聯是指將可能很快使用的資訊直接推送到上下文視窗中，從而節省額外工具呼叫的開銷。例如，當前事件的前 50 個字元、前後幾條聊天訊息以及程式碼審查中的相關評論。
溢出是指將超出視窗預算的長內容留在視窗外，只留下摘要和相關物件的 ID，模型可以在需要時透過工具呼叫取得完整內容。
巧妙之處在於鏈式召回系統，它為每個觸發會話分配一個唯一的 ID。在上下文中，它會連結到關聯物件的 ID，從而建立一個底層參考圖。從當前事件開始，該模型可以按需跳到 ID，從當前訊息追蹤到其線程，再追蹤到相關組織，甚至追蹤到另一個關聯的程式碼審查。這樣一來，即使路由器在長時間運行後需要回顧歷史記錄，也不必強制將所有歷史記錄都顯示在視窗中，而是按需擴展視窗。
推測執行與非同步任務解耦
還有一個有趣的設計叫做推測執行，類似於 CPU 分支預測：當不確定某個結果是否會被使用時，它會在後台根據環境訊號進行猜測。
有時候，只要小組裡有人提到某個漏洞，這件事似乎就變得很嚴重。當大家還在討論問題原因時，它已經在後台悄悄搭建了一個環境來重現問題並編寫修復程式。如果它成功，就能達到預期結果；如果它失敗了，它會保持完全靜默，絕不會突然出現引起注意。他們在內部群組中實施了「靜默複製和修復」策略：一旦報告了問題，它就會嘗試在後台解決該問題；只有在確認問題並找到簡單的解決方法後才會發出報告，否則不會發出任何聲音。
目前，該代理程式已經可以同時處理多個任務並主動聯繫用戶，但仍存在一個用戶體驗問題：代理執行任務時，前台是否會凍結？在經典的 ReAct 循環中，一旦模型發起同步工具調用，循環就會立即阻塞，直到工具執行完畢。
為此，他們將耗時的命令和子任務改為非同步啟動和停止操作。模型呼叫開始後，會立即收到確認訊息；循環不再等待後台執行完成。完成後，系統會將結果作為新事件注入對話中。該模型還可以根據上下文隨時呼叫 stop 來主動終止運行時間過長的後台任務。
這樣一來，前端對話回應和後端任務執行就解耦了；當後端正在編譯或執行測試時，前端仍然可以立即回應您的新命令。
不同管道的溝通策略也各不相同。在群組聊天中，要像一位謹慎的技術同事那樣保持低調，只在需要做決定或簽字時才通知，並且嚴格將個人回复控制在 100 字以內。對於 GitHub 或電子郵件等非同步管道，應轉向輸出高密度、結構化的報告，並根據需要完整記錄問題背景、變更描述或驗證結果。
算儲分離與看門狗監控
然而，即使這樣，仍然存在一個老問題：一旦你合上筆記型電腦的蓋子，代理程式就會關閉。傳統代理將計算狀態和執行環境綁定到同一台機器上，因此當設備離線時，所有操作都會完全停止。
因此，Devika 採用了電腦系統中的「計算-儲存分離」方法，並分兩步驟解決了這個問題。
首先，將驅動代理循環的運算移到雲端的無狀態彈性容器中，同時將會話狀態儲存在資料庫中；這打破了單一機器生命週期的限制，實現了全天候線上服務。
第二，將基於雲端的代理邏輯與狀態密集的執行環境分開。您的程式碼庫、本機工具鏈和私鑰仍然保留在您自己的電腦上，雲端只需要在您的機器上執行一個輕量級守護程式來執行命令並傳回結果。這種設計被稱為自帶環境（BYO-Environment）。
這樣一來，你就不再局限於一台機器了；您可以根據任務需求切換不同的設備並選擇環境。即使您的電腦暫時離線，雲端也可以繼續處理其他任務，並在電腦重新上線後自動重新連線並恢復運作。
他們說這種方法與 Anthropic 提出的「腦手分離」理念相符，但區別在於場景：Anthropic 討論的是託管服務、按需創建沙箱和 VPC 資源，而 Devika 的首要任務是處理個人機器上的日常用戶任務，這些機器可能會間歇性地離線。
對於未提交的變更和本地環境，基於雲端的代理邏輯也可能遇到一系列問題。例如，該過程可能會停滯，模型可能會陷入無限循環，或者可能會偏離軌道並使情況變得更糟。因此，Devika 在主系統外部安裝了一個獨立的看門狗，利用心跳訊號進行監控。監視者本身也是一個代理會話；它不執行實際工作，而是專門監控工人是否取得實質進展以及其方向是否偏離總體目標。如果偵測到異常情況，它將強制介入進行修復；如果是外部間歇性故障，它將持續重新檢查，直到一切恢復正常。維護人員可以直接使用自然語言向代理詢問故障原因，或讓代理商即時線上修改主系統的提示規則。
實驗驗證與當前挑戰
那麼，這種架構在實務上表現如何呢？德文進行了兩組初步實驗。
第一組實驗是端對端模擬實驗，他們使用真實流量和 GitHub CI 訊息流來驅動四種不同的方案。每個實驗包含約 300 條訊息，其中穿插著約 20 個工作請求，其餘的純粹是閒聊、打斷和系統通知。編碼工具被一種只消耗時間的工具所取代，因此實驗衡量的是調度和協作能力，而不是單一任務的執行效能。
每個方案運行五次；結果顯示，該代理人完成任務的平均時間為 12.4 分鐘，第 95 個百分位數為 15.7 分鐘。在具有子代理工具的單代理方案中，在中性提示下，該模型在五次運行中一次也沒有調用子代理，所有工作都在主代理中完成，並且不斷被新訊息打斷，導致第 95 個百分位數達到 29.5 分鐘。切換到優先委託提示後，委託成功率達到五分之四，但速度仍比超級代理慢。此外，還有一次，模型判斷工作量很小，於是自己完成了這項工作，從而產生了長尾效應。
這表明，在單一代理設定中，依靠提示來使模型委派任務是不穩定的。雙代理架構透過確保路由器不會直接執行特定工作，而工作節點只接收已訂閱的訊息，從而在系統層面解決了這個問題。
當然，效率的提升是有代價的。此代理程式需要維護多個獨立會話，因此每個實驗的讀取快取令牌比單一代理要高；本質上，它用更多的代幣換取更短、更穩定的完成時間。
第二組測試是路由層的批量處理壓力測試。到達率從每分鐘 1 個增加到大約 40 個，平均批次大小從 1.0 增加到 2.8，而每次請求所花費的時間僅從 2.5 秒增加到 3.9 秒，增長率遠低於批次大小的增長率。每個決策的攤銷推理時間從 6.4 秒降至 1.6 秒，這證明它可以在突發擁塞期間自動合併請求，從而提高吞吐量。以目前的團隊規模，沒有必要過早進行橫向劃分，以免犧牲全局脈絡的連續性。
然而，正如開發人員自己指出的那樣，該系統目前仍處於研究原型階段；這些實驗基於合成載荷和簡化環境，並非正式的產品結論。DSHAgent 專案的原型已在 GitHub 上以 MIT 授權開源；它基於 DeepsHarness 構建，目前僅支援 GitHub 和 Feishu。它為技術界提供了工程基礎參考資料。
仍有一系列未解決的開放性問題：
- 當雙層架構成長時，如何擴展？
- 路由器何時應該切換，工作節點何時需要直接通訊？這些問題都還沒有解決。
- 此外，一旦超越聊天概念，使用者如何與之協作？聊天視窗是最終形式嗎？還是說互動會更多在 GitHub 等領域介面中進行？這些目前都還處於探索階段。
隨著組織規模的擴大，定義多個代理實例之間的邊界以及管理代理之間的協作也帶來了新的挑戰。最實際的問題是安全和隱私；由於雲端代理連接到本地邊緣設備，如果雲端遭到入侵或注入提示訊息，所有連接的邊緣設備都將面臨風險。
結語：系統工程的價值回歸
回到 DeepSeek 的論文，他們並沒有發明任何新東西：雙層架構、事件驅動、快速通道、慢速通道、推測執行、儲存運算分離和看門狗都是幾十年前的作業系統教科書中的概念。他們公開且有系統地將這些經典設計融入他們的建築中。事實上，你可以清楚地看到其中許多經典系統的影子。
所以，從大局來看，我認為它的價值不在於某個具體的技術細節有多麼令人印象深刻，而是這個產業正在改變。有一段時間，大家都依賴快速的工程技術和運氣來取得成果。現在模型能力有所提高，瓶頸從模型本身轉移到了系統架構。DeepSeek 團隊運用傳統的系統工程方法解決了這個問題，為整個產業提供了一個可參考的方向。
對於你現在使用的 AI 助理來說，更令人沮喪的是：它們的能力不夠強，還是你無法有效地管理它們？
歡迎在評論區分享您的想法。