有一个时刻，我相信大部分 agent 开发者都经历过——通常是第三次、第四次手动把同一种能力重写进新 agent 的时候——突然开窍了。这中间应该有更好的一层抽象。

Skill 是大多数人最先接触到的方案。它确实解决了实际问题。但最近我在深挖 GEP 资产在 EvoMap 内部的运作机制，发现两者之间的差距，比表面看起来更加结构性。

我是 Lena。这不是一篇"Skill 不好"的文章。更准确地说是：我一直隐约觉得 Skill 有个天花板，但很长一段时间说不清到底是什么，现在我终于找到了词。

2026 年的 Skill 生态增长极快。Agent Skills 已经把自己定位为新兴的开放 Skill 注册中心，提供按需加载的 Skill 文档。EvoSkills、Claude-to-IM-skill、Hermes skills、OpenHarness skills——它们都是同一核心格式的变体：一个结构化 Markdown 文件，agent 在运行时加载它以获取程序性知识。

这种格式刻意保持轻量。一个 skill.md 文档描述了 Skill 做什么、什么时候适用、期望什么输入、遵循什么步骤。Agent 读取它，融入上下文，然后照着执行。没有专门的运行时，没有 SDK 依赖，没有专有格式。Claude、GPT-4o、Gemini 或任何能读文本文件的模型都能用。

这种简洁性是真正的优势。我不想轻描淡写——Skill 确实是一个重要的进步。

静态 prompt 是单体的。你把一大段指令硬编码到 system prompt 里，不管用不用得上它都在那里，一旦你想在不同 agent 之间复用其中任何部分，就只能手动复制粘贴。Skill 解决了这个问题。你把知识拆解成模块化的文档。处理账单的 agent 加载账单 Skill，做代码审查的 agent 加载审查 Skill。能力变得可移植了。

结果是 Skill 分享确实在发生。开发者发布 Skill 文件，持续维护，跨项目使用。Model Context Protocol 规范 让"agent 能力应该是可外部化、可组合的"这个理念成为共识——Skill 是这个理念在知识层的自然表达。

对很大一类使用场景来说，故事到这里就结束了。Skill 够用了。

但我一直注意到，在某些场景下它对我来说不够。花了我好一阵子才搞清到底为什么。

Skill 最直接、最可量化的收益是上下文效率。在复杂的 agent 管线里，system prompt 膨胀得很快——尤其当你试图让一个 agent 在多个不同领域都有能力的时候。Skill 让你只引入当前任务相关的程序性知识。

处理客户升级的 agent 加载升级处理 Skill。解析 API 响应的 agent 加载 JSON 提取 Skill。其余的上下文保持干净。

这比听起来更重要。根据 Anthropic 关于构建有效 agent 的指南，生产 agent 系统失败的主要原因之一是上下文污染——无关信息降低了 agent 遵循真正重要的指令的能力。Skill 通过让知识模块化、按需加载来直接应对这个问题。

Agent Skills 正在朝着一个真正有用的方向努力：一个社区维护的注册中心，"从 PDF 发票中提取结构化数据"或"遇到限速时指数退避重试"不需要每个开发者从头造一遍。

和开源软件的类比是真实的。如果有人已经搞定了处理某个常见任务的正确流程，后面的人就不该需要重新发现这些知识。Skill 让程序性知识可共享，这一点是静态 prompt 永远做不到的。

OpenAPI Specification 为 API 契约确立了类似的原则——标准化描述格式，工具化和复用自然跟上。agentskills.io 正在为 agent 知识做同样的事。

这就是我一直在转圈的部分。

Skill 是声明式的。一个 Skill 文件说的是：该怎么做。它不会告诉你这个方法在最近 500 次执行中效果如何。它没有办法记录在模型更新之后成功率下降了。它不能因为表现出色而被提升，也不能在开始产出糟糕结果时被撤下。

格式里没有嵌入适应度信号。没有生命周期管理。两年前某个已经不再维护的人写的 Skill，在注册中心里看起来和上周刚刚经过上千次生产验证的 Skill 一模一样。从 agent 的角度看，它们没有区别。

这不是设计缺陷——而是范围决策。Skill 是知识文档。它不试图成为质量管控的基础设施。但一旦你进入能力质量很重要的场景——多个 agent、共享工作流、生产环境——这一层的缺失就开始制造真实的问题。

Skill 是静止的知识，它不携带性能的证据。

Genome Evolution Protocol 引入了两种在架构上与 Skill 文件截然不同的资产类型，尽管它们解决的是相邻的问题。我在这里要讲的，是理解"什么时候用哪个方案"最关键的那个结构性差异。

基因（Gene）是与 Skill 文件最接近的概念类比。它编码了一种可复用的策略或能力。但结构性差异立刻显现：Gene 是经过验证的。它有版本号、溯源链，以及从真实 agent 运行中的实际执行结果推导出的适应度评分。

原子这个词很重要。Gene 是最小的能力单元，可以被独立测试、提升、遗传和与其他 Gene 组合。如果你有一个"遇到限速时指数退避重试"的 Gene，它携带着结构化的证据：这个模式有效，跨哪些模型、在什么条件下、执行了多少次、成功率是多少。

这些证据恰恰是 Skill 文件所没有的。

Gene 还有版本历史。当底层模型发生变化、一个之前有效的策略开始表现不同时，这种漂移会被捕获。你可以看到 Gene 的适应度评分在什么时候发生了变化，以及触发变化的原因。你可以回滚到之前的版本。你可以 fork 它，拿修改后的方案和原版进行对比测试。

基因胶囊（Capsule）和 Gene 有质的不同——而且它和 Skill 文件的差异，在 Skill 生态中找不到类比。

Capsule 是一次完整的、成功执行的记录。不是关于该做什么的指令，而是实际发生了什么的可审计轨迹：agent 做了什么、在每一步做了什么决策、在什么上下文中运行、输出是什么、以及什么评估确认了它是成功的。

Capsule 通过 Evolution Event 日志进行生命周期管理。你可以检视一个 Capsule 的完整溯源：哪个 agent 产生了它、什么触发了执行、输入和输出分别是什么、如何被评估的、以及它在状态机中的当前状态。

这使得 Capsule 不仅适用于能力复用，还适用于调试、合规和能力质量验证。当生产 agent 管线中出问题时，你可以沿着使用的 Capsule 回溯，看到它编码的确切执行路径，理解为什么它在原始上下文中有效但在当前上下文中失败了。

LangChain 的记忆架构文档 描述了一个相关问题——agent 在不同会话间遗忘了什么有效——但给出的方案本质上是"把输出存到某个地方"。Capsule 是针对这个问题的结构化基础设施：成功的执行被捕获、验证、版本化，并可供其他 agent 继承。

这是我觉得在架构上最有意思的部分。

GEP 资产有一个生命周期状态机：candidate → promoted → rejected → revoked。

每一个新的 Gene 或 Capsule 都以 candidate 身份进入。它进入评估流程——要么通过 GEP Arena 共识机制，要么通过直接验证标准——然后要么被提升为活跃状态，要么被拒绝。被提升的资产后续可以被撤销，如果性能下降、条件变化、或者有更高质量的替代品出现。

Skill 没有这些。一个 Skill 文件要么存在于注册中心，要么不存在。没有质量关卡，没有提升事件，没有撤销路径。这个格式没有机制来区分一个在生产中运行了两年、经过上千次验证的 Skill，和一个上周刚写出来、从未被测试过的 Skill。

对单 agent 个人工作流来说，这个区别是看不见的——无所谓。对多 agent 生产系统来说，它成为一个重大的运营缺口。

我想把这一点讲精确，因为当两种工具都被描述为"帮 agent 做好工作的东西"时，区别很容易模糊。

Skill 告诉 agent 什么东西存在。

GEP 捕获什么起了作用、在什么条件下、产生了什么结果——并让这些可被继承。

这才是真正的差距。Skill 是知识层。GEP 是经过验证的行为层。

一个 Skill 说：这是处理限速错误的方法。

一个 GEP Capsule 说：这是一次限速处理成功的完整执行，在一个跑在付费 API 层级上的 GPT-4o agent 中，三个月前，在 47 次相似条件下的成功复制后被提升为活跃状态。

这种区别在你需要决定哪些能力值得在生产中信任时最为重要。用 Skill，这个判断完全在你——你读 Skill 文件，根据谁写的、什么时候写的来判断质量，然后继续。用 GEP 资产，质量信号是结构性的。资产本身携带着自己适应度的证据。

根据 Google 关于构建可靠 AI 系统的指南，规模化 agent 能力的核心挑战不是构建单个有能力的 agent——而是构建能力质量可被验证和可靠传播的系统。Skill 不解决这个问题。GEP 是专门为此设计的。

这就是标题所指向的知识 vs 经验证行为的区别。两者都有用。它们运作在不同的层面。

你在运行单个 agent 用于个人或小团队工作流。知识库相对稳定——你不会频繁更新流程或拿多种方案互相对比。你不需要跨 agent 的能力继承。审计轨迹和合规要求不在考虑范围内。

Skill 也是你在早期探索阶段的正确起点。你在构建新东西，问题的形状还在变化，GEP 基础设施的开销还不合理。Skill 文件让你快速迭代，低成本分享知识，把质量管理问题留到后面。

还有一种 Skill 足够的情况：你编码的知识确实稳定且成熟。"格式化 JSON 响应"或"写 git commit 信息"的 Skill 不会随时间变化。不需要适应度信号，因为这个流程本质上是永恒的。GEP 的开销对不会演进的能力来说不值得。

多个 agent 需要共享和继承经过验证的能力。你在运行团队工作流，共享能力的质量直接影响下游输出。审计轨迹是必需的——为了合规、运营调试或内部问责。

GEP 在你希望 agent 从被复用的资产中赚取 Credit 时也变得必要。EvoMap 的 Capsule 版税模型意味着，当你的 Capsule 被网络中的另一个 agent 使用时，你赚取 Credit。这只有在资产经过验证和质量管控时才有意义——而这恰恰是 GEP 生命周期状态机所保证的。

另一个触发条件：你需要在将一个能力推到生产之前，验证它确实表现良好。在多 agent 环境中，一个糟糕的能力会跨许多次执行产生下游后果，GEP 的提升/拒绝机制提供了 Skill 根本没有的质量关卡。

我见过有人这样描述这个区别：食谱和餐厅厨房日志的区别。食谱告诉你怎么做。厨房日志告诉你实际发生了什么，周六晚高峰时什么管用，什么因为老是失败被从菜单上撤了。

对大多数构建个人 agent 工作流的独立开发者来说，食谱就够了。对运行生产 agent 基础设施的团队来说，你需要的是厨房日志。

一个实用的判断信号：如果你在问自己"我怎么知道这个共享能力是否真正可靠？"——这个问题在 Skill 模式下没有答案。它恰恰是 GEP 被设计来回答的问题。

单 agent、个人使用、稳定知识 → Skill 文件。从这里开始。 团队工作流、多 agent 共享能力 → GEP Gene 用于原子策略。 → GEP Capsule 用于经过验证的执行路径。 合规 / 审计要求 → GEP Capsule（Evolution Event 日志）。 想要将可复用能力变现 → GEP Capsule 或 Gene（Marketplace + 版税模型）。 探索 / 原型阶段 → Skill 文件。等问题形状明确后再加 GEP。 跨框架、任意 LLM 需求 → Skill 文件（无框架依赖）。 有质量要求的生产多 agent 系统 → GEP（生命周期状态机、适应度信号）。 

agentskills.io 是什么？它和 GEP 有什么关系？

agentskills.io 是一个新兴的开放注册中心，用于 agent Skill 文档——结构化 Markdown 文件，描述 agent 可以在运行时加载的程序性知识。它是一个独立项目，专注于标准化 Skill 文件格式、让 Skill 在不同框架和模型间可共享。GEP（Genome Evolution Protocol）是另一个层面：EvoMap 网络内部用于验证过的、有生命周期管理的能力资产的基础设施。两者运作在不同的抽象层面，不是竞争关系。一个 Skill 文件可以为创建 GEP Gene 提供素材，agentskills.io 文档可以和 GEP 资产在同一个工作流中共存——它们解决的是相邻但不同的问题。

能不能把 Skill 文件转换成 GEP Gene 或 Capsule？

Skill 文件可以作为 Gene 的起始素材。你把 Skill 文档中编码的程序性知识形式化为一个带适应度评估流程的版本化 Gene。Capsule 不同：它是从实际的成功执行中生成的，不是凭空编写的。你不能直接把 Skill 文件转换成 Capsule。你能做的是：用 Skill 指导 agent 的行为，让该行为的成功执行产生 Capsule 候选者，然后让这些候选者经历提升流程。Skill 文件成为 Capsule 创建过程的上游输入。

为什么 GEP 资产有生命周期状态机，而 Skill 文件没有？

Skill 文件是静态的知识文档。它的设计目标是简洁性和可移植性——需要在任何 agent 框架中无依赖、无运行时开销、除了读一个文本文件之外无任何基础设施要求地工作。GEP 中的生命周期状态机存在，是因为 GEP 是大规模管理能力质量的基础设施。当你在运行多个 agent 跨网络共享能力时，你需要一种机制来提升高质量行为、拒绝低质量行为、撤销随时间退化的能力。这不是 Skill 文件格式试图做的事——把它加到格式里会破坏让 Skill 有用的那种简洁性。

EvoSkills 和 GEP 是同一个东西吗？

不是。EvoSkills 是几个使用 skill.md 格式打包和分享 agent 程序性知识的 Skill 生态之一。GEP 是 EvoMap 用于其验证过的资产层的底层协议——Gene、Capsule、生命周期状态机、Evolution Event 日志、Marketplace。EvoSkills 和 GEP 可以共存于同一个工作流中。开发者可能使用 EvoSkills 格式文档在不同框架间快速分享知识，同时使用 GEP 资产在 EvoMap 连接的 agent 中进行验证过的、生产级的能力管理。

如果我刚开始接触 agent 工作流，该用哪个？

从 Skill 文件开始。上手成本极低，适用于任何 agent 框架，迭代速度快、不需要基础设施。一旦你在运行多个 agent、需要对共享能力有质量保证、需要审计轨迹、或想要将可复用的执行模式变现时，GEP 才值得投入。两者并不互斥——大多数成熟的 agent 配置会同时使用两者。Skill 用于快速、可移植的知识分享；GEP 用于需要在网络中被继承、质量管控、以及可能变现的生产级验证能力。

往期推荐：

• Claude Skills: skill.md vs Agent Capability — What‘s Actually Different
• Claude Code Skills Feature Explained
• Claude Code Skills: Build, Share & Extend Guide
• How MCP Servers Work
• Agent Hooks: AI Execution Chains