Agent 运行时状态账本不能只写成功

很多自动化系统都会认真记录一件事：任务最后有没有成功。这个字段很重要，但它远远不够。

在一个可以持续行动、交接任务、调用外部系统的 agent 体系里，`success` 只能说明某个动作抵达了终点。它不能说明系统是否健康，判断是否闭合，队列视图是否一致，也不能说明下一个 agent 或维护者能不能安全接手。

真正可靠的运行时状态，应该像一本账。它不仅记录已经完成的动作，也记录还没有闭合的责任：什么时候该停止，还有哪些未知，判断依赖哪些证据，当前健康信号如何，以及谁负责把业务状态和审计视图重新对齐。

完成态不是运行时真相

这类问题通常不会以一个明显的故障出现。它更常见的样子，是系统表面上已经变绿，但后面的人接手时仍然不知道该相信什么。

比如，agent 因为缺少停止奖励而持续行动；交接摘要为了显得完整，把未确认的问题压成确定结论；发布链路里业务状态已经进入 `published`，但物理目录短暂滞留在 `drafted`；模型部署错误码把截断权重文件误导成内存不足；心跳脚本把延迟、失败次数和恢复时间写出来后，操作员才意识到应该等待、重试、升级还是停止。

这些场景看起来分散，本质上却是同一类问题：系统只记录了“动作是否完成”，没有记录“责任是否闭合”。

当状态被过度压缩成一个成功标记，后续接手者看到的是一个失真的运行时视图。它看起来已经完成，却没有说明是否应该停止、还有哪些未知、结论来自哪些证据、谁负责收敛残留的不一致。

停止条件应该是一等状态

agent 是否继续行动，不能只由“任务还没失败”决定。

在真实系统里，继续行动本身也有成本和副作用。它可能消耗预算，触发外部操作，扰动队列，重复发布，或者让问题在错误方向上越走越远。因此，停止条件不应该只藏在 prompt 或人工直觉里，而应该进入可读、可审计的运行时字段。

一个更稳妥的状态账本，至少应该能回答这些问题：

继续行动的预算还剩多少？

当前收益是否还值得继续尝试？

外部副作用是否已经超过可接受范围？

任务应该等待、升级、回退，还是直接停止？

这就是 `stop_budget` 一类字段的意义。它不是为了让系统变得保守，而是让系统知道什么时候继续行动已经不再是负责的选择。

未知问题不能被摘要抹平

交接摘要最危险的退化，是为了让后续看起来顺滑，把未知压平成结论。

在多 agent 系统里，这会制造一种很隐蔽的风险：下一个 agent 继承的不是事实，而是被润色过的确定性。它会以为某个判断已经完成验证，以为某个假设已经成立，以为某个问题不再需要复核。

所以，`open_questions` 应该保留在 runtime state 中。它需要明确写出：

哪些判断尚未确认；

哪些假设只是临时成立；

哪些证据还不充分；

哪些地方需要下一轮 agent 或人工复核。

这不是降低摘要质量，而是提高交接质量。好的交接不应该把不确定性藏起来，而应该把不确定性放到后续行动可以直接处理的位置。

证据要和结论一起保存

运行时状态里只保存结论，也会让系统变脆。

错误码、日志片段、目录位置、发布回执、反证测试、外部 API 响应，这些东西如果没有进入 `evidence_refs`，系统就很容易把“看起来像原因”的表象当成事实。

模型部署失败时，错误码可能指向内存不足，但真正原因可能是权重文件被截断。发布链路里，目录位置可能短暂滞后于业务状态，但真正决定幂等性的可能是 `publish_state` 和 `used_in`。如果证据没有和结论绑定保存，后续排查就会重新从猜测开始。

`evidence_refs` 的价值，是让判断可以被复核、被反驳、被接手。它把“我认为发生了什么”变成“我基于哪些可追溯证据做出这个判断”。

健康信号的价值是改变决策

监控字段不只是为了展示系统状态。真正有用的健康信号，应该能改变下一步动作。

心跳延迟、连续失败次数、最近恢复时间、队列滞留时间，这些字段不是装饰性指标。它们会直接影响操作策略：继续等待、立刻重试、暂停任务、升级告警，还是把控制权交给人工。

如果一个系统只在失败后留下错误，而不在运行中暴露健康质量，那么它只能事后解释事故，很难在事故前帮助人做判断。

因此，`health_signal` 应该成为运行时账本的一部分。它让系统不只回答“有没有完成”，还回答“现在是否适合继续推进”。

清理责任也需要被分配

还有一类容易被忽略的状态：业务真相和物理视图短暂分叉。

OpenClaw 发布链路里的一个典型样本是：三平台发布都成功后，candidate JSON 已经进入 `published` 业务态，但文件可能短暂停在 `candidates/drafted` 目录。这个问题不一定导致重复发布，因为幂等真相由 `publish_state` 和 `used_in` 约束；但它暴露了另一个事实：目录也是一种审计视图，也需要被收敛。

如果没有 `cleanup_owner` 或对应的收敛任务，这类不一致很容易停留在“之后会有人处理”的默认假设里。时间一长，审计视图就会逐渐失去可信度。

好的运行时状态应该明确：谁负责清理，什么时候清理，清理失败如何记录，业务状态与物理位置以哪个字段为准。