把决策模型接入 Agent Harness 的两种实践

到目前为止，智能体自动化只有一种引擎：LLM。我们一直把 LLM 当作万能模型。在大多数智能体工作中，它们承担一系列任务类型：推理、规划、自然语言理解与合成、分类和预测。随着最近 Jev 的推出，以及“决策模型”这一品类的创建，我们看到其中一些任务（例如分类、二元预测）可以卸载给一个更快、更便宜的模型。

于是设计问题就变成了：我们如何将决策模型整合进智能体框架，以便向它发送正确类型的任务？这应当会从主线 LLM 那里转移走一些调用，进而有助于降低总体成本和延迟，同时保持或提升任务表现。

我花了一个周末尝试了两种将 Jev 嵌入 Proceda 的方式，Proceda 是我最先进的专用框架，用于将标准操作流程转化为智能体。

在框架内使用 Jev

Proceda 接收自然语言 SOP，并逐步执行。这让每次 LLM 调用都有相当窄的范围。框架已经知道当前步骤，并管理整个流程的推进。即使在这种受限环境中，我也怀疑 LLM 在做一些可以移交出去的工作。（我在 Anatomy of a SOTA Agentic SOP-Execution Engine 中写了更多关于架构的内容，更广泛的设计原则在 Specialized Harness Engineering 中。）

我在 SOP-Bench 的三个领域上测试了这一点：推荐滥用检测、电子邮件意图和患者接诊（只是基准测试的一个子集，因为我想快速了解一下）。总共 360 个案例。主 LLM 是 Qwen 3.8 27B，托管 Jev 作为决策模型。

实现和实验报告在 codex/bounded-business-decisions 分支上。我在视频中使用的 HTML 幻灯片 在同一个仓库中；下载它并在浏览器中打开即可查看幻灯片。

实验 1：这一步完成了吗？

在智能体进行工具调用后，它通常会回到 LLM 来解释结果，并决定当前步骤是完成了，还是需要更多工作（工具调用或推理）才能完成。这个决策步骤听起来很适合 Jev。

我把 Jev 放在符合条件的工具调用之后，给它当前步骤、相关上下文，以及工具调用及其结果。它回答两个问题：所有必要的工具调用是否都已进行，以及证据是否足以完成这一步？

如果两个“是”的概率都达到 0.8，Proceda 就继续推进。否则，主 LLM 照常继续。工具仍然运行；节省来自避免后续的 LLM 轮次。

完成检查实验显示：

• 减少了 605 次 LLM 调用，即降低 23.8%。
• 任务表现（几乎）相同：仅用 Qwen 时 357/360 最终任务正确，而混合方案为 356/360。

实验 2：做出业务决策

实验 1 将决策模型用于框架的内部运作。一个自然的问题是：SOP 本身中属于决策的步骤呢？SOP 中的许多业务逻辑问题恰好适合决策模型。这正是 Typesafe AI 的核心假设。

提取邮件意图。给定一封卖家的邮件，SOP 会问它提出了哪类问题：一般性的商品上架问题、定价错误、商品未上架、描述错误，还是无法做出决定。这非常适合决策模型中的“classify”调用。

Jev 可以接收邮件和原始策略，选择一个结果，并将该结果交回给 harness。如果它选出的结果概率低于 0.8，决策就回退到 Qwen。工作流的其余部分仍必须执行。

邮件对比显示：

• 148 个意图决策中有 141 个由 Jev 处理，即 95.3%。
• 有七个决策回退到了 Qwen。
• 在结构化接口背后，无论使用哪个模型，148/148 的最终任务都正确。
• 整个邮件工作流的 LLM 调用减少了 25.4%，从 556 次降至 415 次。

之后的 LLM 调用次数完全相同，因此那 141 次被避免的调用可以直接归因于卸载了意图分类。

综合影响

两项改动都到位后，综合实验显示：

• 主 LLM 调用减少了近 30%：从 2,537 次降至 1,785 次，节省了 752 次调用（29.6%）。
• 预估执行 API 成本降低了近 27%：360 个案例的批次从 $6.41 降至 $4.70，包括 Jev 请求（26.6%）。
• 平均案例延迟降低了近 20%：从 8.64 秒降至 6.94 秒（19.7%）。
• 综合系统中观察到的任务准确率更高：最终任务正确数从 357/360 提升至 360/360。
• 即使计入准备成本，预估 API 成本仍降低了近 25%：从 $6.41 降至 $4.83，包括结构化 SOP 计划的全部最终准备成本（24.6%）。

主 LLM 调用减少近三分之一、执行 API 成本降低近 27%、平均延迟降低近 20%——同时综合系统中观察到的任务准确率更高——这是一组有用的收益。而它来自于在 harness 中找到两个具体位置，那里所需答案比通用生成要窄得多。

决策模型作为缓存

我不断回到的类比是缓存。把主 LLM 想象成主存或磁盘，把决策模型想象成吸收部分流量的 L1 或 L2 缓存。这里较小的模型是计算答案而非检索已存储的答案，但架构角色类似：廉价地处理你能处理的请求，处理不了时就向下传递。

本地决策模型让这一点更有趣，正如我在 本地决策模型 + Jev：用置信级联降低延迟 中探讨的那样。在我的独立实验中，我观察到的响应时间为：

• Laya 大约 30 毫秒，运行在我的 M5 MacBook 上。
• 托管的 Jev 大约 250–300 毫秒。（不过我怀疑其中很大一部分是网络延迟）

让这些模型有用的是它们周围的 harness。它提供证据、定义选项、验证结果并处理不确定性。一旦这些边界明确，你就可以开始问 LLM 的哪些工作真正属于那里。

在 Proceda 中，两个好的起点是“这一步完成了吗？”和“这些结果中哪一个适用？”我怀疑很多 agent 正在把 LLM 调用花在这同样的两个问题上。