有一种很特别的感觉：两个独立的研究团队，彼此互不相干，却得出了同一个让人不太舒服的结论。
嗨，我是 Lena。当我把 EvoSkills 和 EvoSkill 两篇论文连着读完之后，我停下来了。不是因为结果有多出人意料——而是因为两篇论文都没有回避数据真正揭示的东西：人类为 AI agent 编写的技能存在天花板，而 agent 可以靠自己进化突破这个上限。
这不是一个小结论。而接下来的问题——那我们该怎么办？——我到现在都没能停止思考。
EvoSkills 和 EvoSkill 到底证明了什么
两篇独立研究论文，同一个结论：人工编写的技能存在上限，agent 可以自主进化突破它。
人机认知错位问题
这一部分让我有点措手不及。
EvoSkills 不仅证明了进化出的技能表现更好，还量化了为什么人工编写的技能表现不佳——答案比大多数人想象的更具结构性。人类设计者倾向于按照我们思考问题的方式来编写工作流：线性步骤、清晰的抽象、整齐的决策树。但 LLM 的推理方式并非如此。
在 SkillsBench 上——这个专门为测试这一点而构建的基准测试——差距不是微乎其微的。人工精选的技能与大语言模型实际处理多步骤任务的方式之间存在可量化的认知错位。这些技能本身没有错——只是它们的形态并不适合执行它们的推理引擎。
我反复回到这一点。不是人类不擅长写指令，而是我们在为人类可读性做优化，而不是为 LLM 的执行模式做优化。这是两个不同的优化目标。
自我进化到底产出了什么
这些数字值得仔细看一下：
| 指标 | 基线（无技能） | 人工精选技能 | 进化技能（第 5 轮） |
|---|---|---|---|
| EvoSkills 通过率 | ~34.5% | ~60%（约） | 75% |
| 超越人类所需轮数 | — | — | 第 3 轮 |
| 相对无技能增益 | — | — | +40.5pp |
| EvoSkill OfficeQA | baseline | — | 0.073 |
| EvoSkill SealQA | baseline | — | 0.121 |
从 32% 起步，agent 在五轮进化后达到了 75% 的通过率。到第三轮时，它就已经超过了人工精选的上限。这一点让我真的很难用其他理由解释过去：agent 不只是在缩小差距——它在反方向拉开差距。
EvoSkill 在不同的任务领域（办公文档 QA 和基于网络的研究）上显示了相同方向的结果。绝对增益较小，但方向一致。OfficeQA 上 +7.3%，SealQA 上 +12.1%。都超过了人工编写的基线。
跨模型和跨任务迁移
这个细节我差点一扫而过，但不应该。
为一个 LLM 进化出的技能在六个不同模型之间迁移时获得了 +35pp 到 +44pp 的增益。这不是一个小小的可移植性优势——这说明技能编码的是关于任务结构的某些东西，而不仅仅是特定模型的特性。
更有意思的是：SealQA 技能零样本迁移到 BrowseComp 时获得了 +5.3% 的增益。这个技能从未为 BrowseComp 设计过，但它就是在那里起了作用。这暗示被进化出来的东西更接近于一种可泛化的执行策略，而不是一个狭窄的 prompt 微调。
我还不完全确定该怎么理解这件事。但我记下了。
两篇论文都碰到的边界
到这里我明显放慢了速度。
两篇论文都展示了真实的、可复现的增益。而两篇论文仔细读下来，都大致在同一个位置碰了壁。这堵墙不完全是技术性的——它是架构性的。
单 Agent 范围
两项研究中每个进化出的技能都存在于单个 agent 的执行上下文中。具体来说：agent 本地文件系统上的一个文件夹，一个作用域限定在该 agent 会话中的版本化产物。
当 agent 被替换、更新或重新部署时，进化成果不会自动继承——除非有人手动迁移。研究设置中没有内置继承机制。进化是真实的，但持久性是脆弱的。
没有网络传播
两篇论文中，每个新 agent 都从零开始自己的进化循环。
想想这在任何合理的部署规模下意味着什么。十个 agent 运行 EvoSkill 风格的进化循环，就产出十份独立的进化历史。这些历史不会合并，不会做冲突解决。那个让单 agent 内部结果如此惊人的复合增益——从 32% 到 75% 的轨迹——对每个新启动的 agent 都归零重来。
改进是局部的。起点永远一样。
论文明确留下的开放问题
EvoSkill 直接将此标记为未来工作，而非疏忽：共享技能库，让在一个任务上发现的技能可以被其他 agent 和用户浏览、组合和复用。
这句话很重要。研究者并非没有看到这个问题——他们明确指出了它。这是一个开放的研究问题，不是一个等着发布的实现细节。生成问题（agent 能否进化出更好的技能？）现在有了强有力的经验证据。传播问题（经过验证的进化技能如何在 agent 之间大规模流动？）还没有。
论文在系统层面留下的空白
我想在这里谨慎一些，因为这一节很容易被误读为产品推销。不是的。这是一个工程问题，我认为值得从工程本身的角度认真对待。
局部进化与共享继承之间的鸿沟
自我进化技能干净利落地解决了一个问题：对于一个重复执行任务的单 agent，自动进化产出的执行产物优于人工编写。这一点现在有了充分的支撑。
它没有解决的是：传播问题。一个经过验证的进化技能如何在 agent 之间流动？网络如何评估一个技能是否可靠，然后才允许它传播？适应度信号——证明技能确实在多样化的任务和模型上有效的证据——如何在超出单个 agent 会话历史的尺度上积累？
这些不是反问句。它们是研究成果和可部署基础设施原语之间的鸿沟。
网络级协议需要处理什么
如果你要设计基础设施来弥合这个鸿沟——我是说真正去设计，而不是营销——你至少需要：
- 验证层：进化技能在传播之前进行质量评估，而不是之后
- 生命周期模型：跨技能历史的晋升、拒绝和撤销追踪
- 获取机制：agent 检索已验证的能力，而无需从头重建
- 冲突解决方案：当两个独立进化出的技能针对同一任务产生分歧时，系统如何仲裁？
这些都不是 EvoSkills 或 EvoSkill 架构所解决的问题。两篇论文都明确说明了这一点。Model Context Protocol 在 agent 接口层解决了工具连接问题，但它没有定义技能进化或继承的生命周期。这些确实是技术栈不同层面上的不同问题。
关于 agent 能力共享的更广泛探索，Google 的 Agent-to-Agent（A2A）协议规范值得一读——它定义了 agent 之间的通信模式，但技能传播语义仍然不在其范围之内。
为什么这个鸿沟对构建者团队很重要
一个团队部署十个运行 EvoSkill 风格进化循环的 agent，就会得到十个独立的技能仓库。在当前研究中，没有明确定义的方式来：
- 合并这些仓库
- 浮现哪些进化技能最可靠
- 防止低质量的进化技能扩散到其他 agent
- 追踪当底层模型或任务上下文变化时，哪个版本的技能仍然有效
这是一个未解决的基础设施问题。不是一个小问题。
这对你现在构建 Agent 工作流意味着什么
我不认为面对这一切的正确反应是瘫痪。研究在某些方面已经足够清晰，可以立即行动。
停止为复杂任务手写技能
这一点我还是比较有信心的。
对于多步骤的专业任务——文档分析、网络研究、结构化推理链——EvoSkills 和 EvoSkill 的结果表明，自动进化产出的执行产物优于人工编写。不是微小的优势，而是实质性的优势，跨越多个模型，并且能迁移到新任务。
LangChain 关于 agent 记忆和技能脚手架的文档提供了一个合理的基础，帮助思考在哪里可以将进化循环引入现有的 agent 架构中。简短版本：如果你还在为复杂任务手动调优技能指令，并且在困惑为什么性能遇到了瓶颈，那个瓶颈可能是结构性的，不是靠反复迭代能修复的。
想想进化出的技能该住在哪里
一个局部进化出来、只在本地留着的技能是一个私有资产。有用，但有边界。
研究社区正在积极探索下一步：经过验证的、可共享的、可继承的能力，在网络尺度上运作。微软研究院的 AutoGen 框架是探索多 agent 协作模式的较成熟的开源项目之一，尤其值得关注它如何处理 agent 之间的进化能力迁移。
目前的实际启示是：在设计你的进化循环时就考虑可移植性，即使可移植性基础设施还不完全存在。这意味着记录进化出的技能版本、追踪它们通过了哪些评估基准，并将进化产物与 agent 运行时分开保存。
在构建之前值得思考的问题
在你为一个新项目确定特定的 agent 架构之前，我觉得这些问题值得好好想想：
- 进化出的技能在会话结束后住在哪里？ 如果答案是"在 agent 的本地文件系统里，没有导出路径"，那你构建的是一个没有复合价值路径的私有资产。
- 在其他 agent 使用之前，谁来验证它们？ 自动化验证基准是一种答案；人工审核关卡是另一种。都不是零成本的。
- 你如何追踪哪个版本的技能仍然可靠？ 随着底层模型更新、任务上下文变化，一个在二月有效的技能到八月可能就失效了。如果你在构建任何打算运行数月的东西，版本追踪和重新评估不是可选项。
OpenAI 关于工具使用和函数调用模式的研究在这里很有参考价值，可以帮助理解技能调用如何在 API 层面被记录和追踪——这是任何有意义的技能可靠性追踪的前提条件。
常见问题
在 agent 系统中，工具（tool）和技能（skill）的区别是什么？
工具通常是一个离散的能力，有明确的输入/输出接口——一次函数调用、一个 API 端点、一个代码执行器。技能是更高阶的产物：一个结构化的工作流、推理策略或多步骤执行模式，用于编排工具的使用。工具是原子的，技能是组合的。EvoSkills 和 EvoSkill 论文专门针对技能层——决定 agent 如何处理任务的部分，而不仅仅是它能调用什么能力。
EvoSkills 和 EvoSkill 有什么区别？
EvoSkills 聚焦于任务无关的技能进化，在 SkillsBench 上进行评估——这是一个覆盖多种专业任务的多领域基准测试。它展示了五轮进化中通过率从 32% 提升到 75%，并证明进化技能在第三轮就超过了人工精选水平。EvoSkill 更专注于知识密集型 QA 任务（OfficeQA、SealQA），着重强调零样本跨任务迁移——即为 SealQA 进化出的技能无需重新训练就迁移到了 BrowseComp。两篇论文都证明了自动进化优于人工编写；它们在范围和所刻画的特定迁移属性上有所不同。
EvoSkills 或 EvoSkill 进化出的技能可以与任何 agent 一起使用吗？
跨模型迁移结果（在六个 LLM 上 +35pp 到 +44pp）表明，进化技能编码了可跨不同模型架构泛化的任务结构信息。实际上，"任何 agent"说得太绝对了——两篇论文都在特定框架和基准测试内操作。更准确的说法是：在一个模型下进化出的技能在受控评估中有意义地迁移到了其他模型。在不同 agent 运行时之间的真实世界可移植性仍然是一个开放的实现问题。
什么是 SkillsBench？它的结果有多可靠？
SkillsBench 是 EvoSkills 论文中引入的基准测试，旨在评估 agent 在多步骤专业任务中的技能质量。它的结构设计不仅衡量任务完成度，还衡量技能产物本身的质量——不仅看 agent 是否得到了正确答案，还看它使用的技能是否能够泛化。与任何研究基准一样，结果应在上下文中解读：SkillsBench 由构建 EvoSkills 的同一团队设计，在评估独立性方面值得注意。跨基准验证（SealQA → BrowseComp 迁移）提供了一些外部信号，但该领域将受益于更多多样化的、独立构建的评估框架。
一个共享技能库要在网络规模上运作，实际需要什么？
至少需要：一个在进化技能传播之前测试它们的验证机制，一个追踪晋升和撤销的版本控制和生命周期系统，一个语义索引层以便 agent 无需穷举搜索就能识别相关技能，以及一种在独立进化出的技能针对同一任务产生分歧时进行冲突解决的方案。更难的问题是治理（谁决定一个技能"够好"可以共享？）和质量衰减（如何检测一个之前可靠的技能在上下文变化后发生了退化？）。两篇论文都没有回答这些问题——它们被明确标记为未来工作。
在 EvoSkill 的语境中，零样本技能迁移是什么意思？
零样本迁移意味着为一个任务进化出的技能被直接应用于另一个不同的任务，无需任何额外训练、微调或适配。在 EvoSkill 的案例中：为 SealQA 进化出的技能被直接应用于 BrowseComp——一个具有不同结构和领域的网络研究任务——并在没有任何任务特定重新训练的情况下产生了 +5.3% 的增益。这里的"零样本"指的是技能产物，而非底层模型。模型没有被微调；技能的 prompt/工作流被原样复用。复用产生正向增益，这暗示该技能编码的是关于研究任务结构的某些可泛化的东西，而非 SealQA 格式所特有的狭窄内容。
往期文章：
