首页 › ai-agents › 跨模态工具调用:六栈全拆解

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

概述

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,可能包含渲染的图表、合成的音频、修改后的图像
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再调用",而是视觉理解直接驱动工具选择和参数填充。

# 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将工具调用从"请求-响应"模式升级为实时双向流模式。音频流持续输入,工具调用可以在语音中途被触发。

# 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),让模型自己决定如何组合。

# 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开始力不从心:

// 传统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),但正在讨论增加:

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


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

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)。
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个真实任务、原生运行时、双语多模态 - 覆盖:文件管理、数据操作、网络交互、多步推理 - 局限:评分主观性强,复现成本高

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 生产级架构模式

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

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 — GLM-4.6V原生多模态工具调用能力官方介绍
  2. VTC-Bench: Evaluating Agentic Multimodal Models via Compositional Visual Tool Chaining — 视觉工具链编排基准论文
  3. MFCL Vision: Benchmarking Tool Use in Multimodal Large Language Models — NeurIPS 2025多模态工具使用基准
  4. WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation — 真实环境长时Agent评测基准
  5. Audio2Tool: Bridging Spoken Language Understanding and Function Calling — 语音到函数调用端到端方法
  6. Google ADK Gemini Live API Toolkit — Gemini实时多模态工具调用官方文档
  7. Tool Use and Function Calling in AI Agents - Zylos Research — 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学通信知识星球海报-扫码加入