在正确时刻唤醒工作流，而不是无限轮询

Trigger

事件告诉 runtime：有变化发生，某条工作流可能需要恢复。

• 用 profile 和 assessment 事件唤醒正确任务。
• 在 runtime 里保持事件路由显式。
• 不要把业务逻辑塞进投递层。

Re-fetch

收到投递后，先从正式 API 表面重新读取状态，再做动作。

• 让 webhook 决定何时拉取，而不是盲信它本身。
• 动作前重新读取 context 或更窄端点。
• 让续跑保持幂等，重复投递也无害。

Operations

订阅必须可见、有归属，而且能被清理。

• 记录哪条工作流拥有哪个 webhook URL。
• 在模型循环之外审计订阅。
• 流程退役时删除旧订阅。

情况

工作流可以在一次交互内完成

动作

继续使用直接读取。

原因

引入事件基础设施只会增加复杂度。

情况

工作流需要在稍后用户进展后继续

动作

创建 webhook 订阅，并在投递时重新拉取状态。

原因

这是恢复流程并保持数据新鲜度的最干净方式。

情况

出现重复或延迟投递

动作

让续跑保持幂等，并记录每次投递尝试。

原因

事件系统的可靠性来自重复安全，而不是来自绝不重复。