如果以前每天早上都会进Inbox的一批修改，某天却直接进入了正式记录，应该从哪里查起？定时任务没换，脚本没改，Agent甚至还在使用同一串Key。排查时，人们很容易先怀疑工作流出了问题，却漏看账户里刚发生的一次权限修改。
把API Key从Change Request改成Write，影响的不是眼前一个窗口。只要其他旧任务还拿着同一把Key，它们后续请求的能力上限也会一起改变。过去依靠凭据级别保留下来的人工等待，可能在下一轮执行中消失。
Busabase的API Key文档明确说明：权限编辑不改变Key的值与到期时间，既有持有者立即获得新级别。是否真的直接合并，还要看空间角色和实际请求中的待审设置。修改前最值得弄清的是：这把Key到底握在谁手里，哪些任务一直依赖它替自己守住审核入口？
为什么旧脚本会出现新行为
Key 属于账户，不属于某一个 Agent 或单一空间。一个环境变量可能被本机脚本、CI、定时任务和其他 Agent 共用。修改同一把 Key 的级别，会改变这些调用方下一次请求时的权限上限，不需要重新分发一串新字符。
这也解释了为什么“只想让眼前这项任务快一点”可能影响更大范围。若同一 Key 还在处理 CRM、内容或其他空间的数据，账户对那些空间已有的角色也要一起考虑。实际能力是 Key 级别与账户空间角色的交集；升到 Write 不会绕过空间角色。
四种级别，两个不同的问题
Read 只能在账户允许的范围读取；Change Request 可以读取并提出修改，不能自行合并；Write 可以提出、审核、合并和编辑内容；Manage 还包含管理及永久删除能力。该任务若只需要提交建议，Change Request 通常就足够。
“API 允许做什么”和“这次任务被允许做什么”需要分别确定。Write 提供合并能力，不是把原来的业务范围扩大到所有可访问记录的委托。反过来，文字里要求自动合并，也不会让 proposal-only 凭据突然具备合并能力。
有 ChangeRequest，不代表有人工等待
Change Requests 文档说明，每次编辑都有 ChangeRequest；有 Write 权限的写入通常创建后即合并。proposal-only 凭据、显式 autoMerge: false 或匿名表单写入才会保留待审。
因此，旧任务升级后是否直接合并，必须查看实际请求。若它原来只是依靠 Change Request 级别阻止自动合并，升到 Write 后默认行为会变化。若请求明确发送 autoMerge: false，待审要求仍然存在。不能仅凭 Inbox 里曾经出现过这项任务，就推定下次仍会等待。
改权限前，先留下无秘密的调用方清单
打开 Account → API Keys，确认要编辑的 Key 名称、前缀、级别和到期时间。完整 Key 不应复制进报告或聊天。再从你能检查的配置、CI 和定时任务中，确认谁持有它、写哪个空间与 Base、执行什么操作、是否显式保留待审。
这是一份团队自己维护的检查清单，不是产品会自动找出所有旧持有者的承诺。无法确认共享范围时，优先为确实需要 Write 的任务发独立 Key，而不是提升共享凭据。具体创建、迁移和撤销仍由有权限的人执行。
修改后，验收实际结果
权限提高会要求二次确认。变更后先用身份读取确认目标空间，再让一项已授权、影响可控的真实工作走完一次，核对返回的 CR 状态、是否存在合并时间，以及 canonical 记录的实际值。不要为了测试权限随便改业务数据。
检查范围要写清：哪一个调用方已验证，哪些定时任务尚未运行，哪些配置还无法确认。approved 与 merged 是不同状态；请求成功也不能代替记录回读。发现不应自动合并的路径，应先纠正请求或凭据配置，再恢复该路径。
降回去，也要处理已经发生的事
降低同一 Key 的级别同样改变旧持有者的后续能力。它不会自动撤销此前已经合并的业务值。若数据需要纠正，应检查具体记录与历史，提出可审阅的修正，保留原有轨迹。
如果问题其实是换 Agent 或轮换凭据，参考交接访问与待审提案；如果担心写错空间，参考核对写入目的地。同一 Key 改级别的核心，是重新确认每个旧调用方今后的合并边界。
常见问题
改完权限，需要给旧 Agent 换 Key 吗？
同一 Key 编辑级别时，值和到期时间不变，现有持有者立即获得新级别。若要隔离不同任务，另发独立 Key 是不同的配置选择。
想保留人工审核，还能用 Write 吗？
调用方可显式发送 autoMerge: false 保留待审。如果整项任务只需提出修改，proposal-only 凭据提供更明确的能力边界。两种方式都应以实际 CR 状态验收。
Write 能跨过空间角色限制吗？
不能。有效能力仍与账户在空间中的角色相交；正确的 Key 也必须指向正确空间。