客服转来一条投诉：AI 给用户编了个退款政策 十月底，客服同学转来一条用户投诉，附了聊天截图： 用户：我这个订单上周下的，还能退吗？ 机器人：可以的，我们支持 15 天内无理由退款，您直接在订单页面点击申请退款即可。 用户：我看到页面上写的是 7 天？ 机器人：抱歉造成困扰，7 天是普通商品的标准，
入行第八年，回头看自己踩过的坑 十月底做年度复盘，翻出了 2018 年到现在的 git 提交记录和几份老的设计文档。有些代码现在看会脸红，但正是那些代码让我走到了现在。这篇不写技术，写成长路径上几个真实的转折点和代价。 前两年：我以为技术就是知道更多 API 2018 年刚入行，在一家做仓储系统的公
两个同事为「提示词改版有没有用」吵了一周 九月份我们改了一版运维 Agent 的系统提示词，主要变化是加了「先确认信息是否充分，再决定调用工具」这一段。改完之后团队内部炸了： 小王说「明显变准了，我测的几个问题都对」；老李说「变差了，现在它老是不干活，一直问我问题」。两人各举了三四个例子，都很有说服
分代 ZGC 在我们的网关上跑了一年 去年十月，我们把 API 网关从 G1 换成了分代 ZGC，到这个月正好一年。这篇是完整的数据总结，包括参数、遇到的四个问题、以及我现在的看法。 先说结论：换成 ZGC 是我们这一年最值的一次技术决策，但它不是银弹，而且代价被大多数人低估了。 背景：为什么要换
同一个问题跑五次，得到三种不同的结果 九月初用户反馈我们的运维 Agent 有时会给出错误的重启建议——明明是磁盘满了，它建议重启服务。我们拿到 session ID 去复现，同一个问题、同一份上下文，跑了五次： 次数 结论 步数 耗时 token 1 磁盘满，建议清理日志（正确） 4 18s 21
把 AI 服务压到 3000 QPS 之后，GC 曲线完全变了 我们有个文档问答服务，跑在 JDK 21 + G1 上，原来堆 4G，Young 区 1.2G，日均 800 万次调用，GC 表现平平无奇：Young GC 每 8 秒一次，单次 25ms 左右，Full GC 一周见不到一次。 八月份
给公司内部的 CMDB 写了个 MCP Server 八月份我们决定把内部 CMDB、发布系统、监控平台接进 Agent。一开始想的是直接写 Function Calling，写了两周发现每个 Agent 框架（我们内部有 Spring AI 和 LangChain4j 两套）都要实现一遍，工具定义
从 3.3.5 升到 3.5.3，踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定，实际花了九天，中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论：值得升，但别在业务高峰期前升。ServiceConnection 和结
工单：「你们的 Agent 是不是失忆了」 六月份客服转过来一批工单，其中有条写得挺扎心：「你们的运维助手，我上周三让它排查过一次订单服务超时，昨天又超时了，它从零开始问我要服务名、要时间范围，像完全没见过我一样。是不是失忆了？」 我看了下那两个 session，确实是两套完全独立的对话。我们当时只
审计日志里那条被拦截的命令，让我出了一身冷汗 有天早上巡检，我在运维 Agent 的审计日志里翻到这么一条： { "ts": "2025-07-29T03:14:22.118Z", "sessionId": "sess-7f3a91c0", "userId": "u_zhangwei",
