1. 引言
在构建复杂的 LLM 应用时，“One prompt fits all”（一个提示词解决所有问题）往往是不现实的。处理数学问题需要严谨的推理，而处理创意写作则需要发散的思维。
因此，我们需要一种机制，能够根据用户的输入动态选择最合适的处理链路。这就是条件路由 (Conditional Routing)。
在 LangChain LCEL 中，RunnableBranch是实现这一机制的核心原语。本文将通过两个循序渐进的实战案例，带您掌握从简单的关键词路由到高级的语义路由的实现方法。
2. RunnableBranch 基础原理
RunnableBranch的逻辑非常直观，它等同于编程语言中的if-elif-else结构。
它接收一个包含(condition, runnable)元组的列表，以及一个默认的default_runnable。
branch=RunnableBranch((condition_a,chain_a),# if condition_a is True, run chain_a(condition_b,chain_b),# elif condition_b is True, run chain_bdefault_chain# else, run default_chain)3. 实战一：基于关键词的简单路由
在某些简单场景下，我们可以通过检测输入中是否包含特定关键词来进行路由。
代码解析 (src/examples/chains/demo_branch.py)
在这个例子中，我们要区分“数学问题”和“历史问题”。
# 1. 定义分支逻辑# 使用 lambda 函数检查输入字典中的 "topic" 字段branch=RunnableBranch((lambdax:"math"inx["topic"].lower(),math_chain),(lambdax:"history"inx["topic"].lower(),history_chain),general_chain# 默认分支)# 2. 执行# 输入必须包含明确的 topicawaitbranch.ainvoke({"topic":"math","query":"1+1"})局限性：这种方式依赖于外部显式地提供topic，或者输入中必须包含特定的关键词。如果用户直接问 “1+1 等于几？” 而不包含 “math” 这个词，简单的关键词匹配就会失效。
4. 实战二：基于 LLM 的语义路由 (Semantic Routing)
为了处理自然语言的模糊性，我们需要更智能的路由方式：让 LLM 先读懂意图，再决定去哪里。这就是语义路由。
架构设计
- Router Chain: 一个专门的 LLM 链，负责将用户问题分类（如输出 “math”, “history”）。
- Branch: 根据 Router 的输出结果进行分发。
代码解析 (src/examples/chains/demo_router_chain.py)
第一步：构建分类器 (The Classifier)
router_prompt=PromptTemplate.from_template(""" Classify the question into: math, history, or general. Return ONLY the category name. Question: {query} """)router_chain=router_prompt|llm|StrOutputParser()第二步：构建完整链路
这里我们使用了RunnablePassthrough.assign将 Router 的分类结果注入到数据流中。
full_chain=(# 1. 先调用 Router 获取 topic，并保留原始 query# Output: {"query": "...", "topic": "math"}RunnablePassthrough.assign(topic=router_chain)# 2. 根据 topic 进行路由|RunnableBranch((lambdax:"math"inx["topic"].lower(),math_chain),(lambdax:"history"inx["topic"].lower(),history_chain),general_chain))第三步：智能执行
现在，即使用户的提问中没有关键词，系统也能正确路由：
- Input: “What is the square root of 144?”
- Router: 识别出这是数学计算，输出
topic: "math"。 - Branch: 路由到
math_chain（数学专家）。 - Result: 得到专业的数学解答。
5. 架构延伸：从 Router Chain 到多 Agent 系统
我们在 Demo 中展示的“语义路由”模式，实际上是现代多 Agent 系统 (Multi-Agent System)架构的微缩版。
架构映射 (Pattern Mapping)
| Demo 组件 | 企业级架构对应组件 | 职责 |
|---|---|---|
| Router Chain | Main Agent / Supervisor / Routing Agent | 负责意图识别、任务拆解与分发。它是系统的“大脑”。 |
| Math Chain | GitHub Agent / DevOps Agent | 垂直领域的专家。比如专门负责查询代码、操作 Git。 |
| History Chain | Jira Agent / HR Agent | 另一个领域的专家。比如专门负责查询工单、处理人事流程。 |
| RunnableBranch | Orchestrator / Dispatcher | 负责具体的流量转发逻辑。 |
实际应用场景：DevOps 助手
想象一个企业级的 DevOps 助手，它的工作流程与我们的 Demo 如出一辙：
- 用户输入：“帮我修复 main 分支的构建错误，并更新 Jira 票据。”
- Main Agent (Router)：分析意图，发现需要两个动作。
- 首先调用GitHub Agent查看构建日志。
- 然后调用Jira Agent更新状态。
- 分发与执行：系统根据 Router 的指令，依次激活对应的专业 Agent 进行处理。
意义：通过RunnableBranch和语义路由，我们实现了关注点分离 (Separation of Concerns)。Main Agent 只需要懂“分发”，而具体 Agent 只需要懂“执行”，这使得系统极易扩展和维护。
6. 总结
- RunnableBranch是 LCEL 中实现逻辑分叉的关键组件。
- 关键词路由：简单、快速，适用于规则明确的场景。
- 语义路由：利用 LLM 的理解能力作为“路由器”，是构建智能系统的基石。
- 架构价值：掌握了语义路由，就等于掌握了构建复杂多 Agent 协作系统的核心钥匙。
