当一个 Agent 真正进入企业生产环境后，问题很快就不再是有没有工具，而是如何扩展 Agent 的能力 — 将 Agent 连接到各类企业 IT 设施，以实现更复杂的自动化工作流。 MCP、CLI、Skills 看起来都能让 Agent 更强大，但它们解决的是三类不同问题，在不同的场景下合理的组合与应用，才能发挥最强的威力。

本文为大家解读：

如何正确、高效地组合 MCP、CLI、Skills，让你的企业 Agent 发挥最大效能。

01 先别争工具，先分清层级

在做出决策之前，我们应该了解的是 MCP、CLI、Skills 这三者的定位、组成与工作层次，而不是问哪一个更“高级”，更不是盲从“MCP 已死，现在都用 CLI ”这样吸引眼球的武断结论。

• Skills 的核心价值是复用组织知识。Skills 并不是又多了一个工具协议，而是把指令、标准流程（SOP）、模板、参考资料、脚本和校验规则等打包成一个可复用的知识包。它解决的是 know-how，即“某一类专业任务如何稳定完成与产出”的问题；而不是“怎样接入一个新系统”的问题。

• MCP 的核心价值是标准化连接外部系统。它围绕MCP host/client/server 组织能力，MCP Server 可以暴露 tools、resources、prompts，并通过本地 stdio 或远程 HTTP 方式接入。MCP 可以承载标准化的远程系统访问、资源获取、身份认证授权、用户确认和统一治理。

• CLI 的核心价值是贴近“工作”现场。当 Agent 已经在本机、代码仓库、容器或 CI 环境里工作时，直接调用 find、grep、git、gh、jq、kubectl、python 等 这类成熟的工具命令，通常会更轻量级，也更节约 token 。

三者会有重合，但不改变基础定位

在真实工程中，同一个场景可能有多种实现方式。比如 Agent 要从 ERP 查询信息：可以用 MCP 封装成查询工具；也可以写成 CLI 命令直接调用 ERP API；还可以在 Skill 中固化查询方法、参数说明和查询脚本。

但这并不改变三者的基本分工，很多时候需要看当前问题更“接近”哪一个。

02 简单选择题：三个核心问题

生产级 Agent 的工具选择，最好不要从某个技术偏好开始，更不是简单听取网络上绝对的建议，而要从你的 Agent 任务的特点和约束开始。

你可以先问三个问题：

• 问题一

这个任务是否必须连接远程系统（比如企业内的 ERP/CRM/OA 等），特别是需要带上“用户是谁、能做什么”的身份语义？如果是，则使用 MCP。

• 问题二

这个任务的执行过程中是否要在本地环境（工作树、容器等）中执行已有的命令，比如读取文件、执行脚本等。如果是，考虑 CLI。

• 问题三

这个任务是否会依赖团队内部的隐性知识、流程模板或格式规范？且这些知识具有一定重用价值，如果是，考虑用 Skills 来沉淀它们。

注意，很多复杂任务的答案并不是“只选一个”。例如你的代码发布审查的 Agent 既要读取变更系统，又要分析本地 PR，还要按发布模板生成摘要。这种场景里，组合应用就是很自然的选择。

03 不要互相取代，而是组合应用

一些争论之所以容易走极端，是因为只看到了工具能力的重合：查一个订单，CLI 可以调接口，MCP Tool 也可以封装接口；读取一次 PR，CLI 可以调用 gh，也可以用 GitHub MCP；生成一份摘要，提示词可以写，Skill 也可以写。

但在企业生产环境里的最佳方式是：

在清晰定位与职责的指导下，组合应用 MCP/CLI/Skills，以获取最大效果。

继续以代码发布审查的 Agent 为例。它要完成的不是简单写一段摘要，而是要把发布单、审批状态、代码变更、测试结果、风险分级和上线检查清单串起来。如果只用 MCP，本地仓库和命令的效率会被浪费；如果只用 CLI，审批系统、权限控制与回写动作就不太方便；如果只用 Skills，它又只能固化流程，不能真正连接外部系统。

但你可以把它们组合在一起使用：

在这个例子里

• MCP 接企业内的变更平台：负责读取发布单、审批状态、负责人、变更窗口，也负责必要的回写动作。因为这些系统往往涉及身份、权限、审批流等，适合放在受控的连接层里。

• CLI 则负责本地动作：PR 改了哪些文件、关键 diff 是什么、测试是否通过、日志里有没有异常。它可以在命令侧先把信息整合，再把结果交出去 — 比如标题、评审状态、文件列表、失败测试和错误日志等。

• Skills 负责把公司要求固化成稳定规则与流程：上线摘要必须包含哪些字段，风险等级如何判断，检查清单，输出格式，生成后如何校验。它不负责连接系统，也不执行命令，而是把公司规范和格式沉淀成 “SOP 胶囊”。

这种组合的好处，是边界清楚，问题也更容易定位。

所以，企业级 Agent 的正确路线不是“CLI 取代 MCP”，也不是“Skills 包打一切”，而是根据任务性质灵活组合。连接业务系统时要重视治理，处理本地执行时重视效率，沉淀组织经验时则重视可复用，三者各司其职，共同打造真正可落地的生产级 Agent。

04 MCP：不要做成 REST API 镜像

MCP 很适合企业系统集成，但它不应该被做成“每个 REST 端点一个 tool”。Agent 需要的是面向任务目标的工具，不是简单的后端 API 列表（特别是有一些把企业 API 直接转换为 MCP Tool 的工具）。这会导致：

工具定义占用过大上下文，模型选择工具的难度上升，任务容易失控。

这就像给新人发一本 300 页通讯录，然后要求他自己判断该找谁办事。

那么如果确实需要把企业应用中的大量能力用 MCP 暴露给模型怎么办？

更好的方式是给 Agent（模型）一个“服务台”：

先说任务目标，服务台返回最相关的少数 Tools 入口；模型在这少数的 Tools 中确定入口再带着明确参数去执行 — “先检索、再调用”的方式。

MCP 的设计重点不是简单的“把系统能力全部暴露出来”，这会增加模型的推理负担，很容易产生结果漂移。而是尽量从目标任务出发，封装可靠的工具与资源调用。

例如，与其暴露 getIssue、getApproval、getDeploymentWindow 等十几个细碎工具，不如提供一个“读取发布上下文”的聚合工具，把细节留给服务侧（当然，实际应用中你需要从多方面权衡工具的粒度）。

05 CLI 替代 MCP？别急着下结论

最近有种观点很流行：CLI 已经“取代” MCP。

理由也很直接：CLI 更简单；相比 MCP Server 一次性暴露大量工具 schema，CLI 的上下文更短，更省 token。比如，会拿 GitHub MCP 与 gh 等命令行方式对比，强调 MCP 的 schema 开销和工具描述如何挤占上下文窗口。 

这又是一个把局部事实扩大成绝对结论的问题。

CLI 和 MCP Tool 在很多场景里的确都能完成同一件事：代码库管理、调接口、查资源，既可以写成命令行脚本，也可以封装成 MCP 工具。

但问题不在于谁能不能做，而在于这个任务处在什么场景下、更适合谁：

• CLI 更擅长执行侧：本地仓库、构建测试、批处理脚本、成熟的厂商命令、已有的运维工具调用。

• MCP 更擅长连接侧：企业的 CRM/OA/合同/财务等系统等需要身份权限、脱敏、审批和跨团队复用的场景。

它们有重合，但重心并不一样。

更重要的是，CLI 也未必天然省 token。

CLI 省 token 的前提，是命令侧可以做过滤、聚合和截断等，只把“高密度”的结果交给模型。

例如，Agent 想知道一个 PR 改了哪些文件，不需要把完整 PR 页面/评论和 diff 等全部读回来，你可以在命令侧用--json、--jq 或 jq -c 先做裁剪。交给模型决策所需的必要信息，而不是工具原始输出。

而如果你只是简单的追求 CLI 的形式，它一样可以变成上下文噪声入口。换句话说：

省 token 的不是 CLI 这个形式（至少不仅仅是），还需要结合受控输出、结果摘要和最小化必要信息。

06 Skills：不要做成知识库，而是方法和流程

Skills 是一个伟大的 Agent 工程创新。

但我们认为 Skills 对企业 Agent 的最大价值，不是给 Agent 再堆一层知识，而是把企业里反复出现的工作方法，沉淀成可复用的 SOP。

在企业 Agent 场景中，很多自动化任务真正难的是：

让 Agent 每次都能按同一套流程稳定、可控的完成任务，且不失灵活性。

比如代码发布前检查哪些风险、合同按什么格式输出、客户投诉如何分类、代码变更后跑哪些门禁等等。过去这些往往靠老员工提醒、复制模板、人工检查；后来有一些企业内的流程系统；再后来有了 Agentic Workflow 等。

现在，很多场景中一个 Skill 就可以把这些流程、模板、规则和脚本固化下来，让 Agent 处理同类任务时更稳定、更可控。

但要注意的是不要把 Skill 误用成大知识库 — 比如把历史方案、案例、异常说明、业务背景全部都塞进一个SKILL.md。这样做表面上完整，实际很容易慢慢变成“屎山 Skill”：内容太长，一触发就占用大量上下文，也不利于复用；规则也太散，模型分不清强约束和背景；后期维护成本也会越来越高。

Skills 也不是 RAG 的替代品。RAG 适合处理大量知识的检索和问答；Skill 适合固化任务流程、边界、模板和校验方式。

简单说，RAG 解决“查资料”的问题，Skill 更适合解决“按什么步骤做、按什么格式输出、按什么规则检查”。

合理的 Skill 形态是：短主体 + 参考资料 + 模板 + 脚本。

SKILL.md 只写最核心的内容：触发条件、任务目标、关键步骤、必须遵守的边界和产出格式。长背景放到 references，固定格式放到 template，重复校验交给 scripts。

07 技巧：MCP 应用中的 PTC 

基于 MCP Tools 的传统 Agent 的工作方式是：

当 Agent 任务只涉及一两个工具时，这种方式还可以接受。

但一旦要模型决策并连续调用很多个工具时，链路就会变得很长。每一步都要等待模型推理和工具返回，工具越多，延迟越明显。而更重要的是，这其中每一步你都需要把多个 Tool Schema 和 Tool 调用结果输入模型来完成推理，而最终可能只为了获得少量的信息。

所以更实用的方式是 Anthropic 之前提出的 PTC（Programmatic Tool Calling），或者叫 Code Mode。

即让 Agent 不再一个个推理和调用多个 Tool，而是先生成一段编排逻辑（代码），在沙箱中一次性调用多个 MCP Tool、CLI 或内部 API，把结果数据汇总、过滤、校验后，再交给模型来决策后续步骤。

可以简单表示为：

这种模式的价值不是让 Agent 获得无限自由，而是把多工具编排从多个对话回合下沉到沙箱中的受控脚本执行。这样可以减少等待、降低中间上下文噪声，也更适合复杂企业任务。

当然，这也有一定的条件和约束：

• PTC 适合流程相对稳定、工具调用依赖清晰、结果可校验、权限风险可控的多工具任务；这样的任务收益更大。

• 在企业 Agent 中的 PTC 一定要在受控（沙箱+权限边界）环境下进行，不能让 Agent 随便访问系统和调用脚本。

08 番外：Skills Over MCP

现在 Skills 的“声音”明显要大过 MCP，或许底层的逻辑是：

在真实的应用中，问题往往不是有没有工具，而是 Agent 能否知道如何正确的使用工具。

虽然 MCP 可以把数据库、浏览器、DevOps、企业系统等工具暴露给 Agent，但工具描述通常只能说明“这个工具能做什么”，很难承载复杂的多步骤流程、规则和工具编排经验，而这些更依赖 Skill。 

所以目前 MCP 社区工作中出现了“Skills over MCP”（未发布）。即：

通过 MCP 通道，获取与工具配套的 Skill — 流程编排、使用规则、甚至调用脚本等。换句话说，MCP Server 未来可能不只告诉 Agent 有哪些工具，还可以告诉 Agent“这些工具应该怎么组合使用”（skills/list，skills/get）。

比如：合同系统不只是暴露合同查询、条款提取、风险标注等工具，还可以同时提供合同摘要 Skill，付款条款审查 Skill 等。

它尤其适合几类企业场景：Skill 与某些 MCP Server 的工具强绑定；Skill 需要随服务端动态更新；一个 Skill 需要编排多个 MCP Server 的工具。

这样，MCP 的价值就不只是多接几个工具，它可以向下连接系统、数据和工具，向上交付技能（Skills over MCP）、甚至界面（MCP Apps）。MCP、CLI、Skills、Code Mode 的关系，也会更像一个分层协作栈，而不是彼此替代的几个孤立选项。

不妨以一个例子来展示它们的协作关系：

综上，真正值得关注的不是 MCP、CLI、Skills 谁取代谁，而是企业 Agent 进入生产环境后，能力扩展已经不再是“多接几个工具”这么简单。

MCP 解决连接与治理，CLI 解决本地执行效率，Skills 解决领域经验与 SOP，PTC 则进一步提升多工具编排效率。它们各有边界，也各有价值。关键不是追逐某一个新概念，而是把这些能力放在正确的位置上，灵活应用。