这次改造最有意思的地方，不是“把编排迁到 LangGraph”这件事本身，而是我们把一个常见工程陷阱踩出来又填平了： 到底是要“快速把 case 跑通”，还是要“把系统做成可长期治理”。 答案很明确：后者。 下面按真实时间线复盘，尽量给可复现证据，不讲玄学。 1. 讨论分歧：要不要用 fallback 快速过 case中途一度出现典型诱惑： 用户说“1号炉”，那就直接从 query 里正则提

这篇记录复盘最近两次连续提交： 76539e9：refactor(langgraph): 全量收口到MessagesState单一状态源 2138513：refactor(langgraph): 删除未激活respond节点并清理导出 一句话总结：把编排状态从“字段搬运工模式”改成“消息主链模式”，再把没上班的节点请出工位。 先说改造前的问题在这次重构前，编排链路同时维护几套上下文来源： q

调试 LangGraph 时，最容易踩的一个坑不是代码写错，而是脑子里把三件不同的东西混成了一件事： event checkpoint replay 表面看它们都能回答“这轮到底发生了什么”，于是很多项目自然会冒出一个问题： “既然 LangGraph 已经有 checkpoint 和 replay，我自己写的 event 机制是不是多余了？” 这个问题我最近在一套 AI 编排服务里来回掰扯了

这次改造的目标很朴素：让编排流程别再“断电失忆”。 项目原来已经有 LangGraph thread_id，也已经把澄清流程做成了 interrupt/resume 语义。但 checkpoint 用的是进程内内存 saver，服务重启后现场直接蒸发。于是用户问一句“继续”，系统看着你，内心是“我是谁我在哪”。 下面按 STAR 记录这次改造，顺便把关键 QA 和踩坑细节摊开讲清楚。 S

这周把一条很“能跑但不优雅”的链路，改成了真正可恢复的人在回路（HITL）语义。 一句话版本： 以前：clarification_needed -> final，一轮结束，下一轮靠外部再喂输入，图内语义断开。 现在：clarify 节点内 interrupt(payload) 挂起，用户补充后 Command(resume=...) 继续执行，图内闭环。 下面按工程复盘写清楚：问题是什么

这篇复盘写给已经在做 Agent/LLM 编排、并且被“历史包袱 + 线上契约 + 多系统联动”三连击过的工程师。 一句话版结论：这次不是“把代码搬到新目录”，而是把编排从“单文件扛全场”升级为“LangGraph 节点化 + 对外契约不动”的可演进内核。过程不炫技，核心是稳。 如果要用一句带点黑色幽默的话描述这次重构： 我们终于把 orchestrator.py 从“全栈菩萨”劝退成

背景在 iot-framework 的 AI 链路里，我们已经有一条稳定的工具调用架构： Java AI Gateway 对外暴露 /api/ai/* Python ats_iot_ai 负责编排与执行（LangGraph + SSE） Java MCP 负责 /ai/mcp/tools/list 与 /ai/mcp/tools/call 这次目标是把 Dify 知识库检索接成一个 tool，

这篇记录一次真实联调中的 P1 修复：同一个用户问题，本应触发澄清，却被错误归因为“模型不可用”。 STAR 复盘S（Situation）背景在 2026-03-05 的真实联调中，知识库工具链路已经打通，但出现了错误路由： 用户输入：帮我查知识库 实际事件：llm_request -> react_plan(parseStatus=schema_validation_failed) -&

背景在一次编排改造后，用户输入“帮我查今天的炉次生产情况”，系统返回了： 工具参数需要补充/修正（缺少参数: fnCode）… 这类回复有两个问题： 对话体验差：像在看内部错误，不像助手对话。 信息暴露风险：把内部参数名（fnCode）直接暴露给用户。 本文只记录编排与文案层面的坑和改造，不包含联调过程。 STAR 复盘S（Situation）当时的流程是： plan 识别到缺

这篇文章复盘 ats_iot_ai 这一轮重构的关键路径，重点覆盖三部分： 重构记录（发生了什么、按什么顺序推进） 工程收益（稳定性、可维护性、协作成本） 风险与后续计划（哪些问题还在，下一步怎么收敛） 文中时间线和提交号均来自本地仓库历史；敏感信息（内部域名、token、账号、绝对路径）已全部脱敏。 一、重构背景：为什么必须从“旧编排”走向节点化旧阶段的核心问题并不是“功能不工作”，而是“功