压测时 Agent 读到了三小时前的数据 7 月 18 日我们对知识问答 Agent 做季度压测。压到 1,200 QPS 的时候，测试同学反馈一个问题：刚在后台改的商品价格，问 Agent 还是旧值。 一开始我以为是缓存。查了一圈发现不是——向量库里的切片更新时间是三小时前，而业务库的变更早就提交
这个月面了 12 个人，一个 offer 都没发 7 月我们团队要扩两个人，我前后面了 12 个候选。八年以上经验、带过项目、简历上都写着"熟悉大模型应用开发"。 结果不太好看。问"RAG 怎么做的"，八个人能完整背出切分、向量化、召回、重排这条链路；再问"你怎么验证召回效果变好了"，六个人答不上来
「Spring 是不是被 AI 时代落下了」 上个月团队里一个工作两年的同学问我：现在大家都在聊 LangChain、LlamaIndex、各种 Agent 框架，Spring 在这些话题里几乎不出现，是不是已经过时了？ 这个问题我这两年听过很多次。我当时没直接回答，让他去看看 spring-ai
「客户 A 能看到客户 B 的知识库内容」 三月份的一次安全测试，外部团队提了一个问题：他们用 A 公司的账号登录后，通过构造特定的查询，让 Agent 返回了 B 公司的产品文档片段。 这个问题很严重，我们当天就成立了专项。这篇记录多租户隔离的四层设计、每一层我们实际用的方案，以及成本计量那块（这
长连接撑不住了，我们花了三周做无状态化 我们最早那版 MCP Server 用的是 SSE 传输，从 2025 年 6 月跑到现在。四月份开始出问题：Agent 数量从 3 个涨到 11 个，MCP Server 的连接数冲到 4,000+，然后就是各种诡异的断连和内存上涨。 三月份决定做无状态化改
「为什么 Agent 调我们的接口总是调错」 去年 12 月，业务方提了个需求：让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗，把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%，其中大部分不是超时或
多智能体上线两周，成本涨了 6 倍 十一月份我们把合同审查从单 Agent 改成了多智能体——一个主管 Agent 负责任务分解，下面挂了四个专职 Agent（条款抽取、风险识别、合规比对、历史案例检索）。理由是单 Agent 的表现遇到瓶颈：一份 40 页的合同要塞进一次上下文，模型经常顾此失彼，
把工作流改成 Agent 三个月后，我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流：告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent，让它自己决定调用什么工具、走几步。 跑了三个月，结论比较复杂：有些场景效果好得出乎意料，有些场
入行第八年，回头看自己踩过的坑 十月底做年度复盘，翻出了 2018 年到现在的 git 提交记录和几份老的设计文档。有些代码现在看会脸红，但正是那些代码让我走到了现在。这篇不写技术，写成长路径上几个真实的转折点和代价。 前两年：我以为技术就是知道更多 API 2018 年刚入行，在一家做仓储系统的公
