AI

AI 基础知识从 0.5 到 0.6—— Transformer 架构为何能统治AI领域？

Transformer

Transformer 和经典 seq2seq 架构一样使用了 Encoder-Decoder 模式，编码器负责理解输入序列，解码器把编码器的输出作为上下文，自回归输出目标序列，同样是一次编码、多次解码生成。

编码器一次编码：

1.输入序列会被转换成对应的词嵌入表示，每个 token 会被映射到一个连续的向量。然后，需要通过添加位置编码来保留输入序列的先后顺序信息，这样模型就能区分 A B 和 B A 的不同含义。

2.输入序列的词嵌入矩阵被送入模型，通过自注意力机制生成 Query（Q）、Key（K）和 Value（V）三个矩阵，这些矩阵是输入序列中各个 token 的特征表示。

3.Q 矩阵负责提出问题（查询），K 矩阵负责提供信息（匹配），V 矩阵包含实际内容。自注意力机制会计算每个 token 对其他 token 的重要性，也就是注意力权重（Attention Weights），用这些权重对 V 矩阵进行加权求和，生成包含输入序列中每个 token 语义的上下文表示。

因为只编码一次，编码器生成的语义矩阵在结果过程中不再变化（KV 也不会变化）。

解码器逐 token 解码：

1.解码器会对历史生成的目标序列进行嵌入映射，将历史生成结果转化为向量表示。为了保留生成序列的顺序信息，还需要加上位置编码。如果是首次解码（没有历史目标序列），则会使用特殊的起始标记 <SOS>。

2.经过嵌入和位置编码后，目标序列被送入掩码自注意力模块。掩码的作用是确保当前时间步只能看到已生成的历史序列，而不能访问未来的 token，严格遵守自回归生成的规则。

3.掩码自注意力会生成一组新的上下文表示矩阵，描述了解码器目前所有生成序列的内部关系，并作为对目标序列的特征提取结果。

4.解码器进一步通过跨注意力模块，与编码器生成的语义矩阵关联以获取来自输入序列的上下文信息

• 解码器使用掩码自注意力的结果，生成用于与编码器交互的查询表示（Query）。这个 Query 表示当前生成序列的需求或问题。
• 编码器的语义矩阵则通过固定的变换生成 Key（键）和 Value（值），表示输入序列中的全局信息。
• 解码器的 Query 会从编码器输出的 Key 中查询相关的信息，同时结合 Value 形成新的跨序列上下文信息。因为信息来自不同序列，这个操作被称为跨注意力。

5.跨注意力模块的输出被进一步处理，生成解码器最终的语义矩阵，这个矩阵用于预测当前时间步目标 token 的分布，通过采样或搜索方法解码器生成下一个单词。

6.最后，生成的新 token 会添加到历史生成序列中，更新为解码器的输入序列。解码器重复以上步骤，直到遇到特殊结束标记 <EOS>，整个目标序列生成完成。

为了让模型能够利用序列的顺序信息，Transformer 引入了位置编码。位置编码通过为每个位置生成唯一的编码，并与词嵌入（Word Embedding）结合，使模型能够区分相同 token 在不同位置的语义差异。

什么是注意力？

注意力机制并不是 Transformer 的发明，人类在阅读时可以利用注意力聚焦某个词的相关上下文，想象你在阅读这样一个句子：

"那只猫坐在垫子上，它看起来很舒服"

当你读到"它"时，你的大脑会自动回到前面找到"它"指代的对象——"猫"。这种能力就是注意力机制的本质：在理解当前词时，关注与其相关的其他词。

注意力并不是 Transformer 发明的概念，其最早由 Bahdanau 等人于2014年提出，用于解决 RNN 在编码器-解码器架构中的长期依赖问题。但传统注意力机制通过逐步传递信息，但受限于距离和计算效率，难以有效捕捉远距离关联。

Transformer 摒弃了 RNN 和 CNN，提出了自注意力机制，对序列中的每个元素（token）与序列中所有其他元素之间的关系进行建模，用于捕获序列内元素之间的依赖关系。换句话说，它让模型在处理某个 token 时，可以动态关注同一序列中其他对其有重要影响的 token。

注意力的实现 QKV

自注意力机制使模型能够关注输入序列 token 之间的相关性，从而使其能够捕捉数据中的复杂关系和依赖。现在我们知道了什么是注意力，但具体是怎么计算的呢？这就要引入 Transformer 的核心创新：QKV 机制。

那么 QKV 有什么作用？

• Query：是每个 token 提出的“问题”向量，比如一个单词想知道序列中其他单词对其影响。
• Key：是每个单词的“标签”向量，告诉其他位置，它和哪些 token 是相关的。
• Value：是每个单词的语义内容，它是最终被注意力加权取回的信息。

例如：

句子："那只可爱的小猫在阳光下睡觉"
当模型处理"睡觉"这个词时：
- Query（查询）："睡觉"想知道：谁在睡觉？在哪里睡？
- Key（键）：每个词都有自己的标签，如"小猫"标签是"动物"
- Value（值）：每个词的实际含义内容

注意力计算发现：
- "小猫" 与 "睡觉" 关联度最高（主语关系）
- "阳光下" 与 "睡觉" 也有较高关联（地点关系）
- "可爱的" 关联度较低（修饰词，与动作关系不大）

从 QKV 到语义表示

QKV 矩阵并不能表示 Token 和其他 Token 的相关性，从 QKV 矩阵到最终语义表示有一个计算过程。

1. 计算 Query 和 Key 的相关性。每个 token 的 Query 和所有 token 的 Key 做矩阵乘法运算，计算出它对其他 token 的相关性。这会生成一个二维矩阵，即注意力分数矩阵（Attention Scores）
2. 缩放和归一化。为了防止点积值过大造成梯度失控
3. 加权求和获得最终语义矩阵

多头注意力

单个注意力已经很强大了，但 Transformer 的设计者们想：如果同时用多个"大脑"从不同角度理解同一句话会怎样？这就是多头注意力（Multi-Head Attention）——输入序列被分到多个子空间，每个子空间独立计算自己的注意力表示。

多头注意力的核心思想是并行地在多个子空间中计算注意力表示，每个头独立学习特定的关系模式，并在最后通过拼接融合生成最终的上下文特征。

Transformer 的优势

Transformer 相较于传统的 RNN（包括 LSTM 和 GRU）为基础的 Seq2Seq 模型，在多个方面具有显著的优势：

1.并行运算

• RNN 的设计是循环递归的，每个时间步的计算依赖于前一个时间步的输出。这种顺序计算方式阻碍了模型在长序列上的并行化处理，导致训练和推理过程速度较慢。
• Transformer 完全摒弃了递归计算，使用掩码自注意力机制在训练阶段能够同时对整个序列进行处理，加速模型训练过程。

2.长距离依赖

• RNN 越往后传播，模型的隐藏状态可能丢失早期输入的信息，尽管 LSTM、GRU 等通过“门控机制”稍微缓解了这个问题，但在捕获长距离依赖时仍显乏力。
• Transformer 通过自注意力机制，每个 token 都能直接与整个序列中的所有 token 建立联系，全局感知能力极大提高了对长序列上下文的理解能力。

3.丰富的特征表示

• RNN 的隐藏状态是单一维度的时间步相关表示，难以建模复杂的句法和语义模式。
• 多头注意力机制让 Transformer 可以从多角度捕获语义特征，更全面地表示复杂的信息依赖。

Transformer 在计算效率、长距离依赖建模、特征表示能力和任务泛化性等方面全面优于 RNN Seq2Seq，彻底颠覆了序列建模的传统方式，成为现代 NLP 和更广泛任务中的核心架构。

Agent

AI Agent 就是具备自主理解、规划、记忆和工具使用能力的数字化实体。能够代替我们去自主的完成下达的任务。

想象一个高度智能的个人助理，你只需告诉他“帮我规划一次去北京的周末旅行”，他就能自主完成以下任务:

• 感知(Perception): 理解用户的自然语言指令。
• 规划与推理(Planning&Reasoning): 借助模型推理能力，将任务拆解为查询往返机票、筛选酒店、规划景点路线、预估预算等子任务。
• 记忆(Memory): 记住你之前的偏好，比如喜欢靠窗的座位、偏爱的经济型酒店。
• 工具(Tool): 调用外部工具，如机票预订API、酒店查询系统、地图服务等，来执行这些子任务。
• 反馈与迭代(Feedback & Iteration): 将规划好的行程草案反馈给你，并根据你的修改意见进行调整，最终完成预订。

智能体的主流开发范式

主流的智能体应用开发范式大致分为4种：

• 简单 LLM应用: 我们将直接调用模型API实现内容生成的应用归类为简单LLM应用，它们完全依赖模型服务实现内容生成。大家应该还记得，在大模型刚刚面世之时，各类GenerativeAI 概念的 Chat应用大部分都是这类应用。

• 单智能体 SingleAgent: 相比于直接调用模型API的应用，单智能体应用是一种Augmented LLM应用，它的核心理念是为普通LLM应用增加RAG、Tool、Memory等，让模型具备与特定环境交互的能力。

• 工作流 Workflow : 对于一些复杂的业务应用，使用单智能体的架构效果欠佳。为此，我们可以将应用拆分开来，形成多个独立子智能体(每个子智能体是一个Single Agent)的架构，再将这些独立的子智能体按照预定义的流程编排起来，这就是Workflow范式的基本定义。

• 多智能体系统 Multi-Agent: 和Workflow非常类似，都是遵循将复杂智能体应用拆分成多个独立子智能体的理念，但相比于Workflow的确定性流程，Multi-Agent采用的是模型驱动的、对话式的流程编排，各个子智能体在协作上具备更多的自主决策权(通常通过模型决策)。

单智能体

我们将这种架构称之为最简单的智能体应用，同时也是最高级的智能体应用。

弥补了大模型预训练特性在开发上的局限性：

• 无法获取最新数据、私有领域的数据
• 无法调用本地工具
• 无状态，因此无法形成有效的历史记录

说它简单，是因为我们不用做过多的智能体拆分编排等工作，开发者只需要把工具等上下文都给到模型，一切都由模型驱动。说它高级，是因为整个应用由模型作为大脑来驱动和决策，不论任何问题，我们预期模型都能够正确的推理、选择合适的工具、检索到正确的上下文，最终生成复合预期的答案。

单智能体架构的高级性非常依赖底层模型能力，单智能体架构下的一些典型问题:

• 如果一个Agent包含有太多的可用Tools，模型会在决策工具选择时无所适从，效果变差。
• 多轮执行下来，消息上下文会变得很大，消耗大量的Token且影响模型当前专注度。
• 很多复杂的任务需要很多个步骤，通常在某些环节还需要专业领域技能支持，比如科学计算、深入研究、写代码、绘画、任务规划等。
• 单 Agent在复杂任务场景下的可维护性会变差。

工作流

工作流是一种编排模式，需要开发者将一个复杂任务拆解为一系列有序步骤，这些步骤之间的调用关系和条件分支在设计阶段就明确好。

例如，链式工作流(Chain)和路由工作流(Routing)，它们都强调通过规则、逻辑或预设分支，把任务从输入到输出，组织成可控的流程。

工作流的特点是确定性强、可调试性高、可控性好。

1、Chain -链式工作流

链式工作流是一种将复杂任务分解为一系列较小，清晰的子任务的方式。每一步由一个独立的LLM 调用完成，并将上一阶段的输出作为下一阶段的输入。典型应用包括先生成营销文案，再翻译成另一种语言，或先写文章大纲、检查大纲是否满足要求，再基于大纲完整撰写文章。

2、Routing -路由工作流

路由工作流通过对输入进行分类，将它们分派到专门设计的下游任务或处理路径(通常也叫做意图识别)，以实现关注点分离与更精准的响应。例如，在客服系统中，可以将普通咨询、退款请求、技术支持等不同类型的用户问题路由到不同的处理流程与工具，或者在成本和速度优化中，根据问题复杂度，将简单请求分发给小模型，而复杂或罕见问题则交给更强大的模型处理。

多智能体系统

多智能体系统更偏向一种自治协作模式。在这种模式下，系统由多个具备一定自治能力的Agent组成，每个Agent有自己的角色，能力或工具使用范围。它们之间可以通过消息或上下文进行交互，协同完成复杂目标。

这种方式更接近团队合作，而不是预先定义好的流程。优点是灵活性和适应性强，尤其在任务边界不清晰、需要动态规划时表现突出，比如研究型问答、复杂数据分析或跨领域问题求解。但多智能体系统的挑战在于难以预测和调试，因为不同Agent的交互和决策路径可能高度动态，不像工作流那样可控。

Agent设计模式

1、Chain of Thought(思维链)

核心思想: 让模型在回答前，把推理过程一步步写出来。不是一口气报出答案，而是把整个推理过程展示出来。

场景例子: 问小王比小李大1岁，小张的年龄是小李的两倍。如果三个人的年龄加起来是41岁，问小王多大?思维链方式:假设小李的年龄是x，那么小王=x+3，小张=2x，总和=(x+1)+x+(2x) = 4x +1，4x+1=41,4x=38，x=10，所以小王=10+3=13。结果小王13岁。这种方式在逻辑推理、数值计算、逐步分析类问题里，会显得更稳健。

2、Self-Ask(自问自答)

核心思想: 让模型在回答时学会“反问自己”，把大问题拆成多个小问题，然后逐个回答。

场景例子: 问2016年奥斯卡最佳男主角的年龄是多少?Self-Ask会先问:2016年奥斯卡最佳男主是谁?(答:李奥纳多·狄卡比奥)，再问他当时多大?(答:41岁)，最后组合答案。这种方式特别适合事实链路长的问题。

3、ReAct(推理+行动)

核心思想: 在推理(Reasoning)和外部行动(Acting，比如调用搜索引擎或API)之间交替进行。ReAct比CoT、Self-Ask更全能，原因在于它不仅是推理模式，还内建了与外部世界交互的闭环。

场景例子: 问杭州昨天的天气?ReAct会先想:“我不知道昨天的天气，需要查询”，然后执行“调用天气API”，再推理并回答。这让Agent既有思维，又能动手。

4、Plan-and-Execute(计划与执行)

核心思想: 把任务拆成两个阶段，先生成计划(Planning)，再逐步执行(Execution)。

场景例子: 假设你让Agent写一篇“新能源车的市场调研报告”，它不会直接生成报告，而是先拟定计划:收集销量数据，分析政策趋势，总结消费者反馈，撰写结论。然后逐条执行。适合多步骤、需长时间任务的场景。

5、Tree of Thoughts (ToT，树状思维)

核心思想: 不是单线思维，而是生成多条思路分支，像树一样展开，再通过评估机制选出最佳分支。

场景例子: 解一道数独时，Agent会尝试多个候选解法(分支A、B、C)，逐步排除错误分支，最终选出唯一解。适合复杂规划和解谜任务。

6、Reflexion / Iterative Refinement(反思与迭代优化)

核心思想: Agent具备自我纠错的能力，犯错后会总结失败原因，再带着反 思尝试下一次。

场景例子: 让 Agent写一段Python代码，如果第一次运行报错，它会读报错信息，反思“函数参数写错了”，然后自动修正并重试。适合代码生成、流程执行类场景。

7、Role-playing Agents(角色扮演式智能体或者说是多智能体协作)

核心思想: 把任务拆分给不同角色的Agent，每个Agent都有专属职责，通过对话协作完成任务。

场景例子: 一个软件开发任务里，有产品经理Agent写需求文档，程序员Agent写代码，测试 Agent写测试用例。它们像团队一样协作。适合复杂系统开发或跨职能协同。

A2A

什么是 A2A协议？

A2A协议是一项开放标准，旨在解决人工智能快速发展中面临的核心挑战: 如何让由不同团队开发、采用不同技术构建、归属于不同组织的AI智能体实现高效通信与协作? 随着 AI 智能体日益专业化且能力增强，它们需要协同完成复杂任务的需求也愈加迫切。若缺少统一通信协议，将这些异构智能体整合为统一的，用户体验将面临巨大的工程难题。

A2A协议中的角色：

• 用户(User): 发起请求或目标的最终使用者(人类或自动化服务)，需借助智能体协助完成任务。
• A2A客户端(ClientAgent): 代表用户向远端智能体发起操作或信息请求的应用、服务或其他 AI 智能体。客户端通过A2A协议发起通信，不依赖具体远端智能体的实现细节。
• A2A 服务端(RemoteAgent): 实现了A2A协议HTTP 端点的 AI智能体或智能系统，负责接收请求、处理任务并返回结果或状态。

A2A协议中的元素：

• Agent Card(智能体卡片)：一个JSON格式的元数据文档，通常位于固定URL(如/.well-known/agent-card.json), 用于描述A2A服务端的能力。包含智能体身份(名称、描述)、服务端点URL、版本号、支持的A2A功能(如流式传输或推送通知)、提供的技能列表、默认输入/输出模式及鉴权要求。客户端通过解析该文档发现智能体，并获取安全交互的规范。
• Task(任务)：当客户端向智能体发送请求时，若需通过状态化流程完成任务(如生成报告、预订航班)，智能体会创建唯一任务ID并维护其生命周期(提交、处理中、需输入、完成、失败)。任务支持多次客户端与服务端的交互，涵盖复杂场景的多轮通信。
• Message(消息)：客户端与服务端单次通信的基本单元。
• Artifact (产出物)：任务完成后返回的实体化结果(如文档、图片、结构化数据)，由多个内容块(Part)构成，支持流式增量传输。
• Part(内容块)：Message(消息)或Artifact(产出物)中的最小内容单元，支持多类型数据

交互机制：

• 轮询(Polling)：若需状态化长时运行任务，服务端可能返回“处理中”状态，客户端需周期性调用tasks/get轮询获取状态更新，直至任务完成或失败。

• 流式传输(Streaming)：流式传输通过SSE(Server-Send Events)方式实现。适用需增量生成结果或实时进度反馈的任务。

• 推送通知(Push Notifications )：推送通知通过WebHoook方式实现。适用超长耗时任务或SSE长连接不可行的场景。

A2A协议的工作流程主要分为3个大步骤:

1. 发现A2A Server的AgentCard
2. A2A授权和权限认证。
3. 发起A2A请求。

提示词工程

大型语言模型(LLM)作为AI原生应用的技术核心，其输出质量高度依赖于输入的精确性与引导性。提示词工程(Prompt Engineering)，正是围绕如何设计、构建和优化输入文本，以引导大型语言模型产生期望输出的系统性方法。

它并非简单的提问，而是一套涵盖指令设计、上下文注入、角色设定和格式控制的综合性技术。一个精心设计的提示词，能够系统性地引导模型的生成过程，最大化地激发其潜力，确保输出的准确性、相关性和一致性。

提示词核心原则：

1、明确角色与目标

在提示词开头为AI 赋予一个专家角色，能有效激活模型内部与该领域相关的知识库和语言风格，这比泛泛而谈的请求更具引导性。

优秀范例:“假设你是一位拥有10年经验的市场营销总监，请为一款新型智能手表起草一份面向年轻专业人士的产品介绍文案。”

2、提供清晰指令与完整上下文

明确告知 AI需要执行的任务，并提供完成任务所必需的背景信息。指令越具体，歧义越少，模型偏离主题的可能性就越低。

优秀范例:“请总结以下技术文章的核心观点(不超过200字)，并列出其中提到的三个关键数据。不要添加个人评论。文章内容如下:[在此处粘贴文章]”

3、运用范例进行引导

对于需要模型遵循特定模式或风格的复杂任务，提供一到两个“输入-输出”范例，能让AI迅速理解并模仿要求，这远比冗长的描述更有效。

优秀范例:“请分析以下句子的情感及关键对象。范例:输入:‘我喜欢这部电影的剧情。’输出:{'sentiment': 'positive', 'aspect': ‘plot'}。现在，请分析这个句子:‘这台相机的画质很棒，但电池续航太短。’ ”

4、定义结构化输出格式

在应用开发中，要求模型返回特定格式(如JSON、Markdown列表)的数据至关重要，这能确保AI的输出可以直接被下游程序解析和使用。

优秀范例:“请将你的回答组织成JSON格式，包含‘product_name'和‘key_features’两个字段，其中key_features是一个包含至少三项功能的数组。”

提示词工程的局限性：

• 提示词本质是静态的、预定义的模板。缺乏灵活性和扩展性。
• 提示词交互是无状态的，模型不会记忆之前的历史对话。
• 无法突破模型固有的知识边界。

上下文工程

提示词工程在应对动态任务、管理长期记忆、突破知识边界以及高效利用长上下文等方面存在不足，于是就有了上下文工程。

上下文工程的核心理念，在于将AI 应用开发的焦点从优化单次交互的指令，转向为模型的每一次推理动态构建一个完整、准确且高效的认知环境。它不再局限于设计静态的提示词模板，而是致力于创建一个系统，确保模型在执行任务时，能够实时获取并利用完成该任务所需的所有相关信息，包括外部知识、历史记忆、可用工具及执行环境。

关键组成部分：

1、外部知识库的动态供给

为解决 LLM 知识陈旧和领域知识缺乏的问题，上下文工程的核心是为其接入外部知识库。通过检索增强生成(Retrieval-AugmentedGeneration,RAG)技术，系统能够在接收到用户请求时，首先从企业的私有数据库、实时信息流或互联网等外部来源检索相关信息，再将这些检索到的信息与提示词一同组合成最终的上下文，引导LLM基于准确、实时的知识进行回答。

2、长期与短期记忆系统

为了实现连贯且个性化的交互，上下文工程引入了记忆系统。短期记忆负责管理当前对话的上下文，确保多轮对话的流畅性。长期记忆则负责存储跨对话周期的关键信息，如用户偏好、历史决策，重要事实等，使AI能够记住用户，提供真正个性化的服务。

3、工具与能力的扩展

上下文不仅包含静态信息，也包括对模型可用的工具(动态能力)的描述。上下文工程通过为LLM 提供一系列工具(Tools)，本质上是API或函数调用来扩展其能力边界。这使得LLM 不再局限于文本生成，而是可以查询数据库、调用外部服务、执行代码甚至操作物理设备，成为一个能够与数字和物理世界交互的智能体。

4、运行时的上下文管理

面对有限且昂贵的上下文窗口，特别是在长对话或复杂任务中，如何高效管理上下文至关重要。这包括一系列运行时策略，如上下文压缩与摘要，用于在保留关键信息的同时减少Token 消耗;以及上下文重排(Re-ranking)，用于解决中间遗忘问题，将最重要的信息放置在模型最关注的位置，从而提升长上下文处理的可靠性。

RAG

LLM固有的三大局限性，知识时效性滞后、缺乏企业私域知识和存在幻觉风险。

RAG通过引入开卷考试模式，在模型生成答案前，先从指定知识库中检索信息，并将其作为上下文提供给LLM，从而引导模型基于可靠的外部知识进行问答。

RAG 的基础范式可被清晰地解构为三个核心阶段:

• 索引(Indexing)
• 检索(Retrieval)
• 生成(Generation)

这三个阶段环环相扣，共同构成了一个完整的知识注入-匹配-应用的流程。

1、第一阶段:索引

索引阶段的目标是将原始的、非结构化的外部知识(如企业私域文档、实时数据流等)转化为机器可高效检索的格式。这一过程是RAG 系统性能的基石，其质量直接决定了后续检索的准确率和效率。通用实现包含以下关键步骤:

• 文档解析与提取:首先，系统需要从多种格式的原始文档(如PDF、Word、HTML等)中解析并提取出纯文本内容。高质量的解析能最大程度地保留原文的结构和语义信息。
• 文本分块(Chunking):由于LLM上下文窗口的长度限制，以及为了实现更精准的语义匹配，长文档必须被切分成更小、更易于管理的“块”(Chunks)。分块策略(如固定大小、按句子/段落切分)对检索效果有至关重要的影响。
• 语义向量化(Embedding):为让机器理解文本的语义，每个文本块都会通过一个预训练的Embedding模型(如qwen3-embedding、bge-m3)被转化为一个高维度的数学向量。在生成的向量空间中，语义相近的文本块在空间位置上也更接近。
• 构建向量索引库：将所有文本块的向量存储起来，并建立高效索引。

2、第二阶段:检索

检索阶段是连接用户意图与知识库的桥梁。其核心任务是根据用户的自然语言查询，从已构建好的向量索引库中，快速、准确地找出最相关的N个知识块(Top-K)。该过程首先将用户的查询通过相同的Embedding 模型转化为查询向量。随后，系统利用此查询向量在向量索引库中执行相似度搜索(通常使用余弦相似度等度量方法)，计算查询向量与库中所有文本块向量的相似度得分。最后，根据得分高低排序，返回最相关的Top-K个文本块作为后续生成阶段的事实依据。

3、第三阶段:生成

生成阶段是 RAG 流程价值最终体现的环节。系统会将前一阶段检索到的多个相关知识块与用户的原始查询进行整合，构建一个增强的提示词(Augmented Prompt)。

这个提示词通常包含明确的指令，要求LLM 基于提供的上下文信息来回答用户的问题。一个典型的提示词模板如下:

请根据提供的上下文信息来回答用户的问题。如果上下文信息不足以回答，请明确告知。

上下文：
[检索到的知识块1]
[检索到的知识块2]
...

问题：
[用户的原始查询]

Function Calling

Function Calling(函数调用)是一种允许LLM根据用户输入识别它需要的工具并决定何时调用该工具的机制。LLM接收用户的提示词，LLM决定它需要的工具，执行方法调用，后端服务执行实际的请求给出处理结果，大语言模型根据处理结果生成最终给用户的回答。

存在的问题：

• 规格碎片化：不同厂商对工具的描述方式、类型系统、调用时序、流式行为等都不相同。
• 可靠性挑战：错误的选择工具或错误的顺序调用。
• 工程治理缺位。

MCP

MCP(Model Context Protocol，模型上下文协议，下文中简称MCP)是一个开放协议，旨在为模型服务提供标准化的接口，使其能够连接外部数据源和工具。MCP通过统一规范取代了工具的碎片化集成，从而打破数据孤岛，提升AI应用的动手能力。

这与USB-C的设计理念类似: USB-C通过统一接口连接各类物理设备，MCP也提供了一种标准化的方式，将AI应用连接到不同的数据和工具。

从技术角度看，MCP 遵循客户端-服务器架构，其中主机应用可以连接到多个服务器。MCP 有三个关键组件：

• 主机(Host)：代表任何提供 AI 交互环境的应用程序(如 Claude 桌面版、Cursor)，它能访问工具和数据，并运行 MCP 客户端。
• 客户端(Client)：在主机内运行，使其能与 Server通信。MCP Host 会为每一个MCP Server单独创建一个Client，Client与Server保持一对一连接。
• 服务器(Server)：暴露特定功能并提供数据访问

AI应用程序与MCP Server 交互过程：

1. 协议初始化：AI引用程序启用Client，向Server发起初始化请求，附带MCP协议版本与基础上下文等信息。Server返回初始化响应，包括名称、版本及功能概述。
2. 能力发现：查询Server的工具、资源文件、提示词模板列表等
3. 功能调用
4. 会话终止