一文读懂扣子上的多 Agent 模式

一文读懂扣子上的多 Agent 模式 一文读懂扣子上的多 Agent 模式 Modified November 4, 2024 17865 21957 第一种：当你面对一些通用指令时，可以选择已经训练好的、专门用于节点切换的大型模型。这种方法的优点是它已经经过了特定训练，不需要你额外操心设计。 第二种：如果你遇到非常复杂的情景，可能需要更灵活的解决方案（比如要从当前节点跳到不相邻节点时，或者需要更复杂的指定模型跳转的意图时）。这时，你可以考虑使用自定义的大型模型。通过这种方式，你可以根据自己的需求定制模型，编写特定的提示词，以适应更复杂的交互场景。 然而，根据实际测试，第二种设置的效果并不理想。这可能是因为某些模型在处理特定任务时缺乏足够的灵活性或适应性。所以推荐大家还是使用第一种，简单方便。 那么，在使用专门训练的意图识别模型进行节点切换时，我们需要特别注意两个关键点。首先，每个智能体的用途必须清晰明确。这意味着在设计和实现时，需要在每个智能体上清楚地标注其功能和目的。这样做有助于确保系统能够准确地识别和响应用户的意图。 其次，智能体的名称也非常重要。一个清晰、易于识别的名称不仅有助于用户理解每个智能体的角色，也是意图识别过程中的关键触发点。名称应简洁明了，便于系统识别和记忆。 三、测试 最后，让我们一起对整个流程进行测试。首先我们按照预定流程来，即：景点推荐—— 路线规划—— 食宿安排这个顺序来进行常规路线的跑通。 在跑通常规路线后，我们希望再做一些其它的景点推荐，于是我向其发出指令，其成功跳转回了起始点。 最后，再来试一下让其跳转到旅游路线规划节点。 OK，看起来算是初步成形了，接下来就是按需做进一步的调整和优化了。 四、总结 文章的最后，让我们快速对多 Agent 模式做一个小结，以便加深印象： 1. 多 Agent 模式中的设置分为全局设置和节点设置。在全局设置中，更应该注意角色定义和人物刻画，而后者更关注单个智能体中要详细执行的逻辑。 2. 要想让 Agent 达到互相协作的目的，应该在智能体编排中将首尾相连，不然就会成为线性工作流。 3. 单个 Agent 中两种跳转模式分别适用于通用和复杂的意图识别和跳转，一般的场景下，前者的效果更好，而后者适用更复杂的意图识别情景。 4. 在编排时，单个 Agent 的名称和适用场景应该明确设定好，以让节点跳转模型更好的识触发条件。 第一种：当你面对一些通用指令时，可以选择已经训练好的、专门用于节点切换的大型模型。这种方法的优点是它已经经过了特定训练，不需要你额外操心设计。 第二种：如果你遇到非常复杂的情景，可能需要更灵活的解决方案（比如要从当前节点跳到不相邻节点时，或者需要更复杂的指定模型跳转的意图时）。这时，你可以考虑使用自定义的大型模型。通过这种方式，你可以根据自己的需求定制模型，编写特定的提示词，以适应更复杂的交互场景。 然而，根据实际测试，第二种设置的效果并不理想。这可能是因为某些模型在处理特定任务时缺乏足够的灵活性或适应性。所以推荐大家还是使用第一种，简单方便。 那么，在使用专门训练的意图识别模型进行节点切换时，我们需要特别注意两个关键点。首先，每个智能体的用途必须清晰明确。这意味着在设计和实现时，需要在每个智能体上清楚地标注其功能和目的。这样做有助于确保系统能够准确地识别和响应用户的意图。 其次，智能体的名称也非常重要。一个清晰、易于识别的名称不仅有助于用户理解每个智能体的角色，也是意图识别过程中的关键触发点。名称应简洁明了，便于系统识别和记忆。 三、测试 最后，让我们一起对整个流程进行测试。首先我们按照预定流程来，即：景点推荐—— 路线规划—— 食宿安排这个顺序来进行常规路线的跑通。 在跑通常规路线后，我们希望再做一些其它的景点推荐，于是我向其发出指令，其成功跳转回了起始点。 最后，再来试一下让其跳转到旅游路线规划节点。 OK，看起来算是初步成形了，接下来就是按需做进一步的调整和优化了。 四、总结 文章的最后，让我们快速对多 Agent 模式做一个小结，以便加深印象： 1. 多 Agent 模式中的设置分为全局设置和节点设置。在全局设置中，更应该注意角色定义和人物刻画，而后者更关注单个智能体中要详细执行的逻辑。 2. 要想让 Agent 达到互相协作的目的，应该在智能体编排中将首尾相连，不然就会成为线性工作流。 3. 单个 Agent 中两种跳转模式分别适用于通用和复杂的意图识别和跳转，一般的场景下，前者的效果更好，而后者适用更复杂的意图识别情景。 4. 在编排时，单个 Agent 的名称和适用场景应该明确设定好，以让节点跳转模型更好的识触发条件。 You don't have permission to access this synced block. Please log in and try again. Log In 更系列文章合集请访问：蓝衣剑客 AIGC思维火花 蓝衣剑客 AIGC思维火花 一、起因 我之所以撰写这篇文章，缘于社群中一位朋友的学习经历。最近，他正在研究如何在扣子上实现多智能体模式。他的目标是让这些智能体能够协同合作，高效地完成特定任务。 遗憾的是，尽管官方文档提供了关于多智能体的意图识别和分发机制的示例，但它并没有涵盖多智能体在实际应用中所面临的复杂情况。这种单向的处理方式不支持多个智能体的循环串联操作，因此在实际环境中应用起来意义不大。 并且，如果仅仅依赖这个例子，你可能还会有一些困惑，就如这位朋友所发的图一样。（见下方） 面对这种挑战，我决定亲自接手这个任务。作为一个言出必行的人，我整理了一个案例，来讲述一下如何进行多智能体模式的配置，特别是如何拉通多智能体协作路径。这样不仅可以保证每个单独的智能体能够顺利完成任务，还可以灵活地切换到其他智能体进行协作。 二、设计 首先，让我们一起深入探索扣子上的多智能体模式设置。这个配置主要包括两个核心部分。第一部分是全局设置，涉及角色设定与回复逻辑、记忆管理以及对话体验等全局性因素。第二部分则关注于多个代理之间的编排和协调。这两大设置共同构成了多智能体模式的详细框架。 那么，我们首先需要解决的问题是：在全局设置中，人物设定与回复逻辑应如何填充？简单来说，我们需要在“人物设定与回复逻辑应”中明确整体的人物设定，这更侧重于角色的塑造，而非仅仅是业务流程的描述。（因为这是偏向于全局的设置） 接下来，我们来考虑一下智能体的交互流程。我们的设计思路的关键在于，让这些节点形成一个完整的互动链条，而不单单是一次性互动。同时，当用户的意图尚未满足跳转条件时，应保持与当前智能体的沟通和对话。 所以，我们的设计思路大概是这样的（见下图） Unable to load the board. Please refresh and try again.Copy ErrorRefresh Nothing on the board yet 此外，在观察这张图时，大家还可以发现一个关键点：我们在图中实现的是一个循环机制，而不是单向的流程。如果仅仅采用单向流程，那么将像工作流一样，随着对话的进行逐步跳转，直至最后一个智能体。在这种情况下，将无法从最后一个智能体跳转回初始状态。 因此，在设计需要多轮协作的智能体时，我们应该在多智能体编排页面中，设计这些智能体的交互为一个闭环结构。这确保了用户在整个对话过程中能够自由地在不同智能体之间切换，克服了单向交互的限制。 让我们通过一个具体的例子来更好地理解这一概念。以旅游场景为例，我们将设计三个智能体：分别负责景点推荐、路线规划和食宿安排。 让我们先把提示词写出来。 同时，我们还应做好全局人物设定： 当准备好提示词后，就可以开始在扣子上进行编排了，这里我省略了创建和填充的步骤，最终呈现的效果是这样的： 这里有几个关键点需要注意，首先是跳转设置问题。扣子在节点切换提供了独立和非独立两种识别模式，其中独立识别模式是像我们在之前的流程图中看到的：每个节点都有一个独立识别模型。 而非独立模式会直接使用当前智能体模型进行判断，说穿了，这种做法还是靠着 prompt 进行意图识别。 实际使用下来，我推荐前者。 那么前者又有两种选择（不得不说扣子的功能是真多，看的让人眼花缭乱），我们该选哪种？