企业级 AI Agent 时代：MCP、CLI、Skills 的正确打开方式

“你的 Agent 接入 MCP、Skills、CLI 了没？” 最近技术圈聚会，这句话的出现频率高得吓人。仿佛不聊 MCP、Skills、CLI 就跟不上时代，不提 MCP 就意味着你的 Agent 落后了。 但真正在企业里落地 Agent 的人心里清楚：问题从来不是缺工具，而是不知道什么时候该用什么工具。 MCP 很火，CLI 很轻，Skills 很灵活。但在企业生产环境里，这三者到底该怎么配合，很多团队其实还没想清楚。有人 All in MCP，结果工具定义塞满了上下文，模型选工具比完成任务还费劲；有人迷信 CLI 省 token，最后光调命令就调了半天，产出却没多少有效信息。 今天咱们把这件事彻底说透，不追概念，只讲实际。

先别急着站队，搞清楚各自的定位

很多人问我一个高频问题：MCP、CLI、Skills 哪个好？我该怎么选？

这种问法本身就反映了思维方式的问题——他们在试图找一个正确答案，然后 All in 这个答案。

但在真实的 Agent 工程里，这种思路几乎必然会导致踩坑。

MCP、CLI、Skills 解决的是三个不同层次的问题，而不是同一问题的三种不同解法。

打个比方，你不会问锤子好还是螺丝刀好，因为你知道它们用在不同的场景。

搭木架用锤子，装家具用螺丝刀，墙上挂画可能两个都得用。

Agent 的工具扩展也是这个道理——你需要先看清楚当前任务落在哪个层次，再决定用什么。

Skills 解决的是 经验怎么复用 的问题。

你的团队做代码发布审查，每次都要人工确认风险等级、核对检查清单、按固定格式输出摘要。这种重复性的专业判断，Skills 负责把它固化下来，让 Agent 每次处理同类任务时，能按团队的规范来执行，而不只是靠模型自由发挥。

它不负责连接外部系统，也不负责执行本地命令，它的核心价值是沉淀组织know-how——这类任务怎么做才能稳定产出符合团队要求的结果。

MCP 解决的是“系统怎么安全接入”的问题。

企业的 ERP、CRM、OA，这些系统有什么特点？涉及身份认证、权限控制、业务审批、数据敏感度。

企业内部的变更系统、合同系统、财务系统，你不可能让 Agent 想调就调，必须有统一的接入层来管住身份、权限和操作边界。

MCP 的 server/client 架构天然适合做这件事——它能暴露 tools、resources、prompts，有标准化的接入方式，也有统一的治理机制。

CLI 解决的是“现场执行怎么更高效”的问题。

当 Agent 已经在本机、代码仓库、容器或 CI 环境里运行时，你需要它执行一些本地的、成熟的、跟开发运维强相关的操作，比如 git 操作、查日志、跑测试脚本、调 kubectl、起停服务。

这些事情用 CLI 天然比走 MCP 更轻便——不需要额外的服务注册，不需要复杂的协议交互，直接调系统命令，执行效率高，上下文占用也小。

所以回到开头的问题，正确的决策顺序不是“先选 MCP 还是 CLI”，而是“先看清楚这个任务落在哪个层次”。

涉及组织经验和流程规范的，找 Skills；涉及企业系统安全接入的，找 MCP；涉及本地命令执行的，找 CLI。

组合拳才是正道，单一方案必然跛脚

从业多年，OneMind 见过太多团队在工具选择上走极端。

有一类团队是MCP 万能论患者，觉得只要把所有系统都接成 MCP，Agent 就无所不能。

结果呢？

MCP Server 越接越多，工具 schema 越来越庞大，模型在选择工具时就开始犯迷糊——上下文爆炸，任务失控，产出一团糟。

工具是接进来了，但 Agent 根本不知道什么时候该用哪个。

还有一类团队是CLI 唯上论，觉得 MCP 太重，CLI 最简洁，最省 token。

但 CLI 能做的事毕竟有限，当你需要 Agent 读企业内的变更系统、查审批状态、写回操作日志的时候，CLI 就抓瞎了。

企业生产环境里，最常见的真实场景是什么？是组合。

我给你们讲一个真实的例子。

我们团队去年做了一个代码发布审查 Agent，最初的设计思路很简单——Agent 读取 PR 信息，生成一个发布摘要。

听起来不复杂，对吧？

但真正跑起来才发现，这个任务根本不是读 PR + 写摘要这么简单。

它需要串起一整套流程：读发布单的状态、确认审批是否通过、查变更窗口是否合规、看 PR 改了什么文件、跑测试是否通过、评估风险等级、最后按公司的规范格式输出发布摘要。

这里面涉及四个不同的系统，三个不同的操作步骤，还有团队多年沉淀下来的检查规则。

如果只用 MCP 行不行？

可以接系统，但本地仓库分析、命令执行会很别扭，而且团队规范的检查规则没法固化到 MCP 里。

如果只用 CLI 行不行？

查变更单、读审批状态、写回结果，这些涉及权限和审批的操作，CLI 根本 handle 不了。

如果只用 Skills 行不行？

Skills 可以把流程和规范固化下来，但它没有连接能力，连接不了任何系统。

最后我们是怎么做的？三样东西一起用，各司其职。

MCP 负责对接企业内的变更平台。

所有涉及身份、权限、审批流的东西，都走 MCP 的受控连接——读取发布单状态、审批人信息、变更窗口、写回审批意见。

为什么要这么走？

因为这些东西必须严格控制访问边界，CLI 直接调 API 会有权限风险，而 MCP 的治理机制能保证操作可追溯。

CLI 负责本地分析和执行。

在命令侧完成 PR 分析、关键 diff 提取、测试日志检查、风险识别。

这些操作发生在本地 Agent 的运行环境里，用 CLI 直接调系统的成熟命令效率最高，而且上下文占用最小——你可以用 jq、grep、git 这些工具把高密度信息提取出来，只把关键结果传给模型做决策。

Skills 负责把团队规范变成 SOP。

公司对发布摘要有固定的字段要求，风险等级有明确的判断标准，检查清单有清晰的边界，哪些情况能发布、哪些情况需要人工复核。

这些规则不是“知识”，而是“方法”——Skills 把它们固化成 Skill 包，让 Agent 处理任何发布审查任务时，都按同一套标准来执行。

边界一清楚，后面运维和迭代就顺畅多了。

当 Agent 的产出有问题时，你很快能定位是 MCP 连接层的权限问题、CLI 的分析逻辑问题，还是 Skills 的规范固化问题。

MCP 的设计陷阱：别把工具列表当成了能力

MCP 社区现在有个很不好的倾向：追求把系统能力完整暴露。

很多 MCP Server 的设计思路是“这个系统有多少个 API，就封装多少个 Tool”。表面上看很全面，实际上是在给 Agent 挖坑。

如果一个 MCP Server 暴露了五十个 Tool，Agent 怎么选？

它需要理解这五十个 Tool 各自的用途、参数、返回值，然后在任务执行时判断该用哪个、不该用哪个。

这个选择本身消耗的上下文和推理成本，可能比实际执行任务还高。

更合理的设计思路是面向任务目标封装工具，而不是面向系统能力封装工具。

还是用发布审查的例子。

变更系统可能暴露了 getChangeOrder、getApprovalRecord、getChangeWindow、updateChangeStatus 等十几个细粒度的 API。如果按这个思路做 MCP，你会给 Agent 一堆底层工具，让它自己拼出完整的发布上下文。

更好的做法是提供一个聚合工具，比如 getReleaseContext，它在服务端调多个底层接口，把发布单信息、审批状态、变更窗口、相关 PR、测试结果打包一次性返回。Agent 拿到的是一个完整的“发布上下文”，而不是一堆需要自己组装的数据碎片。

这种设计的核心思想是把复杂留给服务端，把简单留给 Agent。

服务端能做聚合、做过滤、做默认处理，Agent 只需要调用一个目标明确的工具，然后拿结果做决策。

这比让 Agent 在一堆细粒度工具里自己规划调用路径靠谱得多。

当然，这里有个度的问题。

工具粒度太粗，Agent 可能丢失必要的灵活性；太细，上下文和推理成本又会爆炸。

实际设计中需要根据场景权衡，但原则是明确的：从目标任务出发设计工具，而不是从系统能力出发堆砌工具。

Skills 的设计陷阱：别把知识库当成了方法库

Skills 这个概念这两年火起来了，但我观察下来，很多团队对它的理解有偏差。

一个常见的误区是：把 Skills 做成了企业内部知识库的另一种形态。

把历史方案、案例库、最佳实践文档全部塞进 SKILL.md，美其名曰让 Agent 学习团队经验。

结果呢？

Skills 越来越臃肿，上下文占用越来越高，模型分不清哪些是强约束、哪些是参考信息，产出一致性反而下降了。

还有一种误区是把 Skills 当 RAG 用。

RAG 的核心场景是查资料——给模型提供一个知识库，让它检索相关信息来回答问题。

Skills 不一样，它的定位是“固化方法”，不是“存储知识”。

RAG 解决的是这个问题该参考什么，Skills 解决的是这类任务该怎么做。

这两个问题完全不同。

查资料需要广度，需要让模型看到尽可能多的参考信息；固化方法需要精度，需要让模型严格按既定流程和边界执行，不允许自由发挥。

所以 Skills 的正确打开方式是：短主体、长尾分离。

SKILL.md 里只写最核心的内容——这个 Skill 在什么条件下触发、目标是什么、关键步骤是什么、必须遵守的边界是什么、产出格式是什么。

这是最精炼的“方法骨架”，是 Agent 执行时必须严格遵守的强约束。

长背景信息、参考案例、历史方案这些东西，放到 references 目录里，按需引用，不影响主流程的上下文。固定格式模板放到 template 目录。重复性的校验逻辑写成脚本，放到 scripts 目录。

一个健康的 Skill 结构是：

一个精炼的 SKILL.md + 按需引用的 references + 固定格式的 template + 可执行的 scripts。Agent 触发 Skill 时，先读 SKILL.md 掌握方法骨架，再根据需要查 references 获取背景信息，用 template 格式化输出，用 scripts 做自动化校验。

CLI 和 MCP 的 Token 之争：该关注的不是形式

CLI 比 MCP 省 token这个说法最近很流行。

理由是 MCP 的工具 schema 需要占上下文，而 CLI 的命令形式更简洁。

这个说法对不对？

在某些场景下是对的，但它把问题过度简化了。

CLI 省 token 的前提，是你能在命令侧完成结果的过滤、聚合和截断，把最关键的信息交给模型。

如果你只是用 CLI 调了一个接口，然后把完整的原始输出全部丢给模型，上下文照样爆炸，一点也省不出来。

举个栗子，Agent 想看一个 PR 改了哪些文件。

你直接调 gh pr diff，返回的是完整的 diff 内容，可能几千行。

但如果你在命令侧先做处理，用 gh pr diff --stat 拿到变更统计，用 jq 提取关键字段，用 grep 过滤出核心改动，把这些高密度信息汇总成一个精简的摘要再交给模型，上下文占用完全不是一个量级。

省 token 的核心不在于用 CLI 还是 MCP，而在于你有没有在数据源侧做足够的加工和过滤。

同样是用 MCP，调用 getReleaseContext 这种聚合工具，比调用 getChangeOrder、getApproval、getDeploymentWindow 等十几个细粒度工具，前者对 Agent 的上下文压力小得多。

反过来，CLI 也有可能变成上下文噪声入口。

你用 CLI 调了十个命令，每个命令都返回一堆原始数据，Agent 光整理这些输出就累死了，还怎么做决策？

所以我的建议是：别在 用 CLI 还是 MCP 这个形式问题上纠结，把注意力放在 如何让 Agent 拿到它真正需要的那部分信息上。 做到了这一点，不管用什么形式，token 效率都不会差。

结语

写了这么多，最后想说的其实就一句话：企业级 Agent 落地的真正挑战，不在于选哪个协议，而在于怎么让多个协议配合着服务好具体的业务任务。

MCP 不是银弹，CLI 也不是万能钥匙，Skills 更不是知识库的替代品。

它们各有各的擅长领域，各有各的局限。你需要做的，不是追随某个概念，而是深入理解每一个工具的本质，然后根据实际任务的需求，把它们放在正确的位置上。

那些在生产环境里稳定跑了十几种任务的团队，没有一个是靠只用 MCP或只用 CLI做到的。

他们都有自己的三叉戟——用 MCP 做安全的系统连接，用 CLI 做高效的现场执行，用 Skills 沉淀可复用的组织经验。

这才是企业级 Agent 的正确打开方式。