收尾要落到确定状态

更新于 2026-09-22

收尾要落到确定状态

# 收尾要落到确定状态

远程 / 异步任务只要停在「等人 / 等事件」的中间态，就等于没有结束 —— 而它不会报错，只会安静地挂在那里。判据一句话：终态必须是三选一 —— 成功、失败、已接管；其余都算悬挂。

出处	看起来的状态	实际	缺的东西
委派前要过用户审查闸门	worker `idle`	只是执行轮次结束，AO 不会自动续跑	没有把 `idle` 翻译成「等指令」并检查未完成项
长任务不要用固定超时判定	超时 → 判失败	长任务本来就可能超过固定阈值	终态判据用了「时长」而不是「真实事件」
阻塞式工具与提案确认	Agent 说完了	写入类工具不在 loop 里，无法就结果继续	工具不可暂停 / 不可恢复
Agent harness 要隔离复现可收尾	跑过了	环境没隔离、收尾动作没人做	harness 缺「收尾」这一半

旁证：全绿的单测可能测的不是那条链路 —— 「修了一个真实 bug」被当成「修好了用户报的问题」，于是 Issue 提前关闭；正确的收尾是退回 In Progress，等用户验收。

「等人确认」「等事件」「idle」都不是终态。 系统必须显式把它们转成可恢复 / 已终止 / 已接管，否则任务会永久悬挂 —— 而且没有任何告警。
超时不能充当终态判据。 用固定时长判定结束会误杀长任务；终态应由权威事件 + 显式状态迁移 决定，超时只能触发「询问 / 接管」，不能直接判死。
收尾的定义权在消费方，不在执行器。 「执行器说完了」不是完成；完成要由验收方认账（见能力要靠消费方认账、Issue完成由用户验收后再关闭）。
可迁移的动作：设计任何异步 / 远程任务时，先列出全部终态，再逐条路径检查 「有没有一条会停在非终态？」 有，就补一条迁移规则或一个接管入口。

单看每一页，都是某次编排 / 工具设计的具体缺陷。并排之后才看得出它们共享同一个缺口：状态机没有把「中间态」收敛掉。