Gemini Live API 支持将函数标记为 NON_BLOCKING,语音对话可在工具执行期间继续,避免用户面对数秒沉默。
实时语音 Agent 最大的可用性问题之一是工具延迟。如果模型需要查询 CRM、订单、数据库、搜索或工单系统,而每次函数调用都会阻塞对话,用户就会经历数秒的沉默。Gemini Live API 在其级联架构中支持异步函数调用。一个函数可以标记为 NON_BLOCKING,允许对话在工具于后台执行的同时继续进行。这并不意味着模型可以凭空编造依赖工具的事实。开发者需要显式的任务状态、超时、取消、并发控制、结果关联、权限和幂等性。
文本用户可能容忍几秒钟。语音用户会立即注意到沉默。
一个正常的实时交互可能包括语音理解、CRM、数据库、搜索、模型生成和音频输出。外部系统的延迟是不可预测的。
如果每个工具调用都阻塞会话,自然的对话就会消失。
传统的流程是:
user asks
→ model calls get_refund_status
→ conversation pauses
→ backend waits four seconds
→ result returns
→ model resumes
用户会听到一个长的间隙。
对于某些事务性工作流来说这可能是可以接受的,但这是糟糕的对话设计。
使用异步函数调用:
user request
→ model starts tool call
├── tool executes in background
└── conversation continues
→ result returns
→ model incorporates result
Agent 可以在等待期间提问澄清或解释流程。
如果退款状态尚未返回,Agent 不得声称退款已完成。
known
pending
unknown
只有已确认的数据才应作为事实呈现。
合适的候选包括客户查询、订单状态、工单、库存、物流、知识检索、网络搜索、推荐以及其他独立的读取操作。
多个独立的读取调用也可以并行执行。
对支付、删除、生产变更、不可逆操作以及任何下游逻辑继续前需要的是否符合条件的决定要谨慎。
这些通常需要阻塞行为和明确审批。
microphone
→ Gemini Live session
→ tool router
├── blocking
├── non-blocking
└── approval-required
→ async task manager
├── timeout
├── retry
├── cancellation
└── idempotency
→ enterprise APIs
→ tool result
→ live session
添加授权追踪、成本控制和审计日志。
维护以下元数据:
name: get_refund_status
mode: non_blocking
timeout_ms: 5000
retry: 1
idempotent: true
risk: read
requires_confirmation: false
对于金融写入:
name: create_refund
mode: blocking
timeout_ms: 10000
retry: 0
idempotent: true
risk: financial
requires_confirmation: true
模型不应自行对业务风险进行分类。
确切语法应遵循当前 SDK 版本,但概念上:
tool = {
"function_declarations": [
{
"name": "get_order_status",
"description": "Get current order status",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"}
},
"required": ["order_id"]
},
"behavior": "NON_BLOCKING"
}
]
}
重要的行为是实时会话在函数运行期间不必停止。
不要用同步 HTTP 工作阻塞 WebSocket 回调。
async def execute_tool(call):
task_id = create_task_id(call)
task = asyncio.create_task(run_with_timeout(call))
registry[task_id] = task
async def on_tool_done(task_id):
result = await registry[task_id]
await send_tool_result(result)
外部服务可能 300 毫秒、两秒、八秒或永不响应。
一个超时的任务应返回结构化状态,而不是永远保持 pending。
不要留下死气沉沉的空白,Agent 可以说:
“客户系统稍微慢了一点。它完成之前我可以确认一些细节。”
这是异步工具的主要用户体验优势之一。
模型可能希望同时调用 CRM、订单、工单、支付、邮件和分析。
设置一个实用的限制,例如:
max_parallel_tools = 3
这可以保护下游系统并保持状态可管理。
session_id
call_id
tool
arguments
start time
conversation turn
当结果返回时,匹配调用 ID,确认会话仍然有效,判断结果是否仍然相关,然后才将其传回实时模型。
用户可能先请求订单 A,然后立即更正为订单 B。
如果可能,取消 A。如果无法取消,将其结果标记为过期,不注入活跃对话。
有用的状态包括:
PENDING
RUNNING
COMPLETED
TIMEOUT
FAILED
CANCELLED
STALE
异步系统会产生重试歧义。远程写入可能成功,但客户端丢失了响应。
对有副作用的操作(如工单创建或订单变更)使用幂等键。目标服务应保证每个键只执行一次。
真正的语音 Agent 必须支持 barge-in。
当用户打断时,停止当前音频,处理新输入,判断现有工具任务是否仍然相关,取消或标记它们为过期,然后继续更新后的目标。
有用的操作包括提问澄清、收集身份详情、解释流程以及运行独立的读取工具。
Agent 不应虚构待处理结果、承诺未确认的结果,或在确认之前声称操作已完成。
一个有用的指令是:
Never state that a tool-dependent fact is confirmed
until the corresponding tool result is received.
模型生成的工具调用不等于授权。
应用仍然需要:
user identity
→ role
→ resource permission
→ tool permission
→ argument validation
→ execution
否则语音 Agent 就成了授权绕过。
如果 CRM 结果包含身份文档、银行信息、联系方式和订单状态,而用户只问了订单状态,则只向模型返回必要的字段。
最小化模型暴露是一个基本的生产原则。
session_id
call_id
tool
mode
start
end
latency
status
retry count
cancellation
token use
business result
重要指标包括工具 P50/P95 延迟、超时率、取消率、并行调用数、任务成功率、首次音频延迟和对话沉默时间。
后端工具延迟本身不能描述用户体验。
一个工具可能需要四秒,但如果 Agent 保持对话有用,用户可能体验到不到一秒的死气沉沉。
测量沉默,而不仅仅是后端延迟。
客户问为什么包裹还没到。
Agent 在询问这是否是昨天讨论的同一订单的同时启动物流查询。
用户在工具执行期间做出回应。
当结果返回时,Agent 提供确认后的物流状态。
后端很慢,但对话从未完全停止。
一个实用的分类是:
READ_FAST
READ_SLOW
WRITE_LOW_RISK
WRITE_HIGH_RISK
FINANCIAL
PRODUCTION
READ_FAST → NON_BLOCKING
READ_SLOW → NON_BLOCKING + status
WRITE_LOW_RISK → confirmation
WRITE_HIGH_RISK → BLOCKING + confirmation
FINANCIAL → BLOCKING + strong approval
PRODUCTION → BLOCKING + multi-party approval
测试慢响应、超时、断连、重试、乱序结果、用户打断、需求变更、取消、授权失败、提示注入、敏感数据和重复写入。
即使对话被中断,最终的业务状态也必须保持正确。
Gemini Live API 异步函数调用解决了一个实时 Agent 的根本问题:
慢的工具不应自动让对话变慢。
使用非阻塞调用,Agent 可以在外部系统执行的同时继续澄清、解释和独立工作。
但架构需要任务状态、超时、取消、调用 ID、并发控制、幂等性、授权、敏感数据过滤和可观测性。
核心规则很简单:Agent 可以在工具运行时继续说话,但绝不能在结果到达之前假装知道依赖工具的结果。