Read Only
文件范围read-only
审批ask
内部技术分享
权限审批
怎么少点几次
先看 Harness 现在怎么做，再看批量整理书签为什么会一直弹审批，最后对比三种处理办法。
01 / 现状
一次工具调用，要过四道关
先判断要不要问，再交给审批服务，用户确认后还有最后一道只会拒绝的 Guard。
1 · Call工具调用名称 + 参数
→
2 · Check前置判断放行 / 拒绝 / 询问
→
3 · Approval审批服务ask / never
→
4 · User用户确认拒绝 / 允许一次
→
5 · Guard最终检查只能再拒绝
Workspace Write
文件范围workspace-write
审批ask
Full Access
文件范围danger-full-access
审批never
02 / 问题
浏览器写操作，每次都会问
读操作在当前会话里能记住；写操作没有 remember key。
以整理书签为例
W 次写 = W 次点审批
移动、重命名、建目录、删除，如果被拆成多次调用，就会连续弹多次。
问题不在总量，在调用链
移动书签→人工审批→执行
重命名→人工审批→执行
···
删除重复项→人工审批→执行
browser_capabilities 只是读取能力目录，不会弹审批。真正反复弹的是 browser_call 的写方法。03 / 方案
三种办法，差别在放开多少
下面直接看实际界面和用起来是什么效果。
全局免审
打开开关后，所有审批自动通过。
按能力长期允许
第一次确认后，同类操作以后不再询问。
智能自动审批
不问用户，规则和模型直接判定。
方案 A
全局免审模式
开关打开后，审批卡片不再出现；重启后仍保持当前选择。
书签整理写操作不再需要点击
文件范围仍可保持 Workspace Write
风险所有审批一起放行，开完要记得关
实际效果：20 次浏览器写操作，人工点击 0 次。
方案 B
按能力长期允许
审批卡片改为“拒绝 / 允许一次 / 以后都允许”。第一次选择“以后都允许”后，相同能力和读写类型不再询问。
授权 Key能力 + 读写类型 + 目录摘要
失效条件用户撤销，或浏览器能力目录变化
书签整理首次批准写权限，后续写操作直接执行
实际效果：只放开书签写能力，不会顺带放开历史记录、下载等其他浏览器能力。
方案 C
智能自动审批
增加一档全托管模式。白名单直接过，危险规则直接拦，其余交给模型判断。
人工点击0 次
运行范围Full Access
代价多一次模型判断，有时延和误判
实际效果：书签任务可以无人值守跑完，但审批人从用户变成了规则和模型。
04 / 对比
放得越开，越省点击
没有哪个方案全占优，关键看任务要什么。
| 对比项 | 方案 A · 全局免审 | 方案 B · 按能力长期允许 | 方案 C · 智能审批 |
|---|---|---|---|
| 书签写操作免点击 | 可以 | 首次确认后可以 | 可以 |
| 授权持续时间 | 一直保持，直到手动关闭 | 直到撤销或能力目录变化 | 处于全托管模式期间 |
| 文件沙箱 | 可保持 Workspace Write | 保持 Workspace Write | Full Access |
| 额外模型调用 | 没有 | 没有 | 有 |
| 主要问题 | 范围太大，容易忘关 | 需要补授权存储和撤销入口 | 误判、时延、成本 |