
> 人工审批真正批准的，不应该是一个模糊的“可以执行”，而应该是某个可信主体在某个任务中提出的那一次精确行动。

假设一个 Agent 帮用户处理订单退款。

第一次调用工具时，它提交了：

```json
{
  "order_id": "ORD-20260723-018",
  "amount": 300,
  "reason": "duplicate_payment"
}
```

系统判断这是一项高后果操作，于是暂停执行，并向审批人展示：

```text
订单：ORD-20260723-018
退款金额：300 元
退款原因：重复支付
```

审批人确认信息无误，点击“批准”。

随后任务恢复，Agent 再次生成工具调用。但这一次，它提交的是：

```json
{
  "order_id": "ORD-20260723-018",
  "amount": 3000,
  "reason": "duplicate_payment"
}
```

如果运行时只记录：

```text
这个任务已经审批通过
```

或者只记录：

```text
refund_create 这个工具已经审批通过
```

那么第二次调用很可能会借用第一次审批，直接执行 3000 元退款。

这不一定来自恶意攻击。参数变化可能源于：

- 模型重新推理后生成了不同数字；
- 上下文压缩丢失了原始参数；
- 工作流恢复时重新执行了参数生成节点；
- 工具 Schema 的默认值或字段映射发生变化；
- Agent 根据后来读取到的信息重新规划了行动；
- 网络重试被错误实现成一次全新的工具调用；
- 人工审批等待期间，任务上下文或业务数据已经变化。

问题的本质并不是“模型为什么不听话”，而是：

> **系统把对一次具体行动的批准，错误地升级成了对未来调用的通用授权。**

这类问题可以称为审批参数漂移。它揭示了 Human-in-the-loop 最容易被忽略的一层：**有人工参与，不等于人工批准的内容与最终执行的内容一致。**

## 一、审批不是一个布尔值

很多系统最初实现人工审批时，会在任务表上增加一个字段：

```text
approved = true
```

这个字段能表达“有人点过同意”，却回答不了：

- 谁提出了这项行动？
- Agent 当时代表谁行动？
- 审批人看到的是哪个工具？
- 审批页面展示了哪些参数？
- 恢复执行时还是不是同一项能力？
- 参数是否发生了变化？
- 这份批准可以使用几次？
- 它是否已经过期？
- 审批发生后，业务状态是否仍然允许执行？

因此，生产系统中的审批对象不应该只是一个任务，也不应该只是一个工具名。

更准确的批准对象应当接近：

```text
可信主体
+ 能力或工具
+ 规范化参数
+ 任务与请求身份
+ 审批决定及其签发者
```

可以把它表示成一个绑定元组：

```text
(subject, capability, tool, args, job_id, request_id)
```

审批人批准的是这个元组所描述的行动，而不是向 Agent 发放一张可以自由填写内容的空白支票。

## 二、为什么只绑定工具名仍然不够

一种常见改进是把批准记录从任务级缩小到工具级：

```text
job_id = job-123
tool = refund_create
status = approved
```

这比一个全局 `approved=true` 更好，但仍然不够。

同一个 `refund_create` 可以表达完全不同的业务后果：

```json
{"order_id":"A","amount":100}
```

和：

```json
{"order_id":"B","amount":100000}
```

工具名相同，不代表行动相同。

同样，下面两个调用也不应该共享批准：

```json
{"employee_id":"E-21","status":"disabled"}
```

```json
{"employee_id":"E-21","status":"deleted"}
```

一个是暂时停用，一个可能是不可逆删除。只看工具名，系统无法知道审批人究竟同意了哪种后果。

因此，审批至少必须绑定到精确参数。只要影响行动语义的字段发生变化，就应该视为另一项行动：

```text
换对象 = 新行动
换金额 = 新行动
换状态 = 新行动
换收件人 = 新行动
换批量范围 = 新行动
```

新的行动应该重新评估风险、重新执行授权，并在需要时重新审批。

## 三、参数快照解决“审批人到底看见了什么”

当运行时决定暂停一项操作时，首先应该冻结一份参数快照。

例如：

```json
{
  "tool": "refund_create",
  "scope": "refund.create",
  "subject": "tenant-18:user-204",
  "args": {
    "order_id": "ORD-20260723-018",
    "amount": 300,
    "reason": "duplicate_payment"
  },
  "job_id": "job-7f93",
  "request_id": "req-b285"
}
```

这份快照至少承担三种作用。

### 1. 生成审批展示

审批页面应该从被冻结的参数生成摘要，而不是在审批时再次让模型解释“它准备做什么”。

模型生成的自然语言可以帮助阅读，但不能成为批准范围的唯一依据。审批人最终看到的金额、订单、目标账号或批量范围，必须能回到原始结构化参数。

### 2. 恢复任务

审批结束后，系统应该恢复同一项任务，而不是重新创建一项“看起来差不多”的任务。

如果 Runtime 需要再次调用模型，也必须把已批准的精确调用作为不可修改的执行输入，而不是只告诉模型：

```text
退款已经批准，请继续。
```

### 3. 建立审计证据

事后需要能够回答：

```text
审批人看见的参数
是否等于
最终派发的参数
```

如果系统没有保留快照，只保留一句“某人批准了退款”，这条记录无法证明最终执行的就是当时展示的内容。

## 四、为什么还需要参数哈希

只保存参数快照还不够。恢复执行时，运行时还需要一种稳定方式判断：

```text
本次参数和被批准参数是否完全一致？
```

直接比较原始 JSON 字符串会遇到一个问题。下面两段 JSON 的键顺序不同，但语义相同：

```json
{"order_id":"A","amount":300}
```

```json
{"amount":300,"order_id":"A"}
```

如果直接比较字符串，系统会错误地把它们判断成两个请求。

因此，常见做法是先规范化参数，再计算摘要：

```text
args_hash = SHA-256(canonical_json(args))
```

一个基本的规范化过程通常需要明确：

- 对象键是否递归排序；
- 数组顺序是否保留；
- 缺失字段与 `null` 是否区分；
- 数字、布尔值和字符串是否禁止隐式转换；
- 非法 JSON 值如何处理；
- 不同语言实现如何得到相同字节序列。

例如：

```json
{"amount":300}
```

不能和：

```json
{"amount":"300"}
```

得到相同语义，因为一个是数字，一个是字符串。

而：

```json
{"ids":[1,2]}
```

和：

```json
{"ids":[2,1]}
```

是否相同，取决于数组顺序在该工具中的业务含义。通用实现通常应保留数组顺序，避免擅自改变调用语义。

### 哈希不是什么

参数哈希只是对快照的稳定引用，不是万能安全凭证。

它不能单独证明：

- 快照来自可信主体；
- 审批决定由有资格的人签发；
- 审批记录没有被篡改；
- 业务状态仍然有效；
- 原始参数中不存在敏感数据。

因此：

- 哈希需要和任务、主体、工具及审批记录一起保存；
- 跨信任域传递时，需要认证通道或签名信封；
- 原始快照仍需按敏感数据策略保存和脱敏；
- 不应把 `args_hash` 当成权限令牌。

## 五、一条可审查的审批执行链

一条最小但完整的链路可以分成十步。

### 第一步：模型提出工具调用

```text
tool = refund_create
args = { order_id, amount, reason }
```

此时的参数仍然是不可信输入。

### 第二步：运行时校验并规范化参数

系统先依据工具 Schema 校验类型、必填字段和结构，再把参数转换成稳定的 JSON 语义。

校验发生在计算快照之前，避免审批一份无法真实派发的参数。

### 第三步：判断是否需要外部决策

判断依据可以来自：

- 操作风险；
- 声明中的审批意图；
- 部署环境策略；
- 企业审批系统；
- 当前可信主体与场景。

这里的目标是判断“是否需要暂停”，不是让模型自己决定“我觉得这次不危险”。

### 第四步：冻结审批意图

系统保存：

```text
approval_id
job_id
request_id
subject
tool
scope
args snapshot
args_hash
risk / reason
created_at
```

审批页面和外部审批通知都应引用同一份冻结数据。

### 第五步：审批权威作出决定

谁有资格批准，取决于企业自己的身份、组织和策略体系。

运行时可以发起审批并等待结果，但不应该凭空假设：

```text
任何登录控制台的人都可以批准任何操作。
```

### 第六步：决定信封返回

一份可机器验证的决定至少应该重新带回：

```text
approval_id
job_id
request_id
args_hash
decision
decision_id
approver
decided_at
```

`decision_id` 用于处理审批系统的重复回调；`args_hash` 用于确认它决定的是同一份参数快照。

如果审批系统和执行系统跨越不同信任域，还需要签名或等价的来源认证机制。

### 第七步：原子消费批准

批准不能被无限复用。

系统需要把：

```text
approved + unused
```

原子地转换成：

```text
approved + claimed
```

如果两个并发执行者同时尝试使用同一张审批单，只能有一个成功。

简单地先查询“尚未使用”，再在调用完成后更新“已使用”，中间存在并发窗口。更稳妥的做法是使用条件更新、事务或等价的 compare-and-set。

### 第八步：只按原参数恢复

恢复执行时再次计算当前参数哈希：

```text
current_args_hash == approved_args_hash
```

相等，才有资格继续。

不相等时，系统应该：

1. 拒绝当前调用；
2. 记录参数漂移；
3. 返回已批准的精确参数，要求按原样恢复；
4. 如果确实要修改参数，创建新的行动并重新评估。

它不应该为了“流程顺畅”自动修改审批记录，也不应该悄悄为新参数创建第二张审批单，让 Agent 在审批循环里空转。

### 第九步：使用稳定幂等身份派发

审批单的一次性消费，解决的是“批准不能被重复使用”；业务幂等解决的是“副作用不能被重复形成”。

两者不能互相替代。

如果进程在“消费批准”后、“收到业务结果”前崩溃，恢复逻辑必须继续同一个任务和同一个业务请求身份，而不是重新创造一次退款。

高保证场景还需要持久任务状态、可靠派发或 Outbox 等机制，缩小批准状态和外部调用之间的崩溃窗口。

### 第十步：业务系统执行最终授权

即使工具、主体、参数和审批完全一致，业务系统仍然可能拒绝：

- 订单已经退款；
- 剩余可退金额发生变化；
- 操作人权限已被撤销；
- 当前租户或门店不匹配；
- 业务状态已不允许继续；
- 同一业务幂等键已经成功处理。

批准证明的是：

```text
有人在某个时刻同意了这项行动
```

它不能证明：

```text
这项行动在任何未来时刻都必须成功
```

最终 Authority 仍然属于业务系统。

## 六、审批有效期为什么只是问题的一部分

很多团队发现审批可能被长期复用后，会增加：

```text
expires_at
```

这是有价值的，但它只解决时间窗口，不解决参数漂移。

一份 30 分钟内有效的批准，如果只绑定工具名，仍然可能在第 2 分钟授权错误金额；一份永不过期但严格绑定精确参数的批准，也可能因为业务状态变化而不再适合执行。

因此，至少需要同时区分：

```text
内容一致性：执行的是不是批准的那项行动？
时间新鲜度：批准是否仍在有效窗口？
业务新鲜度：当前业务状态是否仍允许执行？
```

三者分别由参数绑定、运行时策略和最终业务校验承担。

## 七、五种常见但危险的实现

### 1. 把批准挂在整个会话上

```text
session.approved = true
```

这会让同一会话后续所有高风险操作都有机会借用一次批准。

### 2. 只批准自然语言摘要

```text
“用户同意退款”
```

摘要适合帮助人阅读，却不能替代结构化参数。自然语言遗漏的字段，往往正是决定真实后果的字段。

### 3. 批准后让模型重新生成参数

如果模型只收到“已经批准，请继续”，它会重新推理，而不是恢复一份不可修改的执行请求。

### 4. 发现参数不同后自动更新审批单

这等于让行动提出方在批准之后修改被批准内容。正确做法是拒绝漂移参数；需要修改时重新建立决策。

### 5. 把审批成功当成业务授权成功

审批人可以同意行动，但业务系统仍必须校验对象、租户、余额、状态和权限。上游批准不能覆盖业务不变量。

## 八、审计日志至少要证明什么

一次涉及人工审批的 Agent 行动，审计记录不应只有：

```text
refund approved
```

至少应该能够关联：

- 发起请求的人或系统；
- Agent 实际代表的可信主体；
- 任务与请求身份；
- 工具、能力范围和风险；
- 审批前的参数快照或受保护引用；
- 参数摘要；
- 审批人、决定、时间与决定幂等键；
- 批准被何时、由哪个执行者消费；
- 最终派发参数是否匹配；
- 业务系统最终接受或拒绝的结果；
- 重试、去重、超时和恢复事件。

需要注意的是，日志字段齐全不等于证据天然可信。

如果同一个可能被攻陷的 Runtime 既能伪造审批结果，又能改写唯一的审计记录，这份日志更多是运维记录，而不是独立可验证证据。更高保证等级下，可以让审批权威签发决定、使用只追加存储，并由业务边界重新验证关键绑定。

## 九、一个最小执行伪代码

下面的伪代码强调的是责任顺序，而不是某个框架的固定 API：

```ts
const args = validateAndNormalize(toolSchema, modelArgs)
const argsJson = canonicalJson(args)
const hash = sha256(argsJson)

const exactApproval = await approvals.findApprovedUnused({
  jobId,
  subject,
  tool,
  argsHash: hash,
})

if (!exactApproval) {
  const approvedOtherArgs = await approvals.findApprovedUnused({
    jobId,
    subject,
    tool,
  })

  if (approvedOtherArgs) {
    await audit("tool_args_drift", {
      jobId,
      tool,
      expectedArgsHash: approvedOtherArgs.argsHash,
      actualArgsHash: hash,
    })
    return rejectWithApprovedSnapshot(approvedOtherArgs)
  }

  return createApprovalIntent({
    jobId,
    requestId,
    subject,
    tool,
    args,
    argsHash: hash,
  })
}

if (!await approvals.claimOnce(exactApproval.id)) {
  return reject("approval_already_consumed")
}

return businessSystem.execute({
  subject,
  tool,
  args,
  stableRequestId,
})
```

在真实生产系统中，还要继续处理：

- 审批决定来源认证；
- 决定回调幂等；
- 任务持久化；
- 派发崩溃窗口；
- 业务幂等；
- 超时状态查询；
- 敏感字段脱敏；
- 证据保留策略。

伪代码没有消除这些问题，但它至少避免了最危险的一步：**把一次批准误当成一段可自由改写的执行权限。**

## 十、ACC 与运行时应该怎样分工

能力契约可以声明：

- 哪项操作需要可信主体；
- 操作风险是什么；
- 是否存在审批意图；
- 哪些参数条件会触发人工介入。

这些是可以随能力一起发布的可移植语义。

但能力声明不应该假装知道：

- 企业里谁有资格审批；
- 审批系统使用什么组织模型；
- 批准有效多久；
- 决定如何签名；
- 任务如何暂停和恢复；
- 业务对象此刻是否仍可操作。

这些属于部署时运行策略、审批权威、执行协调和业务系统。

因此，一条清晰的分工是：

```text
声明层：
  表达“这里需要外部决策”

运行时：
  冻结精确行动、暂停任务、绑定决定、恢复原请求

审批系统：
  判断谁有资格批准，并签发决定

业务系统：
  执行最终对象级授权、状态校验和事务提交
```

声明层保持可移植，运行时负责兑现，业务系统保留最终 Authority。

## 十一、一个公开实现样本

BailingHub 采用了一种具体做法：

1. 工具参数先按照实际 JSON 传输语义规范化；
2. 对象键递归排序，数组顺序保留，再计算 `args_hash`；
3. 审批记录绑定 `job_id + tool + args_hash`；
4. 决定回调重新核对 `approval_id / job_id / request_id / args_hash`；
5. 已批准记录只能被原子消费一次；
6. 同一工具出现已批准但参数不一致的调用时，记录 `tool_args_drift` 并拒绝执行；
7. 运行时把已批准的精确参数返回给任务恢复链路；
8. 副作用调用继续使用幂等账本；
9. 业务系统仍然执行最终权限和业务状态判断。

这只是一个可运行的工程样本，不是唯一实现，也不是 ACC 核心规范强制的内部结构。

如果审批需要跨组织、跨 Runtime 或跨多个 Agent 传递，还需要进一步处理标准化规范化、签名委托链、独立时间基准和可验证证据。这些问题不应该被一个 `args_hash` 掩盖。

## 十二、上线前检查表

### 批准对象

- [ ] 批准是否绑定可信主体，而不是模型生成的 user_id？
- [ ] 是否绑定精确工具或能力标识？
- [ ] 是否绑定任务和请求身份？
- [ ] 审批人是否能看到真正影响后果的结构化参数？

### 参数一致性

- [ ] 参数是否先经过 Schema 校验和 JSON 规范化？
- [ ] 规范化规则是否对对象、数组、`null` 和类型有明确语义？
- [ ] 执行前是否重新计算并比较参数摘要？
- [ ] 参数不一致时是否拒绝，而不是自动更新批准？

### 审批决定

- [ ] 谁有资格审批由可信企业系统决定吗？
- [ ] 决定回调是否有来源认证？
- [ ] 重复回调是否使用稳定 `decision_id` 去重？
- [ ] 批准是否只能被一个执行者原子领取一次？

### 执行与恢复

- [ ] 批准后是否恢复同一个任务，而不是创建新任务？
- [ ] 副作用调用是否使用稳定业务幂等键？
- [ ] 崩溃恢复是否会重复执行或丢失已批准行动？
- [ ] 超时后是否查询原任务状态，而不是盲目重试？

### 最终授权与证据

- [ ] 业务系统是否仍校验租户、对象、权限和实时状态？
- [ ] 审计记录能否对齐批准参数与真实派发参数？
- [ ] 敏感参数快照是否被适当保护和脱敏？
- [ ] 系统是否诚实区分运维日志与独立可验证证据？

## 结语

Human-in-the-loop 的价值，不是在人和 Agent 之间增加一次点击，而是把机器提出的高后果行动重新交给可信的外部决策。

要让这项决定真正有效，系统必须保证：

```text
人批准的行动
=
运行时恢复的行动
=
业务系统最终收到的行动
```

只要工具、主体、参数、任务或业务状态发生变化，原批准就不能被静默外推。

这也是 Agent 进入真实业务系统后，一个看似细小却决定安全上限的工程问题：

> **审批不是给 Agent 一次通行权，而是只批准那一次被看见、被理解、被绑定的具体行动。**

你们现在的 Agent 工具审批，是绑定到会话、任务、工具名，还是已经绑定到精确参数快照？如果任务在审批后重新推理，系统如何证明最终执行的仍然是审批人当时看到的那一次调用？


人工审批真正批准的，不应该是一个模糊的“可以执行”，而应该是某个可信主体在某个任务中提出的那一次精确行动。

审批通过后 Agent 改了参数怎么办？Human-in-the-loop 为什么必须绑定参数快照

人工智能

后端

安全

人工审批应绑定精确参数快照而非模糊授权，防止Agent执行时参数漂移。系统需冻结结构化参数、计算哈希值，确保审批与执行内容一致。审批记录应包含可信主体、工具名、规范化参数及任务ID，实现可审计的执行链。业务系统仍需校验实时状态，确保批准行动与最终执行严格匹配。

数据策略

代码解释

敏感数据

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

审批通过后 Agent 改了参数怎么办？Human-in-the-loop 为什么必须绑定参数快照-腾讯云开发者社区-腾讯云

审批通过后 Agent 改了参数怎么办？Human-in-the-loop 为什么必须绑定参数快照

审批通过后 Agent 改了参数怎么办？Human-in-the-loop 为什么必须绑定参数快照

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐