玩转AI应用

大模型

以下是一些常用大模型的特性以及区别：

厂商/系列	代表模型	核心特点	典型应用场景	开源/闭源	大致成本
OpenAI	GPT-3.5	成本（计算／资源）较低；能做一般写作、代码辅助、总结、翻译等任务；	对话式任务，对一般任务（写作、聊天、翻译、简单问题）非常合适	闭源	输入$0.5/百万tokens，输出$1.5/百万tokens
	GPT-4o / GPT-4.1-series	通用性强，多模态（文本、图像、音频），生态整合好，引入更大的上下文支持	内容创作、复杂推理、代码生成、多模态分析	闭源	GPT-4.1 API: 输入$2/百万tokens, 输出$8/百万tokens
	GPT-5	上下文长度：API 上输入 + 输出合起来可以 ~400K tokens 或更多，更好地处理非常长对话、文档、或混合任务（例如图像＋文本长内容）；逻辑推理：在推理深度、多步逻辑、工具调用／agent 工作流中是目前顶尖版本；被设计为“知道什么时候 fast 回答、什么时候 think 更久”的。多模态感知能力：多模态能力更成熟；不仅处理图像 + 文本，也能够把这些模态的信息整合进工具调用、推理等任务中。工具使用：GPT-5 在 Agent /复杂任务自动化 /工具链调用 /长流程任务中被设计为更可靠的支持者。	企业／团队使用／复杂 agent / 多工具调用流程	闭源	GPT-5 是最新旗舰，默认模型；Plus／Pro／Enterprise 等订阅得到不同等级访问；API 用户也可以调用多个变体；有“thinking 模式”等可选设定以匹配任务需求。
Anthropic	Claude 3.5 (Sonnet)	在多数普通任务／生成任务／基础编程任务中表现稳定。能较好处理图像 + 文本，写作、摘要、对话类任务表现不错。支持的上下文窗口已经很大（在 Claude 平台／Bedrock 等为 200,000 tokens 的默认窗口）对文档 /对话历史处理不错。	简单写作／对话／摘要／内容生成，不需要特别复杂的逻辑链／大量上下文	闭源	输入$3/百万tokens, 输出$15/百万tokens
	Claude 3.7 (Sonnet)	安全稳健，超长上下文（200K tokens），混合推理模式（快思慢想），代码能力强。对复杂推理任务、中间解释 (“step-by-step thinking”) 更强；对指令的遵守 (“follow instructions”) 在多数情况下提升；写作／创造性任务中语境构建更丰富。	企业级应用、长文档处理、安全敏感型任务	闭源	输入$3/百万tokens, 输出$15/百万tokens
	Claude 4	在 agent 工作流 /自动化任务中表现更强；在复杂编码任务、长链推理任务（需要多个步骤／需要处理大量上下文／计划任务等）中优势明显。Sonnet 4 最新版本（及 Opus 4）支持 1,000,000 tokens（即百万 token） 的上下文窗口（至少 Sonnet 4 有 preview /扩展支持）。	高复杂／长期项目／大型代码库／需要工具调用／代理操作／大型文件 / 上下文／精准度高／安全性要求高	闭源	输入$3/百万tokens, 输出$15/百万tokens
DeepSeek (开源)	DeepSeek-R1 (系列)	逻辑推理专家，专为数学证明、代码生成、金融分析等复杂任务优化。它基于强化学习（RL）训练，能展示“思维链”（Chain-of-Thought），让推理过程更透明。	科研与数学（解数学题、公式推导）、金融分析（生成复杂SQL查询、策略优化）、算法开发（优化代码逻辑、调试）、教育辅助（分步讲解解题思路）	部分开源	较小模型可本地免费部署；671B通过API调用
	DeepSeek-V3 (系列)	全能型选手，擅长自然语言处理（NLP）任务，如文本生成、多语言翻译、智能客服等。计算效率极高，适合大规模应用。	内容创作（写文章、报告、广告文案）、智能客服（快速响应、多轮对话）、多语言翻译（支持高质量中英互译）、代码辅助（补全、注释生成）	闭源	API成本低（输入$0.14/百万tokens），适合企业大规模部署。

小模型与大模型的区别在哪？为什么现在AI大模型这么流行？

小模型／专门模型：通常训练／设计是为某一类任务或某一个业务场景（比如推荐系统、CTR预测、分类、标签预测）。当任务变了或者场景变复杂，这些模型可能性能下降严重。而且小模型往往依赖有限特征（用户行为、特定历史、有限长度的输入／窗口），不能处理非常长对话／非常多上下文。

大模型（LLMs）：LLMs 可以处理大上下文、对话历史、复杂提示（prompt）／prompt engineering，可以做推理链、中间思考、解释性输出。甚至可以去做RAG（外部知识库检索增强）、MCP（连接外部工具使用），因为现在都是基于Agent去做的，也可以直接通过写提示词的方式用自然语言去调优。

RAG

RAG（Retrieval Augmented Generation，检索增强生成）, 其核心在于将 LLMs 与外部知识库（如维基百科或企业内部文档）连接，使得模型在生成响应前，能够先从这些知识库中检索并使用最相关的信息。这项使开发者能够在无需为每个特定任务重新训练或微调大模型的情况下，通过连接外部知识库和文档，为模型注入额外的非参数化知识，从而显著提升其在专业领域的能力和回答精度。

RAG 系统的搭建与运维，需依托于一套复杂的检索机制，该机制依赖向量搜索及嵌入技术，以确保 LLM 能够高效获取最为契合的信息资源。

RAG是一种将信息检索与生成模型相结合的混合架构。首先，检索器从外部知识库或文档集中获取与用户查询相关的内容片段；然后，生成器基于这些检索到的内容生成自然语言输出，确保生成的内容既信息丰富，又具备高度的相关性和准确性。

一张图看下RAG的基础原理：

RAG 标准技术流程

首先看下这张来自于极客时间实战专栏：RAG 快速开发实战中的分享：

RAG 标准流程由索引（Indexing）、检索（Retriever）和生成（Generation）三个核心阶段组成。

索引阶段，通过处理多种来源多种格式的文档提取其中文本，将其切分为标准长度的文本块（chunk），并进行嵌入向量化（embedding），向量存储在向量数据库（vector database）中。

检索阶段，用户输入的查询（query）被转化为向量表示，通过相似度匹配从向量数据库中检索出最相关的文本块

最后生成阶段，检索到的相关文本与原始查询共同构成提示词（Prompt），输入大语言模型（LLM），生成精确且具备上下文关联的回答。通过这一流程，RAG实现了检索与生成的有机结合，显著提升了 LLM 在领域任务中的准确性和实时性。

再来看看向量的概念和语义搜索。

比如说你有两个水果，我们可以把2个水果通过不同的维度计算出来一个向量的值，形成一个向量的数组，例如：

苹果：[红色: 0.92, 甜度: 0.83, 圆形: 0.78]

草莓：[红色: 0.85, 甜度: 0.75, 圆形: 0.62]

虽然苹果和草莓是不同的水果，但它们的向量很接近。这表明它们有相似的特性，比如颜色和甜度。但如果你把“老虎”表示成向量，则和苹果的向量就不接近。通过比较向量的“距离”，计算机能快速判断哪些事物是相关的。

理解了向量后，我们也许要知道在RAG中，一个重要的搜索方法就是基于向量的语义相似性搜索：

语义检索是通过向量距离，计算用户问题与知识库内容的距离，从而得出“相似度”，当然这并不是语文上的相似度，而是数学上的。

RAG 优化手段

知识采集

RAG的使用有一个关键起点，就是知识库的搭建。而知识库搭建又涉及到一个最原始最通用的方式：数据导入。在企业实际场景中，数据导入的形式五花八门，远不止网页内容。我们需要将各种结构化数据和非结构化数据导入到 AI 的知识库中，才能为后续问答系统提供高质量的“知识地基”。

什么是结构化数据与非结构化数据？

非结构化数据：指那些没有固定格式、不可按行列直接组织的数据，例如：

• PDF、Word、PPT 等文档

• 云文档

• 图片

• 网页内容等

结构化数据：指按预定义结构组织的数据，通常以行和列构成，例如：

• 数据库中的表格数据

因此，企业在构建 AI 系统时，还需要掌握从不同来源导入数据的能力，包括文本、表格、图片、网页等内容，为 RAG 系统提供多样、真实的数据支撑。

一个PDF转Markdown的软件：MinerU，这个软件已经在很多公司的生产环境使用。

企业中除了数据库的知识数据外，还有大量的企业对外的产品文档、帮助手册，而这些文件也需要存储到AI的知识库中。MinurU能够非常较大程度的解析各种PDF文件为Markdown格式，同时识别里面的各种元素。

内容分块

在 RAG 系统中，文档是需要分割成文本块再进行向量嵌入的。分块太大，可能包含太多不相关的信息，从而降低了检索的准确性。相反，分块太小可能会丢失必要的上下文信息，导致生成的回应缺乏连贯性或深度。

分块方式的选择：

• 固定大小的分块：直接设定块中的字数，并选择块之间是否重复内容。通常我们会保持块之间的一些重叠，以确保语义上下文不会在块之间丢失。
• 内容分块：根据文档具体内容分块，例如根据标点符号（如句号）分割。或者直接使用更高级的NLTK或者spaCy库提供的句子分割功能。
• 递归分块：在大多数情况下推荐的方法。其通过重复地应用分块规则来递归地分解文本。例如在langchain中会先通过段落换行符（\n\n）进行分割。然后检查这些块地大小。如果大小不超过一定阈值，则该块被保留。对于大小超过标准的块，使用单换行符（\n）再次分割。以此类推，不断根据块更新更小的分块规则（如空格、句号）。这种方法可以灵活地调整块的大小。例如，对于文本中的密集信息部分，可能需要更细的分割来捕捉细节；而对于信息较少的部分，则可以使用更大的块。而它的挑战在于，需要制定精细的规则来决定何时和如何分割文本。
• 从小到大分块：更直接的解决方案是把同一文档进行从大到小所有尺寸的分割，然后把不同大小的分块全部存进向量数据库，并保存每个分块的上下级关系，进行递归搜索。但是可想而知，我们需要存储大量重复内容，这种方案的缺点就是需要更大的储存空间。
• 特殊结构分块：针对特定结构化内容的专门分割器。这些分割器特别设计来处理这些类型的文档，以确保正确保留和理解其结构。langchain提供的特殊分割器包括：Markdown文件，Latex文件，以及各种主流代码语言分割器。

上述方法中无一例外最终都需要设定一个参数——块的大小，那么我们应该如何选择呢？

首先不同的嵌入模型有其最佳输入大小。比如openai和text-embedding-ada-002模型在256或512大小的块上效果更好。其次，文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。处理长篇文章或书籍时，较大分块有助于保留更多的上下文和主题连贯性；而对于社交媒体帖子，较小的分块更适合捕捉每个帖子的精确语义。实际场景中，可能需要不断实验调整，在一些测试中，128大小的分块往往是最佳选择，在无从下手时，可以从这个大小作为起点进行测试。

嵌入模型

嵌入模型可以帮我们把文本转换成向量，显然不同的嵌入模型带来的效果也不尽相同。比如Word2Vec模型有一些局限性，其生成的词向量是静态的。一旦模型训练完成，每个词的向量就是固定不变的，但如果存在一词多义的情况，可能就会导致问题。相比之下，引入自注意力机制的模型，比如BERT，能够根据上下文动态地调整词义，使得同一个词在不同语境下有不同的向量表示。

在这种情况下，我们推荐参考Hugging Face推出的嵌入模型排行榜MTEB（huggingface.co），同时要注意并非所有的嵌入模型都支持中文，因此在选择时应查阅模型说明。

重排模型

重排模型通过对初始检索结果进行更深入的相关性评估排序，确保最终展示给用户的结果更加符合其查询意图。这一过程通常由深度学习模型实现，如Cohere模型。这些模型会考虑更多的特征，比如查询意图、词汇的多重语义、用户的历史行为和上下文信息等。

在实践中，使用RAG构建系统时都应考虑重排方法，以评估其是否能够提高系统性能。

指代消解

什么是指代消解？

简单来说，指代消解就是让机器学会理解“它”“他”“这里”这种模糊代词到底指的是什么。在我们日常的对话中，代词就像个调皮的小孩，躲在句子里不肯说出“我是谁”，而机器如果不能正确理解这些代词，就很容易答非所问。

尤其是在 RAG（Retrieval Augmented Generation）系统中，能否精准“还原”代词背后的真实含义，直接影响到知识的检索效果和准确率。

在RAG系统中，信息的准确检索和生成依赖于对上下文的深刻理解。如果系统不能正确解析指代关系，就会出现信息混淆，降低召回率和准确性。例如，在检索知识库时，错误地理解“它”可能导致系统返回与用户真正意图不匹配的答案。因此，指代消解有助于：

1. 提升信息检索的精确度
2. 增强生成回答的逻辑连贯性
3. 改善用户体验

指代消解在处理含有复杂指代关系的文本时尤为关键。常见应用场景包括：

1. 自然语言问答系统
2. 对话机器人
3. 机器翻译
4. 信息抽取与文本摘要

当文本中出现多次代词指向同一对象或者含糊不清的指代时，指代消解的作用就显得格外重要。

指代消解的实现通常涉及以下几个步骤：

1. 候选实体识别：梳理用户可能常见的问题，并识别出文本中所有可能的指代对象。
2. 特征提取：利用上下文历史聊天记录信息、语义关系等提取有助于判断指代关系的特征。
3. 模型判定：基于AI大模型，根据当前用户问题和历史聊天记录，从而确定最佳的指代关系。
4. 后处理与评估：持续的对返回结果结果进行优化和校正，确保整体准确性。

查询重写

什么是查询重写？

查询重写（Query Rewriting），是将用户原始的提问，转换为一个更能表达其真实意图的查询方式。它的目标是重新表述问题，以更高的匹配度找到相关文档。

这个能力在面对模糊、歧义或用户表达方式与知识库中的文档术语不一致的情况下，尤其重要。比如用户问：“它开放吗？”如果能自动重写为“长城这个景点现在开放吗，可以去参观吗？”那么检索结果的范围和语义就丰富了，返回的结果显然就更准确了。

为什么需要查询重写

• 用户的提问通常比较口语化，直接用问题检索效果不佳

• 减少查询和文档之间的语义差异

• 多轮对话中的检索，需要指代消解

查询重写策略：

• 子问题查询，生成相关子问题，补充query的细节：利用LLM的分析能力，识别出需要解答哪些子问题才能全面回答主问题。将这些子问题同时发送到检索系统（如向量数据库或搜索引擎）中，寻找与每个子问题最相关的文档片段。将检索到的所有与子问题相关的信息提供给LLM，指令它基于这些证据进行梳理、整合，最终生成一个连贯、全面的答案。
• 假设文档（HyDE）：向LLM发送指令，如“请生成一个能回答以下问题的段落：[用户查询]”。LLM会输出一段虚构但合理的文本。将这个生成的“假设文档”转换为向量（Embedding），然后在向量数据库中进行相似度搜索。找到与“假设文档”最相似的真实文档片段，并将其作为最终检索结果返回给用户或用于后续的答案生成。
• 回溯提示（STEP-BACK Prompting）：引导LLM基于原始问题，提出一个关于基本概念、通用原则或更广泛背景的问题。先检索并获取这个回溯问题的答案。将检索到的通用知识与原始的具体问题相结合，进行演绎推理，最终得出答案。
• 查询扩展，伪相关反馈提供领域知识补充：使用用户的原始查询进行初步检索，得到一组初始文档。从排名前K的文档中，通过算法（如TF-IDF, BM25, 或Embedding）提取出与原始查询最相关且信息量最大的术语。将原始查询与提取出的新术语组合在一起，形成一个新的、更丰富的查询。使用扩展后的新查询进行最终检索，得到更准确、更全面的结果。

MCP

模型上下文协议（MCP）是一种 开放协议，用于实现 LLM 应用 与 外部数据源和工具 之间的无缝集成。无论你是在构建 AI 驱动的 IDE，优化 聊天界面，还是创建自定义 AI 工作流，MCP 提供了一种 标准化方式，让 LLM 能够访问所需的上下文信息。

MCP（ModelContext Protocol）就像是AI世界的USB-C接口，统一了各种工具的连接方式，也就是说通过这个“扩展坞”，AI就可以轻松地与世界上的各种工具协作，变得更聪明、更高效。有了这个，在企业开发中就会通过MCP更容易地接入业务系统，从而实现通过自然语言来操作业务系统。

目前已经有非常多的MCP Server可以让大家使用，网址如下：

• Smithery：https://smithery.ai/

• MCP导航：https://mcp.so/

• 阿里云百炼：https://bailian.console.aliyun.com/?tab=mcp

• MCP官方服务器合集：https://github.com/modelcontextprotocol/servers

• MCP Github热门导航：https://github.com/punkpeye/awesome-mcp-servers

MCP刚发布的时候不温不火，直到今年Agent大爆发才被广泛关注。而在今年2月，Cursor正式宣布加入MCP功能支持，一举将MCP推到了全体开发人员面前。从本质上来说，MCP是一种技术协议，一种智能体Agent开发过程中共同约定的一种规范。这就好比秦始皇的“书同文、车同轨”，在统一的规范下，大家的协作效率就能大幅提高，最终提升智能体Agent的开发效率。

总的来说，MCP解决的最大痛点，就是Agent开发中调用外部工具的技术门槛过高的问题。

MCP工作原理

下面这张图展示了MCP的工作原理：

MCP通信数据结构

在MCP开发过程中，我们会涉及到客户端的开发、服务端的开发，在使用中，客户端AI程序必须通过MCP客服端与MCP服务端进行数据通信，而在通信过程中，通常我们会约定一个说话的格式，这个说话的格式通常称为：协议。

MCP的通信过程中，采用的协议是JSON-RPC，JSON-RPC 就是一个在MCP业务场景中的“说话的格式”。

MCP 强制使用 JSON-RPC 2.0，通过这种标准的约定格式，完成业务流程的通信。这种协议简单轻量，消息格式简单。基于 JSON，几乎所有编程语言都支持。它传输层无关：可在 HTTP、WebSocket、TCP 等多种传输协议上使用。

比如一个JSON-RPC的请求结构如下所示：

请求体：

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

返回体：

{"jsonrpc": "2.0", "result": 19, "id": 1}

针对请求体的结构说明如下：

jsonrpc : 必须为 “2.0”。

method: 调用的方法名（字符串）。

params: 参数（可省略），支持对象（命名参数）或数组（位置参数）。

id: 请求标识符。

请求体这种东西就像你给外卖小哥发消息：

{

  "jsonrpc": "2.0",

  "method": "buy",

  "params": { "item": "coffee", "count": 2 },

  "id": 1

}

method：我要干啥，比如“buy”。

params：我要的细节，比如“2杯咖啡”。

id：这是我给这单起的编号，方便等下对上结果。

然后再响应阶段：外卖小哥给你回消息：

{

  "jsonrpc": "2.0",

  "result": "ok",

  "id": 1

}

这时候你就能根据 id 知道：哦，这是我刚才点的咖啡的结果。

要是出错了，对方会这么回：

{

  "jsonrpc": "2.0",

  "error": { "code": -32601, "message": "Method not found" },

  "id": 1

}

意思就是“你点的这个菜菜单里没有”。

MCP通信协议

MCP 协议基于 SSE 的完整生命周期：从“握手建联”，到“初始化确认”，再到“发工具清单、调用工具”，中间还有“心跳保活”，最后“优雅断开”。

1️⃣ 连接建立

1. 客户端：我先 GET /sse，想开个 SSE 通道。
2. 服务端：好，给你一个 SSE 管道（Emitter），还顺手建了个会话（Session）。
3. 双方：通道打通啦，可以传消息了。

2️⃣ 会话初始化

1. 客户端：我发个初始化请求（InitializeRequest），告诉你我是谁、怎么工作。
2. 服务端：收到！找到对应的会话，回你一个 InitializeResponse。
3. 双方：好，身份确认，咱们对接上了。

3️⃣ ToolList请求（工具清单）

1. 客户端：你有哪些工具能用？我来调用。
2. 服务端：等下，我调调工具管理器，整理出工具清单。
3. 服务端推送：这是工具列表，拿去用吧。

4️⃣ 连接维持（心跳）

1. 客户端：ping~ 还活着吗？
2. 服务端：pong~ 我在呢，同时更新一下心跳时间。
3. 双方：OK，确认连接不中断。

5️⃣ 工具调用

1. 客户端：我现在要用某个工具（POST tools/call），给你参数。
2. 服务端：收到，我去找对应的工具处理器执行一下。
3. 服务端：执行完了，把结果推给你（SSE）。
4. 双方：一次完整的调用结束。

6️⃣ 连接关闭

1. 客户端：事情办完了，我要断开啦。
2. 服务端：好，那我把你的会话和 SSE 管道都清掉。
3. 双方：优雅收尾，拜拜。

AI编排设计模式分享

设计模式之一：链式工作流

这个模式就像工厂流水线——把复杂任务拆成一个个小工序，前一道工序的结果自动传给下一道。技术实现上用了”责任链”设计模式，支持随时增加新的处理环节。

使用场景：

这个实现展示了几个关键原则：

1. 需要分步骤完成的复杂任务（比如先查天气再规划行程最后生成攻略）
2. 宁愿多花点时间也要保证准确率（像重要文件的多级审批）
3. 后一步依赖前一步的结果（就像做菜必须按洗菜→切菜→炒菜的顺序）

设计模式之二：并行化工作流

这个模式就像开了多个窗口同时干活——让多个大模型同时处理任务，最后把结果汇总起来。主要有两种方式：

1. 分片处理：把大任务拆成小任务，分给不同的大模型同时处理（类似分工作业）
2. 投票机制：让多个大模型同时处理同一个任务，最后投票选出最佳结果（像开会讨论）

使用场景：

并行化工作流模式展示了对多个大语言模型操作的高效并发处理。这种模式对于需要并行执行大语言模型调用并自动聚合输出的场景特别有用。

1. 要处理一堆相似但互不干扰的任务（比如同时分析多个用户群体的数据）
2. 需要多个任务独立运行（像工厂里的流水线作业）
3. 任务能快速拆解且可以并行执行（比如同时生成多个产品描述）

设计模式之三：路由工作流

路由模式实现了智能任务分配，能够针对不同类型的输入进行专门处理，这种模式专为复杂任务设计，不同类型的输入由专门的流程处理会更好。

这个模式就像智能分诊台——能自动识别问题类型，转给最专业的处理流程。技术实现上相当于给大模型装了个智能路由器，不同的问题自动走专用通道。

使用场景：

它使用大语言模型分析输入内容，并将其路由到最合适的专门提示或处理程序。

1. 要处理五花八门的问题类型（比如客服系统同时接咨询、投诉、技术问题）
2. 不同问题需要不同专家处理（像医院分内科/外科/急诊）
3. 需要精准分类输入内容（像快递自动分拣系统）

设计模式之四：协调者-执行者

这个模式就像电影拍摄现场——导演（协调者）负责分镜头，各工种（执行者）专注自己的专业领域。技术实现上采用”中央指挥部+特种部队”的架构，既保持灵活又确保可控。

使用场景：

当你的任务像建造摩天大楼需要多方协作时：

1. 任务复杂到无法提前拆解（像应对突发事件的应急小组）
2. 需要不同专业视角（像建筑设计需要结构/水电/装修多方配合）
3. 解决方案需要动态调整（像军事行动中的实时战术变化）

设计模式之五：生成者-评估者

这个模式就像作家与编辑的协作——写手（生成者）负责创作初稿，编辑（评估者）逐字推敲提出修改意见。技术实现上采用”创作-反馈”循环机制，直到作品达到出版标准。

1. 生成者大语言模型：生成初始响应并根据反馈进行改进。
2. 评估者大语言模型：分析响应并提供详细的改进反馈。

使用场景

评估者 - 优化者模式适用于需要多轮迭代以提高质量的任务。

1. 有明确的品质标准（像学术论文需要同行评审）
2. 迭代改进能显著提升价值（像广告文案的AB测试）
3. 追求完美输出（像电影剧本的多次修订）

这种模式我觉得和反思模式应该是同一个。反思（Reflection），是一种重要的AIAgent工作范式。

反思模式对于那些一次执行难以成功的任务特别有用。具体来说，AI首先针对任务生成一个初始输出，然后对这个输出进行审视，检查其准确性、完整性和逻辑性，识别出潜在的问题和改进空间。

这种模式的核心在于赋予AI自我评估和自我修正的能力。它不再是一个简单的输出生成器，而是一个能够不断学习、进步的智能体。通过反思，AI可以从自己的错误中吸取教训，积累经验，逐步提升解决问题的能力。

反思模式的应用：第一个模型处理完成后，第2个模型进行评审，然后让第1个模型处理节点在进行反思性的处理。

设计模式之六：工具使用模式

模型可调用外部 API 或工具获取信息或执行操作，适用于实时数据查询、智能控制等。

在AI会话节点中集成了MCP工具服务，也算是这种模式的应用了。