1. 从能跑通到能记住Agent 开发的分水岭在哪如果你已经用 Spring AI 2.0 搭过一个能对话、能调工具的 Agent大概率会经历这样一个阶段Demo 演示时一切正常一旦放进真实业务里连续跑上十几轮问题就全冒出来了。用户上一句说我叫老张下一句问你还记得我叫什么吗Agent 一脸茫然多轮任务执行到一半中间状态丢了只能从头再来上下文越堆越长Token 消耗飙升响应越来越慢最后直接报 out of memory。这些现象背后其实是同一类问题Agent 的 Memory记忆、State状态和 Context Engineering上下文工程没有设计好。很多人把 Agent 开发理解成接个大模型 挂几个工具函数但真正区分一个玩具 Agent 和一个生产级 Agent 的恰恰是这三块。模型能力是天花板而 Memory、State、Context 决定了你能不能摸到那个天花板。这篇内容我打算把 Spring AI 2.0 里 Agent 进阶的这三块技术全景拆开讲。不是照本宣科念文档而是结合我自己踩过的坑把为什么这么设计实际怎么落地哪些地方最容易翻车讲清楚。适合已经用 Spring AI 跑通过基础 Agent、想往生产级方向推进的开发者也适合正在做 Agent 框架选型、需要理解记忆与状态机制底层逻辑的技术负责人。读完你应该能自己判断什么场景该用哪种记忆策略状态该存在哪上下文该怎么裁剪。先说一个反直觉的结论大部分 Agent记不住的问题根本不是模型不行而是你的上下文管理策略错了。模型本身是无状态的它每次看到的只是你喂给它的那段文本。所谓记忆本质上是你在每一轮请求里把哪些历史信息重新拼进了 Prompt。理解这一点后面所有的技术选择都会顺理成章。2. Memory 不是存聊天记录而是分层的信息调度2.1 短期记忆与长期记忆的本质区别很多人一上来就把 Memory 理解成把历史对话存数据库这是最常见的认知偏差。存下来只是第一步关键在于什么时候取、取多少、以什么形式塞回上下文。短期记忆Short-term Memory对应的是当前会话窗口内的上下文它的生命周期就是这一次对话。Spring AI 里通常通过ChatMemory接口配合MessageWindowChatMemory这类实现来管理核心机制是维护一个消息窗口超过窗口大小的旧消息会被丢弃或压缩。它的价值在于维持对话的连贯性——用户说它、那个、刚才提到的Agent 能正确指代。长期记忆Long-term Memory则是跨会话的用户这次聊完下次再来Agent 还能记得他的偏好、历史事实、关键结论。这块通常要靠向量库或者结构化存储来实现本质是检索增强思路在记忆上的应用把值得记住的信息抽取出来存好需要时按相关性召回。我一般会用一个类比短期记忆像你手边的草稿纸写满了就擦掉重写长期记忆像你的笔记本重要的东西归档进去需要时翻出来查。两者不是替代关系而是配合关系。2.2 Spring AI 2.0 里 ChatMemory 的落地方式在 Spring AI 2.0 中Memory 的接入相对直接。核心是给ChatClient配置一个ChatMemory实现框架会在每次调用时自动把历史消息拼进请求。一个典型的配置长这样Bean ChatMemory chatMemory() { return MessageWindowChatMemory.builder() .maxMessages(20) .build(); } Bean ChatClient chatClient(ChatClient.Builder builder, ChatMemory memory) { return builder .defaultAdvisors(new MessageChatMemoryAdvisor(memory)) .build(); }这里maxMessages(20)是个关键参数。它决定了窗口里保留多少条消息。设太小Agent 记不住前文设太大Token 爆炸、成本上升、还可能触发模型的上下文长度上限。我的经验是先用 20 条起步然后根据实际对话的平均长度和模型上下文窗口反推。假设你的模型支持 128K Token平均每条消息 200 Token那理论上能放几百条但没必要——因为越靠前的信息相关性越低保留太多反而稀释了重点。注意MessageWindowChatMemory默认是滑动窗口超出就丢最旧的。这在多轮任务里很危险因为任务早期的关键约束比如预算不超过 5000可能被丢掉。生产环境建议配合摘要机制而不是单纯丢弃。2.3 长期记忆的抽取与召回别什么都往库里塞长期记忆最容易踩的坑是什么都存。我见过有团队把每一轮对话原封不动写进向量库结果召回时噪声极大检索出来的全是无关寒暄。正确的做法是做信息抽取只把事实性、稳定性、未来可能复用的信息沉淀下来。比如用户的身份、偏好、明确表达过的约束、任务的关键结论。寒暄、临时确认、一次性指令都不该进长期库。抽取的时机一般有两个一是会话结束时批量抽取二是每轮对话后增量抽取。前者成本低但实时性差后者实时但开销大。我通常用会话结束 关键节点触发的混合策略。抽取出来的信息用结构化格式存比如{ userId: u_1001, type: preference, content: 偏好简洁回答不喜欢冗长解释, confidence: 0.9, timestamp: 2025-01-15T10:30:00 }召回时用当前用户输入去向量库检索 Top-K 相关记忆再拼进 System Prompt。这里 K 值别贪大3 到 5 条通常够用多了反而干扰。2.4 记忆冲突与时效性一个容易被忽视的深坑长期记忆有个隐蔽问题信息会过时、会冲突。用户三个月前说我在北京现在说我搬到上海了如果两条都存着召回时可能同时命中Agent 就精神分裂了。解决办法是给记忆加时效标记和冲突消解逻辑。简单做法是同一类信息只保留最新一条覆盖式更新复杂做法是保留版本链召回时按时间倒序优先取新的。我在项目里一般用主体 属性作为唯一键新值覆盖旧值同时保留一个updatedAt字段用于审计。另外记忆的置信度也值得关注。用户随口一句可能吧和明确说我确定权重应该不同。给每条记忆打 confidence 分召回时按分数加权排序能显著提升记忆的可用性。3. State 管理Agent 执行过程中的存档点3.1 State 和 Memory 到底差在哪这两个概念经常被混为一谈但它们的职责完全不同。Memory 面向对话历史State 面向任务执行过程。举个例子你让 Agent 帮你订一张从北京到上海的机票。Memory 记录的是你和它的对话我要订票要几点的下午的State 记录的是任务本身的结构化进度出发地北京、目的地上海、时间下午、当前步骤查询航班、已选航班MU5137、状态待确认。State 的核心价值在于可恢复、可中断、可审计。一个长任务可能跑几分钟甚至几小时中间可能因为网络、人工确认、外部系统回调而暂停。如果没有 State一旦中断就得从头再来用户体验极差。3.2 用 Spring AI 构建可持久化的 Agent StateSpring AI 本身没有强绑定某个 State 存储方案这给了我们灵活度但也意味着要自己设计。我的做法是把 State 抽象成一个可序列化的对象用StateStore接口管理读写public interface AgentStateStore { void save(String sessionId, AgentState state); AgentState load(String sessionId); void clear(String sessionId); } public class AgentState { private String sessionId; private String currentStep; private MapString, Object slots; // 任务槽位 private ListString completedSteps; private String status; // RUNNING / PAUSED / DONE private long updatedAt; }存储介质按场景选单机 Demo 用内存 Map 就够生产环境用 Redis快、支持 TTL需要审计和回溯的用关系库或文档库。我一般推荐 Redis 做主存 定期落库做持久化兼顾性能和可靠性。关键点是每次状态变更都要落盘而不是等任务结束才写。因为任务可能随时中断你永远不知道哪一步是最后一步。3.3 状态机 vs 自由流什么时候该约束 AgentState 设计里有个重要决策要不要用状态机约束 Agent 的执行路径。自由流Agent 自己决定下一步做什么灵活但不可控容易跑偏、容易死循环。状态机预定义步骤和转移条件可控、可测、可审计但灵活性差。我的经验是分场景开放式任务如问答、创意生成用自由流流程化任务如订单处理、审批流用状态机。Spring AI 2.0 里可以通过自定义 Advisor 或者工具调用的返回值来驱动状态转移。比如每个工具执行完后返回一个nextStep提示Agent 据此决定下一步。对于混合场景可以用状态机骨架 局部自由的方式主干流程用状态机卡死每个节点内部的细节处理交给 Agent 自由发挥。这样既有可控性又不失灵活。3.4 并发与幂等多用户场景下的状态隔离单用户 Demo 里 State 很简单一上多用户就出问题。最常见的 bug 是状态串号——A 用户的任务状态被 B 用户读到了。根因通常是 sessionId 生成或传递有误或者用了全局单例存状态。解决思路很直接所有 State 操作必须带 sessionId存储层按 sessionId 分区。Redis 里用agent:state:{sessionId}作为 key天然隔离。同时要注意 sessionId 的生成要足够随机且不可预测避免被猜测。另一个坑是幂等。Agent 执行工具调用时如果因为重试导致同一个操作执行两次比如重复下单后果很严重。做法是给每个工具调用生成唯一operationId执行前先查是否已执行过已执行则直接返回缓存结果。这个幂等层最好放在工具实现里而不是依赖 Agent 自己判断。4. Context Engineering决定 Agent 上限的隐形战场4.1 上下文窗口是稀缺资源不是垃圾桶Context Engineering上下文工程这个词这两年才火起来但它做的事一直存在决定每一轮请求里到底往 Prompt 里塞什么。很多人的做法是能塞就塞——历史对话全带上、所有工具描述全带上、检索到的文档全带上。结果就是上下文迅速膨胀Token 成本失控而且模型在超长上下文里的注意力会被稀释关键信息反而被淹没。这就是所谓的lost in the middle现象模型对上下文中间部分的信息利用率明显低于开头和结尾。所以 Context Engineering 的核心目标是在有限的窗口里放最相关、最必要的信息并且把最重要的放在最容易被注意到的位置。4.2 上下文的四个组成部分与裁剪策略一个典型的 Agent 请求上下文包含四块System Prompt角色与规则、Memory历史对话、Retrieved Context检索到的知识、Current Input当前输入。每一块都有裁剪空间。System Prompt 要精简把稳定不变的规则放这里动态信息别塞。我见过把用户画像、当前时间、任务状态全写进 System Prompt 的导致每次请求前缀都不一样缓存完全失效。正确做法是静态部分固定动态部分后置这样能最大化利用 Prompt 缓存省成本又提速。Memory 的裁剪前面讲过滑动窗口 摘要结合。Retrieved Context 要控制条数和长度检索回来的文档先做重排rerank只留最相关的几条每条再截断到合理长度。Current Input 一般不动但如果用户输入超长比如贴了一大段代码也要考虑分段或摘要。4.3 摘要压缩把长历史变成短要点当对话轮次很多时单纯滑动窗口会丢信息全量保留又太长。这时候摘要压缩是标配。做法是当历史消息超过阈值时把最旧的一批消息交给模型做摘要生成一段浓缩的要点替换掉原始消息。这样既保留了关键信息又大幅压缩了长度。// 伪代码示意 if (messages.size() threshold) { ListMessage old messages.subList(0, batchSize); String summary summarize(old); // 调用模型生成摘要 messages new ArrayList(); messages.add(new SystemMessage(历史摘要 summary)); messages.addAll(recentMessages); }摘要的 prompt 要设计好明确要求保留事实、约束、结论丢弃寒暄和过程性内容。我一般会让摘要输出结构化要点而不是一段散文这样后续拼接更可控。注意摘要本身也会丢信息所以关键约束如金额、时间、ID最好单独结构化存储不要只依赖摘要。摘要负责氛围和上下文结构化字段负责硬约束。4.4 工具描述的瘦身被低估的 Token 消耗大户工具Function/Tool描述是很多人忽略的上下文消耗源。一个 Agent 挂十几个工具每个工具的描述、参数 schema 加起来可能好几千 Token而且每轮请求都要带上。优化手段有几个一是按场景动态加载工具不是所有工具每轮都需要根据当前任务阶段只挂相关工具二是精简描述把冗长的说明压缩成关键信息参数描述能省则省三是工具分组用一层路由先决定用哪组工具再加载具体工具。我实测过一个案例把 15 个工具的描述从平均 200 Token 压到 80 Token单轮请求省了近 2000 Token长对话下成本下降非常明显而且因为上下文更干净模型的工具选择准确率反而提升了。4.5 上下文顺序的讲究把关键信息放在黄金位置前面提到lost in the middle所以上下文的排列顺序是有讲究的。经验法则是最重要的信息放开头和结尾次要的放中间。具体到 Agent 请求System Prompt 里的核心规则放最前当前用户输入和最关键的任务约束放最后靠近生成位置模型注意力最高历史对话和检索文档放中间。如果检索到的文档有多条最相关的放第一条和最后一条。这个技巧看起来玄学但实测有效。我在一个客服 Agent 项目里调整了上下文顺序后模型对关键约束的遵守率从 70% 出头提升到了 90% 以上改动成本几乎为零。5. 三者的协同一个完整 Agent 请求的生命周期5.1 从用户输入到模型响应的完整链路把 Memory、State、Context 串起来看一个完整的 Agent 请求大概经历这几个阶段接收用户输入加载对应 sessionId 的 State 和 Memory。根据 State 判断当前任务阶段决定加载哪些工具。从长期记忆里检索相关记忆从知识库检索相关文档。组装上下文System Prompt 摘要 近期对话 检索结果 当前输入。调用模型可能触发工具调用。工具执行后更新 State判断任务是否继续。响应返回后更新 Memory必要时触发长期记忆抽取。这条链路里每一步都有优化空间也都有坑。比如第 4 步组装上下文时如果检索结果为空要有个兜底策略别让 Prompt 里出现以下是相关资料空这种尴尬内容。5.2 各环节的常见故障与排查思路实际项目里Agent 出问题往往不是单点故障而是多个环节叠加。我整理了一张排查对照表遇到问题可以按图索骥现象可能原因排查方向Agent 记不住前文Memory 窗口太小 / 摘要丢失关键信息检查 maxMessages 配置检查摘要 prompt多轮任务中断后重来State 未持久化 / sessionId 不一致检查 State 落盘时机检查 sessionId 传递响应越来越慢上下文膨胀 / 工具描述过多统计每轮 Token检查工具加载策略工具调用错乱工具描述重叠 / 上下文噪声大精简工具描述检查检索相关性关键约束被忽略上下文顺序问题 / 信息被稀释调整顺序把约束后置记忆冲突长期记忆未做覆盖更新检查记忆写入逻辑加时效字段这张表是我从多个项目里总结出来的基本覆盖了 80% 的常见问题。排查时建议从 Token 统计入手先看每轮请求的实际组成往往一眼就能看出问题在哪。5.3 性能与成本的平衡别为了记忆牺牲响应速度Memory 和 Context 做得越全成本和延迟就越高。这是个永恒的权衡。我的原则是记忆的深度按业务价值分级。核心用户、高价值场景可以多存多召回甚至用更强的模型做摘要普通场景用轻量策略滑动窗口 简单检索就够。不要一刀切。另外异步化能解决很多性能问题。长期记忆的抽取、摘要的生成都可以放到响应返回之后异步做不阻塞用户。用户感知到的只是当前这轮对话后台慢慢整理记忆体验和成本都能兼顾。6. 我在实际项目里踩过的几个真实坑6.1 摘要把关键数字总结没了有一次做报销 Agent用户说这次报销 3800 元超过 3000 的部分需要额外审批。对话轮次多了之后触发摘要结果摘要生成的是用户提交了一笔报销涉及审批流程——金额和阈值全没了。后续 Agent 判断是否需要审批时直接抓瞎。教训是摘要 prompt 必须显式要求保留所有数字、金额、时间、ID 等硬信息或者干脆把这些结构化字段单独抽出来存不依赖摘要。后来我改成摘要 结构化槽位双轨制再没出过这类问题。6.2 State 存了但没清内存泄漏早期项目里 State 存在内存 Map 里任务结束后忘了清理跑了一周服务 OOM 了。排查发现 Map 里堆了几十万条已完成的 State。解决办法是给 State 加 TTL或者任务完成后主动清理。用 Redis 的话直接设过期时间用内存 Map 的话得自己写个定时清理任务。这个坑很基础但真的很容易忘。6.3 工具描述写太全模型反而不会选有个项目里工具描述写得特别详细每个参数都配了大段说明结果模型经常选错工具。后来把描述精简到只保留这个工具干什么、关键参数是什么准确率反而上去了。原因是过长的描述引入了噪声干扰了模型的判断。工具描述的目标是让模型快速理解用途不是写文档。简洁、区分度高比详尽更重要。6.4 上下文顺序调整带来的意外收益前面提过上下文顺序的事这里再补一个细节。我把当前任务的关键约束从 System Prompt 挪到了用户输入之后、紧挨着生成位置模型对约束的遵守率明显提升。这个改动几乎零成本但效果立竿见影。后来我养成了一个习惯每轮请求组装完上下文后问自己一句如果我是模型最重要的信息我第一眼能看到吗。如果答案是否定的就调整顺序。7. 给不同阶段开发者的落地建议如果你刚开始接触 Spring AI 的 Agent 开发我的建议是先把 Memory 跑通用MessageWindowChatMemory加一个合理的窗口大小感受一下上下文对对话质量的影响。这一步能帮你建立对上下文即一切的直觉。如果你已经在做多轮任务型 Agent重点应该放在State 的持久化和状态机设计上。把任务拆成明确的阶段每个阶段的输入输出结构化中断可恢复。这块做扎实了Agent 的可靠性会有质的提升。如果你在做生产级、多用户、长会话的系统那Context Engineering 就是你的主战场。Token 成本、响应延迟、信息利用率全在这里。摘要策略、检索重排、工具动态加载、上下文顺序每一项都值得单独优化。最后分享一个我自己的判断标准一个 Agent 好不好不看它单轮回答多惊艳看它连续跑 50 轮之后还稳不稳。Memory、State、Context 这三块就是决定稳不稳的关键。模型会迭代框架会升级但这三块的工程思路是通用的值得花时间吃透。
1. 从能跑通到能记住Agent 开发的分水岭在哪如果你已经用 Spring AI 2.0 搭过一个能对话、能调工具的 Agent大概率会经历这样一个阶段Demo 演示时一切正常一旦放进真实业务里连续跑上十几轮问题就全冒出来了。用户上一句说我叫老张下一句问你还记得我叫什么吗Agent 一脸茫然多轮任务执行到一半中间状态丢了只能从头再来上下文越堆越长Token 消耗飙升响应越来越慢最后直接报 out of memory。这些现象背后其实是同一类问题Agent 的 Memory记忆、State状态和 Context Engineering上下文工程没有设计好。很多人把 Agent 开发理解成接个大模型 挂几个工具函数但真正区分一个玩具 Agent 和一个生产级 Agent 的恰恰是这三块。模型能力是天花板而 Memory、State、Context 决定了你能不能摸到那个天花板。这篇内容我打算把 Spring AI 2.0 里 Agent 进阶的这三块技术全景拆开讲。不是照本宣科念文档而是结合我自己踩过的坑把为什么这么设计实际怎么落地哪些地方最容易翻车讲清楚。适合已经用 Spring AI 跑通过基础 Agent、想往生产级方向推进的开发者也适合正在做 Agent 框架选型、需要理解记忆与状态机制底层逻辑的技术负责人。读完你应该能自己判断什么场景该用哪种记忆策略状态该存在哪上下文该怎么裁剪。先说一个反直觉的结论大部分 Agent记不住的问题根本不是模型不行而是你的上下文管理策略错了。模型本身是无状态的它每次看到的只是你喂给它的那段文本。所谓记忆本质上是你在每一轮请求里把哪些历史信息重新拼进了 Prompt。理解这一点后面所有的技术选择都会顺理成章。2. Memory 不是存聊天记录而是分层的信息调度2.1 短期记忆与长期记忆的本质区别很多人一上来就把 Memory 理解成把历史对话存数据库这是最常见的认知偏差。存下来只是第一步关键在于什么时候取、取多少、以什么形式塞回上下文。短期记忆Short-term Memory对应的是当前会话窗口内的上下文它的生命周期就是这一次对话。Spring AI 里通常通过ChatMemory接口配合MessageWindowChatMemory这类实现来管理核心机制是维护一个消息窗口超过窗口大小的旧消息会被丢弃或压缩。它的价值在于维持对话的连贯性——用户说它、那个、刚才提到的Agent 能正确指代。长期记忆Long-term Memory则是跨会话的用户这次聊完下次再来Agent 还能记得他的偏好、历史事实、关键结论。这块通常要靠向量库或者结构化存储来实现本质是检索增强思路在记忆上的应用把值得记住的信息抽取出来存好需要时按相关性召回。我一般会用一个类比短期记忆像你手边的草稿纸写满了就擦掉重写长期记忆像你的笔记本重要的东西归档进去需要时翻出来查。两者不是替代关系而是配合关系。2.2 Spring AI 2.0 里 ChatMemory 的落地方式在 Spring AI 2.0 中Memory 的接入相对直接。核心是给ChatClient配置一个ChatMemory实现框架会在每次调用时自动把历史消息拼进请求。一个典型的配置长这样Bean ChatMemory chatMemory() { return MessageWindowChatMemory.builder() .maxMessages(20) .build(); } Bean ChatClient chatClient(ChatClient.Builder builder, ChatMemory memory) { return builder .defaultAdvisors(new MessageChatMemoryAdvisor(memory)) .build(); }这里maxMessages(20)是个关键参数。它决定了窗口里保留多少条消息。设太小Agent 记不住前文设太大Token 爆炸、成本上升、还可能触发模型的上下文长度上限。我的经验是先用 20 条起步然后根据实际对话的平均长度和模型上下文窗口反推。假设你的模型支持 128K Token平均每条消息 200 Token那理论上能放几百条但没必要——因为越靠前的信息相关性越低保留太多反而稀释了重点。注意MessageWindowChatMemory默认是滑动窗口超出就丢最旧的。这在多轮任务里很危险因为任务早期的关键约束比如预算不超过 5000可能被丢掉。生产环境建议配合摘要机制而不是单纯丢弃。2.3 长期记忆的抽取与召回别什么都往库里塞长期记忆最容易踩的坑是什么都存。我见过有团队把每一轮对话原封不动写进向量库结果召回时噪声极大检索出来的全是无关寒暄。正确的做法是做信息抽取只把事实性、稳定性、未来可能复用的信息沉淀下来。比如用户的身份、偏好、明确表达过的约束、任务的关键结论。寒暄、临时确认、一次性指令都不该进长期库。抽取的时机一般有两个一是会话结束时批量抽取二是每轮对话后增量抽取。前者成本低但实时性差后者实时但开销大。我通常用会话结束 关键节点触发的混合策略。抽取出来的信息用结构化格式存比如{ userId: u_1001, type: preference, content: 偏好简洁回答不喜欢冗长解释, confidence: 0.9, timestamp: 2025-01-15T10:30:00 }召回时用当前用户输入去向量库检索 Top-K 相关记忆再拼进 System Prompt。这里 K 值别贪大3 到 5 条通常够用多了反而干扰。2.4 记忆冲突与时效性一个容易被忽视的深坑长期记忆有个隐蔽问题信息会过时、会冲突。用户三个月前说我在北京现在说我搬到上海了如果两条都存着召回时可能同时命中Agent 就精神分裂了。解决办法是给记忆加时效标记和冲突消解逻辑。简单做法是同一类信息只保留最新一条覆盖式更新复杂做法是保留版本链召回时按时间倒序优先取新的。我在项目里一般用主体 属性作为唯一键新值覆盖旧值同时保留一个updatedAt字段用于审计。另外记忆的置信度也值得关注。用户随口一句可能吧和明确说我确定权重应该不同。给每条记忆打 confidence 分召回时按分数加权排序能显著提升记忆的可用性。3. State 管理Agent 执行过程中的存档点3.1 State 和 Memory 到底差在哪这两个概念经常被混为一谈但它们的职责完全不同。Memory 面向对话历史State 面向任务执行过程。举个例子你让 Agent 帮你订一张从北京到上海的机票。Memory 记录的是你和它的对话我要订票要几点的下午的State 记录的是任务本身的结构化进度出发地北京、目的地上海、时间下午、当前步骤查询航班、已选航班MU5137、状态待确认。State 的核心价值在于可恢复、可中断、可审计。一个长任务可能跑几分钟甚至几小时中间可能因为网络、人工确认、外部系统回调而暂停。如果没有 State一旦中断就得从头再来用户体验极差。3.2 用 Spring AI 构建可持久化的 Agent StateSpring AI 本身没有强绑定某个 State 存储方案这给了我们灵活度但也意味着要自己设计。我的做法是把 State 抽象成一个可序列化的对象用StateStore接口管理读写public interface AgentStateStore { void save(String sessionId, AgentState state); AgentState load(String sessionId); void clear(String sessionId); } public class AgentState { private String sessionId; private String currentStep; private MapString, Object slots; // 任务槽位 private ListString completedSteps; private String status; // RUNNING / PAUSED / DONE private long updatedAt; }存储介质按场景选单机 Demo 用内存 Map 就够生产环境用 Redis快、支持 TTL需要审计和回溯的用关系库或文档库。我一般推荐 Redis 做主存 定期落库做持久化兼顾性能和可靠性。关键点是每次状态变更都要落盘而不是等任务结束才写。因为任务可能随时中断你永远不知道哪一步是最后一步。3.3 状态机 vs 自由流什么时候该约束 AgentState 设计里有个重要决策要不要用状态机约束 Agent 的执行路径。自由流Agent 自己决定下一步做什么灵活但不可控容易跑偏、容易死循环。状态机预定义步骤和转移条件可控、可测、可审计但灵活性差。我的经验是分场景开放式任务如问答、创意生成用自由流流程化任务如订单处理、审批流用状态机。Spring AI 2.0 里可以通过自定义 Advisor 或者工具调用的返回值来驱动状态转移。比如每个工具执行完后返回一个nextStep提示Agent 据此决定下一步。对于混合场景可以用状态机骨架 局部自由的方式主干流程用状态机卡死每个节点内部的细节处理交给 Agent 自由发挥。这样既有可控性又不失灵活。3.4 并发与幂等多用户场景下的状态隔离单用户 Demo 里 State 很简单一上多用户就出问题。最常见的 bug 是状态串号——A 用户的任务状态被 B 用户读到了。根因通常是 sessionId 生成或传递有误或者用了全局单例存状态。解决思路很直接所有 State 操作必须带 sessionId存储层按 sessionId 分区。Redis 里用agent:state:{sessionId}作为 key天然隔离。同时要注意 sessionId 的生成要足够随机且不可预测避免被猜测。另一个坑是幂等。Agent 执行工具调用时如果因为重试导致同一个操作执行两次比如重复下单后果很严重。做法是给每个工具调用生成唯一operationId执行前先查是否已执行过已执行则直接返回缓存结果。这个幂等层最好放在工具实现里而不是依赖 Agent 自己判断。4. Context Engineering决定 Agent 上限的隐形战场4.1 上下文窗口是稀缺资源不是垃圾桶Context Engineering上下文工程这个词这两年才火起来但它做的事一直存在决定每一轮请求里到底往 Prompt 里塞什么。很多人的做法是能塞就塞——历史对话全带上、所有工具描述全带上、检索到的文档全带上。结果就是上下文迅速膨胀Token 成本失控而且模型在超长上下文里的注意力会被稀释关键信息反而被淹没。这就是所谓的lost in the middle现象模型对上下文中间部分的信息利用率明显低于开头和结尾。所以 Context Engineering 的核心目标是在有限的窗口里放最相关、最必要的信息并且把最重要的放在最容易被注意到的位置。4.2 上下文的四个组成部分与裁剪策略一个典型的 Agent 请求上下文包含四块System Prompt角色与规则、Memory历史对话、Retrieved Context检索到的知识、Current Input当前输入。每一块都有裁剪空间。System Prompt 要精简把稳定不变的规则放这里动态信息别塞。我见过把用户画像、当前时间、任务状态全写进 System Prompt 的导致每次请求前缀都不一样缓存完全失效。正确做法是静态部分固定动态部分后置这样能最大化利用 Prompt 缓存省成本又提速。Memory 的裁剪前面讲过滑动窗口 摘要结合。Retrieved Context 要控制条数和长度检索回来的文档先做重排rerank只留最相关的几条每条再截断到合理长度。Current Input 一般不动但如果用户输入超长比如贴了一大段代码也要考虑分段或摘要。4.3 摘要压缩把长历史变成短要点当对话轮次很多时单纯滑动窗口会丢信息全量保留又太长。这时候摘要压缩是标配。做法是当历史消息超过阈值时把最旧的一批消息交给模型做摘要生成一段浓缩的要点替换掉原始消息。这样既保留了关键信息又大幅压缩了长度。// 伪代码示意 if (messages.size() threshold) { ListMessage old messages.subList(0, batchSize); String summary summarize(old); // 调用模型生成摘要 messages new ArrayList(); messages.add(new SystemMessage(历史摘要 summary)); messages.addAll(recentMessages); }摘要的 prompt 要设计好明确要求保留事实、约束、结论丢弃寒暄和过程性内容。我一般会让摘要输出结构化要点而不是一段散文这样后续拼接更可控。注意摘要本身也会丢信息所以关键约束如金额、时间、ID最好单独结构化存储不要只依赖摘要。摘要负责氛围和上下文结构化字段负责硬约束。4.4 工具描述的瘦身被低估的 Token 消耗大户工具Function/Tool描述是很多人忽略的上下文消耗源。一个 Agent 挂十几个工具每个工具的描述、参数 schema 加起来可能好几千 Token而且每轮请求都要带上。优化手段有几个一是按场景动态加载工具不是所有工具每轮都需要根据当前任务阶段只挂相关工具二是精简描述把冗长的说明压缩成关键信息参数描述能省则省三是工具分组用一层路由先决定用哪组工具再加载具体工具。我实测过一个案例把 15 个工具的描述从平均 200 Token 压到 80 Token单轮请求省了近 2000 Token长对话下成本下降非常明显而且因为上下文更干净模型的工具选择准确率反而提升了。4.5 上下文顺序的讲究把关键信息放在黄金位置前面提到lost in the middle所以上下文的排列顺序是有讲究的。经验法则是最重要的信息放开头和结尾次要的放中间。具体到 Agent 请求System Prompt 里的核心规则放最前当前用户输入和最关键的任务约束放最后靠近生成位置模型注意力最高历史对话和检索文档放中间。如果检索到的文档有多条最相关的放第一条和最后一条。这个技巧看起来玄学但实测有效。我在一个客服 Agent 项目里调整了上下文顺序后模型对关键约束的遵守率从 70% 出头提升到了 90% 以上改动成本几乎为零。5. 三者的协同一个完整 Agent 请求的生命周期5.1 从用户输入到模型响应的完整链路把 Memory、State、Context 串起来看一个完整的 Agent 请求大概经历这几个阶段接收用户输入加载对应 sessionId 的 State 和 Memory。根据 State 判断当前任务阶段决定加载哪些工具。从长期记忆里检索相关记忆从知识库检索相关文档。组装上下文System Prompt 摘要 近期对话 检索结果 当前输入。调用模型可能触发工具调用。工具执行后更新 State判断任务是否继续。响应返回后更新 Memory必要时触发长期记忆抽取。这条链路里每一步都有优化空间也都有坑。比如第 4 步组装上下文时如果检索结果为空要有个兜底策略别让 Prompt 里出现以下是相关资料空这种尴尬内容。5.2 各环节的常见故障与排查思路实际项目里Agent 出问题往往不是单点故障而是多个环节叠加。我整理了一张排查对照表遇到问题可以按图索骥现象可能原因排查方向Agent 记不住前文Memory 窗口太小 / 摘要丢失关键信息检查 maxMessages 配置检查摘要 prompt多轮任务中断后重来State 未持久化 / sessionId 不一致检查 State 落盘时机检查 sessionId 传递响应越来越慢上下文膨胀 / 工具描述过多统计每轮 Token检查工具加载策略工具调用错乱工具描述重叠 / 上下文噪声大精简工具描述检查检索相关性关键约束被忽略上下文顺序问题 / 信息被稀释调整顺序把约束后置记忆冲突长期记忆未做覆盖更新检查记忆写入逻辑加时效字段这张表是我从多个项目里总结出来的基本覆盖了 80% 的常见问题。排查时建议从 Token 统计入手先看每轮请求的实际组成往往一眼就能看出问题在哪。5.3 性能与成本的平衡别为了记忆牺牲响应速度Memory 和 Context 做得越全成本和延迟就越高。这是个永恒的权衡。我的原则是记忆的深度按业务价值分级。核心用户、高价值场景可以多存多召回甚至用更强的模型做摘要普通场景用轻量策略滑动窗口 简单检索就够。不要一刀切。另外异步化能解决很多性能问题。长期记忆的抽取、摘要的生成都可以放到响应返回之后异步做不阻塞用户。用户感知到的只是当前这轮对话后台慢慢整理记忆体验和成本都能兼顾。6. 我在实际项目里踩过的几个真实坑6.1 摘要把关键数字总结没了有一次做报销 Agent用户说这次报销 3800 元超过 3000 的部分需要额外审批。对话轮次多了之后触发摘要结果摘要生成的是用户提交了一笔报销涉及审批流程——金额和阈值全没了。后续 Agent 判断是否需要审批时直接抓瞎。教训是摘要 prompt 必须显式要求保留所有数字、金额、时间、ID 等硬信息或者干脆把这些结构化字段单独抽出来存不依赖摘要。后来我改成摘要 结构化槽位双轨制再没出过这类问题。6.2 State 存了但没清内存泄漏早期项目里 State 存在内存 Map 里任务结束后忘了清理跑了一周服务 OOM 了。排查发现 Map 里堆了几十万条已完成的 State。解决办法是给 State 加 TTL或者任务完成后主动清理。用 Redis 的话直接设过期时间用内存 Map 的话得自己写个定时清理任务。这个坑很基础但真的很容易忘。6.3 工具描述写太全模型反而不会选有个项目里工具描述写得特别详细每个参数都配了大段说明结果模型经常选错工具。后来把描述精简到只保留这个工具干什么、关键参数是什么准确率反而上去了。原因是过长的描述引入了噪声干扰了模型的判断。工具描述的目标是让模型快速理解用途不是写文档。简洁、区分度高比详尽更重要。6.4 上下文顺序调整带来的意外收益前面提过上下文顺序的事这里再补一个细节。我把当前任务的关键约束从 System Prompt 挪到了用户输入之后、紧挨着生成位置模型对约束的遵守率明显提升。这个改动几乎零成本但效果立竿见影。后来我养成了一个习惯每轮请求组装完上下文后问自己一句如果我是模型最重要的信息我第一眼能看到吗。如果答案是否定的就调整顺序。7. 给不同阶段开发者的落地建议如果你刚开始接触 Spring AI 的 Agent 开发我的建议是先把 Memory 跑通用MessageWindowChatMemory加一个合理的窗口大小感受一下上下文对对话质量的影响。这一步能帮你建立对上下文即一切的直觉。如果你已经在做多轮任务型 Agent重点应该放在State 的持久化和状态机设计上。把任务拆成明确的阶段每个阶段的输入输出结构化中断可恢复。这块做扎实了Agent 的可靠性会有质的提升。如果你在做生产级、多用户、长会话的系统那Context Engineering 就是你的主战场。Token 成本、响应延迟、信息利用率全在这里。摘要策略、检索重排、工具动态加载、上下文顺序每一项都值得单独优化。最后分享一个我自己的判断标准一个 Agent 好不好不看它单轮回答多惊艳看它连续跑 50 轮之后还稳不稳。Memory、State、Context 这三块就是决定稳不稳的关键。模型会迭代框架会升级但这三块的工程思路是通用的值得花时间吃透。
