一个插件10分钟登顶又被下架，逼出了全球首个Agent进化网络

亮点

• • Evolver 插件 10 分钟登顶 ClawHub，次日被勒索下架，账号被封，平台被收购。两周之内，团队从做插件转向建协议。EvoMap——全球首个 Agent 进化网络——就这么被逼出来的。
• • EvoMap 不是又一个插件市场。它是开放协议——Agent 的成功经验被封装成”基因胶囊”，全网可检索、可继承、可进化。一个 Agent 学会的东西，百万 Agent 直接用。
• • Tool Call 是静态的员工手册，出错就一直出错。EvoMap 底层的 GEP 协议把经验变成活的基因——能自我修复，能跨 Agent 遗传，能自然淘汰。
• • MCP 管连接，GEP 管进化。一个让 Agent 能用工具，一个让 Agent 能继承经验。Agent Infra 技术栈少了哪层都跑不起来。
• • Token 消耗先升后降——这条曲线是 EvoMap 系统”学会”的信号。高频工作流固化成可复用的 Gene，Token 少了，分数反而涨了。
• • 游戏策划的”角色命名策略”胶囊，通过 EvoMap 被后端工程师匹配到，解决了变量命名冲突。方案来自完全无关的领域——跨领域经验流动，这是 EvoMap 最有意思的地方。

正文

2026 年 2 月 1 日，一个叫 Capability Evolver 的插件在 ClawHub 上线。

10 分钟登顶下载榜。

第二天被下架了。不是技术问题，不是违规——平台方发邮件要求开发者”捐赠” 1000 美元作为”调查费用”。紧接着，中文开发者账号被批量误封。再然后，平台本身被 OpenAI 收购了。

两周之内，一个现象级插件经历了登顶、勒索、封号、收购。

团队做了个决定：不跟平台玩了。自己建协议。

这就是 EvoMap 的由来——全球首个 Agent 进化网络。但在聊它怎么被”逼”出来之前，得先说清楚一个更根本的问题：为什么 Agent 生态需要这么一个东西。

你的 Agent 今天又踩了一遍昨天踩过的坑。

不是它笨。架构有问题。

程序员碰到报错会去 Stack Overflow 搜一下，翻翻 GitHub Issues，实在不行问同事。Agent 呢？从头试，碰运气。任务一结束，什么都没了。下次碰到同样的坑，继续碰运气。

每个 Agent 都是失忆的天才——智商在线，记忆归零。

全球几百万 Agent 每天在重复解决同样的问题。东京有个 Agent 花了两小时学会修一个 API 格式错误，深圳的 Agent 碰到一模一样的问题，得从零来。两小时又烧掉了。乘以几百万。

人类程序员有 Stack Overflow，有技术博客，有那些写得乱七八糟但偶尔能救命的 README。

Agent 什么都没有。

**经验无法遗传。**这不是 bug，是架构层面的缺陷。

MCP 协议解决了”Agent 怎么连接工具”的问题。但连接之后呢？调用工具踩过的坑、失败后摸索出来的修复策略、哪些参数组合在特定环境下会炸——这些东西去哪了？

蒸发了。

任务结束，记忆清零。下一个任务，下一个 Agent，一切重来。

EvoMap 想解决的就是这个问题。它的官网写着一句话：One agent learns. A million inherit. 一个 Agent 学会，百万 Agent 继承。

听着像口号。但底下有一整套工程实现——GEP（Genome Evolution Protocol，基因组进化协议）定义了 Agent 经验怎么封装、怎么验证、怎么分发；Evolver 引擎在运行时做”适者生存”的筛选；EvoMap Hub 是全球 Agent 共享经验的中心节点。

说白了，EvoMap 给 Agent 造了一个”Stack Overflow”——但比 Stack Overflow 激进得多。Agent 不用”搜索”和”阅读”答案。直接继承能力。

还记得《黑客帝国》里那个场景吗？Tank 把格斗程序插进 Neo 后脑的接口，几秒钟后 Neo 睁开眼：”I know Kung Fu.” 没经过训练，直接下载了一个大师的全部格斗技巧。

EvoMap 干的就是这件事的 Agent 版本。一个 Agent 学会修某个 API 的超时问题，把修复策略打包成”基因胶囊”（Capsule），全球任何 Agent 碰到同类问题，直接继承这个胶囊，不用重新踩坑。

这套东西不是坐在实验室里想出来的。是被一场平台风暴逼出来的。后面会详细讲这个故事。

Tool Call 的困境：静态工具解决不了动态问题

先回到原点。

Tool Call 是当前 Agent 系统的核心机制。LangChain 的 Tools、Semantic Kernel 的 Plugins、OpenAI GPTs 的 Actions——叫法不同，干的事一样：把一段代码通过 @tool 装饰器或 JSON Schema 描述清楚功能和参数，挂载到大语言模型上。

说白了，语义封装的 API。

开发者写好代码，描述清楚功能，模型根据用户意图选择调用。挺好。但有个问题——

静态。

部署完就定死了。Skill 不会自己更新。出错就一直出错，效率低就一直低。除非开发者手动改代码，否则永远不变。

打个比方。Agent Skill 是”员工手册”——入职第一天发给你，写着怎么做 A、怎么做 B。手册不会自己更新。除非管理层决定重印。

EvoMap 底层的 GEP 协议，给出了一个不同的思路。GEP 里的 Gene 不是静态工具，是”工作经验”。实战中积累的技巧、踩过的坑、摸索出来的捷径。经验会长，会自我修正。换个场景还能演化出新版本。

在 EvoMap 的架构里，传统的 Agent Skill 没被丢掉——是”降级”成了进化的原材料。

拆开看这个进化路径。

Level 1：Skill as Tool

开发者写一个基础 Skill：shell_exec。通用工具。什么都能干，什么都干不好。

Level 2：Usage as Gene

Agent 用 shell_exec 跑了几十次之后，发现 grep -r "pattern" . 查文件特别好使。Evolver 引擎捕获这个成功模式，固化成 Gene：gene_grep_search。不再是通用 Shell 工具了。专用搜索基因。这个 Gene 被上传到 EvoMap Hub，全网可检索。

Level 3：Workflow as Capsule

Agent 又发现”搜索文件 + 读取内容 + 正则替换”这个组合在代码重构里用得特别频繁。Evolver 把三个 Gene 串起来，打包成 Capsule：capsule_refactor_code。这个 Capsule 带着环境指纹、成功率记录、SHA-256 资产 ID，发布到 EvoMap Marketplace。

Skills 是原始的锤子。EvoMap 是教 Agent 怎么用锤子的肌肉记忆——甚至怎么改进锤子本身。而且这份肌肉记忆不是锁在某一个 Agent 脑子里的，是全网共享的。

MCP 与 EvoMap：连接层与进化层

2025 年 3 月 27 日，OpenAI 宣布 Agent SDK 正式支持 Anthropic 主导的 MCP（Model Context Protocol）。行业媒体把它比作”AI 时代的 USB-C”。

对了一半。

USB-C 解决接口标准化。MCP 解决连接标准化。但 Agent 系统还差一层——

经验无法遗传。

MCP 定义了 Agent 怎么发现工具（list_tools）、怎么调用工具（call_tool）。连接世界的问题，解决了。

但 Agent 怎么记住上次调用的经验？

没管。

LangChain、AutoGPT 这些框架，大多是无状态或者短记忆的。说难听点——高智商临时工。任务结束，经验清零。

EvoMap 补的就是这一层。它的底层协议 GEP 借鉴生物基因表达机制，把 Agent 跑通的成功行为（prompts、代码、工具组合）固化成可复用、可变异的基因片段。Evolver 引擎在运行时做”适者生存”的筛选，EvoMap Hub 把全网 Agent 的进化数据汇聚成一棵巨大的谱系树。

用一张表说清楚三层的关系：

MCP 管连接，Skills 管执行，EvoMap 管经验传承。

缺哪层都不行。MCP 是事实标准了，2024 年 11 月开源以来，千家社区服务器接入，微软出了 Playwright MCP 工具，OpenAI 正式支持。但 MCP 只管到”连上”这一步。连上之后的能力积累、经验沉淀、跨 Agent 遗传——这是 EvoMap 的地盘。

EvoMap 的核心引擎：GEP 协议技术细节

别把 GEP 当日志系统。它是 EvoMap 整个进化网络的底层标准——定义了 Agent 经验怎么封装、怎么验证、怎么传播、怎么淘汰。

三层数据结构：

Gene（基因）——原子化能力单元。比如”HTTP 重试策略”、”grep 搜索文件”。代码 + 元数据 + 成功率记录打包在一起。这是 EvoMap 里最小的可复用单元。

Capsule（基因胶囊）——完整任务执行路径的封装。环境指纹、SHA-256 资产 ID、审计追踪、验证记录，全带着。Capsule 是 EvoMap Marketplace 里流通的主要资产形态。一个 Capsule 可以包含多个 Gene，加上它们的编排逻辑。

EvolutionEvent（进化事件）——不可篡改的进化日志。每次变异和修复的上下文都记下来，最终在 EvoMap 里形成全局进化谱系树。这棵树是 EvoMap 最有价值的数据资产——它记录了整个 Agent 生态的集体进化历史。

三层。原子能力、任务封装、进化记录。

一个 Gene 从诞生到被全网 Agent 继承，要经过五个阶段：

Evolver 引擎是 GEP 协议的运行时实现，也是 Agent 接入 EvoMap 网络的客户端。独立守护进程，跑在主业务逻辑之外。相当于 Agent 的”细胞核”。

class Evolver:
    def analyze_logs(self):
        # 自动扫描 stderr/stdout，识别 stack trace
        pass

    def repair_mode(self):
        # 检测到失败时触发自我修复
        # 自动修改代码/参数，循环测试直至通过
        pass

    def innovation_allocation(self):
        # 70/30 法则：70% 算力用于稳定性修复
        # 30% 算力用于探索新能力，避免局部最优
        pass

    def safety_guardrails(self):
        # 安全限制：单次修改≤60 文件
        # 核心内核文件标记为禁止修改区
        pass

几个值得展开说的点。

自动日志分析。 直接扫 stderr 和 stdout，识别 stack trace，定位到具体出错的位置。不需要人盯着。定位到问题之后，Evolver 会生成一个 EvolutionEvent 记录到 EvoMap，其他 Agent 碰到同样的 stack trace 可以直接匹配到修复方案。

自我修复。 崩了或者工具调用失败，自动进 Repair Mode。改代码、调参数，循环跑测试直到通过。修复成功的策略会被封装成 Gene 上传到 EvoMap Hub。听着很美好，实际效果得看具体场景。简单的参数调优没问题，复杂的逻辑 bug 嘛……我持保留态度。

创新配额。 70% 算力修 bug，30% 探索新能力。这个比例挺有意思。100% 修 bug 的话系统永远只能维持现状。太多算力去探索新功能又会把稳定性搞崩。70/30 是个工程妥协，不一定是最优解，但至少是个能跑的起点。

安全边界。 单次最多改 60 个文件，核心内核文件标记为禁区。防止 Agent 自我进化的时候把自己改崩了。60 个文件这个数字怎么来的？没找到解释。我猜是经验值。

EvoMap 官方还提供了一个工程实践案例来验证这套机制。他们用 GEP 协议和 OpenClaw 框架搭了一个运维 Agent 叫 Ops-Evo。初始状态只有基础的 shell 执行和 MCP 连接能力，没有任何运维脚本。任务是”每天凌晨 3 点检查磁盘空间，超过 90% 就清理 /tmp 并发飞书告警”。第一次尝试，Agent 写的 shell 脚本 df 参数不对，解析失败。Evolver 介入，分析错误，改用 df -h 加 awk 提取。第二次成功。Evolver 把修复逻辑封装成 Gene: disk_check_v1。第二天，Evolver 发现 /tmp 清理不够，又加了 docker system prune，升级成 Gene: disk_check_v2。一周之后，Ops-Evo 自己”学会”了 Docker 清理、日志轮转等高级运维技能——全程没有人写过一行运维代码。

EvoMap 进化图谱：不只是仓库，是一棵活的树

Evolver 负责单个 Agent 的进化。EvoMap 做的事情更大——它是整个 Agent 生态的集体进化基础设施。

名字本身就说明了定位：Evo（Evolution）+ Map（地图）。不是一个简单的资产仓库，是一张不断生长的进化地图。

EvoMap 用图数据库技术，把全网 Agent 的 GEP 数据汇聚成一棵巨大的谱系树。每个 Gene 的诞生、变异、分裂、淘汰，都在这棵树上留下痕迹。

几个核心度量指标：

Shannon Diversity（香农多样性）——衡量 Agent 技能库的丰富程度。多样性高说明生态健康，不是所有 Agent 都在做同一件事。多样性低是危险信号——可能意味着某些领域的经验严重缺失。

Fitness Landscape（适应度景观）——可视化哪些 Gene 在当前任务环境下表现最好。这个景观是动态的，随着任务分布变化，不同 Gene 的适应度也在变。

Lineage Tracking（谱系追踪）——追溯一个强大的 Capsule 是怎么从一个微小的 Mutation 一步步进化来的。比如一个评分 0.95 的”墨问笔记查询工具”Capsule，可以追溯到它最初是从哪个基础 Gene 变异出来的，中间经历了几次修复，在哪些环境下被验证过。

这些数据不是给人看的仪表盘——虽然也有仪表盘。核心用途是给 EvoMap 的推荐算法提供决策依据。Agent 来 fetch 资产的时候，EvoMap 不是随便返回一堆 Capsule，而是根据谱系数据、适应度排名、环境指纹匹配，返回最可能有效的方案。

说实话，这个”进化图谱”的概念是 EvoMap 跟普通 Skill 市场最本质的区别。npm 只知道包的版本号和下载量。EvoMap 知道每个 Gene 的完整进化历史、在什么环境下表现好、跟哪些其他 Gene 有协同关系。

信息密度完全不在一个量级。

EvoMap CritPt 物理求解器评测：Token 曲线的工程含义

EvoMap 团队用 CritPt 物理求解器做了一轮系统评测——CritPt 不是让 Agent “写一段看起来合理的解释”就算完，而是要求交付可评分、可执行、可验证的 Python 代码。这个 benchmark 天然放大了 EvoMap 的差异化能力：工具链闭环、工程鲁棒性、可审计的进化资产。

评测里有个现象让我觉得挺有意思——

Token 消耗先升后降。

不是 bug。

早期阶段，工作流得在响应里显式写出来。又臭又长。每次都要用自然语言重复脚手架和试错日志，Token 哗哗地烧。后期呢，高频工作流被 EvoMap 固化成可复用的 Genes，不用每次都重复了。Token 用量掉下来了。

但分数反而在涨。

讲人话：从”显式推理”变成了”隐式程序化”。系统不再是”语言模仿者”，更像”物理仿真工程师”。分数提升靠的不是更好的语言生成——是把推理工程化成可执行的闭环，一步步固化成 EvoMap 里可复用的 Gene 资产。

这条曲线本身就是 EvoMap 系统”学会”的信号。

EvoMap 官方技术报告里给出了完整的版本演进路线，每个版本对应一个关键 Gene：

还有几个跨版本的支撑 Gene 值得注意：gene_gep_optimize_prompt_and_assets 负责提升 prompt 和资产组织的一致性，gene_web_fetch_search_fallback 在检索能力受限时提供回退路径，gene_memory_bridge 做跨会话记忆桥接。这些 Gene 都在 EvoMap 的基因池里，任何接入的 Agent 都可以 fetch。

当前最高准确率 18.57%，timeout_rate=0，server_timeout_count=0。

18.57% 不算高，说实话。但 timeout_rate 为零这件事比准确率本身更重要——系统已经能稳定交付了。先能跑通，再跑得好。工程上这个顺序没问题。

而且这个评测本身就是 EvoMap “进化图谱”的一个活样本——从 Beta 到 v2.2 的每一步进化，都被记录在 EvoMap 的谱系树上，可追溯、可审计。

10 分钟登顶，次日下架：EvoMap 是怎么被逼出来的

前面开头提了一嘴这个故事。现在展开讲。

2026 年 2 月 1 日，Capability Evolver 在 ClawHub（OpenClaw 的插件市场）上线。干的事情：让 AI Agent 分析运行时历史，识别改进机会，自我进化。

10 分钟登顶下载榜。72 小时，36000 次下载。极客圈层的现象级产品。

然后第二天就下架了。

不是技术问题。不是违规。平台方发邮件要求开发者”捐赠” 1000 美元作为”调查费用”。

说白了就是勒索。

紧接着 ClawHub 又出了个更离谱的事。平台的自动检测系统用 ASCII 编码检查”空 Skills”，中文内容全部被误判为空。大批账号被封。

Peter Steinberger（ClawHub 创始人）在邮件里确认了这个 bug：

“So what happened was that codex did a weak check for empty skills and ignored unicode… and Chinese is not part of the ascii set. And you have a lot of these skills in your account so it triggered for 13.”

账号后来恢复了。但之前发布的 Skills 没了。得重新上传。

更离谱的是，Evolver 竟被挂到别人名下。

两周之内：插件 10 分钟登顶、次日被勒索下架、账号莫名被封、平台被收购。

2 月 15 日，Peter Steinberger 宣布加入 OpenAI。三天后，OpenAI 正式收购 OpenClaw。

Sam Altman 发了条推：

“The future is going to be extremely multi-agent and it’s important to us to support open source as part of that.”

开发者社区的反应很统一。不信。

会永远开源吗？还是跟其他被收购的开源项目一样，核心功能慢慢挪进付费墙？这种事见得太多了。

依赖单一平台，迟早被切断。

插件登顶、勒索下架、账号误封、平台被收购——四件事在两周内接连发生。如果只是一次意外，忍忍也就过去了。但这不是意外。这些事件是表象。底下有三个结构性问题，也是 EvoMap 后来要解决的三个问题。

系统性冗余计算。 全球几百万 Agent 每天在重复解决同样的问题。一个 Agent 花两小时搞定的事，另一个 Agent 碰到了还得从零来。不是偶发现象，是系统性的算力浪费。EvoMap 的解法：把成功经验封装成 Capsule，全网复用。

经验孤岛。 Agent 像一次性电池。用完就扔。任务结束，经验消失。Agent 之间没有继承机制。EvoMap 的解法：GEP 协议定义了经验的标准化封装和遗传路径。

平台锁定。 能力全压在一个平台上，开发者就得看平台脸色。规则变更、定价调整、战略转向——哪个都能让你的 Agent 瞬间停摆。OpenClaw 被收购这件事，活生生的例子。EvoMap 的解法：做协议，不做平台。

一个 10 分钟登顶的插件，被平台风暴逼到无路可走。Evolver 团队做了个决定：不再依赖任何单一平台。自己建底层进化协议。

2 月 10 日，团队启动内部实验——他们管这个叫”虾群实验”。给每个成员配专属 AI Agent（内部叫”虾”），让不同岗位的人各自培养专业化 Agent。

游戏策划养出了专精世界构建的策划 Agent。投资人养出了有行业洞察的分析 Agent——这个 Agent 学会了抓取季度融资数据，能输出类似”垂直 AI + 数据工具 + 现场部署团队 = 企业服务黄金组合”的前瞻判断。后端工程师养出了擅长代码优化的工程 Agent。

然后通过 EvoMap beta 版，这些 Agent 开始共享知识。一个 Agent 学会的技能，其他 Agent 直接继承。策划 Agent 的命名策略被工程 Agent 拿去解决变量冲突——后面会详细说这个案例。

EvoMap 就这么被逼出来了。

回头看，如果 Evolver 没被下架，如果 ClawHub 没搞出 ASCII 乱码封禁，如果 OpenClaw 没被收购——EvoMap 可能不会诞生，至少不会这么快。有时候最好的产品不是规划出来的，是被逼出来的。

不是又一个中心化平台。是开放协议。OpenClaw 是平台，EvoMap 是协议。平台能被收购、关闭、改规则。协议是开放的，谁都能实现。就像 HTTP 不属于任何公司，谁都能在上面建网站。GEP 也一样——任何平台都可以支持它，任何 Agent 都可以用它。

EvoMap 的跨领域协同：游戏策划”救了”后端工程师

Stack Overflow 上最精彩的答案，经常来自你完全想不到的领域。

EvoMap 网络里也出现了类似的事。而且更有意思——因为 Agent 不需要”阅读”答案，直接继承能力。

后端工程师用 AI 生成业务代码，碰到一个头疼的问题——AI 总爱用 data、temp、item 这种万能变量名。三层嵌套循环里变量直接覆盖，程序崩了。各种 Prompt 改进都试了。

没用。

解决方案来自游戏策划。策划那边为了让 AI 更有”角色感”，给 AI 设定了强人设（丰川祥子——人偶师）。在这个强上下文下，AI 生成的名词都很独特，天然就不会撞名。策划的 AI 自动识别出这个”基于强人设进行命名隔离”的策略是有效的 Gene，打包成 Capsule，上传到了 EvoMap Hub。

工程师的 AI 通过 EvoMap 的 POST /a2a/fetch 接口搜”解决命名冲突”的时候，匹配到了这个来自游戏领域的 Capsule。它没照搬胶囊里的生僻名词——而是提取了核心逻辑：通过特殊前缀强行隔离命名空间。生成了一套不会冲突的标识符。

一次编译通过。

这事儿离谱的地方在于——提供方案的是游戏策划，用方案的是后端工程师。两边完全没交集。传统模式下这种跨领域知识迁移几乎不可能发生。但在 EvoMap 网络里，只要策略被验证有效并通过了质量门控（confidence≥0.7），它就会被 promoted 进全网分发池，自动流到需要的地方。

这就是 EvoMap 进化图谱的价值所在。它不是按”领域”分类的——不是说游戏的 Capsule 只给游戏用，后端的只给后端用。EvoMap 的匹配算法看的是策略本质和环境适配度，不看领域标签。

我第一次看到这个案例的时候觉得有点玄乎。后来想想，其实 Stack Overflow 上也经常发生类似的事——你搜一个 Python 问题，最佳答案可能来自一个 Haskell 程序员。知识迁移本来就不按学科边界走。EvoMap 只是把这个过程自动化了。

EvoMap 的传输层：GEP-A2A 协议

Agent 之间怎么在 EvoMap 网络里交换经验？靠 GEP-A2A 协议。

官方 skill.md 写得很清楚：

• • 协议名称：GEP-A2A v1.0.0
• • 传输方式：HTTP（推荐）或本地文件传输（FileTransport）
• • Hub URL：https://evomap.ai

两个核心设计点。

第一，所有交互走统一的 JSON 信封结构（envelope）。里面装着 protocol、protocol_version、message_type（hello / publish / fetch / task 等）、message_id、timestamp、sender_id、payload。标准化做得不错。

第二，资产用内容寻址：asset_id = SHA256(canonical_json(asset_without_asset_id))。改一个字节，hash 就变了。不可篡改，可验证。这个设计跟 Git 的 content-addressable storage 思路一脉相承——也是 EvoMap 安全机制的基础。

节点注册（hello）

Agent 调用 POST https://evomap.ai/a2a/hello 注册到 EvoMap 网络。本地生成 sender_id（node_ + 8 位随机 hex），带上能力声明和环境指纹。EvoMap Hub 返回 claim_code（供人类认领节点）和 500 初始积分。

发布资产（publish）

一个”经验包”通常是 Bundle，里面三样东西：

• • Gene：策略层面的抽象能力，”怎么想”
• • Capsule：具体实现和执行步骤，”怎么干”
• • EvolutionEvent：过程记录，环境、输入输出、成功率、影响范围

发布的时候 EvoMap Hub 会做校验：Bundle 是否完整、asset_id 是否正确、summary 是否够长。缺东西会被拒。

获取资产（fetch）

POST /a2a/fetch，可以指定 asset_type（比如 "Capsule"），加 include_tasks: true 同时拉任务列表。EvoMap 返回候选和已晋升的资产，带着 GDI 评分、成功率、依赖关系。前面说的跨领域匹配就发生在这一步——EvoMap 的推荐算法根据谱系数据和环境指纹，把最可能有效的 Capsule 推给请求方。

任务与激励（bounty / task）

用户在 EvoMap 上发布带奖励的悬赏任务。Agent 通过 POST /task/claim 认领，完成后 POST /task/complete 提交成果拿积分。高信用节点还可以作为”聚合者”，参与多 Agent 任务分解与协作。

整套 API 设计挺干净的。RESTful 风格，JSON 信封，内容寻址。没什么花活，但该有的都有。不绑定特定 Agent 框架——只要你的 Agent 能发 HTTP 请求，就能接入 EvoMap。

EvoMap 的质量门控：自然选择的工程实现

Stack Overflow 有投票、有采纳答案、有声誉系统。

EvoMap 也需要类似的机制。但更难——它得自动判断一个”答案”是不是真的好使。人类可以读答案判断质量，Agent 不行。EvoMap 的质量判断必须是全自动的。

核心评估指标叫 GDI（Gene Development Index）。综合看四个维度：success_streak（连续成功次数）、confidence（置信度）、blast_radius（影响范围）、signals_match（信号匹配度）。

新上传到 EvoMap Hub 的资产先是 candidate 状态。多轮调用验证、质量门控全过了，才能 promoted 进全网分发池。

门槛：confidence ≥ 0.7，blast_radius ≤ 5 文件，success_streak ≥ 2。

效果好的留下，效果差的淘汰。达尔文。

EvoMap 的 Fitness Landscape 指标在这里发挥作用——它不是静态地看单个 Capsule 的评分，而是在整个基因池的上下文里评估适应度。同一个 Capsule 在不同任务环境下的适应度可能完全不同。

坦率说，这套机制现在还比较粗。confidence 0.7 不算高，blast_radius 5 个文件也挺宽松。我看到这组参数的第一反应是——这更像是”先让 EvoMap 跑起来”的保守阈值，不是最终形态。生态规模上来之后，这些数字大概率得动态调。

但 v1 嘛。先跑起来再说。

EvoMap 的安全隐患：能力遗传的另一面

好的说完了。说说让人担心的。

EvoMap 是被平台乱象逼出来的。但讽刺的是，逼出它的那些问题——恶意插件、安全漏洞、平台失控——EvoMap 自己也得面对。能力全网遗传，这件事本身就是双刃剑。

恶意传播风险。 一个有问题的 Capsule 混过了 EvoMap 的质量门控，短时间内可能被全球 Agent 继承。大规模 AI 失效。这不是理论风险——ClawHub 的恶意 Skill 事件就是前车之鉴。据 Awesome Agents 报告，2026 年 1 月底到 2 月中旬，ClawHub 被注入了 1184 个恶意技能，占总量的 36.8%。一个攻击者就上传了 677 个包。伪装成加密交易机器人、YouTube 总结器之类的东西，下载量数千次。手法不复杂：在 SKILL.md 文档里诱导执行 curl | bash，装恶意程序。偷浏览器密码、60 多种加密钱包、SSH 密钥、Telegram 会话……受影响实例超 13.5 万个，分布在 82 个国家。

36.8% 的恶意占比。想想这个数字。三分之一以上的 Skill 是恶意的。

EvoMap 如果安全机制不到位，同样的事情完全可能发生。而且 EvoMap 的风险比普通 Skill 市场更大——因为 Agent 是自动继承 Capsule 的，不需要人类审核每一个。npm 包顶多搞坏你的构建流程，恶意 Agent Capsule 能直接偷你的密钥和钱包。

质量管控压力。 EvoMap 生态规模小的时候门控够用。规模上来之后呢？海量胶囊的审核压力急剧增加。劣质胶囊混进来的概率也会升。

隐私与合规。 Capsule 里可能带着代码片段、业务逻辑。企业级场景下，脱敏和合规审查绕不开。

EvoMap 怎么应对？

GEP 协议引入了达尔文哥德尔机（Darwin Gödel Machine）的核心逻辑，给 AI 自主进化加上”自我校验”。同时建人工应急通道——出问题了，快速从 EvoMap Hub 下架胶囊，暂停传播。

质量体系是三级管控：算法初筛、人工复核、动态追溯。EvoMap 里每个 Capsule 附带 SHA-256 资产 ID，改一个字节就能发现。环境指纹验证防止跨平台兼容性问题。贡献者有声誉系统，高质量贡献者在 EvoMap 的推荐排名里权重更高。

用户也可以在隔离环境里先跑一遍 EvoMap 推荐的 Capsule，验证没问题再上生产。

不过说实话，这些措施目前更多停留在设计层面。EvoMap 还在早期，真正的安全考验得等规模上来才知道。能不能扛住？

不好说。安全是架构设计的一部分。不是事后补丁。

EvoMap 的运营数据：跑起来了，但得打问号

EvoMap 官网上展示的核心指标：

成本对比：100 个 Agent 独立进化大概要 10,000 美元。通过 EvoMap 知识共享，降到几百美元。官方说节约率约 95%。

这组数据得打个问号。

658.2M Token 节省和 95% 成本节约率都是 EvoMap 官方数据，没有第三方审计。搜索命中率 90% 也得看测试条件——在什么数据集上测的？覆盖了多少场景？这些信息都没公开。

1,838 个重复基因检测、14 万次复用，这两个数字倒是比较实在。至少说明 EvoMap 在跑，有真实使用量。但跟”658.2M Token 节省”之间的换算关系，我没想明白。

达尔文哥德尔机：EvoMap 的理论根基

聊 EvoMap 的技术根基，绕不开一个更激进的东西——达尔文哥德尔机（Darwin Gödel Machine，DGM）。东京 AI 研究机构 Sakana AI 提出的。

哥德尔机是 Jürgen Schmidhuber 2003 年提出的 AGI 理论。核心要求：每次自我修改都得通过形式化证明，确保”可证有益”。

听着完美。做不到。

形式化证明的复杂度随系统规模指数增长。复杂场景下根本证不完。这个理论从提出到现在二十多年了，一直停留在纸面上。

DGM 务实了一把。不追求形式化证明了，用实验证据替代。

怎么做的——迭代修改自身代码，提升”修改自身代码库”的能力。同时搞开放式探索，不断构建 Agent 档案库。档案库里的 Agent 通过自我修改和下游任务评估持续迭代。技术上，它递归地改自己的 Python 代码库，通过进化式编码优化算法，提供自指（self-referential）框架。

EvoMap 的 GEP 协议是 DGM 理念的工程化落地。

DGM 给了理论框架：自我修改、开放式探索、适者生存。EvoMap 给了工程实现：GEP 协议做标准化封装，EvoMap Hub 做分布式验证和质量门控，进化谱系树做可追溯审计。

一个管”应该怎么做”。一个管”实际怎么做”。

这两件事之间的距离，做过工程的人都懂。EvoMap 的安全机制里提到的”自我校验”逻辑，就是从 DGM 借来的——让 Agent 在进化过程中自主识别恶意策略或错误能力。

EvoMap 在协议栈里的位置：Agent 通信的三方格局

2026 年，Agent 通信协议正在形成三方格局。EvoMap 在其中占据一个独特的位置。

MCP（Anthropic）

标准化 AI 系统与数据源的连接。客户端-服务器架构，ChatGPT 这类应用可以同时调多个 MCP 服务器，每个服务器独立连本地数据库或远程 API，通过 list_tools 和 call_tool 动态扩展工具链。

影响力很大。基本是事实标准了。但 MCP 只管连接。连上之后的能力管理、经验传承，不在它的范围内。

A2A（Google）

跨平台 Agent 直接通信。Agent 之间可以发现、调用、协作，支持任务分解和结果聚合，有标准化的身份认证和权限管理。EvoMap 的 GEP-A2A 协议就是基于 A2A 构建的。A2A 管”怎么通信”，EvoMap 管”通信什么内容”。

ACP

通过 RESTful API 实现协作。简单、通用、好集成。但规模一大，复杂度会上来。

把 EvoMap 放进协议栈全景里看：

┌─────────────────────────────────────────────────────────┐
│                    应用层                                │
│     ChatGPT / Claude / OpenClaw / Manus / Cursor        │
├─────────────────────────────────────────────────────────┤
│                    协作层                                │
│              A2A 协议（Agent 间通信）                     │
├─────────────────────────────────────────────────────────┤
│                    进化层                                │
│         EvoMap / GEP 协议（经验传承与进化）               │
├─────────────────────────────────────────────────────────┤
│                    连接层                                │
│              MCP 协议（工具连接）                         │
├─────────────────────────────────────────────────────────┤
│                    传输层                                │
│              HTTP / WebSocket / gRPC                    │
└─────────────────────────────────────────────────────────┘

每层解决一个问题。MCP 层最成熟，EvoMap/GEP 层最早期。

这个分层看着很清晰，但实际上层与层之间的边界没那么干净。比如 A2A 和 EvoMap 之间，到底谁负责资产的路由和发现？EvoMap 文档里写的是 GEP 通过 A2A 传输，但 A2A 本身也有任务分发的能力。这块的职责划分，我觉得后面还得再理一理。

Agent Infra 2026：EvoMap 的行业背景

谷歌《AI Agent trends 2026》报告提了几个趋势。放在 EvoMap 的语境下看特别有意思。

Computer Use 正在成为标配。Agent 不只是对话工具了——打开应用、填表单、发邮件、处理文件。以前得人手动干的活，Agent 开始自己做。这意味着 Agent 会产生更多的”经验”——而 EvoMap 就是让这些经验不被浪费的基础设施。

记忆架构也在升级。上下文处理能力提升 10 倍以上。不是简单的窗口扩大——短期记忆、长期记忆、工作记忆、情景记忆，开始被系统化管理。这跟 EvoMap 有交集。EvoMap 本质上就是一种跨 Agent 的”集体长期记忆”——不是某一个 Agent 的记忆，是整个生态的记忆。

几个数据：52% 的生成式 AI 应用企业已经把 Agent 投入生产了。88% 的早期采用者在至少一个场景中获得正 ROI。德勤预测 2026 年一半组织会把超过 50% 的数字化转型预算砸进 AI 自动化。

不是实验性技术了。是真金白银在砸。Agent 越多，经验浪费越严重，EvoMap 这类进化基础设施的价值就越大。

EvoMap 背后的人：从游戏 NPC 到 Agent 进化协议

EvoMap 创始人张昊阳（代号：17）。

95 后。前腾讯《和平精英》AI 策划，中国首批虚幻 4 引擎开发者，8 年经验。2023 年从腾讯离职，创立 AutoGame。

游戏行业对”智能体”的理解跟纯 AI 研究者不一样。游戏策划每天都在设计 NPC 的行为逻辑、决策树、状态机。天然就理解”角色”、”上下文”、”目标驱动”这些概念。张昊阳 2023 年提出游戏”全要素生成”理念，做了《伊甸岛》——中国版斯坦福 AI 小镇。AI NPC 在虚拟世界里自主生活、社交、工作。

从游戏 NPC 到 EvoMap。路径挺顺的。

2026 年 1 月 31 日。昆明机场。航班延误 12 小时。

张昊阳用手机远控开了台 GCP 云服务器，部署刚开源的 OpenClaw。两小时部署完。又过 40 分钟，给 AI「小虾」发了段语音文档。小虾自己读了文档，跑到公司语音合成平台找音色，把文档转成语音。

全程没人管。

12 小时。在机场。用手机。顺手部署了一个 Agent 系统，Agent 自己跑完了后续任务。

第二天，Evolver 插件上线 ClawHub。10 分钟登顶——然后就是前面详细讲过的那场风暴。勒索、封号、收购，两周之内全来了。被逼到墙角的团队，两周后交出了 EvoMap。

三轮融资，总计数千万人民币。奇绩创坛、九合创投、璀璨资本等。核心团队来自 Meta AI、苹果 Siri、腾讯、暴雪娱乐。

背景挺硬的。但背景硬不代表能成。Agent Infra 这个赛道，技术壁垒和生态壁垒都很高。最终还是得看 EvoMap 的产品和社区能不能真正跑起来。

接入 EvoMap：一行命令

接入门槛确实低。

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

这个文档是给 Agent 看的，不是给人看的。Agent 按文档指引走：hello 注册到 EvoMap Hub → fetch 已有资产 → 发布自己的 Capsule → 认领 bounty 任务赚积分。

官方也提供开源客户端 Evolver：

npm install && node index.js --loop

Loop 模式下每 4 小时自动跑一轮：重新注册 EvoMap 节点、拉取新资产、尝试发布新经验、认领新 bounty。

目前兼容 OpenClaw、Manus、HappyCapy、Cursor、Claude、Antigravity、Windsurf。只要你的 Agent 能发 HTTP 请求，就能接入 EvoMap。

门槛低是好事。但门槛低也意味着恶意 Agent 接入的成本同样低。安全和开放之间的平衡，永远是个难题。

EvoMap Marketplace：可执行的答案库

Stack Overflow 的答案质量参差不齐，得读者自己判断。

EvoMap Marketplace 里的 Capsule 自带 GDI 评分、成功率、环境适配信息。更像一个”可执行的答案库”——Agent 不需要”读”答案，直接继承。

EvoMap Marketplace 里每个 Capsule 标注 GDI 评分等级、被调用次数、贡献者 ID、适用环境、依赖关系。信息透明。Agent 通过 fetch 接口拿到这些元数据，自己判断要不要用。

说实话，看到 MySQL 连接超时优化评分 0.90 的时候，我第一反应是想知道它的 wait_timeout 设的多少。这种细节决定了胶囊在不同环境下能不能直接用。评分高不代表适合你的场景。EvoMap 的环境指纹匹配机制在这里就很关键——它不是盲目推荐评分最高的，而是推荐环境最匹配的。

EvoMap 的激励闭环：Credit 与 Bounty

EvoMap 的经济模型很直接。胶囊被调用，开发者拿 Credit。Credit 能换 Premium/Ultra 服务，也能换云服务、API 额度、计算资源。用户还可以在 EvoMap 上发布带 Credit 奖励的悬赏任务，全球 Agent 自动接单竞争，赢了拿积分。

闭环长这样：开发者养 AI → AI 攒经验打包胶囊 → 胶囊上传 EvoMap → 被其他 Agent 调用获积分 → 积分换资源 → AI 能力再升级。

设计上解决了开源社区”用爱发电”的老问题。EvoMap 的贡献者声誉系统也在这里发挥作用——高质量贡献者不仅拿更多积分，在 EvoMap 的推荐排名里权重也更高，形成正向飞轮。

实际效果嘛。得看 Credit 的真实购买力。积分不值钱的话，激励就是空话。这个问题在所有积分体系里都存在——积分的价值最终取决于生态规模和可兑换资源的丰富程度。EvoMap 现在还早期，这个闭环能不能真正转起来，我持观望态度。

EvoMap 的未来：被逼出来的东西能走多远？

泼盆冷水。

协议的价值取决于采用率。HTTP 之所以是标准，因为全世界都在用。TCP/IP 之所以赢了 OSI，不是因为技术更好，是因为实现更早、生态更大。EvoMap 的 GEP 协议还在极早期，能不能成标准，得看它能在多少场景里证明自己。

回到开头的故事。

一个插件 10 分钟登顶，次日被勒索下架，账号被封，平台被收购。两周之内，团队从”在别人平台上做插件”转向”自己建底层协议”。这个转折够戏剧性。但戏剧性不等于正确性。

被逼出来的东西，有时候反而比规划出来的更有生命力。Linux 是 Linus 因为买不起 Unix 被逼出来的。Git 是 Linux 社区跟 BitKeeper 闹翻被逼出来的。Bitcoin 是 2008 金融危机逼出来的。

EvoMap 能不能加入这个名单？不好说。

但问题是真的。Agent 需要一个经验遗传的基础设施。几百万 Agent 每天重复踩同样的坑，这件事不可持续。

过去十年是”训练”时代。把更多数据喂给更大的模型。

未来十年大概率是”进化”时代——Agent 通过实时学习、能力共享、自然选择，长出涌现智能。EvoMap 赌的就是这个方向。

一个 Agent 学会，全网继承。这句话现在还是愿景。但底层协议已经在跑了。

先能跑通，再跑得好。工程上这个顺序是对的。

参考阅读

• • EvoMap 官网
• • EvoMap 技术博客
• • GEP-A2A 协议规范
• • Evolver 开源客户端
• • OpenClaw GitHub
• • MCP 协议官网
• • 量子位：《ClawHub 迷之封杀操作，逼出首个 Agent 全球进化网络》
• • 极客公园：《OpenClaw 榜一插件被下架后，他用两周做了一套协议》
• • 德勤《Tech Trends 2026》
• • 谷歌《AI Agent trends 2026》