四十秒的任务撞上三十秒的超时 8 月 11 号，我们的工单自动处理 Agent 上线一周后，监控上出现一条难看的曲线：任务失败率 4.7%，失败原因几乎全是 UpstreamTimeout。 查了一下，原因很直白——这个 Agent 平均执行 11 秒，但 P99 是 41 秒。而我们网关的超时是
一条一星评价 8 月 6 号早上，应用商店来了条新评价，一星： 用了半个月，每次都要重新介绍一遍我的情况。上周让它记住的偏好，这周又忘了。同一家公司的人问同一个问题，答案还不一样，无语。 第二条倒是我们有意为之（不同角色权限不同），第一条是实打实的问题。 这篇记录我们做 Agent 记忆持久化的过程
为什么开始看 AgentScope Java 我们团队的主力框架是 Spring AI 2.0，用了快一年。真正让我开始评估 AgentScope Java 2.0 的，是 6 月底一次多 Agent 协作的需求。 需求本身不复杂：一个"故障分析"场景，需要日志分析 Agent、代码检索 Agent
财务对账发现两笔一模一样的退款 7 月 2 日上午，财务在群里贴了两行流水： 2026-07-01 22:14:07 RF2026070122140701 SO20260628009 -12,900.00 成功 2026-07-01 22:14:09 RF2026070122140903
我们内部有 34 个 Agent，每家一套工具定义 今年年初做资产盘点，我发现一件事：公司里跑着 34 个 Agent（客服、运营、数据分析、运维助手……），它们调用的工具加起来有 210 多个，其中功能重叠的大概 60 个。 最典型的是「查订单」。客服 Agent 有一份实现，运营 Agent 有
「让运维 Agent 自己去问数据库 Agent」 四月份我们遇到一个需求：客服 Agent 在处理客诉时，需要判断「这个订单的物流是不是真的延误了」。这个判断需要的权限（查物流商内部系统、看历史延误率）我们不打算给客服 Agent。 常规解法是加一个工具。但那意味着把物流系统的权限开放出去，而且物
半年 470 万次调用，10 个坑 我们的客服 Agent 是 2025 年 9 月上线的，到今天跑了半年多一点。数据：累计 470 万次对话，日均 2.6 万次，峰值 4.1 万次/天，P99 延迟 3.2 秒，月均 token 成本 7.8 万。 半年前上线的时候，我在周报里写「技术方案已验证，
