本文来自微信公众号： 陆三金 ，作者：陆三金
MCP已死，CLI当立。
前段时间，你是不是被这个观点刷屏了？
但就在4月，MCP的co-creater David Soria Parra在AI Engineer上的一场演讲，却在讲着不一样的叙事。
MCP目前每月已经达到了1.1亿次下载，当然，这不仅包括Anthropic自己的客户端和服务器，还包括OpenAI的Agents SDK、Google的ADK、LangChain，以及成千上万个你可能从没听说过的框架和工具，它们把MCP作为依赖拉进来。
熟悉了CLI叙事的你，觉得这很反直觉。
2025年，大家最熟悉的agent是coding agent。这个场景天然适合模型：代码在本地，结果可验证，有编译器、测试、版本控制和开发者兜底。模型写错了，开发者能看见，也能修。
但金融分析师、市场人员、运营人员、研究员要的不是一个会调用编译器的本地agent。他们要的是一个能进入真实工作现场的agent：能读公司云盘，能查CRM，能拉Slack，能开Notion，能跑内部系统，还要知道权限、身份、流程和任务状态。
“它们不需要一个会在本地调用编译器的agent。它们需要的是能连接五个SaaS应用和一个共享云盘的东西。”
这就是MCP的用武之地了。
MCP的价值并不只是“让模型调用工具”。更大的价值是：它试图给agent一个可扩展的连接层，让工具、资源、权限、界面和任务状态都能被清楚表达。
2026年的agent不会只靠一种连接方式
David对“连接能力”的判断很克制。他没有说MCP会取代一切。相反，他明确反对任何单一答案。
“如果有人告诉你，有一个方案可以解决你所有的连接问题……那他们大概率是错的。”
他的判断是，2026年构建agent时，真正需要的是一整套连接栈：skills、MCP、CLI，以及computer use。它们不是互斥关系，而是各自解决不同问题。
Skills适合承载领域知识。它把“这个系统该怎么用”“这个任务应该怎么做”“这个团队偏好什么”写成可复用的文件。对agent来说，skills像是可携带的工作手册。
CLI适合本地、可组合、已被大量训练数据覆盖的任务。Git、GitHub、bash这类工具，本来就已经存在于开发者工作流和模型训练语料里。对coding agent来说，CLI是非常自然的连接方式。
Computer use适合那些没有标准接口、但人类已经能用界面完成的任务。它不优雅，但覆盖面广。
MCP则适合需要更强语义、更好权限、更稳定平台独立性、更长任务状态、更清晰资源模型的场景。尤其是当agent要进入企业工作流时，MCP解决的是那些“无聊但重要”的问题：授权、治理、身份、任务、资源、界面和跨平台一致性。
David的结论是：
“2026年我们会开始构建同时使用所有这些能力的agent。它们不会只用一种东西，而是会全部使用，并且相当无缝地组合在一起。”
他认为我们现在还处于agent构建的早期，不是某个工具赢者通吃，而是一个更复杂的工作系统：该用CLI时用CLI，该用MCP时用MCP，该用skills时用skills，该点屏幕时也别假装屏幕不存在。
上下文膨胀不是协议的锅
MCP经常被批评的一点，是它会让上下文变大。工具太多，描述太长，模型还没开始干活，上下文窗口就被塞满。
David对这个问题的回应很明确：协议只是把信息传过去，真正负责处理信息的是客户端。问题不是MCP天然造成上下文膨胀，而是早期客户端太粗暴，把所有工具一次性塞给模型。
“到目前为止，大家一直在做的事……就是简单地把所有工具都塞进上下文窗口里，然后再惊讶地发现上下文窗口变大了。”
他的解法叫progressive discovery，渐进式发现。模型一开始不需要知道所有工具。它只需要有一个发现工具的入口。当模型意识到自己需要某类能力时，再去搜索、加载、调用。
有没有感觉眼熟？
这也是Skills的核心机制、agent系统设计的核心原则：不要把所有知识、所有工具、所有规则一开始都塞给模型。让模型在正确时间拿到正确东西。
优秀的agent不是靠一个巨型提示词启动，而是靠一个会逐步暴露信息的环境运转。
真正的工具调用，不该让模型一下一下手动编排
David提到的第二个关键技术，是programmatic tool calling，也就是程序化工具调用。
很多agent现在的工具调用方式很笨：模型调用一个工具，拿到结果，再调用第二个工具，再拿结果，再调用第三个工具。每一步都要模型重新推理，延迟高，成本高，也容易出错。
David认为，很多时候更好的方式是让模型写一小段程序，把多个工具组合起来一次执行。就像Claude Code写bash命令一样，MCP工具也应该可以被组合、过滤、循环、抽取。
“你不希望模型先调用一个工具，拿到结果，再调用另一个工具……因为你实际上是在让模型负责把这些东西编排起来。而这种编排用的是推理。”
推理很贵，也慢。脚本便宜，也稳定。
所以他建议给模型一个执行环境，比如类似REPL的工具、受限运行时或解释器，让模型写代码来组合MCP工具。这里结构化输出很重要，因为模型知道每个工具会返回什么类型，就能更可靠地拼接结果。
这也是agent从“会调用工具”走向“会组织工具”的关键一步。前者像是在遥控器上一个按钮一个按钮地按，后者更像是在写一个临时工作流。
MCP即将到来的改进
David在活动上也展望了MCP在2026年的一些改进和计划。
比如更容易扩展的无状态传输协议。比如更好的异步任务能力。比如新的TypeScript和Python SDK。比如跨应用访问，让员工只用公司身份登录一次，就能在不同MCP服务器之间顺滑使用。比如server discovery，让agent到一个网站时可以自动发现这里有没有MCP服务器，而不只是盲目解析网页。
这些不是demo里最吸引人的部分，却是企业真正会在意的部分。
因为一旦agent进入公司系统，问题就不再是“能不能调一个工具”。问题会变成：谁授权的？能访问什么？任务跑多久？中途断了怎么办？日志在哪里？不同客户端行为一致吗？员工离职后权限怎么收回？审计怎么做？
这正是David所说的“无聊但重要”的企业级东西。
MCP如果只是开发者玩具，酷功能就够了。MCP如果要成为agent的连接层，就必须把这些无聊问题处理好。
Skills over MCP可能是最值得关注的扩展
在所有未来扩展里，David最兴奋的是skills over MCP。
原因很简单：一个大型MCP服务器如果有很多工具，就不能只把工具列表丢给模型。它还应该告诉模型这些工具该怎么用，什么顺序更合理，哪些组合是常见模式，哪些坑要避开。
也就是说，服务器不只发布能力，还要发布使用知识。
“如果你有一个大型MCP服务器，里面有很多很多工具，你就会希望把领域知识一起发布出去，告诉模型：这个东西应该这样用，那个东西应该那样用。”
这会让skills从本地文件、插件机制、手动配置，走向服务端持续发布。服务器作者可以随着产品变化更新skills，客户端和agent则能在使用工具时拿到最新的使用说明。
今天你已经可以用一个load skills工具模拟这件事。但一旦MCP正式定义语义，它就会从技巧变成协议能力。
这件事的意义不小。未来一个好MCP服务器，不只是“有很多工具”，而是“知道怎样教agent使用这些工具”。
2026年的关键词是连接
“2026年的主题是连接能力，而最好的agent会使用所有可用的方法。”
过去我们评价agent，常常看它是否更聪明，是否推理更强，是否能写更复杂的代码。但如果agent要进入真实工作，聪明只是入场券。它还必须连接正确的数据、正确的工具、正确的身份、正确的界面、正确的任务状态，以及正确的领域知识。
这也是MCP在这场演讲里的定位。它不是所有问题的答案，也不是唯一的连接方式。它更像agent工作系统里的一层公共语义：当CLI太本地，computer use太脆弱，skills只承载知识，而企业又需要权限、任务、资源和界面时，MCP补上了中间那层。
最好的agent不会洁癖式地只选一种方式。它会像真正的工作者一样：该读文档时读文档，该用工具时用工具，该打开界面时打开界面，该调用协议时调用协议，该遵守权限时遵守权限。
所以，也许就没有你死我忘，而是多种连接方式共同协作，帮助模型在合适的时候处理合适的上下文。