云服务器添加域名从领域知识到自主智能，智能体Agent驱动下的阿里云服务新范式

阿里云服务器连接超时

导读今天我将分享的主题是《云小二 Aivis：揭秘智能体 Agent 驱动下的阿里云服务新范式》。云小二 Aivis是阿里云售后服务中的数字员工，其职责是在真人技术专家的监督下，协同为客户提供售后客服服务。

今天的分享将围绕我们在构建 Aivis 过程中所积累的实践经验展开，分为五个部分：

1. 为何要构建 Aivis

2. Aivis 的整体架构

3. Aivis 核心模块最佳实践

4. 总结与展望

5. Q&A

分享嘉宾｜谢睿 阿里云 高级经理

编辑整理｜曾凤

内容校对｜郭慧敏

出品社区｜DataFun

01

为何要构建 Aivis

首先，介绍一下阿里云售后服务的背景。阿里云作为云服务厂商，提供涵盖服务器、存储、AI 等全方位的云产品。阿里云服务团队的职责是为客户提供专业、高效的云产品售后支持。客户在遇到问题时，可通过在线聊天、电话、工单等方式联系我们的技术专家。

然而，这种依赖人工专家的服务模式面临多重挑战：

技术深度与广度：云产品本身专业性强、技术垂直，要求专家具备扎实的技术背景。同时，阿里云产品种类繁多、技术复杂，覆盖计算、存储等多个领域，专家通常只能精通部分产品，需要按照技能栈分组。系统与工具复杂：我们目前有约 1000 种服务工具，服务场景达 10 万级别，相关文档达百万级，历史工单达千万级，服务客户超过 500 万。这样庞大的体系需要大量技术专家支持。此外，工具分散在不同系统中，开发生态不统一，工具粒度不一致，导致解决一个问题常需跨系统、多工具协同。问题多样性与模糊性：客户问题包括技术性问题与咨询类问题。技术问题可能与其他云厂商类似，具有一定通用性；而咨询问题如发票开具、退款流程等，则与阿里云自身业务设计紧密相关，具有强领域特异性，通用大模型难以覆盖。此外，许多客户缺乏专业背景，提问时表述模糊，进一步加大了理解与处理的难度。

这些挑战导致服务响应时间长、质量难保障，专家工作负荷重。因此，我们亟需突破人力天花板，探索新的服务模式，核心目标是在服务场景中实现人员提效。

阿里云售后服务场景的演进大致分为三个阶段：

第一阶段（2018–2022 年）：BERT 时代

以理解为驱动，产品形态主要为 ChatBot，人机协同关系为客户提问—机器人回答。

第二阶段（2023 年起）：GPT 时代

大模型兴起，进入以生成为驱动的智能辅助阶段，人机关系演进为伙伴模式，专家在前端回答问题，Copilot 协助问题理解与内容提取，效率有所提升，但仍需人工主导与决策。

第三阶段（2024 年至今）：Agent 时代

智能体技术迅速发展，进入以行动驱动的 Agent 时代。人机协同关系转变为以智能体为主、人工简单监督，从而实现极致提效。此时的智能体不仅具备理解与生成能力，更能自主规划、执行与决策，标志着服务模式从被动响应向主动智能转变。

在当前阶段我们投入建设 Aivis，主要基于以下几方面的考虑：

首先，随着大模型时代的到来，客户对我们的服务期望不断提升。Agent 与 RAG 等技术的快速发展，使得用户不再满足于传统僵化的一问一答式客服，而是期待一个更具智能、更人性化、能够真正解决问题的服务形态。

另一方面，客户对智能体提出了更高要求，希望它能够像人类专家一样实际解决问题。这具体体现在两个方面：一是沟通能力上，需要具备多轮对话的能力，能够像人一样进行问题澄清、追问和确认，并在对话过程中保持记忆，逐步引导用户。这与传统问答模式存在本质区别。另一方面，客户不希望智能体仅提供宽泛或表面的解决方案。例如，以往当客户遇到问题时，我们可能只是罗列原因，让客户自行分析，这实际上是将解决问题的责任推给了客户。而在 Agent 模式下，客户期望的是系统能够主动诊断问题，调用相关工具或 API，获取实际解决状态，真正为其解决问题。

这就要求我们的 Agent 具备强大的综合能力：一方面，需要支持多模态输入（如图片、文档等）与多模态输出（如文本答案、图像说明等），并能够链接不同工具与 API，自主决策形成标准化操作流程（SOP）式的解决方案；另一方面，也要求 Agent 具备更强的灵活性与温度，为客户提供更加个性化的服务体验。

Aivis，其命名来源于 AI 与 service 的组合。Aivis 是阿里云组织架构中的正式数字员工，拥有工号与部门，岗位为 AI 岗，核心职责包括：

精准识别客户意图，生成流畅答案；高效检索知识，举一反三；基于预设业务流程，自主、跨系统执行自动化任务。

Aivis 不仅是问答机器人，更是具备深度专业知识、自主行动能力、人机协同能力的数字技术专家。

香港云服务器怎么样

在服务链路中，Aivis 的定位非常清晰：客户提问后，首先由对客机器人处理简单问题；复杂问题则通过智能调度转接至技术专家。Aivis 并不直接对客，而是与人工专家协同工作，主要负责重复性、流程化任务，人工专家进行简单监督。这一设计既缓解了客户对纯机器人服务的不耐心问题，也显著提升了专家工作效率，解决了人力瓶颈问题。

02

Aivis 的整体架构

为打造 Aivis，我们从四个层面进行能力构建：

感知层：决定 Aivis 能看到和听到什么，支持多模态输入，全面理解客户意图与问题。认知层：构建阿里云专属的知识大脑，将领域知识融入通用模型，包括高级数据加工与模型内化（训练与强化学习）。自主推理引擎：将不同粒度的工具与 API 像积木一样，通过自主推理组合成智能解决方案。工具平台：集成各类 Tools，并通过 Coding 大模型降低新工具与 SOP 的开发门槛，快速扩展 Aivis 能力边界。

系统架构分为四层：

数据能力层：统一加工产品文档、知识库、历史工单等数据。模型能力层：在通用模型基础上，构建服务领域大模型与场景专用小模型，通过意图理解、搜索增强、提示词工程、后训练与强化学习，将数据转化为智能。平台能力层：包括服务规划、推理、工具集、记忆管理、服务评测等。服务形态层：将能力以对话机器人、Copilot、服务洞察、产品体验分析等形式输出给用户，其中数字员工 Aivis 是重要载体。

此外还设有人机协同机制与领域评测体系，保障系统高效运行与持续迭代。

03

Aivis 核心模块最佳实践

Aivis 的智能并非单一模型能力，而是数据、模型与 Agent 机制三位一体的系统性突破。

1. Agent 机制：多智能体协同

Aivis 是一个垂直领域、自主决策的多智能体协同系统。最顶层的这个 agent 其实是它是所有模块的一个抽象，所有的模块其实都是 agent 的一个实例化。在具体的系统设置上，我们设计了三层结构：

Planner：接收客户 Query，将复杂任务分解为可执行的子任务，规划执行路径并路由至对应 Reasoner。Reasoner：系统大脑，负责逻辑推理与决策，根据上下文决定下一步行动，并指令 Executor 执行。Executor：系统手脚，负责调用具体工具。

我们目前已支持多种工具 Agent，如 Function Code Agent、RAG Agent、巡检与故障处理 Agent 等。这种多智能体协同模式使 Aivis 能像专家团队一样各司其职，高效处理复杂问题，实现从单智能体到多智能体的跨越。

我们设计了统一的 Agent 结构，包含以下核心组件：

Memory：维护用户信息、工单记录、交互历史等；Context Manager：对记忆进行汇总与管理；LM（大语言模型）：基于上下文、Agent 目标与角色定义进行思考与决策；Action Space：定义模型可执行操作，如发送消息、调用工具等。

这种统一设计使我们能快速构建承担不同角色智能体，提升系统可扩展性与维护性。

2. 数据层面：场景体系化构建

我们对海量历史工单进行分析，通过大模型自动化与人工结合的方式，对完整工单对话进行意图切分与升级，并打上多维度标签。

国外访问阿里云服务器

我们构建了三维分类体系：

复杂度：简单问题 vs. 复杂问题热度：低频问题 vs. 高频问题场景类型：诊断类、操作类、咨询类

不同类别问题对应不同的自动化程度。通过这一体系，阿里云所有问题被转化为可结构化、可评估、可训练的场景体系，为后续解决方案与训练奠定基础。

3. 专家经验的内化与外化

将专家经验通过 Context Engineering 注入模型，使其具备垂直领域知识，主要包括两类经验：

业务型策略经验：资深专家在特定场景下的领域词汇、注意事项等文本经验；流程性经验：如具体问题的诊断步骤，可转化为可执行的流程图，使 Agent 不仅理解是什么，更掌握怎么做。

该机制支持动态更新业务知识，无需频繁训练大模型，并将专家脑中的隐性知识转化为机器可理解的显性知识，实现知识自动化与规模化。

除了专家贡献，还从历史工单中挖掘经验：

对工单进行切分，将用户交互抽象为客户行为客服行为环境状态三类；捕捉行为间的关联与因果关系；对行为进行标签聚合、动作分布聚合、工具聚合等。

通过这一过程，我们将海量杂乱的历史问题与解决方案转化为可理解、可执行业务经验，这是 Aivis 能像专家一样行动与推理的重要原因。

这是一个来自系统的实际案例。如图所示，针对具体工单的对话记录，我们能够从中提取出客户提供的关键信息及其对应的动作类型，并分析不同动作之间的逻辑关联。例如，当客户提出一个模糊问题时，客服的典型反应是进行澄清，引导客户进一步描述问题细节。通过这种细粒度的时间线挖掘，我们可以将专家解决问题的完整思维过程，拆解为一系列原子化的关键动作节点，进而将这些关键动作串联成链，沉淀为宝贵的经验知识库。

这其中体现了一个核心理念：我们需要依托平台能力，让一线客服人员深度参与到整个流程中。通过上图对比，可以清晰看到传统业务经验挖掘模式与基于 Agent 的新模式之间的差异。左侧展示的传统模式以流程为中心，主要由研发人员定义服务软件的功能框架。这种模式下通常采用预设的工作流，一旦上线便难以快速迭代优化。而右侧的 Agent 模式则实现了根本性转变。现在，更多一线客服可以直接参与其中，整个体系转向以结果为导向。这些一线人员既负责处理实际工单，又能够自主总结业务经验，并动态地将这些经验反馈到系统和模型中。这意味着专家不再被动使用工具，而是可以直接通过平台，借助大模型的能力，自主构建、编排并发布新的服务流程。

这是我们挖掘工具的一个具体应用实例。如图所示，界面左侧展示了对历史问题的分析与统计数据，右侧则通过聚类分析挖掘出初步的解决方案，包括处理问题的通用流程和关键节点。该工具不仅能从海量历史数据中提取经验性知识，还能将处理问题的完整流程以流程图的形式可视化呈现。通过采用不同的分析模型，系统能够自动挖掘出解决问题的动态流程路径，最终只需经由人工专家确认，即可形成可靠的处理方案。

4. 模型训练：领域模型的重要性

我们通过 Prompt Engineering 或 Context Engineering 将领域知识外化注入模型。但这是否足够？我们通过两类任务分析：

正向推理：给定问题，模型推理下一步客服的 Action 与内容；证据验证：给定问题与标准答案，模型判断其是否支持该结论。

实验发现，通用模型在正向推理中准确率仅约 10%，而在验证任务中可达 70%–80%。这说明在复杂垂类场景中，通用模型难以直接做出正确决策，更擅长判断与验证。

因此，我们仍需训练垂直领域模型，将人工专家行为与通用模型对齐，包括回复内容、风格、思维路径与决策类型。训练过程包括：

数据源：整合阿里云全量数据，挖掘多轮对话数据与多步任务轨迹数据；数据清洗：确保训练数据分布与实际一致，防止过拟合；课程学习策略：使模型掌握不同场景的解决方案；训练策略：可验证任务：监督微调 + 强化学习 + Reward 模型；难验证任务：SFT + DPO，直接学习人工专家偏好。

训练效果显示，SFT 可提升模型的领域能力，但更大突破来自强化学习。经训练后，模型在各领域指标上相比通用模型有显著提升。我们认为，即便通用模型能力强大，在特定垂直领域中，仍需训练领域模型以应对专业挑战。

5. 自主推理与场景策略

Agent 有两种形式：Workflow（流程固定）与 Agentic Reasoner（自主推理）。Workflow 可控但僵化，类似 if-else 按步执行；Agentic Reasoner 灵活、适应性强，能根据上下文动态决定行动。Aivis 采用自主推理模式，以应对多变、模糊的需求。

我们以 ECS 无法连接为例，说明自主推理的价值：多个相关场景共享大量子节点，若每个场景单独设计 Workflow，将导致大量重复工作。我们将这些节点拆分为原子模块，由模型动态组合，事半功倍地扩展场景。

基于此，我们制定策略：

头部场景（工单量高、ROI 高）：以专家流程设计为主，动态 Workflow 为辅，追求高稳定性；中部与长尾场景：将头部场景拆解为子模块与插件，由模型自主构造动态 Workflow。

在我方场景中，约 30% 为高频场景，70% 以上工单依赖 Aivis 的自主推理能力。

6. 信任度提升与人机协同

最后分享我们在 Aivis 的建设过程中为提效总结的其他一些实践经验。

为提高客户对数字员工的信任，我们采取以下措施：

过程可视化：在调用网页或接口时，通过截图、状态渲染图片、动图或视频等形式，向客户展示操作过程；思考过程可视化：将数字员工的思考过程可视化展示，提升透明度。

在人机协同方面，目前 Aivis 约能处理 30%–50% 的流程自动化，其余仍需人工介入，例如：

需人工审批的流程（如退款）；依赖第三方网站的查询；弹性业务规则等难以代码化的场景。

我们设计了人指导机器的协作模式：当智能体无法自主处理时，将任务转交人工专家，待专家完成后，智能体继续后续流程。通过这种方式，我们以少量人机协同显著提升整体解决率。

04

总结与展望

经过一年建设，我们总结了以下经验，供同行参考：

数据驱动：不依赖单一模型，而是通过高级数据加工、深度挖掘与结构化，构建高质量领域知识库，并通过内化与外化注入模型。专家经验沉淀，广泛参与：将业务流程构建从技术人员下放至一线专家，实现研发驱动向专家广泛参与的范式转变。领域外/内化：通过外化与领域模型训练，使模型既快速适应，又保持专业性。提高信任度：通过拟人化方案与流程小创新，持续提升对数字员工的信任。人机协同，不断反馈：在产品与流程中设计人参与、人指导的机制，形成反馈闭环，共同解决客户问题。

落地路径建议分为三步：

第一步：选择高价值、高频次、低复杂度场景，验证方案可行性，解决无争议痛点；第二步：将成果融入全流程，建立与业务专家的信任，嵌入 Aivis 实现人机协同飞轮，让专家从使用 AI转变为参与教导；第三步：大规模推广与复制，定位数字员工作为人工的辅助伙伴。这一从点到面、从局部到全局的演进路径，不仅适用于阿里云售后服务，也对其他服务场景具有借鉴意义。

05

Q&A

Q1：从业务层面，您如何评估 Aivis 系统？具体从哪些维度和指标衡量其效果？

A1：我们最核心的北极星指标是独立解决工单占比。虽然是人机协同，但多数情况下人工专家仅需监督数字员工输出的答案是否正确。若一通工单有 10 轮对话，全部由数字员工完成，则视为独立解决。我们关注两个主要指标：

独立解决率：严格口径下，完全由数字员工解决的工单比例；采纳率：所有对话中由数字员工发送的比例。

此外，技术指标还包括 Action 准确率、工具调用准确率等。

Q2：系统已迭代一年有余，后续如何持续优化？从问题发现、归因到模型迭代，整个闭环是如何运行的？

A2：我们以指标驱动，分析哪些工单未被数字员工解决。所有工单最终均由人工或数字员工解决，未被数字解决的即为训练样本。系统会记录专家的每一步操作（如访问工具、澄清问题、回复方案等），通过对比数字员工与人工专家行为的差异，形成数据闭环，驱动数字员工向人工专家对齐。

Q3：从技术角度，用户问题范围广泛，系统如何对问题进行归类？具体如何实现？

A3：我们建立了三维分类体系：复杂度（简单/复杂）、热度（低频/高频）、场景类型（诊断/操作/咨询）。所有问题都会落在此体系内，如高频复杂诊断类问题。不同类型问题对应不同解法：

诊断类：使用诊断工具（错误码、状态码等）；操作类：依赖 How-to 流程经验；咨询类：通过 Agentic RAG、文档搜索、业务经验检索等方式处理。

我们在初始阶段就建立了这一问题分类框架。

以上就是本次分享的内容，谢谢大家。

搭建私有云 服务器