系统把完全磁盘访问收回去之后：端侧智能体的接入面要重排
一、早期端侧智能体为什么偏爱粗权限
据公开报道，有一家厂商发出简短公告，宣布将在后续系统版本收紧个人电脑上存在多年的”完全磁盘访问”权限；有评论认为这会让个人智能体类应用更难拿到全盘读取。公告没有给出实现细节、豁免范围与审核口径，本篇不推断它最终怎么落地、以什么形式生效，也不评价这项收紧本身是否合理，那是平台侧的决定。能读出来的只有一件事：一个长期存在、被不少产品当成默认前提的粗权限，从此不能再被假设为可得。
三个理由都很实际。跨应用检索上下文：用户的提问经常是”我上周写的那份东西里有一段要改”，材料散在几个目录、几种应用里，逐个申请授权做不出这个体验。一次性索引：第一次运行时把整盘读一遍建好索引，之后提问不必反复找用户要权限，响应也快。省去逐个授权的转化率压力：每一次系统弹窗都是一次可能被打断的安装流程，产品侧的直觉是把弹窗次数压到最少。
三条合起来是一句商业逻辑：粗权限让产品的第一次运行最顺。代价在后面——能力清单从来没有按数据边界排过。产品文档里写的是一句”需要访问你的文件”，实现里靠的是同一个身份能读所有路径。一旦这个权限被收回，团队发现自己只有”能”和”不能”两种状态，中间没有分层，于是每个功能都要临时找替代路径，找出来的还未必合适。
二、核心交付物之一：四层能力与权限对照表
要重排就得先有一张按数据边界分层的表。我们按数据可及范围分四层，每层配一种授权交互，并写清这一层特有的失败形态。
| 层级 | 可及范围 | 典型任务 | 应配的授权交互 | 该层的失败形态 |
|---|---|---|---|---|
| 一 当前焦点文件 | 用户正在操作的那一个文件 | 摘要、改写、翻译、格式转换 | 随文件切换重新判定，一次确认只对当前文件生效 | 静默沿用上一个文件的内容作答 |
| 二 显式选中的目录 | 用户主动拖入或勾选的目录 | 项目内检索、批量整理、跨文件比对 | 目录级授权，界面上常驻显示已选范围与条目数 | 范围越选越大，用户不再记得选了啥 |
| 三 用户库与应用沙箱 | 文档、照片、音乐等系统定义的媒体库及本应用容器 | 个人资料问答、周期性整理 | 走系统给的范围，说明覆盖到哪、哪部分仍在范围外 | 库里哪些内容进了索引说不清 |
| 四 全盘 | 系统目录、其他账户目录、别的应用容器 | 极少有正当需求 | 不作为默认，也不写进首次引导 | 一旦拿不到，整个产品表现为不可用 |
分层的判据不是”能读到多少”，而是这个任务是否真的需要跨出上一层。把功能逐条对着这张表排一遍，通常会得出一个不太好接受的结论：原先靠全盘权限完成的功能，一大半本来不需要它，只是当时图省事。剩下那一小半才是真问题，得单独设计。
三、粗权限被收回后的四条替代路径
- 走系统提供的受控索引接口。由系统决定哪些内容可以被查询，产品不再自己遍历目录。好处是合规面最干净，代价是覆盖范围、字段粒度与更新时机都不由你控制，功能要按接口能力重写一遍，还要接受”查不到”是正常结果。
- 由用户拖入文件或目录。范围最明确，实现最简单，也最容易解释。代价是每次任务都要人做一次动作，长上下文任务会被打断，而且拖入的东西容易过期——同一份文件在两周后已经不是那份了。
- 按需临时授权，任务结束或到期自动失效。这是把权限窗口收窄的正确方向，代价在实现：要有到期机制、续期提示、任务中断后的状态处理，还要保证失效是系统层面的，不是只在界面上显示失效。
- 把任务搬到云端跑。本地权限问题看起来消失了，实际上换成了另一类问题：数据要出门。这条路径的前提是先讲清上传范围，哪一部分上、哪一部分留在本地、传输后保留多久，讲不清就不要用它绕权限。
四条按”数据离手的距离”排序：受控接口和临时授权数据不出机器，用户拖入出一次手但范围可控，云端执行出一次手且可能留存。选择顺序按这个距离来，而不是按实现难度。
四、失效告知规则：老用户的配置会静默变化
权限模型变化最伤的地方不是新功能拿不到权限，是已有功能悄悄失效。历史授权在新版本下不再等于原来的能力，用户不会收到任何解释，只会发现某一次回答明显变差。三条规则必须提前写进产品。
| 情形 | 界面行为 | 日志与留痕 | 恢复路径 |
|---|---|---|---|
| 权限从有变无 | 直接告知受影响的功能，不静默降级 | 记权限状态变化与判定时机 | 给出替代路径入口，不是一句”请先开启权限” |
| 从未获得权限 | 功能置灰并说明它需要看到什么 | 记首次申请时间与用户选择 | 保留只读或选段功能，不做全有全无 |
| 有权限但没有结果 | 明确回答”范围内没有匹配” | 与上一行分开记录，可区分 | 提示扩大范围的入口并说明代价 |
第三条是实现里最容易被合并的一项：无权限和查询为空经常返回同一个空集合。一旦合并，所有排障都会走错方向——用户以为产品搜不到，实际是没被允许搜；运维以为索引坏了，实际是权限被收回。日志里必须有两个不同的返回语义，界面上也必须有两句不同的话。功能从”能用”变成”不能用”时界面要不要说话，答案是要，而且要说清少了哪部分能力，而不是笼统弹一个错误码。
五、最小留痕与发布前检查
端侧智能体的留痕不需要记内容，需要记访问关系。三项最小集合：哪一次会话访问了哪个路径、是否落盘缓存、缓存的生命周期。第二项最关键：为了省时间，端侧普遍会把读过的内容留在本地索引或临时文件里，权限收回之后，这些历史缓存成了一个不受新权限模型约束的可读面。所以缓存要有四条属性——写入内容与索引粒度、保留期限、清理触发点、清理后的可验证方式。”重启会自动清”不算属性，要能被检查。
发布前检查这六项，任何一项做不到就不要发：
- 权限申请文案是否如实：说”用于搜索你的项目文件”和”用于读取全盘”不是一回事，文案写小了将来解释不清。
- 用户拒绝时能否继续跑：拒绝不是终止安装，而是给出降级形态并明确置灰受影响功能。
- 能力清单是否按四层标注：每个功能要能回答它工作在第几层。
- 无权限与无结果是否可区分：查日志而不是查代码。
- 缓存是否可清理并可验证：含升级后对历史缓存的处置。
- 灰度期能量化受影响比例：按历史授权状态分组统计，不要等用户反馈才知道谁坏了。
六、给企业客户的沟通口径
端侧部署和全盘权限的关系不能含糊，这是我们在这个方向上交付时吃过亏的地方：早期方案文档只写”需要本地文件访问”，等到客户环境收紧策略，才发现整套任务编排是建立在粗权限上的。现在交付文档里固定写三项：需要哪些授权，逐条与用途对应；能关掉哪些功能，关掉之后任务是否仍能完成；拿不到授权时的替代形态，走受控接口、走人工选文件还是走云端，云端那条要同时写清上传范围。
对企业客户还要额外说明一点：策略收紧通常是客户端一侧发生的变化，而不是服务端能承诺的稳定性。凡是把”能读全盘”写进方案的自动化，都应当在评审时被标注为高耦合设计。洹拓现在做端侧方案时，四层表是设计文档的第一页，通不过分层评审的功能不进开发。这次收紧对我们这样的从业者不是能力被收回，而是终于必须回答一个一直跳过的问题：这个功能到底需要看到什么。答不出这句话，产品的能力清单其实一直没被自己核对过。