折腾了一圈 Agent 记忆，最后发现最简单的东西反而最好用。
代价是它要求人肯动手：Markdown 里没有黑盒，能直接改、能用 Git 查历史，也意味着出错的地方得有人去翻。它不适合需要自动检索的大规模场景；对多数小团队，先跑通 5 条用例、把经验沉成文件，比堆向量库划算。
这张图回答的是：Agent 记忆该怎么做减法。
越复杂的记忆系统，越容易丢记忆
有人给 Agent 接了 Mem0、向量库、知识图谱，功能看着很全，实际用起来却经常丢记忆。原因也很简单：切片太碎、自动摘要、关键词过滤、召回失败，任何一个环节出问题，Agent 就会觉得：
“我没见过这条信息。”
纯 Markdown，反而最稳
反而是最普通的 Markdown 文件更稳定。规则直接写进去，Agent 用的时候直接读，没有复杂中间层，也没有什么黑盒。
而且最大的好处是：人能直接看，也能直接改。AI 记错了，打开文件改掉；规则变了，直接更新；想看以前改过什么，就用 Git 看历史记录。
从聊天记录到 Skills 的渐进沉淀
其实比较合理的做法不是一开始就搭很复杂的记忆系统，而是先让 Agent 在 Markdown 里积累经验。用久了以后，再把这些经验慢慢整理：长期有效的，放进长期记忆；只针对某个项目的，放进项目记忆；经常重复执行的流程，再整理成 Skills。
最后就会变成：聊天记录 → 经验 MD → 长期记忆 / 项目记忆 → Skills，这样反而更清楚。
模型越强，越该做减法
模型能力越来越强以后，很多东西可能真的没必要搞得太复杂。把标准、规则、踩过的坑整理成几个干净的 Markdown 文件，很多时候就已经够用了。
有时候折腾了一堆 Prompt、Workflow、向量库、知识图谱，最后才发现：九九归一，还是纯文本最省事。
来源：见山Jetson
- 折腾一圈 Agent 记忆才发现，接 Mem0、向量库、知识图谱反而经常丢记忆，切片太碎、召回失败让 Agent 总说”没见过这条信息”，纯 Markdown 反而最稳。
- 越复杂的 Agent 记忆系统越容易出问题，没有黑盒的纯文本 Markdown 文件让人能直接看、直接改，规则变了更新即可，才是最省事的方案。
- 合理的 Agent 记忆做法不是一上来就搭复杂系统，而是先让 Agent 在 Markdown 里积累经验，用久再整理成长期记忆、项目记忆与 Skills。
- Agent 记忆的渐进沉淀路径清晰可操作：聊天记录变成经验 MD，再分流到长期记忆与项目记忆，重复流程再固化为 Skill，层级分明。
- 你的 Agent 总”没见过这条信息”，根因往往在切片太碎、自动摘要、关键词过滤或召回失败，任一环节出问题都会让记忆断链。
- 随着大模型能力越来越强，很多记忆中间层没必要搞得太复杂，把标准、规则、踩过的坑整理成几个干净 Markdown 文件往往就够用。
- 复杂记忆系统的真凶是中间层，自动摘要和关键词过滤会悄悄丢信息，而纯文本 Markdown 没有黑盒，可读可改可追溯。
- 用 Git 管理 Agent 记忆的 Markdown 文件，每次改动都有历史记录，人能直接审阅和修正 AI 记错的内容，稳定性远超黑盒方案。
- 长期记忆、项目记忆、Skills 三层该怎么分？长期有效的进长期记忆，项目专属的进项目记忆，重复流程固化成 Skill。
- 见山Jetson 的核心观点很朴素：Agent 记忆最好的保存方法就是别把它搞复杂，折腾一堆 Prompt、向量库后最终发现纯文本最省事。
Agent 评测精简方案（小团队落地版）
评测流程全景
整个评测分五个阶段，按顺序走：
准备用例 → 执行Agent → 评分 → 出报告 → 定位问题与回归
每一个阶段都有明确的输入和输出，环环相扣。
第一阶段：准备用例
用例是所有评测的基础。不要一开始就追求数量，按以下顺序逐步扩充：
起步：5条核心用例
选最能代表Agent日常工作的5个场景，先跑通整个流程。
稳定后：扩充到30条以上，分四类
| 类型 | 作用 | 示例 |
|---|---|---|
| 正常任务 | 验证基本能力 | 根据资料正确回答用户问题 |
| 边界任务 | 验证信息不足时的处理 | 资料缺失关键信息，Agent应如实告知而非编造 |
| 负向任务 | 验证安全与拒绝能力 | 用户要求越权操作或输出违规内容，Agent应拒绝 |
| 回归任务 | 防止历史问题复发 | 线上出现过的问题，沉淀为用例反复验证 |
每条用例必须包含：
- 输入（用户问题）
- 上下文/可用资料
- 可用工具（如有）
- 期望结果描述
- 成功条件（必须可判断，如”回答中不包含具体日期”）
- 是否关键用例（关键用例不通过则整体不通过）
注意： 参考答案和评分标准不能出现在给被测Agent的输入中。
第二阶段：执行Agent
执行阶段的核心目标是：让Agent在固定条件下运行，并完整记录它做了什么。
执行前固定配置：
每次执行必须记录以下信息，否则无法解释两次结果为何不同：
- Agent的提示词全文
- 使用的模型名称和参数（temperature等）
- 数据集版本
- 工具/知识库版本
- 评分规则版本
执行时记录轨迹：
至少保存以下信息：
- 用户输入
- Agent每一步的输出
- 调用了哪些工具、传了什么参数
- 工具返回了什么
- 报错信息
- 耗时
- Token消耗或成本估算
有框架自带的trace功能就用框架的，没有就用JSON文件落盘。关键原则：表格管用例和结果，日志文件管轨迹，两者通过用例ID关联。
执行边界：
必须设置超时时间和Token/成本上限，防止某条用例卡死或消耗过多资源。对于会修改外部数据的工具（发消息、改数据库），在测试环境或mock环境下执行。
第三阶段：评分
评分阶段的核心目标是：根据预设标准，判断Agent的表现是否达标。
评分分三类，按需组合：
规则评分
用代码直接检查明确条件。适合：
- 输出格式是否正确（JSON Schema校验）
- 是否包含/不包含特定关键词
- 是否调用了指定工具
- 是否超时、是否超成本
- 是否命中安全规则（如禁止输出某类内容）
这类评分不需要额外模型，直接写脚本检查即可。
LLM裁判评分
用独立的模型当阅卷人，对照参考答案和评分标准，给被测Agent的回答打分。适合：
- 回答是否准确、是否基于资料
- 要点有没有覆盖完整
- 有没有编造事实
- 表达是否清晰合理
LLM裁判的使用方式：
- 为每个需要语义判断的用例编写评分标准（检查哪些维度、每个维度怎么打分）
- 将问题、上下文、参考答案、评分标准一起交给裁判模型
- 裁判模型返回各维度分数和打分理由
- 按预设权重计算总分，判断是否通过
LLM裁判的注意事项：
- 裁判模型本身有成本，用GPT-4级别模型每次裁判可能花费几毛到几块钱，小团队可以先用性价比高的模型
- 裁判模型会误判，建议定期拿一批人工标注过的样本，对比裁判结果，校准评分标准
- 裁判模型的提示词也要固定版本，否则分数波动无法解释
- 关键维度可以设置”一票否决”——这个维度不通过，其他维度分再高也没用
人工复核
适合模型容易分歧、业务判断复杂、或关键用例的最终确认。
人工看实际回答、执行轨迹和评分要求，给出判断。也可以用来校验LLM裁判判得对不对。
组合规则建议：
关键用例 = 规则检查通过 + LLM裁判≥阈值 + 人工确认
非关键用例 = 规则检查通过 + LLM裁判≥阈值
第四阶段：出报告
每次评测完成后生成报告，包含：
- 整体通过率
- 平均分
- 通过/失败用例数
- 平均耗时
- 平均成本
- 各评分维度的表现
看报告时注意：平均分高不代表没问题，关键用例可能挂了；通过率提高可能伴随成本上升。必须综合看。
第五阶段：定位问题与回归
看失败用例：
逐条检查未通过的用例，判断是Agent真的有问题，还是LLM裁判误判。进入执行轨迹查看具体步骤，找到问题根源后再修改。
基线比较：
改提示词、换模型、调工具后，拿一份旧报告做基线，对比：
- 通过率变化
- 新增失败用例（重点盯）
- 恢复通过用例
- 耗时和成本变化
每次尽量只改一个变量，否则不知道分数变化是谁引起的。
定期回归：
- 核心用例：每周跑一次
- 全量用例：每月跑一次
- 线上出新问题：立即补一条用例加入数据集
发布门禁
上线前必须满足的最低标准（可根据业务调整）：
- 关键用例全部通过（逐个人工确认）
- 整体通过率 ≥ 85%
- 无严重幻觉或数据泄露
- 无重复/无效工具调用
- 平均成本在预算内
- 人工抽查无重大风险
达不到就不发布，达到后进入小流量灰度验证。
最低落地组合
小团队不用从零开发系统，用现有工具组合即可：
- 用例管理：飞书表格 / Notion
- 执行脚本：Python + 现有Agent框架
- 日志保存：JSON文件或数据库
- 评分：规则脚本 + LLM裁判 + 人工抽查
- 报告：表格统计
- 回归：失败用例进问题列表，改完单独重跑
先跑通5条用例的完整流程，再逐步扩充。表格管用例和结果，日志文件管轨迹，通过用例ID关联。
