以“客服工单办理”为例，从纯对话变为“可观测的任务流”。

🎯 文章目标

• 展示从聊天到任务流的演进路径
• 提供最小可运行样例（计划/工具/状态/回放）
• 输出上线所需的观测与评估要点

📚 背景/前置

• 初期：仅对话生成答案，无法闭环（无工具，无状态）
• 目标：具备“计划→工具→回放”的闭环能力

🔧 核心内容

1) 设计演进

• V0：对话问答（不可执行/无观测）
• V1：加入工具调用（可执行）
• V2：引入计划与回放（可解释/可调试）
• V3：状态机 + 队列（可恢复/可扩展）

2) 最小落地骨架

graph TD
  A[用户输入] --> B[规划]
  B --> C{工具选择}
  C -->|search| D[搜索工单]
  C -->|close| E[关闭工单]
  D --> F[回放/记录]
  E --> F

3) 关键实现片段

• 规划：JSON 结构 steps/goals/constraints
• 工具：JSON Schema + 幂等键
• 回放：保存入参/出参/错误，支持“替换单步”重跑
• 状态：队列/检查点/告警

💡 实战示例：对话到任务流（Node.js）

const plan = [{ step:1, action:'search', input:{ q:'退款' } }, { step:2, action:'close', input:{ id:'\{\{id\}\}' } ]
const msg = [{ role:'system', content:`计划:\${JSON.stringify(plan)}` }, { role:'user', content:'帮我关闭退款工单' }]

const r = await client.chat.completions.create({ model: process.env.CHAT_MODEL, messages: msg, tools })
// ... 解析 tool_calls 并执行

📊 对比/取舍（速查）

• 对话型：上手快，但不可执行、不可观测
• 任务流：成本更高，但可维护、可扩展

🧪 踩坑与经验

• 没有计划与回放，问题难以复现
• 不做幂等与检查点，长任务易失控

📎 参考与延伸

• ReAct、Plan-and-Execute
• 工作流引擎与任务队列

💭 总结

• 用“计划 + 工具 + 状态 + 回放 + 观测”把对话变为任务流，提升可控性