📢 转载信息
原文作者：Yoav Fishman, Dan Kolodny, and Elior Farajpur
我第一次尝试构建一个差旅规划智能体时，它看起来和大多数早期原型一样：一个大的模型、几个工具和一条很长的系统提示词。直到现实世界的复杂性出现时，它才显得勉强可用。航班信息来自一个干净的API，酒店信息隐藏在一个不断变化的网页UI后面，而模型则不断地混淆指令、忘记上下文或编造步骤。这时就很明显了：单个智能体不是解决方案，它反而是瓶颈。
找到解决方案意味着要拆分工作，而不是试图修复提示词。本文将通过使用 Amazon Bedrock 上的智能体间协作，利用 Amazon Nova 2 Lite 进行规划，以及使用 Amazon Nova Act 进行浏览器交互，将一个脆弱的单智能体设置转变为一个可预测的多智能体系统。
解决方案概述
该系统被构建为一小群协同工作的智能体，如下图所示。一个智能体负责规划工作并与用户对话。其他智能体则处理特定任务，如航班搜索或酒店搜索。它们通过简单的消息进行通信，因此每个智能体都能保持专注，并且任务推理起来很简单。
当我看到单智能体设计崩溃的地方时，这种模式就很明显了：智能体之所以挣扎，不是因为任务本身很难，而是因为任务本质上是不同的。航班搜索是结构化的、可预测的。而酒店搜索是混乱的、视觉化的，充满了动态元素。强迫一个模型同时处理这两者，就像要求同一个工程师既要编写后端API，又要实时手动点击一个网站。我越是用提示词、更多工具和更多回退逻辑来修补它，情况就越糟。当一个智能体承担了过多的责任时，它会变慢、丢失上下文、做出不一致的选择，最终因自身重量而崩溃。问题出在设计上，试图通过提示词来解决是行不通的。解决方案是将工作分配给三个智能体，让每个智能体专注于单一职责。差旅智能体负责处理用户意图和规划。航班智能体负责与结构化的航班API通信。而酒店智能体则使用浏览器自动化来导航真实的酒店网站。不再是一个超负荷的模型，而是每个智能体都能把一件事做好——并通过一个简单的消息传递层进行协调，这样从外部看，整个工作流程仍然是无缝的。每个智能体都有一个非常明确的工作。差旅智能体是协调者，负责解释请求、将其分解为步骤，并决定哪个智能体应该执行每个部分。航班智能体完全专注于结构化API调用，那里的数据是可预测的。而酒店智能体则负责处理混乱的部分：导航网页、处理动态布局以及从真实网站提取酒店详情。以这种方式分离系统，可以保持逻辑清晰，并防止单个智能体再次超载。
为了使这种设置奏效，智能体之间需要一种简单的通信方式。差旅智能体必须向航班智能体发送清晰的请求，等待结果，然后用下一步指令触发酒店智能体。我们不需要花哨的东西，只需要一种轻量级的消息格式，智能体可以传递，这样每个智能体都知道下一步该做什么。当这个通信循环建立起来后，整个工作流程终于感觉像是协调一致的，而不是充满了动态布局且没有公共API的混乱页面。使用同一个智能体处理这两者通常会导致工具过载、指令混乱，并增加产生幻觉的风险。
实现概述
现在架构已经清晰了，是时候实际构建系统了。这时，每个智能体背后的工具就派上用场了。差旅智能体和航班智能体都使用 Amazon Nova 2 Lite 进行推理和规划，航班智能体还调用结构化的航班API来检索真实数据。当没有API时，酒店智能体则依赖 Amazon Nova Act 来自动化浏览器交互。这三个智能体通过一个直截了当的智能体到智能体（A2A）消息传递模式进行通信，智能体交换小型、结构化的消息来协调工作，即使每个智能体在不同的执行环境中运行，也能使工作流程保持可预测。在多智能体系统中，协调与专业化同等重要。智能体需要一种结构化、可预测的方式来交换目标、共享状态和触发行为，尤其是在协作完成像规划旅行这样的任务时。
差旅智能体实现 (Amazon Nova 2 Lite)
差旅智能体是整个工作流程的协调者。它接收用户请求，使用 Amazon Nova 2 Lite 解析意图，并决定下一步应该调用哪个智能体。Nova 2 Lite 在这里承担了繁重的推理工作——它将输入分解为步骤，确定何时触发航班智能体或酒店智能体，并跟踪整体计划。由于差旅智能体不直接接触外部系统，它的唯一工作是清晰地思考并通过 A2A 路由消息。
以下代码示例是差旅智能体初始化方式的简化版本：
# Initialize A2A client tools provider = A2AClientToolProvider(known_agent_urls=[ "http://localhost:9000", # Hotel Booking Expert (NovaAct) "http://localhost:9001" # Flight Booking Expert ]) bedrock_model = BedrockModel( model_id="global.amazon.nova-2-lite-v1:0", region_name="us-east-1", ) # Create client agent with A2A tools client_agent = Agent( name="Travel Client", model=bedrock_model, description="Client agent that coordinates travel planning using specialized A2A agents", tools=provider.tools, system_prompt="""You are an autonomous travel planning agent. You MUST take action immediately without asking for confirmation."""在实践中，差旅智能体接收一个单一的自然语言请求，例如“请在 7 月 10 日为我查找从纽约到东京的航班，并预订酒店直到 7 月 15 日。”从那里开始，Amazon Nova 2 Lite 执行繁重的推理：它识别出需要两个独立任务，生成清晰的计划，向航班智能体发送消息，等待结果，然后用下一步指令触发酒店智能体。最后，它将两个输出组合成一个连贯的响应。这使得编排逻辑保持干净和流畅。Nova 2 Lite 有效地充当了工作流程的大脑，而专业智能体则负责实际执行。
航班智能体实现 (Amazon Nova 2 Lite 和 API)
航班智能体的任务要窄得多：将结构化请求转化为真实的航班选项。它使用 Amazon Nova 2 Lite 进行所需的轻量级推理，用于验证输入、格式化搜索，并决定是调用实时航班API，还是在没有凭据时退回到模拟数据。API 调用完成后，该智能体会通过 A2A 将一个干净、可预测的 JSON 响应发送回差旅智能体。
以下代码示例展示了简化的航班搜索工具版本。完整的实现，包括 OAuth、回退逻辑和机场代码处理，可在 Agent to Agent with Amazon Nova GitHub 仓库中找到：
@tool
def search_flights(origin: str, destination: str, departure_date: str, return_date: Optional[str] = None) -> str: # Nova 2 Lite handles the reasoning around which path to take if amadeus_configured(): return _search_amadeus_flights( origin=origin, destination=destination, departure_date=departure_date, return_date=return_date ) else: # Local development fallback return _search_flights_web(origin, destination, departure_date, return_date)
{ "flights": [ { "flight_number": "DL456", "price": 520, "duration": "14h 30m" }, { "flight_number": "JL701", "price": 545, "duration": "13h 50m" } ], "source": "Amadeus API"
}
由于该智能体处理的是干净、结构化的数据，因此推理负载很轻，Amazon Nova 2 Lite 的工作主要是选择正确的执行路径和标准化输出。这使得整个管道保持可预测性，并避免将特定于 API 的逻辑嵌入到差旅智能体内部。
酒店智能体实现 (Amazon Nova Act)
酒店与航班完全不同。你无法调用一个干净的API，而且大多数预订网站加载内容的方式每次访问都会发生变化。这就是 Amazon Nova Act 发挥作用的地方。酒店智能体使用 Nova Act 来控制一个真实浏览器，并遵循自然语言指令。代理无需编写脆弱的抓取代码，只需告诉 Nova Act 它需要什么，而 Nova Act 负责浏览并返回结构化数据。
以下是该工具的简化版本：
@tool
def search_hotels(location: str, checkin_date: str, nights: int = 2) -> str: with NovaAct() as nova: result = nova.act( f"Search for hotels in {location} from {checkin_date} for {nights} nights. " f"Return the top 3 listings with name, price, and rating.", schema=HotelSearchResults.model_json_schema() ) return json.dumps(result)这是一个简化的响应示例。完整的代码，包括滚动、Cookie 横幅和其他细节，都在 Agent to Agent with Amazon Nova GitHub 仓库中：
{ "hotels": [ { "name": "Shinjuku Grand", "price": "$180", "rating": 4.3 }, { "name": "Park Tower Tokyo", "price": "$210", "rating": 4.6 }, { "name": "Hotel Blossom", "price": "$155", "rating": 4.0 } ], "source": "Anycompany.com via Nova Act"
}
使用 Amazon Nova Act 可以防止酒店智能体在网站布局更改时每次都崩溃。通过使用它，你可以避免编写自己的抓取或 DOM 解析逻辑。
A2A 消息流（智能体如何通信）
现在每个智能体都知道自己的职责，它们需要一种相互通信的方式。在差旅智能体开始发送实际工作之前，它首先通过调用其他智能体的 A2A 端点来检查它们是否已启动。它还会加载每个智能体暴露的工具列表，以便 Nova 2 Lite 知道可用的功能。完成这些后，流程就很简单了。差旅智能体将一个消息发送给航班智能体，其中包含它需要的字段。当航班智能体完成时，它会发送一条消息回来。然后差旅智能体将下一个消息传递给酒店智能体。每条消息都是一个小的 JSON 对象，包含操作、输入数据以及将响应发送到的位置等信息。
端到端示例运行
下面是一个完整的运行示例。用户向差旅智能体发送单个请求：
Please arrange travel for one person from NYC to Paris on December 6, 2025, including a two night stay in Paris.- 差旅智能体 -> 航班智能体：
- 差旅智能体从请求中提取航班部分并将其发送给航班智能体。
- 航班智能体返回从 JFK 到巴黎的三个直飞、廉价航班，包括航空公司、时间、价格和持续时间。
- 差旅智能体 -> 酒店智能体：
- 差旅智能体将请求的酒店部分发送给酒店智能体。
- 酒店智能体使用 Nova Act 检查巴黎的酒店，并返回前三个选项的名称、价格和简短说明。
- 最终结果呈现给用户
- 差旅智能体组合两个答案并发送回清晰的摘要，其中包括：
- 推荐的航班
- 推荐的酒店
- 入住和退房日期
- 价格
- 询问是否预订的问题
结论
使用三个小型智能体构建这个差旅规划器，比使用一个大型智能体更容易管理。每个智能体专注于一项工作，而 Amazon Nova 2 Lite 则负责在步骤之间推进工作的必要思考。Amazon Nova Act 负责处理那些没有 API 的部分，例如酒店搜索，而无需编写抓取代码。A2A 消息流使所有内容保持连接，但结构仍然很简单。
这种设置并不局限于差旅。混合了不同技能组合的任务可以采用相同的思路：让一个智能体规划工作，让其他智能体完成它们擅长的部分，并在它们之间传递小型消息。这使得系统易于修改和解释。
如果你想自己尝试一下，完整的代码和示例都在 Agent to Agent with Amazon Nova GitHub 仓库中。
关于作者
Yoav Fishman 是 AWS 解决方案架构师，拥有 12 年的云和工程经验，专注于生成式 AI、智能体 AI 和网络安全。他指导初创公司（从早期到成长期）构建安全、可扩展的架构并实施推动业务影响的智能体 AI 流程。
Elior Farajpur 是 AWS 的解决方案架构师，在云领域拥有 7 年的经验，热衷于 AI 和云技术。他帮助组织设计创新的云解决方案，以推动真正的业务价值。
Dan Kolodny 是 AWS 解决方案架构师，专注于大数据、分析和生成式 AI。他热衷于帮助客户采用最佳实践、从数据中发现见解并拥抱新的生成式 AI 技术。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区