审计日志里那条被拦截的命令，让我出了一身冷汗 有天早上巡检，我在运维 Agent 的审计日志里翻到这么一条： { "ts": "2025-07-29T03:14:22.118Z", "sessionId": "sess-7f3a91c0", "userId": "u_zhangwei",
早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
实习生问我：为什么文档喂得越多，答案越差 七月份团队来了个实习生，负责维护我们的文档问答系统。他有天跑来问我一个问题：「我把 topK 从 5 调到 20，召回率肯定上去了吧？但测试集准确率从 71% 掉到 63%，是不是哪儿写错了？」 我看了下代码，没写错。这不是 bug，这是我们一直没认真对待的
财务拿着一张 14.7 万的账单来找我 六月初，财务同事拿着模型账单发消息给我："你们那个智能运维 Agent，上个月花了 14.7 万？预算不是 5 万吗？" 我一看确实超了快三倍，而且这个 Agent 上线才一个月，日均任务量只有 420 个左右。 我花了两天把账单拆开分析，发现问题比想象的有意
公司要求数据不出境，得换模型 四月底法务下了个通知：客服对话数据不能出境，我们正在用的海外模型必须换掉。当时系统基于 Spring AI 写的，第一反应是"换个 base-url 应该就行"，实际折腾了两周才稳定上线。 这篇记录接入国内模型的过程，主要是 Spring AI Alibaba 和 Op
订单系统线程池被一个"智能"功能打满 三月下旬的一个下午，监控突然报警：订单履约服务的 Tomcat 线程池活跃数从平时的 40 冲到 200（最大值），接口 P99 从 180ms 涨到 12s，大量订单卡在"待履约"状态。 排查过程很快。看线程 dump，200 个线程里有 187 个卡在同一个
产品说"用户上传截图自动填工单" 三月中旬产品提了个需求：用户报障时经常甩一张截图过来，客服要手工把里面的订单号、错误码、时间点一个个敲进工单系统，平均 90 秒一条，希望系统能自动识别和填充。听起来简单，做下来发现"看懂一张图"这件事在工程上的复杂度远超我的预期。 这篇记录我们在 Java 应用里
8.6 万份文档，Tika 抽出来的表格全是乱码 去年底接了个企业知识库的项目，要把公司十年积累的技术文档、产品手册、标书、合同模板全部灌进 RAG。总量 8.6 万份，PDF 占 45%，Word 30%，Excel 15%，剩下是 PPT 和 HTML。 第一版我图省事，直接用 Apache T
单次 Function Calling 撑不住，我上了 ReAct 去年 11 月我们给内部运维做了个助手，能查监控、查日志、查工单、执行标准操作。第一版用的是大模型的 Function Calling：把工具列表丢给模型，模型返回一个函数调用，我们执行完把结果拼进上下文，再问一次，直到它不再调工具
数据量涨到 2300 万，向量检索 P99 从 60ms 崩到 1.8 秒 我们的商品语义搜索，7 月份上线时是 420 万条向量，P99 稳定在 60 毫秒。到 10 月底商品库扩到 2300 万条，接口 P99 涨到 1820 毫秒，同时 Milvus 集群的内存水位长期在 91%，隔三差五触发
