Amazon Ads 优化 Agent 最容易展示的能力，是读完一份搜索词报告后给出“迁入精准”“加入否定”或“提高首页顶部竞价”的建议。模型能够解释指标，也能够按工具 schema 生成参数，但这还不等于系统能够安全地完成一次投放动作。建议与成交之间至少隔着对象识别、数据成熟、利润约束、冲突检查、权限批准、远端写入和结果回查。任何一环缺失，语言上正确的建议都可能成为账户里的错误配置。
Amazon Ads API提供程序化管理广告活动和获取报告的操作面；OpenAI Agents SDK与 Google ADK提供工具调用、会话和运行编排的通用构件。三者解决的是不同问题：广告 API 定义平台允许做什么，Agent 框架组织模型如何调用工具，Harness 则决定一项业务动作凭什么被允许、如何执行、失败后怎样辨认现场。
本文把 Harness 限定为一套围绕模型的确定性执行外壳，不把它包装成新的万能平台。最小闭环只需要完成六件事：把自然语言建议变成类型化提案，绑定可复现证据，检查业务不变量，取得与风险匹配的批准，以可识别的方式提交写操作，再回读远端状态确认结果。模型负责提出候选判断，Harness 负责让一项被批准的判断以可审计方式在 Amazon Ads 中成立。
工具调用成功，不等于投放动作成立
模型生成 update_bid(target_id, 1.20)，工具返回成功，只能证明一次接口交互看起来完成了。它没有回答 target 是否属于正确 profile 和 marketplace，当前 bid 是否已被人工改动，货币单位是否一致，1.20 是否突破 ASIN 的最大可承受 CPC，也没有证明远端最终状态确实变成 1.20。把工具响应当成业务完成，是 Agent 项目从演示走向生产时最常见的概念跳跃。
建议与成交断桥把本节的判断压缩成可检查的关系：说明模型输出和业务动作之间缺失的执行层。人物动作对应执行责任。
ReAct把推理和行动交织起来，为模型使用外部工具提供了清晰范式；SWE-agent进一步说明，Agent 与计算机之间的接口设计会显著影响任务表现。这些研究支持“执行接口本身是能力的一部分”，却不能推出模型应直接拥有广告账户写权限。代码环境中的失败往往可以重跑，预算、否词和竞价的错误则会立刻改变流量获取与成本分配。
因此，Harness 接收的不是一句“加价 20%”，而是一份动作提案：账户与站点、campaign、ad group、target、当前值、目标值、证据窗口、指标版本、业务目的、风险上限、批准要求和恢复值。提案形成后不可静默改写。若对象、证据或目标变化，系统应创建新版本，而不是让模型沿用旧批准替换参数。
这个边界也解释了为什么 MCP、function calling 或插件清单不是治理方案。它们能把 API 暴露为工具，却通常不拥有账户级利润定义、库存状态、预算所有权和审批规则。Harness 必须在工具之前建立业务门，在工具之后建立验证门，两扇门缺一不可。
先选两个动作检验最小闭环
最小 Harness 不宜从“自动优化整个账户”开始。更适合的检验对象是搜索词迁移和广告位调价：前者跨越查询、target、match type 与否定隔离，后者跨越基础竞价、placement adjustment、动态竞价和 campaign 共享预算。两项动作足以暴露身份、粒度、时间、权限和副作用问题，又能把范围控制在清晰对象内。
类型化提案压铸机把本节的判断压缩成可检查的关系：把自然语言建议压成对象明确的变更单。人物动作对应执行责任。
搜索词迁移的候选条件不能只有“带来订单”。系统需要确认实际顾客搜索词、触发它的 target、广告商品、站点、成熟点击与销售窗口，并判断它是品牌、防守、类目还是竞品意图。迁入精准后，还要决定原结构是否进行负向隔离。若只创建精准关键词而不处理流量重叠，新旧 target 可能继续同时参加相关竞价，之后的表现无法解释。
广告位调价的候选条件也不能只有“Top of Search ACOS 更低”。placement 报告描述位置汇总，target 报告描述定向对象；若底层数据无法给出二者的联合粒度，系统就不能声称某个搜索词在首页顶部的精确回报。加价还会与基础 bid、动态竞价策略和预算消耗共同作用。建议必须计算潜在有效竞价上界，并检查库存、Featured Offer、价格和贡献毛利。
τ-bench把工具、用户和策略约束放在多轮任务中评测，说明单次选对工具不足以证明流程可靠。对 Amazon Ads 而言，最小验收单元应是“提案到回查”的完整动作，而不是一条看起来合理的模型回答。
提案层要把解释压成可校验合同
模型擅长处理模糊要求，例如“把最近表现稳定的词收出来”，但执行层不能接受模糊词。Harness 要求模型先输出结构化提案，再由确定性规则验证。提案中的每个判断都应落到可比较字段：稳定是连续几个成熟窗口、最低点击与订单是多少；利润边界使用哪一版 COGS 和退款率；“最近”以哪个时区和数据截至时间定义。
一份搜索词迁移提案至少包含 source_target_id、customer_search_term、advertised_asin、destination_campaign_id、destination_match_type、negative_isolation_plan 与 evidence_snapshot_id。字符串相似不能替代对象身份。相同搜索词在不同 marketplace、ASIN、品牌意图或投放目标下，可能需要不同动作。
一份广告位提案至少包含基础 bid、当前 placement adjustment、动态竞价策略、建议调整、潜在有效竞价上界、campaign 日预算和风险窗口。系统还要保存“为什么不改另外两个旋钮”。如果同一时间同时修改基础 bid、placement 和动态竞价，观察期即使改善，也无法识别哪个变化产生作用。
Building effective agents主张从简单、可组合的工作流开始，仅在确有价值时增加自主性。这对投放系统的工程翻译是：模型可以参与产生提案与处理例外，范围、类型、金额和状态转换仍由显式合同控制。自然语言解释供人审阅，结构化字段供系统验证，两者必须来自同一个提案版本。
证据门先回答“这次建议基于哪一版事实”
Amazon Ads 报告存在请求参数、报告类型、归因回填和数据到达时间。Harness 不能只记录“过去 14 天”，而要保存具体起止日期、时区、profile、report type、请求标识、抽取批次、数据最大事件时间和质量检查结果。最近日期尚未成熟时，应明确标记 provisional，不得与成熟历史窗口直接比较。
证据门与决策门双锁把本节的判断压缩成可检查的关系：分别检查事实可靠性和业务不变量。人物动作对应执行责任。
证据门先检查粒度。search term、target、placement、advertised product 和 campaign budget 属于不同观察面，不能为了方便展示而直接宽表连接。若连接造成 spend 或 orders 扩张，后续所有建议都失去基础。比值指标也必须保留分子分母；跨行汇总 ACOS 应使用总 spend 除以总 attributed sales，而不是平均行级 ACOS。
证据门再检查经营状态。低 ACOS 可能发生在库存即将耗尽、价格临时促销或 Featured Offer 不稳定期间。系统应把广告事实与配置快照、库存快照、价格状态和利润版本按有效时间对齐。无法对齐时，提案保持草案，不能让模型用“总体趋势良好”填补缺口。
NIST AI RMF Generative AI Profile强调治理、测量与管理贯穿生命周期；OpenTelemetry 对 Agent 可观测性的讨论则把模型调用、工具使用和 Agent 行为放进可追踪链路。这里不需要照搬整套框架，但必须留下足够证据，使审核者能够重建“当时看到了什么”。
决策门检查业务不变量，而不是文案语气
Guardrail 若只检查敏感词和 JSON 格式，对投放风险帮助有限。真正需要执行的是业务不变量：动作对象必须位于批准范围，货币与 marketplace 一致，目标值不超过账户定义上限，预算变化不突破 portfolio 风险额度，低库存 ASIN 不得放量，否定关键词不能覆盖仍需探索的流量，任何写操作都必须存在恢复路径。
风险批准扭矩扳手把本节的判断压缩成可检查的关系：让批准绑定对象、差异、额度和有效期。人物动作对应执行责任。
OWASP 的 Agentic AI 威胁与缓解资料与面向 Agent 的威胁模型研究都指出，持久记忆、工具集成和较高自主性会扩展攻击与误用表面。投放系统还要防范“合法参数组成非法结果”：每个单项调整都在上限内，但一组 campaign 同时提预算，可能突破品牌当日总额度；每个否词看似合理，组合后可能封死新品探索。
决策门因此既检查单动作，也检查动作集合。它计算此次批次的总预算影响、涉及 campaign 数、预计最大损失和与其他自动规则的冲突。若 Amazon 控制台中的 budget rule 或动态竞价正在工作，自建 Agent 不应在同一周期频繁反向覆盖。系统可以要求缩小批次、延长观察或转人工批准。
所有阈值来自账户或业务配置，而不是写死在提示词中。没有毛利、库存和预算上限时，系统只能给出待补证建议，不能凭行业平均值执行。服务商基准可以帮助形成问题，但不能代替当前账户的策略合同。
批准要绑定对象、差异和有效期
“允许 Agent 调价”是过宽授权。有效批准必须绑定具体提案版本、对象集合、before/after 差异、最大影响、证据哈希和有效期。审批者看到的不是一段泛化解释，而是可以逐项核对的动作清单：哪些 target 从多少调到多少，哪些查询迁入何处，哪些原结构加入何种否定隔离。
幂等写入冲压台把本节的判断压缩成可检查的关系：为重复提交赋予可识别的动作身份。人物动作对应执行责任。
风险可以分层。只读分析无需逐次批准；创建不执行的草案可由系统自动完成；小范围、可逆且在硬上限内的改动可采用批次批准；预算大幅提升、广泛否定、跨 marketplace 或缺少可靠恢复值的动作必须逐项人审。风险等级由对象与影响决定，不由模型自报置信度决定。
批准会过期。审批之后若 bid、budget、库存、价格或 Featured Offer 变化，执行前的 compare-and-set 检查应判定基线失效。系统返回冲突并要求重新提案，不能以“已有人批准”为由覆盖新状态。批准身份与执行身份分离，执行 token 只在短时间内拥有必要对象的最小权限。
GAIA与 WebArena都把 Agent 放进需要工具与环境交互的真实任务中。它们适合提醒团队评测环境变化和多步完成度，但广告账户的批准语义必须由投放治理自行定义，不能从通用 benchmark 推导。
执行器要识别重复、未知结果和部分成功
外部写操作有三种需要区分的结果：明确成功、明确失败和结果未知。超时并不等于失败；请求可能已经被 Amazon 接收，只是响应没有到达。若执行器无条件重试，就可能重复创建 target 或连续提高配置。Harness 应为每个动作生成稳定幂等键，并保存请求摘要、对象版本、提交时间和远端响应。
远端回读验收尺把本节的判断压缩成可检查的关系：独立确认 Amazon Ads 最终状态。人物动作对应执行责任。
当平台接口不提供端到端幂等保证时，系统使用“写前读取—带基线提交—写后回读—差异核对”的模式降低歧义。结果未知时先查询远端状态：若目标值与提案一致，登记成功；若仍是基线值，在满足重试策略后重新提交；若出现第三种值，判定并发冲突并转人工处理。
批量动作还会部分成功。十个 target 中八个更新成功、两个失败，不应把整个批次简单标成失败后全部重放。执行账本逐项记录状态，补偿计划也逐项计算。搜索词迁移包含创建精准 target 与原结构负向隔离，两步之间必须有中间状态；若第二步失败，系统应阻断进一步扩量并提示流量重叠，而不是宣称迁移完成。
AgentBench展示了 Agent 在不同交互环境中的能力差异。生产 Harness 需要更苛刻的局部评测：注入超时、限流、过期 token、重复回调、人工并发修改和部分成功，确认执行器不会把基础设施异常翻译成新的投放策略。
回查门证明远端状态，而不是相信返回值
写入返回成功后，Harness 从独立读取路径获取实际配置，比较对象、值、版本和更新时间。回查要允许平台合理的传播延迟，但必须有截止时间。超过窗口仍无法确认时，动作状态保持 UNKNOWN，暂停依赖它的下一步；不能为了流程顺畅自动补写“已完成”。
回查分配置与业务两层。配置回查在分钟级确认 target、bid、budget 或 negative 是否生效；业务回查在归因成熟后判断动作是否达到预设目标。前者回答“系统做了什么”，后者回答“这样做是否值得”。两者不能合并，否则短期没有订单会被误判为写入失败，写入成功也会被误判为策略成功。
业务观察必须使用提案时冻结的指标版本和停止条件。搜索词迁移关注新旧结构的流量隔离、查询覆盖、成熟订单和总体增量；广告位调价关注有效 CPC、预算耗尽、不同位置的流量分配、贡献毛利与库存风险。结果不满足目标时，Harness按预先批准的恢复值生成补偿提案，而不是让模型临时改写成功标准。
这也是 SWE-bench带来的重要启发：任务需要可验证结果，而不只是令人信服的解释。对投放动作而言，验证器必须读取广告平台事实与业务事实，不能给执行 Agent 的自我总结打分。
最小数据模型比复杂多 Agent 更优先
支撑闭环的核心表并不多：不可变 evidence snapshot、版本化 action proposal、approval record、execution ledger、remote state observation 和 business outcome review。每条记录通过 task id、proposal version、object identity 与 evidence hash 连接。模型的自然语言解释可以作为附件保存，但不能成为唯一关联键。
未知结果隔离舱把本节的判断压缩成可检查的关系：处理超时后无法判定成败的中间状态。人物动作对应执行责任。
状态机至少包含 DRAFT、VALIDATED、APPROVED、SUBMITTED、VERIFIED、OBSERVING、KEPT、REVERT_PROPOSED 与 REVERTED。转换由确定性条件触发。模型可以建议下一状态，不能直接跳过验证和批准。终止状态同样重要：证据不足、对象冲突、权限失效和超过风险上限都应结束本次尝试，而不是无限规划。
先建设这个单 Agent、少工具的闭环，再讨论研究 Agent、策略 Agent、审计 Agent 和执行 Agent 的协作。若底层对象身份、证据版本与写入账本尚未建立，多 Agent 只会产生更多相互确认的文字。Harness 的最小不是代码量最少，而是没有任何一项外部副作用处于不可解释状态。
落地顺序也应服务于可验证性。第一阶段只接入报告读取和配置回读，让系统能够准确描述账户现场；第二阶段生成结构化提案，由投手在控制台手工执行，并比较建议与实际选择；第三阶段开放单一 campaign 内的小幅 bid 更新，强制批准、回读和每日动作上限；只有前三阶段持续稳定，才考虑搜索词迁移这类跨对象步骤。每扩大一次范围，都要增加相应的冲突、重复和恢复测试。
这个次序看似牺牲速度，实际减少了返工。许多团队先做自然语言问答和宽工具集，后来才补对象身份、数据版本与审计，结果原有 trace 无法复现，批准也无法绑定。若先固定最小记录和状态转换，模型、框架和 API 适配器都可以替换，已发生的投放事实仍保持连续。
产品验收也要避免只看建议接受率。投手接受很多建议，可能只是界面默认或缺少替代选项；真正应观察的是提案被拒绝和修改的原因、执行冲突是否被发现、远端回查是否一致，以及成熟窗口后是否仍符合原目标。接受率描述使用行为，不能单独证明建议质量。
当这些记录可以被另一名投手在不询问原作者的情况下复核，最小闭环才算形成。否则，所谓自动化仍依赖隐含知识和口头交接。
这条标准应进入发布门禁，而不是停留在设计文档里。
Agent Engineering可以作为当时工程社区对 Agent 系统构件的观察，Reddit 上的 ADK 讨论也能暴露开发者对框架抽象的真实疑问；两类材料只用于发现设计问题，不用于证明平台能力或投放收益。
结语：先把一项动作做完整
Amazon Ads 优化 Agent 的起点不该是覆盖更多 campaign，而是把一项小范围动作做完整。搜索词迁移迫使系统处理查询身份、结构隔离和跨步骤一致性；广告位调价迫使系统处理乘法竞价、共享预算和利润边界。两者都说明，模型输出只是候选，真正的业务结果由证据、约束、批准、执行与回查共同构成。
六步最小闭环装配图把本节的判断压缩成可检查的关系：串联提案、证据、约束、批准、执行与回查。人物动作对应执行责任。
最小 Harness 不需要预先拥有复杂自治，也不依赖某个特定框架。它需要稳定的提案合同、可复现证据、账户级不变量、对象化批准、可识别写入和独立回查。把这六件事连成闭环以后，模型能力升级才能转化为更好的判断，而不会同时放大执行风险。
先让系统能够回答“为什么改、谁批准、实际改了什么、结果怎样、如何恢复”，再让 Agent 获得更大范围。对投放业务而言，这比一次生成多少建议更接近真正的成交。