--- title: "單一會話 agent 簡史 · Comma 部落格" description: "一個常駐主會話、獨立的 Worker，以及團隊級對話背後的工程。" url: https://comma.surf/zh-tw/blog/a-brief-history-of-single-session-agents language: zh-TW --- [返回部落格](https://comma.surf/zh-tw/blog) Comma Team · 2026 年 11 月 1 日 · 閱讀約 7 分鐘 # 單一會話 agent 簡史 一個常駐主會話、獨立的 Worker，以及團隊級對話背後的工程。 [開始使用](https://app.comma.surf/) 想像一個團隊同時開著四十個對話。在一個對話裡，有人請 AI 代理準備客戶提案。在另一個對話裡，同事正在問交付時間。第三個人則在確認，同一個功能能不能在這個月上線。 每段對話都從交代背景開始。這是客戶。這是我們作出的承諾。這是昨天定下來的事。AI 代理各自開工，卻只看到不同片段。直到有人發現，提案裡承諾的日期，早已在工程討論中被排除了。 然後，一個 Task 結束了。它的對話安靜下來。一週後，另一個人開始做相關工作，又把背景講了一遍。 在建置 AI 代理時，我們反覆想到這個場景。我們希望下一項工作能從團隊已經學到的東西出發。於是，我們走向了單一會話的設計：一個持續存在的主對話，搭配獨立執行各項 Task 的 Worker。 子代理協助分工。單一會話回答另一個問題：隨著工作推進，對這些工作的理解放在哪裡？我們同時使用這兩種做法。主對話讓團隊的工作接續下去，Worker 給每項工作獨立展開的空間。 ## 從個人到頻道，再到團隊 [Poke](https://www.webwire.com/ViewPressRel.asp?aId=343533) 給個人 AI 代理一個簡單的歸處：一個人，一個對話（2025 年 9 月）。它把一個人的電子郵件、行事曆和檔案接到文字對話裡。草擬回覆或調整會議時間，都可以從上一次請求所在的地方開始。隨著一天的事情持續推進，這個對話成了可以不斷回來的地方。整個體驗圍繞個人與 AI 代理的關係展開，也讓我們看到了不同工作之間如何保持連續。 [Claude Tag](https://www.anthropic.com/news/introducing-claude-tag) 把一個 Claude 帶進了頻道（2026 年 6 月 23 日）。頻道裡的任何人都能提及同一個 AI 代理、看到它在做什麼，並接著同事的討論往下走。Claude 會逐漸記住相關資訊，使用管理員開放的工具。發佈介紹也提到，在獲得許可時，它能從其他頻道和資訊來源中學習。我們關注的是這種共享對話：人們可以在原本討論工作的地方，把工作交出去。我們的設計則把團隊的主對話當作歸處，接住不同討論和 Task 帶回來的資訊。 我們選擇探索一個團隊、一個對話。上下文跟著團隊的工作跨越不同討論。關於交付的決定，可以影響客戶提案，即使這兩項工作最初發生在不同地方。 從個人對話、共享頻道，到團隊的主對話。 2026 年 4 月 28 日，我們發佈了前一個產品 Bridge 的第一篇相關[文章](https://bridge.surf/blog/introducing-bridge)。這段探索晚於 Poke，早於 Claude Tag。隨後，我們在目前產品 Comma（2026 年 10 月 1 日）中繼續這項工作，這套設計今天就運作在 Comma 上。 2026 年 10 月 31 日，DeepSeek Harness 也介紹了 [Super-agent](https://www.straitstimes.com/asia/east-asia/deepseek-drops-enhanced-coding-agent-with-aim-to-rival-anthropic) 的探索。它會在群組聊天中主動跟進程式碼工作，呼應了同一個方向：把協調工作從人手裡接回系統。這是沿著自身設計展開的研究原型。 DeepSeek 的[設計文章第 8.4 節](https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg)把兩個問題列為待探索：雲端入侵或提示詞注入可能危及連接的裝置，憑證進入模型上下文也可能在正常執行時外洩。我們已在運作的內容流向關卡是 IFC：每次傳送宣告來源，依目的地讀者範圍檢查，不通過就拒絕，必要時申請特定範圍的人工授權。 憑證走另一層。模型只指定憑證參照，執行層解析並注入憑證值，不把值交給模型。 ## 團隊留下了什麼 設想一位新同事加入了客戶提案的工作。他進入的是團隊一直使用的同一個主對話。他可以看到其中的決定，問清楚日期為什麼變了，然後接著做，而不用找三個人要三份摘要。工作區成員身分讓他能進入這個共享對話；某項決定背後的資料，仍依資料本身的權限開放。 Task 完成後，結果和歷史仍然保留。比如，團隊發現某位客戶需要一種特別的匯出格式。報告回到 Router，後續提案就能引用這個發現及其來源。Task 結束了，團隊仍有地方可以回頭找到這次工作的收穫。 並行工作讓這條返回路徑更重要。一個 Worker 可能在讀客戶需求，另一個則在調查技術限制。如果發現經過層層轉述才到達團隊，重要的前提可能會遺失。每個 Task 都把發現連同來源一起回報。Router 在同一個主上下文裡接收這些資訊。 這讓我們有理由把 AI 代理框架拆成兩種角色。一個持續追蹤團隊的對話，其他角色執行具體的工作。 ## Router 和 Worker 如何配合 我們給一個工作區設定一個常駐 Router。它持有團隊的主上下文，隨著新請求進入、決定變化和結果返回，持續追蹤對話。關於客戶提案的請求，與已經展開的交付討論，進入同一個上下文。每條輸入訊息都帶著來源對話和訊息的識別資訊。Router 跨討論共享上下文，同時保留每條輸入來自哪裡的線索。 Router 把明確的工作交給 Worker。每個 Task 都開啟一個新的 Worker 會話，帶上這項工作的指令與交接內容。其他 Worker 的歷史留在各自的會話裡。多個 Worker 可以同時調查不同問題。 我們為每個 Task 定義目標、完成目標所需的上下文，以及預期交付物。「調查這個客戶」留下了太多空白。「檢查客戶的匯出要求，給出格式建議，並附上來源和待確認問題」，就讓 Worker 有明確可完成的工作，也讓 Router 拿到可用的結果。 假設客戶提案既需要檢查匯出要求，也需要估算交付時間。我們可以把它們交給不同 Worker。一個返回客戶需求，另一個返回估算及其前提。Router 把結果帶回主對話，讓團隊作出決定。完成的工作有路可回。 每個 Task 都有全新的 Worker 會話。結果帶著來源回到主對話。 每一條可見回覆都是一次明確傳送，主對話裡的回覆也一樣。Router 指定目的地，並通過該目的地的檢查。模型輸出和結束一輪執行，都不會自動發佈回覆。Worker 回報結果或向其他參與者發言時，也遵循同一條規則。讀取 Task 資料為 Worker 提供工作的上下文，傳送則是單獨的動作。 ### 資訊流控制 並行的 Task 會把讀者範圍不同的資料帶到一起。每次傳送都要宣告所用的來源。資訊流控制，也就是 IFC，會檢查目的地的讀者是否有權閱讀這些來源。 啟用強制執行後，傳送遭拒會回傳原因。AI 代理可以移除受限內容後重試，或申請所需範圍的人工授權。重試時，內文和來源宣告都要隨之調整。 IFC 在準備回覆與分享出去之間，為團隊加上一道可檢查的步驟。 每則可見回覆都要明確傳送，主對話裡的回覆也一樣。 回到客戶提案，Router 可以把估算呈給團隊，問清仍待決定的事，再透過合適的管道送出商定的答覆。Worker 的工作有明確範圍，團隊的對話則穿過這次交接繼續下去。 新的 Task 會開啟新的 Worker 會話。切換會話時，我們把未完成的事和相關參照交接過去。團隊仍然需要能回頭找到以前的決定。 ## 團隊如何一起學習 可重複使用的做法會成為群組共享的 skill，包含可編輯的指令與資源。AI 代理端的修改由建立者負責。其他 AI 代理可以使用，不必重寫原件；唯讀的內建 skill 則可複製後自訂。會話取得自己範圍內的目錄，再開啟相關指令。 Router 維護持久記憶，記錄人、環境、一般事實，以及按日期記下的經歷。它按需讀取或搜尋。一般 Worker 從 Task 交接內容出發；指派的 Triage Worker 只有與來源綁定的讀取權限。記憶寫入由 Router 負責。 啟用精簡工作區（Condensed Workspace）後，每個內部 Router 和 Worker 會話都會看到同一份簡短的目前群組事實清單。工作區擁有者可以直接編輯。 AI 代理更新時會得到建議性檢查：內容是否為其他 AI 代理需要知道的目前事實。系統記錄修訂版與最後寫入者。擁有者可以更正或刪除陳述，讓共同依賴的認知能被看見、能被修改。更新遭拒後，可帶上拒絕識別碼重試，明確覆寫檢查。 ## 維持一個對話的代價 這種安排給主會話帶來壓力。Worker 可以並行運作，Router 仍要彙整結果。前一個請求還沒處理完，新請求就可能到了。不管背後有多少 Worker，人們感受到的仍是一條佇列。 循序排隊仍是我們在解決的問題。把耗時調查交出去，能讓 Router 騰出更多空間回應，但團隊仍需要為互相影響的決定排好順序。在客戶提案裡，總得有人先定下交付日期，再對外作出最後承諾。共享對話讓這層相依關係更容易看清，也讓 Router 承擔更多推動工作前進的責任。 歷史也有自己的成本。每個完成的 Task 都會留下值得以後參考的內容，也會留下很多再也用不上的東西。隨著歷史成長，找到所需的決定和背後的理由，也需要花更多功夫。 我們希望舊決定容易找，不用請同事把整段討論重新講一遍。決定背後的理由，能協助團隊辨識何時該調整決定。 我們的探索就走到這裡。我們選擇共享主對話，是因為團隊會透過不同的人、不同的 Task，一次次回到同一項工作。下一次有人開啟相關討論時，我們希望團隊先前的努力仍在那裡，接得上。 工程 [返回部落格](https://comma.surf/zh-tw/blog) 分享 ## 相關文章 2026 年 10 月 19 日 ### [Comma AI 代理原生支援 SSH](https://comma.surf/zh-tw/blog/native-ssh) 2026 年 10 月 1 日 ### [為分散式 AI 代理框架打造可程式化的事件迴圈](https://comma.surf/zh-tw/blog/agent-programmable-event-loops) 2026 年 10 月 31 日 ### [代管還是自行託管個人 AI 代理：誰來執行什麼？](https://comma.surf/zh-tw/blog/hosted-vs-self-hosted-personal-agent) ## Try Comma, Now. [開始使用](https://app.comma.surf/)