一、Java做 Agent到底缺什么

• 技术栈转型困难：国内后端团队的技术栈基本以 Java 为主，用 Python 独立搭建服务会带来跨语言 RPC 调用，同时需维护两套可观测体系、两套配置中心，让整队人转去写 Python 也不现实。他们要的不是能用 Python 跑的 Agent，而是"能用 Java 写、能长在现有业务代码旁"的 Agent。
• 缺少企业级治理：多数开源框架只做到能跑起来：调通模型、跑通工具。至于链路追踪、配置中心、限流熔断、审计合规、灰度发布，大多要业务方自己接。
• 运行时空白：即便选了 Java 方案，现有框架也基本只做到能调通大模型。而生产化真正难点在运行时Runtime：短期记忆怎么管、单次工具返回的 5 万字结果怎么处理、产生错误结果的流程怎么回溯、工具怎么在不重启的情况下增减、并发工具调用怎么保证一致性，这些几乎没有框架给你兜。

现有Java方案

Spring AI 把不同厂商模型统一抽象为Model接口、Advisor 拦截链、Tool Calling 注解对 Java 工程师很友好。但也就到接入这一步：内部记忆实现机制ChatMemory 只有滑动窗口这类基础实现；工具返回值直接进入上下文、没有溢出保护；可观测只覆盖到“调用发生了”这一层；工具注册是启动期静态的；会话生命周期没有作用域概念。

Spring AI 是模型抽象层，不是Agent 运行时。它给你一辆能开的车，但生产化需要的变速箱、ABS、行车电脑等高级组件，得自己造。

Spring AI Alibaba 走得更远，Graph 编排、Nacos 集成、阿里百炼模型集成、Studio本地可视化调试工具。我们没选它：一来我们已经在用内部配置中心QConfig、CAT、内部 MCP 网关来换 Nacos 这套，等于把现有基建全部替掉；二来它的重点在编排，我们头疼的是单个 Agent 内部怎么更稳定的运行。

AgentScope Java 出现得晚，但布局铺得比较全：不可变消息、A2A / MCP 双协议、Reactor 非阻塞，适合新起项目。它和我们的场景不一样：它是一站式开发平台，我们是往已有 Spring Boot 服务里嵌的一层。后文会把它拿来做对照。

二、设计哲学：我们如何看待 Agent 运行时

后面所有具体设计，都围绕下面四条原则。

2.1 叠加，而不是替代

不重造Spring AI已有轮子，所有扩展能力均通过 Advisor、ToolCallback、Observation 机制接入 Spring AI 体系。业务方可直接使用 Spring AI 原生能力，也可按需启用我们提供的增强能力。

2.2 读写分离，复杂推后

写入链路简单快速，原始数据零加工直接入库，支持随时复盘、审计与流程回放。所有Agent决策（压缩上下文、预算判断）全部等调用LLM前统一执行。

2.3 信息不丢，只降级

面对上下文压力，信息从原文渐进降级到高密度摘要，而不是断崖式截断，也不是被打散成检索碎片。我们要的是斜坡，即保留连续的、可读的、只是密度不同的一份历史。

针对上下文压力，信息从完整原降级为高密度摘要。既不粗暴截断，也不拆成零散检索碎片。始终保持连续、可读，仅信息密度变化。

2.4 默认安全，业务无感

异常路径的清理、并发下的一致性、工具下线的安全窗口、进程重启后的会话续接，这些脏活都由框架在业务背后处理干净。

三、Spring-Ai-Trip架构图

核心数据流：一次 agent调用穿过 Harness 的完整路径，大致是这样

业务侧调用 agent.spawn() 发起请求，进入 Spring-AI-Trip Harness 框架，业务层无需感知内部流程。

1. 框架首次请求大模型前，加载提示词、技能列表、MCP 快照；
2. 核心Agent Loop：

• • MODEL STEP：发起 LLM 调用，模型由SpringAI接入；
  • ACTION STEP：并行工具调用；
  • PAYLOAD STEP：防止上下文溢出；
  • NEXT TURN：更新会话记忆、预算与摘要；

1. 记忆系统：持久化存储原始会话用于审计；按需执行不同级别的摘要压缩策略；修复被中断的工具调用
2. 收尾+清理：loop结束后发布完整会话链路追踪Span；由Micrometer 向Grafana上报指标；清理临时数据、会话缓存，释放 MCP 工具引用。
3. 可观测：所有运行链路指标，包括Span+Event Tree(第五章)、模型思考过程、工具入参和结果、token用量、失败报错等输出至可观测平台（CAT/Grafana）

四、短期记忆：渐进式压缩

没有记忆的 Agent 本质上只是个函数，产生问题：

• 对话连续性断裂：第 1 轮说"处理订单 ORD-2024-001"，第5轮问进展但Agent不记得订单号
• 决策链断裂：中间环节丢失，无法基于已有结论继续推进
• 执行链断裂：早期工具返回消失，可能重复调用或跳过步骤

记忆不是 Agent 的附加功能，而是 Agent 区别于LLM API 的本质特征

4.1通用做法缺陷

核心问题是上下文淘汰标准：按什么规则丢、丢完之后关键信息还在不在。

滑动窗口

Spring AI 的 MessageWindowChatMemory、LangChain 的 ConversationBufferWindowMemory 都是这个路子：保留最近 N 条消息，超出从队头丢。它用位置作为唯一淘汰标准，可信息的价值不一定由时间决定，用户第 1 轮说的"帮我处理订单 ORD-2024-001 的退款"，可能比第 19 轮那句"嗯"重要一万倍。到第 21 轮，窗口一滑，最初的目标被无声丢弃，于是 Agent 开始目标漂移：越聊越偏，或者每一轮都在重新猜用户到底想要啥。

RAG 检索

把历史向量化，用时再捞。它擅长跨文档知识检索，但用作会话记忆有个硬伤：它按语义相似度捞相关片段，却感知不到时序，也拼不出对话的整体画像。Agent 知道自己某次查过订单，却不知道整个任务进展到哪一步了。

看清了这些，记忆的设计哲学其实就一句话：

永远不丢弃任何信息；注入模型时，按信息价值的衰减曲线，渐进地压缩。

"渐进"是关键词。信息不是在某个边界突然消失，也不是被打散成碎片，而是连续、分级地从高精度原文过渡到高密度摘要。

在思考这套渐进压缩具体怎么做时，Claude Code 的四层上下文管理机制给了我们很大启发——我们借鉴了其中三条核心思想：信息不应被硬截断、摘要应该“结构化”而不是简单“总结一下”、压缩之后需要显式恢复。但不能直接照搬：Claude Code 是单机 CLI，单进程持有会话状态、文件写本地磁盘；我们是分布式服务端，会话不绑定特定实例、要跨实例续接、要接多家模型厂商——这些差异决定了我们最终落地形态和它不同。

4.2 三层防御体系

第一层：完整持久化

所有消息逐条落库，只追加、不删除。

这一层包含一个容易被忽视、却极其关键的设计——读写分离。写入永远只是简单的一次落库，毫秒级，零压缩开销；所有压缩只发生在读取、注入模型的那一刻。原始数据一条不少地落库，复盘、审计、回放随时可查。这一步还顺带解决了服务端才需要面对的跨实例会话续接：任何实例拿到sessionId，都能从库里拿到完整历史 + 摘要。

第二层：工具结果微压缩（模仿CC自动压缩）

纯内存计算、完全不调大模型的轻量压缩。核心：一次工具调用的返回值价值衰减极快。一个 3000 token 的订单查询结果，在 Agent 告诉用户"订单已发货"后，3000 token就不需要了，使用"我查过了，已发货"这个简单事实文本替换即可。

压缩前(约 3000 tokens)：  
[工具] query_order → {"status"：200，"body"：{"orderId"："..."，"items"：[...大量数据...]}}
压缩后(约 10 tokens)：  
[工具] query_order → "[旧工具结果已清理，可按 evidence-id=e7f3a 回查]"

一些细节值得注意：

1. 以完结轮次为单位：工具调用链可能横跨好几条消息，只有当整轮真正结束了，其结果才有资格被压缩，绝不压缩中间结果而中断正在进行的调用链；
2. 按工具分策略：不同工具使用不同压缩规则，关键操作永不压缩、查询结果过期即可清理
3. 压缩带证据引用：替换后的文本带一个指向持久层的evidence-id，如果在排障时要还原当时看到了什么直接按指针回查即可。

原始工具返回没有真的消失，只是不再占据上下文。一次 20 轮工具调用的对话，光微压缩就能释放约 5 万 token。

第三层：LLM 结构化摘要（CC同款做法）

微压缩之后仍然超预算，才动用大模型，把早期对话折叠成一份“结构化”摘要。注意，不是让模型随便总结一下，而是按一个固定的九段式模板来写，并且给每一段排了优先级：

这个设计直接命中前面说的目标漂移问题：用户意图和当前进展被显式地、结构化地“锚定”在摘要里，无论压缩多少轮，Agent 始终清楚“用户要什么”和“我做到哪了”。token 实在不够时，先从 P3 往下砍，P0 段落死保。摘要以<system-reminder>标签包裹、作为一条历史消息注入，插在近期原文之前，既压缩了上下文，又保证会话连贯。

对话再长呢？摘要之上还能再做摘要。当已有一份摘要、又积累了一批新对话，框架会以合并更新的方式做增量摘要：在旧摘要基础上更新已有的九段，而不是从头重写。于是摘要的质量随对话深度线性提升，而不是反复推倒重来。

顺带对照一下 AgentScope Java的思路：它的短期记忆走标准的消息容器InMemoryMemory，长期记忆则通过LongTermMemory接口委托给Mem0 / 阿里百炼等第三方记忆服务，其重心是“记忆服务的对接”而不是“单会话内不忘事”这个问题；而我们更像在做“记忆的注入形态”。两种取向没有对错，解决的是不同层次的问题，甚至可以叠加。

4.3 悬空调用修复：服务端才会踩的坑

还有一个真实生产才会踩的坑：服务中断。假如一轮工具调用刚发出、结果还没回来，进程就重启了，库里就留下了一个悬空的工具调用，违反大模型 API 的消息协议（带tool_calls的assistant 消息必须跟tool消息)，下次调模型API直接报错。框架在加载历史时会自动检测并修复这种残缺，把悬空的tool_calls消息删除，让会话能安全地接着跑。这类"脏活"，正是分布式 Harness 该替业务扛下来的。

4.4 动态历史窗口配额：为什么固定配额会翻车

给历史消息分配固定配额(如总窗口的80%留给历史)这个想法，建立在一个错误假设上：prompt 里除历史之外的部分是稳定的。其实一点都不稳定：系统提示词(从几十到三千多 token浮动)、工具 Schema(20 个工具轻松过万)、当前用户输入(一句"好"是1token，粘贴一份日志是几千 token)。产生下面后果：

1. 工具少、用户输入短时，20%用不完白白浪费上下文空间
2. 大量工具、用户传长文本时，20%不够用极易出现 token 溢出。

正确的算法不是“取窗口的某个比例”，而是“窗口减去所有已知固定开销后，剩下多少给历史”

有效窗口  = 上下文窗口 − 预留输出(默认 8000) − 安全缓冲(默认 3000)
固定开销  = 系统提示词 + 工具 Schema + 当前输入
历史窗口  = 有效窗口 − 固定开销
预估总量  = 固定开销 + 历史 tokens + 摘要tokens
触发压缩 when 预估总量 > 有效窗口 × 阈值(默认 0.90)

关键在“先扣后算”：不可压缩的模型预留输出和安全缓冲余量先扣掉，固定开销再扣掉，剩下的才是历史消息的真实可用空间；

判断是否触发压缩时，压缩生成的摘要本身也占地方必须算进去。所有token数由一个本地近似估算器算出：英文约4字符1token、中文约2字符1token、JSON上浮 15%，不调用远程 tokenizer，靠 10% 的阈值余量兜住估算误差。

五、可观测性：Span + Event 树

Agent 的故障模式和传统服务根本不同：没有报错路径，没有错误码，服务运行一切正常只是推理方向偏了。传统 APM 如SkyWalking能覆盖调用链路和耗时分布，但覆盖不到推理层：模型在哪一步、基于什么证据、做出了什么判断，这些信息在现有监控体系里是缺失的。

5.1 一个真实的排障案例

用户问：”帮我看看为什么昨天下午订单转化率跌了“Agent 调了几个工具，最后回答：“经查，是支付网关超时率上升导致的转化率下跌，建议排查支付链路”

结论有零有整，业务方信了，排查支付链路一整天，结果发现支付一切正常。

问题到底出在哪？如果没有可观测性，你只能靠猜。而当你能把这次会话完整回放出来，模型瞎说的原因一目了然：

真相浮出水面：那个查超时率的工具，数据只覆盖到中午 12 点，而下跌发生在下午两点后。模型拿到的是一份残缺数据，误把“上午网关超时率上升”当成下午转化率降低的原因。

错误不在模型笨，而在于它拿到的证据本身有问题，且没人能感知。有了完整的 Span + Event 回放，你一眼就能锁定：不是模型的锅，是那个工具的数据覆盖范围有问题，去修工具，而不是去调提示词。

5.2 认知可观测 vs 传统监控

这就是认知可观测性和传统监控的根本区别：它记录的不只是调用发生了，而是模型基于什么证据、做出了什么推理、得到了什么结论。

我们把一次 Agent 执行，建模成一棵由 Span和 Event 组成的树：

• Span 是有起点终点、可嵌套的执行区间：Agent "思考-行动-再思考"的循环链路能被Span的嵌套特性完整还原出来。
• Event 是 Span 内部的关键瞬间：模型的思维链、最终回复、工具的入参与出参、以及错误。

尤其是 Thinking事件能显式捕获模型思考过程。上面那个例子中，正是第 3 轮那句"超时率上升 → 转化率下降"，暴露了模型的推理跳跃。没有它，你永远只能对着一个错误结论干瞪眼。

5.3 可观测性后台

那么，如何让这些认知层的可观测事件（思维链、证据链、工具入参出参、token 消耗、错误现场）被开发者直观地感受到呢？一个好用的可视化后台同样必不可少。为此，我们把整棵 Span + Event 树做成了一个专门服务于 Agent 开发的可视化平台。

通过它，开发者可以按会话回放 Agent 的每一次执行，把模型看到的有效上下文、每一步的思维链、工具的入参与出参、token 与耗时的分布、异常事件的现场 一并摊在同一个视图里。最终答案只是结果，Trace 才是调优入口

写完一版提示词、加了一个工具、换了一个模型之后，改动到底让 Agent 变好了还是变差了，不再靠肉眼比对输出去猜，而是能落到一条条可对照的证据上

六、Spill：大结果的溢出保护

有了短期记忆的压缩为什么还需要溢出保护?

短期记忆管的是随时间累积的膨胀，但还有一类膨胀是“瞬时”的：我们踩过一个坑：一个MCP 工具单次调用甩回将近 5 万字的报文。这份报文一旦原样进入上下文，三件事同时发生：

1. 窗口瞬间占满：单条消息吃掉大半上下文窗口，其它历史被迫大规模压缩甚至丢弃；
2. 注意力稀释：模型淹没在海量它根本不关心的字段里，真正该看的那几行反而被忽略，输出质量肉眼可见地下滑；
3. 成本被引爆：这份报文会跟着后续每一轮对话反复重新发送，token 一次次翻倍计费。

而模型绝大多数时候只需要其中某个字段，或者只需要知道这个接口调通了、数据拿到了。

6.1 思路：类比虚拟内存

我们的应对，叫 Spill(溢出保护)。思路和操作系统的虚拟内存如出一辙：内存(上下文)放不下的大块数据，落到磁盘去，在内存里只留一个指针。

具体来说，任何工具的返回值，一旦超过阈值(默认 32000 字符)，框架会自动接管：

• 把完整原文落盘持久化，一个字节都不丢；
• 给模型的上下文里，只留一段预览(默认前 2048 字符)+ 一句明确的说明 + 一个可回读的路径。

模型看到的，从洋洋洒洒五万字变成了这样：

[工具结果过大，已溢出到磁盘]
预览(前 2048 字符)：{"code"：0，"data"：{"list"：[{"id"："..."，"name"："..."} ...
完整内容已保存至：spill：//order-assistant/conv-abc/tool-7f3a.json
如需完整数据，可使用读取工具按该路径获取。

这个设计的巧妙之处在于，它把要不要看全文的决策权，交还给了模型自己。绝大多数情况下，预览里的信息已经足够它继续推理；万一真需要全文里的某个细节，它可以主动拿着路径去回读——甚至只读其中一段。信息一点没少，但从"全部灌入大脑"→"需要时再查"。

6.2 几个打磨过的细节

按 tool 粒度灵活配置：哪些工具需要溢出保护、触发阈值多少、预览多长、要不要落盘，都能按工具定制。有些工具的输出天然结构化(如 JSON List)，可以在预览时智能截取前若干项；有些工具的输出是纯文本报告，直接截前 N 个字符就够了。

回读工具支持范围读取：回读接口不是要么给你全文、要么什么都没有，而是允许按字节区间、按 JSON path、按分页游标读取，避免回读取出全文又把上下文爆一次。模型看到一个 5 万字对应的 spill 文件路径时，它可以只回读第 3 到第 5 条 list 项，而不是被迫拿全文。

Spill绑定会话生命周期：Spill 文件按 agentName/sessionId/toolId 组织，天然属于一次会话的资源。会话结束(无论成功、失败、取消、超时)，这批文件跟着会话作用域一起被清理，不会在磁盘上留下孤儿。

并发一致性：多个工具在同一轮里并发返回、并发触发Spill溢出落盘时要保证几件事：文件名不冲突、取回的消息顺序不乱、工具调用事件挂载到各自对应的Span上。

“大工具返回值该往哪放”这个问题不是我们独家看到的坑。Spring AI 目前还没有这一层的原生抽象，工具返回值直接塞进上下文；LangChain 靠调用方手动 truncate，信息直接丢了。

有意思的对照来自 AgentScope Java，它的 ToolResultEvictionMiddleware 思路和我们的 Spill 几乎一致：超过阈值自动落盘原文、上下文里换成预览占位符、模型按需回读。它甚至在设计文档里明确区分了两件事：eviction 解决"上下文的宽度"(单条消息太大)、compaction 解决"上下文的深度"(消息积累太多)，和我们把 Spill 与短期记忆压缩分成两层的思路完全一致。

不同团队独立收敛到相近的方案，这本身就说明“大工具返回值该落盘 + 预留回读入口”是这类问题现阶段的合理解。差异更多在细节：如阈值、预览方式、挂载层次、命名空间、各自场景的具体约束，而不是设计思路的分歧。

七、能力供给：填平 Skill 的空白 + MCP 热插拔

Agent 的能力边界，由它手里的工具决定。这里有一对天生的矛盾：

• 工具给少了—Agent 啥也干不成；
• 工具给多了—每个工具的名字、描述、参数 Schema 都要塞进上下文，20 个工具轻松吃掉上万 token，不但烧钱，还稀释模型注意力（上下文腐烂）。

更别提工具还会变：今天上线一个新数据源，明天下线一个旧接口。难道每次都要改代码、发版？

7.1 拆解一：填平 Spring AI 在 Skill 上的空白

Skill 按需加载的思路早已是业界共识：上下文里只放技能清单(name + description)，模型判断需要时，再调工具捞正文。

但Spring AI 在这件事上是一片空白：业务方要么自己拼加载器，要么把指令全塞进 system prompt。

我们把 Skill 作为一等公民补齐了Spring AI的缺陷，做了两个来源的实现：

• 内置 Skill(classpath 加载)：团队沉淀的通用能力，如日志排查、大工具输出处理、ClickHouse 查询等，打包在框架 Jar 包里一起发布，项目只要引入框架依赖，就能直接使用。
• DB 动态 Skill(后台灵活配置)：每次spawn()创建Agent实例时，拉取当前(appId，agentName) 绑定的技能清单。可在后台新增、修改、绑定新技能，下次spawn即生效，不用改代码、发版。

同名 DB Skill 覆盖内置 Skill。平台方提供默认能力池，业务方按需扩展或覆盖。

7.2 拆解二：让工具能"热插拔"—MCP 动态工具注册

工具集还可由配置中心(如 QConfig)配置、支持运行时热更新：改配置立即生效，无需重启、打包发布。

热更新的难点在“安全”：更新的瞬间，可能正有请求在用旧工具，靠两个机制兜底：

• 引用计数 + 延迟关闭：要下线的旧工具MCP连接，等所有正在调用该工具的请求都结束（引用计数归零）才真正释放—绝不在请求执行到一半时把连接抽走。
• 增量更新：只更新配置真正变动的工具，避免”配置一变就全量重连“ 瞬间压垮 MCP Server

7.3 内置原子工具

框架还内置了一批开箱即用的原子工具：文件读写、命令执行、任务清单、HTTP 调用等，都是我们在多个业务场景里反复用到、抽象出来的最小可复用能力集。

八、并行工具调用：能同时做的事，别排队

还有一个体感极强的痛点：慢。

模型常常一次性决定调好几个相互独立的工具——查订单、查物流、查用户等级。串行执行意味着耗时累加，但这几个调用之间根本没有依赖，没必要排队。

8.1 虚拟线程：针对"网络瓶颈"

框架的做法很直接：当模型在一轮里请求了多个独立的工具调用，用 Java 虚拟线程把它们并发执行—总耗时从各段相加变成取最长的那段。虚拟线程极其轻量，成百上千个并发的 IO 等待也扛得住，契合工具调用这种"大部分时间在等网络"的场景。

虚拟线程在IO 阻塞时会自动释放载体 OS 线程，不会因 IO 阻塞占用系统内核资源。少量内核线程即可承载海量等待任务，因此适配 IO 密集场景。

8.2 并发一致性

• 结果顺序对齐：并发返回的工具结果回注 Prompt 时，要和模型请求顺序严格对齐，不能因为查物流比查订单快 200ms 就颠倒顺序。
• 观测Span不串味：每个工具调用挂在自己那条Span树上，Thinking / ToolInput / ToolOutput 事件归属不错乱。
• Spill 和微压缩在并发下照常工作：多工具并发触发 Spill 时文件命名不冲突；触发微压缩的最后一轮“完结轮次”的判定依然正确。

这些一致性细节，框架都在底层处理干净——业务侧感知不到并发的复杂，只感知到变快了。

九、端到端实战：一次排障会话，把所有机制串起来

单看每个机制，都像一个独立的补丁。但它们真正的威力，在于协同。我们用一个贯穿始终的场景，把它们串成一条线。

用户："帮我排查下为什么订单 ORD-2024-0117 一直卡在'支付中'。"

第 1 步—技能与工具就位。 收到问题，Agent 扫一眼上下文里的技能清单，判断是支付排障，用内置工具把“支付状态机排查”技能正文加载进来。同时，配置中心早已把这个环境该有的查询工具热插拔就绪。

第 2 步—并行取证。 模型一次性决定：查订单主表、查支付流水、查网关回调日志。三个调用互不依赖，框架用虚拟线程并发执行，耗时由最长的一段决定，而不是三段相加。

第 3 步—大报文SPill。 网关回调日志甩回来一份 4 万字的报文而不会污染上下文，超过阈值的部分自动落盘，模型只拿到预览和一个回读路径。模型瞄一眼预览，发现关键信息不在里头，于是拿路径只回读它需要的那一段报文。

上面这几步，都发生在响应这同一个问题的过程里，即模型内部“思考→取证→再思考”地递归推进，整个过程被记录成一棵 Span/Event 树。

多轮对话—记忆不漂移。排障很少一问一答就结束：给出初步结论后，用户往往接着追问—“那网关重试过没有”、“换昨天同一时段再看看”一来一回就成了多轮对话。压缩正是在这里发挥作用：它不发生在某一轮的内部推理中，而是当新一轮对话到来、框架把历史加载进来准备注入模型上下文的那一刻才触发。

前几轮里那些完整的工具返回值，被微压缩成“查过了、结果...”的简单事实结论；

更早的几轮被进一步压缩成结构化摘要，而“用户要排查 ORD-2024-0117 的支付卡单”这个目标，始终被稳稳锚定在摘要的 P0 段落里，哪怕聊到第 20 轮，Agent 依然清楚自己在查什么。

结论给出后—一切可回放。 整个过程被完整记录成一棵 Span + Event 树。万一结论有问题，你能一眼看到模型在哪一步、基于哪份证据、想岔了。

会话结束—干净收场。 无论这次是顺利结案还是中途被取消，会话结束的那一刻，spill 文件、内存缓存、临时工具连接被成套释放，不留一点残渣。

而这一整套协同，业务方几乎一行都不用写。 你只管把对话喂进去，把业务工具接上去；压缩、预算、锚定、修复、观测、清理，全在后台悄悄运转。业务代码里，剩下的就是那件你本该专注的事：把这个领域的问题解决好。

十、Roadmap：框架还能怎么提升

Spring-Ai-Trip 解决的，是“让 Agent 稳稳跑在生产里”这一层的问题。往前看，还有更大的图景：

• 更强的 Agentic Loop： 让 Agent 的自主规划、反思、纠错能力更成熟，并支持Plan Mode、Sub Agent，从“能完成任务”走向“能把任务完成得更好”。
• 长期记忆： 短期记忆解决一次会话内不忘事，长期记忆要解决跨会话地积累经验、认识用户。
• 自愈与容错： 把针对“悬空调用”这种零散问题的修复，扩展成一套系统化的故障自恢复机制。
• 提示词治理： 让提示词像代码一样，可版本化、可评测、可灰度。