AI Agent产品经理血泪史：一年来我摸过的那些石头【Tools篇】

这一系列内容其实早在三个月前就排上日程了，结果新工作一忙，直接搁置。前两天看到一篇关于GPT-6的报道，这才猛地想起来：哦，还有这事儿没写。于是赶紧把草稿翻出来，改改发出来。至于为什么开头先贴这张图，以及为什么“血泪史”要从Tools开始——很简单：即便到了GPT-6的时代，Tools仍然是AI Agent落地的基石。正如图中所示，AI模型可以进化，但物理攻击还是物理攻击，Tools还是Tools，它并没有变成什么“魔法攻击”。

01 - 前言：从接口请求说起

如果从技术底层看这个世界，其实并没有那么多科幻色彩。大模型也是这么回事，GPT-5、GPT-6都一样。 传统互联网时代，所有功能背后都是一堆接口：

入参 → 请求 → 返回结果

然后通过UI和前端，把这些零散的接口包装成一个功能，呈现给用户。比如一个登录页面：

• 用户输入：用户名、密码
• 后台请求：验证接口
• 返回结果：成功/失败

正确就返回Yes，登录成功；不正确就返回No，告诉你账号或密码错误。 大模型的出现，让这套交互发生了一点变化——Agent 可以直接拿着你的数据去请求登录（例子就不考虑数据安全问题了）。但背后那个登录接口，还是那个登录接口。 AI Agent 的出现并没有改变这个本质，它只是把人工编写的规则，替换成了AI的决策。而Tools，正是帮助AI Agent生成正确API请求参数的关键环节。

02 - 起源：大模型的魅力，其实并不是因为它只是个吐字机

而是可以通过它，把这个世界连接到一起

第一次接触ChatGPT的时候，正好在解决一个棘手的问题——如何快速从一堆非结构化数据中，抽取出结构化的候选人信息，然后提交到系统里。 用户输入的数据真是千奇百怪，毫无固定规则。可能是这样： “白苏，男，才华横溢，电话18856888898，家住XXXXXXXXX” 也可能直接就是一坨文本。尝试过很多种解法，都很难，最后只能写一大段正则来兜底。 后来知道了GPT，再然后，道心就崩了——一个prompt，抹掉了几个月的努力。 更让人崩溃的是，这个输出直接可以作为系统中上传候选人的入参——这不就自动化了？ 上传候选人的接口（API）长这样： 这事儿可以描述得更具体一点：很多人用过寄快递的软件，输入地址时，复制一坨文本进去，它能自动帮你填好。如果识别不出来，你就得一项项手动填。 通过大模型自动化之后，只需要给一个文本框，你输入一坨文本进来，自动就能提交。 那会儿还是22年底，没有Function Calling，更没有Tools，Sam也还没给大家演示ChatGPT帮你点外卖。

03 - 探索：JSON Output 让大模型窥见真实的世界

去年有个段子，说GPT-4能自己越狱。这事儿被自媒体越传越邪乎，但事实上，光靠大模型自己，根本不可能——因为它真的没有办法直接触碰到真实世界，连现在是何年何月何日都不知道。 接着上面的例子讲：只要能让大模型按照我们想要的定义输出结构化的信息，就可以去做很多有趣的事情。JSON就是一个非常不错的选择。 基于这个思路，做了很多探索，比如： 1. 无模板的Excel导入：改变传统数据导入方式，不用再写复杂的业务逻辑，只需要一个Prompt去读取想要的数据列。 2. AI审核员：在原先人审环节前加一个AI审，给一些knowhow和fewshot，输出yes/no很简单。 3. 分类器：场景很多。以前搞个分类，好歹得训练个模型吧——那个年代可真是算法的黄金年代。现在一个prompt搞定。 4. 其他一些业务场景落地：好用，真的太好用了。 但那个时候的大模型还太不成熟，上面的路子能通，但走起来磕磕碰碰。

04 - 救星：Function Calling 以及 Tools 的到来

为何抛弃 Json Output？

在OpenAI的Function Calling到来之前，其实很多人都意识到了需要这样东西——因为Action是Agent不可或缺的一环。但那会儿OpenAI还在努力做自己的Plugin商店（后来死了），国内模型厂家还在起名字。 也有大神通过其他方式在做一些牛逼的实现： - Langchain早期Agent的实现，以及它的Output parse - AutoGPT的爆火，Planning & Execute的实现以及后面的Baby AGI - ……还有很多 但是Json Output天然存在很多缺陷： 1. JSON格式非常标准，但凡输出一个错的token，就异常了。 2. 那会儿模型的上下文还很短，整个窗口才4096，GPT-4是8K和32K，但太贵。 3. 模型其实很难在单个请求里完成多个复杂任务，即使到今天也很难。 4. 大模型真的废话很多，必须不断强调：“不要讲废话”。 5. 工程化复杂，维护成本高……还有一箩筐理由。 下面这个图是AutoGPT当时的Prompt，这句话必不可少： 在OpenAI的0613版本中，更新了Function Calling的功能。那天晚上，激动得一夜没睡，连夜改需求——优雅，实在是太优雅了。 Function Calling的实现方式，让所有LLM应用开发的难度大大降低： 1. Prompt维护成本降低：System Prompt和Function解耦。 2. 热插拔：可以通过JSON Schema快速创建工具，比如Search，谁都能用，插上就行。 3. 工程和业务解耦：以前通过Json Output实现，还得针对不同业务流程设计流程图，工程得判断哪个节点用哪个prompt模板，然后下一个节点是啥。 现在，只要一个循环： 大模型真正改变应用开发的范式，是从0613这里开始的。 后来OpenAI又把Function Calling升级成了Tools，也就是1106版本，原因不详。Tools和Function Calling只是写法上有所差异：Tools更高一级，Function Calling同级的还有OpenAI自己封装的工具Code-Interpreter和File-Search（RAG）。个人猜测是为了推它自己的GPTs——毕竟没有场景，很难留住用户。 1106版本的升级也带来了新功能：Tools可以并行调用。但这个版本估计是为了配合DevDay的仓促之作，不管是3.5还是4，在Tools上都有很多异常问题，直到后面的0125版本才得到改善。

05 - 提升：从Tools上让你的 Agent 更可控

上面讲到了四种实现Function Calling的方式： 通过Prompt让模型输出JSON格式内容。优劣势：Prompt麻烦，输出不稳定，串业务成本高。 官方Json Output，1106与Tools同期推出。优劣势：JSON格式稳定，但它的适用场景和Tools不同——JSON mode是为了输出JSON存在的，而Tools是为了Call API存在的。 Function Calling和Tools就不再赘述。 但从可控的角度来说，还是推荐Function Calling和Tools来实现： 1. 放弃JSON mode：随着模型能力提升，模型能准确输出JSON，但还是会出错，不能保证100%正确。模型厂家对Function Calling是有微调优化的，也有说法是专门的MOE专家，但无从验证。 2. 降低System prompt依赖，：System prompt里写的东西太多了，不能保证模型能很好地遵循它。能在Tools里写的东西，尽量写在Tools里。 3. API Response增强Prompt：其实所有输入给模型的内容，都可以算作是Prompt。同理，Tools调用的结果——API Response也会被返回给模型。可以在这一步增加一些给大模型的约束和提示，准确率非常高，毛估估95%以上。 4. 尽量让模型做选择，而不是填空：把确定的答案做成选项给模型，比如用Enum的方式。一方面减少token输出，提高速度；另一方面，准确率高。 5. 利用Tools来做Route，构建Multi Agent：一个不行就上两个，两个不行就上四个。术业有专攻，Agent的世界也一样。

06 - 未来：Tools 如何推动 Agent 走向智能

一路关注着OpenAI各个版本模型能力的迭代，把模型能力摸得一清二楚。虽然官方没有任何明确说明，但从各版本模型迭代的路线来推断，Tools大概率是OpenAI押注AGI的方式。开头报道截图也能证明这一点。 可能很多人对AI Agent的认知是从Plan-and-Execute开始的，比较有名的就是当时的AutoGPT、BabyAGI，以及国内一个项目Xagent。不否认Plan Agent是一种解决问题的方式，但它绝对不是AI Agent该有的智能。这里就不展开聊Plan Agent了——毕竟去年那些Plan Agent项目至今都很难落地。 而Tools则给出了一种全新的解题思路。开发者只需要关注两件事： 1. 选到合适的工具； 2. 填写准确（优秀）的参数。 所有事情的优化，都可以从这两个方面下手。把业务上的knowhow，快速转化为Agent的知识，提升它在上面两件事上的准确率。把精力放在这个上面，而不是放在工程化上。 Sam虽然是个忽悠大王，但有些话确实不无道理：有些模型迭代能解决的问题，不要花太多精力去做。也许你哼哧哼哧搞几个月，还没上线，下个版本模型就解决了。