TencentDB Agent Memory Adapts to the JEV Decision Model: Letting Agents Call on Team Experience as Needed

TencentDB Agent Memory 适配 JEV 决策模型：让 Agent 按需调用团队经验

TencentDB Agent Memory 引入可插拔决策服务，将“是否召回、选择哪些候选资产、是否触发记忆更新”等判断抽象为独立接口，并提供 JEV 接入示例。

在 Skill 召回实测中，接入 JEV 后，主模型因未命中而重复注入的输入 token 从 24.96M 降到 15.04M，减少近四成；任务成功率同时保持稳定，SWE-bench Pro 长难题通过数由 30% 提升至 40% 。

我们希望减少团队经验复用中的两类浪费：已有经验未被调用，任务不得不重复探索；不相关的经验被带入上下文，增加调用开销。其中一个关键环节，是判断经验何时应该参与任务、记忆何时需要更新。这次更新把这些范围明确的判断独立出来，由决策服务处理，让主模型继续承担任务分析与执行。

1

用 JEV 做判断：召回选择与记忆更新

JEV 在 Skill 召回与记忆更新环节中，只处理范围明确的问题，确定需要使用候选资产后，系统再进入召回与加载流程；确定需要更新记忆后，再触发相应的生成流程。通过这样的分工，主 LLM 可以将更多注意力留给任务分析与执行，减少在“要不要查一下”这类高频、小粒度判断上的消耗。

具体而言，JEV 在两个在线决策点上工作：

● 召回侧——选不选、选哪条。

在权限允许的候选范围内，将候选编号和说明交给 JEV，通过一次结构化判断完成选择；确定需要使用后，再读取和加载相应内容。

● 生成侧——值不值得生成。

每次场景记忆（L2）更新后，系统需要判断是否重新生成长期画像与稳定规则摘要（L3）。JEV 比较当前 L3 与新增 L2 信息，按冲突、适用边界变化、新规则、信息强化、无变化的优先级分类：前三类触发立即更新，信息强化延迟处理，无变化则跳过本次 L3 生成。

决策服务返回结构化判断与置信度；判断异常时，可按配置回退到原有策略。

召回判断服务于当前任务，生成判断服务于记忆维护。独立判断环节负责选择与触发，后续流程负责内容加载、生成和任务执行。接入其他模型时，也需要分别评估这两个环节的效果。

为评估独立判断环节对调用开销和任务结果的影响，我们做了两组测试。

Skill 召回——为了验证"JEV 取代主模型做选择"能带来什么，我们在 72 道同源任务上对比了主模型判断和 JEV 判断：

● 主模型因未命中而重复注入的输入从 24.96M token 降到 15.04M，减少约 9.9M——少了近千万 token 的冗余上下文，直接对应成本和延迟；

● 任务成功率几乎持平（66.7% → 65.3%，相差 1 题），选取部分SWE-bench Pro 长难题进行测试，通过数则由 30% 提升到 40%——这表明召回更准并没有牺牲任务质量。

Memory 生成——为了验证"JEV 判断是否触发 L3 重新生成"的效果，我们在 10 题 × 3 臂 × 3 次重复下对比了每次都生成的策略：

● 完整 14 轮用户对话的总成本降低 13.8%——生成侧少调用带来的直接节省；

● L3 生成调用减少 39.7%——大量本不必重新生成的场景被正确跳过；

● 接入JEV后最终语义同步率 96.7%（100%为理想数据）——少调用并没有牺牲记忆的同步质量，跟当前方案数据（86.7%）对比有明显提升；

● JEV 判断成本仅占总成本 0.72%，立即更新召回率 93.3%，二分类准确率 85.1%——判断本身几乎免费，漏判率也很低。

两组测试围绕同一个设计思路展开：把范围明确的选择与触发判断独立出来，让主模型继续承担任务分析与执行。对团队资产管理而言，快慢分工的价值在于：快路径管时机，慢路径管内容——先判断经验是否需要调用、记忆是否需要更新，再进入相应的加载与生成流程，让相关经验更有机会参与任务，同时减少不必要的调用和上下文占用。

不过，判断“什么时候用”只是经验复用的一环。要让决策服务做出有效选择，候选资产本身还需要有清楚的适用条件、验证依据和共享边界。

2

让经验成为可复用的资产

假设团队完成了一次数据库变更：执行记录已经留下，处理步骤也整理成了文档。一段时间后，另一位成员带着新的 Agent 接手类似任务。如果这些经验没有进入当前上下文，Agent 仍会重新查找资料、梳理步骤，成员也需要再次解释背景。

团队已经为这次工作投入了时间，下一次任务却仍要承担一部分重复成本。任务交接、成员变化、多 Agent 协同，都会放大这种重复。

要让经验真正被复用，首先要把它组织成便于查找和使用的资产。TencentDB Agent Memory 把 Chat Memory、Skill、Wiki 和 CodeGraph 统一纳入 Memory Assets 管理——分别承载事实与偏好、操作方法、结构化文档、代码关系四类资产。

其中，Skill 是本次更新的重点，因为重复任务中的操作方法是团队经验的重要组成部分。Skill 将适用条件、执行步骤、验证方式及所需资源组织在一起，帮助接手者判断是否采用。

不过，提炼出 Skill 之后，团队还需要知道它经过了什么验证、可以在什么范围内使用。否则，过去成功的一次操作，也可能在不同环境下被直接照搬。从组织提效的角度看，"整理—复核—共享"这条链路，正是把个人经验转化为团队资产的关键一步。

为明确资产的适用范围，并支持后续复核与维护，建议至少补齐五类信息：

适用条件：面向什么环境、版本和任务

步骤与变量：哪些顺序可复用、哪些参数需填写、如何验证结果

这些信息既帮助团队判断经验是否适用，也为决策服务提供更清楚的候选描述，并为后续修订留下依据。

3

经验调用与资产维护形成闭环

Agent 使用 Skill 执行任务后，会留下新的执行记录与结果。这些反馈可用于修订已有资产，让一次任务与下一次任务连接起来。

● 任务执行（让经验参与行动）：根据目标和当前工作状态判断是否需要召回，在权限允许的范围内筛选资料与方法，再结合规则、工具结果等信息组装上下文。执行结果更新工作状态，任务继续推进。

● 经验积累与维护（让任务留下可复用资产）：从执行记录、结果反馈、文档和人工经验中整理候选内容，保留适用条件和依据；根据需要合并、处理冲突、维护版本并验证改动。

结果反馈为继续改进提供依据，将任务反馈整理成反思文本供下一轮使用，通过更新外部记忆调整 Agent 行为，无需修改模型权重。对团队记忆系统而言，当前更具体的工作是保留结果、修订资产，并通过代表性任务验证改动。

判断策略本身也可以继续迭代。未来，团队可以根据执行反馈调整判断提示词与规则，检验哪些场景应该召回、哪些更新可以延后。经验资产与调用、维护这些资产的机制，都可以纳入持续评估与修订。

这类迭代需要以可追溯的执行反馈和持续维护的经验资产为基础。在 TencentDB Agent Memory 中，经验资产以 Memory Assets 的形式统一管理：团队通过 Memory Hub 复核内容、维护版本，并将修订后的记忆与 Skill 共享、绑定给相关 Agent，让执行反馈转化为后续任务可用的经验，也为判断策略的调整提供依据。

4

一起共建

我们关注的变化，是 Memory 从保存历史，进一步走向连接经验积累、上下文组装与能力改进。记忆层提供持久的信息与方法资产，召回和上下文调度机制决定它们何时参与任务，评估再检验这些经验是否带来了改善。

以前做 Agent 记忆，思路很直接：把聊天记录抽成事实、写进向量库，需要时再按相似度找回来——记忆就是存历史、查历史。但现在不一样了：从执行过程出发，沉淀出经验、记忆和 Skill，再经过整理、去冲突、版本管理，按任务把该用的内容路由出来，组装进上下文交给 Agent 执行，最后把结果反馈回去继续更新。

这条链路最关键的变化，是 Memory 从"翻历史"变成了 Agent 能力演进和上下文调度之间的一层中间层。一个人沉淀的经验，能真正被下一个人、下一个 Agent 复用，而不是换了人就从头解释一遍。

——人定义目标和边界、决定哪些经验值得推广，记忆层负责让这些经验在需要时精准出现。

欢迎在项目中分享 Skill 召回的使用体验、提供真实任务案例，以及你希望接入的决策模型。

决策模型的接入已经抽象，希望使用其他决策模型的开发者，可以基于这层接口自行实现适配；团队可结合任务特点、部署环境和评估结果选择模型。