Jev 不是 LLM 杀手，也不仅仅是一个分类器。我们将其部署于生产环境并与真实用户一起使用。以下是我们学到的经验。

​ 我是一家代理初创公司的创始人。我们已经在生产环境中运行 Jev 并与真实用户一起使用，所以这更多是实际情况而非理论。如果你本周一直在关注这个子版块，你会看到关于 Jev 的两种观点。一种认为它将杀死 LLM 市场，另一种认为它只是一个公关良好的分类器。人们在两点上都错了，错误在于将 Jev 与 LLM 进行比较。别陷入这个误区。Jev 和 LLM 是完全不同的系统。Jev 是一个语义决策引擎。简单来说，你给它一个情境、一个问题和一组选项，它会对每个选项评分，并返回最佳选项及其概率。仅此而已。它不能像 LLM 那样生成内容。它不能编写你的代码或与你聊天。它甚至不能看到你的屏幕，因为它是纯文本的。那么，一个连句子都写不出来的东西怎么会成为我们工具套件最大的升级之一呢？因为计算机不需要输出标记来执行。这是 TypeSafe 的赌注，一旦我明白了，就再也无法忽视。LLM 逐个生成标记，你解析它们，然后某些东西基于它们行动。对于许多代理步骤来说，这太过分了。决定是否点击、滚动或输入，不需要先有一段推理。Jev 并行回答关于同一状态的几个问题并返回一个动作。没有长长的推理痕迹，也没有输出需要解析。而且因为它只能从你定义的选项中选择，它无法发明一个不存在的按钮。在 Vestra 的代理工具套件中，我们将其用于工具调用门控、护栏和监督、浏览和计算机使用。工具套件将屏幕转换为结构化的内容列表，Jev 选择下一个动作，而 LLM 只在任务需要实际规划或写作时才介入。计算机使用是受影响最大的地方。仅使用 LLM 时，速度很慢，因为每次点击都等待模型完成思考输出。现在，它的速度接近我在屏幕上发现某物并点击它所需的时间，我们的用户每天都在通过它执行真实任务。这可能会改变我们使用 AI 代理的方式。现在，是你只在生产环境中才能学到的部分。别天真地认为它是一个确定性的分类器。它有自己的判断力。这正是它有用的地方，也正是它可能自信地出错的原因。"不能返回无效选项" 与 "总是选择正确的选项" 不同。格式正确但错误的答案比损坏的答案更隐蔽，也更难捕获。我们通过置信度阈值来处理这个问题。如果 Jev 很确定且动作是低风险的，它就执行。如果它不确定或风险很高，这一步就交给 LLM 或人类。它不完美，但这是一个很好的起点。以下是我无法完全回答的问题。如果 Jev 接管所有小决策，LLM 在每个循环中的作用就会减少。今天这看起来像每个系统都做自己擅长的事情。一年后，这是否会看起来像 LLM 成为昂贵的后备，只在廉价模型不确定时才被调用？我认为这不会杀死 LLM 市场，但可能会改变我们为 LLM 付费的目的。真心问一下这里构建代理的人：你在哪里将 LLM 从一个它从未需要做出的决策中移除？如果你尝试过 Jev 然后又回到了仅使用 LLM，是什么让你回去的？