权限与安全
5 种权限模式 + LLM 风险分级 + Human-in-the-loop 设计
本页解决的问题
先给结论「权限与安全」要解决的关键问题是什么？
5 种权限模式 + LLM 风险分级 + Human-in-the-loop 设计
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
| # | 操作 | 工具元数据 | 风险评估 | 处理结果 |
|---|
「选择权限模式」里的风险边界在哪里
「5 种权限模式 + LLM 风险分级 + Human-in-the-loop 设计」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「5 种权限模式 + LLM 风险分级 + Human-in-the-loop 设计」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
安全设计必须包含失败和恢复
结合「5 种权限模式 + LLM 风险分级 + Human-in-the-loop 设计」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「选择权限模式」走到「场景模拟」
「选择权限模式」先把问题落在「确认模式 默认 每个危险操作都需用户确认 自动模式 危险 所有操作自动放行，无需确认 智能模式 示例系统 LLM 分类器评估风险等级，按级处理」上；到了「场景模拟」，讨论继续推进到「场景模拟：Agent 想执行 5 个操作 观察当前模式下每个操作的处理方式 ▶ 运行模拟 重置 # 操作 工具元数据 风险评估 处理结果 选择权限模式 → 点击运行 → 观察差异」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「选择权限模式」：确认模式 默认 每个危险操作都需用户确认 自动模式 危险 所有操作自动放行，无需确认 智能模式 示例系统 LLM 分类器评估风险等级，按级处理
- 「场景模拟」：场景模拟：Agent 想执行 5 个操作 观察当前模式下每个操作的处理方式 ▶ 运行模拟 重置 # 操作 工具元数据 风险评估 处理结果 选择权限模式 → 点击运行 → 观察差异
- 「三个设计决策」：📌 设计决策 1： 权限设计的核心矛盾：安全 vs 效率。每次弹窗确认都会打断用户流程，但不确认就可能造成不可逆破坏。你的产品选哪个？ 📌 设计决策 2： 示例系统 的「智能模式」用 LLM 来判断风险，但 LLM 判断也可能出错。一次误判可能删掉用户数据。这个风险你能接受吗？ 📌 设计决策 3： 「只读」和「破坏性」是工具级别的标记。产品经理要决定：你的每个工具属于哪个风险等级？这是产品决策，不能推给工程…
最后的「三个设计决策」把讨论落到「📌 设计决策 1： 权限设计的核心矛盾：安全 vs 效率。每次弹窗确认都会打断用户流程，但不确认就可能造成不可逆破坏。你的产品选哪个？ 📌 设计决策 2： 示例系统 的「智能模式」用 LLM 来判断风险，但 LLM 判断也可能出错。一次误判可能删掉用户数据。这个风险你能接受吗？ 📌 设计决策 3： 「只读」和「破坏性」是工具级别的标记。产品经理要决定：你的每个工具属于哪个风险等级？这是产品决策，不能推给工程…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。