LLM 天生只能文字进、文字出。它不能查数据库、不能改文件、不能调用 API——这些能力需要 Tools 来提供。如果把 LLM 类比成人的大脑Tools 就是手和脚。大脑能思考但真正做事靠的是手脚。没有 Tools 的 LLM就像一个能想但不能动的瘫痪者——想法再多也落不了地。一、Tools 是什么Tools 是给 LLM 用的外接能力。常见的有工具类型用途典型实现Search搜索网络/知识库Web Search APIBrowser浏览网页内容Playwright / PuppeteerFile读写文件本地文件系统操作Code Run执行代码Docker sandboxDatabase数据库查询SQL ConnectorMessage发送消息Email / IM APIFunction Calling 的原理LLM 不直接执行任何代码。它做的事是读完工具描述JSON Schema后输出一个标准 JSON告诉程序该调用哪个函数、传什么参数。真正执行的是程序。LLM 说{function:search,args:{query:北京到上海航班}}程序好我执行 search 函数把结果返回给 LLM LLM 看到结果 → 再推理下一步 → 再输出 JSON 调下一个工具Schema 的 description 字段是关键——LLM 通过阅读描述来推理该用哪个工具。所以工具描述写得越清楚LLM 选得越准。写 Tool Schema 的几个实用技巧description 要写场景而不仅是功能不要写搜索互联网而要写当用户需要查找最新信息、实时数据、或不在训练数据中的内容时使用参数描述要具体写明每个参数的含义、格式、取值范围返回值也要描述让 LLM 知道调用后能得到什么给出使用示例在 description 中嵌入 1-2 个典型用例纯 Tools 的局限每个 Agent 需要单独适配 Tool硬编码在 Agent 里。换个 Agent 就要重新实现不通用。此外当工具数量超过一定阈值通常 10-20 个LLM 选择工具的准确率会显著下降——这就是后面 Skill 要解决的问题。二、MCPModel Context ProtocolMCP 由 Anthropic 于 2024 年 11 月发布并开源目标是建立标准化协议统一 AI 模型与外部工具的交互接口。类比AI 界的 USB-C 接口——一次集成处处运行。在 MCP 出现之前每个 AI 应用都要自己写一套工具集成代码。LLM 框架LangChain、Semantic Kernel各自定义了自己的工具接口。当你同时使用多个 AI 应用时同样的工具需要反复适配。MCP 的解决思路把工具从 Agent 中剥离出来变成独立的服务通过标准协议通信。MCP 三件套架构MCP Host包含 LLM 的 AI 应用IDE、聊天机器人MCP Client位于 Host 内负责将 LLM 请求转为 MCP 协议格式MCP Server独立运行的轻量程序通过标准化协议提供工具HostAI 应用 └─ Client协议转换 └─ Server1搜索能力 └─ Server2文件操作 └─ Server3数据库查询MCP 的工作流程Host 中的 LLM 决定需要调用某个工具Client 将请求格式化为 MCP 标准协议消息对应的 MCP Server 接收请求执行操作返回结果Client 将结果转回 LLM 理解的格式LLM 基于结果继续推理MCP vs 直接 Tools维度直接 ToolsMCP集成方式硬编码在 Agent 内独立 Server标准化协议复用性每个 Agent 单独适配跨 Agent 复用社区共享生态各自为政社区共享 MCP Server 市场安全性Agent 直接操作可通过 Server 做权限隔离部署随 Agent 部署独立部署可单独扩缩容MCP 现在还是早期生态不够成熟但方向是对的。在需要远程工具调用的场景中它正在成为事实标准。GitHub 上已经有数百个开源 MCP Server覆盖文件系统、数据库、GitHub API、Slack、浏览器等常见能力。三、Skill 的引入预告Tools 解决了能不能做的问题MCP 解决了怎么接入的问题。但当工具太多、组合复杂时LLM 自己不一定能走对路——这就是 Skill 要解决的问题。第 11 篇会详细展开。
LLM 天生只能文字进、文字出。它不能查数据库、不能改文件、不能调用 API——这些能力需要 Tools 来提供。如果把 LLM 类比成人的大脑Tools 就是手和脚。大脑能思考但真正做事靠的是手脚。没有 Tools 的 LLM就像一个能想但不能动的瘫痪者——想法再多也落不了地。一、Tools 是什么Tools 是给 LLM 用的外接能力。常见的有工具类型用途典型实现Search搜索网络/知识库Web Search APIBrowser浏览网页内容Playwright / PuppeteerFile读写文件本地文件系统操作Code Run执行代码Docker sandboxDatabase数据库查询SQL ConnectorMessage发送消息Email / IM APIFunction Calling 的原理LLM 不直接执行任何代码。它做的事是读完工具描述JSON Schema后输出一个标准 JSON告诉程序该调用哪个函数、传什么参数。真正执行的是程序。LLM 说{function:search,args:{query:北京到上海航班}}程序好我执行 search 函数把结果返回给 LLM LLM 看到结果 → 再推理下一步 → 再输出 JSON 调下一个工具Schema 的 description 字段是关键——LLM 通过阅读描述来推理该用哪个工具。所以工具描述写得越清楚LLM 选得越准。写 Tool Schema 的几个实用技巧description 要写场景而不仅是功能不要写搜索互联网而要写当用户需要查找最新信息、实时数据、或不在训练数据中的内容时使用参数描述要具体写明每个参数的含义、格式、取值范围返回值也要描述让 LLM 知道调用后能得到什么给出使用示例在 description 中嵌入 1-2 个典型用例纯 Tools 的局限每个 Agent 需要单独适配 Tool硬编码在 Agent 里。换个 Agent 就要重新实现不通用。此外当工具数量超过一定阈值通常 10-20 个LLM 选择工具的准确率会显著下降——这就是后面 Skill 要解决的问题。二、MCPModel Context ProtocolMCP 由 Anthropic 于 2024 年 11 月发布并开源目标是建立标准化协议统一 AI 模型与外部工具的交互接口。类比AI 界的 USB-C 接口——一次集成处处运行。在 MCP 出现之前每个 AI 应用都要自己写一套工具集成代码。LLM 框架LangChain、Semantic Kernel各自定义了自己的工具接口。当你同时使用多个 AI 应用时同样的工具需要反复适配。MCP 的解决思路把工具从 Agent 中剥离出来变成独立的服务通过标准协议通信。MCP 三件套架构MCP Host包含 LLM 的 AI 应用IDE、聊天机器人MCP Client位于 Host 内负责将 LLM 请求转为 MCP 协议格式MCP Server独立运行的轻量程序通过标准化协议提供工具HostAI 应用 └─ Client协议转换 └─ Server1搜索能力 └─ Server2文件操作 └─ Server3数据库查询MCP 的工作流程Host 中的 LLM 决定需要调用某个工具Client 将请求格式化为 MCP 标准协议消息对应的 MCP Server 接收请求执行操作返回结果Client 将结果转回 LLM 理解的格式LLM 基于结果继续推理MCP vs 直接 Tools维度直接 ToolsMCP集成方式硬编码在 Agent 内独立 Server标准化协议复用性每个 Agent 单独适配跨 Agent 复用社区共享生态各自为政社区共享 MCP Server 市场安全性Agent 直接操作可通过 Server 做权限隔离部署随 Agent 部署独立部署可单独扩缩容MCP 现在还是早期生态不够成熟但方向是对的。在需要远程工具调用的场景中它正在成为事实标准。GitHub 上已经有数百个开源 MCP Server覆盖文件系统、数据库、GitHub API、Slack、浏览器等常见能力。三、Skill 的引入预告Tools 解决了能不能做的问题MCP 解决了怎么接入的问题。但当工具太多、组合复杂时LLM 自己不一定能走对路——这就是 Skill 要解决的问题。第 11 篇会详细展开。
