四十秒的任务撞上三十秒的超时 8 月 11 号,我们的工单自动处理 Agent 上线一周后,监控上出现一条难看的曲线:任务失败率 4.7%,失败原因几乎全是 UpstreamTimeout。 查了一下,原因很直白——这个 Agent 平均执行 11 秒,但 P99 是 41 秒。而我们网关的超时是
一条一星评价 8 月 6 号早上,应用商店来了条新评价,一星: 用了半个月,每次都要重新介绍一遍我的情况。上周让它记住的偏好,这周又忘了。同一家公司的人问同一个问题,答案还不一样,无语。 第二条倒是我们有意为之(不同角色权限不同),第一条是实打实的问题。 这篇记录我们做 Agent 记忆持久化的过程
财务对账发现两笔一模一样的退款 7 月 2 日上午,财务在群里贴了两行流水: 2026-07-01 22:14:07 RF2026070122140701 SO20260628009 -12,900.00 成功 2026-07-01 22:14:09 RF2026070122140903
业务方要的是「全自动」,我们给的是「半自动」 去年 12 月的评审会上,业务方提了一个需求:做一个能自动处理客诉的 Agent,从接到投诉到给出解决方案、执行补偿、发送通知,全链路不需要人。 我们的答复是:可以做,但要分阶段,且第一阶段必须有人工确认。对方不太满意,觉得我们在保守。这场会开了两个小时
上下文不是不够用,是没管好 我们的客服 Agent 用的是 128K 上下文的模型。上线初期大家的判断是「128K 够用了,不用操心上下文管理」。 三个月后我们把单次对话的平均 token 从 3,200 涨到了 26,000——不是因为业务变复杂,是因为我们没有做任何管理,历史消息无脑全带上。到第
半年 470 万次调用,10 个坑 我们的客服 Agent 是 2025 年 9 月上线的,到今天跑了半年多一点。数据:累计 470 万次对话,日均 2.6 万次,峰值 4.1 万次/天,P99 延迟 3.2 秒,月均 token 成本 7.8 万。 半年前上线的时候,我在周报里写「技术方案已验证,
新项目选了 LangChain4j,而不是继续用 Spring AI 我们团队的运维 Agent 一直是 Spring AI 写的,跑了半年挺稳。上个月开新项目——一个面向业务部门的合同审查 Agent,我评估了一圈,最后选了 LangChain4j。 这个决定在组内有争议,有人认为「统一技术栈」更
同一个问题跑五次,得到三种不同的结果 九月初用户反馈我们的运维 Agent 有时会给出错误的重启建议——明明是磁盘满了,它建议重启服务。我们拿到 session ID 去复现,同一个问题、同一份上下文,跑了五次: 次数 结论 步数 耗时 token 1 磁盘满,建议清理日志(正确) 4 18s 21
工单:「你们的 Agent 是不是失忆了」 六月份客服转过来一批工单,其中有条写得挺扎心:「你们的运维助手,我上周三让它排查过一次订单服务超时,昨天又超时了,它从零开始问我要服务名、要时间范围,像完全没见过我一样。是不是失忆了?」 我看了下那两个 session,确实是两套完全独立的对话。我们当时只
审计日志里那条被拦截的命令,让我出了一身冷汗 有天早上巡检,我在运维 Agent 的审计日志里翻到这么一条: { "ts": "2025-07-29T03:14:22.118Z", "sessionId": "sess-7f3a91c0", "userId": "u_zhangwei",