大语言模型应用技术体系解析——提示词、知识库、Skills、MCP 与 Agent

开篇引入

本文关键字：提示词、系统提示词、知识库、Skills、MCP、Agent

这篇文章想回答一个很多人都有过的疑问：为什么网页版 ChatGPT 只能"聊天"，而装了 Claude Code 或 Cursor 的电脑，AI 却真的能替你改文件、跑代码、查数据库？这两者之间，到底差了什么？

答案藏在六个词里：提示词、系统提示词、知识库、Skills、MCP 和 Agent。它们分别负责给大模型"下指令、立规矩、补知识、教流程、接工具、装手脚"。本文会从零开始，把这六个概念一个个讲清楚，最后用一条完整的链路把它们串起来。即使你完全没写过代码，也能看懂。

读完你会发现一个反常识的事实：你天天在用的那些"AI 助手"，真正干活的其实不全是那个大模型——真正的秘密，藏在大模型外面的那一圈"零件"里。

一、大语言模型的能力边界与技术演进

本章关键词：大语言模型、上下文窗口、提示词、系统提示词、分层架构

1.1 基本原理与能力特征

大语言模型（Large Language Model，LLM） 是一类基于海量文本语料训练而成的深度学习模型，其核心任务可以概括为：根据给定的上文（Context），预测下一个词元（Token）出现的概率分布，并逐词元地生成后续文本。通俗地说，它本质上是一个能力极强的"文字接续器"——但它接续出来的内容，在人类看来往往具有高度的理解性与逻辑性。

从能力结构上观察，大语言模型具有三项显著优势：

语义理解能力：能够准确解析自然语言中的意图、情感与隐含逻辑，包括歧义消解、指代消解等复杂任务。
推理与生成能力：具备类比推理、多步推理、代码生成、摘要归纳等通用智力行为，可在未见过的任务上展现出较强的泛化能力。
知识承载能力：训练过程中吸收了来自互联网、书籍、论文等来源的海量知识，具备跨领域的常识储备。

然而，与上述优势相对应，大语言模型同样存在三项结构性局限，这些局限正是后续所有应用技术（知识库、Skills、MCP、Agent）存在的根本原因：

结构性局限	具体表现	带来的工程问题
知识时效性局限	训练数据存在截止日期，模型无法感知训练之后发生的事件	无法回答最新新闻、最新版本软件的用法
私有知识局限	模型不了解任何组织或个人的私有数据（内部文档、业务数据、个人偏好）	无法处理企业级业务场景
环境交互局限	模型本身只是一个纯文本计算程序，没有文件系统、网络与命令行权限	无法读写文件、调用 API、执行代码

第三项局限尤为关键：大语言模型本身不具备"行动能力"，它只能输出文本。要让模型"干活"，必须在模型之外构建一套完整的技术体系，为其提供指令、规则、知识、流程、接口与执行载体。这正是本文将要系统论述的内容。

1.2 应用技术体系五要素总览

在当代大语言模型应用工程中，围绕模型本体，业界已经形成了一套成熟的技术组件体系。本文将其归纳为五个核心要素，并以 Agent（智能体）作为整合载体：

要素	正式定义	核心作用	类比
提示词（Prompt）	用户或系统在单次交互中向模型提交的具体指令文本	指导模型完成本次特定任务	一次性的口头指令
系统提示词（System Prompt）	会话开始前注入的高优先级全局指令，通常对用户不可见	定义模型的人设、行为准则、输出约束与安全边界	岗位说明书
知识库（Knowledge Base）	存储领域文档的外部数据库，通常结合检索增强生成（RAG）技术使用	弥补模型的知识时效与私有知识缺陷	可检索的参考资料库
Skills（技能包）	将特定任务的作业流程（SOP）、逻辑规则与配套脚本封装而成的可复用模块	赋予模型执行特定领域复杂任务的方法论	标准作业手册与工具包
MCP（模型上下文协议）	连接大模型应用与外部数据源、工具的统一开放协议标准	解决系统集成中接口不统一的问题	统一的连接标准

需要强调的是，这五个要素并非相互独立、彼此可替代的关系，而是处于不同的抽象层级、服务于不同的工程目的。下文 1.3 节将给出体系化的分层视角。

1.3 体系的分层架构与统一类比

从系统工程的角度，可将上述要素划分为五个层次：

指令层：包含提示词与系统提示词。该层解决"模型应当如何思考、如何表现"的问题，属于纯文本配置，直接作用于模型本身的生成行为。
数据层：包含知识库（RAG）。该层解决"模型不知道的事实从哪里来"的问题，属于外部数据供给。
能力层：包含 Skills。该层解决"模型应当按什么步骤完成某类任务"的问题，属于方法论与作业流程的封装。
协议层：包含 MCP。该层解决"模型应用如何与外部系统安全、统一地连接"的问题，属于基础设施级的通信标准。
执行层：包含 Agent 软件（客户端）。该层提供模型运行所需的进程管理、系统权限与工具调度环境，是上述所有层级的载体。

为便于建立直觉，本文给出一个贯穿全篇的统一类比：可将大语言模型视为一位知识渊博但长期被限制在封闭空间内的专家。这位专家没有手机、没有电脑、不能联网，也无法接触任何外部资料。在此设定下：

提示词与系统提示词，相当于随时传达给专家的话语与专家入职时签订的岗位守则；
知识库，相当于专家身旁可供随时翻阅的资料柜；
Skills，相当于专家案头摆放的各类标准作业手册；
MCP，相当于专家办公室中统一的电话线与接口标准，使专家可以对外联络；
Agent，则相当于为这位专家配备的完整办公环境，使其能够真正"行动"起来。

这一类比将在后文各章中反复使用，帮助读者在理解技术细节的同时，始终保持对整体架构的把握。

知识库（Knowledge Base） 是指以结构化或半结构化方式存储领域文档的外部数据系统。在实际工程中，知识库通常与 RAG（Retrieval-Augmented Generation，检索增强生成） 技术结合使用：在模型生成回答之前，系统先从知识库中检索与问题相关的资料，将检索结果拼接进提示词，再由模型基于这些资料生成最终答案。RAG 的价值在于：它使模型能够在不重新训练的前提下，获得最新的与私有的知识。

RAG 的标准工作流程包含四个环节：

切块（Chunking）：将长文档按照语义边界（如段落、标题层级）切分为固定大小的文本块，便于后续向量化与检索。切块粒度的选择直接影响检索质量，过大会引入噪声，过小会割裂语义。
向量化（Embedding）：通过嵌入模型将每个文本块转换为高维向量，并写入向量数据库（Vector Database），为语义检索建立索引。
相似度检索：将用户问题同样向量化，在向量数据库中检索语义最相似的若干文本块（通常为 Top-K 检索），并可配合重排序（Rerank）模型提升精度。
上下文拼接与生成：将检索到的文本块与用户问题共同注入模型上下文，模型基于检索资料生成回答，并可在回答中引用资料来源，提升可信度。

RAG 所解决的核心问题，对应 1.1 节所述三项结构性局限中的前两项：知识时效性问题（外部文档可实时更新）与私有知识问题（企业内部文档可被检索利用）。需要注意的是，RAG 的实际效果受切块粒度、嵌入模型质量、检索策略与提示词组织方式等多重因素影响，实践中需要针对具体场景进行系统调优，并非简单的"接入即有效"。

1.5 提示词与系统提示词的工程实践

在 1.2 节的基础上，本节对指令层的两个要素作进一步展开。

提示词（Prompt） 是模型每次交互的直接输入，其质量直接决定输出质量，相关方法论即提示词工程（Prompt Engineering）。一份结构良好的提示词通常包含四个要素：

角色设定：明确模型应当扮演的身份（如"资深 Python 工程师"），以激活相应领域的知识分布；
任务描述：清晰、无歧义地说明需要完成的具体工作；
输出格式约束：规定回答的组织形式（如"使用表格呈现""代码必须附注释"）；
示例引导（Few-shot）：提供若干输入-输出对，示范期望的输出风格与质量水平。

以翻译任务为例，糟糕的提问是"帮我翻译一下"，优秀的提问则是"请以资深本地化译员的身份，将以下中文产品介绍翻译为英文，要求语气专业、术语统一，并给出三版候选译文"。二者的输出质量差异通常极为显著，这正说明提示词工程的核心在于"把需求说清楚、把标准定明白"。

系统提示词（System Prompt） 则是会话开始前注入的高优先级全局指令，通常对用户不可见。其典型内容包括：身份人设、行为准则（如"回答必须严谨，不确定时明确说明"）、安全边界（如"拒绝回答违法内容"）与输出约束（如"全程使用简体中文"）。系统提示词与普通提示词的本质区别在于作用域：普通提示词作用于单次交互，系统提示词作用于整个会话。在 Agent 场景下，系统提示词还承担着约束智能体行为范式（如"先规划后执行"）的重要职能，是全体系稳定运行的"地基"。

二、Skills 技能包机制解析

本章关键词：Skills、SKILL.md、标准作业流程、按需加载、指令与代码分离

2.1 定义、定位及其与系统提示词的区别

Skills（技能包） 是指将特定任务的执行流程、思考规则、输出规范以及（在必要时）配套的脚本与资源，封装为可独立分发、可复用、可按需加载的模块化单元。其核心载体通常是一个以 SKILL.md 为主文件的技能目录。

需要首先澄清一个常见的认知误区：Skills 并不仅仅是一段系统提示词。虽然二者的功能存在部分重叠（都以文本形式向模型传递行为指导），但在工程形态与能力边界上存在本质差异，具体对比如下：

对比维度	系统提示词	Skills
形态	单一纯文本片段	复合模块（文档 + 脚本 + 资源 + 元数据）
能力来源	仅依赖模型自身的生成能力	模型生成能力 + 外部代码的真实执行能力
加载方式	会话全程常驻，持续占用上下文	任务匹配时按需动态加载，用后可释放
上下文开销	每次对话均完整计入 Token 消耗	平时仅保留轻量索引，细节按需注入
可分发性	难以独立打包、版本化管理	可打包、可分享、可安装、可版本化
解决的核心问题	模型"如何表现"	模型"按什么流程完成某类任务"

从工程本质上看，可以给出如下概括性结论：Skills 可视为"装配了真实执行能力与标准作业流程的系统提示词模块"。它把"如何思考"（文本指导）与"如何执行"（代码与工具）打包为一体，是模型从"聊天工具"走向"智能体"的关键一步。

2.2 技能包的物理结构

为直观说明 Skills 的物理形态，本节以一个"Excel 专业报表生成技能"（excel-report-generator）为例，展示其完整的目录结构：

excel-report-generator/          <-- 技能包根目录
├── SKILL.md                     <-- 核心文档：模型的"作业指南"
├── scripts/
│   └── make_excel.py            <-- 执行脚本：真正生成 Excel 的代码
└── templates/
    └── company_header.png       <-- 静态资源：公司 Logo 表头模板

其中，SKILL.md 是技能包中唯一不可或缺的文件，它通常由以下结构组成：

---
name: excel-report-generator
description: 当用户提供原始数据并要求生成美化后的专业 Excel 报表时使用。
---

# 技能：专业 Excel 报表生成器

## 1. 触发场景
- 用户上传 CSV/JSON 文件并要求导出为 Excel。
- 用户粘贴表格数据并要求整理为规范表格。

## 2. 标准处理流程（SOP）
1. 数据清洗：日期统一为 YYYY-MM-DD 格式；金额保留两位小数。
2. 样式规范：表头加粗并使用商务蓝（#1F4E78），文字为白色。
3. 汇总行：末尾追加合计行，使用 Excel 公式（如 =SUM(C2:C10)），禁止硬编码结果。

## 3. 调用脚本
将清洗后的数据转为 JSON，运行：
python scripts/make_excel.py --input data.json --output report.xlsx

## 4. 注意事项
- 禁止生成无样式表格；数据超过 50 行时必须冻结首行。

对该文档进行结构化分析，可提炼出 SKILL.md 的四个核心组成部分：

元数据（YAML Frontmatter）：包含技能名称与描述（description），其中描述是模型进行意图匹配、决定是否加载该技能的关键依据。
触发条件：明确界定该技能适用的任务场景，用于避免误用。
标准作业流程（SOP）：以有序步骤的形式，规定模型执行任务时的完整操作路径。
资源引用与注意事项：指明配套脚本的调用方式，以及执行过程中的质量约束与禁忌事项。

需要特别说明的是，在技能包的全部文件中，只有 SKILL.md 是加载流程必需的文件：元数据用于意图匹配，正文用于流程指导，而脚本与资源均属于可选附件。这一设计保证了技能包在纯文本平台上的可分发性——即使没有附带任何代码文件，只要 SKILL.md 存在，技能即可被识别与加载。

2.3 指令与代码的分离机制

在 2.2 节的示例中，SKILL.md 内出现了一条关键指令："调用本技能同目录下的 Python 脚本"。此处需要明确一个易被误解的技术事实：该指令是一段文字引用，而非代码本体。

具体而言：

SKILL.md 是纯文本文档，其中即使包含 Markdown 代码块（以三个反引号包裹的内容），该代码块在文档中的存在形式也仅仅是展示性文本，供模型阅读与理解，并不能被操作系统直接执行。
真正可执行的 make_excel.py 是一个物理上独立的文件，存储于技能目录的 scripts/ 子目录中，与 SKILL.md 并列存在。
SKILL.md 中的指令本质上是一条"路径引用"，其作用是指示模型：可执行代码位于 scripts/make_excel.py，并通过命令行解释器（如 python）调用它。

为帮助读者建立清晰认知，可用一个生活化的类比加以说明：SKILL.md 相当于一本菜谱，菜谱上写有"请按下厨房中榨汁机的开关"这样的文字说明；而 make_excel.py 相当于厨房中真实存在的榨汁机。文字本身无法榨汁，菜谱的作用仅是引导操作者去使用真实存在的工具。同理，Markdown 中的代码块只是"印刷在纸上的代码"，只有将其提取并保存为真实文件后，计算机才能执行。

指令与代码分离的工程合理性体现在四个方面：

可执行性：命令解释器要求目标必须是真实存在的文件路径，而非文档中的字符串。
可复用性：独立脚本可被反复调用，每次传入不同参数（如不同输入数据、不同输出路径），无需重复提取代码。
可维护性：脚本缺陷可在不改动文档的情况下修复，文档更新亦不影响代码，实现关注点解耦。
上下文经济性：完整代码若嵌入文档，每次加载技能都会全文占用 Token；独立文件则仅在需要执行时才被读取。

2.4 脚本内嵌于 Markdown 的可行性分析

基于 2.3 节的论述，自然会产生一个问题：既然代码块在 Markdown 中只是文本，那么是否可以将 Python 脚本直接内嵌于 SKILL.md？答案是：可以，且实践中确实存在此类做法，但需要区分两种不同层级的"内嵌"。

第一种：示例参考型内嵌（普遍存在）。SKILL.md 中包含少量代码块，其作用是向模型展示"标准写法""模板代码"或"数据格式示例"，供模型参考、修改或复制。此类内嵌不承担直接执行职能，是绝大多数技能文档的常规组成部分。

第二种：自包含型内嵌（真实存在但需特殊机制配合）。某些技能设计者将完整可运行脚本以代码块形式写入 SKILL.md，形成"单文件自包含技能包"。其运行依赖文档中的"提取指令"，流程如下：

模型读取 SKILL.md，定位"脚本区"代码块；
将代码块内容原样提取，写入工作目录下的临时文件（如 make_excel.py）；
通过命令行执行该文件；
任务完成后清理临时文件。

该模式的典型写法如下：

## 操作步骤
1. 将下方"脚本区"中的 Python 代码原样提取，保存为工作目录下的 make_excel.py。
2. 运行命令：python make_excel.py --input data.json --output report.xlsx

## 脚本区
```python
import json
from openpyxl import Workbook

def build(data, output):
    wb = Workbook()
    ws = wb.active
    for r, row in enumerate(data, start=1):
        for c, v in enumerate(row.values(), start=1):
            ws.cell(row=r, column=c, value=v)
    wb.save(output)

if __name__ == "__main__":
    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument("--input")
    parser.add_argument("--output")
    args = parser.parse_args()
    build(json.load(open(args.input, encoding="utf-8")), args.output)


需要强调的是，即便采用自包含型内嵌，**代码在执行前仍必须被"落盘"为真实文件**。Markdown 中的代码块始终只是文本，模型在此过程中扮演的是"代码搬运工"的角色。

两种模式的利弊权衡如下：

| 模式 | 优点 | 缺点 |
| :--- | :--- | :--- |
| 独立脚本文件 | 可直接执行、可复用、易维护、上下文开销低 | 需要管理目录结构，不利于纯文本分发 |
| 内嵌于 MD | 单文件便于分享、兼容纯文本平台、零安装依赖 | 不能直接执行、提取过程易出错、占用上下文、难以复用与版本管理 |

**工程实践结论**：对于数十行以内的小型工具代码，内嵌于 `SKILL.md` 完全可行；对于规模较大、需要复用的代码，应优先采用独立文件方式。主流技能规范（如 Anthropic 的 Agent Skills 规范）对两种方式均予以支持。

### <a id="chapter-2-5"></a>[2.5 云端分发缺少本地脚本的成因分析](#toc-2-5)

在技能市场中，大量从云端下载的技能包解压后仅包含一个 `SKILL.md`，并不存在任何 `.py` 或 `.js` 文件。这一现象并非异常，而是由以下四种典型成因所致：

**成因一：纯提示词型技能（指南型）**。某些任务的完成完全依赖大模型自身的推理与生成能力，如代码评审、写作润色、思维框架设计等。此类技能无需任何外部代码，`SKILL.md` 本身即构成完整技能。

**成因二：动态代码生成型技能（当前主流）**。此类技能的 `SKILL.md` 中并未固定封装脚本，而是指示模型"自行编写一段 Python 代码完成任务，并在沙盒中运行"。模型读取指示后，在运行时现场生成临时脚本并执行，任务结束后即丢弃。在此模式下，`SKILL.md` 传授的是"方法"，而非"现成脚本"。

**成因三：云端 API 型技能**。此类技能指示模型调用某个远程 HTTP 接口（如天气服务、翻译服务），真正的业务逻辑运行于云端服务器，本地自然无需包含代码文件。

**成因四：后台自动解压型技能**。部分复杂技能确实附带本地脚本，但安装工具会将整个技能包解压至系统隐藏缓存目录（如 `~/.config/.../skills/`），并在用户界面仅展示 `SKILL.md` 的文字内容，脚本因此对用户不可见。

综合上述分析，可得出如下结论：**`SKILL.md` 是技能包唯一必不可少的"灵魂"，而代码并非必需**。在缺少代码文件的情况下，模型可依靠自身能力完成推理，或现场编写代码，或调用云端接口，三种路径均可实现技能功能。

### <a id="chapter-2-6"></a>[2.6 技能的按需加载机制](#toc-2-6)

Skills 体系最精妙的设计在于其**按需加载（On-demand Loading）**机制。若将所有技能全文一次性注入模型上下文，上下文窗口将迅速耗尽；若依赖用户手动指定，则智能程度不足。为此，现代智能体框架普遍采用以下**三步自动加载流程**：

**第一步：轻量索引扫描**。系统启动时，仅读取每个技能 `SKILL.md` 开头的元数据（技能名称与一句话描述），构建"技能索引"，Token 开销极小。

**第二步：意图匹配（路由判断）**。当用户提出任务请求时，框架将请求与索引中的技能描述进行语义匹配，判定是否存在高度匹配的技能。例如，用户请求"把 PDF 里的表格导出成 Excel"，索引中"PDF 表格提取"技能将被命中。

**第三步：动态注入**。命中后，框架在后台读取该技能 `SKILL.md` 的完整内容及其关联脚本，注入当前对话上下文；任务完成后，相关细节可被清理释放。

此外，主流工具亦支持**手动指定加载**，包括两种形式：其一，用户在交互界面通过斜杠指令或提及（如 `/skill pdf-table-extractor`）强制指定技能；其二，开发者在自动化工作流中通过代码显式加载（如 `agent.load_skill('pdf-table-extractor')`）。

可以用"餐厅点菜"作类比概括该机制：若将全部菜谱背诵在脑中，厨师将不堪重负；合理的方式是厨师手持一份仅含菜名与简介的菜单，在顾客点菜后，再去查阅对应菜品的详细做法。Skills 的加载机制正是这一思想的技术实现：**平时仅保留目录，用时动态调取，亦可手动指定**。

### <a id="chapter-2-7"></a>[2.7 Skills 与 MCP 的边界与协作](#toc-2-7)

在工程实践中，Skills 与 MCP 经常被一并讨论，二者的边界可用一句话界定：**Skills 解决"如何按流程做事"的问题，MCP 解决"如何连接外部系统"的问题**。前者是方法论（知识与流程的封装），后者是基础设施（接口与管道的标准化）。

| 维度 | Skills | MCP |
| :--- | :--- | :--- |
| 本质 | 作业流程与方法的封装 | 通信协议与连接标准 |
| 载体 | SKILL.md 文档与附属脚本 | MCP Server 程序与 JSON 配置 |
| 解决的核心问题 | 模型按什么步骤完成某类任务 | 模型如何统一接入外部数据与工具 |
| 类比 | 员工手册与作业指导书 | 电话线、数据线与接口标准 |

二者并非互斥，而是典型的协作关系：Skills 提供流程（如"审查 PR 时先看单元测试，再看安全漏洞"），MCP 提供连接（如"从 GitHub 拉取 PR 代码、提交审查意见"）。在一个完整的智能体任务中，二者往往被同时调用，协同完成工作。

---

## <a id="chapter-3"></a>[三、MCP 模型上下文协议机制解析](#toc-3)

> **本章关键词**：MCP、模型上下文协议、MCP Server、JSON-RPC、接口标准化

### <a id="chapter-3-1"></a>[3.1 协议定义与历史背景](#toc-3-1)

**MCP（Model Context Protocol，模型上下文协议）** 是由 Anthropic 于 2024 年末发起并推动的开源协议标准，其目标是统一大语言模型应用与外部数据源、本地工具及软件系统之间的连接方式。MCP 在 AI 应用体系中的定位，可类比为"AI 世界的通用连接接口"：只要数据源或工具实现了 MCP 服务端，任何支持 MCP 的客户端即可直接接入。

为理解 MCP 的价值，必须回溯其诞生前的行业痛点，即著名的 **"M×N 胶水代码问题"**。假设存在 M 个 AI 客户端软件（如 Cursor、Claude Desktop、Dify 等）与 N 个外部工具（如 GitHub、Postgres、Slack 等）。在 MCP 出现之前，每一个客户端要接入每一个工具，都必须由该客户端的开发团队自行编写一套专用的"适配代码"（即传统意义上的"插件"或"工具集成"），其内容包括：

1. **接口定义**：以 JSON Schema 等形式声明工具的调用方式与参数格式；
2. **鉴权处理**：在请求中携带 API Token 或密钥；
3. **网络请求逻辑**：按工具 API 的具体格式构造 HTTP 请求；
4. **结果解析**：将工具返回的原始数据裁剪、转换为模型可理解的文本。

这种模式的代价是灾难性的：若 M=5、N=100，则整个行业需要维护 500 套功能重复的适配代码；且任一工具的 API 发生变更，所有相关客户端的代码都必须同步修改，维护成本随规模呈乘积式增长。

为直观呈现"旧时代的插件"究竟是什么形态，以下给出一个真实的 Python 适配代码片段（示例为接入 GitHub 创建 Issue 的胶水代码）：

```python
# 旧模式：AI 客户端团队手写的 github_plugin.py（适配代码）
import requests

GITHUB_TOOL_SCHEMA = {
    "name": "create_github_issue",
    "description": "在 GitHub 仓库中创建一个 Issue",
    "parameters": {
        "type": "object",
        "properties": {
            "repo": {"type": "string"},
            "title": {"type": "string"},
            "body": {"type": "string"}
        },
        "required": ["repo", "title"]
    }
}

def execute_create_issue(token, repo, title, body):
    url = "https://api.github.com/repos/" + repo + "/issues"
    headers = {"Authorization": "Bearer " + token}
    response = requests.post(url, json={"title": title, "body": body}, headers=headers)
    if response.status_code == 201:
        return "创建成功：" + response.json()["html_url"]
    return "失败：" + response.text

可以看到，该代码与 GitHub 的 API 格式强耦合：鉴权方式、请求地址、数据格式均为 GitHub 专属。同样的逻辑，Cursor 团队用 TypeScript 写一遍，Dify 团队用 Python 写一遍，AutoGPT 团队再写一遍——这就是"M×N 胶水代码噩梦"的直观写照。

MCP 的解法是将"适配代码"从各客户端中剥离，标准化为独立部署的 MCP Server（服务端）。工具方只需维护一个 MCP Server，所有支持 MCP 的客户端即可即插即用，集成复杂度由 O(M×N) 降为 O(M+N)。这正是 MCP 被誉为"AI 世界的 USB-C 接口"的原因。

3.2 三大核心原语

一个标准的 MCP Server 向客户端暴露三类能力，构成 MCP 的三大核心原语：

第一类：Tools（工具）。允许模型执行具有副作用（Side Effect）的操作，如写入数据库、发送邮件、创建 Issue 等。每个 Tool 包含名称、描述、入参 Schema 与执行逻辑。例如一个 GitHub MCP 可提供 create_github_issue 工具，参数包括 title 与 body，执行逻辑为调用 GitHub API 发起 HTTP POST 请求。

第二类：Resources（资源）。提供只读数据访问能力，如数据库表结构、日志文件、API 文档等。Resources 不会改变外部系统状态，类似于"只读视图"，通常以 URI 形式标识。

第三类：Prompts（提示词模板）。由 MCP Server 预置的标准化提示词模板，供用户在交互界面直接选用，例如数据库 MCP 可内置"分析慢查询"模板。

三类原语的对比可归纳如下：

原语	读写属性	是否产生副作用	典型用途
Tools	读/写	是	执行操作、调用 API、修改系统状态
Resources	只读	否	提供数据与文档上下文
Prompts	只读	否	提供标准化的交互模板

为直观说明 MCP Server 的构成，以下给出基于官方 SDK（TypeScript）的最小实现示例：

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  ListToolsRequestSchema,
  CallToolRequestSchema
} from "@modelcontextprotocol/sdk/types.js";

// 1. 初始化 MCP 服务器并声明能力
const server = new Server(
  { name: "my-calculator-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

// 2. 声明工具（含名称、描述、参数 Schema）
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "add_numbers",
    description: "对两个数字执行加法运算",
    inputSchema: {
      type: "object",
      properties: {
        a: { type: "number" },
        b: { type: "number" }
      },
      required: ["a", "b"]
    }
  }]
}));

// 3. 处理工具调用请求
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "add_numbers") {
    const { a, b } = request.params.arguments;
    return { content: [{ type: "text", text: "计算结果：" + (a + b) }] };
  }
});

// 4. 连接传输通道
const transport = new StdioServerTransport();
await server.connect(transport);

从代码结构可以看出，MCP Server 本质上是一个遵循固定消息格式（JSON-RPC）的轻量级服务程序，其开发语言可以是 TypeScript、Python、Go、Rust 等主流编程语言。

3.3 文件形态与通信协议

与 Skills 不同，MCP 并不存在专属的文件后缀（如 .mcp），因为它本质上是通信协议而非文件格式。MCP 的落地形态由两部分文件构成：

其一：配置文件（.json）。在客户端软件（如 Claude Desktop、Cursor）中，通过 JSON 配置文件声明 MCP Server 的位置与启动方式，例如 claude_desktop_config.json。

其二：服务端程序（.js / .ts / .py / Docker 镜像）。MCP Server 是独立的可执行程序，由开发者使用常规编程语言编写，或打包为容器镜像分发。

在通信层面，MCP 基于 JSON-RPC 2.0 消息格式进行请求与响应，底层传输通道支持两种模式：

Stdio 模式：客户端以子进程方式启动 MCP Server，通过标准输入输出进行消息交换，适用于本地桌面应用；
HTTP/SSE 模式：MCP Server 以独立服务形式运行，客户端通过网络连接，适用于云端部署。

3.4 启动与部署方式

MCP Server 的启动并不需要用户手动执行复杂操作，主流方式是"客户端托管启动"。以连接 Postgres 数据库为例，用户只需在客户端配置文件中写入如下内容：

{
  "mcpServers": {
    "my-postgres-db": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://postgres:123456@localhost:5432/my_company_db"
      ]
    }
  }
}

上述配置的含义是：使用 Node.js 的包管理器 npx 自动获取并运行官方开源包 @modelcontextprotocol/server-postgres，并以数据库连接串作为启动参数。当用户重启客户端时，客户端将在后台自动执行该命令，完成 MCP Server 的启动与连接，界面通常以插头图标（🔌）标识连接状态。

对于需要独立部署的场景（如生产环境服务器），亦可通过命令行直接启动：

1	`npx -y @modelcontextprotocol/server-postgres postgresql://user:password@localhost:5432/mydb`

或使用容器方式运行：

1	`docker run -i --rm mcp/postgres postgresql://user:password@host.docker.internal:5432/mydb`

3.5 2026 年规范更新的技术要点

MCP 官方团队于 2026 年发布了新版规范，这是 MCP 自发布以来最重要的一次架构级演进，标志着 MCP 从"本地桌面工具协议"升级为"企业级云端与分布式智能体基础设施"。新版规范的核心技术要点包括：

要点一：无状态（Stateless）架构。旧版 MCP 主要依赖本地 stdio 或有状态的 SSE 长连接，难以在云端实现弹性扩容与负载均衡。新版规范使传输层完全无状态化并支持轻量路由，MCP Server 由此可以部署于 AWS Lambda、Cloudflare Workers 等 Serverless 平台，显著降低云端部署与运维成本。

要点二：原生集成 OAuth 2.1 与企业级安全。旧版 MCP 的鉴权通常依赖本地配置文件中的硬编码密钥，存在泄露风险。新版规范原生支持 OAuth 2.1 动态授权、Token 刷新与细粒度权限控制（RBAC），可满足企业级合规要求（如 SOC 2、GDPR），客户端调用企业 SaaS 时可弹窗完成安全登录授权。

要点三：分布式路由与智能体间协同。旧版 MCP 仅支持点对点通信。新版规范引入标准化路由头与多跳（Multi-hop）传输机制，使 MCP 请求可在多个网关、代理服务器与不同智能体之间安全转发，为"智能体调用智能体"（Agent-to-Agent）的协作网络奠定基础设施。

要点四：传输效率优化。新版规范优化了 JSON-RPC 消息格式，降低大文本（如大文件、海量日志）传输时的序列化开销与延迟。

从工程角度看，新版规范对开发者的直接影响包括：MCP Server 可按无状态服务标准编写并部署至 Serverless 平台；鉴权逻辑可由标准 OAuth 2.1 流程接管，无需自研密钥管理方案；跨智能体调用将获得官方的路由支持，为构建分布式智能体网络扫清协议层面的障碍。对于企业用户而言，新规范还意味着更严格的合规审计能力与更低的集成门槛。

四、Agent 智能体架构解析

本章关键词：Agent、智能体、ReAct 循环、函数调用、沙盒、上下文管理

4.1 定义与核心公式

Agent（智能体） 是指以大语言模型为核心决策单元，具备任务规划、记忆存储与工具调用能力，能够自主完成多步骤任务的软件系统。与"问答式"的纯模型交互不同，智能体的核心特征在于自主性（Autonomy）：用户只需提供最终目标，智能体即可自行拆解任务、调用工具、观察结果、修正错误，直至目标达成。

业界对智能体的结构形成了共识性描述，即核心公式：

Agent = 大语言模型（决策大脑） + 规划能力 + 记忆能力 + 工具调用能力

四个组成部分的职能界定如下：

决策大脑（LLM）：负责理解用户意图、进行推理与生成决策，是智能体的智力核心。
规划能力（Planning）：包括任务拆解（将大目标分解为有序子任务）与自我纠错（依据执行反馈修正策略）。规划能力使智能体具备"遇到报错后自行修复并重试"的行为特征。
记忆能力（Memory）：包括短期记忆（当前对话上下文）与长期记忆（通过知识库等外部存储持久化的业务知识与用户偏好）。
工具调用能力（Tools）：通过 MCP、Skills、命令行与各类 API 获得操控真实系统的能力，包括文件读写、网络请求、代码执行等。

为便于理解，可作如下类比：若将大语言模型比作"知识渊博但缺乏行动能力的专家"，则 Agent 相当于为该专家配备了完整的办公环境（电脑、网络、数据库权限与工作手册），使其从"只能提供咨询"转变为"能够独立执行任务"。

按工具调用与协同方式的差异，智能体还可进一步划分为三类形态：单工具智能体仅调用单一工具完成简单任务；多工具智能体可在多个工具之间切换以完成复合任务；多智能体协作系统由多个智能体分工协作，通过消息传递共同完成复杂目标。本文所述的技术体系主要面向后两类形态，而 4.2 节将要阐述的运行机制则是它们的共同基础。

4.2 运行机制的技术分解

Agent 软件（如 Claude Code、Cursor 等）使大语言模型具备自主行动能力的底层原理，可以归纳为四项核心技术机制。需要首先指出一个关键事实：大语言模型本身只是"文本输入-文本输出"的计算程序，真正执行系统操作的是模型外围的 Agent 框架。

机制一：核心循环（ReAct 模式）。Agent 框架的核心是一个任务驱动的主循环，其伪代码如下：

# Agent 框架核心逻辑（伪代码）
messages = [system_prompt, user_task]

while not task_completed:
    # 1. 将历史记录与可用工具列表提交给大模型
    response = llm.generate(messages, available_tools)

    # 2. 判断模型输出：是调用工具，还是给出最终答案
    if response.requires_tool_call:
        tool_name = response.tool_name
        arguments = response.arguments

        # 3. 由 Agent 框架在真实系统中执行该工具
        result = execute_in_real_environment(tool_name, arguments)

        # 4. 将真实执行结果（含报错信息）追加至历史记录，进入下一轮循环
        messages.append(f"工具执行结果：{result}")
    else:
        # 5. 模型判定任务完成，输出最终结果并退出循环
        print(response.final_answer)
        break

该循环即业界所称的 ReAct 模式（Reasoning + Acting），其本质是"思考-行动-观察"的迭代过程。模型自身并不具备执行能力，它只是在文本输出中表达"请运行某命令"的意图；真正执行命令、抓取终端输出并回传的，是外围的 Agent 框架。报错信息被如实回传后，模型得以在下一轮循环中自我修正，这正是智能体"遇到问题能自己解决"的机制来源。

为使上述机制更易理解，以下给出一个完整的"思考-行动-观察"迭代实例。假设智能体被要求"分析销售数据并绘制趋势图"：

思考（Thought）：需要先读取 sales.csv 文件；
行动（Action）：调用文件读取工具，打开 sales.csv；
观察（Observation）：确认数据包含 Date 与 Amount 两列；
思考（Thought）：需要编写绘图脚本，使用 matplotlib 库；
行动（Action）：生成绘图脚本并在沙盒中运行；
观察（Observation）：运行失败，报错 ModuleNotFoundError: No module named 'matplotlib'；
思考（Thought）：环境缺少绘图库，需先安装依赖；
行动（Action）：执行 pip install matplotlib，随后重新运行脚本；
观察（Observation）：趋势图生成成功；
最终输出：向用户交付图表并附上分析结论。

该实例表明，智能体的"自主性"并非来自模型自身的特殊能力，而是源于循环机制与错误回传的结合：报错信息作为观察结果进入下一轮思考，使模型得以自我修正。这正是"遇到问题能自己解决"的行为学本质。

机制二：结构化输出与函数调用（Function Calling）。大模型如何将意图精准传达给框架？答案是：Agent 框架在调用模型 API 时，同时提交一组工具定义（工具名称、描述与参数 Schema）；模型若决定使用某工具，将输出严格符合格式的结构化 JSON（而非自然语言），例如：

{
  "tool_call": "run_bash",
  "arguments": { "command": "python -m pytest" }
}

框架解析该 JSON 后，调用系统接口（如 Python 的 subprocess）执行对应命令。这一"工具定义注入 + 结构化输出解析"的机制，使模型的意图能够被机器可靠地翻译为系统操作。

机制三：上下文与记忆管理。随着循环轮次增加，历史记录将迅速膨胀直至超出模型的上下文窗口。Agent 框架在此承担"记忆整理员"职责：一方面，通过摘要压缩将冗长的执行日志浓缩为简短结论；另一方面，借助检索增强生成（RAG）从外部知识库中检索最相关片段注入当前上下文，实现长期记忆的按需供给。

机制四：沙盒与权限控制。Agent 框架能够读写文件、发起网络请求、执行命令，其根本前提是运行环境向其授予了真实系统权限。为防止模型误操作造成破坏（如误删系统文件），主流 Agent 软件将操作限制于 Docker 容器或受限沙盒中，并对高危命令实施人工确认（Approval）机制。

4.3 客户端依赖关系

结合前文论述，可以得出一个重要的结构性结论：裸大模型无法直接使用 MCP，必须经由实现 MCP 客户端协议的软件（即 Agent 软件或桌面客户端）作为中介。其架构层次如下：

┌──────────────────────────────────────────────────────────┐
│ 第一层：大语言模型（LLM）                                  │
│ 职能：纯文本推理与决策，输出工具调用意图（JSON）          │
└──────────────────────────┬───────────────────────────────┘
                           │ 思考结果
                           ▼
┌──────────────────────────────────────────────────────────┐
│ 第二层：Agent 软件 / MCP 客户端（Claude Code、Cursor 等） │
│ 职能：进程管理、配置读取、启动 MCP Server、翻译与发送请求 │
└──────────────────────────┬───────────────────────────────┘
                           │ JSON-RPC 通信（Stdio / HTTP）
                           ▼
┌──────────────────────────────────────────────────────────┐
│ 第三层：MCP Server（Postgres MCP、GitHub MCP 等）        │
│ 职能：真实执行数据库查询、HTTP 请求、浏览器操作等        │
└──────────────────────────────────────────────────────────┘

该三层架构表明：大语言模型提供"智慧"，MCP Client 提供"管道、手脚与循环机制"，MCP Server 提供"外部系统连接"。三者缺一不可。若用户仅使用网页版对话界面（未安装任何 Agent 软件），则模型因缺乏本地执行环境而无法访问本地文件与外部系统，这正是"网页版 AI 无法替用户操作电脑"的根本原因。

五、体系串联：Agent 调用 MCP 的完整链路

本章关键词：能力发现、意图匹配、工具调用、端到端链路、体系整合

5.1 四步握手过程

Agent 与 MCP Server 的交互遵循一套标准的"能力发现与调用"流程，可概括为四个步骤：

第一步：能力发现（握手与自我介绍）。Agent 启动并连接 MCP Server 后，通过 tools/list 请求获取该 Server 的全部能力清单。MCP Server 返回符合 JSON Schema 标准的工具说明书，例如：

{
  "tools": [
    {
      "name": "query_database",
      "description": "在 Postgres 数据库中执行 SQL 查询",
      "inputSchema": {
        "type": "object",
        "properties": {
          "sql": { "type": "string", "description": "待执行的 SQL 语句" }
        },
        "required": ["sql"]
      }
    }
  ]
}

该说明书明确告知模型：可用工具为 query_database，其功能为执行 SQL 查询，调用时必须传入字符串参数 sql。

第二步：意图匹配与参数拼装。Agent 框架将工具说明书注入模型上下文，模型依据用户请求进行工具选择。例如用户询问"查询姓张的用户数量"，模型将匹配 query_database 工具，自动生成 SQL 语句，并输出结构化调用指令。

第三步：请求发送。Agent 框架通过 JSON-RPC 消息向 MCP Server 发送 tools/call 请求：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT COUNT(*) FROM users WHERE last_name = '张'"
    }
  },
  "id": 1
}

第四步：执行与回传。MCP Server 执行真实查询，将结果封装为 JSON 回传 Agent；Agent 将结果注入模型上下文，模型最终以自然语言向用户呈现结论（如"姓张的用户共 42 人"）。

上述四步流程可用"餐厅点餐"作类比：MCP Server 递出菜单（能力清单），模型据菜单点菜（意图匹配），框架向厨房下单（发送请求），厨房出菜并由服务员上桌（执行回传）。Agent 之所以"知道" MCP 如何被使用，并非依赖事先记忆，而是依靠 MCP Server 在连接建立瞬间动态提供的自我描述信息。

5.2 端到端应用场景分析

为完整展示前文各要素的协同关系，本节给出一个综合应用场景：智能代码助手协助开发者完成"代码审查、数据查询与团队通知"的完整流程。

场景设定：开发者使用支持 MCP 的 Agent 软件，环境中已配置 GitHub MCP 与 Slack MCP，并安装 PR-Review-Skill 技能包。开发者发出指令："审查第 42 号 Pull Request，并将审查结论发送至团队 Slack 频道。"

执行链路分解：

系统提示词层：会话开始前，系统提示词已设定智能体的人设与行为准则（如"先规划后执行、结论须附依据"），全程约束模型行为。
能力层（Skills）：模型识别到任务类型与 PR-Review-Skill 的描述相匹配，按需加载该技能，获取审查流程标准（如"第一步检查单元测试，第二步排查安全漏洞，第三步按固定格式输出评论"）。
协议层（MCP）：模型依据技能流程，依次调用 GitHub MCP 提供的工具（如 get_pull_request、create_review_comment）拉取代码并提交评语；随后调用 Slack MCP 的发送消息工具，将审查结论发布至指定频道。
执行层（Agent 框架）：在上述过程中，Agent 框架持续执行工具调用、回传结果、管理上下文；若调用过程中出现错误（如 API 鉴权失败），框架将错误信息回传模型，模型据以修正后重试。
数据层（知识库）：若审查涉及团队内部编码规范，模型将通过知识库检索相关规范文档，确保审查意见符合团队标准。

在上述执行过程中，还存在两个保障机制值得说明。其一是人工审批（Approval）：对于具有高风险副作用的操作（如修改数据库、推送代码、发送消息），Agent 框架会在执行前暂停并请求用户确认，防止模型误操作造成不可逆后果。其二是上下文治理：随着多轮工具调用的累积，Agent 框架会压缩历史记录、清理临时文件，确保长任务的稳定性与上下文窗口的可持续性。这两项机制共同保证了智能体在"自主"与"可控"之间的平衡。

上述链路清晰地展示了五要素的分工与协同：提示词与系统提示词约束"如何表现"，知识库供给"事实依据"，Skills 提供"作业流程"，MCP 打通"系统连接"，Agent 提供"执行载体"。任一环节缺失，均可能导致任务无法完成或质量下降。

5.3 体系总结与展望

综合全文论述，可将五要素的特征汇总如下：

要素	核心定位	解决的核心问题	动态性	工程形态
提示词	即时指令	本次任务做什么	随对话变化	文本
系统提示词	全局行为准则	模型以何种身份与规则工作	会话级常驻	文本
知识库	外部事实供给	模型不知道的事实从何而来	实时检索	数据库 + RAG
Skills	任务方法论封装	按什么流程完成某类任务	按需加载	SKILL.md + 脚本
MCP	系统连接标准	如何统一接入外部系统	运行时连接	JSON 配置 + 服务程序
Agent	执行载体与调度中枢	谁来整合上述要素并真实行动	持续运行	客户端软件/框架

此外，需客观指出该体系在实践中仍面临若干风险与挑战：一是幻觉问题，当知识库检索结果不充分或提示词约束不足时，模型仍可能生成与事实不符的内容，因此检索质量与引用机制至关重要；二是安全风险，工具调用权限若未严格控制，可能造成数据泄露或系统破坏，权限最小化与人工审批机制不可或缺；三是成本问题，长上下文、多轮工具调用与向量检索均会产生可观的资源消耗，需要在能力与成本之间进行权衡。

从技术演进的视角审视，本文所述体系的演进脉络清晰可辨：提示词工程解决了"如何让模型回答得更好"；RAG 解决了"模型不知道的事实"；Skills 解决了"模型如何按流程执行复杂任务"；MCP 解决了"模型如何安全统一地连接外部世界"；Agent 则将上述能力整合为可自主行动的系统。这一演进路径的本质，是人工智能从"对话系统"向"执行系统"的范式转移。

可以预见，随着 MCP 新规范（无状态架构、OAuth 2.1、分布式路由）的落地，智能体之间的互联互通将成为现实，"智能体互联网"（Agentic Web）的雏形正在形成。对于开发者与使用者而言，理解本文所述的技术体系，不仅是掌握一组工具，更是理解人工智能应用下一阶段演进方向的必要基础。

思考题

【★★☆】Skills 的"按需加载"机制与"系统提示词全程常驻"机制相比，各自的适用场景是什么？若一个技能被高频使用，两种机制在上下文开销与响应速度上分别有何表现？
提示：可从 Token 经济性与意图匹配延迟两个角度分别分析。
【★★★】本文指出"Markdown 中的代码块只是文本，执行前必须落盘为真实文件"。请思考：若某一框架宣称支持"MD 内嵌脚本直接执行"，其底层实现必然包含哪些机制？该机制与"独立脚本文件"模式相比，在安全性与可靠性方面各有哪些隐患？
提示：考虑文件系统写入、代码提取的正确性、沙盒隔离三个层面。
【★★★】MCP 将集成复杂度从 O(M×N) 降为 O(M+N)。请评估：在什么条件下（例如工具数量极少、或对延迟极度敏感的场景），直接编写专用适配代码反而优于引入 MCP？请给出判断依据。
提示：从协议开销、维护成本、团队规模、生态成熟度四个维度权衡。
【★★☆】假设一个企业需要让智能体访问内部数据库，但安全团队禁止任何第三方程序直接连接数据库。请基于第四章的三层架构，设计一种既满足安全合规又能实现"智能体查询数据库"的技术方案。
提示：考虑在 MCP Server 层与数据库之间增加只读代理、审计日志与权限白名单。
【★★☆】本文的四步握手流程中，MCP Server 通过"自我描述"（JSON Schema）向模型告知工具用法。请思考：如果 MCP Server 返回的工具描述不准确或过时，模型端会发生什么？该问题应从协议层还是应用层解决？
提示：可从幻觉产生机制与 Schema 版本管理两个方向思考。

#AI

渲染测试上一篇

第九章多元函数微分学下一篇