Skip to content

让Agent使用工具 ​

大模型客观存在的一个问题在于,它无法感知外界环境。因此需要调用不同的工具(Tool),来完成更多更复杂的任务。当用户提出天气查询请求时,大模型通过理解意图提取出关键参数(如城市:北京、日期:2025年4月2日),并识别出需要调用的外部“天气查询工具”;随后,该工具通过对接“气象局接口”获取实时或预测的结构化数据,最后由模型将这些专业数据转化为用户易读的最终结果(如:晴,15-25℃)

工具(tools) ​

  • 平台将用户需求(如“上海天气”)及可用工具清单发送给大模型,大模型通过意图识别做出“调用天气工具”的决策并下达指令。
  • 平台负责执行该指令并从外部工具获取原始数据,再将结果回传给大模型进行理解与加工。
  • 大模型将结构化的工具数据转化为自然语言回复,由平台反馈给用户,从而实现了从理解意图到外部执行再到信息整合的完整闭环。
  • 在整个流程中,大模型起到的作用只有选择工具和归纳总结,发挥“大脑”的作用。

图片展示了用户、平台、大模型、天气查询工具之间的交互流程。用户提问“上海今天的天气?”,平台接收到后,列出“天气查询、计算器”等工具,调用“天气查询”工具,再将结果返回给平台。平台将天气查询结果返回给大模型,大模型归纳总结后,平台将最终回复“上海天气如下:...”反馈给用户。此图直观呈现了文档中大模型通过调用工具获取信息并整合回复的流程。

这张图展示了AI智能体工作流程中的三个核心角色及其对应职能,与《AI智能体使用手册》中工具使用的内容相呼应。三个角色分别为大模型、工具、平台:大模型的职能是选择工具、归纳总结,工具的职能是查询天气,平台的职能是串联流程,直观呈现了AI智能体借助工具完成用户需求的分工逻辑,对应了文档中用户提出天气查询请求后,大模型调用工具、平台执行获取数据并回传加工的工作流程。

MCP(tools的一种呈现形式) ​

MCP(Model Context Protocol,模型上下文协议)是一套让大模型调用外部工具的通用标准。在它出现之前,同一个工具想接入 OpenAI、Anthropic、Google 等不同厂商,得分别编写各自的接入规范;有了 MCP,工具和数据源只需按这一套标准实现一次,就能像“万能插头”一样接入所有支持该协议的大模型。

MCP 由 Anthropic 于 2024 年 11 月正式推出并开源。前面提到的“分别编写接入规范”,本质是一个 N×M 问题——N 个大模型平台乘以 M 个工具,就要写 N×M 份互不通用的适配代码。MCP 借鉴了 USB-C 统一物理接口、以及互联网早期用 HTTP 统一网页传输的思路,把它压成 N+M:工具方按协议实现一次 Server,模型方实现一次 Client,两端即可自由组合。协议开源后,OpenAI、Google 等在 2025 年相继宣布支持,MCP 迅速成为大模型连接外部世界的事实标准。

在架构上,MCP 由三个角色组成:Host 是承载大模型的宿主应用(例如 Claude Code、Claude 桌面端);Client 是宿主内部为每个外部服务建立的连接器;Server 则是真正提供能力的一方,把文件系统、数据库、浏览器等封装成模型可调用的工具。任何一个 Server 只要实现一次,就能被所有支持 MCP 的 Host 复用。

下面是社区中较常用的一批 MCP Server,其中 Playwright MCP 也是本手册示例环境接入的浏览器自动化工具。官方仓库里还维护着 Slack、Google Drive、数据库等更多 Server,可按需取用。

工具说明出品方链接
MCP 官方 Reference Servers官方参考实现合集,含 Filesystem、Fetch、Git、Memory、Sequential Thinking 等,覆盖文件读写、抓网页、Git 操作、知识记忆、分步推理官方modelcontextprotocol/servers
Playwright MCP微软出品,用无障碍快照驱动浏览器,让模型点击、填表、抓取页面而无需截图微软microsoft/playwright-mcp
GitHub MCP ServerGitHub 官方出品,让模型直接读仓库、管 Issue 与 PR、查 Actions 工作流官方github/github-mcp-server
Chrome DevTools MCPChrome 团队出品,通过 DevTools 协议控制真实 Chrome,做自动化、调试与性能分析官方ChromeDevTools/chrome-devtools-mcp
Context7Upstash 出品,把各类库的最新文档与代码示例实时注入上下文,减少模型用过时 API社区upstash/context7

Client(命令行客户端 CLI,调用另外的一个智能体) ​

如果说 MCP 解决的是“大模型如何连接工具”,Client 要回答的则是“人如何驱动大模型”——它是承载大模型能力、供人日常使用的客户端。客户端有多种形态:网页版、桌面 App、IDE 插件,而在 AI 编程这一场景里,最主流的形态是命令行客户端,即 CLI(Command-Line Interface,命令行界面)。Claude Code 本身就是一个跑在终端里的 CLI——你在命令行敲下需求,它调用大模型、读写文件、执行命令,直接把结果落到项目里。

命令行并不是新事物。早在图形界面出现之前,Unix 的 Shell 就是人机对话的主要方式,几十年来一直是工程师效率最高的操作入口;图形界面普及后,CLI 一度被视为“过时”,只在服务器和开发场景里保留。大模型的到来让它重新成为主角:AI 需要读写文件、执行命令、串联多个工具,终端天然就是这些能力的交汇点,又轻量、可脚本化、易于嵌进自动化流程。于是 2025 年前后,Anthropic 的 Claude Code、OpenAI 的 Codex CLI、Google 的 Gemini CLI 几乎同时把命令行选作旗舰形态,CLI 由此从“极客工具”回归为 AI 编程的主流入口。

这些 CLI 大致分两类:一类是驱动大模型的“AI 编程客户端”,本身就是 Client;另一类是“工具型 CLI”,通过命令行把某个服务的能力暴露出来供前者调用(例如本手册里 Claude Code 就常调飞书 CLI 来读写文档)。

工具说明类型链接
Claude CodeAnthropic 出品的终端 AI 编码代理,读代码库、改文件、跑命令、接各种开发工具AI 编程客户端code.claude.com/docs
OpenAI Codex CLIOpenAI 出品的轻量终端编码代理,在命令行里完成写码、改码AI 编程客户端openai/codex
opencode开源终端 AI 编码代理,自带终端界面与 build、plan 两种模式AI 编程客户端sst/opencode
飞书 CLI把飞书文档、多维表、消息等能力封装成命令行,供 Claude Code 调用工具型 CLI帮我安装飞书 CLI:https://open.feishu.cn/document/no_class/mcp-archive/feishu-cli-installation-guide.md
即梦cli调用即梦生图,seedance 2.0等多模态的模型工具型 CLIcurl -s https://jimeng.jianying.com/cli | bash

该图片为《AI智能体使用手册》第二课中“让Agent使用工具”模块的内容,清晰呈现了Client(命令行客户端CLI,用于调用其他智能体)的相关说明。它以表格形式对比了工具、MCP与Client(CLI)的核心信息,涵盖是什么、在链条里的角色、怎么被调、统一性标准、例子等维度,还补充了核心逻辑图:大模型仅负责选择工具,工具与大模型的统一形态通过三种路径搭建,分别为客户端内置工具、工具型Client/脚本、MCP Server,明确了AI智能体调用工具的底层逻辑,与上下文CLI工具调用的内容形成对应。