- Single-Agent 面临的困境
- 多Agent框架
- Qwen-Agent(未细读)
- OpenAI-Swarm Multi-Agent
- autogen-magentic-one
- XAgent - Agent 并行计算, LLM 汇总
- AutoGPT
- 应用
- 未来
Single-Agent 面临的困境
OpenAI 是以 AGI(Artificial General Intelligence) 为愿景的公司,现在的 Agent 在一定程度上可以看作 AGI 的代偿 —— 除工具使用外,规划和记忆本是 LLM 所应覆盖的范畴。如果 LLM 自身能力增强,一切还可能重新洗牌。不过在那之前,Retrieve 和 Task Decomposition 应该会长期把持 LLM 显学的位置。Agent 是角色和目标的承载,LLMs、Plans、Memory 和 Tools 服务于角色扮演和目标实现。那么,自然的,服务于相同或相关目标时,多个 Agent 之间可以共享 thread context,但需要保持自身权限的独立,即 Multi-Agent。
- Single-Agent 系统的知识获取和认知范畴高度依赖于其训练数据集和模型算法,这使得它难以全面把握多元异构的信息要素,以及复杂环境中瞬息万变的细微变化。 Single-Agent 很容易产生知识盲区和认知偏差,从而在面临新的情景时无法作出前瞻性的正确决策,导致决策失误。
- 即便是当下最先进的 Single-Agent ,其可用的算力资源和计算能力在物理层面仍有明确的上限,无法做到无限扩展。一旦面临极其错综复杂、计算量密集的任务, Single-Agent 无疑会遭遇算力瓶颈,无法高效完成处理,性能将大打折扣。Agent一般都通过XoT (CoT、ToT、GoT) + React等方法来规划和思考,上下文会不断的加长,迟早会突破窗口限制。因此拆分Agent的功能避免超过上下文窗口限制是一个很有效的方法。 而且,Prompt是Agent工作的中很关键的因素,单一的Agent如果维护的大量的上下文,难免”脑子”会乱。如果只执行特定的任务,掌握特定技能,当然理论上表现会更好。
- Single-Agent 系统本质上是一种集中式的架构模式,这决定了它存在着极高的故障风险。一旦核心代理发生故障或遭受攻击,整个系统将完全瘫痪,难以继续运转,缺乏有效的容错和备份机制,无法确保关键任务的连续性和可靠性。
- 复杂环境下的决策往往需要各种异构智能算法模型的协同配合,而封闭的 Single-Agent 系统难以灵活整合不同AI范式,无法充分挖掘多元异质智能的协同潜能,解决复杂问题的能力相对有限。
- Single-Agent 系统通常是封闭式的,新的功能、知识很难被快速注入和更新,整体的可扩展性和可升级性较差,无法高效适应不断变化的复杂业务需求,存在架构上的先天缺陷。
工作流模式适用于 Bot 技能流程相对固定的场景,在该模式下,Bot 用户的所有对话均会触发固定的工作流处理。在 AI 比你懂自己之前,场景分流方法将长期有效。多 Agent 模式通过以下方式来简化复杂的任务场景。
- 您可以为不同的 Agent 配置独立的提示词,将复杂任务分解为一组简单任务,而不是在一个 Bot 的提示词中设置处理任务所需的所有判断条件和使用限制。
- 多 Agent 模式允许您为每个 Agent 节点配置独立的插件和工作流。这不仅降低了单个 Agent 的复杂性,还提高了测试 Bot 时 bug 修复的效率和准确性,您只需要修改发生错误的 Agent 配置即可。
在 Multi-Agent 系统架构中,由众多独立自治的智能体代理组成,它们拥有各自独特的领域知识、功能算法和工具资源,可以通过灵活的交互协作,共同完成错综复杂的决策任务。与单一代理系统将所有职责高度集中在一个代理身上不同, Multi-Agent 系统则实现了职责和工作的模块化分工,允许各个代理按照自身的特长和专长,承担不同的子任务角色,进行高度专业化的分工协作。 此外, Multi-Agent 系统具有天然的开放性和可扩展性。当系统面临任务需求的不断扩展和功能的持续迭代时,通过引入新的专门代理就可以无缝扩展和升级整体能力,而无需对现有架构进行大规模的重构改造。这与单一代理系统由于其封闭集中式设计,每次功能扩展都需要对整体架构做根本性的修改形成鲜明对比。
以rag系统为例
- 简单的rewrite ==> retrieve ==> generate
- rag的尽头是agent
rewrite ==> retrieve ==> generate
可以解决的问题终归有限, 这里涉及到很多花活,比如拆分子问题、联网、ircot等,需要agent 根据当前的已知信息,判断下一步 ==> 行动 ==> 根据观察判断下一步 - rag的尽头是multi-agent 单个agent 可以解决的问题也终归有限,用户的“知识”不只在文档里,也在数据库表里,也是知识图谱里,都编排在一个agent里,对路由器/plan 组件的要求很高,很多时候即便人也无法判断,这时候就要“三个臭皮匠,顶一个诸葛亮”了。 如果LLM能力足够,一个agent 选择tools 就能解决所有问题。实质上还是LLM 能力有限(无法较好的拆解问题,制定plan,也无法较好的判断问题结束),针对某一链路、某一场景进行特化,复查场景采取多角色协作方式。
- MultiAgent: 多个LLM,角色分工明确(角色扮演很重要!),偏向协作解决复杂任务,
- Agent-tools: 单个Agent调用工具(通常为API或功能模块)完成特定功能,偏向任务执行和效率。
从架构的角度,与 single agent 相比,multi-agent 架构更易于维护扩展。即使是基于 single agent 的接口,使用 multi-agent 的实施架构也可能使系统更加模块化,开发人员更容易添加或删除功能组件。目前的技术条件下,无法构建出一个满足所有功能的 single agent,但可以将不同的 Agent 和 LLM 进行组合,构建出一个满足使用要求的 multi-agent。
多Agent框架
智能体的发展:从单任务到多代理协同与人代理交互。多智能体应用让不同的Agent之间相互交流沟通来解决问题。
AutoGen、ChatDev、CrewAI CrewAI:一个集众家所长的MutiAgent框架 PS: 你要是上万个tool的话,llm 上下文塞不下,此时让一个llm 针对一个问题决策使用哪一个tool 就很难(ToolLLaMa已经支持16k+了),此时很自然的就需要多层次的Agent,低层次的Agent 更专业聚焦一些。
- 智能体和环境的交互(Agent-Environment Interface);智能体交互的环境可分为以下几类:
- 沙箱环境(Sandbox);
- 物理环境(Physical)
- 无环境(None),例如多智能体对一个问题进行辩论以达成共识,无环境下的应用主要关注智能体间的交互,而非智能体和外部环境的交互。
- 智能体画像构建(Agents Profiling);多智能体中各智能体承担不同的角色,每个角色均有相应的描述,包括特征、能力、行为、约束和目标等,这些描述构成智能体的画像(Profile)。
- 智能体间的通信(Agents Communication);从通信范式、通信结构和通信内容三个方面对智能体间的通信进行解析:
- 通信范式(Communication Paradigms):智能体间通信的方式、方法:合作;辩论;竞争
- 通信结构可分为四类:
- 分层(Layered)结构;类似多层前馈神经网络,只是将其中的神经元替换为智能体,其针对给定问题,在推理时根据智能体优选算法选择各层中最优的智能体,然后使用选出的智能体逐层向前传递求解给定问题;
- 去中心化(Decentralized)结构;各智能体间直接点对点地相互通信,这种结构主要用于世界模拟(World Simulation)应用中;
- 中心化(Centralized)结构,由一个或一组智能体构成中心节点,其他智能体只与中心节点通信;
- 共享消息池(Shared Message Pool)结构,所有智能体发送消息至共享消息池,并订阅和自己相关的消息。
- 智能体能力获取(Agents Capabilities Acquisition)。能力获取包括智能体从哪些类型的反馈中学习以增强其能力,以及智能体为有效解决复杂问题而调整自己的策略。根据反馈的来源,可将反馈分为以下几类:
- 来自真实或模拟环境的反馈(Feedback from Environment),这种反馈在问题求解应用中比较普遍,包括软件研发中智能体从代码解释器(Code Interpreter)获取的代码执行结果,机器人这类具身智能体从真实或模拟环境获取的反馈等;
- 来自智能体间交互的反馈(Feedback from Agents Interactions),这种反馈在问题求解应用也比较常见,包括来自其他智能体的判断,或来自智能体间的通信等,例如在科学辩论中,智能体通过智能体间的通信评估和完善结论,在博弈游戏中,智能体通过之前几轮和其他智能体的交互完善自己的策略;
- 来自人类反馈(Human Feedback),人类反馈对智能体对齐人类偏好很重要,这种反馈主要在人机回环(Human-in-the-loop)应用中
- 无反馈(None),无反馈主要出现世界模拟这类应用中,因为这列应用主要侧重结果分析,例如传播模拟的结果分析,而非智能体能力获取,所以无需引入反馈对智能体的策略进行调整。 而智能体调整策略、增强能力的方式又可以分为三类:记忆(Memory),自我进化(Self-Evolution)和动态生成(Dynamic Generation)。
Qwen-Agent(未细读)
Qwen-Agent 使用篇 未细读
OpenAI-Swarm Multi-Agent
OpenAI-Swarm Multi-Agent 框架源码解读 未细读。
初识 OpenAI 的 Swarm:轻量级、多智能体系统的探索利器 未细读。
autogen-magentic-one
https://github.com/microsoft/autogen/tree/main/python/packages/autogen-magentic-one
XAgent - Agent 并行计算, LLM 汇总
XAgent采用双环机制,外循环用于高层任务管理,起到规划(Planning)的作用,内循环用于底层任务执行,起到执行(Execution)的作用。
- PlanAgent首先生成一个初始计划,为任务执行制定基本策略。该部分会将给定的复杂任务分解为更小、更易管理的子任务,其表现为一个任务队列,可以直接地执行。
- 迭代式计划优化:在初始规划之后,PlanAgent通过从任务队列中释放出第一个任务,然后将该子任务传递给内循环,PlanAgent持续监视任务的进展和状态。在每个子任务执行后,内循环会返回来自ToolAgent的反馈。根据反馈,PlanAgent触发适当的处理机制,如优化计划或继续执行后续子任务。直到队列中没有剩余的子任务为止,外循环结束。
- 内循环负责执行外循环分配的各个子任务。基于外循环给定的子任务,内循环会指定一个合适的ToolAgent,确保任务达到预期的结果。内循环的主要职责包括:
- Agent调度和工具获取:根据子任务的性质,派遣合适的ToolAgent,该Agent具备完成任务所需的能力。
- 工具执行:ToolAgent首先从外部系统中获取工具以帮助完成任务。然后,Agent使用ReACT来解决子任务,寻找最佳的一系列工具调用来完成子任务。
- 反馈和反思:在一系列动作之后,ToolAgent可以发出一个名为“subtask_submit”的特定动作,以完成当前子任务的处理,并将反馈和反思传递给PlanAgent。这个反馈可以指示子任务是否成功完成,或者强调潜在的改进。
动态规划和迭代改进:PlanAgent赋予Agent不断制定和修订计划的能力,以适应多变的环境和突发需求。这些能力对于确保灵活性、弹性和效率以应对未预见的挑战至关重要。PlanAgent专用于外循环,其通过生成初始计划和不断修订计划来实现这一目标。PlanAgent包含四个函数来优化计划:
- 子任务拆分:使系统能够将特定的子任务分解为粒度更细、更易管理的单元。只有当前正在执行或尚未启动的子任务才有资格进行此操作。
- 子任务删除:删除尚未开始的子任务。已经在进行中或已完成的子任务不具备删除资格。这确保了一定的灵活性,可以修剪多余或不相关的任务,以优化整体执行。
- 子任务修改:修改子任务的内容。要修改的子任务不能是已经开始或已经完成,以保持整体计划的完整性。
- 子任务添加:在特定子任务之后插入新的子任务。只能在当前处理的子任务或其后继任务之后添加子任务。这确保了新任务按顺序编排,简化了执行流程,并保持了一致性。
XAgent缺乏多Agent的能力,例如多Agent的协作模式、通信模式和自定义等,其内部定了的多个Agent,但这些Agent更像是函数的封装。XAgent定义给出的是通用智能体:从XAgent开发框架来看,本质是想通过Agent的任务分解能力加上集成更多的Tools的能力,将复杂任务有效的分解成细粒度的任务执行,但从当前的业界实现,BabyAGI,AutoGen都不是很理想,只能在有限的问题上可能效果可以,但还不是很稳定,完全依赖GPT4的能力,遇到专业性强的复杂问题,效果都不会很好。
AutoGPT
Andrej Karpathy 在 2017 年提出的 Software 2.0:基于神经网络的软件设计。真的很有前瞻性了。这进一步引出了当前正在迅速发展的 Agent Ecosystem。AutoGPT ,BabyAGI 和 HuggingGPT 这些项目形象生动地为我们展示了 LLM 的潜力除了在生成内容、故事、论文等方面,它还具有强大的通用问题解决能力。如果说 ChatGPT 本身的突破体现在人们意识到语言可以成为一种服务,成为人和机器之间最自然的沟通接口,这一轮新发展的关键在于人们意识到语言(不一定是自然语言,也包括命令、代码、错误信息)也是模型和自身、模型和模型以及模型和外部世界之间最自然的接口,让 AI agent 在思考和表达之外增加了调度、结果反馈和自我修正这些新的功能模块。于是在人类用自然语言给 AI 定义任务目标(只有这一步在实质上需要人类参与)之后可以形成一个自动运行的循环:
- agent 通过语言思考,分解目标为子任务
- agent 检讨自己的计划
- agent 通过代码语言把子任务分配给别的模型,或者分配给第三方服务,或者分配给自己来执行
- agent 观察执行的结果,根据结果思考下一步计划,回到循环开始
原生的 ChatGPT 让人和 AI 交流成为可能,相当于数学归纳法里 n=0 那一步。而新的 agent ecosystem 实现的是 AI 和自己或者其他 AI 或者外部世界交流,相当于数学归纳法里从 n 推出 n+1 那一步,于是新的维度被展开了。比如将机器人强大的机械控制能力和目前 GPT-4 的推理与多模态能力结合,也许科幻小说中的机器人将在不久成为现实。
与Chains依赖人脑思考并固化推理过程的做法不同,AutoGPT是一个基于GPT-4语言模型的、实验性的开源应用程序,可以根据用户给定的目标,自动生成所需的提示,并执行多步骤的项目,无需人类的干预和指导(自己给自己提示)。AutoGPT的本质是一个自主的AI代理,可以利用互联网、记忆、文件等资源,来实现各种类型和领域的任务。这意味着它可以扫描互联网或执行用户计算机能够执行的任何命令,然后将其返回给GPT-4,以判断它是否正确以及接下来要做什么。下面举一个简单的例子,来说明AutoGPT的运行流程。假设我们想让AutoGPT帮我们写一篇关于太空的文章,我们可以给它这样的一个目标:“写一篇关于太空的文章”。然后AutoGPT会开始运行,它会这样做:
- AutoGPT会先在PINECONE里面查找有没有已经写好的关于太空的文章,如果有,它就会直接把文章展示给我们,如果没有,它就会继续下一步。
- AutoGPT会用GPT-4来生成一个提示,比如说:“太空是什么?”,然后用GPT-4来回答这个提示,比如说:“太空是指地球大气层之外的空间,它包含了许多星球,卫星,彗星,小行星等天体。”
- AutoGPT会把生成的提示和回答都存储在PINECONE里面,并且用它们来作为文章的第一段。
- AutoGPT会继续用GPT-4来生成新的提示,比如说:“太空有什么特点?”,然后用GPT-4来回答这个提示,比如说:“太空有很多特点,比如说,太空没有空气,没有重力,没有声音,温度变化很大等等。”
- AutoGPT会把生成的提示和回答都存储在PINECONE里面,并且用它们来作为文章的第二段。
- AutoGPT会重复这个过程,直到它觉得文章已经足够长或者足够完整了,或者达到了一定的字数限制或者时间限制。
- AutoGPT会把最终生成的文章展示给我们,并且询问我们是否满意。如果我们满意,它就会结束运行;如果我们不满意,它就会根据我们的反馈来修改或者补充文章。
agent = SimpleAgent.from_workspace(agent_workspace, client_logger)
print("agent is loaded")
plan = await agent.build_initial_plan()
print(parse_agent_plan(plan))
while True:
current_task, next_ability = await agent.determine_next_ability(plan)
print(parse_next_ability(current_task, next_ability)
user_input = click.prompt("Should the agent proceed with this ability?", default = "y")
ability_result = await agent.execute_next_ability(user_input)
print(parse_ability_result(ability_result))
探索AI时代的应用工程化架构演进,一人公司时代还有多远?在冯诺依曼架构或者哈佛架构设备的实际开发中,我们会去关心如何使用相应协议去寻址去读写总线操作不同设备,如UART、I2C、SPI总线协议,这都是我们要学习掌握的,但我们基本不会关心CPU中的CU、ALU等单元。计算机架构这样求同存异的继续发展下去,将这些单元与高速存储及总线等作为抽象概念去进一步封装。而AI应用也是类似的,Agent会将相关的规划反思改进能力不断的作为自身的核心能力封装。因此,对于未来的AI应用极有可能不是在传统计算机上运行的程序,而是标准化的需求,在以规划能力专精的Agent 大模型作为CPU的AI计算机虚拟实例上直接运行的,而我们今天所谈论的应用架构,也会沉积到底层转变为AI计算机的核心架构。最终AI计算机将图灵完备,通过AI的自举将迭代产物从工程领域提升到工业领域。
应用
用于RAG
https://github.com/padas-lab-de/PersonaRAG 未读