从顶级 AI Agent 架构视角看这套 Python Agent 项目
我先给结论。 这个项目现在不是“做不成事”，而是已经到了一个很典型的拐点： 作为单智能体、少量工具、强业务约束的企业 Agent，它已经能跑通主链。 但它的可靠性主要靠 prompt + 少量 runtime 约束 + MCP 双视图 顶住。 一旦继续加工具、加查询类型、加多跳深度，复杂度会明显上升，而且会越来越依赖 prompt 特判。 从顶级 AI Agent 架构视角看，当前最值得做的不
别再让 Agent 靠感觉停下来了：聊聊通用多跳规划能力怎么做
最近在调一条生产计划问答链时，碰到一个很典型的问题。 用户问的是“今天计划炉次有多少”，系统却在第一跳 production_plan_search 后就停了，直接把计划列表里的 count/total 当成了答案。真正需要的链路其实是： 先查计划，定位目标计划。 再查计划详情。 最后基于详情里的计划炉次做汇总。 这个问题看起来像“模型不够聪明”，但本质不是。更准确地说，是系统没有把“当前要回
AI Tool 回答为什么会泄漏内部字段名
这次踩坑点不在工具调用本身，而在回答阶段。 链路里工具已经查到了正确数据，tool_call -> tool_result 也没问题，最后给用户的 final 还是把内部字段名说了出来，比如： furnacePlans ladleBatchCountTarget 这类字段名即使业务含义没说错，也不该出现在用户可见回答里。问题不是“模型不懂业务”，而是我们把不该给它看的东西也一并塞进了回答
别再把 Tool Result 整包喂给 Answer LLM 了
最近在收一条 AI 工具链路时，问题不是 tool schema 怎么写，也不是 function calling 到底该不该开，而是一个更容易被忽略的点：tool 调完之后，返回给后续节点的那份结果，到底该长什么样。 一开始最直觉的做法是，tool 查到了什么就把什么整体回传。Java 侧查出一个对象，塞进 ToolResult.data；Python 侧拿到这份结果，再把它整个塞给回答节点。看
为什么我们的 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 里判断这是补参还是最终回答