科研协作里最累人的往往不是分任务，而是传上下文。A 让 B 改一段综述，B 找不到 A 说的那篇文献；C 在群里发了一个数据表，三天后 D 又问「那个表在哪」。这些 friction 的本质不是人懒，是信息散落在聊天、邮件、网盘之间，没有一个共同的工作台面。MuchSci 的共研工作坊就是冲着这个问题设计的：它把一个课题组需要的「人、智能体、文件」放进同一个空间，让大家围绕同一份上下文推进。
理解它的方式，是把「聊天工具」和「协作容器」分开。前者负责传递消息，后者负责维持一个课题的完整上下文。共研工作坊属于后者。
01 科研协作的真正难点不是分任务，是传上下文
先看一个最直观的对比。
▲ 图 1｜普通群聊聊完就散，共研工作坊把材料、角色、过程留下来
普通沟通的问题不在于不能发消息，而在于消息和文件会随时间下沉。三天前发的 PDF、上周定的结构、上个月讨论的假设，要靠人工翻找才能复原。科研协作的上下文是累积的，不是每一轮都从空白开始。如果容器本身不能承载这种累积，团队成员就只能一遍遍重复解释。
共研工作坊的做法，是给每个课题一个独立空间。这个空间里有固定成员、有绑定智能体、有项目级文件和历史记录。打开它，就能回到上一次离开时的状态。这一点对跨周、跨月的课题尤其重要。
02 项目组是怎么把三类对象放在一起的
打开 MuchSci 的「我的项目组」，你能看到一个课题组的基本骨架。
▲ 图 2｜共研工作坊内部：成员、智能体、文件三类对象共享同一空间
第一层是成员。 项目创建人与普通成员在列表里被明确区分。这个区分不只是标识，它决定了谁有权限调整项目结构、谁可以退出项目组。科研协作里角色本来就有差异，把差异显式化，能减少后续权限纠纷。
第二层是智能体。 项目组可以绑定多个智能体，例如论文检索、办公助手、化学信息学等。绑定之后，成员在聊天里输入 `@` 就能唤起它们。这意味着智能体不是游离在对话之外的工具，而是项目组的常驻成员。
第三层是文件。 知识库、文献、草稿、交付物都随项目留存，不会被新的聊天消息冲走。文件和对话在同一个容器里，讨论时可以直接引用材料，而不是抛出一个文件链接让大家自己找。
03 在项目组里说话，和群聊有什么不同
截图里是一个叫「产业部」的项目组。它的卡片上写着绑定的智能体，底部有「进入共研工作坊」按钮。
▲ 图 3｜「我的项目组」列表：一个项目组绑定多个智能体，点击进入协作空间
进入项目组后，界面更像一个课题工作台。顶部有「返回 产业部」和「历史聊天记录」；右侧分三个标签：成员、智能体、文件；底部输入框提示「输入 @ 可唤起绑定的项目组智能体，例如：@办公助手 帮我生成一份演讲稿」，旁边还有「+ 知识库」入口。
▲ 图 4｜项目组内部：成员列表区分创建人与普通成员，聊天可直接@智能体
这里的关键是「@」机制。 在普通聊天里，@一个人是叫他来看消息；在项目组的聊天里，@一个智能体是调用它的能力。同一个输入框，既能发消息给成员，也能给智能体派活。这种设计让智能体成了协作流程的一部分，而不是一个需要单独打开的插件。
04 什么时候该建一个项目组
不是所有协作都需要项目组。把场景对清楚，反而用得更好。
▲ 图 5｜任务周期长、上下文重、需要智能体参与的课题，才值得开项目组
一次性的通知、几分钟能说清的讨论，普通沟通就够了。但如果是一个持续数周或数月的课题，需要反复回看材料、需要多人共同修改文件、需要智能体参与检索或写作，那共研工作坊的容器优势明显。它不是为了替代聊天，而是为了给长周期协作一个稳定的上下文底座。
▲ 图 6｜从创建项目组到迭代出稿，上下文始终留在项目空间里
实际用起来，流程大致是：创建项目组、沉淀文件、在聊天里@智能体、围绕共享上下文迭代、最终交付。可贵的是，整个过程的可追溯性不是额外记录的，而是容器自带的。
05 边界
照例把边界摆在明面上。
① 本篇讲的是功能位置与机制，不构成效果承诺。 项目组能集中上下文，但不保证协作一定高效；实际效果还取决于成员使用习惯、任务清晰度、文件整理方式等因素。
② 项目创建人与普通成员的权限分工需要人工理解。 功能上区分了角色，但课题内的学术判断、分工安排、知识产权归属，仍需团队自行约定。
③ 项目组内共享的文件与讨论内容，应遵守所在机构的科研数据管理与隐私规定。 涉及未公开数据、敏感信息或合作方保密协议时，以机构现行规定为准。