Evolution

• Evolution 专指 Harness 根据交互经验对自身进行持久化修改的机制
  • Agent 在当前 Context 中对 Belief, Plan 和行动倾向的更新不是 Evolution
  • Model 权重的训练与更新也不属于 Harness Evolution
• Harness Evolution 的对象
  • 改变未来提供给模型的 Knowledge, 包括 Memory 和 Skill
  • 改变未来使用的 Cognitive Control, 包括 Workflow
  • 改变 Runtime, 包括工具, 安全机制, Hooks 和可观测性与评估机制
• Evaluation 为 Harness Evolution 提供选择信号
  • 只有能够区分有效与无效经验, Harness 才能决定沉淀, 修改或遗忘什么

Memory

• 广义的 Memory, 包括环境信息, 用户信息与沉淀经验
  • 环境信息可验证可推导
  • 用户信息不可验证不可推导, 但对完成任务很重要
  • 沉淀经验是之前完成过的任务的总结, 包括成功的经验和失败的教训
• 可以由用户主动提供, 也可以由 Agent 维护
• 关键点
  • 结构: 文本 / 知识图谱 / 结构化数据
  • 语义: 用户信息 / 沉淀经验 / 环境信息
  • 召回方式: 注入 / 检索 / 渐进式披露 / Agent 主动预测 + 推送
  • 生命周期管理: 什么时候写入 / 遗忘

结构

• 结构取决于输入的信息类型与检索方式
  • 代码会使用 AST 进行结构化, 变成知识图谱
  • 图像会使用标签进行结构化, 变成标签列表
  • 文本可以按 chunk 进行结构化, 向量化后存入 VectorDB
  • 不管哪种, 都可以直接总结成文本
• RAG
  • 狭义上指文本切割 -> 向量化 -> VectorDB -> 对提问向量化 -> 相似度匹配 -> 重排序 -> 注入上下文
• 知识图谱
  • 编译知识大于检索知识
  • 不一定是用向量检索节点, 也可能是 LLM Wiki
• AST
  • 对代码的最佳分析方式
  • 使用 Tree-sitter

LightRAG

• 构建
  • llm-based 提取 chunk 中实体与关系为 K-V 形式 (实体名 - 实体摘要 / 实体暗示的全局主题 - 关系内容)
  • 对所有实体 / 关系的 K-V Embedding, 存入 VectorDB, 构建为知识图谱
  • 投入新文档不需要重新构建
• 检索
  • llm-based 提取 Prompt 中实体与抽象
  • 实体向量检索实体, 再根据图谱关系做二跳检索
  • 抽象向量检索关系, 获取相关实体

语义

• 环境信息
  • 也就是工作的项目的信息, 简化模型的探索过程
  • 应该只存索引, 由模型去确定并获取事实, 避免过度依赖记忆
• 用户信息
  • 环境中无法推断, 但对完成任务很重要的信息, 例如用户的偏好, 项目的隐式约束
• 沉淀经验
  • 之前完成过的任务的总结, 包括成功的经验和失败的教训
  • 总结为可复用的技能, 供未来类似任务调用

召回方式

• 注入
  • 适合重要的, 需要模型持续关注的信息
  • 有的人也喜欢每次固定 RAG 一些环境信息, 但感觉不如让模型自己决定什么时候需要
• 检索
  • 适合大量的, 需要模型偶尔参考的信息
  • 可以包装成一个工具, 让模型决定什么时候需要调用
• 渐进式披露
  • 适合绝大部分情况其实, 而且与注入和检索不冲突
  • 提供一个索引, 需要时加载全量信息
• Agent 主动预测 + 推送

生命周期管理

• Agent 写入时机
  • Turn 结束时
  • 失败 / 成功时
  • 定时写入
  • 压缩时
• 遗忘时机
  • 过时遗忘: 给记忆打上时间戳
  • 冲突遗忘: 记忆之间存在强相关, 遗忘或融合

最佳实践

• 用户信息, 项目信息, 目录信息, 本地信息等记忆分层文件存储
  • 用一个 MEMORY.md 存有语义的记忆文件索引用作渐进式披露
  • 根据工作目录动态加载并主动注入
• 对于更广阔具体的信息, 可以考虑检索 (向量相似度 / BM25 / grep+read)
• 信息最好渐进式披露

Skills Based Memory

• 完整上下文, 利于 subagent
• 人类可读, 可编辑, 可审计, 可测试
• 易于分发
• Prompt 的快捷键
• Claude Code 有一个 Commands 功能, 允许 SKills 里嵌入脚本加载时处理 Skills 本身

插件

LSP