决策模型Jev搭配开源框架TrueForge：40次匹配成本降至1/150的实测解析

在企业智能体落地过程中，运行成本始终是绕不开的核心议题。当智能体需要反复在固定选项中做出判断时，让擅长生成文本的大语言模型处理每一次决策，往往意味着高昂的Token消耗。近期一项对照测试提供了新的解决思路：将决策任务剥离给专门的决策模型后，40条客户请求的匹配准确率与Claude Opus持平，但成本仅为后者的1/150至1/250。这一结果背后，是模型分工策略与智能体运行框架的协同优化，为企业控制智能体运营成本提供了可落地的参考路径。

智能体运行成本的三重影响因素

智能体通常在循环中运作：模型判断下一步操作、调用工具、处理结果、继续执行直到任务完成。在此过程中，影响单次运行成本的主要有三个因素：模型接收的上下文规模、框架调用模型的频次，以及每次判断由哪个模型执行。前两项由运行框架决定，第三项则涉及模型之间的任务分配。以客户请求匹配场景为例，需要在300个研发任务中找出与40条客户请求对应的记录，涉及12000种配对可能。若每次判断都由生成模型处理完整上下文，Token消耗将随请求数量线性增长。关键词匹配难以覆盖语义差异，而模型即使启用提示词缓存，仍需处理全部内容。更便宜的模型虽能降低单个Token的价格，却无法据此判断每次匹配的可信程度，高置信度的错误匹配往往更具隐蔽性。

Jev决策模型：从给定选项中精准选取

Jev是TypeSafe AI推出的专用决策模型，被定位为首个“System One”模型，专为固定选项判断场景设计。在以决策为主的智能体工作流中，Jev的运行速度是大语言模型的40至200倍。与生成文本的模型不同，Jev接收状态信息和带类型的问题后，返回软件可直接使用的结构化答案：Choice用于从指定选项中选取、Score将状态归入有序等级、Noul返回是非判断为真的概率。每条请求约900 tokens，每百万输入Tokens仅0.042美元，输出免费。Jev的置信度经过校准，标为0.88的答案从大量预测来看正确率应接近88%，这一特性使得框架可以基于置信度决定哪些结果需要人工复核。不过Jev存在使用边界：只能从给定选项中选择、状态与最长问题合计不超过32000 tokens、选项最多255个。因此在实际流程中，需要先筛选出10个候选选项再交由Jev决策。

TrueForge框架的多层成本控制机制

TrueForge是TrueFoundry开源的智能体运行框架，在Enterprise Bench测试中完成了与Claude Managed Agents和deep agents相近的任务数量，但使用的Token约为前者的1/2.7、不及后者的四分之一。其成本控制主要依赖四种机制：延迟加载工具避免启动时加载全部MCP工具定义，需要时才获取详情；工具返回内容过大时转存至沙箱文件，对话中仅保留预览和路径；代码模式下智能体编写脚本调用工具并处理返回值，中间数据留在脚本中减少对话上下文；子智能体在独立上下文中完成具体任务后返回摘要，减轻主上下文负担。此外TrueForge支持本地单进程运行（SQLite+Node 22.13）或基于Postgres和Redis的托管模式（Docker Compose或Helm部署），MIT许可证允许在自有环境中运行，数据不出本地。

三步工作流实现精准匹配与成本平衡

完整的客户跟进流程将任务分解为三个步骤：第一步找候选项，按客户请求与issue共有关键词排序，保留前10个候选，将300个issue缩小至Jev可处理范围；第二步选择匹配，Jev接收每条请求及其候选，选出一个issue或返回none；第三步生成与复核，若Jev返回none则由生成模型起草新issue，若匹配置信度低于阈值则交回复核。最终测试结果显示：接入Jev与不接Jev的两套方案均答对37/40条，但Jev方案进入复核16条、发现错误5个，不接Jev方案仅复核5条且未发现错误。典型案例REQ-004中，客户描述搜索问题，GitHub上有类似issue但原因不同，无Jev时生成模型误选该issue，有Jev时置信度仅0.40触发复核并正确识别为新问题。成本方面，面对相同候选列表，Claude Opus 5.5的决策成本约为Jev的150至250倍，若启用扩展思考则更接近区间上限。

这一测试揭示了智能体架构中模型分工的必要性：框架影响上下文规模与模型调用频次，专用决策模型可显著降低固定选项判断的成本，置信度机制则为自动化复核提供了依据。类似的分工策略适用于需要反复判断记录的场景，包括收件箱分流、工单打标签、CRM分类和交易审核等，为企业智能体部署提供了切实的成本控制思路。