请务必仔细考虑智能体系统在何处以及如何做出决策。
让 LLM 承担更多决策，可能使系统适用于更多任务，但也可能牺牲速度、可靠性和稳健性。
应尽可能将决策过程从 LLM 中抽离，转化为明确的软件代码。对于高风险和/或生产工作流而言，尤其如此。
设计基于 LLM 的智能体系统时，最重要的选择之一，是确定由 LLM 模型封装的决策范围与由明确软件逻辑承担的决策范围。
为便于理解，可以把这一选择视为介于以下两种方法之间的连续谱：
基于路由器的架构在代码中明确规定顺序和逻辑，确保窄领域任务具有可测试性、可预测性和稳健性（也称为“工作流智能体”）。
编排器智能体依靠大语言模型（LLM）通过自然语言提示动态决定任务流程，适合预定义逻辑不充分或无法预定义的开放式交互。
对于高风险的生产工作流，我们通常建议更多采用基于路由器的功能，并将编排器留给需要灵活通用对话的应用。
基于路由器的架构
路由器智能体系统：
通过代码或软件明确定义决策流程，并使用 LLM 确定软件应选择哪条路径。
更接近传统软件系统，具有清晰且可预测的路径，因此结果也更一致。
非常适合能够严格定义的任务。
以下是一个采用“路由器方法”的航空公司聊天机器人预订智能体简化示例。可以看到，虽然 LLM 会从三个选项中识别问题意图，但最终仍由软件将该意图映射到模板文本回复。由于 LLM 受到严格约束，用户体验到的行为会更加一致。
编排器架构
与路由器系统相比，编排器智能体系统：
通过自然语言提示而非软件来定义逻辑流程。注意：与编程语言相比，自然语言本身具有模糊性和灵活性（正如后文将讨论的，这既是优点也是缺点）。我们将其概括为“表达意图，而非下达指令”。
可以提供多种处理选项，由 LLM 决定执行顺序和方法。
可以动态创建难以在软件中明确规定的新逻辑路径。
这种模糊性可能导致输出不一致，但如果运行顺利，效果会如同“魔法”一般。
以下示例将编排器方法应用于同一个简化的航空公司问题。不再由软件决定哪种回复合适，而是将决策交给 LLM 层。这是一个多智能体系统：由一个“主管”编排器智能体对用户查询进行分流，再转交给专门负责改签航班的智能体，最终由后者向用户回复。
在此示例中，LLM 层同时充当分类器、路由器和回复撰写者。在路由器示例中，它只充当分类器（其余工作由软件处理）。
我们建议尽可能采用基于路由器的方法，因为它具有以下优势：
速度和效率：与依赖外部 API 的编排器相比，本地计算速度更快。此外，在 Python 中处理“IF/ELSE”逻辑也便宜得多，无需付费让 LLM 提供商通过其 4000 亿参数模型处理这些逻辑。
可测试性和可预测性：借助成熟的软件实践，调试、测试和维护要容易得多。
透明度和可靠性：行为变化更少，故障排查更简单。与 LLM 不透明且难以解释的权重相比，应用流程中有更大比例以透明、受版本控制的软件形式呈现。
路由器方法的缺点是可能过于僵化、不够灵活，难以处理更开放的问题。如果聊天机器人总是给出完全相同的回复，用户可能会觉得它乏味、缺乏变化。
编排器设计具备以下强大能力：
规划：可以动态规划回复。
工具选择/智能体交接：选择合适的工具，或将任务委派给智能体。
迭代组合输出：以创造性的方式反复调整并重新组合输出。
判断是否完成：确定收集到的信息何时足以形成最终回复。
使用 Pydantic-AI 或 OpenAI Agents SDK 等框架，可以快速、轻松地实现编排。因此，它非常适合用于演示或概念验证。
这种方法的缺点包括：
无法保证 LLM 的规划步骤及后续操作正确或适当。路由器系统也存在同样的问题，但由于约束更多，其行为更容易预测。
对于简单且定义明确的任务，我们可能并不需要多智能体系统的全部能力。例如，在航空公司智能体示例中，与航空公司客服系统交互的用户实际想要处理的查询类型可能非常有限。
由于 LLM 中包含更多逻辑，恶意行为者更容易对其实施越狱或利用漏洞。
它将决策抽象到 LLM 中，因此更难理解系统的运作方式（不过 Langfuse 或 Braintrust 等监控工具或许能在一定程度上提供帮助）。
读者须知：尽管模型能力正迅速变化，但以下内容短期内不太可能改变。
确定问题的范围。
能否轻松地用图示定义所需的决策逻辑？
应用是否无法容忍失败或意外行为？
以上任一问题的答案为“是”，都意味着路由器功能更合适。
只要条件允许，我们建议优先采用路由器方法。一般原则是：系统中的某个部分如果能用代码表达，就应该用代码表达（即不要在非必要时过度使用 LLM）。
达到这些方法的能力边界后，可以在受约束的条件下复现编排器的部分开放式优势。例如：
工具选择/智能体交接：可通过条件分支或 LLM 分类器轻松实现。
判断是否完成：简单的 LLM 分类器可在向用户返回回复前检查其完整性。
不过，在严格的路由器系统中，“规划”和“迭代组合输出”无疑要难实现得多。因此，当任务需要这些能力时（由 LLM 分类器或其他逻辑判断），我们建议在系统中创建一个限制更少的编排器分支。
选择路由器还是编排器架构，应根据应用的明确程度、复杂度和交互方式来决定。目前，对于定义明确的任务，基于路由器的方法在可靠性、效率和测试便利性方面更具优势。对于范围更广的对话式交互，编排器具有更好的灵活性。
随着 LLM 不断进步，这两种方法之间的平衡可能会发生变化。对于生产工作负载，我们倾向于采用基于路由器的架构或混合架构；编排器则用于需要动态、类人交互的开放式问题。