科研協作裡最累人的往往不是分任務，而是傳上下文。A 讓 B 改一段綜述，B 找不到 A 說的那篇文獻；C 在群裡發了一個資料表，三天後 D 又問「那個表在哪」。這些摩擦的本質不是人懶，是資訊散落在聊天、電郵、雲端硬碟之間，沒有一個共同的工作檯面。MuchSci 的共研工作坊就是衝著這個問題設計的：它把一個課題組需要的「人、智能體、檔案」放進同一個空間，讓大家圍繞同一份上下文推進。
理解它的方式，是把「聊天工具」和「協作容器」分開。前者負責傳遞訊息，後者負責維持一個課題的完整上下文。共研工作坊屬於後者。
01 科研協作的真正難點不是分任務，是傳上下文
先看一個最直觀的對比。
▲ 圖 1｜普通群組聊完就散，共研工作坊把材料、角色、過程留下來
普通溝通的问题不在於不能發訊息，而在於訊息和檔案會隨時間下沉。三天前發的 PDF、上週定的結構、上個月討論的假設，要靠人工翻找才能復原。科研協作的上下文是累積的，不是每一輪都從空白開始。如果容器本身不能承載這種累積，團隊成員就只能一遍遍重複解釋。
共研工作坊的做法，是給每個課題一個獨立空間。這個空間裡有固定成員、有綁定智能體、有項目層級檔案和歷史記錄。打開它，就能回到上一次離開時的狀態。這一點對跨週、跨月的課題尤其重要。
02 項目組是怎麼把三類對象放在一起的
打開 MuchSci 的「我的項目組」，你能看到一個課題組的基本骨架。
▲ 圖 2｜共研工作坊內部：成員、智能體、檔案三類對象共享同一空間
第一層是成員。 項目創建人與普通成員在列表裡被明確區分。這個區分不只是標識，它決定了誰有權限調整項目結構、誰可以退出項目組。科研協作裡角色本來就有差異，把差異顯式化，能減少後續權限糾紛。
第二層是智能體。 項目組可以綁定多個智能體，例如論文檢索、辦公助手、化學資訊學等。綁定之後，成員在聊天裡輸入 `@` 就能喚起它們。這意味著智能體不是游離在對話之外的工具，而是項目組的常駐成員。
第三層是檔案。 知識庫、文獻、草稿、交付物都隨項目留存，不會被新的聊天訊息沖走。檔案和對話在同一個容器裡，討論時可以直接引用材料，而不是拋出一個檔案連結讓大家自己找。
03 在項目組裡說話，和群組聊天有什麼不同
截圖裡是一個叫「產業部」的項目組。它的卡片上寫著綁定的智能體，底部有「進入共研工作坊」按鈕。
▲ 圖 3｜「我的項目組」列表：一個項目組綁定多個智能體，點擊進入協作空間
進入項目組後，介面更像一個課題工作台。頂部有「返回 產業部」和「歷史聊天記錄」；右側分三個標籤：成員、智能體、檔案；底部輸入框提示「輸入 @ 可喚起綁定的項目組智能體，例如：@辦公助手 幫我生成一份演講稿」，旁邊還有「+ 知識庫」入口。
▲ 圖 4｜項目組內部：成員列表區分創建人與普通成員，聊天可直接@智能體
這裡的關鍵是「@」機制。 在普通聊天裡，@一個人是叫他來看訊息；在項目組的聊天裡，@一個智能體是調用它的能力。同一個輸入框，既能發訊息給成員，也能給智能體派活。這種設計讓智能體成了協作流程的一部分，而不是一個需要單獨打開的外掛。
04 什麼時候該建一個項目組
不是所有協作都需要項目組。把場景對清楚，反而用得更好。
▲ 圖 5｜任務週期長、上下文重、需要智能體參與的課題，才值得開項目組
一次性的通知、幾分鐘能說清的討論，普通溝通就夠了。但如果是一個持續數週或數月的課題，需要反覆回看材料、需要多人共同修改檔案、需要智能體參與檢索或寫作，那共研工作坊的容器優勢明顯。它不是為了替代聊天，而是為了給長週期協作一個穩定的上下文底座。
▲ 圖 6｜從創建項目組到迭代出稿，上下文始終留在項目空間裡
實際用起來，流程大致是：創建項目組、沉澱檔案、在聊天裡@智能體、圍繞共享上下文迭代、最終交付。可貴的是，整個過程的可追溯性不是額外記錄的，而是容器自帶的。
05 邊界
照例把邊界擺在明面上。
① 本篇講的是功能位置與機制，不構成效果承諾。 項目組能集中上下文，但不保證協作一定高效；實際效果還取決於成員使用習慣、任務清晰度、檔案整理方式等因素。
② 項目創建人與普通成員的權限分工需要人工理解。 功能上區分了角色，但課題內的學術判斷、分工安排、知識產權歸屬，仍需團隊自行約定。
③ 項目組內共享的檔案與討論內容，應遵守所在機構的科研資料管理與私隱規定。 涉及未公開資料、敏感資訊或合作方保密協議時，以機構現行規定為準。