想像一個團隊同時開著四十個對話。在一個對話裡，有人請 AI 代理準備客戶提案。在另一個對話裡，同事正在問交付時間。第三個人則在確認，同一個功能能不能在這個月上線。
每段對話都從交代背景開始。這是客戶。這是我們作出的承諾。這是昨天定下來的事。AI 代理各自開工，卻只看到不同片段。直到有人發現，提案裡承諾的日期，早已在工程討論中被排除了。
然後，一個 Task 結束了。它的對話安靜下來。一週後，另一個人開始做相關工作，又把背景講了一遍。
在建置 AI 代理時，我們反覆想到這個場景。我們希望下一項工作能從團隊已經學到的東西出發。於是，我們走向了單一會話的設計：一個持續存在的主對話，搭配獨立執行各項 Task 的 Worker。
子代理協助分工。單一會話回答另一個問題：隨著工作推進，對這些工作的理解放在哪裡？我們同時使用這兩種做法。主對話讓團隊的工作接續下去，Worker 給每項工作獨立展開的空間。
從個人到頻道，再到團隊
Poke 給個人 AI 代理一個簡單的歸處：一個人，一個對話（2025 年 9 月）。它把一個人的電子郵件、行事曆和檔案接到文字對話裡。草擬回覆或調整會議時間，都可以從上一次請求所在的地方開始。隨著一天的事情持續推進，這個對話成了可以不斷回來的地方。整個體驗圍繞個人與 AI 代理的關係展開，也讓我們看到了不同工作之間如何保持連續。
Claude Tag 把一個 Claude 帶進了頻道（2026 年 6 月 23 日）。頻道裡的任何人都能提及同一個 AI 代理、看到它在做什麼，並接著同事的討論往下走。Claude 會逐漸記住相關資訊，使用管理員開放的工具。發佈介紹也提到，在獲得許可時，它能從其他頻道和資訊來源中學習。我們關注的是這種共享對話：人們可以在原本討論工作的地方，把工作交出去。我們的設計則把團隊的主對話當作歸處，接住不同討論和 Task 帶回來的資訊。
我們選擇探索一個團隊、一個對話。上下文跟著團隊的工作跨越不同討論。關於交付的決定，可以影響客戶提案，即使這兩項工作最初發生在不同地方。
2026 年 4 月 28 日，我們發佈了前一個產品 Bridge 的第一篇相關文章。這段探索晚於 Poke，早於 Claude Tag。隨後，我們在目前產品 Comma（2026 年 10 月 1 日）中繼續這項工作，這套設計今天就運作在 Comma 上。
2026 年 10 月 31 日，DeepSeek Harness 也介紹了 Super-agent 的探索。它會在群組聊天中主動跟進程式碼工作，呼應了同一個方向：把協調工作從人手裡接回系統。這是沿著自身設計展開的研究原型。
DeepSeek 的設計文章第 8.4 節把兩個問題列為待探索：雲端入侵或提示詞注入可能危及連接的裝置，憑證進入模型上下文也可能在正常執行時外洩。我們已在運作的內容流向關卡是 IFC：每次傳送宣告來源，依目的地讀者範圍檢查，不通過就拒絕，必要時申請特定範圍的人工授權。
憑證走另一層。模型只指定憑證參照，執行層解析並注入憑證值，不把值交給模型。
團隊留下了什麼
設想一位新同事加入了客戶提案的工作。他進入的是團隊一直使用的同一個主對話。他可以看到其中的決定，問清楚日期為什麼變了，然後接著做，而不用找三個人要三份摘要。工作區成員身分讓他能進入這個共享對話；某項決定背後的資料，仍依資料本身的權限開放。
Task 完成後，結果和歷史仍然保留。比如，團隊發現某位客戶需要一種特別的匯出格式。報告回到 Router，後續提案就能引用這個發現及其來源。Task 結束了，團隊仍有地方可以回頭找到這次工作的收穫。
並行工作讓這條返回路徑更重要。一個 Worker 可能在讀客戶需求，另一個則在調查技術限制。如果發現經過層層轉述才到達團隊，重要的前提可能會遺失。每個 Task 都把發現連同來源一起回報。Router 在同一個主上下文裡接收這些資訊。
這讓我們有理由把 AI 代理框架拆成兩種角色。一個持續追蹤團隊的對話，其他角色執行具體的工作。
Router 和 Worker 如何配合
我們給一個工作區設定一個常駐 Router。它持有團隊的主上下文，隨著新請求進入、決定變化和結果返回，持續追蹤對話。關於客戶提案的請求，與已經展開的交付討論，進入同一個上下文。每條輸入訊息都帶著來源對話和訊息的識別資訊。Router 跨討論共享上下文，同時保留每條輸入來自哪裡的線索。
Router 把明確的工作交給 Worker。每個 Task 都開啟一個新的 Worker 會話，帶上這項工作的指令與交接內容。其他 Worker 的歷史留在各自的會話裡。多個 Worker 可以同時調查不同問題。
我們為每個 Task 定義目標、完成目標所需的上下文，以及預期交付物。「調查這個客戶」留下了太多空白。「檢查客戶的匯出要求，給出格式建議，並附上來源和待確認問題」，就讓 Worker 有明確可完成的工作，也讓 Router 拿到可用的結果。
假設客戶提案既需要檢查匯出要求，也需要估算交付時間。我們可以把它們交給不同 Worker。一個返回客戶需求，另一個返回估算及其前提。Router 把結果帶回主對話，讓團隊作出決定。完成的工作有路可回。
每一條可見回覆都是一次明確傳送，主對話裡的回覆也一樣。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，一次次回到同一項工作。下一次有人開啟相關討論時，我們希望團隊先前的努力仍在那裡，接得上。
