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

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

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

核心组件

ElevenLabs Agents

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

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

状态管理

从定义上说，智能体为高效适应环境而必须追踪的数据高度依赖具体任务。对于由外部智能体驱动的 ElevenLabs Agents，建议按几个明确定义的类别维护状态。

内部状态决定对话的动态过程。作为智能体内部状态一部分而追踪的元素包括：

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

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

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

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

解决方案组件

概览 

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

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

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

消息传递

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

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

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

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

为提供这种可见性，外部智能体会在每次调用工具时发出消息，包括请求和响应。这些消息由有状态代理转发至客户端应用，客户端应用通过专用消息队列处理它们。这与 ElevenLabs Agents 客户端事件所用机制一致，确保应用可追踪智能体何时读取或修改外部系统。

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

回到状态管理

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

虽然放宽这种划分可进一步减少对现有解决方案的重复工作，但随着智能体任务集扩大，严格保持边界通常能带来更稳健、更具扩展性的结果。

展望未来

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

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