解析 ElevenAgent 的编排引擎

ElevenAgents 由专为实时对话打造的低延迟编排引擎驱动，额外延迟低于 100ms。这一架构结合了 ElevenLabs 的前沿研究与 OpenAI、Google、Anthropic 等主流厂商的 LLM，以及 ElevenLabs 托管的精选开源模型。通过在不同阶段调用多种模型，智能体能确保对话响应迅速且具备上下文感知能力。动态结合各模型优势，实现了企业级任务和多种对话场景下的高可靠性和可扩展性，同时优化智能、速度与成本的平衡。

本文将介绍这些模型如何协同工作，支撑智能体在复杂环境下的核心能力，具体包括每个模型在何时看到哪些 token。核心在于如何在不同交互节点管理对话历史。我们会详细说明对话历史在独立和多智能体工作流中的共享方式及其作用。

独立智能体

我们先来看独立智能体及其核心组成。最基础的智能体通常包含系统提示词、可访问的若干 工具 和 知识库。当用例对严格步骤顺序要求不高，或需避免智能体间知识孤岛时，建议优先选择独立智能体而非工作流。知识孤岛指部分工具、文档或历史上下文仅对部分子智能体可见，这在多智能体工作流中不可避免，会在灵活性和确定性之间带来权衡。

在 ElevenLabs 中，理解独立智能体如何：

• 构建高效生成请求
• 检索并整合相关文档
• 生成并执行工具调用以辅助响应
• 输出结果用于评估和数据收集

构建对话上下文 

客户与 ElevenLabs 智能体的对话由多轮组成，每轮包含双方消息的交替。这组交替消息是构建对话上下文的起点。每轮中，底层 LLM 会收到包含一系列智能体和用户消息的生成请求，比上一轮多一条消息。消息序列前会加上系统提示词，作为智能体的系统指令。

ElevenLabs 编排器通过预测用户说话结束时间，降低 LLM 的感知延迟。有时同一轮对话会用相同上下文多次请求 LLM。编排优化了响应速度，但响应质量同样依赖知识的获取方式。 随着客户需求提升，通常会将智能体回答与专有文档和公开内容结合。近年来，检索增强生成（RAG）已成为主流方案。ElevenAgents 知识库 基于 RAG，采用了优化的多模型架构，详细内容见 前文。即使用户最新输入为追问、确认或无明确问题，也能可靠检索文档。

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

使用工具执行操作和获取信息

ElevenLabs 智能体可通过灵活的工具系统，在对话中实时执行操作和获取信息。这也带来一个重要设计考量：每启用一个工具，序列化提示词的体积都会增加，因为工具名称、描述和参数结构会与系统提示词和对话历史一同包含。 工具越多，模型推理正确调用顺序的难度也越大。在 Agent Builder 中，工具描述说明了工具的功能及返回字段，模型据此理解其使用场景。具体调用条件应写入智能体的系统提示词。例如：

• 工具描述示例：查询订单: “通过订单 ID 获取客户订单详情。返回订单状态、购买商品、收货地址和物流单号。”
• 系统提示词示例：“在核实客户身份后，调用 查询订单 工具获取订单详情。”

这种分离方式让工具定义可复用，同时每个智能体可通过系统提示词精确控制调用时机。为帮助客户高效设计系统提示词，我们在 提示词指南 中提供了详细说明。该框架下可定义多种工具类型，主要包括：

• Webhook 工具：调用外部 API。
• 客户端工具：通过 websocket 事件分发工具请求。
• 系统工具：用于内置操作，如转接通话。
• MCP 工具：连接 Model Context Protocol 服务器。

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

上述描述了工具如何融入智能体推理，工具执行时机也可配置。工具有三种执行模式，适用于不同对话需求。即时模式下，LLM 请求工具后立即执行，适合如订单查询等需快速响应的场景。结合前置语音，智能体会先生成如“我帮你查一下”这样的简短回复，同时工具并行运行，减少等待。对于较慢的工具，平台会自动延长填充消息以匹配预期等待时间。后置语音模式则在智能体说完后才执行工具，适用于如转接、结束会话、提交支付等有实际后果的操作，用户可在执行前打断。异步模式下，工具在后台运行，不影响对话进程，适合如发送邮件、触发外部工作流、记录数据等无需在回复中引用结果的操作。

完成执行与编排后，下一步是了解如何评估性能。

性能评估

通话结束后，客户可能需要提取部分内容用于分析、存储，或判断通话是否成功。这时 数据收集 和 评估标准 就派上用场。数据收集可从通话文本中提取结构化信息，便于后续分析和汇总。客户常将这些数据导出到企业数据湖用于报表或数据补充。例如，销售开发智能体可自动提取潜在客户信息，创建或更新 CRM 线索。评估标准则用于判定通话是否达标。所有标准满足则标记为成功，否则为失败。这样可确保对话始终符合质量和合规要求，并能快速反馈。通话结束并触发 webhook 后，智能体会将最终文本、工具执行和元数据等，连同所有数据收集点和评估标准，一并交给 LLM 处理。模型会根据综合提示词判断每项评估标准是否达成，并提取指定数据点用于后续分析。由于 LLM 直接根据输入提示词理解这些配置，格式需清晰一致，便于模型准确理解和应用。我们建议按以下最佳实践撰写评估标准和数据收集描述。

评估标准

1. 每项标准只设一个明确目标： 一句话或简短要点优于多目标合并。
2. 可观察且基于文本： 目标应能通过通话文本判断成败（如说了什么、智能体做了什么、用户问了什么）。避免需外部信息的目标。
3. 明确的成功/失败/未知结果： LLM 已知达成目标即为成功，未达成为失败，无法判断则为未知。目标应写得清晰，避免歧义，否则模型可能倾向于未知或误判。
4. 保持简洁： 多项评估标准可能同时发送，过长会增加噪音并导致幻觉。
5. 语言一致： LLM 给出的理由会与标准描述语言一致，需注意保持一致性。

数据收集

1. 明确描述需提取内容： 描述是 LLM 的主要信号。说明字段含义、适用场景、不明确时如何处理（如“若客户未说明日期则留空”）。
2. 类型需匹配预期： LLM 返回值会与数据收集点的数据类型一致（如布尔、字符串、整数等），描述应与类型对应。例如“提取请求商品数量”用于整数，“客户是否同意报价（是/否）”用于布尔。
3. 尽量用枚举类型： 字符串类型如值固定，建议在 schema 中用枚举，便于模型约束输出。
4. 每项只提取一个目标： 不要在一项描述中混合多条无关信息，应拆分为多项，每次只提取一个明确目标。
5. 描述保持简短： 可用几句话，无需长段落。通话内容已在用户消息中，schema 和简短描述足够。

目前用于评估和提取的 LLM 固定为低延迟模型，以保证处理速度。未来我们将提供更多选项，提升灵活性。

接下来，我们关注需要结构化编排、确定性或多角色分工的场景，此时可使用工作流。

工作流

工作流 提供可视化界面，便于设计复杂对话流程。最终生成的逻辑对象由编排器用于统一管理多个子智能体、工具和转接，归属于同一独立智能体标识。工作流除继承独立智能体的能力外，还需考虑：

• 系统提示词与子智能体对话目标的交互方式。
• 流程图中各节点的转移条件。

专属对话目标

工作流复用独立智能体的功能，确保交互行为始终一致，包括基础系统提示词、核心工具和全局知识库，无论流程处于哪个阶段都可用。全局系统提示词通常用于定义整体对话上下文、预期语气、安全约束及品牌或产品相关指令。

在此基础上，工作流引入专属子智能体，在有向图中独立运行。每个子智能体有明确目标，并在基础配置上增加专属提示词、工具和知识源，仅服务于其职责。无需重定义全部对话设置，子智能体通过提示词组合和上下文扩展叠加自身意图。对话历史在子智能体切换时会保留，确保连贯性，但每个子智能体只看到有限的系统视角。知识库和工具按需开放，形成清晰的责任边界，防止信息泄露。为强化隔离，每次切换都会重建编排对象，仿佛是独立智能体，确保当前子智能体的提示词、配置和能力完全可控。这样既能保证全局一致性，又支持局部专精，实现可预测行为、职责分明和对上下文、知识、操作的精准控制。

实现这种控制的关键机制之一，是子智能体间的转移条件。

用 LLM 条件驱动工作流转移

工作流通过遍历子智能体有向图推进，节点间转移由显式条件控制。这些条件决定何时切换子智能体，并可响应用户输入、工具结果和动态变量。图条件可为确定性或 LLM 评估。确定性条件如无条件转移、动态变量表达式或工具结果，能强力保证流程推进，适合严格流程。LLM 条件则支持自然语言语义判断，如识别用户意图或检测特定信息是否已提供。

LLM 条件在当前智能体系统提示词之外独立评估，不影响智能体生成行为。编排器会并行根据当前对话状态评估条件，确保转移逻辑不会污染提示词或影响回复生成，同时又能利用 LLM 推理实现灵活流程。结合确定性和 LLM 条件，工作流既可保证可预测性，也具备适应性：关键节点用确定性转移，需语义理解时用 LLM 转移。

当对话进入新阶段，系统会激活专为该阶段定制的智能体版本。每个阶段有专属指令，只访问与其职责相关的知识和工具。例如，退款阶段可引用退款政策，不会继承入职或分诊的无关上下文。阶段切换由显式条件控制，决定何时切换责任，实现自然路由。为保证连贯性，用户体验在切换时保持无缝，每阶段继承相关上下文但不暴露切换细节。系统还会监控转移，防止无效循环，确保流程稳定、目标明确。

安全与合规

如需更高安全和合规控制，可启用编排器的相关功能。

安全防护

ElevenLabs 智能体通过可配置的审核与对齐系统实现安全防护，实时评估用户和智能体消息。内容会按多类风险（如涉黄、暴力、骚扰、仇恨、自残等）独立设定阈值。触发防护后，对话立即终止，并向客户端明确告知原因，确保不安全交互被及时拦截，而非仅依赖提示词规避。防护机制独立于智能体提示词逻辑，无法被模型或用户绕过。客户可根据业务场景调整安全敏感度，运行时始终保证确定性执行。

合规数据管理

有时用户会向智能体提供需严格存储和处理的敏感信息，如需 HIPAA 合规的医疗数据。为此，我们在智能体或工作区级别提供零留存模式（ZRM）。启用后，所有通话数据仅在内存中处理，不会写入持久存储。通话和处理结束后，ElevenLabs 不保留任何信息。通话文本、音频和分析结果不会出现在 Agents Dashboard，政策适用于客户系统和内部日志。数据虽不留存，但通话期间仍会处理，配置的 webhook 可接收输出，客户可按需存储到自有系统。

ZRM 启用时，我们也确保子处理方不留存数据，仅允许与有合同约束、禁止训练或留存客户数据的 LLM 提供商（如 Google Gemini、Anthropic Claude）。如需在 ZRM 下使用其他 LLM，客户可与供应商签署协议，并用受协议保护的 API key 配置为自定义 LLM。因涉及超出标准信任边界，需安全团队人工审核后方可启用。ZRM 可确保 ElevenLabs 及其子处理方不留存通话数据，但客户仍需确保智能体用到的外部工具或 webhook 符合相关留存和合规要求。

展望未来

本文介绍了 ElevenLabs 智能体如何管理对话上下文、工具、评估和结构化工作流，实现大规模、实时、可靠体验。随着客户在更复杂环境中部署智能体，我们持续扩展编排引擎的灵活性，包括可配置评估模型、更丰富的转移控制，以及对提示词组合和 token 使用的深度可观测性。

我们的 前线工程团队 正与客户紧密合作，确保能力与实际部署同步演进。新一代智能体将在保持低延迟实时对话体验的同时，带来更高透明度、确定性和适应性。