阿里云客服 Agent 业务提效实践：灵活可控的落地方法论

随着 AI Agent 技术的快速发展，业界许多企业开始在 Agent 方向进行深层次探索，而不仅仅是停留在“大模型 + 工具调用”的简单应用上。在 AICon 2025 上海站上，来自阿里云的算法专家姜剑（飞樰）发表题为《阿里云客户服务领域 Agent 在业务提效上的思考与创新实践》的演讲，介绍了“阿里云服务领域 Agent 平台”，以及阿里云基于 Agent 快速赋能业务提效的方法论。

Agent 的技术本质与常见模式

Agent 这个词现在非常火热，在 AICon 的各大分论坛有很多人在提 Agent 和智能体。其实把 Agent 翻译成智能体是比较好的，将它的自主决策能力刻画了出来。

但实际上如果去查一下这个词在词典里面的原始含义，它更想表达的是一种代理或代理人的意思。所以将 Agent 技术总结成一句话，就是用大模型来代理或模拟人的行为，使用某些工具来完成某个任务的能力，它就叫 Agent。

Agent 的运作模式是从我们的环境里感知用户的问题、用户的任务要求，然后输入到它的大脑里。它的大脑里就是大模型，有自己的知识储备，或者使用你提供的一些外部工具或 RAG 的知识储备，从而做决策和推理，最终产出一些 Action，这些动作又返回来作用到我们的环境中，给客户回复或者解决各种任务。

当前 Agent 领域可谓百花齐放，我们将它大致分为两类。一类大模型自主规划的，更加整体的一种模式。另外一类就是 Workflow 预编排类。

大模型自主规划类的典型代表就是前段时间非常火的 manus，你给它问题或需求，它帮你自动做规划，拆解执行，然后观察反思，再进行下一步的规划分解，直到最后把任务完成，将结论反馈给客户。

这种模式的好处是它有非常高度的灵活性，可以动态适应环境的变化，而且容错率较高，一旦出现问题它会自我纠正。你也可以查看它的结果，但它的可控性会比较低，因为很多时候它其实有自己的一套逻辑思维在运作，所以很多时候我们想干预它反而并不那么容易。

这种 Agent 适用于探索类、复杂类的问题，就是说我自己也不知道这个问题怎么解决的情况下，你先给我搞一版，这种情况就非常适合大模型自主规划类的 Agent。

但我们 ToB 领域在落地的时候有非常多的可控性要求，就是我要求它必须按照我的要求一步一步来完成，这种情况就非常适合用 Workflow 的预编排类 Agent。它的灵活性相对低一些，因为它需要我们预定义流程。但它的可控性就会高很多，因为它的每一步执行都是非常清晰可见的。

所以它非常适合标准化场景、重复的重要任务、周期性任务。这一类的典型有我们阿里云的百炼，还有像 LangGraph 这样通过预编排流程来实现的 Agent。

在 Agent 模式的基础上，我们也有非常多的 Multi-Agent 多智能体的体系。这类体系常见的有转交模式，A 执行完给 B，B 执行完给 C。有嵌套模式，A 调 B，B 调 C，然后 C 再逐步回溯到 B，再回溯到 A，实际上像堆栈的运行状态一样是嵌套式的。

另外还有主代理模式，也可以叫做监管者模式或 Supervisor 模式，它通过主 Agent 跟客户交流，主 Agent 在背后会根据需求去调用各种子 Agent 完成任务。最后一种就是群聊模式，比如说我的任务扔到群里，群有很多 Agent 讨论或者争论，最后给我结论或组合的方式来回复我。

当然还有很多类型，这边就不一一列举，但总结成一句话就是让多个 Agent 来代理或模拟一群人的行为，每个 Agent 各司其职完成任务，多个任务协同起来去完成复杂任务。

Agent 给客户服务领域带来的价值增益

Agent 这种技术能够给我们客服领域带来哪些价值？第一点，也是我认为非常重要的价值，就是说 Agent 的技术是能够改变我们的需求研发范式。

首先我们看一下传统的研发逻辑是什么样子的。我们的客服领域有很多业务或客服同学，他们会有很多需求，需求提过来后，我们需要专门的产品研发人员投入进来，排期去给他们开发任务，开发完后我们还要交付，过程中有问题还要再回溯，重新调整返工，再继续迭代优化。

整个这一轮走下来大概也有几周或者上月的时间。主要的问题在于懂业务的同学不懂技术，懂技术的同学不懂业务，所以业务同技术之间反复沟通，确保我们的思路是一致的，然后才能把问题解决掉。在 AI 时代或者 Agent 时代，其实就可以发生一些变化。

我们的一种理想状态是说开发人员负责开发模块化或原子化的 API，把它包装成现在最火的 MCP Server 给业务同学，业务与客服同学只需要选择他们需要用的工具，然后按照需求和业务流程，通过 Prompt 或 Workflow 组装成 Agent，就可以为他自己所用。

也就是说如果我们让业务同学掌握了低成本构造 Agent 的技术，实际上业务跟技术就融为一体了，他们就可以去研发自己想要的一些工具，来实现一些个性化的 Agent，这是第一个优势。

第二个优势是 Agent 可以简化业务的复杂流程。做 ToB 时，很多业务的 Workflow 非常复杂，流程编排起来错综复杂。一个简单的例子，比如说我调用 API Tools，原来我在调度 Tools 之前和之后，都要做非常多的预处理和后处理，比如你的参数要求是这种类型的输入结构，我必须要把我的参数转换成你这种结构，然后去调你，然后你输出结果我还要做解析转换，然后再执行下一步。

但大模型天然有一种能力，它可以根据你的 API 的 Schema 来自动唤起 API，它可以把输入和输出转换成这个 API 真正需要的，然后把 API 返回的结果转换成你真正需要的，这个过程就简化了很多。

这样的场景其实非常多，在我们的业务流转过程中，这种参数的转换、传递、变换是非常占据我们的编排时间的，通过 Agent 可以缓解这样的问题。

第三个优势，Agent 的交互也是非常多样性的。虽然 Agent 是基于大模型，一提到大模型就会感觉像 App 一样一定是一种文本的交互，但实际上现在有非常多的 Agent 已经走向了基于 GUI 的方式。

比如像这个图里是微软的案例，它是供应商的 Agent。如果我们通过纯文本的形式去展示 Agent 里的信息，我们会看到很多文字，哪怕你再结构化，看起来也很费劲，我要第一眼看到重点内容其实是不太容易的。

但如果把它可视化出来变成图表，我就可以一眼看到哪一块供应商、供应链出了问题，哪块出现了延误，就能第一时间提醒出来。从交互层面来讲，它已经脱离了原来的单纯的 LUI 的模式，走向了 GUI。

阿里云服务领域的业务背景与挑战

那么我们阿里云的客服领域有哪些背景和挑战？

云领域的客服模式其实大同小异。我们也是前面有个智能问答，当客户有问题时先来和机器人交互，机器人如果能解决你的问题，那就非常高效。如果机器人解决不了，我们可以用人工服务，我们人工服务会自动根据用户的问题识别它对应的最优技能组。

在客服同学解决的过程中，他旁边也有实时的 Copilot 大模型来做实时辅助，提高解决问题的效率，这是我们的基本模式。

我们阿里云这边用户的问题有哪些特性？第一个特性，也是非常重要的特性，就是阿里云这边的产品有几十个产品线，几百款产品，产品维度很复杂。

然后像 ECS 这样的头部产品下面还有非常多子类型的服务器，像 PAI 或百炼上也有大量不同的模型型号。总体来讲，我们产品的复杂性导致了我们解决用户问题时的难度飙升。这是第一个维度。

第二个特性是用户的问题维度。我们云计算领域的问题属性同传统的客服领域或电商领域有很大差别。我们除了咨询类问题，还有很多技术类问题。所谓咨询类问题，就是比如我要查个订单，要续个费，要查一下某某产品支持哪些功能，这种咨询问题在电商领域非常常见。

但在云领域，我们还有非常多的问题是技术类的，比如说我服务器端口不通，某个 API 调用报错，或者我的某个域名解析过程中出现了什么问题，这种就需要深入到服务器里，深入到你的产品里去深入排查，这些问题通过完全自动化的 AI 方式很难解决，也就是客服机器人的解决率不是很高，很多都到了人工环节，这是我们问题特性的原因导致的。

第三个特性就是意图表达维度。很多时候用户问题的描述不一定是清晰的，可能很难问得清楚到底这个问题的本质是什么。也可能有的客户的问题非常复杂，他会把一大堆报错 Log，或大量的前因后果都扔过来，其实都是一些影响我们识别或者技术判断的因素。

所以总结来说我们有三个痛点，第一个痛点就是云领域的计算技术复杂性确实非常高，场景复杂，诊断也复杂。基于大量产品线和产品的情况，我们就要有大量诊断工具来诊断，因为你说你的服务器出问题了，端口有问题，我就只能登录你的服务器去看到底端口是怎么配置的，你的安全组是怎么配置的，你的防火墙是怎么拦截的，所以我们要出大量的工具去诊断这些东西。

这就带来第二个痛点，就是我们的研发效率也比较低，这些工序都要人开发，然后我们产品又多，所以只能顾头不顾尾。头部产品我们覆盖了很多工具，但中长尾产品又缺失一些信息，导致我们的客服同学只能用最原始的方式排查。

第三个通点，语音这个领域还有一个比较特殊的点，就是个性化流程很多，它不像其它服务领域，有个 SOP 下来一步一步执行就 OK 了。语音这个场景有点像我们的客服又称为技术工程师一样，它其实也是一种工程师，所以它就和我们写代码一样，需求提过来后，我写的和你写的代码很难讲谁写的一定好或不好，但只要解决这个问题它就是好的代码。

我们解决问题的过程也是一样的，就是客服在服务的过程中，诊断过程因人而异，不一定是谁对谁错，有一定个性化因素，这就导致我们的研发工序更困难了。

我们调研的时候会发现 A 客服会反馈，说我一般这样排查，然后 B 客服说我一般那样排查，我们的管理人员、督导同学又有另外的想法，所以最后在收敛需求过程中非常困难。我们很多客服同学的领域知识是沉淀在知识库里，或者文档里，其实这些文档在传播知识的过程中是有很多损失的。

我写的文档你可能看懂了百分之五六十，然后他可能看懂了百分之三四十，中间有很多信息就丢掉了，导致我们的客服同学的培训成本就非常高。

Agent 技术就能解决里面大部分的痛点。首先 Agent 能带来整个研发范式的变革，所以开发同学只需要关注核心 API 工具的开发，然后业务同学进来就可以根据需求来自主构建。Agent 来帮助我们分散研发成本。

另外我们也可以根据自己的喜好构建个性化的 Agent。比如说我习惯某种流程，我就把我这个流程写成 Agent 来赋能我自己。我经常以这种风格或者回复方式去回复客户，我可以把我话术的风格或者回复方式写成 Agent，然后大模型按照我的方式去回复。

Agent 也可以沉淀领域经验，我们既可以把 Prompt、Workflow 共享给别人，还可以运行别人的 Agent，得到别人的处理流程。

阿里云服务领域 Agent 的设计方法论

所以说我们就开始投入到 Agent 的构建，我们的客服和业务同学开始大规模写 Agent。但在写 Agent 的过程中我们发现了非常多的问题，可以总结成四大类。

第一个问题是运行效果。提示词并不是很好写，有的提示词写出来像小作文一样非常长，非常复杂，它有一定门槛，并不是那么简单写得出来的。写完之后，提示词在运行过程中有可能会不稳定，你要去调优它，就导致 Agent 不稳定，这也是最痛的一点。

第二个痛点，我们有两种类型的 Agent，分别是大模型整体驱动和 Workflow 预编排的类型。前者的模式是非常不可控的，我可能预期是这样子运行，但它自己规划后变成了另外的方向，完全走偏，这是很有可能的。

但 Workflow 的方式又要去编排，可能非常低效，可能一些客服同学要好几天才能搞出 Workflow，怎样规划平衡的问题也是痛点。

第三个挑战就是领域知识怎么注入。因为大家用的很多模型都是通用模型，怎样把领域知识注入进来，是非常痛的点。

第四点就是 Agent 的响应速度问题。大参数的模型效果还不错，但非常慢，尤其是带有思考的推理模型要很长时间。小参数的模型速度非常快，但效果又一般。

我们来一个个解决。首先看第一个问题。提示词不稳定的问题主要因为提示词不是太好写，你直接写很容易出现这些问题，过短、主体不明、过长、注意力失焦，导致模型运行过程中可能顾头不顾尾，有些指令遵循，有些不遵循，或者遗忘重点。

甚至有些时候会出现提示词的前后矛盾，你可能自己没有意识到，导致模型理解起来有困难。它就会在运行过程中一会儿遵循你的第一条，一会儿遵循你的第二条，导致不稳定，这是非常痛的问题。

我们的解法是首先提供一套提示词模板。这个模板经过大量调试、测试，运行过程中已经比较稳定了。然后让业务同学尽量遵循这个模板来写提示词，这就比较稳定了。

但我们后来发现这个方式也有问题，很多时候他们过于套用模板了，或者模板有好几套，你也不知道用哪套。写的过程中也会出现一些跟模板冲突的问题等等。

最后我们的方法是用 AI 来辅助提示词调优， AI 帮你写一版，你来确认，如果有问题，你可以及时跟 AI 提出来去调，然后 AI 可以帮你调优。比如说冲突的部分 AI 是可以检测出来的，它可以告诉你这其中某些信息是有问题的，我帮你优化成这样子可能会好一点。

因为最懂大模型的是大模型自己，所以你可以通过这种方式跟它沟通，告诉它需求，让它把提示词整理出来，再让它自己去运行提示词来看到底效果好不好。

第二点是 Workflow 和大模型自主规划的权衡问题。我画了一张图，是说越智能化的东西它可控性越低，越个性化可控性高的东西，智能化越低。

其实这张曲线里的中间点也是可以存在的。那么怎么样去平衡它？我们来看一些在客服领域的常见场景，第一个是订单财务类。像这种标准化场景，比如说我要去查订单有没有过期，或者我要计算有没有该退订的一些费用，该怎样给客户回复，这些都是要标准化的，如果你让大模型深度参与很容易出现幻觉。像排班类问题也是一样，管理同学要定时看一下到底哪个同学没有按时上班，不要出现拖班之类的情况。

这里的定时提醒我们也要严格按照排班表去推送，如果出现幻觉，遗漏了某些同学，导致他没有上班，这个问题也是非常麻烦的。所以像这些场景，我们为了尽量避免出现这些问题，就通过 Workflow 的方式实现。

但另一类场景，比如说 RDS 实例异常诊断，有非常多的客户来咨询问题时就一句话，说我的 RDS 运行非常缓慢，我的实例有异常，我的 SQL 跑半天才跑完，这个描述非常模糊，但可能用户也不能给出更多信息了，因为这确实是我们要进入仔细看的。

比如说到底你的会话连接数有没有异常，你的 QPS 有没有异常，你的内存、MySQL 是不是都有可能导致这个问题？既然它的可能性非常之多，你很难通过 Workflow 去容纳所有可能性。

如果你要编排 Workflow 出来，可能要非常庞大，而且可能会出现一些矛盾或者问题，导致你可能很容易崩溃掉。这种情况就非常适合用大模型自主决策，你只要给它几个大的方向，比如说这几个方向你排查一下，然后模型有很多时候自己内部训练过这些语料，它知道排查 RDS 异常时大概是哪几个维度，就可以通过我们的 API 去诊断，然后自主决策要分析哪些问题。

它不一定全部诊断一遍，它可能根据诊断结果就定位出来可能的原因，然后一步步走下去，这就非常适合用大模型自主规划。

还有一种场景是 Agentic RAG。我们有非常多的中长尾，尤其是长尾产品，我们其实不一定有知识，但是有相应的用户文档或手册。

我们不一定有非常高质量的知识，但又要解决这些问题，就可以用 RAG 来让大模型自主生成 query，搜索完了后自主检查搜索结果是否符合预期，然后自主去调整，进行类似于 deep search 的搜索，最终找到合理的答案。这也非常适合大模型自主规划模式。

在上面的曲线图里其实我们还可以有中间状态，就是大模型与 Workflow 可以结合。比如邮箱诊断这个场景，可能客户会说我邮箱无法收发信了，有的用户会把邮箱账号发过来，有的用户会把邮箱域名发过来，有的用户只会把报错发过来，或者只会说这么一句话，其实可能性非常多。

但我们排查邮箱账号的状态和域名状态，还有报错的时候，我们没办法穷举，所以我们就做了一些中间状态的 Workflow，然后让模型自主决策调度，灵活性就非常高，就是外部灵活内部可控的样子。

我们在 Workflow 这块也有非常多的演化路径。首先我们在探索 Workflow 时，最开始的一版，我们为了降低用户编排 Workflow 的复杂度，其实是让用户用自然语言编排的。就是你用自然语言描述你的流程，然后帮你生成图，然后让大模型按照流程图一步一步执行，完成这个任务。

结果发现这样的方法成本很低，但运行速度太慢，全部走完一遍要很长时间，因为每个环节都要大模型决策。

所以后来为了提升速度和稳定性，我们就做了第二种，就是代码和大模型混排，中间某些部分你可以用代码，有些部分可以用大模型来编排，然后让规则引擎来驱动。

但我们发现虽然这样速度快了，但只能从头支撑到尾，如果中间过程出现一些客户的问题，发生了转移或者跳转，我们没办法做非常灵活的控制。

于是我们演化出第三种方法，自然语言编排加大模型自主规划。也就是说我们不让大模型自己做全部规划，我们会把这张流程图作为参考信息给大模型去做类似 RAG 的自动规划，结果发现效果更灵活一些，这三种我们目前是并存的，具体用哪一种，根据我们的场景可以自己选型。

另外一个话题是领域数据集成和响应速度优化的问题。领域数据集成这块主要的方法是动态加载一些 Prompt，Prompt 里你可以把一些领域数据背景通过动态 Web 的方式加载进来，另外你可以通过引入一些外部技能，让模型自主选择是不是要调工具或者知识库的文档。实在搞不定的情况下，我们可以训练领域大模型来注入领域知识。

为了提高响应速度，我们用把一些中间过程预编译成代码或者参数的方式来提高效率。第二点就是通过各种加速推理方法，比如模型量化、KV Cache 优化等来提高速度。

第三点就是降低模型参数量，如果这是高频场景，或 Function call，那就非常适合小参数模型，用大模型去蒸馏小参数模型，也可以提高速度。

我们在 Agent 这块也是训练一些模型的。首先我们会构造领域数据源，源来自多个地方，比如说我们的领域知识库和文档，还有一些 SOP 标准工具的 API，以及我们各领域产研提供的一些 MCP 措施，包括阿里云的 OpenAPI。接下来我们会汇总清洗，构造成语料，包括单步、多步、反问澄清、Multi-Agent 调用的，和条件判断、场景拒识，然后给模型去做 SFT 或 RL。

评估的方式也有多种，比如说工具选择准确率、动作执行准确率、参数提取准确率，以及模型生成回复的效果评估。

线上推理阶段，包括规划、动作、观察反思，最后生成，并给用户提供 Agent 调优路径。我们可以先通过大模型自主决策的方式构建原型，通过提示词工程调优一版，看形态是否符合业务需要。

如果效果不好，第二步拆解 Workflow，构造更加复杂的 Workflow，来提高它的稳定性或速度与可控性。

Workflow 如果搞不定，比如说我这个地方需要灵活，又要可控，我们就拆解 Multi-Agent 来做指令设计，然后端到端测试。

最后如果实在搞不定，某些环节可能要做模型调优，确定训练任务，寻找构造确定的训练数据，然后做相应的训练。这个成本是随之上升的，但效果也是随着你成本的上升在不断提升。

阿里云服务领域 Agent 平台的设计与落地

基于这些方法论，我们构造出来的 Agent 平台的目的就是要提高平台应用性，也要提高产品的可用性。我们通过 AI 的方式来辅助生成 Agent，你手动构建 Agent 的方式虽然也方便，但它的产品可用性不太稳定。传统的写代码方式虽然效果好，但写代码的方式不太好用。所以我们只有用 AI 方式来构造 Agent。

那么我们的 Agent 平台主要聚焦三个点。

第一，聚焦领域问题，我们这个平台不是通用云平台，它只是解决云计算领域问题，集成领域的数据和领域的模式。

第二，它一定要低成本，因为我们面向的是业务同学和客服同学，他们没有非常高的代码能力、模型调优能力，一定要最简单的方法让他们能够实现一定的构建。

第三，它是个领域沉淀平台，能够把领域思路、流程沉淀到平台上，这个流程既可以看也可以运行，这是我们的定位。

在我们的全链路生产过程中，从提示词到技能，包括 MCP tools 到知识库的调用，到流程编排，再到最后的交互应用上，我们全链路都是用 AI 辅助的。比如说 AI 去引导，提需求，然后 AI 生成 Prompt，AI 调优 Prompt，AI 帮你匹配 MCP tools，匹配文档，AI 帮你编排 Workflow，最后 AI 去生成各种开场白、交互，包括一些 Artifact，还有调用 Agent。

平台架构图如下。最底下是我们的基础设施，在此基础上我们有 Knowledge 和 Prompt，管理 Knowledge 是我们的重要一环。然后有各种措施的集成。Planning 有自主的也有多种风格 Workflow 规划。

再往上，我们有各种交互和多模态。管理部分，我们有 Memory 管理，Agent 之间可以通过 Memory 共享。然后我们有调试诊断、版本管理，你可以回溯到某一版，防止出现线上的不稳定。你可以灰度、授权、统计分析。

比较重要的一块是 AI Generator。里面的很多信息，你可以手动编排，同时也有 AI 生成的方式来编排。最后我们也支持多种 Multi 模式。

下面展示几个 Demo。第一个就是大模型自主规划的，我们可以选择引导式，然后选择任务型，就是大模型自主规划。我可以写 Prompt 写需求，它帮我分析这个需求要做哪些事情，然后生成需求文档。你这个需求其实可以写得非常简单，然后你来确认这个需求文档是不是你要的。

它会根据需求文档自动寻找 MCP tools，然后你去圈选你要使用的那些工具，避免混淆。选完之后我们构建 Prompt，它会自动写结构化的 Prompt，包括怎么调用插件，怎样输出，包括一些约束条件和一些示例，极大简化了我们的业务同学去写提示的难度。然后我们选模型，可以调试，比如说我要诊断邮箱的问题，然后邮箱发送信了，你通过这个域名解析角度来分析一下。

邮件发出去后，我们的模型它自动列了几项，我要检查这几项，然后自己去写代码，调用我们的工具去执行代码，然后一步步诊断。最后全部查完，它会总结出可能的结论，这就是非常高效了。

原来我们的客服同学要去查这几项，最起码得半个小时过去。现在我先给一版去看一下有没有问题，当然过程中也可能会有些地方不是那么的完美，但绝对能提高我们的效率。

第二个 Demo 是 Workflow。我们也做了 Workflow 的编排，也是一样引导式创建，然后选择加速性，就是我们规则引擎驱动的 Workflow。

然后我写简单的业务流程，比如先输入用户识别 ID，然后判断我的 ECS 是哪种付费类型，如果是包年包月就输出什么，如果是按量付费怎么输出，它会把整理成需求文档。然后我们点击下一步，寻找 tools，我们发现有能够查付费类型的 tools，然后去创建，就开始构建 Prompt。

我们的 Prompt 也是流程化的 Prompt，然后把 Prompt 转换成流程图。

之所以要做这一步，是因为我们有的时候 Prompt 也不一定完全是准的，还需要人工再确认一道，确认后把图生成出来。这个图是可以看的，也可以去调，也可以去运行。运行的时候它就告诉我这是什么样的服务器类型，逻辑是一样的，哪怕复杂的上百步的也是这么个逻辑。

最后一个 Demo，我们通过 AI 的方式辅助生成了一些 Artifact。比如说域名信息展示，如果我们展示过程全是文字，看起来很痛苦，就可以通过表格的方式展示。我们也可以通过这种方式让模型自动生成图表，来渲染 MySQL 中 QPS 的图。

这些东西原来都是需要我们研发去做成工具，做成非常复杂的交互，然后让用户去用的。现在我们的客服业务同学只需要简单写写需求，我们自动生成 Prompt，自动去转换，变成可以真正落地的一些效果。

总    结

最后的话我讲一句话，Agent 到底应该是灵活自主还是稳定可控？其实这并不是非此即彼的状态，其实取决于你的场景。你可以选其中某一种选型，也可以用 Multi 的方式结合它们来实现更加智能化、更加可控化的能力。

专题演讲嘉宾：姜剑（飞樰）

姜剑是阿里云算法专家，负责阿里云服务领域 Agent 智能体平台的算法架构设计。曾负责阿里云智能客服机器人整体算法架构设计、服务领域大模型训练、对话机器人链路体系的构建等。在阿里云服务领域深耕 7 年，逐步建设起了阿里云服务领域的算法技术体系，曾主导构建了云计算服务领域的问答系统、知识图谱、推荐系统等。

会议推荐

首届 AICon 全球人工智能开发与应用大会（深圳站）将于 8 月 22-23 日正式举行！本次大会以 “探索 AI 应用边界” 为主题，聚焦 Agent、多模态、AI 产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！