关键词Agent 审批有效期、Human-in-the-loop、审批过期、策略版本漂移、AI 业务系统治理假设一个 Agent 准备为客户发起退款订单SO-1001 金额199.00 元 原因重复支付运行时判断这是一项高风险写操作于是暂停任务等待人工审批。审批人在上午 10:00 核对参数后点击“通过”。但任务没有立即执行而是在队列中等待。到了下午 15:00系统准备真正调用退款接口时现实可能已经发生变化订单已经由客服手工退款退款政策已经更新原审批人的权限已经被撤销发起任务的用户已经退出当前组织退款金额或币种在重试过程中发生变化被批准的工具版本已经下线审批本身规定只在 30 分钟内有效。这时候系统能不能只因为“五小时前有人点过通过”就继续执行不能。因为审批不是一张脱离时间、参数和业务状态的永久通行证。它批准的是某个可信主体在某个上下文中针对某项能力和一组确定参数于特定条件成立时执行一次具体行动。只要这些绑定条件中的关键部分发生变化原审批就不应继续被解释为有效。这也是 Agent 进入真实业务系统以后一个很容易被低估的问题审批不仅要防止参数漂移还要防止时间、策略、主体和业务对象状态的漂移。1. 审批通过不等于获得一项长期权限在人类操作后台时审批通常离执行很近。员工提交申请审批人查看表单系统随后执行。人们容易因此形成一种直觉approval true只要数据库里记录过“已通过”任务以后就可以继续。但 Agent 任务常常不是一次同步请求而是一条跨越多个阶段的长链路理解目标 - 选择能力 - 构造参数 - 生成审批请求 - 等待人类 - 恢复任务 - 排队调度 - 调用业务系统 - 写入审计证据这条链路可能持续几分钟、几小时甚至几天。等待期间原审批所依赖的事实并不会停止变化。因此“曾经通过”只是一条历史事实不能自动证明“现在仍然允许执行”。成熟的审批模型至少要区分概念回答的问题审批意图这类操作是否需要人类介入审批决定某个审批者是否对具体行动作出同意审批证据该决定绑定了哪些主体、参数、策略和时间审批有效性到真正执行时这份证据是否仍然适用最终授权业务系统此刻是否允许产生业务后果这五者不能压缩成一个布尔值。2. 审批到底批准了什么如果审批页面只显示是否同意退款那么审批人并不知道自己批准的是哪一笔订单多少钱什么币种以谁的名义调用哪个能力由哪个业务系统执行在什么策略版本下判断有效到什么时候。这样的审批即使留下了“同意”记录也很难证明它与最终执行的是同一件事。一份可验证的审批证据应当至少绑定以下信息trusted_subject capability canonical_arguments policy_version approval_time expiry_time approver task_identity在更严格的场景中还可能需要绑定tenant business_object_version tool_or_server_artifact request_purpose delegation_context这些字段并不一定全部进入同一份通用规范但运行时必须能够回答审批人当时看到并同意的行动与此刻准备执行的行动是否仍然是同一个行动3. 参数哈希只能防一部分漂移常见做法是把调用参数规范化后计算哈希args_hash SHA256(canonical_json(arguments))审批时保存args_hash执行前重新计算。若不同则要求重新审批。这很重要因为它可以防止审批时 order_id SO-1001 amount 199.00 执行时 order_id SO-1001 amount 19900.00但参数完全相同也不代表审批一定仍然有效。例如参数没有变化 - 订单已经退款 - 当前主体权限已撤销 - 风险策略已升级 - 审批已经超过有效期所以参数哈希解决的是“内容是否相同”而不是“审批是否仍然适用”。更准确的理解是参数一致 是审批有效的必要条件之一 不是充分条件4. 审批为什么需要有效期审批有效期不是为了让流程显得更严格而是因为批准所依赖的事实具有时效性。4.1 主体权限会变化上午 10:00员工仍属于财务部门。下午 14:00该员工离职或被移出项目。如果任务在 15:00 执行系统不能只相信旧审批而不重新确认当前主体状态。4.2 业务对象会变化审批时订单状态是paid执行时可能已经变成refunded chargeback_pending closed同样的退款参数在不同对象状态下具有完全不同的含义。4.3 风险政策会变化审批时的规则可能是1000 元以下由客服主管批准执行前企业更新为所有退款均需财务复核旧审批不能天然穿透新策略。4.4 能力实现会变化同一个scope背后的工具或服务实现可能升级。如果新的实现扩大了副作用、修改了参数语义或改变了下游系统旧审批是否仍适用必须由部署方明确决定而不能默认为“名称一样所以继续执行”。5. 策略版本为什么必须进入审批上下文审批决策不是在真空中产生的。它通常基于某个策略版本policy_version refund-policy-2026-07-01当任务恢复时运行时至少应比较approved_policy_version current_policy_version但比较结果不应该简单地处理成版本不同 - 一律拒绝策略变更可能有三种类型变化类型示例合理处理不影响当前行动修改提示文案可继续但保留证据收紧当前行动新增财务复核重新审批放宽当前行动提高免审阈值是否复用旧审批由部署策略决定通用契约可以要求运行时保留和比较策略版本但很难替所有企业判断“哪些版本变化具有实质影响”。因此正确分层是能力声明 - 表达审批意图和可移植治理语义 运行时 - 保存审批绑定、有效期和策略版本 部署策略 - 判断版本变化是否要求重新审批 业务系统 - 执行此刻的最终授权与业务状态校验6. 执行前必须进行一次 freshness check审批完成后任务不能直接从approved跳到executed中间至少需要一个执行前校验阶段approved - dispatch_validation - executingdispatch_validation应检查审批是否超过有效期可信行动主体是否仍有效参数规范化结果是否与审批快照一致使用的能力、工具或服务版本是否允许当前策略版本是否影响原决定业务对象状态是否要求重新确认幂等键是否已经对应终态结果最终业务授权是否仍成立。其中一些检查可以由运行时完成一些必须请求业务系统。关键不在于所有检查都由一个组件承担而在于不能跳过这一步。7. 哪些变化必须重新审批可以采用保守规则必须重新审批审批明确过期行动主体变化租户变化capability 或 operation 变化参数快照变化金额、币种、目标对象等安全关键字段变化策略变化导致要求更严格原审批证据无法验证业务对象变化使行动后果发生实质变化。可以继续但必须留痕非安全关键的显示文案变化不影响当前决策的元数据变化运行时重启但持久任务身份和审批证据完整传输层重试但业务行动身份未改变。不能由通用层独立决定某类对象状态变化是否仍适用原审批某次策略升级是否影响历史批准审批人组织权限变化是否追溯影响已批准任务特定行业对审批证据有效期的合规要求。这些问题需要部署方和业务系统定义。8. 过期后不要“静默重试”最危险的实现之一是任务恢复 - 发现审批无效 - 后台自动重新生成审批记录 - 或继续使用旧决定这会把人类介入变成形式。审批失效时任务应进入显式状态approval_required或者approval_expired并提供清楚的原因{status:approval_required,reason:policy_version_changed,approved_policy_version:refund-policy-2026-07-01,current_policy_version:refund-policy-2026-07-30}系统可以创建新的审批请求但不能伪装成原审批仍然有效。9. 一个更完整的退款状态机退款任务可以按下面的状态推进created - awaiting_approval - approved - dispatch_validation - executing - approval_required - rejected - already_completed - succeeded / failed / reconciliation_required其中awaiting_approval等待第一次人工决定approved已经获得一份绑定具体行动的审批证据dispatch_validation执行前重新验证时间、参数、主体、策略和业务状态approval_required原审批过期或关键绑定发生变化already_completed幂等查询发现业务效果已经发生reconciliation_required无法确定最终业务结果需要人工或后台对账。这种状态机比一个approved: true更复杂但它准确反映了真实世界。10. ACC 在这里负责什么不负责什么ACC 可以声明这项能力是否进入 Agent-facing 范围使用哪个稳定scope风险等级是否必须绑定可信主体哪些参数条件产生审批意图是否应具备幂等、只读、限流等执行属性。但 ACC v1 不应被误解为已经定义审批证据格式审批令牌签名方案企业的审批有效期策略版本兼容算法业务对象的新鲜度判断最终用户授权。这些属于运行时、部署策略、审批系统或业务系统。因此这篇文章讨论的不是“再往 ACC Core 里塞更多字段”而是提醒实现者声明“这项操作需要审批”只是开始。部署方还必须保证审批证据在执行时仍然有效。11. 六个常见误区误区一审批记录存在就能执行记录只能证明过去发生过决定不能证明当前条件未变化。误区二参数哈希一致就足够主体、策略、对象状态和有效期仍可能变化。误区三策略更新只影响新任务如果旧任务尚未执行新策略是否影响它必须被明确处理。误区四审批过期后自动重试即可过期意味着需要新的决定不是换一次传输重试。误区五运行时检查过就不需要业务系统再鉴权业务系统掌握最新权限和对象状态最终授权不能外包。误区六把所有审批规则都写进通用规范通用层可以规定需要保存和验证什么不应替企业定义全部组织流程。12. 一份实现检查表审批是否绑定具体 capability 和规范化参数是否绑定可信行动主体而不是模型生成的用户标识是否记录审批时间和有效期是否记录产生决策时的策略版本运行时恢复任务后是否会执行 freshness check参数变化是否强制重新审批策略收紧是否会使旧审批失效主体、租户或业务对象变化是否有明确处理审批失效时是否进入显式状态而不是静默执行或重试业务系统是否仍会在执行瞬间进行最终授权审计记录能否解释旧审批为什么被复用或为什么失效13. 结语审批是一段有条件的授权关系Agent 系统里的审批不应只是工作流页面上的一个按钮。它是一段被参数、主体、策略、时间和业务状态共同限定的授权关系。真正安全的链路不是有人点过同意 - 以后都能执行而是人类对具体行动作出决定 - 系统保存可验证的绑定证据 - 执行前重新确认这些绑定仍然成立 - 业务系统完成最终授权审批的价值不在于制造等待而在于让真实后果与真实意图保持一致。当任务持续时间越来越长、Agent 自主性越来越高时审批是否“新鲜”会和审批是否“存在”一样重要。
