归档

从 2023 年 9 月到今天，虚拟线程我们用了两年半 JDK 21 发布是 2023 年 9 月，我们当年 11 月就把一个内部服务切到了虚拟线程，算是比较早的一批。到今天两年半，虚拟线程跑在我们 14 个服务上，处理过峰值 4.7 万 QPS 的流量，也引发过两次 P2 故障。 这篇不写原理，只

「为什么 Agent 调我们的接口总是调错」 去年 12 月，业务方提了个需求：让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗，把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%，其中大部分不是超时或

一月的架构评审上，有人提议全量升 Spring Boot 4 开年第一次架构评审，议题是把公司 47 个 Java 服务统一升到 Spring Boot 4。提这个的人理由很充分：Boot 3.5 的 OSS 支持快到期，Spring AI 2.0 的里程碑版本已经明确要求 Boot 4 基线，晚动

年初做技术盘点：Java 的启动性能和 AOT，现在到哪一步了 每年一月我会花几天时间把 Java 生态的重点项目过一遍，看看有哪些东西从「观望」变成了「可以用」。今年重点看了三块：Leyden 的进展、AOT 生态的成熟度、以及启动性能的现状。 结论先说：JDK 25 这一代，启动性能有了不需要改

多智能体上线两周，成本涨了 6 倍 十一月份我们把合同审查从单 Agent 改成了多智能体——一个主管 Agent 负责任务分解，下面挂了四个专职 Agent（条款抽取、风险识别、合规比对、历史案例检索）。理由是单 Agent 的表现遇到瓶颈：一份 40 页的合同要塞进一次上下文，模型经常顾此失彼，

向量检索选型：我们算了一笔账，最后没上专业向量库 十月份做知识库检索重构，团队里争论要不要上 Milvus 或者 Qdrant。我们已经在用 PostgreSQL（存业务数据 + 元数据），pgvector 扩展是顺手的选择，但大家都担心性能不行。 最后我们做了完整的压测和成本核算，结论是继续用 p

把工作流改成 Agent 三个月后，我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流：告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent，让它自己决定调用什么工具、走几步。 跑了三个月，结论比较复杂：有些场景效果好得出乎意料，有些场

同事问：MCP 不就是 Function Calling 换了个名字吗 上个月内部分享会，我讲完 MCP 之后有同事问了这个问题。当时我答得不太好，说了些「更标准化」「生态更好」之类的空话。后来我认真想了想，也去读了规范原文，这篇算是个正经的回答。 结论是：不是换名字，是两个层次的东西。Functi

流式对话服务 OOM，堆转储里有 47 万个 ByteBuffer 十一月中旬的一个周一早上，告警炸了：智能客服服务的三个实例在 20 分钟内相继 OOM 重启。这个服务上线两个月一直很稳，堆 8 GB，平时使用率 40% 左右。 这篇是完整的排查过程。结论不复杂——流式响应没有正确关闭，但排查过程

新项目选了 LangChain4j，而不是继续用 Spring AI 我们团队的运维 Agent 一直是 Spring AI 写的，跑了半年挺稳。上个月开新项目——一个面向业务部门的合同审查 Agent，我评估了一圈，最后选了 LangChain4j。 这个决定在组内有争议，有人认为「统一技术栈」更