一个普通前端

tools概述

Sat, 28 Feb 2026 00:00:00 GMT

要构建更强大的AI工程应用，只有生成文本这样的"纸上谈兵"能力自然是不够的。工具Tools不仅仅是"肢体"的延伸，更是为"大脑"插上了想象力的"翅膀"。借助工具，才能让AI应用的能力真正具备无限的

可能，才能从"认识世界"走向"改变世界"。

Tools 用于扩展大语言模型(LLM)的能力，使其能够与外部系统、API或自定义函数交互，从而完成仅靠文本生成无法实现的任务(如搜索、计算、数据库查询等)。

特点:

增强LLM的功能:让LLM突破纯文本生成的限制，执行实际操作(如调用搜索引擎、查询数据库、运行代码等)

支持智能决策:在Agent 工作流中，LLM根据用户输入动态选择最合适的Tool完成任务。.模块化设计:每个Tool专注一个功能，便于复用和组合(例如:搜索工具+计算工具+天气查询工具)

Tools 本质上是封装了特定功能的可调用模块,是Agent、Chain或LLM可以用来与世界互动的接口。

Tool通常包含如下几个要素:

name:工具的名称

description:工具的功能描述

该工具输入的JSON模式

要调用的函数

return_direct:是否应将工具结果直接返回给用户(仅对Agent相关)

实操步骤:

步骤1:将name、description和JSON模式作为上下文提供给LLM

步骤2:LLM会根据提示词推断出需要调用哪些工具，并提供具体的调用参数信息

步骤3:用户需要根据返回的工具调用信息，自行触发相关工具的回调

定义tool的方式

Sat, 28 Feb 2026 00:00:00 GMT

#%% md

创建方式1：手动创建Tool()

定义tool的方式2：@tool装饰器

使用@tool装饰器(自定义工具的最简单方式)装饰器默认使用函数名称作为工具名称，但可以通过参数name_or_ca11able来覆盖此设置。同时，装饰器将使用函数的文档字符串作为工具的描述，因此函数必须提供文档字符串。

修改args

定义tool的方式3：StructuredTool.from_function()

修改args

MCP

Sat, 28 Feb 2026 00:00:00 GMT

type

Post

status

Published

date

slug

summary

• MCP 的核心想法：给大模型一个统一的“工具调用协议”，让模型能通过标准方式去调用各种外部工具，从而扩展能力边界（不只是思考，还能做事）。 • 要解决的问题：如果工具分别用 Java、Python、Rust 写，直接把它们做成某个特定语言的 tool 会受限。MCP 通过统一协议，把“跨语言、跨进程”工具调用标准化。 • MCP 最大特点：跨进程调用工具 ◦ 本地跨进程：通过 stdio（标准输入输出）与子进程通信 ◦ 远程跨进程：通过 http 连接远程服务通信 • 消息协议标准：统一使用 JSON-RPC 2.0，优点是与语言无关、结构清晰、易调试、轻量灵活。 • 传输模式演进： ◦ Stdio：客户端启动 MCP Server 子进程，用 stdin/stdout 交换 JSON-RPC 消息，并管理子进程生命周期。 ◦ SSE（旧远程标准）：HTTP POST 发请求 + SSE 长连接收结果，用 sessionId 和 requestId 关联请求响应，属于“伪双工”。 ◦ Streamable HTTP（新标准，2025-03-26 起）：用更统一、健壮的方式替代 HTTP+SSE，减少双连接维护问题，并增强 session 管理（例如返回并使用 Mcp-Session-Id，支持终止会话等），更利于扩展和部署。

MCP的基本原理

我们实现的 tool 怎么调用、参数是什么都是大模型自己决定的。

tool 给大模型扩展了做事情的能力，本来它只能思考，不能做事情，但是现在可以自己调用 tool 来帮你做事情了。

但你有没有发现 tool 有个问题：node 写的 ai agent 的代码，你的 tool 也得是 node 写。如果你之前有一些工具是 java、python、rust 写的呢？你想封装成 tool 怎么办呢？

有的人说：现在不是可以执行命令么，通过单独进程把这些其他语言写的代码跑一下就行啊。

确实，也就是这样：这里的 stdio 就是标准输入输出流，也就是键盘输入、控制台输出。当你进程跑一个子进程，就可以用这种方式通信。

还有的人说：简单，用 http 啊！本地跑个服务就好了。也就是这样：现在是解决了跨语言调用工具的问题。

那如果每个人都这样搞，它们提供的服务都不一样，我想接入别的 tool，是不是要了解每个服务都是怎么定义的呢？

能不能定义一个统一的通信协议，我们都按照这个格式来沟通，这样所有的跨进程工具调用就都可以接入了。

也就是这样：想跨进程调用某个工具，通过这个协议通信就行。不管是本地工具，直接跑那个进程，然后 stdio 通信。还是远程工具，通过 http 连接远程服务进程。

这个协议叫什么呢？是给 Model 扩展 Context 上下文，让它能做的更多，知道的更多的 Protocal 协议。就叫 MCP 吧。恭喜你，你发明了 MCP！

MCP 最大的特点就是可以跨进程调用工具。

跨本地的进程调用，就是用 stdio。

跨远程的进程调用，就是用 http。

你的 AI Agent 就是 MCP 客户端，可以通过 MCP 协议调用各种 MCP Server，实现跨进程的工具调用。

当然，在 langchain 里，它也是 tool ，只不过是 tool 的一种而已：你在 tool 的函数里，调用下 MCP Client，访问下远程 Mcp Server，它本质上还是 tool，但是却集成了 MCP 工具。

MCP传输模式与核心架构深度剖析

1.消息协议:JSON-RPC2.0

在MCP中规定了唯一的标准消息格式，就是JSON-RPC2.0JSON-RPC2.0是一种轻量级的、用于远程过程调用(RPC)的消息交换协议，使用JSON作为数据格式注意:它不是一个底层通信协议，只是一个应用层的消息格式标准。这种消息协议的好处，与语言无关(还有语言不支持JSON吗)、简单易用(结构简单，天然可读，易于调试)、轻量灵活(可以适配各种传输方

2.三种传输模式

MCP提供了三种不同的传输实现。

默认传输方式:基于Stdio、SSE、Streamable HTTP

STDlO(Standard Input/Output)

是一种基于标准输入(stdin)和标准输出(stdout)的本地通信方式

MCPClient启动一个子进程(MCR Server)并通过stdin和stdout交换JSON-RPC消息来实现通信

详细描述如下:

1.启动子进程(MCPServer)

MCPClient以子进程形式启动MCPServer,通过命令行指定Server的可执行文件及其参数

2.消息交换

MCPClient通过stdin向MCPServer写入JSON-RPC消息

MCPServer处理请求后,通过stdout返回JSON-RPC消息，也可通过stderr输出日志

3.生命周期管理

MCPClient控制子进程(MCPServer)的启动和关闭。通信结束后,MCPClient关闭stdin,终止MCP Server

SSE模式

基于SSE的Remote模式(MCP标准(2025-03-26版之前))SSE(服务器发送事件)是一种基于HTTP协议的单向通信技术，允许Server主动实时向Client推送消息，Client只需建立一次连接即可持续接收消息。它的特点是:

单向(仅ServerClient)

基于HTTP协议，一般借助一次HTTPGet请求建立连接

适合实时消息推送场景(如进度更新、实时数据流等)由于SSE是一种单向通信的模式，所以它需要配合HTTPPost来实现Client与Server的双向通信严格的说,这是一种HTTP Post(Client->Server)+HTTPSSE(Server->Client)的伪双工通信模式

这种传输模式下:

一个HTTPPost通道,用于Client发送请求。比如调用MCPServer中的Tools并传递参数。注意,此时Server会立即返回

一个HTTPSSE通道，用干Server推送数据，比如返回调用结果或更新进度

两个通道通过sessionid来关联，而请求与响应则通过消息中的id来对应

详细描述如下: 1.连接建立:Client首先请求建立SSE连接，Server"同意"，然后生成并推送唯一的SessionID

2.请求发送:Client通过HTTPPOST发送JSON-RPC2.0请求(请求中会带有SessionID和Request ID信息)

3.请求接收确认:Server接收请求后立即返回202(Accepted)状态码，表示已接受请求

4.异步处理:Server应用框架会自动处理请求，根据请求中的参数，决定调用某个工具或资源

5.结果推送:处理完成后，Server通过SSE通道推送JSON-RPC2.0响应，其中带有对应的RequestID

6.结果匹配:Client的SSE连接侦听接收到数据流后，会根据Request ID将接收到的响应与之前的请求匹配

7.重复处理:循环2-6这个过程。这里面包含一个MCP的初始化过程

8.连接断开:在Client完成所有请求后，可以选择断开SSE连接，会话结束

简单总结:通过HTTPPost发送请求，但通过SSE的长连接异步获得Server的响应结果

Streamable 模式

Streamable HTTP模式(MCP标准(2025-03-26版))在MCP新标准(2025-03-26版)中，MCP引入了新的Streamable HTTP远程传输机制来代替之前的HTTP+SSE的远程传输模式

HTTP+SSE 这种方式存在问题有:

需要维护两个独立的连接端点

有较高的连接可靠性要求。一旦SSE连接断开，Client无法自动恢复，需要重新建立新连接，导致上下文丢失

Server必须为每个Client维持一个高可用长连接，对可用性和伸缩性提出挑战

强制所有Server向Client的消息都经由SSE单向推送，缺乏灵活性

这里的主要变化包括:

Server只需一个统一的HTTP端点(/messages)用于通信

Client可以完全无状态的方式与Server进行交互,即RestfulHTTPPost方式.必要时Client也可以在单次请求中获得SSE方式响应，如:一个需要进度通知的长时间运行的任务可以借助SSE不断推送进度

Client也可以通过HTTPGet请求来打开一个长连接的SSE流，这种方式与当前的HTTP+SSE模式类似

增强的Session管理。Server会在初始化时返回Mcp-Session-ld,后续Client在每次请求中需要携带该MCP-Session-ld。这个Mcp-Session-ld作用是用来关联一次会话的多次交互; Server可以用Session-ld来终止会话,要求Client开启新会话;Client也可以用HTTPDelete请求来终止会话

Streamable HTTP在旧方案的基础上，提升了传输层的灵活性与健壮性:

允许无状态的Server存在，不依赖长连接。有更好的部署灵活性与扩展能力

对Server中间件的兼容性更好，只需要支持HTTP即可，无需做SSE处理

允许根据自身需要开启SSE响应或长连接，保留了现有规范SSE模式的优势

总结

MCP 的核心想法：给大模型一个统一的“工具调用协议”，让模型能通过标准方式去调用各种外部工具，从而扩展能力边界（不只是思考，还能做事）。 • 要解决的问题：如果工具分别用 Java、Python、Rust 写，直接把它们做成某个特定语言的 tool 会受限。MCP 通过统一协议，把“跨语言、跨进程”工具调用标准化。 • MCP 最大特点：跨进程调用工具 ◦ 本地跨进程：通过 stdio（标准输入输出）与子进程通信 ◦ 远程跨进程：通过 http 连接远程服务通信 • 消息协议标准：统一使用 JSON-RPC 2.0，优点是与语言无关、结构清晰、易调试、轻量灵活。 • 传输模式演进： ◦ Stdio：客户端启动 MCP Server 子进程，用 stdin/stdout 交换 JSON-RPC 消息，并管理子进程生命周期。 ◦ SSE（旧远程标准）：HTTP POST 发请求 + SSE 长连接收结果，用 sessionId 和 requestId 关联请求响应，属于“伪双工”。 ◦ Streamable HTTP（新标准，2025-03-26 起）：用更统一、健壮的方式替代 HTTP+SSE，减少双连接维护问题，并增强 session 管理（例如返回并使用 Mcp-Session-Id，支持终止会话等），更利于扩展和部署。

文档拆分器

Sat, 28 Feb 2026 00:00:00 GMT

1. 为什么要拆分/分块/切分

当拿到统一的一个Document对象后，接下来需要切分成chunks。如果不切分，而是考虑作为一个整体的Document对象，会存在两点问题:

1.假设提问的Query的答案出现在某一个Document对象中，那么将检索到的整个Document对象直接放入Prompt中并不是最优的选择，因为其中一定会包含非常多无关的信息，而无效信息越多，对大模型后续的推理影响越大。

2.任何一个大模型都存在最大输入的Token限制，如果一个Document非常大，比如一个几百兆的PDF，那么大模型肯定无法容纳如此多的信息。基于此，一个有效的解决方案就是将完整的Document对象进行分块处理(Chunking)。无论是在存储还是检索过程中，都将以这些块(chunks)为基本单位，这样有效地避免内容不相关性问题和超出最大输入限制的问题。

2、TextSplitter的使用

TextSplitter作为各种具体的文档拆分器的父类

内部定义了一些常用的属性:

chunk_size:返回块的最大尺寸，单位是字符数。默认值为4000(由长度函数测量)

chunk_overLap:相邻两个块之间的字符重叠数,避免信息在边界处被切断而丢失。默认值为200,通常会设置为chunk_size的10% -20%。

Length_function:用于测量给定块字符数的函数。默认赋值为len函数。Len函数在Python中按Unicode字符计数，所以一个汉字、一个英文字母、一个符号都算一个字符。

keep_separator:是否在块中保留分隔符，默认值为False

add_start_index:如果为'True'，则在元数据中包含块的起始索引。默认值为False

strip_whitespace:如果为'True'，则从每个文档的开始和结束处去除空白字符。默认值为True

2.内部定义的常用的方法:

情况1:按照字符串进行拆分:

split_text(xxx):传入的参数类型:字符串;返回值的类型:List[str]

create_documents(xxx):传入的参数类型:List[str];返回值的类型:List[Document]。底层调用了split_text(xxx)

情况2:按照Document对象进行拆分:

split_documents(xxx):传入的参数类型:List[Document];返回值的类型:List[Document]。底层调用了create_documents(xxx)

常见的拆分器

Sat, 28 Feb 2026 00:00:00 GMT

#%% md

1.CharacterTextSplitter

参数情况说明:

chunk_size:每个切块的最大token数量,默认值为4000。

chunk_overlap:相邻两个切块之间的最大重叠token数量，默认值为200。

separator:分割使用的分隔符,默认值为"n\n"。

length_function:用于计算切块长度的方法。默认赋值为父类Textsplitter的len函数。

#%% md

举例1：体会 chunk_size 和 chunk_overlap

separator优先原则:当设置了 separator(如"。")，分割器会首先尝试在分隔符处分割，然后再考虑chunk_size。

这是为了避免在句子中间硬性切断。这种设计是为了:

1.优先保持语义完整性(不切断句子)

2.避免产生无意义的碎片(如半个单词/不完整句子)

3.如果 chunk_size比片段小，无法拆分片段,导致overlap失效。

4.chunk_overlap仅在合并后的片段之间生效(如果chunk_size足够大)。如果没有合并的片段，则overlap失效。

#%% md

2.RecursiveCharacterTextSplitter（最常用）

文档切分器中较常用的是RecursivecharacterTextSplitter(递归字符文本切分器)，遇到特定字符时进行分割。

默认情况下，它尝试进行切割的字符包括["\n\n","\n"," "，""]。

具体为:根据第一个字符进行切块，但如果任何切块太大，则会继续移动到下一个字符继续切块，以此类推。

此外，还可以考虑添加，。等分割字符。

特点:

保留上下文:优先在自然语言边界(如段落、句子结尾)处分割，减少信息碎片化。

智能分段:通过递归尝试多种分隔符，将文本分割为大小接近chunk_size的片段。

灵活适配:适用于多种文本类型(代码、Markdown、普通文本等)，是LangChain中最通用的文本拆分器。

#%% md

TokenTextSplitter

为什么按Token分割?

语言模型对输入长度的限制是基于Token数(如GPT-4的8k/32k Token上限)，直接按字符或单词分割可能导致实际Token数超限。

大语言模型(LLM)通常是以token的数量作为其计量(或收费)的依据，所以采用token分割也有助于我们在使用时更方便的控制成本。

TokenTextSplitter 使用说明:

核心依据:Token数量+自然边界。(TokenTextsplitter 严格按照 token数量进行分割，但同时会优先在自然边界(如句尾)处切断，以尽量保证语义的完整性。)

优点:与LLM的Token计数逻辑一致，能尽量保持语义完整

缺点:对非英语或特定领域文本，Token化效果可能不佳典型场景:需要精确控制Token数输入LLM的场景

#%% md

SemanticChunker:语义分块 (langchain1.0 中用不了，代替方案semchunk)

Semanticchunking(语义分块)是LangChain中一种更高级的文本分割方法,它超越了传统的基于字符或固定大小的分块方式，而是根据文本的语义结构进行智能分块，使每个分块保持语义完整性，从而提高检索增强生成(RAG)等应用的效果。

1. Late Chunking (延迟分块) —— 2025 年最火技术

这是目前最推崇的替代方案，由 Jina AI 等公司率先普及。

需要先用一个“逻辑切割器”来定义边界，然后让 Embedding 模型去处理这些边界。

传统做法：先切块，再对每个块单独生成向量。这会导致切块时丢失整篇文章的语境（Context Loss）。

Late Chunking 做法：

用 RecursiveCharacterTextSplitter 把文本物理上切开。

将整篇长文档输入支持长上下文的 Embedding 模型（text-embedding-v3 或 Qwen3-Embedding，国外是JinaEmbeddings）。

模型会为每个 Token 生成带有全局信息的向量。

最后再进行切块。这样切出来的每一个分块向量，都**“吸收”了前后文的信息**。

优点：即便是一个很短的句子，它的向量也包含了整篇文章的背景，极大提升了检索精度。

2. Contextual Retrieval (上下文检索/分块)

由 Anthropic（Claude 厂商）在 2024 年末提出，并在 2025 年大规模流行。

原理：在分块之前，利用 LLM 为每个小分块写一段简短的“背景说明”（Contextual Header）。

示例：

原始分块：“该公司的营收增长了 20%。”（单独看这个块，搜索者不知道是哪家公司，哪一年）。

上下文分块：“[背景：这是关于苹果公司 2024 年第三季度财报的描述] 该公司的营收增长了 20%。”

优点：显著解决了分块后语义支离破碎的问题，检索成功率（Top-1 Recall）通常能提升 40% 以上。

3. Agentic Chunking (智能体分块)

利用 AI Agent（如 GPT-4o 或 Claude 3.5）来像人一样阅读并决定在哪里下刀。

逻辑：

Agent 扫描全文。

它判断：“这里主题变了，从‘产品功能’转到了‘售后政策’，我应该在这里切断。”

它能识别复杂的边界（如表格中间、代码块中间不准切）。

优点：这是目前最精准的切分方式，完全遵循逻辑而非字符数。

缺点：非常昂贵，通常只用于构建极高质量的旗舰级知识库。

文档嵌入模型

Sat, 28 Feb 2026 00:00:00 GMT

04-文档嵌入模型.ipynb

221.6 KiB