粤ICP备17114055号
微信扫码
与创始人交个朋友
支持私有云部署
我要投稿
在以LLM驱动的Agent系统中，LLM扮演着Agent的大脑角色，并辅以几个关键组件：
规划：LLM能够进行全面的规划，不仅仅是简单的任务拆分。它可以评估不同的路径和策略，制定最佳的行动计划，以实现用户给出的目标。
记忆：可以利用LLM具有的记忆功能，存储和检索过去的信息和经验。这使得它能够在处理用户查询时，利用之前学到的知识和经验，提供更准确和个性化的答案。
工具使用：LLM通过理解工具的描述，来学习使用各种工具和资源，并灵活运用它们来支持任务的完成，在构建Agent的时候可以让Agent感知自己可以使用什么工具。工具的实现可以是利用搜索引擎、数据库、调用API等，获取和整理相关信息，以满足用户的需求。
这里关于Agent不过多介绍，网上关于Agent的文章很多，感兴趣的可以查看这几位大神的文章了解Agent的更多知识：
Agents 能力解密：
https://blog.csdn.net/youyi300200/article/details/132864191
AI Agent到底是什么：
https://zhuanlan.zhihu.com/p/681639504
了解了Agent的概念后，结合手猫在做的智能助手相关探索，PD希望把Agent技术与智能助手业务结合起来做用户侧的创新。PD希望在手猫APP中可以提供一个交互页面，可以使用LLM智能体的自然语言理解能力、思维规划能力、工具使用等能力，直接理解用户输入的需求，然后通过Agent规划能力，决策出实现用户述求的行动路径，并调用智能体对应的工具实现用户需求，最后把结果展示在页面上，解决用户述求。先看做出来的demo版本的视频，再在来介绍整体的思路。
结合下图的工程侧实现方案，串联整个链路大致做了以下几件事情：
搭建端到LLM直接信息传输链路，完成工程侧业务管理能力建设。
搭建用户会话管理、多场景识别、链路分发机制。
完成Agent模版到工具协议串联，把工具抽象化、按照协议“喂”给tpp Agent模版工程，完成Agent的使用工具的动态构建和在线灵活管理。
完成Agent工具抽象模版化建设以及工具描述的步步调优，提升Agent整体链路规划准确性。
完成工具&LLM输出到端展示的视图层转换，页面流式协议引入，提升端上输出稳定性。
Agent方案中，LLM有理解工具描述、区分工具使用场景的能力，可以按照工具的约定，将指定的参数结构化的输入到接口内部，总结下来我们LLM能力解决了人类非结构化语言到工具结构化输入的问题。但是现在手猫APP端页面的展示，都需要转化为非常复杂的结构化数据结构才行，经过测试LLM输出复杂结构化展示数据的稳定性非常的差，面对复杂的页面展示逻辑，至少现在无法达到面向C端用户放开的标准。因为业务产品是无法容忍对线上用户透出内容的不确定性，所以解决LLM非结构化输出到端上结构化数据转化问题，才能解决APP展示端的问题，也是大模型项目能够面向C端用户顺利上线的前题。
为了解决LLM输出非结构化数据到端上展示的问题，我们根据工具实现功能的特性和页面交互特征不同，把工具分类抽象和分别建模（具体可见4-工具类型与定义），根据工具类型与端上约定特定协议，同时把工具的返回做区分，工具返回定义了Object（给LLM消费的内容）和 ViewDTO（app端消费数据结构）两个数据结构，在Agent侧做数据解析，把Object内容输入给LLM做下次ReAct推演，同时把ViewDTO输出到端上展示。在定义工具的展示协议，也抽象化定义了工具异常、模型中断、用户选择等交互模式，实现整体的用户交互方案，详见下图。
工程侧会在视图层，做页面工具数据的解析和转化，具体逻辑大致如下图所示：
首先会在视图层会根据agent执行输出内容，判断整体Agent思维和执行流程是否使用工具，
如果没有使用工具，会直接返回大模型的输出结果返回到C端做文案展示。
如果流程使用工具，会解析整个思维链中最后一个工具的返回结果，判断是否有给端上的展示数据结构viewDTO，
如果有返回viewDTO，使用viewDTO内容展示。
如果工具没有返回viewDTO，直接使用模型返回文案。
经过上述的逻辑解析，可以覆盖每一个既定场景的端上交互，然后再根据用户下一步的输入或者选择，继续新的一轮交互。
业务PD做AI技术结合业务场景的尝试时，需要经常做技术可行性尝试，例如需要测试Agent智能体的推理过程是否合理，是否能按照自己的思维路径落地，推理一致性问题等。在基建没有完成之前，资源有限的情况下，如果通过写脚本支持业务反复验证测试、参数调整等，技术成本比较高。体会到AI项目与传统项目落地的差异后，意识到后续不同场景的迭代都会经历这样的过程，提供给产技一个类似大学“实验室”的地方，让他们做自己各种各样的验证，是AI项目落地过程中必不可少的一环，于是就有了搭建Agent实验室的想法，提供给产技做业务探索和提效工具，提高业务迭代效率。
基于自己对AI技术的理解，做数据建模、类型抽象，搭建了自己的AI运维实验室，并不断地完善和补充功能，让AI“实验室”应用到产技日常开发和业务迭代中去，AI实验室设计思路如下图。
搭建Agent实验室，是为了提供给产技快速构建Agent，验证业务想法的测试场地，提供可以组合现有的已有工具，搭属于自己的私有Agent模版的平台，让业务技术快速试错。
Agent实验平台提供能力如下：
提供Agent抽象、管理和测试，每个人都能基于现在的工具快速搭建自己的智能体，做业务场景验证和工具串联验证。类似于你提供一个注入"tool"工具，构建"Agent" Spring bean的方式，可以在页面做Agent调用和能力验证。
提供工具定义抽象，工具描述管理、工具类型抽象，让工具管理可视化，实现工具的可视化配置,根据工具功能抽象通用工具、中断器、选择器等工具类型。详见下图。
提供工具接口数据mock等能力，通过Agent测试链路中mock工具返回，实现在没有工具功能实现的前提下，能验证LLM智能ReAct流程对工具的理解和判断，评测Agent是否能达到业务预期，降低业务试错成本。
Agent可以通过学习调用外部API来获取模型权重中所缺少的额外信息，这些信息包括当前信息、代码执行能力和访问专有信息源等。这对于预训练后难以修改的模型权重来说是非常重要的。
掌握使用工具是人类最独特和重要的特质之一。我们通过创造、修改和利用外部工具来突破我们身体和认知的限制。同样地，我们也可以为语言模型（LLM）提供外部工具来显著提升其能力，LLM可以利用搜索引擎、数据库、API等工具，获取和整理相关信息，以满足用户的需求。
在工具的使用过程中，有必要对工具的类型进行归类使用，确认工具边界后，开发者在定义和使用工具过程中，能更好的根据业务提供更好工具。目前FC部门内部工具的分类，是根据不同工作的作用来划分。目前平台支撑的工具类型有以下分类。
工具的类型是以工具的使用特性为标准抽象的，一类工具的定义，会与底层Agent模版工程做协议，Agent模版工程会区分不同的类型，做不同的动作。例如通用工具，Agent会使用通用工具模版，按照工具提供的描述拼接给LLM，LLM规划使用工具时候，Agent模版工程会按照通用工具的协议，执行配置接口/方法的调用，按照返回协议，解析工具返回，给到Agent做Observations：
中断的定义：
中断是指Agent在做规划和调用工具时候的一种行为。Agent执行用户指令的时候，遇到不能继续执行的情况，可以先中止流程的继续执行，需要外部输入或者反馈后，继续后续推理流程的动作。
例如用户需要执行一个订单退款操作，但是在订单查询的时候，查到了多个订单，这个时候需要先中断退款的操作，反馈给用户，让用户选择其中的一个订单继续执行。
是否中断：否
执行：Agent执行到通用类型工具的时候，不会中断推理-执行的流程。
通用型工具定义：LLM判断需要调用工执行，系统需要执行一段工程化指令来获取答案，并且不会中断ReAct流程的时候，可以使用通用型工具。通用型工具目前支持外调服务（tpp/hsf）来获取答案，也支持调用本地方法来获取结果。
使用场景：业务场景中，需要借助外部工具查询信息、执行操作、逻辑处理等，都可以抽象成通用工具给LLM使用。例如外调订单接口，查询用户的历史订单；外调商家接口，查询商家信息等等。
支持类型：
HSF ：工程以hsf方式，提供外调服务执行查询、写、等业务定制操作。
TPP ：工程TPP形式，提供外调服务执行查询、写、等业务定制操作。
LOCAL：工程本地方法、JAR包形式，提供定制业务操作。
其他：待扩展类型
执行这个类型的工具，会中断ReAct推理过程，等待外部反应或者用户输入，才能继续推理流程。
是否中断：是
执行：Agent执行到选择器类型工具的时候，会中断推理-执行的流程。
选择器定义：工具实现一个集合的输入，让用户做一次选择。
使用场景：在业务实现的过程中，往往会遇见需要用户再次决策的场景，例如让用户选择目标商品集合的一个继续操作，这个时候就需要使用选择器。
支持类型：
订单选择器：如果LLM判断使用一个工具只需要一个订单，而上一个工具查询出多个订单的时候，可以使用订单选择器，让用户确认一个订单，继续继续使用工具做后续流程。
商品选择器：如果LLM判断使用一个工具只需要一个商品，而上一个工具查询出多个商品的时候，可以使用商品选择器，让用户确认一个商品，继续继续使用工具做后续流程。
使用选择器的时候，需要注意前台做样式的适配和定制，目前支持的订单选择器和商品选择器，需要APP端适配展示卡片。
是否中断：是
执行：Agent执行到中断器类型工具的时候，会中断推理-执行的流程。
中断定义：工具实现一个自定义输出，输出可以是一个页面地址或者一个协议地址，让用户做反馈。
使用场景：在业务实现的过程中，会遇见需要用户补充信息的场景，例如盯降级的场景，如果用户没有给出需要盯降价的商品，【盯降价】的工具就无法继续执行，这个时候可以使用中断器，中断流程后，返回盯降价的商品选择页面让用户补充信息，用户盯价商品后，LLM使用【盯降价】工具创建盯价任务。
支持类型：
业务中断器：使用中断器，中断流程，返回页面动作，让用户反馈信息。
使用中断器时候，需要注意中断以后跟端上协议，中断器要配合APP端上动作，才能起到让用户补充信息的作用。
正常一个工程接口的返回示例如下：
{"code":200,"success":true,"pageDTO":null,"message":null,"class":"com.alibaba.test.api.response.Result","object":[{"itemId":665788007683,}],"viewDTO":{"sceneName":"showOrder",}}Agent模版工程解析工具异常路径如下：
会优先取object字段，如果object字段不为空，直接输出给LLM，做下次ReAct。
如果object为空，会取message字段输出给LLM做下次ReAct，不会再判断message是否为空。
目前tools返回异常不会中断ReAct流程，无论是系统异常还是业务异常。
如果系统发生异常，直接使用以下方式返回tools结果
return Result.buildFail(-1, "系统异常");{"code":-1,"success":false,"message":"系统异常","class":"com.alibaba.test.api.response.Result","object":null}
这个时候因为object里没有值，给到LLM的就是：“系统异常”
如果业务查询异常，返回了空list，使用以下方式返回tools结果
List<Obejct> list = null;return Result.buildSuccess(list);{"code":200,"success":true,"class":"com.alibaba.test.api.response.Result","object":[]}
这个时候因为object里有值，给到LLM的就是："[]"
如果业务正常
{"code":200,"success":true,"pageDTO":null,"message":null,"class":"com.alibaba.test.api.response.Result","object":[{"itemId":665788007683,}],"viewDTO":{"sceneName":"showOrder",}}这个时候因为object里有值，给到LLM的就是："[{"itemId":665788007683} ]"，viewDTO不会给到LLM消费,只是页面展示用。
如果异常想提示给用户，需要把异常按照特定格式设置到ViewDTO中，这样页面才能按照协议展示。最简单的在胶囊展示提示如下，"sceneName":"showError" 这个写死：
{"code":-1,"success":false,"pageDTO":null,"message":"没有权限","class":"com.alibaba.test.api.response.Result","object":null,"viewDTO":{"sceneName":"showError","showTips":"抱歉，你暂时没有权限",}}Tools工具定义粒度
工具定义粒度就是工具实现功能范围的大小，工具实现的功能越多，工具的粒度越大；工具实现的工具越小，工具的粒度越小。例如要实现一个订单退款场景，如果工具定义的粒度大，可以一个工具就实现订单查询+订单退款操作；如果工具定义的粒度小，可以分订单查询工具，订单退款工具。
工具粒度 | 优势 | 劣势 |
大 | ||
小 |
开发者在实现LLM调用的工具时候，一定要注意接口的安全策略，应用工具的调用者是LLM，使用过程会比一般的程序开发者更加“开放”，无法预知LLM使用工具的前置条件，所以在工具实现的时候，要更加谨慎和保守，前置校验也需要更规范。建议如下：
参数透传：安全级别比较高的参数，一定要使用系统层透传，不要让LLM设定传入参数，防止LLM“臆造”、“篡改”，例如用户id，设备id等参数，影响代码稳定性和数据安全。
代码防腐层：建议设计代码防腐层，用来隔离LLM传入参数和下游调用参数。
参数合法性校验：对于比较关键的参数，一定要校验合法性，例如订单号一定是数字，位数在10位以上等，防止LLM“臆造”的参数对下游系统造成影响。
数据状态校验：对应执行类工具（存在写操作的实现），执行前一定要对数据状态进行校验，防止非法操作存在。
接口幂等：LLM在ReAct流程中可能会重复执行接口，对于幂等要求比较高的操作，设计时候要考虑接口幂等性。
多阶段事务：对于业务比较复杂的场景，尽量保证事务操作在一个工具内实现，防止跨工具事务的工具实现。
项目上线和迭代的过程中，遇见的问题也特别多，大致总结如下：
面向C端的AI创新，对于结果的正确率要求很高，经过对底层模型针对场景的语料的需求和评测，正确率提示至80+%，但是对于面向C端全面开发还有很长的路要走。
大模型解决了用户输入的自然语言到底层工具结构化输入的转化，但是大模型直接输出到端上的结构化展示错误率比较高，直接透出给用户风险比较大，目前只能依赖工具的结构化输出做页面展示，缺点是失去输出内容展示的灵活性。
随着智能体中工具的数量增加，智能体对工具的理解和组合会变得不稳定，影响特定场景的正确率，固定Agent和多Agent方案应该是未来的方向，但是要解决Agent智能体分发的问题。
LLM对工具的返回复杂度有要求，不能返回太复杂的对象，入参也不能过于复杂，否则成功率会降低。
感谢项目组的人员一起学习排解难题、落地思路，虽然在项目的过程中遇见很多问题，但是探索的过程中积累了很多项目经验，毕竟“书上得来终觉浅”，要知Agent要躬行。另外也要感谢阿里巴巴集团提供的大量学习平台，让我们在学习和接触AI新技术的过程更加方便快捷，集团内技术平台和框架的推出，给业务创新屏蔽了底层技术细节，为上层业务快速落地打下基础。也希望随着AI技术的越来越成熟，未来阿里巴巴能有更好结合C端的场景落地服务于用户。
53AI，企业落地应用大模型首选服务商
产品：大模型应用平台+智能体定制开发+落地咨询服务
承诺：先做场景POC验证，看到效果再签署服务协议。零风险落地应用大模型，已交付160+中大型企业
2024-08-18
当产品经理谈到用LLM Agent构建新一代智能体的时候，他们在说什么？
2024-08-15
对话AI教育从业者们：AI如何解决因材施教的难题？
2024-08-03
工业应用中的向量数据库与知识向量化存储方案
2024-07-25
两大深度学习框架TensorFlow与PyTorch对比
2024-07-17
让生成式 AI 触手可及：NVIDIA NIM on VKE 部署实践
2024-07-16
中文大模型基准测评2024上半年报告
2024-07-16
一文看懂人工智能的起源、发展、三次浪潮与未来趋势
2024-07-14
"自拍" 秒变 "证件照" 看Coze如何实现
2024-05-14
2024-04-26
2024-05-22
2024-04-12
2024-07-18
2024-03-30
2024-05-10
2024-08-13
2024-04-25
2024-04-26
回到顶部