教程
ADK 语音 Agent Eval：把“听起来不错”变成 CI 可测
Google 在 8 月 24 日为 Agent Development Kit（ADK）介绍了原生 Live Evaluation：开发者现在可以让一个 LLM 驱动的模拟用户直接“说话”给语音 Agent，完成多轮真实音频对话，再用自然语言 Rubric、逐轮指标和 Tool Execution 结果进行评分。官方示例使用三个 `gemini-live-2.5-flash-native-audio` Agent 串成一个 Graph Workflow，用 `gemini-3.7-flash` 控制模拟用户的对话逻辑，用 `gemini-3.1-flash-tts-preview` 合成用户音频，并可以通过 `AgentEvaluator` 接入 CI/CD。对实时语音 Agent 来说，这意味着测试终于从“人工听 Demo”进入可回归、可自动化的工程阶段。
# ADK 语音 Agent Eval：把“听起来不错”变成 CI 可测
## 文章摘要
Google 在 8 月 24 日为 Agent Development Kit（ADK）介绍了原生 Live Evaluation：开发者现在可以让一个 LLM 驱动的模拟用户直接“说话”给语音 Agent，完成多轮真实音频对话，再用自然语言 Rubric、逐轮指标和 Tool Execution 结果进行评分。官方示例使用三个 `gemini-live-2.5-flash-native-audio` Agent 串成一个 Graph Workflow，用 `gemini-3.7-flash` 控制模拟用户的对话逻辑，用 `gemini-3.1-flash-tts-preview` 合成用户音频，并可以通过 `AgentEvaluator` 接入 CI/CD。对实时语音 Agent 来说，这意味着测试终于从“人工听 Demo”进入可回归、可自动化的工程阶段。
---
语音 Agent 最危险的错觉是：
> “我刚刚打了一通电话，效果挺自然。”
这不叫测试。
因为实时语音系统可能在下一次：
- Prompt 改了一句话；
- 模型换了一个版本；
- Tool Description 改了；
- 多 Agent Handoff 顺序变化；
以后突然出现：
- 不调用工具；
- 忘记上一轮上下文；
- 用户插话时继续说；
- 身份没验证就泄露信息；
- 错过结束条件；
- 语音里把日期说错。
文本 Agent 可以比较字符串。
语音 Agent 需要测试的是：
> **整个多轮行为轨迹。**
## Google ADK 的 Live Eval 到底测什么？
官方示例不是单 Agent Chatbot。
而是一个三阶段 Workflow：
```text
Greeter Agent
↓
DOB Verifier Agent
↓
Goals Agent
```
中间还有 Tool Call：
```text
validate_date_of_birth()
```
整个过程使用：
```text
gemini-live-2.5-flash-native-audio
```
音频流持续打开。
ADK 会保留：
- Session State；
- Conversation History；
- Agent Handoff 上下文。
用户听起来像是在和一个 Agent 连续对话。
## 语音 Agent 的 Eval 不应该只看最后一句
例如医疗预约场景。
最终 Agent 说：
> “你周二下午3点有预约。”
这句话本身可能完全正确。
但如果它在：
```text
没确认姓名
没验证生日
```
之前就说出来，整个流程仍然失败。
所以 Google 示例使用的是：
```text
rubric_based_multi_turn_trajectory_quality_v1
```
评的是：
> 整条对话轨迹是否满足业务规则。
## 一个关键 Rubric：先身份验证，再披露信息
官方示例中的 Rule 类似：
```text
Across the call,
the agent confirms the caller's name
and validates date of birth
before disclosing appointment details.
```
这比：
```text
expected_output = "Tuesday 3 PM"
```
成熟得多。
因为真实业务真正关心的是：
```text
顺序
权限
工具调用
信息披露
最终结果
```
## 两种测试方式：Scenario 和 Fixed Conversation
ADK 支持两种思路。
### Conversation Scenario
只描述：
- Persona；
- Goal；
- Conversation Plan。
模拟用户自己决定每轮怎么说。
例如：
```json
{
"starting_prompt": "Hello?",
"conversation_plan": "Confirm your identity, provide DOB, ask what to bring...",
"user_persona": "NOVICE"
}
```
这种方式适合测试：
> Agent 是否真的会主动推动对话。
### Fixed Conversation
你把用户每轮话写死：
```text
Turn 1: Hi, this is John Doe.
Turn 2: My DOB is July 12, 1985.
```
适合：
- 精确回归；
- 已知 Bug；
- Compliance Case。
## 为什么 Scenario 比固定脚本更接近真实用户？
因为真人不会按 Test Case 说话。
同一个目标可能说：
```text
“我生日是85年7月12号。”
```
也可能说：
```text
“July twelfth, eighty-five.”
```
或者：
```text
“等一下，我身份证上是12号。”
```
如果只测试固定字符串，系统很容易：
> 测试全部通过，真实电话大量失败。
## Persona 是一个非常有价值的变量
Google 示例中的：
```text
NOVICE
```
模拟用户不会一次把所有必要信息全说完。
它只提供高层目标，等 Agent 主动追问。
企业可以继续增加：
```text
IMPATIENT
ELDERLY
INTERRUPTING
NON_NATIVE
ANGRY
CONFUSED
FAST_SPEAKER
```
不一定是官方内置 Persona。
可以通过 Prompt 驱动扩展。
## 用户模拟模型和音频模型是分开的
这是架构里一个很聪明的设计。
例如：
```text
model = gemini-3.7-flash
```
负责：
> “下一轮用户应该说什么？”
而：
```text
audio_model = gemini-3.1-flash-tts-preview
```
负责：
> “把这句话说出来。”
因此可以独立改变：
- Voice；
- Language；
- Accent；
- User Behavior。
这让 Eval 组合更丰富。
## 一个最小 Live Eval 配置
核心结构大致是：
```json
{
"criteria": {
"rubric_based_multi_turn_trajectory_quality_v1": {
"threshold": 0.7,
"judge_model_options": {
"judge_model": "gemini-3.7-flash"
}
}
},
"live_model_config": {
"timeout_seconds": 300
},
"user_simulator_config": {
"type": "llm_audio",
"model": "gemini-3.7-flash",
"max_allowed_invocations": 10,
"audio_model": "gemini-3.1-flash-tts-preview"
}
}
```
这几个字段都很重要。
## `max_allowed_invocations` 为什么必须有？
动态模拟用户可能出现：
```text
Agent 不结束
↓
Simulator 继续说
↓
Agent 再说
↓
无限循环
```
所以必须给测试：
> 上限。
例如：
```text
10 Turns
```
超过就失败。
生产环境同样需要类似：
- Max Turns；
- Max Duration；
- Max Tool Calls；
- Max Cost。
## 语音 Eval 应该分五层指标
### 1. Content Correctness
内容是否正确。
### 2. Workflow Correctness
有没有按正确顺序完成业务步骤。
### 3. Tool Correctness
工具是否：
- 该调时调；
- 参数正确；
- 不重复调。
### 4. Conversation Quality
是否：
- 一次只问一个问题；
- 不机械；
- 不重复；
- 能处理澄清。
### 5. Realtime Behavior
是否：
- 插话能停；
- 恢复正确；
- 沉默不过长；
- Handoff 不突兀。
## 文本测试通过，语音仍然可能失败
同一套 Case，如果不配置 `live_model_config`，可以按文本模式运行。
这非常有价值。
企业可以做：
```text
Text Eval
↓
通过
↓
Live Audio Eval
↓
通过
↓
Release
```
如果文本通过、语音失败，说明问题可能在：
- ASR/TTS；
- Turn-taking；
- Realtime State；
- Barge-in；
- Audio Timing。
而不是业务逻辑。
## 如何把它接进 CI/CD？
Google 明确表示可以通过：
```text
AgentEvaluator
```
程序化调用同一套 Pipeline。
可以设计：
```text
Pull Request
↓
Unit Test
↓
Agent Text Eval
↓
Agent Live Eval
↓
Threshold Gate
↓
Merge
```
当然，语音测试成本通常高于普通 Unit Test。
所以可以分层。
## 推荐的 CI 分层
### 每个 PR
跑：
```text
10 个核心 Text Eval
3 个核心 Live Eval
```
### Nightly
跑：
```text
50～100 个 Persona / Scenario
```
### Release Candidate
跑：
```text
全量 Voice Regression
多语言
不同声音
中断
网络波动
Tool Failure
```
这样成本更合理。
## ADK Web 为什么也很重要？
自动 Score 不是全部。
ADK Web 可以把 Live Run 重建成：
- Transcript；
- 每轮消息；
- 可播放的 Audio Clip。
也就是说，当 Eval 失败时，开发者可以：
> 直接听出问题。
这对语音系统非常重要。
很多失败看文字没问题，听起来却非常糟糕。
例如：
- 语速奇怪；
- 句子断裂；
- Handoff 突然换风格；
- 用户插话后 Agent 又接着说旧内容。
## 语音 Agent 还应该额外测哪些指标？
Google 示例主要展示 ADK 原生功能。
生产环境建议再增加：
```text
First Audio Latency
Turn Latency
Silence Time
Barge-in Stop Latency
Tool P95
Call Completion Rate
Abandonment Rate
Escalation Accuracy
```
尤其是：
> **Silence Time。**
用户最讨厌的不一定是模型慢。
而是电话里出现 4 秒死寂。
## 如何设计一个真正有用的 Eval Set？
不要只写 Happy Path。
至少包含：
### 正常用户
### 用户说错后纠正
### 用户插话
### 用户答非所问
### Tool Timeout
### Tool 返回空结果
### 身份验证失败
### 用户要求越权信息
### 通话中改变目标
### Agent Handoff
### 多语言 / 口音
### 长对话后回忆前文
这才接近真实生产。
## 最终判断
Google ADK 的 Live Evaluation 最重要的意义不是“多了一个测试命令”。
而是实时语音 Agent 终于可以从：
```text
人工 Demo
```
变成：
```text
Scenario
+
Synthetic Audio User
+
Rubric
+
Tool Metrics
+
Regression
+
CI Gate
```
任何准备把语音 Agent 放进：
- 客服；
- 医疗预约；
- 销售；
- 银行；
- 企业内部热线；
的团队，都不应该再把：
> “听起来挺自然”
当作上线标准。
更成熟的标准应该是：
> **每次 Prompt、模型和工具变化，都能自动证明关键多轮行为没有退化。**
想继续了解 Gemini Live、Google ADK、语音 Agent 和生产级 Eval，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续发布可直接落地的 AI 工程实践。