引子

我们相信在AI时代，Agent将像工业革命时期的机器一样无处不在。对Agent来说，学会使用工具就像人类使用工具一样重要。经过云原生时代的积累，这些工具一大部分就是我们经常提到的微服务架构中的API（接口）。

比如Agent要实现企业内部的问询，没有工具调用能力的Agent就只能回答"我不知道"，使用工具的Agent就能通过调用查询接口来完成回答。

在这里，Agent 使用工具的能力本质上是翻译能力，即结合可用工具，将自然语言翻译为机器调用语言，在图中的例子Agent要完成的翻译题目就是：

不过，这个翻译能力没有那么简单，就连三好学生GPT-4o也会犯错，比如在下面这个案例中，用户需要查询的是类型为会员（type=5）的商品详情，但GPT-4o对应到了“超级会员”（type=23）的类型。

直观归因，LLM能否准确使用工具取决于两个变量：

• 变量一：工具使用的复杂度，相当于API的复杂程度

• 变量二：LLM的理解能力。

  
  

我们首先来看第一个变量：如何评定一个工具（API）是否复杂？

一个工具（API）对LLM难还是简单？

直观感受来说，当一个API request的结构越复杂，LLM将自然语言指令翻译为对应的API 调用请求的难度越大。那么到底复杂到什么程度，LLM的翻译准确率会下降到这个工具不值得被使用呢？

在Chat2AP中用户可以针对不同API很快给出LLM调用该API的准确率：

比如上图中是智谱GLM-4-PLUS，针对3个API（CreateProduct，getFeedback，getUserInfo）的评测结果。 那么，对于准确率较高（>95%）的getUserInfo API，就可以相对放心地被Agent使用。

而上述评测结果在chat2API中并不需要您准备任何数据，只需要像下图一样的API文档即可。

这个API文档就像一个“工具使用说明书” ，告诉LLM应该如何使这款工具，“读完”之后，LLM即可掂掂自己的能力，给出评估。

有了这样的评估之后，Agent开发者就可以知道哪些API可以较为可靠地能被模型使用，Agent可以先从调用这些API的场景开始落地。

那对于那些尚不能被准确调用的API（比如上例中的CreateProduct），是否可以通过优化第二个变量（LLM的理解能力）来实现呢？

复杂工具，如何提升LLM的理解力？

什么样的数据就会产生什么样的模型，我们试想，如果使用企业自身的API数据，是否就可以训练出最懂使用自家工具的模型。

于是，我们以专注于做工具调用的Gorrila（7B）为基础模型，使用企业自身API合成数千条数据，将模型在企业实际场景下的准确率从微调前的70%提升到81%，与GPT-4o（百B级参数量）不相上下。而这个过程不需要用户提供新的数据，仍然使用刚刚提到的API文档即可。

但这仅仅是开始，在此基础上我们还可以在实际案例中根据具体情况继续优化，准确率持续提升。

实际上，在Agentic system 中，支撑Agents的三大资源池是workflow 资源，tools资源和knowledge资源，它们分别对应Agent的规划、工具使用、记忆能力，同时也是Coze、dify这类低代码平台维护的三大件。对于Tools资源池来说：

• Chat2API的工具复杂度评估，可以让Agent开发者优先将简单工具使用起来。

• Chat2API的理解力增强，可以让Agent可使用工具的越来越多。随着数据积累，理解力还会越来越强。

最终，Agent可以将公司内部的工具（API）使用起来，并形成一个Agent库，像现在的内部wiki一样被广泛使用。

那么，Chat2API究竟是如何做到的呢？

Chat2API是如何做到的？

下面这张图阐述概要过程：

第一步： 将API文档转换为OpenAI统一的function schema格式。本质上是利用提示词将非结构的语料转换为本结构化的JSON文档。

第二步：根据function schema合成评估（或训练）数据，具体合成方法可以参考《让Agent从Chat走向Act -- 我在亚马逊云AI初创活动上的分享》的第七部分：FC tuning数据合成方式。除此之外，我们也进行了各种数据清洗、过滤、优化。

第三步：采用AST（抽象语法树的方式评估准确性）评估。AST方法简单来说是按照函数规定的原则逐步输出结果是否准确，比如在下面的示例中，可以准确给出翻译出来的API request中，是数据格式不对，数据的值不对。

实际上，按照这个评估方法，我们收集了不同的测试集，进行进一步地评测，得到如下的结果：