一份文档→多 Agent 协作+无数分支

从第一性原理看，企业文档首先是一块共享状态，文件只是它的载体。

过去的协作重点，是让多人看见同一份内容，知道谁改了什么。光是多人同时编辑、评论、追踪权限和历史版本，就足以改变组织效率。

AI 进来以后，状态同步还不够。因为 Agent 不会只留一两句评论，它会生成方案、改结构、补资料、重写段落、拆任务、生成检查项。

如果所有 Agent 都直接改主文档，主文档会很快失控。它会充满未确认的判断、不同人的偏好、互相打架的版本。

所以文档会更像代码仓库：有主线，有分支，有 diff，有 review，也有 merge。

一个销售 Agent 可以基于同一份方案改客户版；一个法务 Agent 可以标出风险；一个产品 Agent 可以补需求边界；一个管理者 Agent 可以把它压成决策摘要。它们一开始都不该直接写进主文档。

更好的形态，是每个 Agent 先在自己的分支里工作。分支可以是版本、批注、建议、局部章节，也可以是一份派生文档。等人确认之后，再合回主线。

这件事对产品提出三个很硬的要求。

第一，和生态内办公软件打通。文档、表格、日历、IM、会议、审批，都不能只靠复制粘贴。Agent 要读得到真实上下文，也要写得回真实位置。

第二，工作空间要被创建出来。一次任务不能散落在聊天记录、附件和本地文件里。它需要自己的空间：文档同步、素材、权限、执行记录、分支关系，都放在这里。

第三，垂直场景要足够明确。合同、周报、销售方案、需求评审、项目复盘，调用的 Agent、模板、权限和验收标准都不一样。

设计文件和代码会很快遇到同一个问题。设计文件会有不同 Agent 改视觉、动效、组件；代码仓库已经有分支模型，但 Agent 多了以后，分支数量、review 成本和合并策略都会被放大。

视频会议也会变。每个人都可能带着自己的 Agent 进会，帮自己记录关心的点：销售记客户顾虑，产品记需求变化，工程记实现风险，管理者记决策和责任。

这听起来很有效，也很危险。会议里到底哪些内容被记录、被谁的 Agent 记录、能不能进入个人知识库、能不能进入公司资产，都要透明。

数据需要安全、透明；Agent 需要个性化。前者保护组织边界，后者保护个人工作方式。两者只要混在一起，就会出问题。

最后，评估体系也会被改写。以前评估一个人的产出，看的是他写了什么、交了什么、推动了什么。以后很可能还要看他的 Agent 产出了什么，分支质量怎么样，合并成本高不高，留下的资产能不能被别人复用。

人的能力不会消失，但会换一个观察面。会用 Agent 的人，除了自己输出更快，还能让自己的 Agent 在组织里留下更干净、更可合并的工作。