跳转至

Scalable voice agent design with Amazon Nova Sonic: multi-agent, tools, and session segmentation

📊 Level ⭐⭐⭐ | 12.0KB

来源：原文存档

核心要点

  • AWS Nova Sonic 支持多智能体架构、工具调用和会话分段
  • 三种架构模式：单智能体（工具直接调用）、路由多智能体（sub-agent as tool）、会话分段（session segmentation）
  • 与 DynamoDB、Kendra 等 AWS 服务深度集成
  • 基于 Amazon Bedrock AgentCore Runtime 和 Strands BidiAgent 框架
  • MCP 协议用于工具调用，A2A 协议用于 agent-to-agent 通信 → 原文存档

相关实体

深度分析

三种集成模式的架构哲学

文章提出了三种递进的集成模式，每种模式对应不同的延迟-复杂度权衡： Pattern 1: AgentCore Gateway — 工具直接调用（最低延迟） Nova Sonic 通过 AgentCore Gateway 直接调用 MCP 服务器上的工具，无需中间推理层。语音模型理解意图 → 选择工具 → 传递参数 → 获得结果 → 语音回复，全流程在语音模型端完成。 这个模式的局限在于：复杂工作流（多步验证、条件逻辑、链式调用）的推理负担完全落在语音模型的 system prompt 上。当工具数量增加时，工具选择本身成为性能瓶颈。 Pattern 2: Sub-Agent（Agent-as-Tool）— 解耦推理 语音 orchestrator 将完整任务委托给子智能体，每个子智能体有自己的模型、system prompt、工具和推理能力。Strands 支持两种连接方式：

  • Local agent-as-tool：子智能体在进程内运行，无网络延迟，但与 orchestrator 共用进程和扩展资源

  • Remote agent via A2A：子智能体部署在 AgentCore Runtime 上独立运行，通过 A2A 协议通信。A2A 是连接不同框架（Strands、OpenAI、LangGraph、Google ADK）构建的智能体的开放协议 关键延迟权衡： 子智能体调用会增加延迟（子智能体自身推理 + 工具调用），对于语音对话场景意味着「更长的沉默」。AWS 建议子智能体使用 Amazon Nova 2 Lite 等小型高效模型来控制延迟。 Pattern 3: Session Segmentation — 超低延迟 这是针对语音场景专门设计的模式，不是 MCP 或 A2A 的直接映射。在同一 WebSocket 连接内，当对话从一个阶段转换到另一个阶段（如认证 → 账户查询 → 抵押贷款询问）时，关闭当前 Nova Sonic 会话并打开新的会话（新的 system prompt、新的工具集）。 每个阶段获得：

  • 更短、更具体的 system prompt（减少推理开销）

  • 只加载当前阶段需要的工具（而非一个巨大的工具集）
  • 可选的子智能体（复杂阶段可用 Pattern 2，简单阶段保持工具调用）

延迟优化的工程实践

文章系统地总结了语音智能体的延迟优化技术： 1. 子智能体使用小模型：orchestrator 用 Nova Sonic，对话质量由其保证；子智能体不需要大语言模型，用 Nova 2 Lite/Micro 即可。默认小模型，有必要时升级特定子智能体。 2. 状态化子智能体 + 缓存：无状态的子智能体每次调用都访问数据库或 API，引入额外延迟。设计子智能体在会话内缓存数据源结果，后续问题从内存读取而非重复调用后端。 3. 认证后预取数据：尤其适用于客服中心场景。用户认证后，主动在后台拉取账户余额、近期交易、待处理警示、抵押贷款状态。当用户询问时，答案已在内存中。 4. 并行化独立工具调用：用户请求「给我所有账户概览」时，不要顺序调用「活期 → 储蓄 → 信用卡」，用并发执行一次完成三个调用。Strands 原生支持独立工具调用的并行化。 5. 填充短语掩盖延迟：当工具调用不可避免时，通过 system prompt 指示语音模型说填充短语（"Let me check that for you…"）而非沉默等待。

MCP vs A2A：两个协议的角色分工

文章澄清了两个协议的定位：

  • MCP（Model Context Protocol）：连接 agent 到工具的协议。AgentCore Gateway 托管 MCP 服务器作为托管端点，语音模型通过 Gateway ARNs 访问工具。
  • A2A（Agent-to-Agent）：连接 agent 到其他 agent 的协议。在 AgentCore Runtime 上，不同框架构建的智能体可以共享上下文和推理，使用共同格式通信。 两者是正交的关系：MCP 解决「agent 如何调用外部功能」，A2A 解决「agent 如何与其他 agent 协作」。

实践启示

对语音 AI 产品经理

  1. 选择正确的集成模式：

  2. 简单工具调用（查余额、查天气）：Pattern 1，延迟最低

  3. 复杂多步推理（贷款申请、故障排查）：Pattern 2，子智能体承担推理
  4. 多阶段对话（客服IVR流程）：Pattern 3，阶段隔离减少认知负担
  5. 延迟预算是核心指标：语音对话的用户体验容忍度远低于文本。对每个查询，明确「用户期望的响应时间」，并用延迟预算反推架构选择。
  6. 系统 prompt 的分阶段设计：即使不使用 Pattern 3，主动将系统 prompt 按对话阶段组织也能提升效果。将认证逻辑、账户查询、投诉处理分为独立的 prompt 分支，减少模型每次需要「忽略无关上下文」的计算。

对架构师和工程师

  1. A2A 协议的长期价值：如果你的组织已有不同框架构建的智能体（LangGraph、AutoGen、自研），A2A 提供了跨框架协作的可能性。评估 AgentCore Runtime 上的 A2A 支持是未来智能体集成的关键投资。
  2. MCP 工具托管的安全边界：AgentCore Gateway 是 AWS 托管的 MCP 服务器。需要评估业务工具通过 Gateway 暴露的安全边界——哪些工具可以在 Gateway 上注册，哪些必须保持独立服务。
  3. 会话分段的上下文传递：Pattern 3 的会话切换需要显式传递上下文（chat history）。设计阶段间的「交接协议」——认证阶段的结果（用户身份、权限级别）如何传递到下一阶段的 session。
  4. Nova Sonic 异步工具调用：Amazon Nova 2 Sonic 支持异步工具调用， 对话可以在工具运行时继续，接受输入、多工具并行、在用户中途改变请求时优雅调整。这是减少感知延迟的关键特性。

对 DevOps 和 SRE

  1. WebSocket 连接管理：语音智能体依赖 WebSocket 维持实时双向流。设计连接管理策略：断线重连、超时处理、并发连接数限制。AgentCore Runtime 提供 microVM 级会话隔离，避免「 noisy neighbor」问题。

  2. 延迟监控指标：除标准 LLM 指标外，语音智能体需要追踪：

  3. Time-to-first-audio（用户说话到听到响应的延迟）

  4. 工具调用成功率
  5. 阶段切换频率和切换延迟
  6. 容量规划：语音智能体的扩展不是简单的实例数横向扩展。需要考虑并发 WebSocket 连接数、Bedrock AgentCore 的容器调度、以及下游工具服务的吞吐能力。

对创业者和 ISV

  1. 现有智能体的复用是核心资产：文章在结论中强调「The sub-agents you've already built are your biggest asset. Reuse them.」 如果你已有文本聊天机器人的工具/子智能体，它们可以低成本迁移到语音场景。
  2. Strands BidiAgent 的框架价值：Strands 提供了连接 Nova Sonic 和应用的双向流生命周期管理。对于不想深入 WebSocket 细节的团队，这是快速起步的集成路径。
  3. 垂直场景的专注：文章的场景示例（银行、抵押贷款）都是高价值、复杂对话的垂直领域。语音智能体在这些场景的价值高于简单查询。评估创业方向时，优先考虑「对话复杂度高、人工成本高」的领域。