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

电话仍是医疗服务的第一入口，但如今已拥堵不堪。梅奥诊所研究和 Epic案例研究的数据均显示，约 30% 的预约安排发生在正常营业时间之外。转入语音信箱的电话，往往意味着预约悄然落空；而本应接听这些电话的前台人员也人手紧张、流动频繁。语音智能体已不再只是演示，而是诊所填补这一缺口的方式。预约安排是最常见的切入点：量大、重复、可预测，占据前台大量工作，而且无需临床判断。

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

本指南将使用 ElevenAgents 构建这样的智能体：可通过电话访问、连接示例 EHR，可端到端完成预约、改期和取消，并在需要时转接人工。你将了解如何通过工作流、安全护栏、测试和分析确保其合规运行，并部署在为受监管医疗服务打造的基础设施上。

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

前提条件

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

• 一个 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 条记录，才能确认匹配。返回 0 条表示未匹配；返回多条则表示搜索参数不够具体，无法安全地继续。 

架构

本指南将构建一个通过 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。每项安全护栏都可配置执行模式：流式模式可实现近乎零延迟；阻塞模式则会在回复通过检查前暂缓发送。还可配置触发后的退出策略：结束通话，或将纠正反馈注入下一轮后重试。

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

工具

流程中的每一步都需要特定的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 匹配后，验证阶段将进入第二重验证：向患者发送短信一次性验证码，并在继续任何操作前完成确认。设置流程分为 3 步：

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 要预约哪类事件。使用该 ID 在已连接工具中将其设为固定参数。可在 Cal.com 控制台获取。

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

之后，预约流程取决于问候阶段收集到的意图。对于新预约，智能体先调用 calcom_get_available_slots 查询开放时段，再向来电者提供选择，然后在其确认后调用 calcom_create_booking。始终遵循这一顺序，因为先查询可用时段才能避免重复预约。对于改期或取消，智能体先通过 calcom_find_bookings_by_attendee 查找来电者的现有预约，与来电者确认具体预约后，再通过 calcom_cancel_booking 将其取消；如果是改期，则先预约新时段，再取消旧预约。

人工转接

如需转接人工，可使用 ElevenLabs 的 transfer_to_number 系统工具。在智能体层级将其添加为系统工具，以便从问候、验证或预约阶段均可调用。对于转接规则，添加采用 E.164 格式的目标电话号码，并用自然语言描述应在何时触发。LLM 会根据这些条件及工具说明决定何时、转接至何处。转接类型保留为默认的 Conference，因为它支持温和交接消息，向人工接线员简要说明来电转接原因。

构建患者旅程

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

Greeting 是入口：它接听电话、介绍诊所，并在交接前收集患者意图——自身不使用工具，只收集足以正确路由的上下文。

Verification 执行前述双重验证，使用 FHIR GET /Patient 工具确认来电者与 EHR 中的记录匹配，然后使用 send_SMS_verification 和 check_SMS_verification 工具发送并核验一次性验证码，来电者通过前不得继续。只有通过这两道验证的来电者才能前进；未通过者会通过前向边转至 Transfer Notice。

Booking 包含上一节的日历工具，问候阶段收集的意图决定路径：新预约时查询可用时段并预约；改期时查找现有预约，并在取消前重新预约；取消时确认并取消。该节点也会开放地失败至 Transfer Notice——如果日历中没有合适时段、无法匹配来电者的现有预约，或来电者希望与工作人员交谈，边会将其路由至该节点，而不会让通话停滞。

Transfer Notice 位于工作流其余部分与实际交接之间——这是一个简短的子智能体，唯一职责是在通话真正离开智能体前告知来电者即将转接（例如：“我现在为你接通团队成员。”）。所有转接条件都先经过此节点，而不是从 Greeting、Verification 或 Booking 直接触发 transfer_to_number，这样即使各子智能体的措辞不同，也能确保来电者总能听到这句话，而不会被静默转接。

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

Close 仅在预约成功后触达：它向来电者总结预约详情，并以亲切的语气结束通话。

可在 此处查看工作流 JSON 模板示例。

分析和测试

医疗语音智能体的大部分工作，不在于顺利流程，而在于通话未按预期进行时仍须正确处理的一切。ElevenAgents 内置测试和分析功能。这意味着上线前测试所用的评估标准，也会在生产环境中为每次通话评分，无需连接或协调额外工具。

成功标准

定义成功标准，以捕捉与业务和运营目标一致的具体评估条件。在 Analysis 标签页中，每项标准都是 LLM 针对转录文本运行的一条自然语言提示词，返回 success、failure 或 unknown，并附带理由。此智能体可包括以下标准：

• 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 控制台中，前往 Phone Numbers，然后点击 Import number。
2. 输入 Label、Phone Number，以及 Twilio Account SID 和 Auth Token
3. 导入后，通过下拉菜单将该号码分配给智能体
4. 拨打该号码进行测试，然后查看 Conversations 历史记录控制台，确认前几通电话是否符合预期。

准备服务真实患者

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

真正上线时，这一模式才体现价值。构建期间定义的评估标准会成为上线门槛——当智能体持续通过这些标准且指标趋于稳定时，你就能有信心上线，而不必凭主观判断——上线后，学习重点则从模拟测试转向生产转录文本。我们曾在此前的博客中介绍这些实践，包括分阶段发布以及何时停止迭代。

迈向 HIPAA 合规的关键一步是数据处理。启用 Zero Retention Mode后，通话一结束便会删除通话录音、转录文本和包含 PII 的元数据，从而消除电话部署中最大的合规风险来源。配合通话后 webhook，不会失去任何可见性——通话结束时，每项预约结果、验证结果和评估分数都会实时发送到你的系统。

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