在线咨询

专属客服在线解答，提供专业解决方案

工单支持

专业技术支持团队，随时响应服务需求

首页博客正文

AI 面试系统怎么开发？从实时语音对话到智能追问的技术实现

2026-11-09

奇维香蕉果

对话式 AI 技术解析

开发一套 AI 面试系统，最直接的需求是让候选人打开一个链接，就能与 AI 面试官完成一场语音面试。候选人进入页面后，AI 根据岗位要求提问；候选人通过麦克风回答，AI 听完后决定继续追问还是切换下一题。面试结束，系统整理问答记录，交给招聘人员查看。

前端页面并不复杂。真正需要处理的是实时语音与面试业务之间的衔接。如果完全自行开发，团队需要搭建实时音视频传输、语音识别、语言模型、语音合成、轮次判断和打断控制等模块。采用声网对话式 AI 引擎，可以将实时通信与语音模型编排交给现有服务，开发者重点实现岗位题库、追问逻辑、面试流程和招聘系统集成。

下面以 Web 端一对一语音面试为例，介绍 AI 面试系统的技术架构和开发流程。

一. 一套 AI 面试系统需要实现哪些功能？

可以先从最小可用版本（MVP）入手，不必一开始就增加数字人形象、复杂评分模型和多角色面试。

第一版需要完成五项功能：

实时语音面试：候选人使用浏览器麦克风，与 AI 面试官直接对话。
岗位问题管理：根据岗位要求配置基础问题、能力维度和追问方向。
动态追问：根据候选人实际回答补充提问，而不是机械播放固定题库。
面试状态管理：支持开始、暂停、重复问题、跳过、断线恢复和正常结束。
面试记录：保存经过授权的问答内容，形成可供招聘人员复核的记录。

在这个版本中，AI 面试官只需要一个语音形象。候选人看到当前问题、面试进度和麦克风状态，就可以完成交互。

如果后续需要视频面试，可以打开候选人的摄像头；需要可视化 AI 面试官时，再集成数字人服务。这些能力不影响核心的面试对话流程。

1. 技术底座与面试业务需要分开设计

AI 面试系统可以分为两层。

实时交互层：负责候选人的音频采集、传输、识别，以及 AI 的语音生成、播放、轮次判断与打断。

面试业务层：负责岗位信息、题库、追问、面试进度、数据保存，以及招聘人员后续的人工复核。

声网 RTC 和对话式 AI 引擎主要解决前一层的问题。面试计划、能力评估和 ATS（Applicant Tracking System，申请人跟踪系统）集成，需要开发者自行实现。

二. AI 面试系统的整体技术架构

下面是一种适合一对一语音面试的参考架构。

AI 语音面试系统架构

候选人 Web / App
麦克风 · 当前问题 · 面试进度 · 可选摄像头

↕ RTC 实时音频

声网对话式 AI 引擎
ASR · 轮次检测 · LLM 接入 · TTS · 打断控制

↕ 模型请求 / 业务调用

自定义面试 Agent
问题选择
动态追问
上下文管理

面试业务服务
岗位题库
流程状态
身份与权限

↓ 业务数据

面试记录 / 招聘平台
转录记录 · 面试摘要 · 证据整理 · ATS · 人工复核

示意图描述模块职责，并非所有模块都必须独立部署。实时交互链路与招聘业务数据链路应分别进行鉴权、存储和权限管理。

1. RTC：让候选人与 AI 建立实时音频连接

候选人进入面试页面后，通过声网 RTC SDK 加入指定频道，发布麦克风音频。

服务端创建对话式智能体，让智能体加入同一 RTC 频道，订阅候选人的音频并返回语音回复。

对于每场一对一面试，建议使用独立的频道和对应的访问凭证，避免候选人的音频进入其他面试会话。

RTC 负责实时媒体传输。岗位题库、面试评价和业务操作并不在 RTC SDK 内完成。

2. 对话式 AI 引擎：连接 ASR、LLM 和 TTS

声网对话式 AI 引擎支持接入 ASR、LLM 和 TTS 服务，形成实时语音交互链路。

候选人讲话时，语音首先由 RTC 传输到智能体；ASR 将语音转换为文本；LLM 根据当前面试上下文生成回复；TTS 将回复转换为语音，通过 RTC 播放给候选人。

引擎还提供轮次检测、智能打断和智能体状态事件等能力，用于控制语音交互节奏。

需要注意，ASR、LLM、TTS 的模型选择、供应商配置以及相关费用，应结合实际部署方案确定。

3. 面试 Agent：决定当前应该问什么

面试 Agent 可以采用自定义 LLM 服务实现。

它收到候选人的回答后，读取当前岗位、已完成的问题、能力覆盖情况和剩余面试时间，再决定生成追问、切换问题或结束面试。

开发者可以使用与 OpenAI Chat Completions API 兼容的自定义服务接入声网对话式 AI 引擎，在模型请求处理逻辑中整合面试状态和题库信息。

这样，实时语音处理与招聘业务逻辑可以分开迭代。

三. 如何使用声网搭建 AI 面试的实时语音链路？

下面按照声网官方 RESTful API 的接入流程，说明怎样实现最基础的语音面试。

步骤 1：开通服务并准备鉴权信息

首先在声网控制台创建项目，开通 RTC 和对话式 AI 引擎。

根据官方快速开始文档，开发者需要准备：

声网 App ID。
用于服务端 RESTful API 鉴权的凭证。
用于客户端与智能体进入 RTC 频道的 RTC Token。
所选 LLM 和 TTS 服务所需的配置信息。

RESTful API 鉴权凭证与 RTC Token 用途不同，不能混用。涉及服务端密钥的操作，应在业务服务器执行，不应把密钥写入前端 JavaScript。

步骤 2：创建独立的面试频道

业务服务器为一场面试创建唯一的会话 ID，并生成相应的 RTC 频道名与访问凭证。

例如，可以将一场面试关联到：

{
  "interview_id": "interview_10001",
  "channel": "interview_room_10001",
  "candidate_rtc_uid": "1001",
  "status": "waiting"
}

上述数据是招聘业务系统内部的记录示例，不是声网创建频道的 API 请求格式。

随后，候选人通过声网 RTC SDK 加入频道，并开启麦克风采集。

业务系统应确保频道名不可被随意猜测后直接访问，并使用经过服务端签发的有效 Token 控制加入权限。

步骤 3：调用 RESTful API 创建 AI 面试官

客户端准备就绪后，服务端调用声网创建对话式智能体的接口：

POST /cn/api/conversational-ai-agent/v2/projects/{appid}/join

创建请求中需要指定 RTC 频道、智能体 UID、需要订阅的候选人 UID，以及 ASR、LLM、TTS 等配置。

例如，官方接口中的关键配置字段包括：

{
  "name": "ai_interviewer_demo",
  "properties": {
    "channel": "interview_room_10001",
    "token": "RTC_TOKEN",
    "agent_rtc_uid": "2001",
    "remote_rtc_uids": ["1001"],
    "asr": {
      "language": "zh-CN"
    },
    "llm": {
      "url": "https://your-server.example.com/chat/completions",
      "api_key": "YOUR_LLM_SERVICE_KEY",
      "system_messages": [
        {
          "role": "system",
          "content": "你是一名负责初步面试的AI面试官。根据业务服务提供的面试计划提问，一次只问一个问题。"
        }
      ],
      "greeting_message": "你好，欢迎参加本次面试。我们先从你的项目经历开始。"
    }
  }
}

注意：上面只展示与业务相关的部分字段，并非可以直接发送的完整创建请求。正式调用还需要根据所选供应商补充 TTS 配置、必要的模型参数、鉴权和其他必填字段。

创建成功后，接口会返回 agent_id。智能体加入相应 RTC 频道，候选人就可以开始语音交流。

开发者可以先通过声网 Playground 验证 ASR、LLM、TTS 配置，再使用控制台提供的 View code 获取完整的服务端调用示例，避免手动拼装复杂的供应商参数。

步骤 4：让 AI 面试官接入自定义业务逻辑

对于面试场景，仅在 System Prompt 中写上“你是一名面试官”，通常不足以实现稳定的业务流程。

更合适的方式是提供自定义 LLM 服务。

根据声网自定义大模型接入说明，该服务需要提供兼容 OpenAI Chat Completions API 的 HTTP 接口，并按需要返回流式 SSE 响应。

在这个服务里，开发者可以先读取面试计划和当前状态，决定本轮应使用哪些上下文，再调用实际的 LLM。

例如，当前候选人正在回答“项目经历”问题，业务服务可以向模型提供需要补充的证据项，而不必把整份招聘数据库直接发送给模型。

步骤 5：结束时释放智能体资源

候选人完成面试后，业务服务器调用停止对话式智能体接口：

POST /cn/api/conversational-ai-agent/v2/projects/{appid}/agents/{agentid}/leave

同时关闭客户端音频发布，更新面试状态，并按业务要求完成记录归档。

需要注意，停止接口在当前版本中采用异步处理方式。请求成功不意味着智能体已经同步完成全部退出过程，应用应根据实际状态处理资源释放。

四. 如何实现动态追问，而不是机械播放题库？

如果 AI 只能依次朗读预设问题，整个系统更接近自动语音问卷。

真正需要开发的是：根据候选人的回答，决定是否继续追问，以及下一步应该问什么。

1. 先将岗位要求整理为结构化面试计划

例如，后端开发岗位的一项能力要求是生产故障处理。

可以为这项能力配置基础问题、需要确认的信息和最大追问次数。

{
  "competency_id": "incident_response",
  "question": "请介绍一次你处理线上故障的经历。",
  "required_evidence": [
    "候选人负责的工作",
    "定位问题的方法",
    "采取的解决措施",
    "最终结果"
  ],
  "max_followups": 2,
  "time_limit_seconds": 240
}

这是应用业务层的 JSON 配置示例，并非声网 API 的固定字段。

开发者可以根据岗位和面试时长建立多个类似的问题单元。

2. 根据回答识别缺失信息

假设候选人回答：

“之前有一次接口突然变慢，最后查出来是数据库连接池配置的问题。”

系统可以识别到，当前回答包含故障现象和大致原因，但没有充分说明个人职责、排查过程和处理结果。

面试 Agent 可以生成追问：

“你当时通过哪些日志或监控指标判断是连接池的问题？”

候选人继续回答后，系统更新当前能力项的证据记录。如果追问已经达到设定上限，就进入下一项问题。

3. 业务状态机负责控制面试节奏

不建议让语言模型完全依赖对话历史记住每道题的进度。

可以在服务端维护一份结构化面试状态：

{
  "interview_id": "interview_10001",
  "status": "in_progress",
  "current_competency": "incident_response",
  "followup_count": 1,
  "completed_competencies": [
    "project_experience"
  ],
  "remaining_seconds": 900
}

每当完成一轮候选人回答，业务系统更新当前问题状态，再决定是否允许模型继续追问。

例如，候选人已经回答完整，或者该问题已经达到时间上限，服务端就可以强制进入下一阶段。

这样可以减少重复提问、遗漏岗位要求、追问失控等情况。

4. 模型产生建议，业务服务决定执行

在生产系统中，可以让模型输出“继续追问”“切换问题”“重复当前问题”等决策建议，再由业务服务检查当前状态是否允许执行。

例如，模型建议继续追问，但当前问题已经达到最大追问次数，业务服务可以拒绝该建议并切换下一题。

声网对话式 AI 引擎支持自定义 LLM 和外部工具调用，开发者可以通过这些接口将语音对话连接到面试业务服务。

不过，题库管理、追问判断、候选人评价与流程控制并不是声网引擎直接提供的招聘功能，需要在业务层实现。

五. 候选人思考时停顿，如何避免 AI 抢话？

AI 面试有一个很常见的问题：候选人需要回忆经历，讲话中会出现较长停顿。

例如：

“那个项目里，我主要负责……嗯……接口设计，还有数据库这部分。”

如果系统仅按固定静音时长判断回答结束，就可能在候选人停顿时立即发起追问。

这时需要同时考虑语音活动检测和语义轮次判断。

1. VAD 与语义判停解决不同问题

VAD（Voice Activity Detection）用于检测用户是否正在发声。

语义轮次检测则会结合用户已经说出的内容，辅助判断当前表达是否完成。

对于面试场景，后者尤其重要。候选人可能只是短暂停顿，并没有完成回答。

声网对话式 AI 引擎提供相应的轮次检测能力，可根据不同交互场景配置结束发言与打断行为。

2. 用户说“稍等”，可以保留等待状态

根据声网对话式 AI 引擎 v2.5 的官方发版说明，语义判停配置支持识别“等一下”“稍等”等暂停意图。

3. 使用当前版本的判停与打断配置

需要注意，声网已在 v2.13 发版说明中提出相关参数迁移要求。

新的接入方案应优先使用：

properties.turn_detection.config：配置轮次检测。
properties.interruption：配置智能体打断行为。

旧版的 properties.vad.* 以及部分平铺的 turn_detection 参数已进入迁移范围，不适合直接复制到新项目中。

正式配置时应以当前发版说明和创建智能体接口文档为准。

六. 如何处理专业术语、重复问题与网络中断？

1. 使用 ASR 热词改善专业名词识别

技术岗位面试经常涉及 Redis、Kafka、Kubernetes 等专有名词。

如果 ASR 将这些术语识别错误，后续模型就可能基于错误文本生成追问。

声网当前文档支持为凤鸣 ASR 配置热词，通过 properties.asr.keywords 传入需要加强识别的词汇。

例如：

{
  "asr": {
    "language": "zh-CN",
    "vendor": "fengming",
    "keywords": [
      "Redis",
      "Kafka",
      "Kubernetes",
      "微服务"
    ]
  }
}

该示例是创建智能体请求中 properties.asr 的子配置。

目前官方文档要求热词数量不超过 128 个，并且这一配置只适用于凤鸣 ASR 或未明确指定其他 ASR 供应商的情况。

ASR 热词能够改善特定词汇的识别，但不能保证所有术语都被准确转写，仍需使用真实面试录音测试。

2. 重复问题与跳过问题由面试服务管理

候选人可能说“请再说一遍”“这个问题我先跳过”。

这些属于面试流程指令。

业务服务可以将其定义为受控操作：

重复问题：重新播报当前已确认的问题文本，不增加追问计数。
跳过问题：按业务规则标记未作答并进入下一题。
暂停面试：停止新的问题播报并管理计时状态。
结束面试：确认结束并更新会话状态。

如果使用工具调用执行这些操作，应在服务端验证面试 ID、参与者身份和当前状态，避免模型直接修改不属于本次面试的数据。

3. 网络断线后不能只恢复 RTC 连接

候选人可能在面试过程中切换网络，或者误关闭浏览器。

重新连接 RTC 频道只能恢复媒体连接，并不意味着应用的业务状态已经恢复。

因此，面试系统需要在服务端保存当前问题、已完成能力项、追问次数和面试剩余时间。

候选人重新加入后，业务服务根据实际状态决定继续当前问题、重新提问或结束异常会话。

是否复用原智能体实例、重新创建实例或恢复对话上下文，需要结合实际生命周期和服务端实现设计，不能假设 SDK 会自动恢复完整的招聘业务进度。

七. 如何生成面试记录，并接入招聘业务系统？

面试完成后，招聘人员通常需要查看候选人的实际回答，而不是只看一段模型生成的评价。

1. 获取实时转录与智能体状态

声网对话式 AI 引擎提供实时字幕相关能力。

客户端需要使用对应的 Conversational AI API 组件订阅消息，并在创建智能体时启用 RTM 数据通道。

其中，实时字幕场景涉及以下配置：

{
  "advanced_features": {
    "enable_rtm": true
  },
  "parameters": {
    "data_channel": "rtm"
  }
}

上述字段属于创建智能体请求中的 properties 子配置示例。

候选人和智能体的文本信息可以用于展示字幕、核对当前回答，以及由业务系统整理面试记录。

正式保存时，应根据具体事件格式、隐私授权和存储需求设计自己的持久化流程。实时字幕消息不应直接被当作已经完成校验的最终证据。

2. 将面试问答对应到岗位能力

业务系统可以把每一轮问题、回答及其对应的岗位能力项关联起来。

例如，候选人在生产故障问题中提到具体监控指标，可以将相关回答归档至“问题定位能力”。

如果候选人没有解释最终处理结果，系统应标记缺失信息，而不是凭借模型推测补齐。

这种结构化记录更方便招聘人员查看，也有利于后续人工面试继续追问。

3. ATS 集成由招聘业务系统实现

如果企业已有招聘平台，可以通过其允许的 API 将面试状态、经过审核的摘要和相关记录关联到候选人档案。

声网提供实时音视频与对话式 AI 能力，但不负责对接所有 ATS 产品，也不直接提供统一的招聘评分规则。

因此，在系统设计时，需要把招聘平台 API、数据字段映射、授权和失败重试单独作为业务模块实现。

八. AI 面试 Demo 可以按照什么顺序开发？

对于首次开发 AI 面试系统的团队，可以先完成一套纯语音 Demo，验证核心链路后再增加更复杂的功能。

第一阶段：跑通实时语音问答

创建声网项目并开通对话式 AI 服务，使用 Web RTC SDK 接入麦克风，通过服务端 RESTful API 创建智能体。

这一阶段先采用简单的面试官提示词，确认候选人能够正常说话、AI 能听懂并回答，且双方语音可以稳定收发。

第二阶段：接入岗位题库和面试 Agent

实现面试业务状态机和结构化问题配置，将自定义 LLM 服务接入声网对话式 AI 引擎。

先验证一份固定岗位的三到五个问题，确认模型不会遗漏问题、无限追问或擅自结束面试。

第三阶段：处理停顿、打断和异常

配置轮次检测与打断策略，测试候选人长时间思考、重复问题、跳过问题和临时网络中断等情况。

这一步应使用真实语音测试，而不能仅用文本对话代替。

第四阶段：增加记录与人工复核

接入实时转录、业务记录和面试摘要，再设计招聘人员查看页面。

初期可以先输出问题、回答、岗位能力对应信息及未回答事项，不必立即引入自动评分。

第五阶段：上线前评估性能和成本

开发者需要分别观察实时通信、模型调用、TTS 播放和业务接口的延迟。

声网对话式 AI 引擎提供对话轮次信息查询接口。当前文档支持查看每轮的 e2e_latency_ms 及 segmented_latency_ms，用于分析轮次检测、ASR、LLM 和 TTS 等处理环节。

该接口支持分页查询，并且当前仅支持查询最近 7 天内的会话轮次数据。

如果需要长期运营监测，应由业务系统按需留存相关指标，并结合用户端的实际播放时间进行验证。

九. 正式上线 AI 面试系统，需要特别注意什么？

1. 面试数据属于需要严格管理的个人信息

简历、姓名、语音、录音和工作经历都可能涉及个人信息。

系统应明确告知候选人正在与 AI 交互、是否录音或录像、数据使用目的和保存期限，并根据业务地区的适用法律与企业政策落实访问控制、删除和人工复核机制。

招聘人员应能够核对原始回答，避免直接依据错误的 ASR 转录或模型总结作出决定。

2. 不用声音特征或外貌推断不相关的岗位能力

AI 面试系统的评价依据应当与岗位实际要求相关。

候选人的口音、说话速度、停顿习惯或镜头中的表情，不应自动被转换为“能力不足”“不够自信”等招聘结论。

需要采用语音以外的合理替代方式时，例如文字面试或人工面试，业务系统也应支持相应安排。

3. 不把模型输出直接作为自动录用决定

AI 可以协助整理回答和发现需要继续确认的问题，但最终招聘决策应由企业依据相关岗位标准、适用法律和人工复核流程作出。

开发阶段还需要检查模型幻觉、错误转录、岗位不相关追问，以及不同候选人之间问题覆盖和评价标准是否一致。

4. 提前评估并发与服务配额

如果招聘平台需要同时开展大量 AI 面试，应评估 RTC 连接、对话式 AI 引擎任务、LLM、TTS、字幕和业务数据库的并发容量。

声网当前快速开始文档说明，单个 App ID 的对话式 AI 并发用户数存在默认配额，具体限制及提升方式应以控制台和官方文档为准。

不能只按前端页面能够创建多少个面试房间，推断系统能够同时承载多少场完整 AI 面试。

十. AI 面试系统的开发重点是什么？

开发 AI 面试系统，可以先把问题分成两个部分。

第一部分是实时交互：候选人能否自然讲话，AI 能否及时响应，系统能否正确处理停顿、打断和网络变化。

这一部分可以通过声网 RTC 和对话式 AI 引擎搭建，让开发者不必从零实现实时音视频传输与完整语音模型编排。

第二部分是面试业务：该问什么、什么时候追问、如何控制面试进度，以及怎样把回答整理成招聘人员能复核的记录。

这些能力需要开发者结合岗位题库、LLM、业务状态机和招聘平台 API 自行实现。

建议先开发一套能够完成 15—20 分钟一对一语音面试的最小版本，验证实时对话、追问和记录是否稳定，再逐步增加视频、数字人、复杂岗位评估与大规模并发。

对于需要快速验证方案的开发者，可以先参考声网对话式 AI 引擎快速开始完成语音 Agent 接入，再在此基础上开发自己的面试业务逻辑。

在声网，连接无限可能

想进一步了解「对话式 AI 与实时互动」？欢迎注册，开启探索之旅。

注册体验

本博客为技术交流与平台行业信息分享平台，内容仅供交流参考，文章内容不代表本公司立场和观点，亦不构成任何出版或销售行为。