如何构建可投入生产的AI Agent：MCP、CLI与Skills

作者：AI拉呱（Errol Yan）
定位：AI领域深度内容与实战方法分享

2026 年 agent 连接能力栈的实用指南：该用什么，不该混淆什么

2024 年，我们做的是 demo；2025 年，我们开始做 coding agent；到了 2026 年，真正进入生产环境的，是能处理跨 SaaS、多驱动、多系统协同任务的“知识工作者型 agent”。

根据 Anthropic 的 David Soria Parra 提到的数据，Model Context Protocol（MCP）的月下载量已经达到 1.1 亿，增长速度甚至超过 React。可随着 agent 要接入越来越复杂的企业系统，一个现实也越来越清楚：连接能力从来不是单一技术问题。

如果有人告诉你，所有连接问题都能用一个方案解决，无论它叫 computer use、MCP 还是 CLI，那么这个结论基本就是错的。

真正优秀的 agent，不是在这些方案里“二选一”，而是会同时、自然地使用整套连接能力栈。

这篇文章想解决的问题，就是 2026 年 agent connectivity stack 到底应该怎么理解：Skills、CLI、MCP 分别解决什么问题，如何协同，以及你在构建生产级 agent 时该怎么选。

先理解这套连接能力栈

在开始写代码之前，先把三层能力边界理清楚：Skills、CLI 和 MCP 分别是什么，又是怎么形成的？

• • Skills（领域知识层）：本质上是可复用的程序化指令和 markdown 文档，用来教模型如何在某类任务中使用工具。它们可以跨客户端迁移，为复杂任务提供必要上下文。Skills 通常由人编写，也可能由 agent 自动生成，通常从本地 .claude/skills/ 目录或远程仓库加载。像 superpowers 和 everything-claude-code 都是很典型的代表。
• • CLI / Computer Use（本地执行层）：这更像 Unix 世界的连接方式。它高度可组合、token 效率高（单次响应大约 200 tokens），并充分利用模型对 git、gh、curl 等标准工具的预训练知识。CLI 工具的形成方式，通常就是安装现成二进制，再让 agent 去调用。
• • MCP（连接协议层）：MCP 提供的是 richer semantics、平台无关性，以及企业级必需的 OAuth、治理策略和审计能力。MCP server 通常通过 server.py 或 server.ts 这样的代码定义 tools、resources 与 prompts，并通过 JSON-RPC 2.0 over HTTP 或 SSE 通信。

什么时候该用 MCP

当你需要更强的语义表达、明确的授权边界和平台无关性时，MCP 是正确选择。

它提供的是 schema-first、deterministic 的工具选择模式。

MCP 的优势在于：工具是显式定义的，有治理能力，也有审计轨迹。但它也有现实代价。

如果你采用非常朴素的实现方式，把所有工具 schema 一次性全塞进上下文，context 很容易暴涨到 44,000 到 55,000 tokens。并且它返回的往往是完整、强类型的 JSON 对象，虽然很适合程序解析，但 token 成本也会更高。

给 MCP Server 作者的一个关键建议：

工具名、参数名和参数描述一定要写得足够清楚。LLM 对工具的使用成功率，很大程度上取决于它能否从定义里立即理解“这个工具是干什么的”。

# 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

MCP 的本质不是“把 REST API 原样搬进来”，而是把工具设计成 agent 更容易理解、选择和组合的形态。

什么时候该用 CLI

如果目标工具已经深度存在于模型的预训练经验里，比如 GitHub CLI、Git、curl、jq，那么 CLI 往往非常强。

它的优点主要有三个：

• • 组合性强：命令、管道、重定向天然适合串联
• • token 更省：相比一次塞入大量工具 schema，命令行输出更可控
• • 可迭代调试：模型可以基于错误信息快速修命令

与其让 agent 拿到一个庞大的 JSON 响应，不如让它用 jq 等工具筛出真正需要的信息，只返回 200 tokens 左右的压缩结果。

这也是为什么，在很多开发、运维和本地自动化场景里，CLI 不是 MCP 的替代品，而是更高性价比的执行层。

Progressive Discovery 才是连接层的关键升级方向

如果说今天大多数 agent harness 最该改进的一点是什么，我会选 Progressive Discovery。

核心思想很简单：不要把所有工具一次性扔进上下文，而是在模型真正需要时再加载。

通过提供一个 tool_search 能力，模型可以动态查找可用工具，而不是预先消化整本“工具黄页”。在很多场景里，这种方式可以把上下文占用压缩到原来的五分之一左右。

如果你在做 agent harness，这个方向几乎是必须投入的。

Programmatic Tool Calling：别逼模型一轮轮顺序调工具

如果你希望模型编排多个工具，最差的做法往往是让它逐轮调用。

因为每多一轮工具调用，就多一次推理延迟，整个 orchestration 会被拆得非常慢。

更好的方式，是让模型进入 Code Mode，也就是给它一个 REPL（Read-Eval-Print Loop）环境，例如 Python sandbox 或 V8 isolate，让它直接写一小段脚本来组合这些工具。

对应的思路大致像这样：

// 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);

它的核心收益不是“模型更聪明了”，而是把多轮串行决策压缩成一次脚本式 orchestration，从而显著降低延迟。

为 Agent 而设计，而不是把 REST 机械映射成 MCP

如果你是 server author，一个很重要的转变是：别再把 REST API 1:1 地搬进 MCP server 里。

应该从 agent 使用场景出发，重新设计工具。

这一点可以总结成三条：

为 Agent 设计接口：像为人设计 UI 一样，为 agent 设计清晰的工具意图。
优先提供 Code Mode 能力：如果可能，就暴露可执行环境，让模型可以自己编排复杂流程。
把 UI 也纳入协议层：MCP 不只能传工具，还可以传 HTML、JS、CSS 这类资源，让 server 自带界面在 client 中渲染。

真正优秀的 MCP server，不只是 API bridge，而是 agent-native 的交互边界。

MCP 接下来会往哪走

MCP 生态还在快速演进，尤其是在企业部署与大规模落地方向。

当前几个明显趋势包括：

• • Improved Core：Google 提出的 Stateless Transport，会让 MCP server 更容易部署在 Kubernetes、Cloud Run 这类环境中，同时 TypeScript 与 Python SDK 2.0 也值得期待。
• • Integrate Everywhere：跨应用访问（Cross-App Access）将允许企业通过统一身份提供方实现多个 MCP server 的单点登录，.well-known/mcp-server-card/server.json 也会让 server discovery 更自动化。
• • Pushing the Boundary：Skills over MCP 会让 server 不只是传工具，还能通过 skills/list 与 skills/get 直接分发领域知识。

这背后其实指向同一个结论：agent connectivity 不会只剩一个协议，而会是技能、协议、执行层的协同演进。

最后的结论：别再把 MCP 和 CLI 对立起来

2026 年 agent connectivity 的演化已经证明了一点：不存在银弹。

“MCP 还是 CLI”这种争论，本质上是个伪命题。真正要进入生产环境的 agent，需要的是分层思考，而不是站队。

MCP 面临的批评，比如 token overhead、认证缺口、server 质量不齐，这些都是真问题。但它们是可解的工程问题，不是协议层面的原罪。

Progressive Discovery 和 Programmatic Tool Calling 已经证明，只要 harness 设计得对，MCP 的 token 膨胀和延迟问题都可以被大幅压缩。

相反，如果在企业环境里彻底放弃 MCP，只依赖 CLI，你会引入更糟的问题：授权碎片化、零审计能力、供应商锁定和治理失控。

所以最终胜出的，不会是只会一种连接方式的 agent，而是能把 Skills 的领域知识、MCP 的安全连接、CLI 的高效执行整合起来的 agent。

真正强的 agent，会全部用上。

关注 AI拉呱

如果这篇内容对你有启发，欢迎关注「AI拉呱」，获取更多 AI 前沿洞察、实战教程与趋势解读。

下期在看

下期将继续带来该主题的进阶拆解与实操案例，建议先收藏本文，避免错过更新。