企业 AI 客服项目落地时，几乎都会撞到同一面墙 — 用户聊到第 5 轮以后，回复越来越慢，单次对话成本肉眼可见地涨。这是机制决定的，不是 bug，也不是产品偷懒。阿里这周开源的 Spring AI Alibaba 框架，让我们第一次看清背后到底发生了什么。
这是什么
Spring AI Alibaba 是阿里在 Java 生态里主推的 AI Agent（智能体，可以理解为"会自己调用工具、查资料、做决定"的 AI 程序）开发框架。围绕它的最新一篇技术深扒发现，多轮对话的"记忆"机制直白得让人意外：不总结、不压缩、不遗忘 — 每次用户说一句新话，系统就把之前整段对话原封不动再喂给模型一次，靠一个名为 threadId 的编号把上下轮关联起来。
stream 和 call 这两条接口只是返回粒度的差别：stream 给你"边说边出"的流式内容，call 给你最后一句完整的助手消息。框架从不在背后悄悄"调用模型做一次总结"，只是把图执行完的产物按不同大小切给你。
行业怎么看
开发者社区里这件事讨论得不少。强调工程可靠性的团队支持"全量传递"：可回溯、可调试、出问题能精确定位到某一轮。但更普遍的担忧指向成本与延迟：随着对话轮次增加，token（模型的计费单位，按输入字数计费）线性增长、响应线性变慢，逃不掉。当框架不帮企业做摘要、不帮企业做压缩时，每个团队必然自己动手实现一套"记忆方案"，系统之间无法互通，体验好坏全凭工程水平。文章作者自己也点出：这种"作坊式记忆管理"才是企业 AI 真正落地最难的部分，比选哪个模型还难。
对普通人的影响
对企业 IT：看起来门槛很低的客服 Agent 项目，预算要按"对话轮数 × 单价"估算；与厂商谈合作时一定要问："超过 20 轮以后你们怎么处理"。
对个人职场：用 ChatGPT、Claude 这类工具做长文档协作时，如果发现聊久了会变慢变贵 — 不是错觉，是机制本身如此；长任务建议主动分段重启会话。
对消费市场：未来一段时间各家 AI 客服的体验差距，会越来越多地来自厂商愿意为"多读历史"花多少钱，而不是模型本身聪不聪明。这是商业决策，不是技术问题。