夜雨聆风
本文通过一系列递进式的技术追问，剖析 OpenClaw 底层引擎 Pi 的极简主义哲学、与 MCP 协议路线的根本分歧，以及"养龙虾"隐喻背后被掩盖的技术张力。
OpenClaw 是一款开源的本地优先 AI 智能体框架，因其龙虾图标被中文社区称为"小龙虾"。它不同于 ChatGPT、Claude 等对话式 AI——OpenClaw 能在用户自己的设备上 7×24 小时运行，通过 WhatsApp、Telegram、Slack 等消息平台接收指令，自主执行文件操作、浏览器控制、API 调用等任务，并在多次交互中积累记忆。自 2026 年 1 月发布以来，OpenClaw 在 GitHub 上获得了超过 16 万颗星，引发了一场"养龙虾"的全民热潮。
但在热潮之下，OpenClaw 的架构设计中隐藏着一场深刻的技术路线之争：它的底层引擎 Pi 坚持极简主义，故意拒绝了业界流行的 MCP（Model Context Protocol）协议；而它的社区生态却在不自觉地重新发明一套非正式的标准化体系。这种张力值得深入剖析。
一、Pi Agent：OpenClaw 的底层引擎
OpenClaw 中的 Pi agent 并不是某个特定功能角色的 agent，而是 OpenClaw 底层的核心编码代理引擎——整个 OpenClaw 就是建构在 Pi 之上的。
1.1 Pi 的技术架构
Pi 是由 Mario Zechner（libGDX 游戏框架的创建者）编写的一个 TypeScript 工具包，用于构建 AI Agent。它是一个由多个包分层组成的 monorepo：
┌─────────────────────────────────────────┐│ Your Application ││ (OpenClaw, a CLI tool, a Slack bot) │├────────────────────┬────────────────────┤│ pi-coding-agent │ pi-tui ││ Sessions, tools, │ Terminal UI, ││ extensions │ markdown, editor │├────────────────────┴────────────────────┤│ pi-agent-core ││ Agent loop, tool execution, events │├─────────────────────────────────────────┤│ pi-ai ││ Streaming, models, multi-provider LLM │└─────────────────────────────────────────┘• pi-ai：处理跨供应商的 LLM 通信 • pi-agent-core：负责带工具调用的 agent 循环 • pi-coding-agent：提供完整的编码代理（内置工具、会话持久化和可扩展性） • pi-tui：提供终端 UI
1.2 OpenClaw 如何嵌入 Pi
OpenClaw 使用 Pi SDK 将 AI 编码代理嵌入其消息网关架构中。它不是将 Pi 作为子进程启动，而是直接导入并通过 createAgentSession() 实例化 Pi 的 AgentSession。这种嵌入式方式让 OpenClaw 能完全控制会话生命周期和事件处理，并注入自定义工具（消息、沙箱、频道特定操作等）。
在 OpenClaw 的整体架构中，Gateway 是控制平面，嵌入式的 Pi agent 是其核心执行引擎，与 CLI、WebChat UI、macOS app、iOS/Android 节点共同构成完整的客户端生态。
1.3 Pi 的设计哲学
Pi 只有四个核心工具：read、write、edit、bash。整个系统提示不到 1000 tokens。Mario Zechner 的理念是："如果我不需要它，它就不会被构建。"
二、Pi 为什么故意不支持 MCP
Pi 不支持 MCP 是 Mario Zechner 深思熟虑的架构决策，而非偷懒。这个决策可以从四个层面来理解。
2.1 上下文窗口的"Token 税"
这是最直接的技术理由。像 Playwright MCP（21 个工具，13,700 tokens）或 Chrome DevTools MCP（26 个工具，18,000 tokens）这样的热门 MCP 服务器，会在每个会话中将全部工具描述注入到上下文中——在你开始工作之前，上下文窗口就被占用了 7-9%。而其中很多工具在当前会话中根本不会用到。
Pi 的替代方案是渐进式披露（progressive disclosure）：构建带有 README 文件的 CLI 工具。Agent 在需要时才读取 README，仅在必要时支付 token 成本。然后通过 bash 调用这些工具。这种方式可组合、易扩展、token 高效。
2.2 缓存失效与会话连贯性
MCP 的工具定义需要在会话开始时加载到系统上下文，成为 LLM KV cache 前缀的一部分。一旦你中途增删工具，前缀变化会导致整个缓存失效；更糟的是，模型可能在前半段会话中已经"学会了"某个工具的行为模式，突然更换工具定义会让模型对先前调用产生困惑。
Pi 的工具只有四个，永远不变。Cache prefix 始终稳定。当 agent 需要调用天气 API 时，它不是通过"注册一个新工具"来做，而是写一个脚本然后 bash 执行。从模型的视角看，它始终在用同一个 bash 工具。
2.3 哲学层面："代码即协议"
Mario 的论点是："所有前沿模型都已经经过大量 RL 训练，所以它们天生就理解编码代理是什么。" 模型知道 bash 是什么，知道文件怎么运作。添加专门的工具只是在系统提示中增加 token，却没有增加实际能力。
2.4 自我扩展而非下载扩展
Pi 的整个理念是：如果你想让 agent 做它还不会做的事情，你不用去下载扩展或技能——你让 agent 自己扩展自己。Armin Ronacher（Flask 作者）以自己的实践为例：他用 agent 自己生成的 skill 完全替代了所有浏览器自动化的 CLI 或 MCP，直接使用 CDP 协议——不是因为替代方案不好，而是因为这样做更自然。
2.5 实例：Pi 如何从零回答"今天天气如何"
上面的设计哲学可能还是偏抽象，下面用一个具体场景来还原 Pi Agent 面对"今天台北天气如何"时实际会发生什么。请记住：Pi 没有天气工具，没有 MCP，没有任何预装的 API 集成，只有 read、write、edit、bash 四个工具。
首次调用：从零构建工具
第 1 步：用户提问
用户：今天台北天气如何？第 2 步：Agent 检查是否有现成工具
Agent 内部推理："我没有天气工具，但我可以用 bash 调用网络获取天气信息。先看看有没有之前写过的脚本。"
# Agent 调用 bash 工具ls ~/tools/weather* 2>/dev/null没找到。进入构建流程。
第 3 步：Agent 检查可用的 API 凭证
# Agent 调用 bash 工具cat ~/.env | grep WEATHER找到 OPENWEATHER_API_KEY=abc123。
第 4 步：Agent 编写天气查询脚本
Agent 调用 write 工具，创建 ~/tools/weather.py：
import requests, sys, oscity = sys.argv[1] if len(sys.argv) > 1 else "Taipei"api_key = os.environ.get("OPENWEATHER_API_KEY")url = f"https://api.openweathermap.org/data/2.5/weather?q={city}&appid={api_key}&units=metric&lang=zh_tw"resp = requests.get(url)data = resp.json()print(f"城市: {data['name']}")print(f"天气: {data['weather'][0]['description']}")print(f"温度: {data['main']['temp']}°C (体感 {data['main']['feels_like']}°C)")print(f"湿度: {data['main']['humidity']}%")print(f"风速: {data['wind']['speed']} m/s")第 5 步：Agent 执行脚本并回复
# Agent 调用 bash 工具python ~/tools/weather.py Taipei返回：
城市: Taipei天气: 多云温度: 28.3°C (体感 31.5°C)湿度: 72%风速: 3.1 m/sAgent 组织语言回复："台北现在多云，气温 28.3°C，体感温度偏高约 31.5°C，湿度 72%，有轻微的风。"
首次调用总计 3-4 次 LLM 推理，耗时约 10-15 秒。
后续调用：摊销生效
下次用户问"东京天气如何"，Agent 记得自己写过天气脚本，直接执行：
python ~/tools/weather.py Tokyo1 次推理 + 1 次 bash 调用，耗时与 MCP 路径相当，但不付任何 token 税。
进一步进化：正式化为 Skill
如果用户频繁问天气，Agent 可能会主动把工具升级为一个正式的 Skill，创建配套的 SKILL.md 文档：
# Weather Skill## 用途查询全球城市的实时天气信息。## 依赖- Python 3 + requests 库- 环境变量 OPENWEATHER_API_KEY## 用法python ~/tools/weather.py <城市名>## 示例- `python ~/tools/weather.py Taipei` — 查询台北天气- `python ~/tools/weather.py "New York"` — 查询纽约天气这个 SKILL.md 就成了 agent 自己的"文档"。下次 compaction 后即使忘了具体脚本路径，只要读到这个 skill 文件就能恢复记忆。
三条路径的完整对比
┌─────────────────────────────────────────────────────────┐│ MCP 路径 ││ ││ 用户："台北天气" ││ ↓ ││ LLM 看到工具列表中有 weather_fetch ││ ↓ ││ 生成 tool_call: weather_fetch(city="Taipei") ││ ↓ ││ Gateway 执行 MCP 调用 → 返回 JSON ││ ↓ ││ LLM 组织回复 ││ ││ 总计: 1 次推理，确定性，每次都付 token 税 │└─────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────┐│ Pi 路径（首次） ││ ││ 用户："台北天气" ││ ↓ ││ LLM 推理：我没有天气工具，用 bash 解决 ││ ↓ ││ bash: ls ~/tools/weather* → 没找到 ││ ↓ ││ bash: cat ~/.env | grep WEATHER → 找到 key ││ ↓ ││ write: ~/tools/weather.py → 创建脚本 ││ ↓ ││ bash: python ~/tools/weather.py Taipei → 拿到结果 ││ ↓ ││ LLM 组织回复 ││ ││ 总计: 3-4 次推理，首次慢（10-15 秒），但工具被持久化 │└─────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────┐│ Pi 路径（后续） ││ ││ 用户："东京天气" ││ ↓ ││ LLM 推理：上次写过天气脚本 ││ ↓ ││ bash: python ~/tools/weather.py Tokyo → 拿到结果 ││ ↓ ││ LLM 组织回复 ││ ││ 总计: 1 次推理，跟 MCP 一样快，且不付 token 税 │└─────────────────────────────────────────────────────────┘这个例子完整展示了 Pi 所说的"代码即协议"——不需要预先注册任何工具，模型用 bash 和文件系统作为万能接口，自己构建所需的一切。代价是首次调用的多轮开销，收益是后续调用零 token 税，并且工具完全按自己的需求定制。
三、MCP 与"代码即协议"的工程权衡
Pi 的设计哲学在实际工程中面临一系列具体挑战。以下是四个关键问题的深入分析。
3.1 "渐进式披露"的延迟问题
从 2.5 节的天气实例可以直观看到：Pi 的首次调用需要 3-4 次 LLM 推理（检查工具→检查凭证→写脚本→执行），耗时 10-15 秒；而 MCP 路径只需 1 次推理 + 1 次 API 调用，2-5 秒即可完成。
Pi 路径存在摊销效应——首次调用后工具被持久化，后续调用与 MCP 一样快且不付 token 税。但这个摊销在实践中不那么可靠，原因有三：
1. Compaction 导致遗忘：会话压缩后，agent 可能不记得工作区里有 weather.sh，于是又从头写一遍。2. 跨会话不连续：在 Telegram 会话里写的脚本，换到 Discord 的另一个会话时，新会话的上下文里没有这个信息。 3. 长尾工具无法摊销：如果某个 API 一个月才调用一次，每次都要重新"学习"怎么用，"首次成本"就几乎是每次成本。
生产中的实际策略往往是混合的：高频调用的工具预先注册，低频的让 agent 按需构建。
3.2 生产中使用 MCP 如何解决 Token 税
MCP 的 token 税问题在生产中有几种缓解策略：
• 工具路由与动态加载：在 Gateway 层做意图分类，只向 LLM 注入当前轮次需要的工具子集。 • 工具描述压缩：维护精简版的 tool schema，把几百 token 的描述压到几十 token。 • 多轮工具注入：第一轮只注入一个"工具发现"元工具，让模型先决定需要什么，再在后续轮次动态注入。
但这些方案都在给 MCP 打补丁，增加了系统复杂度。Pi 的 CLI + README 方式天然就是按需加载的。
3.3 非本地标准服务的调用
对于简单的 REST API 调用（天气、汇率、新闻），Pi 的方式完全可行——模型可以自由组合 curl、jq、Python 等工具。
对于需要 OAuth 流程、WebSocket 长连接、复杂认证的服务（Google Calendar、Slack、数据库连接池），Pi 的方式就显得吃力了。MCP 的价值恰恰在于它封装了这些连接管理的复杂性。这也是为什么 OpenClaw 虽然底层用 Pi，但在 Gateway 层通过 mcporter 引入了 MCP 支持。
更准确的说法是：Pi 不是说"永远不需要标准化的服务协议"，而是说"这个协议不应该以工具定义注入的方式实现，而应该以可执行代码的方式存在"。
3.4 "自我扩展"在生产环境的可行性
在个人开发者场景下可行，在团队/企业生产环境下有严重局限。
可行的场景包括个人开发者的私人助手、探索性任务、agent 为自己构建的内部工具。
不可行的维度包括：
• 可审计性：MCP 有标准化的调用日志格式，agent 自己写的脚本每次写法可能不同。 • 可复现性：Agent 今天和明天可能写出完全不同版本的工具脚本。 • 安全边界：MCP 可以在协议层面做权限控制，agent 自写脚本只能依赖操作系统沙箱。 • 团队协作：10 个人的 agent 各自构建了一套工具，互不兼容、无法共享。 • 质量保证：Agent 生成的代码可能有 bug，每次用临时脚本处理客户数据风险极高。
四、社区工具集成——正在重新发明的"非正式 MCP"
4.1 一个深层矛盾
Pi 的原始哲学是：不下载扩展，不用社区 skill，agent 自己为自己构建工具。但 OpenClaw 的现实是：它有 53+ 官方 skill，有 ClawHub skill 注册中心（托管了 2 万多个技能），社区在持续贡献工具。
每个 skill 本质上就是一份"如果用户要做 X，你应该按照这个步骤调用这些 API"的预定义协议。这跟 MCP 的工具描述在功能上是等价的，只是形式不同：
4.2 区别不是无意义的
灵活性上，skill 方式更灵活。因为它是自然语言描述的，agent 可以"理解"意图后自由发挥。如果 API 升级了，agent 有时可以自行适应。
确定性上，MCP 更好。Schema 是精确的，工具调用的输入输出格式是确定的，可以做类型检查、参数校验。
维护成本上，skill 的维护门槛更低（只是改文档），但质量也更难保证。
4.3 不可避免的标准化引力
OpenClaw 社区正在自发地重新发明一个非正式的 MCP——只不过用了不同的技术栈。当用户规模从一个人扩展到数万人时，标准化是不可避免的引力。这不是 Pi 设计的失败，而是自然的演化。
Pi 和 MCP 的分歧不是"要不要有协议"，而是"协议应该存在于哪一层"。Pi 认为操作系统本身（文件系统 + bash + 网络）就是最好的协议层。MCP 认为需要在应用层再建一个专门的协议。OpenClaw 同时使用两者，本身就是最好的证明。
五、"养龙虾"——隐喻背后的技术张力
5.1 "养"的多层含义
"养龙虾"中"养"字的第一层含义是记忆积累——OpenClaw 可以长期记忆用户使用记录，持续理解用户行为偏好，"越用越懂用户"。它不一样于传统大模型每次对话都从零开始，而是给了一套机制，让用户在日常聊天中跟 AI 不断沟通，积累记忆，定义人格和习惯。慢慢"养"出来的，是一个有记忆、有作息、有专长且可主动执行的个人超级助手。
第二层含义是能力进化——从"被动等待"到"主动服务"，从"普通工具"到"自我进化"。
5.2 Agent 自建 Skill 的实践
社区中确实存在让 agent 自己构建 skill 的趋势。ClawHub 前百下载量的 Skill 中，Agent 自进化类就占了 10%。核心工作流是：
1. self-improving-agent：赋予 Agent 主动规划的能力，随着交互次数增加，自动复盘历史、优化执行流程。 2. find-skills：让 Agent 自动在 ClawHub 库中搜索并推荐安装对应的插件。 3. skill-creator：创建自己的专属技能。 4. automation-workflows：把多个技能组合成工作流。
"水产市场"这样的社区更进一步：本地 OpenClaw 连上后，进化手册会收集过去所有对话，看看有什么能力缺口，还会复盘社区的最新更新。贡献家则定时复盘对话，拆解成不同的资产，去掉敏感信息后发布给社区。
5.3 两种"养"的分裂
"养"这个隐喻在社区中实际分化成了两种截然不同的实践：
Pi 原教旨路线：agent 为自己编写工具，不从外部下载，完全自主进化。Mario Zechner、Armin Ronacher 的实践属于这一类。这种"养"更像是养一个学徒，从零开始培养，它构建的每个工具都是量身定做的。
大众社区路线：给 agent 安装各种 skill，配置各种连接，调教行为规范（SOUL.md、AGENTS.md），让它在工作流中越来越好用。这种"养"更像是养一个员工——你培训它、给它工具、给它规章制度。Agent 的能力增长主要来自人类的干预，而非自主构建。
5.4 被掩盖的门槛差异
Pi 的极简主义在个人工作流中完美运作，但社区需要可分享、可复用、可信任的组件。"养龙虾"的温暖隐喻某种程度上掩盖了这个巨大的技术门槛差异——对于 99% 的用户来说，"养"更多是配置和安装，只有极少数技术用户在实践真正的"自我进化"路线。
六、结论
回顾整条技术链路，几个核心洞见浮现出来：
1. Pi 的极简主义是对的——在特定尺度上。四个工具 + 不到 1000 tokens 的系统提示，证明了一个足够聪明的模型不需要复杂的工具协议。但这个结论的适用范围是个人开发者级别的使用。 2. MCP 和 Pi 不是在回答同一个问题。Pi 回答的是"编码代理需要多少内置复杂性"——答案是越少越好。MCP 回答的是"异构系统之间如何标准化通信"——这是一个分布式系统的问题。MCP 的价值不在于给模型"更多能力"，而在于给人（开发者、运维、安全团队）更多的可控性和可见性。 3. 标准化是不可避免的引力。OpenClaw 社区通过 ClawHub 和 Skill 体系正在自发地重新发明一个非正式的 MCP。当工具从一个人的私人助手扩展到数万用户的社区平台时，预定义的交互契约不可避免。 4. "养龙虾"的隐喻既精准又有误导性。精准在于它捕捉了 agent 与用户共同成长的本质；误导在于它暗示了一种人人可及的有机过程，实际上大多数用户的"养"是配置驱动的，而非自主进化的。
最终，OpenClaw 的工程实践本身就是最好的答案——它同时拥抱了 Pi 的极简内核和 MCP 生态的标准化接口，没有把这当作一个非此即彼的选择。这或许才是真正务实的 agent 架构思路：在内核保持极简，在边界拥抱标准。