摘要
1) 一句话总结 MCP 本质上是在应用层低效地重新实现了 POSIX 操作系统，公司应优先发布基于 POSIX 的标准 CLI 工具，并仅通过补充轻量级的静态清单文件来解决 AI Agent 的工具发现与身份验证需求。
2) 关键要点
- 能力重叠与成熟度差异： MCP 试图解决的 5 个核心需求（发现、调用、数据流、权限、编排），POSIX 早在 1988 年就已解决，并在数十亿台机器上稳定运行了近 40 年。
- 数据流与成本对比： MCP 将中间执行结果传回模型上下文，消耗大量 Token（如 Anthropic 曾报告仅加载工具元数据就耗费 13.4 万 Token，约 0.40 美元）；而 POSIX 通过管道（如
curl | jq | grep）传递数据，不进上下文窗口，成本不到一美分。 - 编排机制对比： MCP 依赖模型进行多步推理编排；POSIX 使用 Shell 脚本，具备确定性、可重放性且无需消耗 Token。
- MCP Server 的冗余性： 大多数 MCP Server 仅是现有 CLI 工具（如
stripe,gh,aws）的多余翻译层，将 CLI 包装为 JSON-RPC 格式。 - 身份验证的误区： MCP 带来的 OAuth 体验提升属于“运行时（Runtime）”功能，Agent 运行时完全可以拦截标准 CLI 的身份验证请求并注入环境变量，无需引入全新协议。
- 真正的解决方案： 填补 POSIX 与 AI Agent 之间缺口的正确方法是引入两个静态文件：机器可读的“工具清单（Tool Manifest，类似
package.json）”和标准化的“身份验证声明（Auth Declaration）”。 - 理想的技术栈架构： 应由模型（Model）负责推理决策并输出命令，操作系统（POSIX）负责底层执行与管道传输，Agent 运行时（Runtime）负责 UI 交互与身份验证代理。
3) 风险与不足（基于原文明确指出）
- 高昂的 Token 成本与上下文瓶颈： MCP 要求将工具元数据和中间执行结果全部序列化到模型上下文中，极易造成上下文瓶颈并产生高昂费用。
- 协议不稳定与生态不成熟： MCP 仍是一个不断变动的目标，频繁发布破坏性更新（breaking changes），认证规范去年才落地，且目前仅有几千个集成。
- 编排效率低且易出错： 依赖模型进行“工具调用-推理”的循环编排，被 Anthropic 官方承认是“既慢又容易出错”的方式。
- 增加系统延迟与复杂性： 在现有 CLI 工具之上强加 MCP 翻译层，不仅无法使用管道或脚本，还增加了系统的延迟和复杂性。
正文
我之前的文章曾提出，Bash 才是 AI Agent（智能体）正确的工具编排层。这个观点本身没错，但还不够深入。如果仅仅将 Bash 视作 MCP（Model Context Protocol）的一种实用替代方案，听起来就像是工程师们在午餐时会争论的那种单纯的“工具偏好”问题。但真正的问题要严重得多：MCP 实际上是在操作系统之上重新构建了一个操作系统，而它试图解决的每一个问题，POSIX 早在 1988 年就已经解决了。
抛开各种包装概念，一个 AI Agent 对其运行环境的需求其实只有五点：发现工具的方法、调用工具的方法、在工具间传递数据的方法、控制访问权限的方法，以及编排多步工作流的方法。MCP 提供了这五种能力，但 POSIX 同样也提供了。两者的区别在于：POSIX 已经稳定运行了近四十年，支撑着地球上的每一台服务器，并拥有数以百万计基于其接口构建的工具生态；而 MCP 还是一个不断变动的目标，仅有几千个集成，且其中大多数不过是对现有 CLI（命令行界面）工具的二次封装。
MCP 与 POSIX 的能力对比
以下是这五种能力在两个系统中的映射关系：
- 发现工具（Discovery）
- MCP： 需要将工具的 Schema 加载到模型的上下文中，以便模型知道有哪些工具可用。最初的做法是预先加载所有内容，这在对话开始前就会消耗数万个 Token。Anthropic 自己的工程团队曾报告，仅工具元数据就消耗了 13.4 万个 Token——按当前 Claude 的定价，用户还没说一句话，大约 0.40 美元的输入成本就已经花掉了。后来的修复方案是引入“工具搜索工具”来实现按需发现。
- POSIX： 几十年前就通过
$PATH和--help解决了这个问题：二进制文件存放在已知目录中，需要时直接运行，不需要向内存中预加载任何内容。
- 调用工具（Invocation）
- MCP： 通过基于 stdio 或 HTTP 的 JSON-RPC 调用工具。模型发出结构化的工具调用，服务器执行，然后将结果作为结构化数据返回。
- POSIX： 使用
fork和exec。模型发出 Shell 命令，内核运行它，结果通过stdout返回。 - 对比： 两者的能力完全相同，区别在于 POSIX 版本已经在数十亿台机器上经过了四十年的生产环境实战检验。
- 数据流（Data flow）
- MCP： 将每个工具的执行结果传回模型的上下文窗口。这意味着模型需要消耗 Token 来读取它，上下文窗口成为了瓶颈。
- POSIX： 直接在进程之间通过管道传递数据。例如
curl | jq | grep可以让数据流经三个工具，而完全不进入上下文窗口——因为根本不存在上下文窗口。 - 对比： 成本差异极其惨痛。在 Bash 中成本不到一美分的五步流水线，在 MCP 中可能轻易耗费数美元，因为每一个中间结果都必须序列化到对话中，并让模型进行推理后才能开始下一步。
- 访问控制（Access control）
- MCP： 正在从零开始构建自己的权限模型。
- POSIX： 拥有用户、用户组和文件权限模式（file modes）。这是一个被广泛理解、久经考验，且被所有基础设施支持的系统。
- 编排（Orchestration）
- MCP： 通过“工具调用-推理-工具调用-推理”的循环，将每一步路由回模型来进行编排。Anthropic 自己的博客文章也承认这种方式“既慢又容易出错”，他们的解决方案是“编程式工具调用（Programmatic Tool Calling）”，让模型在沙盒中编写代码来调用多个工具。
- POSIX： 使用 Shell 脚本进行编排：编写命令，用管道连接，然后运行脚本。步骤之间不需要模型推理，不消耗 Token，且具有确定性和可重放性。
五种能力，五个早已被解决的问题。MCP 并不是在扩展操作系统，它是在应用层重新实现操作系统，而且性能更差、成熟度更低、生态系统也小得多。
MCP Server 的本质：多余的翻译层
如果说 MCP 是对 POSIX 的重新实现，那么 MCP Server 就是对 CLI 工具的重新实现——事实上，大多数 MCP Server 确实如此。
典型的 MCP Server 会将 HTTP API 或现有的 CLI 包装成 MCP 的 JSON-RPC 格式，在协议和底层服务之间进行翻译。这个翻译层增加了延迟、复杂性，并且依赖于一个仍在不断发布破坏性更新（breaking changes）的协议。
Agent 最需要交互的那些公司，其实早就提供了 CLI 工具。比如 stripe payments list、gh pr create、aws s3 cp：它们可以与管道、脚本、CI/CD、Cron、Docker 以及任何拥有 Shell 访问权限的 Agent 完美配合。它们已经存在，有人维护，并且可以与机器上的任何其他 CLI 工具免费组合使用。
在这些工具之上再发布一个 MCP Server，意味着为相同的功能发布了第二个接口。而这个第二接口只能在兼容 MCP 的宿主环境中运行，不能使用管道或脚本，每次调用都需要模型消耗一次推理过程，并且依赖于一个去年才刚刚落地认证规范的协议。
支持 MCP Server 的理由通常是“易用性”：它们能出现在工具选择器中，能透明地处理身份验证，能在聊天 UI 中工作。这些优势是真实的，但它混淆了“表现层”和“执行层”。工具选择器是宿主应用程序的功能，而身份验证代理是运行时的功能。这两者都不需要在工具层面引入一个全新的协议。
身份验证：被错误归因的优势
支持 MCP 的最后一个严肃理由是身份验证（Auth）。传统上，CLI 工具需要用户手动运行类似 gh auth login 或 gcloud auth login 的命令，这对于聊天界面中的非技术用户来说确实存在摩擦。
MCP 通过内置的 OAuth 解决了这个问题：服务器声明它需要的权限范围（scopes），宿主程序打开浏览器，用户授权，然后 Token 透明地流回。这确实是一个真正的 UX（用户体验）提升，否认这一点是不诚实的。
然而，这种提升被错误归因了。它来源于“运行时（Runtime）”，而不是“协议（Protocol）”。
当你运行 gh auth login 时，CLI 会打开浏览器，你点击授权，Token 就会存储在你的环境变量中。今天这套流程之所以不能在聊天 UI 中无缝运行，仅仅是因为还没有人搭建这座桥梁。Agent 运行时完全可以拦截身份验证请求，在 UI 中呈现与 MCP 完全相同的 OAuth 流程，将获取到的 Token 设置为环境变量，然后让 CLI 像往常一样继续运行。用户获得了同样的“点击、授权、完成”体验，而底层的工具依然是标准的 CLI。
这是 Agent 宿主的功能，而不是工具本身的属性。运行时已经充当了用户和模型之间的中介，为需要凭证的 CLI 工具代理 OAuth 只是这一角色的自然延伸，根本不需要工具本身去使用一种自定义协议。
真正的缺口：我们到底需要什么？
对于上述观点，有一个合理的反对意见值得认真回答：即使 POSIX 可以处理调用、数据流和编排，难道我们不需要一些新东西来处理“发现”和“身份验证”吗？
是的，这个缺口确实存在。但它比 MCP 要轻薄得多。
关于发现（Discovery）：
--help 对 LLM 来说效果出奇地好，因为它们能读懂自然语言。但是，“能用”和“在数千个异构 CLI 中大规模可靠地使用”是两码事。一个结构化的、机器可读的清单（Manifest），用于描述工具的命令、参数类型以及必填/可选输入，显然比指望模型正确解析每个 CLI 千奇百怪的 help 输出要可靠得多。
但这只是一个清单格式，而不是一个协议。把它想象成 package.json 或 pyproject.toml：一个与二进制文件放在一起或内置其中的静态文件，描述了它能做什么。你不需要 JSON-RPC 和一个运行中的服务器进程来告诉 Agent stripe payments list 接受什么参数。
关于身份验证（Auth）：
如果运行时要代表 CLI 工具代理身份验证，这些工具就需要一种标准化的方式来声明它们的需求。比如：“我需要一个来自该 OAuth 提供商、具有 repo 权限的 GitHub Token，并且我希望它被放在 GITHUB_TOKEN 环境变量中。”
目前每个 CLI 的做法都不一样，如果没有统一格式，运行时就无法通用化。但这只是一个身份验证声明规范，而不是一个协议。一个指定了 OAuth 提供商、权限范围和目标环境变量的静态文件足矣。
两个静态文件格式：一个工具清单（Tool Manifest）和一个身份验证声明（Auth Declaration）。这就是 POSIX 与 AI Agent 对工具层需求之间的全部缺口。至于其他的一切——调用、数据流、编排、访问控制——操作系统都已经处理好了。
结论：解绑与回归简单
MCP 的问题不在于它解决的是伪需求。那层薄薄的发现元数据和身份验证配置确实非常有用。MCP 的问题在于，它将这层“薄薄的有用层”与一层“厚厚的不必要的基础设施”捆绑在了一起：它自带的调用机制、数据传递格式和编排模型，全都在重新实现 POSIX 已经提供的东西，而且实现得更糟。
正确的做法是解绑它们。定义这两个轻量级标准，让 POSIX 处理剩下的事情。
整个技术栈应该比行业目前搞的要简单得多：
- **模型（Model）**决定做什么：它对任务进行推理，规划动作序列，并输出 Shell 命令或脚本。
- **操作系统（OS）**执行这些命令：处理进程管理、文件 I/O、网络、管道和权限——也就是 POSIX 定义的一切。
- **Agent 运行时（Runtime）**位于用户和模型之间：处理模型和操作系统都不覆盖的部分，比如在 UI 中展示结果、代理身份验证、执行安全策略、管理对话。
在这个技术栈中，没有空间容纳一个重新实现操作系统并将每个工具包装在自定义 RPC 格式中的协议。但这里有空间容纳两个轻量级标准：一个描述 CLI 功能的工具清单，以及一个告诉运行时如何代理凭证的身份验证声明。
公司应该发布带有清单文件和身份验证声明的 CLI 工具。Agent 运行时应该提升读取这些清单、代理身份验证和管理访问权限的能力。而它们之间的执行层应该是 POSIX——它一直在等待一个足够聪明、能流利使用它的用户，而这个用户，最终证明是 LLM。