引子
我们相信在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中，是数据格式不对，数据的值不对。
实际上，按照这个评估方法，我们收集了不同的测试集，进行进一步地评测，得到如下的结果：
从上图中我们可以看到：这样的微调并没有降低模型对标准实验数据集能力。
注：关于测试集的定义在Chat2API的官方技术报告（https://agent2api.com/docs/chat2api-tech-report）中有详细定义，这里不再详述。
展望
当然，Chat2API不会止步于此。一方面我们发现市场需要效果更直接的产品；另一方面学会使用工具（API）还不足以让Agent 具备Act的能力，只有工具也被很好地组合使用之后，才能Act，比如用户购买商品要完成以下API的组合：
-
首先调用搜索API，找到备选商品。
-
其次调用查询API，查看商品详情。
-
然后调用购买API，完成商品购买。
事实上，在微服务架构下的云原生软件里，所有的GUI应用里，用户旅程实际上都是工具（API）的组合使用的结果。
如果模型能独立从工具池中找到满足用户意图的工具，并进行组合，意味着我们离真正能做事的Agent就非常接近了。
这也是Chat2API正在探索的道路，我们也正在寻找早期合作伙伴，加速大家的Agent落地过程。欢迎直接访问官网预约演示（https://agent2api.com/x007/index）来找我们合作。
感谢
在新的起点上，仍然感谢支持Chat2API项目的合作机构：
-
宽带资本AI坊
-
西云算力的丹摩智算平台（公众号：丹摩智算）
宽带资本AI坊一直在找寻有想法、有行动同学，如果有兴趣，私信我来牵线。
还要感谢Chat2API的UE设计、和前端伙伴：
-
UE设计： 华华（135 2196 2703，清华大学设计硕士，10+年设计经验，ex-自动驾驶APP设计）
-
前端伙伴：Wing（151 1790 1754，ex-滴滴、百度）
Ta们的专业水平和敬业程度绝不亚于大厂高P水平。
新年祝福
最后祝大家元旦快乐，2025走出自己的AGI之道！
原创文章，作者：产品二姐，如若转载，请注明出处：https://www.agent-universe.cn/2024/12/29514.html
