构建基于大语言模型（LLM）的应用时，架构选择直接决定了系统的可靠性、可维护性和成本。从简单的单次调用到复杂的多智能体协作，每种模式都有其适用场景和权衡。本文梳理从单体到流水线、从无状态到有状态、从无工具到多工具的常见架构模式，并给出选型建议。

单体模式：最简起点

核心思路：将用户输入直接传给 LLM，返回结果。无外部数据、无工具调用、无状态管理。

适用场景：原型验证、简单问答、内容生成（如翻译、摘要）。

优点：实现最快，延迟最低，成本可控。

缺点：无法处理需要实时数据或外部知识的问题；LLM 幻觉风险高；无上下文记忆。

python
伪代码示例：单体模式
def simple_chat(user_input: str) -> str:
    response = llm.generate(user_input)
    return response

关键取舍：单体模式是起点，但几乎不适用于生产级应用。一旦需要引用外部数据或执行动作，就必须引入其他模式。

检索增强生成（RAG）：解决知识边界

RAG 模式在 LLM 调用前增加检索步骤，从外部知识库（如向量数据库、搜索引擎）获取相关文档，作为上下文注入 prompt。

架构流程：用户输入 → 检索（embedding + 向量搜索）→ 构建 prompt（含检索结果）→ LLM 生成 → 返回。

适用场景：客服知识库、企业文档问答、法律/医疗合规查询。

优点：降低幻觉，可引用来源，知识可更新（无需重训模型）。

常见坑：

- 检索质量差：chunk 大小、重叠策略、embedding 模型选择直接影响召回率。 - 上下文窗口溢出：检索结果过多会撑爆 token 限制，需做重排序（rerank）或截断。 - 延迟增加：检索步骤通常增加 200-500ms 延迟，需考虑缓存。

python
伪代码示例：RAG 模式
def rag_answer(query: str) -> str:
    docs = vector_store.similarity_search(query, k=5)
    context = "\n".join([doc.text for doc in docs])
    prompt = f"基于以下资料回答：\n{context}\n问题：{query}"
    return llm.generate(prompt)

选型建议：RAG 是当前最成熟的知识增强方案。若知识库规模大（百万级文档），需考虑分片策略和索引优化；若对实时性要求高，可结合缓存。

工具调用/函数调用：赋予 LLM 行动能力

工具调用（Tool Calling）让 LLM 能够调用外部 API、数据库、计算器或代码解释器。模型输出结构化 JSON 描述要调用的函数及其参数，由应用层执行并返回结果。

架构流程：用户输入 → LLM 决定调用哪个工具（输出函数名+参数）→ 应用执行工具 → 结果回传给 LLM → 生成最终回答。

适用场景：天气查询、数据库查询、代码执行、发送邮件、调用第三方 API。

优点：扩展 LLM 能力边界，可执行精确计算或操作真实系统。

常见坑：

- 工具定义不清晰：函数描述、参数类型、示例值需精确，否则 LLM 会误解。 - 循环调用风险：LLM 可能反复调用同一工具，需设置最大调用次数或超时。 - 安全边界：工具调用可能执行危险操作（如删除数据），需做权限校验和输入过滤。

python
伪代码示例：工具调用
def handle_tool_call(user_input: str) -> str:
    response = llm.generate_with_tools(user_input, tools=[get_weather, search_db])
    if response.tool_call:
        result = execute_tool(response.tool_call)
        return llm.generate(f"工具返回：{result}，请回答用户")
    return response.text

选型建议：工具调用是构建 Agent 的基础。若应用需要执行多步操作（如先查数据库再发邮件），需配合状态管理。

Agent 模式：多步推理与自主决策

Agent 模式让 LLM 在循环中自主决定下一步动作：思考 → 调用工具 → 观察结果 → 继续推理，直到完成任务或达到终止条件。

架构流程：用户目标 → LLM 规划（如 ReAct、Plan-and-Solve）→ 执行工具 → 观察 → 再规划 → 终止。

适用场景：复杂任务（如预订旅行、数据分析、代码调试）、需要多步推理的场景。

优点：高度灵活，可处理开放式任务。

常见坑：

- 成本不可控：Agent 可能调用数十次 LLM，token 消耗巨大。 - 错误累积：早期步骤的错误会传播到后续推理。 - 循环死锁：需设置最大迭代次数或超时回退。

选型建议：Agent 模式适合探索性任务，但对可靠性要求高的生产系统需谨慎。可考虑“受限 Agent”：限定工具集、步骤数、输出格式。

路由模式：智能分流

路由模式（Model Router）根据输入特征（如意图、语言、复杂度）将请求分发到不同的处理流程或模型。

架构流程：输入 → 分类器（可以是 LLM 或轻量模型）→ 路由到对应 handler（如 RAG、Agent、简单问答）。

适用场景：多语言支持、不同复杂度任务分流（简单问题用小模型，复杂问题用大模型）、A/B 测试。

优点：优化成本（小模型处理简单请求），提升响应速度。

常见坑：

- 路由规则过细：维护成本高，可考虑用 LLM 做动态路由。 - 分类错误：路由错误会导致用户体验下降，需设置 fallback 策略。

python
伪代码示例：路由模式
def route_request(user_input: str) -> str:
    intent = classify_intent(user_input)  # 可用 LLM 或分类模型
    if intent == "faq":
        return rag_answer(user_input)
    elif intent == "calculation":
        return tool_call_answer(user_input)
    else:
        return simple_chat(user_input)

缓存模式：降本增效

缓存模式在 LLM 调用前检查是否已有相同或相似请求的结果。

类型：

- 精确缓存：完全相同的 prompt 返回缓存结果。 - 语义缓存：基于 embedding 相似度匹配，相似问题返回相同答案。

适用场景：高频重复问题（如 FAQ）、模板化生成。

优点：大幅降低延迟和成本（缓存命中可节省 90%+ 成本）。

常见坑：

- 缓存过期：知识更新后需失效旧缓存。 - 语义缓存误匹配：相似但不同的问题可能得到错误答案。

评估与护栏：保障质量与安全

评估（Evals）：在开发和生产中持续评估 LLM 输出质量。常见维度：准确性、相关性、安全性、格式合规。可构建测试集，用 LLM-as-judge 或人工标注。

护栏（Guardrails）：在输入和输出端设置规则，防止有害内容或格式错误。例如：输入过滤（敏感词）、输出校验（JSON 格式、长度限制）、内容安全检测。

选型建议：评估和护栏应作为基础设施，而非事后补救。建议在 CI/CD 中集成评估流水线，在生产中部署实时护栏。

可观测性：理解系统行为

LLM 应用的黑盒特性要求更强的可观测性。关键指标：延迟、token 消耗、工具调用次数、错误率、用户满意度。常用工具：OpenTelemetry、LangSmith、自定义日志。

常见坑：仅记录输入输出，忽略中间步骤（如检索结果、工具调用链）。建议记录完整 trace，包括 prompt 模板、检索文档、工具返回值。

单体 vs 流水线：架构风格对比

维度单体模式流水线模式

结构单次 LLM 调用多步骤链式处理 灵活性低高（可替换/组合步骤） 调试难度低高（需追踪每步） 典型场景简单问答RAG、Agent、多模态处理

选型建议：从单体开始，当需要引入外部知识或工具时，逐步拆分为流水线。不要过早抽象。

选型综合建议

从最简开始：先实现单体模式，验证核心逻辑。

按需引入：需要知识 → 加 RAG；需要行动 → 加工具调用；需要多步推理 → 加 Agent。

成本与延迟：用路由模式分流简单请求，用缓存模式减少重复计算。

安全与质量：评估和护栏是生产级应用的必备组件。

可观测性：从第一天起记录 trace，否则问题难以定位。

---

FAQ

Q1: RAG 和微调有什么区别？什么时候用 RAG？ A: RAG 在推理时检索外部知识，适合知识频繁更新或需要引用来源的场景。微调改变模型行为（如风格、格式），适合固定知识或特定输出格式。RAG 更灵活，微调更稳定。

Q2: Agent 模式中如何防止无限循环？ A: 设置最大迭代次数（如 10 步）、超时时间（如 30 秒）、以及“无进展”检测（连续相同工具调用）。建议在 Agent 循环中加入“思考”步骤的 token 限制。

Q3: 语义缓存和精确缓存哪个更好？ A: 取决于场景。精确缓存零误匹配，但命中率低。语义缓存命中率高，但有误匹配风险。生产环境建议两者结合：先查精确缓存，再查语义缓存，并设置相似度阈值。

Q4: 路由模式中如何选择分类器？ A: 简单场景用规则（如关键词匹配）或轻量分类模型（如 fastText）。复杂场景用 LLM 做动态路由（但成本高）。建议先用规则兜底，再逐步引入模型。

Q5: 评估 LLM 输出时，如何避免“LLM-as-judge”的偏见？ A: 使用多个 judge 模型投票、引入人工抽检、定义明确的评分标准（如“是否包含事实错误”而非“是否好”）。也可用对比评估（A/B 测试）替代绝对评分。

*最后更新：2026 年 7 月。请以各工具官方文档为准。*