LangGraph HITL 重构复盘：从一次性澄清到可恢复编排
这周把一条很“能跑但不优雅”的链路，改成了真正可恢复的人在回路（HITL）语义。 一句话版本： 以前：clarification_needed -> final，一轮结束，下一轮靠外部再喂输入，图内语义断开。 现在：clarify 节点内 interrupt(payload) 挂起，用户补充后 Command(resume=...) 继续执行，图内闭环。 下面按工程复盘写清楚：问题是什么
LangGraph 编排重构实录：拆编排不拆对外契约（STAR）
这篇复盘写给已经在做 Agent/LLM 编排、并且被“历史包袱 + 线上契约 + 多系统联动”三连击过的工程师。 一句话版结论：这次不是“把代码搬到新目录”，而是把编排从“单文件扛全场”升级为“LangGraph 节点化 + 对外契约不动”的可演进内核。过程不炫技，核心是稳。 如果要用一句带点黑色幽默的话描述这次重构： 我们终于把 orchestrator.py 从“全栈菩萨”劝退成
Dify 知识库 Tool 集成策略：Java MCP 与 Python 双路径
背景在 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解析失败恢复：从误报模型不可用到可恢复澄清链路
这篇记录一次真实联调中的 P1 修复：同一个用户问题，本应触发澄清，却被错误归因为“模型不可用”。 STAR 复盘S（Situation）背景在 2026-03-05 的真实联调中，知识库工具链路已经打通，但出现了错误路由： 用户输入：帮我查知识库 实际事件：llm_request -> react_plan(parseStatus=schema_validation_failed) -&
直接回复未走 Chat 优化的踩坑复盘（STAR）
背景在一次编排改造后，用户输入“帮我查今天的炉次生产情况”，系统返回了： 工具参数需要补充/修正（缺少参数: fnCode）… 这类回复有两个问题： 对话体验差：像在看内部错误，不像助手对话。 信息暴露风险：把内部参数名（fnCode）直接暴露给用户。 本文只记录编排与文案层面的坑和改造，不包含联调过程。 STAR 复盘S（Situation）当时的流程是： plan 识别到缺
ats_iot_ai 重构复盘：从旧编排到 LangGraph 节点化拆分
这篇文章复盘 ats_iot_ai 这一轮重构的关键路径，重点覆盖三部分： 重构记录（发生了什么、按什么顺序推进） 工程收益（稳定性、可维护性、协作成本） 风险与后续计划（哪些问题还在，下一步怎么收敛） 文中时间线和提交号均来自本地仓库历史；敏感信息（内部域名、token、账号、绝对路径）已全部脱敏。 一、重构背景：为什么必须从“旧编排”走向节点化旧阶段的核心问题并不是“功能不工作”，而是“功
踩坑复盘：ObjectMapper 被覆盖引发 shiftBeginAt/shiftDate 连锁异常
这次排障最核心的坑，不是某个 DTO 字段写错，而是 ObjectMapper 被覆盖后出现多实例分叉。shiftBeginAt 返回数组、shiftDate 反序列化报错，是同一个根因触发的两个表象。 关联提交（按你本地排障记录）： 8ba6d3c5914c23f29cd52f5326c79af4a0e8eced 49957ccc62e80014546bf5a62685e9c73f0d8000
一次被 Metadata Lock 隐藏的 AI 聊天故障：从 CommunicationsException 到长事务排查
这篇文章记录一次线上故障：Java 应用里一条普通查询，最终抛出来的是 CommunicationsException。表面看像网络或连接池问题，实际是被 DDL 等待放大的 metadata lock。 排查过程横跨 4 层： MySQL DDL 与 metadata lock 机制 JDBC 驱动的超时表现 连接池里的空闲连接与未结束事务 应用层对异常语义的误判 先说结论根因是： 某些旧