企业网盘的下一站,会是文档操作系统吗?

做企业网盘的产品，经常要回答一些很具体的问题。文件能不能传得更快，外发能不能更安全，权限能不能再细一点。这些事情都重要，客户每天都在用。

但最近，我开始想另外一个问题：如果越来越多的工作交给 Agent，企业网盘会变成什么？

过去，网盘主要服务于人。人找到文件，下载到电脑，打开软件处理，再把结果传回去。以后，发起任务的仍然可能是人，查找资料和处理文件的却是 Agent。它需要一个可以反复访问的工作空间，任务中断以后，资料和进度也不能跟着消失。

这个说法听起来有点大。我更愿意从一个普通的投标项目说起。

销售要找过去的案例，技术人员要拿到最新的产品资料，商务同事要核对资质，最后还有人负责审核。今天即使这些文件都在网盘里，大家仍然需要反复确认，哪份可以用，哪份已经过期，哪份只允许内部查看。

假设把其中一部分工作交给 Agent，原来的问题一个也不会自动消失。它找到一份旧方案，写得再流畅也可能用错产品参数。它能读内部报价，也不代表它可以把报价放进准备发给客户的材料里。

网盘如果只把文件内容交出去，这个任务还没有完成。它还得让 Agent 知道资料的版本和使用范围，让生成的文件进入审核流程，出错时能找回修改前的内容。

我所理解的文档操作系统，要解决的就是这类具体问题。不同的人和 Agent 围绕同一批资料接着工作，前一个环节做过的事，后一个环节能够看见，也能核查。

资料在同一处流转，查找、修改和审核都有迹可循。

这条路已经有人在走了。

2026 年 11 月 5 日，Dropbox 宣布 DBX Agent Cloud，从独立的对象存储服务切入，并计划增加文件系统和内容处理能力。它明确提到了 Agent 跨任务、跨会话访问文件的需求。需要注意，文件系统和内容处理是后续计划，不能当成已经完整交付的产品。

微软同月公布的 SharePoint 工具预览，则把 60 多种内容操作通过 Work IQ MCP 开放给 Agent。调用者可以查找文件，也能在授权范围内处理列表、审批和版本等工作。

国内也有类似进展。阿里云 PDS 的文档已经列出通过 MCP 查找、整理和分析网盘文件的能力，还支持将处理结果保存回网盘。

这些动作让我更确信，企业网盘需要认真考虑 Agent 会怎样使用自己的产品。不过，厂商推出新能力，还不能证明客户一定会持续付费。这个判断最终要回到真实工作里验证。

RAG 是这里绕不开的话题。

把文档解析出来，分片、向量化，再根据问题检索相关内容，能够解决一部分知识问答需求。但如果把文档操作系统理解成一套规模更大的 RAG，后面的产品很容易做窄。

找合同编号时，准确匹配往往很有用。判断哪份制度生效，要看版本和审批状态。汇总全部订单需要读取表格数据并计算。要修改一份方案，还得处理文档结构和修订记录。检索到几个相似片段，离完成这些工作还有距离。

所以，我很看好给网盘提供一套 Agent 能调用的文档操作能力。

可以有类似 grep 的精确查找，也可以按章节读取报告，按单元格读取表格。Agent 修改文件以后，系统要能展示差异，把草稿提交给人审核。涉及扫描件，就先做好识别，并保留对应的原始页码。每种操作都应该有清楚的权限边界。

这些工具不需要摆在普通用户面前。用户可以只说“用最新材料整理一份项目方案”，Agent 在背后选择合适的工具。企业网盘负责把工具做好，让调用结果稳定、可理解，操作失败时也能解释原因。

原来的文件夹在这个过程中仍然有用。项目目录告诉 Agent 资料属于什么工作，文件的修改时间提供线索，审批状态说明它是否已经被确认。把这些信息全部压成没有来历的文本片段，反而会丢掉企业工作里很重要的判断依据。

2026 年 9 月发表的 CorpusMap 研究也关注到了这个问题。研究者在文档之间增加实体导航，让 Agent 沿着同一个项目或实体找到分散的证据，在其测试中改善了检索和回答效果。这还不能直接证明它适合所有企业，但至少提醒我们，文件之间的关系值得保留。

文件存储之上，逐步建立内容理解和文档操作能力。

至于 Agent 的上下文，我觉得可以存进网盘，但得先分清楚存的是什么。

企业确认过的制度，是正式知识。Agent 为某个任务写下的阶段性判断，还只是工作记录。为了处理一张表临时生成的文件，用完可能就该清理。它们即使放在同一个产品里，也不应该遵守完全相同的规则。

尤其是长期记忆。如果 Agent 上次理解错了一条产品规则，又把错误保存下来供下次使用，存得越久，影响可能越大。记忆也需要记录来源，允许纠正，并在原始材料变化时重新检查。

多 Agent 协作还会带来一个很实际的问题。两个人同时改一份文档，我们已经知道要处理冲突。两个 Agent 同时改，也不能简单地以后写入的版本覆盖前一个版本。任务做到一半失败，再次启动时，还要知道哪些动作已经完成，避免重复修改。

这些工作做起来很细，也不太容易在发布会上讲得热闹。但客户是否敢把正式任务交给 Agent，很大程度上就取决于这些细节。

我对“网盘会成为未来的浏览器”这个判断，反而保留了一些疑问。

浏览器掌握着用户入口。未来的人可能在聊天工具里发起任务，也可能在办公助手或业务系统里直接调用 Agent。网盘在后台被频繁访问，自己的网页却未必被打开。

微软最近公布的一项安排就很值得关注。它计划从 2026 年 11 月中旬开始，将 SharePoint Agent 的创建和管理迁移到更广泛的 Microsoft 365 Agent 平台。SharePoint 继续提供受治理的知识，Agent 的生命周期则由另一层管理。截至本文写作时，这仍是即将启动的迁移计划。

如果客户换了模型，或者改用另一个 Agent，原来的资料和工作成果仍然能够继续使用，这本身就有价值。能让客户保留选择权，也可能成为企业网盘的竞争力。

如果员工在别处完成全部工作，只在项目结束时上传一个压缩包，网盘拿到的就是事后的归档。这样的资料当然有保存价值，却很难支持 Agent 参与日常任务。要往文档操作系统走，就得进入文件产生和修改的过程，让工作成果持续回到平台上。

我不会一开始就按完整操作系统的规模立项。更现实的做法，是从已有客户的一个重复任务开始。

比如检查项目交付资料。客户给出清单，Agent 查找对应文件，标出缺失项和版本问题，生成一份可以核查的结果，再由项目负责人确认。先让这件事稳定做成，观察它到底省了多少时间，用户还要改多少，愿不愿意下个月继续用。

如果客户只是偶尔问几个问题，后续投入就需要谨慎。如果任务反复发生，成果持续保存下来，其他同事也开始接着使用，才有依据把能力往更大的范围扩展。

我希望未来客户打开企业网盘时，能够直接把一项文档工作交给它。至于这项工作由哪个模型理解、哪个 Agent 执行，可以有不同选择。项目结束以后，资料和成果仍然归企业所有，团队能够看清做过哪些修改，并从这里继续下一项工作。

配图为 AI 生成的概念插画