上周受亚马逊云的邀请，在一个线下五六十人的会场讨论了Agent的话题。
活动内容非常精彩，嘉宾和听众的提问都很有质量。场地和一个中学教室差不多，观众和讲台的距离不足半米，没有麦克风，观众和嘉宾更像是探讨而不是单向分享。亚马逊初创团队的晓妍说活动面向的都是AI初创者和爱好者，希望在早期就扶持到创业者，孕育亚马逊未来的客户，这也是秉承了亚马逊云服务从创始以来的理念。
这次的会议的主题是Agent, 我分享的题目《从chat到act, 让你的agent从好玩走向实用》。今天跟大家同步分享在我的公众微信号，以下是分享内容，PPT在公众号分享时清晰度下降，大家可以公众号回复”Act“即可获得原版PPT。
2012年，ImageNet大赛上，深度学习大放异彩，那个时候起，AI专注于做识别工作。
2022年11月，ChatGPT的发布，GPT让AI可以聊天了。
去年11月，OpenAI的GPTS发布之后，我们就开始畅想AI不仅可以聊天，还可以做事。
顾客A: 你们这个设计真不方便。
顾客B: 我今天不方便收货。
注意在这两个诉求中，都包含“不方便”三个字，但意味着不同的客户诉求。
在AI1.0时代，我们希望ta能识别这两个“不方便”，哪个是正面情绪，哪个是负面情绪。 在Agent 的Chat时代，我们希望ta能对不同的情绪反馈不同语言，比如对顾客A回答“抱歉，给您带来不便”， 对顾客B回答“您需要安排什么时间收货呢”。 在Agent 的Act时代， 我们不仅希望他能够说“抱歉“，还能真正执行“安排退货”这个动作。
在Act时代，Agent需要去和实际的业务系统去关联。所以就有了tool calling, 我们希望通过Agent能主动调用退货接口，和安排送货接口来完成工作。
实际上，实现调用业务接口的方式有很多种，比如说现在的Coze，Dify这类workflow-based Agent，还比如自动化类的RPA。但我这里想说的Act agent，它既不是像Dify、Coze这种基于workflow的Agent， 也不是RPA这种精密运行的机器。
引用开源项目Mind2Web的一个例子来说明我所说的Act Agent：在右图中，用户提出”帮我查一下从北京到上海的机票”，Act agent就会主动从众多的资源(大约100+个网站）中自主选择合适的网站；之后主动去读取网页内容，在网页上找到可以选择起始地点的编辑框，并将用户口令中的“北京” 和“上海”填入，执行查询动作。
所以更准确的说，这里的Act Agent是Self-driven Act Agent。与RPA, Workflow-based Agent相比，Act agent自主性、理解能力更强，而RPA和workflow-based Agent的执行准确率更高。三者各有使用场景，只是Act Agent作为新兴事物的想象空间更大。
在这个客观对比下，如何让Act Agent来表现得更加准确成为业界主要任务，这也是我今年早些时候开始研究实践的话题。这些话题在之前的文章（产品经理研读：Agent的九种设计模式(图解+代码)，Agent开发者坦白：窘境中前行）有提到，今天在这里总结一下，同时又有些新的进展和探讨和大家分享。
方法1： 采用合适的Agent设计模式。
方法2：Agent tuning。
1.Agent-Tuning后的模型效果好于不微调；
2.Agent tuning的模型越小，提升空间越大。比如你对7B和700B参数的模型去做agent tuning，700B模型可能提升1%，而7B模型能提升20%；
3.Agent tuning后的能力可以十倍规模的大模型相媲美。比如经过Agent tuning的7B模型，在agent tuning这个领域内可以达到70B模型的效果。
获取全部论文公众号回复”Agent tuning“。
我们用一句话来解释这个function calling：大模型在理解函数定义的情况下，把自然语言指令转换为API request或者其他函数的调用指令，从而让agent具备外部工具的使用能力，Function calling本身不提交API request。如上图1中，我们把左边的user request和API scheme list发给大模型，期待ta能输出API request.
在这个任务上面我们同样也会有个问题：到底应该使用大模型还是小模型呢？
根据他们对模型的function calling的能力评测，可以看出大小模型的能力可以做到非常接近。图中横坐标是模型推理成本，实际上代表着模型参数量的大小，纵坐标是模型的准确率。大家可以看到，似乎大模型和经过function calling tuning的小模型在一个水平线上。
那么我们如何来做function calling tuning呢？
OpenAI的FC tuning的Cookbook给出了完整菜谱：
首先对基准模型进行function calling能力评估。如果此时他能达到95%的正确率，按照目前最高标准GPT4 90% 来说，这个标准可以说很高了。此时你甚至可以直接使用，对于不准确的5%在产品中降级（比如发现失败时由人工介入，或者对模型不擅长的API不做AI化处理）。
如果基准测试无法达到要求，比如User request是查一下北京今天的天气，但模型始终不能把“北京”和 “今天”这两个参数值放在API 里正确的字段。这个时候我们就要开始第二步。
微调里面最重要的一步就是数据集的准备，这里也有三步。
假设我们有一个API的schema定义在这个API里面我们有两个字段：地点和日期。
这一步和常规模型的第一步的评测差不多，略过。
这个时候我们就会发现一个非常有意思的事情：也就是说我们单纯用API schema就能够生产出更专业的数据；更专业的数据能生产出更专业的模型；更专业的模型也能被更多的人使用，又能生产出更专业的数据；
如此就进入了数据迭代反馈的阶段，这种迭代的力量是非常强大的，我想大家在互联网的产品当中应该有很深的体会。
这样，我们就暂且总结一下让Agent 从好玩走向实用的方法。
提升思考规划能力：采用合理的设计模式；采用Agent Tuning训练专业模型。
提升执行能力：使用FC专业小模型，并根据API schema进行业务API精调。
