尧图网页设计 
如何用 LiveKit SIP 外呼搭建 RSVP 确认语音代理并把通话结果写回事件数据库【免费下载链接】Nebius-CookbookA collection of projects showcasing RAG, agents, workflows, and other AI use cases项目地址: https://gitcode.com/GitHub_Trending/ne/Nebius-CookbookNebius-Cookbook 仓库中的livekit_rsvp_agent项目解决的是一个很具体的问题活动开始前如何自动拨打电话确认每位“待定”参会人是否还来、带几名嘉宾并把通话结果写回事件数据库。它用 LiveKit Agents 跑语音流水线用 LiveKit Telephony 的 SIP trunk 向外拨号通话内容理解交给 Deepgram STTnova-3、Nebius Token Factory 的 LLMmeta-llama/Meta-Llama-3.1-70B-Instruct和 Cartesia TTS最终通过 agent 的 function tool 调用把参会人状态更新为confirmed、declined、maybe或no_answer。这篇文章覆盖从环境准备、配置外呼 trunk、启动 agent worker、发起 SIP 外呼到核对结果是否写回data/attendees.json的完整部署路径。前提条件按 README 的 Prerequisites 一节部署前需要准备Python 3.10 和 uvpyproject.toml中requires-python 3.10一个LiveKit Cloud项目提供LIVEKIT_URL、LIVEKIT_API_KEY、LIVEKIT_API_SECRET三个值一个SIP outbound trunk在 LiveKit Cloud 控制台的 Telephony → Trunks 页面配置需要 Twilio、Telnyx、Plivo、Exotel 或 Wavix 等 SIP 提供商以及一个真实的、可用来外呼的号码。把 trunk ID 存为SIP_OUTBOUND_TRUNK_IDNebius、Deepgram、Cartesia 三个模型提供商的 API key。没有可用的 SIP trunk 和真实号码外呼链路无法走通——这是该项目区别于纯 Web 语音 demo 的关键前置条件。配置环境变量与依赖在项目目录下复制并填写环境变量文件cd voice_agents/livekit_rsvp_agent cp .env.example .env # 填入各 key特别是 SIP_OUTBOUND_TRUNK_ID uv sync.env文件结构参见 .env.example其中需要替换的变量及含义变量说明LIVEKIT_URL/LIVEKIT_API_KEY/LIVEKIT_API_SECRETLiveKit Cloud 项目凭证SIP_OUTBOUND_TRUNK_ID你在 LiveKit Cloud 配置的出站 trunk ID示例文件中的形如ST_xxxxxxxxxxxx的值是占位示例必须换成真实 trunk IDNEBIUS_API_KEY/DEEPGRAM_API_KEY/CARTESIA_API_KEY三个模型提供商的 keyAGENT_NAME注册到 LiveKit 的 agent 名称默认rsvp-agent注释明确要求它与 worker 侧的WorkerOptions.agent_name保持一致dispatch 侧读取的就是这个变量依赖安装由uv sync完成依赖清单见 pyproject.tomllivekit-agents、livekit-plugins-openai、livekit-plugins-cartesia、livekit-plugins-deepgram、livekit-plugins-silero、livekit-api、python-dotenv、loguru。准备事件与参会人数据通话内容来自data/下的两个 JSON 文件tools.py 把它们当作线程安全的 JSON 数据库来读写data/event.json事件元数据名称、日期、时间、地点、主办方。仓库示例是Spring Tech Mixerdata/attendees.json参会人列表每条记录含id、name、phone、status、guests、notes、attempts。README 要求把phone改成真实号码且使用 E.164 格式例如14155550101。status只能是pending、confirmed、declined、maybe、no_answer之一——tools.py的update_attendee会校验该集合非法值直接抛ValueError。dispatcher 只拨打status pending且未超过重试上限的记录所以测试前确认目标记录的status是pending。启动 agent worker在一个终端启动 worker它会常驻并等待被 dispatch 的任务uv run python agent.py devworker 的入口逻辑在 agent.py 的entrypoint从 job 的 metadata 解析attendee_idmetadata 缺失或 JSON 解析失败会记 warningattendee_id缺失或查无此人会直接中止这是通话前最常见的静默失败点对该参会人执行increment_attempts即把attempts计数 1 写回 JSON组装AgentSessionDeepgram STTnova-3、openai.LLM.with_nebius模型meta-llama/Meta-Llama-3.1-70B-Instruct读取NEBIUS_API_KEY、Cartesia TTSCARTESIA_VOICE常量指定 voice id、Silero VAD启动RSVPAgent会话并以“向 {姓名} 打招呼并开始 RSVP 确认”为指令发起第一轮回复。RSVPAgent定义了 4 个 function tool是“写回数据库”动作的实际载体confirm_attendance(guests_count)→ 状态写为confirmed并更新guestsdecline_attendance(reason)→ 状态写为declinednotes记录原因mark_maybe(follow_up_note)→ 状态写为maybeend_call→ 结束会话。发起 SIP 外呼在另一个终端运行 dispatcherworker 必须在运行中# 拨打所有 pending 参会人 uv run python dispatch.py # 或只拨打一名参会人做测试 uv run python dispatch.py --id A1建议先用--id A1单拨验证整条链路再跑全量。dispatch.py 对每位参会人依次执行三件事创建房间rsvp-{id}-{随机6位hex}调用create_dispatch把 agent名称取自AGENT_NAME默认rsvp-agent派进该房间metadata 里带attendee_id调用create_sip_participant通过SIP_OUTBOUND_TRUNK_ID指向的 trunk 向参会人号码外呼wait_until_answeredTrue若拨号抛异常attempts1达到MAX_ATTEMPTS源码中为 2则把记录写为no_answer否则只更新attempts留待下一轮重试相邻两次拨号之间asyncio.sleep(1)做温和限速。全量模式下目标集合的筛选条件是status pending and attempts MAX_ATTEMPTS即已确认、已拒绝或重试耗尽的记录不会被重复拨打。验证结果是否写回部署是否成功的判据直接落在文件和控制台日志上检查 JSON 数据文件。通话结束后打开data/attendees.json对应记录的字段应已被更新。以仓库自带的 A1 记录为例文档示例的初始状态是status: pending, attempts: 0通话完成并得到确认后记录应变为status: confirmed且guests为通话中确认的人数attempts也会因 worker 侧的increment_attempts增加。若拨号失败且重试耗尽则变为status: no_answer。检查日志。dispatcher 侧每次拨号会输出示例结果姓名号码取决于你的数据Dialing Arindam Majumder (91 8902208995) in room rsvp-A1-3f2a1cworker 侧在每个 tool 调用时输出例如Confirmed Arindam Majumder (1)、Marked maybe for ...、Ending call with ...。worker 侧如果出现No attendee_id in job metadata; aborting或Unknown attendee_id...; aborting说明 dispatch 的 metadata 与数据文件对不上应核对--id参数和attendees.json中的id。限制与后续改造点当前“事件数据库”是本地 JSON 文件适合验证链路README 的 Customizing 一节指出接入真实环境时应把tools.py的 JSON 读写替换为你自己的后端Eventbrite、Hubspot、Postgres 等。重试上限MAX_ATTEMPTS是 dispatch.py 顶部的常量当前为 2调整重试策略改这一处即可。如需定时外呼例如活动前 24 小时README 建议把dispatch.py挂到 cron、Celery beat 或 GitHub Action 上。想换 LLM 或音色分别在 agent.py 中改openai.LLM.with_nebius的 model 参数和CARTESIA_VOICE常量。【免费下载链接】Nebius-CookbookA collection of projects showcasing RAG, agents, workflows, and other AI use cases项目地址: https://gitcode.com/GitHub_Trending/ne/Nebius-Cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 LiveKit SIP 外呼搭建 RSVP 确认语音代理并把通话结果写回事件数据库
如何用 LiveKit SIP 外呼搭建 RSVP 确认语音代理并把通话结果写回事件数据库【免费下载链接】Nebius-CookbookA collection of projects showcasing RAG, agents, workflows, and other AI use cases项目地址: https://gitcode.com/GitHub_Trending/ne/Nebius-CookbookNebius-Cookbook 仓库中的livekit_rsvp_agent项目解决的是一个很具体的问题活动开始前如何自动拨打电话确认每位“待定”参会人是否还来、带几名嘉宾并把通话结果写回事件数据库。它用 LiveKit Agents 跑语音流水线用 LiveKit Telephony 的 SIP trunk 向外拨号通话内容理解交给 Deepgram STTnova-3、Nebius Token Factory 的 LLMmeta-llama/Meta-Llama-3.1-70B-Instruct和 Cartesia TTS最终通过 agent 的 function tool 调用把参会人状态更新为confirmed、declined、maybe或no_answer。这篇文章覆盖从环境准备、配置外呼 trunk、启动 agent worker、发起 SIP 外呼到核对结果是否写回data/attendees.json的完整部署路径。前提条件按 README 的 Prerequisites 一节部署前需要准备Python 3.10 和 uvpyproject.toml中requires-python 3.10一个LiveKit Cloud项目提供LIVEKIT_URL、LIVEKIT_API_KEY、LIVEKIT_API_SECRET三个值一个SIP outbound trunk在 LiveKit Cloud 控制台的 Telephony → Trunks 页面配置需要 Twilio、Telnyx、Plivo、Exotel 或 Wavix 等 SIP 提供商以及一个真实的、可用来外呼的号码。把 trunk ID 存为SIP_OUTBOUND_TRUNK_IDNebius、Deepgram、Cartesia 三个模型提供商的 API key。没有可用的 SIP trunk 和真实号码外呼链路无法走通——这是该项目区别于纯 Web 语音 demo 的关键前置条件。配置环境变量与依赖在项目目录下复制并填写环境变量文件cd voice_agents/livekit_rsvp_agent cp .env.example .env # 填入各 key特别是 SIP_OUTBOUND_TRUNK_ID uv sync.env文件结构参见 .env.example其中需要替换的变量及含义变量说明LIVEKIT_URL/LIVEKIT_API_KEY/LIVEKIT_API_SECRETLiveKit Cloud 项目凭证SIP_OUTBOUND_TRUNK_ID你在 LiveKit Cloud 配置的出站 trunk ID示例文件中的形如ST_xxxxxxxxxxxx的值是占位示例必须换成真实 trunk IDNEBIUS_API_KEY/DEEPGRAM_API_KEY/CARTESIA_API_KEY三个模型提供商的 keyAGENT_NAME注册到 LiveKit 的 agent 名称默认rsvp-agent注释明确要求它与 worker 侧的WorkerOptions.agent_name保持一致dispatch 侧读取的就是这个变量依赖安装由uv sync完成依赖清单见 pyproject.tomllivekit-agents、livekit-plugins-openai、livekit-plugins-cartesia、livekit-plugins-deepgram、livekit-plugins-silero、livekit-api、python-dotenv、loguru。准备事件与参会人数据通话内容来自data/下的两个 JSON 文件tools.py 把它们当作线程安全的 JSON 数据库来读写data/event.json事件元数据名称、日期、时间、地点、主办方。仓库示例是Spring Tech Mixerdata/attendees.json参会人列表每条记录含id、name、phone、status、guests、notes、attempts。README 要求把phone改成真实号码且使用 E.164 格式例如14155550101。status只能是pending、confirmed、declined、maybe、no_answer之一——tools.py的update_attendee会校验该集合非法值直接抛ValueError。dispatcher 只拨打status pending且未超过重试上限的记录所以测试前确认目标记录的status是pending。启动 agent worker在一个终端启动 worker它会常驻并等待被 dispatch 的任务uv run python agent.py devworker 的入口逻辑在 agent.py 的entrypoint从 job 的 metadata 解析attendee_idmetadata 缺失或 JSON 解析失败会记 warningattendee_id缺失或查无此人会直接中止这是通话前最常见的静默失败点对该参会人执行increment_attempts即把attempts计数 1 写回 JSON组装AgentSessionDeepgram STTnova-3、openai.LLM.with_nebius模型meta-llama/Meta-Llama-3.1-70B-Instruct读取NEBIUS_API_KEY、Cartesia TTSCARTESIA_VOICE常量指定 voice id、Silero VAD启动RSVPAgent会话并以“向 {姓名} 打招呼并开始 RSVP 确认”为指令发起第一轮回复。RSVPAgent定义了 4 个 function tool是“写回数据库”动作的实际载体confirm_attendance(guests_count)→ 状态写为confirmed并更新guestsdecline_attendance(reason)→ 状态写为declinednotes记录原因mark_maybe(follow_up_note)→ 状态写为maybeend_call→ 结束会话。发起 SIP 外呼在另一个终端运行 dispatcherworker 必须在运行中# 拨打所有 pending 参会人 uv run python dispatch.py # 或只拨打一名参会人做测试 uv run python dispatch.py --id A1建议先用--id A1单拨验证整条链路再跑全量。dispatch.py 对每位参会人依次执行三件事创建房间rsvp-{id}-{随机6位hex}调用create_dispatch把 agent名称取自AGENT_NAME默认rsvp-agent派进该房间metadata 里带attendee_id调用create_sip_participant通过SIP_OUTBOUND_TRUNK_ID指向的 trunk 向参会人号码外呼wait_until_answeredTrue若拨号抛异常attempts1达到MAX_ATTEMPTS源码中为 2则把记录写为no_answer否则只更新attempts留待下一轮重试相邻两次拨号之间asyncio.sleep(1)做温和限速。全量模式下目标集合的筛选条件是status pending and attempts MAX_ATTEMPTS即已确认、已拒绝或重试耗尽的记录不会被重复拨打。验证结果是否写回部署是否成功的判据直接落在文件和控制台日志上检查 JSON 数据文件。通话结束后打开data/attendees.json对应记录的字段应已被更新。以仓库自带的 A1 记录为例文档示例的初始状态是status: pending, attempts: 0通话完成并得到确认后记录应变为status: confirmed且guests为通话中确认的人数attempts也会因 worker 侧的increment_attempts增加。若拨号失败且重试耗尽则变为status: no_answer。检查日志。dispatcher 侧每次拨号会输出示例结果姓名号码取决于你的数据Dialing Arindam Majumder (91 8902208995) in room rsvp-A1-3f2a1cworker 侧在每个 tool 调用时输出例如Confirmed Arindam Majumder (1)、Marked maybe for ...、Ending call with ...。worker 侧如果出现No attendee_id in job metadata; aborting或Unknown attendee_id...; aborting说明 dispatch 的 metadata 与数据文件对不上应核对--id参数和attendees.json中的id。限制与后续改造点当前“事件数据库”是本地 JSON 文件适合验证链路README 的 Customizing 一节指出接入真实环境时应把tools.py的 JSON 读写替换为你自己的后端Eventbrite、Hubspot、Postgres 等。重试上限MAX_ATTEMPTS是 dispatch.py 顶部的常量当前为 2调整重试策略改这一处即可。如需定时外呼例如活动前 24 小时README 建议把dispatch.py挂到 cron、Celery beat 或 GitHub Action 上。想换 LLM 或音色分别在 agent.py 中改openai.LLM.with_nebius的 model 参数和CARTESIA_VOICE常量。【免费下载链接】Nebius-CookbookA collection of projects showcasing RAG, agents, workflows, and other AI use cases项目地址: https://gitcode.com/GitHub_Trending/ne/Nebius-Cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考