4、记忆需要权限过滤企业场景尤其要注意。比如一个企业 Agent 同时服务多个部门：A 项目的测试策略不能被 B 项目随意召回管理层的复盘结论不能被普通成员看到用户个人偏好不能污染团队公共知识生产环境账号、Token、密钥不能进入长期记忆所以长期记忆检索前，必须先做权限过滤。5、召回太多会污染上下文长期记忆不是越多越好。召回太多，会导致：Prompt 变长模型注意力分散无关历史干扰当前任务旧信息覆盖新信息更合理的流程是：6、召回结果要可解释尤其是企业场景，最好能知道：这条记忆来自哪里什么时候写入为什么被召回当前是否仍然有效是否经过用户确认否则一旦 Agent 基于错误记忆做出错误判断，很难排查问题。十、记忆治理：长期记忆系统能不能跑稳，关键看这里长期记忆不是一次写入就结束了。它更像一类动态数据资产，需要持续治理。否则系统运行一段时间后会出现几个问题：重复记忆越来越多过期信息没有清理测试规范相互冲突临时信息被错误保存召回结果越来越不准敏感信息带来安全风险所以一个成熟的记忆系统，至少要设计四类策略。1、Write Policy：什么内容可以写入？写入前要判断：是否长期稳定？是否未来可复用？是否已经明确确认？是否涉及敏感信息？是否已经存在相似记忆？简单来说：不是所有内容都值得成为长期记忆。比如下面这些内容可以考虑写入：团队长期采用的测试分层规范项目的核心业务链路反复出现的高风险缺陷类型已确认的自动化环境约束稳定复用的测试数据准备方式但下面这些内容不建议默认写入：一次性临时讨论未确认的猜测生产账号和密钥临时测试数据已经过期的接口文档结论2、Read Policy：什么场景可以读取？读取长期记忆时要判断：当前问题是否需要历史记忆？记忆是否和当前任务相关？用户是否有权限访问？记忆是否仍然有效？召回数量是否会污染上下文？比如用户只是问一个通用技术问题，不一定需要读取团队历史记忆。但用户说：按我们团队之前的规范，帮我设计订单接口自动化测试方案。这就明显需要召回长期记忆。3、Update Policy：新旧记忆冲突怎么办？长期记忆必须支持更新。常见策略包括：新记忆覆盖旧记忆按场景拆分记忆降低旧记忆权重标记旧记忆 inactive让用户确认冲突项
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
