LLM与外部系统交互：CLI、MCP与SKILL的三层架构与选型指南

1. 先搞清楚这三者分别在“哪一层”做事

1.1 我的第一次“让模型动手”的失败经历

去年带一个内部数据项目，团队里A同学提出了一个很常见的需求：让大语言模型（LLM）自己查数据库、算指标、生成日报，而不是每次都由人把数据喂进去。听起来不复杂，但真正跑起来才发现，最大的障碍根本不是模型聪明不聪明，而是“模型怎么碰到外部系统”这个问题一直没想清楚。

最初我们走的是最原始的路子：把命令行工具（CLI）暴露给模型，让它自己敲命令。做法本身没毛病，但落地时天天出事——命令偶发解析失败、超时、返回格式不稳定、权限边界几乎为零。后来我们换了模型上下文协议（MCP）的方式，把查询封装成标准化工具，情况立刻稳了不少。再后来又观察到另一个现象：同样是稳定的MCP工具，在“多步骤流程”场景下又不够用，于是又引入了技能（SKILL）层的封装。

那次折腾让我彻底明白一件事：CLI、MCP、SKILL这三种方式，本质上是LLM与外部系统交互的三层不同设计，不存在谁取代谁。很多人一上来就问“哪个最好”，其实这个问题本身就是错的。正确的问题是“你希望模型在哪个层面接管控制权”。

1.2 一句话定位：CLI是手，SKILL是剧本，MCP是插座

我用一个比喻帮团队里的新人快速建立画面感。

如果把LLM比作一个能力很强但刚入职的实习生，那么：

• CLI是“手”：你直接告诉他“你去终端执行这条命令，把结果拿回来”。优点是几乎所有系统都有命令行入口，缺点是这个实习生必须自己学会准确敲命令、看懂报错、处理各种异常返回。
• MCP是“插座”：你给他一个标准化的接口面板，上面写着“查订单”“查库存”“发通知”，每个都带输入输出说明。他只需要按说明调用，不需要关心背后是调了数据库还是调了哪个内部系统。这就是模型上下文协议解决的核心问题——把工具标准化、可发现、可复用。
• SKILL是“剧本”：你给他一份操作手册，上面写着：先做A，如果A的结果满足条件再做B，最后按固定格式输出。他不一定知道每个步骤背后调用了什么，但他能完整地把整个流程跑完。这也是技能层最大的价值——把“一次交互”升级为“一次任务”。

所以你看，CLI解决的是“让模型能动手”，MCP解决的是“让工具好找到、好调用”，SKILL解决的是“让流程能跑完”。三层分工完全不同，但实际落地时它们往往互相配合。这也是为什么我后来跟团队定了一个默认架构：CLI打底、MCP连接、SKILL编排。你先记住这个结论，后面我会逐一展开。

2. 再看原理：协议、权限与执行路径的根差异

2.1 MCP：把工具标准化成可发现的资源

MCP（Model Context Protocol）这个名词听起来很重，其实它的设计目标很短小：让原本散落在各系统里的能力，变成LLM可以主动“发现”和“调用”的资源。为什么需要它？因为在此之前，你想让模型调用一个工具，就得把工具的说明写进系统提示词（system prompt）里，而且每个工具的说明格式都不一样，模型经常理解错。

MCP的设计思路是“客户端-服务器（client–server）”模型。LLM所在的环境是客户端，它负责告诉你“我这边有哪些工具可用”；外部系统那边做一个MCP服务器（MCP server），把真实能力包装成统一的工具（MCP tool）暴露出来。关键点在于：每个工具都有统一的JSON输入输出描述，客户端可以用同一个格式去发现、注册、调用，不再需要为每个系统适配一套私有格式。

我拆一下它的核心要素：

• 工具注册（Tool Registration）：MCP服务器启动时，把自己提供的工具列表和参数Schema注册出来。LLM侧的运行环境拿到这份清单后，就能在对话中动态决定调哪个工具。
• 资源（Resources）：除了“调用”，MCP还支持“读取”。比如一个服务器的状态信息、一份配置文件，都可以作为资源暴露，让模型只读访问。
• 协议交互：客户端与服务器之间通过标准化消息传递调用请求和返回结果，不是模型在提示词里瞎猜参数，而是由协议层明确告诉你“参数该是什么结构”。

用一句话总结：MCP最本质的贡献是把“提示词里的工具说明”升级成了“运行时可发现的协议”。副作用也很明显——引入了一套独立的基础设施，连接、生命周期、安全认证都要处理。它不是银弹，但确实解决了大团队、多系统场景下的标准化难题。

2.2 SKILL：流程内置在提示里，靠模型自己编排

SKILL这个词在不同产品里的实现不太一样，但我理解它的本质是一致的：把一套完成某个目标的步骤、边界条件和输出规范，打包成一个可以被LLM直接加载执行的单元。它做的事情是“流程编排”。

举个例子，你让LLM“生成一份周度销售报告”。如果没有任何技能封装，模型可能会自由发挥，也许先查数据，也许先写摘要，也许漏掉对比上周的环节。如果封装成一个SKILL，它内部就定义了固定步骤：第一步读取日期范围参数；第二步调用订单查询工具；第三步计算环比、同比；第四步套用报告模板输出。模型拿到这个SKILL，就像拿到一份剧本，照着演就行。

这里有一个容易混淆的点——SKILL和RAG（检索增强生成）不是一回事。RAG解决的是“模型不知道的知识怎么补进去”，SKILL解决的是“模型不知道怎么做时，给它一套操作流程”。两者可以组合，但目标不同。另一个容易混淆的地方是SKILL和“多智能体”的关系。SKILL不一定是多个模型协作，完全可以是同一个模型按剧本顺序执行多个步骤；多智能体则更强调角色分工。所以SKILL更轻量、更实用。

从实现上看，一个SKILL通常包含：

• 触发条件：什么时候该调用它；
• 输入参数定义：需要哪些结构化信息；
• 内部步骤：一个有序的操作列表，每一步都对应一个工具、一次检索或一段计算；
• 输出规范：结果的格式要求，比如必须是JSON或固定模板。

它的强项是“人话直达流程”——不去纠结底层协议，而是把精力放在步骤设计和边界条件上；弱项也很明显，如果底层工具不稳定，SKILL再漂亮也白搭。这正好说明，SKILL和MCP其实是不同层面的东西。

2.3 CLI：最老最直接，但要让模型学会“人话”

CLI（命令行接口）的历史比一切LLM基础设施都长，几乎每一个系统都逃不开它的影子。LLM本身以文本为输入输出，而CLI接受文本命令、输出文本结果——这种天然的亲和性，让CLI成了LLM接外部系统的第一个入口，而且至今没有被完全替代。

我常形容CLI像是“裸奔的接口”：没有注册中心、没有权限协商、没有结构化错误码，通通没有。你需要用一段提示词告诉模型“请执行psql -h localhost -U read_only -d appdb -c "SELECT count(*) FROM orders;"”，然后祈祷它不要写错参数、不要被环境变量干扰、不要超时。

在实际工程里，CLI模式通常意味着三层能力需要自己补齐：

• 命令生成：模型需要把自然语言目标翻译成精确的、带正确参数的命令；
• 输出解析：命令行的返回通常是非结构化的文本流，需要额外解析成结构化数据；
• 异常处理：退出码非零、stderr有内容、超时挂起，这些都需要程序逻辑去兜底。

这也是为什么它便宜但脆。便宜在于几乎零成本接入，任何系统只要有shell就能用；脆在于每一环都得靠提示词和外围代码去补。很多团队一开始都是CLI起步，后来才发现维护成本全散在“看不见的地方”。不过，我后面会讲，CLI恰恰可能是三种方式里最值得保留的一个——因为它能成为MCP服务器的内部实现，这就把它的“弱点”给补上了。

2.4 三种方式的本质差异对照

为了帮大家把视角拉高，我列一个对比表。这个表不是结论，而是帮你看清楚“它们在为同一个问题提供不同的解”。

如果你读完表格还是觉得抽象，我给你一个大白话归线：CLI是“底层能力”，MCP是“把底层能力包成标准接口”，SKILL是“把标准接口按剧本串起来”。下一章，我用同一个任务把这三种方式各写一遍，你应该会更有实感。

3. 同一个任务，三种方式各写一遍（实测对比）

3.1 任务设定：让模型查数据库并汇总指标

为了对比公平，我设定一个真实的业务任务：让LLM查询昨天的订单数据，计算出总订单数、总销售额和平均客单价，然后输出一段简要的日报总结。

这个任务不大不小，正好够看出三种方式在接入过程、稳定性和扩展性上的差别。我们假设数据库是一个常规的MySQL实例，只读账号已经准备好，终端可以访问。

3.2 CLI实现：一段system prompt搞定，但脆得很

CLI方案最直接。系统提示词大概长这样：

你是数据库操作员。有一个只读MySQL账号，连接参数如下： host: db.internal.local user: readonly password: 【按环境变量注入】 database: shop 当用户要求查订单数据时，请按以下步骤操作： 1. 用mysql命令执行查询，注意输出格式使用 -t -A 选项，避免表格线干扰； 2. 计算结果需要你自行对比多行结果； 3. 输出时给出汇总数字和一段中文总结。

实际调用时，模型会生成类似这样的命令：

mysql -h db.internal.local -u readonly -p$MYSQL_PWD -D shop -t -A \ -e "SELECT COUNT(*), SUM(amount), AVG(amount) FROM orders WHERE created_at >= CURDATE() - INTERVAL 1 DAY AND created_at < CURDATE();"

优点非常明显：从定方案到跑通，十分钟以内。缺点在第一次测试里就暴露了：

• 模型对命令的拼写不一定对，尤其是-t -A这种非日常参数；
• 返回结果格式不太稳定，数字带了|分隔符，解析麻烦；
• 一旦SQL写错，报错信息直接堆到stderr里，模型经常“看不懂”。

我们当时为了稳定解析输出，额外写了大概200行正则和容错代码。后续每加一个新查询场景，就得在系统提示词里追加一段说明，系统提示词不断膨胀，这是CLI路线最典型的“隐性负债”。

3.3 MCP实现：定义一个查询工具，稳定可控

MCP方案需要多做一些前期工作：先写一个MCP服务器，把查询能力包成工具。流程上分三步：

第一步，定义工具。我在MCP服务器里注册一个工具，格式类似：

{ "name": "query_daily_orders", "description": "查询指定日期的订单汇总指标，返回订单数、总销售额、平均客单价", "inputSchema": { "type": "object", "properties": { "target_date": { "type": "string", "description": "目标日期，格式YYYY-MM-DD" } }, "required": ["target_date"] } }

第二步，在服务器内部实现真正的查询逻辑。这一步可以直接复用CLI那套命令，也可以用数据库驱动直接查询，区别在于外部考虑：包在MCP服务器里之后，模型不再直接拼SQL，而是只传一个target_date参数。这个看似微小的变化，实际把很多乱象消灭了——参数从模型自由发挥变成了受控枚举。

第三步，接入LLM运行环境，让客户端发现这个工具。之后，模型在对话里看到“有这个工具可用”，会自动按Schema填参数调用。我们实测下来的效果是：只要服务器端SQL逻辑没错，模型几乎不会抱怨格式问题，因为返回结果已经由服务器处理成结构化数据再回传。

代价是前期搭建成本明显上升：服务器部署、鉴权、客户端连接、日志追踪，每一项都是新工作。但它换来的是：系统提示词不用天天加说明，新查询场景直接加工具注册就行，排查问题也变成了看工具日志而不是猜模型写了什么命令。

3.4 SKILL实现：把整个流程封装成一次性指令

到了SKILL这一步，我们关注的就不再是“单次查询”，而是“整个日报流程”。我会把“查昨天订单、计算指标、生成总结”封装成一个可复用的技能块，大概是这个形状：

SKILL: 生成每日订单日报 触发条件: 用户要求生成日报/查看昨日汇总 输入参数: - report_date: 可选，默认昨天 执行步骤: 1. 调用 query_daily_orders 工具，目标日期设为 report_date 2. 如果结果中订单数为0，则直接输出文案“昨日暂无订单” 3. 否则，计算/提取三指标：订单数、总销售额、平均客单价 4. 按以下模板输出： “昨日（${report_date}）共成交 ${orders} 单，总销售额 ${revenue} 元，平均客单价 ${avg} 元。较前一周期……（可选用对比工具补充）”

这个方案的关键在于：步骤顺序、异常分支、输出模板都是预先定义的，LLM不是自由发挥，而是按剧本走。从实际体验上看，它的最大好处是“同一个任务不管谁发起、不管上下文多乱，最终输出都长一个样”，对下游对接非常友好。

当然SKILL也有代价。第一个代价是“设计成本”——把流程拆成步骤、定义异常分支，需要业务方和技术方一起想清楚；第二个代价是“惰性”——一旦SKILL写好，团队成员可能不再质疑流程本身，过段时间会发现步骤过时了但没人改。这也是为什么我们后来规定，SKILL必须定期复盘，不能写完就忘。

3.5 三种实现的宏观对比

我把同一个任务的实测感受汇总一下，供大家参照：

看到这里你应该能感受到，三种方式不是替代关系，而是不同抽象层次的选择。CLI最快但最不可靠，MCP可靠但需要基建，SKILL最稳但最需要设计。接下来最关键的问题就是：实际项目里到底怎么选？

4. 选型判断：交付形态决定技术路线

4.1 场景一：内部工具链，优先“CLI打底+MCP接缝”

如果你的项目是内部数据平台、运维辅助、批量任务这类场景，我强烈建议你考虑一种组合：底层实现多用CLI，对外暴露用MCP。

为什么？内部工具链往往系统老、接口乱、文档缺，但每个系统一定有命令行可用。让MCP服务器直接去调各种CLI命令，等于把“模型-系统”之间的一大段复杂对接收拢到一个人为可控的适配层里。模型只和MCP服务器打交道，服务器内部再通过子进程调CLI、解析输出、转换结构。这样一来，CLI的碎片问题被隔离了，MCP的标准化优势被保留了。

举个例子，我们内部某个统计脚本原本是一堆Python脚本加Shell包装，既不安全也没接口。后来我让团队写了大概200行MCP服务器代码，把几个常用脚本包成工具注册。效果立竿见影：调用稳定、参数可控、日志齐全。这个200行的服务器，比之前反复调提示词不知道划算多少。

4.2 场景二：对外产品，把SKILL当“功能开关”

如果你的场景是做一个面向外部用户的产品，比如智能客服、个人助理、垂直领域的问答机器人，那么你需要考虑的层级又不一样了。外部用户不会关心你调用数据库用的是什么协议，他只会关心“这个流程是否稳定、结果是否符合预期”。

这种场景下，SKILL几乎是刚需。因为外部产品的交互路径必须要固定，用户问“帮我订票”，你不能让模型自由发挥每一步，而要让模型走进一个固定的订票SKILL里，每一步的卡点、异常话术都在SKILL里定义好。这会让产品的行为变得可预期，也更方便产品经理去描述“用户会经历什么”。

另外，对外产品通常有严格的权限设计，如果把权限直接暴露给LLM的“自由发挥”，风险会成倍放大。SKILL因为是预先设计的步骤，天然带了一层限制；再配合MCP工具层的鉴权，权限设计就有双重保障。我个人在产品项目上的经验是：CLI绝不直接暴露给终端模型，SKILL和MCP是产品层唯一可选的组合。

4.3 场景三：快速验证/原型阶段，CLI永远是第一选择

那有没有场景是直接上CLI就对的？有——原型验证阶段。

比如你想验证“LLM能不能解决这个业务问题”，这时候你根本不关心基建长什么样，你只需要尽快得到一个好坏结论。这种情况下，写提示词让模型跑几个命令，是最快的验证路径。我自己的习惯是：第一版一定先用CLI跑通，哪怕结果不稳定，至少能证明“路走得通”；一旦证明方向可行，再回头补MCP适配层和SKILL编排。

这里我想多说一句：很多人一上来就纠结基础设施，反而把问题本身的验证拖慢了。技术方案是为问题服务的，验证阶段最忌讳过度设计。

4.4 我的选型判断清单

把上面的逻辑提炼成一个简单清单，方便大家对照自己的情况：

• 你有多个外部系统需要接入，且接口风格差异大？→ 考虑MCP适配层，不要裸露CLI给模型。
• 你的核心价值在“把一件事稳定跑完”？→ 考虑SKILL编排，固定步骤和输出。
• 你还在验证想法、还没确定该不该投入建设？→ 先用CLI快速跑，别急着搭框架。
• 你的系统需要面对外部用户，且权限监管严格？→ 不要直接暴露CLI，至少加MCP层，最好再加SKILL层。
• 你的团队对提示词工程很有经验，但缺基础设施人手？→ CLI也能出活，优先考虑“控制面在代码侧”的方案。
• 你的团队有平台工程能力，且对接方多？→ 大胆上MCP，长期回报极高。

清单不追求绝对正确，但至少能帮你少走一半弯路。接下来我讲的一章更实际，是我在生产环境里踩过的坑，希望你看完能绕开。

5. 我在生产环境里踩过的坑，三种方式各有各的坑

5.1 CLI方向：stdout和stderr混在一起，解析全线崩溃

有一次我们跑一个批量导出任务，模型调用了一个CLI工具导出Excel报表。日志显示工具执行成功，退出码也是0，但模型输出的结果一直是空的。查了半天，最后发现问题是：这个工具把警告信息打到了stdout，真正的数据反而在stderr。我们的解析代码只看了stdout，数据丢了。

这个案例也许极端，但它揭示了一个CLI路线的普适问题——你永远无法假设命令行的输出规范。有些工具调试打印走stdout，有些走stderr，有些在stderr里放警告，模型不知道该看哪边，解析代码也不知道。

我的修法有两条：首先，在CLI封装层统一做输出重定向处理，把stderr单独接住，并约定“stderr非空即警告但不必然报错”；其次，在代码里对返回文本做格式嗅探，不预设stdout一定有效。与其教模型“看哪边”，不如让代码侧先把两边都收集起来，再把干净的结果交给模型。

5.2 CLI方向：参数转义和超时是隐性大坑

第二个CLI大坑是参数转义。模型生成命令时，经常把特殊字符直接拼进去。有一次任务需要查询包含引号的字符串，模型生成的SQL直接把引号拼坏了，数据库端报错，而模型完全没有意识到自己需要转义。后来我们在封装层强制要求所有外部参数必须经过参数白名单校验，不允许模型自由拼接命令片段。能写成结构化参数的绝不让它出现在命令字符串里。

还有一个必须提的坑：超时挂起。CLI进程一旦卡在某个交互式提示上，模型会一直等下去。我们的兜底方案是所有外部命令必须在有限时间内返回，封装层统一加超时控制，超时后杀掉进程并返回明确的错误信息。这块经验后来也带进了MCP服务器实现里——MCP服务器内部调CLI时，同样要先包一层超时逻辑。

5.3 MCP方向：连接堆积和工具膨胀

MCP给我印象最深的坑不是协议本身，而是连接管理。MCP服务器和客户端之间是一次次调用关系，但如果每个会话都新建连接而不复用，很快就会出现连接堆积。我们曾经在测试环境看到几百个空闲连接，端口被占满，新会话反而连不上。

解决办法是在MCP客户端侧引入连接池，做超时清理。这一点很多人一开始根本注意不到，因为本地Demo完全暴露不出来。到生产环境，并发一上来，连接管理就变成第一优先级的正经问题。

第二个坑是工具膨胀。MCP的价值在于“可发现”，但可发现也会带来副作用——工具太多，模型在每次对话里都要“思考”到底用哪一个，不仅响应变慢，还更容易选错工具。我们用下来的经验是：工具的粒度要控制在“能完成一个明确子任务”的范围，不要把一个完整业务流程拆成上百个细碎片工具。能合并的合并，能不注册的就不注册。记住一个原则：工具是给模型用的接口，不是给开发者的函数库。

5.4 MCP方向：鉴权与内网暴露边界

MCP服务器本质是一个独立服务，只要独立服务就会有暴露面和生产问题。我们踩过一次很低级的坑：MCP服务器部署在内网，某个马虎的配置让它把接口暴露到了公网，虽然没有造成数据事故，但安全审计时被点名。后来我们约定：MCP服务器默认只监听内网地址，外联全部走网关鉴权。

此外，MCP连接断开后的重连逻辑、心跳检测、幂等处理也必须提前设计。特别是涉及写操作的工具（比如发送通知、创建工单），一定要做幂等——同一请求重复发送不能产生两个工单。这个经验来自一次测试环境的重放事件，当时重放请求导致测试工单翻倍，调试了半天才定位。

5.5 SKILL方向：一次成功、二次失效的“剧本幻觉”

SKILL方向最大的坑，我个人叫它“剧本幻觉”——你以为流程定义好了，模型就会照剧本走，但实际情况是，模型在长上下文中经常“出戏”。

典型现象是：当天第一次调用SKILL，执行得很好；上下文再长一点、或者SKILL步骤多一点，模型就开始漏步骤。不是它不想做，而是它把“我计划要做这事”和“我已经做了这事”混淆了。这在心理学里叫“计划行为混淆”，在LLM里则表现为输出里写了“已完成查询”，实际上根本没有调用工具。

修这个坑的方法有两个方向。第一，把SKILL拆得更小，每个SKILL只负责不超过五步的流程，宁可用两个SKILL串联，不要写一个十步的巨无霸。第二，在SKILL的每一步强制要求“调用后必须回填结果”，也就是每一步的输入都必须包含前一步的实际输出，而不是模型自己脑补的“完成”。有了强制回填，想跳过步骤就没那么容易了。

5.6 SKILL方向：并发执行时共享状态混乱

还有一个SKILL使用中的小坑：并发场景下，不同会话共用同一个SKILL定义本身没问题，但如果SKILL内部依赖了某个共享缓存或会话变量，就会出现数据串线。我们的方案是让SKILL执行上下文完全独立，所有变量都是局部传参，不从全局取。这也是从一次线上故障里学到的教训——某个技能块里用了一个模块级缓存变量，两个会话同时跑，结果A会话的报表里混进了B会话的参数。

如果你现在正在设计一个偏流程化的LLM应用，请提前把执行上下文隔离放在心上，不要以为“流程定义一样就天然隔离”。

6. 我现在带项目的默认组合

6.1 常规架构：CLI打底、MCP连接、SKILL编排

经历过这么多坑之后，我目前带项目的默认组合是固定的一套三层架构，这里直接分享出来给大家参考。

• 最底层：所有能通过命令行完成的操作，尽量沉淀成可复用CLI脚本。这些脚本不直接暴露给LLM，而是作为“真实执行者”存在。它们体积小、可单测、故障域清晰。
• 中间层：用MCP服务器包一层，把CLI脚本包装成标准工具注册给LLM侧。MCP服务器负责参数校验、输出结构化、超时控制、连接管理。这是唯一与LLM直接交互的接口层。
• 最上层：把固定的业务流程封装成SKILL，SKILL内部调度MCP工具，按步骤执行并强制回填结果。SKILL是面向业务的编排层，不关心底层是CLI还是数据库驱动。

这套组合的好处是：每一层职责单一，替换成本低。如果某一天某个CLI脚本从Shell换成了Python，只需要改MCP服务器内部实现，SKILL完全不受影响；如果MCP协议在未来被更优的协议取代，只要SKILL调用的还是“工具抽象”，迁移成本也基本可控。

6.2 什么时候我会打破默认组合

默认组合不是万能的。我在两种情况下会刻意打破它。

一是硬件资源非常受限的嵌入式或边缘场景，跑MCP服务器可能有点重，这时我会退回到纯CLI加严格提示词约束的路线，同时把提示词里的命令限制死、不允许模型自由发挥。二是纯粹做知识问答、不涉及工具调用的应用，根本不需要这三层，一个不带工具的路由检索就完事了。如果硬套框架反而增加无意义的调用链。

打破默认组合的原则只有一个：不要为抽象层而抽象层。每一层都应当对某个真实问题负责。哪一层解决不了问题，哪一层就该被砍掉。

6.3 这个组合后续还能怎么扩展

最后聊聊后续扩展空间。我目前观察到的趋势是：SKILL层会越来越像“可编程的流程模板”，未来可能会有更丰富的条件分支、循环、嵌套调用支持；MCP层则会越来越多地与成熟的企业安全体系对齐，比如审计、令牌化、细粒度权限；CLI层短期不会消失，因为任何系统最终都有一个可触碰的执行边界。

对我们做工程的人来说，与其跟风追新名词，不如先把这三层之间的关系拿稳：让模型动手靠CLI，让模型好调用靠MCP，让模型跑完流程靠SKILL。这套判断可以用在很多项目上。你下一次要设计LLM与外部系统的交互时，建议先按这个顺序想一遍，应该能少走不少弯路。