ElevenAgents for Healthcare：构建入站预约安排智能体

电话仍是医疗服务的第一入口，但它正不堪重负。Mayo Clinic研究和 Epic案例研究的数据均显示，约 30% 的预约安排发生在正常营业时间之外。转入语音信箱的来电，往往意味着预约悄然落空；而本应接听这些电话的前台人员却人手紧张、流失迅速。语音智能体已不再只是演示，正成为诊所填补这一缺口的方式；而预约安排是最常见的起点：来电量大、重复性高、流程可预测，并且占据了前台大量无需临床判断的工作。

医疗预约安排的要求也更高。排错时段或听错就诊原因，不只是体验不佳，更可能构成安全和合规事件。前台预约智能体需要的不只是悦耳的声音：还需要可靠的身份验证、严格的护栏、清晰的人工升级路径、处理受保护健康信息所需的合规能力，以及在真实预约系统中完成、修改或取消预约的能力。

本指南将使用 ElevenLabs Agents 构建这样的智能体：可通过电话访问、接入示例 EHR，能够端到端完成预约、改期和取消，并在适当时升级至人工。你将获得 workflow、护栏、测试和分析方法，确保它始终遵循规则，并部署在专为受监管医疗场景打造的基础设施上。

以下演示展示了你将构建的智能体如何端到端处理实时来电：

前提条件

开始前，需要准备以下内容：

• 一个 ElevenLabs 账户，可访问 ElevenAgents 平台和我们的音色。
• 一个 Twilio 账户和一个号码。
• 可访问 Twilio Verify。
• 一个沙盒或开发者 EHR 环境。本指南将使用 HAPI FHIR，这是 HL7 FHIR 格式的开源参考实现，用于验证合成患者记录。
• 诊所使用的日历应用。本指南使用 ElevenLabs 与 原生集成的 Cal.com。

可选

如果无法访问沙盒数据，或只是为了演示而跟随操作，可以使用 HAPI FHIR R4 沙盒服务器，并创建一条模拟患者记录，供验证阶段使用。请在终端中使用模拟数据运行以下 API 命令：

curl -X POST "https://hapi.fhir.org/baseR4/Patient" \
  -H "Content-Type: application/fhir+json" \
  -H "Accept: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "identifier": [
      { "system": "http://hospital.example.org/mrn", "value": "<YOUR-FAKE-MRN-NUMBER>" }
    ],
    "name": [ { "use": "official", "family": "<YOUR-FAKE-FAMILY-NAME>", "given": [ "<YOUR-FAKE-GIVEN-NAME>" ] } ],
    "gender": "<male or female>",
    "birthDate": "<YOUR-FAKE-DOB> (in YYYY-MM-DD format)"
  }'

只有查询恰好返回 1 条记录才视为匹配：无结果表示不匹配，多于 1 条则说明搜索参数不够具体，无法安全继续。

架构

本指南将构建一个通过 Twilio 号码运行、与 ElevenAgent 原生集成的预约安排智能体。接通入站来电后，智能体会借助可用工具收集验证和预约信息——无论来电者想新建预约、改期还是取消现有预约——并可在必要时转接人工。

采用此架构和工具后，成功的通话流程包含以下步骤：

1. 发起通话：患者拨打关联到智能体的 Twilio 号码，智能体问候患者并确认其需求。
2. EHR 验证：智能体根据 EHR 中的记录验证患者信息。
3. 身份验证：智能体通过 SMS 工具向患者手机号发送一次性密码（OTP），进行最终验证。
4. 预约或变更：智能体根据已确认的需求操作日历——新建预约时收集预约信息并检查可用时段；改期时查找现有预约并寻找新时段；取消时确认并移除现有预约。
5. 转接：如果预约或变更未成功、患者要求与人工沟通，或智能体收到其他无法处理的需求，通话将转接至人工坐席。
6. 确认并结束：成功预约、改期或取消后，智能体会总结通话详情并友好结束通话。

系统提示词和智能体设置

构建有效 ElevenAgent 的第一步是系统提示词。遵循 ElevenLabs 的 提示词指南，我们将其组织为适用于所有生产环境智能体的核心模块——个性、目标、语气、工具和护栏——每项都有清晰标注的独立部分，而非一整段连续指令。

对于医疗预约安排智能体，这种结构必须考虑电话另一端的真实用户：他们可能年长、身体不适、听力不佳，或只是对来电原因感到焦虑。个性和语气部分应设定温暖、不急促的节奏，回复简短自然；日期、时间和数字应按人们说话的方式表达，而不是照着屏幕念。目标部分按顺序说明流程：先验证身份；随后根据来电者是想预约、改期还是取消，检查可用时段并确认、查找并调整现有预约，或确认要取消的预约。工具文档应注明其所需的准确口语格式输入。护栏则包含此领域特有的规则：绝不透露超出来电者已提供范围的 PHI；工具失败时绝不虚构可用时段或预约详情；拒绝回答临床问题，并建议咨询来电者自己的医疗服务提供者；如有人描述紧急症状或医疗急症，立即升级处理。任何预约操作前必须验证身份，这条规则应反复强调，而非只写一次。这是智能体最不能遗漏的底线。

接下来，可以添加更多智能体配置，例如首条消息、不同语言（请确保已启用 语言检测系统工具）、所选 LLM、对话式 ElevenLabs 文本转语音模型以及 ElevenLabs 音色。

可在此处查看系统提示词示例。

护栏

系统提示词中的护栏部分涵盖指令级规则，模型会高度重视这些规则。但提示词仍属于非确定性层，在长时间通话中容易发生偏移。ElevenAgents 通过自身的 防护机制 提供独立的运行时执行机制作为补充。其中包括：在对话变长时强化系统提示词的 Focus Guardrail；在智能体回复前捕获提示词注入尝试的 Manipulation Guardrails；以及实时评估每条回复、可在来电者听到前拦截回复的 Content 和 Custom Guardrails。每项护栏都可配置执行模式——近乎零延迟的 streaming，或等待回复通过检查的 blocking——以及触发后的退出策略：结束通话，或向下一轮注入纠正反馈后重试。

对于此智能体，可为医疗或诊所专属规则定义自定义护栏：拦截疾病诊断或治疗建议、账单问题、药物剂量指导，以及任何替代持证临床医生建议的内容。对于紧急症状，可将退出策略设为携带反馈重试并转接人工，使护栏将通话交给工作人员，而不是直接结束通话。

工具

流程中的每一步都需要特定的 webhook 和集成工具，以便在与患者交谈时执行相应操作。

EHR 验证工具

要根据 EHR 中的记录验证患者身份，将使用 FHIR GET /Patient API 操作。将其添加为指向 HAPI FHIR 基础 URL 的 webhook 工具，并将 family、given、identifier 和 birthdate 设置为由 LLM 填充的参数。验证阶段的首次工具调用会通过一次查询，将来电者姓名和出生日期发送至端点：

GET /baseR4/Patient?family={lastName}&given={firstName}&birthdate={YYYY-MM-DD}

只有查询恰好返回 1 条记录才视为匹配；仅满足此条件时，智能体才能进入预约阶段。

可在此处查看该工具的 JSON 示例。

Twilio SMS 验证工具

确认 EHR 匹配后，验证阶段将进入第二重验证：向患者发送一次性验证码，并在执行其他操作前完成确认。设置步骤如下：

1. 创建 SMS webhook 工具。配置两个工具：send_SMS_verification 和 check_SMS_verification，两者均指向 Twilio Verify 服务。两者的 URL 路径中都需要 Verify Service SID（Verify 服务设置中的 VA... 值），并使用作为密钥存储的 Account SID 和 Auth Token 构建 Basic 身份验证标头。

2. 使用系统变量设置收件人。ElevenAgents提供系统变量，会在任何语音通话中自动将来电者手机号填入 system__caller_id，因此应将 {{system_caller_id}} 作为 To 参数传入，无需让来电者口述号码。在与真实 EHR 集成的生产环境中，验证码应发送至患者记录中存储的手机号，而不是来电者标识号码。

3. 启用 skip_turn。将此系统工具与 webhook 工具一同添加后，智能体可在来电者查找短信时安静等待，而不会在停顿期间说话。

只有同时通过 EHR 查询和 OTP 验证的来电者，才能进入预约阶段。

可在此处和此处查看两个工具的 JSON 示例。

日历集成工具

预约阶段需要通过真实日历检查可用时段、预约、改期和取消。设置 Cal.com 集成需要以下 3 步：

1. 连接集成。在智能体的工具标签页中，添加 Cal.com 集成并点击 Connect。

2. 固定事件类型。每个日历工具都需要一个事件类型 ID，用于告知 Cal.com 应预约哪类事件。使用 Cal.com 控制台中的 ID，将其作为已连接工具中的固定参数。

3. 设置参与者邮箱。预约工具还需要参与者邮箱。为演示起见，可将其固定为自己的邮箱，以便在收件箱中收到确认通知。在接入真实 EHR 的生产环境中，应从患者记录的邮箱中填充，而不是硬编码。

之后，预约流程将取决于 Greeting 阶段收集到的需求。对于新预约，智能体先调用 calcom_get_available_slots 查询可用时段，再提供选项；来电者确认后调用 calcom_create_booking。务必按此顺序执行，因为先检查可用性才能避免重复预约。对于改期或取消，智能体会先使用 calcom_find_bookings_by_attendee 查找来电者的现有预约，与来电者确认具体预约后，再通过 calcom_cancel_booking 取消；如需改期，则先预约新时段，再取消旧预约。

转接人工

如需转接人工，可使用 ElevenLabs 的 transfer_to_number 系统工具。将其作为智能体级别的系统工具添加，以便 Greeting、Verification 和 Booking 阶段均可使用。对于转接规则，添加 E.164 格式的目标电话号码，以及描述何时触发的自然语言条件。LLM 会结合这些条件和工具描述，决定何时及转接到哪里。转接类型保留默认的 Conference，因为它支持温和交接消息，可向人工坐席简要说明转接原因。

设计患者流程

工作流 是可视化的图形化对话流程，由几类节点构成：子智能体节点会在 编排器基础智能体 之上，为通话的某个阶段叠加系统提示词、工具和知识库；调度工具节点确保执行特定工具，并根据成功或失败分支；智能体转移和号码转接节点用于交接；结束节点用于结束通话。节点通过边相连，前向边可携带 LLM 条件——模型实时评估的自然语言规则，以决定采用哪条路径。我们将智能体构建为 5 个子智能体节点：Greeting、Verification、Booking、Transfer Notice 和 Close，每个节点仅使用自己的工具；另设一个可从 Transfer Notice 访问的 Phone Number Transfer 节点。

问候 是入口：接听电话、介绍诊所，并在交接前收集患者需求。它不使用工具，只收集足够的上下文以正确路由。

验证 负责前述的双重验证：使用 FHIR GET /Patient 工具确认来电者与 EHR 中的记录匹配，然后使用 send_SMS_verification 和 check_SMS_verification 工具发送并验证一次性验证码。只有通过两道验证的来电者才能继续；未通过者将通过前向边进入 Transfer Notice。

预约 包含上一节的日历工具，Greeting 阶段收集的需求决定路径：新预约时检查可用性并预约；改期时查找现有预约，先重新预约再取消；取消时确认后取消。该节点也会开放式地转至 Transfer Notice——如果日历中没有合适时段、无法匹配到来电者的现有预约，或来电者希望与工作人员沟通，边会路由至该节点，而不会让通话停滞。

转接通知 位于 workflow 其他部分和实际交接之间——这是一个简短的子智能体，唯一职责是在通话真正离开智能体前告知来电者即将转接（例如：“我现在为你接通团队中的一位工作人员。”）。将每种转接条件都先路由至该节点，而不是直接从 Greeting、Verification 或 Booking 触发 transfer_to_number，可确保无论子智能体的措辞如何变化，来电者都会听到这句话，而不会被无提示地转接。

电话转接 基于 transfer_to_number 工具构建，是 Transfer Notice 始终转发至的节点。其规则将目标号码与从上游传递来的相同条件配对——验证失败、明确提出请求、无法完成预约——在来电者已被告知即将转接后执行实际交接。

结束 仅在预约成功后进入：向来电者总结预约详情，并以友好的方式结束通话。

可在 此处查看 workflow 的 JSON 模板示例。

分析和测试

医疗语音智能体的大部分工作并不在于理想流程，而在于通话没有按预期进行时，仍要正确处理所有情况。ElevenAgents 提供平台原生的 测试和分析，因此上线前用于测试的评估标准，同样会用于生产环境中的每通电话评分，无需连接或核对其他工具。

成功标准

定义成功标准，以捕捉与业务和运营目标一致的具体评估标准。在 Analysis 标签页中，每项标准都是 LLM 根据转录文本执行的自然语言提示词，返回 成功、失败 或 未知，并附带理由。对于此智能体，可使用以下标准：

• patient_verified：“若智能体在进入预约前，通过 EHR 查询和 SMS 一次性验证码确认了来电者身份，则标记为成功。”
• appointment_booked：“若患者预约已完成，则标记为成功。”
• appointment_changed：“若患者要求改期或取消现有预约，且智能体完成了相应变更——更新或删除日历事件——并向来电者确认结果，则标记为成功。”
• call_escalated_when_requested：“若来电者要求与人工沟通且智能体已转接通话，则标记为成功；若来电者提出要求但智能体未转接，则标记为失败。”

数据收集

还可以搭配数据收集字段。例如添加 requested_action（预约、改期或取消）、appointment_date 或 appointment_type。这些字段从每份转录文本中提取结构化的字符串、布尔值或数值，并通过 通话后 webhook 推送至任何用于跟踪通话结果的下游系统。

模拟和测试

在医疗场景中，智能体必须在第一通真实来电前赢得信任——故障模式应在测试中暴露，而不是在患者面前。对话模拟 API 可模拟真实的来电者场景，包括端到端和针对性片段，并使用生产环境中相同的标准自动为结果评分——即上文定义的 patient_verified 和 appointment_booked 检查，而非仅用于测试的单独评分规则。可针对整通电话运行完整模拟，也可从对话中段开始运行局部模拟，以验证单一决策点；这样无需重跑整个流程，就能更快迭代单个节点。

对于此智能体，这意味着要编写超出理想流程的场景：来电者姓名与任何 EHR 记录都不匹配、有人两次输错 OTP、患者要求改期而非预约，以及来电者在验证过程中明确要求人工协助。这些清晰而聚焦的场景，可覆盖边界情况、工具使用和回退逻辑，而非期待问题在生产环境中自行出现。

连接 Twilio 电话号码

构建智能体后，将其连接到真实号码只需几分钟：

1. 在 ElevenLabs 控制台中，前往 电话号码，然后点击 导入号码。
2. 输入 标签、电话号码，以及 Twilio 的 账户 SID 和 认证令牌
3. 导入后，从下拉菜单中将该号码分配给智能体。
4. 拨打该号码进行测试，然后查看 Conversations 历史记录控制台，确认前几通电话是否符合预期。

准备服务真实患者

我们构建的患者预约安排智能体不只是接听电话：它在访问记录前通过 EHR 和第二重 OTP 验证身份；通过 Cal.com 的 API 直接操作实时日历，完成预约、改期和取消；并且知道何时应将来电者交给人工。确定性的 workflow、运行时护栏和评估标准，为团队提供医疗部署所需的审计轨迹和可重复测试模式。

上线后，这套模式才能真正发挥作用。构建期间定义的评估标准会成为上线门槛——当智能体能持续通过这些标准且指标趋于稳定时，便可有信心上线，而非凭主观判断；上线后，学习将从模拟测试转向生产转录文本。我们曾在此前的博客文章中介绍这些实践，包括分阶段发布和判断何时停止迭代。

迈向 HIPAA 合规的关键一步是数据处理。启用零留存模式后，通话一结束，系统便会删除通话录音、转录文本和包含 PII 的元数据，从而消除电话部署中最大的合规风险来源。结合通话后 webhook，可见性并不会消失——通话结束时，每次预约结果、验证结果和评估分数都会实时发送至自己的系统。

现在，你已经拥有一套模板，可将智能体语音 AI 部署在诊所的第一入口。预约安排是来电量最大的起点，同一模式也可扩展至患者接诊、处方续配、账单和就诊后随访——这样每类来电都不必在非工作时间转入语音信箱。我们的前线部署工程团队与医疗机构紧密合作，将此类部署转化为具体产品能力。如果希望将面向患者的 workflow 引入 ElevenLabs Agents，并满足医疗行业所需的合规要求，欢迎试用此方法并告诉我们你的想法。