Agent 人在回路与控制权
本节目标
学完后，你应能：
- 区分澄清、审批、监督、接管、拒绝和取消。
- 为高风险动作设计绑定参数、状态版本和过期时间的 approval contract。
- 把人工等待建成可持久恢复状态，而不是阻塞 worker 的聊天窗口。
- 识别 automation bias、审批疲劳与“橡皮图章”式假监督。
人在回路不等于弹一个确认框
有效控制需要明确：
- 哪个角色负责什么；
- 在什么风险/不确定性触发；
- 人看见哪些证据与影响；
- 可以如何编辑、拒绝、接管和取消；
- 决策怎样绑定当前 action；
- 等待期间状态如何保存；
- 执行后怎样审计和补偿。
NIST AI RMF 1.0 强调定义并区分 human-AI 配置中的角色与监督责任。NIST 官方站点在 2026-07-21 仍说明 1.0 正在修订中；本节引用其通用风险管理原则，不把某一版本当成具体行业合规结论。
六种人类交互
| 类型 | 系统在问什么 | 例子 |
|---|---|---|
| clarification | 目标/参数是什么意思 | “处理哪个项目？” |
| approval | 是否允许冻结的高风险动作 | “向客户发送这封邮件？” |
| review | 候选结果是否可接受 | 代码 diff、报告草稿 |
| intervention | 运行中纠正计划/范围 | 排除某目录 |
| takeover | 人接管并停止自治 | 生产事故处理 |
| cancel/reject | 不再执行该动作/run | 拒绝付款、取消任务 |
不要把 clarification 的回答当通用授权，也不要把 review 通过解释为允许后续任意修改。
何时必须暂停
- 目标或关键参数有实质歧义。
- 不可逆、高价值、公开沟通、支付、删除、部署等动作。
- 敏感数据跨越新边界。
- 来源冲突或 verifier 无法判断。
- 即将超用户授权、成本、时间或地域范围。
- 连续失败、无进展、策略命中异常。
- 检测到提示注入、工具污染或权限提升请求。
- 法律/行业流程要求具备授权角色。
“模型置信度高”不能取消这些 deterministic gate。
Approval contract
一条审批记录至少绑定：
{ // 一次人工审批的不可歧义记录
"run_id": "run-42", // 审批只属于该运行，不能跨 run 重放
"action_id": "publish-report", // 被批准的动作 ID，而不是笼统的“可以发布”
"action_fingerprint": "sha256(tool + target + normalized_args + policy_version)", // 绑定工具、目标、参数和策略版本，防止审批调包
"state_version": 12, // 只对看到的该状态版本有效，状态变化后必须重新审批
"decision": "approve", // 人工明确作出的决定；也可为 reject 或 cancel
"approver_identity": "user-123", // 可审计的审批主体身份
"approver_role": "publisher", // 用于授权检查的角色，而不是模型自述
"scope": {"project": "demo", "max_items": 1}, // 审批覆盖的资源范围和数量上限
"created_at": "...", // 创建时间，供审计与时序校验使用
"expires_at": "...", // 过期后即使参数未变也不能继续执行
"policy_version": "approval-v2" // 审批采用的策略版本，策略变化后应重新评估
}JSONC 教学表示
行尾
//是阅读注释；严格 JSON 序列化前请去除。
执行前重新验证：
- approver 当前身份与角色；
- run/action/fingerprint；
- state version 未变化；
- 未过期、未撤销；
- scope 仍满足；
- 目标资源当前版本未发生关键变化。
正文改一个 URL、目标账户改变、金额改变，都应让旧审批失效。
审批卡片显示什么
最小 UI：
- 动作：要调用哪个工具；
- 目标：具体文件、账户、用户、URL；
- 影响：写入、删除、公开、费用、可撤销性；
- 关键参数/diff：审批的精确内容；
- 来源：为什么提出，依据哪些 observation；
- 风险：不确定点、失败后果；
- 范围/过期：本次还是一段时间；
- 选择：批准、拒绝、编辑参数、查看更多、接管、取消。
原始日志过多会造成审批疲劳；只显示一句“是否继续”又不知情。使用分层披露：先显示关键影响，再允许查看完整证据。
Pause 与 Resume
进入 waiting_approval：
- 冻结 pending action 与 fingerprint。
- 持久化 state、event、budget 和截止时间。
- 释放 worker/连接资源。
- 发送不含秘密的通知。
- 等待有权限角色的 decision。
恢复：
- 取得 run lease。
- 重新认证 approver。
- 验证 approval contract。
- 重新检查当前资源和授权。
- 执行已经冻结的 action，而不是重新让模型决定要做什么。
- 用幂等键执行一次。
- 保存 receipt 与审计事件。
审批不是内存布尔值。进程重启后仍要安全恢复；多 worker 不能重复消费同一批准。
本库示例的范围
bounded_agent.py用scope=ticket_id演示“批准只针对当前目标”，并把完整 tool/arguments/idempotency key 放进 action fingerprint。它的 expiry 是逻辑 step，不是现实时间；也没有 approver 身份、签名、撤销列表或分布式消费。生产 approval 仍需采用上面的完整 contract，并在恢复时重新认证、检查expires_at与资源版本。
拒绝与取消是正常状态
- reject：拒绝当前动作；Agent 可提出无副作用替代方案，或进入
rejected。 - cancel：终止整个 run；停止新动作、尝试取消在途调用、报告已产生副作用。
- timeout：审批过期；不能默认批准，也不必等同永久拒绝。
- edit：形成新 action/fingerprint，重新审批。
进入 rejected、cancelled、failed 或 budget_exhausted 等 terminal 状态时，应从可执行状态中清除 pending action，并依靠历史 event 保留审计事实。否则旧审批可能在终止后仍看似可消费。不要用异常堆栈向用户表示“你拒绝了”；这是正常控制路径。
监督的认知风险
Automation bias
人容易过度相信流畅建议。缓解：
- 显示原始证据与不确定性；
- 不预选“批准”；
- 高影响时要求主动输入/二次确认；
- 用抽样审计和独立 verifier；
- 监控批准率异常。
Approval fatigue
过多低价值确认让人机械点击。按风险分级：
- 低风险只读自动；
- 可恢复小写入按 scope 批准；
- 高风险逐项；
- 异常/边界变化强制重新批准。
批量授权必须限定资源、工具、金额/数量、时效与撤销。
Skill mismatch
审批者若看不懂证据，就不能承担真实监督。NIST 强调角色责任与人员能力；系统需把领域专家、操作员、安全/法务等角色区分，而不是把所有判断丢给最终用户。
高风险控制矩阵
| 动作 | 默认控制 |
|---|---|
| 读取公开网页 | 自动，内容仍不可信 |
| 读取用户私有文件 | 明确范围、最小披露 |
| 修改本地草稿 | diff + 可撤销；按产品审批 |
| 发送外部消息 | 目标/正文预览，临执行审批 |
| 删除/付款/部署 | 强身份、角色、双重或分级审批、恢复 |
| 写长期记忆 | 展示内容、scope、TTL、删除方法 |
| 安装工具/扩大权限 | 独立安全决策，不能由工具内容触发 |
具体阈值属于应用 risk policy，不由通用教程编造。
动手练习
为“发布公开公告”设计：
- approval contract；
- 卡片中的目标、正文 diff、URL、受众、影响和来源；
- 审批后正文变化的失效规则；
- waiting 状态的 checkpoint；
- approver 角色和认证；
- reject、timeout、cancel、takeover 路径；
- 发布 receipt 与撤回/更正。
再设计一个批量授权，说明它怎样限制最大条数、允许域名、有效期和撤销。
自测
- clarification 与 approval 的语义为什么不同？
- action fingerprint 应包含哪些内容？
- 审批后 state version 变化为何要失效？
- 为什么人类确认仍可能只是“假监督”？
- reject 与 cancel 的影响范围有何不同？
能把审批做成可持久、可审计、可失效的 contract，才算掌握。
下一步
进入 不可信工具结果与防护，确保人和 runtime 看到的证据不会被环境文本劫持。
参考资料
以下为官方风险框架与第一方工程资料，获取/复核日期：2026-07-21。