系列：100 天系统学习 AI Agent 开发
当前阶段：LangChain 与 LangGraph 工程化
今日目标：流式输出能改善长任务体验，也能展示工具调用、状态变化和中间结果。

1. 先给结论

进入「LangChain 与 LangGraph 工程化」之后，我明显感觉 Agent 开发不只是 Prompt 技巧了。流式输出能改善长任务体验，也能展示工具调用、状态变化和中间结果。 这件事越早建模，后面流程越不容易散。

2. 从工程视角看

• 状态：把任务进度、用户上下文、工具结果和错误信息显式保存。
• 节点：每个节点只处理一个清晰步骤，便于调试和替换。
• 路由：用条件边或规则决定下一步，关键路径不要完全交给模型猜。

3. 动手清单

今天的主任务是：设计一个前端事件列表：message_delta、tool_start、tool_end、final_answer。

我会按这个节奏做：

1. 先画状态，再写节点，最后补路由条件。
2. 完成主题任务：设计一个前端事件列表：message_delta、tool_start、tool_end、final_answer。
3. 检查每个节点的输入、输出、失败处理和是否需要 checkpoint。

4. 最小可交付物

今天可以留下一个最小状态图，先把流程跑顺：

5. 避坑笔记

我今天给自己设一个发布门槛：这篇文章不能只像学习笔记，还要像一块项目积木。

• 积木名称：Streaming 体验
• 应该放进项目的材料：一个状态图、节点表或 checkpoint 草案
• 读者收藏它的理由：读者看完能把一个长任务拆成可恢复的工作流
• 不达标就返工的原因：不要把所有内部推理暴露给用户。展示可解释事件即可。

面试官会追问：Streaming 应该展示“思维链”吗？

不应该把模型的私有推理原样展示给用户。真正有用的是可验证的事件：正在检索哪个知识库、某个工具是否开始或失败、是否等待审批、当前处于哪个业务阶段。它们能提升掌控感，也不会把不稳定的内部推理包装成事实。

事件协议可以统一为 run_started、stage_changed、tool_started、tool_finished、approval_required、message_delta、run_finished。每个事件带 sequence_id，前端断线重连后从最后序号续传；服务端仍以持久化状态为准，SSE 只是展示通道。

测试重点是乱序、重复和重连。若相同 tool_finished 被收到两次，UI 不应显示两份结果；若流断了，任务也不能被误判为失败。

今日检查清单

• 检查标题里是否有明确技术词：Streaming 体验
• 检查正文有没有围绕这个任务展开：设计一个前端事件列表：message_delta、tool_start、tool_end、final_answer。
• 检查风险提醒是否具体到动作：不要把所有内部推理暴露给用户。展示可解释事件即可。
• 给每个节点写清输入、输出、失败时去哪
• 标出哪一步需要 checkpoint 或人工确认
• 写一句“我明天会怎么继续”