DecisionLoop：用小决策模型替代LLM做Agent调度

在Agent框架几乎默认"用大模型驱动一切"的当下，一位开发者在Reddit上抛出了不同的思路：把意图识别、工具选择、参数生成、流程控制这些决策环节，交给一个小型决策模型，而不是每次都让LLM从头推理一遍。这个名为DecisionLoop的Python框架，试图回答一个工程问题——Agent的"大脑"一定要很大吗？

核心主张：决策层与语言层解耦

DecisionLoop的基本架构，是把Agent的工作拆成两层。语言层负责理解和生成自然语言，决策层则负责"下一步做什么"——检测用户意图、选择合适的工具、填充参数、决定流程走向。框架的创新点在于，后者由一个专门的小决策模型承担，而非让LLM在每一轮对话中同时完成语言理解和决策推理。

这种设计带来了直接的工程收益。据作者描述，决策模型体积小、推理路径固定，因此在工具调用这一环节上，延迟和成本都比"LLM每一步都重新判断"的方式更低。对于需要频繁调用外部工具的场景，这意味着一轮对话中可能省下多次大模型请求。

小决策模型通常指参数量在数亿到数十亿之间的语言模型（如1B–3B），区别于动辄70B+的通用大模型。其核心优势在于推理路径短、显存占用低、单次调用成本低，适合执行分类、意图判别、槽位填充等结构化任务。在小决策模型的训练与微调上，常见做法是用领域标注数据做监督微调，或通过LoRA等参数高效方法在少量样本上适配特定业务流程。由于参数量小，它对提示格式、工具描述的变化更敏感，泛化到未见意图的能力弱于大模型——这正是文章中"换成更小模型结果波动明显"的原因。

在Agent语境下，**工具调用（Tool Calling）**指模型根据用户请求，从预定义工具集中选择合适工具并生成符合Schema的参数，再执行外部API并整合结果。它通常包含三个子步骤：工具选择、参数生成、结果解析。传统做法是让LLM在每轮对话中完成全部三步；DecisionLoop则将前两步下放给决策模型，仅把需要自然语言理解和生成的部分交给LLM。

三个测试场景与初步结果

作者在三个业务场景上做了验证：订单客服、航班服务台、银行服务台。这三个场景的共同点是流程相对明确、工具集有限，同时又要应对用户表达方式的多样性——恰好是决策模型能够发挥结构优势的典型环境。

早期测试结果显示，DecisionLoop在工具调用准确率上优于基于LangChain、使用12B模型构建的LLM Agent，同时在成本和延迟上也有优势。作者同时指出，换成更小的模型时结果波动明显，说明决策模型本身的能力下限会直接影响整体表现。

需要强调的是，作者本人把这些结果称为初步观察而非正式基准测试。测试场景、样本规模、评判标准都没有公开，所以这些数字更适合理解为"方向性信号"，而不是可直接对比的性能结论。

LangChain是目前主流的Agent与LLM应用开发框架，提供工具封装、记忆管理、链式编排等抽象。基于LangChain构建的LLM Agent通常采用ReAct式循环：LLM输出"思考—行动—观察"序列，逐步决定调用哪个工具。这类方案的典型问题是每轮决策都要调用一次大模型，延迟和Token消耗随对话轮数线性增长。文章提到以12B模型的LangChain Agent为基线，需要留意的是12B在今天已属于中等偏小规模，业界生产Agent常用70B级或闭源大模型，因此这一对比的"上限"并不高，也解释了作者为何强调需要与更强模型做受控比较。

小决策模型的适用边界

这套思路的价值，取决于任务本身的确定性程度。当工具集固定、业务流程可枚举、用户意图可以归纳为有限类别时，决策模型可以用很小的参数量覆盖大部分情况，把LLM从重复的"选项判断"中解放出来。

但边界也很清晰。一旦对话进入模糊、多义、需要大量世界知识才能判断的领域，决策模型可能缺乏足够的语义理解能力来做出正确选择——这也是作者在帖子里主动征集"difficult conversations to test"的原因。哪些对话类型会击穿决策模型的假设，目前还没有答案。

另一个隐含的前提是工具集和流程的稳定性。如果工具频繁变动、流程经常调整，决策模型的维护成本可能会抵消掉它在推理时的节省。

作者正在寻找的反馈

这篇帖子本质上是一次开放式的架构讨论。作者列出了几个具体问题：架构设计是否合理、有哪些真实场景值得测试、哪些对话类型可能让决策模型失效，以及如何公平地与更强的LLM做对比。

最后一点尤为关键。用12B模型做基线的说服力有限，因为业界主流Agent早已在使用更大、更强的模型。要证明DecisionLoop的路线有普适价值，需要在同等工具集、同等任务分布下，与强模型进行受控对比，并明确报告失败案例——而不仅仅是准确率和成本的平均值。

作者还提到，下一步计划在DecisionLoop之上构建多Agent架构，由一个路由层将请求分发给领域专家Agent。这个方向与决策模型的思路一脉相承：路由本身也是一个决策问题，同样可以用小模型来承担。

**受控对比（Controlled Comparison）**指在变量尽可能一致的条件下比较两种方案，这里至少要固定：相同的工具集与工具描述、相同的任务分布与样本量、相同的评判标准（如工具调用是否正确、参数是否完整、端到端成功率）、相同的部署环境（硬件、并发）。缺少这些控制，准确率或延迟的差异可能来自任务难度、提示词差异或模型规模，而非架构本身。此外，仅报告平均值会掩盖长尾失败——在Agent场景中，少数复杂对话往往决定了产品能否上线，因此报告失败案例分布（如按意图类别、对话轮数分层）比单一平均值更有说服力。

这条路线值得关注的理由

无论DecisionLoop本身能否走通，它提出的问题是有价值的：当前Agent框架中，LLM承担了太多本可以结构化处理的决策负担。把"选哪个工具"和"怎么表达"分开，理论上能让系统在成本和延迟上更可控，也让每一层的可调试性更强。

对于正在构建生产级Agent的团队来说，这提供了一个值得实验的对照方案：先用小决策模型处理可枚举的决策，只在真正需要语言理解和开放推理时调用LLM。至于这条分界线应该划在哪里，可能需要更多像这样的公开实验来回答。