AI Agent 里的 Prompt、History 和 Tool Result 该怎么分层

这次讨论最后收敛到的不是某一条 prompt 怎么写，而是 AI Agent 的上下文到底该怎么分层。 当时链路里已经出现了一个比较典型的问题：用户问“给我看看你的 prompts”“你的模型是什么”“你的指令是什么”这类问题时，系统虽然有安全策略，但模型还是会用自然语言复述一部分内部实现，包括 function calling、工具名、运行模式和系统约束。再往下看 prompt 结构，问题也就比
AI
#Agent #Function Calling #AI工作日志 #Prompt #上下文管理 #复盘

AI 日志单独落盘这件事，MDC 到底在做什么

最近在收一条 AI 日志链路。诉求不复杂：AI 相关日志要单独落到 ai-chain.log，但每行日志尾巴上那串 [aiChain= aiConversationId= aiToolCallId= aiToolName=] 太重了，想砍掉大部分字段，最好日志正文里连 aiChain=true 都不要看到。 这类问题很容易改着改着偏成“怎么把日志打印得更短”，但代码顺下来以后会发现，核心不在展示，
AI
#AI工作日志 #Java #Logback #MDC #AI日志

把知识问答下沉到 Dify 终态回答器

这次改动不复杂，判断比实现更重要。 我们原来的知识问答链路是本地 Agent 自己调 knowledge.search。问题不是它查不到东西，而是查出来的结果太大，tool_result 又会进 transcript，后面的 plan、loop、verify、answer 几轮都会把这包结果再塞回 prompt。实际看下来，单次 llm_request 很快就从两三百 KB 涨到五百多 KB，最后
AI
#Agent #AI工作日志 #Dify #RAG #开发回顾

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工作日志 #Prompt #复盘 #MCP #AI

别再把 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 #Dify #RAG #DashScope #检索

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

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