1. 决策模型在AI Agent中的角色以及NeoHorse-Jev-4B为什么要对标Jev最近做Agent工具链优化时发现一个有意思的现象大家开始区分“大而全的模型”和“小而专的模型”了。通用大模型擅长对话和内容生成但在任务规划、工具调用、结果校验这些决策密集型场景里反而容易出现“能力溢出”的问题——不是它不会而是它在做决策时想得太多有时候会想偏。于是行业内开始出现一批专门做决策的模型Jev就是其中之一。它的定位非常明确让模型在特定规则下做快速、稳定、可约束的决策而不是自由发挥。我最近业余时间在折腾一个对标项目模型名暂定为NeoHorse-Jev-4B。核心目标就三个字学Jev。不是抄权重而是复现它的决策链路设计思路把决策模型这个细分方向吃透。Jev在圈子里受欢迎我觉得有几个点抓得很好。一是它的体量定位很聪明不追求超大参数而是把精力放在决策链路的稳定性和可控性上。二是它火了之后社区陆续把Jev接入了Codex、Claude Code这些编程智能体专门用来做工具调用规划、任务拆解和步骤校验。三是Gitee和GitHub上大量项目在讨论如何用Jev做嵌入式决策也就是把决策能力嵌到业务系统里。这几个点叠加在一起让“决策模型”从一个被大模型顺带覆盖的能力变成了一个独立的技术赛道。NeoHorse-Jev-4B这个名字NeoHorse是我个人项目系列的代号Jev是对标对象4B是指模型参数规模在40亿左右。选择4B这个体量是有意为之决策任务不像创作任务那样需要海量知识储备它更需要的是精确的规则理解、结构化的输出能力和快速的推理响应。换句话说如果你把决策模型做得太大推理成本上去了响应速度下来了反而违背了“轻量决策”这个初衷。4B左右的规模在消费级显卡和CPU推理环境下都能跑同时对量化也比较友好这个平衡点选得比较务实。我自己在做的是开源方向整个方案基于常见的开源模型底座继续做指令微调和决策链路优化。目标场景是智能体调用工具时的动作选择、多步任务拆解、以及前后步骤的一致性校验。这东西做好了小到自动化测试用例选择大到业务系统里的风控决策都能插一脚。这里要说明一个关键认知决策模型不是替代通用大模型而是跟它分工。通用大模型负责理解语言、生成内容、处理开放性问题决策模型负责在限定规则空间内做选择。举个例子你让通用模型写一段代码它是创作你让决策模型判断“这段代码应该调用A接口还是B接口”它是决策。后者需要的是对约束条件的精确理解而不是发散联想。所以决策模型的训练目标、数据组织方式和评估维度跟通用模型是有本质区别的。Jev在这个方向上的设计相当于给后来者画了一条参考线。NeoHorse-Jev-4B要做的就是对标这条线做出一套可复现、可扩展、可落地的开源实现。这篇文章我会把整个思路拆开讲清楚决策模型的核心原理、训练数据怎么组织、部署和对接工具链的实操过程、以及我在这个过程中踩过的坑和总结的经验。对这块感兴趣的朋友尤其是做Agent工程化、工具调用优化、嵌入式决策方案的朋友应该能从中找到一些可以直接拿去用的东西。2. 决策模型核心原理拆解为什么通用模型做不好纯决策2.1 决策任务的本质是约束条件下的选择决策任务的本质可以拆成一句话给定当前状态和目标从有限的动作空间中选出一个最优动作。这里面的关键词是“有限”。跟开放域生成不同决策任务的输出空间是受限的往往是“从预定义的动作列表里选一个”或者是“判断当前状态是否满足某个执行条件”。这种任务不需要模型有很强的发散能力反而需要它有很强的约束意识。2.2 通用语言模型在决策场景中的典型失效模式通用语言模型的失效模式主要是三种一是过度生成。你问它“当前这个函数返回错误接下来应该如何处理”它给你输出一大段分析从可能的原因到修复建议甚至把代码都重写了。但对一个决策系统来说我需要的是“调用日志模块记录错误然后重试一次如果失败则进入降级流程”——结构化的、有限的选择。过度生成引入大量不确定性下游系统在处理这些自由文本时很容易解析失败。二是上下文漂移。大模型在长对话中容易把前面的约束条件“忘掉”。决策任务通常需要严格遵循用户一开始定义的动作空间但模型生成过程中可能因为“联想”跑偏输出了动作空间之外的选项。这在Agent系统里是很致命的因为你给Agent定义的工具列表是固定的它输出一个不存在的工具名整个调用链就崩了。三是一致性差。同一个决策问题稍微换个问法模型可能给出完全不同的选择。原因是通用模型没有被“规则约束”训练过它的决策更多依赖语料里的统计规律而不是对规则的真正理解。决策模型要做的事情就是把这个“规则约力”内化到参数里让模型在相同约束条件下对相同状态给出稳定一致的决策结果。2.3 决策模型的数据范式状态-约束-动作三元组Jev这类决策模型训练数据的组织方式围绕一个核心思路就是状态-约束-动作三元组。状态当前的系统状态可以是自然语言描述也可以是结构化JSON。比如“当前内存使用率超过80%”。约束决策必须遵循的规则比如“不可重启服务”、“只能在降级和限流中选择其一”。动作在约束条件下做出的选择比如“触发限流”。这三个维度组织成一条训练样本模型要学的不是“状态是什么”这个事实而是“在给定约束下应该选什么动作”这个映射关系。这跟通用模型学“语言规律”有本质区别它学的是决策策略。NeoHorse-Jev-4B在训练数据的构造上我是按照这个三元组框架来做的。每条样本都包含这三个部分并且在约束维度上做了大量的“负样本”设计——即故意给出一些容易产生歧义的约束组合模型必须正确区分“可做”和“不可做”。这个设计也是从Jev的思路里学到的决策模型最有价值的训练数据不是那些显而易见的常识决策而是边界案例。2.4 结构化输出能力是决策模型的命门决策模型还有一个容易被人忽略的重点就是结构化输出能力。Jev在对标实现里对输出格式的控制做得很严格。它会让模型输出JSON格式的动作选择结果字段固定、枚举值固定、不允许多余内容。表面上看这只是格式要求但底层其实是在训练模型“在有限输出空间里做选择”的能力。我自己在实现中也是这么做的。训练阶段所有样本的答案格式严格统一比如{ action: trigger_rate_limiting, params: {limit: 100}, confidence: 0.9 }模型如果输出格式不符合要求训练损失直接惩罚推理阶段配合约束解码逻辑把输出强制约束在合法动作空间内。双保险之下结构化输出的稳定性才有保障。这里值得多说一句决策模型的“推理”不是做数学题而是在约束树上做路径选择。所谓决策推理就是模型在状态空间和动作空间之间建立起有效的映射。这个映射越干净模型的决策能力越强。通用模型为什么在决策场景不稳定因为它的映射空间被海量语料污染了同一状态可能对应无数种可能的后续文本它不知道哪个才是你期望的“决策动作”。决策模型通过微调和数据构造把那些无关的映射路径裁剪掉留下一条清晰的决策通路。这就是为什么决策模型参数不需要很大的原因——它是一个被“精修”过的专用工具不需要保留那么多泛化能力。3. 训练数据构造与微调策略3.1 领域数据收集从哪里找到决策训练语料这是做决策模型最苦的环节。通用模型训练数据好办网上大把文本可以抓决策模型的训练数据必须有明确的“状态-约束-动作”结构这种数据在自然文本里很少见需要自己构造。我当时整理了三类来源第一类是开源Agent轨迹数据。GitHub上一些Agent框架项目会附带工具调用日志包含了“观察到什么状态、决定调用什么工具、结果如何”的完整轨迹。这类数据质量高但数量有限需要清洗和重排。第二类是人工构造的决策场景数据。围绕几个核心场景系统运维决策、代码调用决策、业务规则决策用模板批量生成状态描述和约束组合再人工标注动作。这个效率不高但质量可控是训练数据的“压舱石”。第三类是从通用数据集中筛选转换。比如GSM8K数学题、BBH基准里的某些任务虽然本身不是决策任务但含有“从多个解法中选一个”的逻辑可以通过改写转换成决策样本。这个转换过程比较费人工但是能帮助模型建立更丰富的决策语义。3.2 样本构造的核心设计正交化与边界覆盖决策模型的样本构造有个关键原则我把它叫做“正交化”。简单说就是每个约束条件、每个状态特征都必须在足够多的样本里独立出现、交叉出现。这样做的好处是模型能够学到每个变量对决策结果的影响而不是把某个决策结果错误地归因到某个无关特征上。举个例子如果你想训练一个“服务降级决策”的模型状态特征有“CPU使用率”和“请求错误率”约束条件有“不可重启”和“保持核心服务可用”。那么训练数据的构造要让这四个特征两两组合、三三组合覆盖所有业务上可能出现的情况。仅仅覆盖“CPU高不可重启→限流”这种常见路径是不够的还得覆盖“CPU正常错误率高保持核心服务可用→降级非核心服务”这种边界路径。边界路径看似少见但恰恰是模型最容易判断错误的地方。我在构造样本时专门为边界场景建了一个样本池覆盖大概20多类边界条件包括双重约束冲突、约束与状态矛盾、动作空间外部选项、状态信息缺失等。这些样本在总数据中的占比大约15%到20%但对模型决策质量的提升贡献非常大。3.3 指令模板设计约束条件必须显式化决策模型的指令模板跟通用模型的指令模板差别很大。通用模型的指令强调“说明任务、给出上下文、要求输出”决策模型必须在此基础上把约束条件显式化并且要放在一个固定的位置。我这里的模板设计大致如下当前状态 {状态信息格式为JSON或结构化文本} 约束条件 - {约束1} - {约束2} - {约束3} 可选动作 - action_a: {描述} - action_b: {描述} - action_c: {描述} 请根据当前状态和约束条件从可选动作中选择一个动作并输出JSON格式结果。这个模板看起来简单但里面的门道不少。约束条件放在状态之后、动作之前是为了让模型的注意力集中在“约束”和“动作”的对应关系上。可选动作必须是有限列表每一项的描述要准确。如果动作描述太模糊模型很容易产生歧义。另外模板中禁止出现“如果你认为、请合理选择”这类开放性表述决策模型的样本和指令都必须把所有自由度锁死。3.4 微调训练策略LoRA vs 全参微调在4B规模的模型上进行微调方法上可以选择LoRA或全参微调。我实践下来两者的性价比差别很大。LoRA的优势是省资源、迭代快。一张24G显存的消费级显卡就能跑4B模型的LoRA微调用QLoRA甚至可以在16G显存上运行。缺点是对决策任务来说可学习的参数太少模型对“规则内化”的深度可能不够。决策能力跟对话能力不同它需要模型在深层参数上建立起状态到动作的稳定映射LoRA的低秩更新有时候表达不了这么复杂的映射。全参微调对显存的要求高一些4B模型的全参微调至少需要40G以上显存才能稳定跑但对决策质量的提升是实打实的。我在实践过程中采用的是“两阶段混合策略”先用LoRA做快速实验验证数据构造和模板设计是否合理等数据稳定之后再用全参微调训练最终版本。这个小流程帮我省了很多试错时间——LoRA一个训练周期大概几小时全参微调动辄一两天用LoRA先验一轮数据质量然后再上全参数是最务实的路径。3.5 决策模型评估离线指标与在线检验评估决策模型不能只盯着Loss下降。Loss下降了不代表决策准确率上升更不代表部署后行为稳定。我做了一套评估流程三个层次第一层是动作准确率。给定测试集看模型选对动作的百分比这个最直接可以快速验收每次微调的效果。第二层是约束遵循率。这个指标专门检测模型是否违反约束条件。比如约束里写了“禁止重启服务”模型如果输出了重启动作就算决策准确率再高这条也算失败。约束遵循率这个指标的重要性有时候高过动作准确率因为违反约束的决策比选错动作更危险。第三层是输出格式合规率。模型输出的是不是严格的JSON、字段是否齐全、枚举是否在定义范围内。这个指标是工程化部署的基础模型如果连格式都保障不了下游Agent系统根本没法解析。我跑微调实验时三个指标分开记录、分开分析。动作准确率低说明状态映射学习不到位约束遵循率低说明负样本不够或者约束位置不突出格式合规率低说明模板和约束解码有问题。各有各的解法混在一起看是看不出病灶的。4. 实操过程与核心环节实现4.1 环境准备与模型底座选择先讲环境。我用的方案是基于Docker的一体化环境好处是隔离干净、可复现换机器不用重新配环境。硬件层面训练阶段使用的是一张24G显存的消费级显卡配合全参微调之外的LoRA快速验证。最终的全参微调跑在两张24G显卡上。推理阶段则宽松得多CPU环境配合量化后的模型也能跑出可用的速度这一点后面细说。模型底座的选型上我的原则是“原生代码能力优先”。决策任务虽然不等同于代码生成但训练和推理过程中大量涉及到JSON、结构化文本和函数调用语义的处理。基于这些经验我选择的开源底座是CodeQwen1.5-4B。选它的原因有两点一是这个体量跟目标参数规模刚好吻合不用再做层裁剪二是它在工具调用和结构化输出方面的基础能力比较扎实省去了我在底座阶段的大量适配工作。如果你手头有其他偏好也可以参考同思路的模型但尽量别用太大的底座也不要用纯对话模型。软件环境方面训练框架用的是PyTorch加HuggingFace生态的标准组合。部署阶段还在用vLLM做统一推理服务后面接入Codex和Claude Code时也是走vLLM的OpenAI兼容协议这个方案对模型和工具的适配成本最低。4.2 数据流水线搭建与样本量控制数据流水线我拆成三个环节样本生成、清洗去重、格式转换。样本生成环节主要是把规则模板和人工标注结果合并生成原始JSONL格式的数据清洗去重环节用脚本做规则清洗和embedding去重主要解决模板批量生成导致的重复样本问题格式转换环节把数据转成训练需要的对话格式。样本量控制上我的经验是决策模型不需要海量数据质量远大于数量。最终训练集大约3万条左右验证集3000条。这个体量跟那些动辄百万级的大模型训练数据相比显得很小但决策任务的本质是规则学习规则的复杂度有限不需要通过海量数据来覆盖无限可能的输入空间。关键是每条样本的信息量要足够大边界样本占比要足够高。一个常见误区是为了凑数据量用模板随机生成大量同质样本。这会在训练时造成“特征偏斜”——模型看到某种状态描述就无脑选择某个动作根本没有学到真正的约束逻辑。我踩过这个坑刚开始用模板批量生成到十万条看似数据量很大但验证集的决策准确率反而不如精筛后的三万条。后来做了同质样本压缩把低质量的重复样本删掉之后模型行为才真正稳定下来。4.3 训练参数与完整训练记录实操训练参数分享一套实测可复用的参数名取值说明基础模型CodeQwen1.5-4B代码能力底座训练方式全参微调第二阶段使用学习率2e-5带Warmup前3%步数线性上升Batch Size16梯度累积8步有效Batch 128最大序列长度2048决策样本一般不会超过这个长度训练轮数3轮数不贪多防止过拟合优化器AdamWbeta(0.9, 0.999)weight_decay0.01学习率调度Cosine末端衰减到初始学习率的10%训练到第一个Epoch结束时训练Loss下降很快但验证集的动作准确率提升不明显。这里出现过一次过拟合信号——训练Loss在跌验证Loss在涨。处理办法是减少训练轮数到3轮并增加验证集里边界样本的比例。第二个Epoch之后三个评估指标同时开始明显改善特别是约束遵循率第一次突破了85%。第三个Epoch结束时动作准确率稳定在92%左右约束遵循率93%格式合规率接近97%。这个结果在4B规模的模型上已经具备对外开放的基础条件。训练过程中的显存占用细节值得说一下。序列长度2048、有效Batch 128的情况下两张24G显卡的显存占用率在85%到95%之间波动。如果你的显卡配置比我低可以降低Batch Size或者改用LoRA训练效果会差一些但不是不能跑。我在模型完全训练完成后导出BF16权重并用GPTQ做了4bit量化最终模型文件大小从8G左右压到2.4G左右量化后验证集上的动作准确率掉了不到1%这个量化损耗在工程上是完全可以接受的。4.4 vLLM部署与OpenAI兼容接口对接部署阶段选择了vLLM作为推理服务框架。vLLM对4B这种小模型的推理优化非常到位单卡就能扛住高并发。部署命令参考如下vllm serve NeoHorse/NeoHorse-Jev-4B \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1启动之后服务会暴露一个OpenAI兼容接口。四个关键信息是base_url指向http://localhost:8000/v1api_key随便填一个占位值model填模型名NeoHorse-Jev-4B。这样接入方式就跟调用OpenAI的接口完全一致了。接入Claude Code或者Codex时都是走这个OpenAI兼容接口。需要注意一个细节Claude Code和Codex在调用工具型模型时会要求模型的输出严格符合一定的JSON Schema或工具调用格式。所以推理服务端需要开启vLLM的约束解码功能。我的建议是在模型本身的输出模板里做一套约束同时加一道输出校验层模型输出后先做JSON解析和枚举校验不合法就直接丢弃重试。这两道关卡配合起来才能保证Agent系统不因为格式问题中断流程。4.5 接入Codex和Claude Code的实测记录把NeoHorse-Jev-4B接入Codex和Claude Code本质上不是改模型而是改Agent的工具调用策略。我的做法是在这些Agent工具的配置文件中把工具选择器指向NeoHorse-Jev-4B的API地址让它在进行工具调用时先经过决策模型做动作筛选而不是直接调用底层的大模型进行自由选择。接入Codex时主要拿它做代码库变更决策——判断一次代码变更涉及哪些文件、需要运行哪些测试、变更顺序是什么。接入Claude Code时主要把它用于任务拆解的校验——在复杂任务开始前让决策模型先做一次步骤规划和约束检查。实测下来两个场景都达成了预期。Codex场景里的工具调用失败率降低了约30%原因是模型不会在动作空间中乱选。Claude Code场景里的多步任务中断率明显下降因为步骤之间的一致性校验做得更严格了。当然这组数据只是参考效果跟你对接的Agent框架版本和任务类型密切相关不要当成通用指标去对齐。5. 常见问题与排查技巧实录5.1 模型总是输出动作空间外的内容怎么办这是最典型的决策模型问题。现象是模型在训练时表现正常一部署到实际环境中就开始“自由发挥”输出了动作列表之外的动作名。原因通常有三个一是约束条件被模型忽略。指令模板里约束位置不明显模型没有把它当作硬性规则。解决方法是把约束条件改成显式的“禁止”列表比如加上“注意以下动作不允许被选择动作X、动作Y”比“约束条件不可选动作X”更有效。二是训练数据里混入了噪声。如果有部分训练样本的答案是动作空间之外的模型就会学习到“可以跳出限制”的行为。检查每条训练样本确保动作严格属于定义的空间。三是推理阶段的约束解码没有生效。如果你用了vLLM确认约束解码配置正确尤其看guided_json或guided_choice参数这两个参数是控制输出枚举范围的关键。没有启动约束解码时模型永远存在越界输出的可能。在实际处理中我会同时启用“约束解码 输出后校验 重试机制”三层保障。5.2 训练Loss下降但决策准确率不涨这个现象也经常出现而且比较折磨人。排查思路是先确认是不是数据“假多样”。如果训练样本里存在同质样本过多的问题模型只是在记忆数据没有真正建立起状态到动作的映射关系。检查方法随机抽100条训练样本看状态描述和约束条件是否覆盖了足够多的组合。另一个可能是样本里的状态描述和约束条件“高度相关”。比如约束B只在状态A下出现从未在其他状态下出现过。这会引入虚假的相关性模型会学到“看到状态A就直接选动作B”的捷径而不是真正理解约束B独立限制决策结果的语义。对这类问题需要检查训练数据的正交化程度把绑定出现的特征解耦开重新随机组合生成新样本。5.3 量化后行为漂移明显GPTQ量化后模型的决策行为如果出现明显变化说明有两个问题。一是原始模型本身对量化不够鲁棒二是关键决策层在量化过程中受损过大。排查时可以先做逐层敏感性分析。具体做法量化后逐层使用原始层的权重替代量化权重看决策准确率恢复情况。准确率在某层开始明显恢复说明这一层是敏感层。找到敏感层之后可以进行两层处理一是保护该层不参与量化GPTQ支持Layer-wise的量化开关二是稍微提高该层的量化比特数比如其他层用4bit敏感层用6bit。实测下来多数情况下仅保护1到2个敏感层就能把量化后的准确率拉回与原始权重基本一致的水平。5.4 接入Agent后出现“决策滞后”问题让Agent在执行过程中频繁调用决策模型容易造成体验上的“卡顿感”。原因很简单每调用一次决策模型就有一轮网络请求累积起来延迟就高了。我的优化方案有三个按效果排序一是批量决策——把多个决策任务一次性打包发给模型一次推理解决多个选择这个对Task拆解场景特别有效二是本地推理——如果服务端允许把模型放到Agent同一台机器上推理省去网络延迟三是预测缓存——对重复出现的状态缓存决策结果避免重复请求。实测中批量决策的效果最明显多步任务的执行效率能提升40%以上。具体做法是修改Agent的调用逻辑把连续的多个工具选择合并成一次决策模型的批量推理请求返回多个动作选择结果Agent再逐个执行。5.5 决策模型在长对话场景中的约束漂移这是我在接入Claude Code做长任务规划时遇到的特殊问题。Agent在长时间运行中对话上下文不断增长模型在处理后续决策时有时会忽略早期对话中定义好的约束条件。比如用户在一开始指定“只允许使用Python代码”但Agent处理后期任务时输出了一个Shell命令的动作。解决思路有两个层面。模型层面把关键约束条件定期“重申”以系统消息的形式周期性注入到最新上下文中。工程层面在Agent的上下文中维护一个“约束摘要”槽位一旦检测到上下文扩展自动把历史关键约束压缩成摘要并重新注入。这两层结合基本能解决约束漂移问题。还有一个细节是评估模型的约束遵循能力时最好专门构造一个长对话的测试集包含几百轮对话历史测试模型在上下文长尾部分的约束表现——这才是真正贴近线上环境的检验方式。6. 决策模型的扩展方向与个人的一点体会最后再说一些个人体会。做决策模型这段时间最大的感悟是决策模型是一种“约束放大器”。它在数据层面上建立了规则到动作的清晰映射在工程层面上用格式约束保证了输出可控在系统层面上跟Agent工具链做了对接。每一个环节都在做同一件事把不确定性拧出来让整个决策链路变得可预期、可监控、可回滚。但这个方向还有很多可以继续深挖的点。比如在多步骤长链路决策中引入显示状态跟踪每个步骤决策都关联到前一个步骤的执行结果形成状态依赖的决策链。比如研究多决策模型协同不同层级的决策任务交给不同专长的模型而不是指望一个模型解决所有决策场景。比如探索决策模型与执行验证器之间的主动反馈循环让决策模型在每次执行之后根据结果反馈更新自己的决策策略。这些方向都还在早期阶段但已经有社区项目在尝试了。如果你是做Agent工程化、工具链优化、或者想在嵌入式场景里做轻量决策方案的人NeoHorse-Jev-4B的做法可以直接参考代码和模型权重完全开源训练数据构造方案也在仓库里。这个项目对标Jev只是起点不是终点。项目仓库里目前开放的资源包括决策模型训练数据样例、完整的训练脚本含LoRA和全参微调两条路径、推理部署方案适配vLLM、以及接入Codex和Claude Code的配置示例。我自己后续的计划是把边界样本池扩充到更多业务场景——比如电商交易链路里的售后决策、内容推荐里的动作选择、薪资结算里的规则判定——让这个模型从“工具调用决策”走向“通用业务决策”。写这篇文章的时候我回看了一遍整个项目的代码和数据踩过的坑还在眼前。有人可能会问做个4B的决策模型花这么大精力值不值。我的回答是在Agent应用大规模落到业务场景的当下真正能在约束条件里做对选择的轻量模型价值才刚刚开始显现。如果这篇文章给正在做类似事情的朋友省下几个周末的摸索时间那就够了。
