当一个 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 也可以封装接口读取一次 PRCLI 可以调用 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 一次性暴露大量工具 schemaCLI 的上下文更短更省 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 之前提出的 PTCProgrammatic 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/listskills/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 解决领域经验与 SOPPTC 则进一步提升多工具编排效率。它们各有边界也各有价值。关键不是追逐某一个新概念而是把这些能力放在正确的位置上灵活应用。
企业级 AI Agent： MCP、CLI、Skills，如何定位、该怎么选、最佳实践。
当一个 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 也可以封装接口读取一次 PRCLI 可以调用 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 一次性暴露大量工具 schemaCLI 的上下文更短更省 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 之前提出的 PTCProgrammatic 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/listskills/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 解决领域经验与 SOPPTC 则进一步提升多工具编排效率。它们各有边界也各有价值。关键不是追逐某一个新概念而是把这些能力放在正确的位置上灵活应用。
