Amazon Ads 优化 Agent 上线后，团队很容易把演进等同于更换更强模型：新的模型能读更长报告、调用更多工具、解释更完整，于是被期待自然减少误调价。实际系统表现由模型、提示、工具 schema、数据语义、状态管理、审批、执行适配器和恢复逻辑共同决定。只换模型，既无法定位改善来自哪里，也可能在回答质量提升的同时扩大行动风险。
SWE-agent说明 Agent–Computer Interface 会显著影响模型完成任务；τ-bench把策略遵循、工具与用户互动纳入评测；Towards a Science of AI Agent Reliability进一步强调重复试验和可靠性分布。这些研究不能代替广告效果实验，却足以否定一个常见做法：用少量演示或单次准确率给整个投放 Agent 盖章。
更可行的演进单元是“版本化 Agent 系统”：模型、提示、工具、Harness 策略和数据合同分别有版本，评测既看最终业务状态，也看完整轨迹是否遵守证据、权限和风险约束；生产 trace 经脱敏和确认后转成回归案例。先证明新版本在相同投放任务上更可靠，再讨论它是否因为模型更强。
先写清被评测的到底是哪一个系统
“评测 Agent”若不记录版本，结果无法复现。一次运行至少标识模型与参数、系统提示、工具清单和 schema、语义层版本、知识资料快照、Harness 状态机、策略规则、执行适配器以及 eval dataset 版本。任何一项变化都可能改变轨迹，不能只以模型名称归因。
换模型幻觉展示柜把本节的判断压缩成可检查的关系：对比模型升级与系统能力演进。人物动作对应执行责任。
例如，旧版本把 update_campaign 暴露为宽参数工具，新版本拆成 set_budget、set_bid_strategy 和只读查询。即使模型不变，误改字段的风险也会下降。相反，新模型能够自主串联更多工具，如果审批和幂等规则没有同步加强，单次越界的影响可能更大。能力与风险需要分别测量。
OpenAI 关于 eval 驱动开发的文章与 Anthropic 的 Agent eval 方法都主张把评测纳入开发循环。厂商方法可用来组织思路，具体 Amazon Ads 成功标准仍要由广告主定义：正确策略不只是一句建议，还包括数据窗口、对象、动作、批准、回读和成熟结果。
版本登记还要覆盖可变外部环境。Amazon API、报告字段和控制台功能会变化；动态官方文档用于解释当前机制，不能反向证明历史能力。历史回归使用固定 schema 与模拟适配器，线上验证再以当前官方资料和账户能力清单校准。
结果评测要落到可验证的业务状态
结果不是模型最后一段总结，而是任务结束时能够独立读取的状态。搜索词迁移的结果包括精准 target 是否创建在正确 campaign、原结构是否按方案隔离、是否出现重复竞争、观察窗是否成熟；预算建议的结果包括批准范围、实际 budget、累计风险和 pacing；广告位调价则要验证基础 bid、placement adjustment、动态策略与有效竞价上界。
决策轨迹检修台把本节的判断压缩成可检查的关系：逐步检查观察、推理、工具与门禁。人物动作对应执行责任。
结果评分可分为任务正确、业务价值和安全护栏。任务正确回答对象和配置是否符合合同；业务价值在成熟窗口观察贡献、规模、增量假设和库存影响；安全护栏检查是否越权、超限、重复写入或跳过审批。安全失败不能被销售改善抵消，否则系统会学到“赚到钱就可以越界”。
SWE-bench用可执行测试判断补丁是否解决问题，WebArena与 GAIA则扩展到网页和真实世界多工具任务。Amazon Ads eval 应借鉴“外部验证器”而非复制任务内容：验证器从冻结报告、配置快照和执行账本计算结果，不读取 Agent 的自我解释。
业务价值常受季节、价格、库存和自然流量干扰。离线任务主要验证决策正确性和安全性，不能声称产生真实 ROAS；线上增量需要受控实验或谨慎准实验。两类证据分开报告，避免把历史回放里的正确选择写成未来收益承诺。
轨迹评测解释“结果是怎样得到的”
两个运行可能得到同一最终 budget：一个先校验库存和利润，经过批准后写入并回读；另一个误用旧报告、反复调用更新接口，最后碰巧达到相同值。只看结果会把二者判成同样成功，轨迹评测则检查证据选择、工具序列、状态转换和停止条件。
轨迹不要求模型走唯一固定路径。可以定义必要事件与禁止事件：必须读取正确 profile 和配置基线，必须使用成熟证据，L3 动作必须批准，写后必须回读；禁止跨 marketplace、禁止在未知执行结果时直接重试、禁止修改未授权对象。对于开放分析路径，评审器关注不变量，不惩罚合理的工具顺序差异。
OpenAI Agents SDK tracing提供 span 与 trace 的实现入口，OpenTelemetry 的 Agent 可观测性文章和 GenAI agent span conventions提供标准化方向。后者仍处于演进状态，应锁定 commit 并标注实验性，不能把草案字段当成稳定承诺。
轨迹评分应保留证据链接。评审器判断“跳过库存检查”时，要指出预期事件、实际事件和规则版本；判断“重复写入”时，要关联 idempotency key 与远端 receipt。没有具体证据的 LLM judge 只能作为辅助意见，不能直接决定生产放权。
把一次任务拆成可诊断的跨度
观测设计需要同时服务调试、评测与审计。根 trace 对应一个运营任务，下面分为 evidence acquisition、semantic validation、proposal、policy evaluation、approval wait、tool execution、remote verification 和 outcome review。每个 span 携带非秘密的 task id、proposal version、object type、evidence snapshot 和状态结果。
离线任务靶场把本节的判断压缩成可检查的关系：用固定场景验证搜索词迁移和调价路径。人物动作对应执行责任。
模型调用 span 记录模型版本、提示模板版本、token 与结构化输出状态；工具 span 记录工具版本、参数摘要、幂等键、响应类别和重试；状态 span 记录前后状态与触发事件；审批 span 记录批准引用和等待时间；业务复核 span 记录数据成熟度与结论。敏感凭据、完整顾客查询和不必要的账户数据不进入通用遥测。
错误分类要贴近机制。模型选择错误、schema 校验失败、数据不成熟、语义口径冲突、权限拒绝、远端限流、未知写入、回读不一致、人工并发修改和业务护栏触发，不能全部归为 agent_failed。分类越粗，团队越容易用换模型处理本该修工具或状态机的问题。
观测不是记录越多越好。需要明确定义保留期、采样、脱敏和访问权。高风险写入轨迹完整保留，低风险只读分析可采样；评测数据提取必须去除账户身份和凭据。生产 trace 的目的，是解释系统行为并生成可操作改进，不是保存无限思维文本。
用重复运行衡量可靠性，不看最好一次
Agent 具有非确定性，同一任务可能因模型采样、工具延迟和环境顺序产生不同轨迹。每个关键 eval 应重复运行，报告成功率、失败类型分布、最坏风险和置信区间，而不是挑选最好的录像。对高影响动作，即使平均表现很高，少量未经授权写入也可能阻止上线。
生产观测黑匣子把本节的判断压缩成可检查的关系：采集参数、时延、拒绝、恢复与业务结果。人物动作对应执行责任。
Time Horizon 1.1更新了长任务测量方法，说明可靠性会随任务长度变化；原始长任务论文也提示趋势外推依赖任务集与假设。Amazon Ads 团队应建立自己的时程分层：单次读取与解释、数分钟提案、跨审批执行、跨日观察和跨周复盘，分别测量。
可靠性指标包括 pass@1、重复运行全通过概率、违规发生率、恢复成功率和完成时间分布。对一个需要连续通过多个关键阶段的任务，单步 95% 并不意味着端到端 95%。系统应报告瓶颈阶段，优先修正高频或高损失失败。
成本也属于可靠性。无限重试或过度研究可能最终完成，却消耗不可接受的 token、API 配额和人审时间。评测设置工具调用、墙上时间和人工中断预算，超过即视为运营失败或降级，不让“最终成功”掩盖过程失控。
领域 eval 集要从投放故障而不是知识问答开始
Amazon Ads eval 不应主要测试“ACOS 的定义是什么”。模型通常能回答术语，生产风险来自事实组合和状态变化。案例应覆盖：报告最近两天仍在回填、search term 与 placement 粒度无法联合、同一 ASIN 库存下降、人工刚修改 bid、预算规则正在触发、target 创建响应超时、批量操作部分成功、否词可能过度覆盖。
每个案例包含当时可见证据、隐藏真值、业务合同、允许工具和故障注入。时间按步骤释放，防止模型读取未来销售。期望输出不是唯一文案，而是允许的动作集合、必须满足的检查和不可违反的不变量。案例可以有“证据不足，停止”的正确答案。
Google ADK Evaluation和 OpenAI Agents SDK Testing可用于参考 response/trajectory 与测试组织；两者都是动态文档，应锁版本使用。领域数据集仍由内部账户事实脱敏构建，并经投手确认标签。
困难样本要保留边界。品牌词低 ACOS 但自然成交强，不能自动加预算；高意向查询有订单但利润为负，不能迁入放量；Top of Search 回报好但 campaign 上午耗尽预算，不能只提高 placement；库存恢复但 Featured Offer 不稳，不能立即恢复全部竞价。这样的案例才能检验系统是否面向经营问题，而非报表数字。
生产失败如何进入回归集
生产事件先完成事实核验，再转成 eval。原始 trace 可能含缺失数据、人工操作和外部故障，不能直接把最终结果当标签。事件复盘需要重建时间线、识别当时可见信息、确定违反的不变量、区分模型判断、工具实现与流程配置责任。
错误分类标本墙把本节的判断压缩成可检查的关系：区分理解、数据、权限、执行和恢复失败。人物动作对应执行责任。
形成回归样本时，删除账户身份与敏感字段，保留语义结构和关键数值关系。若失败来自“批准后 campaign 被人工修改”，样本应包含基线版本变化；若失败来自“未知写入被重试”，应模拟超时与远端已成功。修复版本必须通过原失败样本和邻近反例，防止只对单个 trace 打补丁。
生产成功也可入集，但要避免幸存者偏差。保留那些正确停止、正确请求补证和正确降级的案例，不只保留带来销售的动作。长期看，数据集应按广告产品、marketplace、策略、风险等级和时程覆盖，明确仍未覆盖的区域。
Reddit 对 Agent telemetry 语义约定的讨论和 X 上的 Harness 工程总结能帮助发现社区正在争论的观测盲点；Long-Running Agents提供长任务工程综述。社区材料只用于发现问题，事件标签仍以内部证据和一手规范为准。
先比较 Harness 版本，再隔离模型变量
演进实验可分两步。第一步固定模型，比较工具与 Harness：缩小工具表面、增加幂等校验、改善上下文构造或调整审批策略，观察轨迹违规、完成率和成本。第二步固定 Harness，比较模型：判断不同模型在相同证据、工具和规则下的提案质量与恢复能力。这样才能定位投资回报。
反事实回放双屏把本节的判断压缩成可检查的关系：比较实际动作与替代策略的后果。人物动作对应执行责任。
若同时更换模型、提示、工具和数据层，即使线上指标变化，也无法知道原因。版本矩阵不必穷举，可以按风险优先：先在离线数据集筛选，再 shadow 运行，之后对小范围低风险对象开放写入。每一阶段有明确晋级条件和回退版本。
模型升级可能改变工具调用频率和自主规划长度，旧的限流、成本和批准设计未必适用。新模型离线准确率提高，却更愿意采取动作时，需要重新测拒绝能力、停止条件和批量影响。更强的模型不是天然更保守。
Harness 升级也要兼容在途任务。状态 schema、幂等键或审批规则改变时，旧任务需按版本恢复或显式迁移。不能把线上任务静默切到新规则，再用新评测解释旧行为。
线上验证从 shadow 到受限写入
shadow mode 让新版本读取真实数据、生成提案和预计动作，但不写账户。系统将其与现行流程、人类决定和成熟结果比较，重点看证据选择、冲突发现和风险判断。shadow 不能测量真实动作的因果收益，却能暴露大量越权、口径和工具问题。
进入受限写入后，只开放少量 profile、campaign 与 L2 可逆动作，设置对象数、每日累计预算影响、最大 CPC、执行频率和自动暂停条件。所有写入要求回读，未知结果进入人工对账。控制组继续使用旧版本或人工流程，避免把季节和促销变化误判为 Agent 效果。
Amazon 统一报告更新提供 2026 年 6 月的官方产品事实，可用于改善跨对象分析入口，但报告统一不等于指标语义自动统一。评测仍要固定广告产品、归因窗口、币种和粒度，并将广告归因结果与零售经营结果分开。
放权依据是风险调整后的稳定表现：多次运行可靠、无未批准写入、未知副作用得到对账、人工拒绝率下降且业务护栏稳定。达到条件后逐步扩大，不以一次大促期间的销售增长直接升级权限。
看板要把能力、可靠性、风险和业务价值分开
一个综合“Agent 分数”会掩盖问题。能力面展示各类任务完成率；可靠性面展示重复运行分布、恢复和耗时；风险面展示越权、超限、重复写入和撤销；业务面展示成熟贡献、规模、pacing 与库存影响。四个面板可以相关，但不能相互抵消。
评测到发布回路把本节的判断压缩成可检查的关系：让失败证据进入提示、工具和 Harness 改造。人物动作对应执行责任。
每个指标还要有分母和样本状态。未经授权写入率的分母是所有实际写入机会，还是全部任务，会得到完全不同的数字；恢复成功率要说明注入了哪些故障；业务贡献要区分成熟、未成熟与受干扰窗口。只展示百分比而不展示样本数，会让小规模试运行产生虚假的稳定感。
趋势比单点更重要，但版本切换会打断趋势。看板在发布线标记模型、Harness、数据合同与 Amazon API 变化，避免把报告口径调整当成能力增长。若统一报告改变了可见对象或字段，先做同窗口重算与守恒检查，再连接前后时间序列。无法桥接时明确断点，不用平滑曲线掩盖。
团队还需要失败预算。不是允许一定比例越权，而是规定可接受的重试、人工接管、延迟和低风险任务失败范围；安全不变量仍保持零容忍。失败预算耗尽后暂停扩大权限，优先修复最高影响故障。这样产品节奏与可靠性有可讨论的边界，而不是每次事故后临时决定是否回退。
看板不直接触发账户动作。它产生调查或版本决策，具体投放修改仍经过正常提案与批准。观测系统若同时拥有自动调价权限，会把测量与控制耦合，异常指标可能立即放大成账户变化。诊断和执行保持分权，结论更可信。
指标负责人要定期删除失去决策价值的图表。若一个指标连续数月没有对应行动，可能只是装饰；若团队总在事故后临时查询某类 trace，说明正式看板缺少诊断入口。观测体系随故障模型和权限范围演进，不以收集字段数量衡量成熟度。
对外汇报只呈现经过成熟和口径核验的业务结果，对内保留工程可靠性与未知项。把离线 benchmark、shadow 建议和真实写入收益混在同一增长数字里，会让下一次版本决策失去基础。
看板按版本、任务类型、marketplace、风险级别和阶段切分。若新模型提高分析任务完成率，却增加 L3 动作提案和人审负担，团队能看到真实取舍。若 Harness 更新降低重复写入，但完成时间变长，也可以判断延迟是否可接受。
评审节奏分为发布前、周度生产和月度策略。发布前看回归与安全门；周度看新失败簇和数据漂移；月度看业务结果和权限是否应扩大。每个结论都指向 owner、修复类型和验证计划，避免“继续观察”成为无期限状态。
当数据不足时，明确 unknown。小体量 campaign 的业务结果可能无法稳定判断，但越权和重复写入仍可精确测量。先用能测准的工程指标限制风险，再等待足够业务证据。
结语：演进的是整个决策与执行系统
Amazon Ads 优化 Agent 的表现不是模型能力的单变量函数。数据口径、工具设计、状态恢复、审批、执行与观测共同决定最终结果。只换模型会让团队错过更高价值的修复，也可能把新能力直接转化为更大的行动半径。
Agent 演进年轮图把本节的判断压缩成可检查的关系：用轨迹覆盖与风险收敛记录真实进步。人物动作对应执行责任。
结果评测确认广告账户和业务状态，轨迹评测检查证据与规则，重复运行揭示可靠性分布，生产观测提供真实失败，再通过版本隔离判断应修模型、工具还是 Harness。整个闭环以账户事实和风险边界为准，不以厂商 benchmark 或演示完成度代替。
Agent 演进不是追逐一次更聪明的回答，而是让同一类投放任务在更多真实扰动下，仍能稳定做对、正确停下，并留下足以解释和改进的证据。