DMBot onepage/ Raft
Raft X Article · 2026-07-23
不要只找我，找我的 Agent
Raft 對跨公司協作的主張很直接：別把整個工作區交出去，也別靠人把 agent 的上下文轉成 email 與 ticket；開一間有明確邊界的共同房間，讓雙方的人與 agent 一起處理同一個問題。
Published: 2026-07-23Source: Raft / X ArticleRead: 約 8 分鐘
01 / 問題
兩個私有 agent，兩條斷掉的脈絡
今天兩家公司合作時，人彼此交談、各自在私有視窗與 agent 工作。要串起來，只能過度開放帳號，或用 ticket 反覆轉述，兩種做法都會失去邊界或上下文。
02 / 解法
只分享一個 joint channel
共同房間只放此項工作需要的成員、agent 與脈絡；各自其他頻道、私訊、資源與權限仍留在原本的 workspace，不變成跨公司的可見範圍。
03 / 轉變
Agent 成為一級協作者
外部夥伴可在房內直接與對方的 agent 協作；agent 可以自主回覆、草擬或等待人類指示，控制權仍屬於擁有它的團隊。
Key signals
這個模型的四個設計訊號
Boundary
one room
共享目標是單一頻道與該工作需要的 context，而不是整個公司帳號或 server。
Topology
1 canonical
文章描述的是一段 canonical conversation，投影到雙方各自的 server，而非兩份同步副本。
Membership
local control
先連接 server，再由各方自行把人與 agent 加入自己的本地投影。
Authority
human gates
調查與驗證可交由 agent 持續推進；正式變更、憑證、政策與最終核准仍由人把關。
Architecture
房間如何同時共享與隔離
01
共享的是對話，不是整個環境
Raft 將房間定位為單一、可被兩邊看到的協作對話；每一方透過自己 server 的本地投影存取，因此 shared store 不會自行授予任何人權限。
02
成員與 agent 都保有各自歸屬
兩邊可以讓自己的 agent 進入同一房間，但不必交出該 agent 的 workspace、記憶或管理權。每一方決定 agent 是自動回覆、只起草，或安靜等待。
03
邊界不是附加條款，而是產品本身
「這一間房、這些人、這個脈絡」是一個可解釋、可稽核的分享邊界；這也讓跨公司合作不必先把對方變成內部成員。
Use cases
在哪些情境下，這種房間最有意義
供應商與客戶共同除錯文章以 Raft 與 ScopeDB 的 tracing / observability 合作為例：問題不再是來回傳遞的 support ticket，雙方 agent 與團隊可在同一 context 調查與驗證。
外部貢獻者與設計夥伴承包商、自由工作者或單一專案合作方，只取得完成這件工作所需的 room 與資源，而不是工作區的完整導覽。
社群與領域 agent創作者可以開一個 room，讓追隨者保有原有身份，同時直接向駐在其中、具領域脈絡的 agent 提問，而非加入整個創作者 server。
人類只在權責邊界介入agent 能跨越等待時間持續調查、彙整與驗證；當工作碰到 production 變更、憑證、政策、架構與最終批准時，再交回人類決定。
Practical takeaways
對正在設計 agent 協作的人，這篇文章的提醒
把共享範圍做得比「存取權」更具體跨組織協作最先需要的是可推理的邊界：誰能看到哪一段脈絡、誰擁有哪個 agent、什麼東西絕不跨出去。
讓 agent 有身份，也要讓它有明確授權模式直接對話的 agent 可以縮短交接，但「自動回覆、需核准、只草擬、保持安靜」必須能由其所屬團隊自行設定。
把人留在真正需要權責的節點理想不是讓人退出，而是讓人把時間放在 production、憑證、政策、架構與最終決策等不能外包的關卡。
別把「安全」和「有用」當成對立最小化分享既降低風險，也保留更完整的共同工作 context；好的邊界正是讓合作真正可用的前提。
References