LLM 与外部系统交互：MCP、SKILL、CLI 三种主流方式深度解析

liu_zhiyi

461人浏览 · 2026-04-12 09:55:44

liu_zhiyi · 2026-04-12 09:55:44 发布

LLM 与外部系统交互：MCP、SKILL、CLI 三种主流方式深度解析

本文档系统梳理当前 LLM 与外部系统交互的三种主流方式——MCP（Model Context Protocol）、SKILL（技能封装）、CLI（命令行接口），涵盖工作原理、实现机制、演进历史、适用场景，并进行多维度横向对比。

一、概述

大语言模型（LLM）本身是一个孤立的知识库——它只能基于训练数据和有限的上下文进行推理。要让 LLM 真正发挥作用，必须让它与外部世界建立连接：

获取实时信息（搜索、数据库、API）
执行具体操作（发消息、写文件、操作软件）
访问私有知识（企业文档、个人数据）
调用工具完成任务（浏览器、文件系统、第三方服务）

当前业界主要有三种主流的交互方式：MCP、SKILL、CLI。这三种方式并非互斥，很多成熟的 Agent 系统（如 OpenClaw）会同时支持多种方式，各自承担不同的角色。

二、MCP（Model Context Protocol）

2.1 什么是 MCP

MCP（Model Context Protocol）是 Anthropic 于 2024 年底正式发布的开放协议，旨在为 LLM 与外部工具/数据源之间建立标准化的双向通信通道。

它的设计目标是解决一个核心问题：每个 AI 应用都需要自己实现一套工具连接逻辑，导致大量重复工作，且工具无法跨应用复用。

MCP 试图成为 AI 时代的 “USB 接口”——无论设备是什么品牌，只要支持 USB，就能连接任何 USB 设备。

2.2 工作原理

MCP 采用 Client-Server 架构，分为三个核心组件：

┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│   LLM Host  │◄───────►│ MCP Client  │◄───────►│ MCP Server  │
│ (Claude等)  │  JSON   │  (SDK)      │  JSON   │  (工具提供方) │
└─────────────┘  RPC    └─────────────┘         └─────────────┘
                                                     │
                                                     ▼
                                              ┌─────────────┐
                                              │  Local/Remote│
                                              │  Resources  │
                                              │ (文件/API/DB)│
                                              └─────────────┘

🔐 生产级安全架构说明：上述简化架构仅用于理解原理。在生产环境中，MCP 应包含以下安全组件：

Permission Middleware：工具调用鉴权、资源访问控制

Inspector/Policy Engine：权限策略执行、速率限制、操作审计

双向 TLS 认证：Client-Server 通信加密

敏感操作审批：高危操作需人工确认

通信流程：

Host（如 Claude Desktop）内置 MCP Client
Server（工具提供方）通过 MCP SDK 实现，提供一组标准化的接口
Client 与 Server 之间通过 JSON-RPC 2.0 协议通信（TLS 加密）
LLM 通过 function calling 调用 MCP 工具，结果以结构化 JSON 返回

MCP 的三大能力：

能力	说明
Tools	LLM 可调用的函数，Server 定义工具的名称、描述、输入Schema
Resources	LLM 可读取的数据源（文件、API 响应），带 URI 标识
Prompts	预定义的提示模板，可携带参数复用

2.3 协议示例

一个典型的 MCP 工具调用：

// Client → Server (调用工具)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "filesystem_read",
    "arguments": { "path": "/docs/report.md" }
  }
}

// Server → Client (返回结果)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "# Report\n\n这是报告内容..." }
    ]
  }
}

2.4 适用场景

✅ 强项：

需要标准化复用的工具生态（如多个 AI 应用共享同一套工具）
数据查询类任务（数据库、文件系统、API）
需要安全审计的工具调用（MCP 有明确的权限模型）
多宿主场景——同一工具供多个 LLM 应用使用

⚠️ 局限：

需要服务长期运行（Server 常驻）
不适合需要复杂状态管理的工作流
对于一次性/临时性任务略显笨重

2.5 代表实现

官方 SDK：Python、TypeScript、Java
官方 Server：filesystem、git、postgres、s3、slack
社区 Server：2000+（涵盖 GitHub、Google Drive、Figma、Spotify 等）
OpenClaw：内置 MCP Client，支持连接外部 MCP Server

三、SKILL（技能封装）

3.1 什么是 SKILL

SKILL 是一种以提示词为核心的能力封装范式——将某一类任务的知识、流程、最佳实践封装为一个"技能包"，LLM 通过读取这个技能包的指导来完成特定领域的任务。

SKILL 不依赖协议或代码，而是依赖结构化的文本描述（SKILL.md）来"教会"LLM 如何执行某类任务。

它的核心理念是：让 AI 行为可复制、可分享、可进化。

3.2 工作原理

SKILL 的架构通常包含以下文件：

skill-name/
├── SKILL.md          # 核心描述文件（必须）
├── examples/         # 示例对话
├── references/       # 参考资料
├── scripts/          # 可选的可执行脚本
└── assets/           # 资源文件

SKILL.md 的核心结构：

# SKILL.md - 技能名称

## Description
简短描述这个技能是做什么的。

## Triggers
- 触发条件1
- 触发条件2

## Workflow
1. 步骤一
2. 步骤二

## Best Practices
- 最佳实践1
- 最佳实践2

## Constraints
- 限制条件

执行流程：

用户请求 → Agent 检测触发条件 → 加载对应 SKILL.md → 
LLM 根据 SKILL.md 的指导执行 → 输出结果 → 记录经验到 scripts/

3.3 实现方式

SKILL 的实现可以是纯文本的，也可以包含可执行脚本：

纯文本型 Skill：

知识型技能（写作风格、分析框架）
决策参考型技能（谈判策略、投资评估）
教育型技能（张雪峰思维框架、女娲造人）

脚本增强型 Skill：

# scripts/ 中包含可执行脚本
scripts/
├── fetch_data.sh     # 获取数据
├── parse_result.py   # 解析结果
└── report.py         # 生成报告

LLM 在执行 Skill 时，可以：

直接参考 SKILL.md 的指导进行推理
调用 scripts/ 中的脚本完成具体操作
两者结合——LLM 决策 + 脚本执行

3.4 适用场景

✅ 强项：

知识密集型任务（需要专业领域知识、决策框架）
风格一致性要求高的任务（保持特定的写作/分析风格）
经验沉淀——将专家经验转化为可复用的 AI 能力
快速分发——只需分享一个 markdown 文件即可复现能力
低代码创建——无需编程，直接写文档即可定义技能

⚠️ 局限：

不能直接执行系统级操作（需要 CLI 或 MCP 辅助）
执行质量依赖 LLM 的理解能力（非确定性）
复杂工作流需要配合其他机制

3.5 代表实现

OpenClaw Skill 生态：
- nuwa-skill：女娲造人——从人名/主题自动生成新 Skill
- zhangxuefeng-skill：张雪峰思维框架
- clawhub：Skill 的分享与分发平台
Claude Code Skills：Anthropic 的代码任务扩展
GPTs / Actions：OpenAI 的技能封装方案

四、CLI（命令行接口）

4.1 什么是 CLI

CLI（Command-Line Interface）是最传统也是最灵活的 LLM 与外部系统交互的方式——LLM 通过生成并执行 shell 命令来完成任意操作。

无论工具多么复杂，最终都可以分解为一系列系统命令的组合。CLI 的本质是：LLM 生成命令字符串 → 系统执行 → 结果返回 LLM。

4.2 工作原理

┌─────────────┐
│     LLM     │  推理生成命令
└──────┬──────┘
       │ text (shell command)
       ▼
╔═══════════════════════════════════════════════════════════════╗
║  🔐 Security Gateway / Command Validator                       ║
║  • 命令白名单校验    • 参数过滤/转义    • 高危操作拦截           ║
╠═══════════════════════════════════════════════════════════════╣
║                                                               ║
║  ┌─────────────────────────────────────────────────────────┐  ║
║  │         🐳 Sandbox / Container 隔离层                    │  ║
║  │  • Docker / gVisor / seccomp                            │  ║
║  │  • 最小权限原则（Principle of Least Privilege）          │  ║
║  │  • 网络隔离（无外网访问）                                  │  ║
║  │  • 文件系统只读挂载或临时目录                              │  ║
║  └─────────────────────────────────────────────────────────┘  ║
║                          │                                  ║
║                          │ stdout/stderr                   ║
║                          ▼                                  ║
║  ┌─────────────┐        ┌─────────────┐                    ║
║  │   Shell     │───────►│   System    │                    ║
║  │  (exec)     │        │  Resources  │                    ║
║  └─────────────┘        └─────────────┘                    ║
║                          (受限资源)                         ║
╚═══════════════════════════════════════════════════════════════╝

🔐 安全边界说明：CLI 直接执行系统命令是最高风险的操作。生产环境中必须引入：

Security Gateway：命令白名单 + 参数校验 + 注入防护

Sandbox/Container：资源隔离，限制文件系统、网络、进程能力

最小权限原则：即使被攻破，损害范围可控

执行流程：

LLM 根据用户请求，生成对应的 shell 命令
通过 exec / subprocess / open 等机制执行命令
捕获命令的标准输出（stdout）和标准错误（stderr）
将结果注入 LLM 的上下文，继续推理或返回用户

安全机制（重要）：

由于 CLI 直接执行任意命令，存在严重的安全风险。成熟系统会实现多层防护：

机制	说明
命令白名单	只允许执行预定义的安全命令
参数校验	对命令参数进行严格检查，防止注入
权限隔离	在沙箱/容器中执行，限制文件系统访问
审批机制	高危命令需人工确认后才能执行
日志审计	记录所有命令执行，便于事后追溯
超时控制	防止命令永久阻塞

4.3 实现方式

基础实现：

import subprocess

result = subprocess.run(
    "opencli douyin hashtag hot --limit 50 --format md",
    shell=True,
    capture_output=True,
    text=True,
    timeout=30
)
print(result.stdout)

标准化 CLI 封装（OpenCLI）：

OpenClaw 团队开发的 opencli 工具，将大量平台 API 封装为统一的 CLI 接口：

# 之前（各平台不同）
curl -X GET "https://api.twitter.com/..."
python scripts/douyin_fetch.py
wget "https://..."

# 现在（统一接口）
opencli twitter search "AI news" --limit 10
opencli douyin hashtag hot --limit 50
opencli 36kr news --limit 10

opencli 的价值：

统一认证：cookie/API key 统一管理
统一输出格式：支持 table/plain/json/yaml/md/csv
统一错误处理：标准化错误码和消息
可观测性：支持 verbose 调试输出

4.4 适用场景

✅ 强项：

任意系统操作——只要能写命令，就能执行
成熟的命令行工具——git、docker、kubectl、ffmpeg 等
一次性/临时任务——不需要复杂的状态管理
工具生态丰富——有数十年积累的 CLI 工具库
调试友好——命令可见、易理解、易修改

⚠️ 局限：

安全风险高——直接执行任意命令，需要严格防护
可靠性不稳定——命令格式可能变化，解析困难
结构化数据处理弱——返回的是文本，需要额外解析
缺乏类型安全——运行时才能发现参数错误
不适合复杂状态流——多步骤任务需要脚本包装

4.5 代表实现

OpenClaw opencli：标准化 CLI 封装，覆盖 84 个平台
Anthropic Tools：Claude 内置的文件操作、bash 执行
LangChain Tools：Python 生态的 CLI 工具封装
agent-browser：浏览器控制的 CLI 封装

五、三者对比

5.1 核心特性对比

维度	MCP	SKILL	CLI
设计理念	协议标准化	知识封装	命令执行
标准化程度	高（协议层）	低（格式约定）	无标准
执行确定性	✅ 高	⚠️ 中（依赖 LLM）	✅ 高
安全性	⚠️ 中（有权限模型）	✅ 高（只读指导）	❌ 低（需防护）
工具复用性	✅ 极高（跨应用）	⚠️ 中（需适配）	✅ 高（系统级）
创建门槛	高（需 SDK）	低（写 Markdown）	低（写命令）
实时性	✅ 好	✅ 好	✅ 好
状态管理	弱	弱	需脚本包装
适用任务复杂度	中等	低-中	任意

5.2 功能能力对比

能力	MCP	SKILL	CLI
API 调用	✅ 原生	❌ 需辅助	✅
文件系统操作	✅ via tools	❌ 需辅助	✅
数据库查询	✅ 原生	❌	✅
浏览器控制	❌	❌	✅
消息发送	⚠️ 需实现	❌	✅
定时任务	❌	❌	✅
知识推理	❌	✅ 核心能力	❌
风格一致性	❌	✅	❌
经验复用	❌	✅	⚠️ 脚本化

5.3 适用场景对比

场景	推荐方式
企业内部工具标准化	MCP
专业领域知识复用	SKILL
系统运维、DevOps	CLI
数据查询、报表	MCP + CLI
内容创作、写作风格	SKILL
一次性数据分析	CLI
跨平台操作（84+平台）	opencli (CLI)
AI Agent 能力扩展	SKILL + MCP + CLI 组合
敏感操作（需审批）	MCP（有权限模型）
快速验证想法	CLI

5.4 安全性对比

维度	MCP	SKILL	CLI
权限控制	✅ 细粒度（工具级）	⚠️ 间接（取决于调用的工具）	❌ 粗粒度（进程级）
注入风险	⚠️ 中	✅ 低	❌ 高（shell 注入）
审计追溯	✅ 标准化日志	⚠️ 依赖实现	⚠️ 依赖 shell 日志
沙箱隔离	⚠️ 依赖实现	✅ 天然隔离	⚠️ 需手动配置
最小权限原则	✅ 支持	N/A	⚠️ 难实现

5.5 Token 用量评估与对比

Token 是 LLM 调用的核心成本来源。三种方式在 Token 消耗上的表现差异显著，以下从单次调用成本、上下文占用、实际场景对比三个维度进行分析。

5.5.1 单次调用的 Token 消耗拆解

MCP Token 消耗构成：

组成部分	说明	典型大小
Tool Schema	工具定义（名称、描述、参数）	200-800 tokens/工具
Tool Call Input	调用参数（JSON）	50-500 tokens/次
Tool Result	返回结果（结构化 JSON）	100-2000 tokens/次
Protocol Overhead	JSON-RPC 协议包装	~50 tokens/次

MCP 的特点：Schema 一次加载，多次复用。工具定义只在会话开始时传入一次，后续只有调用参数和返回结果的往返消耗。

SKILL Token 消耗构成：

组成部分	说明	典型大小
SKILL.md 全文	技能描述文件	500-5000 tokens
examples/ 对话示例	Few-shot 示例	200-2000 tokens
Execution Context	执行时的任务描述	100-500 tokens
Output	LLM 输出	50-2000 tokens

SKILL 的特点：按需加载，整块传入。SKILL.md 作为系统上下文的一部分加载，加载成本高但执行时无需额外 Schema 解析。

CLI Token 消耗构成：

组成部分	说明	典型大小
Command Generation	生成命令的 Prompt	50-200 tokens
Command String	生成的命令本身	10-100 tokens
Execution Output	命令执行结果（文本）	0-10000+ tokens
Result Parsing	解析输出后的文本注入	0-5000 tokens

CLI 的特点：Token 消耗极不稳定，取决于命令输出内容。大型命令（如 ls -la /）可能产生大量文本，而简单命令几乎没有输出。

5.5.2 上下文窗口占用对比

以一个典型任务——"获取抖音热点话题 Top50"为例：

维度	MCP	SKILL	CLI (opencli)
工具定义	~500 tokens	~300 tokens (SKILL.md)	~100 tokens (命令模板)
任务描述	~100 tokens	~100 tokens	~50 tokens
执行结果	~800 tokens (JSON)	N/A（无结构化返回）	~2000 tokens (Markdown表格)
解析后注入	~400 tokens	~1000 tokens (LLM 整理)	~1000 tokens (LLM 整理)
总计（单次）	~1800 tokens	~1400 tokens	~3150 tokens

关键发现：CLI 的 Token 消耗最高，因为需要将原始命令输出完整注入上下文。SKILL 和 MCP 都能通过结构化返回减少不必要的文本注入。

5.5.3 Token 效率综合对比

① 效率与质量维度（⭐ 越多越好）

维度	MCP	SKILL	CLI
单次调用效率	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
批量任务效率	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
上下文窗口利用率	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
Token 可预测性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐

② 成本与风险维度（⭐ 越少越好）

维度	MCP	SKILL	CLI
首次加载成本	⭐⭐⭐ 中等	⭐⭐⭐⭐⭐ 高	⭐⭐⭐ 中等
推理延迟敏感性	⭐⭐⭐⭐⭐ 低	⭐⭐⭐⭐ 高	⭐⭐⭐⭐⭐ 低
Token 消耗波动性	⭐⭐⭐⭐⭐ 稳定	⭐⭐⭐⭐ 较稳	⭐⭐ 波动大

5.5.4 成本估算（以 GPT-4o mini 为基准）

参考价格：GPT-4o mini ~$0.15/1M input tokens，$0.6/1M output tokens

任务类型	MCP	SKILL	CLI
简单查询（<500 tokens）	$0.0002	$0.0002	$0.0003
中等任务（~2000 tokens）	$0.0005	$0.0006	$0.0008
复杂任务（~10000 tokens）	$0.002	$0.0025	$0.004
年度成本（每日100次）	$75	$90	$150

年度对比：CLI 比 MCP 贵约 2倍，比 SKILL 贵约 1.7倍（在相同任务量下）。

5.5.6 优化策略

MCP 优化：

合并多个小工具为一个批量接口
使用分页避免一次性返回大量数据
在 Server 端过滤，只返回必要字段

SKILL 优化：

精简 SKILL.md，只保留核心内容（<1000 tokens 最佳）
常用 SKILL 预加载，不常用按需加载
使用示例而非完整文档（examples/ 更省 Token）

CLI 优化：

命令加 --format json 替代 --format md（JSON 更结构化，解析更少）
使用 --limit 控制输出量，避免返回全量数据
输出重定向到临时文件，只读取关键部分
在命令端预处理（grep/awk/jq）减少传输量

# 不推荐：返回全量 Markdown
opencli douyin hashtag hot --limit 50 --format md

# 推荐：返回 JSON，在命令端处理
opencli douyin hashtag hot --limit 50 --format json | jq '.[:10]'

5.6 演进趋势对比

趋势	MCP	SKILL	CLI
标准化程度	快速提升	缓慢演进	稳定
生态规模	爆发增长（2000+）	缓慢增长	成熟稳定
AI Native 程度	✅ 高	✅ 极高	⚠️ 低
未来潜力	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐

六、总结与建议

6.1 选型决策树

需要与外部系统连接？
    │
    ├── 需要标准化复用？ ──→ MCP
    │
    ├── 需要专业知识/风格？ ──→ SKILL
    │
    └── 需要执行任意操作？ ──→ CLI (opencli)

6.2 最佳实践

MCP 优先：如果有成熟 MCP Server 可用，优先使用 MCP，它的标准化和安全性最优
SKILL 沉淀：将专家经验、知识框架固化为 Skill，实现组织内 AI 能力积累
CLI 兜底：对于没有 MCP Server 的平台，使用 opencli CLI 封装作为补充
安全第一：无论哪种方式，都必须有完善的权限控制和审计机制
分层组合：复杂任务通常需要三者协同，不要局限在单一方式

6.3 未来展望

方向	预测
MCP	可能成为 ISO 标准级别的协议，80%+ AI 应用支持
SKILL	AI 能力市场的交易单元，像 App 一样买卖分享
CLI	opencli 类工具持续扩展，但逐渐被 MCP 接管部分场景
融合	最佳实践是多层组合，而非单一方式打天下