Agent 的工具是如何被大模型使用的

Agent 的工具是如何被大模型使用的

一篇讲清“工具选择 - 工具调用 - 工具结果回传 - 再推理”的实战笔记

一、前提

先记住一个最重要的结论：

Agent 每次发给大模型的，不只是用户问题，还会带上历史消息和工具信息。

也就是说，模型看到的不是“单独一句话”，而是：

• 当前用户在问什么
• 前面聊过什么
• 现在有哪些工具可以用
• 每个工具怎么调用、参数是什么

所以，工具并不是模型自己“长出来”的能力，而是 Agent 把工具说明和上下文一起喂给模型后，模型再决定要不要用、怎么用。

图 1：Agent 与大模型的基本关系

二、先把流程说透

工具使用不是“一步到位”的，它通常是一个循环：

1. 用户发出任务。
2. Agent 把历史消息和工具信息一起发给大模型。
3. 大模型判断要不要调用工具。
4. 如果要调用，就输出一个工具调用请求。
5. Agent 执行这个工具。
6. 工具结果再回传给大模型。
7. 大模型继续思考，直到给出最终答案。

这个过程看起来像模型在“亲自操作文件”，实际上不是。
真正执行readFile、writeFile的，还是 Agent 侧的程序。

图 2：工具调用的完整闭环

三、工具信息到底长什么样

工具信息可以理解成一份“说明书”。

至少会包含这几类内容：

• name：工具名
• description：工具用途
• parameters：需要哪些参数
• required：哪些参数必填

例如：

{"name":"readFile","description":"读取指定文件内容","parameters":{"type":"object","properties":{"path":{"type":"string","description":"文件路径"}},"required":["path"]}}

模型看到这份信息后，才知道：

• 这个工具能干什么。
• 它需要传什么参数。
• 什么时候适合调用它。

四、例子一：只有readFile工具

现在有一个场景：

• Agent 只提供了readFile工具。
• 用户要求读取a.txt。

可能发生什么

如果文件路径没问题，流程就很简单：

1. 用户说“帮我读a.txt”。
2. Agent 把这个问题连同工具信息发给大模型。
3. 大模型发现可以用readFile。
4. 大模型发起工具调用：readFile(path="a.txt")。
5. Agent 执行读取。
6. Agent 把文件内容回传给大模型。
7. 大模型组织成自然语言回复给用户。

如果读取报错

比如a.txt不存在、路径写错、权限不足，或者文件编码有问题，就会出现报错。

这时的关键点是：

• 报错不是模型自己“看见文件系统报错”
• 而是 Agent 执行工具后，把错误信息回传给模型
• 模型再根据错误信息决定下一步

这一步很重要，因为它说明了：

大模型不是直接访问磁盘，而是通过 Agent 提供的工具间接访问。

图 3：只提供readFile时的流程

五、例子二：同时提供readFile和writeFile

第二个场景更完整一点：

• Agent 提供了readFile和writeFile。
• 任务是：读取a.txt的内容，然后纯净地写入b.txt。

这里的“纯净写入”可以理解为：

• 不额外加解释
• 不夹带多余文本
• 只把a.txt的内容写到b.txt

这个场景里大模型怎么想

大模型看到工具信息后，会做一轮“任务分解”：

1. 先读a.txt。
2. 拿到内容以后，再写入b.txt。

也就是说，模型不是一次性把两个工具同时用完，而是先完成前一步，再决定下一步。

这个流程为什么合理

因为工具调用不是纯文本回答，而是一个带状态的多轮执行过程。

模型需要先知道：

• 读取结果是什么
• 内容是否成功拿到
• 要不要原样写入
• 有没有格式转换需求

六、标准版流程

可以整理成下面这样：

七、为什么模型能“选对工具”

原因不是模型真的认识你的代码仓库，而是工具说明把能力边界讲清楚了。

模型会根据这几个信号判断：

1. 工具名字像不像我要的能力。
2. 工具描述是不是符合当前任务。
3. 参数结构能不能满足当前需求。
4. 上下文里有没有前置结果需要承接。

比如：

• readFile很明显适合“读取文件”
• writeFile很明显适合“写入文件”
• searchWeb很明显适合“查资料”

所以，工具描述写得越清楚，模型越容易选对。

八、为什么工具调用不是直接回答

模型有两种常见输出方式：

1. 直接回答用户。
2. 先发起工具调用，再等工具结果回来后继续回答。

当任务涉及外部世界时，模型通常会优先走第二条路。

例如：

• 读文件
• 查数据库
• 查天气
• 调用支付接口
• 发消息

这些都不是纯语言推理能完成的事情，必须靠工具。

九、工具消息和普通消息的区别

普通消息是对话内容，工具消息是执行结果。

可以简单理解为：

• 用户消息：提出需求
• 助手消息：决定下一步
• 工具消息：告诉模型“刚才执行结果是什么”

这样模型就能在“思考 - 执行 - 再思考”之间循环。

十、实战总结

把这件事说透，其实就是一句话：

大模型不会自己操作文件系统，Agent 会把工具信息发给模型，模型决定调用哪个工具，Agent 再负责真正执行。

如果再展开一点，就是：

• 历史消息让模型知道上下文
• 工具信息让模型知道可用能力
• 工具执行结果让模型知道下一步怎么走

这就是 Agent 工具能够被大模型使用的完整逻辑。