Part.2: AI Agent 的工作流程模式 (Agentic Workflow Patterns) 

2.1 何时以及何时不使用代理 (When and when not to use agents)

2.1.1 简洁性原则 (Simplicity Principle)

2.1.2 Agent 的优势和适用场景:

• 复杂性 (Complexity): 当任务需要复杂的推理、规划、决策过程时，Agent 可以利用其内部的推理引擎和规划算法来处理这些复杂性。例如：
• 多步骤任务: 需要多个步骤才能完成的任务，例如旅行规划。Agent 可以将旅行规划分解成多个子任务，例如查询航班、预订酒店、安排行程等，并逐步完成每个子任务。
• 动态环境: 环境不断变化，需要 Agent 具备适应能力。例如股票交易 Agent 需要实时监控市场行情，并根据行情的波动调整交易策略。
• 不确定性: 任务的输入或环境存在不确定性，需要 Agent 具备鲁棒性。例如，客户支持 Agent 需要处理各种各样的用户问题，即使有些问题超出了预期的范围，也需要能够给出合理的答复。

• 个性化 (Personalization): 当任务需要根据用户的个性化需求进行定制时，Agent 可以利用其记忆和学习能力，提供个性化的服务。例如：
• 个性化推荐: 一个新闻推荐 Agent 可以根据用户的阅读历史和兴趣偏好，推荐用户可能感兴趣的新闻。
• 个性化教育: 一个 AI 助教可以根据学生的学习进度和能力水平，提供个性化的辅导和练习。

• 主动性 (Proactivity): 当任务需要主动执行，而不仅仅是被动响应时，Agent 可以根据预设的目标，主动采取行动。例如：
• 健康管理: 一个健康管理 Agent 可以主动提醒用户进行锻炼、服药或体检。
• 安全监控: 一个安全监控 Agent 可以主动监测系统状态，并在发现异常情况时发出警报。

• 长期运行 (Continuous Operation): Agent 可以长时间运行，持续监控环境和执行任务，例如 7*24 小时运行的客服 Agent，或者持续监控天气的 Agent.

• 与其他 Agent 或者与人协作 (Collaboration): 当任务需要复杂的协调与沟通, 单一的 Agent 或流程难以胜任时, 可以考虑构建多 Agent 系统, 各司其职, 或者采用人机协同的模式, 让人类专家介入 Agent 的工作流程。

2.1.3 Agent 的劣势和不适用场景:

• 开发和维护成本: Agent 的开发和维护成本通常比传统工作流更高，需要考虑的因素也更多, 需要有明确的 ROI。

• 性能开销: Agent 的推理和决策过程可能会带来较大的性能开销, 需要更强的算力, 可能会增加延时。

• 可解释性和可控性: Agent 的行为可能难以解释和预测, 在一些安全性要求较高的场景下需要谨慎使用。我们需要能够理解 Agent 的决策过程，并在必要时进行干预。

• 数据依赖: Agent 的性能通常依赖于大量的训练数据, 在数据稀缺的场景下可能难以发挥作用。

• 简单、确定的任务: 对于简单、确定的任务，例如数据格式转换、简单的计算等，使用传统的工作流更加高效。这类任务的执行步骤是固定的，不需要 Agent 的自主性和适应性。

• 静态、可预测的环境: 如果环境是静态的、可预测的，那么使用预定义的规则就足够了, 不需要 Agent 的动态规划和决策能力。

• 对实时性要求极高的场景: Agent 的决策过程可能需要一定的时间，在对实时性要求极高的场景下可能不适用，例如，自动驾驶中的紧急避障，需要毫秒级的响应速度，目前 Agent 可能难以胜任。

2.1.4 成本、延迟和性能的权衡:

• 开发成本: 构建 Agent 的复杂性带来的成本, 包括人力成本、时间成本、技术成本等。我们需要评估开发 Agent 的投入产出比，确保其带来的收益大于成本。

• 计算成本: 运行 Agent, 特别是进行复杂的推理和规划, 带来的计算资源消耗, 例如 CPU、GPU、内存等。我们需要根据实际的计算资源情况，选择合适的 Agent 架构和算法。

• 时间成本/延迟: Agent 做出决策并执行操作所需的时间, 包括推理时间、规划时间、工具调用时间等。我们需要考虑 Agent 的响应时间是否满足应用场景的需求, 是否需要针对延迟进行优化。

• 数据成本: 训练和维护 Agent 所需的数据量, 包括获取数据、清洗数据、标注数据等成本。我们需要考虑是否有足够的数据来训练和维护 Agent。

• 需要根据具体的应用场景，综合考虑成本、延迟、性能和效果等因素，选择合适的解决方案。 有时, 一个简单的基于规则的系统可能比一个复杂的 Agent 系统更有效。我们需要根据实际情况进行权衡, 选择最合适的方案。

2.1.5 Agent 与工作流的对比表格:

+---------------------+       +---------------------+
|    Traditional      |       |        Agent        |
|     Workflow        |       |                     |
+---------------------+       +---------------------+
| - 预定义流程         |       | - 动态决策          |
| - 线性执行           |       | - 适应性            |
| - 简单任务           |       | - 复杂任务          |
| - 低开发成本         |       | - 高开发成本        |
| - 高可解释性         |       | - 可解释性相对较低   |
+---------------------+       +---------------------+
     ^                                   ^
     |                                   |
     |                                   |
     +-----------------------------------+
              选择哪种方案取决于具体需求

      (图 16. Agent 与传统工作流对比)

2.2 常见工作流程模式 (Common Workflow Patterns)

2.2.1 检索增强生成 (Retrieval-Augmented Generation, RAG):

• 定义: RAG 模式是一种将检索 (Retrieval) 和生成 (Generation) 相结合的技术，Agent 首先从外部知识库 (例如向量数据库) 中检索与输入查询相关的信息，然后利用检索到的信息来增强 LLM 的生成能力，从而生成更准确、更相关的响应。 RAG 可以看作是 LLM 的 "外挂" 知识库, 使其能够利用外部信息来增强自身的生成能力。

• 原理: RAG 主要包含两个步骤:
1. 检索: 根据用户的输入 (例如, 一个问题或一个指令), 使用一个检索模型 (Retriever) 从预先构建的知识库 (例如, 向量数据库) 中检索相关的文档或段落。检索模型通常基于向量相似度计算, 例如计算查询向量和文档向量之间的余弦相似度。
2. 生成: 将检索到的文档或段落作为上下文 (Context), 与用户的输入一起输入到 LLM (Generator) 中, 由 LLM 生成最终的响应。LLM 会根据检索到的上下文信息来生成更准确、更相关的答案。

• 组成: RAG 通常由三个部分组成:
• Query Encoder: 负责将用户的问题 (Query) 编码成一个向量, 用于后续的检索步骤。
• Retriever: 负责从文档库中检索 (Retrieve) 相关文档。通常使用向量数据库, 并进行相似度检索, 例如使用余弦相似度来衡量 Query 向量和文档向量之间的相似度。
• Generator: 负责根据 Query 和检索到的文档 (Context) 生成答案, 通常是一个 LLM, 例如 GPT-4, LLaMA 3 等。

• 流程示意:

+----------+       +----------+       +-------------+
|  Query   |------>| Retriever|------>|  Generator  |
| Encoder  |       +----+-----+       | (LLM +      |
+----------+            |             |  Context)   |
                        |             +-------------+
                        |             |
                        v             v
                +--------------+   +-------------+
                |  Document    |   |    Answer   |
                |  Store      |   +-------------+
                +--------------+

(图 12. RAG 工作流程示意图)

• 优点:
• 知识增强: RAG 可以利用外部知识库来增强 LLM 的生成能力, 使其能够回答超出其预训练知识范围的问题, 并提供更丰富的信息。
• 减少幻觉: 通过提供相关的上下文信息, RAG 可以减少 LLM 产生幻觉 (生成不符合事实的内容) 的可能性, 提高生成结果的可靠性, 因为 LLM 现在可以基于检索到的文档进行生成, 而不是仅仅依赖于自身的参数化记忆。
• 可定制性: 可以根据具体的应用场景, 定制和更新知识库, 使 Agent 具备特定领域的知识。例如, 构建一个医学领域的 RAG 系统, 可以使用医学文献数据库作为知识库。
• 可解释性: 由于 RAG 的生成过程依赖于检索到的文档, 因此可以追溯生成结果的来源, 提高可解释性。这对于需要解释 AI 决策的场景非常重要。
• 数据安全: RAG 可以使用本地部署的知识库, 避免将敏感数据上传到云端, 从而提高数据的安全性。这对于处理私有或专有信息的企业尤其重要。

• 缺点:
• 依赖于检索的质量: RAG 的性能很大程度上取决于检索到的文档的质量, 如果检索到的文档不相关或质量较低, 则会影响最终的生成结果。需要不断优化检索模型和知识库, 以提高检索的准确性和覆盖率。
• 计算开销: 检索过程可能会带来额外的计算开销, 特别是当知识库非常庞大时。需要对检索过程进行优化, 例如使用高效的向量索引和检索算法, 以及使用缓存机制来提高检索速度。
• 需要维护知识库: 需要定期更新和维护知识库, 以确保信息的准确性和时效性。这需要投入一定的人力和物力, 以及建立合适的知识库维护流程。

• 适用场景:
• 问答系统: RAG 可以用于构建问答系统, 根据用户的问题从知识库中检索相关的答案, 并生成最终的响应。例如, 构建一个基于公司内部文档的问答系统, 帮助员工快速找到所需的信息; 或者构建一个基于产品手册的问答系统, 帮助客户解答产品使用中的疑问。
• 信息检索: RAG 可以用于构建信息检索系统, 根据用户的查询从文档库中检索相关的文档。例如, 构建一个基于学术论文的检索系统, 帮助研究人员查找相关的文献; 或者构建一个基于法律法规的检索系统, 帮助律师查找相关的法律条文。
• 对话系统: RAG 可以用于构建对话系统, 根据用户的对话历史和当前的上下文, 生成更加相关和自然的回复。例如, 在客服对话系统中, 使用 RAG 可以根据用户的历史订单信息和当前的对话内容, 提供更加个性化的服务; 或者在闲聊机器人中, 使用 RAG 可以根据用户的兴趣爱好, 生成更具吸引力的对话内容。

• 示例: 一个医疗问答 Agent, 可以使用 RAG 技术, 从医学文献数据库中检索与用户问题相关的信息, 并生成更准确、更专业的回答。例如, 当用户询问“流感的症状有哪些”时, RAG 系统可以从医学文献中检索相关的段落, 并将其作为上下文提供给 LLM, LLM 可以根据这些信息生成更准确的回答, 例如 "流感的常见症状包括发烧、咳嗽、喉咙痛、肌肉酸痛、头痛和疲劳等, 具体症状可能因人而异。这些信息摘自 [某医学文献的标题] 这篇文献。"

• 与其他模式的组合: RAG 可以与其他工作流程模式结合使用, 例如, 可以将 RAG 作为路由 (Routing) 的一个分支, 根据问题的类型, 决定是将问题路由给 RAG 模块进行知识库检索, 还是路由给其他模块进行处理; 也可以将 RAG 的结果作为评估者-优化器 (Evaluator-Optimizer) 的输入, 利用 RAG 生成的多个候选答案, 并通过评估者进行筛选和排序, 最终选择最优的答案。

2.2.2 提示链 (Prompt Chaining):

• 定义: 提示链模式将一个复杂的任务分解成多个子任务, 并将每个子任务的输出作为下一个子任务的输入, 通过多个提示 (Prompt) 串联起来, 逐步完成整个任务。这种模式类似于 “链式反应”, 前一个步骤的输出触发下一个步骤的执行, 形成一个链式的处理流程。

• 原理: 将一个复杂的 Prompt 分解成多个简单的 Prompt, 每个 Prompt 负责完成一个子任务, 并将输出传递给下一个 Prompt。通过这种方式, 可以将复杂任务的执行过程分解成多个更小、更易于管理的步骤, 从而降低任务的难度，提高执行的可靠性。提示链的核心思想是“分而治之”，将复杂问题分解成一系列可管理的子问题。

• 优点:
• 简化复杂任务: 将复杂任务分解成多个简单的子任务, 降低了每个子任务的难度, 更容易构建和调试。每个子任务都可以独立设计和优化, 提高了开发的效率。
• 提高可控性: 可以通过调整每个子任务的提示来控制 Agent 的行为, 对 Agent 的输出进行更精细的控制, 从而更好地引导 Agent 完成任务。
• 提高可复用性: 可以将一些通用的子任务的提示保存下来, 并在不同的任务中重复使用, 例如, 可以将“文本摘要”或“实体识别”等子任务的提示保存下来, 并在其他任务中复用, 从而减少重复开发的工作量。
• 增强可解释性: 通过将任务分解成多个步骤, 可以更清晰地了解 Agent 的执行过程, 便于调试和优化。每个步骤的输入和输出都清晰可见, 便于追踪和理解 Agent 的行为。

• 缺点:
• 需要预先定义好任务的分解方式: 提示链模式需要预先定义好任务的分解方式, 以及每个子任务的输入和输出, 缺乏一定的灵活性, 难以应对任务需求的变化, 需要人工干预来重新设计提示链。
• 错误传播: 如果一个子任务的输出出现错误, 可能会影响后续所有子任务的执行结果, 需要进行错误检测和处理, 增加了系统的复杂性。
• 效率可能较低: 由于需要多次调用 LLM, 可能会导致执行效率降低, 特别是当 LLM 调用是串行的, 并且后一个步骤依赖于前一个步骤的输出时。

• 适用场景:
• 需要多个步骤才能完成的任务: 例如, 撰写一篇长篇报告、进行数据分析、制定旅行计划、进行软件开发等。这些任务通常可以分解成多个子任务, 每个子任务都可以通过一个 Prompt 来完成。
• 任务的分解方式比较明确的场景: 例如, 可以将一个复杂的数学问题分解成多个简单的计算步骤, 或者将一个软件开发任务分解成需求分析、设计、编码、测试等多个阶段。

• 示例: 一个内容生成 Agent, 可以使用提示链模式, 将“写一篇关于 AI Agent 的博客文章”分解成以下几个步骤:
1. 生成文章大纲: 第一个 Prompt 可以是 “请为一篇关于 AI Agent 的博客文章生成一个大纲, 包括 3-5 个主要章节。”
2. 根据大纲生成每个章节的内容: 后续的 Prompt 可以根据大纲中的每个章节标题, 分别生成相应的内容, 例如 “请根据以下章节标题, 生成一段关于 AI Agent 定义的介绍: [章节标题]”。
3. 对生成的文章进行润色和修改: 最后一个 Prompt 可以用于对生成的文章进行润色和修改, 例如 “请检查以下文章是否存在语法错误和逻辑问题, 并进行修改: [文章内容]”。
通过这种方式, 可以将一个复杂的写作任务分解成多个简单的步骤, 并逐步完成。

+----------+     +---------+      +---------+       +------------+
| Input    |---->| Prompt 1|----->| Prompt 2|-----> | Prompt N   |------>| Output     |
| (Task)   |     |         |      |         |       |            |       | (Result)   |
+----------+     +---------+      +---------+       +------------+
     ^               |              |                       |
     |               v              v                       v
     |          +---------+      +---------+       +------------+
     |          | Subtask |      | Subtask |       | Subtask    |
     |          |    1    |      |    2    |       |    N       |
     +----------+---------+      +---------+       +------------+

                (图 17. 提示链工作流程示意图)

2.2.3 路由 (Routing):

• 定义: 路由模式根据用户的输入或当前的上下文, 将任务分配给不同的 Agent 或模块来处理。路由模式可以看作是一个 “任务分发器”, 它根据任务的类型和特点, 将其分配给最合适的执行单元, 从而实现任务的专业化处理。

• 原理: Agent 内部维护一个路由器 (Router), 路由器根据一定的规则 (例如, 关键词匹配、意图识别、语义理解等) 将任务分配给不同的处理器 (Handler), 每个处理器负责处理特定类型的任务。路由的核心在于 路由规则 的设计, 需要根据具体的应用场景进行定制。

• 优点:
• 提高效率: 可以将不同类型的任务分配给最擅长处理该任务的 Agent 或模块, 提高任务处理的效率和专业性。例如, 一个客服 Agent 可以将技术问题分配给技术支持 Agent, 将订单问题分配给订单处理 Agent, 从而提高客户服务的效率和质量。
• 增强灵活性: 可以根据需要添加或删除处理器, 从而扩展 Agent 的能力, 而无需修改路由器的逻辑, 增强了系统的灵活性和可维护性。
• 提高可维护性: 可以将不同类型的任务的处理逻辑分离到不同的处理器中, 提高代码的可维护性和可读性, 每个处理器可以独立开发和测试。
• 支持多种数据源: 可以将不同数据来源的任务分配给不同的处理器, 例如, 将来自向量数据库的查询路由给 RAG 模块, 将来自 Web 的查询路由给搜索引擎。

• 缺点:
• 需要设计合理的路由规则: 路由规则的设计需要根据具体的应用场景进行定制, 以确保任务能够被正确地分配给合适的处理器。 需要大量的测试和调优才能得到较好的路由规则。
• 可能增加系统的复杂性: 引入路由机制可能会增加系统的复杂性, 需要考虑路由器的实现和维护成本, 以及不同处理器之间的交互和数据传递。
• 路由决策的准确性: 路由器的决策准确性直接影响 Agent 的性能, 如果路由错误, 可能会导致任务处理失败或效率低下。需要使用高效的意图识别或分类算法来保证路由的准确性。

• 适用场景:
• 需要处理多种不同类型的任务: 例如, 一个智能客服 Agent 可以根据用户的问题类型, 将问题路由给不同的业务部门, 例如将售前咨询路由给销售 Agent，将售后问题路由给售后 Agent, 将一般问题路由给 FAQ 机器人。
• 需要集成多个不同的 Agent 或模块: 例如, 一个智能家居 Agent 可以将控制灯光的任务路由给灯光控制模块, 将控制空调的任务路由给空调控制模块, 将播放音乐的任务路由给音乐播放模块。
• 需要根据上下文选择不同处理流程: 例如, 一个 Agent 可以根据用户的历史行为或当前的对话上下文, 选择不同的处理流程, 例如, 对于新用户, 可以路由到新手引导流程; 对于老用户, 可以路由到常规服务流程。

• 示例: 一个智能客服 Agent 可以根据用户的意图，将问题路由给不同的业务 Agent，例如将售前咨询路由给销售 Agent，将售后问题路由给售后 Agent，将技术问题路由给技术支持 Agent。路由规则可以基于关键词匹配、意图识别或机器学习模型来实现。例如, 如果用户的问题中包含“购买”、“订单”等关键词, 则可以将其路由给销售 Agent; 如果用户的问题中包含“退货”、“维修”等关键词, 则可以将其路由给售后 Agent。

• 与 RAG 的结合: 路由可以与 RAG 结合, 例如根据问题的类型, 决定是将问题路由给 RAG 模块进行知识库检索, 还是路由给其他模块进行处理。在我们的例子中, 可以根据问题是否与已有的知识库 (向量数据库) 相关, 来决定是路由给向量数据库进行检索, 还是路由给 Web 搜索来获取信息。例如, 如果用户的问题是“什么是 AI Agent？”, 而知识库中有相关的文章, 则可以将问题路由给 RAG 模块; 如果用户的问题是“明天的天气如何？”, 则可以将问题路由给 Web 搜索工具。

+-----------------+       +-----------------+       +-----------------+
|   User Input    |------>|      Router     |------>|  Handler 1      |
|   (Question)    |       | (Routing Logic) |       | (e.g., RAG)     |
+-----------------+       +--------+--------+       +-----------------+
                                   |
                                   | Route based on
                                   | question type,
                                   | context, etc.
                                   v
                             +--------+-----------+
                             |      Handler 2     |
                             | (e.g., Web Search) |
                             +--------------------+
                                   ^
                                   |
                                   | Results/
                                   | Response
                                   v
                            +-----------------+
                            |      Agent      |
                            +-----------------+
                            |  Final Response |
                            +-----------------+

                (图 13. Agent 使用路由模式)

2.2.4 并行化 (Parallelization):

• 定义: 并行化模式将一个任务分解成多个子任务, 并 同时 执行这些子任务, 从而提高任务处理的效率。并行化模式利用了现代计算机的多核处理器或分布式系统的计算能力, 通过并行执行来缩短任务的执行时间。

• 原理: 将一个大的任务分解成多个独立的子任务, 并将这些子任务分配给不同的处理器或计算节点同时执行, 最后将子任务的结果合并起来, 得到最终的结果。并行化的关键在于任务的分解和结果的合并，以及避免子任务之间的冲突。

• 优点:
• 提高效率: 通过并行执行, 可以显著缩短任务的执行时间, 特别是对于计算密集型任务, 效果尤为明显。
• 充分利用计算资源: 可以充分利用多核处理器或分布式系统的计算能力, 提高资源的利用率, 避免资源闲置。
• 增强可扩展性: 可以通过增加处理器或计算节点的数量, 来提高系统的处理能力。

• 缺点:
• 需要处理数据同步和一致性问题: 在并行执行的过程中, 需要确保不同子任务之间的数据同步和一致性, 避免数据竞争和冲突。这需要使用锁、信号量等同步机制, 或者使用分布式数据存储, 或者设计无锁的并行算法。
• 可能增加系统的复杂性: 并行化可能会增加系统的复杂性, 需要考虑任务的分解、调度、同步、合并等问题。
• 调试难度增加: 并行程序的调试通常比串行程序更困难, 需要考虑并发执行带来的各种问题, 例如死锁、竞态条件等。
• 并非所有任务都适合并行化: 只有能够分解成多个独立子任务的任务才适合并行化, 对于一些串行依赖性强的任务, 并行化可能无法带来明显的效率提升, 甚至可能降低效率。

• 适用场景:
• 计算密集型任务: 例如, 大规模数据处理、图像渲染、科学计算、机器学习模型训练等。这些任务通常可以分解成多个独立的子任务, 并在不同的处理器上并行执行。
• 可以分解成多个独立子任务的任务: 例如, 并行处理多个用户的请求、并行处理多个文档、并行执行多个查询等。
• 需要实时响应的场景: 通过并行化可以缩短任务的执行时间, 从而提高系统的响应速度, 例如, 在实时图像处理、实时语音识别等场景中, 可以使用并行化来提高处理速度。

• 示例:
• 一个图像处理 Agent 可以将一张大图片分割成多个小块, 并分配给多个处理器进行并行处理, 最后将处理结果合并起来, 从而加速图像处理的速度。例如, 可以使用并行化来进行图像的缩放、裁剪、滤镜等操作。

+-----------------+     +-----------+     +------------+
|   Image Input   |---->|  Splitter |---->|  Section 1 | ---+
+-----------------+     +-----+-----+     +------------+    |
                              |                             |  Processor 1
                              |                             |
                              v                             |
                        +-----+-----+     +------------+    |
                        |  Section 2 | ---+------------+    |
                        +------------+    |            |    |
                              |                             | (Concurrent)
                              |                             |  Processor 2
                              v                             |
                        +-----+-----+     +------------+    |
                        |  Section N | ---+            |    |
                        +------------+    |            v    |
                              |             |        +------------+
                              +------------>|  Merger    |
                                            +------------+
                                            |   Output   |
                                            +------------+
         (图 18. 图像处理并行化示意图)

• 一个数据分析 Agent 可以将一个大型数据集分割成多个子集, 并分配给多个处理器进行并行分析, 最后将分析结果汇总起来, 从而缩短数据分析的时间。例如, 可以使用并行化来计算数据的统计指标、进行数据挖掘等。
• 一个 Web 服务器可以同时处理多个用户的请求, 每个请求都由一个独立的线程或进程来处理, 从而提高服务器的吞吐量。例如, Apache、Nginx 等 Web 服务器都支持多线程或多进程模式, 可以并行处理多个 HTTP 请求。

• 两种实现方式:
• 分段 (Sectioning): 将输入数据分成多个部分, 分别进行处理, 最后合并结果。例如, 将一个大型文档分成多个段落, 分别进行文本摘要, 然后将每个段落的摘要拼接起来, 得到整个文档的摘要。

+-----------+            +-------------+        +-------------+
|  Data     |----------> |  Section 1  |------->|  Process 1  |----+
|  Input    |            +-------------+        +-------------+    |
+-----------+            +-------------+         +-------------+   |   +----------+
|            +---------->|  Section 2  |-------> |  Process 2  |-->    |  Merger  |
|            |            +-------------+        +-------------+   |   +----------+
|            |            ...                                      |   |  Output  |
|            |            +-------------+         +-------------+  |   +----------+
+------------+---------->|  Section N  |------->  |  Process N |---+
                           +-------------+        +-------------+

            (图 19. 分段并行化示意图 - 修正版)

• 投票 (Voting): 对相同的输入数据, 使用多个不同的 Agent 或模型进行处理, 然后根据投票结果决定最终的输出。例如, 对同一个问题, 使用多个不同的 LLM 生成答案, 然后根据投票结果选择最佳答案。这种方式可以提高结果的可靠性和鲁棒性, 避免单个 Agent 或模型的偏差或错误。

+------------+
| Data Input |
+------------+
     |
     |
     |-------------------+-------------------+-------------------+
     |                   |                   |                   |
     v                   v                   v                   v
+-----------+       +-----------+       +-----------+       +-----------+
|  Agent 1  |       |  Agent 2  |       |    ...    |       |  Agent N  |
+-----------+       +-----------+       +-----------+       +-----------+
     |                   |                   |                   |
     | Result 1          | Result 2          |                   | Result N
     v                   v                   v                   v
+-----------------------------------------------------------------+
|                            Voting                           |
+-----------------------------------------------------------------+
                         |
                         v
                    +------------+
                    |  Output    |
                    +------------+

          (图 20. 投票并行化示意图)

• 并行化与 RAG 的结合: 可以对 RAG 的检索阶段进行分段并行化, 例如, 将知识库分成多个分片, 每个分片由一个独立的检索器进行检索, 然后将检索结果合并起来; 也可以对生成阶段进行投票并行化, 例如, 对同一个问题和上下文, 生成多个候选答案, 然后根据投票结果选择最佳答案, 或者将多个答案融合起来。

2.2.5 调度器-工人 (Orchestrator-Workers):

• 定义: 调度器-工人模式将 Agent 分成两种类型: 调度器 (Orchestrator) 和工人 (Worker)。调度器负责将任务分解成子任务, 并将子任务分配给工人执行, 最后将工人返回的结果合并起来, 或者根据结果进行进一步的处理。这种模式类似于“管理者-员工”的模式, 调度器负责任务的分配和协调, 工人负责具体任务的执行。

• 原理:
• 调度器维护一个任务队列, 工人从任务队列中领取任务并执行。
• 调度器可以根据任务的类型和工人的能力, 动态地分配任务。
• 工人执行完任务后, 将结果返回给调度器。
• 调度器可以根据工人的执行结果, 决定是否需要进一步处理, 例如, 将结果合并、排序、过滤等。

• 优点:
• 任务分配更灵活: 调度器可以根据任务的类型和工人的能力 (例如, CPU 密集型、IO 密集型、特定领域知识), 动态地分配任务, 实现更精细的任务调度。
• 易于扩展: 可以通过增加工人的数量来提高系统的处理能力, 只需要增加工人节点, 而不需要修改调度器的逻辑, 易于水平扩展。
• 提高资源利用率: 工人可以专注于执行特定类型的任务, 提高资源的利用率, 例如, 可以将擅长不同任务的 Agent 作为工人, 从而实现 Agent 的专业化分工。
• 增强容错性: 如果某个工人出现故障, 调度器可以将任务重新分配给其他工人, 从而提高系统的容错性。
• 支持异构 Agent: 不同的工人可以是不同类型的 Agent, 具有不同的能力和专长, 从而实现 Agent 系统的多样性和异构性。

• 缺点:
• 需要设计合理的调度算法: 调度算法的优劣直接影响系统的性能, 需要根据具体的应用场景进行定制, 例如, 需要考虑任务的优先级、工人的负载均衡、任务的执行时间等因素。
• 可能存在单点故障: 如果调度器出现故障, 整个系统将无法正常工作, 需要考虑调度器的容错机制, 例如, 使用多个调度器进行备份或使用分布式调度算法。
• 需要处理任务之间的依赖关系: 如果任务之间存在依赖关系, 调度器需要考虑任务的执行顺序, 例如, 一个任务的执行结果是另一个任务的输入, 这就需要调度器进行任务的依赖关系管理。

• 适用场景:
• 任务可以分解成多个不同类型子任务的场景: 例如, 一个复杂的项目管理任务可以分解成需求分析、设计、开发、测试等多个子任务, 每个子任务可以由不同的工人 (Agent) 来执行。
• 需要动态分配任务的场景: 例如, 一个客户服务系统可以根据客户问题的类型, 将问题分配给不同的客服 Agent, 例如, 将技术问题分配给技术支持 Agent, 将账单问题分配给财务 Agent。
• 需要并行处理大量任务的场景: 例如, 一个 Web 爬虫系统可以使用调度器-工人模式, 调度器负责生成 URL 列表, 工人负责下载和解析网页, 从而实现大规模网页的并行抓取。

• 示例: 一个 Web 爬虫 Agent 可以使用调度器-工人模式, 调度器负责生成 URL 列表, 工人负责下载和解析网页, 最后将解析结果 (例如, 提取的文本、图片等) 返回给调度器, 调度器可以将解析结果存储到数据库中, 或者进行进一步的处理。例如, 调度器可以将 URL 分配给多个下载器工人, 下载器工人负责从不同的网站下载网页, 解析器工人负责从下载的网页中提取信息, 最后由调度器将提取的信息存储到数据库中。

• 与 RAG 的结合: 调度器可以将 RAG 相关的检索任务分配给检索工人, 将生成任务分配给生成工人。例如, 调度器可以将用户的查询分解成多个子查询, 并将每个子查询分配给一个检索工人, 检索工人从不同的知识库中检索相关的信息, 然后将检索结果返回给调度器, 调度器将检索结果合并后, 分配给生成工人, 生成工人根据合并后的检索结果生成最终的答案。

 +-----------+        +--------+       +--------+
 | Orchestrator|------->| Worker |       | Worker |
 | (Scheduler)|        |  1     |       |  2     |
 +-----+-----+        +---+----+       +---+----+
       ^                  |                |
       |                  v                v
       |          +------------+    +------------+
       |          | Task Queue |    | Task Queue |
       |          +------------+    +------------+
       |                  ^                ^
       |                  |                |
       +------------------+----------------+
            Results/Feedback

          (图 14. 调度器-工人模式示意图)

2.2.6 评估者-优化器 (Evaluator-Optimizer):

• 定义: 评估者-优化器模式包含两个 Agent: 评估者 (Evaluator) 和优化器 (Optimizer)。评估者负责评估当前方案的质量, 优化器负责根据评估者的反馈, 生成新的方案或对现有方案进行改进, 通过迭代的方式不断优化方案, 直到找到最优解或满足特定条件。这种模式类似于“反馈-改进”的循环，评估者提供反馈，优化器根据反馈进行改进, 通过不断的迭代, 逐步逼近最优解。

• 原理: 评估者和优化器交替工作, 优化器生成方案 (例如, 一个投资组合、一个文本段落、一段代码等), 评估者评估方案的质量并给出评分或反馈意见 (例如, 投资组合的收益率、文本的流畅度、代码的执行效率等), 优化器根据评估结果, 调整自身的策略或参数, 生成新的方案或对现有方案进行改进, 如此循环, 直到找到最优解或满足特定条件 (例如, 达到预设的迭代次数或评估分数)。

• 优点:
• 能够找到较优的解决方案: 通过迭代优化的方式, 可以逐步逼近最优解, 或者找到满足特定条件的解决方案, 尤其适用于难以直接求解的问题。
• 适用于难以直接求解的问题: 对于一些难以直接求解的问题, 例如 NP-hard 问题, 可以使用评估者-优化器模式来寻找近似解或满意解, 例如, 可以使用该模式来求解旅行商问题、背包问题等。
• 可解释性: 通过观察评估者和优化器的交互过程, 可以了解方案的优化过程, 以及每一步改进的原因, 从而提高 Agent 的可解释性。
• 灵活性: 可以根据具体的应用场景, 设计不同的评估函数和优化算法, 从而实现对不同类型问题的优化。

• 缺点:
• 计算开销较大: 需要多次迭代才能找到较优解, 计算开销较大, 特别是当评估者和优化器的计算成本较高时, 例如, 评估一个复杂的投资组合的收益率可能需要大量的计算。
• 可能陷入局部最优: 如果评估函数或优化算法设计不合理, 可能会陷入局部最优解, 而无法找到全局最优解。例如, 如果优化算法的搜索空间有限, 或者评估函数存在多个局部最优值, 则可能会导致优化过程停滞在局部最优解。需要精心设计评估函数和优化算法, 以避免陷入局部最优。
• 需要调整的参数较多: 评估者和优化器通常都有一些参数需要调整, 例如学习率、迭代次数、种群大小等, 参数的设置对最终的结果影响较大, 需要进行仔细的调优, 才能获得较好的性能。

• 适用场景:
• 优化问题: 例如, 旅行商问题、背包问题、参数调优、投资组合优化、路由优化、结构优化等。
• 需要不断改进方案的场景: 例如, 设计优化、策略优化、代码优化、模型优化、超参数优化等, 需要根据反馈不断改进方案的场景。
• 生成式任务: 例如, 文本生成、图像生成、音乐生成等, 评估者可以评估生成内容的质量 (例如, 流畅度、相关性、创造性等), 优化器可以根据评估结果改进生成模型, 例如, 调整模型的参数或策略, 以生成更高质量的内容。

• 示例:
• 一个代码优化 Agent 可以使用评估者-优化器模式, 评估者负责评估代码的性能 (例如, 执行时间、内存占用等), 优化器负责根据评估结果修改代码 (例如, 改变算法、优化数据结构、使用更高效的库函数等), 通过迭代的方式不断提高代码的性能。
• 一个文本生成 Agent 可以使用评估者-优化器模式, 评估者负责评估生成文本的质量 (例如, 流畅度、相关性、逻辑性、语法正确性等), 优化器根据评估结果, 调整生成模型的参数或策略 (例如, 使用不同的 Prompt, 或者调整生成温度等), 以生成更高质量的文本。
• 一个投资组合优化 Agent 可以使用评估者-优化器模式, 评估者负责评估投资组合的收益率和风险, 优化器负责根据评估结果调整投资组合的配置, 通过迭代的方式不断优化投资组合, 以实现收益最大化和风险最小化。

• 与 RAG 的结合: 评估者可以使用 RAG 技术来评估生成内容的质量, 例如, 评估生成的内容是否与检索到的文档相关, 是否符合事实, 是否存在逻辑错误等。优化器可以根据评估者的反馈, 调整 RAG 的参数或策略, 例如, 调整检索的关键词、检索的文档数量、生成时的 Prompt 等, 以生成更高质量的内容。例如, 在生成论文摘要时, 评估者可以利用 RAG 技术, 检索与论文相关的文献, 并评估生成的摘要是否涵盖了文献中的关键信息, 优化器可以根据评估者的反馈, 调整生成摘要的策略, 例如, 使用更具概括性的 Prompt, 或者从检索到的文献中提取更相关的信息。

+-------------+       +-----------------+       +-------------+
|  Optimizer  |------>|    Candidate    |------>|  Evaluator  |
|             |       |    Solution     |       |             |
+-------------+       +-----------------+       +------+------+
      ^                                                |
      |                                                | Feedback/Score
      |                                                v
      +------------------------------------------------+
                          Iteration

             (图 15. 评估者-优化器模式示意图)

2.2.7 基于拍卖的机制 (Auction-based Mechanisms):

• 定义: 在多 Agent 系统中, Agent 可以通过拍卖的方式来竞争任务的执行权或资源的分配权。拍卖机制是一种常用的分布式资源分配方法, 可以用于协调多个 Agent 之间的行为, 实现资源的有效分配. 特别适用于资源稀缺且多个 Agent 存在竞争关系的场景。

• 原理: Agent 根据自身对任务或资源的估价进行出价, 出价最高 (或最低, 取决于具体场景) 的 Agent 获得任务的执行权或资源的分配权。拍卖过程通常包含以下几个步骤: 1. 发布拍卖信息 (例如, 任务描述、资源信息、拍卖规则等); 2. Agent 进行出价; 3. 拍卖结束, 确定中标者; 4. 执行任务或分配资源。

• 优点:
• 资源分配高效: 可以将任务或资源分配给最需要、最合适的 Agent, 从而提高资源的利用率和任务执行的效率。例如, 将任务分配给报价最低 (效率最高) 的 Agent。
• 激励相容: 在合理的拍卖机制下, Agent 有动机报出自己的真实估价, 从而保证拍卖结果的有效性。例如, 在密封价格拍卖中, Agent 不知道其他 Agent 的出价, 因此会倾向于报出自己的真实估价。
• 去中心化: 拍卖机制可以在没有中心协调者的情况下运行, 每个 Agent 都可以独立地参与拍卖, 从而提高系统的鲁棒性和可扩展性。
• 灵活性和适应性: 拍卖机制可以适应不同的场景和需求, 例如, 可以根据任务的紧急程度或资源稀缺程度来调整拍卖规则, 例如, 紧急任务可以采用快速拍卖机制, 而稀缺资源可以采用多轮拍卖机制。

• 缺点:
• 需要设计合理的拍卖机制: 拍卖机制的设计需要考虑多个因素, 例如拍卖的类型 (例如, 英式拍卖、荷兰式拍卖、密封价格拍卖等)、出价的方式 (例如, 公开喊价、密封投标等)、结算的规则等, 不同的拍卖机制会产生不同的结果。设计不合理的拍卖机制可能会导致资源分配效率低下, 甚至引发 Agent 的恶意竞争。
• 可能存在欺诈行为: Agent 可能会虚报自己的估价, 例如, 在竞标任务时故意报高价, 或者在竞标资源时故意报低价, 以获取不正当利益。需要设计机制来防止或惩罚欺诈行为, 例如, 要求 Agent 提供保证金, 或者对 Agent 的历史行为进行评估。
• 通信开销: 拍卖过程需要 Agent 之间进行通信, 可能会带来一定的通信开销, 特别是在 Agent 数量较多或通信网络不稳定的情况下, 需要考虑通信的效率和可靠性。
• 计算开销: Agent 需要评估任务或资源的价值, 并根据自身情况进行出价, 这可能需要一定的计算开销, 特别是当 Agent 需要进行复杂的估价计算时。

• 适用场景:
• 多 Agent 任务分配: 例如, 多个机器人竞争执行同一个任务, 例如, 在仓库中, 多个机器人竞争搬运同一个货物, 可以将搬运任务拍卖给出价最低的机器人。
• 多 Agent 资源分配: 例如, 多个 Agent 竞争使用有限的计算资源、带宽资源或电力资源, 例如, 在云计算平台中, 多个虚拟机竞争 CPU、内存等资源, 可以将资源分配给出价最高的虚拟机。
• 动态环境: 适用于环境动态变化, 需要 Agent 实时调整自身行为的场景, 例如, 在交通系统中, 车辆可以根据路况实时调整行驶路线, 并通过拍卖的方式竞争道路的使用权。

• 示例: 在自动驾驶领域, 多个自动驾驶汽车可以通过拍卖的方式来竞争道路的使用权, 例如, 在十字路口, 多个车辆可以根据自身的目的地、行驶速度、到达时间等因素, 对通过路口的权利进行出价, 出价最高的车辆优先通过, 从而避免碰撞和提高通行效率。例如, 一辆救护车可以对通过路口的权利报出非常高的价格, 从而优先通过路口。

+---------+       +---------+       +---------+
| Agent 1 |       | Agent 2 |       | Agent 3 |
+---+-----+       +---+-----+       +---+-----+
    |                 |                 |
    |    Bid (Task A) |                 |
    v                 v                 v
+---------------------------------------+
|           Auctioneer               |
|   - Collects Bids                  |
|   - Determines Winner (e.g., highest bid)|
|   - Awards Task/Resource           |
+---------------------------------------+
    ^                 ^                 ^
    |                 |                 |
    |  Awarded Task  |                 |
    |                 +-----------------+
    |                      Not Awarded
    +-----------------------> Agent 2
       Executes Task

          (图 21. 基于拍卖的机制示意图)

2.2.8 基于协商的机制 (Negotiation-based Mechanisms):

• 定义: 在多 Agent 系统中, Agent 可以通过协商的方式来达成一致, 例如分配任务、共享资源、解决冲突等。协商机制是一种常用的分布式决策方法, 可以用于协调多个 Agent 之间的行为, 达成互惠互利的合作方案。 协商可以看作是多 Agent 之间的一种沟通和协调机制。

• 原理:
• Agent 之间通过交换信息、提出建议、讨价还价等方式, 最终达成一个所有 Agent 都同意 (或可接受) 的方案。
• 协商过程通常包含多个回合, 每个回合中, Agent 可以根据其他 Agent 的提议, 调整自身的策略, 直到达成一致或协商失败 (例如, 超过预设的最大回合数)。
• 协商的核心在于 协商协议 的设计, 需要明确协商的内容、协商的流程、协商的终止条件、以及每个 Agent 的权利和义务等。

• 优点:
• 能够达成共赢的方案: 通过协商, Agent 可以找到一个对所有参与者都有利的方案, 实现帕累托最优 (Pareto Optimality), 即在不使任何一个 Agent 的境况变差的情况下, 不可能再使其他 Agent 的境况变得更好。
• 能够处理复杂的利益关系: 协商机制可以处理 Agent 之间存在复杂的利益冲突和依赖关系的情况, 例如, 多个 Agent 既有合作关系, 又有竞争关系, 可以通过协商来平衡各方的利益, 找到一个折中方案。
• 增强系统的灵活性和适应性: 通过协商, Agent 可以根据环境的变化和自身的需求, 动态地调整自身的行为和策略, 以达成更优的方案, 从而提高系统的灵活性和适应性。
• 提高决策的合理性和公平性: 协商机制可以让所有 Agent 都参与到决策过程中, 从而提高决策的合理性和公平性, 避免了单方面决策可能带来的偏见和不公平。

• 缺点:
• 协商过程可能比较耗时: Agent 之间需要进行多轮交互才能达成一致, 特别是当 Agent 数量较多, 或者 Agent 之间的利益冲突较大时, 协商过程可能会非常耗时, 需要设计高效的协商策略来提高协商效率。
• 可能无法达成一致: 如果 Agent 之间的利益冲突过大, 或者协商机制设计不合理, 可能无法达成一致, 导致协商失败, 需要设计备选方案来处理协商失败的情况, 例如, 引入仲裁者, 或者使用默认方案。
• 需要设计合理的协商协议: 协商协议的设计需要考虑多个因素, 例如协商的语言、协商的流程、协商的终止条件等, 不同的协商协议会产生不同的结果, 需要根据具体的应用场景进行定制。
• 可能存在欺骗行为: Agent 可能会故意提供虚假信息, 或者采取欺骗策略, 以获取不正当利益, 例如, 在协商过程中, 一个 Agent 可能谎报自己的需求或能力, 以获得更多的资源或利益。需要设计机制来防止或惩罚欺骗行为, 例如, 引入信誉机制, 或者对 Agent 的承诺进行验证。

• 适用场景:
• 多 Agent 任务分配: 例如, 多个 Agent 协商如何分配一个复杂的任务, 每个 Agent 负责其中的一部分子任务, 需要协商确定每个 Agent 的职责和协作方式。
• 多 Agent 资源分配: 例如, 多个 Agent 协商如何共享有限的资源, 例如, 多个机器人协商如何使用同一个充电桩, 或者多个 Agent 协商如何分配有限的带宽资源。
• 多 Agent 冲突解决: 例如, 多个 Agent 在执行任务的过程中发生了冲突, 需要通过协商来解决冲突, 例如, 两个机器人在狭窄的通道相遇, 需要协商谁先通过, 或者两个 Agent 同时需要使用同一个工具, 需要协商使用顺序。
• 需要 Agent 之间进行合作的场景: 例如, 多个 Agent 需要合作才能完成一个任务, 例如, 多个机器人合作搬运一个重物, 需要协商各自的动作和力度, 以保持物体的平衡和稳定。

• 示例: 在供应链管理中, 多个供应商 (Agent) 可以通过协商的方式来决定供货的价格和数量, 例如, 一个供应商可以根据自身的生产能力和成本, 提出一个报价, 其他供应商可以根据自身的需求和市场行情, 进行还价, 最终达成一个双方都能接受的协议, 实现供应链的协同优化。

+---------+      +---------+      +---------+
| Agent 1 |------| Agent 2 |------| Agent 3 |
+---------+      +---------+      +---------+
    |                 |                |
    | Proposal (A)    |                |
    v-----------------|                |
    |      Accept (A)  |                |
    |<----------------|                |
    |                 | Proposal (B)   |
    |                 |<---------------|
    |                 |   Reject (B)   |
    |                 |--------------->|
    |                 |                | Modify Proposal (B')
    |                 |                |<---------------|
    |                 |  Accept (B')  |
    |<----------------|<---------------|
    |                 |                |
    v                 v                v
+---------------------------------------+
|           Agreement Reached          |
+---------------------------------------+

          (图 22. 基于协商的机制示意图)

2.2.9 迭代式 (Iterative)

• 定义: 迭代式工作流程模式指的是 Agent 反复执行某一个或多个步骤，并在每次迭代中根据反馈或环境变化调整自身行为，直至达成目标或满足特定条件。这种模式强调的是 Agent 的持续学习、适应和改进能力。迭代式模式常见于需要不断优化和精进结果的任务中, 例如: 机器学习模型的训练, 机器人控制等。

• 原理:
• Agent 首先基于当前的状态和目标, 执行一个或多个步骤, 并得到一个中间结果。
• Agent 评估中间结果, 并根据评估结果或环境的反馈, 调整自身的策略或参数。
• Agent 基于调整后的策略或参数, 再次执行步骤, 得到新的中间结果。
• Agent 重复上述步骤, 直到满足特定的终止条件, 例如达到预设的迭代次数、结果达到预期的质量、或者环境状态满足特定要求等。

• 优点:
• 适应性强: 能够根据环境的变化和反馈信息, 动态调整自身的行为, 适应不同的场景和需求。
• 鲁棒性好: 即使在初始状态不理想或者环境存在噪声的情况下, 也能够通过迭代的方式逐步改进, 最终达到目标状态。
• 能够处理复杂问题: 对于难以一次性解决的复杂问题, 可以通过迭代的方式逐步逼近最优解, 将问题分解成多个阶段, 降低了解决问题的难度。
• 持续学习: Agent 可以从每次迭代中学习经验, 不断优化自身的策略和参数, 从而提高未来的性能。

• 缺点:
• 可能需要多次迭代: 迭代式模式需要多次执行步骤才能达到目标, 可能会消耗较多的时间和计算资源, 特别是当每次迭代的计算成本较高时。
• 终止条件难以确定: 如何确定合适的终止条件, 是一个需要仔细考虑的问题, 过早终止可能会导致结果不理想, 过晚终止则会浪费资源。
• 可能陷入局部最优: 如果迭代策略设计不合理, 可能会导致 Agent 陷入局部最优, 而无法达到全局最优。需要设计有效的迭代策略, 例如引入随机性、探索新的解决方案等, 以避免陷入局部最优。

• 适用场景:
• 机器学习模型的训练: 例如, 使用梯度下降算法训练神经网络, 需要多次迭代更新模型的参数, 直到模型的损失函数收敛到最小值。
• 机器人控制: 例如, 机器人通过反复试验, 学习如何保持平衡、行走、抓取物体等。
• 游戏 AI: 例如, 围棋 AI 通过自我对弈, 不断提升自身的棋力。
• 优化问题: 例如, 旅行商问题、背包问题等, 可以通过迭代的方式寻找最优解或近似解。
• 需要不断改进和优化的场景: 例如, 文本生成、图像生成、代码优化等, 可以通过迭代的方式不断改进生成结果的质量。

• 示例:
• 模型训练: 训练一个机器学习模型, 例如, 使用梯度下降算法迭代更新神经网络的权重。
• 机器人学习: 一个机器人学习如何行走, 通过反复尝试不同的步态, 并根据传感器反馈的信息调整自身的动作, 最终学会稳定的行走方式。
• 游戏 AI: 一个围棋 AI, 通过自我对弈, 不断改进自身的棋力, 在每次对弈中, AI 会评估当前的棋局, 选择最佳的落子位置, 并在对弈结束后, 根据胜负结果调整自身的策略。
• 文本润色: 一个文本生成 Agent, 可以反复修改生成的文本, 直到达到预期的质量, 例如, Agent 可以先生成一个初稿, 然后根据语法规则和流畅度进行评估, 并根据评估结果进行修改, 如此反复, 直到生成的文本符合要求。

+-----------------+
|   Initial State  |
+--------+--------+
         |
         v
+--------+--------+      +-----------------+
|   Iteration 1   |----->| Evaluation/     |
|                 |      | Feedback        |
+--------+--------+      +--------+--------+
         |                          |
         v                          | Adjustment/
+--------+--------+      +-----------------+   Update
|   Iteration 2   |----->| Evaluation/     |
|                 |      | Feedback        |
+--------+--------+      +--------+--------+
         |                          |
         v                          |
    (Repeat until           +-----------------+
     termination          |   Termination   |
     criteria are met)     |   Criteria Met? |
         |                  +--------+--------+
         |                          | Yes
         v                          v
+-----------------+      +-----------------+
|    Final State  |      |   Final Output  |
+-----------------+      +-----------------+

      (图 26. 迭代式工作流程模式示意图)

• 定义: 开发者可以根据具体的应用场景和需求, 组合 上述的常见模式, 或者 设计 全新的工作流程模式, 以满足特定的需求。自定义模式的核心在于 灵活性 和 针对性, 可以根据任务的特点、环境的特点、Agent 的能力, 量身定制最合适的工作流程。

• 原理: 自定义模式通常没有固定的原理, 它依赖于开发者对 Agent 应用场景的深入理解, 以及对各种工作流程模式的灵活运用。开发者需要根据实际情况, 选择合适的模式进行组合, 或者设计新的模式来满足需求。

• 优点:
• 最大的灵活性: 可以根据具体的应用场景和需求, 设计最合适的工作流程模式, 不受已有模式的限制。
• 能够解决特定问题: 对于一些特殊的应用场景, 已有的模式可能无法满足需求, 这时就需要自定义新的模式, 以解决特定的问题。
• 可以充分发挥 Agent 的能力: 可以根据 Agent 的能力, 设计最能发挥其优势的工作流程模式。

• 缺点:
• 设计难度较大: 自定义模式需要开发者对 Agent 的应用场景和工作流程有深入的理解, 并且需要具备较强的设计能力。
• 开发成本较高: 自定义模式通常需要从头开始设计和实现, 开发成本较高。
• 可复用性较低: 自定义模式通常针对特定的应用场景, 可复用性较低。

• 适用场景:
• 已有的模式无法满足需求的场景: 例如, 需要处理一些非常特殊的任务, 或者需要将 Agent 应用于一些全新的领域。
• 需要充分发挥 Agent 能力的场景: 例如, 希望 Agent 能够更加智能、更加自主地完成任务。
• 需要对 Agent 的工作流程进行精细控制的场景: 例如, 希望 Agent 能够按照特定的步骤执行任务, 或者希望 Agent 能够根据不同的情况采取不同的行动。

• 示例:
• 结合 RAG、路由和工具的智能助手: 对于一个智能助手 Agent, 可以根据用户的查询类型, 动态选择不同的工作流程。如果用户查询的是知识类问题, 可以使用 RAG 模式; 如果用户查询的是天气, 可以使用工具模式; 如果用户需要执行某个特定任务, 可以使用路由模式将其分配给相应的子 Agent。
• 基于状态机的工作流程: 对于一个需要执行复杂流程的任务, 可以将 Agent 的工作流程定义为一个状态机, Agent 根据当前的状态和接收到的事件, 在不同的状态之间进行转换, 并执行相应的操作。例如, 一个订单处理 Agent, 可以将订单处理流程定义为一个状态机, 包括“待付款”、“待发货”、“已发货”、“已完成”等状态, Agent 根据订单的状态和用户的操作, 在不同的状态之间进行转换, 并执行相应的操作, 例如, 当订单状态为“待付款”时, Agent 可以发送付款提醒; 当订单状态为“待发货”时, Agent 可以调用物流接口进行发货。
• 基于进化算法的工作流程: 可以使用进化算法来自动生成和优化 Agent 的工作流程, 例如, 可以使用遗传算法来搜索最优的提示链组合, 或者使用强化学习来训练 Agent 的调度策略。

+-----------------+       +-------------+       +-------------+
|  User Input    |------>|   Router    |------>|   Module A  |
|   (Question)    |       |  (Decision  |       +-------------+
+-----------------+       |   Logic)    |             |
                              +------+------+             |
                                     |                     |
                                     |                     |
                                     v                     v
                            +-----------------+       +-------------+
                            |  Context Mgr    |       |   Module B  |
                            |   (RAG, etc.)   |       +-------------+
                            +--------+--------+             |
                                     |                     |
                                     v                     v
                            +-----------------+       +-------------+
                            |   Reasoner      |       |   Tool      |
                            | (e.g., ReAct,   |       |  Executor   |
                            |  Chain of      |       +-------------+
                            |  Thought)      |             |
                            +--------+--------+             |
                                     |                     |
                                     v                     v
                            +-----------------+       +-------------+
                            |    Executor    |       |   Delegator |
                            | (e.g., Tool     |       +-------------+
                            |   Calls)       |             |
                            +--------+--------+             |
                                     |                     |
                                     v                     v
                            +-----------------+       +-------------+
                            |    Finalizer   |------>|   Output    |
                            |  (Response     |       +-------------+
                            |   Generation)  |
                            +-----------------+

                     (图 25. 自定义工作流程模式示例)

总结: