阿里云服务领域Agent智能体从概念到落地的思考设计与实践
一、背景 2022年底，ChatGPT掀起了大模型的新浪潮，而基于大语言模型的Agent（智能体）更是被推到了聚光灯下。不少人甚至认为，Agent是通往AGI的一把钥匙，也是让大模型真正在各行各业落地的关键抓手。从那时起，基于大模型的Agent技术就进入了爆发式增长——越来越易用、越来越高效，未来很
一、背景
2022年底，ChatGPT掀起了大模型的新浪潮，而基于大语言模型的Agent（智能体）更是被推到了聚光灯下。不少人甚至认为，Agent是通往AGI的一把钥匙，也是让大模型真正在各行各业落地的关键抓手。从那时起，基于大模型的Agent技术就进入了爆发式增长——越来越易用、越来越高效，未来很可能成为AI应用层的基础范式。
在阿里云售后服务这个具体场景里，我们与通义实验室合作，基于通义千问基座模型训练并构建了阿里云服务领域大模型。用这个模型“升级”了阿里云对客售后服务机器人的底层算法，让它从传统的问答机器人变成了生成式对话机器人。这其中，有一个模块非常重要，而且会长期持续优化和发展——没错，就是Agent（智能体）。下面就来聊聊阿里云服务领域的Agent是怎么设计、怎么落地的，以及到目前为止取得的一些阶段性成果。
二、大模型落地的理想形态
传统的大模型问答机器人，本质还是靠纯文本对话来回复问题。这种形式更适合知识类和常识类的咨询场景，比如“中国的首都是哪里？”“明朝是哪一年建立的？”——问题和答案都是固定的，直接文本回答就行。就算用了RAG（检索增强生成），也只是给大模型注入最新的知识或常识，比如“最新一届世界杯的冠军是谁？”“刚发布的Sora模型是什么？”
但纯问答只是大模型落地的第一步。还有很多场景需要大模型跟现实世界“握手”——真正去连接、去操作。想象一下：你躺在家里的床上准备睡觉，突然发现窗帘没关上。你跟大模型说“帮我关一下窗帘”，你肯定不想听它念叨一大段“关闭窗帘的步骤”。你希望它能像人一样直接把事办了，那才叫酷。再进一步，你说“窗帘不用全关，留个缝”，如果大模型能理解，自动把“留个缝”这种自然语言转换成“闭合百分比”这样的量化参数，然后真的把窗帘关到合适位置——到那时，大模型在行业落地才会掀起真正的浪潮。
我们需要的不只是一个能聊天的机器人玩具，而是“有手有脚”、能干活的大模型。这才是理想形态。而Agent，正是通往这个理想形态的一把重要梯子——不是唯一的，但在当下这个时间点，绝对是最重要的技术手段之一。
图1：ChatGPT、通义千问等均推出了不同形态的Agent（智能体）能力
现在业界已经有很多公司推出了Agent产品。比如ChatGPT的Plugins功能，允许第三方把自己的接口接进来，通过对话就能购物、订餐、解读PDF、剪辑视频……通义千问等国产大模型的C端App里也有很多Agent能力：角色扮演对话、绘图、PDF问答等等。可以预见，更多有创意的功能会不断接入进来。随着规模扩大，Agent一定会成为大模型最重要、最不可或缺、也最能产生价值的能力。
三、从“解释”问题到“解决”问题
回到阿里云售后服务这个业务场景：为什么一定要引入Agent概念？先看看售后客服小二遇到客户问题时是怎么处理的。大致分几类：事实类问题、诊断类问题、模糊类问题、其他问题。其中诊断类问题最常见——客户的问题不是简单的事实性疑问，光靠业务经验和帮助文档解决不了，比如“ECS无法远程连接”“查询下备案进度”。这类问题的帮助文档里只有排查方案或通用流程，要想知道根本原因，必须去各种平台、工具上查，甚至要授权后登录客户的服务器。这些平台工具通常是产研提供的，也有售后团队基于一些API封装出来的。查完之后，才能结合小二的领域经验和帮助文档一步步解决问题。
就像第二部分举的那个例子：客户真正想要的是“打开窗帘”这个动作被执行，而不是收到一堆“打开窗帘的步骤”的文字。比如客户的问题是“退款”，他要的是执行退款操作，而不是看一堆规则和步骤——绝大多数人根本没耐心读大段文字。
我们当初决定走基于大模型的生成式对话机器人路线，而不是继续传统机器人，核心目标就是能够“拟人化”地去“解决问题”。相比传统机器人，大模型优势明显：更强的语义理解能力、更好的生成组织能力、还有思维链（Chain of Thought，CoT）能力，可以Step by Step思考。
从“拟人化”角度看，目前的服务领域大模型在识别和组织回复话术上，已经明显超过传统机器人里知识库匹配+精排模型的水平。在“解决问题”层面，大模型也能很好地完成FAQ式问答——这部分靠的是对通义千问大模型的Finetune训练加上RAG，让模型更懂阿里云业务、引入实时信息、降低幻觉。但针对大多数诊断类问题，大模型原本只有基本的多轮对话问答能力，没有真正的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的“大脑”，提供推理、规划等能力。整体架构如下：
图3：大模型Agent的组成结构（from OpenAI）
这个框架包含多个部分：规划（Planning）、记忆（Memory）、工具（Tools）、动作（Action）。分别来看：
- 规划（Planning）：主要包含子目标分解和反思与改进。子目标分解是把大型任务拆成更小、可管理的子目标，有效处理复杂任务；反思与改进是让Agent对过去的行动自我批评、自我反思，从错误中学习并改进后续步骤，提升最终质量。
- 记忆（Memory）：分短期记忆和长期记忆。短期记忆把所有的上下文学习（比如Prompt Engineering、In-Context Learning）都当成利用模型的短期记忆来学习；长期记忆则提供长期存储和召回信息的能力，通常通过外部向量存储和快速检索来实现。
- 工具（Tools）：Agent通过调用外部API，获取模型权重（预训练后很难修改）中缺少的额外信息，包括当前信息、代码执行能力、访问专有信息源等。
- 动作（Action）：根据上面的规划、记忆、工具，大模型决策出最终要执行的动作。
再参考ReAct Agent的流程来理解实际执行过程：一开始，LLM先思考（Thought），然后触发动作（Action）和输入（Action Input），接着执行并观察工具执行结果（Observation）。如果结果不满足需求，就回到思考阶段重新来；直到最后生成回答（Final Answer），整个过程就结束了。流程图如下：
图4：大模型Agent的整体流程（from ReAct Agent）
简单来说，Agent要实现的效果就是：让大模型结合问句（Query）、上下文（Context）和各种API（也就是各种Tools），自己规划在什么场景下调用哪些API来解决客户最关心的问题，然后根据API的返回结果决定怎么答复客户——也就是最后的动作。
五、服务领域Agent设计
除了有行业Agent设计框架参考，还一定要结合业务。那么，真正的小二到底是怎么解决复杂问题的？看下面这个真实工单的例子：
图5：阿里云售后工作台中小二解决问题的流程示例
第①轮：根据客户问题场景反问，获取执行退订需要的基本信息。
第②轮：根据查到的实例和订单状态，继续跟客户沟通确认，一步步解决问题。
把这个真实工单的流程拆解一下：
- 客户咨询问题：“企业邮箱退订”
- 客服小二首先回复：“请提供下需要申请退订的产品订单和退款原因”
- 客户回复具体订单号和原因
- 小二按“企业邮箱退订”的标准SOP流程处理：先根据订单号查询订单状态，确认是企业邮箱产品，然后根据SOP接口返回，发现该邮箱不支持自助退款，同时查到该实例最新的订单是“失效续订”状态，于是回复客户“是否需要退订这个未生效续费订单”
- 客户回复“是的”，确认是这个最新订单，之后小二按照后续操作联系相关专员……
从这个案例可以抽象出阿里云售后服务解决问题的经典步骤：“问题识别”→“查询SOP工具”→“反问客户、获取信息”→“根据信息查询工具”→“查询到工具执行结果”→“根据执行结果回复客户”→“客户继续沟通”→……→“解决问题”。
基于这个基本步骤，大模型要做的事情可以抽象成两大类：Planning（包括Action、Observation）和Generation（主要是Response）。其中Planning是一个多步工具调用的过程，会循环调用工具并观察返回结果，直到完成信息收集或工作操作——包括API正常调用、复杂问题拆解搜索、搜索结果不佳时重新搜索等。根据阿里云当前解决工单的主要步骤，可以抽象出大模型Agent的主要步骤，流程如下：
图6：阿里云服务领域Agent的整体设计流程
- Agent判断：根据用户问句判断当前场景是不是诊断类问题，是否需要进入Agent逻辑。
- 任务规划：这里又分几个细节步骤：
- API检索：先把与用户问题Query最相关的API接口前置检索和召回。
- API选择：用大模型读取当前Query和上下文Context，判断需要用哪些接口，以及规划调用顺序。
- 参数判断：判断要调用的API接口所需参数是否已经提供，如果没提供，就需要向用户“反问”获取信息。
- 参数组装：如果客户提供了完整参数信息，或者反问后拿到了缺失参数，就生成调用API所需的入参结构（比如JSON）。
- 动作执行：用上一步决策的动作进行执行——比如反问，或者调用API，拿到API返回结果。
- 生成回答：大模型根据API执行结果，组织成解决方案回复。
六、自动化、成本与可控性
从上面的流程分解能看到，Agent的执行步骤不少。特别是API规划部分可能涉及多步调用——比如某个API需要客户提供实例ID查询，但客户很可能不知道实例ID，只提供了一个IP地址。这时候就需要先调用根据IP查实例ID的接口，再通过实例ID查后续内容，前后要调用两个API。由于大模型生成速度相对较慢，整个过程下来客户要等很久才能收到回复。虽然更智能了，但更耗时，界面像是卡住了，客户体验反而不好。
再看行业里其他Agent落地案例，比如AutoGPT、AgentGPT。它们通常先分析任务，然后不断思考、添加任务来完成，中间涉及一些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这个开源项目。主要调用方式就是按照官方示例，组织一段API调用的Prompt，提供API的name、description、parameters。比如一个图像生成API，可以像下面这样组织，然后通过Qwen官方提供的Prompt构造函数组装起来传给模型，就能实现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能力。
根据用户Query的分布特点，在阿里云客服场景下，大部分客户的问题中缺失具体信息较多，很多问题都是“ECS连不上”“备案进度查询”这类简明的意图名称，很难一次性直接提取出必填参数。所以绝大多数场景都需要参数“反问”的能力，这就涉及多轮的Agent对话能力——在客户提供了相应信息后，Agent要能接得上之前的意图，并继续完成调用链路。除此之外，还需要增加不需要调用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主要调用的是“开箱即用”的工具API，但这些工具都是基于微应用开发的，开发成本和周期都比较高。如何让大模型Agent更准确地调度细粒度的API能力，降低工具的开发配置成本？如何结合思维树（ToT）、思维图（GoT）等方式进行Agent推理？这些都是未来的重点方向。
接下来，我们会继续基于服务领域大模型，持续优化和开发“精准、专业、拟人化”的智能化机器人，希望这个智能对话机器人和Agent能力能够不断提升、茁壮成长，解决越来越多的客户售后问题。本文只是我们团队在阿里云服务领域Agent的设计、实践和阶段性成果上的一次总结整理，欢迎大家多交流，互相学习，共同提高。