从零构建 AI 决策模型：让 Agent 把算力花在真正复杂的地方

截至 2026 年 10 月 11 日，AI Agent 的竞争重点正在从“能不能调用工具”转向“每一步到底该不该调用、调用哪个工具、什么时候停止”。这类问题并不需要模型写一篇长答案，却会在一次任务里重复出现几十甚至上百次。

**Decision Model 是一种只在预定义选项中做选择的模型，输出通常是类别、分数或排序结果，而不是开放式文本。**例如，在“是否需要联网搜索”“选择哪个检索器”“当前实验是否值得继续”“这封邮件属于投诉还是咨询”等任务中，模型只需从有限候选集中选出一个结果。

这类模型的价值很直接：它通常比通用大语言模型更快、更便宜、更容易约束，也更容易测量错误率。但它不是万能的“缩小版大模型”。它适合高频、候选集明确、需要稳定执行的判断，不适合开放式规划、复杂推理和需要解释大量背景的任务。

为什么现在需要 Decision Model

**Agent 的瓶颈正在从单次生成质量转向连续决策的累计成本。**一个看似简单的自动研究任务，可能包含这些判断：选择搜索关键词、判断网页是否相关、决定是否继续抓取、挑选下一步实验、判断当前结果是否足够、决定是否终止路线。

如果每个判断都交给 GPT、Claude 或其他推理模型，问题不只在价格。长上下文会增加延迟，开放式输出需要额外解析，偶发的格式错误会打断工作流，模型还可能在本来只有三个选项的问题上生成一段没有必要的解释。

假设一个 Agent 任务需要 40 个离散判断，每次调用通用模型平均耗时 800 毫秒，那么仅决策环节就要消耗约 32 秒。如果专用模型将单次判断压缩到 20 毫秒，总延迟可以降到约 0.8 秒，理论降幅达到 97.5%。实际系统还会受到网络、排队、工具执行和上下文准备影响，但决策模型带来的收益仍然清晰。

近期公开讨论中，Jev、StartLux-Decision 等项目都把重点放在类似方向：让复杂模型负责建立上下文和制定高层计划，让更小的分类模型接管重复选择。StartLux 公布的测试显示，在单卡 H200、BF16、本地 HTTP 和短请求条件下，其 Decision-4B 对三个问题的平均耗时约为 26 毫秒，2B 和 0.8B 版本分别约为 15.5 毫秒和 12.2 毫秒。这里的数字不能直接等同于所有部署环境的端到端延迟，但说明专用模型的优化空间确实比“每一步都调用大模型”更大。

先定义问题：不要把规则引擎包装成模型

**构建决策模型的第一步不是选底座，而是确认这个问题是否值得用模型解决。**如果判断条件完全明确，例如“金额大于 5000 元就转人工”，代码和规则引擎通常更可靠；如果候选项只有固定关键词匹配，Embedding 或普通分类器就足够；只有当输入具有自然语言变化、规则难以穷举，同时输出空间仍然有限时，Decision Model 才真正有意义。

一个合格的决策任务至少要明确四件事：

1. 输入是什么：用户问题、Agent 当前状态、工具返回结果，还是一组实验指标。
2. 输出有哪些：候选标签必须尽量封闭，不能让模型自由发明第五个选项。
3. 错误代价是什么：误判为“无需人工”通常比误判为“需要人工”更危险。
4. 何时拒答：模型不确定时，是选择默认策略、返回 unknown，还是升级给通用模型。

以客服分流为例，输出可以定义为 refund、technical_support、billing、human_review 四类。不要一开始就让模型输出“请将用户转接给负责账单问题的人工客服”这样的自然语言。对于 Agent 来说，标签本身就是动作，越短越稳定。

一个可落地的模型架构

实用的 Decision Model 通常由状态构造、决策模型和策略执行三层组成。

第一层是状态构造器。它把分散的信息压缩成模型能理解的输入，例如当前用户意图、历史动作、工具结果、剩余预算和失败次数。状态构造器可以由代码完成，也可以由通用大模型负责。

第二层是决策模型。它只处理一个窄问题，例如从 search_web、query_database、ask_user、stop 四个动作中选择一个。输入格式应尽量稳定，候选标签也应固定。

第三层是执行策略。它不应该把模型输出直接当作事实，而是先检查权限、参数和业务约束，再执行对应动作。例如模型选择了退款流程，系统仍然要验证订单状态和退款金额。

一个典型工作流如下：

用户请求
  -> 通用模型提取任务状态
  -> Decision Model 选择下一步动作
  -> 策略层校验动作是否合法
  -> 工具执行
  -> 更新状态并再次决策

这里最关键的设计是“模型只决定它擅长的那一小段”。让 Decision Model 同时负责理解用户、制定计划、调用工具和生成回复，最后通常会得到一个既不稳定又难以评测的系统。

从零开始做第一版：先用传统分类器建立基线

**第一版决策模型不需要直接训练一个数十亿参数的 Transformer，TF-IDF 加逻辑回归就是很有价值的基线。**它训练快、推理快、容易解释，可以帮助团队先确认标签设计和数据质量是否成立。

训练数据可以采用 JSONL，每行包含一条输入和一个标签：

{"text":"用户说信用卡已经扣款，但后台订单仍显示待支付","label":"billing"}
{"text":"应用打开后一直白屏，重装后问题仍然存在","label":"technical_support"}
{"text":"用户要求撤销昨天购买的年度套餐","label":"refund"}
{"text":"用户描述不清，且涉及高风险账户操作","label":"human_review"}

下面是一段本地训练基线的示例。它不是 API 调用，而是使用公开 Python 库在本地完成文本分类：

from sklearn.pipeline import Pipeline
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

texts = [
    "信用卡扣款但订单仍然待支付",
    "应用打开后一直白屏",
    "我想撤销昨天购买的套餐",
    "这个账户操作风险太高，请人工处理",
]
labels = ["billing", "technical_support", "refund", "human_review"]

x_train, x_test, y_train, y_test = train_test_split(
    texts, labels, test_size=0.25, random_state=42, stratify=labels
)

model = Pipeline([
    ("tfidf", TfidfVectorizer(ngram_range=(1, 2), min_df=1)),
    ("classifier", LogisticRegression(max_iter=1000, class_weight="balanced")),
])

model.fit(x_train, y_train)
print(classification_report(y_test, model.predict(x_test)))

这段代码的意义不在于直接用于生产，而在于暴露问题：标签是否互斥，样本是否覆盖真实表达，某些类别是否天然难以区分，以及“人工复核”是不是被错误地当成万能兜底。

数据构造比模型大小更重要

**Decision Model 的上限通常由标签体系和负样本质量决定，而不是由参数量单独决定。**如果训练数据只包含标准书面表达，模型上线后遇到口语、错别字、混合语言和不完整上下文，准确率会迅速下降。

数据至少应覆盖以下几类样本：

• 正常样本：清晰表达单一意图。
• 边界样本：两个类别语义接近，必须依赖上下文判断。
• 对抗样本：故意包含误导词、否定词或无关信息。
• 缺失信息样本：输入不足以做出可靠判断。
• 多意图样本：一句话同时包含退款和技术问题。
• 分布外样本：训练集中没有出现过的新表达或新业务。

建议把“无法判断”单独设为 unknown 或 human_review，不要强迫模型在错误选项里猜一个。一个分类器即使准确率达到 95%，如果剩下的 5% 恰好集中在高风险场景，也不能直接上线。

数据划分也不能只做随机切分。更可靠的方法是按时间、用户、业务版本或来源切分测试集，避免同一模板的轻微改写同时出现在训练集和测试集中。对于 Agent 决策，还应保留完整轨迹：当时的状态、候选动作、最终动作、执行结果和人工修正。只记录输入和标签，无法判断模型为什么错。

两条训练路线：分类器与结构化输出

构建 Decision Model 主要有两条路线：训练专用分类器，或者先用通用模型通过结构化输出模拟决策行为。

第一条路线适合高频、低延迟、候选集稳定的任务。可以从 DeBERTa、ModernBERT、BERT 类编码器开始，也可以使用规模更小的语言模型，再通过 LoRA、全量微调或知识蒸馏训练。输出层通常是一个分类头，直接生成每个标签的 logits。

第二条路线适合需求还在变化、样本不足或需要快速验证的阶段。给通用模型一组明确的标签枚举，让它只能输出固定结构，再记录人工修正结果。等数据积累到足够规模后，可以将这些轨迹清洗成训练集，蒸馏到更小的专用模型中。

这两条路线不是互斥关系。工程上更合理的顺序通常是：先用结构化输出建立基线，再观察调用量和错误类型，最后决定是否值得训练专用模型。为了省几百毫秒而训练模型，可能得不偿失；但当同一个判断每天执行数百万次时，专用模型的收益会快速放大。

不要只看 Accuracy：校准比“猜得准”更重要

**模型校准是指模型输出的置信度是否与真实正确率匹配。**如果一批样本的预测置信度都约为 0.8，那么其中大约 80% 正确，说明模型的置信度具有参考价值；如果实际正确率只有 55%，模型就是过度自信。

决策系统尤其需要校准，因为置信度往往决定是否升级给大模型或人工。常见指标包括：

• Accuracy：整体预测正确率。
• Macro-F1：各类别 F1 的平均值，适合类别不平衡场景。
• Precision：预测为某类别的样本中，有多少真的属于该类别。
• Recall：真实属于某类别的样本中，有多少被找出来。
• ECE：Expected Calibration Error，用于衡量置信度和真实正确率之间的偏差。
• Selective Accuracy：只保留高置信度预测时的准确率。

例如，模型在 90% 的请求上给出高置信度答案，准确率达到 98%，剩余 10% 交给更强模型处理，这往往比强迫模型覆盖 100% 请求更可靠。决策模型的目标不是“所有问题都自己答”，而是在明确边界内稳定工作。

上线前至少应该绘制混淆矩阵和置信度分桶图，并单独统计高风险类别。必要时可使用温度缩放等方法进行后校准，但不能把校准当成数据质量问题的替代品。

延迟、吞吐和成本怎么测

**Decision Model 的性能评测必须同时记录准确率、P95 延迟、吞吐量和单位成本。**只报告平均延迟会掩盖排队、冷启动和长尾请求；只报告跑分也无法说明它在真实 Agent 中是否有用。

建议至少做三组测试：

| 方案 | 适用阶段 | 输出控制 | 典型优势 | 主要问题 | |---|---|---|---|---| | 规则引擎 | 规则明确 | 极强 | 延迟低、可解释 | 难处理自然语言变化 | | 通用大模型结构化输出 | 快速验证 | 较强 | 迁移快、少训练数据 | 成本和延迟较高 | | 专用 Decision Model | 高频生产任务 | 强 | 低延迟、低成本、易批处理 | 需要持续维护数据 |

第一组测试是单请求延迟，分别记录 P50、P95 和 P99。第二组测试是并发吞吐，观察批处理、量化和动态批处理是否改变准确率。第三组测试是端到端 Agent 轨迹，统计每个任务的总耗时、决策次数、错误重试次数和最终成功率。

StartLux 公布的毫秒级数据采用了 H200、BF16、本地 HTTP 等特定条件，不能直接作为消费级显卡或云端部署的保证。对于实际项目，应在目标硬件上复测，并把序列化、网络、队列、模型加载和策略校验全部算入总耗时。

上线时必须保留“升级通道”

**一个可用的决策系统必须允许模型在不确定时把问题交给更强的模型或人工。**常见策略包括置信度阈值、类别专属阈值、风险规则和连续失败熔断。

例如：

如果 max_probability >= 0.92 且不属于高风险类别：直接执行
如果 0.65 <= max_probability < 0.92：交给通用模型复核
如果 max_probability < 0.65：请求补充信息或转人工
如果连续两次执行失败：停止自动重试并记录轨迹

阈值不能凭经验拍脑袋。它应该根据误判成本、人工处理成本和任务成功率进行选择。对于退款、权限修改、删除数据等不可逆动作，宁可牺牲一部分自动化率，也要提高精确率和人工复核比例。

此外，模型版本、标签版本、候选动作版本和策略版本都要可追踪。标签从 technical_support 拆成 login_failure 和 runtime_error 后，旧模型的输出不能直接与新指标混在一起，否则线上评估会失真。

哪些任务适合，哪些任务不适合

**Decision Model 最适合候选集有限、调用频率高、错误边界清晰的判断。**例如语义路由、工具选择、内容审核分层、实验优先级排序、自动研究中的下一步动作选择、客服分流和是否升级人工。

它不适合以下情况：

• 候选答案经常变化，标签体系还没有稳定下来。
• 判断需要长链条推理，且无法压缩成有限状态。
• 输入包含大量新知识，模型必须实时检索才能判断。
• 错误代价极高，但又没有可靠的人工兜底。
• 团队没有持续收集线上失败样本的能力。

最常见的误区，是把 Decision Model 当成“更便宜的大模型”，然后让它承担所有复杂任务。正确理解应该是：它是 Agent 架构中的一个零件，负责把高频选择从昂贵的通用推理中拆出来。

最终建议：先做一个窄模型，再扩大边界

截至 2026 年 10 月，Decision Model 仍处于快速演进阶段，公开榜单和项目名称变化很快，模型许可证、训练数据来源和真实线上表现也需要逐项核验。对于开发者来说，最稳妥的路径不是追逐某个排行榜第一，而是围绕自己的 Agent 轨迹建立评测集。

可以按以下顺序推进：

1. 用规则和通用模型定义一个不超过 5 个选项的窄任务。
2. 收集至少数千条真实输入，并补齐边界样本、拒答样本和高风险样本。
3. 用 TF-IDF 分类器建立基线，确认标签体系确实有效。
4. 再尝试小型编码器、量化模型或蒸馏模型，比较准确率、校准和 P95 延迟。
5. 设置置信度阈值，把不确定样本交给更强模型或人工。
6. 在线上记录完整决策轨迹，每周用失败样本更新评测集。

**真正值得部署的 Decision Model，不是参数最小的模型，而是在明确边界内做出稳定选择、知道什么时候应该退让的模型。**当 Agent 由“一个大模型包打天下”转向“多个专用组件协同工作”，决策模型会成为其中一个越来越重要的基础模块。