Agent记忆分层设计实战：从会话上下文到团队知识治理

一个反直觉的问题：Agent到底该不该有记忆？

很多团队在构建 Agent 时，都会默认一个逻辑：Agent 应该「越来越懂我」，所以要不断积累记忆。但随着项目规模变大，一系列问题开始暴露：

• 以前记录的知识已经过期
• 同一件事，不同 Agent 的记忆并不一致
• Agent 根据旧记忆做出错误决策
• 团队根本不知道 Agent 为什么会给出这样的回答

于是有人提出了另一种思路：真正应该拥有记忆的不是 Agent 本身，而是外部的 Harness（执行框架）。Agent 每次都是一个相对「干净」的执行器，Harness 根据当前任务把需要的知识、规则、上下文动态注入。Agent 不长期保存业务知识，而是按需加载。

不过，把问题简化成「Agent 要不要记忆」本身就有偏差。Agent 本质上等于大模型 + Harness，把 Agent 和 Harness 平级讨论并不严谨。所谓「无状态」也过于绝对——真正的关键，是如何设计一套分层的记忆治理体系。

记忆分层：从会话上下文到团队知识

如果让你设计一个团队级 AI 开发平台，长期记忆应该放在哪里？放在 Agent 本身、放在 Git 知识库，还是放在 Skill？答案是：都不放在单一位置，而是分层管理。

三种不同生命周期的记忆

持久知识（Git 知识库）：记录长期、显式、可治理的团队知识，比如业务知识、架构说明、工程规范、项目决策、排查经验以及可复用流程。它的核心特点是可版本化、可评审、可追溯。此外还包括当前执行进度——做到了哪个节点、哪些任务完成、哪些测试失败、当前用的方案版本。

会话记忆：当前对话内的短期上下文，比如用户刚补充的要求、本轮已经做过的尝试、临时形成的假设。它的生命周期通常跟随会话或任务，任务结束即消散。

Memory（跨会话记忆）：按用户或业务维度划分，比如某用户长期关注的方向、常用表达方式、偏好的输出格式等。

这种分层设计在工程上对应不同的存储与检索机制。持久知识通常以文档或结构化数据形式存入 Git 仓库或向量数据库，需要时通过 RAG（Retrieval-Augmented Generation，检索增强生成）技术按语义相关性召回，再注入 Prompt；会话记忆则直接存储在运行时内存或短生命周期的缓存中，随会话销毁；跨会话的 Memory 层介于两者之间，通常存储在结构化数据库里，按用户 ID 或业务实体检索。三层记忆的写入与失效策略各不相同，若混用同一存储介质或不设过期机制，就会导致文章开头提到的「旧记忆污染决策」问题。

最终都会拼成 Prompt

无论是短期记忆还是长期记忆，最后都会被组装成 Prompt 送入 Agent。一个完整的用户 Prompt 结构通常包含：

• Harness 的当前规则
• Git 中检索到的知识
• 当前任务的状态
• 会话的历史对话
• Memory 中的相关内容
• 用户本轮的输入

这种分层设计的意义在于：不同生命周期的信息被清晰隔离，避免了「一锅乱炖」式的记忆污染，也让每一条知识的来源和有效期都变得可追踪。

当记忆发生冲突：谁说了算？

分层之后，一个棘手的问题随之而来。假设出现下面的冲突：

• Git 架构文档：订单接口仍使用 V1
• 任务状态：本次任务已按 V2 方案开发
• 会话记忆：用户刚说「暂时不要升级 V2」
• 长期 Memory：此前记录用户倾向优先采用新版本方案

Agent 该相信哪一个？

答案并不是「固定某个层级优先级最高」，而是——冲突时应触发人工介入机制。更完整的处理链路是：多个来源的信息进入上下文后，先检测冲突，再判断冲突类型和影响范围：

• 如果系统此前有明确规则、且属于低风险，Agent 可以自行裁决
• 如果没有明确规则，或 Agent 判断为高风险，则暂停并请求人工判断
• 人工介入后记录问题、更新规则，下一轮 Agent 就能自行判断

无论如何兜底，冲突时一定要埋点上报，方便后续告警、反馈和复盘。这本质上是一个「执行→发现→人工介入→规则演进」的正向循环。

冲突检测：结构化规则与语义理解如何配合

冲突检测本身也可能出错。比如文档说「默认使用 V1，特殊商家使用 V2」，用户这次要给特殊商家开发。表面上看两句话不冲突，但结合业务条件才能得出「应该用 V2」的结论。

那冲突检测该主要依靠结构化字段和版本规则，还是依靠 LLM 理解语义？

版本规则提供确定性

主要应依靠版本规则。所有文档更新时都应带版本号标识，即便没有强制版本号，用 Git 时也有可追踪的 commit 顺序。

但要注意：顺序并不等于「最新」或「应该使用」。真正决定是否使用，还要结合审批状态、生效状态、知识的作用域以及依赖关系。结构化规则主要负责判断确定性——是否为同一知识对象、是否已审批、是否正式生效（有些知识可能处于灰度状态）。

版本规则在实现上通常借助语义化版本号（Semantic Versioning，如 v1.2.3）或 Git commit SHA 来标识知识对象的变更历史。语义化版本号的三段结构分别对应破坏性变更、新增功能和向下兼容的缺陷修复，使 Harness 能够在不读取全文的情况下快速判断两个版本间的兼容关系。对于没有显式版本号的知识文档，Git 的 commit 时间戳和分支归属可作为替代依据，但前提是知识库的提交纪律要足够严格——随意 force push 或 squash 历史会破坏这条可追溯链路。

大模型补充语义判断

大模型则负责发现语义层的冲突。比如两个文档版本虽然不同，但内容并不互斥，只是措辞不一样，表达的意思一致；又比如某些文档带有适用条件，需要模型去理解判断。

正常的处理流程是：Harness 先根据规则决定某个知识是否直接使用，并自动埋点；若有冲突，再通过大模型做语义冲突检测；这一步往往需要人工裁决。

发现方案漏洞时：停止不等于什么都不做

再看一个更极端的场景：AI 执行编码任务时发现，当前已批准的技术方案明显存在漏洞，但仓库规定只能按已批准版本执行。此时 AI 该继续按错误方案编码，还是立即暂停提出变更？

关键在于：Agent 无法自己判断，必须依赖外部规则。前置逻辑是根据 Harness 中预设的风险和中断规则来判断：

• 异常在授权范围内、可安全处理 → 自动继续
• 需要补充信息 → 暂停并主动挖取知识澄清
• 超出授权范围或判断为高风险 → 立即停止变更，请求人工介入

停止的是「不可逆操作」

一个重要认知是：停止变更并不等于什么都不做，主要停止的是不可逆的执行，比如删除数据。事实上，即使 Agent 认为某方案是错误的，它依旧可以继续编码——开一个新分支，或编码后不提交，等待人工审核。人工审核通过后直接 push 即可。如果确实是错误方案，这段代码丢弃即可；如果是 Agent 误判，产出的代码还能保留，同时更新规则。

不是每个问题都要更新规则

发生的问题不一定每次都需要更新规则。有些问题是一次性的，比如本次需求描述有遗漏、某个开发环境异常导致误判。只有重复出现、影响较大、且具备通用性的处理经验，才值得进入 Harness 变更流程。

团队规则的沉淀：像代码PR一样治理

最后一个核心问题：如何判断一个问题值得沉淀成团队 Harness 规则，而不只是当前项目的一次性经验？

答案是——Harness 规则就是团队的工程代码，不能因为某个 Agent 或某个人觉得有用就直接合并进主干，必须有晋升机制。

完整的治理流程类似代码开发：

1. 任务中发生问题，Agent 自行提交规则变更申请，或人工提交
2. 团队 review 变更是否值得晋升为团队级规则
3. 带着新变更进行评测
4. 上线后通过灰度手段逐步放量
5. 全量验证有效后，正式合并进主干

团队 review 的评分也可以类比评测来做，比如五分、四分、三分，不同分值代表的含义由业务团队自行决定。

这一治理思路与软件工程中的「渐进式发布」和「特性开关（Feature Flag）」机制高度类似。灰度放量意味着新规则仅对部分任务或用户生效，通过对比实验观察其对 Agent 决策质量的影响，再决定是否全量推送。评测环节则类似持续集成中的自动化测试，需要预先准备覆盖典型场景的 Golden Set（标准问答集），对新旧规则分别跑分后做对比。这种机制能有效防止「规则通胀」——即规则越加越多、互相干扰、导致 Agent 行为愈发难以预测的问题，同时也为规则的回滚提供了清晰的版本锚点。

总结：Agent治理的正向闭环

梳理下来，一套成熟的团队级 Agent 记忆与规则体系应该具备几个核心特征：

• 分层管理：知识、状态、记忆按生命周期分层，最终统一组装成 Prompt 注入 Agent
• 规则驱动裁决：按既有规则决定自动裁决还是暂停人工介入，全程埋点保证可观测性
• 人工把关规则演进：团队 Harness 规则不能由 AI 自动升级，必须走类似代码 PR 的评审、评测、灰度、全量流程

这套机制的本质，是把 Agent 从「越来越懂我的黑盒」变成「可治理、可追溯、可演进的工程系统」。而一个值得深思的开放问题是：未来 AI 提交的究竟只是代码 PR，还是连团队研发规范都能一起提交 PR？谁又该拥有最终的合并权？这或许是每个构建 AI 开发平台的团队都需要回答的问题。