长连接撑不住了,我们花了三周做无状态化 我们最早那版 MCP Server 用的是 SSE 传输,从 2025 年 6 月跑到现在。四月份开始出问题:Agent 数量从 3 个涨到 11 个,MCP Server 的连接数冲到 4,000+,然后就是各种诡异的断连和内存上涨。 三月份决定做无状态化改
「Spring 是不是被 AI 时代落下了」 上个月团队里一个工作两年的同学问我:现在大家都在聊 LangChain、LlamaIndex、各种 Agent 框架,Spring 在这些话题里几乎不出现,是不是已经过时了? 这个问题我这两年听过很多次。我当时没直接回答,让他去看看 spring-ai
「为什么 Agent 调我们的接口总是调错」 去年 12 月,业务方提了个需求:让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗,把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%,其中大部分不是超时或
多智能体上线两周,成本涨了 6 倍 十一月份我们把合同审查从单 Agent 改成了多智能体——一个主管 Agent 负责任务分解,下面挂了四个专职 Agent(条款抽取、风险识别、合规比对、历史案例检索)。理由是单 Agent 的表现遇到瓶颈:一份 40 页的合同要塞进一次上下文,模型经常顾此失彼,
把工作流改成 Agent 三个月后,我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流:告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent,让它自己决定调用什么工具、走几步。 跑了三个月,结论比较复杂:有些场景效果好得出乎意料,有些场
四个服务里塞了四份大模型调用代码 年初我们把 AI 能力往业务里铺的时候,图快,哪个服务需要就直接引一份 spring-ai-openai,配个 key 开干。到六月底盘点,订单服务、客服服务、商品服务、报表服务里各有一套调用代码,四份 application.yml 里躺着四个 API Key。
我们有个 WebFlux 服务,没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的,三个接口、两千多行,但组里除了我没人愿意碰它。原因很简单:那套 Mono/Flux 的链式调用,加上 .flatMap() 里嵌套 .zip() 的写法,改起来要花两倍时间,而且出错后堆栈完全看不
三个团队写了三套几乎一样的东西 今年三月做季度复盘时,我们数了一下公司的 AI 建设:客服知识库、智能质检、合同审核,三个项目分属三个团队,各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是:三个项目都踩了同样的坑(
我们用传统架构设计 AI 应用,处处别扭 过去一年半我做了三个 AI 项目:客服知识库、智能质检、合同审核助手。回头看,第一个项目(2023 年底的知识库)踩的坑最多,原因不是技术不熟,而是我在用设计传统后端系统的方式设计它。 具体表现是:设计了标准的三层架构(Controller / Servic
早上九点收到的一条额度告警 2025 年 2 月底的一个周一,我刚进公司就收到运维的消息:"模型供应商账户额度用了 78%,平时这个时候只有 15%。" 紧接着业务群炸了,客服系统开始大面积报 429 Too Many Requests。 查了半小时,根因很朴素:上周五上线的智能质检功能有个循环调用