跨国深谈← 返回←MCP没有问题，你的智能体才有问题

MCP没有问题，你的智能体才有问题

关联

人物 Jan Čurn

公司 Appify · Anthropic · Cloudflare

概念 MCP · CLI · harness · 子智能体 · 渐进式工具发现 · CodeMode · 工具调用 · 沙箱 · 上下文窗口 · MCPC · Connector Evals

MCP是Anthropic在近两年前推出的标准，用来让AI智能体安全地连接各种工具。

去年它一度是AI圈的宠儿，现在市面上大约有1万到1.5万个MCP服务器，Claude和ChatGPT都在用它接入工具。可与此同时，骂它的声音也越来越多。

Apify创始人兼CEO Jan Čurn这场演讲要回答的问题是：MCP真的像大家说的那么糟吗？

大家为什么骂MCP？

网上流传的批评相当狠。有人说「MCP是个错误，命令行万岁」，有人说MCP基本没用，连Gary Tan都说说实话，MCP很糟糕。

Čurn把最常被引用的一条批评拿出来分析：MCP太吃上下文了。

这确实是真的。早期智能体接入MCP的方式很天真：10个服务器、每个10个工具，就把100个工具全部塞进上下文。

你还没开始提问，三分之一的上下文已经被吃掉了。

之后每次调用工具、每次返回结果，上下文还在继续膨胀，越变越长，准确度下降，费用飙升。

但Čurn指出，这是智能体的问题，不是协议的问题。MCP规范里对智能体该怎么设计只字未提——那是实现者自己的责任 。

业界已有的三种补救办法

第一种是把任务分给子智能体，让它们各自处理，不污染主上下文。

但代价是代币费用照样要付，而且敏感信息（比如密码）还是会留在某个上下文里，可能被其他工具调用滥用。

第二种叫渐进式工具发现，去年年底由Anthropic和Cursor先后推出。

思路简单得让人心疼：不要一次把100个工具全塞进去，而是用一个工具搜索工具，需要哪个再加载哪个。

通常你只需要一两个工具，这样能省下大量上下文 。

第三种是Cloudflare推出的CodeMode：别把MCP工具当函数塞进上下文，把它们当代码。

因为模型读代码、写代码的能力很强，训练数据里有海量代码可以学。

相比之下，工具调用是人造的概念，训练数据里本来没有，得靠合成数据硬教 。

问题是，这些方案大多数MCP客户端根本不支持。协议进化了很多，客户端还停留在黑暗时代。

命令行为什么天生就强？

很多人主张用命令行（CLI）取代MCP，理由其实站得住脚。

智能体从不把整个命令行的帮助文档全塞进上下文，而是按需查询——相当于天生就自带渐进式发现。

运行命令行必须通过shell，而shell本身就是代码——相当于天生就自带CodeMode。

更关键的是，智能体对shell熟得不能再熟。Unix从1969年就有了，那个80列25行的黑终端，是40多年优化的结果，每个字节都在传达最重要的信息。

智能体的训练数据里见过无数shell用法，AI实验室还能合成无限的shell训练数据 。

但命令行也有硬伤：它是个本地黑盒，没有标准的传输协议。企业没法监控它用了什么接口，也没法给它注入凭证。

所以远程接入的场景，MCP依然是更好的选择——你见不到哪个智能体用命令行做远程连接器。

MCPC：把两个世界的优点合起来

Čurn的方案是：远程访问用MCP，本地操作用CLI。于是他做了MCPC，一个通用的MCP命令行客户端。

这个项目最初只是一个业余项目，后来成了市面上功能最全的同类工具。

它的思路是把MCP的全部复杂性藏在一个所有智能体都会用的工具调用背后——bash。会话管理、授权、认证，统统不用操心。

每条命令都支持—json参数，输出纯JSON，可以用JQ之类的工具把多次调用串成脚本，完全不浪费上下文代币 。

现场演示里，MCPC连接了本地的Filesystem服务器和远程的Apify服务器。登录认证走浏览器，凭证安全地存在操作系统的钥匙串里。

会话是持久化的，设置一次，Claude Code和Codex等智能体可以共用同一套配置。

它还支持MCP协议的新特性，比如异步任务：加个—task参数，任务在服务器上跑，你可以先去干别的，回头再取结果。

Čurn提到，大多数客户端连协议里的instructions（服务器自我说明）这种基本原语都不支持 。最近他们还加了X402支持，可以用来管理本地钱包。

实测：MCPC表现如何？

为了比较不同接入方式的优劣，Apify做了一个叫Connector Evals的评测框架。

一般的基准测试（比如TerminalBench）比较的是不同智能体谁更强，他们反过来，固定用Claude Code加Sonnet 5，比较不同的连接器——原生CLI、原生MCP、MCPC——哪个更高效。

初步结果显示，MCPC和原生CLI表现相当，而原生MCP虽然有时完成得更快，但消耗的代币更多 。

所以Čurn的结论是：别再说CLI比MCP好了。MCP加CLI，才是最好的组合。

本集带走

• MCP被骂吃上下文，但那是智能体实现得差，不是协议本身的问题——MCP规范根本不管智能体怎么设计。
• 命令行天生自带渐进式发现和代码模式，加上智能体对shell极其熟悉，这是它受欢迎的真正原因。
• 命令行是本地黑盒，没有标准传输协议；远程接入场景，MCP依然是更合适的选择。
• Apify开源的MCPC把MCP包装成命令行，隐藏全部协议复杂性，支持持久会话、渐进式工具搜索、异步任务等新特性。
• Apify的Connector Evals框架初步测试显示：MCPC与原生CLI表现相当，原生MCP消耗代币更多。

MCP 就已经用 100 个工具占满了你的上下文。可能你三分之一的上下文就这么没了，却什么工作都没做。
MCP would already eat 100 tools in your context. Maybe one third of your context would be gone without actually doing any work.
—— Jan Čurn · [03:00]

如果你很少用到那 100 个工具，为什么要一直把它们全部放进上下文呢？
Why would you add all the 100 tools in your context all the time if you rarely need them?
—— Jan Čurn · [05:17]

模型在编写和调用代码方面比调用工具更好，因为工具调用基本上是一种人工构造，我们必须教会 LLM 去做这件事。
Models are better at writing and calling code than calling tools because tool calling is an artificial construct, basically, that we have to teach the LLMs to do.
—— Jan Čurn · [06:28]

它在现实世界中不存在，不在真实训练数据中。这些数据必须被合成出来并放进模型里。
It doesn’t exist in the real world, in real training data. Those have to be synthesized and put into the model.
—— Jan Čurn · [06:39]

所以大多数智能体仍然生活在黑暗时代，它们不支持这些功能，你知道的，大多数 MCP 客户端也是如此。
So still, most agents are living in the dark ages, and they don’t support these features, you know, and most MCP clients.
—— Jan Čurn · [07:03]

那里的每一个字节、每一个字符都经过了 40 年的优化，只传达最重要的信息。
Every byte, every character there is optimized over 40 years to convey only the most important information.
—— Jan Čurn · [08:55]

所以请不要再说什么 CLI 比 MCP 好了，因为 MCP 加 CLI 才是最好的。
So please stop saying CLI is better than MCP because MCP plus CLI is the best.
—— Jan Čurn · [18:18]