Spring AI 接存量 Java 服务时，我们上线前踩过的 5 个坑

小六九 · 2026-06-22T16:06:27.182Z

背景：最近在企业内部用 Spring AI + MCP，把已有的 RPC/HTTP 能力接到 Agent 侧。不是入门教程，主要是一些上线前才会撞上的问题，内容做了脱敏。 ## 坑 1：把 ChatClient 当万能入口，Tool 调用容易失控早期 Prompt 写的是「你是助手，尽量帮用户完成请求」，结果模型会连环调 Tool，甚至尝试调用没有权限的接口。后来改了几处： - System Prompt 里明确允许 Tool 白名单和禁止行为 - 服务端做二次鉴权，Tool 层校验用户身份，不能只信 Agent - 写操作默认走 confirm 流程 ## 坑 2：Tool Schema 太「Java」，模型看不懂一开始直接把内部 DTO 字段名暴露给模型，比如 participantOpenIdList、corpId，调用成功率很低。比较有效的做法是： - Schema 里补自然语言 description - 参数尽量少一点，语义清楚一点 - 枚举值给示例，不要只丢 int 码表 ## 坑 3：同步 RPC 直接包成 Tool，超时会拖死 Agent 有个 Tool 里面串了 5 个 RPC，只要其中一个慢，整个对话就会卡住。调整方式： - Tool 保持单一职责，设置短超时 - 长任务改成异步 + 轮询 Tool，或者推送通知 - 关键路径加熔断，不要让 Agent 触发重试风暴 ## 坑 4：没有「轨迹日志」，出问题没法复盘用户反馈「助理昨天删错了」，如果没有 Tool 调用链和参数快照，基本只能靠猜。后来补了这些： - 每次 Tool 调用记录 traceId、入参、出参摘要、耗时 - 敏感字段脱敏存储 - 发版前用固定评测集做回归 ## 坑 5：测试环境 Tool 连到了生产数据为了 Demo 快，Test Profile 误连了 prod 只读库。哪怕是只读，Agent 一旦误操作，也很容易变成事故。这块最后按比较硬的方式处理： - 环境硬隔离，配置中心 + 启动校验 - Test Tool 用 Mock 或沙箱租户 - Demo 账号权限最小化 ## Java 后端的优势实际接下来感觉 Java 后端不是没优势，反而很多现成能力能直接用： - 存量 Spring Boot、鉴权、配置中心可以复用 - MCP Server 可以和现有服务同 JVM，也可以 sidecar，不一定要推翻重来 - 限流、审计、灰度这些治理手段，团队本来就熟最后的感受是，Spring AI 不是加个依赖就能把系统变智能，工程化、权限和观测这些东西都得一起跟上。

发现产品榜单精选讨论