解析 ElevenAgent 的编排引擎

ElevenAgents 由专为实时对话打造的低延迟编排引擎驱动，额外开销不足 100ms。该架构结合了 ElevenLabs 的顶尖研究成果、OpenAI、Google 和 Anthropic 等领先提供商的前沿 LLM，以及由 ElevenLabs 托管的精选开源模型。通过在回答流程的不同阶段使用多个模型，智能体能兼顾高响应速度与上下文感知能力。通过动态协同发挥各模型的优势，我们在多种企业任务和对话场景中实现可靠、可扩展的性能，同时优化智能水平、速度与成本之间的平衡。

本文将介绍这些模型如何协同工作，为智能体在复杂环境中运行提供核心能力；更具体地说，哪个模型会在何时看到哪些 token。核心在于管理交互各环节中的对话历史。我们将重新梳理对话历史的共享方式和位置，以说明它在独立智能体和 多智能体工作流 编排中的作用。

独立智能体 

先来了解独立智能体及其核心组件。一个具备基本价值的智能体通常应有系统提示词，并可访问多个 工具 和一个 知识库。如果使用场景不太需要验证严格的步骤顺序，或需避免智能体间形成知识孤岛，建议优先选择独立智能体而非工作流。当某些工具、文档或历史上下文仅供部分子智能体访问、其他子智能体无法访问时，就会形成知识孤岛。这是多智能体工作流的固有特征，也意味着需要在灵活性与确定性之间权衡。 

使用 ElevenLabs 独立智能体时，需了解其如何：

• 构建有效的生成请求
• 检索并整合相关文档
• 生成并执行工具调用，为智能体回复提供信息
• 输出结果以供评估和数据收集

构建对话上下文 

客户与 ElevenLabs 智能体之间的一次对话由一系列轮次构成，每轮均包含双方之间的消息交换。这份由智能体消息和用户消息交替组成的列表，是构建对话上下文的起点。每轮中，底层 LLM 接收的生成请求包含一系列交替的智能体和用户消息，且会比上一轮多一条消息。自然地，这一系列消息前会加上一条代表智能体系统提示词的系统消息。

ElevenLabs 编排器会预测用户何时说完，从而降低感知到的 LLM 延迟。在某些情况下，单轮对话中可能会出现多个拥有相同对话上下文的 LLM 生成请求。 编排可优化智能体的响应速度，而回复质量同样高度依赖知识访问方式。 随着使用深入，客户通常会开始结合专有文档和公开内容，为智能体回复提供依据。多年来，检索增强生成（RAG）一直是实现这一目标的标准方法。 ElevenAgents 知识库 在 RAG 的基础上，采用了优化的多模型架构，我们已在 此前文章 中详细介绍。即使用户最近的输入只是追问、对澄清内容的确认，或未明确提出问题，该架构也能可靠地检索文档。

不过，检索只是智能体与外部系统交互的一种方式。

通过工具执行操作和检索信息

ElevenLabs 智能体可通过灵活的工具系统，在对话中执行现实操作并获取实时信息。但这也带来一个重要设计考量：每启用一个工具，序列化提示词都会变大，因为工具的名称、描述和参数架构都会随系统提示词和对话历史一同纳入。 随着工具增加，模型正确调用所需工具序列的推理负担也会加重。在 Agent Builder 中，工具描述会说明工具的功能及其返回字段。这些信息可帮助语言模型理解工具的使用上下文。定义完成后，调用工具的具体条件应写入智能体的系统提示词。例如：

• 工具 lookup_order 的描述：“根据订单 ID 获取客户订单详情。返回订单状态、购买商品、收货地址和追踪编号。”
• 系统提示词指令：“验证客户身份后，调用 lookup_order 工具获取其订单详情。”

这种职责分离让工具定义可在不同 智能体 间复用，同时允许每个智能体通过系统提示词控制工具的确切调用时机。为帮助客户有效设计这些系统提示词，我们在 提示词指南 中提供了更深入的指导。在此框架下，主要可定义以下几类工具：

• 调用外部 API 的 Webhook 工具。
• 通过对话 websocket 以事件形式分发工具请求的客户端工具。
• 用于通话转接等内置操作的系统工具。
• 连接到 模型上下文协议 服务器的 MCP 工具。

智能体决定使用工具时，会从对话中提取必要信息并发送执行请求。工具返回结果后，该结果会加入对话，以便模型在下一次回复中自然引用。如有需要，工具输出还可将智能体保存的信息更新为 动态变量。这些保存的信息以简单键值对形式存储，通过预定义映射从工具响应中提取。设置后，这些变量可通过系统提示词、后续工具参数和工作流条件反馈给智能体。这一反馈循环让智能体获得会随交互演变的工作记忆。

以上介绍了工具如何融入智能体推理，其执行时机同样可配置。工具可采用 3 种执行模式，分别适用于不同对话需求。即时模式下，LLM 发出请求后工具立即执行。这是快速查询的默认模式，适用于用户期望近乎即时得到回复的情况，例如查询订单状态。与工具调用前语音结合时，智能体会先生成“我来帮你查一下”等简短确认语，并在工具并行运行期间回复用户，从而减少静默等待。对于较慢的工具，平台会自动延长这些填充消息，以匹配预期等待时间。相比之下，工具调用后语音模式会延迟执行，直至智能体说完。这对于会产生现实后果的操作至关重要，例如转接电话、结束会话或提交付款。用户会先听到“我现在将为你转接至账单部门”等完整说明，并可在操作执行前打断。异步模式则让工具完全在后台运行，不暂停对话。该模式最适合发送邮件、触发外部工作流或记录数据等即发即忘操作，此时智能体无需在回复中引用结果。

完成执行和编排的配置后，下一步是了解如何衡量性能。

衡量性能

与智能体完成通话后，客户可能希望提取通话中的特定信息，用于进一步分析和存储，或判断通话是否成功。这时便需要用到 数据收集 和 评估标准。数据收集可从通话转录中提取结构化信息，以供下游分析和聚合。客户通常将这些输出导出到企业数据湖仓，用于报告或数据扩充工作流。例如，销售开发智能体可从对话中自动提取潜在客户详情，以便在客户关系管理（CRM）系统中创建或更新销售线索。另一方面，评估标准用于判断通话是否成功。若满足所有已配置标准，通话将标记为成功；否则标记为失败。这能确保对话持续符合既定的质量和完整性标准，并提供快速反馈。通话结束并触发通话后 Webhook 后，智能体会通过 LLM 处理最终转录内容，包括工具执行记录和元数据，以及所有已配置的数据收集点和评估标准。模型通过这一组合提示词，判断是否满足每项评估标准，并提取指定数据点供下游分析。由于 LLM 会直接将这些配置作为输入提示词的一部分进行解读，因此必须以清晰、一致的方式编写，确保模型能够准确理解和应用。为此，我们建议按以下最佳实践编写评估标准和数据收集描述。

评估标准

1. 每项标准只设一个明确目标： 一个句子或简短要点优于在一项标准中设置多个目标。 
2. 可观察且基于转录： 将目标表述为可根据转录内容判断成功或失败的形式（说了什么、智能体做了什么、用户问了什么）。避免需要 LLM 不具备的外部上下文才能判断的目标。
3. 明确成功、失败和未知结果： LLM 已知：目标达成即标记成功，未达成即标记失败，无法从转录中判断则标记未知。因此，目标应明确界定“达成”与“未达成”；若表述模糊，模型可能倾向于给出未知或错误分类。
4. 保持简洁： 有时会同时发送多项评估标准。过长的评估标准可能增加噪声，并可能导致幻觉。
5. 语言很重要： LLM 对评估标准是否达成给出的任何理由，都会使用与标准描述相同的语言，因此需注意这一点。

数据收集

1. 准确描述要提取的内容： 描述是 LLM 的主要信号。请说明字段含义、应在何种情况下设置，以及不明确时如何处理（例如，“如果客户从未说明首选日期，则保留 null”）。
2. 匹配预期类型： LLM 提供的值始终会匹配为数据收集点指定的数据类型（如 boolean、string、integer 等）。因此描述也应与之对应。例如，对于 integer 可使用“提取请求的商品数量”，对于 boolean 可使用“客户是否同意该报价，填是或否”。
3. 尽可能使用枚举： 对于 string 类型，若值集合固定，请在架构中使用 enum；这会约束模型并减少无效输出。
4. 每项只设一个提取目标： 不要在一项描述中塞入多个无关事实；应拆分为多项，让每次调用只有一个明确的提取目标。
5. 描述保持简短： 描述写几句话即可，无需长篇大论。转录内容已包含在用户消息中，因此架构加上简短描述便已足够。

目前，此评估和提取步骤使用的 LLM 固定为低延迟模型，以确保快速处理。近期我们预计将推出更多选项，为客户提供更大灵活性。 

接下来，我们将关注需要结构化编排、确定性或跨多个对话角色进行专业分工的使用场景。对于这类场景，客户可改用工作流。

工作流

工作流 提供可视化界面，用于设计复杂的对话流程。它最终会生成一个逻辑对象，供编排器在一个独立智能体标识符下管理多个子智能体、工具和转接。除独立智能体已有的要素外，工作流还引入了其他需要考虑的组件，包括：

• 系统提示词如何与子智能体的对话目标交互。
• 如何确定图中各转换点的遍历路径。

专属对话目标

工作流复用独立智能体的功能，以确保交互过程中的行为保持一致。这包括无论工作流的哪个部分处于活动状态都应始终可用的共享元素，例如基础系统提示词、核心工具和全局知识库。整体系统提示词通常负责定义全局对话上下文、预期语气、安全约束，以及任何品牌专属或全产品适用的指令。

在这一共享基础上，工作流引入在有向图中运行的专用子智能体。每个子智能体都被分配了范围明确的目标，并通过仅与其角色相关的额外提示词指令、工具和知识来源来扩展基础配置。子智能体并非重新定义整套对话设置，而是通过提示词组合和选择性扩展上下文，将其意图叠加到基础智能体上。为保持连续性，对话历史会在子智能体转换时保留；但每个子智能体对系统的视图都经过有意限制。知识库和工具会被选择性公开，形成清晰的隔离区，避免不同职责之间的信息泄漏。为加强这种隔离，编排器对象会在每次转换时重建，如同它是一个独立智能体。这样可确保当前子智能体的提示词状态、配置和可用能力完全具有确定性。该设计使工作流既能保持全局一致性，又能支持局部专业化，从而实现可预测的行为、清晰的职责分离，以及对交互各阶段上下文、知识和操作应用方式的精确控制。

实现这种控制的关键机制之一，是对子智能体之间转换的管理方式。

使用 LLM 条件驱动工作流转换

工作流通过遍历子智能体的有向图推进，节点间转换由明确条件控制。这些条件决定何时应从一个子智能体移交控制权给另一个子智能体，并使工作流能够响应用户输入、工具结果和动态变量。图条件可以是确定性的，也可以由 LLM 评估。无条件转换、基于动态变量表达式的检查或工具结果条件等确定性条件，能为控制流提供有力保障，适合强制工作流严格按步骤推进。相比之下，基于 LLM 的条件可对自然语言标准进行语义评估，例如检测用户意图或识别是否已提供特定信息。

重要的是，LLM 条件在当前智能体的系统提示词之外进行评估，不会影响智能体的生成行为。相反，编排器会根据当前对话状态并行评估这些条件。这种分离确保转换逻辑不会污染智能体提示词或影响回复生成方式，同时仍让工作流能够利用 LLM 推理灵活遍历图。结合确定性条件与 LLM 评估条件，工作流可同时实现可预测性和适应性：在正确性至关重要时使用确定性转换，在需要语义理解时使用基于 LLM 的转换。

当对话进入新阶段时，系统会激活专为该步骤定制的智能体版本。每个阶段都有专注的指令，并且只能访问与其职责相关的知识和工具。例如，退款处理阶段可引用退款政策，而不会继承开户引导或分流阶段的无关上下文。阶段间的移动由明确的转换条件管理。这些条件决定何时应转移职责，并让路由决策随着对话自然推进。为保持连续性，用户在转换过程中始终拥有无缝体验；每个阶段都会继承相关对话上下文，但不会暴露交接机制。安全机制还会监控转换，防止无效的路由循环，确保工作流保持稳定并围绕目标推进。

安全与保障

对于需要加强安全与保障控制的场景，客户可使用编排器的其他组件。 

安全护栏

ElevenLabs Agents 通过可配置的审核与对齐系统实施安全护栏，实时评估用户和智能体消息。传入内容会按多种风险类别分类，包括色情内容、暴力、骚扰、仇恨和自残，每类均可独立配置阈值。触发安全护栏时，对话会立即终止，客户端将收到明确的失败原因通知。这确保不安全交互能被及早、一致地拦截，而非仅依赖基于提示词的缓解措施。安全护栏独立于智能体的提示词逻辑运行，提供可靠的强制执行层，无法通过模型行为或用户输入绕过。该方法让客户可根据其领域调整安全敏感度，同时保持运行时的确定性执行。

合规数据管理

发言者有时会向智能体分享需遵守严格存储和处理要求的敏感信息，例如需要符合 HIPAA 规范处理的医疗数据。为支持这类使用场景，我们在智能体或工作区级别提供零保留模式（ZRM）。启用后，所有通话数据仅在内存中处理，绝不写入持久化存储。通话和处理完成后，ElevenLabs 不会保留任何信息。因此，智能体控制台中不会提供转录、录音和分析输出；该政策同时适用于面向客户的系统和内部日志。虽然数据不会被保留，但通话期间仍会进行处理，所有已配置的通话后 Webhook 都会收到输出，因此客户如有需要可在自己的系统中存储转录或分析结果。 

ZRM 启用时，我们还会将可用 LLM 限制为承诺不使用客户数据训练或保留客户数据的提供商，以确保子处理商不会保留数据；目前包括 Google Gemini 和 Anthropic Claude 的模型。希望在 ZRM 下使用其他 LLM 的客户，可自行与该提供商签订协议，并使用该协议涵盖的 API 密钥将其配置为自定义 LLM。由于这会将数据处理扩展到我们的标准信任边界之外，启用前必须由安全团队人工审核并批准该使用场景。ZRM 可确保 ElevenLabs 及其子处理商不保留通话数据，但客户仍有责任确保其智能体使用的任何外部工具或 Webhook 符合适用的数据保留和监管要求。

展望未来

本文探讨了 ElevenLabs Agents 如何管理对话上下文、工具、评估和结构化工作流，从而大规模提供可靠的实时体验。随着客户将智能体部署到日益复杂的环境中，我们将持续扩展编排引擎的灵活性，包括可配置的评估模型、更丰富的转换控制，以及更深入地观测各阶段的提示词组合和 token 使用情况。

我们的 前线部署工程团队 正与客户紧密合作，确保这些能力与真实部署同步演进。下一代 Agents 将在不牺牲实时对话所需低延迟性能的前提下，提供更高的透明度、确定性和适应性。