这篇东西我酝酿了挺久。市面上讲AI Agent的教程不少，但绝大多数讲的是“怎么调API、怎么写工具函数、怎么串工作流”，天花板很清晰——你的Agent只能做你预先设计好的事。而“自我进化”指的是Agent在运行过程中，把自己做对的事、踩过的坑、沉淀下来的经验，反哺回自身的记忆、技能和决策策略里。说得直白点：它应该像人一样，越用越顺手。这篇我尽量从底层讲透，适合已经跑通基础Agent、想再往上走一步的朋友，也适合想从零理解“进化机制”、不想被各种概念带偏的新手。我会先拆解进化的底层回路，再讲工程选型思路，然后落到可复现的最小闭环和问题排查，最后分享几个我踩过的坑。

1. 先搞清楚：Agent“自我进化”到底进化什么

1.1 你手上的Agent离“自我进化”还有多远

很多朋友一听到“自我进化”就联想到科幻片里的自主意识，于是要么觉得太玄，要么反过来当成营销噱头。其实本质上它说的是一个非常工程化的事情：让系统在运行过程中，通过自身经验持续改进后续行为。你手上那个能调用工具、能多轮对话的Agent，离真正的自我进化差在哪？我给你一个判断标准——如果你的Agent换一批问题、换一个环境，能力就明显打折扣，那它只是在执行预设逻辑；如果它能从失败任务里提取规律，下次自动避开同类坑，那才叫自我进化。

最常见的误解是把RAG当作自我进化。RAG是给Agent外挂了一个知识库，知识变了Agent本身没变，它依然不知道“上次哪个参数组合导致超时”。还有人把Prompt模板的微调当成进化，那只是换了一套话术，没形成闭环。真正的自我进化至少要包含三件事：经验被记录下来、经验被归纳成可复用的模式、新模式被验证后反哺回运行时。这三件事缺一不可，少了任何一环都只能算“增强”，不能算“进化”。

换句话说，进化意味着系统里存在一个反馈回路。它跟“人越用越熟练”是同一个逻辑：一个新人刚开始写报告，先照着模板写；某次他发现某个数据口径经常被领导打回，于是把这个教训记进自己的操作手册；下次再遇到同类报告，他直接按新口径处理，一次性通过。Agent的自我进化就是把这个“听说读写”的过程自动化、代码化，让它不需要你手动改逻辑就能自我迭代。

1.2 底层进化的三个回路：记忆、技能、行为策略

我习惯把进化的内容拆成三个回路，分开设计也分开维护，这样系统才不会变成一锅粥：

这三个回路不是并列关系，而是层层依赖的。记忆层是地基——如果没有对历史任务的记录，其他一切无从谈起。技能层是在大量记忆中发现规律后，把“偶然做对了”变成“稳定做对”。策略层又在技能之上再做一层选择：当多个技能都可用时，根据当前上下文选最优的那个。比如一个客服Agent，记忆层记得“A类客户对响应时间敏感”，技能层提炼出“先给A类客户发进度模板”，策略层则在“重试三次未接通时切换人工通道”和“继续自动跟进”之间做权衡。每一层都向上层提供原料，上层又反过来影响下层的记录方式，这就是闭环。

设计时我建议把三个回路的数据格式和更新节奏都分开。记忆层更新频繁，每跑完一个任务就可以写；技能层更新要谨慎，至少批量验证过再入库；策略层更新最慢，必须有对比评测做支撑。如果三层搅在一起，你会发现系统里到处是“经验”，却不知道哪条经验在真实生效。

2. 自我进化的工程底座：从框架到运行时的选型思路

2.1 框架选型：别只看“能跑”，要看“能不能改”

选框架这件事，我的建议跟大部分人相反：越“重”的框架越要小心。现在流行的Agent框架确实开箱即用，给你封装好了规划、记忆、工具调用、多Agent协作，看起来效率很高。但自我进化需要你在关键环节植入“观察、提取、注入”的逻辑，如果框架把Agent内部流程包得死死的，你根本找不到地方下手。

我实际对比过几条路，给你一个参考：

• 某全栈式Agent框架：功能全，但内部循环是个黑盒，想拿到每一步的完整轨迹得自己扒源码，改造成本高。适合快速出Demo，不适合做深度进化。
• 某轻量编排框架：只负责调度大模型和工具，日志、记忆、重试策略都开放接口。适合自建进化系统，因为你能在每一步前后插入钩子。
• 完全裸写：不依赖任何框架，自己维护大模型调用、工具注册、对话循环。灵活度最高，但工程量最大。如果团队对LLM调用很熟，这是长期最省心的方案。

我的经验是，选框架时重点看三个能力：可插拔（能不能在Agent循环中插入自研逻辑）、可观测（每一步输入输出、工具调用、token消耗能不能拿到）、可回滚（更新后的策略或技能能不能快速下线）。如果一个框架在演示时很好看，但你想看它内部的推理轨迹得靠“猜”，那它就不适合做进化底座。宁可自己多写两百行胶水代码，也要保证关键数据裸奔可见。

还有一个容易被忽略的点：进化的逻辑要尽可能独立于Agent运行时。不要在每一个Agent实例里内嵌一大堆“反思”和“学习”代码，那样不仅拖慢线上响应，还会让问题排查变得极度痛苦。把进化做成旁路服务，Agent负责跑任务、留日志，进化服务负责离线分析、生成技能、评测验证，最后再把验证通过的产物发布回运行时。这样两边可以独立扩展，线上出问题也不会被“学习”拖累。

2.2 记忆层与工具层的设计差异

记忆层和工具层表面上都是“给Agent更多资源”，但设计逻辑完全不同，混着用会出大问题。

记忆层解决的是“知道什么”。它有两种形态，我做过对比：短期工作记忆放当前任务上下文，用窗口或者摘要管理；长期语义记忆放历史经验，检索出来供Agent参考。长期记忆的存储现在主流是向量库加元数据过滤，但很多人忽略了一个关键：向量检索解决“语义相似”，不解决“情境一致”。你按文本相似度捞出来的记忆，可能是在完全不同的约束条件下产生的，直接放进上下文反而会误导Agent。所以我建议在写记忆时强制带上情境标签，比如任务类型、数据规模、所用工具、结果状态。检索时不光看向量相似度，还要按这些标签做粗筛。举个简单例子，“用某工具对100万行数据做清洗，耗时超长”这条记忆，就不能在只有一万行数据的任务里被当成“超时警告”推送出来。

工具层解决的是“会做什么”。想把工具调用变成可学习的技能，工具定义就必须自带机器可读的元数据。一个合格的工具Schema至少包括：名称、一句话描述、入参说明（含枚举值和单位）、出参结构、错误类型、典型场景。这样Agent翻历史轨迹时，才知道“自己当时是拿哪个工具解决了什么问题”，技能归纳才有素材。我见过不少项目，工具函数写得草率，description只有一句含糊的话，Agent调用时靠“猜”，出错后连复盘都不知道错在哪一步。这种工具定义方式，做普通任务勉强能跑，做自我进化基本没戏。

另外，工具层必须有“自省”能力。所谓自省，就是允许Agent离线查看工具的执行历史：哪些参数组合成功率最高、哪些场景下这个工具最容易出异常。把这些统计信息暴露给进化服务，它才能判断要不要生成一个“先预处理再调工具”的新技能。没有这个数据，你的Agent就像一个人只知道“有个工具很好用”，却说不清好在哪、适合什么场景。

2.3 运行时抽象：把“进化”做成一个独立服务

前面我反复提到“旁路服务”，这里展开说下我的实际做法。整个系统我分成两条链路：在线链路负责执行任务，离线链路负责学习和进化。两条链路通过日志队列和配置中心衔接，互不阻塞。

在线链路的职责很纯粹：接任务、调度模型、调用工具、维护短期上下文、把每一步轨迹（包括反思触发点）写进日志。轨迹日志的字段我一般固定成：任务ID、用户意图、上下文摘要、Agent中间推理、工具调用序列（含入参出参）、最终结果、耗时、人工反馈（如果有）。这套日志是进化服务唯一的“食物”，所以宁可多记也别少记。

离线链路的职责是：定时或按量消费轨迹日志，先做质量过滤，再跑反思器生成改进建议，接着把建议翻译成技能描述或策略变更，然后在新旧版本上做对比评测，评测通过后生成正式版本，推送到在线链路的配置中心。整个过程像一条“质检流水线”。我特别强调质量过滤这一步：不是所有轨迹都有资格进入反思环节，低质量的样本进多少污染多少。你可以设最低标准，比如任务完整跑完、没有超时、人工反馈评分不低于阈值，才算有效样本。

把进化做成独立服务最大的好处是你可以像对待一个单独产品一样对待它：单独部署、单独扩容、单独回滚。某一次进化策略写错了，只需要下线进化服务，线上Agent完全不受影响。我早期把进化逻辑塞在Agent内部，有一次反思器产生死循环，直接把线上的推理速度拖慢了几十倍。那次之后我彻底改成旁路架构，再也不敢把学习和执行耦合在同一个进程里。

3. 底层机制详解：反馈闭环、技能固化与记忆沉淀

3.1 反馈信号怎么设计才不会被“带偏”

进化系统的第一性问题不是“怎么反思”，而是“用什么信号驱动反思”。反馈信号质量差，后续所有环节都是空中楼阁。我按来源和可靠性把反馈分成几类：

• 环境反馈：任务执行过程中系统返回的硬信号，比如调用工具报错、接口超时、结果格式校验失败。这类信号最可靠，但很稀疏，很多任务从头到尾不报错但结果就是烂。
• 用户反馈：用户显式的点赞、点踩、纠错。可靠度其次，但覆盖不全，大多数用户懒得反馈。
• 结果校验器：用规则或另一个模型检查Agent产出是否符合要求。可控性强，但需要额外开发。
• 自我评估：让Agent自己判断“这次做得好不好”。最灵活，但可靠性最差，模型容易高估自己。

实际项目里这些信号通常要组合使用。我见过一个典型的失败案例：某团队只用了环境反馈（只有报错才算失败），结果Agent学出了一套“避开报错但完全不解决问题”的路径——遇到不确定的数据就跳过，任务倒是没报错，但交付质量一塌糊涂。这就是反馈信号被“钻空子”了。

设计反馈信号有个生活化的类比：教小孩做菜。你不能只在他把锅烧糊时批评，也不能只在他喊“我做完了”时表扬。你要在过程里设置检查点：切菜尺寸对不对、火候有没有超标、调料顺序是否合理。对应到Agent，就是拆任务环节，在每个关键节点放一个“过程反馈”。比如任务是“写一份项目周报”，节点反馈可以包括：是否提取了核心数据、是否对比了上周进展、是否标注了风险项。过程反馈比结果反馈更细腻，也更容易被进化系统转化为可执行的改进项。

3.2 自我反思模块的两种实现路线

反思器是整个进化系统的大脑，它的输入是轨迹样本和反馈信号，输出是结构化的改进建议。我在不同项目里试过两种实现路线，各有适用场景。

路线A：直接让大模型写反思。做法是给模型看一段轨迹，让它用自然语言总结“哪里出了问题、下次怎么做”。优点是成本低、实现快，prompt写得好效果就不错。缺点是输出不稳定，经常总结出“我要更细心”这种正确但无用的废话。所以用这条路必须强制结构化输出，让模型按固定格式返回：问题事件、根因分类、修正动作、验证方式。

我常用的反思提示词骨架长这样：

你是Agent进化系统的反思器。分析以下任务轨迹，定位Agent出现的具体失误。 输出要求： 1. 失误事件：用一句话描述在哪一步、什么情境下出了问题。 2. 根因分类：从下列选项中选择最适合的一个： - 检索偏差（用错了记忆/知识） - 工具误用（参数错误/工具与意图不匹配） - 规划缺失（步骤顺序不合理/缺少必要步骤） - 表达不清（输出内容符合流程但用户难以理解） 3. 修正动作：给出可执行的改进建议，必须具体到“在某类场景下应该采用什么操作”。 4. 验证方式：说明如何判断修正是否有效，最好给出可量化的指标。

路线B：结构化反思，不依赖大模型的“灵感”。做法是先固定一套问题模式库，比如“工具连续失败N次”“重试后结果没有变化”“多个工具调用顺序混乱”，再用程序去轨迹里匹配这些模式，命中后走预设的修正模板。优点是稳定、可解释、容易测试；缺点是需要人工设计模式，覆盖面有限。

我的建议是新项目先走路线B，把最常踩的坑固化成规则，跑通之后再叠加路线A。我只用路线A作为“增量发现器”，让它去挖掘规则库里没有的新问题类型，而不是让它直接驱动进化决策。这样即使大模型说胡话，也不会对整个系统造成大范围污染。

无论走哪条路线，反思器都必须绑定具体的事件样本，不能只输出泛泛的结论。试想一下，如果反思结果是“Agent在写SQL时不够仔细”，这个结论没有任何可操作性；但如果它是“当查询条件涉及三张以上表连接时，Agent没有先检查关联键的一致性，导致结果缺失”，后面的人或程序才能依据这个结论设计技能。

3.3 技能固化：把“做对了”变成“下次还会”

反思器产出的建议，最终要变成可复用的技能，否则进化就停留在口头。技能库的数据结构我建议这样设计：

技能ID: sk-20250618-001 技能名称: 复杂SQL联表查询前置校验 触发条件: 任务类型: 数据查询 特征: 涉及表连接数量>=3 上下文关键词: [join, 关联, 多表] 执行步骤: - step 1: 提取所有关联字段及其类型 - step 2: 检查关联字段是否为目标表的合法字段 - step 3: 联合数据字典校验关联键唯一性 - step 4: 存在风险时先给出修正建议，再执行查询 校验项: - 查询结果行数与预期偏差不超过阈值 - 关联字段类型匹配 版本: 1.0 成功率: 0.93 来源轨迹: [task-88214, task-88231] 负反馈计数: 0

看到关键点了吧？技能必须包含触发条件、执行步骤、校验项、来源轨迹。触发条件决定了Agent在什么情境下想起这个技能，没有它技能就只是躺在库里的死数据；校验项用于上线前评测和上线后监控；来源轨迹保证了可追溯性——出故障时能倒查“这技能是从哪两条轨迹里提炼出来的”。

从轨迹里生成技能，我通常分三步。第一步，把所有成功样本按“任务类型+工具调用模式”聚类；第二步，用大模型把一个簇里的共同步骤归纳成可执行的流程，同时让它在步骤里标注关键参数和注意事项；第三步，人工或规则审核可读性和正确性，通过后写入技能库。注意，技能不是越通用越好。一个适用范围太广的技能，往往对具体场景都不够精准。我宁愿技能库里同时存在三个“SQL校验”技能，分别针对“多表关联”“聚合函数”“子查询嵌套”，也不用一个万金油技能硬套所有情况。

技能上线不等于进化完成，还必须设计退化检测。我给每个技能挂了两个计数器：调用次数和负反馈次数。当负反馈率超过阈值，技能自动降级为“仅记录不执行”，同时生成一条待人工处理的工单。这一步非常关键，因为大模型生成的技能，哪怕当时评测通过，真实环境里也可能遇到没见过的边界情况。如果没有退化检测，一个坏技能会在线上悄悄工作很久，造成大量隐性损失。

4. 手把手搭建一个可自我进化的Demo Agent

4.1 最小闭环长什么样：组件拆解

纸上谈兵聊了这么多，我交个实底：一个最小可用的自我进化Agent，到底需要哪些零件。我按“能跑起来、能留日志、能改自己”三个标准，拆出下面几个组件：

1. 任务调度器：接收请求，分配任务ID，控制并发，维护任务生命周期。
2. 执行核心：标准的大模型推理加工具调用循环。每一步都输出原始轨迹，包括中间推理、工具入参出参、耗时。
3. 记忆管理器：负责短期上下文组装和长期记忆读写。所有读取的记忆都带来源标签，便于复盘。
4. 反思器（离线）：消费成功或失败的轨迹样本，产出结构化反思事件。
5. 技能生成器（离线）：把反思事件和成功轨迹归纳成技能草案。
6. 评测器（离线）：用固定评测集对技能草案做对比验证，通过后才能被标记为“可用”。
7. 技能库（在线）：可版本化、可回滚。执行核心在启动任务前会先检索匹配技能。
8. 进化控制器：编排离线流程，控制技能上线和下线。

这么小的闭环大概多长时间能搭出来？如果你对代码还熟悉，一个周末可以出雏形。最开始不需要做得很重，用配置文件代替数据库，用本地JSON代替向量库，先把闭环跑通，再逐步替换成更稳固的组件。

这个最小闭环的数据流是：任务进入执行核心，执行核心把轨迹交给记忆管理器和反思器，反思器在离线侧产出技能草案，评测器做验证，验证通过的技能写回技能库，下一次任务执行时直接从技能库取用。我特别建议第一版就把“人工确认”接口留出来——技能草案先不自动上线，而是推到审核队列里由人点一下“通过”。这个设计能帮你挡掉初期大部分质量问题。

4.2 核心模块实现：反思器、记忆管理器、技能库

我给你一份可以照着写的核心逻辑伪代码，语言用的是Python，但思路跟具体语言无关。

记忆管理器：核心是“先按情境粗筛，再做语义相似度排序”。

class MemoryManager: def __init__(self, vector_store, max_recall=5): self.vector_store = vector_store self.max_recall = max_recall def remember(self, task_context: dict) -> list: # 1. 情境粗筛：用任务类型、数据规模等字段过滤 candidates = self.vector_store.filter( task_type=task_context["task_type"], status__in=["success", "partial"], min_quality_score=0.6 ) # 2. 语义排序：在候选集里做向量相似度排序 ranked = self.vector_store.similarity_search( task_context["query"], top_k=self.max_recall, candidates=candidates ) return ranked

一些项目图省事，不做第一步粗筛，直接全局向量检索，结果就是Agent经常拿“八竿子打不着”的经验来指导当前任务。粗筛这一步多加三行代码，效果天差地别。

反思器：输入轨迹，输出结构化问题事件。

class Reflector: def __init__(self, llm_client, problem_patterns): self.llm = llm_client self.problem_patterns = problem_patterns def reflect(self, trajectory: dict) -> list: events = [] # 先用规则库匹配已知问题模式 for pattern in self.problem_patterns: if pattern.matches(trajectory): events.append(pattern.to_reflection()) # 如果有未被规则覆盖的异常，交给大模型补充分析 if not events: events = self.llm.generate_reflection(trajectory) return events

反思器千万不要“每次任务都跑”，成本高且噪音大。我一般只在三种情况下触发：任务失败、结果校验器评分低、用户给了负反馈。成功的任务默认不反思，只进记忆库积累。

技能库：检索匹配时按“触发条件”走，启动执行前调用。

class SkillLibrary: def __init__(self, skills): self.skills = [] def lookup(self, task_context: dict) -> str | None: for skill in self.skills: if skill.is_active() and skill.match(task_context): return skill.instructions return None def disable(self, skill_id: str): for skill in self.skills: if skill.id == skill_id: skill.deactivate()

这个lookup方法要在执行核心的推理循环里被调用。大模型开始规划之前，先把记忆和技能一起塞进上下文，让Agent“带着解法去做题”。技能匹配度不能搞太严格，否则召回率太低；我习惯用一个置信度阈值，如果所有技能都不超过阈值，就让Agent自由发挥。自由发挥的结果会被记录，正好成了未来生成新技能的素材。

4.3 渐进式进化策略与回滚机制

自进化系统最怕的是一夜之间“进化过度”，把之前好端端的行为改坏了。我强烈建议用三档渐进式进化，这也是我在生产环境跑下来最稳的模式：

• 记录档：进化系统只做记忆积累，对所有轨迹打标签、存库，但不生成任何新技能、不改任何策略。适合刚开始收集数据时用。
• 建议档：开始生成技能和策略草案，但一律进人工审核队列。审核通过才上线。适合验证反思器和技能生成器是否靠谱。
• 自动档：低风险技能的生成、评测、上线、下线路全部自动化，但高风险操作（比如涉及支付、删除、外发）仍然强制人工兜底。适合系统运行稳定后逐步放开。

这个策略的本质是“给进化加保险丝”。你永远不知道哪次反思会产出意想不到的结论，所以要让系统先从“不会犯错”做起。我在一个内部项目里跑了两个月，第一个月一直是建议档，人工审核阶段就拦掉了大量明显有问题的技能草案。到了第二个月我才针对一小类低风险任务放开自动档，系统自动上线了十几个新技能，整体任务成功率提升了约四成。

回滚机制方面，每个技能和策略版本都有一个权重值：负反馈计数。负反馈计数递增的规则要写死，比如“执行失败一次加1分，用户点踩一次加2分”。当计数超过阈值，进化控制器自动触发回滚，把该技能从在线库里摘除，同时回到上一个可信版本。注意这个可信版本不是指“上一版”，而是“有足够正反馈记录的那个版本”。所以版本管理别只放在代码里，要放进数据库，每次上线都记一条带时间戳的记录。

5. 跑起来之后：常见问题与排查技巧实录

5.1 记忆污染：Agent开始胡言乱语的元凶

我踩过最深的坑就是记忆污染。现象是：Agent跑了几天后，回答开始变“飘”，明明之前处理得很好的任务，现在频繁出错。查来查去，问题出在记忆库写入了大量低质量轨迹。

什么算低质量轨迹？任务被用户中途打断、工具一直重试但最后靠运气成功、结果校验器没跑但Agent自我感觉良好。这些样本一旦进入长期记忆，就会变成“错误的正确答案”，被后续任务检索到，指挥Agent往错误方向走。这就像团队里一个不靠谱的同事把错误经验写进了新人手册，带歪一整批新人。

我的排查方法分三步。第一步，检查记忆库的“来源轨迹质量分布”，如果发现评分低于阈值的历史记录占比超过5%，那基本就是污染源。第二步，做一次定向清理，把所有低分来源的记忆标记为不可用。第三步，最关键的是给写入判定补上“质量门禁”：轨迹必须满足“任务完整结束、结果校验器评分合格、无异常重试”等硬性条件，才有资格进入长期记忆。宁可让记忆库空一点，也不要让垃圾样本留着，这是我要你记住的第一条铁律。

5.2 进化不收敛：越改越差的死循环

第二个大坑是“进化振荡”。具体表现是：这个版本把策略A改成了B，结果下一轮评测发现B不如A，回滚之后又发现A也不行，于是系统在A和B之间反复横跳，评估指标像过山车。根源通常是两个：反馈信号噪声太大，或者新老策略的对比评测不严谨。

反馈信号噪声大的典型场景是用户行为不稳定——同一个回复，十个用户里五个点踩五个点赞。这时候拿用户反馈去驱动策略进化就是不靠谱的，必须换更稳定的信号，比如回归测试集、客观结果校验、任务耗时这类硬指标。新老策略评测不严谨，往往是评测集太薄，或者评测任务和线上任务分布不一致。我建议建一个固定的回归任务集，里面塞三种题目：线上真实历史任务、人工构造的边界情况、已知的困难case。每次新技能要上线，先在这个固定集上做新旧对比，A/B测试的置信度不达标就不允许上。

还要加一个“进化冷却时间”。某个技能刚上线，至少要积累足够多的真实调用样本再评估它的表现，不要因为一次负反馈就立刻把它踢掉。我经常告诉同事，进化系统要有“记忆曲线”，给新技能一点试错耐心，但一旦负反馈计数超过阈值，就果断回滚，不要恋战。

5.3 可复现性与安全边界的权衡

自我进化系统最反直觉的一个要求是必须可复现。你可能会想，进化本来就是“自我迭代”，怎么可能每次结果一样？我这里说的可复现，指的是“进化决策可解释”：任何一个技能上线，你都能说清楚它是因为什么事件、哪些历史轨迹、什么评测结论才被批准的。

想要做到这一点，核心是把每一次进化操作都落成一条不可删除的审计记录。记录内容至少包括：进化触发时间、源轨迹ID、反思事件、技能草案、评测结果、上线版本号、当前状态。前期会麻烦一点，但当系统进化到几十上百个技能的时候，你一定会感激这个设计。否则某一天线上出了个诡异bug，你想回退都找不到该回退到哪。

安全边界方面，我给所有技能按风险分了三类：低风险（改文案、调格式、优化检索）、中风险（改SQL、批量操作、跨系统触发动作）、高风险（涉及资金、权限、用户隐私数据的处理）。低风险技能可以逐步放开自动档，中风险必须经过评测器加人工闸门，高风险技能的设计初衷就不应该走全自动进化路线——这类建议最多生成“预警”或“错误提示”，不能自动触发写操作。说到底，进化系统学得再怎么聪明，也得有不聪明时兜底的人和人肉确认的机制。

6. 这一篇之外：我踩过的坑和后续扩展方向

最后说几个很少被写进文档、但我实际吃过大亏的点。

第一个教训：进化系统的评测集才是真正的核心资产。我早期一门心思调反思器和技能生成器，后来发现效果迟迟上不去，卡点居然在评测集太粗糙。评测集就像考试卷子，卷子出得不准，再聪明的学生也答不对方向。建议在项目启动的第一周就人工标注两百条高质量评测任务，后面所有进化决策都拿它们做基准。这两百条任务，决定了系统进化的上限。

第二个教训：日志必须留全，尤其是中间推理和工具入参出参。很多人为了省存储，只留最终结果。等到想复现某个问题、追溯某条技能来源时，发现素材已经被截断，只能干瞪眼。我现在的做法是：轨迹日志至少保留三十天，关键字段全部原始记录，不做摘要截断。

第三个教训：不要追求“全自动进化”一步到位。市场上很多宣传稿把全自动吹得神乎其神，但真实项目里，人工确认仍然是不可替代的“安全气囊”。哪怕系统已经跑得很稳，也至少留一个“人工审批接口”备用。进化这件事，永远是“能闭环”比“全自动”重要，“稳”比“快”重要。

往后续扩展想，两个方向让我特别感兴趣。一个是多Agent协作场景里的集体进化——多个Agent各跑各的任务，它们产生的经验如何汇总成一个共享技能库，又如何避免某个Agent的偏差传染给其他Agent。另一个是领域专用技能库的生态化——让不同团队积累的技能可以像积木一样组合和复用，重新上线前做一次交叉验证。这些方向比单Agent进化复杂得多，但边界也更清晰，做好了会变成真正的行业基础设施。回到开头那句话，自我进化这条路，走得慢一点没关系，方向和闭环对了，时间会给你回报。