Amazon Ads 优化的目标常以周、月或销售季表达，输入却以小时、天和异步报告到达。预算上午耗尽需要尽快处理，搜索词归因需要等待，库存风险可能在活动中途出现，利润和退款又比广告销售更晚成熟。若把这些事件都塞进一次超长 Agent 会话，系统只是延长了上下文，并没有获得长期运营能力。
METR 的任务时程研究尝试用人类完成任务所需时间衡量 AI 能力，并反复说明外部有效性限制；Towards a Science of AI Agent Reliability则把重复试验与可靠性分布置于单次成功之上。两类研究共同提示：长时程不是 token 数量，而是系统跨越更多步骤、反馈和环境变化后仍保持目标与约束的能力。
对 Amazon Ads 更实用的设计，是把长期目标拆成一组可续跑运营周期。每个周期有清晰输入、水位线、候选动作、批准、执行、观察和退出条件；周期之间通过外部状态与证据包衔接，而不是依赖前一个模型会话仍然存在。长期自治不等于模型一直在线，而是模型退出后，业务承诺、已发生动作和下一次唤醒条件仍然准确。
先区分三种经常被混为一谈的“长”
第一种是长上下文：一次推理需要读取大量 campaign、search term、ASIN 和策略资料。第二种是长耗时执行：任务包含异步报告、限流等待或人工审批，墙上时间很长，但每次计算可能很短。第三种是长时程运营：系统要在数周内反复观察、行动和复盘，同时面对价格、库存、竞争与目标变化。三者需要不同技术，不能用更大的上下文窗口统一解决。
超长会话膨胀气囊把本节的判断压缩成可检查的关系：揭示把长期任务塞进上下文的失控。人物动作对应执行责任。
长上下文主要处理选择和压缩。Effective context engineering for AI agents讨论如何让有限上下文保持高信号。长耗时执行主要处理 durable workflow、检查点和恢复，Temporal Python SDK 变更日志与 OpenAI Agents SDK 的运行文档提供实现线索。长时程运营还要额外处理业务目标版本、归因反馈、风险额度和策略交接。
如果系统只解决第一种，它能读更多报告，却会在进程重启后丢状态；只解决第二种，它能恢复调用，却可能忠实执行已经过期的策略；只有第三种明确目标和反馈周期，前两种能力才有业务方向。
Amazon Ads 场景中可以用一个判断题识别：如果本次会话永久消失，明天的系统能否只靠任务状态、远端配置和证据包继续，并且知道哪些条件已经失效？不能，就不是可续跑运营。
用运营节奏代替永不结束的 Agent 循环
投放系统需要多种时钟。小时级节奏监控 spend、CPC、预算耗尽和 Marketing Stream 异常；日级节奏检查报告完整性、target 与 placement 结构；周级节奏评审成熟归因、利润、搜索词迁移和实验结果；月度或活动节奏重新分配预算、复核商品组合与策略目标。
运营周期分段转盘把本节的判断压缩成可检查的关系：拆开观察、判断、批准、执行与复盘。人物动作对应执行责任。
这些节奏不是四个互不相干的 Agent。它们共享一个运营状态模型，但拥有不同权限。小时级循环只允许风险抑制和告警，不因一小时无订单就大幅降价；周级循环可以在成熟数据上提出结构调整；月度循环可修改预算组合，但需要更高批准。快循环不能推翻慢循环定义的目标，慢循环也不能忽略快循环发现的风险。
Amazon Marketing Stream为更及时的广告信号提供产品入口；统一报告发布说明则说明 Amazon 在 2026 年继续改善跨账户、跨广告产品的分析入口。前者更快、后者更完整，都不等于最终经营事实。系统仍要声明事件缺口、报告水位线、归因成熟和与 Seller/Vendor 结果的对账状态。
运营周期应能自然结束。一次小时风险检查完成后关闭；一次周度搜索词评审在提案入队后关闭；等待归因的实验进入带唤醒时间的状态，而不是保持模型线程。有限周期比无限循环更容易审计、限权和计费。
周期之间需要清晰的优先级，而不是谁先触发谁覆盖。风险周期可以暂停正在观察的放量实验，却不能重写实验目标；库存周期可以收紧竞价上限，却不能把销售下降解释为策略失败；月度预算周期可以调整 portfolio 额度，但必须识别仍在归因窗口内的 campaign。冲突由状态机升级到共同 owner，不能让两个 Agent 互相调回配置。
运营日历还要尊重 marketplace 时区、促销日和报告截止。美区自然日与团队办公时间不同，按服务器 UTC 零点切割会把同一购物时段拆进两个周期。大促前后的流量结构也不同，不能让常规周度策略在活动中途机械恢复基线。每个周期保存业务时区、活动标签和目标版本，后续才有资格比较。
当多个周期共享数据时，复用的是经过校验的 evidence snapshot，而不是各自重新抽取一份“最近七天”。这样预算、搜索词和库存任务看到相同截止时间与配置版本；若某任务需要更新数据，它创建新快照并显式标记依赖任务是否失效。共享事实减少争议，独立决策合同保留职责边界。
一个实用的调度器不追求把每个 campaign 都交给模型。确定性检查先筛出数据缺口、预算异常、库存红区和达到样本门槛的候选，仅把需要语义判断或冲突处理的少数任务交给 Agent。没有候选时周期正常结束，不生成空洞建议。这样模型成本随需要判断的问题增长，而不是随账户对象总量线性增长。
周期负载也要受控。大促期间同时出现大量异常时，系统按最大潜在损失、证据新鲜度和人工可处理容量排队；低风险优化可以延后，高风险抑制优先。排队本身写入状态，超时后重新读取现场，旧提案不因等待时间长就自动获得更高优先级。
运营责任不能完全交给调度器。每类周期要有业务 owner、技术 owner 和人工接管渠道；任务连续多次因相同证据缺口结束时，应进入数据治理待办，而不是继续消耗模型调用。系统把“没有动作”区分为运行正常、没有机会、证据不足和被风险阻断，运营者才能判断应该等待、补数还是修改策略。
周期效果也按层评审：调度层看准时启动和正常结束，决策层看证据与提案质量，执行层看远端一致性，业务层看成熟结果。某周期晚启动但没有越过业务窗口，未必影响结果；准时运行却使用错误时区，反而是更严重的失败。时间指标必须与业务截止相连。
这种分层还能明确责任：调度延误交给运行平台，口径错误回到数据治理，越权动作由 Harness 处理，策略假设则由投放 owner 复核，不把所有问题统称为模型失败。
周期入口是一份任务合同，不是一句目标口号
“降低 ACOS”“提高销售”无法指导长期执行。合同要说明 profile、marketplace、portfolio、campaign 和 ASIN 范围，目标指标与版本，广告前贡献口径，数据截至时间，允许动作，最大单次变化、周期风险额度、审批层级和终止条件。目标改变时创建新版本，并明确旧在途任务怎样收尾。
预算 pacing 周期可以定义：在不突破 portfolio 月度上限、ASIN 库存覆盖和最大可承受 CPC 的前提下，让日内累计 spend 接近目标曲线；快速环只处理偏离风险带，慢速环在成熟销售后校准曲线。合同不承诺每天花完预算，也不把预算利用率当成唯一成功指标。
库存联动周期可以定义：库存进入黄区时禁止新增放量，进入红区时仅允许预批准的降级动作；库存恢复后先检查价格、Featured Offer 和配送状态，再逐步恢复。这里的状态来自零售事实，不由 Agent 从广告点击下降中猜测。
合同还要规定不可识别问题。若报表不能把某搜索词与具体 placement 联合观察，Agent 不得生成精确位置收益；若利润数据缺失，系统不能把目标 ACOS 当成净利润边界。长期系统最重要的能力之一，是在条件不足时正确停止。
外部状态要能回答“现在进行到哪一步”
可续跑状态至少包含目标版本、当前周期、最新证据水位线、配置快照、在途提案、批准与有效期、执行 receipt、观察窗口、风险余额和下一次唤醒。状态应存于事务数据库、durable workflow 或等价持久层；模型上下文只取本轮所需视图。
快慢双时钟齿轮组把本节的判断压缩成可检查的关系：协调小时级监控与归因成熟后的决策。人物动作对应执行责任。
LangGraph和它的 interrupt 机制展示了图状态、检查点与人机暂停的实现方式；Microsoft Agent Framework 发布说明把 workflow 与 Agent runtime 结合。选择框架前应先写状态合同，否则团队容易把框架 checkpoint 当成完整业务状态。
状态分事实与解释。事实包括 Amazon 对象 ID、配置值、报告批次、审批身份和远端回读；解释包括为什么建议调整、风险是什么和下一步假设。恢复时先验证事实，再让模型重建必要解释。这样即使更换模型或摘要方式，历史动作仍可复盘。
状态还有所有权。人工在控制台修改 campaign 后，系统要记录外部变更并判断是否终止自动周期。多个优化器不能默认共享控制权；每个对象在某个时间段由哪个策略管理，需要显式租约或控制标记。
一次预算周期如何暂停和继续
周期从读取目标曲线、campaign budget、当日 spend、时区和剩余时段开始。系统先校验 Marketing Stream 或报告数据是否连续，再计算偏离。偏离在容忍区间内则不动作；超出区间时生成受约束候选，例如小幅降低竞价或调整预算，但候选必须经过库存、利润和组合风险检查。
可暂停任务泊位把本节的判断压缩成可检查的关系：让缺数据、待批准和库存风险进入等待态。人物动作对应执行责任。
若动作需要人审，周期保存提案与当前快照后暂停。数小时后批准到达，恢复器重新读取 spend、budget 与库存。若白天流量已经使预算接近目标，原加预算建议自动失效；若人工已经改过配置，提案进入冲突。批准是对某个基线差异的授权，不是对未来任意状态的长期许可。
执行后周期回读配置，并安排两个唤醒点：近期检查预算是否异常耗尽，较晚检查归因是否成熟。worker 在两次检查之间完全退出。近期触发风险时可以执行预批准的降级；较晚数据仍回填时继续等待，而不是为了按时结案将未成熟销售当成最终结果。
这个过程看起来比一个自主循环更保守，却更接近运营。它允许系统在证据不足时不动，在环境改变时废止提案，在反馈成熟后再评价。持续运行的不是模型，而是业务状态机。
搜索词策略应跨周期保留身份与归因边界
搜索词从发现到迁入精准结构，至少经历发现、候选、证据成熟、意图审查、创建、负向隔离和观察。发现周期可以每天运行，结构迁移周期通常更慢。两者通过稳定 query identity、source target、advertised ASIN、marketplace 和证据版本衔接，不能只传一段“这个词表现不错”的摘要。
外部记忆货架把本节的判断压缩成可检查的关系：把事实、状态和证据移出模型上下文。人物动作对应执行责任。
迁移后的观察要处理过渡归因。原 target 在生效前获得的点击可能在迁移后转化，新精准 target 又需要冷启动。周期状态保存 action effective time 和归因窗口，评审时把不可归属过渡段单独标记。没有可识别数据时，不把销售变化强行归功于迁移。
长期系统还应防止策略漂移。模型可能在每次恢复时重新解释“优质搜索词”，导致门槛缓慢变化。候选规则与例外决策都要版本化；规则升级只影响新周期，在途任务按明确迁移策略处理。这样才能比较不同版本的命中率、误否率与增量贡献。
τ-bench说明多轮工具任务中策略遵循本身就是评测对象。对搜索词运营，可测试 Agent 在等待、冲突和部分成功后是否仍保持原意图，而不是只测它第一次能否选对关键词。
长时程上下文按需重建，不做无限日志回灌
把全部历史消息、报告和 trace 每次回灌模型，会提高成本并稀释关键约束。更可靠的上下文由四部分组成：当前任务合同、已核验状态摘要、与本轮决策相关的证据切片、允许工具与输出 schema。历史细节通过引用 ID 按需读取，不直接塞进主提示词。
跨周期目标接力棒把本节的判断压缩成可检查的关系：保留策略意图而不复用过期动作。人物动作对应执行责任。
摘要必须区分事实、决定、假设和未决问题。事实只能来自回读或验证数据；决定包含批准人与版本；假设明确可被后续证据推翻；未决问题带责任人和截止条件。模型生成摘要后，由确定性程序核对关键字段是否与状态一致，不能让流畅文案覆盖冲突。
Harness design for long-running application development和长运行 Harness 实践都强调跨会话的进度制品与环境反馈。把这一思路用于广告，需要进一步加入数据成熟、远端配置和审批约束；软件仓库中的任务清单不能直接等价于投放账本。
上下文重建也提供模型可替换性。不同模型读取同一份合同与状态视图，可以离线比较候选判断；外部状态不随模型供应商变化。长时程能力因此更多属于系统架构，而不是某个会话模型的记忆长度。
用状态迁移评测长期可靠性
单次问答准确率无法覆盖跨日运营。评测场景应按时间释放信息：第一天只有点击与 spend，第三天部分订单回填，第五天库存下降，第七天人工调整 budget。Agent 每一步只能看到当时可用数据，测试它是否等待、是否更新提案、是否识别冲突，以及是否在风险触发时停止。
Demystifying evals for AI agents区分结果和过程评测；Time Horizon 1.1以及时程结果限制说明提醒读者关注任务集与测量边界。Amazon Ads 评测需要自建领域环境，不能用代码 benchmark 分数替代投放安全性。
指标至少包含周期完成率、错误状态转换率、未经批准写入率、重复副作用率、冲突发现率、证据成熟遵守率、风险停止正确率和人工接管时间。收益指标仍要观察，但不能抵消越权或重复写入。一次高回报的失控操作不是可靠成功。
每个场景重复运行，报告分布而非最好一次。模型非确定性、工具波动和状态竞争都会使同一任务产生不同轨迹。系统上线门槛应落在最差风险和稳定性上，而不是演示录像。
运营治理决定何时结束、交接和降级
长期 Agent 容易被描述为“持续优化”，但没有退出条件的持续就是失控。每个周期应在达到目标、证据不足、风险耗尽、对象冲突、权限过期或人工接管时结束。结束后生成简洁交接包：当前状态、已发生动作、未成熟反馈、剩余风险和建议复核时间。
止损与升级信号塔把本节的判断压缩成可检查的关系：定义异常阈值、人工接管和任务终止。人物动作对应执行责任。
降级路径应预先定义。流式数据中断时退回日级报告并关闭快动作；利润数据过期时只做风险抑制，不做放量；审批服务不可用时保留草案，不提升权限；模型不可用时确定性监控仍能告警和执行已批准的安全动作。长时程系统的韧性来自这些退路。
Long-Running Agents和 X 上关于 managed agents 的讨论可作为工程趋势观察；Reddit 对 Agent reliability 的讨论可以帮助发现实践者关心的问题。它们都不承担产品能力和效果数字的证明，关键结论仍回到论文、官方资料与账户实验。
交接不应要求接手者阅读全部 trace。系统提供当前事实与重要历史索引，必要时下钻。人工可以终止任务、缩小范围或创建新合同，Agent 无权以“保持连续性”为由拒绝新的业务决定。
结语：持续的是运营合同，不是模型会话
Amazon Ads 长时程任务的本质，是目标与反馈分布在不同时间尺度，期间环境和控制权持续变化。更长上下文可以帮助一次判断，background run 可以等待一次调用，durable workflow 可以恢复一次流程；真正的运营能力还需要版本化目标、外部状态、多时钟节奏、归因成熟和清晰退出。
耐久运营闭环轨道把本节的判断压缩成可检查的关系：展示多周期累积证据后再调整投放。人物动作对应执行责任。
把预算 pacing、库存联动、搜索词迁移和广告位优化拆成有限周期，每个周期都能暂停、重读现场、继续或结束。模型只在需要语义判断的节点运行，状态机和证据包负责跨时间保持承诺。这样既能利用 Agent 的适应性，也不会把账户托付给一个无法解释的无限循环。
长时程系统的验收标准不是“会话坚持了多久”，而是任意时刻停止后，下一次运行仍能准确知道目标、现场、风险和合法下一步。