Agent从Chat到Act：亚马逊云AI初创活动实战分享

2026-06-03阅读 0热度 0

ai 人工智能

上周受亚马逊云的邀请，在一个线下五六十人的会场，聊了聊Agent的话题。活动氛围相当好。场地不大，大概和中学教室差不多，讲台和观众的距离不到半米，没有麦克风，大家更像是围在一起探讨问题，而不是单向输出。亚马逊团队的晓妍提到，这个活动面向的是AI领域的初创者和爱好者，目标是在早期就发现并支持那些有潜力的创业者——这也是亚马逊云服务从创立之初就延续下来的理念。会议的主题是Agent，我分享的题目叫《从chat到act, 让你的agent从好玩走向实用》。以下是分享内容的核心整理。 --- 先说几个核心判断。从基于深度学习的AI技术发展历史来看，趋势其实很清晰： - **2012年**，ImageNet大赛上深度学习一战成名，那时候AI主要做的是“识别”工作。 - **2022年11月**，ChatGPT发布，AI开始能“聊天”了。 - **去年11月**，OpenAI的GPTs发布后，大家开始畅想：AI不光能聊，还能“做事”。用客服场景举个例子，这三个阶段的差异就一目了然了： > 场景：请对以下两种客户的诉求做出正确回应。 > 顾客A: 你们这个设计真不方便。 > 顾客B: 我今天不方便收货。注意看，两句话里都有“不方便”三个字，但背后的诉求完全不同。 - **AI 1.0时代**：我们希望AI能识别出，哪个“不方便”是负面情绪，哪个是正面信息。 - **Agent的Chat时代**：我们希望AI能针对不同情绪，给出不同的语言回应。比如对A说“抱歉给您带来不便”，对B说“您希望什么时间收货呢”。 - **Agent的Act时代**：我们不光希望它能说“抱歉”，更希望它能直接执行“安排退货”这个动作。进入Act时代，Agent必须与真实的业务系统打通。这时候就有了tool calling——我们希望Agent能主动调用退货接口、安排送货接口，来完成工作。 --- 那么，Act Agent到底长什么样？其实调用业务接口的方式有很多种，比如Coze、Dify这类基于workflow的Agent，或者RPA这类自动化工具。但我这里想说的Act Agent，既不是Dify/Coze那种工作流型，也不是RPA那种精密执行的机器。引用开源项目Mind2Web的一个例子说明：用户说“帮我查一下从北京到上海的机票”，Act Agent会主动从一百多个网站中自主选择最合适的站点，然后读取网页内容，找到填写出发地和目的地的编辑框，把“北京”和“上海”填进去，再执行查询动作。所以更准确地说，这里讨论的是 **Self-driven Act Agent**。与RPA和Workflow-based Agent相比，Act Agent的自主性和理解能力更强，而后两者的执行准确率更高。这不是说谁更好，而是各有各的用武之地。只不过Act Agent作为新事物，想象空间确实更大。在这个客观对比下，如何提高Act Agent的准确性，就成了业界的主攻方向——这也是我今年早些时候开始研究和实践的话题。之前的文章（产品经理研读：Agent的九种设计模式(图解+代码)，Agent开发者坦白：窘境中前行）里提到过一些，今天不妨再总结一下，同时补充一些新的进展。 --- ## 核心思路：拆解准确率问题 Agent设计模式的本质，是把人类思维模式用Prompt的方式表达出来。Re-Act模式是Agent的奠基模式，而提升Agent执行准确率，可以拆解为两个任务： 1. 如何提高规划、思考能力 2. 如何提高执行精准力接下来分别看看，有哪些方法可以完成这两个任务。 ### 方法一：采用合适的Agent设计模式比如“胡椒瓶”这类需要“见机行事”的任务，可以采用Re-Act模式；而“西红柿炒鸡蛋”这类需要“计划先行”的任务（你不可能等油锅热了才去准备鸡蛋），更适合Plan-and-resolve模式。更多内容可以参考之前那篇设计模式的文章。 ### 方法二：Agent Tuning 简单来说，就是通过构建类似Re-Act模式的提示词与自然语言指令，对模型进行微调（详见“Agent开发者坦白：窘境中前行”）。从2023年起，学界在Agent Tuning方面积累了不少论文，这中间有几个值得关注的发现： 1. Agent-Tuning后的模型效果，明显好于不微调的。 2. 模型越小，Agent Tuning带来的提升空间越大。比如对7B和700B参数的模型分别做Agent Tuning，700B模型可能只提升1%，而7B模型能提升20%。 3. Agent Tuning后的能力，可以与十倍规模的大模型相媲美。换句话说，经过Agent Tuning的7B模型，在Agent这个领域内，可以达到70B模型的效果。 ### 方法三：Function Calling Tuning 用一句话来解释Function Calling：大模型在理解函数定义的基础上，把自然语言指令转换成API request或其他函数的调用指令，从而让Agent具备使用外部工具的能力。注意，Function Calling本身并不提交API request。在这个任务上，同样面临一个问题：到底该用大模型还是小模型？参考伯克利大学的开源项目Gorilla，它是在7B基座模型上通过Function Calling Tuning专门优化出来的模型。从评测结果可以看出，大小模型的能力可以做到非常接近。横坐标是推理成本（代表参数量），纵坐标是准确率——大模型和经过Function Calling Tuning的小模型，基本在一个水平线上。 --- ## 如何进行Function Calling Tuning？ OpenAI的FC Tuning Cookbook给出了完整的步骤： ### 第一步：基准模型测试先对基准模型做Function Calling能力评估。如果准确率能达到95%（目前GPT-4的最高标准也就90%左右），那其实可以直接用了。对于不准确的5%，可以在产品层面做降级处理（比如人工介入，或者对模型不擅长的API不做AI化处理）。如果达不到要求——比如用户说“查一下北京今天的天气”，但模型始终没法把“北京”和“今天”这两个参数放到API的正确字段——那就需要进入下一步。 ### 第二步：Function Calling微调微调中最关键的一步是数据集的准备，又可以分为三步： 1. 基于API schema中各个字段的定义，让大模型生成对应的样本值。比如生成100个地点和100个日期。 2. 经过排列组合，得到100×100=10000条API request。过滤掉不合逻辑的数据，假设合格率30%，剩下3000条。 3. 让高阶大模型根据API schema，将这3000条API request转换成相应的自然语言指令。比如“北京明天天气怎样？”“巴黎后天会下雨吗？”。这样就生成了3000条自然语言指令与API request的数据对。 4. 将数据格式化，进行Function Calling微调。 ### 第三步：Function Calling评估这一步与基准模型测试类似，不再赘述。 --- ## 一个有意思的闭环到了这里就会发现一个有意思的事情：我们单纯用API schema，就能生产出更专业的数据；更专业的数据能训练出更专业的模型；更专业的模型被更多人使用，又能反过来生成更专业的数据——这就形成了一个**数据迭代反馈的闭环**。这种迭代的力量非常强大，在互联网产品中大家应该都有深刻的体会。 --- ## 总结让Agent从“好玩”走向“实用”，核心方法可以归为两类： - **提升思考规划能力**：采用合理的设计模式；采用Agent Tuning训练专业模型。 - **提升执行能力**：使用FC专业小模型，并根据API schema进行业务API精调。

Agent从Chat到Act：亚马逊云AI初创活动实战分享

相关阅读

最新教程

最新资讯