HarnessRouter 支持System 1/2两类AI应用

清晰讲解：1 型系统与 2 型系统智能体框架，有两种不同的方式把 AI 集成到应用里。

1 型框架要求模型做出有界判断。应用提供请求和相关状态，模型选择一个受约束的结果，比如分类、分数、路径或是提取出的字段。代码在执行结果或是升级案例之前，会检查置信度和策略。

模型不掌控工作流，它只从代码提供的选项里做选择。这种方式在意图分类、模型路由、风险关口、重排序，以及其他所有可能输出提前可知的高容量决策场景下，效果很好。

Jev 就是为这个 1 型系统角色设计的，用来做出快速、有界的判断，同时由应用代码控制工作流。

2 型框架处理路径无法提前指定的工作。大语言模型接收目标、约束和当前状态，它规划下一步，同时由受保护的路由控制它能调用哪些工具。

工具结果返回给框架，框架更新状态并验证进度。每个循环最终可以是执行最终动作、向用户提问，或是制定另一个计划。大语言模型帮助驱动工作流，但它不应该拥有权限。工具权限、预算、停止条件和最终执行都仍然由应用代码掌控。

这种模式适用于编码、研究、事件调查，以及其他包含多个依赖动作的任务。

所以这本质上不是小模型和大模型的区别，而是控制流的差异。大多数生产应用都需要两者：1 型系统处理快速、有界判断，2 型系统处理模糊或多步骤工作。

接下来的工程问题是，如何同时运行这两种模式，而不需要为每个框架单独维护一个执行层。

现在这个问题的解决方案已经开源，并且在 HarnessRouter 中实现了。它在应用和执行任务的框架之间提供了基础设施层。
- 它的 1 型系统基底可以运行 Jev 和其他决策模型，这些模型使用类型化输出和置信度门限来选择有限动作。
- 它的智能体框架基底支持 Codex、Claude Code 和 Hermes 这类运行时，它们可以做规划、调用工具、管理文件，完成开放式任务。

GitHub 仓库：不要忘记点星标 ⭐
HarnessRouter 不会让这些系统以完全相同的方式推理。相反，它只是标准化它们执行周围的基础设施。

通过统一框架协议，应用获得一份统一约定，涵盖启动任务、流式传输进度、恢复会话、交换文件、取消工作和报告结构化故障。这让应用可以选择合适的框架，而不需要围绕每个运行时重建它的任务生命周期。

如果你想要深入了解，Akshay 写了一篇详细文章，解释 HarnessRouter 和统一框架协议如何提供这个基础设施层。它涵盖了为什么模型路由不是框架路由，任务如何……