没人认真讨论的权限难题
多数 AI 编码工具只有两种模式：所有操作都询问，或所有操作都自动批准。实际使用时，两边都不理想。全部放行太冒险——你不会希望 Agent 不经确认就运行 rm -rf；全部手动又令人疲惫——连读文件都要逐次确认，会破坏 Agent 编码最有价值的流畅感。
真正的问题不是“Agent 要不要自主”，而是“哪些操作可以自主”。读取源码通常安全，删除分支显然不是；安装依赖则处于两者之间。可用的权限系统必须能表达这些差别。
Onevium 的三种模式如何工作
Onevium 用三层权限对应不同的信任边界。每种模式都是光谱上的一个位置，而不是非黑即白的开关。
- 默认模式：每次工具调用都需要明确批准。适合不熟悉的代码库、敏感环境，或你想逐步观察 Agent 行为的时候。
- 自动模式：SDK 层分类器实时评估每次工具调用，自动批准它判断为安全的操作，例如读取文件、类型检查和 git status。破坏性或含糊的操作仍会请求批准，让你保持节奏，也保留监督。
- 完全访问模式：所有操作自动批准。适合速度比人工监督更重要、且环境已经受信任的场景，例如个人项目、CI 流水线或隔离的开发分支。
让自动模式真正可用的分类器
自动模式不是静态白名单。分类器会查看每次工具调用的工具名、参数和当前上下文，并实时判断风险。运行测试套件的 shell 命令可以批准，同一个 shell 工具若要执行部署脚本，则会被拦下。
同一种工具是否安全，取决于它如何被调用。写入测试夹具很常见，写入生产配置则不同。静态规则无法覆盖这种差异，理解操作意图的分类器可以。
权限模式与能力模式是两条独立轴线
Onevium 有一个值得说明的设计：权限模式和能力模式彼此独立。系统另有 Plan 模式，Agent 只提出改动方案，不直接执行。Plan 可以和任意权限档位组合；例如 Auto + Plan 下，Agent 可以自由研究，但所有代码改动仍以提案形式交给你审查。
这种分离避免了 Agent 设计中的常见错误：把“Agent 能做什么”和“Agent 被允许做什么”混为一谈。模型能力本身不变，信任边界则是一项策略决策，应该能按会话、项目和用户调整。