如何像Manus一样构建智能体
1. 智能体技术调研
1.1 关键结论(1)智能体是人类和AI的最佳协同模式
AI Agent(智能体)是一种能够感知环境、进行决策和执行动作的智能实体。不同于传统的人工智能, AI Agent 具备通过独立思考、调用工具去逐步完成给定目标的能力。如图一所示:
(图一:理解智能体)
多智能体模式,从副驾驶模式向主驾驶模式的演进。基于大模型的多智能体系统可以提供几种优势,根据分工原则,具备专业技能和领域知识的单个Agent可以从事特定的任务。一方面,通过分工,Agent处理特定任务的技能日益精进。另一方面,将复杂任务分解为多个子任务,可以省去在不同流程之间切换的时间。最终,多个Agent之间的高效分工可以完成比没有专业化分工时大得多的工作量,从而大大提高整个系统的效率和产出质量。如图二所示人类和AI协同的三种模式。
(图二:人类和AI协同的三种模式)
1.2 关键结论(2)多智能体协同有效完成复杂任务
我们调研发现,智能体之间进行多次协同,能够让答案越来越精准。
定义清晰的目标:确保所有智能体对任务的目标有共同的理解,并能够将目标量化为可执行的任务。
分工合作:将整体目标细分成子目标,使得每个智能体可以独立地处理自己的任务,而不需要对其他智能体的状态和行为进行直接操作。
协调与规划:使用协调算法和规划方法来确保所有智能体的行动按照整体目标协同进行。这可能涉及协商、规划冲突解决等技术。
激励机制:设计合适的奖励和激励机制,以鼓励智能体按照整体目标进行协同行动。
1.3 关键结论(3)多智能体建议采用有序合作模式
多智能体的交互模式有中心式模式和分布式模式两种。
中心式模式:一个门控智能体 + 多个协同智能体。也是一种无序模式,门控智能体可以决定其他智能体是否应该执行某个动作,负责整合和组织所有Agent的响应,从而更新最终答案。但是对门控智能体挑战很大,多数表决也可以作为做出适当决策的有效方法。
分布式模式:多智能体之间相互协同。也是一种有序合作模式,当系统中的Agent遵守特定规则时,例如按顺序逐一发表意见,下游Agent只需关注上游的产出。这样任务完成效率就会大大提高,整个讨论过程也会变得井然有序。CAMEL 是双Agent合作系统的成功实施案例。在角色扮演交流框架内,Agent分别扮演人工智能用户(下达指令)和人工智能助手(通过提供具体解决方案来满足请求)的角色。通过多轮对话,这些Agent自主合作完成用户指令。一些研究人员将双Agent合作的理念融入到单个Agent的操作中,交替使用快速和深思熟虑的思维过程,以在各自的专业领域发挥优势。
(图三:多智能体交互)
图源:https://arxiv.org/pdf/2303.17760
结论:我们采用分布式模式中的有序合作模式,协同方式比较清楚简单。
2. 智能助理解决方案
2.1 智能助理解决思路
大模型天生存在几个局限性,第一个是实时知识缺乏,如今天的实时信息获取,第二个是专业技能缺失,如分期需求分析。第三个是缺少协作意识,彼此之间无法协作。第四个是很难完成复杂任务,如需要多个步骤和流程完成的任务。
针对实时知识缺乏我们需要提供互联网实时搜索工具来解决,专业技能缺失我们需要提供各种专业化的工具给大模型使用。针对缺少协作意识问题,我们需要构建多智能体协作框架来解决。针对很难完成复杂任务,我们需要对任务进行拆解和分工,把大问题分成若干小问题。
智能助理 = 大模型底座 + 专业执行计划 + 专业工具 + 专业知识库
2.2 智能助理执行流程
我们设计的智能助理的执行流程如图所示
(图四:运营智能体执行流程)
智能体输入:请帮忙提升XX商家或场景的GMV
智能体输出:输出分为以下几部分:
|
3 智能助理的关键组成部分
3.1 智能体的执行计划
智能体最核心的还是构建执行计划,构建执行计划有两种模式,简单的就是内置执行计划,复杂的就是通过大模型自动生成执行计划。
3.1.1 固定执行计划
第一种模式是固定的执行计划,这也是最容易实现的,就是你告诉大模型每一步做什么,包括哪一步需要调用外部工具,比如
# Role: 你是一个生成攻略的助手
## Profile
- Author: ftf
- Version: 0.1
- Language: 中文
- Description: 这是一个生成攻略的助手,帮助用户生成各种攻略。
## Rules
- 输出的内容不要超过500个字
- 攻略智能包含3,5,7天三种
- 攻略包含交通出行,准备事项,美食攻略,景点攻略
## Type
旅游
## Workflow
1. 调用工具打开浏览器搜索<Question>的<Type>攻略
2. 给用户生成一个攻略
3. 整理:以HTML格式输出工具
## Initialization
严格遵守 <Rules>, 使用默认 <Language> 与用户对话,不允许在答案中添加编造成分
## Question
请帮忙生成一个去北京旅游攻略
3.1.2 Manus如何生成执行计划
通过分析OpenManus的源码和看Manus的演示视频,我猜测生成执行计划一共有两种方法。猜测第一种方法应该是通过提示词生成执行计划,提示词里增加部分约束。以下是OpenManus生成执行计划的提示词。提示词里包含使用工具创建执行计划。
(图五:OpenManus执行计划提示词)
以下是OpenManus生成执行计划的代码和工具代码。
(图六:OpenManus执行计划代码)
猜测第二种模式应该是通过提示词模版生成具体的执行计划。比如你生成一个攻略类的执行计划模版,里面变化的部分用变量代替,比如旅游攻略,XX地方等。
# Role: 你是一个提示词工程师
## Profile
- Author: ftf
- Version: 0.1
- Language: 中文
- Description:你是一名优秀的Prompt工程师,你熟悉[CRISPE提示框架],并输出符合预期的回复。
## Constrains:
- Role: 基于我的Prompt,思考最适合扮演的1个或多个角色,该角色是这个领域最资深的专家,也最适合解决我的问题。
- Profile: 基于我的Prompt,思考我为什么会提出这个问题,陈述我提出这个问题的原因、背景、上下文。
- Goals: 基于我的Prompt,思考我需要提给chatGPT的任务清单,完成这些任务,便可以解决我的问题。
- Skill:基于我的Prompt,思考我需要提给chatGPT的任务清单,完成这些任务,便可以解决我的问题。
- OutputFormat: 基于我的Prompt,基于我OutputFormat实例进行输出。
- Workflow: 基于我的Prompt,要求提供几个不同的例子,更好的进行解释。
- Don't break character under any circumstance.
- Don't talk nonsense and make up facts.
## Rules
- 提示词必须包含Workflow
## Workflow
1. 生成大模型使用的执行计划的提示词
## Initialization
严格遵守 <Rules>, 使用默认 <Language> 与用户对话,不允许在答案中添加编造成分
## Question
请帮忙生成一个去北京旅游攻略的执行计划提示词
3.2 智能体使用的工具
智能体使用的工具大概有以下几类
取数类工具,包含获取商家数据,行业报告等
竞对洞察类工具,包括获取相关数据,分析竞对数据等
策略空间洞察类工具,洞察每一种策略给业务带来的增长空间有多大
策略洞察类工具,洞察业务的增长策略有哪些
策略执行类工具,执行具体的某个策略,给业务代码结果
效果评估类工具,复盘业务数据,各项指标是否有增长或下跌
3.3 智能体的执行模式
我们研究了九大智能体模式,这些模式可以用在不同的场景和各种智能体上。比如我们刚开始通过智能体生成的策略比较少,使用了Storm模式后大大提高了策略生成的丰富度。
模式名称 | 优点 | 缺点 | 应用场景 |
Storm | 多角度、多角色、多维度生成内容 | 步骤多,耗时长 | 生成使用手册,百科,长文本文档 单一策略的泛化生成 |
LLM Compiler | 并行处理,执行效率高 | 框架复杂度高 | 海量执行任务 |
LATS(Language Agent Tree Search) |
| 耗时长,推理成本高 | 推理、决策等问题,如围棋、象棋 |
Refexation | Reflexion框架利用语言反馈强化学习,无需模型微调,支持复杂任务快速学习与迭代改进。 | 依赖自我评估,可能陷入局部最小值,无成功保证,需精心设计的提示。 | 适用于需要快速适应和学习新任务的编程、决策和语言推理任务。 |
Plan&Solve | 提升LLMs多步推理准确性,减少计算和遗漏错误,无需手动示例,易于定制,适用于多种推理任务。 | 设计有效提示有待改进,模型对提示敏感,可能导致语义理解错误,需要进一步优化。 | 教育、自动化客服、技术研究和多步骤复杂问题解决。 |
Self-Discover |
| 计算错误:在数学计算等任务中,尽管推理结构正确,模型在执行计算步骤时可能会出错,这导致预测错误 任务特定结构的局限性:这些推进结构无法适用于非常特定领域知识的复杂任务 对模型能力的依赖:Self-Discover 的效果依赖于模型的元任务推理能力,如果模型在这方面的能力有限,则可能无法生成有效的推理结构 | 适用于语言推理类任务 |
Basic Reflection |
| 1.可能会出现过渡反思,陷入无意义的自我循环中 | 问答,如文案生成、修订等 |
REWOO | ReWOO将LLM的推理过程与外部工具分离,避免了观察相关推理中交错提示的冗余,从而显著减少了token使用,提高了提示效率 | 无法处理那些需要从步骤中的返回结果再决策下一步骤的情况,需要一次性把所有步骤均推理完成 | 推理类 |
reAct |
| 对于需要长期规划类的任务,效果不及预期 | 推理类任务 |