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

前沿智能体编排器越来越能处理复杂任务，并跨企业工具套件运行。这需要认真管理应用、对话和系统状态。对于语音以外的模态，业界已形成一些常见模式，统称为上下文工程，其目标是围绕智能体的系统提示词，在交互推进过程中建立一致的实践。引入语音不仅增加了一层用于管理语音交互组件的状态，也能复用此前在其他模态中积累的成果。

本文将介绍ElevenLabs Agents如何支持外部智能体，以及实现精细集成控制的模式。这些机制让客户既能利用 ElevenLabs 一流的语音编排能力，也能完全掌控更广泛的编排流程。

核心组件

ElevenLabs Agents

最简单的情况下，可通过Websocket 客户端访问 ElevenLabs Agent。对话中代表服务器和客户端事件的信息，会以 JSON 对象的形式在智能体与客户端之间传递。智能体转录用户语音后，会立即触发生成请求。我们支持大多数主流模型提供商，也允许客户自带Custom LLM。如果使用更复杂的编排器（智能体）在 Custom LLM 后端响应生成请求，需确保它支持 OpenAI 的 Chat Completions 或 Responses API。幸运的是，大多数主流智能体构建框架（CrewAI、LangChain、LangGraph、HayStack、LlamaIndex 等）都能轻松支持这种 API 格式规范。

集成后，无论位于哪个语音编排器之后，这些智能体通常都需要能随时读取和更新内部与外部状态。有效管理这些状态，可确保与现有纯文本智能体保持一致。

状态管理

智能体为高效应对环境而需跟踪的数据，本质上高度依赖具体任务。对于由外部智能体驱动的 ElevenLabs Agents，建议按几个明确类别维护状态。

内部状态决定对话的动态过程。智能体内部状态跟踪的元素包括：

• 当前对话流程，包括语音活动、打断情况及活跃说话者识别。
• 从实时转录分析中得出的应用专属洞察，例如识别出的意图、实体或情感。
• 推理轨迹，包括中间想法、假设，以及此前生成解决方案的尝试。
• 配置和运行参数，例如当前目标、运行模式，以及交互期间引导其行为的临时约束。

而外部状态主要关注智能体与之交互或对其产生影响的相关系统和人员。智能体外部状态跟踪的元素包括：

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

下面介绍一种常见模式，可在智能体与用户建立关系的整个生命周期内可靠维护这些信息。

解决方案组件

概览

本节将介绍成功集成复杂外部智能体所需的架构组件和实现细节。这种方法的核心，是能在所有服务间代理一个任意但唯一、代表会话的标识符。对于使用自定义 LLM 的 ElevenLabs Agents，只需在发起通话时，将所需标识符作为extra body 对象中的 LLM 参数，随对话覆盖设置一同传递即可。这样，标识符就能从用户经由 ElevenLabs Agent 流向外部智能体。

请注意，自定义 LLM 后方的有状态代理。这项通常并不存在的服务，可将单个生成请求映射到代表与外部智能体连接的任意标识符。该服务由外部智能体开发者负责实现。最简单的形式下，代理通过唯一标识符管理连接，这些标识符映射到 ElevenLabs 对话或通话 SID（用于电话场景）。更高级的版本则可在对话映射中引入层级结构，以表示跨多次交互的更复杂客户关系。

在这些更高级的配置中，代理会维护额外标识符，不再局限于绑定单个下游会话的单个请求。每个标识符不必只代表一个对话或通话 SID；代理可将一个标识符关联到多次相关交互。这样，系统便可跟踪跨渠道的客户旅程、复用历史上下文，并同时协调多次交互。例如，一个映射可将多个网页聊天会话、一次后续语音通话和一个内部支持 workflow 归到同一逻辑客户标识符下。代理随后可根据简单规则将请求路由到正确标识符，同时保留自定义 LLM 后统一的状态。这让外部智能体能够管理更灵活、更持久的多步骤交互。

消息传递

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

例如，让外部智能体了解当前语音活动通常很有用，这样它便能判断用户是否在说话、说了多久，以及是否应提前采取行动。这些信息可直接从 ElevenLabs Agents 提供的经处理的语音活动检测（VAD）分数中获取，并将其作为通过对话 websocket 接收的客户端事件进行处理。客户端应用从 ElevenLabs 接收分数后，可根据应用需求将 VAD 客户端事件转发给有状态代理，并确保消息中包含任意会话标识符。有状态代理必须实现请求映射逻辑，以最佳方式识别该会话现有的连接。

这一模式可扩展以适配来自客户端的任何事件，前提是它能表示为一段 JSON。不过，公开由智能体自身发起的事件也很有用。常见示例包括工具调用或知识库查询的生命周期，它们代表对外部系统的操作。这些机制是当今企业构建智能体的基础。

通过自定义 LLM 集成外部智能体时，ElevenLabs 的工具调用和检索增强生成（RAG）功能通常会被绕过，转而使用外部智能体自身的实现。因此，这些组件完全由外部智能体提供商负责。不过，应用仍可通过了解工具活动而受益，因为这能展示智能体进度，并相应更新终端用户体验。

为提供这种可见性，外部智能体会在调用工具时发送消息，包括请求和响应。这些消息由有状态代理转发给客户端应用，后者通过专用消息队列处理。该机制与 ElevenLabs Agents 的客户端事件相似，确保应用可跟踪智能体何时读取或修改外部系统。

因此，使用这些核心组件，并启用代理与客户端应用之间的双向消息传递，客户便可将外部智能体集成到 ElevenLabs Agents 中，严格使用其提供的语音编排能力，同时保留对 LLM 编排各个部分的控制权。

回到状态管理

要有效支持复杂外部智能体，尤其在状态管理方面，必须明确划分代理与智能体的职责。在这一模型中，代理负责维护相关交互表，并按应用需求进行分组；还负责使用保持无状态的逻辑，在自身与智能体之间路由消息。外部智能体则应处理并存储所有构成整体状态的重要内部和外部信息。

尽管放宽这种划分可进一步减少现有方案的返工，但随着智能体任务集扩大，维持严格边界通常能带来更稳健、更易扩展的结果。

展望未来

随着组织在采用支持语音和非语音的智能体方面日益成熟，我们预计这些智能体所需信息的模式将逐渐清晰，从而简化本文所述服务的开发与归属。与此同时，我们正持续满足已出现的需求。我们的前线部署工程团队正与客户密切合作，将这些新兴需求转化为具体产品能力，并确保解决方案与实际部署同步演进。

如果你已在使用现有智能体，并希望通过ElevenLabs Agents启用语音功能，同时保留对 LLM 编排的控制权，欢迎试试这种方法，并告诉我们你的想法！