把 LangGraph 黑盒编排重构成精简 React Loop
这次重构之前，ats_iot_ai 的编排层已经有明显的黑盒感了。想改 prompt，不知道最终是在哪一步组装进去的；想追一轮对话历史，不知道该看 event、LangGraph state、checkpoint，还是 memory projection；想改一条澄清链路，最后会同时碰到 graph 节点、checkpoint 恢复、事件回放和 guardrail。 这套东西一开始是为了把更早的一
把补参从模板里拿出来：Agent Clarify 改造成结构化 Tool Call
这次在改工业 AI 助手的编排层时，前面已经把 LangGraph + checkpoint 那层黑盒拆掉了，但 clarify 这件事还是不顺。问题不在“能不能让模型问用户要参数”，而在“这句补参话术到底应该由谁写”。 一开始很容易想到两条路： 继续把补参文案硬编码在工具 schema 里，比如 x-clarifyTemplate 让模型自己在普通 content 里判断这是补参还是最终回答
把知识库检索参数交给 LLM，是一条错误的分层
线上知识库查询突然开始报参数错误，日志里看着像是 knowledge.search 接口坏了。再往前翻一层，会看到编排器已经把这轮调用打回了 CLARIFY，理由是 invalid_arg:score_threshold。用户只是想查知识库，结果系统先追问了一个相似度阈值。 这类问题最烦的地方不在于报错本身，而在于它表面上像工具执行失败，实际上是工具暴露面设计错了。知识库查询真正需要用户表达的只有
给 AI 调用链单独开一本日志：用 MDC 给入口打标，再让 Logback 分流
有些系统的日志看起来很热闹，真正出事时却像在翻一本错页的电话簿。 我这次碰到的是 AI tool call 链路。需求说起来不复杂：希望 AI 触发的一整条调用链，包含内部 service、support、mapper 打出来的 info 和 error，都能在一个单独文件里找到。麻烦在后半句。那些组件并不专门服务 AI，平时还有普通业务流量在调它们。按包名单独切文件当然省事，代价是非 AI 请求
单 Agent 编排里，Prompt、JSON Schema 与 Function Calling 该怎么收口
最近我把一个 FastAPI + LangGraph 的控制平面，从“多节点编排”一路砍到“单节点 Agent Loop”。 砍到最后，最费脑子的地方已经不是“节点怎么连”，而是这三个问题： prompt 里到底该塞什么。 工具的输入约束到底该放在哪一层。 如果要接官方 function calling，它和现在这套 response schema + JSON 解析 有什么本质区别。 这篇就
把多节点 Agent 编排压成单节点 ReAct：一次真实重构复盘
前段时间我把一条原本还算“规矩”的 Agent 编排链路，硬生生压成了单节点。 原始版本大概是这种气质： bootstrap plan tool_validate tool_call clarify chat 看起来层次分明，像一张写给评审看的 UML 图。真跑起来以后，感受更像在组装机关枪，每多一个节点，代码体积、状态字段、测试断言和联调排查成本就跟着长。 这篇文章记录的就是一次比较彻底的收
MCP、Tool Spec 与 Function Calling：别把三层协议揉成一锅粥
前言最近排查一条 AI 工具链路时，最容易把人绕进去的不是模型发疯，也不是某个参数名写错，而是脑子里把三层东西混成了一层： Java 侧维护的 AiTool / ToolSpec Python 侧拿到的 tool list / schema 模型侧的 function calling / tool calling 一开始看起来都像“工具定义”。看久了就会产生一种错觉：既然都有 name + d
一场被 pip 镜像污染带偏的 Python 升级故障：从 RemoteDisconnected 到干净 venv
这篇文章整理自一段公开聊天记录，主题很朴素：一台 Ubuntu 服务器上，项目本来只是想装依赖，结果 pip install -r requirements.txt 一路刷出 RemoteDisconnected('Remote end closed connection without response')。乍看像镜像站抽风，再看像 Python 3.11 升级后遗症，继续看又像