🚨 明明上一轮刚跑通，为什么下一轮就复现失败了
很多团队把 Agent 接上代码执行器后，最先暴露的问题不是生成逻辑，而是任务一跨回合就开始“复现蒸发”。⚠️ 同一段脚本上午还能跑通，下午重放却报依赖缺失或结果文件不一致；更糟的是，日志里只留下成功结论，环境细节已经丢了。📉
代码执行型 Agent 和纯文本 Agent 的差别，在于它不仅要给答案，还要把运行现场一起保住。🧠 Python 版本、系统包、临时目录和中间产物只要有一个维度漂移，复现链路就会断开。📌 团队如果只保存 prompt、stdout 和最终结论，实际上只保存了“说法”，并没有保存“证据”。
🔍 真正漂移的，不只是依赖版本，而是工作区、运行状态和中间产物一起失控
线上最常见的复现失败，通常不是单点故障，而是三层漂移叠在一起。🔍 第一层是环境漂移，Python小版本、系统包和隐式环境变量在不同 worker 上并不一致；第二层是状态漂移，Agent 上一轮创建的临时文件、下载模型或缓存没有被登记，下一轮自然找不到；第三层是产物漂移，报告里引用的 CSV、图像或权重没有被密封，后续重跑时内容已经变了。🧩
一组内部代码评测任务灰度里，团队只记录prompt + stdout + exit code时，任务“结论可复现率”只有63%；补上pip freeze和工作目录清单后，提升到81%；再把输入数据、输出文件和哈希一起封存，复现率提升到94%。📊 这说明真正需要治理的不是“脚本有没有跑”，而是“这次运行是否形成了可验证的闭环”。✅
| 方案 | 结论可复现率 | 二次重跑成功率 | 存储开销 | 典型问题 |
|---|---|---|---|---|
| 只存日志结论 | 63% | 58% | 1.00x | 看见成功，看不见现场 |
| 补环境快照 | 81% | 77% | 1.12x | 仍缺输入与产物约束 |
| 环境快照 + Artifact Seal | 94% | 91% | 1.26x | 更稳，适合生产 |
🛠️ 更稳的做法，是在任务成功瞬间同时冻结环境快照和 Artifact Seal
更稳的工程做法，不是等用户质疑后再回头排查，而是在每次执行成功的当下就生成一份最小可重放包。🛠️ 这份快照至少要包含解释器版本、依赖清单、工作目录摘要、输入文件指纹和输出产物哈希。🔒 只有把“这次运行依赖了什么”写成结构化记录，后续回放才有锚点。
真正关键的一步，是给输出结果做Artifact Seal。🔁 也就是把本轮真正影响结论的输入、配置和输出绑定成一个不可歧义的封印，而不是只把大文件扔进对象存储。🧪 如果报告声称某张图、某个 CSV 或某份 patch 证明了结论，就应该同时记录它们的路径、哈希和上游输入指纹；一旦重跑结果哈希变化，系统应直接标记“结论待重验”，而不是继续复用上一次成功文案。📎
defseal_run(run_ctx):env=snapshot_env(python_version=run_ctx.python_version,deps=run_ctx.freeze_packages(),workdir=run_ctx.list_workspace(),env_allowlist=["PATH","PYTHONPATH","CUDA_VISIBLE_DEVICES"],)artifacts=[]forpathinrun_ctx.output_files:artifacts.append({"path":path,"sha256":sha256_file(path),"source_inputs":run_ctx.input_digests(path),})return{"env_snapshot":env,"artifact_seal":artifacts,"entry_command":run_ctx.command,}这段逻辑的重点，不是多存一份日志，而是把“答案为什么成立”转成可验真的运行合同。🙂
📈 接下来 3 到 6 个月，代码 Agent 的分水岭会从“会不会执行”转向“能不能验真重放”
接下来3到6个月，代码执行型 Agent 的竞争点不会只是“谁能调用更多工具”，而是谁能把执行结果变成可验真、可重放的资产。📈 团队至少要持续盯住replay_success_rate、env_snapshot_coverage、artifact_hash_miss_rate和rerun_delta_rate。📊 如果这些指标没有进入主面板，平台就很容易在 demo 阶段显得聪明，一到生产审计就开始失分。🚦
笔者认为，成熟的代码 Agent 最终更像一条带证据链的自动化流水线，而不是会写脚本的聊天界面。💡 真正能上线放量的系统，不是回答最快的那个，而是两周后还能把同一结果重演出来的那个。🙂
