在智能客服问答系统中，配置是第一架构决策。是让系统像瑞士军刀一样适应不同场景，还是为每个场景定制一把专用刀？本文通过解析一个某个 FAQ 系统的配置驱动架构与双模式管线设计，展示如何用一套配置体系支撑从精确交互到全自动化的完整服务谱系。

一、为什么需要配置驱动架构？

传统 FAQ 问答系统通常将配置硬编码在业务逻辑中——检索用哪种算法、LLM 用哪个提供商、是否允许 Agent 调用工具，这些决策在代码写死的那一刻就固定了。对于某个同样一套 FAQ 知识库，在不同部署场景下的需求截然不同：

• SaaS 后台嵌入场景：用户是餐厅操作员，问题明确（“如何创建工单”），需要精确匹配和友好交互，但可以容忍一定的延迟。
• API 批量问答场景：上游系统批量推送问题，对吞吐量要求极高，每一步人工确认都是灾难。
• 对内客服辅助场景：客服人员需要 AI 辅助回答，希望系统对模糊问题主动追问，而非直接给出不准确的答案。

如果用硬编码分支来处理这些差异，代码会迅速膨胀为难以维护的"意大利面条"。于是我们设计了配置驱动架构（Configuration-Driven Architecture）——将几乎所有行为决策点提升为配置项，通过 .env 文件和配置类统一管理，实现"一套代码，多种行为模式"。

二、配置体系总览

2.1 配置管理核心

整个系统的配置集中在 config.py（约 867 行）中。核心设计思想是：

环境变量驱动 + 配置类封装 + 运行时发现

# 伪代码示意
class Settings(BaseSettings):
    SERVICE_MODE: str = "interactive"  # 核心模式开关
    RETRIEVE_MODE: str = "navigate"   # 检索模式开关
    TOOL_USE_STRATEGY: str = "react"  # 工具使用策略
    LLM_PROVIDER: str = "openai"      # 默认LLM提供商
    
    # ... 数百行配置项

2.2 九大配置分类

所有配置项按照职责划分为九个类别，每一类对应一个独立的功能模块：

配置分类	职责范围	典型配置项
系统配置	基础运行参数	SERVICE_MODE、DEBUG、LOG_LEVEL
检索配置	检索引擎行为	RETRIEVE_MODE、TOP_K、SCORE_THRESHOLD
匹配配置	匹配算法参数	MATCHER_TYPE、HYBRID_WEIGHT
Agentic 配置	AI 自主行为	TOOL_USE_STRATEGY、MAX_ITERATIONS
记忆配置	记忆管理	MEMORY_ENABLED、MEMORY_TTL
历史配置	对话历史管理	HISTORY_LIMIT、SESSION_TTL
网络搜索配置	联网能力	WEB_SEARCH_ENABLED、SEARCH_API_KEY
日志配置	日志与监控	LOG_FORMAT、LOG_FILE、METRICS_ENABLED
工具配置	外部工具注册	TOOL_ALLOW_LIST、TOOL_TIMEOUT

这种分类方式带来的好处是：任何新功能的引入只需要增加一个配置分类，而不需要改动已有的业务逻辑。新开发者看配置分类就能快速理解系统提供了哪些能力。

三、双模式设计——interactive vs autonomous

配置体系中最核心的开关是 SERVICE_MODE，它将系统划分为两种截然不同的运行模式。

3.1 模式对比

维度	Interactive（交互式）	Autonomous（AI 自主）
设计哲学	精确优先	速度优先
核心策略	追问确认 + AI 自主兜底	策略路由 + 质量门控
用户交互	多轮追问，逐步收窄	单轮完成，自主决策
延迟	较高（多轮交互）	较低（一次完成）
适用场景	SaaS 后台、客服辅助	API 批量、内部自动化
容错策略	用户确认消除模糊性	质量门控兜底不准确回答

3.2 选择依据

在代码层面，SERVICE_MODE 的取值决定了系统初始化时加载哪一套管线：

if SERVICE_MODE == "interactive":
    pipeline = InteractivePipeline()
elif SERVICE_MODE == "autonomous":
    pipeline = AutonomousPipeline()

但选择并非固定——同一套部署可以通过环境变量实时切换，开发环境用 interactive 模式方便调试，生产环境用 autonomous 模式保障性能。

四、Interactive 管线详解

交互式管线是系统的"高精度模式"，通过多轮人机交互逐步消除问题中的歧义。完整的管线包含九个阶段：

用户输入
    │
    ▼
┌─────────────────────┐
│ ① 问题优化           │  ← 指代消解 + 省略补全
│    (Question Refine) │
├─────────────────────┤
│ ② 意图分类           │  ← chitchat / conversational / knowledge
│    (Intent Classify) │
├─────────────────────┤
│ ③ 预检索追问         │  ← 宽泛问题 → 选项收窄
│    (Pre-Retrieve Ask)│
├─────────────────────┤
│ ④ 检索               │  ← 记忆库 + 三种检索模式
│    (Retrieve)        │
├─────────────────────┤
│ ⑤ 检索后追问         │  ← 模糊结果 → 选项消歧
│    (Post-Retrieve Ask)│
├─────────────────────┤
│ ⑥ 润色               │  ← 根据角色生成最终回答
│    (Polish)          │
├─────────────────────┤
│ ⑦ 评分收集           │  ← 收集用户反馈
│    (Rating)          │
├─────────────────────┤
│ ⑧ AI 自主兜底        │  ← 以上均未命中时LLM生成
│    (AI Fallback)     │
└─────────────────────┘
    │
    ▼
   最终回答

4.1 第一阶段：问题优化

用户的原始输入往往包含指代词和省略结构——"那审核流程呢？"中的"那"和"呢"如果不处理，检索引擎会一头雾水。

问题优化阶段使用 LLM 进行指代消解（Coreference Resolution） 和省略补全（Ellipsis Completion）：

• 输入：“那审核流程呢？”
• 对话历史：“如何创建工单？→ 创建工单的步骤是…”
• 输出优化后问题：“工单的审核流程是什么？”

4.2 第二阶段：意图分类

优化后的问题进入意图分类器，分为三类：

• chitchat（闲聊）：问候、感谢、告别——直接返回友好回复，跳过后续所有检索流程
• conversational（会话）：需要结合对话上下文的业务问题——进入完整检索管线
• knowledge（知识）：独立的知识库查询——直接进入检索阶段

4.3 第三阶段：预检索追问

当问题被判定为"宽泛"（如"告诉我系统X的功能"）时，系统不会盲目检索，而是先向用户提问以收窄范围：

系统："系统X包含以下模块，请问您想了解哪个？

1. 工单创建
2. 供应商管理
3. 入库验收
4. 统计报告统计"

这种"先问清楚再检索"的策略，避免了检索引擎在模糊查询中召回大量不相关的内容。

4.4 第四阶段：检索

检索阶段同时查询两个数据源：

1. 记忆库（L2 评分记忆）：优先从高分问答记录中查找
2. 知识库：使用三种检索模式（navigate/index/direct）进行多路召回

关于检索的详细设计，请参考本系列第三篇《五种检索引擎与混合匹配架构》。

4.5 第五阶段：检索后追问

当检索结果匹配度不高或存在多个候选答案时，系统再次发起追问进行消歧：

用户：“如何设置工单审批？”
系统：“您是指工单的审批流程还是审批权限设置？请选择：
A. 审批流程设置
B. 审批权限分配”

4.6 第六阶段：润色

检索到准确答案后，LLM 根据当前角色设定对答案进行润色——"专业客服"风格 vs "技术文档"风格，由配置项 PERSONA 控制。

4.7 第七阶段：评分收集

每轮交互结束时，系统会主动邀请用户评分（👍/👎）。评分结果会写入 L2 记忆库，用于未来类似问题的直接复用。

4.8 第八阶段：AI 自主兜底

如果以上七个阶段都没有找到满意的答案（用户对检索结果不满意、评分低），系统触发AI 自主兜底机制——LLM 不使用检索结果，而是基于自身知识生成回答。这在某个 FAQ 中虽然罕见（因为知识库覆盖了所有产品操作问题），但作为最后一道防线，保证了系统不会"哑火"。

五、Autonomous 管线详解

自主管线的设计目标是速度优先、最少交互。它没有交互式管线的九阶段精细流程，而是采用了更简洁的三阶段架构：

用户输入
    │
    ▼
┌─────────────────────┐
│ ① 策略路由           │  ← planner.py 路由至 skip/A/B/C/D
│    (Strategy Router) │
├─────────────────────┤
│ ② 执行               │  ← 检索调用 / 工具调用 / LLM生成
│    (Execution)       │
├─────────────────────┤
│ ③ 质量门控           │  ← 评估答案质量，决定返回or重试
│    (Quality Gate)    │
└─────────────────────┘
    │
    ▼
   最终回答

5.1 策略路由

策略路由是 autonomous 管线的核心决策点，由 planner.py 实现。LLM 作为路由决策者，从五种策略中选出最优路径：

策略	名称	适用场景	行为
skip	跳过	闲聊问候	直接回复，不检索
A	单步检索	简单知识查询	一次检索 + 回答
B	单步工具	简单操作查询	一次工具调用
C	多步计划	复杂多步骤问题	规划 → 分步执行
D	检查型计划	需自检的复杂问题	规划 → 执行 → 自检

路由决策基于以下信号：

• 问题复杂度（长度、实体数量、动词数量）
• 是否需要外部工具
• 是否需要跨章节/跨系统知识

5.2 执行阶段

根据路由结果执行具体操作：

• skip：LLM 直接生成问候语
• A：调用检索引擎，使用配置的 RETRIEVE_MODE
• B：调用注册的外部工具（如查询订单状态 API）
• C/D：进入 ReAct 循环，按计划分步执行

5.3 质量门控

与 interactive 模式依赖用户确认不同，autonomous 模式使用自动质量门控（Quality Gate） 来评估答案质量：

1. 完整性检查：答案是否覆盖了用户问题的所有方面
2. 相关性检查：答案是否与问题直接相关，有无幻觉
3. 置信度评分：综合评分低于阈值则重新执行或降级

质量门控的设计借鉴了"自我校验"思想——让 LLM 同时担任执行者和评估者的角色。如果质量门控连续三次失败，系统会返回一个预设的兜底回答，避免无限循环。

六、三大可切换系统

配置体系中最具灵活性的是三个可独立切换的子系统，它们共同构成了系统的"行为立方体"：

# 三个互不依赖的可切换系统
SERVICE_MODE    = "interactive" | "autonomous"
RETRIEVE_MODE   = "direct" | "navigate" | "index"
TOOL_USE_STRATEGY = "react" | "auto"

6.1 SERVICE_MODE

如前所述，决定系统走交互式还是自主管线。这是最高层的决策开关。

6.2 RETRIEVE_MODE

控制检索引擎的行为模式，有三种选择：

• direct（直接检索）：将问题直接送入检索引擎，不做任何预处理。适合精确、简短的问题。
• navigate（导航式检索）：先对问题进行知识图谱导航，确定目标章节和文档范围，再执行检索。适合需要跨章节的复杂问题。
• index（索引式检索）：基于预构建的倒排索引进行检索，速度最快但召回率较低。适合高吞吐场景。

6.3 TOOL_USE_STRATEGY

控制 LLM 如何与外部工具交互：

• react（ReAct 循环）：推理 → 行动 → 观察 → 推理的经典循环，每一步都进行推理决策。准确率高但 Token 消耗大。
• auto（自动模式）：LLM 自主判断何时调用工具，一次推理后可能连续调用多个工具。效率高但可解释性较低。

这三个系统可以自由组合，产生 2 × 3 × 2 = 12 种行为模式，足以应对绝大多数业务场景。

七、多 LLM 提供商自动发现

在 AI 系统的实际部署中，LLM 提供商的选择往往受限于成本、延迟、可用性等因素。我们的配置系统设计了一个智能的提供商发现机制 _discover_providers()：

_discover_providers() 发现逻辑
    │
    ├── 检查环境变量 OPENAI_API_KEY → 注册 openai
    ├── 检查环境变量 ANTHROPIC_API_KEY → 注册 anthropic
    ├── 检查环境变量 DEEPSEEK_API_KEY → 注册 deepseek
    ├── 检查环境变量 OLLAMA_BASE_URL → 注册 ollama
    └── 检查环境变量 CUSTOM_N_API_KEY → 注册 custom_N

这种设计的好处是：

1. 零配置集成：只要设置对应的 API Key，提供商就会被自动发现和注册，无需修改任何代码
2. 运行时切换：可以在不重启服务的情况下切换 LLM 提供商
3. 优雅降级：当首选提供商不可用时，自动尝试备用提供商
4. 扩展友好：新增一个提供商只需增加一个环境变量检查分支

# 伪代码: 自动发现已配置的 LLM 提供商
def discover_providers():
    """从环境变量中自动发现并初始化所有已配置的 LLM 提供商"""
    providers = {}
    
    # 检查标准提供商的环境变量，存在则注册
    if env_var_exists("OPENAI_API_KEY"):
        providers["openai"] = create_provider("openai")
    if env_var_exists("ANTHROPIC_API_KEY"):
        providers["anthropic"] = create_provider("anthropic")
    if env_var_exists("DEEPSEEK_API_KEY"):
        providers["deepseek"] = create_provider("deepseek")
    if env_var_exists("OLLAMA_BASE_URL"):
        providers["ollama"] = create_provider("ollama")
    
    # 支持自定义提供商 CUSTOM_1 ~ CUSTOM_N（无限扩展）
    for i in range(1, MAX_CUSTOM_PROVIDERS + 1):
        if env_var_exists(f"CUSTOM_{i}_API_KEY"):
            providers[f"custom_{i}"] = create_custom_provider(i)
    
    return providers

在生产环境中，这种设计允许系统同时接入多个 LLM 提供商，根据任务类型选择合适的模型——简单检索用便宜的模型，复杂推理用高性能模型。

八、Web 部署架构

系统通过 web_main.py 提供 Web 部署入口，采用 FastAPI 框架构建 RESTful API。部署架构的核心设计是配置驱动的多模式服务：

web_main.py
    │
    ├── /api/chat          ← Interactive 模式 API
    │   ├── 支持多轮对话 (session_id)
    │   ├── 支持追问确认
    │   └── 返回流式结果
    │
    ├── /api/query         ← Autonomous 模式 API
    │   ├── 单轮问答
    │   ├── 高速响应
    │   └── 返回完整结果
    │
    ├── /api/config        ← 配置查看/更新 API
    │   ├── 运行时查看当前配置
    │   └── 管理员更新配置
    │
    └── /api/memory        ← 记忆管理 API
        ├── 查看L2记忆库
        └── 手动导入/删除记忆

通过 Web API，前端可以根据业务场景自由选择调用 Interactive 还是 Autonomous 端点，甚至在同一应用中混用两条管线。

九、总结

配置驱动架构与双模式管线的设计，回答了智能客服系统中的一个根本问题：如何在同一套代码基础上，同时满足"精确"和"高效"这两种看似矛盾的需求？

我们的答案是：

1. 将行为决策点从代码提升到配置层——通过九大配置分类覆盖系统的所有可调节维度
2. 设计两条独立的管线——Interactive 用多轮交互换取精确性，Autonomous 用策略路由和门控机制换取效率
3. 提供三个可独立切换的子系统——SERVICE_MODE × RETRIEVE_MODE × TOOL_USE_STRATEGY 组合出 12 种行为模式
4. 自动化 LLM 提供商发现——让系统灵活适应不同部署环境

这套架构经过FAQ 系统的生产验证，在两个关键指标上取得了令人满意的结果：

• Interactive 模式：问题首次解决率（FCR）提升 40%+
• Autonomous 模式：API 端到端延迟降低 60%+

配置驱动不是银弹，但当你的系统需要同时服务多种场景时，它提供了一条可维护、可扩展、可观察的路径。下一篇文章我们将深入剖析系统的工具调用机制与 ReAct 循环优化。

---

本系列文章索引：

• 01: Agent 记忆分层设计实践
• 02: 多策略路由的智能客服系统设计
• 03: 五种检索引擎与混合匹配架构
• 06: 配置驱动架构与双模式管线（本文）