Appearance
一次 Run 如何可复现：Version Snapshot 与 Run Manifest
前置：怎么在不依赖真实模型的情况下测试 Runtime：Fake Model 与 Deterministic Tests
一次回归只在 prompt commit 改动后出现时，可以通过 manifest 对比找到差异，而不是把结果波动全部归因于模型。线上失败 Run 可导出 manifest，在测试环境加载同一工具 schema、prompt 和代码版本，再用 ScriptedModel 重放 Runtime 路径或真实模型做近似复现。
Prompt / Model / Tool Schema Versioning
每次 Run 都应留下足够的版本证据，让后续能够回答“这次执行到底使用了哪组模型、Prompt、Tool 与代码配置”。否则回归出现时很难知道真正变化的变量。
Prompt、模型版本和 Tool Schema 都会改变 Agent 行为，应当作为运行依赖版本化。版本号必须能关联到具体内容，而不是只有“v2”这种无法重现的标签。
Run Manifest / Reproducibility
Run Manifest 要解决的是：几天后看到一个失败 Run，能不能回答“当时到底运行了什么”。
最少应能定位：
text
model/provider/version + settings
instruction/prompt version
exposed tool catalog + schema version
retrieval/index version
runtime config
application commit/build只保存最终 prompt 文本还不够。例如同一个 prompt 在 Tool schema 从 v2 改到 v3 后，模型可选动作已经变化；如果 manifest 没记录 tool version，历史失败就无法真正复现。
“Reproducible”也不意味着模型必须逐 token 输出完全一致，而是让输入依赖和运行条件可解释、可重建，便于判断回归来自模型变化、Context 变化还是 Runtime 变化。
Failure Modes
只保存 Prompt 文本却没有保存完整运行版本
症状： 回归时只能看到用户输入，不知道 model、tool schema、retrieval index、code/config 是哪个版本。
为什么危险： 同一任务表现变化无法复现，也无法判断是模型、提示、工具还是代码引起。
处理： Run 开始时快照 model/provider/settings、prompt、tool catalog、index、runtime commit/config。
如何验证
| Case | 断言 |
|---|---|
| 只保存 Prompt 文本却没有保存完整运行版本 | 回放一条历史 Run，断言能解析全部版本引用；任一关键版本缺失则 reproducibility check 失败。 |
自测
- 同一 Prompt 昨天通过、今天回归。只有 Prompt 文本相同为什么还不足以复现？Run Manifest 至少还要固定哪些版本？
- 历史 Run 引用了已不存在的 tool schema version。此时系统应把它当成“可复现但失败”还是“缺少复现条件”？为什么？