目标授权与动作授权必须分开
用户说“整理云盘”时，给出的是一个目标，不是对任意实现步骤的空白支票。代理可以先读取目录、计算重复项和拟定分类方案，但删除、移动、公开共享等会改变外部状态的动作，必须在最终参数已经确定后单独获得授权。这条边界让规划能够灵活，又不会把自然语言目标误解成无限权限。
建立动作分级时，应同时考虑可逆性、影响范围、金钱或权限成本以及第三方可见性。读取和本地草稿通常可以直接执行；发送邮件、下单、删除资源、修改成员角色则应进入强审批。一个动作即使技术上可以撤销，若撤销会留下对外通知或合规记录，也不应被归入低风险通道。
审批包要展示真正将被执行的内容
一份可用的审批包不能只写“是否继续”。它应列出动作类型、目标系统、资源标识、变更前后差异、预计数量、费用上限和可恢复方式。批量操作还要拆出异常项，例如“二十三个普通文件与一个共享给外部成员的文件”，避免高风险目标被总数淹没。用户看到的内容应来自已解析的执行参数，而不是代理另写的摘要。
差异视图应突出不可逆字段和意外扩大的范围。对邮件展示最终收件人、主题和附件；对权限变更展示主体、旧角色与新角色；对付费展示币种、含税金额和收款方。界面不要把确认按钮置于可滚动详情之前，也不要用默认勾选替代明确决定。详情过长时可分组，但关键参数不能折叠隐藏。
用参数哈希锁定审批时刻
最重要的实现不发生在弹窗，而发生在审批记录与执行器之间。服务端先对规范化后的工具名、目标资源、最终参数和调用者身份计算动作哈希，然后将它与审批人、创建时间、到期时间和状态一起持久化。执行器消费审批时重新计算哈希，任意字段变化都应导致失效，而不是沿用原来的通过结果。
规范化过程必须确定，特别是对对象键顺序、时区、货币小数、空值和资源标识的处理。如果审批端与执行端使用两套序列化方式，同一动作也会被误判为篡改。可以保存规范化版本并在升级期间同时验证旧版本，但不能将原始凭据、完整邮件正文或其他敏感资料为了哈希调试而长期复制到日志中。
审批是一次性消费的安全对象
审批状态至少需要待决定、已通过、已拒绝、已消费和已过期。从已通过到已消费的转换应使用数据库条件更新或交易锁，保证两个工作进程不能同时拿到一份授权。审批标识不应直接充当可转发凭据；消费时还要校验当前登录主体、任务租约和预期工具，避免一份批准被跨任务移用。
到期时间应根据动作变化速度设置。一份付款草稿可能在数分钟内失去价格有效性，而一份静态报告导出可以保留更久。过期后代理需要重新读取对象并生成新差异，不能只修改时间戳。拒绝和取消也要终止等待中的工作，不得留下一个在后台轮询并突然执行的旧任务。
执行前必须再做一次授权与事实检查
人工通过并不会冻结外部世界。从审批到执行之间，资源可能已被删除，用户角色可能被收回，价格和库存也可能变化。所以执行器要在服务端重新计算资源所有权、配额、当前版本和业务约束。审批证明的是用户曾对某一组参数表达意愿，它不能替代目标系统现时的鉴权决定。
对强一致要求高的动作，审批哈希中应带上资源版本或条件标识。执行时用“标识加旧版本”作为最终写入条件，影响行数为零就说明审批后已有变更，此时应回到差异页面。如果仅在审批前查询一次，最后却无条件写入，仍然会有典型的检查与使用竞态，审批层并不能消除它。
从结果证据判断动作是否真正完成
代理不应在工具返回一段“成功”字符串后就向用户宣布结果。执行记录应保存目标系统的资源标识、最终状态码、结果摘要和可查询的完成凭据。对发送类动作，可以查询投递或已接收状态；对文件变更，可以重新读取元数据与版本。用户看到的回执应是这些证据的安全投影，而不是模型的自我判断。
如果调用在提交后、回应前断线，结果应被标记为未知，而非简单失败。工作进程用同一操作键查询外部状态，确认没有受理后才能再次执行。若目标系统不提供状态查询或幂等键，高风险操作应暂停并交由人工对账，不要用“多试一次”去猜测已经发生的事实。
批量审批需要范围上限与可分割性
批量动作最容易把一个正常的审批界面变成形式上的门槛。执行系统应设置单次项目数和总影响量上限，按租户、目录或风险类型分组展示，并允许用户排除个别项后再生成新的动作哈希。当一批中同时出现普通项与权限异常项时，后者应被单独分批，不能用一个“全部同意”混合处理。
执行阶段也要定义部分成功语义。如果每个项目彼此独立，应保存每项的操作键和结果，失败项可以重试而不重复成功项。如果业务要求整批不可分割，就必须在审批前证明有真正的交易或补偿能力。不能在界面上承诺“一键撤销”，实际却只能人工逐项尝试恢复。
用故障注入验证审批链路
验收不能只覆盖“点击确认后返回二百”。安全矩阵应包含参数在审批后被篡改、审批过期、审批人与执行人不匹配、两个工作进程同时消费、资源版本变化以及取消后迟到任务继续运行。每个案例既要断言外部副作用为零，也要断言审批状态和审计事件能够说明拒绝原因。
可用性矩阵则要覆盖长清单、小屏和放大、键盘操作、读屏标题以及高延迟审批。还应在执行提交前、提交后回应前、记录回执前三个时点强制断线，确认系统能区分未执行、结果未知和已完成。只有这些失败模式都能在测试环境重现，人工审批才是一条可验证的控制链，而不是一个心理安慰弹窗。
不同风险动作需要不同审批强度
只用“需要审批”与“无需审批”两级策略，会让低风险操作频繁打断用户，同时又无法给高风险操作足够信息。可以按影响金额、外部接收者数量、权限等级、可逆性和资源敏感度计算策略层，低风险只做执行前通知，中风险要明确确认，高风险还需要近期重新认证或双人复核。
风险分类只能由可信服务端策略根据实际参数决定，不接受模型或客户端自报的等级。一笔单人小额付款与一份包含数百个收件人的通知，即使使用同一工具也应命中不同门槛。策略版本写入审批记录，执行时如果当前策略已提高要求，旧审批应失效而不是继续按旧标准消费。
审批通知与任务租约要协同
代理进入待审批状态后应释放不必要的计算和外部连接，只保留已持久化的计划、参数哈希和恢复指针。不能在内存中阻塞等待用户点击，因为进程重启会丢失等待状态，长时间占用任务租约又可能阻止其他工作者正确恢复。审批通过事件只负责唤醒任务，恢复者仍从数据库重读最新状态并完成原子消费。
通知渠道可以携带审批页链接和非敏感摘要，但不携带可直接执行的一键凭据。用户打开页面后重新登录并由服务端加载完整参数，避免邮件转发或聊天记录泄露待执行内容。多次通知应幂等且有频率上限，审批被拒绝、消费或过期后立即停止提醒，不让迟到消息又将用户导向无效动作。
审计需要证明决定与执行一致
审计链应记录谁在何时针对哪个动作哈希做了通过或拒绝，哪个工作者在何时尝试消费，服务端授权和版本检查的决定，以及外部结果证据摘要。记录参数哈希与必要的脱敏差异，不要把邮件正文、凭据或整份客户文件复制到审计库。这份链路应能回答“执行的是否恰好是用户看到的内容”，而不只是“曾有人按过确认”。
验证审计能力时，从完成的外部资源反向查找操作记录、审批记录和参数哈希，确认链路唯一且时间顺序合理。再对过期、篡改、版本冲突和授权收回的拒绝案例做同样查询，保证能看到拒绝原因但没有外部副作用。日志的读取权限和保留期也要独立治理，否则一个安全控制会变成更集中的隐私风险。
实现片段
await approvals.consume({ approvalId, actionHash, actorId })
评论 · 0