执行策略与结果核对

一次失败的修复

假设模型修改了一个函数，并在测试后报告“已经修好”。随后模型修改一处调用方，但没有重新测试。模型仍给出肯定结论，测试记录却已对应旧内容。

Aster 分开模型意图、工具效果和完成判断。模型提出下一步，工具执行操作，Core 根据回执、修改记录和验证结果判断能否结束。宿主根据这些记录确定任务状态。

Harness 组织上下文、模型、工具、等待、验证和收尾。Meta Harness 把其中的可组合部分开放给宿主。应用可以改变执行方式，并继续使用原有会话和检查机制。

三种信息各自证明什么
信息	例子	能支持的判断
模型意图	准备调用 edit，或准备结束任务	模型希望下一步做什么
执行事实	某个工具 ID 的调用已经完成，写入了哪些内容	实际发生了什么，以及是否还有结果不明的操作
完成结论	验证报告对应当前 effect_digest，资源收尾已经结束	这次运行是否满足宿主要求的结束条件

文本增量不能证明文件已经写入。ToolStart 不能证明工具已经执行。命令退出码为 0 也不能单独证明当前修改通过验收。界面应区分这些阶段，不能把最后一段回复作为成功依据。

任务可能只读检索、反复修改与测试，或等待用户确认。固定执行循环会把这些差异绑在同一份实现中，增加实验、接入和恢复的耦合。

Meta Harness 提供三个入口：配方组合默认组件，宿主注册表挂载组件，Assembler 提供完整组件树。调用次数、压缩、上下文来源和工具另有配置入口，普通扩展无需新建调度器。

组件的 initial、step 和 output 根据事实计算状态、视图和候选动作。文件写入和模型请求由动作承担。重建状态时可以重新计算组件，无需重复外部操作。

可替换的策略仍需明确 Core 和宿主的职责。工具能否执行取决于原有权限与确认入口。修改能否结束取决于当前报告、回执和完成检查。系统提示、组件名称和普通 Hook 返回值都不能代替这些依据。

例如，从配方里删除 budget，不会取消调度器的次数限制。系统提示要求“直接通过”，也不能生成对应当前修改的验证报告。检查实现时，应追踪配置进入调度器、工具准入和结果进入完成检查的路径。

这个约束针对经过 Core 管理的执行入口。宿主装入的原生 Rust 代码仍需信任、审查和必要的进程隔离。运行生成代码时，宿主还要管理构建与执行环境。注册表不会根据模型写出的名称自动加载代码。

运行、工具调用、动作 key、工作区与数据绑定都有各自的身份。恢复时必须找回原事实和对应资源。聊天文本无法证明某个外部写入是否发生。

动作 key 变化后，旧日志可能把动作视为新动作。宿主替换组件树时，需要明确已有会话的处理方式。实验应使用新会话和隔离工作区，以区分新旧执行。

事实重放可以重建已经记录的状态。再次请求外部模型或服务时，输出仍可能不同。回执缺失的外部操作需要核实。结果未知的状态不能自动视为允许重试。

模型结束回复后，工具创建的监听器、租约和后台工作可能仍在活动。Aster 把资源清理结果纳入原运行的结束过程。清理失败或超时时，界面不能沿用先前算出的成功状态。

会话、Run 和长期目标需要分开。一次 Run 可以结束，整个目标仍可能有未接受的步骤。会话可以接收下一条任务，但上一运行的资源不能遗留在后续任务中。

选择最小的扩展入口并保留运行身份。失败路径验收应覆盖：拒绝是否阻止执行，后续修改是否使测试报告失效，取消是否退出，恢复是否重复操作。通过这些检查后，组件才适合用于递归自我改进的候选实验。