Muse 真正开始替你做事后，你一定会遇到一个画面：
Approval。
例如：
AI 已经帮你把 Email 写好。
准备寄出。
或者商品已经找到。
准备付款。
Muse 会停下来问：
要不要允许？
很多人这时候只会看：
「Yes 还是 No？」
但今天要多看一件事：
「这个 Yes 到底可以用多久？」
Muse 的 Approval 不只分「准、不准」
Meta 对 Muse 的安全设计里，有一个独立的 Sentinel。
它不是负责替你完成主要工作。
而是专门判断：
Muse 现在要求的 Connector Action 或网络操作，到底可以：
允许。
拒绝。
还是需要再问用户。
如果需要你批准，系统会停下来。
Muse 本身不能自己偷偷替你按 Yes。
但更重要的是：
批准也有 Scope。
Scope 可以理解成：
这个权限到底涵盖多大的范围。
Meta 支持哪些 Permission Scope？
Meta 技术文档列出的 Muse Approval 类型包括：
One-time。
也就是只允许这一次。
Session-scoped。
只在这个 Session 有效。
Task-scoped。
只在这个 Task 有效。
Time-bounded。
只在一段指定时间内有效。
以及：
Perpetual。
持续有效。
不过不是每一次 Approval 画面都一定会把所有选项全部列出来。
Meta 说明，是由 Sentinel 根据这次行为决定哪些 Grant Type 适合提供。
所以今天不是教你：
「每次一定会看到五个按钮。」
而是教你一个判断方式。
今天只记一条：第一次先给最短 Scope
假设你第一次叫 Muse：
「帮我写一封 Email 给饭店，询问有没有机场接送。」
Muse：
查完数据。
写好内容。
准备寄出。
这时如果画面提供：
只允许这一次。
和：
以后都可以替我寄信。
第一次比较合理的选择通常是：
只允许这一次。
原因不是你一定不能信任 Muse。
而是：
你目前真正需要的权限，本来就只有寄这一封信。
不要把「省一次点击」变成「多很多未来权限」
想像另一个情况。
你今天只是请朋友帮你进家里拿一个包裹。
你会给他：
今天下午可以进门一次。
还是：
从此以后永久持有你家钥匙？
不是说这个朋友一定不可信。
而是：
完成今天这件事，根本不需要永久钥匙。
AI Agent 的权限也是一样。
如果任务只需要一次：
就先给一次。
如果整个 Task 需要反复做同类动作：
再考虑 Task Scope。
只有真的出现稳定、长期、重复工作时：
才值得重新评估更长的授权。
例如：整理进程和寄信需要的权限不一样
假设你请 Muse：
「帮我规划下周的出差。」
它可能需要：
读 Calendar。
读 Email。
找航班。
比较饭店。
最后准备寄一封确认信。
你不需要因为它要完成整个旅行规划，就把所有权限都设成同样长度。
读 Calendar：
如果整个 Task 都需要，可以考虑 Task Scope。
寄出最后那封 Email：
可能只需要 One-time Approval。
付款：
更应该针对每次实际交易确认。
这才是 Permission Scope 真正的用途。
同一个 Agent，不同 Action，可以有不同权限长度。
「这次准了」也不等于「以后任何事情都准了」
Meta 的 Muse Approval 还有另一个重要设计。
批准不是只记一句：
「这个人相信 Muse。」
Permission 会绑定到比较具体的：
Connector。
Destination。
Use Case。
也就是：
哪一个服务。
要去什么地方。
做什么事情。
这比单纯在 Prompt 里说：
「你以后可以帮我处理。」
更接近真正的技术权限。
例如你批准 Muse：
替这次任务寄出某封 Email。
不代表 Muse 因此取得：
任意登录其他网站。
任意使用所有 Credential。
任意代表你做其他事情。
为什么要从最短权限开始？
因为 AI Agent 和一般 App 最大的差别，是它会自己走很多步。
一般 App：
你按一个按钮。
它做一件固定的事。
Agent：
你给一个 Goal。
它可能：
找数据。
开网站。
读 Email。
调用 Subagent。
填表。
再根据中途得到的新数据决定下一步。
这种弹性就是 Agent 好用的地方。
但也代表：
它未来会遇到的情境，很难全部在第一天预测。
所以在你还不了解一个工作流程之前：
权限愈长。
未来可以作用的情境也愈多。
最简单的方法：问「这件事做完后，权限还有存在的必要吗？」
下次看到 Muse Approval，可以先不要立刻按。
只问自己一句：
「这件事完成后，这个权限还有存在的必要吗？」
如果答案是：
没有。
选一次性。
如果答案是：
这整个 Task 还需要。
考虑 Task Scope。
如果答案是：
今天工作期间还会反复使用。
才考虑比较适合的 Session 或限时 Scope。
只有当你真的确认：
这是一个长期固定流程。
风险也可以接受。
才重新评估 Persistent 或 Perpetual Permission。
先小，再慢慢放大
可以把它记成：
一次 → 一个 Task → 一段时间 → 长期。
不要反过来。
第一次直接：
长期全部打开。
之后发现太大，再慢慢往回关。
因为在 Agent 世界里，最容易失控的往往不是：
「AI 完全没有权限。」
而是：
以前为了方便给出去的权限，后来大家忘记它还存在。
但「最短 Scope」不是所有情况永远最好
如果你每天都固定叫 Muse：
整理同一个 Calendar。
在同一个范围读取同样数据。
每次都要求相同操作。
人工每次重新批准可能真的没有必要。
这时较长的 Permission Scope 就可能合理。
所以今天的原则不是：
永久权限一定错。
而是：
第一次不要因为怕麻烦，就直接从最大权限开始。
先让工作真的跑过。
看看 Agent 做了什么。
确认 Audit Trail。
看看有没有意料之外的步骤。
再决定是不是值得延长。
Approval 也不是万用安全保证
就算你永远选最短 Scope，也不能得到：
「Agent 绝对不会出错。」
Meta 自己明确表示：
Muse 仍然可能犯错。
也可能读到带有 Prompt Injection 的外部数据。
所以 Muse 除了 Human Approval，还另外使用：
Secure VM。
Credential Isolation。
Sentinel。
网络出口控制。
Prompt Injection 侦测。
以及其他技术边界。
这代表：
Approval 是安全层之一，不是全部。
人的 Permission Choice 也不能取代系统本身的安全设计。
今天实际怎么做？
下次 Muse 跳出 Approval 时：
先不要只看：
「它现在想做什么？」
多看第二个问题：
「我这次批准之后，它可以用这个权限多久？」
如果只是完成现在这一件事：
选最短可用 Scope。
先跑一次。
看完结果。
再决定下一次要不要放大。
这个动作可能只多花几秒钟。
但当 AI Agent 开始碰：
Email。
Calendar。
帐号。
购物。
付款。
真正代表你对外做事时：
权限多一天。
和只准一次。
已经不是同一件事。
所以今天只记一句：
第一次授权 Agent，不要先问「怎样最方便」，先问「完成这次任务最少需要多久」。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 快问快答｜2026/09/01：OpenClaw 固定 Automation 已经核准一次，就代表之后每次运行都安全、不用再看吗？
AI 一分钟教学｜2026/09/01：OpenClaw 跑固定工作前，先写「能做、一定停、凭证怎么拿」最小权限卡
AI 快问快答｜2026/09/03：Workspace Studio 已经设置 Approval，就代表所有高风险动作一定会停下来吗？
