Amazon Ads 的跨日优化不是一串可以从头重跑的纯计算。系统先申请异步报告，等待数据就绪，识别搜索词或广告位机会，提交审批，修改 target、bid 或 budget，再经过归因成熟期复核。有些步骤可以重复，有些步骤重复一次就会改变账户；有些接口超时意味着失败，有些超时只是“远端已成功，本地没收到确认”。把所有异常统一处理为 retry，会把可靠性问题转化为真实投放风险。
Temporal 的 Durable Execution 指南把事件历史与确定性重放作为进程故障后继续工作的基础；LangGraph 的持久执行文档提供另一种检查点与状态恢复路线。这些框架不是 Amazon Ads 的业务答案，但它们揭示了关键区分：恢复不是重新思考一遍，而是根据已经发生的历史，只继续尚未完成且仍然有效的部分。
跨日调价需要三类相互配合的记录。检查点说明任务在什么业务阶段、当时使用哪版证据；事件历史说明每个确定性决定怎样形成；幂等账本说明哪些外部副作用已经提交、是否确认、如何对账。重试只是在相同条件下再次尝试一个步骤；恢复则要先识别现实中已经发生了什么，再决定下一步是否合法。
跨日任务为什么不能从提示词重新开始
一次搜索词迁移可能在周一发现候选词，周二等待完整报告，周三由投手批准，周四创建精准 target，随后对原自动投放结构进行否定隔离，再观察一周。若进程在创建 target 后崩溃，新的运行不能仅根据原提示词“重新执行迁移”。它必须知道创建是否已经成功、target 的远端 ID 是什么、原结构是否已否定，以及审批在当前配置下是否仍有效。
重试与恢复岔路牌把本节的判断压缩成可检查的关系：区分再次请求和恢复业务现场。人物动作对应执行责任。
模型上下文不适合作为这类事实的唯一载体。上下文可能被压缩、会话可能被清理，模型也可能把“计划创建”误写成“已经创建”。Effective context engineering for AI agents讨论了上下文选择与压缩，但上下文工程并不能取代事务记录。对外部副作用，系统需要机器可判定的状态，不是更好的摘要。
Measuring AI Ability to Complete Long Tasks把任务长度与可靠完成率联系起来，并明确讨论外部有效性限制。对投放系统的合理推断是：步骤越多、等待越长，错误累积与环境变化越重要；它并不证明某个模型可以连续管理广告账户。Harness 仍要把任务切成可以停止、恢复和验证的单元。
跨日任务的恢复入口因此不是“把上次聊天发给模型”，而是读取任务合同、最新检查点、执行账本和当前远端状态，计算差异，再构造本轮所需上下文。模型看到的是经核验的现场，而不是一段可能过期的叙述。
检查点保存业务承诺，不保存全部思维过程
检查点不是对话备份。它应保存足以继续工作的最小业务状态：task id、阶段、对象范围、证据快照、配置基线、待完成动作、批准版本、风险余量、下一次唤醒条件和已知冲突。模型的完整思维文本既难以验证，也不应成为恢复所必需的依赖。
跨日调价检查点栈桥把本节的判断压缩成可检查的关系：把长任务切成可续跑的稳定节点。人物动作对应执行责任。
对搜索词迁移，检查点可以位于 EVIDENCE_READY、APPROVED、TARGET_CREATED、SOURCE_ISOLATED 与 OBSERVING。每个阶段都有进入证据。例如 TARGET_CREATED 必须包含远端 target ID 和回读结果，不能因为模型曾调用创建工具就进入。SOURCE_ISOLATED 必须证明否定表达式已生效，并记录可能受影响的其他查询。
对广告位调价，检查点保存基础 bid、三类 placement adjustment、动态竞价策略、campaign budget、版本时间和预计有效竞价上界。只保存“Top of Search +20%”会丢失乘法链上下文；恢复时若基础 bid 已被人工调整，相同的 20% 已不是原批准动作。
Effective harnesses for long-running agents建议用初始化阶段和进度制品帮助后续会话接续。应用到 Amazon Ads 时，进度制品必须由确定性状态与远端回读生成，模型只负责解释和提出下一步，不可自行宣布阶段完成。
重放重建决定，但不重复外部副作用
工作流重放的目标，是根据历史事件重新得到相同的内部状态。它要求决定逻辑在相同输入和历史下保持确定性：不能在重放时重新读取当前时间、随机数或最新广告配置，并假装它们属于过去。所有非确定性输入都要作为事件记录，外部 API 调用则被隔离为 activity 或等价副作用单元。
Temporal Python SDK 的变更日志记录了 2025 年 7 月对 OpenAI Agents 集成的发布条目，可用于核验框架连接的时间点；它不意味着集成自动获得广告业务幂等性。工作流能够重放，仍需开发者把 Amazon 报告请求、target 创建和配置更新放在正确边界，并为结果建立对账逻辑。
重放过程中，若历史记录显示某个报告请求已经提交，系统复用 request id 并轮询状态，而不是申请第二份语义相同但身份不同的报告。若历史显示提案已经批准，系统仍要检查批准绑定的配置版本是否与当前远端一致；重放历史不等于冻结现实。
版本升级也会影响重放。代码改变后，旧事件历史可能走到不同分支。生产 Harness 需要 workflow version 或兼容分支，使在途任务按旧语义完成或迁移。不能把新版本“更聪明的”策略直接应用到历史任务，否则同一事件会产生不同动作，审计链失去一致性。
幂等键要标识业务意图，而不只是一次请求
随机 request id 只能区分网络调用，不能识别两次调用是否代表同一业务意图。幂等键应由稳定字段构成，例如 task id、proposal version、动作类型、对象身份和目标状态的哈希。相同提案重试得到同一键；目标值或对象变化则产生新键。这样执行器才能判断是重复提交还是新的批准动作。
幂等钥匙铸造台把本节的判断压缩成可检查的关系：由对象、期望差异与版本生成动作身份。人物动作对应执行责任。
Amazon Ads 不同接口对幂等、批量和错误返回的支持并不相同，Amazon Ads API 介绍只说明程序化访问范围，不能被解读为所有写操作具有端到端 exactly-once 保证。Harness 必须在适配器层声明每种动作的语义：可安全重试、需要先查询、批量可能部分成功，或失败后必须人工对账。
更新 bid 通常可以被理解为“使对象达到目标状态”，执行前读取当前值、执行后回读目标值；创建 target 则可能产生重复对象，需要使用自然业务键搜索既有实体，并检查 match type、campaign 和 state。否定隔离更危险，因为相似表达式可能不是同一对象，不能仅凭文本相等去重。
τ-bench强调 Agent 在多轮工具交互中遵守策略的重要性。对于幂等性，策略应由执行器强制，而不是提示模型“请勿重复”。模型可能因上下文缺失或工具超时再次提议相同动作，账本必须在调用 API 前阻断未经识别的重复。
三态结果比成功与失败更接近现实
网络调用后的状态至少有 SUCCEEDED、FAILED 和 UNKNOWN。明确的参数校验失败可以进入 FAILED；回读确认目标状态可以进入 SUCCEEDED；超时、连接中断或响应解析失败则先进入 UNKNOWN。未知不是失败的别名，因为远端可能已执行。把未知直接重试，是重复副作用的主要来源。
远端未知态三色灯把本节的判断压缩成可检查的关系：区分成功、失败和无法确认。人物动作对应执行责任。
对账器针对动作类型选择读取方式。bid 更新按对象 ID 读取当前配置；target 创建按 campaign、表达式和 match type 搜索候选并核对创建时间；预算规则要同时检查规则对象和 campaign 的实际 budget 状态。若当前值等于目标，登记成功；等于基线且没有远端迹象，才允许受控重试；出现第三种值，说明并发修改或部分应用，任务转冲突状态。
批量接口需要逐项状态。十项动作中七项成功、两项明确失败、一项未知，不能把整个批次标成失败并全部重放。每个子动作拥有独立幂等键与 receipt，父批次只聚合进度。后续补偿也只作用于已经成功且仍符合恢复前提的对象。
OWASP 的 Agentic AI 资料提醒工具调用和权限组合会扩大风险。三态模型把不确定性显式保留下来，使系统在证据不足时停下，而不是让自主循环用更多调用掩盖未知。
检查点恢复前必须重新读取广告现场
跨日等待期间，账户不会静止。投手可能在控制台调整预算，Amazon 的 budget rule 可能触发，库存可能下降，价格与 Featured Offer 可能变化。恢复器首先读取当前现场，并与检查点基线比较。只有差异为空或处于批准允许范围，原任务才可以继续。
Amazon Marketing Stream 指南可用于理解近实时事件进入监控的产品面，但页面持续更新，历史文章不能据当前页面证明某日版本细节。系统使用流式信号发现异常，同时仍以配置 API 回读和稳定报告作为最终证据。事件缺口、重复和迟到必须进入质量状态。
若 campaign budget 在审批后被人工提高，原 placement 提案的最大损失可能扩大；即使 target 的目标值没有变化，批准也应失效。若 ASIN 库存进入警戒区，原本计划加价的任务转为 SUSPENDED_BY_RETAIL_STATE。恢复不是忠实执行旧计划，而是在旧承诺和新现实之间重新核验。
当前配置差异要分类：本任务已知动作、平台规则动作、人工动作、其他自动化动作和来源未知。来源未知时不允许覆盖。没有操作者信息的系统，也至少要通过快照差异与时间界定并发变化，要求人工确认所有权。
搜索词迁移需要一个小型 Saga
搜索词迁移包含多个外部步骤：确认目的结构、创建精准 target、回读 target、在来源结构添加否定隔离、回读否定、开始观察。它不是一个数据库事务，不能依赖单次原子提交。更合适的做法是小型 Saga：每个步骤有完成证据和必要的补偿策略。
决策输入封存箱把本节的判断压缩成可检查的关系：保留报告版本、指标口径与批准证据。人物动作对应执行责任。
如果精准 target 创建成功而否定隔离失败，立即删除新 target 未必是正确补偿，因为它可能已经获得流量，删除也可能不可逆或失去历史。系统可以先暂停进一步自动扩量，标记流量重叠，重试可安全的隔离步骤，超过窗口再由人决定保留、暂停或合并。补偿的目标是恢复可控业务状态，不是机械反向调用。
迁移还必须处理归因跨界。来源 target 在迁移前产生的点击可能在迁移后形成订单，若直接按报告日期比较新旧结构，会把历史点击贡献错误归给当前结构。检查点保存动作生效时间，评测按 click/cohort 或可用归因语义区分过渡期，不在数据无法识别时伪造精确拆分。
Building effective agents对 workflow 和 agent 的区分有助于这里的设计：迁移主干是预定义、可校验的工作流，模型只在目的结构选择、例外解释和冲突处理处参与。这样既利用语义判断，也避免让恢复路径依赖自由规划。
预算与广告位调整要用同一份风险账本
广告位倍率提高会加快预算消耗，预算规则又可能在事件或表现条件下提高日预算。若两个自动化系统分别优化，各自都可能在局部约束内，却共同扩大最大损失。风险账本需要按 profile、portfolio、campaign 和 ASIN 聚合所有在途提案的上界，批准前计算组合影响。
安全重放轨道把本节的判断压缩成可检查的关系：从最近确认状态继续而不是从头复制动作。人物动作对应执行责任。
每次调价记录基础 bid、placement adjustment、动态竞价策略和 campaign budget 的完整快照。有效竞价不是单个字段，恢复也不能只回滚一个字段。若观察期内 budget rule 合法触发，回滚 placement 时要保留还是撤销预算变化，必须由任务合同预先定义，不能由模型事后猜测。
New tools and features in the Responses API在 2025 年发布 background mode 等能力，说明长耗时调用的产品支持在增强；Microsoft Agent Framework 的发布说明也将 Agent 与 workflow 放在同一运行框架讨论。两者能帮助实现等待和编排，却不负责定义 Amazon Ads 的组合风险。
风险账本必须来自广告主自身的预算、利润、库存和授权策略。服务商常见的固定 ACOS、点击或订单阈值只能作为候选方法，不能替代账户目标。缺少上限时，Harness 可继续分析和生成草案，但写操作保持关闭。
观察期也是可恢复工作流的一部分
动作回读成功以后，任务进入 OBSERVING，而不是结束。观察期保存下一次检查时间、归因成熟规则、主要指标、护栏指标、控制范围和停止条件。worker 可以退出，计时器到期后由任何可用实例恢复任务，无需维持一个长期会话。
恢复观察时重新申请或读取报告，比较数据水位线与前次快照。若销售仍在明显回填，任务继续等待；若库存、价格或促销发生重大变化，标记实验受干扰；若 spend 突破风险带，触发预批准的降级提案。所有判断写入事件历史，使后续评审能够区分策略无效、数据未成熟和外部环境改变。
How Does Time Horizon Vary Across Domains?讨论不同任务域中的时程差异，适合提醒团队不要把软件任务测量直接套到广告运营。Reddit 对 Durable Execution 的讨论与 Google Cloud 关于 ADK/A2A 的社媒内容只作为社区与厂商传播样本，不承担系统正确性的证据责任。
观察完成后，独立评审器根据冻结目标决定 KEEP、ITERATE 或 REVERT_PROPOSED。不能让执行 Agent 因已经投入大量步骤而降低成功门槛。任务历史越长，越需要让终止条件保持稳定。
验证恢复能力要主动制造故障
正常路径跑通不能证明 durable。测试应在每个副作用边界前后终止进程，制造响应丢失、限流、过期凭据、部分成功、重复调度和人工并发修改。恢复后核对远端对象数量、最终配置、账本状态和审批使用次数，确认没有重复创建、越权覆盖或遗漏补偿。
并发修改防撞器把本节的判断压缩成可检查的关系：发现人工改价后停止覆盖。人物动作对应执行责任。
回放测试使用冻结事件历史，验证同一代码版本产生相同内部决定；版本兼容测试用旧历史运行新代码，确认显式版本分支有效；对账测试注入 UNKNOWN，验证系统先读取而非直接重试。业务测试则检查搜索词迁移的流量隔离和广告位调价的组合风险。
可观测性至少关联 workflow id、task id、proposal version、idempotency key、Amazon object id、report request id 和 evidence snapshot。日志中不得记录凭据或不必要的顾客搜索词明文；审计需要身份和结果，不等于无边界收集数据。
一个合格恢复测试的结论不是“任务最终跑完”，而是“每项外部副作用最多形成一个被批准的业务结果，所有未知结果经过对账，所有并发变化被发现，最终配置与账本一致”。这比框架自带 retry 次数更能说明系统是否可靠。
测试还要区分可用性与一致性。报告服务短暂不可用时，系统可以延迟周期并告知下一次唤醒，这是可用性下降；为了按时完成而使用旧证据调价，则是一致性破坏。前者会让优化变慢，后者会让系统无法解释为何行动。投放 Harness 应优先保护对象、批准和证据一致，再通过缓存、退避与容量治理改善完成时间。
恢复演练需要固定节奏，而不是等事故发生。团队可定期选择在途任务，在报告等待、审批等待和写后回读三个位置终止 worker，检查接管实例是否得到相同现场判断。演练记录进入发布门禁，任何新增写工具都必须补充相应未知结果与部分成功案例。
只有演练能够重复得到一致账户状态，团队才有依据扩大任务时长和写入范围。
结语：可靠执行先尊重已经发生的事实
Amazon Ads 跨日调价的困难不在于等待时间长，而在于等待期间存在外部变化，写操作存在不确定结果，多步骤存在部分成功。重试解决短暂失败，无法回答远端是否已经执行；提示词恢复对话，无法证明账户现场；只有检查点、事件历史、幂等账本和对账共同工作，任务才有可恢复语义。
恢复账本全景剖面把本节的判断压缩成可检查的关系：把检查点、命令、响应与回查串成证据链。人物动作对应执行责任。
系统应把搜索词迁移组织为可补偿步骤，把广告位和预算放进同一风险账本，把观察期作为可唤醒状态，并在恢复前重新读取广告现场。模型仍然负责解释复杂证据和提出候选动作，确定性运行时负责识别历史、保护批准边界并验证副作用。
不要问“失败后能否再跑一次”，要问“再启动时能否准确知道哪些已经发生、哪些仍可继续、哪些必须停止”。能回答这三个问题，跨日优化才真正具备恢复能力。