随着LLM的发展，ChatGPT能力不断增强，AI不断有新的概念提出，一种衍生类型的应用AI Agent也借着这股春风开启了一波话题热度，各种初创公司，包括Open AI内部也都在密切关注着AI Agent领域的变化。阿里集团内的AI团队也有很多基于Agent的尝试，Xlangchain和阿里LangEngine有很多Agent的例子，手猫端在过去一年中始关注AI技术动向，不断在手猫端上做面向用户的AI产品尝试，也结合结合Agent技术结合购物组手业务做探索。本文就手猫在探索Agent能力和智能助手业务结合过程、技术侧遇到的问题、想法和实践做简单总结，欢迎大家一起讨论、交流意见。
什么是Agent？
OpenAI应用研究主管Lilian Weng在一篇长文中提出了Agent = LLM（大型语言模型）+记忆+规划技能+工具使用这一概念。AI Agent需要具备感知环境、做出决策并执行适当行动的能力。在这些关键步骤中，最重要的是理解输入给Agent的内容、进行推理、规划、做出准确决策，并将其转化为可执行的原子动作序列，以实现最终目标。
一个精简的Agent决策流程：感知（Perception）→ 规划（Planning）→ 行动（Action）
- 感知（Perception）是指Agent从环境中收集信息并从中提取相关知识的能力。
- 规划（Planning）是指Agent为了某一目标而作出的决策过程。
- 行动（Action）是指基于环境和规划做出的动作。
Agent通过感知从环境中收集信息并提取相关知识。然后通过规划为了达到某个目标做出决策。最后，通过行动基于环境和规划做出具体的动作。Planning是Agent做出行动的核心决策，而行动又为进一步感知提供了观察的前提和基础，形成了一个自主的闭环学习过程。
借用网上的一个案例来解释agent的执行：
- 当一个人问Agent是否会下雨时，感知模块将指令转换为LLM可以理解的表示。
- 然后，大脑模块开始根据当前天气和互联网上的天气预报进行推理。
- 最后，动作模块做出响应，将伞交给人类。
通过重复上述过程，智能体可以不断地获得反馈并与环境进行交互。
在以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版本的视频，再在来介绍整体的思路。
7
结合下图的工程侧实现方案，串联整个链路大致做了以下几件事情：
- 搭建端到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，直接使用模型返回文案。
经过上述的逻辑解析，可以覆盖每一个既定场景的端上交互，然后再根据用户下一步的输入或者选择，继续新的一轮交互。
