为什么我们的 RAG 还打不过 Dify 原生助手
最近在做一条自建 RAG 链路：Java 负责知识库工具调用，Python 负责编排和回答生成。链路能跑，双知识库也已经接上了，但同一个问题丢给 Dify 原生聊天助手，回答还是更稳，引用也更像“已经把资料看明白了再说话”。 这个差距一开始看着像模型问题，后来排下来，主要不是模型本身，而是检索编排层差得比较多。Dify 用的是一条完整的问答链路，我们现在更像是“从知识库捞几段文本出来，再让模型自己
AI Tool 调用里的 NotLogin 排查与线程级登录态注入
最近在一条 AI tool 调用链路里碰到一个典型问题：工具本身是从 Python 调 Java MCP，再进入 Java 里的业务 service，但执行到查库阶段时抛了 NotLoginException。表面看像是工具参数没带全，实际排下来，问题不在参数，而在历史业务代码对登录态的隐式依赖。 这次排查最后没有把整条链路改造成显式上下文传递，而是先做了一个线程级 LoginUser 注入的兼容
把 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 图。真跑起来以后，感受更像在组装机关枪，每多一个节点，代码体积、状态字段、测试断言和联调排查成本就跟着长。 这篇文章记录的就是一次比较彻底的收