阿里妹导读

本文讲述了作者团队在阿里云的服务领域Agent是如何设计与实践的，以及到目前为止的一些阶段性成果，作者做出了总结和整理。

一、背景

以ChatGPT引领的大模型在2022年底开创了新的智能能力和对话交互形式，其中基于大语言模型的Agent（智能体）更是引起了广泛关注，甚至被许多人认为Agent打开了通往AGI的路径，是真正能让大模型在各种应用领域落地的重要技术。因此，基于大模型的Agent技术也迎来了前所未有的快速发展阶段，随着Agent变得越来越易用和高效，未来Agent有望成为AI应用层的基本场景。

在阿里云售后服务这个场景下，我们与通义实验室共同基于通义千问基座模型训练、构建了阿里云服务领域大模型，并通过这个模型“升级”了阿里云对客售后服务机器人的底层算法能力，从传统问答机器人转换成为了生成式对话机器人，其中，非常重要并且会长期持续优化、发展的一个模块就是Agent（智能体）。那么，本文就来讲述一下阿里云的服务领域Agent是如何设计与实践，以及到目前为止的一些阶段性成果。

二、大模型落地的理想形态

基于大模型的传统问答机器人，其基本逻辑还是通过纯文本对话形态来完成对问题的回复，这种对话形式更加适用于知识、常识等咨询类的场景，比如“中国的首都是哪里？”、“明朝是哪一年建立的？”等等，问题与回答都是已有的固定的知识，可以通过文本直接回答。即使是使用搜索增强RAG的情况下，也是为了给大模型注入最新的知识、常识，比如“最新一届世界杯的冠军是哪支球队？”、“刚发布的Sora模型是什么？”。但这种纯问答的场景只是大模型落地的第一步，还有许许多多场景是需要AI大模型与现实世界进行“连接”才能完成的。

试想一下，当你躺在家里的床上准备睡觉的时候，突然发现窗帘没有关上，如果这时候跟大模型说“请帮我关闭我家的窗帘”，其实我们并不想听到大模型回复了一大段的“关闭窗帘的步骤”，如果大模型真的像一个人一样能够完成这件事情，那该有多酷！甚至当你说出一些稍微复杂指令，比如“窗帘不用全部关上，给我留一个缝”，如果大模型也能“理解”并且能自动将“留一个缝”这种自然语言转换为控制“窗帘闭合百分比”这样的一个量化参数并且真正将窗帘关闭到合适位置的时候，那么大模型才真正能在各行各业的落地中带来一波大的浪潮。

我们并不需要一个只知道聊天的机器人“玩具”，我们需要的正是这种“有手有脚”的大模型、能做事情的大模型，这应该才是我们真正的所需要的大模型的理想形态。那么Agent正是我们通往这种理想形态的一个很重要的技术手段，肯定不是唯一的，但至少是当下这个时间点非常重要的一种技术手段。

图1 ChatGPT、通义千问等均推出了不同形态的Agent（智能体）能力

目前业界有许多公司都推出了相应的Agent产品，比如ChatGPT的Plugins功能，Plugins是支持第三方开发者将其接口接入到ChatGPT中，可以通过ChatGPT实现各种原生GPT无法实现的效果，比如通过对话就可以购物、订餐、解读PDF、剪辑视频等等。通义千问等国产大模型的C端APP中也有着许多Agent能力，比如角色扮演对话、绘图、PDF文档问答等等。相信更多新的、有创意的功能会不断的接入进来，随着规模的不断扩大，Agent未来一定会成为大模型最重要、最不可或缺、也最能产生价值的能力。

三、从“解释”问题到“解决”问题

回到阿里云的售后服务这个业务场景下，为什么一定要引入Agent的概念呢？

首先，我们先来看一下阿里云的售后客服小二在遇到客户问题的时候，是如何来解决的呢？主要分为这几种类型的情况：事实类问题、诊断类问题、模糊类问题、其他问题等。其中诊断类问题是客服小二最常遇到的情况，主要指的是客户的问题并不是一个简单的事实性问题，并不能仅通过业务经验和查询帮助文档就能解决的，比如“ECS无法远程连接”、“查询下备案进度”等等，这类问题帮助文档或者知识库中只会有一些相关的排查方案或者通用流程，想要知道客户问题的根本原因，必须要去各种平台、工具、甚至授权后登录到客户的服务器上进行查询，这些平台、工具通常都是产研提供的，也有部分是售后这边根据一些API封装出来适合于小二解决问题使用的。那么经过查询之后，才能知道客户真实云资源的状态、问题所在，之后再结合小二的领域经验和帮助文档一步一步地解决客户的问题。

就像第二部分中我举的例子一样，客户其实想要的是真正“打开窗帘”这个动作的执行，而不是大模型回复一堆“打开窗帘的步骤”的文字。比如客户的问题是“退款”，那么客户想要执行退款这个操作，而不是大模型提供一堆退款的规则和步骤，因为绝大多数的人对于很长的文字是很难完全有耐心能阅读下去的。

我们之所以建立基于大模型的生成式对话机器人，而不是继续原有传统机器人的路线，其最初目标是能够“拟人化”的去“解决问题”。与传统机器人相比，大模型的优势很明显，有更强的语义理解能力、更好的生成组织能力、有思维链（Cot，Chain of Thought）能力，可以Step by Step思考。那么，结合大模型的优势来看，大模型的“拟人化”能力做的还是不错的，目前的服务领域大模型的识别和组织回复话术能力是绝对高于传统机器人的知识库匹配精排模型能力的；在“解决问题”层面，大模型也能够比较好的完成一问一答的FAQ式问题的回复和解决，这些是基于对通义千问大模型的Finetune训练并结合搜索增强RAG的方式完成的，能让大模型上更加理解阿里云业务、引入实时知识和信息、降低幻觉比例。但是，针对于大多数的诊断类问题，通过大模型来解决，就是一个比较有挑战性的课题了，在Agent设计之前，大模型只有基本的多轮对话问答能力，没有真正的Step by Step解决问题的能力。

因此，仅仅有了大模型是不够的，更需要利用大模型强大的语义理解能力，让大模型从“解释”问题走到真正的能够“解决”问题，下图中将这两者进行了比较好的对比：

图2 “解释”问题 vs “解决问题”

四、Agent的设计框架

要设计Agent的框架，让大模型实现Step by Step的方式来解决问题，可以参考ChatGPT的Plugins功能，以及AutoGPT、AgentGPT等。OpenAI的研究主管Lilian Weng曾经写过一篇博客叫做《LLM Powered Autonomous Agents》，其中就很好的介绍了Agent的设计框架，她提出了“Agent = LLM + 规划 + 记忆 +工具使用”的基础架构，其中大模型LLM扮演了Agent的“大脑”，在这个系统中了提供推理、规划等能力[1]。整体架构图如下所示：

图3 大模型Agent的组成结构（from OpenAI）

Agent这个框架包含多个部分，分别是规划（Planning）、记忆（Memory）、工具（Tools）、动作（Action）等，分别介绍一下：

- 规划（Planning）：主要包括子目标分解、反思与改进。其中子目标分解主要指的是Agent可以将大型任务分解为较小，可管理的子目标，从而有效地处理复杂的任务；而反思和改进指的是Agent可以对过去的行动进行自我批评和自我反思，从错误中学习并改进未来的步骤，从而提高最终结果的质量。
- 记忆（Memory）：分为短期记忆和长期记忆。其中短期记忆是指的将所有的上下文学习（比如Prompt Engineering、In-Context Learning）都看成是利用模型的短期记忆来学习；而长期记忆为Agent提供了长期存储和召回信息的能力，它们通常通过利用外部的向量存储和快速检索来存储和召回信息。
- 工具（Tools）：Agent通过学会调用外部API来获取模型权重（通常在预训练后很难修改）中缺少的额外信息，包括当前信息，代码执行能力，访问专有信息源等。
- 动作（Action）：根据上述的规划、记忆、工具，大模型才能决策出最终需要执行的动作是什么。

我们再来参考ReAct Agent的流程来表述一下Agent的实际执行过程[2]，从Agent的最开始，LLM先思考（Thought），然后触发动作（Action）和输入（Action Input），之后执行并观察工具执行结果（Observation），如果观察的效果不满足需求，会重回到思考阶段，最后生成最终回答（Final Answer），到此，Agent的整体过程就结束了，具体如下面这张图所述：

图4 大模型Agent的整体流程（from ReAct Agent）

简而言之，Agent所需要实现出来的效果是：

- 能够让大模型可以结合问句（Query）、上下文（Context）、各种API，也就是各种Tools，大模型能够规划（Planning）在这样的场景下需要调用哪些API来解决客户当前最关心的问题。
- 大模型需要根据API的返回结果，来决策如何答复客户，也就是最后的动作（Action）。

五、服务领域Agent设计

除了有上述的行业Agent设计框架作为参考，还必须要结合业务，那么我们就来看一下真正的小二是如何解决复杂类问题的，以下图中的真实工单为例：

第①轮，根据客户问题场景进行反问，获取到需要执行退订所需的基本信息。

图5 阿里云售后工作台中小二解决问题的流程示例

第②轮，根据查询到的实例和订单状态，继续与客户沟通确认，从而一步步解决问题。

根据上图中的情况，这个真实实工单场景的流程分解如下：

- 客户咨询问题：“企业邮箱退订”
- 客服小二首先回复：“请提供下需要申请退订的产品订单和退款原因”
- 客户回复了具体的订单号和原因
- 这时候，小二开始按照“企业邮箱退订”的标准SOP流程进行处理，先根据用户的订单号查询订单状态，确认是企业邮箱产品，然后根据SOP的接口返回，可以看到该邮箱不支持自助退款，并且也能查这个实例最新的订单是“失效续订”的状态，跟客户进行回复“是否需要退订这个未生效续费订单”
- 客户回复“是的”，确认是这个最新订单，之后小二按照后续操作需要联系相关专员进行操作…

根据这个真实的人工客服小二解决问题的Case，我们可以去抽象一下阿里云售后服务解决问题的一个经典步骤基本上是：

“问题识别” -> “查询SOP工具” -> “反问客户、获取信息” -> “根据信息查询工具” -> “查询到工具执行结果” -> “根据执行结果来回复客户” -> “客户继续沟通” -> … -> “解决问题”

那么，基于上面抽象出来的这个基本的解决步骤，根据用户的问题，大模型要做的事情可以抽象为两大类：Planing（包括Action、Observation）、Generation（主要是Response）。其中，Planing过程是一个多步工具调用的过程，会进行循环调用工具并观察返回结果，直到完成信息收集或工作操作，期间包括API的正常调用、复杂问题拆解搜索、搜索结果不佳时重新搜索等。

根据阿里云目前解决工单方式的主要的步骤，可以抽象出大模型Agent的主要步骤，流程如下图所示：

图6 阿里云服务领域Agent的整体设计流程

Agent判断：根据用户问句判断当前场景是否是诊断类问题，是否需要进入Agent的逻辑；
任务规划：任务规划这里还分几个细节步骤，分别是：

1、API检索：先将与用户问题Query最相关的API接口进行前置检索和召回；

2、API选择：然后用大模型读取当前Query和上下文Context，来判断需要使用哪些接口，以及规划调用顺序；

3、参数判断：判断需要调用的API接口所需参数是否已经提供，如果未提供，需要向用户“反问”获取信息；

4、参数组装：如果客户提供了完整的参数信息，或者当反问客户之后拿到了缺失的参数信息，就生成调用该API所需的入参结构，如JSON结构；

动作执行：使用上一步决策的动作进行执行，比如反问，或者API执行，拿到API的返回结果；
生成回答：大模型根据API执行结果，组织成解决方案进行回复；

六、自动化、成本与可控性

通过上述的流程分解，可以看到，Agent的执行步骤还是比较多的，其中API规划这部分可能涉及到API的多步调用，比如某个API需要客户提供实例ID来进行查询，但是客户很有可能不知道实例ID，就提供了一个服务器的IP地址。这种情况就涉及需要先调用根据IP地址查询实例ID的接口，然后再通过实例ID查询后续内容，那么就要前后调用并执行两个API。由于大模型的生成速度相对比较慢，因此这个方案最后导致的结果就是客户需要等待很长的时间才会回复，虽然更智能，但是也更耗时，界面像是卡住一样，整体上来看客户体验是比较差的。

再来看下行业，也有许多的Agent落地，比较有名的如AutoGPT、AgentGPT等。通常情况下，Agent的逻辑是先对任务分析的，之后通过不断思考、添加任务等动作来完成，中间会涉及到一些API调用，比如搜索引擎或者某些任务相关的API等来完成。因此，完成一个任务所需要的时间耗时还是比较久的，甚至还有一些人出现Agent进入死循环的情况，即大模型思考、执行、观察之后发现结果不满足预期，重复进行思考、执行、观察，然后发现还是不满足预期，就进入了死循环的状态。

在实际业务落地的情况下，需要考虑几个因素：执行效果、整体耗时、大模型生成成本、API调用成本等等诸多因素，如果效果好，但是耗时太久，或者大模型的生成成本（token、qps）、API的调用成本（qps）等都太高，那么也未必有好的用户体验。因此，在实际落地的情况下，我们将Agent的流程进一步进行了优化，并在算法、工程、前端等多个方面进行了一定程度的适配和改造，从而才能做出在目前状态下的最佳体验效果，下面会进行详细的介绍。

首先，API的多步调用过程是最耗时的部分，因此我们的工具API尽可能的将场景端到端的进行了封装，做到每个场景的API都能“开箱即用”，比如“退款”的API可以支持实例ID、订单号等多种入参，“ECS无法连接”的API也支持实例ID、IP地址等多种入参，尽量避免出现客户提供一种入参的情况下还需调用另一种API去转换的情况，这样算法侧就可以减少多步调用的场景，从而优化耗时。

其次，API的执行过程有长有短，有些产品或者业务场景查询相对简单，因此可以快速返回相应结果，这样的情况下，大模型可以根据API的返回内容组装回复文本，但阿里云有着大量的场景是需要一定的时间才能诊断出结果的，尤其是ECS的诊断场景所需时间相对较长，因此等待API返回结果后再回复客户也会体验较差，因此这里进行了异步处理，通过微应用卡片方式从前端渲染给客户，从而让客户能够直接看到动态的执行进度条。

最后，通过构造高质量的训练数据集来对通义千问基座模型进行Finetune训练，让大模型在选择API、反问、提取入参、执行API的准确度上都尽可能的高，这样就也精简了大模型观察结果的过程，避免大模型的执行失败率，尽量做到一次执行就可以满足客户效果的体验。

七、Agent能力的训练与评估

在上面，我们对服务领域的Agent进行了框架设计，并结合自动化、成本、可控性等多个维度进行了权衡，那么想要让Agent能力真正的落地，还需要对服务领域大模型进行Agent相关能力的训练和评估。

通义千问基座模型是官方支持Agent工具调用能力的，详情可以看下Qwen Agent这个Github开源项目[3]，其主要调用方式就是按照官方提供的示例，组织一段API调用的Prompt，提供出API的name、description、parameters，比如一个图像生成的API，就可以用类似下方的形式去组织，然后通过Qwen官方提供的Prompt构造函数，将这些信息组装起来，传给Qwen模型，就可以实现Agent工具的自动调用效果了。

name = 'my_image_gen'description = 'AI painting (image generation) service, input text description, and return the image URL drawn based on text information.'parameters = [{    'name': 'prompt',    'type': 'string',    'description': 'Detailed description of the desired image content, in English',    'required': True}]

通义千问官方提供的Agent能力为我们服务领域大模型的Agent能力提供了很好的基础，但是毕竟我们的业务属性比较强，Qwen官方的Agent能力在具体业务上使用的时候，还是有一定的不足，因此，最终还是需要按照业务场景进行深度定制和微调训练，才能真正做出符合我们需求的领域Agent能力。

根据用户Query的分布特点，在阿里云客服场景下，大部分客户的问题中缺失具体信息的较多，很多问题都是“ECS连不上”、“备案进度查询”这类简明的意图名称，因此很难一次性直接提取出必填的参数信息，所以绝大多数的场景都需要参数“反问”的能力，那么涉及到反问澄清，就需要具备多轮的Agent对话能力，也就在客户提供了相应信息的情况下，Agent还能够接得上之前的意图，并且继续完成调用的链路，除此之外，还需要增加不需要调用API的情况，以及无参数提取等情况，让大模型能够知道在什么场景下要调用什么API、调用的动作、参数的提取、API的执行情况等等。整体的训练流程图如下所示：

图7 阿里云售后服务领域Agent的训练、评估和应用能力

在训练完成后，我们也构建了一个服务领域的Agent benchmark评测集，用于对比不同模型的Agent能力情况，这个benchmark中有多个维度的评估，包括API选择准确率、动作执行（反问、直接调用、拒识等）准确率、入参抽取准确率、端到端成功率、生成文案的BLEU和Rouge-L等指标，最终需要经过各维度的权衡决策哪版本模型作为线上模型。

八、Agent实际落地效果

前面讲了一大堆，最终还是得给大家看一下阿里云服务领域Agent在实际真实业务上的运行效果：

① 直接触发Agent场景：能够准确提取出客户的个性化信息，如实例ID，并且根据API的返回结果生成回复文案，并在下方提供执行卡片，用户可在卡片中直接进行操作；

图8 用户问句直接触发Agent的执行效果

② Agent反问与澄清：当客户没有提供API入参所必须的入参的时候，大模型会进行反问，客户可以在对话框中直接输入具体参数，下一轮可以通过多轮对话继续触发Agent执行，当然，为了更好的客户体验，我们也在第一轮的卡片中提供了参数选择能力。

图9 用户问句触发Agent反问并回复后的执行效果

③ Agent异步卡片渲染：当遇到ECS诊断等复杂场景的时候，API的执行时间耗时较长，通过异步卡片渲染的方式可以实时显示诊断的进度条、状态等，让客户等待的过程体验也更好。

图10 Agent中异步卡片渲染的效果

上述三种Case是我们Agent版本的落地效果中比较典型的情况，我们目前已经上线近Top30的头部场景，通过大模型自动根据用户的需求，调度不同的Agent诊断工具的API和卡片，可以更加高效的解决客户的问题。经过统计，Agent的解决方案相比传统的文本类的生成式答案要高出10%+的自助解决率。

九、总结

Agent是目前大模型行业蓬勃发展的全新方向，行业的产品和技术设计也都在早期初级阶段，我们团队也是服务客户这条路上不断“摸着石头过河”，后续还可以在Agent方向进行更多进行探索，比如目前Agent主要是调用了“开箱即用”的工具API，但是这些工具都是基于微应用开发的，开发成本和周期还是比较高的，因此如何让大模型Agent能更准确的调度细粒度的API能力，降低工具的开发配置成本，以及如何结合思维树（ToT）、思维图（GoT）等方式进行Agent推理，也都是后续的重点方向。未来我们也将继续基于服务领域大模型持续优化和开发“精准、专业、拟人化”的智能化机器人，也希望我们这个智能对话机器人和Agent能力，能够不断提升、茁壮成长，能够解决越来越多的客户售后问题。

本文也仅仅是我们团队在阿里云的服务领域Agent的设计与实践和到目前为止的一些阶段性成果进行了总结和整理，欢迎大家多交流，互相学习，共同提高！