因素05：统一执行状态与业务状态

来源：12-Factor Agents / Factor 5（Unify execution state and business state）

一句话先懂

尽量用一条事件线程同时承载“业务发生了什么”和“流程走到哪”，减少双状态系统的复杂度。

奶奶版理解

做饭时你记一本流水账：

• 买菜
• 切菜
• 炒到一半停电

这本账既告诉你“饭做到哪步”，也告诉你“发生了什么事”。
不需要再单独维护一本“流程状态账”。

原文核心思想

传统系统常分两套状态：

• 执行状态：当前步骤、重试次数、是否等待
• 业务状态：对话历史、工具调用结果

两套一旦不同步，问题排查会非常痛苦。

推荐方案：事件线程（thread）

{
  "thread_id": "t_1001",
  "events": [
    {"type": "user_request", "data": "发布后端"},
    {"type": "list_tags_result", "data": ["v1.2.3"]},
    {"type": "approval_requested", "data": {"target": "oncall"}}
  ]
}

通过最后几个事件，通常可直接推导当前执行状态。

为什么这会更稳

• 单一事实源（single source of truth）
• 更易序列化和持久化
• 回放调试和断点恢复天然支持
• 方便做可视化审计

边界提醒

不是所有东西都应写进线程：

• 敏感凭证
• 临时会话密钥
• 合规限制数据

这类数据应存在安全域，用引用 ID 关联。

常见误区

• 事件类型随意命名，后续难维护。
• 没有幂等 event_id，重复写入导致状态污染。
• 线程存了“最终结论”，却没存“过程事件”。

我的思考

我把这条理解为 AI 场景下的“轻量事件溯源”。
只要你能重放 thread，你就几乎拥有：

• 可恢复
• 可解释
• 可审计
• 可分支试验

这比在多个表里拼状态可靠得多。

小结

• 优先追求一份统一线程。
• 过程事件比最终状态更有价值。
• 状态可重放，系统才真正可维护。