执行框架（harness）拥有控制流，因为模型不拥有。它构造状态包、调用类型化 API、校验输出、应用阈值、调用工具、记录回执、处理重试并决定何时停止。语义决策是这个程序的一个输入，而不是程序本身。
这种分离也改善了可靠性。决策失败时，开发者能分辨：是状态不够、契约含糊、模型不确定，还是执行器拒绝了动作。没有这些边界，一切都会塌缩成「智能体失败了」。
| 故障 | 确定性响应 | 语义角色 |
|---|---|---|
| 无效输出 | 修复并重试 | 无——类型违规 |
| 低置信度 | 改进状态或升级 | 可建议证据 |
| 工具不可用 | 回退或暂停 | 可重新选择选项 |
| 预算耗尽 | 停止并报告 | 不做新决策 |
| 副作用冲突 | 回滚或加围栏 | 可解释状态 |
不是每种故障都是语义故障。解析错误意味着输出违反了声明的类型；被拒绝的工具调用是权限或可用性问题；超时可能是基础设施问题。把它们统统当成「模型错误」，会导致重试一个根本修不好的问题。
契约应当给故障分类：无效、不确定、不可用、被禁止、陈旧、冲突、耗尽。每一类映射到不同的确定性响应。
恢复属于执行框架，不属于临时拼凑的提示词。开发者声明一次重试可以改变什么：新证据、更窄的选项集、更强的模型、不同的契约版本，或人工审查。
用同样的状态重复同一个问题很少是恢复。如果第一次尝试不确定，系统需要的是不同的信息或不同的决策边界——而不是再采样一次。
重试有预算。每次重试都消耗 token、延迟与用户耐心。把每次尝试记入回执，校准才能区分「一次成功」与「第三次才成功」。
retry@2 narrowed options, second attempt escalate human review after budget
复合任务经常部分成功。如果系统能证明剩余工作是独立的，它可以保留已完成的产物，只把未决的剩余部分路由去审查。
部分接受需要副作用跟踪。不知道哪些写入已提交，框架就无法安全续跑。检查点让「已完成」与「进行中」之间的边界显式化。
回执喂给一个改进回路：按契约版本与状态切片聚合路由、置信度与结果，找出那些自动化率很高、人工改判率也高的分支。
回路是：观测回执 → 分析校准与改判 → 改进契约或状态 → 在留出 fixture 上验证 → 以阈值变更的形式灰度上线。每一步都有负责人与回滚条件。
observe → analyze → improve → verify
模型升级是契约迁移。新版本可能改变置信度的含义、选项措辞或校准。绝不要在生产阈值背后悄悄换模型。
在留出 fixture 上重跑、重新估计校准、逐切片对比行为。如果新模型在关键分支上只是「不同」而非「更好」，就保留旧契约，直到证据支持切换。
契约应当被有意识地退役：标记版本为弃用、把新流量路由给继任者、保留旧版本用于重放历史回执。
被弃用的契约对审计仍然重要。如果一次事故引用了 receipt@version，系统必须能重建那个版本在决策时刻的含义。
用户、工具、语言与模型都会变化。持久的工程表面是执行框架：类型化契约、版本化状态、校准阈值、记录在案的回执、确定性恢复。这一层牢固时，模型变化是一次实验，而不是一次重写。