本文整理自已有的运行时研究笔记，讨论的是系统设计问题，尚未包含实验验证。
四种容易混淆的状态
一次健康检查返回成功，可以说明进程能够响应，却不能说明智能体正在接近目标。工具调用持续发生，也可能只是换着说法重复同一个失败。
因此，我想把状态拆开来看：
| 状态 | 最基本的问题 |
|---|---|
| 存活 | 执行环境还能响应吗？ |
| 就绪 | 继续工作需要的依赖和资源可用吗？ |
| 推进中 | 最近的行为有没有改变任务状态？ |
| 可恢复 | 此刻中断后，能否从可信的状态接着做？ |
这些状态之间没有简单的蕴含关系。一个忙碌的进程可以没有进展；一个暂停的任务也可以拥有完整的恢复条件。
让进展变得可观察
观察对象可以包括目标与当前步骤、工具调用结果、记忆或工作区的有效变化，以及最近一次检查点的时间。连续重复的调用模式，也可能是停滞信号。
但“产生了变化”仍然不等于“产生了进展”。不断改写同一份无关文档会制造活动痕迹，长时间推导一个困难结论则可能暂时没有明显产物。语义层的判断，需要把行为与任务目标联系起来。
从观察到干预
一个控制循环可以分成观察、解释、决策与行动。先收集信号，再解释状态，最后才决定等待、暂停、重试或恢复。
把这些环节分开，是为了避免监控信号直接触发过度干预。工具暂时失败与任务陷入循环，需要不同的处理方式；恢复动作本身也可能重复产生外部副作用。
接下来要证明什么
真正需要验证的是：这些信号是否能比单纯的心跳检查更早识别停滞，同时避免频繁打断正常工作。
目前这仍是一份问题地图。把“语义进展”写进架构名称，并不会自动获得识别进展的能力。