长任务当然需要计划，但一份写得很漂亮的计划并不会自动让系统持续收敛。环境在变，工具会失败，用户会改要求，原先正确的步骤可能过期。计划如果直接覆盖事实状态，模型很容易把「准备执行」记成「已经完成」；如果每次变化都从头规划，又会丢掉已经验证的有效工作。
状态机提供了更稳的连接方式。目标状态记录当前义务，计划状态记录下一批候选动作，环境状态记录工具真实改变了什么，确认记录保存已经通过验证的结果。计划可以频繁重算，明确事件负责更新事实与证据。验收要求和有效证据共同决定任务是否完成；模型暂停生成或计划列表暂时为空时，系统会重新检查状态。
1. Manage、Execute 与 Audit 各管什么
Manage 根据目标和可信事实选择下一步，Execute 在受限权限内调用工具，Audit 独立检查观察能否支持状态更新。三者可以由同一个模型在不同上下文中承担，也可以由多个模型或确定性程序完成；关键不在角色数量，而在写权限和信息边界。执行者不能自行把候选结果标成已验证，审计者也不应在缺少环境证据时补全成功。
MEA 状态循环从 LongHorizon-Harness 的 Manage-Execute-Audit 结构进入，推导状态合约、滚动计划、停止条件和最小实现。它还解释 fresh context 为什么有助于隔离局部偏见，却无法代替持久化状态：上下文刷新后，系统仍要从权威记录恢复目标、已完成工作和未决风险。
2. 验证与恢复决定闭环上限
Auditor 能看见什么、能够调用哪些验证器，决定系统最多能确认到哪一步。测试覆盖不到的性质只能保持未知；工具超时也不能被自动提升为失败或成功。故障发生后，系统要判断受污染范围，回到与外部世界一致的 checkpoint，再根据当前目标重新规划。若 checkpoint 与真实副作用错位，恢复可能重复发送消息或创建资源。
审计恢复与能力归因用故障注入检查这些边界，并拆分模型、Harness 和环境对结果的贡献。掌握状态转移、验证覆盖和恢复以后，评价新的 Agent 框架就有了三个直接问题：谁拥有真相，哪些事件可以改状态，错误以后从哪里继续。
3. 进度是一组已证明的命题
计划列表勾掉多少项并不等于有效进度。更稳的表示是把任务要求写成命题，把测试、文件哈希或外部查询结果作为证据。只有证据满足当前版本的要求，命题才从 pending 进入 verified；目标变化或环境漂移会让它退回待验证。这样定义以后，恢复不必依赖模型回忆做过什么，只需从最近仍成立的命题集合继续。它也能识别一种常见假完成：Agent 没有下一步可生成，却仍有要求缺少证据。系统此时应报告阻塞或继续获取观测，而非把停机当成成功。