架构5. 统一执行状态与业务状态
即使在AI领域之外，许多基础设施系统也试图将“执行状态”与“业务状态”分离开来。对于AI应用而言，这可能涉及复杂的抽象来追踪诸如当前步骤、下一步、等待状态、重试次数等信息。这种分离带来了复杂性，虽然有时是值得的，但对于你的使用场景来说可能有些过度。
一如既往，你应该根据自己的应用情况做出最适合的决定。但不要认为你必须分开管理它们。
更明确地说：
- 执行状态：当前步骤、下一步、等待状态、重试次数等。
- 业务状态：智能体工作流中目前已发生的内容（例如：OpenAI消息列表、工具调用及结果列表等）
如果可能的话，请简化——尽可能将它们统一起来。
[
]
实际上，你可以通过工程设计，使得所有执行状态都可以从上下文窗口中推断出来。在许多情况下，执行状态（当前步骤、等待状态等）仅仅是关于已发生事件的元数据。
你可能会有一些无法放入上下文窗口的内容，比如会话ID、密码上下文等，但你的目标应该是尽量减少这类内容。通过遵循原则3，你可以控制实际输入到大语言模型（LLM）中的内容。
这种方法具有多个优点：
- 简洁性：所有状态只有一个真实来源
- 序列化：线程可以轻松序列化/反序列化
- 调试：整个历史记录在一个地方可见
- 灵活性：只需添加新的事件类型即可轻松添加新状态
- 恢复：通过加载线程可以从任何点恢复执行
- 分支：通过将线程的某个子集复制到新的上下文/状态ID中，可以在任何点进行分支
- 人机界面与可观测性：可以轻松将线程转换为人类可读的Markdown或丰富的Web应用界面