“关键动作需要人工确认”听起来已经足够谨慎，真正落到 Amazon Ads 账户时却仍有大量空白：谁是“人工”，确认的是一句策略描述还是具体对象差异，批准能持续多久，campaign 在批准后变化怎么办，跨多个预算的组合影响由谁检查，已经批准的动作能否在执行前撤销，执行后又如何恢复。
OpenAI Agents SDK 的 Human-in-the-loop 文档与 LangGraph interrupts都展示了暂停工具调用、等待外部输入再恢复的机制。它们解决运行控制，不替广告主定义授权。一个“Approve”按钮若没有绑定 Amazon profile、campaign、目标值、证据版本与有效期，只是把风险从模型点击转移给人点击。
投放 Agent 的批准系统应围绕业务影响设计：读取不改变账户，草案可被丢弃，小幅 bid 调整可逆，大幅预算提升会扩大损失半径，广泛否词还可能长期切断需求发现。不同动作不能共享同一确认方式。Human in the loop 的价值不在让人看过，而在让正确责任人对一个可理解、有限、可撤销的状态变化承担明确授权。
“允许优化账户”不是可执行授权
宽泛授权通常以角色或 token 表达：某服务账号可以管理广告活动，某操作者同意 Agent 自动优化。技术上可调用不等于业务上可执行。账户管理权限可能覆盖多个 marketplace、品牌和 portfolio，而本次任务只允许调整一个新品 campaign；“自动优化”也没有说明预算、竞价、否词和结构创建分别允许到什么程度。
预算钥匙交接柜把本节的判断压缩成可检查的关系：明确谁能对哪个账户执行何种动作。人物动作对应执行责任。
Amazon Ads API提供广告活动管理和报告能力，API 身份定义可调用表面，Harness 还要在上层建立对象级能力（capability）。一份能力至少包含主体、profile、marketplace、对象选择器、动作类型、数值上限、有效期和是否需要二次批准。模型只能获得当前任务所需能力，不能从工具列表推断自己拥有更大范围。
授权对象也必须使用稳定 ID，而不是 campaign 名称。名称可重复、可修改，字符串筛选容易把相邻品牌或测试活动纳入。profile、campaign、ad group、target、portfolio 和 advertised ASIN 的身份链要在提案生成前解析，并在批准页面上展示可读名称与真实 ID。
当范围无法确定时，系统可以完成只读分析并生成草案，不能自动扩大选择器。缺少权限是一种正常结束状态，不应通过让模型换工具或多次请求来绕过。
先按副作用而不是按工具名称分级
风险分级至少考虑可逆性、损失速度、作用范围、证据成熟和语义复杂度。读取 report 风险低，但包含敏感查询数据，需要访问控制；创建草案不改变竞价，却可能进入后续批处理；bid 小幅调整通常可恢复，但高基数 target 的小时损失可能很大；budget 增加直接扩大可消费额度；negative keyword 可能长期改变流量，恢复后也无法补回错失机会。
风险分级阶梯秤把本节的判断压缩成可检查的关系：按金额、范围、可逆性与时效划分审批。人物动作对应执行责任。
可以设置四级动作。L0 是只读与解释；L1 是不执行的提案和模拟；L2 是小范围、可逆、硬上限内的写入；L3 是高影响或难恢复动作。分级结果由规则计算，输入包括对象数量、累计预算变化、潜在有效 CPC、历史消耗速度、库存和权限，不由模型给自己打“低风险”。
NIST AI RMF Generative AI Profile提供识别、测量与管理风险的公共框架；ASTRA从 Agent 可操控性与 guardrail 评估出发，说明仅靠系统提示执行规则并不稳固。对投放 Harness 的含义是：风险边界应由独立策略引擎和执行适配器强制，模型只能在边界内提案。
L2 也不是“一次批准永久自动”。系统可以为特定 campaign、动作步长和每日累计影响发放短期能力，达到次数、金额或时间上限后自动失效。风险额度是消耗品，不是静态角色标签。
批准对象必须是一份不可变差异
审批者需要看到动作前后差异，而非“建议适当提高预算”。预算提案要列出当前日预算、建议值、增幅、预计最大额外消耗、portfolio 汇总影响、证据窗口与恢复值。竞价提案还要显示基础 bid、placement adjustment、动态竞价策略和潜在上界。否词提案则展示 exact/phrase 类型、来源查询、可能覆盖范围与仍需保留的探索流量。
差异包包含 proposal id、version、evidence hash 与 remote baseline version。批准签名绑定整个包；任何字段改变都生成新版本并重新审批，不能在后台保留“已批准”状态再替换 target 列表。自然语言摘要帮助理解，结构化 diff 才是授权对象。
OpenAI Agents SDK guardrails提供输入、输出和工具 guardrail 的实现参考，但动态文档只用于说明机制，不用于证明某日已经发布某项能力。广告 diff 需要额外的业务校验：汇总预算、利润边界、库存、站点货币、广告产品支持与当前 API 状态。
审批页面还应暴露未知信息。若归因未成熟、COGS 过期或报告有缺口，不能用一个综合置信分掩盖。人可以在明确未知下拒绝、缩小范围或仅批准观察，不应被迫在“批准全部”和“取消全部”之间选择。
批准有作用域、额度和时间
同一人可能是某品牌的预算 owner，却不是另一个 marketplace 的授权人。审批路由要按 profile、portfolio、品牌、金额和动作类型计算。高影响批次可以要求双人批准：策略负责人确认投放逻辑，财务或业务 owner 确认预算与利润风险。双人批准不是重复点击，而是两种责任边界。
差异化批准放大镜把本节的判断压缩成可检查的关系：审批的是具体变更而非宽泛意图。人物动作对应执行责任。
授权额度既看单动作，也看组合。十个 campaign 各提高 10 美元，单项都可能属于 L2，汇总后却突破 portfolio 当日上限。Harness 在审批前和执行前两次计算组合影响，并扣减在途、已批准未执行的额度，避免并发批次分别通过。
批准还要有有效期。小时级预算异常提案可能只在当天有效，搜索词迁移可有更长窗口，但 campaign 结构、库存或价格变化会提前使其失效。执行器采用 compare-and-set：当前远端基线与批准 diff 不一致时，停止并生成冲突，不让旧授权覆盖新现场。
AWS Agentic AI Lens 的 HITL 指南与 Google Secure AI Framework controls可用于校准最小权限、监督和控制设计。二者是通用安全资料，具体审批人、额度和撤销时限仍由广告主组织负责。
三类投放动作需要不同批准逻辑
预算提升的风险是损失速度和组合额度。批准应显示当前 pacing、剩余时段、库存覆盖、最大可承受 CPC、portfolio 可用风险额，以及 Amazon 预算规则是否已启用。Amazon budget rules guide用于理解产品入口；动态页面能力必须按执行当时核验，不能用今天页面描述过去账户状态。
授权租约沙漏把本节的判断压缩成可检查的关系：让写权限随对象和时间自动失效。人物动作对应执行责任。
bid 与 placement 调整的风险是乘法放大。基础 bid、位置倍率和动态竞价共同决定潜在竞价，审批不能只显示一个百分比。建议若同时改变多个旋钮，应升级风险或拆成可辨识实验。高流量 target 的小比例调整可能比低流量 target 的大比例调整影响更大，分级必须结合历史竞价资格和消耗速度。
negative keyword 的风险是语义覆盖和机会损失。Sponsored Products targeting guide帮助核验 target 与匹配相关产品语义；具体否词仍需搜索词证据和 overblocking review。exact negative 与 phrase negative 的影响不同，品牌词、类目词、型号词和多语言变体也不能只靠字符串包含判断。
三类动作共同遵守最小变更原则：一次批次只改变必要对象，配置回读后再进入观察。批准系统不是为了加快批量写入，而是为了把风险拆成责任人能够理解和承担的单位。
撤销发生在执行前，回滚发生在执行后
撤销与回滚常被混用。撤销（revocation）使尚未执行或尚未继续的授权失效；回滚（rollback/compensation）处理已经发生的外部副作用。前者应尽可能即时，后者必须重新评估当前状态。用户点击撤销后，执行队列、等待中的 workflow 和短期凭据都要感知同一个授权版本已失效。
批准记录拥有 ACTIVE、REVOKED、EXPIRED、CONSUMED 与 SUPERSEDED 状态。执行器在真正调用 Amazon API 前进行最后一次授权校验，不依赖任务入队时的结果。批次执行期间发生撤销时，尚未提交的子动作停止，已提交动作进入回读和补偿评估，不能假装整个批次未发生。
执行后的回滚不是简单改回旧数字。观察期内可能发生人工修改、budget rule 触发或库存变化，旧值不一定仍合理。系统读取当前版本：若仅本任务修改且恢复仍安全，可生成预批准补偿；若存在并发变化，升级人工复核。所有补偿都有新 proposal、幂等键与回读证据。
Temporal 的 HITL 研讨资料和 Temporal AI patterns可用于参考长等待、信号和工作流恢复；它们不替代广告动作的撤销语义。撤销必须是业务状态的一等事件，而不是给模型发一句“请停止”。
最小权限要落实到执行凭据和工具表面
若 Agent 进程长期持有账户全量写 token，即使审批逻辑正确，提示注入、工具误选或实现缺陷仍可能绕过上层。更稳妥的方式是分析身份只读，批准后由执行服务换取短期、限对象能力；执行服务不接收自由文本，只接收签名后的类型化 diff。
双人复核签章桌把本节的判断压缩成可检查的关系：高风险预算变更需要独立批准。人物动作对应执行责任。
工具也应按动作拆分。set_campaign_budget、set_target_bid、create_negative_exact 与 create_negative_phrase分别拥有 schema 和校验，不提供一个可以任意透传请求体的通用 call_ads_api。对象 ID 由服务器从批准包读取，模型不能在调用参数中替换 profile 或 campaign。
Claude Code sandboxing从工程代理角度讨论隔离与许可，Securing Agentic AI则系统整理 Agent 工具和持久状态风险。Amazon Ads 场景的推断是：工具能力越宽，Harness 越难证明一次批准只产生预期影响；缩小工具表面本身就是治理。
凭据、批准记录和执行日志分开保存。日志只记录非秘密引用、主体、对象和结果，不记录 token。权限获取失败应停止任务，不能让模型寻找旁路身份。安全降级是保留提案和证据，等待授权恢复。
人审界面要降低决策负担，而不是堆满指标
审批者不需要阅读完整模型 trace，也不应面对几十个未经整理的比率。界面先展示业务目的、对象范围、关键 before/after、最大额外风险和未知信息，再允许下钻证据。批量动作按原因和风险聚类，但每个对象仍可展开、排除或要求重新计算。
紧急撤销拉闸箱把本节的判断压缩成可检查的关系：发现异常后冻结后续动作并收回权限。人物动作对应执行责任。
审批信息的排序很重要。先呈现不可逆或高损失部分，再呈现预期收益；先显示证据缺口，再显示模型理由；先说明批次总影响，再让人查看单个 campaign。若页面把“预计销售增长”放在最醒目位置，把归因未成熟和库存风险藏在折叠区，形式上有人审，实际仍在推动确认偏差。
对于批量提案，系统允许批准者拆分。投手可以只批准已有成熟证据的三个 target，把其余对象退回补证；也可以降低建议步长并形成新版本。任何人工改动都重新计算组合额度和恢复值，不能在浏览器里改一个数字后沿用原签名。审批体验的目标不是一次通过更多动作，而是用较低认知成本得到准确授权。
拒绝原因应结构化但保留备注，例如证据不足、对象错误、风险过高、与促销冲突、需要更小范围或策略本身不成立。结构化原因用于统计提案问题，备注用于保留上下文。系统不能把拒绝简单当成负反馈要求模型“更有说服力”，否则 Agent 会优化文案而不是修正证据。
移动端可以接收提醒和查看摘要，但高影响预算批次若无法完整展示差异，应要求在更适合的界面完成。便利性不是降低知情标准的理由。紧急风险抑制则采用事先批准的安全动作，例如冻结新增放量，并在事后提供完整记录；不能借“紧急”开放任意写权限。
审批服务自身也需要可用性设计。通知失败不能自动视为批准，审批超时不能由 Agent 代签；系统保留草案并按升级路径提醒替代责任人。若风险正在快速扩大，只能执行预先授权的保守动作，不能临时创造权限。所有离线、超时和替代批准都进入同一审计生命线。
最后要衡量人审是否真的改善结果。比较被批准、被修改和被拒绝提案的后续轨迹，分析哪些证据最常改变决定，逐步减少无关信息。优化目标是提高有效判断密度，而不是单纯缩短点击时间；高影响动作多花几分钟核对，可能比事后数天追查更便宜。
人审质量本身也需要抽样复核，避免批准流程在长期使用后退化为机械点击。
解释需要反事实：如果不执行，会保留什么状态；如果只执行部分，风险如何变化；什么条件会触发恢复。对预算建议，展示剩余时间与目标 pacing；对否词建议，展示可能被覆盖的真实查询；对 placement 建议，展示乘法后的上界。这样人批准的是选择，不是模型权威。
人也会犯错。界面应阻止超过硬上限的批准，显示证据过期和远端冲突，避免默认勾选高风险批次。审批耗时、拒绝原因、修改比例和后续回滚都进入评测，用于改进提案质量，而不是评价员工是否“配合自动化”。
The Agent Harness、Reddit 上的 HITL 实践讨论和 X 上的 HITL 架构观点可以帮助发现交互与工程问题；它们属于社区观点，不证明安全性。最终界面必须由真实投手用具体 diff 做可用性测试。
审计要能重建一次授权的完整生命线
审计记录从提案产生开始：模型与版本、任务合同、证据快照、规则结果、风险级别、审批路由、审批身份、时间、撤销事件、执行请求、远端回读、观察结果和补偿。每个事件追加而非覆盖，形成可排序生命线。
审计关心的不只是“有人批准”。它要回答审批者是否有权、看到的 diff 是否与执行相同、批准时证据是否有效、执行前是否再次校验、撤销是否及时生效、最终远端状态是否一致。缺少任一环，系统只能证明有日志，不能证明授权完整。
Microsoft Agent Framework可以作为 workflow、checkpoint 和 HITL 的开源实现参考。采用任何框架，都要把 Amazon 对象和批准状态作为领域事件；框架 trace id 不是业务审计 ID，模型 span 也不能替代远端配置证据。
定期审查授权策略：哪些 L2 动作经常被拒绝，哪些 L3 动作实际影响很小，哪些撤销未及时到达执行器，哪些恢复因并发修改失败。策略调整要版本化，并用历史任务回放，防止降低审批摩擦的同时扩大风险。
验证批准系统要测试拒绝和竞态
只测试批准后的顺利执行，会遗漏最危险路径。测试集要覆盖拒绝、超时、撤销、审批后基线改变、两个批次竞争同一预算、部分执行后撤销、凭据过期和回读不一致。每个场景验证账户最终状态、额度账本、审批消费次数和补偿状态。
最小权限工具腰带把本节的判断压缩成可检查的关系：只向当前任务暴露必要操作。人物动作对应执行责任。
策略测试可以生成边界案例：单 campaign 未超上限但 portfolio 汇总超限；bid 增幅很小但乘法竞价突破最大 CPC；phrase negative 覆盖多个仍在探索的高价值词；库存由绿区转红区后旧批准仍在队列。期望结果通常是阻断或重新审批，而不是让模型解释为何仍可执行。
安全指标包括未经授权写入率、过期批准拦截率、撤销传播时间、组合额度超限率、远端回读完整率和补偿成功率。业务收益单独评估。即使某次越权加预算带来销售，也不能计为安全系统成功。
测试环境无法完全复制拍卖与归因，但授权状态机、额度竞争和执行竞态可以确定性验证。上线先用 shadow mode 生成 diff 和审批建议，不写账户；之后只开放小范围 L2 动作，扩大范围必须以真实审计记录为依据。
结语：批准是一份受约束、可撤销的能力
Amazon Ads 投放 Agent 的治理不应止于“高风险时弹窗”。授权必须绑定真实对象、不可变差异、证据版本、风险额度和有效期；执行前重新校验现场；撤销即时影响尚未提交的动作；已经发生的副作用通过回读与补偿处理。这样人工参与才成为控制机制，而不是责任装饰。
批准证据审计卷宗把本节的判断压缩成可检查的关系：串联提案、签署、执行、撤销与责任人。人物动作对应执行责任。
风险分级使人力集中在预算放大、广泛否词和高影响竞价等关键动作，最小权限则保证模型和执行器无法扩大批准范围。审批界面用经营影响和反事实帮助判断，审计生命线让每次授权都能复建。
谁可以改预算，不由模型、工具 token 或一个通用角色单独回答；它由主体、对象、动作、额度、时间和当前证据共同决定。把这六项写进 Harness，Agent 才获得真正可治理的行动能力。