“帮我算一下，以当前车速刹停大概需要多少米？”“下一首歌放一首我上次在健身房听过的粤语歌。”“我快到停车场了，帮我把车窗降下来，再把空调调到26度。”这些指令看起来都不复杂，但你去问任何一个大模型，它大概率会给你一个逻辑完整、听上去头头是道、但完全没法直接用的回答——因为它没有传感器，没有计算器，没有车况总线数据，也没有地图POI的实时接口。大模型什么都“知道”，但什么都“做不了”。这和人的处境其实很像：一个再厉害的顾问，也不能代替你去拧螺丝。
如果你接触过大模型相关的落地项目，多半会产生同一个困惑：让模型直接生成答案不行吗？为什么还要搞一堆工具、API、插件出来？这个问题的正解，恰恰藏在一个叫 Toolformer 的工作里。它用一套很聪明的思路，让语言模型自己学会在合适的位置调用外部工具，而不是试图把所有能力都塞进参数里。这篇文章我想从 Toolformer 的核心机制聊起，把它放到车载 AI 的语境里重新拆一遍，聊聊“模型负责什么”“工具负责什么”这条边界究竟该怎么划，以及实操中你会遇到哪些绕不开的坑。
这篇文章适合正在做车载语音助手、智能座舱、车机交互相关产品的人，也适合对大模型工具调用机制感兴趣、想理解“为什么模型不能什么都自己做”的技术同学。不需要你有很强的论文功底，我会尽量把机制讲得像拆一台发动机一样直白。
1. 先回到源头：Toolformer 到底解决了什么问题
1.1 语言模型的天生缺陷
先问一个基础问题：语言模型最擅长什么？答案是“续写”。给它一串 token，它预测下一个 token 是什么。这个能力在大量文本上反复训练之后，会长出惊人的语言组织能力、知识记忆能力和一定的推理能力。但与此同时，续写这个目标本身就决定了它有三个天生缺陷：
- 它没有真正的计算能力。你问它 278 乘以 364 等于多少，它是在“猜一个看起来合理的答案”，而不是在“算”。小数字还能靠训练样本背下来，大数字就露馅了。
- 它的知识是静态的。训练数据截止日期就是它的世界末日。你问它今天路况怎么样、最近充电站有没有空闲桩位，它完全没有概念。
- 它只能输出文本，无法操作任何东西。哪怕它知道“应该把空调调到26度”，它也没有任何手和脚去拧旋钮。
这些缺陷不是靠堆参数量就能解决的。模型参数再多，也不能让死知识变成活数据；训练数据再全，也不能覆盖实时变化的物理世界。这就指向一个必然结论：模型不应该试图自己完成一切，而应该学会把一部分工作外包出去。
1.2 Toolformer 的四步驯化法
Toolformer 是某研究团队在 2023 年提出的一项工作，核心思想说起来特别简单：让语言模型在一段文本中自己找到“该调用工具的位置”，然后调用工具得到结果，把结果拼回去，再继续生成文本。整个过程不需要大量人工标注，模型可以从普通语料里自动学习。
具体流程分四步：
| 步骤 | 做什么 | 关键逻辑 |
|---|---|---|
| 第一步 | 准备一批工具，比如计算器、搜索、翻译、日历等 | 工具本身是固定的，模型不学工具内部怎么实现，只学“何时调用”和“传什么参数” |
| 第二步 | 对语料中每个 token 位置采样候选 API 调用 | 模型会生成一个类似[Call(CALC, 278*364)]的标记序列，代表“这里我想调用计算器” |
| 第三步 | 执行 API 得到结果，判断这个调用是否让后续文本预测更准 | 把调用结果拼回去再算一次语言模型的 loss，如果 loss 降低了，说明这个调用是有用的 |
| 第四步 | 把通过筛选的调用样本作为训练数据，微调模型 | 模型从此学会在类似场景下主动插入工具调用 |
这套流程最妙的地方在于第三步的“筛选机制”。模型每看到一个候选位置都想调用工具，但大部分调用是没意义的。怎么判断？看结果。如果带上工具结果后，模型对后续 token 的预测概率变高了，说明这个调用确实提供了有效信息；如果概率没变甚至变低了，说明这个调用是噪音，直接丢掉。这个自监督信号让模型自己学会了“什么时候该用工具，什么时候不该用”。
1.3 为什么“让模型自己决定”比“规则决定”更高级
你可能会问：为什么不直接在系统里写死规则？比如用户说“充电桩”就调 POI 搜索，说“计算”就调计算器？在固定场景下规则确实够用，但真实交互远没有这么规整。
语言是模糊的。“帮我看看附近有没有能吃饭的地方”——你需要调的不是一个“餐厅搜索工具”，而是先判断意图、再抽取位置和口味偏好、然后决定调用什么服务。“我明天早上走的时候车里太热了”——这里甚至没有明确的指令性动词，但模型可以通过上下文推理出用户要设置“驻车通风”或者“远程空调”。
Toolformer 的启发在于：工具调用的位置和参数，本质上是一个概率分布，而不是一个固定模板。模型在训练中见过大量“文本中提到缺失信息→调用搜索→补充信息→继续生成”的样本后，自然学会了在类似情况下主动发起调用。这和规则系统的“人肉写逻辑”有本质区别——前者把决策权交给了学习到的分布，后者靠人脑穷举。
1.4 别神化 Toolformer
当然，Toolformer 也不是万能的。它有几个明显的局限，我在做车载相关实践时必须提前说明：
- 它学到的工具调用是“单步”的，不会自己规划“先搜索地点，再搜索路线，再查询路况”这种多步流程。
- 工具集合是固定的，训练完之后不能随意加新工具。
- API 结果只作为文本拼接回去，没有结构化的状态管理和错误重试机制。
所以它更大的意义是一套方法论，而不是一个可以直接上生产的组件。我们真正要学的是它的“筛选信号”思想——怎么让模型知道边界在哪、什么时候该求助于外部工具。
2. 车载 AI 的特殊性：为什么这里是“模型+工具”边界最敏感的场景
2.1 算力与实时性的硬约束
车机不是数据中心。哪怕现在座舱芯片越做越强，跟云端 A100 集群比还是差着量级。如果一个指令动辄要走完整的大模型推理链路，时延根本压不住。
我拿一个实际场景说话。用户在开车时说了一句“空调太冷了”。如果走传统规则引擎，一个意图分类模型加一个槽位解析，20 毫秒内就能触发空调温度调节。但如果交给一个大语言模型去“理解这句话”，再“生成一个回复”，再“决定要调用哪个温度控制接口”，整个链路跑完可能已经过去一两秒。高速上车速 120 公里/小时，1 秒钟车就飞出 33 米。时延不是体验问题，是安全问题。
这就是边界的第一层含义：能走确定性链路的，别让模型掺和；模型负责的是“理解”和“决策”，不是“执行”和“计算”。
2.2 输出的概率性不能被安全场景接受
大模型的输出本质上是从概率分布里采样的。再强的模型也有概率在某个时刻给你一个匪夷所思的回答。这在聊天场景里顶多算个笑话，但放在车辆控制场景里是不可接受的。
试想两个场景：
- “帮我打开雨刷”——如果模型理解错了，把空调压缩机打开了，夏天还没什么，冬天吹冷气就很糟糕。
- “前方拥堵吗，要不要换个路线”——如果模型引用了一个过期的路况工具结果，或者干脆幻觉出一个“前面堵车”的结论，用户就得在真实拥堵里多堵半小时。
所以车载 AI 的架构天然要求“模型参与决策，但工具保障执行”。凡是涉及车辆状态改变的操作，必须通过确定的工具接口去执行，并带状态回读确认。模型生成的任何控制指令，都得经过一层校验和确认机制才能落到底层执行器。
2.3 数据时效性与私有性
大模型的常识、通识再强，也不可能知道“这辆车的胎压当前是多少”“附近三个充电站哪个空闲”“用户上次听歌是在哪里”。这些都是车端私有数据或实时数据，必须通过工具实时获取。
模型如果硬背这些数据，只会得到两种结果：一种是训练截止日期之后的数据一概不知道；另一种是把别人车的数据幻觉到你这辆车上。无论哪种，在用户侧都是灾难。所以在车载环境里，“实时数据”和“车端私有数据”必须走工具，模型只负责“消费工具返回的结果并组织语言”。
2.4 组合型操作的天然复杂性
车载场景还有一个特点：用户的一句话经常是对多个系统的联合操作。比如“我回家了，帮我导航到小区东门，顺便把座椅和方向盘复位，再提醒我今晚八点给老妈打个电话。”这句话涉及导航、座椅记忆、方向盘位置、日程提醒四个系统。让模型自己“记住”并完成这些操作是不可能的，它必须把它们拆解成多个工具调用并组织执行顺序。
组合操作还带来一个额外的问题：不是所有工具都可以并行调用。座椅复位和导航规划之间没有依赖关系可以并行；但“导航到小区东门”必须先完成 POI 搜索、拿到准确的终点坐标，才能发起导航路线规划。这就需要模型具备一个“任务分解”的能力，同时还需要一个外部执行环境去管理这些工具调用的状态和时序。模型在这里的角色更像是一个“项目拆解人”，而不是“施工队”。
3. 模型与工具的边界，具体怎么画
3.1 四条边界原则
我经过一段时间的车载 Deme 实践，把模型与工具的边界总结成四条原则，基本可以覆盖绝大多数场景。
原则一：模型决定“做什么”，工具决定“怎么做”。
用户说“太热了”，模型负责理解这句话背后是“希望降低车内温度”的意图，然后决定调用“空调控制”工具，并把“温度下调”作为参数传过去。但具体是驱动压缩机、调节风门、调整内外循环，这些是工具内部的事情，模型不干预，也不需要懂。
原则二：凡是涉及活数据的，一律走工具。
实时路况、天气、充电桩空闲状态、停车场剩余车位、当前车速、胎压、续航里程——这些数据要么来自云端服务，要么来自车端传感器，模型一概不应被允许“凭空回答”。它可以调用工具拿数据，再基于数据组织语言，但它不能直接生成一个“当前胎压是 2.5 巴”这样的结论。
原则三：凡是涉及操作执行的，一律走工具，且需要结果回执。
开空调、降车窗、切歌、设导航、发起通话——这些操作不能靠模型“嘴动”，必须调用车控服务完成实际动作，并且服务端要向模型返回执行成功与否、当前状态如何。模型基于这个回执生成用户可感知的反馈，比如“空调已打开，温度设定为 26 度”。如果执行失败，模型要能理解失败类型，再给出合理的应对话术。
原则四：模型只做它擅长的“弹性部分”。
模型擅长什么？理解复杂且模糊的自然语言、多轮对话的上下文追踪、话术的智能组织和个性化表达。这些是传统的规则引擎很难做好的部分。所以模型的定位不是“全能智能体”，而是“交互大脑”——它处理理解、决策和表达，把确定性执行交给工具。
3.2 一个完整示例：工具怎么被调用的
我用一个完整的车载场景把这条链路串起来。
用户说：“我快到了，帮我把空调打开，再找找附近有没有充电桩。”
这条指令在“模型+工具”架构下会经历这样的过程：
- 语音转写完成后，把它交给车载对话模型。
- 模型判断这是一个复合意图，拆解出两个子任务：空调控制和充电桩搜索。
- 对第一个子任务，模型调用车控工具
ACControl，参数是{"state": "on"}。工具执行完成后返回{"state": "on", "temp_current": 28.5}。 - 对第二个子任务，模型调用地图工具
SearchPOI，参数是{"keyword": "充电桩", "location": "current", "radius": "3km"}。工具返回附近充电桩的结构化列表。 - 模型把两个结果组织成回复：“空调帮你打开了，现在车里 28.5 度，预计几分钟就凉下来。附近 3 公里内有 4 个充电桩，其中 2 个有空闲，最近的 350 米，要导过去吗？”
这个例子里，模型做的事情是把用户的一句话拆成任务列表、为每个任务选择合适的工具并构造参数、把工具返回的结构化数据转换成自然语言。它没有制造任何车控指令，没有编造充电桩位置，也没有凭记忆回答“现在车里多少度”。每一条信息的背后都有一个真实工具在支撑。
4. 实操落地：构建车载“模型+工具”系统的几个关键环节
聊完理论，进入实操。这部分我会把做车载智能体时，真正需要动手设计的环节逐个过一遍。
4.1 第一步：定义你的工具集
工具集设计是整个系统的地基。工具不是越多越好，而是越“正交”越好。什么叫正交？就是每个工具负责一件独立的事，功能之间尽量不要重叠。
我在实际设计车载工具集时，一般按领域划分：
| 领域 | 工具示例 | 核心参数 | 返回内容 |
|---|---|---|---|
| 车控 | 空调控制、车窗控制、座椅调节、后备箱开关 | 目标值、开关状态 | 执行状态、当前值 |
| 导航 | POI 搜索、路线规划、路况查询、收藏地点 | 关键词、起点终点、偏好 | 坐标、路线、时长 |
| 多媒体 | 歌曲搜索、播放控制、电台切换 | 歌名、歌手、播放状态 | 歌曲信息、播放状态 |
| 信息查询 | 天气、新闻、百科 | 城市、话题 | 结构化内容 |
| 日程提醒 | 创建提醒、查询日程 | 时间、事件 | 确认状态 |
| 车辆诊断 | 读取胎压、电量、里程、故障码 | 车辆部件 | 数值、状态码 |
工具描述要尽量用模型容易理解的自然语言，并写明参数含义和边界。比如一个 POI 搜索工具，参数radius要说明“单位是米，默认 3000”，模型才知道该传什么值。工具描述写得含糊，再聪明的大模型也会传错参数。
4.2 第二步：决定工具调用的触发策略
工具调用不是模型“灵光一现”就能稳定触发的，工程上通常有三种策略组合：
策略一：规则前置。用户的指令经过前端意图分类和槽位解析，如果意图非常明确且槽位齐全，直接走传统链路，不经过大模型。比如“打开雨刷”这种指令，意图类别和槽位都是确定的，没必要让大模型绕一圈。这个策略能保障高频确定性指令的低时延和高可靠。
策略二：大模型意图理解 + 工具选择。当规则引擎无法确定意图，或者指令包含多个子任务、存在指代和省略时，把请求交给大模型。模型基于它的工具集描述，自行决定调用哪个工具、传什么参数。
策略三：混合路由。实际生产中最常见。先用一个轻量的意图分类器做路由，简单意图走规则，复杂意图交给大模型；如果大模型的输出置信度低，回退到规则链路，并给出澄清话术。
这三种策略放在一起，才构成一个完整的边界体系。模型不是每一个请求都要参与，而是只处理它该处理的部分。那些规则能确定的、确定性系统更快的、出错代价高的操作，反而应该尽量用规则解决。
4.3 第三步：模型微调还是提示词工程
工具调用链路有了，接下来要考虑模型本身怎么具备“工具选择能力”。这里有两种路线，我分别说明适用场景。
路线 A：直接使用支持工具调用（function calling）的通用大模型。你只需要在提示词里把工具集的 JSON Schema 描述清楚，模型就能根据用户指令输出一个结构化的工具调用请求。优点是几乎没有训练成本，模型能力不够时换个大一号的版本就行；缺点是依赖外部 API 的稳定性，有时效延迟和费用，而且车端网络弱的环境下不一定可靠。
路线 B：借鉴 Toolformer 的思路，采集一批“用户指令—工具调用—工具结果”的样本，让车机端小模型做监督微调。这是 Toolformer 给产业落地最大的启发——不是所有模型都要靠人工标注去教“何时调用工具”，你可以在日志数据里自动构造样本，只要样本里有“调用工具后回复更准确”的正反馈信号，就能训练出工具调用能力。优点是可以把推理放到车端，时延更低、不依赖网络；缺点是前期要积累足够的车端日志样本，而且小模型的泛化能力不如云端大模型。
我的经验是：在项目初期，用户真实交互数据还不多时，先用路线 A 快速验证体验；等积累了足量日志后，再用路线 B 把高频场景下放到车端小模型，借助类似 Toolformer 的样本筛选法自动构造训练集。云端大脑负责长尾和复杂场景，车端小模型负责高频和确定性场景，两条腿走路。
4.4 第四步：设计“失败兜底”和“多轮确认”
工具调用不是只要模型输出了ACControl就万事大吉。真实世界里工具会超时、会返回空结果、会执行失败。边界划分的最后一公里，恰恰是“失败时怎么办”。
我建议在设计边界时提前定义三层兜底：
- 工具执行失败：模型应基于失败类型生成不同的用户反馈。比如空调控制工具返回
{"error": "busy"}（有其他指令占用），模型应该说“空调控制系统正在忙，稍等一下我再试一次”，而不是干巴巴地复读“调用失败”。 - 工具结果可信度低：比如 POI 搜索返回空列表，模型应该说“附近 3 公里内没有找到充电桩，要不要我把范围扩大到 5 公里？”这里的“5 公里”可以是模型根据上下文自动建议的合理值，也可以走一个预先配置的兜底逻辑。
- 模型自身不确定：当模型对用户指令的意图置信度很低时，不要硬猜，应该主动澄清。比如“你说的‘老地方’是指家里还是公司？我需要确认一下才能帮你导航。”
模型与工具边界画得再清晰，如果没有这三层兜底，真实体验还是会很割裂。用户不会关心你的系统里模型和工具是怎么分工的，他只知道空调到底开了没有、路线到底有没有规划成功。边界设计最终要落到“用户感受到的结果”上。
5. 常见问题与排查技巧实录
这部分是我自己在车载智能体联调过程中踩过的坑，整理成一份问题排查速查表，帮你少走弯路。
| 常见问题 | 表现 | 排查思路 | 解决方案 |
|---|---|---|---|
| 模型调用了错误工具 | 用户说“调低温度”，模型却调用了“风速控制” | 看模型的工具选择日志，判断是意图理解错误还是工具描述歧义 | 优先检查工具描述是否需要更明确的边界词汇，必要时在提示词里加“温度调节使用 ACControl，风速调节使用 FanControl”的显式约束 |
| 工具参数传错 | 把radius=3000传成了radius=3000公里 | 检查模型输出是否没有严格遵循 JSON Schema | 在工具定义中加单位说明，同时对关键参数做归一化校验，发现异常时用规则修正参数值 |
| 工具结果超时 | 用户等待超过 3 秒没有反馈 | 检查工具服务端耗时，定位是外部 API 慢还是模型生成慢 | 对长耗时工具加超时配置和异步机制，先回复用户“正在查询”，再返回结果 |
| 工具返回内容太长 | 搜索结果很长，模型生成回复过慢 | 看工具是否返回了过多冗余字段 | 精简工具返回字段，前端先用规则截取最核心的几条信息，再交给模型组织语言 |
| 多轮对话中工具状态丢失 | 用户第一轮选了充电桩 A，第二轮说“导航过去”，模型却不记得了 | 检查对话上下文中是否保存了工具调用的状态快照 | 把工具调用的关键结果（如 POI 的坐标和名称）回填到会话记忆中，而不是只记住轮次的文本 |
| 低频工具被冷落 | 模型在联合指令中总漏掉“订阅胎压提醒”之类的不起眼工具 | 查看模型输出的任务列表，确认是否拆解不完整 | 在提示词里增加“检查用户指令中是否有隐含的子任务”的指令，同时用长尾样本做针对性微调 |
| 模型在车端小参数下变“笨” | 换成车端小模型后工具调用成功率骤降 | 检查小模型是否在训练数据上覆盖了工具调用的格式 | 参考 Toolformer 的样本筛选法，用自动构造的“指令—调用—结果”样本做针对性微调，补充工具调用格式语料 |
5.1 一个值得单独说的坑：工具结果回填
多轮对话里的工具状态问题是车载场景里最容易翻车的，值得单独展开说。用户说“帮我找附近的充电桩”，模型调用 POI 搜索，返回了三个结果。正常流程下模型会把这三个结果压缩成自然语言回复给用户，比如“附近有三个，最近的在 350 米处”。
问题在于：如果第二轮用户说“导航到第一个”，系统怎么就“第一个”？
严格来说，这个“第一个”是上一轮工具调用结果里的某个 POI 实体，它不在最初的自然语言回复里，更不在用户指令里。它只存在于工具返回的结构化数据中。如果系统没有把这个结果保存下来并挂载到当前会话上下文，模型第二轮看到的就是一段“附近有三个，最近的在350米处”的纯文本，它根本无从得知“第一个”具体对应哪个具体坐标。
这个问题的解法和 Toolformer 的机制有异曲同工之处：工具调用的结果本身就是上下文的一部分，模型需要能“看到”这些结构化的结果，而不是只看到被转写后的摘要。所以我在做系统设计时，会把每次工具调用的完整返回结果以结构化格式附加到对话上下文中，并且标明调用序号。这样模型在下一轮才能正确理解“导航到第一个”里的指代。
这个细节看起来小，但直接影响整个系统能不能支撑多轮交互。边界不是画完工具列表就结束了，还要保证边界两侧的信息能完整地来回流动。
5.2 关于小模型工具能力的一点心得
Toolformer 最初做实验时用的模型体积并不大，这给了我们一个启发：工具调用能力不一定非得靠超大规模模型。但这句话在实际落地时有个前提——小模型要把工具调用的“格式”学到足够熟。
模型产生工具调用时，要输出特定的控制 token 和 JSON 参数。大模型在预训练阶段见过大量类 JSON 文本，所以它很容易无师自通地学会这个格式；但小模型可能只在弹窗问答类的数据上训练过，根本不熟悉“输出一个结构化工具调用”这种任务。想让小模型具备工具调用能力，需要准备足够多的问答配对数据，其中相当一部分要覆盖“用户问→思考→调用工具→拿到结果→组织回复”这种格式。少了这一步，小模型要么直接瞎编工具参数，要么干脆跳过工具调用直接回答。
我建议在早期采集样本时，不要只采真实日志，还可以用规则和模板造一批高质量样本。把高频的车控指令、导航指令、多媒体指令先覆盖一遍。造数据的过程本身就是一种边界梳理——你越清楚有哪些工具、每个工具输入输出是什么，造出来的数据质量就越高。
6. 写在最后：边界不是限制，是解放
做了一段时间车载智能体之后，我最大的感受是：模型与工具的边界不是我们给模型套上的枷锁，反而是让模型真正发挥作用的前提条件。一个什么都要自己做的模型，最后什么都只能做得平庸；一个知道自己何时该求助工具的模型，才能把语言理解、对话决策的天赋落到实处。
如果你是做车载产品、智能座舱或者任何具身智能方向的开发者，我建议你从今天开始就把这句话记在项目文档的第一页：让模型做它擅长的事，把不擅长的事交给工具，然后用一套清晰的协议把它们连起来。这句话听起来朴素，但执行起来需要你对每个交互场景做细颗粒度的拆解，需要你在模型输出和工具执行之间建立校验和兜底，需要你敢让模型说“这个我不确定，我来查一下”。
这条路没有银弹，但沿着 Toolformer 指出的方向走，你会看到一个更健康的系统形态。
