DeepSeek超級代理方案 引發上下文管理討論

雙層架構的設計邏輯

該方案把最外層接事件觸發器，中間設常駐Router，底下掛多個幹具體工作的Worker Session。Router不執行重活，專責守在入口判斷任務歸屬，完成後匯總回報，理念是讓Session成為系統實現細節，而非用戶的認知負擔。

上下文管理才是難點

該工程師認為，Session只是臨時執行過程，可藏於底層；但工作上下文是工作現場與權限邊界，包括代碼倉庫、工作目錄、AGENTS.md規範、文檔站連結及工具權限，必須端到端呈現。單一入口讓Router憑語義猜測路由，一旦猜偏，本意清理本地測試目錄的指令，可能演變成線上刪庫事故。

文中亦對「投機執行」提出保留：Agent持續監聽群聊並在無人召喚時於後台拉代碼、提交修復，屬不可回滾的外部副作用，文中以處理器投機執行曾引發Spectre漏洞作類比，強調缺少顯式邊界攔截，不可信輸入可能觸發後台靜默執行。

群聊與共享數據庫

該文認為，管理多個上下文最自然的形態是群聊，每個群天生就是顯式Context容器，進群開口即解決路由，並引 ChatOps 及數據庫先聲明資料庫與角色的做法佐證。群聊底下真正的骨架，是跨Agent共享的數據庫：聊天記錄如預寫日誌，整理後的Wiki如數據表，各類索引可隨時重建。

記憶沉澱與部署考量

記憶方面，該文主張聊天記錄沉澱為文檔或Wiki，再配向量、全文及圖索引；整理難在持續維護，需由「書記」定期提煉決定與規範，設寫入門檻並標記作廢過時結論。部署上，Agent需常開機器，工作環境留在原地由輕量Daemon遠程執行，狀態與身份宜留在用戶手中。

業界現狀與底座選擇

現狀方面，文中列出騰訊 WorkBuddy 今年3月公測後日活達1300萬，飛書讓Agent進群領工號，Slack把路由做成統一調度產品；開源端則有 OpenClaw、Mattermost 及獨立開發者的 cumora、magpie 等零件，完整形態尚未出現。

底座方面，該文主張共享狀態落在 PostgreSQL 加 S3 之上，結合文檔框架與代碼倉庫；作者並指出應用層競爭與否由市場決定，而管理狀態與邊界的上下文底座具高度確定性，其相關能力已打包於開源項目 Pigsty 與 Silo，並認為現階段真正的超級代理仍是人類自己。