这是一篇来自 LegacyPilot 的工程笔记。项目把 Java 代码变更拆成计划、受控执行与独立验证，最核心的约束是：模型返回“完成”，不会直接让任务进入成功状态。
模型动作与执行权限分别判断
模型负责提出下一步动作，例如搜索方法、读取源码或应用补丁。Runtime 先检查预算，再由策略判断允许、拒绝或等待审批。工具输出回到状态机，成为后续推理的事实依据。
文件写入范围、Maven goal 和网络访问都有明确边界。这样的 Harness 把“想做什么”与“获准做什么”分别记录，也让开发者能够复核执行过程。技术架构描述了 Runtime 与 Tool Runtime 的职责。
验证从业务要求开始
公开示例要求普通用户和 VIP 用户遵守不同的每日累计转账限额。只验证代码可编译，并不足以判断规则成立，还需要检查超限、日期切换与并发转账。
LegacyPilot 的验证流程组合工作区完整性、diff、编译、测试、静态检查和确定性断言。必需检查通过才能成功；可修复的失败进入预算内重试；预算耗尽则保留失败原因。公开示例最终通过 5 项断言和独立 Maven 测试，完整依据见演示证据。
恢复依赖持久证据
长任务可能在写文件或调用工具后中断。重启时重新执行所有动作，可能重复副作用；直接跳过动作，也可能遗漏尚未完成的工作。
项目用 Checkpoint 保存状态，用 Action Journal 记录动作与效果，用 Run Lease 限制并发恢复。只有持久证据能够确认结果的动作才自动跳过或重放；不确定的写操作进入人工复核。恢复机制给出了具体边界。
评测结论保留适用范围
单个任务成功可以说明这条路径有效，无法推出所有 Java 变更都可靠。因此固定数据集、模型配置、重试次数和验证结果需要一起保存；确定性 Replay 测试与真实模型评测也分别记录。
这组设计让 Agent 的成功有一个可解释的含义：在指定代码快照、权限和验收条件下，完成了通过验证的变更。下一步改进也因此有了落点，可以针对检索遗漏、工具错误或业务断言失败分别处理。