自进化 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:把一次任务的生命周期固定下来
任务循环别太花,建议固定成这样:
- 规划(Plan):把目标拆成可执行子任务
- 执行(Act):工具调用 + 中间结果
- 总结(Summarize):压缩工作记忆
- 反射(Reflect):评估 + 提炼资产
- 沉淀(Evolve):写入技能库 + 打分 + 版本
你要做的是把这些节点变成“硬流程”,而不是靠 prompt 自由发挥。
Step B:实现三层记忆的最小数据结构
给你一个很省事的落地方式:
- 工作记忆:Redis / 内存对象
- 情景记忆:Postgres + 向量索引(pgvector)或纯文档库
- 技能记忆:Git 管理的 YAML/JSON + 索引库(方便版本回滚)
情景记忆建议至少存这些字段:
task_id / user_id / project_idgoalplantool_calls[](参数、返回摘要、耗时)final_outputevaluation(自评 + 用户评分)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 体系?
- 你的任务更偏“写作/运营”,还是“数据处理/爬取/企业流程”?