3.3 复核与重试：循环的刹车与倒车

3.3 复核与重试：循环的刹车与倒车

本节摘要：复核拍回答两个问题：这步成没成、任务还打不打。判成败靠模型对照任务单的自我评估，控制损耗靠步数上限与任务粒度。本节建立"跑不完"与"跑不对"的失败分类法，给出步数经济学和粒度拆解两件工具——长任务的账本从这里学起。

先分清两种死法

任务失败无非两种死法。跑不完：循环还在转，步数烧完了，max_steps 触顶强制收兵——死因多为绕圈或任务太肥。跑不对：循环体面地结束了，还报告"任务完成"，但结果是错的——死因在复核失察或任务单模糊。两种死法处方完全不同，混着治就会闹出"任务跑不完就把步数调大"的笑话（步数调大只是让它烧更多钱绕更多圈）。本节承接 3.2 的排查顺序，把第三拍之后的事管起来。

复核怎么判成败

每一拍末尾，模型收到一个复核问题：对照任务单，当前页面算不算达成？评估结果写在 3.2 看过的"评估行"里。这套机制的有效性直接依赖任务单的可判定性：

# 不可判定：什么叫"逛一逛"？复核拍无法收敛，注定烧到步数上限
task_bad = "去旅游站逛一逛"

# 可判定：产出有明确形态，复核拍能一锤定音
task_good = "找出五一假期北京去上海最便宜的高铁二等座价格，只回答价格数字"
​

复核还有一层隐性收益：自我纠错。模型发现自己点错按钮、填错框后，多数情况下下一拍会修正——这是智能体相对脚本的隐性优势，脚本错一步全盘错。但自我纠错不等于无限纠错，绕圈（同一动作反复出现）就是纠错失败的标志，此时需要人为干预。

步数经济学

max_steps 不是保险丝，是钱包。每一步都是一次模型调用加一次页面交互，步数预算要按任务真实复杂度给：

result = agent.run(max_steps=6)    # 短任务：导航加一两次交互
result = agent.run(max_steps=15)   # 中任务：搜索加翻页加提取
result = agent.run(max_steps=30)   # 长任务：多页遍历加汇总，慎用，先拆解
​

判定预算合不合理，看跑完后的轨迹分布：正常任务的动作行应该密在前半程、评估行在后半程收尾；若动作行匀速铺满全程最后触顶，说明要么任务该拆（见下），要么站点路径和预想的差太远（回 3.1 查情报）。

取回轨迹并判别死法，是排错的起手式：

# 任务结束后检查：跑到终点了，还是被步数掐死的
history = result.history() if hasattr(result, "history") else []
print("总步数：", len(history))
final = history[-1] if history else None
if final is not None and getattr(final, "is_done", True):
    print("自然完成，答复：", result)
else:
    print("触顶终止，最后一步在干什么：",
          getattr(final, "model_actions", "无记录"))
​

预期输出二选一：自然完成，答复：…… 或 触顶终止，最后一步在干什么：点击元素 索引 12——后者告诉你它死前在纠缠哪个元素，那就是 3.2 黑匣子的回放键。

粒度拆解：把肥任务切成小仗

长任务的正解不是加大预算，而是切分。命令台的原则：一次战役打不下来，就拆成几场战斗，每场有自己的胜利标准。以"把某站前五页商品信息汇总成表"为例：

# 反面教材：一单打包五页，中途任何一次情报失手都要从头再来
task_fat = "翻五页，把每页商品名和价格都记下来，汇总成表"

# 正解：一页一仗，页内自带产出，仗仗有收成
page_tasks = [
    f"打开列表页第{n}页，提取本页所有商品的名称与价格，"
    "按'名称 价格'逐行列出"
    for n in range(1, 6)
]
for t in page_tasks:
    r = Agent(task=t, llm=llm, browser=browser).run(max_steps=8)
    print(r)   # 每页独立交割，失败只重打这一页
​

拆解还有个隐藏红利：每场战斗的任务单短而清晰，决策拍的输入更干净，单拍正确率反而上升。宁打十场小仗，不打一场消耗战。

复核的边界

也要说实话：复核拍是模型自评，不是审计。页面内容本身可能骗它（弹窗伪装成成功提示），任务单歧义会直接传导成评估歧义。关键业务不能裸依赖自评——第 4 章的自定义动作可以在复核链路上加程序化校验（比如提取结果跑一遍格式检查），第 6 章会把它升级成"不可信输入"的防线。此处记住结论：自评管方向，程序校验管底线。

预算设定的经验公式

给一个能直接用的估算式：基础步数 = 导航 1 拍 + 关键操作数 × 1.5 + 提取 2 拍，再上浮一半当余量。以 5.1 的比价任务为例：导航 1 拍，关键操作（搜商品、切店铺）约 4 个算 6 拍，提取 2 拍，合计 9 拍，上浮后给 13 到 14。别问"为什么不干脆给 30"——预算松一倍，绕圈的任务就能多绕一倍才死，账单跟着翻倍。预算是闸门，不是摆设。

顺带回答一个衍生问题：**重试的预算怎么给？**粒度拆解之后的重试只重打失败的一仗，预算与首跑相同；永远不要在同一个 Agent 实例上原地续跑——它的历史轨迹里已经塞满失败上下文，接着跑只会顺着错误惯性滑下去。正确姿势是起一个全新实例，带着修正过的任务单重新出发。

复核失察的两个补丁

复核是模型自评，下面两个补丁能明显提高它的查全率。补丁一：任务单里预写验收特征——"回答里必须包含具体数字，若无数字视为未完成"，给复核一个可机检的锚点。补丁二：产出落地后跑 6.2 的程序化校验器，让格式错误、常识错误（价格为零、日期在过去）在入库前被拦下。自评管方向、程序管底线，两道都上才叫闭环。

设预算前的三个自问

公式之外，动手前先自问三个问题，答完预算自然浮出水面：这仗有几个关键动作？（决定基础盘）哪几步可能要重来？（决定余量给谁——易错步骤多的任务余量要倾斜）失败了损失是什么？（决定预算的松紧——只读任务失败零损失，预算给紧点逼自己优化任务单；写操作任务宁松勿紧，也别在预算内硬挤）。三问答完再对照经验公式校验，两套算法打架时，以保守的那个为准——预算少给省的是钱，多给省的是命（复查时间）。

四拍打完，原理章收官。第 4 章开武器库：每一件武器都标明作用于哪一拍，带着"拍"的坐标去领装备。