点了“以后不再询问”，AI 就该一直有权限吗？
用 AI 干过一段完整工作的人，大概都能理解一种矛盾。
它什么都不问，直接动手，心里不踏实。可它每查一次资料、跑一次检查、执行一步操作，都停下来问“是否允许”，又让人觉得：到底是它在帮我，还是我一直在照看它？
于是，“允许，以后不再询问”成了一个很有吸引力的选项。
点下去，工作终于可以连续进行了。
但这个选择还值得多看一眼：用户想减少的是打断，系统保存的究竟是什么？这份同意会留多久，影响哪些后续操作，又在什么时候停止生效？
11 月 5 日，安全公司 Apiiro 发布研究，指出在其调查的部分公开代码仓库中，Claude Code 保存的获准命令包含凭据，并随着配置文件进入仓库。研究呈现的是凭据暴露，并不等于这些凭据都仍然有效或已经被利用。
Claude Code 官方文档也说明，“以后不再询问”会保存为本地许可规则，同时存在防止本地配置进入代码提交的忽略机制。因此，不能把这件事概括成每次授权都会泄密；需要核对具体的保存内容、文件状态和传播路径。
这项研究直接讨论的是凭据如何被保存和暴露。顺着它往下想，我们还会遇到另一个问题：即便凭据保存得很好，一份过去的许可，是否就足以支持未来的每一次行动？
一次操作的批准，被保存成持续生效的规则时，系统实际上替用户作了一次很重要的转换。
批准这次执行、允许以后重复执行、保存所需凭据、把配置分享给别人，这几件事有不同的含义。用户可能只注意到眼前那个确认按钮，系统却需要把这些边界分别处理清楚。
我们可以把这个问题放到一家企业里看。
假设一家连锁门店在双十一安排促销。运营负责人希望 AI 自动处理符合条件的订单，为指定五家门店的活动订单发放十元优惠券，每笔订单一次，总预算三千元，执行时间是当天上午十点到晚上十点。
这里的门店、金额和时间都是假设，只是为了把问题说具体。
负责人当然不希望 AI 每发一张券，就来请示一次。规则已经谈清楚，符合条件的事情自动完成，才是这项能力的价值。
但假如系统只把这段委托压缩成“允许调用发券功能”，麻烦就会出现。
晚上十点以后，还有订单进入。第二天，AI 发现另一家门店也可以使用同样的活动方案。原来负责活动的人调岗了，之前安排的定时任务却还在运行。
这些操作可能仍然使用同一个接口，甚至带着同一个账号。可企业允许它们发生的理由，已经不再一样。
“这个账号能发券”，只能说明它具备相应业务权限；“这次活动允许自动发券”，还包含对象、时间、预算和委托范围。前者没有失效，不能直接推出后者仍然成立。
机器记住了我们曾经说过“可以”，还需要有机制判断，眼前这件事是不是当时允许的那件事。
这也解释了为什么，仅仅把按钮做得更醒目、警告写得更长，往往不够。
人点击时看到的是一项具体工作。系统长期保存的，可能是一个抽象的操作权限。任务中的条件如果没有被承接下来，之后复用权限时，就可能把新的业务情况也当成已经获得批准。
在前面的活动中，三千元预算也不能由每个助手各自记一遍。假如两位助手同时处理订单，都认为自己还没有超过三千元，合起来仍然可能超支。企业需要一份实际共同生效的额度记录，并在支出发生的位置约束它。
这类问题很难仅靠“提醒 AI 不要超预算”解决。提醒可以帮助它规划，业务规则还需要在行动真正发生时被执行。
长期授权可以成立，但它应该是一份有条件的委托，而不只是被记住的一次点击。
这里的“有效期”，也不必总是一张日历上的日期。
有些委托在任务完成时结束，有些在额度用尽时结束，有些在人员角色、业务对象或组织政策变化后需要重新判断。另一些低风险、长期重复的工作，可以持续运行，只要适用范围明确，也能被查看、修改和收回。
例如，每天为负责人生成指定门店的经营摘要，可以是一项持续的安排。它不必每天早上重新问一次。但如果负责人不再负责这些门店，原来的安排就需要跟着改变。
所以，我们真正需要设计的是：哪些变化会让原来的同意不再足够，以及谁有权决定继续。
模型可以帮助识别变化、说明影响、提出新的执行方案。新的范围是否被允许，仍然要来自有资格作决定的人或组织规则，不能因为它觉得“这样更有利于完成目标”，就自行延长原来的委托。
再往前一步，还需要回答：企业说“停”，究竟停在哪里？
关掉一个对话窗口，不一定取消已经排队的任务。删掉一条本地许可，也不一定让另一个执行节点立刻知道。更重要的是，已经发到顾客账户里的优惠券，不会因为授权被撤销就自动消失。
因此，收回授权至少要说明三种状态：尚未开始的动作还能不能启动，正在处理的动作能否在业务提交前拦下，已经生效的结果由谁核对和善后。
如果请求已经到达业务系统，结果暂时不明确，就应先核实发生了什么。不能一边声称“已经停止”，一边让重试任务继续提交；也不能把“取消后续操作”理解成“过去的影响已经全部撤回”。
执行前检查与业务提交之间还可能发生变化。对于必须严格控制的操作，最终检查需要落在掌握当前业务状态、能够拒绝写入的位置，不能只依赖很早以前的一次判断。
这些安排听起来比一个确认按钮复杂，但复杂性本来就存在。
过去，很多事情由人顺手收尾：活动结束就停投放，预算不足就找负责人，岗位交接时把旧任务一起移交。AI 接管操作后，这些隐含动作也需要有人或系统明确负责。
减少人工操作，不会自然消除这些管理职责。
同样，凭据管理与委托管理也不能混成一件事。
保护好访问凭据，解决的是访问能力不要落到不该持有它的人手里。让委托在正确的条件下生效，解决的是持有访问能力以后，当前究竟可以做什么。
一个凭据没有泄露，不代表它承载的所有旧任务都仍然合适；停止一项任务，也未必需要让整个账号下的其他正常业务一起停摆。企业需要能够分别处理访问能力和具体委托，既收得住边界，也保留正常工作的连续性。
从这个角度看，AI 产品的“免打扰”能力还可以继续往前走。
企业除了能选择“不再询问”，也应该容易看见：目前有哪些委托仍然有效，谁批准的，适用于哪些业务，已经消耗了多少额度，以及发生什么变化时需要介入。
授权时给人一份能读懂的范围，执行时检查当前条件，收回时交代实际结果。这样，少问几次才能建立在明确的安排上。
如果只是把一次次弹窗变成一份越来越长、没人再看的许可列表，操作上的负担虽然下降了，维护权限的负担却可能在后台继续累积。
企业也需要关注这份积累。员工离开后还有哪些自动任务在替他办事？活动结束后还留下哪些有效安排？一个入口换掉以后，原来发出去的委托是否还有执行者在继续履行？
这些问题可以成为验收 AI 自动化的具体场景。
仍以发券为例：活动范围内的正常订单应当顺利处理，不必反复批准；活动结束后不再接受新发券任务；预算被其他任务消耗后，剩余额度应当同步生效；负责人收回委托后，系统能够说明哪些已完成、哪些被停止、哪些结果仍待核实。
测试这些场景，比单纯统计“少弹了多少个确认框”，更接近企业真正需要的自动化。
我们讨论 A2B、ACC 和 BailingHub，也是从这类实际关系出发。
A2B，Agent-to-Business，是我们为机器接受人或组织的委托、进入业务并产生后果所提出的认知框架。它让我们把注意力从“AI 会不会用这个功能”，继续放到“组织把什么行动交给了它”。委托如何开始、怎样持续、何时结束，都属于值得认真研究的问题。
ACC 是我们提出的开放能力契约，尝试为能力范围、主体要求、风险和审批意图提供共同表达。它让不同接入方理解治理要求时有一个参照，业务系统仍然保留最终权限判断。
本文讨论的完整授权生命周期，还需要组织政策、身份系统、运行机制和业务系统共同落实，不能把它当成现有 ACC 声明已经自动完成的功能。
BailingHub 则提供可运行的开源控制面实践，承接能力开放、执行约束、人工介入和操作记录，帮助这些问题进入实际接入过程。
随着企业接入更多助手，真正值得积累的，是一套能够被不同入口理解、在实际行动中执行、又能随着组织变化持续维护的委托关系。具体由现有平台还是独立组件承接，可以因企业而异；已经可靠运行的机制应当被复用。
我们希望 AI 能承担更多工作，也希望人能够放心地减少干预。这要求系统除了记住“我允许你做”，还要理解并落实这句话的范围和期限。
当我们说“以后不再询问”，希望得到的是持续、可靠的协助。系统应当让我们知道，这份同意会持续到哪里，以及我们怎样把它收回来。
