归档

周会上被问住了 6 月底的架构周会，组里一个同学问："Spring 官方和 DeepSeek 合作之后，我们要不要把模型调用层切到官方 starter？" 我当时答不上来。这两年"XX 与 XX 达成合作"的新闻太多了，大部分最后落在 PPT 上。我没有花时间验证过，就不能在会上拍板，于是给自己派了

红队测试甩过来一张截图 6 月中旬，安全组在我们客服 Agent 上做了一轮红队测试。第二天他们丢过来一段对话记录，最后一句模型输出是一串完整的身份证号——那是用户第一轮就提供的、我们已经脱敏过的号码。 我们的敏感词库有 12,800 条规则，身份证正则也在里面。为什么没拦住？ 这篇记录我们随后两周

同事在群里甩了一张截图 上周三下午，运营在群里 @ 我，配了张图：用户问"退款多久到账"，机器人答"7 个工作日内"。而政策文档在 6 月 2 日就改成了"3 个工作日"。 后台里那份 PDF 更新时间是 6 月 2 日 15:47，状态"已解析、已入库"。文档是新的，索引里的内容是旧的。 这篇记录

语义缓存上线一个月，命中率 8.3% 三月份我们给客服 Agent 上了语义缓存，预期是「相似问题不用重复问模型，能省一大笔钱」。上线一个月看数据，命中率 8.3%，省下的钱还不够维护缓存本身的成本。 这篇文章记录我们怎么把命中率从 8.3% 提到 41%，以及中途推翻重做的一版设计。 先看为什么这

从 JDK 21 切到 25，同样的服务堆占用降了 19% 我们一个文档问答服务在 JDK 21 上跑了快两年，堆峰值 4.8 GB，一直想降但找不到好办法——该做的代码优化都做了，GC 参数也调过了。 四月份我们把它切到了 JDK 25，只加了一个参数，堆峰值降到 3.9 GB。这个改动是 JEP

「让运维 Agent 自己去问数据库 Agent」 四月份我们遇到一个需求：客服 Agent 在处理客诉时，需要判断「这个订单的物流是不是真的延误了」。这个判断需要的权限（查物流商内部系统、看历史延误率）我们不打算给客服 Agent。 常规解法是加一个工具。但那意味着把物流系统的权限开放出去，而且物

GA 在下个月，我们这个月就已经在迁了 Spring AI 2.0 的 GA 定在 2026 年 6 月。我们在 5 月初就拉了 2.0.0-RC1 做迁移演练，到今天两周，9 个服务里有 6 个跑通了。 为什么不等 GA？因为 1.x 到 2.0 的破坏性变更比想象中多，我们评估过，等 GA 再动

「客户 A 能看到客户 B 的知识库内容」 三月份的一次安全测试，外部团队提了一个问题：他们用 A 公司的账号登录后，通过构造特定的查询，让 Agent 返回了 B 公司的产品文档片段。 这个问题很严重，我们当天就成立了专项。这篇记录多租户隔离的四层设计、每一层我们实际用的方案，以及成本计量那块（这

长连接撑不住了，我们花了三周做无状态化 我们最早那版 MCP Server 用的是 SSE 传输，从 2025 年 6 月跑到现在。四月份开始出问题：Agent 数量从 3 个涨到 11 个，MCP Server 的连接数冲到 4,000+，然后就是各种诡异的断连和内存上涨。 三月份决定做无状态化改

业务方要的是「全自动」，我们给的是「半自动」 去年 12 月的评审会上，业务方提了一个需求：做一个能自动处理客诉的 Agent，从接到投诉到给出解决方案、执行补偿、发送通知，全链路不需要人。 我们的答复是：可以做，但要分阶段，且第一阶段必须有人工确认。对方不太满意，觉得我们在保守。这场会开了两个小时