将外部智能体集成到 ElevenLabs Agents 语音编排中

前沿智能体编排器越来越能处理复杂任务，并在企业工具链中协同工作。这需要对应用、对话和系统状态进行细致管理。除语音外，其他模态下已出现一些通用模式，被统称为上下文工程,，旨在为智能体的系统提示词建立一致的实践规范。引入语音不仅增加了需要管理的状态层，还能复用其他模态下已有的成果。

本文将介绍ElevenLabs 智能体如何支持外部智能体，以及实现精细集成控制的常见模式。这些机制让用户能充分利用 ElevenLabs 的顶级语音编排，同时完全掌控更广泛的编排流程。

核心组件

ElevenLabs 智能体

最简单的 ElevenLabs Agent 可通过Websocket 客户端访问。对话中代表服务端和客户端事件的信息以 JSON 对象形式传递。当智能体转写用户语音时，会自动触发生成请求。我们支持主流模型服务商，也允许用户接入自有自定义 LLM. 如果要用更复杂的编排器（智能体）来响应自定义 LLM 后的生成请求，需确保其支持 OpenAI 的 Chat Completions 或 Responses API。好在大多数主流智能体开发框架（如 CrewAI、LangChain、LangGraph、HayStack、LlamaIndex 等）都能轻松支持这种 API 格式。

集成后，这些智能体通常需要随时读取和更新其内部及外部状态，无论其背后的语音编排器如何。有效管理这些状态，可确保与现有文本智能体保持一致。

状态管理

智能体需追踪的数据高度依赖具体任务。对于由外部智能体驱动的 ElevenLabs Agents，建议将状态分为几个明确的类别进行维护。

内部状态用于管理对话动态。常见的内部状态包括：

• 当前对话流程，包括语音活动、中断及当前说话人识别。
• 通过实时转写分析获得的应用相关洞察，如识别意图、实体或情感。
• 推理过程，包括中间想法、假设及以往生成方案的尝试。
• 配置和运行参数，如当前目标、运行模式及交互过程中的临时约束。

外部状态则主要关注智能体与之交互或影响的相关系统和人员。常见的外部状态包括：

• 与其交互的其他用户或系统的状态，如当前目标、可用性或权限。
• 工具和知识库，例如 API、数据库或集成，可能影响智能体的行动能力。
• 涉及外部参与者或系统的进行中任务和依赖，影响智能体的后续步骤。

我们将介绍一种常见模式，帮助在智能体与用户的整个生命周期内可靠维护这些信息。

解决方案组件

概览

本节介绍成功集成复杂外部智能体所需的架构组件和实现细节。核心思路是在所有服务间代理一个唯一的会话标识符。对于使用自定义 LLM 的 ElevenLabs Agents，只需在额外 body 对象中的 LLM 参数中传递所需标识符，作为对话覆盖参数在呼叫发起时传递。这样，标识符可从用户端经 ElevenLabs Agent 传递到外部智能体。

注意有状态代理位于自定义 LLM 之后。该服务通常不是默认存在的，它用于将每个生成请求映射到代表与外部智能体连接的唯一标识符。该服务的实现由外部智能体开发者负责。最简单的代理只需管理唯一标识符与 ElevenLabs 对话或呼叫 SID（电话场景）的映射。更高级的版本可在对话映射中引入层级，支持跨多次交互的复杂客户关系。

在更高级的配置中，代理会维护超出单一请求和下游会话的额外标识符。代理可将一个标识符关联到多个相关交互，而不是仅对应一个对话或呼叫 SID。这样，系统可追踪跨渠道的客户旅程，复用历史上下文，并同时协调多次交互。例如，一个映射可将多次网页聊天、后续语音通话和内部支持流程归为同一客户标识符。代理可根据简单规则将请求路由到正确标识符，同时在自定义 LLM 后保持统一状态。这让外部智能体能灵活持久地管理多步交互。

消息传递

除了将生成请求映射到更高层级实体外，有状态代理还可通过 API 请求，支持与应用前端或独立路由服务等外部来源的双向消息传递。在需要此功能的应用中，ElevenLabs Agents 无需感知消息已被转发到其他服务。

例如，外部智能体通常需要了解当前语音活动，以判断用户是否在说话、持续时长及是否需提前响应。这些信息可通过 ElevenLabs Agents 提供的客户端事件（通过对话 websocket 接收）直接获取和处理。收到 ElevenLabs 的分数后，客户端应用可根据需求将 VAD 客户端事件转发给有状态代理，并确保消息中包含会话标识符。代理需实现请求映射逻辑，准确识别该会话的现有连接。

该模式可扩展到任何客户端事件，只要能用一段 JSON 表达。同时，也建议暴露智能体自身产生的事件。常见场景包括工具调用或知识库查询的生命周期，这些操作代表对外部系统的操作，是企业智能体建设的基础能力。

通过自定义 LLM 集成外部智能体时，ElevenLabs 的工具调用和 RAG 功能通常会让位于外部智能体的实现。因此，这些组件完全由外部智能体提供方负责。应用仍可通过工具活动获得可见性，从而展示智能体进度并优化终端用户体验。

为实现这一点，外部智能体在调用工具时会发送消息（包括请求和响应）。这些消息由有状态代理转发给客户端应用，并通过专用消息队列处理。这与 ElevenLabs Agents 的客户端事件机制类似，确保应用能追踪智能体对外部系统的读取或修改操作。

通过这些核心组件，并实现代理与客户端应用间的双向消息传递，用户可将外部智能体集成到 ElevenLabs Agents 中，仅使用其语音编排能力，同时完全掌控 LLM 编排的所有环节。

回到状态管理

要高效支持复杂外部智能体，需在代理与智能体间明确分工，尤其在状态管理方面。此模式下，代理负责维护按应用需求分组的相关交互表，并用无状态逻辑在自身与智能体间路由消息。而外部智能体应处理并存储所有影响整体状态的内部和外部信息。

虽然放宽这种分离可减少对现有方案的改造，但严格区分通常能带来更健壮、可扩展的效果，尤其在智能体任务集不断扩展时。

展望未来

随着企业在语音和非语音智能体应用上的成熟，相关信息需求的模式将逐步清晰，有助于简化本文所述服务的开发和管理。目前，我们正持续满足已出现的需求。我们的前线工程团队正与客户紧密合作，将这些新需求转化为具体产品能力，确保解决方案与实际部署同步演进。

如果你已有智能体并希望通过ElevenLabs 智能体实现语音功能，同时保留对 LLM 编排的完全控制，欢迎尝试上述方案并反馈你的体验。