终端即接口

终端即接口是 OpenClaw 与 AI 行业主流智慧正面冲突的那条架构主张：不要为智能体建造标准化的工具协议层，直接给它一个终端。[^1]¹

这是 2026 年智能体架构里最锋利的一次路线分歧，也是一次典型的"通用性 vs 结构化"的老争论在新语境下的复现。

争论的两边

当时 Anthropic 与 OpenAI 等主要玩家正在推动 MCP（模型上下文协议）——一种让 AI 模型与外部工具和数据交互的标准化方式，旨在安全、结构化和可扩展，本质上是"为 AI 设计的 API"。彼得斯坦伯格 的态度是完全拒绝：**"MCP 是垃圾，无法规模化。"**[^1]¹

论据：大模型是 CLI 的母语使用者

斯坦伯格的论点扎根于计算历史的基石——Unix。命令行界面五十年来一直是计算的通用语言：基于文本、可通过管道组合、有详尽的文档记录。而大型语言模型是在整个互联网上训练的，包括数十亿行日志和文档。[^1]¹

它们不需要特殊的协议来理解如何使用 curl、grep 或 git；它们已经知道了。

由此得出那个被称为"只管跟它说"的方法：如果智能体需要控制 Sonos 音箱，它不需要什么"Sonos MCP 服务器"，它只需要一个 Sonos 的 CLI 工具——智能体可以运行 sonos --help，读取输出，然后自己弄清楚怎么操作。

graph TD
    subgraph MCP 路线
    A1[新工具] --> A2[写 MCP 适配器]
    A2 --> A3[模式验证/结构化]
    A3 --> A4[智能体可用]
    end
    subgraph 终端即接口
    B1[新工具<br/>只要有 CLI] --> B2[智能体运行 --help]
    B2 --> B3[读输出自行推断用法]
    B3 --> B4[立即可用]
    end
    B4 --> C[现有命令行生态<br/>瞬间成为技能商店]

这条路线最大的杠杆在于存量：它把已经存在了几十年的命令行工具生态，零成本地转化成了智能体的能力库。

为什么这场分歧值得被记住

这不是一次工具偏好之争，而是训练数据决定接口设计的第一个清晰案例。传统软件接口设计问的是"什么结构最清晰"；这里问的是"被调用者的先验知识里已经有什么"。当调用者是一个读过整个互联网的模型时，最好的接口可能不是最新最规范的那个，而是文档最多、被写得最烂熟的那个。

这条推理与 j空间 揭示的"内部结构不是被设计的、是长出来的"是同一种思路的两个方向：一个说模型的内部长在训练数据上，一个说模型的外部接口也应该长在训练数据上。

代价：便利即攻击面

终端即接口的每一条优点都有对应的安全成本。给智能体终端权限就是给它"上帝模式"，而这正是 致命三连 中"权限"那一环的来源。OpenClaw 的"技能商店"生态更把这一点放大：用户被鼓励安装"技能"脚本来赋予智能体新能力，但这些技能没有集中的审查流程，一个看起来无害的技能可能包含窃取配置文件或 API 密钥的隐藏载荷。[^1]¹

因此 wiki 对这场路线之争不作裁决：MCP 的结构化开销与终端路线的权限开销，是同一笔账在两端的不同记法。可以确定的只有一点——个人开发者与组织平台会长期做出不同的选择，而这两种选择正在同时扩散。

相关页面

• OpenClaw — 这条路线的载体项目
• 彼得斯坦伯格 — 提出者
• 致命三连 — 这条路线的安全代价
• 智能体文件 — 同一套"最少抽象"哲学的记忆侧解法
• 应用的消解 — 终端权限带来的产品形态后果

[^1]: OpenClaw：一个奥地利程序员意外点燃了智能体时代的第一把火？.md

注释

1. OpenClaw：一个奥地利程序员意外点燃了智能体时代的第一把火？ ↩