「让运维 Agent 自己去问数据库 Agent」 四月份我们遇到一个需求：客服 Agent 在处理客诉时，需要判断「这个订单的物流是不是真的延误了」。这个判断需要的权限（查物流商内部系统、看历史延误率）我们不打算给客服 Agent。 常规解法是加一个工具。但那意味着把物流系统的权限开放出去，而且物
「客户 A 能看到客户 B 的知识库内容」 三月份的一次安全测试，外部团队提了一个问题：他们用 A 公司的账号登录后，通过构造特定的查询，让 Agent 返回了 B 公司的产品文档片段。 这个问题很严重，我们当天就成立了专项。这篇记录多租户隔离的四层设计、每一层我们实际用的方案，以及成本计量那块（这
长连接撑不住了，我们花了三周做无状态化 我们最早那版 MCP Server 用的是 SSE 传输，从 2025 年 6 月跑到现在。四月份开始出问题：Agent 数量从 3 个涨到 11 个，MCP Server 的连接数冲到 4,000+，然后就是各种诡异的断连和内存上涨。 三月份决定做无状态化改
半年 470 万次调用，10 个坑 我们的客服 Agent 是 2025 年 9 月上线的，到今天跑了半年多一点。数据：累计 470 万次对话，日均 2.6 万次，峰值 4.1 万次/天，P99 延迟 3.2 秒，月均 token 成本 7.8 万。 半年前上线的时候，我在周报里写「技术方案已验证，
业务方要的是「全自动」，我们给的是「半自动」 去年 12 月的评审会上，业务方提了一个需求：做一个能自动处理客诉的 Agent，从接到投诉到给出解决方案、执行补偿、发送通知，全链路不需要人。 我们的答复是：可以做，但要分阶段，且第一阶段必须有人工确认。对方不太满意，觉得我们在保守。这场会开了两个小时
上下文不是不够用，是没管好 我们的客服 Agent 用的是 128K 上下文的模型。上线初期大家的判断是「128K 够用了，不用操心上下文管理」。 三个月后我们把单次对话的平均 token 从 3,200 涨到了 26,000——不是因为业务变复杂，是因为我们没有做任何管理，历史消息无脑全带上。到第
Rod Johnson 又回来了，这次做的是 Agent 框架 看到 Embabel 的时候我愣了一下。作者是 Rod Johnson，Spring 的创始人。他 2025 年开始做这个框架，2026 年初发布了 1.0。 我花了一个月读源码、写了两个 POC。这篇记录我对它的理解，重点是 GOAP
「能不能不装 Python」 起因是运维同事的一个要求。我们的一个内部 Agent 需要在客户机房部署，而客户的环境管控很严：不能装 Python，不能连外网，只能给一个 JAR 包和一个 JDK 21。 我第一反应是这个需求没法满足——跑模型怎么可能不用 Python。然后我想起去年在技术雷达里标
「我们的知识库问答准确率只有 71%，要不要做微调」 去年 11 月，业务方拿着一份评测报告来找我：客服问答准确率 71%，离可用的 85% 差得远。他们的结论是「做微调，把行业知识训进模型」。 我说先别急，让我把两条路都跑一遍再决定。这篇是三个月实测的结果，包括所有成本数字。结论先放：我们最后选了
「为什么 Agent 调我们的接口总是调错」 去年 12 月，业务方提了个需求：让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗，把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%，其中大部分不是超时或
