每次迭代保留上一版脚本：AI 改错了能回退，自动化是不断迭代不是一次性魔法

一、问题的起点：为什么 AI 自动化天然需要回退

1.1 非确定性是模型的原生属性，不是 bug

大语言模型的推理过程带有采样随机性。即便把 temperature 设为 0，由于浮点运算顺序、批处理并行、硬件差异等因素，同一输入在不同时刻仍可能产生不同输出。OpenAI 在其 API 文档中明确提示，即使 temperature=0 也“不能保证完全确定性”（OpenAI API Reference, 2024）。这意味着：任何依赖模型生成脚本的自动化流程，其产物本身就是概率性的。

传统软件工程假设“相同输入产生相同输出”，因此可以用单元测试锁定行为。AI 自动化打破了这个假设。当模型今天生成的爬虫脚本能跑通、明天生成的版本却因为选择器变化而失败时，如果没有保留上一版脚本，团队将陷入“改一次坏一次”的困境。

1.2 真实世界的失败模式：三类不可逆损伤

在自动化实践中，AI 改错脚本带来的损伤大致分为三类：

• 数据损伤：脚本错误导致重复写入、覆盖生产数据、误删记录。例如一个“去重后入库”的脚本被 AI 改成“直接入库”，可能造成数据库唯一约束冲突或脏数据扩散。
• 外部副作用损伤：脚本向第三方系统发送了错误请求，如重复下单、误发邮件、触发风控。这类副作用往往无法通过本地回滚消除。
• 流程状态损伤：长流程执行到一半失败，已完成的步骤无法撤销，导致状态不一致。典型如“扣款成功但发货失败”。

本文评述：三类损伤中，数据损伤和流程状态损伤可以通过检查点与幂等设计缓解，而外部副作用损伤只能靠“事前防护 + 事后补偿”处理。这决定了回退机制必须分层设计，而非单一手段。

1.3 业界共识：从“一次生成”转向“持续迭代”

2024 年以来，主流 AI 工程实践普遍转向“迭代式开发”。LangChain 团队在 LangGraph 文档中提出“持久化执行”（Durable Execution）概念，强调工作流应在每个节点保存状态，以便失败后从检查点恢复（LangChain, 2024）。Temporal 平台则把“确定性重放 + 状态持久化”作为核心卖点，被广泛用于 AI Agent 编排（Temporal Documentation, 2024）。

这些工具的共同信号是：自动化系统正在从“无状态脚本”进化为“有状态、可回退的工作流”。AI 只是加速了这个进程，因为模型的不确定性让回退从“可选优化”变成了“必需能力”。

延伸阅读：LangGraph 官方文档中关于持久化与检查点的说明，见 LangGraph Persistence；Temporal 关于确定性重放的介绍，见 Temporal Workflows。

二、检查点迭代：本文的分析主线

2.1 核心定义

笔者把“检查点迭代”定义为：在 AI 自动化流程的每一个关键节点，保存足以重建该节点状态的完整信息（脚本版本、输入、输出、环境快照），使得任何一次迭代都可以被比较、复现和回退。

这个定义包含三个关键词：

• 关键节点：不是每一步都存，而是在“状态发生质变”的位置存，如模型生成脚本后、脚本执行前、外部调用前、数据写入前。
• 完整信息：只存脚本不够，还要存 prompt、模型参数、依赖版本、环境变量摘要。
• 可回退：回退不是“重跑”，而是“恢复到某个已知良好状态并继续”。

2.2 与传统版本控制的区别

Git 管理的是“代码版本”，而检查点迭代管理的是“执行版本”。二者的差异可以用下表说明：

本文评述：Git 仍然是底座，但仅有 Git 不足以支撑 AI 自动化的回退需求。真正的回退需要“代码 + 数据 + 状态”三位一体，这也是检查点迭代区别于传统版本管理的核心。

2.3 贯穿全文的逻辑结构

后文将沿着“保存什么 → 怎么保存 → 怎么回退 → 怎么保证回退安全 → 怎么观测 → 怎么验证 → 怎么落地 → 未来走向”的顺序展开。每一章都服务于同一条主线：让每一次 AI 迭代都可回退。

三、脚本版本管理：把 prompt、代码、配置一起纳入版本控制

3.1 为什么只存脚本不够

一个 AI 自动化任务的产物通常由四部分组成：

1. Prompt 模板：告诉模型要做什么。
2. 生成脚本：模型输出的可执行代码。
3. 配置与参数：模型名称、temperature、工具白名单、超时设置。
4. 依赖环境：Python 版本、第三方库版本、系统依赖。

如果只把第 2 项提交到 Git，那么当脚本出问题时，团队无法回答“当时用的哪个 prompt”“temperature 是多少”“依赖版本有没有变”。这会导致回退后问题依旧复现。

3.2 推荐目录结构

笔者建议采用如下目录组织一个 AI 自动化项目，把四类产物放在同一仓库、同一提交中：

auto-pipeline/
├── prompts/
│   ├── extract.v1.md
│   └── extract.v2.md
├── scripts/
│   ├── extract_20240601.py
│   └── extract_20240612.py
├── configs/
│   ├── model.yaml          # 模型名、temperature、top_p
│   └── tools.yaml          # 工具白名单、超时
├── checkpoints/
│   └── run_20240612_0930.json
├── tests/
│   └── test_extract.py
├── requirements.lock       # 锁定依赖版本
└── README.md

每次迭代时，新脚本不覆盖旧脚本，而是以日期或版本号命名新增。prompt 同理。这样 Git 历史天然形成“脚本版本谱系”。

3.3 用 Git 分支承载“实验性迭代”

对于风险较高的 AI 改写，建议采用分支策略：

• main 分支：只保留经过回归测试、当前生产在用的脚本版本。
• exp/xxx 分支：AI 生成的新脚本先在此分支验证。
• tag：每次生产发布打 tag，如 v2024.06.12，便于一键回退。

本文评述：分支策略的价值不在于“多分支”本身，而在于它强制团队把“AI 生成”与“生产可用”之间划出一条明确的验证边界。没有这条边界，回退就无从谈起。

延伸阅读：Git 官方关于分支与标签的教程，见 Pro Git 中文版；关于语义化版本，见 Semantic Versioning。

四、快照与回退：从 Git 到状态机检查点

4.1 快照的四个层次

回退的可靠性取决于快照的完整度。笔者把快照分为四个层次，逐层增强：

大多数团队停留在 L1，少数做到 L2。而 AI 自动化的真正难点在 L3 和 L4。没有 L3，回退后无法复现问题；没有 L4，回退可能造成二次损伤。

4.2 用 LangGraph 实现节点级检查点

LangGraph 是当前较成熟的 Agent 编排框架，其持久化机制允许在每个节点执行后保存状态。以下是一个简化示例（基于 LangGraph 官方文档思路，代码为示意）：

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver

# 定义状态结构
class PipelineState(dict):
    script: str
    input_data: dict
    result: dict
    error: str

builder = StateGraph(PipelineState)
builder.add_node("generate_script", generate_script_node)
builder.add_node("execute_script", execute_script_node)
builder.add_node("validate", validate_node)
builder.add_edge("generate_script", "execute_script")
builder.add_edge("execute_script", "validate")

# 关键：挂载检查点存储器
memory = SqliteSaver.from_conn_string("checkpoints.db")
graph = builder.compile(checkpointer=memory)

# 每次运行指定 thread_id，即可从上次检查点恢复
config = {"configurable": {"thread_id": "run-20240612-01"}}
graph.invoke({"input_data": data}, config)

这段代码的关键在于 checkpointer。它让每个节点的状态自动落盘。当 execute_script 失败时，可以修复脚本后从该节点重放，而不必重新调用模型生成。

本文评述：LangGraph 的检查点机制解决的是“流程状态回退”，但它不解决“模型输出回退”。也就是说，如果模型这次生成的脚本质量不如上一版，你仍然需要自己保留上一版脚本。二者互补，不能互相替代。

4.3 用 Temporal 实现确定性重放

Temporal 的核心思想是“工作流代码必须确定性”，所有非确定性操作（如调用模型、读时间、发请求）都封装在 Activity 中。工作流执行历史被持久化，失败后通过重放历史恢复到故障点。

对于 AI 自动化，这意味着：模型调用作为 Activity，其结果被记录进历史。回退时不会重新调用模型，而是直接使用历史结果。这恰好满足“保留上一版脚本”的需求——上一版的模型输出就是历史记录。

延伸阅读：Temporal 官方“确定性”章节，见 Temporal Determinism；LangGraph 检查点教程，见 LangGraph Persistence How-to。

4.4 回退的三种模式

实践中，回退并非只有“全部重来”一种。笔者总结为三种模式：

• 代码回退：仅切换脚本版本，数据不动。适用于脚本逻辑错误但数据未受影响的情况。
• 状态回退：从检查点恢复流程状态，重新执行后续节点。适用于流程中途失败。
• 补偿回退：对已产生的外部副作用执行补偿操作（如退款、撤单），再回退状态。适用于有外部调用的场景。

选择哪种模式，取决于损伤类型。这也是为什么第 1.2 节要先分类失败模式。

五、幂等与状态持久化：让回退真正安全

5.1 幂等是回退的前提

如果一次操作重复执行会产生不同结果，那么回退重放就是危险的。幂等性（Idempotency）要求：同一操作执行一次和执行多次，对系统状态的影响相同。

在 AI 自动化中，幂等设计至少包括：

• 写入幂等：用唯一键去重，如 INSERT ... ON CONFLICT DO NOTHING。
• 调用幂等：外部 API 调用携带幂等键（Idempotency-Key），如 Stripe、支付宝均支持。
• 生成幂等：模型生成结果缓存，同一 prompt + 参数命中缓存则复用，避免重复消耗与结果漂移。

本文评述：很多团队把幂等当作“性能优化”，但在 AI 自动化里，幂等首先是“安全机制”。没有幂等，回退就是赌博。

5.2 状态持久化的存储选型

检查点数据该存哪里？不同规模有不同选择：

笔者建议：开发期用 SQLite，生产期用 PostgreSQL 存元数据、对象存储存大体积快照。二者通过 run_id 关联。

5.3 检查点的最小字段设计

一个可用的检查点记录至少应包含以下字段：

{
  "run_id": "run-20240612-01",
  "node": "execute_script",
  "timestamp": "2024-06-12T09:30:00Z",
  "script_version": "scripts/extract_20240612.py",
  "prompt_version": "prompts/extract.v2.md",
  "model": "gpt-4o-2024-05-13",
  "temperature": 0,
  "input_hash": "sha256:...",
  "output_hash": "sha256:...",
  "env_lock": "requirements.lock@sha256:...",
  "status": "success",
  "error": null
}

其中 input_hash 和 output_hash 用于快速比对两次迭代是否等价，是回退决策的重要依据。

六、可观测性：没有观测就没有回退

6.1 三类可观测信号

回退决策依赖“知道现在坏在哪”。可观测性提供三类信号：

• 日志（Logs）：记录每次模型调用、脚本执行、外部请求的详细上下文。
• 指标（Metrics）：成功率、延迟、token 消耗、回退次数。
• 追踪（Traces）：跨节点、跨服务的调用链，定位失败发生在哪一步。

OpenTelemetry 已成为事实标准。LangSmith、LangFuse、Phoenix 等工具则专门为 LLM 应用提供追踪能力。

6.2 关键指标设计

针对“可回退自动化”，笔者建议重点监控以下指标：

注：以上阈值为笔者基于常见工程经验的建议值，非来自特定文献，实际应结合业务基线调整。

6.3 追踪与检查点的联动

理想状态下，每个检查点应携带 trace_id，使得从追踪系统可以直接跳转到对应快照。这样当告警触发时，工程师能一键查看“失败节点当时的完整状态”，并决定回退到哪个版本。

本文评述：可观测性与回退机制的关系，类似“诊断”与“治疗”。没有诊断，治疗就是盲目的。很多团队急于搭建回退，却忽略了观测，结果回退后问题依旧。

延伸阅读：OpenTelemetry 官方文档，见 OpenTelemetry Docs；LangFuse 开源 LLM 可观测平台，见 LangFuse Docs。

七、评测闭环：用回归测试守住每一次迭代

7.1 为什么 AI 自动化需要回归测试

传统软件回归测试验证“代码改动是否破坏既有功能”。AI 自动化的回归测试还要多一层：验证“模型生成的新脚本是否优于旧脚本”。这需要一套固定的评测集（Eval Set）。

7.2 评测集构建方法

评测集应覆盖典型场景与边界场景。构建步骤：

1. 收集历史输入：从生产日志中抽取真实输入样本。
2. 标注期望输出：人工或半自动标注正确结果。
3. 分层抽样：按难度、类型分层，避免评测集偏斜。
4. 冻结版本：评测集一旦确定，用 Git 管理，改动需评审。

涉及数据集时需说明预处理细节。例如若使用公开数据集，应记录清洗规则、去重策略、字段映射。若为模拟数据，须明确标注“模拟数据”。

7.3 评测指标与回退决策

常用指标包括：任务成功率、输出格式合规率、平均 token 消耗、执行耗时、人工介入率。当新版本在评测集上表现劣于旧版本时，应自动阻止合并，保留旧版本。

# 简化的评测对比逻辑（示意）
def compare_versions(old_script, new_script, eval_set):
    old_score = evaluate(old_script, eval_set)
    new_score = evaluate(new_script, eval_set)
    if new_score.success_rate < old_score.success_rate:
        return "REJECT", old_script   # 保留旧版本
    return "ACCEPT", new_script

本文评述：评测闭环是“检查点迭代”的守门人。没有它，回退只能靠事后救火；有了它，回退变成事前预防。二者结合，才构成完整的迭代治理。

八、工程落地路径：从零搭建可回退自动化流水线

8.1 分阶段实施路线

笔者建议按四阶段推进，每阶段都有明确交付物：

8.2 CI/CD 中的回退卡点

在 CI 流水线中加入以下卡点，可显著降低“AI 改坏”的风险：

• 静态检查：脚本语法、依赖可用性、敏感操作检测（如 rm -rf、DROP TABLE）。
• 沙箱执行：在隔离环境跑一遍，验证不破坏外部系统。
• 评测对比：新版本必须不劣于旧版本才允许合并。
• 人工审批：高风险操作（涉及资金、用户数据）强制人工确认。

8.3 一个最小可用示例

以下是一个“AI 生成数据清洗脚本 + 可回退执行”的最小流程（示意代码）：

import hashlib, json, subprocess
from pathlib import Path

def save_checkpoint(run_id, node, script_path, data):
    cp = {
        "run_id": run_id,
        "node": node,
        "script": script_path,
        "input_hash": hashlib.sha256(json.dumps(data).encode()).hexdigest(),
    }
    Path(f"checkpoints/{run_id}_{node}.json").write_text(json.dumps(cp))

def run_with_rollback(run_id, script_path, data):
    save_checkpoint(run_id, "before_exec", script_path, data)
    result = subprocess.run(["python", script_path], capture_output=True)
    if result.returncode != 0:
        # 回退：切换到上一版脚本
        prev = get_previous_script(script_path)
        print(f"失败，回退到 {prev}")
        return run_with_rollback(run_id, prev, data)
    save_checkpoint(run_id, "after_exec", script_path, data)
    return result

这段代码虽然简化，但体现了核心思想：执行前存检查点，失败时切换到上一版脚本重试。生产环境还需加上幂等、告警、人工介入等机制。

延伸阅读：n8n 工作流自动化平台，见 n8n Docs；DVC 数据版本控制，见 DVC Documentation；GitHub Actions 入门，见 GitHub Actions 中文文档。

九、前沿预判：自愈式自动化与回退即能力

9.1 从“人工回退”到“自动回退”

当前多数回退仍需人工决策。但随着可观测性与评测体系成熟，自动回退成为可能：系统检测到指标异常，自动切换到上一个检查点，并通知人工复核。这类似 Kubernetes 的“自愈”机制，但作用于 AI 工作流层面。

2024 年以来，已有研究探索“Agent 自我修复”方向。例如部分工作尝试让 Agent 在失败后自动分析错误日志、修改脚本、重试（相关方向可参考 arXiv 上关于 self-refine、reflexion 的系列工作）。

9.2 回退即能力：一种新的工程价值观

笔者认为，未来评价一个 AI 自动化系统是否成熟，不应只看“一次成功率”，而应看“回退成本”。回退成本越低，系统越健壮。这带来一个价值观转变：回退不是失败，而是能力。

这一观点与软件工程中的“可逆性设计”（Reversible Design）一脉相承。经典文献如 Martin Fowler 关于“蓝绿部署”“功能开关”的论述，本质上都在降低变更的回退成本。AI 自动化只是把这一原则推向了更细的粒度。

9.3 待解问题

该方向仍有若干开放问题：

• 如何在保证幂等的同时，处理不可避免的非幂等外部调用？
• 检查点存储的成本与保留策略如何平衡？
• 自动回退的触发条件如何避免误判？
• 多 Agent 协作场景下，检查点如何跨 Agent 对齐？

这些问题尚无标准答案，但正是它们构成了未来几年的工程研究空间。

十、结论

AI 自动化不是一次性魔法，而是持续迭代的工程实践。模型的不确定性决定了“改错”是常态，因此“能回退”必须成为系统的默认能力。本文以“检查点迭代”为主线，从脚本版本管理、快照与回退、幂等与状态持久化、可观测性、评测闭环五个层面，给出了一套可落地的工程路径。

核心结论可以浓缩为一句话：每次迭代都保留上一版脚本，让回退成为自动化的第一性能力，而不是事后补救。

当团队真正把回退成本降下来，才敢让 AI 更大胆地参与自动化。这或许才是 AI 自动化走向成熟的标志。