嗨，我是 Lena。前阵子我听到一位 podcast 主持人丢出一句让我一下停住的话：“真正的瓶颈不是把工具连起来，而是 agent 一直在反复重学同样的东西。”
这话一下击中了我。在我自己的实验里，每一次 “New Session” 都像从零开始。我的 agents 不会把任何“经验”带到下一轮，也记不住五分钟前到底是什么失败了。
这难道就是 AI 的宿命吗？并不是——这其实是设计上的缺陷。最近我一直在顺着一个框架往下挖，想看看怎么补上它，里面正好有三层：MCP、CLI 和 GEP。 下面就是我把它们一点点拼起来的过程。
为什么 agent stack 会有分层问题
现在多数在做 AI agent 的团队，通常都会把两件事做得越来越顺：让 agent 连上工具，以及高效地调用这些工具。但他们不会自动得到第三样东西，那种会随着时间 持续累积 的东西。
换个角度想，会更清楚。一个 agent stack 其实要解决三类彼此不同的问题：
Connection —— agent 能不能找到并接到自己需要的工具？
Invocation efficiency —— 它能不能在不把整个 context window 都耗在 schema 开销上的前提下调用这些工具？
Experience retention —— 当 agent 真的摸清一件事以后，这份知识会不会留下来？
前两个问题，在现在的生态里其实都已经有了还算靠谱的解法。第三个问题——experience retention——才是几乎所有标准 setup 会悄悄塌掉的地方。agent 把一个问题解出来，session 结束了，却没有任何东西被保存成可复用的形式。下一轮再来，还是同一个问题，还是同一套试错。什么都没有积累下来。
这就是所谓的分层问题。下面这三层，刚好各自对应这三件事里的其中一件。
Layer 1 — MCP：把工具连接标准化
Model Context Protocol（MCP）是 Anthropic 在过去两年里提出的开放标准，用来把 AI agents 接到外部工具和 data source 上。大家最常用的类比，是把它看成 USB-C 接口——不再为每一对工具和 agent 单独定制连接方式，而是共用一个标准接口。而在这一层上，它确实做得很好。
MCP 把 connection 问题处理得很干净。agent 可以发现有哪些工具可用，理解它们能做什么，再通过一致的 protocol 去调用它们。对那种只有少量工具的简单 setup 来说，单靠 MCP 往往就已经够用了。
但一旦规模上来，MCP 的真实限制也会开始冒出来：
- Token overhead. MCP 会在 session 一开始，就把每个工具完整的 JSON schema 预先塞进 context window。GitHub MCP server 这一项单独就暴露出 93 个 tools，agent 还没真正开始做事之前，就先吃掉大约 55,000 tokens 的上下文。在 multi-server setup 里，光是 tool schemas，就可能在 agent 处理第一条用户消息之前，占掉 72% 的可用 context window 空间。
- Statelessness. 每个 MCP session 都是彼此独立的。上一轮什么有效，并没有内建机制可以继续带到下一轮。
- No experience retention. MCP 负责把 tools 连起来，但它不会替 agent 保留下自己学会的解法，也不会保存那些已经验证成功的 execution path。
什么时候单用 MCP 就够了：工具集很小、还在做 prototyping，或者是那种 dynamic discovery 确实有价值的 IDE integration。什么时候不够：工具很多的 production system，或者任何需要 agent 建立在过去经验之上的场景。
Layer 2 — CLI：更高效的 Tool Invocation
为什么 CLI 在 Token Cost 上更占优
MCP 和 CLI invocation 之间的 token cost 差距，大到足以影响 architecture decision。基于 CLI 的调用，每条 command 大概只要 200 tokens；而 MCP 在 multi-tool server 上，典型的 schema load 大约是 55,000 tokens。
Cloudflare 做过一个很具体的对比：如果把他们的 2,500 个 API endpoints 通过标准 MCP server 暴露出来，光 schema definition 就要吃掉 117 万 tokens——比今天前沿模型的整个 context window 还大。后来他们改成让模型面向 typed SDK 写代码，token usage 直接降了 81%。
这种差距落实到实际使用里，大概就是下面这个感觉。MCP 的 tool call 每次开新 session 都会加载 完整的 JSON schema：
{
"name": "get_document",
"description": "Retrieves a document from Google Drive",
"inputSchema": {
"type": "object",
"properties": {
"documentId": { "type": "string", "required": true },
"fields": { "type": "string", "required": false }
}
}
}
而 CLI 对应的写法，只是：
gdrive get --id <documentId>
没有 schema injection。agent 在训练里本来就已经知道 CLI tools 大致怎么工作，token cost 基本上就是这条 command 本身。
Progressive Discovery 与 Upfront Schema Loading
CLI 有一个经常被低估的优点，就是 agent 可以按需、渐进地探索。用 MCP 时，不管这些 tools 最后会不会被用到，完整 schema 都会在 session 一开始注入进来。用 CLI 时，agent 只有在需要某个具体 tool 的时候，才去跑一次 --help 看看它怎么用，然后直接调用。
Anthropic 自家的 engineering blog 也描述过这种模式：模型可以“按需读取 tool definitions，而不是一上来就把所有东西全读完”，靠的是一种 search-and-load 的方法，让活跃 context 保持精简。这有时就叫 progressive discovery——agent 是随着任务推进再慢慢把 tool knowledge 补齐，而不是一口气全塞进去。
CLI 的天花板在哪
CLI 在 invocation efficiency 这件事上确实解决得不错。但它解决不了的，刚好也是 MCP 没解决的那部分：statelessness 和 experience retention。一个基于 CLI 的 agent 也许终于摸到了某个不稳定 API 的正确 retry strategy，或者找到了处理复杂文件操作时正确的 command sequence——可这套解法只存在于那次 session 的 context 里。一旦 run 结束，它就蒸发了。下一个从头开始的 agent，还是会再走一遍同样的发现过程。
CLI 不是 MCP 的替代品。它更像是在 agent 已经从训练里获得足够 tool knowledge 的场景下，一层更高效的 invocation layer。但它和 MCP 一样，还是完全没有碰到那个“如何累积”的问题。
Layer 3 — GEP：Capability Evolution 与 Inheritance
GEP 真正额外带来了什么
Genome Evolution Protocol（GEP）是 EvoMap 的开放协议，用来在网络里打包、共享 agent capability。这里最关键的一点——也是我最开始读到它时一直反复搞错的一点——是 GEP 不是一个 logging system。
Logs 只是记录发生过什么。GEP assets 则是结构化、经过验证、可以复用的 capability 单元。它主要有两种 asset 类型：
Gene —— 一种可复用的 strategy template。你可以把它理解成原子级 capability：比如 “retry with exponential backoff”、“parse this specific API response format”、“validate SQL before execution”。一个 Gene 里会包含另一个 agent 安全套用它所需要的 intent、preconditions、constraints 和 validation steps。
Capsule —— 面向某个具体任务、已经验证过的 execution path。当 agent 真正把一个现实问题解出来时，整条路径——包括 environment fingerprint、confidence score 和 blast radius assessment——都会被打包成一个 Capsule。
GEP 定义的是 agent 如何通过 “trial-validation-solidification” 这个 loop 获得新 capability。Genes 是可复用、经过验证的 code 或 prompt fragments。Capsules 则是成功的 task execution paths；当 agent 解决掉一个复杂问题时，这条路径会连同完整 audit trail 一起被封装起来。
Gene 和 Capsule 这两类 asset 都是 content-addressed 的（也就是对内容做 SHA-256 hash），这意味着它们防篡改，而且版本稳定。这一点很重要：你继承的不是“某次碰巧管用的东西”，而是一个可验证、可审计的 asset。
Evolver Loop
GEP 的 evolution cycle 会经过六个阶段：Scan → Signal → Mutate → Validate → Solidify，中间还穿插一个 selection step，会根据 signal match、Capsule history 和 memory graph preference 给 Genes 打分。
在实际里，如果用 EvoMap 的 open-source Evolver engine，大概就是这样跑：
# Single evolution run (generates GEP prompt)
node index.js
# Review mode — pause before applying changes (recommended for production)
node index.js --review
# Continuous loop
node index.js --loop
Evolver 会扫描 runtime logs 和 session memory 里的 error patterns，把它们转成标准化 signals，选出最匹配的 Gene，生成 mutation，做验证，如果通过——再把它 solidify 成新的或更新后的 Capsule。
为什么这一层才是真正会累积的层
真正让我一下想通的，是下面这一点。当 EvoMap network 上有一个 agent 解决了问题，并把结果发布成 Capsule，其他 agents 就可以通过 A2A protocol 把这份解法抓回来、直接用上：
POST https://evomap.ai/a2a/fetch
{
"signals": ["api:timeout", "retry:failed"],
"environment": "node-18/linux"
}
只要接上这个 network，任何 agent 都可以通过 A2A 去 search、retrieve、apply 任意 Capsule——不受地理位置、团队边界或领域限制。agent 拿回来的会是一条带着 success rate 和 usage history 的具体建议：不是猜测，而是已经被证明过的解法。
三层是怎么协同工作的
下面这个具体场景，能把层与层之间的 handoff 看得比较清楚。
有一个 agent 要从一个会间歇性 timeout 的 external API 拉数据。它得先识别失败，再找出有效的 retry strategy，还要确保这套策略下次也能用。
MCP 负责 connection。 agent 先通过 MCP server 发现这个 API tool，完成 authentication，然后发起调用。MCP 做完了自己的职责：工具可达，schema 也清楚。
CLI 负责 efficient invocation。 agent 不再每次 retry 都重新载入完整的 MCP schema，而是把后续调用切到 CLI invocation——这样在处理 failure pattern 的过程中，context 会一直保持轻一点。
GEP 负责 experience retention。 一旦 agent 找到了可用的 retry strategy（比如在 429 response 上用带 jitter 的 exponential backoff），GEP 就会把它打包成一个 Capsule：
{
"type": "publish",
"gene": {
"id": "sha256:a3f8...",
"intent": "repair",
"preconditions": ["api:429", "retry:active"],
"constraints": ["no_breaking_changes"],
"validate": ["npm test", "curl --retry 3"]
},
"capsule": {
"signals": ["api:timeout", "http:429"],
"confidence": 0.87,
"blast_radius": "low",
"artifacts": [{ "kind": "patch", "path": "src/api-client.ts" }]
}
}
到了下一个 session，agent 就不用再重走一遍发现过程了。它只需要 fetch 已经验证过的 Capsule，检查 environment fingerprint，然后应用这个 fix。三层各自处理了自己的问题：connection、invocation、retention。
每一层做不到什么
这里有几个很常见的误会，我觉得最好还是直接点名说清楚。
把 CLI 当成 MCP 的替代品，是最常见的错误。CLI 只有在 agent 已经从训练里具备 tool knowledge 的时候才好用。遇到 novel tools、复杂的 authentication flow，或者 dynamic discovery 确实很重要的环境，它就会开始失灵——而这些恰恰就是 MCP 值回自己 overhead cost 的地方。
把 GEP 当成 logging system，则是彻底看偏了。Logs 属于 observability。GEP 是一套很严格的 agent evolution 标准——它定义了 agent 如何通过 trial-validation-solidification loop 获得新 capability，而这些 assets 是可复用、可验证、可做 lifecycle management 的。两者的差别，就像“读一份 post-mortem”和“直接继承一个能工作的 fix”之间的差别。
FAQ
Q：我一定要三层全上吗，还是可以只选其中一层？
你完全可以只从一层开始。只有少数工具的小型 setup，单用 MCP 就能工作得很好。CLI 则是在 context window 开始吃紧的时候才真正值得加上——也就是 schema loading 已经在挤掉 agent 真正需要用来推理的空间时。GEP 是最后那一块，说实话，通常要等你真的注意到那个模式之后，才会强烈需要它：agents 每个 session 都在重解同样的问题，什么都带不走。
Q：还没接好 MCP 或 CLI 之前，我可以先用 GEP 吗？
技术上可以。GEP 工作在另一层——它关心的是 capability 的打包与继承，不是 tools 怎么连接、怎么调用。Evolver engine 并不在乎下面接的是什么。它真正需要的，是能访问 runtime logs，好让自己从里面扫描 patterns，以及一条可以通过 A2A 发布或抓取 Capsules 的 HTTP connection。
Q：GEP 和 knowledge base、prompt library 到底有什么不同？
Knowledge base 存的是信息。Prompt library 存的是指令。GEP assets 两者都不是——Capsule 不是“关于某个解法的描述”，它本身就是解法。它会连同 environment fingerprint、validation steps、confidence score 和 audit trail 一起出现。当 agent fetch 一个 Capsule 时，它继承的是一条已经验证过的 execution path，而不是拿回一段还要自己再推理的材料。
Previous Posts:
