嗨，我係 Lena。前排我聽到一位 podcast 主持人拋出一句幾戳中我嘅話：「真正嘅瓶頸唔係將工具連起身，而係 agent 一次又一次重學同樣嘅教訓。」
呢句真係打到我心口。喺我自己做嘅實驗入面，每一次「New Session」都好似由零開始。啲 agents 帶唔走任何「經驗」，連五分鐘前衰喺邊都記唔住。
AI 係咪本身就係咁？唔係——呢個其實係設計上嘅缺口。我最近一路喺度研究一個框架，想睇下點樣補返呢個問題，而入面啱啱好有三層：MCP、CLI 同 GEP。 以下就係我點樣一步步將佢哋拼埋一齊。
點解 agent stack 會有分層問題
而家好多做 AI agent 嘅團隊，通常都已經好識處理兩件事：點樣令 agent 連到工具，同埋點樣高效率咁調用呢啲工具。佢哋攞唔到嘅，反而係第三樣會隨時間 一路累積 嘅嘢。
你可以咁樣諗，件事就會清楚啲。一個 agent stack 其實要處理三類唔同嘅問題：
Connection —— agent 係唔係搵得到、連得到自己需要嘅工具？
Invocation efficiency —— 佢可唔可以唔將成個 context window 都燒喺 schema overhead 上，就調用到啲工具？
Experience retention —— 當 agent 真係摸清一件事之後，嗰份知識會唔會留得低？
頭兩個問題，喺而家嘅生態入面其實都已經有算係合理嘅解法。第三個問題——experience retention——先至係幾乎所有標準 setup 都會靜靜地散開嘅地方。agent 解完一個問題，session 完咗，卻冇任何嘢被保存成可重用嘅形式。下一次再跑，仲係同一個問題，仲係同一輪 trial-and-error。乜都累積唔到。
呢個就係所謂嘅分層問題。下面講嘅三層，啱啱好各自處理呢三件事入面嘅其中一件。
Layer 1 — MCP：將 Tool Connection 標準化
Model Context Protocol（MCP）係 Anthropic 喺過去兩年提出嘅 open standard，用嚟將 AI agents 連到外部工具同 data source。大家最常拎嚟比喻嘅，就係 USB-C 插口——唔再為每一對工具同 agent 單獨做 custom integration，而係用同一個標準接口。喺呢一層上面，佢真係做得幾好。
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，等模型直接對住 SDK 寫 code，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 都講過呢種模式：model 可以「按需要去讀 tool definitions，而唔係一開始就一次過讀晒」，靠嘅係一種 search-and-load 方法，令 active context 保持輕身。呢個有時就叫 progressive discovery——agent 係跟住任務需要，慢慢建立對 tools 嘅認識，而唔係一下子全部塞晒入去。
CLI 會撞到邊度
CLI 喺 invocation efficiency 呢件事上確實做得幾好。但佢解決唔到嘅，啱啱都係 MCP 冇解決到嗰部分：statelessness 同 experience retention。一個基於 CLI 嘅 agent，可能終於摸到某個唔穩定 API 嘅正確 retry strategy，又或者搵到處理複雜 file operation 時正確嘅 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），所以佢哋防篡改，而且 version stable。呢點好重要：你繼承嘅唔係「有一次啱啱好 work 嘅嘢」，而係一個可驗證、可審計嘅 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 將呢份解法 fetch 返嚟，再直接套用：
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 嘅具體建議：唔係估，而係驗證過嘅解法。
三層係點樣一齊運作
下面呢個具體場景，會比較清楚睇到 layers 之間點樣 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 responses 上用帶 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 flows，或者 dynamic discovery 真係重要嘅環境，佢就會開始失靈——而呢啲正正就係 MCP 值回自己 overhead cost 嘅地方。
將 GEP 當成 logging system，就真係完全捉錯重點。Logs 屬於 observability。GEP 係一套相當嚴格嘅 agent evolution standard——佢定義咗 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 去發布或者 fetch 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:
