一场关于"接口"的路线之争

2026 年的 AI 应用层，正在发生一场静默但深刻的路线之争。争论的焦点不是模型谁更强，而是一个看似古老的问题：AI 应该如何与外部世界交互？

Anthropic 押注 MCP，想把 AI 接入工具的方式标准化为"AI 世界的 USB-C"。Perplexity 却在 Ask 2026 大会上公开宣布放弃 MCP，回归 CLI 和传统 API，理由是上下文消耗过高、认证机制笨重。与此同时，一个名为 OpenClaw（中文社区称"龙虾"）的框架正在另一条轨道上生长——它不纠结于单一 Agent 如何接工具，而是专注于让多个 Agent 在本地环境中像团队一样协作。

这三条路线——CLI、MCP、龙虾 Agent——表面上是技术选型之争，本质上是三种不同的世界观：

• CLI 派相信：模型已经知道怎么用命令行，别整新的抽象层。
• MCP 派相信：没有标准就没有生态，必须统一协议。
• 龙虾派相信：单个 Agent 接工具是小事，多个 Agent 怎么协作才是大事。

理解它们的分歧，比判断"谁更好"更有价值。因为答案从来不是"某一个赢了"，而是"不同场景需要不同的握手方式"。

---

MCP：理想主义的协议层

MCP（Model Context Protocol）的设计初衷非常宏大。在 MCP 出现之前，每个 Agent 框架定义自己的工具调用格式，每个工具提供方需要为 LangChain、AutoGen、Claude 分别写适配代码。Anthropic 看到了这种碎片化的低效，于是提出了一个统一标准：所有工具都包装成 MCP Server，所有 Agent 都通过 MCP Client 发现、调用、消费工具。标准化的发现机制、统一的认证流程、一致的上下文格式。

这套逻辑在纸面上无懈可击。如果全世界都接 MCP，Agent 生态会像 USB-C 生态一样繁荣——任何新工具只要实现一个 MCP Server，就能被所有 MCP 兼容的 Agent 调用。

但 MCP 在实践中遇到了几个硬核问题：

第一，上下文吞噬。 MCP 的协议开销极大。Perplexity 的实测数据显示，MCP 模式可以消耗高达 72% 的上下文窗口。对于一个 128K 上下文的模型，这意味着近九成的 token 预算被协议元数据、工具描述、Schema 定义吃掉，留给实际任务推理的空间所剩无几。在上下文就是生产力的时代，这种开销几乎是致命的。

第二，认证与安全的笨重。 MCP 要求工具提供方实现一套标准化的认证机制，但对于企业内部工具、本地脚本、临时性命令来说，这种标准化反而成了负担。不是每个工具都值得被包装成一个常驻的 MCP Server。有时候你只需要让 AI 执行一行 git log，却要先启动一个 MCP 服务、配置权限、描述 Schema——杀鸡用了牛刀。

第三，生态惯性的阻力。 虽然 Anthropic 在 2025 年底将 MCP 捐赠给了 Linux 基金会，但真正的大规模采纳并没有发生。原因很现实：现有的大量工具和 API 已经运转良好，重写为 MCP Server 的动力不足。标准制定者常常高估了"统一的好处"，低估了"迁移的成本"。

MCP 没有失败，但它暴露了一个永恒的矛盾：标准化是生态成熟的终点，而不是起点。 在生态尚未形成共识的时候强行推行协议，往往事倍功半。

---

CLI：实用主义的回归

与 MCP 的理想主义形成鲜明对比的，是 CLI 路线的务实甚至朴素。

CLI 的核心假设非常简单：大语言模型在训练过程中已经"阅读"了海量的命令行操作、Shell 脚本、系统文档、Stack Overflow 问答。它知道 grep 是干什么的，知道 curl 怎么调 API，知道 docker run 有哪些参数。既然如此，为什么不直接让模型生成命令行指令，然后通过标准输入输出与外部世界交互？

这个思路的优雅之处在于零额外抽象。不需要新的协议、不需要新的适配层、不需要工具方做任何改造。AI 生成命令，操作系统执行命令，结果通过 stdout/stderr 返回给 AI。这是计算机科学中最古老、最稳定、最普适的接口形态。

2026 年，这种朴素正在重新被认可。斯坦福 CRFM 的研究显示，基于 CLI 的智能体相比 MCP 模式，上下文占用减少 62%，任务成功率提升 28%，故障率下降 41%。数字背后是一个直观的事实：命令行是人类与计算机交互的最小公分母，也是 AI 与计算机交互的最小公分母。

但 CLI 路线也有它的天花板：

第一，非结构化输出的解析成本。 命令行工具的输出格式千差万别——有的是人类可读的表格，有的是 JSON，有的是纯文本日志。AI 需要额外的推理成本来解析这些输出，而 MCP 的 Schema 在设计时就保证了结构化。

第二，状态管理的缺失。 CLI 是无状态的。每次执行都是独立的进程，没有内置的会话管理、错误重试、权限缓存机制。复杂的工具交互（比如需要先登录、再查询、再操作）在纯 CLI 模式下需要 AI 自己维护状态，增加了推理负担。

第三，安全边界的模糊。 让 AI 直接执行系统命令，本质上是在给它 root 权限（或接近 root 的权限）。一个被提示词注入攻击的 MCP 调用最多泄露一个工具的访问范围，而一个被注入的 CLI 命令可能直接 rm -rf /。

CLI 不是银弹，但它是当前阶段性价比最高的默认选项。当 MCP 还在争论 Schema 版本的时候，CLI 已经帮你把活干完了。

---

龙虾 Agent（OpenClaw）：架构层的第三条路

如果说 MCP 和 CLI 争论的是"单个 Agent 如何接工具"，那么 OpenClaw（龙虾）回答的是另一个问题：当多个 Agent 需要协作时，整个系统应该如何组织？

OpenClaw 由奥地利开发者 Peter Steinberger 在 2025 年底创建，其核心理念可以概括为两个词：本地优先和模型无关。

本地优先意味着 OpenClaw 不是云端 SaaS，而是一个运行在你本地机器上的 Agent 框架。你的数据、你的工具、你的环境变量，都不需要上传到第三方服务器。这在企业级场景中有巨大吸引力——金融、医疗、法律等对数据隐私敏感的领域，无法接受把核心业务数据送到云端 Agent 平台。

模型无关意味着 OpenClaw 不绑定任何特定的大模型。你可以接 Claude、GPT、Gemini、本地 Llama，甚至可以在同一个任务链条中混用不同模型——让最强的模型做决策，让最快的模型做执行，让本地模型做隐私敏感的处理。

OpenClaw 的架构设计很有特色，采用Gateway + Agent + Channels 三层解耦：

• Gateway 层是系统的神经中枢，一个常驻的 WebSocket 服务，负责消息路由、调度决策、状态同步。它是"单一事实来源"，所有 Agent 的协作都通过它协调。
• Agent 层是实际干活的单元。每个 Agent 有独立的角色定义、工具集、记忆上下文。一个 Agent 可以是"代码审查员"，另一个是"测试执行者"，第三个是"文档撰写者"。
• Channels 层负责与外部世界通信——飞书、钉钉、Telegram、Slack、邮件系统，甚至是本地文件系统。Channels 把外部输入翻译成 Agent 能理解的指令，把 Agent 的输出推送到外部系统。

这种架构的野心不在于"让 AI 能调用工具"（这件事 CLI 和 MCP 都能做），而在于让多个 AI 像人类团队一样分工协作。Gateway 相当于项目经理，Agent 相当于团队成员，Channels 相当于对外沟通的窗口。

龙虾 Agent 的独特价值在于它不把"接工具"当作核心问题，而是把"组织智能"当作核心问题。 在 MCP 和 CLI 还在争论接口格式的时候，OpenClaw 已经假设"接工具"这件事已经有了足够多的解决方案，真正需要解决的是"如何 orchestrate（编排）多个智能单元"。

但 OpenClaw 也有它的局限：

第一，部署和运维成本。 本地优先意味着你需要自己维护 Gateway 服务、管理 Agent 生命周期、处理 Channels 的配置。对于个人开发者或小团队，这种 overhead 可能超过收益。

第二，社区和生态的稚嫩。 相比 MCP 的 Linux 基金会背书、CLI 的 ubiquitous 存在，OpenClaw 仍然是一个相对年轻的项目，插件生态、最佳实践、企业级案例都在积累中。

第三，与现有工作流的融合摩擦。 把 OpenClaw 引入一个已经运转良好的团队，需要重新定义工作流——哪些任务交给人类、哪些交给 Agent、多个 Agent 之间如何交接。这不是技术问题，而是组织变革问题。

---

三者对比：不是优劣，是层次

把 CLI、MCP、龙虾 Agent 放在一起比较"孰优孰劣"，本身就是一个有点误导的命题。因为它们不在同一个抽象层次上：

维度	CLI	MCP	龙虾 Agent (OpenClaw)
抽象层次	接口层（怎么调用）	协议层（怎么通信）	架构层（怎么组织）
核心问题	如何让 AI 执行命令	如何让 AI 统一发现工具	如何让多个 AI 协作
优势场景	快速原型、系统运维、脚本自动化	工具生态标准化、SaaS 集成	企业级多 Agent 协作、隐私敏感场景
上下文效率	高（占用少 62%）	低（消耗可达 72%）	中（取决于 Gateway 路由效率）
工具改造成本	零（现有 CLI 工具直接用）	高（需实现 MCP Server）	中（需配置 Channels 适配）
安全模型	依赖系统权限控制	协议内置认证机制	本地隔离 + 权限白名单
协作能力	单 Agent 单命令	单 Agent 多工具	多 Agent 多角色协作
生态成熟度	极高（四十年历史）	中（Linux 基金会背书）	低（新兴项目）

从这个对比可以看出，三者之间不是替代关系，而是互补关系。

一个成熟的 AI 应用架构，很可能会同时使用这三种技术：

• 用 MCP 接入那些已经被标准化封装的外部服务（比如数据库、GitHub、Slack）——因为这些服务值得被标准化。
• 用 CLI 处理那些临时性、探索性、一次性的系统操作（比如日志分析、文件批量处理、环境检查）——因为不需要为一次性操作写 MCP Server。
• 用 龙虾 Agent 编排那些需要多角色协作的复杂任务（比如"需求分析 → 代码实现 → 测试验证 → 文档更新"的完整开发流程）——因为这不是单一 Agent 能完成的。

---

深层逻辑：标准化、原子化与组织化

这场路线之争的底层，其实是三种对"AI 如何融入现有世界"的不同回答：

MCP 代表的是"标准化"思维。 它相信，AI 与世界的交互应该像互联网一样，有一套统一的协议、统一的数据格式、统一的发现机制。这种思维在技术史上反复出现——TCP/IP、HTTP、REST、GraphQL，每一次标准化都催生了巨大的生态。但标准化有一个前提：生态已经大到需要统一。在 AI Agent 的早期阶段，生态可能还不够大。

CLI 代表的是"原子化"思维。 它不相信需要新的协议层，因为计算机世界最原子的接口——进程、标准输入输出、退出码、环境变量——已经存在了四十年，而且工作得很好。AI 应该学会使用这些原子接口，而不是在它们之上再盖一层。这种思维的优势是务实和快速，劣势是缺乏结构——当交互变得复杂时，纯 CLI 会暴露出力不从心的一面。

龙虾 Agent 代表的是"组织化"思维。 它不纠结于单个接口的形态，而是关注多个智能体如何形成有效的组织结构。这种思维假设：未来的 AI 应用不是"一个超级聪明的 Agent 做所有事"，而是"一群专门化的 Agent 像团队一样协作"。这种思维跳出了"接口之争"，直接把问题提升到了"系统架构"的层面。

这三种思维没有对错，只是时间尺度和问题域不同：

• 短期（今天到明年）：CLI 最实用，因为它现在就能工作，不需要任何人配合。
• 中期（两到三年）：MCP 可能在特定生态里成为事实标准，但不会一统天下。
• 长期（三到五年）：组织化思维可能是终极答案——因为当 AI 足够普及时，"如何编排它们"会比"如何接入它们"重要得多。

---

给技术选型的建议

如果你今天站在技术选型的十字路口，可以根据以下逻辑做判断：

选 CLI，如果：

• 你的场景以系统运维、脚本自动化、开发工具链为主
• 你需要快速原型验证，不想花时间写适配层
• 你的团队已经有大量现成的 CLI 工具和脚本
• 你对上下文效率敏感（比如使用长上下文模型的成本很高）

选 MCP，如果：

• 你正在构建一个需要接入大量外部 SaaS 服务的 Agent 平台
• 你希望工具提供方能自助接入，不需要你写适配代码
• 你的场景对结构化输入输出有强需求（比如数据库查询、API 调用）
• 你愿意承受上下文开销来换取生态标准化

选龙虾 Agent（OpenClaw），如果：

• 你的场景需要多个 Agent 协作完成复杂任务（如完整软件开发流程）
• 数据隐私是硬性要求，不能接受云端处理
• 你希望在一个系统中混用多个不同厂商的模型
• 你的组织愿意投入精力重新定义人机协作的工作流

最重要的建议：不要只选一个。 未来的 AI 应用架构，大概率是"CLI 处理原子操作 + MCP 接入标准化服务 + 龙虾 Agent 编排复杂流程"的混合形态。能根据场景灵活切换接口形态的系统，才是最鲁棒的系统。

---

结语

CLI、MCP、龙虾 Agent 的争论，某种程度上是 AI 应用层从"玩具"走向"工程"的必经阶段。每一种路线都在探索同一个问题的不同侧面：当 AI 走出聊天框、开始操纵真实世界时，它应该通过什么样的"手"去触碰这个世界？

CLI 给了它一双粗糙但万能的手——能抓任何东西，但不够精细。
MCP 给了它一双标准化的假肢——接入顺滑，但需要先改造世界。
龙虾 Agent 给了它一个团队——每只手只做一件事，但合在一起能完成复杂的手术。

真正的答案，可能不是选择哪一种手，而是学会在不同的时候用不同的手。

毕竟，人类也不是只用一种工具与世界交互的。我们用命令行写脚本，用 USB-C 接设备，用团队协作完成大项目。AI 为什么不可以呢？