---
id: EXP-012
sequence: 12
number: "012"
kind: experience
slug: ai-terms-mcp-cli-llm
label: 经验 012
category: AI 协作
topics:
  - MCP
  - CLI
  - LLM
  - Agent
  - API
  - RAG
  - Token
audience: 想把 AI 用明白，却总被 MCP、CLI、LLM、RAG、Agent 这些缩写挡在门外的人
read_minutes: 9
title: MCP、CLI、LLM 到底是什么？我用一间 AI 工作室讲明白了
subtitle: 三个词分属模型、接口和协议三层；看懂它们怎么接起来，AI 才不再是一团黑箱
summary: LLM 是负责理解和生成的模型，CLI 是用文字直接控制程序的界面，MCP 是让 AI 应用按统一规则连接外部工具和资料的协议。本文用一间 AI 工作室和一个门店报表任务，把 Token、上下文、API、RAG、Tool Calling、Agent 也放回同一张地图。
published_at: "2026-08-14"
updated_at: "2026-08-14"
version: v1.0
verification: verified
visibility: public
publication_state: published
legacy_path: ""
public_url: https://aixlg.com/exp/ai-terms-mcp-cli-llm/
wechat_url: ""
source_href: https://aixlg.com/exp/ai-terms-mcp-cli-llm/
source_cta: 打开 AI 黑话认知地图
article_state: v1.0 按 MCP 2026-07-28 官方架构、POSIX 2024 Shell 规范与公开论文复核；产品实现会继续演进
takeaways:
  - LLM 是模型，不是聊天软件、数据库或自动拥有现实权限的全能大脑
  - CLI 是文字交互界面；Terminal 是窗口，Shell 是解释命令的程序，三者不要混成一个词
  - MCP 是连接协议，不是模型也不是工具本身；它让 AI 应用发现并调用 Tools、Resources 和 Prompts
  - API、CLI 和 MCP 不是互相替代：一个 MCP Server 背后常常仍在调用某个 API 或 CLI
  - Agent 把目标、上下文、LLM、工具、权限和结果回读组织成循环；接得上不等于有权限，执行成功也不等于结果正确
deliverables:
  - 一张 LLM、MCP、CLI、API、Agent 总关系图
  - 十个 AI 常见词的普通话解释
  - 一个门店报表任务的完整工作链路
  - 一段以后遇到陌生 AI 黑话时可直接复用的提问模板
source_refs:
  - https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro
  - https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
  - https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
  - https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html
  - https://platform.openai.com/tokenizer
  - https://arxiv.org/abs/2005.14165
  - https://arxiv.org/abs/2005.11401
replaces: []
revisions:
  - version: v1.0
    date: "2026-08-14"
    note: 首次公开，用一间 AI 工作室讲清 LLM、CLI、MCP 的层级、协作关系、常见近义词和权限边界。
audio: []
---

> 一句话结论：**LLM 是会思考和表达的模型，CLI 是用文字直接控制程序的界面，MCP 是让 AI 应用按统一规则接上外部工具与资料的协议。**它们不在同一层，也不是三种互相竞争的 AI。

## 先别背缩写：它们根本不在同一层

刚接触 AI 时，最容易把一桌子缩写当成同一种东西：哪个更强？装了 MCP 还要不要 CLI？有了 LLM 是不是就能操作电脑？

这就像把**大脑、对讲机和插座标准**放在一起比高低。问题不是记不住英文，而是一开始就把层级放乱了。

| 词 | 它是什么 | 负责什么 | 它不是什么 |
| --- | --- | --- | --- |
| **LLM** | 模型 | 理解上下文，生成文字、判断和计划 | 不是聊天 App，也不会自动获得文件、日历或付款权限 |
| **CLI** | 交互界面 | 用一行行文字命令直接控制某个程序 | 不是编程语言，也不是只有程序员才配用的黑窗口 |
| **MCP** | 开放协议 | 让 AI 应用用统一方式发现、读取和调用外部能力 | 不是模型，不是插件商店，也不会替你绕过授权 |

先记住这张三层图，后面的 Token、API、RAG、Agent 才有地方可放。

![一间纸白与墨色的 AI 工作室剖面：LLM 推演，MCP 连接工具、资料与模板，CLI 和 API 控制外部程序，结果沿回路返回。](/exp/images/ai-workshop-mcp-cli-llm-image2.png "LLM 是模型层，MCP 是协议层，CLI 是交互层；真正的 AI Agent 还要把权限与结果回读接成闭环。")

## LLM：会推演的大脑，但不是整间工厂

LLM 是 **Large Language Model，大语言模型**。

从底层工作方式看，它先把文字拆成 Token，再根据当前上下文预测接下来最合适的 Token。训练规模变大以后，这种预测不只会续写句子，也能形成翻译、归纳、写代码、规划和一定程度的推理能力。

把它想成工作室中央那位读过海量资料的老师傅：你把任务、资料和规则摊在桌上，它能很快看懂并提出方案。但**单独一个模型没有手**。它不知道你电脑上刚保存了哪份表，也不能凭空打开日历、查数据库或真的发送消息。

ChatGPT、Claude、Codex 这类产品也不等于某一个 LLM。产品通常还包着界面、账号、上下文管理、记忆、搜索、工具、权限和安全规则。**模型像发动机，AI 应用才是整辆车。**

这也解释了“幻觉”：模型的输出目标首先是生成连贯、合适的下一段，不是自动从现实世界领取真相。遇到日期、金额、状态、来源和执行结果，要让它查资料、调用工具并回读证据，不能只问一句“你确定吗”。

## CLI：不用点按钮，直接把动作写出来

CLI 是 **Command-Line Interface，命令行界面**。

比如：

~~~bash
git status
python report.py --month 7
~~~

第一行让 Git 报告当前文件状态；第二行让一个报表程序处理 7 月数据。命令本身可复制、可组合、可写进脚本，输入、输出和报错也容易留痕，所以 AI 很喜欢通过 CLI 干活。

三个常混的词顺手分开：

- **Terminal** 是装着命令行的窗口，像操作台。
- **Shell** 是读懂并调度命令的解释器，例如 zsh、bash。
- **CLI** 是某个程序提供的文字操作方式，例如 `git status` 里的 Git CLI。

CLI 也不等于“更危险”。真正决定风险的是命令会做什么、它拥有什么权限、有没有预演和回读。查看状态和删除数据都能写成一行命令，不能因为都长在黑窗口里，就把它们当成同一风险。

## MCP：不是一件工具，而是 AI 世界的统一接头

MCP 是 **Model Context Protocol，模型上下文协议**。官方把它比作 AI 应用的 USB-C：不同 AI 应用和外部系统按同一套规则交流，就不用每接一个服务都重新发明插头。

一条完整链路里通常有三种角色：

1. **Host**：你正在使用的 AI 应用，负责界面、权限和整体协调。
2. **Client**：Host 为每个 MCP Server 建立的专用连接。
3. **Server**：把某一类外部能力按 MCP 规则暴露出来的程序；它可以跑在本机，也可以在远端。

MCP Server 主要能摆出三类东西：

- **Tools**：可执行的动作，例如查数据库、写文件、创建日程。
- **Resources**：可读取的资料，例如文件内容、数据库记录、接口返回。
- **Prompts**：可复用的工作模板，例如一套固定审稿流程。

关键点是：**MCP 没有消灭 API 或 CLI。**一个 MCP Server 背后，可能正是在调用某个网站 API，也可能是在运行一条本地 CLI。MCP 负责把“这里有什么、参数怎么填、结果怎么回”说成统一语言；具体活仍由后面的程序完成。

截至 2026 年 7 月 28 日的官方架构，MCP 的数据层基于 JSON-RPC，常见连接方式是本机进程间的 Stdio 和远端的 Streamable HTTP。普通使用者不必背这些名词，只需知道：**Server 不一定在服务器上，协议接通也不等于权限自动放开。**

## 把十个常见词放回同一张桌子

| 词 | 普通话解释 | 工作室里的位置 |
| --- | --- | --- |
| **Token** | 模型读写文字时使用的小块，不严格等于一个字或一个单词 | 老师傅眼里的“文字颗粒” |
| **Prompt** | 这一次给 AI 的任务、要求和示例 | 任务单 |
| **Context** | 模型这一次能看到的对话、文件片段、规则和工具结果 | 当前摊在桌上的材料 |
| **Context Window** | 一次最多能放进桌面的 Token 容量 | 有限大小的工作台 |
| **API** | 程序与程序之间约定好的调用入口 | 某台机器自己的专用门 |
| **RAG** | 先检索外部资料，再把相关片段交给模型生成 | 开工前去档案室取最新文件 |
| **Tool Calling** | 模型提出结构化工具请求，由应用决定是否执行 | 老师傅填写标准工单 |
| **Agent** | 围绕目标反复计划、调用工具、观察结果、再调整的系统 | 会跑闭环的项目负责人 |
| **Inference** | 已训练好的模型正在处理你的这一次请求 | 老师傅现场干这一单 |
| **Fine-tuning** | 用专门数据继续调整模型行为 | 让老师傅接受专项训练 |

Agent 不是第四个神秘模型。在产品里，它通常是一套循环：**目标 → 上下文 → LLM 判断 → 工具动作 → 观察结果 → 修正下一步**。模型负责想，工具负责做，Host 负责连接、权限和记录，人负责划边界与验收。

## 一份门店报表，所有词怎么一起工作

假设你说：

> 把 7 月门店流水汇总成一页报告，找出异常变化；先给我看，确认后再发给老板。

真实链路可以是：

1. **Prompt** 写明目标和“先看后发”的边界，Agent 保存当前任务状态。
2. **RAG / Resources** 取回指标口径、门店清单和 7 月数据，放进 Context。
3. **LLM** 判断先校验缺失行，再计算环比，最后写结论。
4. Host 通过 **MCP** 发现报表 Tool；这个 Tool 背后可能运行 Python **CLI**，也可能调用财务系统 **API**。
5. 程序返回行数、异常项、生成文件和校验结果；这些证据重新进入 Context。
6. LLM 根据真实结果写出一页摘要。Agent 停在“待确认”，不因为技术上能发送就替你发。
7. 你确认对象和正文后，发送工具执行，再按消息 ID 回读。

到了这一步，LLM、CLI、MCP 的关系就清楚了。**它们是在一条链上各守一段。**

## 最容易踩的六个坑

- **把 LLM 当数据库。**它会流畅表达，不代表每个事实都来自最新资料。
- **把 CLI 当代码。**CLI 是界面；你可以手输，脚本可以调用，Agent 也可以调用。
- **把 Terminal、Shell、CLI 混成一个词。**窗口、解释器、程序接口是三层。
- **把 MCP 当万能插件。**它统一连接，不替你判断工具是否可信，也不替你授权。
- **把 RAG 当重新训练。**RAG 是这次回答前临时查资料；Fine-tuning 才是继续调整模型。
- **把 Agent 当无限自治。**没有精确权限、停止线、幂等和回读，自动化只会更快地把错误放大。

MCP 官方安全文档也把会话劫持、提示词注入和授权边界单独列出。最朴素的安全线仍然有效：**接得上不等于能乱用；工具返回成功不等于业务结果正确；高风险动作必须有人类确认和真实回读。**

## 以后再遇到 AI 黑话，只问三句话

第一，它属于哪一层：模型、应用、协议、接口、资料，还是执行工具？

第二，它吃进去什么，吐出来什么？

第三，谁给它权限，结果由谁回读和验收？

能答清这三句，再长的英文缩写也只是一件有位置、有输入、有边界的工具。

## 验收标准

- 能用一句话分别解释 LLM、CLI、MCP，并明确三者不在同一层。
- 能说清 Terminal、Shell、CLI 的区别。
- 能画出 Host → LLM → MCP → Tool / Resource → 结果回读的闭环。
- 能解释为什么 MCP Server 背后仍可能调用 API 或 CLI。
- 遇到一个新词，能指出它的输入、输出、权限主体和失败证据。
- 不再用“已经接入”“命令成功”代替“对象正确、结果正确、用户确认”。

## 可复用提示词

~~~text
请把我接下来给你的 AI 术语讲给完全没有技术背景的人听。

不要只翻译英文，也不要堆定义。请依次回答：
1. 它属于模型、应用、协议、接口、资料还是执行工具哪一层？
2. 它吃进去什么，吐出来什么？
3. 用一个生活化场景解释它和 LLM、MCP、CLI、API、Agent 的关系。
4. 它最容易被误解成什么？
5. 谁给它权限，怎样回读结果，什么情况下必须停下来让人确认？

最后给我一句普通话解释、一张不超过五层的关系图和一个真实任务例子。不要用新的黑话解释旧黑话。
~~~

## 来源与修订

MCP 的定义、Host / Client / Server 角色、Tools / Resources / Prompts 以及 Stdio / Streamable HTTP，以 Model Context Protocol 官方 2026-07-28 文档为准；协议仍在演进，旧教程里的个别方法和能力可能已经变化。

CLI 与 Shell 的边界参考 The Open Group 的 POSIX.1-2024 Shell Command Language；Token 的解释参考 OpenAI 官方 Tokenizer。LLM 的规模化与少样本能力参考 GPT-3 论文，RAG 的“参数记忆＋外部检索”来源于 2020 年原始论文。

本文是一张普通人认知地图，不替代具体产品的安装、权限和安全文档。不同 AI 应用如何实现 Agent、记忆与工具调用并不完全相同，实际使用以当时版本和真实回读为准。