工作流 Agent 的上下文记忆分 两层，互不混淆，各司其职
📝 第一层
对话历史（messages）
给 LLM 看 · 每次调用都拼进 prompt
每次调 LLM 时，把之前所有的用户消息和系统回复拼进 prompt。
LLM 靠这个知道前面聊了什么，回复才连贯自然。
LLM 看到的上下文 = 对话历史 + 当前 step 的任务指令
LLM 看不到 = 状态定义、状态转移表、pending_params、推荐列表
编排器是"记住事情"的人
LLM 是每次被叫来帮忙的翻译官
🔒 第二层
工作流状态（workflow_state）
不给 LLM 看 · 编排器独占读写
存在 session_data.workflow_state 里，LLM 完全不知道它的存在。
编排器用它知道"现在该做什么"——选哪个 prompt、走哪条分支。
典型结构：
{ step: "awaiting_pickup_select", pending_params: {...}, recommended_pickups: [...] }
🎬 工作示例
编排器
读取 workflow_state.step → "awaiting_pickup_select"
编排器
选择 prompt：interpret_pickup_selection
编排器
拼 prompt：对话历史 + 推荐列表（A/B） + 用户输入"用B"
LLM
输出：{ "action": "select", "selected_index": 1 }
编排器
解析 JSON → 更新 workflow_state → 调算法 → 返回结果
⚡ 长对话优化策略
KV Cache 推理引擎
Transformer 自动缓存已算过的 Key/Value 矩阵。连续请求的前缀相同时，只算新增部分，不需要你写代码。vLLM / TGI / llama.cpp 原生支持。
Prompt 剪裁 编排器可控
不同步骤对历史的需求不同。意图分类看最近 5 轮就够了，选择解析只需要推荐列表 + 用户最新回复。编排器按步骤精细控制上下文长度。
历史摘要 编排器可控
对话超过几十轮时，用异步任务把早期对话压缩成一段摘要。后续 prompt 中用 摘要 + 最近N轮 替代全量历史。
检索增强 编排器可控
每轮提取关键信息存入向量数据库，需要时检索相关片段。适合信息量大、轮次极多的场景，你的提箱点工作流暂时用不上。
核心要点
✓ 两层记忆互不混淆——LLM 看到对话历史，编排器掌握工作流状态
✓ 每轮仅调 1-2 次 LLM，每次上下文有限，比 ReAct Agent 省得多
✓ KV Cache 自动吃掉重复前缀的开销，长对话成本增长是次线性的
✓ 按步骤精细控制上下文长度——不需要每次都全量历史