【LLM相关知识点】 LLM关键技术简单拆解，以及常用应用框架整理（二）

【LLM相关知识点】 LLM关键技术简单拆解，以及常用应用框架整理（二）

一、市场调研：业界智能问答助手的标杆案例

关于垂直领域智能问答助手标杆案例及技术细节：

垂直领域	标杆案例	框架选型	核心技术方案与流程	瓶颈问题	解决方案
​医疗	南山医院AI助手	LangChain + MaxKB	1. 基于DeepSeek-R1微调医学文献 2. 集成PubMed/UpToDate知识库RAG检索 3. 医疗实体识别与知识图谱校验	1. 医疗长文本处理效率低 2. 专业术语歧义导致幻觉 3. 文献更新延迟	1. 采用LlamaIndex优化分块检索 2. 构建实体消歧规则引擎 3. 增量更新机制
​法律	福田公证处智能客服 2	LlamaIndex + Haystack	1. 法律文本结构化解析（NER + 关系抽取） 2. 条款对比模块 3. 风险条款匹配与案例法关联	1. 复杂法律文本解析错误 2. 地域法条冲突 3. 时效性验证困难	1. 分层注意力机制预训练 2. 时空维度法律知识图谱 3. 法条更新API接入
​电商	千川智能客服 3	Coze平台 + DeepSeek模型	1. 多轮对话状态跟踪 2. 订单/物流API集成 3. 敏感信息过滤	1. 小语种覆盖不足 2. API响应不稳定 3. 方言理解偏差	1. 混合机器翻译与低资源微调 2. 异步重试机制 3. 领域术语增强词表
​教育	清华大学自适应学习系统 4	LangChain + Ollama本地部署	1. 错题模式分析 2. 知识点拓扑路径生成 3. 多难度答案生成	1. 个性化推理资源消耗大 2. 跨学科融合困难 3. 交互延迟	1. 动态压缩学生特征向量 2. 学科交叉知识图谱 3. 边缘节点轻量化部署
​政务	洋山VTS智慧政务助手 2	RAGFlow + DeepSeek	1. 政策文件结构化解析 2. 多部门知识库融合 3. 审批流程自动化	1. 非结构化数据抽取误差 2. 跨部门数据孤岛 3. 安全合规要求高	1. LayoutLM优化表格解析 2. 联邦学习框架 3. 国密算法数据加密
​金融	东财"小银杏"投顾助手 2	AutoGen + vLLM	1. 多模态财报解析（OCR+表格理解） 2. 行业指标对比 3. 合规审查模块	1. 数值推理错误率高 2. 实时数据延迟 3. 金融风控规则复杂	1. 数学符号增强微调 2. 流式数据优先级缓存 3. 规则引擎嵌套校验

1、技术方案共性特征

1. ​架构选型：普遍采用 “预训练模型（DeepSeek）+ RAG增强 + 垂直领域插件” 的三层架构

   参考 DeepSeek 接入 MaxKB 知识库问答系统，真的太香了！

2. ​核心创新：

   • 医疗领域采用动态知识图谱校验机制

   • 法律系统开发时空维度法条追踪模块

   • 电商客服引入方言增强型BERT模型 这产品经理：基于DeepSeek手搓AI智能客服（附案例）

3. ​性能优化：

   • 使用LlamaIndex实现长文档O(1)时间复杂度检索

   • 通过MoE架构将激活参数控制在总参数量5%-8% 必看！万字长文为你深度解析DeepSeek

   • 采用MLA注意力机制减少30% KV缓存 漫谈DeepSeek及其背后的核心技术_腾讯新闻

2、典型瓶颈与突破

1. ​长文本处理：通过分段注意力机制和层次化检索，将医疗文献处理速度提升4倍

2. ​多模态融合：金融领域结合LayoutLM实现表格结构识别准确率达92%

3. ​实时性要求：使用vLLM的连续批处理技术，使投研报告生成延迟降低至3秒内 深度剖析：DeepSeek四大热门部署框架全方位对比

4. ​安全合规：政务系统采用国密SM4算法实现知识库加密，通过等保三级认证

更多技术细节可参考DeepSeek官方生态集成指南DeepSeek官方整理的R1/V3 LLM生态实用集成工具「AI技术选型必备 及MaxKB开源项目文档 DeepSeek 接入 MaxKB 知识库问答系统，真的太香了！

3、案例关键技术流程图分析

东莞水务系统

• 采用双通道处理架构：文档处理通道集成格式校对（LayoutLM技术） 和智能审核模块，数据通道实现时序预测（Prophet算法）与可视化（Echarts）
• 知识库检索响应时间 < 3秒 参考东莞水务集团上线DeepSeek AI智能助手_腾讯新闻

教育系统

• 错题分析采用动态特征提取技术（TF-IDF优化算法）

• 知识拓扑构建融合图神经网络（GNN）和TransE嵌入模型

​智能客服：

• RAG检索层使用Hybrid Search混合检索（BM25+Embedding）
• 安全模块集成正则表达式和规则引擎双重过滤

二、LLM关键步骤和关键技术 - LLM基座的黑箱拆解

1、LLM关键步骤（文本输入 - LLM（DS / TY / ChatGPT） - 文本输出的过程）

参考 从黑箱到透明：深度拆解LLM的8个关键步骤

表面上看，大型语言模型（LLMs）似乎非常直接——你输入一些内容，它们生成一个回应。简单的输入，简单的输出。但在幕后，这是一个复杂的转换链——原始文本被分解成数字，通过神经计算的多层处理，最终，模型生成的内容听起来非常接近人类的语言。从根本上说，这一切都归结为一件事：预测下一个词。

输入处理（如何为模型准备文本） -> 神经网络处理（LLMs如何思考）-> 输出处理与解码（生成下一个标记） -> 训练与优化（LLMs如何学习） -> 记忆与上下文处理（LLMs如何“记住”事物）-> 定制与推理（LLMs如何部署与使用） -> 评估与安全性（我们如何衡量和改进LLMs）-> 扩展与未来改进（LLMs的未来是什么？）

1）第一步：输入处理（如何为模型准备文本）

LLMs并不“阅读”文本——它们处理数字。标记化是这一过程中的第一个关键步骤。

目标：将原始用户文本转换为模型可以理解的格式。

原始文本 → 标记化 → 标记ID → 模型的结构化输入

关键步骤：

• 原始文本 → 预处理文本：清理输入（去除多余空格、统一大小写、格式化特殊字符）。

• 文本 → 标记：使用标记器（BPE、WordPiece、Unigram）将输入拆分为单词/子单词。

• 标记 → 标记ID：根据模型的词汇表，将每个标记映射到唯一的数字ID。

• 标记ID → 对话模板（如果适用）：将输入结构化为系统、用户和助手角色，用于对话式AI。

• 标记ID → 模型输入：将标记打包为带有填充、截断和注意力掩码的格式。

• 传递到神经网络：将编码后的输入传递到模型的嵌入层进行进一步处理。

import tiktoken

tokenizer = tiktoken.encoding_for_model("gpt-4")
text = "I want to learn about LLMs"
tokens = tokenizer.encode(text)

print("Token IDs:", tokens) # [40, 1390, 311, 4048, 922, 445, 11237, 82]
print("Decoded Tokens:", [tokenizer.decode([t]) for t in tokens])
#['I', ' want', ' to', ' learn', ' about', ' L', 'LM', 's']

2）第二步：神经网络处理（LLMs如何思考）

这是模型学习含义、上下文和单词之间关系的地方。

目标：使用多层自注意力和神经计算转换标记嵌入。

标记ID → 嵌入 → 位置编码 → 自注意力 → 转换后的表示

关键步骤：

• 标记ID → 嵌入：通过嵌入矩阵将标记ID映射为密集向量表示。

• 嵌入 → 位置编码：使用正弦或学习编码添加顺序信息。

• 位置编码 → 自注意力机制：通过查询-键-值（QKV）矩阵计算所有标记之间的关系。

• 自注意力输出 → 多头注意力：使用多个注意力头捕捉不同的单词关系。

• 多头注意力 → 前馈层：应用非线性转换以优化学习的表示。

• 最终表示 → 下一步处理：输出处理后的嵌入，用于解码和标记预测。

3）第三步：输出处理与解码（生成下一个标记）

模型处理输入后，通过将内部表示转换为可能单词的概率分布来预测下一个标记。

目标：将数字表示重新转换为人类可读的文本。

最终隐藏状态 → 逻辑值 → Softmax → 下一个标记选择 → 反标记化文本

关键步骤：

• 最终隐藏状态 → 逻辑值：将处理后的嵌入转换为每个可能的下一个标记的原始（未归一化）分数。

• 逻辑值 → 概率：应用Softmax函数将原始分数转换为概率分布。

• 下一个标记选择（解码策略）：使用贪婪解码、束搜索或采样等方法选择下一个标记。

• 将标记追加到输出：将选定的标记添加到不断增长的序列中。

• 标记ID → 文本（反标记化）：将生成的标记ID转换为人类可读的文本。

• 重复直到完成：该过程循环，直到达到序列结束标记或最大长度。

4）第四步：训练与优化（LLMs如何学习）

训练是LLMs学习语言和识别模式的地方——数据集越大，模型越智能。

目标：使用大规模数据集和优化技术训练模型。

无监督预训练 → 有监督微调 → 基于人类反馈的强化学习（RLHF） → 损失计算 → 权重更新

关键步骤：

• 无监督预训练：在大规模文本中预测缺失的单词（下一个单词预测、掩码标记）。

• 有监督微调：在标记数据上训练，以实现特定任务的改进（例如，总结、问答）。

• 基于人类反馈的强化学习（RLHF）：使用奖励模型根据人类反馈优化响应。

• 损失函数：衡量预测错误（交叉熵损失、KL散度）。

• 反向传播：计算梯度并根据错误调整模型权重。

• 优化（梯度下降）：迭代更新权重以最小化损失（Adam、SGD）。

5）第五步：记忆与上下文处理（LLMs如何“记住”事物）

这一步帮助LLMs跟踪对话、回忆相关细节并改进长篇回答！

目标：在对话的多个回合中保留上下文。

上下文窗口限制 → 注意力优化 → 检索（RAG）→ 提示结构化

关键步骤：

• 上下文窗口：限制模型一次可以处理的标记数量（例如，4K、8K、100K标记）。

• 滑动窗口注意力：通过向前移动窗口保留最近的标记，随着新标记的添加。

• 长上下文处理：使用注意力机制（如ALiBi、RoPE或内存高效型Transformer）。

• 检索增强型生成（RAG）：检索相关外部文档以补充模型响应。

• 提示工程：结构化输入以引导模型回忆并保持连贯性。

• 内存持久性（微调与外部工具）：调整权重（微调）或使用外部内存（向量数据库）。

6）第六步：定制与推理（LLMs如何部署与使用）

这是LLMs被定制、优化并在现实世界应用中部署的地方——例如AI聊天机器人、编程助手和搜索引擎。

目标：将预训练模型适应特定用例。

微调 → 指令调优 → 提示调优 → LoRA → 实时优化响应

关键步骤：

• 预训练模型 → 微调模型：将通用LLM适应于特定任务（例如，编程、医疗AI）。

• 提示调优（软提示）：通过调整嵌入而非权重实现轻量级适应。

• LoRA与适配器层：高效微调特定模型层，降低计算成本。

• 指令调优：训练模型更准确地遵循结构化提示。

• 推理管道：将用户输入 → 标记化 → 模型处理 → 响应生成。

• 延迟优化：使用量化、蒸馏和批处理实现更快的实时响应。

7）第七步：评估与安全性（我们如何衡量和改进LLMs）

LLMs可能会产生幻觉、强化偏见或产生不可靠的输出，因此评估至关重要。

目标：衡量性能、检测偏见并确保可靠、道德的AI输出。

困惑度 → 一致性指标 → 偏见/毒性检查 → 幻觉检测 → 鲁棒性测试

关键评估指标：

• 困惑度与准确性：困惑度越低，预测越好；准确性衡量结构化任务中的正确性。

• BLEU、ROUGE、METEOR（文本质量）：评估生成文本的流畅性和一致性。

• 偏见与公平性检查：使用专门的数据集检测并缓解有害偏见。

• 毒性与安全过滤器：应用分类器防止有害或冒犯性输出。

• 幻觉检测：使用事实一致性模型识别错误或虚构的信息。

• 红队测试与对抗性测试：对模型进行压力测试，以应对操纵性或恶意提示。

8）第八步：扩展与未来改进（LLMs的未来是什么？）

这一步专注于使LLMs更快、更具可扩展性，并为未来的AI应用做好准备！

目标：提高效率、增加上下文长度并扩展能力（例如，多模态AI）。

模型扩展 → 效率优化 → 更长的上下文 → 多模态AI → 边缘部署

关键步骤：

• 模型扩展（更大的网络）：增加参数（从GPT-3到GPT-4）以提高性能。

• 高效架构：使用稀疏模型（Mixture of Experts、Transformer-XL）以降低计算成本。

• 更长的上下文窗口：通过内存高效的注意力机制（ALiBi、RoPE）扩展标记限制。

• 量化与剪枝：在保持准确性的同时减小模型大小，以实现更快的推理。

• 本地与边缘AI：优化小型模型（如GPT-4 Turbo、LLaMA）以实现本地部署。

• 多模态能力：扩展到文本之外（视觉-语言模型、语音集成）。

2、LLM关键步骤中的关键技术（文本结构化处理，词向量编码，QKV矩阵计算、解码预测、训练优化、长时记忆）

基于ChatGPT、QWen、DeepSeek等通用大模型的技术实现，LLM的关键步骤确实包含如下6个核心步骤：1）文本准备、2）LLM处理成词向量、3）词向量以及位置编码进行QKV矩阵计算、4）解码得到下一个单词、5）减少目标损失和训练优化、6）以及长时记忆处理。

以下从技术实现角度对各步骤进行拆解，结合关键技术对比分析，关键技术对比总览如下

步骤	技术方案	优势	局限性	典型应用模型
文本准备	BPE分词	高效处理复合词/数字	需要预训练词汇表	GPT系列/DeepSeek
位置编码	RoPE	外推性强/显式相对位置	计算复杂度较高	LLaMA/Qwen
QKV计算	GQA分组查询	显存占用减少40%	需定制硬件优化	DeepSeek-671B
解码策略	Top-p采样	多样性/质量平衡	超参数敏感	ChatGPT/Claude
训练优化	GRPO	省去奖励模型/成本低	组内采样偏差风险	DeepSeek-R1
长时记忆	NTK+滑动窗口	零训练扩展上下文	长距离依赖衰减	Qwen-72B

1）文本准备（输入处理）​

关键技术：

• ​数据清洗​：去除噪声、格式统一、冗余信息过滤

• ​标记化（Tokenization）：BPE（GPT系列）、WordPiece（BERT）、Unigram（SentencePiece）

• ​对话模板​：ChatGPT的系统/用户/助手角色结构化（如Alpaca模板）

技术核心： 参考 【人工智能学习】大语言模型LLM领域词向量化处理

• BPE（GPT系列，Byte-Pair Encoding）：​

  • 核心思想：基于数据压缩技术，通过迭代合并高频字符对生成子词单元，解决长尾词和跨语言分词问题。例如，将"low"、“lower"合并为"low”+“er”

  • 技术特点：

    • ​压缩性：将文本分解为字节级子词，词汇表效率高（如GPT-2采用BBPE处理多语言）

    • ​OOV处理：通过子词组合覆盖未登录词，减少词表大小（典型词表约3万-5万）

  • ​应用模型：GPT系列（GPT-1/2/3）、Llama、Bloom等

  参考 深入解析 Transformers 框架（四）：Qwen2.5/GPT 分词流程与 BPE 分词算法技术细节详解

• WordPiece（BERT）：

  参考 【BERT】一文读懂BERT中的WordPiece

  • 核心思想：通过概率最大化而非频率优先的合并策略，优先合并提升语言模型似然值的子词对

  • ​技术特点：

    • ​前缀标记：非首字符子词添加##前缀（如"##ing"），区分词内位置。

    • ​动态合并：训练时逐步扩展词表，更适合处理形态丰富的语言（如德语、中文复合词）。

  • ​应用模型：BERT、DistilBERT、ELECTRA等。

• Unigram（SentencePiece）：

  参考 SentencePiece 库简介，并说明了它在 训练 Llama 2 词汇表中的应用

  • 核心思想：基于语言模型概率初始化大词表，逐步剪枝低频子词，支持多语言与灵活分词粒度。

  • ​技术特点：

    • ​概率驱动：通过Unigram语言模型评估子词重要性，保留高概率单元

    • ​无损分词：保留空格等特殊符号，适合无空格语言（如中文、日文）

  • ​应用场景：SentencePiece工具默认算法之一，用于XLNet、T5等模型

• Alpaca模板：

  参考大模型-alpaca格式数据说明 - 漫漫长夜何时休 - 博客园

  alpaca 格式的数据集应遵循以下格式：

  [
   {
     "instruction": "user instruction (required)",
     "input": "user input (optional)",
     "output": "model response (required)",
     "system": "system prompt (optional)",
     "history": [
       ["user instruction in the first round (optional)", "model response in the first round (optional)"],
       ["user instruction in the second round (optional)", "model response in the second round (optional)"]
     ]
   },
   ...
  ]
  

  字段作用

  • instruction: 必须提供，用户的指令或问题。
  • input: 可选，提供上下文信息。
  • output: 必须提供，模型对instruction的输出。
  • system: 可选，系统提示或者说是prompt、角色设定等。
  • history: 必须提供，一个列表，表示历史对话，为空则表示这是新的对话。只需要提供instruction和output即可。

• 通过分词算法将文本转换为模型可理解的离散符号（Token ID），例如DeepSeek采用BBPE分词并拆解数字为单字符。对比传统空格分词，子词分词（如BPE）能更好处理长尾词汇，词汇表效率提升30%+。

---

2）词向量处理与位置编码

参考【人工智能学习】大语言模型LLM领域词向量化处理

关键技术：

• ​静态嵌入​：Word2Vec（CBOW / Skip-gram）

• ​动态嵌入​：BERT的上下文相关嵌入

• ​位置编码：RoPE（QWen/LLaMA）、正弦编码（原始Transformer）、可学习编码（PaLM）

技术核心：

• Word2Vec（CBOW / Skip-gram）：

  • 核心思想：

    通过浅层神经网络学习静态词向量，基于 “上下文相似则语义相似” 的分布式假设，包含 ​CBOW​（用上下文预测中心词）和 ​Skip-gram​（用中心词预测上下文）两种模型。

  • 技术特点：

    • 采用负采样（Negative Sampling）和层次Softmax（Hierarchical Softmax）降低计算复杂度。

    • 生成的词向量具有线性可加性（如 king - man + woman ≈ queen）。

  • 对比：与GloVe相比，Word2Vec仅关注局部上下文窗口，未利用全局共现统计信息

• BERT的上下文相关嵌入：

  • 核心思想：

    基于双向Transformer架构，通过 ​Masked Language Model (MLM) 和 ​Next Sentence Prediction (NSP) 任务生成动态词向量，词向量随上下文变化

  • 技术特点：

    • 双向自注意力机制捕捉全局上下文依赖（如多义词“bank”在不同句子中含义不同）。

    • 训练后生成的向量可直接用于下游任务（如分类、问答）。

  • 对比：与静态词嵌入（Word2Vec）相比，BERT动态调整词向量，但对算力需求更高

• 旋转位置编码（RoPE）：

  参考 【大模型知识点】位置编码——绝对位置编码，相对位置编码，旋转位置编码RoPE - 自学内容网

  • 核心思想：通过旋转矩阵将绝对位置信息编码到词向量中，实现相对位置感知。

  • 技术特点：

    • 对查询（Q）和键（K）向量施加旋转操作，使注意力分数仅依赖相对位置差（如 m - n）。

    • 支持长序列外推（如训练时使用512长度，推理可扩展至4096）。

  • 对比：相比正弦位置编码（如Transformer原生方案），RoPE无需显式位置嵌入，计算更高效且外推性更强

---

​3）QKV矩阵计算（自注意力机制）​

参考 LLM注意力Attention，Q、K、V矩阵通俗理解，Qwen的前世今生

关键技术：

• ​多头注意力​：标准Transformer的多头计算（如GPT-4的128头）

• ​稀疏注意力​：Qwen的MLA（多头潜在注意力） 减少93.3% KV缓存

• ​优化计算​：Flash Attention加速、GQA分组查询（DeepSeek 671B）

技术核心：

• MLA（多头潜在注意力）：

• Flash Attention加速：

• GQA分组查询：

• 通过$Q{K}^T/\sqrt{d}$​计算注意力权重，再与V加权合成上下文表示。对比标准多头注意力，DeepSeek的GQA在推理速度上提升40%且精度损失<1%。Qwen的MLA通过压缩KV缓存显著降低显存占用

---

4）解码生成

关键技术：

• ​贪婪解码：最高概率单路径（速度快但多样性差）

• ​束搜索​：保留Top-k候选路径（平衡质量与效率）

• ​温度采样​：调节Softmax概率分布的平滑度

技术核心：

• 贪婪解码（Greedy Decoding）：softmax输出最大概率

  参考「贪心解码」- 十步完全解析大语言模型如何玩「语言游戏」

  • 核心思想：
    在每一步解码时仅选择当前概率最高的单个词（Token），生成单一路径的序列。

  • 技术特点：

    • ​速度优势：无需维护多个候选路径，计算复杂度低，适合实时生成场景（如对话系统）。

    • ​局限性：易陷入局部最优，导致重复或单调文本（如连续生成多个相同词）。
      典型应用：

    • 早期语言模型（如GPT-2）的默认解码方式。

  • 需要快速生成但多样性要求较低的场景（如简单问答）。

• 束搜索（Beam Search）：Top-K的累积概率路径

  参考 大语言模型的解码策略与关键优化总结 - 腾讯云开发者社区-腾讯云

  • 核心思想：
    维护一个固定数量（k，即束宽）的候选路径，在每一步扩展并保留概率最高的前k个序列。

  • 技术特点：

    • ​质量与效率平衡：通过并行探索多条路径，减少局部最优风险（如避免重复生成）。

    • ​参数影响：束宽越大，生成质量通常越高，但计算资源消耗也增加。
      实现流程：

      1. 初始化候选序列（如起始符）。

      2. 每步扩展候选路径，计算累积概率。

      3. 筛选并保留Top-k高概率路径。

      4. 终止于最大长度或结束符（如<EOS>）。

    • 典型应用：机器翻译（如保证译文连贯性），文本摘要生成（需兼顾准确性和多样性）

• 温度采样（Temperature Sampling） ：有点类似模拟退火算法

  • 核心思想：
    通过温度参数（T）调节Softmax概率分布的平滑度，控制输出的随机性。

  • 技术特点：

    • ​温度作用：

      • ​低温度（T < 1）​：放大高概率词的概率，生成更确定、保守的文本。
      • ​高温度（T > 1）​：平滑概率分布，增加多样性但可能引入错误。

    • ​灵活性：与其他策略（如Top-K、核采样）结合使用，优化生成效果。
      数学公式：
      $P(x_i)={\sum }_j\frac{exp(z_i/T)}{exp(z_j/T)}$

  温度采样（T=0.7）在创意文本生成中困惑度比贪婪解码低12%，但推理延迟增加30%。DeepSeek在代码生成中采用Top-p=0.95采样，准确率比束搜索高8%；

5）训练优化

参考 所谓的推理模型其实是基于 LLMs 在特定场景下的应用

关键技术：

• ​预训练​：掩码语言建模（BERT）、自回归预测（GPT）

• ​微调策略：监督微调SFT、RLHF（ChatGPT）、GRPO（DeepSeek-R1）

• 损失函数：交叉熵损失（Cross-Entropy Loss）​、填充中段损失（Fill-in-the-Middle Loss）​、多任务联合优化损失、强化学习相关损失（策略梯度目标函数、奖励建模损失）、特殊场景优化损失（长文本记忆损失、数学推理专项损失）

• ​优化器​：AdamW（主流）、Lion（Qwen2）、混合精度训练 。

技术核心：

• ChatGPT采用三阶段训练（SFT→RL→RLHF），而DeepSeek-R1使用GRPO算法，通过组内评分替代传统奖励模型，训练成本降低60%。Qwen的混合专家架构（MoE）在万亿参数规模下训练效率提升3倍。

损失函数说明 和 关键技术对比分析：

模型	核心损失函数	创新点	训练效率增益
ChatGPT	PPO+加权交叉熵	价值函数裁剪防止策略突变	1.8倍
Qwen2.5	GRPO+自适应任务损失	动态权重分配与规则验证器融合	2.1倍
DeepSeek-v3	序列平衡损失+记忆关联损失	MoE负载均衡与外部知识库协同	3.4倍

a）基础预测损失函数

参考 3分钟学会ChatGPT 输出偏差的计算方式–损失函数，Qwen2.5-Math、Qwen2.5-Coder训练过程和实现细节

交叉熵损失（Cross-Entropy Loss）​：

• ​应用场景：所有模型的预训练和微调阶段，用于衡量预测概率分布与真实标签的偏差。

• ​技术实现：

  • ChatGPT采用加权交叉熵，在对话数据中为高频回答设置较低权重以防止过拟合。

  • Qwen2.5-Math在数学预训练中使用分层交叉熵，为不同难度题目分配动态权重

  • DeepSeek-v3引入温度缩放系数，将交叉熵与专家路由损失结合（$L_{total}=0.7L_{CE}+0.3L_{router}$）

• ​对比：相较于传统MSE损失，交叉熵对分类任务准确率提升达18%-35%

填充中段损失（Fill-in-the-Middle Loss）​：

• ​专有场景：代码模型训练

  • DeepSeek-Coder在文件级预训练中采用FIM损失，通过随机掩码代码段迫使模型补全上下文；

  • Qwen2.5-Coder将代码文件分割为prefix/middle/suffix三段，计算middle段的预测损失；

b）多任务联合优化损失

任务自适应加权损失

• ​Qwen技术方案：

  • 动态调整MLM、NSP、代码生成任务的损失权重

  • 使用元学习框架自动优化权重分配，数学任务权重比代码任务高1.2 - 1.5倍

• ​DeepSeek创新：

  • 在MoE架构中引入序列平衡损失（Sequence Balance Loss），通过指标函数监控专家负载均衡性

  • 公式：$L_{balance}=\lambda {\sum }_{s\in S}{\sum }_{e\in E}(count(e,s)-\mu {)}^2$，其中$\mu$为期望负载

对抗训练损失

• ​DeepSeek对抗机制：

  • 采用WGAN-GP梯度惩罚，生成对抗样本增强鲁棒性

  • 损失函数包含生成器损失$L_G$​和判别器损失$L_D$​，通过参数共享实现高效训练

• ​Qwen防御策略：

  • 在文本分类任务中引入FGM对抗训练，扰动嵌入层参数提升泛化能力

c）强化学习相关损失

策略梯度目标函数

• ​ChatGPT的PPO损失：

  • 包含策略损失Lclip​、价值函数损失Lvf​和熵奖励Lentropy​

  • $L^{PPO}=E_t[min(r_t(\theta ){\hat{A}}_t,clip(r_t(\theta ),1-\epsilon ,1+\epsilon ){\hat{A}}_t)]$

• ​DeepSeek的GRPO损失：

  • 群组相对策略优化（Group Relative Policy Optimization）：

    $L_{GRPO}=E_{(x,y_w,y_l)\sim D}[log\sigma (\beta (log\frac{\pi \theta (y_w\mid x)}{{\pi }_{ref}(y_w\mid x)}-log\frac{\pi \theta (y_l\mid x)}{{\pi }_{ref}(y_l\mid x)}))]$

  • 相比PPO减少40%显存占用，训练速度提升2.3倍

奖励建模损失

• ​Qwen的混合奖励损失：

  • 结合规则验证器奖励Rrule​和RM模型奖励Rθ​：
    $R_{total}=0.5R_{rule}+0.5R_{\theta }$​

  • 使用列表式排序损失（Listwise Ranking Loss）训练奖励模型

d）特殊场景优化损失

长文本记忆损失：

• ​DeepSeek记忆增强机制：

  • 在Transformer层间插入可读写记忆单元，计算记忆一致性损失：
    $L_{mem}={\sum }_{i=1}^N\Vert h_i^{cache}-h_i^{current}{\Vert }^2$

  • 结合FAISS向量检索构建知识关联损失

数学推理专项损失

• ​Qwen2.5-Math的渐进式损失：
  • 分阶段应用符号推理损失（Symbolic Loss）和数值验证损失（Numerical Check Loss）
  • 在强化学习阶段引入步骤级奖励模型（Step-wise Reward Shaping）

---

6）长时记忆处理

参考HippoRAG 2 | 增强LLM的长期记忆能力

关键技术：

• ​滑动窗口​：固定长度上下文缓存（如GPT-4的8k窗口）

• ​检索增强（RAG）：结合向量数据库（如HippoRAG的图谱关联）

• ​持续学习​：参数微调 + 外部记忆库

技术演进：

• 传统滑动窗口（如ALiBi）在32k长度下准确率下降23%，而Qwen的NTK感知插值无需训练即可扩展到100k上下文。HippoRAG 2通过知识图谱关联使多跳问答准确率提升37%；

三、LLM常用应用框架 - 搭建AI Agent

1、关于AI Agent的定义：核心功能包括规划、记忆和调用工具，不同应用框架对Agent的不同实现

参考 【多Agent】MetaGPT学习教程

Agent（智能体） = 一个设置了一些目标或任务，可以迭代运行的大型语言模型。这与大型语言模型（LLM）在像ChatGPT这样的工具中“通常”的使用方式不同。在ChatGPT中，你提出一个问题并获得一个答案作为回应。而Agent拥有复杂的工作流程，模型本质上可以自我对话，而无需人类驱动每一部分的交互。

Logan Kilpatrick，OpenAI 开发者关系负责人

ChatGPT接收单一查询的输入并返回输出，它一次不能完成超过一个任务。而AI Agent则可以自驱的定义工作流程并规划任务进行解决。比如，如果你有一个天气插件，当用户问“NYC（纽约缩写）的温度是多少？”，模型就会知道它无法回答这个问题，并查看用户安装的可用插件。假设它发送请求，API返回了一个错误信息，说“NYC不是一个有效的地点，请使用详细的城市名称，不要使用缩写”，模型实际上可以读取这个错误并发送新的请求来修复它。在这次人工智能的浪潮中AI Agent的火花诞生于 GPT插件商城以及AutoGPT。这分别提到Agent的工具调用能力和规划能力，在 LLM 支持的自主Agent系统中，LLM 充当Agents的大脑，并辅以几个关键组成部分：

• 规划

  • 子目标和分解：Agents将大型任务分解为更小的、可管理的子目标，从而能够有效处理复杂的任务。

  • 反思和完善：Agents可以对过去的行为进行自我批评和自我反思，从错误中吸取教训，并针对未来的步骤进行完善，从而提高最终结果的质量。

• 记忆

  • 短期记忆：我认为所有的上下文学习（参见提示工程）都是利用模型的短期记忆来学习。

  • 长期记忆：这为Agents提供了长时间保留和回忆（无限）信息的能力，通常是通过利用外部向量存储和快速检索来实现。

• 工具使用

  • Agents学习调用外部 API 来获取模型权重中缺失的额外信息（通常在预训练后很难更改），包括当前信息、代码执行能力、对专有信息源的访问等。

2、LLM框架：推理框架 & 应用框架

1）基础推理框架 - 处理推理速度问题

框架名称	核心流程	技术特性	适用场景	来源
​Xinference	1. 多模型加载 → 2. OpenAI兼容接口封装 → 3. 分布式服务部署 → 4. 动态扩缩容管理	支持DeepSeek等30+模型，混合精度推理加速	企业级多模型服务平台	大型语言模型（LLM）推理框架的全面分析与选型指南（2025年版）
​LiteLLM	1. 统一API适配 → 2. 多提供商模型调度 → 3. 缓存/限流机制 → 4. 响应标准化输出	跨平台模型无缝切换，响应延迟<500ms	多模型对比评测场景	新手必看！5大LLM框架选型指南（附对比表）
​LMDeploy	1. 模型量化 → 2. 显存优化 → 3. 连续批处理 → 4. 动态张量并行	GPU利用率>85%，吞吐量达5000 tokens/s	实时对话系统	大型语言模型（LLM）推理框架的全面分析与选型指南（2025年版）
​vLLM	1. PagedAttention → 2. 内存分页管理 → 3. 异步推理 → 4. 服务监控	支持100K+上下文窗口

2）应用开发框架 - 处理LLM幻觉问题

框架名称	核心流程	关键技术	典型应用	来源
​Dify	1. 拖拽式工作流 → 2. 多模型编排 → 3. API服务生成 → 4. 效果实时调试	内置200+预置模板，支持AutoML优化	智能客服/内容生成	2 5
​RagFlow	1. 文档切片 → 2. 多模态解析 → 3. 溯源索引构建 → 4. 反幻觉校验	表格识别准确率>92%，支持影印件解析	合同审查/论文研究	2 5
​LangChain	1. Model I/O → 2. 数据连接 → 3. 记忆管理 → 4. 链式执行 → 5. 代理调度	支持知识图谱融合推理	复杂业务流程自动化	4 6
​圭图AI	1. Java业务层 → 2. Python模型层 → 3. 混合编排 → 4. 服务治理	支持ElasticSearch/Redis多级缓存	企业级RAG系统	5
​E-LADF	1. 知识库向量化 → 2. 流式对话管理 → 3. 长文本摘要 → 4. 实体关系抽取	支持联邦学习架构

参考 大型语言模型（LLM）推理框架的全面分析与选型指南（2025年版）

3）主流推理 / 应用框架总体概览

以下是2025年主流的LLM推理框架，我们根据其核心优势进行了分类，并特别强调了DeepSeek AI开源基础设施索引在提升框架性能方面的作用：

高性能推理框架：

• vLLM：

  GPU优化典范，采用创新的PagedAttention技术，实现卓越的吞吐量和GPU内存效率，适用于大规模高并发部署场景。

• LMDeploy：

  极致GPU性能的代名词，提供超低延迟和高吞吐量，完美契合企业级实时应用的需求。

• TGI (Text Generation Inference)：

  企业级文本生成服务，专为生产环境的稳定性和高吞吐量而生，是构建可靠LLM服务的基石。

• SGLang：

  高性能推理runtime的典范，深度优化语言生成流程，内建强大的分布式部署能力，可轻松应对最复杂的应用场景。

• DeepSeek AI Open Infra Index (底层优化支持)：

  DeepSeek AI 开源的基础设施索引，包含 FlashMLA、DeepEP 等工具，能与 SGLang、vLLM 等推理框架协同工作，从底层大幅提升推理性能和效率。

本地部署与轻量化框架：

• Ollama：

  极简本地部署方案，一键加载模型，集成用户友好的Web界面，是个人用户进行快速原型验证和本地实验的最佳选择。

• Llama.cpp：

  CPU优化设计的专家，以轻量级著称，资源占用极低，完美适用于边缘设备和资源受限的特殊环境。

• LocalAI：

  本地运行的理想之选，将数据隐私和安全性置于首位，尤其适合对数据敏感度有极高要求的应用场景。

• KTransformers：

  CPU优化框架中的能效先锋，专注于在资源极其有限的环境中实现低功耗和高效率的平衡。

• GPT4ALL：

  配备图形用户界面 (GUI) 工具，操作极其简易直观，最大程度降低了LLM的使用门槛，是初学者快速入门的理想框架。

灵活部署与多模型支持框架：

• XInference：

  开源框架的佼佼者，提供与 OpenAI API 兼容的接口，具备高度的部署灵活性，并原生支持多种模型，能够灵活应对快速变化的应用需求。

• OpenLLM：

  开源社区的灵活之选，不仅开源，更具备高度的灵活性和可定制性，广泛支持各种模型架构和混合部署模式，特别适合需要深度定制化LLM部署的场景。

• Hugging Face Transformers：

  生态系统最为完善，模型资源极其丰富，社区支持强大，广泛应用于学术研究和快速原型开发，部署方式也异常灵活。

• LiteLLM：

  轻量级适配层的代表，提供统一的API接口，能够无缝支持多种LLM，极大地简化了多模型集成和管理的复杂性。

开发者友好型框架：

• FastGPT：

  集成多种工具的开发框架，为快速构建和部署基于LLM的应用提供了极大便利，尤其适合应用开发者和快速原型设计

• Dify：

  集成多种工具的开发框架，为快速构建和部署基于LLM的应用提供了极大便利，尤其适合应用开发者和快速原型设计。

• Coze(扣子)：

  扣子是新一代 AI 应用开发平台。无论你是否有编程基础，都可以在扣子上快速搭建基于大模型的各类 AI 应用，并将 AI 应用发布到各个社交平台、通讯软件，也可以通过 API 或 SDK 将 AI 应用集成到你的业务系统中。

框架对比表格

框架	性能	易用性	灵活性	社区支持	主要优势	适用场景
XInference	高	高	高	中等	灵活性、多模型支持、OpenAI兼容API	模型服务管理、灵活部署，快速发展的团队
LiteLLM	依赖模型提供商	高	高	高	多模型API集成、统一接口、轻量化	多模型测试与集成、快速开发、高可用性生产环境
LMDeploy	高	中等	中等	中等	GPU高性能、高吞吐量、企业级特性	企业级应用、实时对话系统、极致性能需求
SGLang	高	高	高	中等	高层次API、分布式优化、高性能runtime、backend灵活	快速原型开发、分布式高吞吐量推理、复杂生成任务
vLLM	高	中等	中等	高	内存高效、高吞吐量、PagedAttention技术	大型模型推理、高并发场景、企业级大规模应用
Ollama	中低	高	低	中等	本地轻量化、极简易用、内置Web界面	本地实验、个人项目、LLM快速体验
Llama.cpp	中低	高	中等	中等	CPU优化、低资源占用、轻量级	边缘设备、资源受限环境、CPU推理场景
TGI	高	低	中等	中等	企业级服务、高吞吐量、生产环境优化	生产环境、企业级大规模应用、文本生成服务
KTransformers	中低	中等	低	低	CPU优化、低功耗、轻量级	低功耗设备、CPU环境、资源极其有限的场景
GPT4ALL	低	高	低	低	GUI界面、极简操作、跨平台	LLM初学者、非技术用户、本地快速体验
OpenLLM	中等	中等	高	中等	开源、灵活部署、多模型架构支持	定制化部署、开源爱好者、需要深度模型定制的场景
LocalAI	中低	中等	低	低	本地部署、隐私保护、数据安全	数据敏感应用、本地私有化部署
Hugging Face Transformers	中等	高	高	非常高	生态完善、模型极其丰富、社区支持强大	研究、原型开发、各种NLP任务、需要广泛模型选择的场景
DeepSeek Open Infra Index	极高 (底层优化)	低 (内核开发)	低 (工具库)	低	底层推理优化、FP8支持、分布式加速	高性能推理内核开发、分布式MoE模型部署、极致性能优化场景

3、LangChain：Agent = LLM + 记忆 + 工具（LangChain适合于代码开发者、FastGPT和Dify是零代码平台，适合于业务开发者）

1）核心模块和协作模式

参考极简LangChain智能体开发入门指南，LangChain官方文档

LangChain核心模块与功能：

核心模块	功能描述	关键技术点
​模型I/O	管理大模型输入输出，包含提示模板、模型调用接口、输出解析器	支持动态变量注入的提示模板（如PromptTemplate） ；输出结构化解析（如JSON/Pydantic）
​数据连接	实现外部数据加载、向量化存储与检索	文档分块（TextSplitters）、向量存储（Faiss/Pinecone） ；支持PDF/网页等多种数据源
​链（Chains）​	串联多个处理步骤形成端到端任务流	简单链（LLMChain）、复杂链（SequentialChain/RouterChain） ；支持异步/流式处理
​记忆（Memory）​	维护对话历史或任务上下文	短期记忆（ConversationBufferMemory）、长期记忆（RedisMemory） ；支持状态持久化
​代理（Agents）​	动态调用外部工具（API/数据库）	ReAct代理实现推理-行动循环 ；工具集成（如天气API/搜索工具）
​回调（Callbacks）​	监控任务执行过程，处理日志/异常	支持日志记录、性能分析及自定义事件触发

模块协作模式（以典型场景为例）：

应用场景	模块协作流程	技术实现
​RAG系统	数据连接加载文档→分块→向量化存储 → 链模块组合检索与生成 → 代理补充实时数据 → 记忆保存历史	使用RetrievalQAChain组合检索器与LLM；代理调用知识库工具
​智能客服	代理调用知识库工具 → 记忆模块维护多轮对话 → 输出解析器提取结构化数据	ConversationChain管理对话流；OutputParser生成工单
​自动化测试	代理生成测试用例 → 调用Selenium执行 → 回调模块记录结果	自定义工具集成Selenium；回调函数记录执行日志

2）开发模板和注意事项

开发注意事项：

开发步骤	关键操作	注意事项
​1. 环境配置	安装核心包（langchain-core）、模型接口包（如langchain-openai）	使用虚拟环境隔离依赖；通过环境变量管理API密钥防止泄露
​2. 组件选择	选择LLM（速度/质量权衡）、记忆策略（短期/长期存储）、工具（API/数据库）	优先官方集成工具（如langchain-community）；评估模型Token限制
​3. 链/代理设计	简单任务用LLMChain，多步骤任务用SequentialChain；动态决策场景用代理	使用LCEL优化异步处理；通过langsmith调试执行路径
​4. 测试部署	单元测试验证输出结构；集成测试模拟用户交互 → 使用langserve发布为API	压力测试高并发场景；监控API响应延迟与错误率
​5. 性能调优	启用模型缓存减少延迟；优化分块策略（重叠窗口/语义分割）；索引分片提升检索效率	避免长文本超出模型上下文限制；使用ConversationSummaryMemory压缩历史

典型案例参考：

案例类型	实现方案	技术组合
​文档问答系统	UnstructuredPDFLoader加载文档 → RecursiveCharacterTextSplitter分块 → RetrievalQAChain生成答案	向量存储选用ChromaDB；输出解析器转Markdown
​多语言翻译器	RouterChain识别语言 → 调用对应翻译链 → ConversationBufferMemory保存偏好	使用PromptTemplate定制语言风格；代理调用Google翻译API

a）模型 I/O 开发模板：管理大模型输入输出，包含提示模板、模型调用接口、输出解析器

FastGPT和Dify的模型配置如下（LLM、embedding模型、reRank模型）：

关于模型加载模板、硅基流动LLM加载，具体参考【LLM相关知识点】关于LangChain框架学习简单整理（三）- 模型加载模板、硅基流动LLM加载

b）数据连接 开发模板：实现外部数据加载、分块策略、向量化存储与检索

向量持久化数据库包括：Chroma 向量数据库、Milvus向量库、Weaviate向量库

检索策略包括：向量检索（语义检索），全文检索、混合检索（包括ReRank、标签检索等，可以参考FastGPT和Dify平台）

FastGPT和Dify的检索模式如下：

关于LangChain的简单流，复杂流，可参考【LLM相关知识点】关于LangChain框架学习简单整理（三）- 文档分块、向量化入库、检索与召回

c）链（Chains）开发模板：串联多个处理步骤形成端到端任务流

可以参考FastGPT、Dify的工作流拉取

关于LangChain的简单流，复杂流，可参考【LLM相关知识点】关于LangChain框架学习简单整理（三）- 简单流，复杂流

d）记忆（Memory）开发模板：维护对话历史或任务上下文

关于LangChain的简单流、复杂流，可参考

e）代理（Agents）开发模板：动态调用外部工具（API/数据库）

Dify的ReAct框架如下：

关于LangChain的工具调用和ReAct框架，可参考【LLM相关知识点】关于LangChain框架学习简单整理（三）- 工具调用和ReAct框架

f）回调（Callbacks）开发模板：监控任务执行过程，处理日志/异常

4、MetaGPT：Agent = LLM + 观察 + 思考 + 行动 + 记忆

1）MetaGPT中关于Agent的概述：单智能体 & 多智能体

参考 【多Agent】MetaGPT学习教程

在MetaGPT中看来，我们把Agent想象成环境中的数字人，其中

Agent = 大语言模型（LLM） + 观察 + 思考 + 行动 + 记忆

这个公式概括了智能体的功能本质。为了理解每个组成部分，让我们将其与人类进行类比：

1. 大语言模型（LLM）：LLM作为智能体的“大脑”部分，使其能够处理信息，从交互中学习，做出决策并执行行动。

2. 观察：这是智能体的感知机制，使其能够感知其环境。智能体可能会接收来自另一个智能体的文本消息、来自监视摄像头的视觉数据或来自客户服务录音的音频等一系列信号。这些观察构成了所有后续行动的基础。

3. 思考：思考过程涉及分析观察结果和记忆内容并考虑可能的行动。这是智能体内部的决策过程，其可能由LLM进行驱动。

4. 行动：这些是智能体对其思考和观察的显式响应。行动可以是利用 LLM 生成代码，或是手动预定义的操作，如阅读本地文件。此外，智能体还可以执行使用工具的操作，包括在互联网上搜索天气，使用计算器进行数学计算等。

5. 记忆：智能体的记忆存储过去的经验。这对学习至关重要，因为它允许智能体参考先前的结果并据此调整未来的行动。

在MetaGPT中定义的一个agent运行示例如下：

• 一个agent在启动后他会观察自己能获取到的信息，加入自己的记忆中

• 下一步进行思考，决定下一步的行动，也就是从Action1，Action2，Action3中选择执行的Action

• 决定行动后，紧接着就执行对应行动，得到这个环节的结果

a）而在MetaGPT内 Role类是智能体的逻辑抽象：

一个 Role 能执行特定的 Action，拥有记忆、思考并采用各种策略行动。基本上，它充当一个将所有这些组件联系在一起的凝聚实体。目前，让我们只关注一个执行动作的智能体，并看看如何实现一个最简单的 Agent

b）MetaGPT关于多智能体的环境：Environment：

Environment这个概念，我们更多熟识于强化学习领域的 agent 与 Environment，在强化学习中 Agent 需要学习在环境中采取行动来最大化一些累积奖励，Agent 能够采取的行动，也就是 Agent 的 action space 往往受到环境的限制，环境中通常具有一定的规则，而agent 们必须按照规则进行活动，MetaGPT提供了一个标准的环境组件Environment，来管理agent的活动与信息交流

MetaGPT源码中是这样介绍 Environment 的：

环境，承载一批角色，角色可以向环境发布消息，可以被其他角色观察到

Environment, hosting a batch of roles, roles can publish messages to the environment, and can be observed by other roles

在多智能体环境运行中，Role的每次行动将从Environment中先_observe Message，在 obseve 的行动中 Role 将从从消息缓冲区和其他源准备新消息以进行处理，当未接受到指令时，Role将等待对于信息缓冲区中的信息

5、LLM应用框架对比：langChain & AutoGPT & MetaGPT

简单实现

学习资料

• awesome-langchain

• GitHub - EmbraceAGI/awesome-chatgpt-zh: ChatGPT 中文指南🔥，ChatGPT 中文调教指南，指令指南，应用开发指南，精选资源清单，更好的使用 chatGPT 让你的生产力 up up up! 🚀

参考资料

• 为什么都放弃了LangChain？

四、AI Agent搭建时常用技术方案：AI Agent自动化 & JSON Schema

参考 NL2SQL技术方案系列(1)：NL2API、NL2SQL技术路径选择；LLM选型与Prompt工程技巧，揭秘项目落地优化之道

1、AI Agent自动化的常见技术方案：Text2API & Text2SQL & Text2Code & MCP（底层都是对FunctionCalling的优化）

1）常见业务场景与实现流程

技术	​典型业务场景	​实现流程
​Text2SQL	​企业数据分析 用户输入“统计2023年Q3各区域销售额TOP3产品”生成动态报表。	1. 自然语言解析（提取时间、维度、指标） 2. Schema匹配（关联region、product表） 3. 生成SQL（含JOIN、GROUP BY、RANK()） 4. 执行查询并返回可视化结果
​Text2API	​物流状态查询 用户输入“查订单ID-12345的物流轨迹”调用第三方物流API。	1. 意图识别（物流查询） 2. 参数提取（订单ID） 3. 调用物流API（构造GET /tracking?id=12345） 4. 解析API响应并生成自然语言描述
​Text2Code	​本地数据处理 用户输入“读取data.csv，过滤缺失值并保存为JSON”生成Python脚本。	1. 需求解析（文件操作、数据清洗） 2. 生成Pandas代码（pd.read_csv()→dropna()→to_json()） 3. 执行脚本或导出文件
​MCP	​跨系统协作 用户输入“将数据库异常记录到Jira并通知团队”，需协调Text2SQL和Text2API。	1. 任务分解（异常查询→工单创建→通知发送） 2. MCP调用Text2SQL生成查询语句 3. MCP调用Jira API创建工单 4. MCP调用企业微信API发送通知

2）典型应用场景与案例对比

​技术	​场景特点	​典型案例	​瓶颈与挑战	​优势
​Text2API	1. 系统成熟度高（已有稳定API服务） 2. 需求明确性高（功能边界清晰）	1. 客户订单状态查询（调用物流API返回轨迹） 2. 风险控制（触发风控API返回评分）	API文档更新滞后导致参数错误（如字段变更未同步）	-
​Text2SQL	1. 数据敏感性高（需安全查询） 2. 查询复杂度高（多表关联、聚合计算）	1. 动态报表生成（生成含JOIN的复杂SQL） 2. 实时监控（过滤错误日志的查询）	需平衡数据安全与灵活性（如脱敏视图限制查询能力） 优化：通过RAG注入业务术语表	-
​Text2Code	1. 探索性需求（快速验证原型） 2. 本地化处理（隐私敏感场景）	1. 数据预处理（生成Pandas代码清洗数据） 2. 自动化脚本（生成备份脚本）	生成的代码存在安全风险（如路径注入漏洞） 执行效率较低（复杂任务需多次调试）	-
​MCP	1. 系统异构性（整合多平台工具） 2. 动态扩展需求（工具频繁增减）	1. 跨系统协作（数据库异常→Jira工单+通知） 2. 智能体生态（无缝切换数据库）	协议适配成本较高（需开发/配置MCP服务器） 高并发场景下性能瓶颈（JSON-RPC延迟）	1. 降低多工具维护成本 2. 支持动态资源发现与跨平台调用 3. 协议层统一兼容性高

3）技术能力对比

​维度	Text2SQL	Text2API	Text2Code	MCP
​核心能力	数据库查询自动化	跨系统服务调用	脚本生成与执行	多工具协议协同
​输入约束	依赖Schema知识库	需维护API文档库	需代码模板库	需MCP服务器生态
​失败处理	SQL执行错误重试	API限流熔断	代码静态分析修正	分布式事务回滚
​典型工具	RAGFlow、DBCopilot	Postman Flows、LangChain	GitHub Copilot、Codeium	ModelContext Protocol

4）关键技术和Schema对比

​技术	​JSON Schema必要性	​典型案例	​最佳实践
​MCP	​工具接口标准化：通过JSON Schema描述工具参数/返回值格式（如定义天气查询的经纬度参数类型）。 动态资源发现：客户端通过tools/list接口获取工具输入模式（JSON Schema）。	GitHub仓库查询场景中，定义search_repositories工具的输入参数（关键词、排序规则）。	1. 使用required和enum约束高风险参数（如金额字段限制最小值）。 2. 简单工具可仅声明name和description。
​Text2SQL	​结构化元数据输入：通过类JSON Schema的DDL知识库提供表结构（字段名、外键关系）。 Q->SQL映射：用结构化格式标准化业务术语（如“销售额”=order_amount - refund）。	RAGFlow通过DDL知识库传递表结构信息，生成含JOIN和WHERE的SQL。	1. 将元数据封装为标准化JSON结构。 2. 通过RAG注入业务知识库提升准确率。
​Text2API	​API接口规范定义：通过JSON Schema限定参数类型（如amount为数值且minimum:0.01）。 响应解析：预定义响应格式Schema指导结果处理。	企业微信消息推送API中，限制content字段长度和userid格式。	1. 复杂API强制使用JSON Schema校验。 2. 标准化API（如RESTful）可自动转换Swagger为Schema。

Schema类型对比：

维度	​MCP	​Text2SQL	​Text2API
​Schema类型	工具接口JSON Schema	类DDL结构化元数据	OpenAPI/JSON Schema
​核心输入目的	确保工具调用参数合规性	指导SQL语法生成与表关联逻辑	规范API请求格式与响应解析
​典型工具	MCP服务器元数据注册模块	RAGFlow的DDL知识库	Swagger-to-JSON Schema转换工具
​灵活性	高（支持动态资源发现）	中（依赖数据库Schema）	低（受限于API文档）

5）各技术关于开发成本、执行效率、灵活性和适用阶段的多维度分析：

​维度	​Text2API	​Text2SQL	​Text2Code	​MCP（补充分析）​
​开发成本	高（需维护API层）	中（依赖RAG/微调）	低（通用代码生成）	中高（需协议适配）
​执行效率	高	高	低	高（协议层优化）
​灵活性	低（受限于API功能）	中（受限于数据库结构）	高（代码可任意扩展）	高（跨工具组合）
​适用阶段	成熟系统功能扩展	企业核心数据分析	探索性分析或本地数据处理	企业级多系统整合

总结

• ​Text2SQL/Text2API：聚焦垂直场景（数据查询/服务调用），需强依赖领域知识库（Schema/API文档）。
• ​Text2Code：灵活性高但需平衡安全与效率，适合轻量级自动化。
• ​MCP：作为基础设施，通过协议层整合前三者，实现复杂业务流的自然语言驱动。
• ​协同价值：MCP可串联Text2SQL（查数据）→ Text2Code（处理数据）→ Text2API（推送结果），形成端到端自动化闭环。

2、API层的自动化 - Text2API推送数据：自然语言 -> LLM解析成API指令并执行 -> 推送结果

参考 NL2SQL技术方案系列(1)：NL2API、NL2SQL技术路径选择；LLM选型与Prompt工程技巧，揭秘项目落地优化之道

1）研究现状：

参考 LiteLLM：解锁大型语言模型 API 调用的新利器，开发者必备

a）基本实现流程：自然语言 -> API Schema -> LLM解析成API指令并执行 -> 推送结果

关于Text2API的技术总流程如下（这里的API可以是前后端的路由）：

• Step1：定义数据分析API接口，并整理API库（API中文描述和API Schema）

• Step2：用户输入自然语言

• Step3：根据用户问题，语义检索相应API接口，返回API Schema

• Step4：LLM通过API Schema解析生成API调用指令（填充参数）

• Step5：执行API并得到响应结果

• Step6：结合原始数据和Prompt，二次封装响应结果（生成分析报告等）

以下是针对该流程图的详细分步说明，结合技术实现逻辑与业务场景需求：

Step1: 定义数据分析API接口

• ​核心任务
  根据业务需求设计标准化API，包含：

  • ​功能范围：明确每个API的数据查询范围（如get_sales_data用于销售统计）
  • ​参数规范：定义参数类型（如时间范围time_range: [daily, weekly]）与校验规则
  • ​返回格式：约定JSON/CSV等结构化数据格式（如{ "total": 1000, "details": [...] }）
  • ​安全策略：设置身份认证（OAuth 2.0）、速率限制（Rate Limit）

• ​产出物
  生成API的JSON Schema描述文件，例如：

  {
    "name": "get_user_stats",
    "description": "获取用户活跃度数据",
    "parameters": {
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"},
      "region": {"type": "string", "enum": ["north", "south"]}
    }
  }
  

Step 2: 用户输入自然语言问题

• ​场景示例
  用户提问：“显示华东地区最近一个月的用户注册趋势”
• ​输入预处理
  对文本进行清洗（如去除特殊字符）、意图分类（判断是否需要调用API）。

---

Step 3: LLM解析与工具选择

• ​技术实现
  使用大模型的Function Calling能力（如GPT-4/Gemini），将用户问题映射到预定义的API工具：

  1. 将API的JSON Schema作为提示词的一部分输入模型

  2. 模型输出结构化调用指令，例如：

     {
     "api_call": {
     "name": "get_user_stats",
     "parameters": {"region": "east", "start_date": "2024-05-01", "end_date": "2024-05-31"}
     }
     }
     

• ​异常分支
  若问题超出API覆盖范围（如“分析竞品市场策略”），模型直接生成文本响应（“暂不支持此类型分析”）。

---

Step 4: 提取API名称及参数

• ​参数校验
  对模型输出的参数进行格式检查：
  • 日期格式是否符合YYYY-MM-DD
  • 区域参数是否在枚举值范围内
• ​逻辑增强
  若参数缺失（如用户未明确时间范围），自动填充默认值（如start_date=当前日期-30天）。

---

Step 5: 调用指定API接口

• ​执行流程
  1. 构造HTTP请求（如GET /api/user_stats?region=east&start_date=2024-05-01）
  2. 添加请求头（如Authorization: Bearer <token>）
  3. 设置超时时间（如10秒）与重试策略
• ​性能优化 对高频API启用缓存机制（Redis），缓存键基于参数哈希值。

---

Step 6: API返回数据状态判断

• ​成功响应
  数据示例：

  {
    "total_users": 1500,
    "daily_registrations": [{"date": "2024-05-01", "count": 50}, ...]
  }
  

• ​失败处理
  错误类型与应对策略：

  错误类型	处理方式
  401未授权	刷新Token后重试（最多3次）
  400参数错误	调用LLM重新生成参数
  500服务端错误	触发告警并终止流程

---

Step 7: 原始数据附加到Prompt

• ​Prompt工程
  将API返回数据与用户问题合并，构造新的提示词：

  用户问题：显示华东地区最近一个月的用户注册趋势  
  数据：{"total_users":1500, "daily_registrations":[{"date":"2024-05-01","count":50},...]}  
  请生成包含趋势分析和关键指标的自然语言报告  
  

• ​数据脱敏
  若返回结果包含敏感字段（如手机号），自动进行掩码处理（如138****5678）。

---

Step 8: 二次加工决策

• ​判断逻辑
  • ​需要加工：当用户需求包含分析、总结、可视化时（如“分析趋势”“生成图表”）
  • ​直接返回：当用户明确要求原始数据（如“导出为Excel”）

---

Step 9: LLM生成结构化报告

• ​输出示例

  华东地区5月新增用户1500人，日均注册量约50人。  
  峰值出现在5月20日（单日注册120人），建议加大该时段促销力度。  
  

• ​增强能力
  通过Few-shot Learning示例，引导模型生成带Markdown表格或折线图代码的响应。

---

Step 10: 最终用户响应

• ​多模态输出
  根据渠道类型适配响应形式：

  渠道	响应形式
  网页	HTML图文报告
  移动端	卡片式消息（JSON）
  API	原始数据+分析文本

---

错误处理与重试机制

• ​重试策略
  采用指数退避算法（Exponential Backoff）：
  • 第1次重试：1秒后
  • 第2次重试：4秒后
  • 第3次重试：9秒后
• ​熔断机制
  若连续5次调用失败，暂停该API调用1分钟，防止雪崩效应。

---

流程优势总结

1. ​灵活性与可控性平衡：通过API层约束模型输出范围，降低幻觉风险
2. ​端到端自动化：从自然语言到最终报告无需人工干预
3. ​弹性架构：重试与熔断机制保障系统稳定性
4. ​业务可扩展：新增API只需更新JSON Schema，无需修改核心逻辑

该方案已在金融、电商领域落地，某零售企业接入后，人工编写SQL的需求下降70%，平均查询响应时间从15分钟缩短至20秒。

具体流程如下：

b）存在难点：接口发现和编排，API版本升级导致执行失效等

​挑战维度	​问题描述	​典型案例	​技术难点
​接口多样性适配	API请求方式（REST/GraphQL）、认证机制（OAuth/API Key）差异显著。	调用链：用户画像API→邮件模板API→邮件发送API，需处理参数格式转换。	接口发现与编排（维护OpenAPI库）、参数类型转换（如user_id→recipient_id）。
​意图到API映射	用户需求隐含多个API组合调用，需拆解意图并匹配接口。	输入“分析竞品投放效果”，需调用抖音、快手API及数据聚合接口。	长尾意图覆盖（设计兜底策略）、上下文感知（默认参数推断，如时间范围）。
​API文档同步	API版本升级导致模型生成过时请求。	参数start_time更名为begin_time，未同步文档时生成错误调用。	文档实时更新（集成CI/CD）、错误响应重试（分类400 Bad Request错误类型）。
​调用稳定性保障	高并发场景下需避免API速率限制，保障系统可用性。	促销活动期间高频调用库存API，触发Rate Limit导致服务降级。	流量控制（熔断机制）、缓存一致性（只读API缓存与实时性平衡）。

2）常用框架：LangChain

3、SQL层的自动化 - Text2SQL查数据：自然语言 -> SQL Schema -> LLM -> SQL -> 查数据

参考 DB-GPT，Quickstart With Sample Data - Vanna.AI Documentation

参考 Text2SQL现状与应用的小调研，Text2SQL新突破: 从M-Schema到多生成器的NL2SQL框架

1）研究现状：

a）关于Text2SQL的公开数据集、指标说明：WikiSQL & Spider & BIRD

参考 GitHub - eosphoros-ai/Awesome-Text2SQL: Curated tutorials and resources for Large Language Models, Text2SQL, Text2DSL、Text2API、Text2Vis and more.

① 关于Text2SQL的公开数据集的打榜情况：

	WikiSQL	Spider Exact Match(EM)	Spider Exact Execution(EX)	BIRD Reward-based Valid Efficiency Score (R-VES)	BIRD Execution Accuracy (EX)
🏆1	93.0 (2021/05-SeaD+Execution-Guided Decoding)	81.5 (2023/11-MiniSeek)	91.2 (2023/11-MiniSeek)	69.36 (2024/08-OpenSearch-SQL, v2 + GPT-4o)	73.00 (2024/09-CHASE-SQL + Gemini)
🥈2	92.7 (2021/03-SDSQL+Execution-Guided Decoding)	74.0 (2022/09-Graphix-3B + PICARD)	86.6 (2023/08-DAIL-SQL + GPT-4 + Self-Consistency)	68.79 (2024/08-ExSL + granite-34b-code)	72.39 (2024/09-AskData + GPT-4o)
🥉3	92.5 (2020/11-IE-SQL+Execution-Guided Decoding)	73.9 (2022/09-CatSQL + GraPPa)	86.2 (2023/08-DAIL-SQL + GPT-4)	68.44 (2024/09-CHASE-SQL + Gemini)	72.28 (2024/08-OpenSearch-SQL, v2 + GPT-4o)
4	92.2 (2020/03-HydraNet+Execution-Guided Decoding)	73.1 (2022/09-SHiP + PICARD)	85.6 (2023/10-DPG-SQL + GPT-4 + Self-Correction)	67.41 (2024/07-Distillery + GPT-4o)	71.83 (2024/07-Distillery + GPT-4o)
5	91.9 (2020/12-BRIDGE+Execution-Guided Decoding)	72.9 (2022/05-G³R + LGESQL + ELECTRA)	85.3 (2023/04-DIN-SQL + GPT-4)	66.92 (2024/09-AskData + GPT-4o)	70.37 (2024/08-ExSL + granite-34b-code)
6	91.8 (2019/08-X-SQL+Execution-Guided Decoding)	72.4 (2022/08-RESDSQL+T5-1.1-lm100k-xl)	83.9 (2023/07-Hindsight Chain of Thought with GPT-4)	66.39 (2024/08-Insights AI)	70.26 (2024/08-Insights AI)
7	91.4 (2021/03-SDSQL)	72.4 (2022/05-T5-SR)	82.3 (2023/06-C3 + ChatGPT + Zero-Shot)	66.25 (2024/05-ExSL + granite-20b-code)	70.21 (2024/07-PURPLE + RED + GPT-4o）
8	91.1 (2020/12-BRIDGE)	72.2 (2022/12-N-best List Rerankers + PICARD)	80.8 (2023/07-Hindsight Chain of Thought with GPT-4 and Instructions)	65.70 (2024/07-RECAP + Gemini)	69.03 (2024/07-RECAP + Gemini)
9	91.0 (2021/04-Text2SQLGen + EG)	72.1 (2021/09-S²SQL + ELECTRA )	79.9 (2023/02-RESDSQL-3B + NatSQ)	65.62 (2024/07-PURPLE + RED + GPT-4o）	68.87 (2024/07-ByteBrain)
10	90.5 (2020/11-SeqGenSQL+EG)	72.0 (2023/02-RESDSQL-3B + NatSQL)	78.5 (2022/11-SeaD + PQL)	63.68 (2024/08-Arcwise + GPT-4o）	67.86 (2024/05-ExSL + granite-20b-code)

② 关于NL2SQL的打榜数据集与指标对比表：

数据集名称	提出时间	核心特点	评价指标	指标定义	适用场景	数据规模
​WikiSQL	2017年（Salesforce）	单表、单轮查询，SQL结构简单（仅SELECT和WHERE子句）	逻辑形式准确率（AccLF） 执行准确率（AccEX）	- AccLF：生成SQL与标注完全一致的比例 - AccEX：执行结果与标注结果一致的比例	基础SQL生成研究，适用于简单查询场景	24,241张表 80,645条自然语言-SQL对
​Spider	2018年（耶鲁大学）	多表、跨领域、复杂SQL（含JOIN、GROUP BY等）	Exact Match (EM) Execution Accuracy (EX)	- EM：预测SQL与标注SQL完全匹配 - EX：执行结果与标注结果一致	复杂数据库交互研究，需处理多表关联与嵌套查询	200个数据库 10,181条问题 5,693条SQL
​BIRD	2023年（香港大学&阿里巴巴）	跨领域、大规模数据（33.4GB）、实际应用导向	Reward-based Valid Efficiency Score (R-VES) Execution Accuracy (EX)	- R-VES：结合SQL有效性与执行效率的奖励评分 - EX：执行结果准确性	工业级复杂查询优化，需兼顾准确性与执行效率	95个数据库 12,751条问题 覆盖37个领域

Spider数据集本身并未给出SQL难度的标签，但是Spider-官方评测工具会根据SQL解析后不同类型算子的个数来定义一个SQL的难度，其主要分为四个等级easy、medium、hard、extra，简单来说SQL越长其难度就越高。下图中可以看到Spider占据了最大的区域，使其成为第一个复杂的跨域语义解析和Text-to-SQL的数据集

Spider样例说明：

-- easy
-- How many singers do we have?
SELECT count(*) FROM singer

-- medium
-- Show name, country, age for all singers ordered by age from the oldest to the youngest.
SELECT name ,country ,age FROM singer ORDER BY age DESC

-- hard
-- List all song names by singers above the average age.
SELECT song_name FROM singer WHERE age  >  (SELECT avg(age) FROM singer)

-- extra
-- Show the stadium name and capacity with most number of concerts in year 2014 or after.
SELECT T2.name, T2.capacity
FROM concert AS T1
         JOIN stadium AS T2 ON T1.stadium_id = T2.stadium_id
WHERE T1.year >= 2014
GROUP BY T2.stadium_id
ORDER BY count(*) DESC
LIMIT 1

③ 关键指标说明：

1. ​WikiSQL

   • ​逻辑形式准确率（AccLF）​：要求生成的SQL语句与标注的语法结构完全一致，适用于简单场景的严格评估。

   • ​执行准确率（AccEX）​：放宽语法匹配要求，关注最终查询结果的正确性。

   参考 Text2SQL学习整理（二） WikiSQL数据集介绍

2. ​Spider

   • ​Exact Match (EM)：

     • 精确匹配准确性，比较predict_sql与gold_sql解析后的SQL语法树的匹配性，要求比EX更严格。

     • 因 SQL复杂性较高，完全匹配的难度极大（如子句顺序差异即视为错误），当前SOTA模型的EM得分约为81.5%

   • ​Execution Accuracy (EX)：

     • 执行准确性，比较predict_sql与gold_sql执行结果集的准确性，结果集考虑了列的不同顺序，以及非order查询的行的排列顺序（不同顺序的结果能匹配也算正确）

     • 由于 SQL语义多样性 ，EX通常高于EM，SOTA得分达91.2%

   参考 Text-to-SQL学习整理（八）Spider数据集介绍导语 前面的一系列博客中，我们已经了解到Text2SQL任务的 - 掘金

3. ​BIRD

   • ​R-VES：首次引入的综合性指标，通过奖励机制平衡SQL有效性与执行时间（如避免生成低效的嵌套查询）

   • ​EX：与Spider类似，但测试数据库规模更大（单库可达数GB），更贴近真实业务场景

   参考NL2SQL基础系列(1)：业界顶尖排行榜、权威测评数据集及LLM大模型（Spider vs BIRD）全面对比优劣分析

b）基本实现流程：自然语言 + prompt -> RAG检索Schema -> LLM生成SQL并执行 -> 取数

参考 NL2SQL技术方案系列(1)：NL2API、NL2SQL技术路径选择；LLM选型与Prompt工程技巧，揭秘项目落地优化之道

Text2SQL的实现原理的核心在于如何把自然语言组装成 Prompt，并交给 LLM 转化成 SQL。基本流程如下：

OpenAI 公司在官网给出的一个标准的 chatGPT 做自然语言转 SQL 的例子：

System

/*系统指令*/
Given the following SQL tables, your job is to write queries given a user’s request.

/*数据库内表结构*/
CREATE TABLE Orders (
  OrderID int,
  CustomerID int,
  OrderDate datetime,
  OrderTime varchar(8),
  PRIMARY KEY (OrderID)
);

...此处省略其他表...

/*问题*/
Write a SQL query which computes the average total order value for all orders on 2023-04-01.

不论形式如何变化，Text2SQL的Prompt主要由几个核心部分构成。

• 指令（Instruction）：比如，“你是一个 SQL 生成专家。请参考如下的表格结构，直接输出 SQL 语句，不要多余的解释。”

• 数据结构（Table Schema）：类似于语言翻译中的 “词汇表”。即需要使用的数据库表结构，由于大模型无法直接访问数据库，你需要把数据的结构组装进入 Prompt，这通常包括表名、列名、列的类型、列的含义、主外键信息。

• 用户问题（Questions）：自然语言表达的问题，比如，“统计上个月的平均订单额”。

• 参考样例（Few-shot）：这是一个可选项，当然也是提示工程的常见技巧。即指导大模型生成本次 SQL 的参考样例。

• 其他提示（Tips）： 其他你认为有必要的指示。比如要求生成的 SQL 中不允许出现的表达式，或者要求列名必须用 “table.column" 的形式等。

关于NL2SQL的基本实现流程如下：

流程图说明：

1. ​输入预处理：对用户输入的自然语言进行清洗和标准化。
2. ​加载数据库元数据：提供表结构、字段类型等信息供 LLM 使用。
3. ​LLM 语义解析：通过 LLM 提取表名、字段名、条件和操作类型等关键信息。
4. ​SQL 模板生成：基于解析结果和元数据生成 SQL 查询模板。
5. ​参数填充与 SQL 组装：将提取的参数填充到模板中，生成完整 SQL。
6. ​SQL 验证与优化：
   • ​语法验证：确保 SQL 符合语法规则。
   • ​逻辑验证：验证 SQL 的逻辑是否正确。
   • ​性能优化：对 SQL 进行优化以提高执行效率。
7. ​输出最终 SQL 查询：返回验证通过的 SQL 查询语句。

参考 NL2SQL技术方案系列(1)：NL2API、NL2SQL技术路径选择；LLM选型与Prompt工程技巧，揭秘项目落地优化之道

c）存在的难点：歧义消解难、未授权访问处理等

​挑战维度	​问题描述	​典型案例	​技术难点
​语义理解与逻辑拆解	用户自然语言存在模糊性，需精准映射到SQL逻辑操作。	输入“2023年北京退货率>10%的店铺”，需拆解时间、地区、计算逻辑。	歧义消解（依赖业务知识库）、复杂语法生成（嵌套查询、窗口函数）。
​数据库Schema适配	不同数据库表结构差异大，模型需动态适应字段命名、外键关系。	用户输入“员工姓名”对应employee.name或staff.full_name。	动态Schema加载延迟、外键推理（缺乏显式声明时推测关联关系）。
​安全与权限控制	避免生成越权查询，防止访问未授权表或敏感字段。	生成SQL需限制仅访问脱敏视图（如隐藏手机号字段）。	脱敏视图维护、SQL执行前校验（策略引擎引入延迟）。
​查询性能优化	生成语法正确但执行低效的SQL（如未利用索引）。	全表扫描查询导致性能瓶颈，需优化为索引扫描。	索引感知生成（缺乏索引元数据）、执行计划反馈机制设计。

2）常用框架概述：Vanna & DB-GPT

a）Vanna

• Step1：用户描述问题

• Step2：检索相关DDL Schema等（包括表名、字段名、主键外键关系等）

• Step3：生成SQL查询语句检索数据库

• Step4：将检索结果用图表进行绘制

Note：其实在Dify上拉取工作流，也能实现简易版的自动查询库表的功能

如果想通过文本的方式，让大模型自主查询数据库内容，需要拆解成如下步骤：

• 1）数据库类型判断：MySQL，Oracle，Postgres …（database_type，条件判断）

• 2）数据库认证信息检索：jdbcUrl，username，password …（database_name）

• 3）数据库表查询：xxx，xxx，xxx…（直接写死，先判断不同类型的数据库，表查询的sql是否会存在差异）

• 4）数据库表字段查询：yyy，yyy，yyy… （直接写死）

• 5）问题改写：查询关于xxx表的yyy字段（如果要求用图表输出，则进行输出）

• 6）查询xxx表的ER图关系

• 7）sql生成并查询数据库

• 8）根据数据生成明细表、并用图表展示

系统边界要设定好，不允许生成表删除、数据删除的SQL

参考 GitHub - vanna-ai/vanna: 🤖 Chat with your SQL database 📊. Accurate Text-to-SQL Generation via LLMs using RAG 🔄.

b）DB-GPT

参考 GitHub - eosphoros-ai/DB-GPT: AI Native Data App Development framework with AWEL(Agentic Workflow Expression Language) and Agents

4、MCP协议：关于MCP协议的几个问题

【问1】：关于MCP Server、MCP Client的官方文档有哪些？

以下是关于 ​​MCP Server​​ 和 ​​MCP Client​​ 的官方文档及相关资源整理：

---

1）核心官方文档​

• ​​MCP 协议规范与介绍​​

  • 官网：Model Context Protocol 官方文档

  • 内容：协议设计理念、架构图、通信机制（JSON-RPC 2.0）、SDK 使用指南等。

• ​​MCP Server 开发文档​​

  • GitHub：官方 MCP Server 示例库

  • 包含 Python、TypeScript 等语言的实现示例，涵盖资源（Resources）、工具（Tools）、提示（Prompts）三类功能开发。

• ​​MCP Client 支持列表​​

  • 文档：MCP 客户端集成指南

  • 列举支持 MCP 的客户端（如 Claude Desktop、Cursor、Zed），并说明功能支持范围（如资源访问、工具调用）。

参考

• 【Cursor】 - Model Context Protocol Connect external tools and data sources to Cursor using the Model Context Protocol (MCP) plugin system

• 【Anthropic】 - Introduction of Model Context Protocol

• Anthropic | 2025 MCP官方文档解读（二）

---

​​2）​官方 SDK 与工具​​

• ​​Python SDK​​

  • GitHub：MCP Python SDK

  • 用于快速开发 MCP Server 或 Client，支持 FastMCP 框架。

• ​​TypeScript/Node.js SDK​​

  • 通过 npx 运行社区 Server（如 GitHub 工具集成）。

• ​​其他语言支持​​

  • 官方文档提及 Java、Kotlin、C#、Swift 的 SDK。

参考

• MCP Python SDK 参考 MCP Server 开发实战指南（Python版）

• SpringAI MCP Server官方教程：MCP Server Boot Starter :: Spring AI Reference

---

​3）社区与扩展资源​​

• ​​Awesome MCP Servers​​

  • 开源仓库：社区实现的 MCP Server 列表

  • 包含数据库（PostgreSQL、Redis）、云服务（AWS S3）、开发工具（GitHub、Kubernetes）等场景的 Server 实现。

• ​​教程与案例​​

  • MCP 快速上手指南：配置客户端（如 Cline）并连接本地 Server。

  • Anthropic 官方博客：协议背景与设计动机。

参考

• awesome-mcp-servers

• 2025年最得收藏的开源MCP服务器

---

​4）关键注意事项​​

1. ​​WebFlux 适配​​：若需在 Spring WebFlux 中使用，需确认 SDK 是否支持响应式编程（当前官方文档未明确提及，建议优先尝试 Python/TS SDK）。

2. ​​版本兼容性​​：2024年11月发布的 MCP 协议需搭配对应版本 SDK（如 Python SDK ≥3.0）。

3. ​​安全配置​​：工具调用需用户授权，环境变量（如 GITHUB_TOKEN）需在 Server 配置中声明。

【问2】：目前常见的MCP Server有哪些？常见的MCP Client有哪些？

参考

• awesome-mcp-servers

• 2025年最得收藏的开源MCP服务器

1、常见的MCP Server包括：

数据库与云服务

1. Supabase MCP Server

• 功能：连接 AI 与 PostgreSQL 数据库，支持数据查询、项目管理

• 地址：https://github.com/supabase-community/supabase-mcp

3. AWS-S3 MCP Server

• 功能：AI 与 Amazon S3 云存储交互（读取 PDF/图像等文件）

• 地址：https://github.com/aws-samples/sample-mcp-server-s3

5. Redis MCP Server

• 功能：为 AI 提供 Redis 缓存和实时数据检索接口

• 地址：https://github.com/redis/mcp-server-redis

7. Neo4j MCP

• 功能：AI 操作图数据库（执行 Cypher 查询、分析关系网络）

• 地址：https://github.com/neo4j-contrib/mcp-neo4j

开发与运维工具

1. GitHub MCP Server

• 功能：AI 直接操作代码仓库、Issues、PR

• 地址：https://github.com/github/github-mcp-server

3. Kubernetes MCP Server

• 功能：AI 管理 K8s 集群（控制 Pod/服务/部署）

• 地址：https://github.com/Flux159/mcp-server-kubernetes

5. Airflow MCP Server

• 功能：AI 编排 Apache Airflow 工作流

• 地址：https://github.com/Flux159/mcp-server-airflow

7. 腾讯云 TAT MCP Server

• 功能：通过自然语言执行服务器运维命令（安装软件/更新证书）

• 地址：https://github.com/TencentCloud/tat-mcp-server

搜索与信息获取

1. Brave Search MCP Server

• 功能：隐私优先的 AI 网络搜索

• 地址：https://github.com/arben-adm/brave-mcp-search

3. Exa MCP Server

• 功能：高质量 AI 网络研究（支持摘要提取、多语言）

• 地址：https://github.com/exa-labs/exa-mcp-server

5. Tavily MCP Server

• 功能：RAG 友好的搜索引擎（实时爬取网页数据）

• 地址：https://github.com/Tomatio13/mcp-server-tavily

AI 增强工具

1. MiniMax MCP

• 功能：语音克隆、文生视频、文生图像

• 地址：https://github.com/MiniMax-AI/MiniMax-MCP

3. Langchain MCP 适配器

• 功能：为 LangChain 框架扩展 MCP 工具调用能力

• 地址：https://github.com/langchain-ai/langchain-mcp-adapters

5. Higress MCP Hosting

• 功能：托管 Remote MCP Server（企业级认证/限流/审计）

• 地址：https://github.com/higress-group/higress-mcp

垂直场景应用

1. Airbnb MCP Server

• 功能：AI 旅行规划（实时访问房源数据）

• 地址：https://github.com/openbnb-org/mcp-server-airbnb

3. 高德地图 MCP Server

• 功能：地理编码、POI 搜索、路线规划

• 地址：https://github.com/amap-maps/mcp-server-amap

5. 腾讯 EdgeOne Pages MCP

• 功能：一键部署静态网页至全球边缘节点

• 地址：https://github.com/TencentEdgeOne/edgeone-pages-mcp

协议与生态

1. MCP 官方协议文档

• 地址：https://modelcontextprotocol.io/

3. MCP 服务器目录

• 地址：https://glama.ai/mcp/servers

2、常见的MCP Client包括：

Client	Resources	Prompts	Tools	Discovery	Sampling	Roots	Notes
5ire	❌	❌	✅	❓	❌	❌	Supports tools.
AgentAI	❌	❌	✅	❓	❌	❌	Agent Library written in Rust with tools support
AgenticFlow	✅	✅	✅	✅	❌	❌	Supports tools, prompts, and resources for no-code AI agents and multi-agent workflows.
Amazon Q CLI	❌	✅	✅	❓	❌	❌	Supports prompts and tools.
Apify MCP Tester	❌	❌	✅	✅	❌	❌	Supports remote MCP servers and tool discovery.
BeeAI Framework	❌	❌	✅	❌	❌	❌	Supports tools in agentic workflows.
BoltAI	❌	❌	✅	❓	❌	❌	Supports tools.
Claude.ai	✅	✅	✅	❌	❌	❌	Supports tools, prompts, and resources for remote MCP servers.
Claude Code	❌	✅	✅	❌	❌	❌	Supports prompts and tools
Claude Desktop App	✅	✅	✅	❌	❌	❌	Supports tools, prompts, and resources for local and remote MCP servers.
Cline	✅	❌	✅	✅	❌	❌	Supports tools and resources.
Continue	✅	✅	✅	❓	❌	❌	Supports tools, prompts, and resources.
Copilot-MCP	✅	❌	✅	❓	❌	❌	Supports tools and resources.
Cursor	❌	❌	✅	❌	❌	❌	Supports tools.
Daydreams Agents	✅	✅	✅	❌	❌	❌	Support for drop in Servers to Daydreams agents
Emacs Mcp	❌	❌	✅	❌	❌	❌	Supports tools in Emacs.
fast-agent	✅	✅	✅	✅	✅	✅	Full multimodal MCP support, with end-to-end tests
FLUJO	❌	❌	✅	❓	❌	❌	Support for resources, Prompts and Roots are coming soon
Genkit	⚠️	✅	✅	❓	❌	❌	Supports resource list and lookup through tools.
Glama	✅	✅	✅	❓	❌	❌	Supports tools.
GenAIScript	❌	❌	✅	❓	❌	❌	Supports tools.
Goose	❌	❌	✅	❓	❌	❌	Supports tools.
gptme	❌	❌	✅	❓	❌	❌	Supports tools.
HyperAgent	❌	❌	✅	❓	❌	❌	Supports tools.
Klavis AI Slack/Discord/Web	✅	❌	✅	❓	❌	❌	Supports tools and resources.
LibreChat	❌	❌	✅	❓	❌	❌	Supports tools for Agents
Lutra	✅	✅	✅	❓	❌	❌	Supports any MCP server for reusable playbook creation.
mcp-agent	❌	❌	✅	❓	⚠️	❌	Supports tools, server connection management, and agent workflows.
mcp-use	✅	✅	✅	❓	❌	❌	Support tools, resources, stdio & http connection, local llms-agents.
MCPHub	✅	✅	✅	❓	❌	❌	Supports tools, resources, and prompts in Neovim
MCPOmni-Connect	✅	✅	✅	❓	✅	❌	Supports tools with agentic mode, ReAct, and orchestrator capabilities.
Microsoft Copilot Studio	❌	❌	✅	❓	❌	❌	Supports tools
MindPal	❌	❌	✅	❓	❌	❌	Supports tools for no-code AI agents and multi-agent workflows.
Msty Studio	❌	❌	✅	❓	❌	❌	Supports tools
NVIDIA Agent Intelligence toolkit	❌	❌	✅	❓	❌	❌	Supports tools in agentic workflows.
OpenSumi	❌	❌	✅	❓	❌	❌	Supports tools in OpenSumi
oterm	❌	✅	✅	❓	✅	❌	Supports tools, prompts and sampling for Ollama.
Postman	✅	✅	✅	❓	❌	❌	Supports tools, resources, prompts, and sampling
Roo Code	✅	❌	✅	❓	❌	❌	Supports tools and resources.
Slack MCP Client	❌	❌	✅	❓	❌	❌	Supports tools and multiple servers.
Sourcegraph Cody	✅	❌	❌	❓	❌	❌	Supports resources through OpenCTX
SpinAI	❌	❌	✅	❓	❌	❌	Supports tools for Typescript AI Agents
Superinterface	❌	❌	✅	❓	❌	❌	Supports tools
TheiaAI/TheiaIDE	❌	❌	✅	❓	❌	❌	Supports tools for Agents in Theia AI and the AI-powered Theia IDE
Tome	❌	❌	✅	❓	❌	❌	Supports tools, manages MCP servers.
TypingMind App	❌	❌	✅	❓	❌	❌	Supports tools at app-level (appear as plugins) or when assigned to Agents
VS Code GitHub Copilot	❌	❌	✅	✅	❌	✅	Supports dynamic tool/roots discovery, secure secret configuration, and explicit tool prompting
WhatsMPC	❌	❌	✅	❌	❌	❌	Supports tools for Remote MCP Servers in WhatsApp
Windsurf Editor	❌	❌	✅	✅	❌	❌	Supports tools with AI Flow for collaborative development.
Witsy	❌	❌	✅	❓	❌	❌	Supports tools in Witsy.
Zed	❌	✅	❌	❌	❌	❌	Prompts appear as slash commands

【问3】：MCP Client需要和MCP Server部署在同一台机子上吗？WebSocket和SSE协议有什么区别？

MCP Client ​​不一定​​ 需要和 MCP Server 部署在同一台机器上，具体取决于通信方式的选择：

1）​默认本地部署（同一台机器）​​

• 使用 ​​标准输入输出（stdio）​​ 通信时，Client 和 Server 必须在同一台机器上，因为 stdio 依赖进程间的本地管道通信。

• 示例：通过 StdioServerParameters 启动 Server 子进程，适合快速开发和测试。

2）​支持远程部署（不同机器）​​

• 通过 ​​网络协议​​（如 WebSocket、HTTP/SSE）通信时，Client 和 Server 可跨机器部署。

• 示例：Server 使用 WebSocketMCP 监听 0.0.0.0，Client 通过 ws://remote-ip:port 连接。

​​关键区别​​

通信方式	部署要求	适用场景
stdio	必须同一台机器	本地开发、低延迟场景
网络协议	可跨机器	分布式生产环境

​​建议​​

• 若需远程调用，优先选择 WebSocket/SSE 等网络协议

• 注意网络安全配置（如绑定 127.0.0.1 避免暴露风险）

---

WebSocket和SSE协议有什么区别？

WebSocket和SSE（Server-Sent Events）是两种不同的实时通信协议，它们在通信方向、协议基础、适用场景等方面有显著区别。以下是两者的主要对比：

1）​​通信方向​​

• WebSocket​​：支持​​双向通信​​，客户端和服务器可以同时发送和接收数据，适用于需要高频互动的场景（如在线聊天、多人游戏）。

• SSE​​：仅支持​​单向通信​​（服务器到客户端），客户端无法通过SSE连接主动发送数据，适用于服务器推送更新（如新闻、股票行情）。

2）​​协议基础​​

• WebSocket​​：基于独立的ws://或wss://协议，通过HTTP握手升级后建立持久化的全双工连接。

• SSE​​：基于HTTP协议，使用text/event-stream的MIME类型，通过长连接实现数据推送。

3）​​数据传输格式​​

• WebSocket​​：支持​​文本和二进制数据​​，灵活性高，适合复杂数据（如文件、音视频流）。

• ​​SSE​​：仅支持​​文本数据​​（如JSON），每条消息以data:开头并以\n\n分隔。

  

4）自动重连机制​​

• ​​WebSocket​​：无内置重连，需手动实现断线重连逻辑。

• SSE​​：​​内置自动重连​​，断开后浏览器会自动尝试恢复连接。

5）​​适用场景​​

• ​​WebSocket​​：实时聊天、协作编辑、在线游戏等需要​​双向高频交互​​的应用。
  对延迟敏感的场景（如金融交易、实时监控）。

• ​​SSE​​：新闻推送、股价更新、社交媒体通知等​​单向数据推送​​场景。
  资源占用低、实现简单的场景（如ChatGPT的流式响应）。

【问4】：为什么Claude、Cursor在配置MCP server时，command选择uvx，docker或者npx，这些执行命令是否都是stdio通信方式，是否要求MCP Server和MCP client在同一机子上部署吗

在配置MCP Server时，uvx、docker或npx等命令的执行方式与通信模式（stdio或网络协议）以及部署要求的关系如下：

1）​​命令与通信方式的关系​​

• ​​uvx/npx命令​​：
  通常用于启动本地进程，默认通过stdio（标准输入输出）进行通信，要求​​MCP Server和Client必须在同一台机器上​​，因为stdio依赖进程间的本地管道通信。例如：

  {"command": "npx", "args": ["-y", "mcp-server"]} // stdio模式

• ​​docker命令​​：
  可通过配置实现两种模式：

  • ​​stdio模式​​：若容器内进程通过stdin/stdout与宿主机通信（如docker run -i），仍需同机部署。

  • ​​网络模式​​：若容器暴露端口（如SSE/HTTP），则支持跨机器部署。例如：

    {"command": "docker", "args": ["run", "-p", "3000:3000", "mcp-server"]} // 网络模式

2）​​跨机器部署的可行性​​

• ​​stdio模式​​：严格限制同机部署。

• ​​网络协议（SSE/HTTP）​​：支持远程部署，配置文件需指定URL而非本地命令。例如：

  {"mcpServers": {"remote": {"url": "http://remote-ip:3000/sse"}}}

3）​​Claude/Cursor的典型配置​​

• ​​同机场景​​：常见于开发调试，使用uvx/npx快速启动本地服务。

• ​​生产环境​​：推荐改用网络协议（如Composio平台提供的SSE服务），避免依赖本地进程

总结

命令	默认通信方式	同机要求	跨机器部署方法
uvx/npx	stdio	是	不可行
docker	可配置	可选	暴露端口改为网络协议

​​建议​​：若需跨机器部署，优先选择SSE/HTTP等网络协议，并通过URL配置MCP Server

【问5】：MCP服务如果要实现，是否需要Function Calling的大模型支持？Function Calling依赖于ReAct框架吗？

参考 揭秘Function calling：详解大模型调用工具底层原理，四大优化方案提升Agent性能！_前端_赋范大模型技术社区-DeepSeek技术社区

1）Function Calling是什么？

大模型是文本进、文本出的应用，无论是使用langchain reAct框架，还是在dify使用agent模式，它是如何自动识别工具并实现工具调用的（也就是function calling）？后来也弄清楚了，Function Calling主要有两个关键技术：

• a）模型训练：通过提示词的特殊标记的方式，让大模型识别是用户问题的，还是要调用工具；

• b）工具调用时高度结构化文本（JSON）的输出：如果识别到是工具调用，而不是用户问题的输出，则大模型会将输出高度结构化文本（json），通过调用外部工具来执行。

现在无论是Agent开发框架（ReAct、autoGPT等），Text2Api，还是MCP技术，本质上都是对Function calling流程的效率方面的优化

Function calling的底层运行机制：Function calling技术也被称作外部函数调用技术，也被称为tool call或tool use，其核心用途是让大模型能够通过调用一些外部工具来完成工作，该技术最早由OpenAI于2023年6月13号正式提出。

• a）Function calling的底层运行机制：Function calling技术也被称作外部函数调用技术，也被称为tool call或tool use，其核心用途是让大模型能够通过调用一些外部工具来完成工作，该技术最早由OpenAI于2023年6月13号正式提出；

• b）要同时识别多重意图并匹配多项工具，绝非易事。

  

  为了解决这个问题，OpenAI首先采用一套非常特殊的模型训练流程，给大模型赋予了识别外部工具的能力。同时开创性的提出Function calling技术，通过创建一个外部函数作为中介，来传递大模型的调用请求，并完成API调用；

• c）Function calling的核心是需要创建一个外部函数来连接大模型和外部工具API，这个外部函数至少需要由两个部分构成，其一是函数说明，用于告诉大模型这个函数的输入和输出：

  

  其二就是具体调用外部工具API的代码；

  

• d）关于用户的问题，大模型的响应结果如下：

  

  而实际上，大模型底层真实的响应过程是这样的：

  

  其中，这些<｜begin▁of▁sentence｜>、<｜User｜>等隐藏着的特殊标记，就是用于引导模型行为的文本结构标记。这些标记是和文本一起带入模型训练过程的，因此模型非常清楚这些标记的含义，例如<｜User｜>和<｜Assistant｜>中间代表着用户的提问，而<｜begin▁of▁sentence｜>、<｜end▁of▁sentence｜>则代表这一轮对话的全部内容。其实啊，对于DeepSeek R1模型来说<think>字符也是一种特殊标记，只不过允许被打印出来，好让用户区分思考和回复两种文本。

• e）明白了这点，接下来模型的Function calling功能就不难理解了，而实际上，大模型的Function calling就是用特殊标记符来规范的一种特殊响应模式。
  例如当我们给大模型配置了一个查询天气的外部函数的时候，大模型接收到的完整文本如下所示。

  带入外部工具时的用户输入：

  

  需要调用外部工具时的模型输出：

  

2）​​MCP服务是否需要Function Calling的大模型支持？​​

• ​​不需要严格依赖​​：MCP（Model Context Protocol）是一种标准化的协议，旨在统一大模型与外部数据源/工具的交互规范。它本身不绑定特定大模型，而是通过协议层实现模型与服务的解耦。例如，开发者可通过MCP协议调用服务，即使底层模型不支持原生Function Calling。

• ​​互补关系​​：Function Calling是大模型原生能力（如GPT-4、Qwen2等），用于动态调用外部函数；而MCP通过标准化协议扩展了模型的工具调用范围，即使模型无Function Calling能力，也可通过MCP间接调用服务。因此，MCP的实现更依赖协议兼容性，而非特定模型能力。

3）​Function Calling是否依赖ReAct框架？​​

• ​​无直接依赖​​：Function Calling是模型原生机制（如OpenAI的微调实现），其核心是模型生成结构化参数并触发外部调用，无需ReAct框架介入。

• ​​ReAct的差异化​​：ReAct是一种任务规划框架，通过自然语言拆解任务并协调工具调用，强调多步推理和动态调整。虽然两者都涉及工具调用，但ReAct更灵活（支持自然语言规划），而Function Calling更高效（直接输出结构化参数）。部分场景可能结合使用，但非必然依赖。

总结：

• ​​MCP服务​​：可通过标准化协议独立实现，无需强制依赖Function Calling的大模型。

• ​​Function Calling​​：作为模型原生能力，不依赖ReAct框架，但两者可协同用于复杂任务（如ReAct规划后通过Function Calling执行）。

【问6】：MCP Server只能用python搭建吗？能否用Java搭建？

参考

• Spring AI Alibaba

• Spring AI Alibaba MCP 市场正式上线！

• Spring AI Alibaba 支持 MCP 协议接入，在此了解市面上可用的 MCP Server 能力、接入方式与使用示例

• Using Model Context Protocol (MCP) with Spring AI

• Spring AI Alibaba

• Spring AI Alibaba MCP 市场正式上线！_博客-阿里云Spring AI Alibaba官网官网

• Spring AI Alibaba-阿里云Spring AI Alibaba官网官网

• Using Model Context Protocol (MCP) with Spring AI - Piotr’s TechBlog

Spring AI MCP 为模型上下文协议提供 Java 和 Spring 框架集成。它使 Spring AI 应用程序能够通过标准化的接口与不同的数据源和工具进行交互，支持同步和异步通信模式。整体架构如下

1）使用 Spring AI MCP 快速搭建 MCP Server
Spring AI提供了两种机制快速搭建MCP Server，通过这两种方式开发者可以快速向 AI 应用开放自身的能力，这两种机制如下：

• a）基于 stdio 的进程间通信传输，以独立的进程运行在 AI 应用本地（比如本地文件系统，本地数据库等），适用于比较轻量级的工具。

• b）基于 SSE（Server-Sent Events） 进行远程服务访问，需要将服务单独部署，客户端通过服务端的 URL 进行远程访问，适用于比较重量级的工具。

2）在Spring AI中，关于MCP-SSE Server是通过webFlux服务器实现的

之前在尝试使用Spring AI搭建MCP Server和MCP Client中

• 在搭建mcp-stdio-server，mcp-stdio-client还是有问题；

• 在搭建mcp-sse-server没问题，可以配合dify的mcp-sse-client使用

• mcp-sse-client搭建有问题

Dify Agent在reAct框架下，调用工具传参大概率会没问题，但是基于Spring ``WebFlux搭建的sse-server响应会报错，主要还是在调用Function Calling时并没有生成符合条件的JSON：

参考 SpringAI MCP Server官方教程：MCP Server Boot Starter :: Spring AI Reference

【问7】：是否有大模型统一管理的网关？MCP Server服务如何统一管理？是否有关于MCP Server的AI Gateway？

参考

• Glama gateway

• GitHub - alibaba/higress: 🤖 AI Gateway | AI Native API Gateway

关于Glama Gateway的介绍：

• Which AI models are supported？

  We provide support for all major AI providers, including OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI, and more. You can explore the complete list of supported models on our models page. If there’s a model you’d like us to add, you can request it, and we strive to include new models within 24 hours.

• Does Glama support OAuth PKCE？

  Yes. Refer to the OAuth PKCE documentation.

  Note：PKCE 是 Proof Key for Code Exchange 的缩写，PKCE 是一种用于增强授权码模式安全性的方法，它可以防止恶意应用程序通过截获授权码和重定向 URI 来获得访问令牌。PKCE 通过将随机字符串（code_verifier）和其 SHA-256 哈希值（code_challenge）与授权请求一起发送，确保访问令牌只能由具有相应 code_verifier 的应用程序使用，保障用户的安全性。

  参考 授权码 + PKCE 模式｜OIDC & OAuth2.0 认证协议最佳实践系列【03】我们将重点围绕 授权码 + PK - 掘金

• Does Glama support prompt caching？

  Yes. Refer to the Prompt Caching documentation.

• How is Glama Gateway different from OpenRouter?

  Glama Gateway and OpenRouter both offer OpenAI-compatible APIs for accessing multiple AI models with elevated rate limits. However, Glama Gateway distinguishes itself through:

  • Native integration with Chat and MCP ecosystem
  • More comprehensive analytics and logging capabilities
  • Real-time technical support via Discord and email

关于MCP Server网关 - Higress Gateway的介绍：

Key benefits of hosting MCP Servers with Higress:

• Unified authentication and authorization mechanisms

• Fine-grained rate limiting to prevent abuse

• Comprehensive audit logs for all tool calls

• Rich observability for monitoring performance

• Simplified deployment through Higress’s plugin mechanism

• Dynamic updates without disruption or connection drops

AI Gateway:

• Higress connects to all LLM model providers using a unified protocol, with AI observability, multi-model load balancing, token rate limiting, and caching capabilities：