简介
本文写于 2026 年 8 月 4 日。这里的“主流”指头部闭源模型及主流开源模型/推理栈的产品方向，而非某一个动态排行榜的名次。模型版本、价格和可用地区变化很快，生产选型应以当日模型卡、API 文档和自己的任务集复测为准。
几个月前做 vLLM 部署时，很多团队会刻意寻找某些带 -IT、-Instruct、-Function-Calling 或 -Tool 标记的权重。直觉没有错：要让模型稳定地产生可执行 JSON、在多轮中消费工具结果、选择正确函数，普通续写模型往往远远不够。
但这个说法里有一个值得先拨正的小问题：-IT 通常是 instruction-tuned（指令微调），不是业界统一定义的“工具调用/电脑操作专项模型”标签。不同发布者对后缀的定义并不一致。真正要看的，是模型卡是否声明了 function/tool calling、所用聊天模板和工具格式、支持的 JSON Schema 子集、调用轮次表现、以及是否在浏览器或桌面环境做过 computer-use 训练和评测。
今天最显著的变化，是工具调用从“需要为每个模型单独拼装的一项附加技能”，变成了越来越多模型和平台的默认接口能力。它不意味着智能体已经可靠到可以脱离工程约束，也不意味着开源部署只要升级权重即可一劳永逸。更准确地说，能力的重心正在从生成一段像 JSON 的文字，移动到在受约束的行动循环里完成任务。
一、过去几个月到底变了什么
可以把这轮变化拆成四层。只观察第一层，很容易高估模型；忽略后面三层，又会错过真正可落地的进步。
| 层次 | 较早的常见状态 | 现在的主流方向 | 对部署者的含义 |
|---|---|---|---|
| 模型 | 主要是指令跟随；工具格式靠提示词“诱导” | 训练中显式包含工具选择、参数填写、工具结果追踪与多步任务 | 不必从零教 JSON，但仍要验证特定工具和语言 |
| 接口/协议 | 每家格式不同，应用自行解析文本 | Function calling、JSON Schema、结构化输出和工具结果消息成为一等对象 | 适配成本下降，协议边界比提示词更重要 |
| 推理运行时 | 聊天模板、stop token、解析器常被忽略 | 运行时提供自动工具选择、模型专用 parser 与可观察的调用轨迹 | 模型能力能否兑现，取决于模板和 parser 是否匹配 |
| 代理工程 | 单次调用后直接执行 | 计划、执行、校验、重试、权限和人工确认组成闭环 | 成败越来越由系统可靠性决定，而非单轮“聪明程度” |
这也是为什么近来的产品公告看上去都在讲 agent、tool、computer use、MCP、结构化输出或 SDK。它们并非同一个概念，却都在补齐“模型会说”到“系统敢做”之间的断层。
二、从专用后缀到原生能力：发生了什么
1. 训练目标变了：不只学会回答，还要学会调用和恢复
早期工具调用往往是 few-shot 提示词加一段函数说明。模型输出一段文本，程序用正则或 JSON 解析器碰碰运气。它在 demo 中有效，在真实服务里却暴露出一串问题：函数名拼错、参数缺失、额外解释污染 JSON、工具报错后丢失上下文、遇到相近工具选择错误。
如今的主流路线是在训练数据和后训练阶段直接放入工具定义、调用消息、工具回包和后续推理轨迹。模型学习的不是一个静态“格式”，而是这样的状态转移：
用户目标
-> 判断是否需要外部能力
-> 选择最合适的工具
-> 生成受 schema 约束的参数
-> 阅读工具结果或错误
-> 继续调用、向用户澄清，或给出最终答案
这让模型在工具选择、参数补全、错误恢复和多轮状态保持上普遍更稳。注意“更稳”不是“正确”。模型仍然会在含义相近的工具之间误选，也会把不可信工具结果当成指令。因此，调用权限和结果可信度不能交给模型自行判断。
2. API 把工具作为消息类型，而不是提示词附件
OpenAI、Anthropic 和 Google 的官方接口文档都已将函数/工具声明、模型发起的调用、应用返回的工具结果，设计为对话协议中的显式对象，而非一段约定俗成的文本。OpenAI 的函数调用指南、Anthropic 的工具使用文档 与 Gemini 的 Function Calling 文档 都体现了这一方向。
这是比“多了一个 function_call 字段”更重要的进步。显式协议使应用可以：
- 校验参数是否符合 schema，再决定是否执行；
- 把工具错误作为结构化结果返回，让模型修正；
- 在审计日志中区分模型文本、模型请求、工具输入和工具输出；
- 对高风险操作插入审批，而不破坏对话状态。
这也解释了为什么“会输出 JSON”不再是充分条件。一个可部署的工具调用能力至少需要语义正确、结构可验证、轮次可继续、失败可恢复、权限可控制五件事。
3. 电脑操作从视觉问答变成闭环控制问题
浏览器或桌面 computer use 与函数调用有相同的外形：模型提出 action，环境返回 observation。但它更难，因为环境是部分可观测、异步、脆弱且带副作用的。
一个网页按钮可能因为加载延迟、弹窗、滚动位置、A/B 页面、登录态或验证码而改变。仅仅识别截图上的“提交”按钮并不等于安全完成任务。真正的提升来自模型对截图、页面语义和操作历史的联合处理，也来自运行时对每一步的截图回传、等待、断言、幂等性和人工接管。
因此应把 computer use 分为三档，而不要混为一谈：
| 能力档 | 典型输入/动作 | 适用场景 | 主要风险 |
|---|---|---|---|
| API 工具调用 | JSON 参数调用受控后端 API | 查询、报表、受限事务 | 参数或权限错误 |
| 浏览器语义自动化 | DOM/无障碍树加浏览器工具 | 内部稳定网站、测试、资料整理 | 页面漂移、登录态与越权 |
| 视觉桌面控制 | 截图、鼠标、键盘 | 无 API/无 DOM 的遗留系统 | 误点、不可逆提交、敏感信息暴露 |
工程上应遵循“能用确定性 API 就不用浏览器；能用浏览器语义层就不用纯视觉点击”。不是因为视觉模型没有价值，而是每向下一级，观测噪声、重试难度和审计成本都会陡增。
三、vLLM 场景：为什么模型已经更强，部署仍然会失败
对于本地或私有化服务，vLLM 现在提供了自动工具选择和模型专用 tool-call parser 等能力，但官方文档明确把 parser、聊天模板与所选模型绑定。vLLM Tool Calling 文档 中列出的支持路径，本质上说明：运行时不能凭空从任意权重的文本里可靠推断调用边界。
实际故障通常不在“模型没有 tool use”，而在以下接缝：
- 聊天模板不匹配。 同一个权重换了错误模板，特殊 token、工具定义的注入位置和工具结果格式都会失真。
- parser 不匹配。 模型可能生成了本族格式，服务端却按另一种标签或 JSON 包装解析；表现为不触发工具、参数为空或最终答案被截断。
- 协议能力被过度泛化。 OpenAI-compatible endpoint 的字段兼容，不表示约束解码、并行调用、严格 schema、工具选择策略都等价。
- schema 设计过宽。 把复杂业务对象完整暴露给模型，会让“参数合法”与“业务正确”之间留下巨大空隙。
- 只测 happy path。 一次天气查询成功，无法说明面对空结果、429、超时、权限拒绝、相近工具和中英文混合请求仍可靠。
Hugging Face 也把工具定义放入 chat template 的语义范围，而不是通用字符串拼接；这正是本地推理常被忽略的一层。Transformers Chat Templates 文档 可作为检查起点。
一个更实用的选型标准
不要问“这是不是 IT 模型”，而应建立下面这张验收表：
| 问题 | 可接受证据 |
|---|---|
| 模型是否原生支持工具？ | 模型卡/API 文档写明格式、限制与示例；而非社区口耳相传 |
| vLLM 是否有相应 parser 和推荐模板？ | 当前版本官方文档、启动参数和最小可复现请求 |
| 该模型会不会选对工具？ | 自建含相近工具、无需工具和拒绝执行案例的评测集 |
| 参数是否真的可用？ | schema 校验通过率，加上业务规则校验与人工抽样 |
| 工具失败后是否可恢复？ | 注入超时、空结果、权限拒绝、格式错误后的多轮测试 |
| 能否安全执行？ | 最小权限、allowlist、审批点、审计日志和幂等设计 |
其中前两项是“能连通”，后四项才接近“能上线”。
四、主流模型能力的比较：应比较什么，而不应比较什么
闭源前沿模型通常在长上下文、多工具协调、视觉理解、错误恢复和产品化接口上领先；开源模型则在数据边界、成本可控、可私有部署、可微调和延迟可控上更有优势。两者不是简单的智商高低，而是交付形态不同。
| 维度 | 托管前沿模型常见优势 | 开源/自部署常见优势 | 决策提示 |
|---|---|---|---|
| 单任务成功率 | 多步推理、模糊指令、复杂工具选择 | 可针对固定流程微调与约束 | 用真实任务成功率而非通用榜单决策 |
| 电脑操作 | 视觉理解、跨页面恢复、产品级安全提示 | 可在封闭环境训练和定制 | 高风险动作都需要外部确认 |
| 数据与合规 | 托管安全能力与快速迭代 | 数据不出域、日志与版本完全可控 | 先确定数据边界，再谈模型偏好 |
| 成本与延迟 | 免运维、按量弹性 | 高并发稳定负载下成本可预测 | 计算端到端成本：模型、工具、失败重试和人工复核 |
| 可控性 | API 演进快，但黑箱更多 | 模板、权重、解码和路由可控 | 生产系统要锁定版本并保留回归集 |
不应把“支持 function calling”与“适合自治执行”画等号。前者是接口/训练能力，后者是一个关于任务分解、环境确定性、权限设计、错误成本和监控能力的系统结论。
五、未来 12-24 个月：我认为最可能的五个方向
以下是判断，不是已被验证的事实。概率反映技术与产品方向的主观估计，条件比数字本身更重要。
1. 工具调用将成为基础模型的默认竞争项（高概率，约 85%）
它会像今天的多语言、长上下文和结构化输出一样，逐步从卖点变成基线。差异会转移到多工具编排、调用经济性、错误恢复、长程状态与权限感知。条件是模型供应商持续提供稳定协议，而不是频繁破坏调用语义。
2. “模型会调用什么”将让位于“系统允许它调用什么”（高概率，约 90%）
最有价值的护城河不只是一个更大的模型，而是高质量工具目录、语义清晰的 schema、可观测执行器、权限图谱、可回放的评测和业务数据。模型替换会更频繁，执行边界应更稳定。
3. MCP/类似协议会降低连接成本，但不会消灭集成治理（中高概率，约 75%）
统一协议能减少 N x M 适配，但它不解决工具描述是否准确、服务端是否可信、凭据如何隔离、结果是否含 prompt injection、动作是否需要审批。连接器越容易接入，供应链与权限治理越重要。
4. Computer use 会先在“低损失、可回滚、环境稳定”的任务里规模化（高概率，约 80%）
测试、数据录入草稿、资料检索、内部工单和受控后台将比付款、删库、生产变更、对外发送更早成熟。原因不只是模型能力，而是前者可以通过沙箱、回放和人工复核把错误成本压低。
5. 小模型与专用执行模型会重新重要（中高概率，约 70%）
昂贵前沿模型适合计划、例外和难例；轻量模型适合字段抽取、工具路由、分类、UI 元素定位和批量检查。未来更可能是分层路由，而不是让一个最大模型承担每个 token 和每次点击。
六、风险没有消失，只是从格式错误迁移到了系统错误
当模型只能聊天时，错误主要是幻觉；当它能调用工具时，错误会变成有副作用的动作。至少应防范四类风险：
- 提示注入与不可信工具输出。 网页、邮件、文档和搜索结果中的内容都可能试图改变代理目标。把外部内容标为不可信数据，不允许它直接升级权限或改变系统指令。
- 权限扩张。 不要把管理员 token 给“一个方便的万能工具”。拆分读/写/删权限，按动作设置允许列表和审批。
- 不可重放的失败。 为每次调用记录模型版本、提示版本、工具 schema、输入摘要、工具回包、批准人和最终动作；敏感字段做脱敏。
- 评测幻觉。 厂商 benchmark 往往不能代表你的 ERP、浏览器页面和中文业务术语。必须维护贴近真实失败模式的私有回归集。
一个很实用的原则是：把模型当作提出行动建议的策略，把执行器当作拥有最终否决权的控制平面。 模型不应该直接持有超出当前任务所需的权限。
七、给正在运行 vLLM 的团队：一条务实的迁移路线
如果现有系统已经依赖“专用后缀模型 + 自定义解析”，不建议因为新模型宣称原生 tool use 就整体推倒重来。更稳妥的顺序是：
- 冻结当前基线。 记录权重、revision、tokenizer/chat template、vLLM 版本、parser 参数和 30-100 条真实脱敏任务的结果。
- 先换协议适配，不先换业务执行器。 让新模型通过同一套 schema 校验、权限网关和审计日志；不要让模型升级隐含业务权限升级。
- 做分层评测。 分开统计工具选择准确率、参数 schema 通过率、业务规则通过率、任务完成率、平均轮次、P95 延迟和人工介入率。
- 故障注入。 对每个关键工具模拟超时、429、空列表、部分成功、拒绝权限和恶意文本回包；观察是否停止、重试、澄清或越权。
- 灰度路由。 先让新模型承担低风险读操作或作为候选策略，与旧模型并行比较；达标后再扩大范围。
- 保留降级路径。 当 parser、模板或新权重发生回归时，能在不改业务代码的情况下回切已验证的模型和配置。
这条路线的关键思想是把“模型升级”变成一个可回归测试的软件变更，而不是一次押注。
结语：从模型中心，走向行动系统中心
几个月前，为 vLLM 找到一个带特定后缀、能比较规整地吐出工具调用格式的模型，是合理的工程策略。现在，更多模型确实已经把工具调用、结构化输出和一定程度的电脑操作内化为原生能力，因而这件事不再需要那么多提示词魔法。
但真正成熟的标志，不是模型在演示里点对一次按钮，而是系统能在权限受限、工具失败、网页变化、输入不可信和错误代价真实存在时，仍然可控、可审计、可回退地完成工作。
下一阶段最值得投入的，不是追逐每个新后缀，而是建立自己的工具契约、执行网关、任务评测集和灰度机制。模型会继续快速变化；这些资产才会沉淀为组织能力。
参考资料
- vLLM: Tool Calling（检索于 2026-08-04）
- OpenAI API: Function Calling（检索于 2026-08-04）
- Anthropic Docs: Tool Use Overview（检索于 2026-08-04）
- Google AI for Developers: Gemini Function Calling（检索于 2026-08-04）
- Hugging Face Transformers: Chat Templates（检索于 2026-08-04）
