1. EvoMap 到底在映射什么：一张会进化的能力地图

先交代一下背景。我前段时间在梳理一套智能体系统的调用关系时，被三个概念来回折腾：Skill、MCP、GEP。每个概念单拎出来都有人讲，但放到同一个项目里，它们到底是什么关系、该谁先谁后、该由谁来负责哪一部分，几乎没有一份资料能讲透。后来我试着用 EvoMap（演化地图）这个分析框架重新拆了一遍，才发现之前一直绕圈的根源，是我把三个不同结构层面的东西硬放在了同一个维度里比较。

EvoMap 的核心想法并不复杂，它把智能体面对的环境和它拥有的能力放在同一张图里。图中每个节点是一个能力单元，比如“解析一份PDF”“查天气”“生成SQL”“调用某个内部接口”；每条边是一次可调用的路径，比如模型向某个工具发起的请求，或者一个模块对另一个模块的依赖。任务每执行一次，这张图上就会留下一条轨迹。跑的次数多了，哪些路径总是成功、哪些路径常年失败、哪些能力其实从没被用到，全部一目了然。

这张图最关键的属性是“可演化”。它不是一张静态架构图，而会随着使用不断调整：失败频发的边权重会被压低，甚至被移除；高价值能力旁边会长出新的辅助节点；当外部环境变化时，曾经的核心节点可能迅速边缘化。你可以把智能体的进化过程理解成：沿着经验不断调整图上路径，让下一个任务走得更顺。这和进化算法里“变异—选择—适应度”的思路类似，但落地到工程上，真正有用的是下面三个原则。

第一个原则：能力好不好，不能脱离场景单看。同一个能力节点，在任务A里稳定高效，在任务B里可能就是个死点。所以评估Skill必须放到具体任务轨迹里看“用得上”和“用得成”，而不是看实现代码多优雅。第二个原则：路径价值由“使用频率乘成功率”决定，而不是由实现者的自我感觉决定。很多团队会花大力气优化一个一周都用不上的封装，却忽视那些高频失败的路径，这在EvoMap视角下非常得不偿失。第三个原则：地图必须允许自动增删。一动不动的能力清单不是地图，是陈列架。好的智能体系统，应该具备能力评估机制，判断哪些节点值得沉淀、哪些边要被替补，让整体调用结构随着任务分布自然收敛。

把这三样东西放到地图上，就得到了一句我后来反复引用的话：Skill 是图里的能力节点；MCP 是边的标准化；GEP 是图中长路径的通用执行规则。后面的所有内容，都是围绕这句话展开的。Layer 架构容易让人误以为上层就是更高级的，但 Skill、MCP、GEP 之间的关系不是一条从上到下的直线。你是想定义一个具体能力，还是在定义两个模块之间怎么交流，又或者是在定义一整条多步任务该按什么顺序走？答案不同，概念自然不同。

1.1 EvoMap 如何帮你做技术选型

我之所以坚持用“地图”而非“分层架构”来理解，是因为在真实项目里，你很难说清楚某一段代码“属于”哪一层。一个函数可能同时具备能力封装和协议适配的代码；一个编排逻辑里也可能临时内联了一段工具调用。分层思维会逼着你把所有东西放进固定格子，而地图思维允许你先画节点、再画边、最后画路径。

实际做选型时，我一般会先画一张粗糙的能力地图：左边列出所有可能被调用的外部工具和内部模块，右边列出高频任务场景。然后每个任务场景里，标出它实际经过的节点序列。画完之后，三个问题自然浮出来：存在哪些重复建设的能力，说明 Skill 需要抽象；哪些能力有多端接入需求，说明该考虑 MCP；哪些多步任务经常在中间环节失败，说明需要 GEP 来规范过程。

这个方法我用过很多次，几乎每次都能快速定位当前项目缺哪一环。很多团队的问题不是“没有能力”，而是地图上的边和路径混乱，导致明明有节点，却走不通；或者路径太个性化，换个场景就彻底失效。EvoMap 给的不是答案，而是定位问题的坐标系。

2. Skill 是能力节点，不是函数列表的别名

2.1 一个合格 Skill 的组成部分

如果把 EvoMap 的每个节点比作一个站点，那 Skill 就是站点本身。它是智能体真正“做事”的单元。一个合格的 Skill 不是简单地包一个函数，它至少要包含四样东西：稳定的输入输出约定、明确的触发语义、可观测的失败反馈、以及可验证的执行结果。

举个例子，假设我们要做一个“从日志文本中提取错误码”的能力。底层实现可能是一段正则匹配脚本，也可能是一个小的分类模型，但对外暴露的 Skill 应该长这样：

输入：一段不定长日志文本； 输出：结构化数组，每个元素包含错误码、出现次数、关联日志行号； 失败模式：输入为空时返回明确错误码，而不是抛出晦涩异常； 能力描述：用一段简短的自然语言说明它适合处理什么、不适合处理什么。

为什么“能力描述”这么重要？因为在智能体系统里，调用方往往不是人，而是模型。模型需要根据任务目标和已有上下文，自己判断该调用哪个 Skill。如果 Skill 没有描述清楚适用边界，模型就可能拿它去处理不匹配的任务，然后在 EvoMap 上留下一条失败边。很多项目踩坑，就是因为在抽象能力时只写了“实现了一个工具函数”，却忘了告诉模型“什么时候该用它”。

从 EvoMap 的角度看，Skill 应该尽量与单一职责对应。一个能力节点覆盖的任务类型越杂，它在图上就越难被准确找到。这就像地图上一个标注了“什么都卖”的巨型商场，导航系统根本不知道该把你导到哪个入口。所以我在设计 Skill 时，宁可多拆几个细粒度节点，也不做一个覆盖全场景的“万能能力”。

2.2 Skill 和普通函数到底有什么区别

很多刚接触智能体开发的人会把 Skill 理解成“给函数写个注释”，这其实错得离谱。普通函数和 Skill 的区别，可以从三个维度来看。

第一是调用方式。普通函数由开发者显式调用，参数必须在代码层面精确匹配；Skill 则可能由模型在运行期动态选择，参数来源可能是自然语言抽取，也可能是上一个 Skill 的输出，因此它的输入输出约定必须足够宽容且结构清晰。第二是上下文感知。Skill 可以依赖当前会话的上下文状态，比如“读取项目根目录”这个 Skill 依赖的就是执行环境里已经存在的目录变量。第三是生命周期。普通函数被调用完就结束了，Skill 则应该带有可观测的生命周期——它被选中了几次、成功了几次、平均耗时多少，这些数据会持续反馈到 EvoMap 的评估机制里。

我见过有个团队把所有 Py 文件里的函数都套了一层“Skill 装饰器”，结果地图上一下子多了几百个节点，模型光理解这些能力描述就快崩溃了。原因就在于他们没有区分“可复用能力”和“普通内部函数”。判断标准其实很简单：这个能力是否会被多个不同的任务场景复用？如果答案是否，它就没有资格成为节点，至少现在没有。

2.3 用 EvoMap 的指标给 Skill 打分

EvoMap 给我最大的启发在于，它把 Skill 从一个“写得好不好”的问题，变成了“在地图上活得好不好”的问题。我一般用三个指标评估一个 Skill：

• 覆盖率：它声明的任务类型里，实际能正确处理的占比；
• 成功率：在所有被调用记录中，稳定完成且结果可用的比例；
• 复用度：它在不同任务轨迹中被选中的频次。

这三个指标共同决定一个 Skill 节点的去留。覆盖率低，说明这个能力名不副实，要么改描述，要么重新实现；成功率低，说明它不适合被模型直接调用，需要加固容错或缩小边界；复用度低，说明它当前没有场景支撑，先降级为普通函数，等有高频需求再升级。

有个反直觉的现象值得注意：一个实现质量很差的 Skill，只要它覆盖了一个其他节点覆盖不了的任务，它仍然会长期存在于地图上，甚至因为“唯一性”而获得很高调用权重。这恰恰是 EvoMap 想表达的——地图关心的不是单点质量，而是整体可达性。真实系统里，一个“不太好但可用”的节点，往往比一个“完美但只在理想条件下可用”的节点更有生存价值。

3. MCP 是“边的标准化”，解决的是能力可达性问题

3.1 没有标准协议时，适配成本会指数膨胀

如果说 Skill 解决“智能体能做什么”，那 MCP 解决的就是“智能体怎么接到外部能力”。这里说到的 Model Context Protocol，可以理解为一套统一交互约定：模型、应用、外部服务之间通过标准方式来发现工具、传递参数、获取结果。它把原来一对一的私有接法，变成一套大家共同遵守的公共接法。

为什么需要公共接法？回到 EvoMap 上。假设图里有 N 个能力节点，M 个调用方（包括模型、不同客户端、外部系统）。如果每个调用方都要和每个能力节点单独写一套适配，那么需要维护的适配器数量就是 N×M。这个数字到两位数还可以接受，一旦能力和调用方分别到了几十个，适配就变成了灾难，每次改一个接口都要牵动一串上游。

MCP 的做法是把适配关系拆成“调用方对协议”和“能力方对协议”。新增一个能力，只要实现一次标准服务端接口；新增一个调用方，只要实现一次标准客户端逻辑。系统从 N×M 的网状适配，变成了 N+M 的星型对接。这是典型的标准协议收益，和当年统一电器接口、USB 接口的逻辑一模一样。

3.2 MCP 在 EvoMap 上的真实角色

有些人跑通一个 MCP 示例后，看到工具列表里出现了一堆函数，就以为“MCP 就是 Skill”，这是最容易产生的误解。用 EvoMap 的视角看，MCP 是“边的标准化”，而不是“节点”。它不生产任何能力，只负责让两个端之间的连接变得更统一、更可靠、更容易被复用。

一个 MCP Server 可以暴露多个“工具入口”，这些入口背后可以是一个正式 Skill，也可以只是一个临时脚本。反过来，同一个 Skill 也可以同时通过 MCP 暴露、通过 HTTP 接口暴露、或者作为普通函数被直接调用。Skill 本身并不绑定传输方式。如果一个人跟你说“我的能力是 MCP”，那他多半还没理解地图上的分工——他应该说的是“我的能力通过 MCP 这个边被访问”。

MCP 真正改变的是地图上边的生成成本。没有它时，每新增一条边都要重新做对接；有了它之后，新边在接入的那一刻就天然拥有了和其他边一致的行为模式，包括参数校验、错误返回、连接管理。这套成本下降对地图演化的价值非常大，因为它意味着“尝试新路径”的代价变低了，智能体可以更频繁地在图上探索新的可能性。

3.3 MCP 里值得注意的实现细节

实际使用 MCP 时，有三个细节容易被忽视。第一个是工具描述的“可发现性”。MCP 的工具列表是模型了解能力的第一入口，描述写得够不够清楚，直接决定模型会不会在错误场景调用它。有时候描述里少一个负面条件，就会导致模型反复尝试一个注定失败的能力。第二是输入参数的容错设计。模型从自然语言里抽取参数时经常带有噪声，所以参数定义尽量宽松，并提供默认值，远比严格类型检查更能提升成功率。第三是结果返回的语义统一。不管底层能力返回什么格式，对外最好统一成结构化的成功/失败结果，这样上层的 GEP 才能根据反馈做出更精准的决策。

有一点需要提前想清楚：MCP 标准能标准化“连接方式”，但不能标准化“能力质量”。接入协议只是开始，后面还有大量在 EvoMap 上观察这个节点实际表现的工作。

4. GEP：把“点和点怎么连”上升到“一张图怎么跑完”

4.1 为什么还需要一套执行层的统一规范

实践中学到的另一件事是：多步任务和不屬於编排的成功率，常常不是某一个工具不行，而是路径管理混乱。一个智能体要完成“生成行业分析报告”，可能要经历：检索资料、整理数据、生成大纲、填充内容、格式转换、合规校验。如果每一步都由模型临时自由发挥，中间任何一环失败，后续都不知道该如何继续；如果依赖写死在代码里的 if-else，又会把灵活性全部牺牲掉。

这时候就需要 GEP 这样一个执行层的通用规范。GEP 在中文社区里通常被理解成“通用执行协议”或“通用执行规范”，核心作用是约定一整条任务链路的推进方式：任务分几个阶段、阶段间如何传递状态、每一步失败如何处理、需要保留哪些中间记录。它不规定每一步具体怎么做，只规定“这个过程应该如何被管理”。

在 EvoMap 语言里，GEP 可以理解为“典型长路径的固化”。当某一类任务已经反复成功，我们就可以把从起点到终点的完整走法提取出来，加上异常分支、重试策略、降级预案，形成一条被验证过的“高速公路”。新任务如果符合这个模式，智能体就不用再从零找路，直接按 GEP 的框架走，同时保留在每个节点内部做具体选择的弹性。

4.2 GEP 和 MCP 的分界：一个管连接，一个管过程

最常被混淆的就是 GEP 和 MCP，因为它们都带着“协议”的影子。但用 EvoMap 来看，分界非常清楚：MCP 标准化的是“一条边怎么连上”，GEP 标准化的是“由多条边组成的一段旅程怎么走完”。前者是连接层问题，后者是编排层问题。

我见过有人试图在 MCP 接口里塞入状态机和重试逻辑，想让协议本身承担执行编排职责，结果每个工具实现都被迫引入一套全局状态的判断，复杂度快速上升。更好的做法是让 GEP 在更高的执行层面管理整条链路，而 MCP 只负责一次一次的标准交互。两者不是竞争关系，而是接力关系：GEP 规划好路径之后，每一段的实际传输仍要由 MCP 完成。

我简单用一张表记录两者的差异，方便项目评审时快速对齐：

4.3 GEP 会不会取代 Skill

答案是不会，两者根本不在同一个层面。GEP 定义的“路径”最终要落到具体的 Skill 节点上执行：第一阶段调用检索 Skill，第二阶段调用数据清洗 Skill，第三阶段调用生成 Skill。GEP 是那个负责说“按这个顺序走，失败了去那里避风”的总调度，但真正干活儿的永远是 Skill 节点。

用个形象的类比：GEP 是导演，负责分镜、进度、突发情况的处理；Skill 是演员，负责把每一场戏实实在在演出来。没有演员，导演的脚本只是一纸空文；没有导演，演员们不知道什么时候该出场、怎么配合。两者配合，拍出来的才是一部完整作品。

5. 用一张图理解三者分工：节点、边、路径的组合逻辑

5.1 核心差异对照表

到了项目方案设计阶段，我通常会给团队画这样一张三列对比表：

这张表每次评审都帮我很多。它不是理论推演，而是我多次踩坑后的总结。比如在“典型失败原因”那一行，Skill 我见过最多的是“功能本身不稳定却强行抽象”；MCP 最多的是“各个服务对规范的理解不一致”；GEP 最多的是“把简单任务复杂化”。知道每种技术最典型的死法，你就能在架构阶段提前避开。

5.2 一个具体项目里的协作方式

拿最熟悉的“自动生成项目周报”场景举例。这个任务看起来简单，真正跑起来却涉及好几个能力：读取代码提交记录、聚合工时数据、按模板生成 Markdown、推送到指定系统。把它们装进三层结构后是这样的：

能力层：沉淀出四个 Skill。“读取仓库提交记录”负责拉取最近七天的 commit；“统计各成员工时”负责按作者聚合数据；“生成结构化周报”负责套用模板输出；“发送周报”负责推送但权限校验失败时返回明确错误。

连接层：把上述 Skill 通过统一的 MCP 服务暴露给模型。模型拿到的是一个标准化的工具列表，工具名、参数说明、返回结构统一风格，无论在哪个客户端操作，看到的接口都一样。

执行层：GEP 约定整体顺序：取数 → 聚合 → 生成 → 校验 → 发送。取数失败自动重试两次；聚合阶段如果数据量不足，自动降级为“按天汇总”；生成完毕后必须经过关键词校验，未通过则返回生成阶段重新修改；发送前保留一次人工确认机会。

在这个例子里，Skill 决定了“这些事都能干”，MCP 决定了“模型能稳定安全地调用它们”，GEP 决定了“这些事以什么顺序干、失败了怎么处理”。三个概念各司其职，缺一环，这个自动周报系统都会要么能力混乱、要么交互困难、要么整条流程不可控。

5.3 不要为了完整而强行套三层

不过，必须泼一盆冷水：不是所有项目都需要同时引入 Skill、MCP、GEP。以 EvoMap 的“成本—收益”来看，如果任务只有一两步、失败模式又很简单，直接用普通脚本调 Skill 就行，引入 MCP 和 GEP 反而增加不必要的复杂度。一套优秀的架构不是把所有先进概念全堆上去，而是让每层技术都在它该出现的时候才出现。

我通常这样判断：先让地图自然长出几条高频路径，再根据实际拥堵决定铺什么样的基础设施。只有当你明显感受到多端重复接入、或者长任务频繁失败的时候，才值得系统性引入 MCP 和 GEP。过早的基础设施建设，和过晚的技术债务一样，都是成本。

6. 我踩过的坑，和现在推荐的实践顺序

6.1 坑一：把“所有可调用函数”一律包装成 Skill

最早做智能体时，我把项目里能封装的东西全都封装成了 Skill，想着能力越多越好。结果地图上节点爆炸，模型每次决策要面对一堆互相重叠的能力描述，反而不知道选哪个。后来才意识到，Skill 的抽象标准不是“能不能复用”，而是“有没有被高频场景实际需要”。低频逻辑先留在脚本里，等失败多了、被反复请求了，再升级为正式节点。

6.2 坑二：在 MCP 里硬塞执行状态

另一个印象深刻的问题，是想让传输协议自己处理“当次调用失败后要不要重试”这类执行级逻辑。结果每个 Server 都开始维护前端传入的执行状态，协议越来越重，调试却越来越难。把执行过程的管理权交还给 GEP，让传输和编排各管一段，问题才迎刃而解。这让我越来越确信一个原则：一个标准只解决一个问题，边界模糊是架构腐化的开始。

6.3 坑三：一开始就上 GEP，把简单任务变成重流程

还有一次，在整体链路还不稳定时就开始设计通用执行规范，试图覆盖所有异常分支。几个月后发现这个“万能执行引擎”根本没机会被实际调用，因为它太复杂了，改动一个小场景都要回归测试大半天。正确的节奏应该是先把自然路径跑通，积累足够多的失败模式之后，再把高频路径提炼成可复用的执行规范。

6.4 现在常用的落地顺序

综合这些教训，我目前推荐这样一个循序渐进的实践顺序：

1. 先用 EvoMap 思路画出当前智能体的能力地图，把高频路径标记出来；
2. 只把高频且边界清晰的能力沉淀为 Skill；
3. 当多个客户端或外部系统都要访问同一批能力时，再引入 MCP 统一连接；
4. 当多步任务反复出现中途失败、且难以定位时，再提炼高频路径为 GEP 规范。

如果你现在恰恰被 Skill、MCP、GEP 这三个概念绕得头晕，我的建议是先别急着背诵定义，也别着急引入全套框架。找一张纸，把当前要做的事情画成地图：节点是什么、边是什么、哪几条路走得最多。等你真的把地图画出来，你会发现该在哪一层做什么，几乎是明摆着的事。这也是 EvoMap 带给我最大的价值——它不制造技术，它只是让技术各归其位。