AI Agent 的权限天花板：应用能做啥和马上做啥是两码事

过去几周，我一直在纠结一个确认弹窗——就在 StareBrain 发送短信、预约日历或者执行任何其他操作之前弹出的那个。参数绑定的 token 确保计划在确认和执行之间不会漂移。重新校验实时状态，防止预约的时段已经被人占走却仍然被错误预订。还有第三种状态 DENIED_UNRESOLVED，用于真正不知道派发后发生了什么的情况。这些都是真实必要的工程工作。

但这些都没有回答一位读者本周提出的另一个问题——来自一个不相关的项目：用户是否知道这个应用总体上能做什么，而不是此刻即将做什么？

两句话，两个意思

我构建过的每一个确认弹窗，答案都是"这是即将发生的具体事情"。它从未回答"这件事背后的天花板是什么"。用户确认"发送这条短信给 Sarah"，但他们看不到同样的授权是否也覆盖读取联系人、日历，或者同一权限授予中打包的其他任何能力。他们在确认一个动作，而不是在确认一个行为者。

这件事的意义比听起来的要大得多，因为两种失败模式完全不同。一个糟糕的动作确认，意味着错误的短信被发出。一个糟糕的权限披露，意味着用户一次一个动作地同意了一些远比他们意识到的要大得多的东西，却从未看到所同意事物的全貌。

需要一个持久的、独立的界面——不是埋在设置深处——在第一个动作确认弹窗触发之前，就回答"这个应用目前能做什么"。不是那种在安装时没人看一次的权限清单。而是在一个真正能读懂的时刻展示：就在风险变得具体、而不是在 onboarding 时抽象存在的时刻。

同一套形状，多了一层

这和我几周来在执行端一直在兜圈子的东西是相连的：系统报告自己的权限，和 webhook 报告自己的投递状态，是同一种自我报告行为。"我检查了我的权限，我被允许做这件事"是一个声明，不是证据——正如"短信发送成功"是当事方有理由这么说的一方之词。

修复方法在本质上和执行证据修复也没什么不同：把披露的生成与用户判断它的能力分开。我的工作是诚实而完整地展示天花板。用户的职责——而不是我的——是决定那个天花板是否是他们可以接受的。

下一步就是做这个。确认动作和披露权限原来是两件不同的事，而我之前只做了其中一件。