2026年,AI Agent工具使用能力正经历一次范式跃迁:从纯文本函数调用迈向视觉、语音、代码跨模态统一调用。GLM-4.6V率先实现原生多模态Function Calling,Google ADK的Gemini Live API将音频流与工具调用实时绑定,MFCL Vision和VTC-Bench两大基准首次系统化评估视觉驱动的工具链编排能力,Audio2Tool论文打通语音到函数调用的端到端桥梁,WildClawBench则在60个真实长时任务中暴露了跨模态Agent的深层脆弱性。本文从六个技术栈维度——感知层、Schema层、编排层、执行层、评测层、生产层——实测跨模态工具调用的真实能力边界,揭示从文本工具调用到多模态统一调用的工程鸿沟。
传统工具调用遵循一个隐含假设:输入是文本,输出是JSON。2024-2025年的函数调用生态——OpenAI Function Calling、Anthropic Tool Use、BFCL评测——全部建立在这个假设之上。2026年,这个假设被打破。
跨模态工具调用的核心变化是三层解耦:
graph TB
subgraph "传统工具调用 (2024-2025)"
T1[文本Prompt] --> LLM1[LLM]
LLM1 --> FC1[Function Call JSON]
FC1 --> EXE1[工具执行]
EXE1 --> RES1[JSON结果]
end
subgraph "跨模态工具调用 (2026)"
M1[截图/视频/音频/文本] --> VLM[多模态LLM]
VLM --> FC2[多模态Function Call]
FC2 --> EXE2[工具执行]
EXE2 --> RES2[多模态结果]
RES2 --> VLM
end
style T1 fill:#e1f5fe
style M1 fill:#fff3e0
style VLM fill:#fce4ec
这意味着工具调用从"文本→JSON→文本"的闭环,升级为"任意模态→结构化指令→任意模态"的开环。工程复杂度呈指数增长。
GLM-4.6V是第一个在模型层面原生支持多模态函数调用的开源模型。它的核心创新不是"先OCR再调用",而是视觉理解直接驱动工具选择和参数填充。
# GLM-4.6V 多模态工具调用示例
from openai import OpenAI
client = OpenAI(
api_key="your-key",
base_url="https://open.bigmodel.cn/api/paas/v4"
)
# 工具定义 - 包含视觉相关参数
tools = [{
"type": "function",
"function": {
"name": "analyze_ui_element",
"description": "分析屏幕截图中的UI元素并执行操作",
"parameters": {
"type": "object",
"properties": {
"element_type": {
"type": "string",
"enum": ["button", "input", "dropdown", "checkbox"]
},
"action": {
"type": "string",
"enum": ["click", "type", "select", "screenshot"]
},
"coordinates": {
"type": "object",
"properties": {
"x": {"type": "number"},
"y": {"type": "number"}
},
"description": "元素在截图中的坐标位置"
},
"text_content": {
"type": "string",
"description": "元素中显示的文本"
}
},
"required": ["element_type", "action"]
}
}
}]
# 视觉驱动的工具调用 - 直接传入截图
response = client.chat.completions.create(
model="glm-4.6v",
messages=[{
"role": "user",
"content": [
{
"type": "image_url",
"image_url": {"url": "data:image/png;base64,..."}
},
{
"type": "text",
"text": "找到登录按钮并点击它"
}
]
}],
tools=tools
)
# 模型直接从截图中提取坐标和元素类型
# 无需先OCR再解析再调用
GLM-4.6V的关键差异在于参数coordinates的填充——模型不是先做视觉理解输出文本描述,再将文本解析为坐标,而是端到端直接输出结构化的坐标值。这消除了"视觉理解→文本中间表示→结构化解析"的精度损耗链。
实测发现:在简单UI场景(按钮、输入框),坐标精度达到±5px;在复杂场景(重叠元素、动态内容),精度下降到±30px,仍需后处理校正。
Google ADK的Gemini Live API将工具调用从"请求-响应"模式升级为实时双向流模式。音频流持续输入,工具调用可以在语音中途被触发。
# ADK Gemini Live API - 实时音频工具调用
import asyncio
from google.genai import types
async def live_multimodal_tool_call():
config = {
"response_modalities": ["AUDIO"],
"tools": [{
"function_declarations": [{
"name": "control_smart_home",
"description": "控制智能家居设备",
"parameters": {
"type": "object",
"properties": {
"device": {"type": "string"},
"action": {
"type": "string",
"enum": ["on", "off", "dim", "set_temp"]
},
"value": {"type": "number"}
}
}
}]
}],
"system_instruction": "你是一个智能家居助手,可以通过语音控制设备"
}
async with client.aio.live.connect(
model="gemini-2.5-flash",
config=config
) as session:
# 实时音频流 - 边说边调工具
await session.send({
"role": "user",
"parts": [{"text": "帮我把客厅灯调暗一点"}]
})
async for response in session.receive():
if response.tool_call:
# 音频中途触发工具调用
result = execute_tool(response.tool_call)
await session.send({
"function_response": {
"name": response.tool_call.name,
"response": result
}
})
Gemini Live API的核心技术是半级联语音处理:不是传统的STT→LLM→TTS三段式管线,而是语音直接输入多模态模型,工具调用在语音理解过程中同步触发,响应也是合成音频流。端到端延迟从传统方案的2-4秒压缩到300-800ms。
Claude的Computer Use API走了一条不同的路线——它不定义结构化的视觉工具Schema,而是提供三个原子操作(computer、text_editor、bash),让模型自己决定如何组合。
# Claude Computer Use - 视觉驱动的原子操作组合
response = client.beta.messages.create(
model="claude-sonnet-4-6-20250514",
tools=[
{
"type": "computer_20250124",
"name": "computer",
"display_width_px": 1920,
"display_height_px": 1080
}
],
messages=[{
"role": "user",
"content": "帮我在Excel中创建一个销售数据透视表"
}]
)
# 模型执行流程:
# 1. screenshot() → 视觉感知当前桌面
# 2. mouse_click(x=500, y=300) → 点击Excel图标
# 3. screenshot() → 验证Excel已打开
# 4. key_press("Ctrl+T") → 创建透视表
# 5. screenshot() → 验证结果
# 每一步都依赖视觉反馈来决定下一步
这种"视觉→操作→验证"闭环是Claude Computer Use的核心优势,也是其最大的性能瓶颈——每一步都需要screenshot→VLM推理→操作的循环,平均每步耗时2-5秒。一个包含15步的复杂任务需要1-2分钟。
| 能力维度 | GLM-4.6V | Gemini Live API | Claude Computer Use | GPT-5 Vision | InternVL3 | NVIDIA Nemotron 3 Omni |
|---|---|---|---|---|---|---|
| 视觉→工具调用 | 原生支持 | 通过图像输入 | 截图循环 | 支持 | 支持 | 支持 |
| 音频→工具调用 | 不支持 | 原生流式 | 不支持 | 支持 | 不支持 | 原生支持 |
| 工具Schema多模态 | 部分支持 | 完整支持 | 原子操作 | 完整支持 | 部分支持 | 完整支持 |
| 实时流式调用 | 不支持 | 支持 | 不支持 | 有限支持 | 不支持 | 支持 |
| 坐标精度 | ±5-30px | N/A | ±3-15px | ±8-20px | ±10-25px | ±12-30px |
| 开源 | 是 | 否 | 否 | 否 | 是 | 是 |
| 端到端延迟 | 1-3s | 0.3-0.8s | 2-5s/step | 1-2s | 2-4s | 1-3s |
传统JSON Schema描述工具参数时,天然假设所有参数都是文本可描述的。但当工具参数涉及视觉空间信息时,JSON Schema开始力不从心:
// 传统Schema - 无法描述视觉语义
{
"name": "click_element",
"parameters": {
"x": {"type": "number"},
"y": {"type": "number"}
}
// 问题:模型怎么知道x=500,y=300对应哪个元素?
}
// 多模态Schema - 需要扩展描述能力
{
"name": "click_element",
"parameters": {
"target": {
"type": "object",
"description": "目标元素的视觉描述和位置",
"properties": {
"visual_description": {
"type": "string",
"description": "目标元素在屏幕上的视觉外观描述"
},
"bounding_box": {
"type": "object",
"properties": {
"x_min": {"type": "number"},
"y_min": {"type": "number"},
"x_max": {"type": "number"},
"y_max": {"type": "number"}
},
"description": "从输入图像中提取的目标区域坐标"
}
}
}
}
}
| Provider | Schema扩展方式 | 视觉参数类型 | 音频参数类型 | 向后兼容 |
|---|---|---|---|---|
| OpenAI | 标准JSON Schema | 图像URL + 坐标 | 不支持 | 完全兼容 |
| Anthropic | 扩展JSON Schema | Bounding box + 屏幕坐标 | 不支持 | 部分兼容 |
| 原生多模态参数 | 原生图像 + 视频 + 音频 | 原生音频 | 框架绑定 | |
| GLM-4.6V | 扩展JSON Schema | 图像URL + 坐标 + 区域描述 | 不支持 | 部分兼容 |
分裂的核心问题:没有一个标准化的方式在工具Schema中描述"这个参数应该从视觉输入中提取"。每个Provider用自己的方式扩展,导致工具定义不可移植。
MCP (Model Context Protocol) 在2026年开始探索多模态工具描述扩展。当前MCP的工具定义支持inputSchema(JSON Schema),但正在讨论增加:
inputModalities: 声明工具接受哪些模态的输入outputModalities: 声明工具返回哪些模态的输出visualGrounding: 标记哪些参数需要从视觉输入中提取坐标这一扩展仍在草案阶段,但它代表了跨模态工具调用标准化的重要方向。
VTC-Bench (VisualToolChain-Bench) 是2026年第一个系统评估视觉工具链编排能力的基准。它提供32个OpenCV工具,要求模型从图像输入出发,规划并执行多步工具链来完成视觉任务。
VTC-Bench的核心发现:
边缘检测→轮廓提取→面积计算,但不检查边缘检测的输出是否合理就直接进入下一步。cvtColor vs cvtColor2)。graph LR
subgraph "VTC-Bench 工具链示例"
IMG[输入图像] --> T1[灰度转换]
T1 --> T2[高斯模糊]
T2 --> T3[Canny边缘检测]
T3 --> T4[轮廓查找]
T4 --> T5[面积过滤]
T5 --> T6[结果绘制]
T6 --> OUT[输出图像]
end
subgraph "模型常见错误"
E1[跳过模糊直接检测] --> E2[噪声过多]
E3[参数选择错误] --> E4[阈值不匹配]
E5[工具顺序颠倒] --> E6[输入类型不匹配]
end
style IMG fill:#e8f5e9
style OUT fill:#e8f5e9
style E2 fill:#ffebee
style E4 fill:#ffebee
style E6 fill:#ffebee
从VTC-Bench、WildClawBench和实际生产案例中,我们提炼出五种跨模态工具链编排模式:
模式一:串行视觉流水线(Serial Vision Pipeline) 视觉工具按固定顺序执行,每步输出是下一步的输入。这是最基础的模式,VTC-Bench中的大部分任务都属于此类。
图像 → [预处理] → [特征提取] → [后处理] → 输出
模式二:视觉-文本交叉验证(Vision-Text Cross-Validation) 视觉工具和文本工具交替执行,用文本推理验证视觉结果,或用视觉结果校正文本输出。Claude Computer Use的screenshot→操作→screenshot循环就是这种模式。
模式三:音频-工具实时绑定(Audio-Tool Real-time Binding) Gemini Live API的模式——音频流持续输入,工具调用在语音理解的任意时刻被触发,不需要等用户说完整个句子。
模式四:散射-汇聚多源查询(Scatter-Gather Multi-source) 一个视觉输入触发多个并行工具调用(如同时查询图像中的多个物体),然后汇聚结果。Arcade的Scatter-Gather Tool模式是典型实现。
模式五:递归视觉修正(Recursive Visual Correction) 工具执行后产生新的视觉输出(如修改后的截图),模型基于新视觉输入决定是否需要修正,形成递归循环。
| 模式 | 典型场景 | 模态跨越 | 延迟特征 | 错误传播 |
|---|---|---|---|---|
| 串行视觉流水线 | 图像处理管线 | 视觉→视觉 | 线性累加 | 单向传播 |
| 视觉-文本交叉验证 | GUI自动化 | 视觉↔文本 | 交替累加 | 双向校正 |
| 音频-工具实时绑定 | 语音助手 | 音频→文本→工具 | 流式低延迟 | 实时截断 |
| 散射-汇聚多源 | 多目标检测 | 视觉→并行工具 | 取最长路径 | 部分容错 |
| 递归视觉修正 | 精密UI操作 | 视觉→工具→视觉 | 不确定 | 逐步收敛 |
跨模态工具调用面临严重的上下文膨胀。一次screenshot + VLM推理就可能消耗数千Token,多步循环后上下文迅速溢出。
实测数据(Claude Computer Use场景):
| 步骤数 | 截图Token消耗 | 文本推理Token | 工具调用Token | 总Token |
|---|---|---|---|---|
| 1步 | ~1,200 | ~300 | ~100 | ~1,600 |
| 5步 | ~6,000 | ~1,800 | ~600 | ~8,400 |
| 10步 | ~12,000 | ~4,000 | ~1,500 | ~17,500 |
| 20步 | ~24,000 | ~9,000 | ~3,500 | ~36,500 |
10步操作的Token消耗是单步的10倍以上,因为每步的screenshot都要重新编码。这直接导致: - 成本线性增长(GPT-5 Vision每步约$0.03,20步=$0.6/任务) - 上下文窗口限制(128K窗口最多支撑约30步循环) - 信息衰减(早期步骤的视觉信息在长上下文中被"遗忘")
Gemini Live API的实时音频工具调用面临独特的执行挑战:
挑战一:工具调用时机不确定性 音频流中,用户可能在句子中间停顿后继续说("帮我打开……不对,关掉客厅的灯")。系统需要在语音断句和工具调用之间做平衡——太早调用会执行错误操作,太晚会增加延迟。
挑战二:音频和工具状态同步 音频流是持续的,但工具调用是离散的。当工具调用触发后,音频流如何处理?Gemini Live API的做法是"barge-in"——允许工具调用的结果以合成音频形式插入到音频流中,同时继续监听用户可能的打断。
挑战三:多轮音频工具交互 用户可能连续发出多个工具指令("把灯关了,然后空调调到26度,再放首歌")。系统需要将连续语音流分割为多个独立的工具调用,并维护每个调用的独立状态。
2026年的Audio2Tool论文(arXiv:2604.22821)首次系统研究了从语音直接到函数调用的端到端方法,不经过STT→文本→工具调用的中间步骤。
核心发现: 1. 端到端语音工具调用在简单意图上比STT→文本管线快40%(减少了中间表示转换) 2. 在复杂多意图场景(一个语音包含多个工具调用)上,端到端方法的准确率比级联方法低15%——因为语音的韵律信息(停顿、重音)在端到端训练中被部分丢失 3. 噪声鲁棒性:在SNR<10dB的噪声环境下,端到端方法的准确率下降35%,而STT→文本方法只下降18%
2026年的多模态工具调用评测呈现三足鼎立格局:
MFCL Vision(NeurIPS 2025) - 聚焦:单步视觉驱动的函数调用 - 方法:扩展BFCL框架,增加视觉输入 - 覆盖:简单/多重/并行/多轮函数调用 + 视觉输入 - 局限:不评估工具链编排能力
VTC-Bench(arXiv:2603.15030) - 聚焦:多步视觉工具链编排 - 方法:32个OpenCV工具的组合规划 - 覆盖:2-8步工具链、32种工具、真实视觉任务 - 局限:限于计算机视觉领域,不涉及音频/文本交叉
WildClawBench(arXiv:2605.10912) - 聚焦:真实环境长时Agent工具使用 - 方法:60个真实任务、原生运行时、双语多模态 - 覆盖:文件管理、数据操作、网络交互、多步推理 - 局限:评分主观性强,复现成本高
graph TB
subgraph "多模态工具调用评测体系"
A[MFCL Vision<br/>单步视觉函数调用]
B[VTC-Bench<br/>多步视觉工具链]
C[WildClawBench<br/>真实长时任务]
D[BFCL V4<br/>纯文本函数调用]
E[Audio2Tool<br/>语音工具调用]
end
A -->|评估能力| A1[视觉感知→工具选择]
B -->|评估能力| B1[视觉任务→工具链规划]
C -->|评估能力| C1[真实场景→端到端执行]
D -->|评估能力| D1[文本意图→工具调用]
E -->|评估能力| E1[语音意图→工具调用]
A1 -.->|互补| B1
B1 -.->|互补| C1
style A fill:#e3f2fd
style B fill:#f3e5f5
style C fill:#e8f5e9
style D fill:#fff3e0
style E fill:#fce4ec
MFCL Vision 主要发现: - GPT-5 Vision在简单视觉函数调用上达到89.3%准确率 - Claude Sonnet 4.6紧随其后(87.1%),在多重函数调用场景表现更好 - 开源模型中GLM-4.6V表现最佳(78.6%),但与闭源模型仍有10+点差距 - 失败模式分类:视觉推理失败(34%)、假设工具能力(28%)、参数格式错误(22%)、幻觉调用(16%)
VTC-Bench 主要发现: - 所有模型在5步以上工具链规划上准确率低于50% - GPT-5 Vision在3步任务:92%,5步:61%,7步:41% - 工具选择错误率(选了语义相似但功能不同的工具)高达23% - 人类基线在8步任务上达到95%
WildClawBench 主要发现: - 19个前沿Agent中,最高完成率仅为42.7%(Claude Sonnet 4.6 + Computer Use) - 长时任务(>10步)的完成率骤降至15-20% - 跨模态任务(涉及视觉+文本+代码)的完成率比纯文本任务低35%
| 部署模式 | 单次调用成本 | 10步任务成本 | 适合场景 |
|---|---|---|---|
| GLM-4.6V(自部署) | ~$0.002 | ~$0.02 | 批量视觉处理、离线任务 |
| Claude Computer Use | ~$0.03 | ~$0.30 | 精密GUI操作、低容错场景 |
| GPT-5 Vision + Tools | ~$0.02 | ~$0.20 | 通用多模态Agent |
| Gemini Live API | ~$0.015/分钟 | ~$0.05/分钟 | 实时语音助手 |
| 纯文本函数调用 | ~$0.001 | ~$0.01 | 传统API Agent |
跨模态工具调用的成本是纯文本调用的10-30倍。这个成本差主要来自视觉Token编码和多步循环的累加效应。
跨模态工具调用在生产环境中需要三层缓冲:
graph TB
subgraph "生产级跨模态工具调用架构"
IN[多模态输入<br/>文本/图像/音频] --> GW[API网关<br/>速率限制·认证]
GW --> MM[模态路由器<br/>判断输入模态]
MM -->|纯文本| TC[文本工具调用<br/>传统Function Call]
MM -->|含视觉| VC[视觉工具调用<br/>VLM + 坐标校正]
MM -->|含音频| AC[音频工具调用<br/>流式处理 + 断句]
VC --> CACHE[结果缓存<br/>视觉特征去重]
AC --> CACHE
TC --> CACHE
CACHE --> ORCH[工具编排器<br/>DAG调度]
ORCH --> EXEC[工具执行沙盒]
EXEC --> VALID[结果验证<br/>Schema + 视觉校验]
VALID -->|通过| OUT[返回结果]
VALID -->|失败| RETRY[重试/降级]
RETRY --> ORCH
end
style IN fill:#e8f5e9
style OUT fill:#e8f5e9
style RETRY fill:#ffebee
关键工程决策:
模态路由:不是所有请求都需要多模态处理。一个简单的模态路由器可以节省60%以上的成本——将纯文本请求直接路由到文本工具调用管线,避免VLM的昂贵推理。
视觉特征缓存:同一个截图在多步操作中反复出现(如Claude Computer Use的screenshot循环),缓存视觉编码结果可以将重复步骤的Token消耗降低70%。
降级策略:当VLM调用超时或成本超限时,降级到OCR→文本工具调用管线。精度下降但可用性保持。
结果验证:跨模态工具调用的结果需要双重验证——Schema验证(输出是否符合预期格式)和视觉验证(操作后的截图是否符合预期状态)。
| 场景 | 技术栈 | 月成本估算 | 变现模式 | 市场成熟度 |
|---|---|---|---|---|
| RPA自动化 | Claude CU + 自定义工具 | $500-2000 | 按任务计费 | 高 |
| 语音智能客服 | Gemini Live API | $300-1000 | 订阅制 | 高 |
| 视觉质检 | GLM-4.6V + OpenCV | $100-500 | 按检次数 | 中 |
| 多模态数据录入 | GPT-5V + OCR | $200-800 | 按页计费 | 中 |
| 实时监控告警 | Nemotron + 视频流 | $500-1500 | 订阅制 | 低 |
| 栈层 | 核心挑战 | 当前最佳方案 | 成熟度 | 预期演进 |
|---|---|---|---|---|
| 感知栈 | 视觉/音频→工具决策的精度 | Gemini Live API(音频)、Claude CU(视觉) | 3/5 | 多模态统一推理 |
| Schema栈 | 多模态参数描述标准化 | JSON Schema扩展 | 2/5 | MCP多模态扩展草案 |
| 编排栈 | 多步视觉工具链规划 | GPT-5 Vision(3步内) | 2.5/5 | 强化学习规划 |
| 执行栈 | 上下文膨胀和实时性 | 视觉特征缓存 + 流式处理 | 3/5 | 原生多模态Token压缩 |
| 评测栈 | 基准分裂和场景覆盖 | VTC-Bench + WildClawBench互补 | 2.5/5 | 统一多模态评测框架 |
| 生产栈 | 成本控制和可靠性 | 模态路由 + 降级策略 | 3.5/5 | 专用跨模态推理芯片 |
场景一:GUI自动化测试(RPA) - 推荐:Claude Computer Use + 自定义工具 - 理由:视觉→操作→验证闭环最完整,精度最高 - 注意:成本高,需视觉特征缓存优化 - 备选:GLM-4.6V + Playwright(成本优化方案)
场景二:语音智能助手 - 推荐:Google ADK Gemini Live API - 理由:唯一实现原生音频流式工具调用的方案 - 注意:Vendor锁定风险,需评估MCP兼容性 - 备选:Audio2Tool端到端方案(研究中)
场景三:视觉质检/图像处理 - 推荐:GLM-4.6V + OpenCV工具链 - 理由:开源可部署,视觉工具调用原生支持 - 注意:复杂工具链规划能力弱,需人工定义管线 - 备选:GPT-5 Vision + VTC-Bench工具集(高精度场景)
场景四:通用多模态Agent - 推荐:GPT-5 Vision + 混合工具集 - 理由:文本/视觉工具调用均衡,生态最成熟 - 注意:成本敏感,需模态路由优化 - 备选:Claude Sonnet 4.6(高可靠性场景)
场景五:边缘端多模态Agent - 推荐:NVIDIA Nemotron 3 Nano Omni - 理由:唯一支持边缘部署的统一多模态工具调用模型 - 注意:精度低于云端方案,功能受限 - 备选:GLM-4.6V量化版(社区方案)
跨模态工具调用仍处于早期阶段,以下方向值得关注:
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
