@tobi: 关于 LLMs 的 MCP 与 CLI 之争是错误的讨论。人们在错误的层面上辩论。只要……

X AI KOLs Timeline 新闻

摘要

本文认为,关于 LLMs 的 MCP 与 CLI 之争是错误的,因为两者在持久状态环境中都表现良好,并建议通过一个通用执行环境来实现未来的统一。

MCP 与 CLI 之争是错误的讨论。人们在错误的层面上辩论。 只要通过能持久状态的 repl 类环境运行,两者都表现得非常好。CLI 的有趣之处在于,CLI 工具通常通过 BASH 访问,而 BASH 恰好是一个具有持久状态(文件系统)的 repl,因此 cli 比 mcp 工作得更好。但这甚至不是 MCP 的内在属性。只是意味着我们需要更好的工具。 目前最好的 repl 有: - bash + fs - jupyter kernels - codemode 类型的 repl,通常是 quickjs LLMs 非常理解向前演化系统以满足需求的概念。这来自于代理强化学习。它们理解如何改变代码库的状态或从数据库获取数据,然后像人类一样操作。但如果没有执行环境,它们实际上无法正确执行。 我的预测?不久之后,有人会(或者已经?)创建一个可嵌入的、sqlite 风格的迷你执行环境,将 bash、typescript 或工具调用解析为通用的 IL 执行计划,以便在执行前轻松进行安全检查。并专门设计用于持久执行环境。然后我们只需将 cli、mcp、webmcp 等连接到那里,它接受任何输入模态,因为它们都可以相互表示。
查看原文
查看缓存全文

缓存时间: 2026/09/21 15:43

MCP与CLI之争对于LLM来说是个错误的议题。双方的辩论其实处于错误的层面。

只要通过能持久化状态的交互式环境运行,两种方式都表现极其出色。有趣的是,CLI工具通常经由BASH访问——BASH恰好是一个具有持久化状态(文件系统)的交互式环境,因此CLI比MCP表现更优。但这绝非MCP的固有缺陷,仅说明我们需要更完善的执行框架。

当前最优秀的交互式环境包括:

  • bash + 文件系统
  • Jupyter内核
  • codemode类交互环境(通常是QuickJS)

LLM能深刻理解通过系统演进解决问题的概念——这源于其智能体强化学习训练。它们懂得如何修改代码库状态或获取数据库数据,并能像人类一样操作这些数据。但若缺乏执行环境,LLM实际上无法正确完成这些操作。

我的预测是:很快就会有人(或许已有人?)开发出可嵌入的SQLite式微型执行环境,能将Bash、TypeScript或工具调用解析为通用中间语言执行计划,便于执行前进行安全检查。该环境将专为持久化执行而设计。届时我们只需将CLI、MCP、WebMCP等各类接口接入该系统——由于所有输入模态都能相互转化,该系统可接受任何形式的输入。

相似文章

@akshay_pachaar: MCP 与 CLI 之争。在 2025 年的大部分时间里,AI 工程师们对此争论不休。怀疑论者摆出了真实数据:- Playwright MCP …

X AI KOLs Following

Anthropic 的“代码模式”(Code Mode)重新定义了 MCP 与 CLI 之争。它让 AI 代理编写代码,通过运行时调用工具,而不是将完整的模式加载到上下文中,从而大幅减少了 token 消耗。这种方法结合了 MCP 的强类型契约与懒加载机制,证明了该协议正在演进,而非走向消亡。

技能 + CLI 或 MCP

Reddit r/AI_Agents

作者讨论了他们对LLMs日益增长的信任,并寻求关于在软件开发中使用AI技能结合CLI工具或MCP服务器哪种方法更优化令牌使用且更不易出错的建议。

为何MCP一直是个糟糕的想法?

Hacker News Top

这篇文章认为,MCP最初用于将LLMs连接到外部服务,但由于LLMs的进步,现在可以直接处理API调用,使得许多MCP服务器变得多余,因而过时了。