简介
PS：与其说是多agent 不如说是多模型，每个模型擅长的不同。agent之间部分记忆不共享（也事太多了），总要有一个管控agent，会有控制权转移的过程。
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。
工作流模式适用于 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
multi-agent-orchestrator
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 未读