MCP、CLI与Skills的结合：面向生产级智能体的连接架构

演示版本定义了2024年，编程智能体定义了2025年，而2026年则是通用知识工作智能体投入实际应用的年份。据报道，Model Context Protocol的月下载量已达到约1.1亿次，这一里程碑的达成速度甚至超过了React。然而，当这些智能体开始处理涉及多个SaaS应用和共享驱动器的企业级工作流程时，有一个问题不断被提及：连接性并非单一概念。任何声称存在唯一解决方案的人，无论是计算机操作、MCP还是命令行，都在夸大其词。强大的智能体不会只选择其中一种，而是会同时利用整个连接性技术栈。

三层架构

技能模块、命令行界面以及MCP各自解决不同的问题，其构建方式也各不相同。

• 技能包含领域知识。它们是可重复使用的流程指令，通常为 Markdown 文件，用于教导模型如何使用工具。这些技能会在不同客户端之间传递，为复杂任务提供所需上下文。它们可以由人类编写，也可由智能体生成，并从诸如 .claude/skills/ 这样的本地目录或远程仓库中加载。
• CLI，即计算机操作，属于 Unix 风格的本地执行方式。它的响应效率很高，消耗的标记量较少（每次响应约 200 个标记），并且能得益于模型在 git、gh 和 curl 等工具上的预训练成果。要使用 CLI 工具，只需通过包管理器安装常规二进制文件即可。

MCP是一种连接性技术，它具备丰富的语义功能、平台独立性，以及OAuth、治理策略和审计追踪等企业级功能。服务器通过代码定义，例如server.py或server.ts，这些代码还包含了工具、资源及相关指令，服务器通过HTTP或SSE协议使用JSON-RPC 2.0进行通信。

何时选择MCP

当需要丰富的语义功能、授权机制以及平台独立性时，应选择MCP。它采用以模式优先的确定性方法来选择工具，并内置了治理与审计追踪功能。不过其代价是资源消耗。如果采用简单的设置方式，预先加载所有工具的模式，可能会消耗44,000到55,000个令牌，而且每个响应都是完整的带类型标注的JSON对象，虽然便于程序化解析，但会占用大量令牌。

对于任何编写服务器代码的人而言，建议使用具有描述性的函数名和参数名，并为每个参数添加说明。当模型清楚知晓所需输入的内容时，其运行效果会更好、速度也会更快。

# Annotated Tool Definitions
from typing import Annotated
from datetime import date
from enum import Enum

class Category(str, Enum):
    TRAVEL = "travel"
    MEALS = "meals"
    OFFICE = "office"

def submit_expense(
    amount: Annotated[float, "The expense amount in USD"],
    date: Annotated[date, "Date of the expense in YYYY-MM-DD format"],
    category: Annotated[Category, "The expense category"]
) -> str:
    """Submits a new expense report for approval."""
    pass

何时应选择命令行接口

如果某个工具已经存在于模型的预训练数据中，比如 Git 或 GitHub CLI，那么通过命令行执行会显得非常高效。模型可以利用管道和重定向功能串联命令，并以较低成本处理错误。它无需接收庞大的 JSON 数据，只需用 jq 进行过滤，即可获取所需信息，得到的响应通常只有大约 200 个标记。

渐进式发现

对大多数智能体框架而言，最重大的改进就是渐进式发现功能。无需将所有工具都放入上下文窗口中，而是可以在模型真正需要时再加载。赋予模型 tool_search 功能，使其能够动态查找工具，这样上下文的使用量便可减少约五倍。

程序化调用工具

当模型需要协调多个工具时，不要让它依次调用这些工具，因为每一步都会产生推理延迟。应采用编程方式调用工具，也就是所谓的代码模式。提供诸如 V8 孤立环境或 Python 沙箱之类的 REPL，让模型编写用于组合这些工具的脚本。该脚本只需编写一次即可运行整个流程，从而大幅降低延迟。

// Programmatic Tool Calling (Code Mode)
// Instead of multiple sequential LLM turns, the model writes this script once:
const issue = await mcp.call_tool("linear_get_issue", { id: "ENG-5121" });
const prs = await mcp.call_tool("github_list_prs", { repo: "frontend" });

// Use structured output to enforce types
const expectedType = z.object({ title: z.string(), status: z.string() }).passthrough();
const typedIssue = await extract("claude-haiku-4-5", expectedType, issue);py

为智能体构建

服务器开发者应停止将REST API与MCP服务器进行一一映射的做法，而应从一开始就为智能体进行设计。三个习惯有助于实现这一目标：以明确的意图构建工具，就像为人类设计界面一样；像Cloudflare MCP那样公开执行环境，以便模型能够通过代码编排复杂的工作流；此外还要发布MCP应用：利用MCP的语义通过网络传输HTML、JavaScript和CSS等UI资源，从而使服务器能够在客户端渲染自己的界面。

MCP的未来发展

该生态系统正在快速发展，以满足企业需求并实现规模化扩展，2026年的发展路线图包含三个重点方向。

• 更完善的核心功能：由谷歌提出的全新无状态传输机制将使MCP服务器更易于在Kubernetes和Cloud Run上部署，同时TypeScript和Python SDK的2.0版本也即将发布。
• 全面集成：跨应用访问功能可通过企业的身份提供商实现MCP服务器间的单点登录，同时服务器信息可从.well-known/mcp-server-card/server.json文件中自动获取。
• 超越现有边界：基于MCP的技能功能允许服务器通过skills/list和skills/get接口，在工具之外传递领域知识。

如何选择

选择取决于具体场景和需求：需要强管控与丰富语义时选用MCP，模型已知晓工具且令牌至关重要的情况下选用CLI，而需要整合各工具的流程知识时则选用技能功能。

要点总结

没有哪种工具能独占优势，将MCP与CLI对立起来也偏离了重点。生产环境中的智能体需要多层架构。对MCP的批评——比如令牌开销大、认证存在缺陷以及服务器质量参差不齐——确实指出了实际问题，但这些都属于工程问题，有解决方案，而且相关生态系统已经在不断调整。渐进式发现和代码模式能够减少令牌冗余和延迟，因此这个标准可以优化而非被放弃。企业在放弃MCP后，将会面临更严重的问题：认证分散、缺乏审计追踪以及供应商锁定。预计最强大的智能体将会结合Skills来实现知识处理，用MCP处理受管控的连接，而用CLI进行低成本的本地执行。