简介
PS：与其说是多agent 不如说是多模型协同，每个模型擅长的不同。agent之间部分记忆不共享（也事太多了），总要有一个管控agent，会有控制权转移的过程。解决复杂问题业界普遍还是在 agent model、workflow、multi-agent 打转转。
在处理复杂问题时，就应该用更多的 Token 换取更好的效果这样的「力大砖飞」策略。为什么需要多智能体系统？会有两个截然不同的观点。
- 反方：模型越强大，所有 AI Agent 都有可能被“模型即产品”所替代，不需要多智能体系统。
- 正方：模型再智能，也无法主动甄别所有环境感知（Context），每个细分领域的 Agent，调研类 Agent、Coding Agent、表格 Agent，都需要花大量的时间，少则半年多则一年，去设计环境感知（Context），减少模型幻觉，Agent 会像互联网 APP 那样百家齐放，而不是一家独大。
这个需要时间来证明。单只从技术视角看，支持多智能体能力不失为一种稳健的选择。这样既保留了面向生态和未来的扩展性，也不妨碍我们专注于优化单智能体的能力。
Single-Agent 面临的困境
真的可以有通用的 God Agent，它可能什么都会吗？GodAgent 不会存在，就好比世界上没有全知全能的人。
随着任务复杂度增加，单一智能体需要理解的语境和工具使用面临上下文窗口限制，导致性能下降。多智能体协作通过动态任务分解、专业化分工和协同工作克服这一挑战。在当前的现实中，在开发一个单智能体系统时会遇到的问题：
- 智能体可用的工具过多，在决定下一步调用哪个工具时效果不佳。
- 上下文过多对于单个智能体来说过于复杂，难以跟踪
- 系统中需要多个专业领域(如规划器、研究员、数学专家等)
- 单体架构在扩展新功能或修改现有功能时，往往需要对整个系统进行调整，成本高且风险大。PS：微服务里的单体架构 vs 微服务架构 PS： 模型可以持续强大到什么都会么？
为了解决上述的问题，可以考虑将应用拆分为多个更小的独立智能体，并将它们组合成一个多智能体系统，期望达到的效果
- 模块化：独立的智能体使开发、测试和维护变得更容易；不同服务可以并行处理任务，某个服务出现问题，其他服务可以继续运行。
- 专业化：可以创建专注于特定领域的专家智能体，或者简单领域用小模型，这有助于提高整个系统的性能和资源消耗。每个Agent可能有不同的工具类型可用（理想少于10个），也可能有不同的记忆系统。
- 控制：可以明确控制智能体之间的通信方式(而不是依赖于函数调用)。 在处理复杂任务时，系统会将任务分解为多个子任务。每个子任务由专门的智能体处理，这些智能体在特定领域具有专长。智能体之间通过持续的信息交换和任务协调来实现整体目标，这种协作方法可能产生智能涌现，即系统整体表现超越单个智能体能力之和。
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 系统具有天然的开放性和可扩展性。当系统面临任务需求的不断扩展和功能的持续迭代时，通过引入新的专门代理就可以无缝扩展和升级整体能力，而无需对现有架构进行大规模的重构改造。这与单一代理系统由于其封闭集中式设计,每次功能扩展都需要对整体架构做根本性的修改形成鲜明对比。此外，资源成本优化和并行处理，如果所有任务都指派给同一个性能最强的智能体，资源消耗大。采用多智能体系统，每个智能体系统因为只擅长各自领域的任务，参数更小，能显著降低资源消耗。另外，每个智能体可以根据自身任务需求分配计算资源、时间等，而且多个智能体可以同时处理不同任务，实现并行处理。容错性和可靠性，对于多智能体系统，某个智能体出现故障，其他智能体可以继续工作，通过智能体之间的协作和备份机制，确保系统整体的稳定性和可靠性。PS：跟单体系统与微服务系统的对比一样一样的。
以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工程能力思考记录过去在微服务的实践上，我们在统一的一套系统框架（HSF）下进行交互，领域的互联以服务接口交互的方式进行，因此在AI时代，未来的系统交付物可能不再是现在的某个服务，而是某个Agent；它与接口最大的差别在于不是一轮input-output，而可能是多轮的，因此协议上的设计需要考虑多轮input-output完成某项任务；
即然单体Agent到多Agent协作是必然的客观演进规律，那么就有必要看一下多Agent协作模式：
| 任务分配机制 | 协作方式 | 冲突解决 |
|---|---|---|
| 集中式任务分配 分布式任务协商 基于角色的任务划分 动态任务重分配 |
平行协作：多Agent并行解决问题 层级协作：管理Agent统筹下级Agent 专家协作：不同领域Agent联合解决问题 |
基于优先级的决策 投票机制 仲裁Agent介入 基于规则的冲突处理 |
可以看到当前市面上关于多Agent协作的讨论，核心是围绕着任务的解决展开的：任务分发、任务处理、任务结果回收；这也是A2A协议引入任务这个概念的原因。
上图是对多Agent协作模块理解的一个简图，从业务主Agent出发，需要基于任务中心恢复当前任务上下文，继续本次任务的处理；接着通过Agent仓库找到需要协同的Agent；我们通过多Agent交互协议与其他协作Agent交互，并在主Agent业务流程中完成结果决策或子Agent的状态透传。
另一个材料
- Anthropic 的 Research 系统采用“编排者-工作者（orchestrator-worker）”模式：主智能体负责整体规划和任务分解，多个子智能体并行执行具体子任务。用户提交查询后，主智能体分析问题、制定策略，并生成多个子智能体，分别探索不同方向。子智能体像智能过滤器一样，利用搜索工具收集信息，最后将结果汇总给主智能体，由其整合成最终答案。与传统的 RAG（检索增强生成）不同，Anthropic 的多智能体架构采用多步动态搜索，能根据中间发现不断调整策略，生成高质量答案。
- 模型必须自主运行多轮，根据中间结果来决定追求哪个方向。线性的、一次性的处理流程无法胜任这些任务。
- 主导智能体将查询分解为子任务，并向子智能体描述它们。每个子智能体都需要一个目标、一个输出格式、关于使用哪些工具和来源的指导，以及明确的任务边界。没有详细的任务描述，智能体就会重复工作、留下空白，或找不到必要的信息。
- 根据查询的复杂度来调整投入。 智能体很难判断不同任务的适当投入量，所以我们在提示中嵌入了扩展规则。简单的事实查找只需要1个智能体进行3-10次工具调用，直接比较可能需要2-4个子智能体，每个进行10-15次调用，而复杂的研究可能需要超过10个子智能体，并有明确分工。这些明确的指导方针帮助主导智能体高效分配资源，并防止在简单查询上过度投入。
- 让智能体自我改进。当给定一个提示和一个失败模式时，它们能够诊断出智能体失败的原因并提出改进建议。
- 引导思考过程。 扩展思考模式（Extended thinking mode）引导 Claude 在一个可见的思考过程中输出额外的令牌，可以作为可控的草稿纸。主导智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂度和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思考改善了指令遵循、推理和效率。子智能体也会进行规划，然后在工具返回结果后使用交错思考（interleaved thinking）来评估质量、发现差距，并完善下一步的查询。这使得子智能体在适应任何任务时都更加有效。
- 并行工具调用改变了速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体是按顺序执行搜索的，速度慢得令人痛苦。为了提高速度，我们引入了两种并行化：（1）主导智能体并行启动3-5个子智能体，而不是串行启动；（2）子智能体并行使用3个以上的工具。这些改变将复杂查询的研究时间缩短了高达90%，使得“研究”功能能在几分钟内完成更多工作，而不是几小时，同时覆盖的信息比其他系统更多。
反对声音——上下文工程（Context Engineering）
从Prompt Engineering到Context Engineering跟AI开发相关的大部分工作，都是围绕着如何把上下文窗口填充正确来进行的。随着LLM性能的进步，人们不再需要为了想出一个像咒语一样的prompt而绞尽脑汁了。但是，随着agent系统的动态性、复杂性逐步增加，保持每一次都能把context组装正确和完整，已经不是一件简单的事情了。这就需要Context Engineering这样一个专业的词汇来指代一整套系统化的方案。Context Engineering包含了所有对组装正确的上下文起到关键作用的技术组件。为了从大量文档内容中选出跟当前任务更相关的数据，就需要retrieve技术（RAG）；为了向模型传达长期记忆和短期记忆，就需要memory工程；为了更好地决策未来，就需要把当前状态以及历史信息传达给模型；另外，还需要一系列的错误处理、恢复、以及guardrails机制。所有这些，都属于Context Engineering的范畴。至少包括：
- 静态的prompt及instruction。
- RAG返回的片段。
- web搜索返回的页面内容。
- 对于工具候选集合的描述。
- 工具调用的历史结果。
- 长期记忆及短期记忆。
- 程序运行的其他历史轨迹信息。
- 出错信息。
- 系统执行过程中通过human-in-the-loop获取到的用户反馈。 Context Engineering并不是某一种具体的技术，而更像是一种思想或观念。它也暗含了AI技术圈（尤其是深入一线的工程师们）对于未来技术趋势的一种判断。AI应用开发在本质上可以看成是，从海量信息中找到恰当的有效信息，最终适配到LLM的上下文窗口上。为了让这个漏斗工作得更高效，你需要检索、过滤、排序。你需要一套完整的Context Engineering工程架构。
别再构建多智能体了来自全球首位AI程序员Devin，热门AI应用DeepWiki的开发团队，Cognition AI认为在2025年的技术水平下，追求让多个AI智能体并行协作的架构，是一种脆弱且极易失败的歧途。为什么？关键在于“上下文灾难”：
- 信息孤岛： 并行工作的子智能体无法看到彼此的进展和决策，就像蒙着眼睛的工匠，最终做出的“零件”风格迥异、无法组装。
- 决策冲突： 智能体的每一个行动都包含着“隐性决策”。当多个智能体独立决策时，这些决策极有可能相互冲突，导致整个项目走向混乱。
出路何在？拥抱“上下文工程（Context Engineering）”：Cognition AI 团队提出，构建可靠AI智能体的关键，不是增加智能体的数量，而是精细化地管理和传递信息。他们主张采用单线程线性架构，确保信息流的完整和连续，让每一步行动都基于完整的历史背景。对于超长任务，他们则提出用一个专门的模型来智能“压缩上下文”，而非粗暴地将任务分包。
HTML于1993年问世。2013年，Facebook向世界发布了React。如今已是2025年，React（及其衍生技术）主导了开发者构建网站和应用的方式。为什么？因为React不仅仅是一个编写代码的脚手架，它是一种哲学。通过使用React，你欣然接受了一种以响应式和模块化模式构建应用的方式——人们现在认为这是一种标准要求，但在早期Web开发者看来，这并非理所当然。在LLM和构建AI智能体的时代，感觉我们仍像是在玩弄原始的HTML和CSS，试图弄清楚如何将它们组合起来以创造良好的体验。除了某些最基础的概念外，还没有哪一种构建智能体的方法成为标准。
在2025年，市面上的模型已经极其智能。但即使是最聪明的人，如果缺乏对任务上下文的理解，也无法有效地完成工作。“提示工程（Prompt engineering）”这个词被创造出来，指的是为LLM聊天机器人以理想格式编写任务所需的努力。而“上下文工程”则是它的下一个层次。它关乎在一个动态系统中自动完成这件事。这需要更精细的把握，并且实际上是构建AI智能体的工程师们的首要工作。以一种常见的智能体类型为例。这种智能体：
- 将工作分解成多个部分
- 启动子智能体来处理这些部分
- 最后（一个总结智能体）将结果合并 这是一个诱人的架构，特别是当你的任务领域包含多个并行组件时。然而，它非常脆弱。关键的失败点在于：假设你的任务是“构建一个Flappy Bird的克隆版”。它被分解为子任务1“构建一个带有绿色管道和碰撞区的移动游戏背景”和子任务2“构建一个可以上下移动的小鸟”。结果，子智能体1实际上误解了你的子任务，开始构建一个看起来像《超级马里奥》的背景。子智能体2为你构建了一只鸟，但它看起来不像游戏素材，其移动方式也与Flappy Bird中的完全不同。现在，最终的智能体只能面对一个棘手的任务：将这两个沟通失误的产物组合起来。
从Prompt Engineering到Context Engineering具备高度自主性的Agent，一般来说是由agent loop驱动的运行模式。在每一个循环迭代中，它借助LLM动态决策，自动调用适当的工具，存取恰当的记忆，向着任务目标不断前进，最终完成原始任务。然而，这种agent loop的运行模式，直接拿到企业生产环境中却很难长时间稳定运行。这种所谓的「tool calling loop」在连续运行10~20轮次之后一般就会进入非常混乱的状态，导致LLM再也无法从中恢复。Dex Horthy质疑道，即使你通过努力调试让你的Agent在90%的情况下都运行正确，这还是远远达不到“足以交付给客户使用”的标准。想象一下，应用程序在10%的情况下会崩溃掉，没有人能够接受这个。可以说，Agent无法长时间稳定运行的原因，大部分都能归结到系统送给LLM的上下文 (Context) 不够准确。
- 所以说，Context Engineering产生的第一个背景就是，AI技术落地已经进入了一个非常专业化的时代。这就好比，对于流行歌曲，很多人都能哼上两句。你不管是自娱自乐，还是朋友聚会唱K，这当然没问题。但是，如果你真的要去参加“中国好声音”并拿个名次回来，那就不是一回事了。类似地，Context Engineering这一概念的提出，对于Agent开发的交付质量提升到了专业工程学的高度，它要求你的系统要尽最大可能确保LLM上下文准确无误。
- Context Engineering产生的第二个背景，来源于LLM的技术本质，它具有天然的不确定性。LLM的底层运行原理，基于概率统计的 predictnexttoken。概率是充满不确定性的，模型本身的行为就不能被精确控制。在模型训练完成之后的生产运行环境中，你只能通过精细地调整Context来「间接地」引导它的行为。在很多现实场景中，都采取了较为保守的做法，在现有的业务流程代码中，穿插着调用一两次LLM，对于这种简单的情形，只要在调用的局部把LLM所需的prompt提前设计好、调试好，系统就可以上生产环境了。但是，在更复杂、更高自主性的Agent系统中，对于prompt的管理就没有这么简单了。资深的AI从业者Nate Jones把Context Engineering大体分成两部分。
- 第一部分 (the smaller part)，称为deterministic context。这部分指的是我们直接发送给LLM的上下文，包括指令、规则、上传的文档等等，总之它们是可以确定性地进行控制的 (deterministically control）。
- 第二部分 (the larger part) ，称为probabilistic context。这部分指的是，当LLM需要访问web以及外部工具的时候，会不可避免地将大量不确定的信息引入到LLM的上下文窗口。典型地，Deep Research就是属于这一类的技术。在这种情况下，我们能直接控制的上下文内容，只占整个上下文窗口的很小一部分（相反，来自web搜索和工具返回的内容，占据了上下文窗口的大部分）。因此，针对probabilistic context这一部分的上下文，你就很难像针对deterministic context那样，对prompt进行精细地微控制 (micro control) 。 总之，LLM本身的不确定性，加上访问web和外部工具带来的context的不确定性，与企业对于系统稳定运行的要求存在天然的矛盾。这样的难题解决起来，就需要更多、更系统的工程智慧。这成为Context Engineering产生的第二个背景。
- 至于Agent执行会失败的具体技术原因，更进一步拆解的话，可以归结为两个方面：
- 第一，模型本身不够好或者参数不够，即使有了正确的context还是生成了错误结果。
- 第二，模型没有被传递恰当的上下文。在实际中，占大多数。这第二个原因，又可以细分成两类：
- 上下文不充分，缺失必要的信息 (missing context) 。
- 上下文的格式不够好 (formatted poorly) 。类比人类，如果说话没有条例，颠三倒四，即使所有信息都提到了，仍然可能无法传达核心信息。
多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）；从通信范式、通信结构和通信内容三个方面对智能体间的通信进行解析：
- 智能体能力获取（Agents Capabilities Acquisition）。能力获取包括智能体从哪些类型的反馈中学习以增强其能力，以及智能体为有效解决复杂问题而调整自己的策略。根据反馈的来源，可将反馈分为以下几类：
- 来自真实或模拟环境的反馈（Feedback from Environment），这种反馈在问题求解应用中比较普遍，包括软件研发中智能体从代码解释器（Code Interpreter）获取的代码执行结果，机器人这类具身智能体从真实或模拟环境获取的反馈等；
- 来自智能体间交互的反馈（Feedback from Agents Interactions），这种反馈在问题求解应用也比较常见，包括来自其他智能体的判断，或来自智能体间的通信等，例如在科学辩论中，智能体通过智能体间的通信评估和完善结论，在博弈游戏中，智能体通过之前几轮和其他智能体的交互完善自己的策略；
- 来自人类反馈（Human Feedback），人类反馈对智能体对齐人类偏好很重要，这种反馈主要在人机回环（Human-in-the-loop）应用中
- 无反馈（None），无反馈主要出现世界模拟这类应用中，因为这列应用主要侧重结果分析，例如传播模拟的结果分析，而非智能体能力获取，所以无需引入反馈对智能体的策略进行调整。 而智能体调整策略、增强能力的方式又可以分为三类：记忆（Memory），自我进化（Self-Evolution）和动态生成（Dynamic Generation）。
智能体间的通信
通信范式（Communication Paradigms）：智能体间通信的方式、方法：合作；辩论；竞争
- 系统的通信拓扑主要有两种方式：一种是静态结构，另一种是动态结构。静态拓扑是事先规划好的。它不变，按既定规则连接各个Agent。相比之下，动态拓扑不是一开始就设定好，而是Agent会根据当前情况，比如任务难度、资源分配或执行表现，自动调整连接方式和团队分工。
- 静态拓扑常见的几种结构：
- 分层（Layered）结构；类似多层前馈神经网络，只是将其中的神经元替换为智能体，其针对给定问题，在推理时根据智能体优选算法选择各层中最优的智能体，然后使用选出的智能体逐层向前传递求解给定问题；
- 去中心化（Decentralized）结构；各智能体间直接点对点地相互通信，这种结构主要用于世界模拟（World Simulation）应用中；
- 中心化（Centralized）结构/单主动-多被动，由一个或一组智能体构成中心节点（root agent/main agent/orchestrator），其他智能体只与中心节点通信；中心节点负责协调和集成所有智能体的信息，然后向各个智能体发出指令或反馈。中心节点可以全局地了解所有智能体的状态和信息，有助于做出全局最优的决策。但是容易出现单点故障，中心节点的故障可能导致整个系统的通信瘫痪。
- 共享消息池（Shared Message Pool）结构，所有智能体发送消息至共享消息池，并订阅和自己相关的消息。
- 通信协议
可扩展性是另一个核心问题。Agent一多，通信量就飙升。全连接结构里，每多一个Agent，通信路径不是加一条，而是多出一大片，计算资源很快就吃不消。有的系统尝试用有向无环图（DAG）来控制结构复杂度，有的则采用分布式架构和并发机制来提升系统吞吐量。
多Agent系统的评估
评估分为两个方向：
- 一是解决特定任务时的表现。包括代码生成、知识推理、数学推理等任务，测试的是分布式任务解决的能力——即让多个Agent分工协作，优化每一步的处理过程。比如在代码生成中，有的系统会让不同的Agent担任“程序员”、“测试员”、“评审员”等角色，从而把复杂的代码任务拆解成流水线式的操作，大幅提升正确率和效率。
- 二是系统整体能力的衡量。强调沟通是否顺畅、任务是否分配合理、是否能在突发情况下做出反应，比如一个Agent“出故障”时，其他Agent是否能顶上。评估标准不再只有准确率和完成率，还包括沟通效率、决策质量、协调能力和环境适应能力。
工程实例
无论你选择哪种框架来创建Multi-Agent系统，它们通常由几个要素组成，包括其档案、对环境的感知、记忆、计划和可用行动。每个框架在Agent之间的通信方式上略有不同。但归根结底，它们都依赖于这种协作性的沟通。Agent有机会相互交流，以更新它们的当前状态、目标和下一步行动。
开发AI Agent到底用什么框架——LangGraph VS. LlamaIndex当使用一个框架来实现某个具体的multi-agent系统的时候，需要把上层系统的概念同底层抽象概念有效对应起来。
- 使用LangGraph来支持multi-agent的方案，节点可以表示LLM，可以表示某个Tool，可以表示任意的一段程序执行逻辑，也可以表示一个完整的Agentic System子图（也就是可以嵌套子图）。如何用LangGraph构建多Agent系统架构各个Agent被定义为图节点，Agent通过图状态进行通信。
- 使用LlamaIndex来支持multi-agent的方案，调用工具 (handletoolcall) 、调用模型 (speakwithsub_agent)、做路由分发 (orchestrator) ，等等这些逻辑，都使用一个step来实现（具体代码层面就是在方法上标注一个 @step的decorator）。 LlamaIndex的Workflow，只需要在方法上标注 @step，就能创建出一个step，非常灵活易用。但是对于step之间的执行偏序关系没法直接指定，只能通过声明和匹配事件类型来隐式地指定，不是那么方便。而LangGraph要求开发者显式地调用 add_node、 add_edge来构建执行图。这些用来构建图的代码，对于开发者的代码有一定的侵入，你需要去理解node、edge这些与你的业务逻辑无关的概念，并在代码中穿插调用它们。另外，不管是LlamaIndex还是LangGraph，对于multi-agent的上层封装都不太够。
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
google adk
https://google.github.io/adk-docs 官方文档将各个方面介绍的很全面
- 有类似BaseLLM、BaseTool等抽象，以及围绕这些抽象的Callbacks/Events（比如模型安全就可以通过Callbacks来做），这些是构成一个Agent的基本要素。
- 与langgraph相比，明确提出了BaseAgent抽象，具体有LLM Agents/Workflow Agents/Custom agents，以及围绕这些的Context/State传递与共享等。
- 在agent 之上提出了agent team（Agent.sub_agents，与agno 有些不同），进一步提出了几种Multi-Agent Patterns
- Coordinator/Dispatcher Pattern, A central LlmAgent (Coordinator) manages several specialized sub_agents.
- Sequential Pipeline Pattern, A SequentialAgent contains sub_agents executed in a fixed order.
- Parallel Fan-Out/Gather Pattern
- Hierarchical Task Decomposition, A multi-level tree of agents where higher-level agents break down complex goals and delegate sub-tasks to lower-level agents. PS：a.sub_agents=b, b.sub_agents=cd
- Review/Critique Pattern
- Iterative Refinement Pattern, Uses a LoopAgent containing one or more agents that work on a task over multiple iterations.
- Human-in-the-Loop Pattern PS: 总之agent 多起来之后，跟微服务一样，它们的组合关系也很多样，看业务需要。
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 未读