多智能体SOC应用的LLM选型策略：规则路由还是LLM自主决策？

在构建多智能体（Multi-Agent）安全运营中心（SOC）应用时，一个核心的架构问题往往被低估：如何为工作流中的不同环节选择合适的大语言模型（LLM）？一位 Reddit 开发者最近分享了他的实践困境，这个问题对所有在 LangGraph 上搭建复杂 Agent 系统的工程师都极具参考价值。

一个真实的架构困境

这位开发者基于 LangGraph 构建了一套多智能体 Agentic SOC 应用，系统内包含多个协作的智能体：

路由器（Router）：负责请求分发与调度
基础研判（Basic Triage）：对告警进行初步分级
高级研判（Advanced Triage）：处理复杂的深度分析
记忆候选生成（Memory Candidate Generation）：为系统积累可复用的知识

reddit source: LLM selection

目前整套系统的推理任务全部交由 Claude 完成。开发者希望引入更多不同的 LLM 模型来优化成本与性能，但卡在了一个关键决策点上：LLM 的选择逻辑应该放在哪里？ 是在路由器 Agent 中预先定义好明确的选型规则，还是让路由器 Agent 直接调用 LLM 来动态判断该用哪个模型？

LangGraph 是由 LangChain 团队开发的基于图结构的 Agent 编排框架，允许开发者将多个 LLM 调用、工具使用和条件分支定义为有向图中的节点与边。与线性的 Chain 不同，LangGraph 支持循环、状态持久化和多 Agent 协作，特别适合需要多步推理和动态决策的复杂场景。在 SOC 应用中，它可以将告警接收、分级、分析、响应等环节建模为相互协作的节点，每个节点可独立绑定不同的 LLM 或工具，这正是本文讨论的「多模型路由」问题的技术前提。

两种路径的本质区别

这个问题看似是实现细节，实则是「确定性」与「灵活性」之间的经典权衡。

规则驱动的模型路由

第一种方案是在路由器中硬编码选型标准。例如：基础研判任务因为逻辑简单、调用频繁，可以路由到更便宜、更快的轻量模型（如 Haiku 级别或开源小模型）；而高级研判涉及复杂推理，则交给能力更强的模型（如 Claude Sonnet/Opus 或 GPT 系列旗舰）。

这种做法的优势非常明显：

可预测性强：每一类任务走哪个模型是确定的，便于调试和审计
成本可控：能精确估算每个路径的 token 消耗
延迟更低：省去了一次额外的 LLM 判断调用
符合安全场景要求：SOC 属于安全领域，可解释性和可追溯性至关重要

Claude Haiku、Sonnet、Opus 是 Anthropic 对其 Claude 模型系列的能力分档命名，分别对应轻量快速低成本、均衡性能中等成本、旗舰推理高成本三个档位，与 OpenAI 的 GPT-4o mini / GPT-4o / o1 系列形成类似的梯度结构。在多模型架构中，这种「能力档位」概念是成本优化的核心抓手：简单分类任务用 Haiku 级别可将单次调用成本压低至旗舰模型的 1/20 甚至更低，在高频调用的 SOC 告警场景中，累计成本差异十分显著。

LLM 驱动的动态选型

第二种方案是让路由器本身调用一个 LLM，由模型根据请求内容动态决定后续该用哪个模型。它的吸引力在于灵活——能处理规则难以覆盖的边缘情况，理论上可以根据语义复杂度做更细粒度的分配。

但代价同样不容忽视：每次路由都要额外增加一次 LLM 调用，带来延迟与成本的叠加；更棘手的是，这引入了不确定性——一个用于「决定用哪个模型」的模型，本身也可能判断错误，而这类错误在安全场景中难以排查。

针对 SOC 场景的建议

结合安全运营的特性，多数经验丰富的架构师会倾向于以规则路由为主、LLM 判断为辅的混合策略。

先用规则覆盖确定性路径

SOC 中大量任务的类型是已知且稳定的。告警等级、事件类型、数据源这些元数据往往足以驱动一套确定的路由规则。将这部分逻辑固化下来，既省钱又稳定，还能满足合规审计对「为什么这个决策由这个模型做出」的追溯需求。

仅在模糊地带引入 LLM 判断

当规则无法明确归类时——比如告警内容模糊、跨越多个研判层级——再回退（fallback）到 LLM 做二次判断。这样既保留了灵活性，又把不确定性和额外成本限制在最小范围内。

让选型标准显式化

无论采用哪种方式，都建议把「任务复杂度 → 模型能力档位」的映射关系显式定义出来。可以为每个 Agent 标注它所需的推理强度，路由器据此匹配对应档位的模型。这种「能力分档 + 显式映射」的设计，比让一个黑盒 LLM 隐式决策要健壮得多。

更深层的工程启示

这个案例折射出 Agentic 系统设计中的一条通用原则：能用确定性逻辑解决的，就不要交给 LLM。LLM 的价值在于处理开放性、语义性的任务，而调度、路由这类结构化决策，规则引擎往往更可靠、更廉价。

在多模型混用（Multi-LLM）成为趋势的当下，模型路由本身正在演变为一个独立的工程课题。目前社区已经出现了一些专门的模型路由框架，核心思路大同小异：用轻量的分类逻辑将请求导向成本与能力匹配的模型，把昂贵的旗舰模型留给真正需要它的复杂任务。对于 SOC 这类兼顾成本、性能与可解释性的场景，从确定性规则起步，再按需引入智能判断，是一条更稳妥的演进路径。

目前社区涌现的模型路由框架中，较具代表性的包括 RouteLLM（由 LMSys 团队开源）和 NotDiamond 等商业服务。RouteLLM 的核心思路是训练一个轻量分类器，根据输入 prompt 的特征预测「是否需要强模型」，从而在准确率损失极小的前提下大幅降低路由到强模型的比例。这类工具将「路由决策」本身从业务逻辑中抽离，形成独立的推断层，与本文建议的「显式映射」思路一脉相承，但提供了更数据驱动的自动化替代方案，可作为规则路由的补充或升级路径。