很多人刚开始做 Agent 时，都会有一个很朴素的想法：既然模型吃上下文，那我就把能拿到的信息都给它。如果你把所有任务都交给同一套压缩规则，效果通常一般。模型不是只怕少，而是也怕多。大模型应用里最先炸掉的，往往不是模型本身，而是上下文。因为它们把一件以前很散的事，做成了一个明确的系统层。工具返回如果不做结构化整理，下一轮上下文还是会炸。把上下文压缩做好，Agent 才有机会把活干完。上下文虽然短了

记忆、RAG 和上下文管理，本质上是在帮 Agent 控制“知道多少、记住多少、每次看多少”。真正有用的 RAG，不是“召回很多”，而是“召回对的”。哪些是永久的，哪些是临时的，哪些是可覆盖的，要提前定义好。简单说，记忆负责“记住什么”，RAG 负责“去哪里找”，上下文管理负责“这次该喂给模型多少”。RAG 不是简单地“把文档搜一下”，而是一个完整链路：切片、索引、召回、重排、拼接、再交给模型。你

工具名要唯一工具描述要清楚输入 schema 要让模型看得懂有没有一堆queryexecuteprocess这种没语义的工具名是否足够具体输入输出是不是简单、可序列化、稳定很多线上“不稳定”，本质上是模型面对一堆描述模糊的工具时选择开始漂。模型是否支持你需要的 Tool Calling 能力？Prompt 是否已经结构化，而不是糊成大字符串？模板变量、JSON、渲染器规则是否一致？memory 和

你的模型支持吗？你的工具是挂在默认配置里，还是挂在这次请求里？你是不是以为默认工具和运行时工具会自动合并？写得是否足够具体？参数 schema 是否能让模型看懂？你有没有把打开？如果关闭了自动执行，你有没有自己继续跑 tool loop？工具方法有没有使用OptionalMonoFlux之类的类型？你现在看到的是“没触发”，还是“触发了但你没观察到”？把这 9 个点过一遍，大多数 Spring A

你的ChatClient是否真的挂了或其他 memory advisor？每次请求是否传了稳定的？你现在想解决的是“上下文连续性”，还是“完整历史归档”？你是不是还停在默认的？应用重启后记忆消失，是不是其实符合默认实现？的窗口大小够不够？你有没有频繁替换 system prompt，导致上下文结构变化？你是不是误以为 Tool Calling 的中间消息也会自动进 memory？

MCP 在官方授权文档里已经明确把认证、授权放到了协议层面考虑，尤其是基于 HTTP 的远程 MCP 场景，客户端和服务器需要通过标准授权机制建立可信访问关系。Spring AI 当前 MCP 安全支持文档里明确写了，这部分能力带有明显的演进属性，并强调了其面向 MCP Java SDK 社区实现的背景。这在单用户测试时往往没感觉，但到了线上，多轮对话、工具重试、上下文拼接、提示词污染一起叠加后，

Tool Calling 不触发，很多时候并不是“模型太笨”，而是工程链路里某一层没有对齐。我的经验是，先查注册、再查描述、再查 Prompt、最后查模型和网关，通常都能比较快定位到问题。如果后面要继续做 Spring AI 落地，我会更建议把这套排查顺序固化成清单，因为它真的比临场猜原因省时间得多。

Spring Boot 接 MCP 时出现超时，表面看像是“AI 太慢”，但实际常常是线程池、工具执行、配置不一致一起造成的。把链路拆开看，比直接围着模型转更容易定位问题。对这类系统来说，真正重要的不是一句“优化模型调用”，而是把整条链路的耗时结构看清楚。

EasyExcel 不是“替代所有 Excel 处理”的银弹，但在大数据量场景里，它确实比 POI 更顺手，也更稳。

我们网关那块已经用 Go 重写了」「K8s 组件基本都是 Go 写的」「Go 岗薪资比同资历 Java 高一截」Java 不香了吗？我现在学 Go 还来得及吗？这篇不贩卖焦虑，只讲事实、讲场景、讲路线。Go 不是要取代 Java，而是 Java 工程师最值得投资的第二语言。大厂不是要你用 Go 换掉 Java，而是要你会用 Go 补上高并发和云原生那块短板——而 Java 人的架构经验，恰恰是最快