AI 代理应调用模型

MLAT 论文描述了一个生产试点：代理将 XGBoost 定价模型作为工具调用，在留出数据上达到 R^2 = 0.807，平均绝对误差为 3688 USD，并将方案生成时间从数小时缩短到不到 10 分钟。¹

真正有价值的不是那个具体的定价模型，而是边界本身：当任务需要评分、预测、价格、风险估计、排序、分类器或检测器时，代理应调用为该任务训练的模型，而不是用流畅的文字临场编造统计答案。

训练好的模型应进入代理工具注册表。LLM 可以决定何时调用它、解释结果、询问缺失输入并路由异常。拟合后的模型则应产出数值估计、置信度信号、带版本的输出以及证据轨迹。

摘要

LLM 代理擅长编排。统计模型和机器学习模型往往更适合边界清晰的预测。Machine Learning as a Tool 模式将拟合后的 ML 模型视为代理工作流中的可调用工具，与搜索、数据库、API 和其他工具并列。¹

这一模式为团队提供了一条清晰的运行规则：让代理协调工作，但让专用模型完成专用推断。结果应包含模型版本、输入模式、输出模式、校准说明以及可追踪的调用记录。缺少这条边界，LLM 可能听起来笃定，却在暗中用猜测替代模型。

要点

• 对于代理构建者：将训练好的模型暴露为带类型的工具，并提供模式、版本和失败模式。
• 对于 ML 团队：把代理视为调用方，而不是模型评估、持久化或注册表规范的替代品。
• 对于产品团队：展示某个数字究竟来自模型调用、规则、数据库，还是 LLM 解释。
• 对于安全团队：将代理密钥需要风险预算中的作用域权限逻辑同样用于模型工具。
• 对于评审者：在信任答案之前，要求查看模型调用、模型版本、输入、输出和置信边界。

为什么代理应调用模型，而不是模仿模型？

LLM 可以讨论价格。定价模型可以根据它学习过的特征估算价格。LLM 可以概述风险。风险模型可以基于经过测试的特征集给风险打分。LLM 可以描述流失。流失模型可以返回与训练流程相关联的概率。

这些是不同的工作。

代理工具已经让这种分工成为可能。OpenAI 的 Agents SDK 文档介绍了带 JSON Schema 参数的函数工具、工具调用处理器以及结构化工具输出。²Anthropic 的工具使用文档描述了 Claude 如何通过 JSON Schema 输入调用客户端工具和外部函数。³代理可以像使用搜索、日历更新、shell 命令或数据库查询一样，通过同一种工具模式请求模型预测。

核心失败模式出现在团队跳过这种分工时。他们向 LLM 索要估算值，因为 LLM 确实能给出一个。答案来得很快。文字看上去也合理。界面却没有任何明显线索表明，这个数字来自模式补全，而不是拟合后的估计器。

这是一份薄弱的契约。用户不知道结果由什么产生。评审者无法检查模型版本或输入特征。运维人员无法重放调用。产品也无法解释答案为何发生变化。

证据关口在这里同样适用：信心不是证据。模型调用可以产生证据。文字猜测通常不行。

MLAT 模式增加了什么？

MLAT 代表 Machine Learning as a Tool。论文将训练好的 ML 模型定义为一等工具，供 LLM 代理在对话需要定量估计时调用。¹

论文中的试点系统 PitchCraft 使用了两个代理。研究代理通过并行工具调用收集潜在客户上下文。草稿代理调用 XGBoost 定价模型，然后通过结构化输出撰写方案。¹ML 模型负责定价。LLM 负责上下文、组装和解释。

这种分工很重要，因为它避免了两种糟糕设计：

代理仍然重要。它可以判断定价输入是否不完整。它可以向用户询问缺失字段。它可以先调用搜索或 CRM 工具，再调用模型。它可以说明估算来自模型，而不是来自自己的权威。

这才是合理分工：LLM 负责编排；拟合模型负责预测。

模型工具应返回什么？

模型工具不应只返回一个裸数字。严肃的模型工具应返回一个证据对象。

这种输出形态让模型工具能够与代理执行追踪是执行环境契约兼容。如果代理调用了定价模型，追踪应显示该模型调用。如果代理跳过模型却仍然写出一个数字，追踪也应让这种缺失一目了然。

同样的逻辑也支撑评审包是新的最终答案。只包含价格的最终答案很薄弱。包含模型调用记录、模型版本、特征快照和置信说明的最终答案，才给了评审者可以检查的东西。

模型注册表放在哪里？

工具封装并不能替代 MLOps。它是把 MLOps 暴露给代理执行环境。

MLflow 的模型注册表文档描述了模型的血缘、版本控制、别名、元数据标签以及生命周期信息。⁴这一注册层很关键，因为只有平台先跟踪模型版本，代理工作流才有可能引用某个模型版本。

Scikit-learn 的模型持久化文档从服务侧提出了相关观点：持久化选择会带来安全性和可移植性取舍；ONNX 可以在没有 Python 环境的情况下服务模型，而基于 pickle 的路径要求信任来源。⁵模型工具不应仅仅因为代理请求预测，就把不安全的模型工件偷偷塞进代理。

最低限度的运行栈如下：

团队常常把这些层压缩成一个名为 predict 的端点。这个捷径适合演示。一旦代理开始把预测串联进客户邮件、销售方案、承保备注、基础设施计划或医疗分诊草稿，它就会失效。

产品需要的是模型契约，而不是魔法端点。

产品应如何展示模型输出？

UI 应告诉用户，某个答案何时来自模型工具。

糟糕的界面文案会隐藏来源：

更好的文案会说明生产路径：

这种区分保护用户尊严。用户不应被迫猜测一个数字究竟来自经过测试的模型、模型卡、业务规则，还是语言模型补全。代理式设计是控制界面设计认为，代理产品需要用于监督和控制的界面。模型来源就是其中之一。

模型卡在文档层也有助于解决同一问题。Model Cards 论文提出了围绕模型特征、预期用途、指标和评估上下文的结构化报告。⁶代理界面可以在执行环境中借鉴这一思路：每个模型答案都应携带足够上下文，让用户或评审者理解模型提出的是哪类主张。

代理应拒绝什么？

具备模型意识的代理应拒绝几种诱人的捷径。

当模型工具不可用时，它应拒绝编造模型输出。它可以说明定价模型失败。它可以询问用户是否需要一个粗略的人工标注估计。但它不应悄悄替代模型。

它应拒绝在没有证据的情况下扩大模型适用域。一个基于中端市场 SaaS 数据训练的流失模型，不应因为提示词写得客气，就变成通用的企业健康度预言机。

它应拒绝隐藏不确定性。如果模型返回区间，答案不应在没有明确产品展示规则的情况下，把区间压缩成单个自信数字。

它应拒绝使用缺失或伪造的特征调用模型工具。代理可以收集输入、提出追问，或将字段标记为未知。但它不应为了方便，用虚构内容填充特征向量。

它应拒绝把模型权威等同于行动权限。模型可以估计欺诈风险。但这并不意味着代理可以冻结账户。行动仍然需要代理密钥需要风险预算中的作用域密钥规范。

决策规则

构建代理工作流时使用这条规则：

这条规则给了 LLM 一份有价值的工作，同时不允许它冒充所有其他系统。它可以协调工作流、解释输出、起草消息，并提出更好的问题。但它不能只凭流畅表达，就变成定价模型、风险模型、欺诈模型、排序模型或策略引擎。

最好的代理产品不会要求一个模型假装自己是整家公司。它们会构建一个工具界面，让每个系统完成自己能够证明的工作。

FAQ

这只适用于传统机器学习模型吗？

不是。同一模式适用于任何专用估计器或评分器：梯度提升模型、分类器、排序系统、预测模型、规则引擎、检索评分器以及领域专用检测器。重点不是算法，而是围绕输出建立的契约。

为什么不让 LLM 直接估算？

有时，粗略的定性估计是可以接受的。产品应明确说明这一点。当用户需要价格、风险评分、预测或资格决策时，答案应来自经过测试的模型或规则路径，并带有可追踪输入和限制。

模型工具会让答案自动正确吗？

不会。模型工具仍可能过期、有偏、校准不佳、被误用，或超出其有效适用域。模型工具提升的是可检查性。它并不会取消评估、监控和人工评审的必要性。

最小可行的模型工具契约是什么？

从输入模式、输出模式、模型版本、预测、置信度或注意事项、错误形态、超时和追踪 ID 开始。当模型影响金钱、访问权限、安全或面向客户的决策时，再加入特征名称、注册表链接、模型卡引用和校准说明。

这会如何改变代理 UX？

界面应标注重要输出的来源。用户应能看到答案来自模型调用、检索到的文档、业务规则、人工审批，还是 LLM 综合。这个来源信息会改变答案值得被信任的程度。

参考资料