11｜Why：从Chat走向Act，我们还缺什么？

你好，我是产品二姐。

这节课我们会开启一个全新案例。前面的案例大多是Chat类的工作，让Agent帮我们梳理资料、回答问题。而这个案例，我们会让Agent做Act类的工作。当然，这里的Act并不是说要干体力活（那属于具身机器人的范畴），而是让人类可以通过Agent来操作软件系统，比如让Agent帮我们在美团上订个外卖之类的。

我们的案例是让Agent下一个工单，做一个自助工单小助手的产品。在技术应用方面，除了之前用到的RAG、提示词工程、Agent设计、function calling之外，还会使用微调技术来提升Agent执行的准确率。

第一节，我会带你理解三个重点。一是什么是能做事（Act）的Agent，也就是“自助工单小助手”这个产品做些什么事？二是有哪些方式可以实现Agent的Act能力？三是“自助工单小助手”在做事儿的背后发生了什么。这部分内容能让你在未来的工作中准确识别哪些场景适合实现Act类Agent，即理解“锤子”的基础上找“钉子”。

第二节，我们会讨论微调模型对构建Act类的Agent来说有什么好处，以及作为产品经理，应该如何理解和应用这项技术？这部分内容既能帮你判断什么时候需要用到微调，又能帮你与技术、算法工程师更加融洽地合作。

第三节，我们会深入到“自助工单小助手”的实际场景，讨论如何准备微调数据，如何评估微调后的模型。这两部分内容也是AI产品经理在提示词工程之外的主要工作，在你在未来的工作中可以当做观摩案例。

目前，这类应用在市场上目前没有成熟的商业案例可以参考，甚至在我们目前的尝试中，准确率也难以达到商用水准，因此我会拿部分论文案例参考。尽管如此，它依然是未来的方向，正因如此，我希望你和我一起探索，在本门课的最后一个案例中走在市场前沿，为你未来的AGI产品经理职业生涯做好知识预习！

什么是能做事儿（Act）的Agent？

首先，我想引用阿里集团CEO吴永铭一句话来说明什么是Act类的Agent。他说：

深层次AI最大的想象力绝对不是在手机屏幕上做一两个超级APP，而是接管数字世界，改变物理世界。

这是他在最近2024年9月云栖大会上的发言。这句话怎么理解呢？我用三个例子来说明。

• 例1：2024年10月，OpenAI的开发者大会上，演讲中展示了Agent帮主人订咖啡的场景。

• 例2：2024年9月，蚂蚁金服旗下的支小宝发布大会上，展示了一个送奶茶到现场的例子。

• 例3：在本门课第一章03节开头有个例子：当客户要求明天送货的时候，Agent可以自动修改快递师傅的送货时间。

这三个例子中，订咖啡、送奶茶、上门送货都是物理世界，而AI所操作的是数字世界。

过去几十年互联网的发展帮我们构建起了巨大的数字世界，它使人类与物理世界可以进行广泛链接。比如在某打车软件的App里，完成了出行工具、司机与乘客的链接；在某个购物App里，完成了商品、卖家与买家的链接。

而AI带给我们的，就是把人类从数字世界中解放出来，让Agent代替人类完成这一链接。

在我们要讲的案例中，一个汽车企业客户希望做一个自助工单创建的小助手，他们希望Agent在帮助车主解答问题的同时，还能根据故障情况安排师傅上门维修。也就是，让Agent接管“电动汽车车主-售后维修师傅-电动车及其设备”的数字世界。

我再用一段Agent与客户的对话来说明。

在这段简短对话中：

• 首先客户反馈“充电桩坏了，需要报修”，接下来Agent追问故障信息。

• 然后客户反馈故障是“无法开机，拉闸拉不上去”，于是Agent回复“故障需要上门维修，并给客户三个时间选项。

• 最后客户回复“周三方便”，Agent停留片刻后，就回复已经安排好，并把师傅的电话也一并发给客户。

看到这里你可能会想：

嗯～第一步Agent追问故障信息，这个应该是很自然的事情。
第二步中Agent判断上门维修可能是在RAG知识库里查到了类似的故障需要上门维修，但是它又是怎么知道周三、周四、周五这个时间的呢？不会是随便瞎说的吧。
至于第三步，Agent真的给安排师傅了吗？可不能随便给客户一个假消息，让客户白等一趟吧。

其实，这些回复背后都是有充分的依据的。要达到这样的标准，就需要Agent的思考力和行动力，Agent的思考力主要靠大语言模型本身来完成，实现方法上和之前Chat类的Agent是一致的，我们就不做详细讲解；而行动力需要Agent与外部世界进行准确链接来完成，我们把重点放在这一部分，看看有哪些方式可以提升Agent的行动力。

有哪些方式可以提升Agent的Act能力？

目前业界有两种方式实现Agent的Act能力。

1. 模拟方式，即让Agent 模拟人类操作。比如人类在网页上点击一个按钮，那么Agent也就执行一次点击操作。

2. 函数调用方式，即Agent直接操作数字世界的接口或者函数来实现。比如通过function calling调用一次查询接口请求实现一次查询操作，这里Agent无需操作页面。

我们一个个来讲。

方式1：模拟人类来操作数字世界。

顾名思义，就是人类怎么操作数字世界，Agent也怎么操作数字世界。

比如某旅游网站的Agent收到用户指令“给我订一张23号从北京到上海的晚上九点以后的机票”。那Agent的执行步骤就是：

1. 提取用户指令中的出发地， 目的地，出发日期。

2. 找到网站上出发地， 目的地，出发时间这些字段，并将上述信息填入对应的输入框。

3. 点击确认，提取网页中各个航班的信息，包括时间、价格、机场，即从网页html代码中提取出对应的页面元素。

4. 提取出晚上九点以后的机票信息，返回给用户选择机票。

5. 收到用户的选择。

6. 点击对应机票的确认按钮。

7. 填入乘机人信息。

8. 点击提交订单。

9. 请求用户输入账户密码。

10. 点击确认，完成机票预订。

这种方式的好处是不用改变数字世界本身。但这种方式在操作的时候需要做大量的信息提取工作。

在Claude的Computer Use中，通过多模态识别到屏幕上元素所在的像素点，然后通过点击该像素点实现。这种方式目前在一个开源数据集中的准确率是多少呢？14.9% [参考]，这是Claude的测试结果，而这已经是非常领先了。

另外一种方式是类似开源项目Mind2Web中，要从几百个网页元素中找到出发地、目的地、出发时间。这个过程中难免会发生提取错误。

虽然我们可以通过微调的方式提升Agent的网页元素识别准确率，但根据一些论文来看，微调后的准确率也没有超过80%。比如开源项目mind2Web 中，作者收集了137个网站的页面信息，执行了2350个自然语言指令，记录了这些指令背后的页面操作步骤作为数据进行微调，网页元素识别的准确率仅仅为55%。

另外，这种方式会把大量的无效信息（几百个网页元素的html代码）发送给模型，造成Token浪费。我下载了部分数据后发现，仅仅一条自然语言指令对应的数据量大小大约是40万Token数。如果在OpenAI GPT3.5模型的基础上微调，一条数据就要消耗3.2美元，成本令人咂舌。

注：这里的成本计算方法是，mind2Web的某个训练数据文件大小为28MB，该文件中包含9条训练数据。平均每条训练数据的文件大小约3MB，约3M个字符，按照平均每个单词10个字符算，约为30万个单词，折合为40万Token数，微调openAI GPT3.5的价格为$8/百万Token，即3.2美元

综合起来看，虽然这种方式不用改变现有系统，但如果直接让Agent模拟人类操作现有系统，准确率和成本都是难以克服的问题。所以，我们来看另外一种方式。

方式2：调用与物理世界的接口-function calling

这种方式就是让Agent学会使用数字世界的接口来完成任务，同样是订机票的例子，这种方式操作的步骤是：

1. 识别用户意图，决定调用查询机票接口。

2. 提取用户指令中的出发地， 目的地，出发时间。

3. 将出发地， 目的地，出发时间填入查询接口的对应字段。

4. 提取出晚上九点以后的机票信息，返回给用户选择机票。

5. 收到用户的选择。

6. 调用订单提交接口，将机票信息，乘机人信息填入接口的对应字段。

7. 请求用户输入付款密码。

8. 将付款信息与订单信息提交给支付接口，并返回请求结果。

在这个过程中，模型完成了3次接口调用，这就要求现有系统能提供相对完善的接口，意味着有一定的接口改造工程。但是相比于模拟人类操作的方式，函数调用方式的准确率更高，比如业界标杆OpenAI的函数调用准确率大概是85%（数据来源：2024年8月数据伯克利大学Gorrilla项目中的函数调用排行榜），高于上一种方式的80%。

另外，Token消耗也会有数量级的降低。在订机票的这个例子中约为1.2万Token， 远低于上一种方法的40万Token数。

采用函数调用法订机票的Token消耗计算方法：
一个接口调用Token消耗 = （API 接口定义描述+自然语言指令） * （接口调用的错误次数+1）

最后，我把这两种方式对比来看。

其实，在过去十年的数字化转型过程中，很多企业、软件系统已经完成了前后端分离的微服务架构建设，也就是开放了相对完备的接口服务，这也为Agent通过函数调用方式接管数字世界提供了较好的基础。所以综合来看，函数调用的方式似乎更具潜力。

在我们的自助工单小助手中，也会使用第二种方式来实现。我们接下来的任务，就是理解自助工单小助手的内部实现逻辑。

自助工单小助手是怎么做事儿的？

我把这个过程放在下面这张图中，右侧绿色的是Agent需要在对话背后与接口做的交互，为了表述重点，我省略了某些细节步骤。

我们捋一下整个的任务流程。

1. 首先，客户反馈“充电桩坏了，需要报修”时， Agent会做意图识别，将问题路由到TicketCreateAPI。在TicketCreateAPI中，Agent会阅读TicketCreateAPI的接口定义，然后发现在这个接口中有几个必填字段。其中有些字段可以直接从用户信息获取，有一个字段是“故障信息”，它无法获得，于是据此生成了向客户咨询故障信息的问题。

2. 接下来，当用户反馈故障表现时，再进行一次意图识别，Agent要从充电桩维修知识库里搜索方案，然后发现这类问题需要师傅上门。

3. 之后Agent会思考（Think）：需要查看师傅的可用时间；于是开始行动（Act）：调用SearchAvailableTime接口，获取时间；接着观察到（Observation）：师傅周三、周四、周五有空；于是据此思考后生成回答，并向客户发出消息。细心的同学可能发现：咦？这不就是Re-Act的过程吗？ 没错，我们这里顺便就把上一个案例中的知识也回顾了一下。

4. 后面的步骤，我想你对照着图就能理解这个过程了，这里就不再用文字详述。

到这里，我们构建出了自助工单小助手这个产品的“期待模样”，Ta应该具备以下能力。

1. 准确的意图识别、Query重写和路由能力，这两项大家参考上一个案例即可。

2. 让Agent正确地思考：比如在第二步当Agent发现需要师傅上门时，怎么能让他思考到需要查询师傅的可用时间呢？ 我把这个过程称为workflow学习，这部分和Chat类Agent的实现方法是一致的。

3. 让Agent正确地行动：比如在调用SearchAvailableTime接口时，如何准确地将地址信息填入SearchAvailableTime接口的对应字段呢？这其实就是如何让function calling更准确，我把这个过程称为 function calling 学习，这部分是Act类Agent的必备能力，也是与Chat类Agent最大的不同。

别急，后面两个问题我们下两节课就来解决。

小结

这节课，我们初步认识了什么是Act类的Agent，从全球科技巨头的Demo中，我们可以确定地看到Agent 从Chat 走向Act的必然趋势。在这条路上，我们看到了人们同时在探索两条通往这个目标的路径，一个是模拟人类来操作数字世界，一个是调用与物理世界的接口。

在这两种路径中，采用函数调用的路径似乎更具潜力。但各位产品经理在未来的工作中，需要优先寻找那些已经具备完善的接口的“数字世界”，这里的启动更为容易，成本也会更低，Agent实现数字世界的接管的道路也会更加畅通。

但即便如此，我们看到业界标杆的正确率（90%）还有上升空间，甚至这个正确率在真实场景中可能会更低，那么，有没有什么方法能提高准确率呢？ 我们下节课继续！

课后题

下载蚂蚁金服的生活助手支小宝，让支小宝帮你做点“事”，测一测它执行得是否准确？

• 对于执行较好的指令，想想它背后到底调用了什么样的接口？

• 对于执行错误的指令，想想如何才能让它做得更好？

欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！

参考：

Mind2Web：https://osu-nlp-group.github.io/Mind2Web/

>>戳此加入课程交流群