使用 Strands Agents 和 Amazon Nova 的多智能体协作模式

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/multi-agent-collaboration-patterns-with-strands-agents-and-amazon-nova/

原文作者：Julia Hu, Jessie-Lee Fry, Bhavya Sruthi Sode, David Rostcheck, and Rui Cardoso

多智能体生成式AI系统使用多个专业AI智能体协同工作，以处理超出任何单一模型能力的复杂、多方面任务。通过结合具有不同技能或模态（例如语言、视觉、音频、视频）的智能体，这些系统可以并行或按顺序处理任务，产生更稳健的结果。最新研究表明，多智能体协作可以显著提高复杂目标的成功率（比单一智能体方法高出70%）。对于此类多智能体协作，存在不同的模式。无论是像经理智能体委托专业任务（智能体作为工具）、头脑风暴者群（群智能体）、精心连接的专家智能体图（智能体图），还是结构化的管道（智能体工作流），正确的设计模式与正确的工具相结合，都将显著提高系统的有效性。

然而，多智能体系统的挑战在于其计算需求。现代多智能体应用可能会为每次用户请求发出数千个提示，因为智能体之间会进行头脑风暴、批判和完善彼此的答案。这种高强度的流程产生了两个关键要求：高吞吐量（每秒令牌数）和成本效率（每百万令牌的美元成本）。这正是 Amazon Nova 成为多智能体架构非常合适的基础模型 (FM) 选择的原因所在：

• 极速吞吐量：Nova Micro 的流式传输速度超过每秒 200 个令牌，首个令牌延迟不到一秒，即使是大型智能体群也能保持对最终用户的响应速度。
• 一致的结构化输出：借助最新的约束解码实现，Amazon Nova 模型可以生成一致的结构化输出，并提高工具调用准确性。
• 超低成本：团队可以利用 Nova Micro 和 Nova Lite 的低成本来负担多智能体推理所需的令牌量。

由于每个智能体调用的成本都很低，开发人员可以自由地让像开源 Strands Agents SDK 这样的编排框架启动特定任务的 Nova 智能体、重试或交叉验证答案，并进行迭代直到收敛到最佳结果——所有这些都无需担心失控的推理费用。反之，多智能体生成式AI系统通过以下方式释放了 Amazon Nova 的全部潜力：

• 迭代式自我改进：智能体可以要求 Nova 反思自己的答案，批判其弱点，并在无需任何微调的情况下，通常能将成功率提高两位数百分比。
• 冗余和故障转移：并行运行多个 Nova 智能体（例如共识或群模式）可以提高答案质量和弹性——一个弱响应会被多数否决或自动重试。

在本文中，我们将探讨多智能体、多模态AI系统的四种关键协作模式——智能体作为工具、群智能体、智能体图和智能体工作流——并讨论何时以及如何使用开源 AWS Strands Agents SDK 结合 Amazon Nova 模型来应用每种模式。Strands 作为一个智能体编排框架，其构建目标是轻量级且易于学习——它只使用少数几个概念，并依赖 Python 的原生结构来组合智能体。另一个优势是其模型驱动的方法：Strands 鼓励您让 FM 自己找出步骤顺序（智能体循环咨询 FM 下一步该做什么，而不是硬编码流程）。这利用了 FM 强大的推理能力来进行编排决策，减少了固定代码逻辑的工作量。 以下每个模式部分都提供了概念概述、图表、现实世界用例、优缺点以及代码示例来说明实现。

智能体作为工具模式

智能体作为工具模式将专业AI智能体封装为可调用的工具，供主要的协调器智能体调用。这创建了一个分层团队结构：一个顶层智能体充当经理，将特定查询委托给专家子智能体，然后集成它们的输出。每个工具智能体专注于特定的领域或模态，而协调器决定为用户请求的每个部分调用哪个工具。这种设置模仿了人类场景中团队领导咨询各种专家的情景，而不是试图独自完成所有工作。通过将工作分派给专家智能体，协调器可以提供比单一整体智能体更准确、更多方面​​的响应。

图 1：多模态智能体作为工具——一个协调器智能体（经理）使用专业的“工具”智能体（专家）来处理不同的子任务，然后将它们的结果汇总成最终答案。

用例、优点和缺点

当用户查询自然地分解为需要不同专业知识的独特子任务时，此模式最为理想。例如：

• 一个涉及差旅规划、产品推荐和研究等多个领域的助理——协调器可以将部分任务路由到差旅规划师、产品推荐者或研究员智能体。
• 多模态任务，其中一个智能体处理图像或语音输入，而另一个处理文本（协调器选择正确的特定模态智能体作为工具）。
• 任何需要专业技能或工具的系统（例如，教育辅导智能体调用代码执行智能体处理编程问题，或客服机器人调用数据库查询智能体）。

优点：

• 关注点分离：每个智能体都有一个集中的角色/专业知识，使整个系统更易于理解和扩展。
• 模块化：只要与协调器的接口保持一致，专家（工具）就可以独立添加或更新，而不会影响其他组件。
• 分层决策：协调器提供清晰的指挥链，决定为每个任务使用哪个专家，这可以提高可靠性。
• 优化性能：每个智能体都可以为其特定任务定制提示、模型或工具，潜在地提供比通才智能体更好的准确性或效率。

缺点：

• 协调器复杂性：顶层智能体必须正确识别应调用哪个工具智能体以及如何集成结果。这需要仔细的提示工程或路由逻辑（如果协调器误解了查询，则存在出错的风险）。
• 单点故障：协调器智能体成为关键组件；如果它失败或做出错误的决定，整个系统的输出可能会受到影响。
• 上下文共享和集成：专业智能体通常只接收包含在其特定查询中的信息，限制了它们对更广泛上下文的访问。因此，协调器必须整合来自不同智能体的输出。如果专家们孤立工作，确保最终答案的一致性（避免矛盾或遗漏）可能会很困难。

Strands SDK 示例

Strands Agents SDK 使用 @tool 装饰器将 Python 函数转换为可调用工具，从而可以轻松实现智能体作为工具。每个工具智能体本质上是一个具有自己提示或指令的 LLM（或其他服务），并作为可调用函数暴露。调用时，专家智能体仅接收协调器传递的信息（通常是特定的子任务提示）并返回其输出。然后，协调器在上下文中利用该输出，可能调用更多工具或产生最终答案。在以下代码中，我们定义了一个专业的研究助理智能体作为工具，然后创建了一个协调器来使用它（以及其他特定领域的智能体）来回答查询，查询结果可来自索引知识或网络搜索信息：

from strands import Agent
from strands_tools import retrieve, http_request # 定义一个专业的 Research Assistant 智能体作为工具
RESEARCH_ASSISTANT_PROMPT = (
    "You are a specialized research assistant. Provide factual, cited answers."
) @tool
def research_assistant(query: str) -> str:
    """Provide well-sourced research answers for a given query."""
    try:
        # 使用专注于研究的提示和工具创建一个智能体
        research_agent = Agent(
            system_prompt=RESEARCH_ASSISTANT_PROMPT,
            tools=[retrieve, http_request]  # 例如：多模态知识库检索、网络检索工具
        )
        response = research_agent(query)
        return str(response)
    except Exception as e:
        return f"Error in research assistant: {e}" 

以类似的方式，您还可以定义其他工具智能体，例如 editor_assistant 或 image_creation_assistant，每个智能体都有自己的系统提示和用于其领域的工具。定义好专家智能体后，协调器智能体就可以将它们包含在其工具列表中：

# 使用所有专业工具定义协调器智能体
MAIN_SYSTEM_PROMPT = "You are an orchestrator coordinating multiple domain experts."
orchestrator = Agent(
    system_prompt=MAIN_SYSTEM_PROMPT,
    tools=[research_assistant, editor_assistant, image_creation_assistant]
) # 通过协调器处理复杂的user查询
query = "I'm planning a hiking trip to Patagonia and need the right gear."
response = orchestrator(query)
print(response)

在这个例子中，协调器会将查询的不同部分委托给相关的专家——例如，使用研究助理，然后将该上下文传递给编辑器助理以根据提供的上下文生成内容，最后综合一个组合答案给用户。智能体作为工具模式通过 Strands 中简单的函数调用，实现了专家能力的强大组合。

此多模态电子邮件编写助理的完整代码示例和解决方案图（可随时运行和部署）可在此 Github 仓库中找到。

图 2： 使用“智能体作为工具”模式的多模态电子邮件编写助理的解决方案图。

有关更多信息，请参阅智能体作为工具文档。

群模式 (Swarm pattern)

群模式涉及一组对等智能体在一个任务上协同工作，直接和迭代地交换信息。这受到了自然界中群体智能的启发（如蚁群或蜂群），其中许多简单的单元体通过相互作用产生复杂的、涌现的行为。在AI群中，每个智能体可能会从不同的角度（或使用不同的数据或模式）来处理问题，并分享其发现，以便其他智能体可以完善自己的结果。没有中央控制器进行微观管理；相反，协调是去中心化的，通常通过共享内存或消息空间发生。因此，群通过多轮通信集体探索解空间并收敛到答案。

图 3： 群智能体——一个去中心化的智能体网络（例如：研究、创意、批判、总结者）相互通信，以协作解决问题。没有单一的协调者；智能体集体共享和完善思想时，涌现出智能。

群的关键特征包括信息共享、智能体专业化、冗余以及超越个体智能体总和的涌现智能潜力。重要的是，控制是去中心化的——没有单一的智能体为其他智能体决定角色。智能体遵循相对简单的局部规则（“与他人分享我的结果，然后在查看他人结果后修改我的答案”），复杂的全局行为源于这些互动。例如，一个智能体可能专注于创意头脑风暴，另一个专注于事实准确性，另一个专注于批判解决方案，最后一个专注于总结；通过两轮或更多轮的思想交流，它们共同产生一个平衡且经过充分验证的结果。

用例、优点和缺点

当问题受益于多样化的视角或并行探索时，群模式非常有用：

• 头脑风暴和构思：多个生成式智能体可以并行提出想法或解决方案（有些可能很疯狂且富有创意，有些则更保守），然后集体完善它们。这可以产生比单一智能体答案更具创新性的结果。
• 复杂推理任务：智能体可以通过结构化的交接来建立在彼此工作的基础上。例如，一个智能体分析问题，交接到另一个进行解决方案设计，再交接到第三个进行验证和完善。这种顺序协作通常产生比并行方法更高质量的结果。
• 多阶段工作流：不同的智能体可以处理复杂任务的不同阶段。在金融分析中，研究智能体收集数据，交接到分析智能体以获取见解，再交接到报告智能体以进行最终展示。每次交接都包含上下文和中间结果。
• 迭代改进：通过多次迭代和交接，群可以逐步完善解决方案。一个智能体的初始草稿会得到后续智能体的增强，每次迭代都在可配置的时间窗口内建立在先前工作的基础上。
• 容错处理：通过超时控制和交接机制，群可以优雅地处理智能体故障。如果一个智能体超时，群可以继续使用可用结果或使用其他智能体重试。

优点：

• 思想多样性：每个智能体都可以追求独特的策略或观点，从而产生更丰富的想法库。最终结果可以通过纳入所有智能体的输入而更加全面和平衡。
• 涌现式改进：通过迭代通信，群通常比单次传递的方法更能完善解决方案。智能体可以通过相互纠正错误或建立在彼此的部分解决方案之上，从而获得高质量的结果。
• 无单一故障点：由于没有中央协调器，系统的容错能力可能更强——如果一个智能体表现不佳，其他智能体可以进行补偿（并且没有一个智能体的失败会导致进程崩溃）。

缺点：

• 超时敏感性：过于严格的超时设置可能会切断富有成效的工作，而过于宽松的超时可能会导致资源使用效率低下，如果智能体卡住。
• 迭代开销：多次迭代可能会累积成本和延迟，特别是对于大型语言模型，需要在质量和效率之间进行仔细的权衡。

Strands SDK 示例

在以下示例中，群包含以下三个协作智能体：

• research_agent：查找事实信息
• analysis_agent：通过 API 分析实时市场数据
• writer_agent：编译最终答案

from strands import Agent
from strands.models import BedrockModel
from strands.multiagent import Swarm # 为不同任务创建专业智能体
research_agent = Agent(
    name="researcher",
    system_prompt="Research and gather information, then hand off to analyst.",
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0", region="us-east-1"),
    tools=[web_search, knowledge_base]
) analysis_agent = Agent(
    name="analyst",     system_prompt="Analyze research data and hand off to writer.",
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0", region="us-east-1"),
    tools=[data_analysis, financial_metrics]
) writer_agent = Agent(
    name="writer",
    system_prompt="Create final report based on research and analysis.",
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0", region="us-east-1"),
    tools=[editor, formatter]
) # 配置带有交接和超时控制的群
swarm = Swarm(
    agents=[research_agent, analysis_agent, writer_agent],
    max_handoffs=2,           # 允许智能体之间最多进行 2 次交接
    max_iterations=3,         # 最多 3 轮的完善
    execution_timeout=300.0,  # 总群超时时间（5 分钟）
    node_timeout=60.0        # 单个智能体超时时间（1 分钟）
)
# 执行协作工作流
result = swarm("Analyze Q3 financial performance and create executive summary")
print(f"Final result: {result.final_response}")
print(f"Collaboration path: {[node.node_id for node in result.node_history]}")

这种方法消除了手动协调代码的需求，并为协作模式提供了细粒度的控制。群自动管理智能体之间的交接、跟踪对话历史记录，并确认执行在指定的超时时间内完成。智能体可以专注于其专业任务，而群框架则处理复杂的编排、共享内存管理和容错机制。关键优势在于，复杂的多智能体工作流变得像配置几个参数一样简单，同时仍然通过交接和迭代机制支持复杂的协作模式。

此财务助理群智能体的完整代码示例和解决方案图（可随时运行和部署）可在此 Github 仓库中找到。

图 4： 财务助理群智能体的解决方案图。

有关更多信息，请参阅群文档。

图模式 (Graph pattern)

智能体图定义了一个结构化的智能体网络，具有定向连接，决定了信息如何在它们之间流动。与群的自由网状结构不同，智能体图通常由开发人员设计，以适应特定的工作流或组织层次结构。图中的每个节点都是一个具有明确定义角色的智能体，而每条边代表一个通信或交接通道（可以是单向或双向的）。此模式可帮助您对智能体间交互的顺序和方向实施精确控制。例如，您可以将智能体安排在多级层次结构中：一个顶层执行智能体将任务分解为部分，传递给中间经理智能体，这些经理智能体又委托给低级别专家智能体，结果再返回到链条上。或者，您可以定义一个星形拓扑结构，其中一个中心智能体协调一组外围智能体（类似于智能体作为工具，但可能有反馈循环），或任何适合问题领域的自定义图拓扑结构（树、有向无环图）。

图 5： 智能体图模式的说明。

智能体图如以下图表所示。（拓扑结构示例 – 分层）：以多级图连接的智能体。规划者智能体将查询委托给强大的主管智能体，然后委托给中层智能体智能体 1、智能体 2、智能体 3 和智能体 4；每个智能体都监督一个专家智能体团队。信息沿着定向边流动。分支可以纳入业务逻辑，根据条件边决定使用哪个智能体。 智能体图的关键优势在于可预测性和控制力。通过将智能体明确连接成图，开发人员可以验证一个事实核查智能体是否总是在生成智能体的输出到达最终报告者智能体之前对其进行验证，或者信息只以批准的方式流动（对安全很有用，除非需要，否则可防止某些智能体看到敏感数据）。此模式在您需要自定义通信模式、不同的专业角色和细粒度的信息流管理时表现出色。

用例、优点和缺点

当出现以下情况时，智能体图模式尤其出色：

• 您有复杂的、多阶段的决策过程，例如企业工作流，其中一个领导智能体委托给单独的分析智能体（财务、技术、社会影响分析），并且每个分析智能体可能进一步委托给子智能体。 图结构可以反映组织结构图或决策树，以便在更高级别上审查和整合每个步骤的输出。
• 您需要受控的工具访问和数据流：假设某些智能体可以调用外部工具或 API，而其他智能体不应这样做（出于安全或成本原因）。通过构建图，您可以隔离使用工具的智能体，并让其他智能体通过它们来引导请求。
• 避免“自由交流”：如果任务需要紧密的协调和明确的角色，智能体图比群更可取。例如，在具有多个智能体（计费、技术支持、销售）的客户支持系统中，您可能不希望它们都任意地相互通信。图可以强制所有通信都通过中央协调器或遵循定义的升级路径（如星形或树形拓扑结构）。

优点：

• 细粒度控制：开发人员明确定义了谁与谁通信。这可以防止意外的交互，并使系统的行为更易于推理，例如，当您知道报告聚合器智能体只接收来自事实核查和分析智能体的输入，而没有其他输入时。
• 上下文和状态管理：图的边可以被视为持久通道——可能维护状态或使用消息队列。这对于长期运行的上下文很有用。
• 可预测的执行流程：与群（其中交换的时序和顺序是涌现的）不同，智能体图遵循更确定性的流程。这有利于需要确定性输出或分步跟踪的工作流。使用图的路径来跟踪输入在系统中如何移动会更容易。

缺点：

• 设计工作量：确定正确的图拓扑结构可能很具有挑战性。您必须充分了解问题域，才能有效地划分任务和安排智能体。过度设计图可能会导致僵化；设计不足可能无法获得该模式的优势。
• 动态适应性较差：固定的图不如群那样具有自适应性。如果传入的查询略微超出了预期模式，被编排的路径可能无法优雅地处理它（除非您构建了大量的路由逻辑）。相比之下，群或工具方法可能通过简单地尝试不同的工具或智能体来动态调整。
• 深层图中的延迟：如果图具有许多级别（如高层级结构），信息必须通过多个智能体进行顺序传递，这可能会增加延迟。每次跳转都会增加开销。例如，在三级层次结构中，消息可能会向下流经两个中间智能体，然后再返回——这比扁平的架构需要更多的往返次数。

Strands SDK 示例

Strands SDK 中可用的 GraphBuilder 类提供了一种简化的方式来实现智能体图模式。它处理智能体通信和网络拓扑管理的复杂性，帮助开发人员专注于智能体行为。它内置支持定义智能体之间的图拓扑结构、消息处理（传输数据机制）和方向（单向或双向信息流）。对于每个智能体，开发人员可以实现业务逻辑来处理回退机制和智能体响应评估。

from strands import Agent
from strands_tools import agent_graph
builder = GraphBuilder() # 添加节点
builder.add_node(coord_agent, "research")
builder.add_node(get_stock_prices_agent, "stock_price_search")
builder.add_node(fin_web_searcher_agent, "fin_web_searcher")
builder.add_node(report_writer_agent, "report")
builder.add_node(image_generator_agent, "create_display_img") # 添加边（依赖项）- 协调器居中的星形拓扑结构
builder.add_edge("research", "stock_price_search")
builder.add_edge("research", "fin_web_searcher")
builder.add_edge("research", "report")
builder.add_edge("research", "create_display_img") # 设置入口点
builder.set_entry_point("research") # 构建图
graph = builder.build() # 运行图
result = graph("Analyze Q3 financial performance and create executive summary")

使用 GraphBuilder 来定义节点、边和入口点...

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。