业务方要的是「全自动」，我们给的是「半自动」 去年 12 月的评审会上，业务方提了一个需求：做一个能自动处理客诉的 Agent，从接到投诉到给出解决方案、执行补偿、发送通知，全链路不需要人。 我们的答复是：可以做，但要分阶段，且第一阶段必须有人工确认。对方不太满意，觉得我们在保守。这场会开了两个小时
上下文不是不够用，是没管好 我们的客服 Agent 用的是 128K 上下文的模型。上线初期大家的判断是「128K 够用了，不用操心上下文管理」。 三个月后我们把单次对话的平均 token 从 3,200 涨到了 26,000——不是因为业务变复杂，是因为我们没有做任何管理，历史消息无脑全带上。到第
Rod Johnson 又回来了，这次做的是 Agent 框架 看到 Embabel 的时候我愣了一下。作者是 Rod Johnson，Spring 的创始人。他 2025 年开始做这个框架，2026 年初发布了 1.0。 我花了一个月读源码、写了两个 POC。这篇记录我对它的理解，重点是 GOAP
把工作流改成 Agent 三个月后，我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流：告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent，让它自己决定调用什么工具、走几步。 跑了三个月，结论比较复杂：有些场景效果好得出乎意料，有些场
新项目选了 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",
实习生问我：为什么文档喂得越多，答案越差 七月份团队来了个实习生，负责维护我们的文档问答系统。他有天跑来问我一个问题：「我把 topK 从 5 调到 20，召回率肯定上去了吧？但测试集准确率从 71% 掉到 63%，是不是哪儿写错了？」 我看了下代码，没写错。这不是 bug，这是我们一直没认真对待的
一次发版，37 个跑了两小时的任务全没了 五月底的一次例行发版，我们的合同审核 Agent 服务重启。重启完没多久，业务部门来问："我昨天下午提交的那批合同怎么一直显示'审核中'？" 查了一下，那次重启时正在执行的 37 个长任务全部丢失，其中最长的已经跑了 2 小时 17 分钟，完成了 60 多个
