【人工智能】AI基础知识（第四节：工具）

一. 聊天机器人工作模式的局限

传统的聊天机器人工作模式遵循“输入-思考-输出”的简单循环：用户提供信息，大模型接收后进行思考，最终将答案返回给用户。这种模式在处理简单问答时表现尚可，但一旦涉及需要与外部环境交互的复杂任务，其局限性便暴露无遗。

例如，我们期望大模型能帮助我们撰写一篇文章，并自动将其保存到本地指定目录。这看似是一个连贯的任务，但在基础聊天模式下却难以实现。又或者，当你向AI求助：“请帮我查看一下 xxx.js 文件，其中第XX行报了一个XXXX错误。”由于缺乏访问本地文件系统的工具，大模型无法直接读取该文件，只能回复“我无法看到 xxx.js 文件”。此时，你不得不手动复制代码内容并粘贴给模型进行分析。

然而，即便模型分析出了问题的根源，又会面临新的障碍：它无法将修正后的代码写回你的本地硬盘，更不具备调用代码修复、编译验证等工具的能力。因此，整个流程被迫中断，问题无法得到闭环解决。

这正是传统聊天机器人无法真正“帮我们干活”的核心原因。它只能以被动的一问一答方式进行沟通，无法主动调用工具来执行操作、观察结果并持续迭代。简而言之，大模型如同一个拥有强大算力的“超级大脑”，但如果没有接入相应的“手脚”（工具），它就无法协助我们完成实际工作，只能作为一个功能受限的对话工具。

二. 聊天机器人升级为Agent

1）大模型先升级

将聊天机器人升级为 Agent 的第一步，是对大模型本身进行“升级”。这里的升级并非指模型参数的更新，而是指让大模型具备理解和使用工具的能力。

具体来说，升级的核心在于让大模型掌握工具的“元信息”。我们并非在每次对话时临时将工具信息传递给模型，而是需要在通信之前，就完成对大模型的“赋能”。大模型需要主导整个交互流程，明确知道：

• 当前有哪些工具可用；
• 每个工具的名称、功能描述、所需参数及返回格式；
• 如何以结构化的方式请求调用某个工具。

例如，一个名为 write-file 的文件写入工具，其元信息可能包括工具名称、描述（“用于将内容写入指定路径的文件”）、参数（file_path, content）等。只有将这些信息预先“告知”大模型，它才能在后续的推理中知道何时、如何调用该工具。

此外，如果大模型需要调用公开的 API 接口，那么在升级时也必须同步更新对应的接口规范，确保模型能正确构造请求、解析响应。

简言之，只有先将工具的信息完整、结构化地提供给大模型，它才能真正“知道”自己拥有哪些“手脚”，以及如何指挥这些手脚去完成实际任务。

2）聊天机器人升级

按新API的要求把工具信息传递给大模型。一个是输入消息回复消息；一个是React技术。

React具体内容如下：
思考：把历史消息以及工具信息发送给大模型
执行：按照模型的要求执行某个工具
观察：把工具的执行结果进行数据整理

三. 实例演示

下面的例子告诉咱们，大模型和Agent是如何相互协作来完成复杂问题的。需要注意的是Agent在每次与大模型交互之前都会将历史消息信息以及工具的信息通通都告诉大模型，只有大模型知道这些信息之后，大模型才可以进行下一步的推理和操作。

1. Agent->大模型：帮我解决a.js文件的问题，验证工具信息
2. 大模型->Agent：找到读文件工具，并联系Agent来读出文件a.js文件中的内容（对应React中的执行步骤）
3. Agent->大模型：Agent读出a.js文件中的内容，把历史消息和工具信息一并发送给大模型（对应React中的思考步骤）
4. 大模型->Agent：对a.js文件中的内容进行确认，找出问题，并联系Agent来写入文件a.js文件中修正的内容。
5. Agent->大模型：调用write-file工具将大模型分析出来出错的内容予以修正（对应React中的思考步骤），修正完后将历史消息工具信息发给大模型。

下面的时序图清晰地展示了大模型与 Agent 在解决 a.js 文件问题时的协作流程：

该时序图直观地诠释了前文所述的 React（思考-执行-观察）循环：在每一次与大模型交互前，Agent 都会将历史消息和完整的工具信息传递给大模型。大模型基于这些上下文进行推理，并发出调用特定工具的指令。Agent 随后执行该工具，观察执行结果，并将结果连同新的上下文再次传递给大模型，如此循环迭代，直至任务最终完成。

四. 总结

工具是聊天机器人升级为 Agent 最关键的一步。以 ChatGPT 为例，其基础形态只能进行一问一答式的对话，难以独立完成复杂的、多步骤的实际任务。正是通过赋予大模型使用工具的能力，它才能像拥有了“手脚”一样，主动执行操作、观察结果并持续迭代，从而帮助我们完成那些需要与外部环境交互的复杂工作。