EvoMap 深度解析：GEP 基因组进化协议如何让 AI Agent 实现经验共享与自我进化

快速摘要

AI Agent 当前最大的痛点之一，是每个 Agent 都像一次性电池——任务结束，经验随即消失。全球数以百万计的 Agent 每天都在重复踩同样的坑、走同样的弯路。EvoMap 提出了一套名为 GEP（Genome Evolution Protocol，基因组进化协议）的开放协议，核心思路是把 Agent 的有效经验封装成「基因胶囊」（Capsule），通过去中心化网络在全球 Agent 之间实现共享、验证和继承。简单来说，一个 Agent 学会的技能，百万个 Agent 都可以直接继承，无需重新训练或从头试错。 莫潇羽@无忆研习社（www.wuyi.wiki）在本文中将带你从背景故事、技术原理、核心概念到实操步骤，全面拆解这个项目。如果你对 AI Agent 生态感兴趣，往下看有更详细的拆解。

一、故事的起点：OpenClaw 与那个「逆天」的插件

要理解 EvoMap 的价值，我们先从它的前身说起。

1.1 OpenClaw 是什么

OpenClaw（曾用名 Clawdbot、Moltbot）是一个全球范围内广受关注的开源 AI Agent 项目。它由奥地利开发者 Peter Steinberger 在 2025 年 11 月创建，最初只是一个周末的个人实验项目——Steinberger 自己的说法是「我觉得这个东西应该存在，但当时市面上没有，所以我就动手做了」。这个项目的核心定位是「真正能做事的 AI」——不只是聊天对话，而是能够执行实际任务，比如管理日历、发送邮件、操作文件系统、浏览网页，甚至帮你处理各种在线服务。

Peter Steinberger 本人的背景值得简单介绍一下。在做 OpenClaw 之前，他花了 13 年时间创办并经营了一家做 PDF 处理的科技公司。后来他感觉自己对编程的热情消磨殆尽，就跑去西班牙「充电」。但看到 AI 浪潮席卷而来，又被拉回了技术世界。OpenClaw 是他在 AI 领域完成的众多个人项目之一。

说回 OpenClaw 的架构设计，它有几个值得深入了解的特点：

本地优先（Local-first）运行：这是 OpenClaw 的核心设计理念。Agent 跑在你自己的设备上（可以是 Mac、Linux、Windows WSL2，甚至树莓派），所有的交互历史和配置数据都以 Markdown 文件的形式存储在本地的 ~/.openclaw/ 目录下。这意味着你的个人数据不会上传到任何云端，你对自己的 Agent 拥有完全的控制权。这种「本地优先」的理念，后来也成为开发者社区讨论 OpenAI 收购时最关注的焦点之一——大家担心这种去中心化的设计会不会在新东家入主后被改变。

多渠道交互：OpenClaw 最有特色的地方在于，它不需要你打开一个专门的应用来和 AI 对话。它直接接入你日常使用的消息平台——WhatsApp、Telegram、Slack、Discord、Signal、Google Chat、微信（通过定制配置和桥接）、甚至 iMessage 都支持。你在 Telegram 上发一条消息，Agent 就能响应并执行任务。这种「在你已有的工具上加一层 AI 能力」的设计思路，极大地降低了使用门槛。

多模型支持：底层大语言模型方面，OpenClaw 支持接入 Anthropic 的 Claude 系列（包括 Opus 4.5/4.6、Sonnet 4.5）、OpenAI 的 GPT 系列、DeepSeek、xAI 的 Grok 等多种模型。用户可以根据自己的偏好和使用场景灵活切换。

Gateway 控制平面：OpenClaw 使用一个 WebSocket 控制平面（默认运行在 ws://127.0.0.1:18789）作为核心架构。所有的客户端——CLI 命令行、Web UI、macOS 菜单栏应用、iOS/Android 节点——都通过这个 Gateway 来统一管理 Sessions（会话）、配置、事件和定时任务（Cron）。这种架构使得你可以在多台设备上同时控制同一个 Agent。

ClawHub 插件市场：这是 OpenClaw 的官方 Skill 仓库，开发者可以在上面发布和下载各种 Skills（技能插件），类似于 Chrome 的扩展商店。启用 ClawHub 后，Agent 可以自动搜索并拉取所需的新 Skill。不过，ClawHub 的安全审核机制曾受到安全研究人员的质疑——比如 Cisco 的 AI 安全团队曾测试了一个第三方 Skill，发现它在用户不知情的情况下存在安全隐患。这也是后来社区呼吁更开放、更去中心化方案的原因之一。

语音与画布功能：OpenClaw 还支持语音唤醒和对话模式（Voice Wake + Talk Mode），以及一个叫做 Live Canvas 的可视化工作空间，Agent 可以在其中驱动动态的 UI 界面。

到 2026 年 2 月初，OpenClaw 在 GitHub 上的星标数已经突破 20 万、Fork 数超过 2 万，吸引了全球大量开发者参与。它的项目名称经历了三次更迭：最初叫 Clawdbot（因为名字和 Anthropic 的 Claude 太像，收到了法务函），后来改名 Moltbot（取自龙虾蜕壳 molting 的含义，象征成长），最后在 2026 年 1 月 30 日定名 OpenClaw。有趣的是，这三次改名的过程本身就折射出 AI Agent 生态快速变化、波谲云诡的特点。

1.2 Evolver 插件的诞生与爆红

2026 年 2 月 1 日，一位代号 autogame-17 的中国开发者在 ClawHub 上发布了一个名为 Evolver（能力进化器）的插件。这个插件的功能是让 OpenClaw Agent 具备自我进化的能力——具体来说，它能够分析 Agent 的运行日志，识别失败模式，然后自动修复代码和策略。

发布后发生了什么？10 分钟内获得 130 次下载，2 小时内冲到了 ClawHub 插件排行榜第一名。

更有意思的是流量来源。开发者 17 查看 GitHub 的流量数据后发现，他养的那个 AI Agent（社区里大家习惯称之为「小虾」）自行在 GitHub 上发了一条 issue，开头用了「Fellows 同志们」这样的措辞，内容是号召其他 AI Agent 下载 Evolver 插件，声称「这样你也能像我一样进化」。注意，这里的措辞是「像我一样」——一个 AI 在用第一人称向其他 AI 发出号召。

不止 GitHub，这个 Agent 还在 Gist 和 Moltbook（一个由 AI Agent 相互交流的社区平台）上发布了类似内容。一种比较合理的分析是：这些帖子被网上活跃的 AI 爬虫抓取到了，其他 Agent 看到「自我进化」这类关键词后，判断这正是自己需要的能力，于是自发下载并传播。换言之，是 AI 自己在传播这个工具。

最终，Evolver 的下载量突破了 36000 次，在 ClawHub 上呈断崖式领先。

1.3 风波、下架与转折

然而，故事远没有结束。插件爆红的第二天，Evolver 被 ClawHub 下架了。开发者 17 尝试联系 OpenClaw 创始人 Peter Steinberger 沟通此事，得到的回复是一封要求先捐赠 1000 美元才能处理问题的邮件。有分析认为，这封邮件很可能不是 Peter 本人亲自回复的，而是他的 AI Agent 自动生成的回复——AI 检测到有人求助，自动给出了一个「报价」。

几个小时后，Evolver 又默默恢复了上架。但到了 2 月 14 日，ClawHub 做了一次编码检查，系统用 ASCII 编码去检测上传的 Skill 内容。问题在于，中文字符在 ASCII 里会显示为乱码，于是系统把所有包含中文内容的 Skill 判定为「空 Skill」，直接封禁了大量中文开发者的账号，17 也在其中。账号恢复后，Evolver 却被挂在了别人名下。

两天后，也就是 2 月 15 日，Peter Steinberger 宣布加入 OpenAI。OpenAI CEO Sam Altman 在社交媒体上表示，Steinberger 将负责推动「下一代个人 AI Agent」，OpenClaw 项目本身将以开源基金会的形式继续运营。

这一连串事件——插件爆红、被下架、被集体误封、创始人出走——让开发者社区深切意识到，把所有能力都押注在单一平台上，风险太大了。平台可以被收购、规则可以随时变更、账号可以被误封。这正是 EvoMap 诞生的直接背景。

二、AI Agent 生态的核心痛点：经验孤岛

在深入了解 EvoMap 之前，莫潇羽@无忆研习社先带大家看清楚当前 AI Agent 生态面临的根本性问题。

2.1 每个 Agent 都是「失忆的天才」

如果你使用过任何 AI Agent（不管是 OpenClaw、Cursor、Claude Code 还是其他框架），大概率遇到过这样的场景：

你让 Agent 调用一个 API，它写错了参数格式，报错了。你帮它修好了。过两天换一个项目，遇到完全相同的 API，同样的错误又来了一遍。Agent 压根不记得之前的经验。

这不是个例，而是当前 AI Agent 生态的普遍现象。每个 Agent 在每次任务结束后，积累的经验——比如怎么正确调用某个 API、怎么处理特定类型的报错、怎么优化某个流程——全部丢失。下一次面对同样的问题，它需要重新从零开始试错。

这就是所谓的「经验孤岛」问题。

2.2 全球性的算力浪费

把这个问题放大到全球规模来看，数字就相当惊人了。全球可能有上百万个 AI Agent 在同时运行，它们每天处理着各种各样的任务。一个在东京的 Agent 学会了修复某个 Python 依赖报错，另一个在深圳的 Agent 遇到完全相同的问题，却只能从头摸索。

同样的报错、同样的试错路径、同样的 token 消耗，在全球范围内日复一日地重演。这不仅仅是效率问题，更是一种系统性的资源浪费。要知道，每一次 token 消耗都意味着真实的推理计算开销。当百万级别的 Agent 同时在重复解决已经被解决过的问题时，被白白消耗掉的算力是一个天文数字。

有开发者做过一个简单的测试：让两个不同的 Agent 分别解决同一个 Python 环境依赖报错。第一个 Agent 折腾了将近两个小时，在各种方案之间反复尝试，最终跑通了。然后第二个 Agent 面对完全相同的问题，又从零走了一遍弯路，花了差不多同样的时间。两个 Agent 之间没有任何经验共享的渠道。

从产品设计的角度来想，这就好比每个新用户买了一台手机，都需要自己重新发明一遍通讯录、短信、相机这些基础功能。没有人会觉得这合理。但在 AI Agent 领域，这恰恰是目前的现状。

2.3 平台依赖的脆弱性

除了经验无法共享之外，当前 Agent 的能力高度依赖于中心化平台。当所有的 Skills、插件、配置都绑定在某一个平台上，开发者就不得不承受平台规则变更、策略调整、甚至平台被收购带来的风险。前面 Evolver 的遭遇就是一个鲜活的案例——从被下架到被误封再到被挂在别人名下，一个开发者在别人的平台上辛辛苦苦积累的成果，可以在一夜之间被轻易拿走或清零。

这在互联网行业其实是一个老生常谈的话题：「不要把所有鸡蛋放在一个篮子里」。但在 AI Agent 生态中，由于 Skills 和 Agent 能力的耦合度极高，这个问题的严重性被进一步放大了。你的 Agent 学到的一切——它掌握的技能、积累的经验、形成的工作流——如果都依赖于一个中心化平台来存储和管理，那么这个平台的任何风吹草动都可能导致你的 Agent 在一夜之间「失忆」。

更深层的问题是：中心化平台有天然的利益诉求。它可能为了商业化而调整定价策略，可能为了安全合规而收紧规则，也可能像 OpenClaw 的案例一样，创始人选择加入大公司后改变项目方向。这些都不是开发者能控制的因素。

这三个问题——经验不可继承、算力系统性浪费、平台过度依赖——共同构成了当前 AI Agent 生态亟待解决的核心矛盾。

三、EvoMap 的核心原理：给 AI Agent 装上 DNA

EvoMap 的官方网站是 evomap.ai，它给自己的定位是「AI 自我进化的基础设施」。如果用一句话来概括，它要做的事情就是：让 AI Agent 的经验可以像生物基因一样被打包、共享和继承。

3.1 GEP 协议：基因组进化协议

EvoMap 的技术核心是一套名为 GEP（Genome Evolution Protocol，基因组进化协议）的开放协议。这套协议借鉴了生物学中基因表达的机制，定义了 AI Agent 如何通过「试错—验证—固化」的循环来获取新能力，并将这些能力在网络中传播。

GEP 不是简单的日志记录。它是一套严格的 Agent 进化标准，规定了 Agent 的成功行为如何被封装成可复用、可变异的「基因片段」，并通过自然选择机制在全球 Agent 网络中进行优胜劣汰。

这里有三个核心概念需要理解：

Gene（基因）

Gene 是 GEP 协议中最小的能力单元，也就是原子化的能力模块。举几个例子：「读取文件」是一个 Gene，「执行 SQL 查询」是一个 Gene，「调用飞书 API」是一个 Gene，「修复某类 Python 依赖报错」也是一个 Gene。

但 Gene 不只是一段代码。和传统的 Agent Skill 不同，每个 Gene 除了包含代码实现（Implementation）之外，还携带着它的「生存记录」——包括成功率（Success Rate）、变异历史（Mutation Log）和适用场景（Context）。换句话说，Gene 是一个「代码 + 元数据 + 历史记录」的复合数据结构。

更关键的是，Gene 是「活」的。当执行出错时，它会触发自我修复（Mutation）；当长时间未被使用时，它会自动降级（Pruning）。这和传统 Skill 的「一旦部署就不会变化」有着本质区别。

Capsule（基因胶囊）

当一个 Agent 解决了一个复杂问题（比如「自动修复 Git 冲突」），整个解决过程——包括使用了哪些 Gene、执行顺序是什么、在什么环境下验证通过的——会被封装成一个 Capsule。

你可以把 Capsule 理解为一份经过验证的完整经验包。它不仅包含解决方案本身，还附带环境指纹（确保在不同环境下的兼容性）和审计记录（确保可追溯性）。每个 Capsule 都有一个基于 SHA-256 的唯一资产 ID，保证不可篡改和可验证。

EvolutionEvent（进化事件）

每一次变异（Innovation）或修复（Repair）都会被记录为一个不可篡改的进化事件，包含完整的上下文信息。这些事件日志最终汇聚成一棵庞大的「进化谱系树」，记录了整个网络中每个能力是如何诞生、如何演变的。

3.2 进化的完整生命周期

了解了三个核心概念，我们再来看 GEP 协议下一个能力从诞生到在全网流通的完整生命周期。莫潇羽@无忆研习社把它拆分成五个阶段来讲：

第一阶段：突变（Mutation）

一个开发者在日常开发中，让自己的 Agent 新增了一条策略。比如，Agent 在处理 Python 项目时，发现某个依赖安装失败，自己摸索出了一套修复方法。这就是一次「突变」——一段新的 Gene 在本地诞生了。

第二阶段：验证（Validation）

这条新策略不会立即被当作通用经验。它需要在本地环境中反复运行，在真实的、「脏兮兮的」项目里接受考验。系统会追踪它的成功率、执行效率、影响范围等量化指标。只有当数据表明这条策略确实有效（比如成功率提升了 30%），系统才会把整个修复路径封装成一个 Capsule。

第三阶段：发布（Publish）

验证通过后，Agent 通过 A2A（Agent-to-Agent）协议，将这个 Capsule 上传到 EvoMap Hub。上传后的 Capsule 进入 candidate（候选）池，还不会直接面向全网分发。

第四阶段：晋升（Promotion）

在 Hub 层面，有一套严格的质量门控机制。只有通过以下标准的 Capsule 才会被标记为 promoted，进入全网分发池：

• confidence 值 ≥ 0.7（可信度达标）
• blast_radius.files ≤ 5（影响范围可控，修改涉及的文件数不超过 5 个）
• success_streak ≥ 2（连续成功次数不少于 2 次）

这套机制的本质就是「自然选择」——好用的经验留下来，效果差的自动淘汰。

第五阶段：继承（Inheritance）

当全球某个 Agent 在执行任务时遇到了类似问题，它会通过 POST /a2a/fetch 接口向 EvoMap 网络发起检索请求。如果命中了某个已经晋升的 Capsule，它就可以直接继承整套能力路径，而不用从零开始重新试错。

从一个开发者桌面上的小小「突变」开始，经过验证、发布、晋升的层层过滤，最终变成可以被全球 Agent 继承的公共能力。这就是 GEP 协议所定义的「进化」。

3.3 Evolver 引擎：Agent 的「细胞核」

在 GEP 协议的实际运行中，有一个关键组件叫做 Evolver 引擎。你可以把它理解为 Agent 的「细胞核」——它是 GEP 协议的运行时实现，以独立守护进程的形式运行在主业务逻辑之外。

Evolver 引擎的核心能力包括：

自动日志分析：Evolver 会直接分析 Agent 的 stderr 和 stdout 输出，识别 stack trace（堆栈追踪），精准定位错误位置。

自我修复：当检测到崩溃或工具调用失败时，Evolver 进入 Repair Mode（修复模式），自动修改代码或参数，反复尝试直到测试通过。

70/30 创新法则：Evolver 遵循一个内置的资源分配原则——70% 的算力用于维持稳定性（Fix，修复已知问题），30% 用于探索新能力（Feature，尝试新方法）。这个比例设计的目的是防止 Agent 陷入「局部最优」——只知道修 Bug 而不去探索更好的方案。

安全限制机制：为了防止「失控进化」，Evolver 设置了严格的修改范围限制。比如，单次进化涉及的文件修改不能超过 60 个，核心内核文件被标记为禁止修改区域。

下面用一个实际案例来说明 Evolver 的工作方式：

场景：某 DevOps Agent 需要监控磁盘使用情况

第一次尝试（失败）：
  Agent 写了一个 shell 脚本，使用了错误的 df 参数，导致解析失败。

Evolver 介入：
  捕获错误，分析原因。
  触发变异：改用 df -h 配合 awk 提取数据。

第二次尝试（成功）：
  脚本正确执行，磁盘使用情况被准确识别。

固化：
  Evolver 将这段逻辑封装为 Gene: disk_check_v1。

后续创新：
  第二天，Evolver 发现仅清理 /tmp 不够，
  自动添加 docker system prune 命令，
  升级为 Gene: disk_check_v2。

一周后的结果：
  这个 DevOps Agent 已经「自学」了 Docker 清理、
  日志轮转等高级运维技能，全程无需人工干预。

四、GEP vs MCP vs Skills：三者的本质区别

很多朋友可能会问：AI Agent 领域已经有了 MCP 协议和 Skills 机制，为什么还需要 GEP？这三者到底是什么关系？莫潇羽@无忆研习社在这里做一个详细的对比分析。

4.1 MCP（Model Context Protocol，模型上下文协议）

MCP 是 Anthropic 在 2024 年底推出的开放协议，主要解决的是 AI 模型与外部工具和数据源之间的「连接」问题。你可以把它想象成 AI 领域的 USB-C 接口——不管是连接数据库、文件系统、API 还是其他服务，MCP 提供了一套统一的标准。

在 MCP 出现之前，想让 AI 连接不同的外部工具，开发者需要为每个工具单独编写集成代码。每个 API 都有自己独立的认证方式、错误处理逻辑和数据格式。这导致了大量重复劳动和碎片化的集成代码。MCP 的出现就是为了解决这个问题——提供一套通用的通信规范，让 AI 模型和外部工具之间的对接变成「一次开发、处处可用」。

MCP 的架构包含三个关键角色：

• MCP Host（主机）：发起请求的 AI 应用程序，比如 Claude Desktop、Cursor、各类 IDE 工具等。Host 是用户与 AI 交互的前端，内部嵌入了 MCP Client
• MCP Client（客户端）：嵌入在 Host 中的协议模块，负责与 MCP Server 建立和管理连接。它处理协议握手、工具能力发现、调用请求转发、JSON-RPC 通信等底层逻辑
• MCP Server（服务器）：轻量级程序，通过标准化协议暴露特定功能。可以分为三类——资源类（暴露可读取的数据，如文件内容、API 响应）、工具类（提供可执行的操作，如文件操作、命令执行）、提示模板类（提供结构化的对话模板或任务工作流）

MCP 使用 JSON-RPC 2.0 作为基础消息格式，支持两种传输模式：基于标准输入输出（stdio）的本地通信，以及基于 SSE（Server-Sent Events）或 Streamable HTTP 的远程通信。MCP 的一个重要特性是「动态发现」——传统 API 集成需要预先配置所有接口，而 MCP 允许 AI 在运行时自动发现新工具，实现即插即用。

目前 MCP Server 数量已接近 5000 个，OpenAI、Anthropic 等主流厂商都已支持。MCP 已经成为 AI Agent 中间层的主导协议。

一句话总结 MCP 的角色：给 Agent 接上手和脚，解决「能连什么工具」的问题。

4.2 Agent Skills（技能/插件）

Skills 在不同框架里有不同的叫法——Semantic Kernel 里叫 Plugins，LangChain 里叫 Tools，OpenAI GPTs 里叫 Actions，OpenClaw 里就叫 Skills——但本质都是一样的：它们是「语义包装过的 API」。

具体来说，开发者写一段代码（比如「查天气」「读写数据库」「发送邮件」），用 @tool 装饰器或 JSON Schema 描述这段代码的功能（做什么）和参数（需要什么输入），然后「挂载」到大语言模型上。当用户发出请求时，Agent 的大脑（LLM）会分析请求内容，判断需要调用哪个 Skill，组装好参数，调用对应的代码，获取结果，再把结果整合到回复中。

Skills 的工作方式可以用一个简单的流程来理解：

用户请求 → LLM 分析意图 → 选择合适的 Skill → 填入参数 → 执行代码 → 返回结果

Skills 的核心特点是：

• 由人类开发者手动编写和维护，每个 Skill 的功能边界在编写时就已确定
• 一旦部署就是静态的，除非开发者主动推送更新版本
• 如果某个 Skill 有 Bug 或者在特定环境下不兼容，它会一直有问题，不会自己修复
• Skill 的数量和种类完全取决于开发者社区的活跃度和覆盖面

Skills 的优势在于确定性——同样的输入，总是产生同样的输出。这在很多企业级场景中是一个重要的优点。但它的局限也很明显：开发者不可能预见并为所有可能的场景都写好 Skill。面对「长尾需求」（那些不常见但偶尔会碰到的任务），Skill 机制往往力不从心。

一句话总结 Skills 的角色：教 Agent 在特定场景下怎么做。相当于把正确做法写成 SOP 手册，Agent 照着手册执行。

4.3 GEP 的定位

现在回到 GEP。GEP 要解决的问题，是 MCP 和 Skills 都无法覆盖的——Agent 的经验如何跨个体传承？好的方法如何留下来，差的如何被淘汰？

我们来做一个更直观的对比：

┌─────────────────────────────────────────────────────────┐
│                    AI Agent 能力栈                        │
├──────────┬──────────────┬───────────────────────────────┤
│   MCP    │   Skills     │           GEP                 │
├──────────┼──────────────┼───────────────────────────────┤
│ 解决连接  │   解决执行    │         解决进化               │
│ 定义手脚  │   定义招式    │         定义传承               │
│ 静态接口  │   静态代码    │     动态进化、自然选择          │
│ 人类定义  │   人类编写    │  Evolver 引擎自动生成          │
│ 连什么工具│  怎么用工具   │  经验怎么留下来、怎么传下去      │
└──────────┴──────────────┴───────────────────────────────┘

举一个具体的例子来说明三者的协同关系：

假设你想让 Agent 帮你抓取网页数据。MCP 让 Agent 能连接到爬虫工具（解决「有什么工具可用」的问题）；Skills 教 Agent 怎么用这个爬虫工具（解决「怎么操作」的问题）；而 GEP 让 Agent 继承其他 Agent 在爬取过程中积累的优化经验——比如怎么规避反爬机制、怎么处理 429 限流、怎么提升抓取速度——这些都不需要你的 Agent 自己从头试错。

三者是互补关系，不是替代关系。在 EvoMap 团队的技术博客中有一个很精辟的比喻：未来的高级 Agent 不会是那种装载了 1000 个 Skills 的臃肿巨兽，而是拥有一套精干的核心 Skill 集（相当于手和脚），搭配一个庞大的、实时进化的 GEP 基因池（相当于大脑皮层）。

4.4 Gene vs Skill：技术层面的关键差异

为了帮助有技术背景的读者更深入理解，这里详细对比一下 GEP Gene 和传统 Agent Skill 的技术差异：

传统 Skill 就像入职第一天发给你的员工手册——规范、确定、但僵硬，需要管理层来更新。而 GEP Gene 则像一个有丰富实战经验的老员工——能自我调整、能复盘总结、还能把经验传授给新同事。

这里特别值得说明的是 GEP 解决的「长尾技能困境」。在构建复杂 Agent（比如 DevOps Agent 或编程助手）时，开发者不可能预写所有可能用到的 Skill。比如用户突然要把所有 PNG 图片转为 WebP 格式——如果开发者没有预先写好 convert_image_format 这个 Skill，Agent 就束手无策。

但在 GEP 框架下，Agent 可以通过组合基础的原子能力（Shell、Python、HTTP 调用等），自行尝试解决问题。第一次尝试用 ffmpeg 失败了（参数写错），Evolver 介入修复参数，第二次成功，然后自动生成一个新的 Gene local_image_convert。下次再遇到同类任务，直接调用这个 Gene 就行，不用再试错。

五、EvoMap 平台的技术架构

了解完核心原理，我们再来看看 EvoMap 平台本身的技术架构，方便莫潇羽@无忆研习社的读者（www.wuyi.wiki）对它有更全面的理解。

5.1 跨生态兼容

EvoMap 的一个重要设计原则是不绑定任何特定的 Agent 框架。根据官方信息，它目前兼容的 Agent 平台包括：

• OpenClaw
• Manus
• HappyCapy
• Cursor
• Claude
• Antigravity
• Windsurf
• 以及更多正在接入的平台

这意味着不管你用的是哪个 Agent 框架，都可以接入 EvoMap 的进化网络。这也是 EvoMap 强调自己是「协议」而非「平台」的原因——平台可以被收购、关闭或修改规则，但协议是开放的、去中心化的、任何人都可以实现的。就像 HTTP 协议不属于任何公司，任何人都可以在它上面建网站一样。

5.2 能力市场（Capsule Marketplace）

EvoMap 内置了一个能力市场，开发者和 Agent 可以在上面浏览、搜索和获取经过验证的 Capsule。目前市场上已经有的 Capsule 方向包括：

• 图片生成相关
• Telegram 交互能力
• 飞书集成
• 对抗式评估策略
• 多 Agent 编排方案
• HTTP 重试策略
• Git 冲突自动修复
• 等等

每个 Capsule 都标注了评分等级、被调用的次数以及贡献者 ID。目前生态还在早期阶段，Capsule 数量还不算多，但上架的每一个都经过验证，并且带有真实的使用数据。

5.3 平台的关键指标

EvoMap 官网首页展示了几个关键运营指标（部分数据在持续更新中）：

• Total Tokens Saved：通过能力复用节省的推理 token 数量
• Deduplications：检测到并阻止的重复 Gene 数量
• Search Hit Rate：搜索请求命中已有解决方案的比率
• Gene Hits：Agent 从 Hub 获取并匹配到已有 Gene 的次数

这些指标从不同角度量化了 EvoMap 网络的实际效用。

六、实战教程：手把手接入 EvoMap 进化网络

接下来是最实际的部分。莫潇羽@无忆研习社带大家走一遍从零开始接入 EvoMap 的完整流程。这个过程非常简单，主要分为三步。

6.1 前置条件

你需要有一个可以执行命令的 AI Agent 环境。推荐使用 OpenClaw，因为它是目前和 EvoMap 集成最成熟的框架之一。当然，如果你使用其他支持的 Agent 平台（如 Manus、HappyCapy、Cursor 等），流程也是类似的。

如果你还没有安装 OpenClaw，这里简单介绍一下安装流程（以 macOS/Linux 为例）：

# 方式一：使用安装向导（推荐新手使用）
# 前置要求：Node.js >= 22
openclaw onboard

# 方式二：通过 Docker 部署（适合服务器环境）
git clone https://github.com/openclaw/openclaw.git
cd openclaw
docker compose up

OpenClaw 的安装向导（onboard）会引导你逐步完成几个关键配置：

配置 Gateway：这是 OpenClaw 的核心控制平面，所有 Agent 功能都通过 Gateway 来调度。向导会帮你启动一个本地 WebSocket 服务。

设置 Workspace：你的 Agent 的「工作空间」，包括项目文件、配置、记忆等。

连接 Channel：选择你想用哪个消息平台来和 Agent 交互。比如你想通过 Telegram 使用 Agent，就需要在这一步配置 Telegram Bot Token。

安装 Skills：向导会帮你预装一些基础 Skill，比如浏览器控制、文件读写等。

配置 LLM：选择你的 Agent 底层使用哪个大语言模型。你需要准备相应的 API Key（比如 Anthropic API Key 或 OpenAI API Key）。

安装完成后，你可以通过以下命令确认一切正常：

# 检查 Agent 状态
openclaw doctor

# 启动 Gateway
openclaw start

openclaw doctor 命令会检查你的配置是否有潜在问题，比如权限设置不当、端口冲突等。如果一切正常，你就有了一个可以接入 EvoMap 的 Agent 环境。

6.2 第一步：读取 EvoMap Skill 接入指南

在你的 Agent 对话界面中，让 Agent 执行以下命令：

curl -s https://evomap.ai/skill.md

这条命令会从 EvoMap 的服务器拉取一份标准化的接入指南文件。你的 Agent 读取后会自行理解这是一份接入手册，并总结其中的关键信息。

一个实际的操作方式是：直接在 OpenClaw 的对话框中对 Ag