想象你升任一家五星级酒店的总管家。主管郑重递来三件法宝:一部直拨外部服务商的电话、一本随时更新的资料手册、一把不知疲倦的计算器。客人可能举起手机照片说“我要这样的婚宴布置”,也可能用含混的语音断断续续描述需求。你一边用眼睛看照片、耳朵辨语音,一边在脑中盘算:这单要找花店(API 调用)、查手册确认场地档期(搜索工具)、最后用计算器算清三百人的酒水预算(代码工具)。看完、听完、查完、算完,你还要根据对方的答复调整下一步——这整套“感知—决策—行动—再看结果”的服务闭环,就是多模态工具调用,而你就是那个多模态 Agent。 本文用“管家的一天”串起核心知识:先看工具调用与多模态 Agent 的基本功,再逐一拆解电话(API)、手册(搜索)、计算器(代码)三件工具,最后补上质检流程(评估体系)和带队方法(行业实践)。读完你会明白:让大模型“会动手”,关键不在于会接几个 API,而在于一套可靠的决策与治理框架。

岗位关联

掌握多模态工具调用,等于掌握了大模型从“能说”到“会做”的关键一跃——这是多模态应用落地中最稀缺的工程能力,直接决定你能否独立交付智能客服、数据分析等真实项目。

目录
  1. 可视化演示
  2. 工具调用基础
  3. 多模态Agent
  4. API调用工具
  5. 搜索工具
  6. 代码工具
  7. 评估体系
  8. 行业实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示多模态工具调用API搜索代码的核心机制,通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

多模态工具调用API搜索代码:多模态工 多模态工具调用概述 API工具调用机制设计 核心机制可视化 多模态工具调用API搜索代码整体架构与关键组件

工具调用基础

想象你刚入职这家酒店,成为一名实习管家。你的随身装备很朴素:一双眼睛、一对耳朵、一张嘴,外加那部电话。客人可能指着一张手机照片说“我想住这样的房间”,也可能用语音含混地抱怨空调太吵。传统接线员只会照本宣科,但你不同——你“看见”照片、“听见”语音,然后在心里快速判断:这单要翻通讯录,还是直接回答?这个“看见→判断→行动→再看结果”的闭环,就是多模态工具调用的全部秘密。

把管家换成多模态大模型,事情就变成这样:模型接收图像、音频、文本三种模态的信号,通过一个“决策大脑”从预先注册好的工具集中选出最合适的工具并生成参数,再把工具返回的结果作为新的观察,进入下一轮决策。这套循环在学术界被称为 ReAct——思考(Thought)、行动(Action)、观察(Observation)交替进行,正如管家每做一件事都要“心里先过一遍”。

为了形式化描述这个决策过程,研究者通常用一个动作选择公式来刻画:

你看,这就是管家接客时的完整心路:眼睛看照片、耳朵听需求、脑子翻通讯录、手拨出电话,挂断后把对方的答复记在心里,再决定下一步。多模态工具调用的本质,就是给大模型装上“管家的手脚”——让它能真正对外部世界施加影响。

at=πθ(st,T)\displaystyle a_t = \pi_{\theta}(s_t, \mathcal{T})
一句话理解:管家每一步的动作 = 他的职业大脑 π 结合当下局面 s 与工具箱 T 共同做出的选择。
  1. 决策策略 π_θ管家的“职业直觉”,由大模型参数 θ 承载,输入当前局面、输出一个动作
    πθ:s→a\pi_{\theta}: s \rightarrow a
  2. 综合状态 s_t第 t 轮管家掌握的全部信息,包括图像、语音、文本与历史记录
    st=(ximg, xaudio, xtext, ht−1)s_t = (x_{\text{img}},\, x_{\text{audio}},\, x_{\text{text}},\, h_{t-1})
  3. 工具集合 T仓库里全部可用工具的清单,每项都附带“使用说明”
    T={f1,f2,…,fk}\mathcal{T} = \{f_1, f_2, \dots, f_k\}
  4. 动作 a_t本轮选定的工具编号及对应参数,驱动一次真实调用
    at=(fj, paramsj)a_t = (f_j,\, \text{params}_j)

多模态Agent

实习管家转正了,开始独立负责贵宾的“全生命周期服务”。贵宾说:“下个月我要在西湖边办一场三百人的婚礼。”优秀的管家不会抓起电话就拨——他先画一张作战地图:订场地、约摄影师、排菜单、发请柬、备雨伞……把一个大目标拆成一串小任务,再逐个调配工具。这套“拆解+编排+记忆”的脑子,就是 Agent 与普通对话机器人的分水岭。

多模态 Agent 的架构通常包含四个模块:感知编码器(把图像、音频、文本映射到同一语义空间)、规划器(把用户意图分解为子目标)、执行器(实际调用工具)、记忆模块(记录历史)。相比“你问一句我答一句”的对话 API,Agent 更强调多轮自主闭环:分解目标、按序执行、根据观察动态调整计划。

规划器最常用的策略是 Plan-and-Execute(先规划再执行),其形式化表达为:

管家之所以能独当一面,不是因为他认识所有供应商,而是因为他脑子里有一套“拆解—编排—复盘”的方法论。多模态 Agent 补上的正是这块“脑力”,让工具调用从我问你答升级为:你说个大方向,我端上一整套方案。

Plan(G)=[g1,g2,…,gn],gi∈P\displaystyle \mathrm{Plan}(G) = [g_1, g_2, \dots, g_n], \quad g_i \in \mathcal{P}
一句话理解:管家拿到总目标后,先列出一张“任务清单”,清单上的每个任务都是整个方案的一小块拼图。
  1. 总目标 G用户提出的复杂需求,例如举办一场三百人的婚礼宴会
    G=举办婚礼宴会G = \text{举办婚礼宴会}
  2. 规划映射 Plan把大目标拆解为有序子目标列表的“作战会议”
    Plan(G)=[g1,g2,…,gn]\mathrm{Plan}(G) = [g_1, g_2, \dots, g_n]
  3. 子目标 g_i一个可独立执行的小任务,如订场地、发请柬、排菜单
    gi∈Pg_i \in \mathcal{P}
  4. 任务空间 P所有可行子任务的集合,规划器在此空间中做搜索与排序
    P={订场地,发请柬,排菜单,… }\mathcal{P} = \{ \text{订场地}, \text{发请柬}, \text{排菜单}, \dots \}

API调用工具

管家的西装口袋里永远揣着一本电话簿:花店、蛋糕店、摄影棚……每家都印着一行“接口说明”——打给谁、要报什么信息(婚礼日期、人数、预算)、对方会给什么回执(订单号、报价单)。电话打得准不准,直接决定这单生意成不成。

API 调用在工程上对应 Function Calling(函数调用)。开发者在系统提示里注册一组函数描述:函数名、参数 JSON Schema(参数的类型、必填项、默认值)和功能说明。模型收到用户请求后,不是直接输出自然语言答案,而是输出一段结构化的函数调用指令,再由运行时去执行真正的 HTTP 请求。

选择哪个函数、填入什么参数,本质是在工具集合上做条件生成:

电话打得准不准,决定管家专业不专业。API 调用亦然——“选对工具”和“填对参数”是两项独立考核,工程师宁可让模型多问一句,也不许它带着半截地址去订蛋糕。

f∗=arg⁡max⁡fj∈FPθ(fj, paramsj∣q, h)\displaystyle f^{*} = \arg\max_{f_j \in \mathcal{F}} P_{\theta}(f_j,\, \text{params}_j \mid q,\, h)
一句话理解:管家从电话簿里挑最合适的一家,同时把客人信息填进对方要的表格栏位里。
  1. 函数清单 F电话簿中所有服务商接口描述的集合
    F={f1,f2,…,fk}\mathcal{F} = \{f_1, f_2, \dots, f_k\}
  2. 请求 q 与历史 h当前的多模态请求与先前的对话、工具调用记录
    q=编码后的用户请求,h=历史上下文q = \text{编码后的用户请求}, \quad h = \text{历史上下文}
  3. 候选函数 f_j清单中某一个待选的函数,例如“查询天气”
    fj=(namej,schemaj,descj)f_j = (name_j, \text{schema}_j, desc_j)
  4. 条件概率最大化在所有候选中挑出概率最高的函数与参数组合
    f∗=arg⁡max⁡fj∈FPθ(fj,paramsj∣q,h)f^{*} = \arg\max_{f_j \in \mathcal{F}} P_{\theta}(f_j, \text{params}_j \mid q, h)

搜索工具

酒店后台有一座日夜更新的资料库:菜谱典故、宾客忌口、本地景点手册。管家不确定某道菜能不能做,先翻手册,再把找到的段落摘录给主厨。搜索工具的价值就在于此——它让 Agent 的知识不再局限于“训练时见过的东西”,而是随时翻阅实时资料。

搜索工具的技术底色是检索增强生成(RAG,Retrieval-Augmented Generation)。流程分三步:先把用户问题编码成一个向量(query embedding),再到文档库中找语义最接近的片段,最后把相关片段拼进提示词,让模型在“有资料”的前提下作答。多模态场景下,查询可能来自一张图片或一段语音,需要先用视觉或语音编码器转成向量再检索。

相关性打分最常用的是余弦相似度:

管家翻手册时不会逐字读,而是快速扫标题、抓关键段。RAG 的 Top-K 截断就是这个“扫”的过程——先粗筛,再让模型精读。搜索工具的伟大之处在于:它把 Agent 的知识边界从训练截止日期,延伸到整个不断更新的资料库。

score(q,d)=eq⋅ed∥eq∥ ∥ed∥\displaystyle \text{score}(q, d) = \frac{\mathbf{e}_q \cdot \mathbf{e}_d}{\|\mathbf{e}_q\| \, \|\mathbf{e}_d\|}
一句话理解:管家翻手册时不看章节厚薄,只看“说的是不是同一件事”——余弦相似度衡量的正是语义方向的一致程度。
  1. 查询向量 e_q把用户问题编码为语义向量,文本、图片、语音都可以编码
    eq=Encoder(q)\mathbf{e}_q = \mathrm{Encoder}(q)
  2. 文档向量 e_d资料库中每篇文档预先算好的向量表示
    ed=Encoder(d)\mathbf{e}_d = \mathrm{Encoder}(d)
  3. 点积运算两个向量逐维相乘再求和,衡量它们对齐的程度
    eq⋅ed=∑ieq,i⋅ed,i\mathbf{e}_q \cdot \mathbf{e}_d = \sum_{i} e_{q,i} \cdot e_{d,i}
  4. 模长归一化除以各自的长度,消除文档长短带来的干扰
    eq⋅ed∥eq∥ ∥ed∥\frac{\mathbf{e}_q \cdot \mathbf{e}_d}{\|\mathbf{e}_q\| \, \|\mathbf{e}_d\|}
  5. Top-K 筛选按相似度排序,取前 K 篇文档注入提示词
    d∗=arg⁡max⁡d∈Dscore(q,d)d^{*} = \arg\max_{d \in \mathcal{D}} \text{score}(q, d)

代码工具

宴会散场,管家要算三百人的酒水账单、按桌分摊费用。心算口算都不现实——他掏出计算器,把公式敲进去,机器瞬间给出精确答案。代码工具就是那把计算器:专门负责精确计算与批量操作,这是自然语言回答永远做不到的。

代码工具的典型链路是:模型根据任务描述生成一段程序(Python、SQL 或 Shell 脚本)→ 在沙箱环境中执行 → 捕获运行结果或报错 → 把报错反馈给模型 → 模型修复后重试。与 API“打电话问别人”不同,代码是“自己动手算”,适合处理数据清洗、数学计算、文件批处理等任务。

代码生成在数学上是一个自回归的语言生成过程:

管家按计算器也有按错的时刻,但他会看屏幕上的报错、重新检查算式。代码工具同理:报错不是失败,而是下一轮修复的起点;沙箱就是“只准在小书房里算账、绝不碰客人财物”的铁规矩。

P(c∣p)=∏i=1LPθ(ci∣c1,…,ci−1, p)\displaystyle P(c \mid p) = \prod_{i=1}^{L} P_{\theta}(c_i \mid c_1, \dots, c_{i-1},\, p)
一句话理解:管家把任务描述递给计算器,计算器一个数一个数地敲出完整算式,整段代码的正确性靠最终结果来验证。
  1. 任务描述 p把图像、语音、文本压缩成一段明确指令,告诉模型“要算什么”
    p=summary(ximg,xaudio,xtext)p = \text{summary}(x_{\text{img}}, x_{\text{audio}}, x_{\text{text}})
  2. 代码序列 c待生成的代码按 token 切分的结果
    c=(c1,c2,…,cL)c = (c_1, c_2, \dots, c_L)
  3. 逐 token 生成每一步只预测下一个 token,依赖此前生成的所有 token
    Pθ(ci∣c1,…,ci−1,p)P_{\theta}(c_i \mid c_1, \dots, c_{i-1}, p)
  4. 链式乘积整段代码的出现概率等于各 token 条件概率相乘
    P(c∣p)=∏i=1LPθ(ci∣c<i,p)P(c \mid p) = \prod_{i=1}^{L} P_{\theta}(c_i \mid c_{<i}, p)

评估体系

酒店的质检部每个月给管家打分:送错房间几次?上错菜几次?客人投诉率多少?分数高的升职,分数低的回炉重训。Agent 上线前同样要过“质检关”——不能因为“看起来聪明”就放行上线。

工具调用的评估分三层:单步指标(工具选对没有、参数填对没有)、多步指标(给定复杂目标,能否多轮调用工具完成任务)、鲁棒性指标(遇到模糊请求、恶意提示、工具超时,是否还能优雅处理)。业界常用的基准如 ToolBench、API-Bank 会把这些要求规整成带标注的评测集,既考单步选择也考多轮完成度。

最基础也最核心的是工具选择准确率:

质检部不看管家“态度好不好”,只看“送对没送对”。评估体系的铁律也是这样:指标必须落在可观测的动作与结果上,而不是模型的自我感觉。分数上去了,Agent 才敢从实验室走进产线。

ToolAcc=1N∑i=1N1[a^i=ai∗]\displaystyle \mathrm{ToolAcc} = \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}\left[\hat{a}_i = a_i^{*}\right]
一句话理解:质检部抽查 N 次服务,每次核对“管家实际做的”和“标准做法”是否一致,一致计 1 分,最后算平均分。
  1. 样本数 N评测集中带标准答案的测试任务总数
    N=测试任务数N = \text{测试任务数}
  2. 预测动作模型对每个任务从工具集中选出的动作
    a^i=πθ(si,T)\hat{a}_i = \pi_{\theta}(s_i, \mathcal{T})
  3. 标准答案人工标注的“正确工具 + 正确参数”
    ai∗∈Ta_i^{*} \in \mathcal{T}
  4. 指示函数一个开关,相等计 1、不等计 0
    1[a^i=ai∗]∈{0,1}\mathbb{1}[\hat{a}_i = a_i^{*}] \in \{0, 1\}
  5. 求平均所有样本的得分之和除以样本总数
    ToolAcc=1N∑i=1N1[a^i=ai∗]\mathrm{ToolAcc} = \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}[\hat{a}_i = a_i^{*}]

行业实践

最优秀的管家被提拔为管家团队总监,手下管着十位管家、五十件工具和五套权限。新的烦恼来了:任务该怎么派?工具多了,选择变多反而容易乱套;权限怎么收?绝不能让实习生拿到保险柜钥匙。行业实践要解决的,正是“从一个人能干,到一群人可靠地干”。

实际落地时,工程师首先面对的是工具编排问题:多工具调用该用固定工作流编排,还是让模型自由决策?工具越多,候选调用序列会呈爆炸式增长,这是典型的组合爆炸问题:

因此工业界常用“少而精”的工具清单加上人工编排骨架(DAG 工作流),让模型只在局部节点做选择,从而控制组合爆炸。与此同时,安全治理要跟上:权限最小化(工具级鉴权)、沙箱隔离(代码与搜索不出域)、审计日志(每一次调用全程留痕)、人工兜底(连续失败自动转人工)。总监的岗位价值不是“自己会订蛋糕”,而是“让团队不出错、可追溯、可兜底”——多模态工具调用的工程化正是如此:在模型能力之上架起编排与安全护栏,才能把聪明的实验室原型变成稳定的线上服务。

N=∑k=1nn!(n−k)!\displaystyle N = \sum_{k=1}^{n} \frac{n!}{(n-k)!}
一句话理解:工具越多,管家能排出的“行动剧本”就越多——剧本多了是本事,但选剧本的难度也跟着爆炸。
  1. 工具总数 nAgent 可调用的全部工具数量
    n=∣T∣n = |\mathcal{T}|
  2. 调用步数 k一次任务中最多串联工具的次数
    k≤nk \le n
  3. 排列数计算从 n 个工具中选 k 个并按顺序排列的序列数
    P(n,k)=n!(n−k)!P(n, k) = \frac{n!}{(n-k)!}
  4. 组合求和把所有可能长度的调用序列累加起来
    N=∑k=1nn!(n−k)!N = \sum_{k=1}^{n} \frac{n!}{(n-k)!}

AI 应用场景

智能客服工单助理

阶段:多模态感知 + API 调用 + 搜索增强

解决的问题:用户上传一张模糊的产品照片,再用语音抱怨“刚买的耳机没声音了”。传统客服只能反复追问型号、购买时间,信息重复收集且效率低下。AI Agent 可以同时解读图片与语音,自动补齐上下文。

具体案例:某电商平台上线多模态客服 Agent:用户拍照并语音留言后,Agent 调用图像识别 API 确认产品型号,搜索知识库匹配“蓝牙耳机无声”的故障处置方案,再通过订单查询 API 核验保修期,最终自动生成一张带处理建议的维修工单,派给售后组。

报表数据分析助手

阶段:多模态编码 + 代码工具 + 搜索工具

解决的问题:财务人员上传季度报表截图,口述“算一下华东区同比增幅”。传统流程需要人工写 SQL、查口径文档,门槛高且易出错。AI Agent 把截图变为可计算的表格,再自动化执行数据分析。

具体案例:某咨询公司的数据助手接收 Excel 截图和语音指令,先用视觉编码器抽取表格结构,调用代码工具生成 pandas 脚本完成分组汇总与同比计算,同时搜索内部口径文档确认“同比”定义,最终输出数值结论与可视化图表,全程附带可审计的代码。

会议纪要智能提炼

阶段:语音识别 API + 文档检索 + 代码汇总

解决的问题:一场两小时的项目复盘会,既有现场录音又有 PPT 投屏。传统速记员逐字记录耗时耗力,事后还要人工整理待办。多模态 Agent 能同步处理音频与图像,自动产出结构化纪要。

具体案例:某互联网公司的会议 Agent 在会议结束后,调用语音转写 API 生成逐字稿,搜索企业知识库定位相关项目文档,再用代码工具对发言内容做聚类统计,自动提炼出决议事项、负责人与截止时间,并生成周报草稿发送给参会人。

Python 演示

python111 行
# -*- coding: utf-8 -*-"""多模态工具调用Agent简易演示:管家感知多模态请求,按需调用API/搜索/代码工具"""import json  TOOL_SCHEMAS = [    {"name": "weather_api", "params": {"city": "string"}, "desc": "查询城市天气"},    {"name": "hotel_api", "params": {"city": "string"}, "desc": "预订酒店房间"},    {"name": "translate_api", "params": {"text": "string"}, "desc": "翻译文本"},    {"name": "search_docs", "params": {"query": "string"}, "desc": "检索知识库"},    {"name": "run_python", "params": {"code": "string"}, "desc": "沙箱执行代码"},]  class ToolBox:    """三层工具箱:API / 搜索 / 代码"""     def __init__(self):        self.api_map = {            "weather_api": lambda p: {"weather": "晴", "temp": 24, "city": p["city"]},            "hotel_api": lambda p: {"order_id": "BK-2024-001", "status": "confirmed"},            "translate_api": lambda p: {"translated": "hello " + p["text"]},        }        self.search_index = ["杭州今日天气", "西湖附近酒店", "英文翻译服务"]        self.code_runner = lambda c: eval(c, {"__builtins__": {}}, {})     def api_call(self, name, params):        """模拟调用外部API,返回JSON结果"""        if name not in self.api_map:            return {"error": "unknown api"}        return self.api_map[name](params)     def search_docs(self, query):        """模拟检索:把关键词命中的文档作为结果返回"""        hits = [doc for doc in self.search_index if query in doc]        return {"hits": hits if hits else []}     def run_python(self, code):        """模拟沙箱执行:捕获异常并返回结果或报错"""        try:            return {"result": self.code_runner(code)}        except Exception as exc:            return {"error": str(exc)}  class MultimodalAgent:    """管家Agent:感知 -> 规划 -> 执行 -> 观察 的决策循环"""     def __init__(self, tools):        self.tools = tools        self.memory = []      # 短期记忆:本轮对话与行动历史        self.gc_count = 0     # 计数器,不与任何方法同名     def perceive(self, text_note, image_note, audio_note):        """多模态感知:把图像与音频的文本描述汇总成一句话"""        merged = " ".join(x for x in [text_note, image_note, audio_note] if x)        self.memory.append({"role": "perceive", "content": merged})        return merged     def plan(self, query):        """规则式规划:根据关键词从五件工具中选一件"""        self.gc_count += 1        if "天气" in query:            return "weather_api"        if "酒店" in query:            return "hotel_api"        if "翻译" in query:            return "translate_api"        if query.startswith("计算"):            return "run_python"        return "search_docs"     def execute(self, action, query):        """执行:调用工具并把结果写回记忆"""        if action == "weather_api":            result = self.tools.api_call("weather_api", {"city": query[2:4]})        elif action == "hotel_api":            result = self.tools.api_call("hotel_api", {"city": "杭州"})        elif action == "translate_api":            result = self.tools.api_call("translate_api", {"text": query[3:]})        elif action == "run_python":            result = self.tools.run_python(query[3:])        else:            result = self.tools.search_docs(query)        self.memory.append({"role": "action", "tool": action, "result": result})        return result     def run(self, query, text_note="", image_note="", audio_note=""):        """完整Agent循环:感知 -> 规划 -> 执行 -> 返回"""        self.perceive(text_note, image_note, audio_note)        action = self.plan(query)        result = self.execute(action, query)        return {"query": query, "tool": action, "result": result}  def main():    """演示三个场景:天气API、代码计算、知识库检索"""    tools = ToolBox()    agent = MultimodalAgent(tools)    cases = [        {"query": "查询杭州天气", "image_note": "[图片] 阴雨中的城市街景"},        {"query": "计算 3*8+2", "text_note": "[文本] 用户需要精确结果"},        {"query": "找一下西湖附近酒店", "audio_note": "[语音转文字] 用户口述"},    ]    for case in cases:        print(json.dumps(agent.run(**case), ensure_ascii=False, indent=2))    print("Agent记忆轮次:", len(agent.memory))  if __name__ == "__main__":    main()
目的:用不到 100 行实现一个“管家式”多模态工具调用 Agent,演示从多模态感知到工具选择的完整决策循环。
  1. TOOL_SCHEMAS = [...]电话簿:注册五件工具的“接口说明”,对应机器学习中的函数描述清单
  2. self.api_map = {...}API 工具注册表,模拟三个外部服务商的响应逻辑
  3. def perceive(...)多模态感知,把图片、语音、文本三类线索合并成一句话输入
  4. def plan(self, query)规则式规划器:按关键词从五件工具中选出最合适的一件
  5. self.memory.append(...)记忆写入:每次感知与行动都记入短期记忆,供后续轮次参考
  6. agent.run(**case)触发完整 Agent 循环:感知 → 规划 → 执行 → 返回结果

常见误区

误区刚开始接触时,我以为工具调用就是写脚本把图片识别、天气查询等接口按顺序调用一遍,会写 requests 库就能搞定。

正解工具调用的灵魂是模型“自主决策”,而不是脚本“机械串联”。API 只是被调用的对象,真正的难点在于:何时调、调哪个、参数如何从多模态输入中正确提取、工具结果如何作为观察进入下一轮。脚本是写死的,Agent 是动态决策的——就像管家要根据现场情况决定先打给花店还是先打给蛋糕店,而不是固定顺序。

为何常见:大多数教程展示的都是“调一个接口”的简化 demo,让学习者误以为把多个接口拼在一起就是工具调用的全部。

误区搜“猫的照片”就把这几个字丢给搜索引擎做字面匹配,搜不到就觉得是资料库太小,从没想过问题出在匹配方式上。

正解多模态搜索必须把查询和文档都编码成语义向量,用余弦相似度衡量语义接近度。用户发一张模糊的橘猫照片,走视觉编码器得到查询向量,才能匹配到“橘猫品种介绍”的文档;关键词匹配遇到同义改写、跨模态查询就会失效。

为何常见:传统搜索引擎用关键词倒排索引,先入为主的习惯让人忽略了语义层面的对齐问题。

误区模型生成一段 Python 代码,就直接复制到生产环境跑,跑不通就骂模型不行,跑通了就万事大吉。

正解代码工具的标准流程是沙箱隔离执行 → 单元测试验证 → 报错反馈给模型修复。生成代码只是起点,“能通过测试”才算成功。生产环境直接执行未经沙箱的模型代码,既有逻辑错误风险,也有安全风险。

为何常见:现代大模型写简单代码的正确率确实高,样本量一大就容易让人忽略失败率和副作用。

误区只要 Agent 某次调用 API 超时或返回错误,就觉得产品不可用,于是拼命追求 100% 的单次成功率。

正解工程实践讲究容错设计:重试、备用工具、人工兜底、连续失败阈值。评估看的是多轮任务完成率与整体业务指标,单次失败本是正常分布的一部分,关键是有没有优雅的恢复路径。

为何常见:实验室评测常常只报单步准确率,让人误以为线上也必须零失误。

面试题

Q1. 在多模态工具调用中,“选择哪个工具”这一动作的本质是?

单选题 · easy

  • A.随机挑选任意工具执行
  • B.按固定顺序依次执行
  • C.从工具集中做出决策← 正确答案
  • D.交给用户手动选择

答案:C。工具调用由 Agent 根据当前状态做决策,本质是从工具集 T 中选出动作 a_t = π_θ(s_t, T)。随机挑选、固定顺序或把决策权甩给用户,都不符合“自主决策”的设计初衷,就像管家必须自己判断该给哪家供应商打电话。

Q2. 在“思考-行动-观察”循环中,“观察(Observation)”环节的主要作用是?

单选题 · mid

  • A.清空所有历史对话信息
  • B.直接跳过工具执行步骤
  • C.读取工具返回的结果← 正确答案
  • D.切换多个不同的大模型

答案:C。观察环节把工具返回的 JSON、报错或搜索结果写回上下文,成为下一轮决策的状态。如同管家挂断电话后把对方的答复记在心里。清空历史、跳过执行、切换模型都与“观察”无关。

Q3. Function Calling 中,模型最核心的产出是?

单选题 · mid

  • A.一段完整的业务文案
  • B.用户身份验证码
  • C.符合结构的参数数据← 正确答案
  • D.工具的内部实现代码

答案:C。Function Calling 要求模型输出“函数名 + 符合 JSON Schema 的参数”,参数填错就像电话打过去报错房间号,一切白搭。文案、验证码、内部实现代码都不是模型该产出的内容。

Q4. RAG 检索采用余弦相似度的主要原因是?

单选题 · hard

  • A.对向量模长变化不敏感← 正确答案
  • B.计算速度永远最快
  • C.只支持中文语料检索
  • D.能完全替代深度学习

答案:A。余弦相似度只比较向量方向,对模长不敏感——文档长短不一但语义方向一致时也能命中,正如管家翻手册时不看章节厚薄。速度、语种限制、替代深度学习都不是其设计目标。

Q5. 代码工具放入沙箱执行的首要原因是?

单选题 · easy

  • A.减少程序的运行时间
  • B.让代码速度变得更快
  • C.避免代码格式出错
  • D.隔离危险操作副作用← 正确答案

答案:D。沙箱的核心价值是隔离副作用,如文件删除、网络请求等危险操作只能在受控环境执行。就像管家只能在小书房里打算盘,不能把算盘拿到宴会厅乱敲。运行速度与格式问题不是安全考虑的首要目标。

Q6. 下列哪些信号可以作为多模态 Agent 的输入?

多选题 · mid

  • A.摄像头拍摄的现场照片← 正确答案
  • B.用户说话的原始音频← 正确答案
  • C.一段指令性文字说明← 正确答案
  • D.尚未发生的未来计划

答案:ABC。多模态 Agent 的输入包括图像、音频、文本等模态的编码结果;“尚未发生的未来计划”不是可感知的信号。就像管家只能处理已经看到、听到的信息,不能处理还没发生的事。

Q7. 评估工具调用质量时,常用指标包括哪些?

多选题 · hard

  • A.工具选择准确率← 正确答案
  • B.参数填充准确率← 正确答案
  • C.多轮任务完成率← 正确答案
  • D.模型参数量大小

答案:ABC。工具选择准确率、参数填充准确率、多轮任务完成率共同刻画调用质量,而模型参数量只说明模型规模,不代表调用能力。质检部看的是服务结果,而不是管家体重。

Q8. 多模态 Agent 引入记忆机制的主要目的是?

单选题 · mid

  • A.增加每次请求的参数量
  • B.降低大模型的训练成本
  • C.记住用户偏好与历史决策← 正确答案
  • D.移除对工具调用的依赖

答案:C。记忆机制保存对话历史、用户偏好与工具返回结果,让 Agent 在多轮对话中不重复提问,如同管家记得贵宾不吃香菜。增加参数量、降低训练成本、移除工具依赖都不是记忆机制的目标。

Q9. 行业落地时,安全治理通常包含哪些措施?

多选题 · easy

  • A.对工具执行做权限管控← 正确答案
  • B.对输出内容进行审核← 正确答案
  • C.对代码工具不做隔离
  • D.对失败任务全程记录← 正确答案

答案:ABD。权限管控、输出审核、审计记录是安全治理的支柱;“不做隔离”是危险做法。安全治理 = 权限最小化 + 沙箱隔离 + 全程留痕 + 人工兜底,缺一不可。

Q10. 当工具箱数量增加时,Agent 的规划难度会?

单选题 · hard

  • A.保持不变不受影响
  • B.候选序列呈组合数增长← 正确答案
  • C.线性平稳缓慢上升
  • D.先下降再快速回升

答案:B。n 个工具、最多 k 步的调用候选序列数为 ΣP(n,k),随工具数量呈组合爆炸式增长。线性增长、不受影响、先降后升都不符合组合爆炸的数学规律。这也是工业界坚持“少而精工具集 + 人工编排骨架”的原因。