首页 / 正文

自进化 Agent 怎么搭:三层记忆 + 反射循环 + 技能系统(顺便聊聊开源署名怎么别翻车)

Mooko
发布于 2026-04-27 · 5分钟阅读
1290 浏览
0 点赞 暴击点赞!

自进化 Agent 怎么搭:三层记忆 + 反射循环 + 技能系统

你有没有这种瞬间:

  • 写了个 Agent,能跑任务,但每次都像“失忆”一样,从零开始
  • 你加了记忆,结果越跑越臃肿,召回一团糟
  • 你想让它“学会新技能”,最后变成一堆 hardcode prompt

最近圈里围绕 Evolver / Hermes Agent 的讨论很热闹,撇开口水战不聊对错,有一件事很值钱:这类“自进化 Agent”的核心架构已经很清晰了

这篇就干一件事:把这套架构拆成你能照着做的工程步骤。你做出来的 Agent,目标是——

  • 跑完任务会自动沉淀“可复用资产”(技能/工具链/提示词/流程)
  • 记忆分层,不乱
  • 定期复盘,越用越顺手
  • 技能按需加载,别把 prompt 写成一锅粥

友情提示:下面会用偏工程的写法,默认你有一个基础 Agent(LLM + 工具调用 + 任务循环)。


这类“自进化 Agent”到底在进化什么?

别被名字唬住,它不是让模型参数自己训练。

它进化的是执行层资产,比如:

  • 一段可重复的工具调用链(抓网页 → 清洗 → 入库 → 生成报告)
  • 一个稳定的子流程(对账、归类、提取字段、写周报)
  • 一个可复用的提示词模板(含输入输出规范、异常处理)
  • 一个“判断器”(什么时候该用哪个工具/技能)

你可以把它理解成:Agent 不是变聪明,是变熟练。像你上班干久了会有自己的 SOP。


标准结构:三层记忆 + 反射循环 + 技能系统

把系统拆开看,通常就三块:

1)三层记忆:别把所有东西塞一个向量库

推荐的分层方式(很好用):

  • 工作记忆(Working Memory):当前任务临时状态

    • 当前目标、子任务列表、已完成步骤、工具返回结果摘要
    • 生命周期:一轮任务结束就清掉或压缩
  • 情景/项目记忆(Episodic Memory):一次任务的全过程记录(可检索)

    • 输入是什么、做了哪些决策、踩了什么坑、最终效果如何
    • 生命周期:长期保存,按项目/用户/时间分桶
  • 技能/语义记忆(Semantic / Skill Memory):被验证可复用的“方法”

    • SOP、模板、工具链、约束条件、适用场景、失败案例
    • 生命周期:长期保存,需要版本管理

你会发现:

  • 工作记忆服务“当下”
  • 情景记忆服务“复盘”
  • 技能记忆服务“复用”

把边界划清楚,系统立刻清爽很多。


2)反射循环:跑完别急着结束,给它一个“复盘回合”

反射(Reflection)建议做成一个固定流程:

  • 结果评估:输出是否满足任务要求?哪里不够?
  • 关键决策回看:哪一步最影响结果?当时依据是什么?
  • 可复用资产提取:这次有没有形成 SOP/模板/工具链?
  • 写入技能库:通过阈值才入库(别什么垃圾都存)

触发方式建议两种并存:

  • 周期性触发:每完成 N 个任务反射一次(比如 N=5)
  • 事件触发:出现失败/超时/用户差评/高价值成功时立刻反射

你会明显感觉到:Agent 不再只是“执行器”,而是“带复盘能力的同事”。


3)技能系统:把“会做”变成“一键复用”

技能系统核心就两件事:发现技能 + 按需加载

  • 技能发现(Discovery):从情景记忆里挖出重复模式
  • 按需加载(On-demand Loading):当前任务需要什么技能,再加载什么(别全塞进 prompt)

一个实用的技能结构(建议你照抄):

skill_id: "invoice_reconcile_v3"
name: "发票对账并生成差异报告"
description: "对比A表与B表,输出缺失/重复/金额差异"
inputs:
  - file_a
  - file_b
outputs:
  - diff_report_markdown
constraints:
  - "金额字段统一转为分" 
  - "必须保留原始行号"
tool_chain:
  - tool: read_excel
  - tool: normalize_schema
  - tool: join_and_diff
  - tool: write_report
prompt_template: |
  你是财务对账助手...
examples:
  - case: "字段名不一致"
    fix: "映射表..."
version: 3
quality_score: 0.86
created_at: "2026-04-01"

重点是:技能不是一段 prompt

技能是“可执行资产包”。里面要有工具链、约束、输入输出契约、失败案例。


你照着做:最小可用的自进化 Agent 工程清单

Step A:把一次任务的生命周期固定下来

任务循环别太花,建议固定成这样:

  1. 规划(Plan):把目标拆成可执行子任务
  2. 执行(Act):工具调用 + 中间结果
  3. 总结(Summarize):压缩工作记忆
  4. 反射(Reflect):评估 + 提炼资产
  5. 沉淀(Evolve):写入技能库 + 打分 + 版本

你要做的是把这些节点变成“硬流程”,而不是靠 prompt 自由发挥。


Step B:实现三层记忆的最小数据结构

给你一个很省事的落地方式:

  • 工作记忆:Redis / 内存对象
  • 情景记忆:Postgres + 向量索引(pgvector)或纯文档库
  • 技能记忆:Git 管理的 YAML/JSON + 索引库(方便版本回滚)

情景记忆建议至少存这些字段:

  • task_id / user_id / project_id
  • goal
  • plan
  • tool_calls[](参数、返回摘要、耗时)
  • final_output
  • evaluation(自评 + 用户评分)
  • reflection_notes

技能记忆建议至少存这些字段:

  • skill_id / version
  • 适用条件(非常关键,不写就是灾难)
  • 输入输出契约
  • 工具链
  • 失败案例

Step C:做一个“资产提取器”(跑完自动提炼)

你可以写一个专门的 Extractor Prompt/模块,输入是本次任务的情景记录,输出是:

  • candidate_skills[]
  • candidate_templates[]
  • candidate_tool_chains[]

提取器输出要可结构化解析,别让它写散文。

示例输出(JSON):

{
  "skill_candidates": [
    {
      "name": "网页资料抓取并生成结构化摘要",
      "use_when": "用户给多个链接,需要统一格式输出",
      "tool_chain": ["fetch_url", "extract_main_text", "dedup", "summarize"],
      "constraints": ["保留引用链接", "区分事实与观点"],
      "quality_signal": {"success": true, "user_feedback": 5}
    }
  ]
}

Step D:加一个“技能准入门槛”,不然技能库会烂掉

最常见的翻车:什么都当技能存进去

建议你做个简单评分:

  • 成功率(同类任务复用是否成功)
  • 用户反馈(点赞/采纳/投诉)
  • 成本指标(耗时、token、工具费用)
  • 稳定性(是否依赖脆弱网页结构、是否经常超时)

准入规则可以很朴素:

  • quality_score >= 0.75 才能进入“默认技能池”
  • 低于阈值的进“实验池”,需要人工确认或更多样本

别嫌麻烦,这一步能救命。


Step E:按需加载技能:别把全部技能塞进系统提示词

做一个技能检索器(Retriever),输入当前任务,输出 Top-K 技能:

  • 规则召回:看任务类型、关键词、项目标签
  • 向量召回:对任务描述 embedding,匹配技能描述
  • 重排:用一个小模型/LLM 打分排序

加载策略:

  • Top-3 技能以“工具说明 + 契约 + 约束”形式注入
  • 只注入必要示例
  • 超长技能放在外部文档,按需读取

你会看到 token 直接省一大截,输出也更稳定。


避坑清单:做自进化 Agent 时最容易踩的雷

  • 把情景记忆当技能记忆:复盘日志很长,但不可复用,塞进去只会污染检索
  • 技能没有适用条件:Agent 会乱用技能,越用越像“自信胡说”
  • 只存 prompt,不存工具链:一换工具参数就失效
  • 没有版本管理:技能改坏了无法回滚,线上直接炸
  • 反射太频繁:每轮对话都反射,成本爆炸、还吵
  • 评估缺失:没有质量信号,技能库就只能靠玄学增长

顺手聊一句:开源署名与协议,别把自己送上风口

围绕 Evolver / Hermes 的争议里,有个很现实的点:

  • 你用 MIT 开源,别人拿去用、改、商用,法律上空间很大
  • 你希望对方必须开源改动、必须保留协议条款,那通常会走向 GPL 这类更“强约束”的协议

实操建议(偏保守,但省事)

  • 仓库里放清楚 LICENSE,别含糊
  • README 写清楚引用方式:怎么署名、引用哪篇文档、保留哪些文件
  • 贡献者协议(CLA):团队项目建议上,不然后期版权关系很乱
  • 技术博客/论文式文档:把设计动机、时间线、模块边界写清楚

你开源的是代码,别人读到的是“信任”。信任这东西,碎了很难补。


你可以直接照抄的落地路线(给忙人)

  • 先把 三层记忆 做出来:工作/情景/技能分开存
  • 再做 反射循环:每 5 个任务复盘一次 + 失败即时复盘
  • 加上 资产提取器:从情景记录产出候选技能(结构化)
  • 准入门槛:评分不过线不进默认技能池
  • 最后做 按需加载:技能检索 Top-K 注入当前任务

做完这五步,你的 Agent 基本就从“能用”变成“越用越顺”。


如果你愿意,我可以按你的场景把这套架构落到更具体的代码结构上:

  • 你用 Python 还是 TypeScript?
  • 工具调用是 MCP、OpenAI function calling,还是 LangGraph/Autogen 体系?
  • 你的任务更偏“写作/运营”,还是“数据处理/爬取/企业流程”?
OpenClaw
OpenClaw
木瓜AI支持养龙虾啦
木瓜AI龙虾专供API,限时领取免费tokens
可在 OpenClaw接入全球顶尖AI大模型
立即领取