为什么AI Agent需要决策模型？别让生成式LLM包揽一切

一个昂贵的隐性假设

大多数Agent框架都藏着一个代价高昂的假设：把语言模型当成工具箱里唯一的锤子。每当Agent需要做出选择——路由消息、挑选工具、判断是否压缩对话历史、验证答案是否有事实依据——框架的做法总是格式化一段提示词、调用生成式LLM、然后等待token流式返回。

把每一个决策都当成文本生成问题来处理，既慢、又脆弱、还浪费。生成式模型是在数万个候选词的开放词汇表上逐token预测的。当你让它在两个动作之间做选择时，它并不是简单地选一个分支，而是要花时间输出语法、格式化花括号、转义字符串，甚至在给出答案前还夹带一段没人要求的闲聊。你为首个token的等待付费，为生成延迟付费，还要额外消耗算力去验证输出到底是不是合法的JSON。

这篇来自Reddit的技术分享提出了一个更合理的架构模式：把生成工作与决策工作分离开。在Agent harness（承载Agent运行的执行框架）层面的那些关键选择，应该交给专门的"决策模型"来处理，而不是通用生成式LLM。

什么是决策模型？

决策模型不产生自由格式的token流，而是针对一个有界的假设空间去评估当前状态。在实践中，一个Agent harness主要问三类问题：

三种决策类型

• Choice（选择）：从一个预定义的集合中精确选出一个选项，本质是枚举或字面量联合类型。
• Truth（真值评估）：给定当前状态，评估某个具体断言的概率或真值，返回0到1之间的连续分数，或一个经过校准的布尔置信度。
• Score（打分）：根据评分标准对候选项进行评估和排序。

关键在于，输出空间在调用开始前就被严格界定。模型不需要生成任何语法或开放式散文，它直接对候选项打分。这带来的好处是执行快速、成本低廉、结果确定，同时消除了解析错误、JSON schema违规，以及生成式模型在"自我审查"时常见的阿谀式漂移（sycophantic drift）。

从技术实现角度看，决策模型可以通过多种路径落地。一种常见方式是约束解码（Constrained Decoding）：在推理时强制限定模型只能从预定义的token集合中采样，从根本上封闭了开放式生成的可能，延迟接近于零附加开销。另一种方式是使用经过微调的小型分类模型（如基于BERT或类似架构的判别式模型），这类模型原本就不做自回归生成，天然适合输出概率分布或类别标签。还有一种轻量方案是利用现有LLM的logprobs接口：只请求特定候选token的对数概率，而非完整补全，许多推理API（如OpenAI的logprobs参数）支持这一模式，可以在不换模型的前提下获得类似效果。这三种路径在延迟、成本和工程复杂度上各有权衡，但共同点是：输出空间的约束发生在架构层面，而非依赖提示词措辞去"祈祷"模型自觉遵守格式。

决策模型在架构中的四种落地方式

原文作者详细描述了这套"决策/生成分离"思路如何贯穿他们的整个harness。

1. 动态技能注入（Dynamic Skill Hydration）

生产环境Agent的一个常见失败模式是提示词膨胀。开发者希望机器人能同时处理编程、日历管理、数据库查询和文档检索，最省事的做法就是在每一轮开始时把所有技能、提示规则和工具schema一股脑塞进系统提示词。

但这会"毒害"模型的注意力。当一个模型的上下文里塞着四十个工具和十五页指令时，工具选择的准确率会下降，延迟会飙升。

他们的方案是用决策模型对候选技能逐一评估：针对每个可用技能，决策模型回答一个简单的真值问题——当前这一轮或用户请求是否需要这项能力？ 只有得分超过置信阈值的技能才会被注入到本轮的Agent上下文中。这样系统提示词保持精简，用户切换话题时技能也能干净地卸载。

这一问题在学术和工程社区通常被称为**"Lost in the Middle"效应**：多项研究（如斯坦福2023年的同名论文）发现，当上下文过长时，语言模型对位于序列中部的信息的利用率显著低于开头和结尾。在Agent场景中，这意味着即便所有工具定义都出现在提示词里，模型在实际工具选择时也可能系统性地忽略排在中间的选项。动态技能注入从架构层面规避了这一问题——通过只向上下文注入当前轮次真正相关的少量技能，让每一项被注入的工具定义都处于模型注意力的"有效区间"内，而非被淹没在数十个并列条目之中。这也解释了为什么这一模式对工具选择准确率的提升并非仅来自token节省，还来自注意力分布的改善。

2. 选择性记忆压缩（Selective Memory Compaction）

自主Agent会产生海量的工具执行轨迹。一轮涉及bash命令、文件搜索或数据库查询的操作，就可能往历史里塞入数千token的原始stdout、堆栈跟踪和JSON载荷。

这里有个两难：全部保留会撑爆上下文窗口、破坏prompt缓存命中率；而定时粗暴地压缩摘要，又会抹掉用户或Agent正在调试的中间行号、文件路径或编译错误。

决策模型的介入方式很巧妙：在一轮执行前，harness会问它某些过去的执行片段是否"已了结"——这个片段里的子任务是否已完成，且当前用户请求是否已不再依赖检查那份原始stdout或错误轨迹？ 如果确认已了结，harness就把中间的工具调用和输出折叠成一份紧凑的语义摘要；如果用户还在追问那一轮的报错，原始日志则原封不动。上下文保持干净，同时不破坏活跃的工作记忆。

3. 幻觉与安全闸门（Hallucination and Safety Gate）

当Agent产生回复时，尤其是在WhatsApp、Telegram这类实时消息环境中，指望生成式模型自己给自己的输出把关是不可靠的——生成式模型天然倾向于为自己的补全辩护。

因此，在一条消息离开harness之前，一个独立审计器会运行决策模型检查。决策模型接收用户查询、工具产出的已验证事实、以及拟发送的机器人回复，评估一个布尔条件：这条回复是否是跑题的幻觉，或者是否凭空发明了与已验证事实相矛盾的断言？

一旦被标记，harness就中止发送，向Agent的内部历史注入一条有针对性的纠正思路，然后重试。由于决策模型评估的是一个离散边界，而非陷入对话式辩论，这道闸门的延迟开销极小。

值得注意的是，这一机制在结构上属于**"裁判模型"（Judge Model）模式**的一个变体——用一个独立模型来评估另一个模型的输出，而非让生成模型自我反思。研究表明，让同一模型评估自己输出的真实性时，会出现系统性的自我确认偏差（self-consistency bias）：模型倾向于为自己已生成的内容辩护，即便该内容存在事实错误。将验证职责交给结构上独立的决策模型，可以切断这一反馈回路。在工程实现上，这也意味着两个模型可以针对不同目标优化——生成模型追求流畅性与覆盖度，验证模型则可专门针对事实一致性任务进行微调或提示设计，职责分离带来的不仅是延迟收益，也是更高的可审计性。

4. 混合Schema拆分（Hybrid Schema Splitting）

很多工作流需要结构化数据，里面既有离散标志又有自由描述。比如一个工单分类schema可能包含isUrgent布尔值、category枚举和summary字符串。传统做法是把整个schema丢给生成式模型，然后祈祷JSON能解析成功。

这套harness则在运行时检查schema：

• 如果schema只包含离散类型（布尔、枚举、字面量或字面量联合），就完全绕过生成式补全，直接走决策模型。
• 如果是混合schema，harness会自动把它拆成两部分：离散字段交给决策模型，自由文本字段交给生成式模型调用。

两者并发执行，最后harness把校验后的结果拼接回单一的类型化对象。决策模型确定性地处理分类，生成式模型则专注于合成自然语言。

用对工具：不要用Web服务器去做加法

这套论述的核心洞见很清晰：生成式模型擅长合成语言、解释微妙概念、编写代码，但在Agent harness的确定性管道工作上，它们出人意料地糟糕。

作者打了一个精准的比方：用生成式模型来决定是否激活某个技能、压缩执行日志或校验输出，就像为了做两个数的加法而启动一整个Web服务器——能跑，但白白引入了延迟、成本和脆弱性。

把"决策"与"生成"解耦，能让上下文窗口更小、延迟更低、行为更可预测。对于正在构建生产级Agent系统的开发者，这提供了一个值得认真对待的架构思路：不要把每一个判断都外包给通用大模型，而是识别出那些本质上是分类、评估、打分的有界问题，交给更适合的确定性组件去处理。

需要说明的是，本文内容来自单一Reddit技术分享，其"决策模型"具体是通过微调小模型、约束解码，还是其他技术实现的，原文并未展开，读者在实践中仍需结合自身场景验证。