<!-- title: 跨模态工具调用：六栈全拆解 -->

# 跨模态工具调用六栈全拆解：视觉·语音·代码统一调用实测

## 概述

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年，这个假设被打破。

跨模态工具调用的核心变化是三层解耦：

1. **感知输入不再限于文本**：截图、UI界面、实时视频帧、音频流都可以触发工具调用决策
2. **工具Schema可以包含视觉/音频约束**：例如"此工具需要一个图片区域的bounding box作为输入"
3. **执行结果可以是多模态的**：工具返回的不只是JSON，可能包含渲染的图表、合成的音频、修改后的图像

```mermaid
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→文本"的闭环，升级为"任意模态→结构化指令→任意模态"的开环。工程复杂度呈指数增长。

---

## 二、感知栈：六大多模态工具调用入口实测

### 2.1 GLM-4.6V：原生视觉工具调用

GLM-4.6V是第一个在模型层面原生支持多模态函数调用的开源模型。它的核心创新不是"先OCR再调用"，而是**视觉理解直接驱动工具选择和参数填充**。

```python
# 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，仍需后处理校正。

### 2.2 Google ADK Gemini Live API：实时音频流工具调用

Google ADK的Gemini Live API将工具调用从"请求-响应"模式升级为**实时双向流**模式。音频流持续输入，工具调用可以在语音中途被触发。

```python
# 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。

### 2.3 Claude Computer Use：视觉→操作→验证闭环

Claude的Computer Use API走了一条不同的路线——它不定义结构化的视觉工具Schema，而是提供三个原子操作（`computer`、`text_editor`、`bash`），让模型自己决定如何组合。

```python
# 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分钟。

### 2.4 六大多模态工具调用入口对比

| 能力维度 | 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 |

---

## 三、Schema栈：多模态工具描述规范的分裂与统一

### 3.1 文本Schema的局限

传统JSON Schema描述工具参数时，天然假设所有参数都是文本可描述的。但当工具参数涉及视觉空间信息时，JSON Schema开始力不从心：

```json
// 传统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": "从输入图像中提取的目标区域坐标"
        }
      }
    }
  }
}
```

### 3.2 四大Provider的多模态Schema方案

| Provider | Schema扩展方式 | 视觉参数类型 | 音频参数类型 | 向后兼容 |
|---------|-------------|-----------|-----------|--------|
| OpenAI | 标准JSON Schema | 图像URL + 坐标 | 不支持 | 完全兼容 |
| Anthropic | 扩展JSON Schema | Bounding box + 屏幕坐标 | 不支持 | 部分兼容 |
| Google | 原生多模态参数 | 原生图像 + 视频 + 音频 | 原生音频 | 框架绑定 |
| GLM-4.6V | 扩展JSON Schema | 图像URL + 坐标 + 区域描述 | 不支持 | 部分兼容 |

分裂的核心问题：**没有一个标准化的方式在工具Schema中描述"这个参数应该从视觉输入中提取"**。每个Provider用自己的方式扩展，导致工具定义不可移植。

### 3.3 MCP的多模态扩展尝试

MCP (Model Context Protocol) 在2026年开始探索多模态工具描述扩展。当前MCP的工具定义支持`inputSchema`（JSON Schema），但正在讨论增加：

- `inputModalities`: 声明工具接受哪些模态的输入
- `outputModalities`: 声明工具返回哪些模态的输出
- `visualGrounding`: 标记哪些参数需要从视觉输入中提取坐标

这一扩展仍在草案阶段，但它代表了跨模态工具调用标准化的重要方向。

---

## 四、编排栈：跨模态工具链的组合模式

### 4.1 VTC-Bench揭示的视觉工具链编排能力

VTC-Bench (VisualToolChain-Bench) 是2026年第一个系统评估视觉工具链编排能力的基准。它提供32个OpenCV工具，要求模型从图像输入出发，规划并执行多步工具链来完成视觉任务。

VTC-Bench的核心发现：

1. **规划能力是瓶颈**：当任务需要5步以上工具链时，所有模型的规划准确率急剧下降。GPT-5 Vision在3步任务上达到92%准确率，但在7步任务上降至41%。
2. **中间步骤的视觉验证缺失**：模型规划工具链时不考虑中间结果验证。例如规划`边缘检测→轮廓提取→面积计算`，但不检查边缘检测的输出是否合理就直接进入下一步。
3. **工具组合爆炸**：32个工具的理论组合空间巨大，模型经常选择语义相似但功能不同的工具（如`cvtColor` vs `cvtColor2`）。

```mermaid
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
```

### 4.2 五种跨模态编排模式

从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操作 | 视觉→工具→视觉 | 不确定 | 逐步收敛 |

---

## 五、执行栈：跨模态工具调用的运行时挑战

### 5.1 上下文膨胀问题

跨模态工具调用面临严重的上下文膨胀。一次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步循环）
- 信息衰减（早期步骤的视觉信息在长上下文中被"遗忘"）

### 5.2 实时音频的流式工具调用

Gemini Live API的实时音频工具调用面临独特的执行挑战：

**挑战一：工具调用时机不确定性**
音频流中，用户可能在句子中间停顿后继续说（"帮我打开……不对，关掉客厅的灯"）。系统需要在语音断句和工具调用之间做平衡——太早调用会执行错误操作，太晚会增加延迟。

**挑战二：音频和工具状态同步**
音频流是持续的，但工具调用是离散的。当工具调用触发后，音频流如何处理？Gemini Live API的做法是"barge-in"——允许工具调用的结果以合成音频形式插入到音频流中，同时继续监听用户可能的打断。

**挑战三：多轮音频工具交互**
用户可能连续发出多个工具指令（"把灯关了，然后空调调到26度，再放首歌"）。系统需要将连续语音流分割为多个独立的工具调用，并维护每个调用的独立状态。

### 5.3 Audio2Tool：语音到函数调用的端到端桥接

2026年的Audio2Tool论文（arXiv:2604.22821）首次系统研究了从语音直接到函数调用的端到端方法，不经过STT→文本→工具调用的中间步骤。

核心发现：
1. **端到端语音工具调用在简单意图上比STT→文本管线快40%**（减少了中间表示转换）
2. **在复杂多意图场景（一个语音包含多个工具调用）上，端到端方法的准确率比级联方法低15%**——因为语音的韵律信息（停顿、重音）在端到端训练中被部分丢失
3. **噪声鲁棒性**：在SNR<10dB的噪声环境下，端到端方法的准确率下降35%，而STT→文本方法只下降18%

---

## 六、评测栈：多模态工具调用基准全景

### 6.1 三大基准定位

2026年的多模态工具调用评测呈现三足鼎立格局：

**MFCL Vision**（NeurIPS 2025）
- 聚焦：单步视觉驱动的函数调用
- 方法：扩展BFCL框架，增加视觉输入
- 覆盖：简单/多重/并行/多轮函数调用 + 视觉输入
- 局限：不评估工具链编排能力

**VTC-Bench**（arXiv:2603.15030）
- 聚焦：多步视觉工具链编排
- 方法：32个OpenCV工具的组合规划
- 覆盖：2-8步工具链、32种工具、真实视觉任务
- 局限：限于计算机视觉领域，不涉及音频/文本交叉

**WildClawBench**（arXiv:2605.10912）
- 聚焦：真实环境长时Agent工具使用
- 方法：60个真实任务、原生运行时、双语多模态
- 覆盖：文件管理、数据操作、网络交互、多步推理
- 局限：评分主观性强，复现成本高

```mermaid
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
```

### 6.2 关键评测数据

**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%

---

## 七、生产栈：跨模态工具调用的工程实践

### 7.1 成本结构对比

| 部署模式 | 单次调用成本 | 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编码和多步循环的累加效应。

### 7.2 生产级架构模式

跨模态工具调用在生产环境中需要三层缓冲：

```mermaid
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
```

**关键工程决策**：

1. **模态路由**：不是所有请求都需要多模态处理。一个简单的模态路由器可以节省60%以上的成本——将纯文本请求直接路由到文本工具调用管线，避免VLM的昂贵推理。

2. **视觉特征缓存**：同一个截图在多步操作中反复出现（如Claude Computer Use的screenshot循环），缓存视觉编码结果可以将重复步骤的Token消耗降低70%。

3. **降级策略**：当VLM调用超时或成本超限时，降级到OCR→文本工具调用管线。精度下降但可用性保持。

4. **结果验证**：跨模态工具调用的结果需要双重验证——Schema验证（输出是否符合预期格式）和视觉验证（操作后的截图是否符合预期状态）。

### 7.3 变现场景评估

| 场景 | 技术栈 | 月成本估算 | 变现模式 | 市场成熟度 |
|-----|-------|---------|---------|-----------|
| RPA自动化 | Claude CU + 自定义工具 | $500-2000 | 按任务计费 | 高 |
| 语音智能客服 | Gemini Live API | $300-1000 | 订阅制 | 高 |
| 视觉质检 | GLM-4.6V + OpenCV | $100-500 | 按检次数 | 中 |
| 多模态数据录入 | GPT-5V + OCR | $200-800 | 按页计费 | 中 |
| 实时监控告警 | Nemotron + 视频流 | $500-1500 | 订阅制 | 低 |

---

## 八、六栈能力矩阵与选型推荐

### 8.1 跨模态工具调用六栈能力矩阵

| 栈层 | 核心挑战 | 当前最佳方案 | 成熟度 | 预期演进 |
|-----|---------|-----------|-------|---------|
| 感知栈 | 视觉/音频→工具决策的精度 | 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 | 专用跨模态推理芯片 |

### 8.2 场景化选型推荐

**场景一：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量化版（社区方案）

---

## 延伸阅读

跨模态工具调用仍处于早期阶段，以下方向值得关注：

1. **MFCL Vision基准的后续扩展**——从单步评估到多步工具链评估，补齐VTC-Bench的视觉覆盖与MFCL的深度覆盖之间的空白
2. **MCP多模态扩展草案的标准化进程**——如果达成共识，将解决当前Schema栈的分裂问题
3. **端到端语音工具调用（Audio2Tool路线）的工业化**——当前仍是研究阶段，但潜力巨大
4. **视觉Token压缩技术**——解决上下文膨胀的关键，直接影响长时视觉Agent的经济可行性
5. **WildClawBench推动的真实环境评测范式**——从实验室基准到原生运行时评测的方法论转变

## 参考来源

1. [GLM-4.6V: Open Source Multimodal Models with Native Tool Use](https://z.ai/blog/glm-4.6v) — GLM-4.6V原生多模态工具调用能力官方介绍
2. [VTC-Bench: Evaluating Agentic Multimodal Models via Compositional Visual Tool Chaining](https://arxiv.org/abs/2603.15030) — 视觉工具链编排基准论文
3. [MFCL Vision: Benchmarking Tool Use in Multimodal Large Language Models](https://openreview.net/forum?id=vV4tC5rhw6) — NeurIPS 2025多模态工具使用基准
4. [WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation](https://arxiv.org/abs/2605.10912) — 真实环境长时Agent评测基准
5. [Audio2Tool: Bridging Spoken Language Understanding and Function Calling](https://arxiv.org/abs/2604.22821) — 语音到函数调用端到端方法
6. [Google ADK Gemini Live API Toolkit](https://adk.dev/streaming/) — Gemini实时多模态工具调用官方文档
7. [Tool Use and Function Calling in AI Agents - Zylos Research](https://zylos.ai/research/2026-04-07-tool-use-function-calling-standards-benchmarks) — 2026年工具调用生态综合分析

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)