AI Agent 前沿调研：软能力下沉为硬能力、Skills、Subagents 与 Workflow 的真实趋势

结论先行 这轮跨 X / Reddit / Linux.do / GitHub / 论文 / 官方文档 调研后，最清晰的共识不是“让 agent 更自由”，而是： 把 自由裁量缩到少数高价值决策点 把 执行、验证、补参、审计、回放 下沉到 runtime / workflow / grader / skill 把 domain-specific 差异 优先做成 sk
AI
#AI工作日志 #LangGraph #ReAct #AI Agent #Workflow #Skills #Subagents #调研

从顶级 AI Agent 架构视角看这套 Python Agent 项目

我先给结论。 这个项目现在不是“做不成事”，而是已经到了一个很典型的拐点： 作为单智能体、少量工具、强业务约束的企业 Agent，它已经能跑通主链。 但它的可靠性主要靠 prompt + 少量 runtime 约束 + MCP 双视图 顶住。 一旦继续加工具、加查询类型、加多跳深度，复杂度会明显上升，而且会越来越依赖 prompt 特判。 从顶级 AI Agent 架构视角看，当前最值得做的不
AI
#AI工作日志 #AI Agent #架构评审 #MCP #Python #LLM

别再让 Agent 靠感觉停下来了：聊聊通用多跳规划能力怎么做

最近在调一条生产计划问答链时，碰到一个很典型的问题。 用户问的是“今天计划炉次有多少”，系统却在第一跳 production_plan_search 后就停了，直接把计划列表里的 count/total 当成了答案。真正需要的链路其实是： 先查计划，定位目标计划。 再查计划详情。 最后基于详情里的计划炉次做汇总。 这个问题看起来像“模型不够聪明”，但本质不是。更准确地说，是系统没有把“当前要回
AI
#Agent #Function Calling #MCP #AI #架构

AI Tool 回答为什么会泄漏内部字段名

这次踩坑点不在工具调用本身，而在回答阶段。 链路里工具已经查到了正确数据，tool_call -> tool_result 也没问题，最后给用户的 final 还是把内部字段名说了出来，比如： furnacePlans ladleBatchCountTarget 这类字段名即使业务含义没说错，也不该出现在用户可见回答里。问题不是“模型不懂业务”，而是我们把不该给它看的东西也一并塞进了回答
AI
#Agent #AI工作日志 #复盘 #MCP #AI #Prompt

别再把 Tool Result 整包喂给 Answer LLM 了

最近在收一条 AI 工具链路时，问题不是 tool schema 怎么写，也不是 function calling 到底该不该开，而是一个更容易被忽略的点：tool 调完之后，返回给后续节点的那份结果，到底该长什么样。 一开始最直觉的做法是，tool 查到了什么就把什么整体回传。Java 侧查出一个对象，塞进 ToolResult.data；Python 侧拿到这份结果，再把它整个塞给回答节点。看
AI
#Function Calling #AI工作日志 #AI Agent #MCP #架构设计 #Tool Calling

为什么我们的 RAG 还打不过 Dify 原生助手

最近在做一条自建 RAG 链路：Java 负责知识库工具调用，Python 负责编排和回答生成。链路能跑，双知识库也已经接上了，但同一个问题丢给 Dify 原生聊天助手，回答还是更稳，引用也更像“已经把资料看明白了再说话”。 这个差距一开始看着像模型问题，后来排下来，主要不是模型本身，而是检索编排层差得比较多。Dify 用的是一条完整的问答链路，我们现在更像是“从知识库捞几段文本出来，再让模型自己
AI
#AI工作日志 #复盘 #Python #RAG #Dify #DashScope #检索

AI Tool 调用里的 NotLogin 排查与线程级登录态注入

最近在一条 AI tool 调用链路里碰到一个典型问题：工具本身是从 Python 调 Java MCP，再进入 Java 里的业务 service，但执行到查库阶段时抛了 NotLoginException。表面看像是工具参数没带全，实际排下来，问题不在参数，而在历史业务代码对登录态的隐式依赖。 这次排查最后没有把整条链路改造成显式上下文传递，而是先做了一个线程级 LoginUser 注入的兼容
AI
#AI工作日志 #MCP #Java #Sa-Token #问题排查 #线程上下文

把 LangGraph 黑盒编排重构成精简 React Loop

这次重构之前，ats_iot_ai 的编排层已经有明显的黑盒感了。想改 prompt，不知道最终是在哪一步组装进去的；想追一轮对话历史，不知道该看 event、LangGraph state、checkpoint，还是 memory projection；想改一条澄清链路，最后会同时碰到 graph 节点、checkpoint 恢复、事件回放和 guardrail。 这套东西一开始是为了把更早的一
AI
#Agent #Function Calling #AI工作日志 #LangGraph #复盘 #React Loop #重构

把补参从模板里拿出来：Agent Clarify 改造成结构化 Tool Call

这次在改工业 AI 助手的编排层时，前面已经把 LangGraph + checkpoint 那层黑盒拆掉了，但 clarify 这件事还是不顺。问题不在“能不能让模型问用户要参数”，而在“这句补参话术到底应该由谁写”。 一开始很容易想到两条路： 继续把补参文案硬编码在工具 schema 里，比如 x-clarifyTemplate 让模型自己在普通 content 里判断这是补参还是最终回答
AI
#Agent #Function Calling #Clarify #工程复盘 #AI工作日志

把知识库检索参数交给 LLM，是一条错误的分层

线上知识库查询突然开始报参数错误，日志里看着像是 knowledge.search 接口坏了。再往前翻一层，会看到编排器已经把这轮调用打回了 CLARIFY，理由是 invalid_arg:score_threshold。用户只是想查知识库，结果系统先追问了一个相似度阈值。 这类问题最烦的地方不在于报错本身，而在于它表面上像工具执行失败，实际上是工具暴露面设计错了。知识库查询真正需要用户表达的只有
AI
#AI工作日志 #复盘 #AI #RAG #知识库