文章目录
很多 AI 工作从上传附件开始，也在回答生成后结束。原始材料、修改后的文件和下一次工作的输入，往往散落在不同对话里。每次重新开始，人又要解释背景、寻找文件并上传一遍。
brazosd 把云盘作为持续的工作环境。文件有自己的位置和访问边界，可以在对话之外继续存在。Agent 可以读取材料、产生新文件，应用和其他界面也能在授权范围内使用这些成果。
文件为什么是一种基础设施
文件承载着大量真实业务：合同、报表、设计稿、录音和项目资料。它们不只是模型的一次性输入，也是人之间、应用之间可以共同理解的交付形式。
如果每个 Agent 和应用都维护自己的附件孤岛，同一份材料会不断复制，更新后也难以判断哪份才是原件。共同的文件体系让应用围绕持久材料协作，而不必先把数据搬进自己的封闭空间。
云盘在这里既服务人，也服务 Agent。人通过文件夹和预览理解内容，Agent 通过工具和 API 读取、组织和写入。两者操作的是同一套资源，而不是界面中的一份副本和 Agent 内部的另一份副本。
知识库首先要解决事实的归属
把文件放在一个目录里，并不自动形成可靠的知识系统。一个回答需要知道依据来自哪里，材料是否适合当前问题，以及当前用户是否可以访问。
云盘为原始材料提供归属和访问方式。围绕它构建知识应用时，还需要决定文档怎样提取、如何切分、什么时候更新索引、回答如何引用原文。
| 层次 | 负责保存或处理什么 |
|---|---|
| 云盘原始材料 | 可核对的文件内容与成果 |
| 处理与索引流程 | 文本提取、分段、更新 |
| 检索层 | 根据问题寻找相关材料 |
| Agent | 理解问题、组织答案、说明依据 |
表格可以左右滑动
这几层不能混为一谈。模型的回答是基于材料产生的解释；原始文件仍是核对事实的重要依据。
向量检索扩展了应用的选择
传统关键词搜索依赖字面匹配。向量检索把内容转换成数字特征，用相似程度寻找相关片段，适合表达不同但含义接近的问题。
brazosd 的 SQLess 云数据库已经内置 sqlite-vec。应用可以把业务记录、文档片段信息和向量检索放在 SQLite 的 SQL 接口下组织。
这为构建知识应用增加了一种选择，但不会自动为整个云盘生成索引。开发者或 Agent 仍要建立提取和嵌入流程，并处理删除、更新和访问范围。搜索到一段内容之前，就应考虑检索者是否有权读取它，而不是等答案生成后再隐藏一个链接。
文件、会话和业务记录各有职责
文件保存内容，会话保存围绕工作的持久记录，云数据库保存应用的结构化状态。例如，一份项目报告在云盘中，Agent 对它的分析在会话中，项目管理应用的负责人和进度在 SQLite 中。
它们可以相互引用，但不宜互相冒充。聊天里提到“已归档”，不代表文件真的完成移动；数据库里有一个文件名，也不代表它拥有那份文件的最新内容。
这正是单一事实来源的重要性：每类事实有明确归属，其他界面通过引用和读取使用它。
协作需要权限与变化同步
共同文件系统并不意味着所有人看同一份目录。个人、组织以及不同业务资源有各自的访问范围；企业权限可以进一步细分读取、写入和删除等动作。
当文件发生变化，相关界面还需要更新。UnoZ OS 已经利用云盘事件刷新受影响的文件视图，让桌面、窗口与后台变化保持联系。
实时通知用于让界面接近当前状态，持久数据仍由资源系统负责保存。网络断开后的页面不能仅凭缓存就成为新的事实来源。
从附件，变成可以积累的工作环境
云盘让 Agent 的成果有机会进入下一轮工作：研究资料继续用于分析，生成的文档进入项目目录，应用读取已有文件，另一个 Agent 接着处理。
这种积累减少的是每次任务重新建立背景和搬运材料的负担。知识质量仍取决于材料、检索和判断，但共同的数据基础让这些环节可以持续改进。
UnoZ OS把它呈现为文件系统；Serverless让应用围绕它运行；Agent > UI让人可以直接表达如何组织和使用这些资源。