这类大模型面试题集，最核心的价值不是让你背答案，而是帮你快速理清一个复杂技术栈里，哪些是高频考点，哪些是实际落地时最容易混淆的概念。特别是当“Langfuse追踪评估”、“LangChain”、“LangGraph”、“RAG”、“Agent”这些词堆在一起时，新手很容易迷失在工具和框架的海洋里，分不清它们各自解决什么问题，以及如何协同工作。

这篇文章会围绕“2026大模型面试100问”这个主题，但不会简单罗列100个问题。我会以一个面试官和一线开发者的双重视角，帮你拆解这些技术栈的核心脉络、高频考点和实战避坑点。目标是让你看完后，不仅能应对面试中关于“区别”、“原理”、“场景”的提问，更能建立起一套清晰的工程化思维：什么时候该用哪个工具，如何评估效果，以及如何排查问题。

1. 先理清核心工具栈：LangChain、LangGraph、Langfuse 各自扮演什么角色？

面试中最常见的第一类问题就是：“请说一下 LangChain、LangGraph 和 Langfuse 的区别与联系”。很多人会陷入功能罗列，但更有效的回答是讲清楚它们在应用开发生命周期中的不同定位。

1.1 LangChain：应用开发的“脚手架”和“粘合剂”

LangChain 的核心定位是简化大模型应用的构建流程。它不是一个运行时，而是一个开发框架。

• 它解决了什么：在没有 LangChain 之前，你要连接大模型 API、处理文本分割、管理向量数据库、设计提示词模板、调用外部工具，需要写大量胶水代码。LangChain 把这些通用模式抽象成了可复用的组件（如 LLM、PromptTemplate、Chains、Agents、Retrievers）。
• 关键理解：你可以把 LangChain 想象成 Web 开发中的 Spring 或 Django。它提供了标准化的方式来组织你的代码逻辑。它的Chain是把多个组件按顺序组合起来的工作流。它的Agent是让 LLM 能够动态决定调用哪些工具（包括 Chains）的决策器。
• 面试高频点：
  • LCEL (LangChain Expression Language)：这是 LangChain 最新的、推荐的链式构建方式。面试官可能会让你对比传统的LLMChain和基于 LCEL 的链写法。
  • Tools 和 Toolkits：如何为 Agent 自定义工具？StructuredTool和普通Tool的区别？工具调用的性能受什么影响？（答案通常是：网络延迟、LLM 生成速度、工具本身执行耗时）。
  • Memory：ConversationBufferMemory,ConversationSummaryMemory等不同记忆类型的适用场景。
  • 与原生 LLM Function Call 区别：LangChain 的 Tool Calling 是对各大模型厂商 Function Calling 能力的一层抽象和统一封装，使其接口一致，并方便与 LangChain 的 Agent 框架集成。速度主要受封装层开销、网络及 LLM 本身影响。

1.2 LangGraph：复杂、有状态工作流的“编排引擎”

LangGraph 是构建在 LangChain 之上的一个库，用于创建有环、有状态、可持久化的复杂工作流。

• 它解决了什么：传统的 LangChainChain是线性或简单分支的，难以描述像“多轮对话”、“审批流程”、“循环检查直到条件满足”这类带有状态和循环的复杂场景。LangGraph 引入了图（Graph）的概念，节点是处理步骤，边是流转条件，并且维护一个全局的State对象。
• 关键理解：如果 LangChain 的 Chain 是“管道”，那么 LangGraph 就是“流程图”或“状态机”。它特别适合构建复杂的 Agent（比如 ReAct 模式，需要“思考-行动-观察”循环）、多角色协作系统、或任何需要根据中间结果动态改变执行路径的应用。
• 面试高频点：
  • State 设计：StateGraph中State对象的 Schema 如何定义？如何通过Reducer（如add_messages）来更新状态？这是理解 LangGraph 的核心。
  • 节点（Node）与边（Edge）：如何定义节点函数？条件边（conditional_edges）和普通边（add_edge）如何使用？
  • 编译与执行：graph.compile()之后得到的是一个可执行对象，通过.invoke()或.stream()来运行。stream()可以实时看到每个节点的输出，用于调试。
  • 如何暂停/取消：LangGraph 本身没有内置的“暂停”API。通常需要在节点逻辑中检查外部标志位，或通过持久化Checkpointer来实现状态的保存与恢复，间接达到“暂停”效果。stream()的终止也是通过外部中断（如键盘中断）或节点中抛出异常来实现。
  • 与 LangChain 的关系：LangGraph 可以独立使用，但它与 LangChain 生态无缝集成。你可以使用 LangChain 的 LCEL、Tools、Models 作为 LangGraph 节点的一部分。

1.3 Langfuse：应用生产部署的“监控和评估平台”

Langfuse 是一个独立的、开源可自部署的可观测性（Observability）和评估（Evaluation）平台。它和 LangChain/LangGraph 不是替代关系，而是互补关系。

• 它解决了什么：当你的 AI 应用上线后，你需要知道：用户问了什么？模型回答了啥？整个调用链（Chain/Graph）每一步花了多长时间？消耗了多少 Token？最终答案的质量如何？Langfuse 通过 SDK 自动或手动插桩，收集这些**追踪（Trace）**数据，并提供可视化、分析和评估功能。
• 关键理解：LangChain/LangGraph 帮你构建应用，Langfuse 帮你监控、调试和优化运行中的应用。它类似于 Web 开发中的 APM（应用性能监控）工具，如 Datadog 或 New Relic，但是专为 LLM 工作流设计。
• 面试高频点：
  • Trace, Span, Generation：这三个核心概念的关系。一个 Trace 是一次完整的请求（如一次用户问答），里面包含多个 Span（如“检索”、“生成”等步骤），每个 Span 下可能有具体的 Generation（LLM 调用详情）。
  • 集成方式：如何通过Langfuse回调处理器（CallbackHandler）集成到 LangChain/LangGraph 应用中？环境变量LANGFUSE_SECRET_KEY和LANGFUSE_PUBLIC_KEY的作用是什么？
  • 评估（Evaluation）：这是 Langfuse 的强项。评估分为：
    • 手动评估：在后台界面人工对结果打分、写评语。
    • 自动评估：利用 LLM（如 GPT-4）作为裁判，根据你定义的评分标准（相关性、正确性、有害性等）或通过对比（pairwise）来自动打分。
    • 分类评估：针对输出结果进行多分类判断。
  • 生产价值：能帮助定位瓶颈（是检索慢还是生成慢？）、分析成本（哪个提示词最耗 Token？）、评估效果（新模型或新提示词是否比旧版本好？）。

一句话总结关系：用LangChain组装你的零件（模型、工具、记忆），用LangGraph设计复杂的流水线（带状态和循环），用Langfuse给整个流水线装上监控摄像头和质检仪。

2. 深入核心场景：RAG 与 Agent 的面试题如何拆解？

“RAG”和“Agent”是当前大模型应用的两大核心范式，也是面试的绝对重点。问题往往不会直接问定义，而是结合场景和问题。

2.1 RAG（检索增强生成）场景题与八股文

RAG 的面试题通常围绕“效果优化”和“故障排查”。

• 场景题示例：“我们做了一个知识库问答系统，但用户经常反馈答案不准确或包含幻觉，你会从哪些方面进行优化？”

  • 不要一上来就谈换模型。应该遵循一个排查优化路径：
    1. 检索阶段：
       • 文本分割：你的chunk_size和chunk_overlap设置是否合理？对于技术文档，小片段（200-300字）可能更好；对于连贯叙事，可以大一些。重叠是为了避免上下文断裂。
       • 嵌入模型：是否使用了适合你语料领域和语言的嵌入模型？text-embedding-ada-002是通用选择，但对于中文或专业领域，BGE、M3E可能更优。评估检索效果是关键，可以计算检索结果的召回率。
       • 检索器：是简单的向量相似度检索，还是融合了关键词（BM25）的混合检索？后者能提高召回率。
       • 检索数量（k）：top_k值是多少？太小可能漏掉关键信息，太大可能引入噪声。可以尝试动态调整 k。
    2. 生成阶段：
       • 提示词工程：你的系统提示词是否明确要求“仅根据上下文回答”、“不知道就说不知道”？是否将检索到的上下文清晰、无丢失地传递给 LLM？
       • 上下文压缩/重排：检索到的多个片段是否直接拼接？可以引入ContextualCompressionRetriever或LLMChainExtractor来压缩无关信息，或用CohereRerank等对片段进行重排，只把最相关的交给 LLM。
    3. 整体评估：
       • 如何量化评估 RAG 的效果？不能只靠人工看。要定义评估指标，如答案相关性（Answer Relevance）、上下文忠实度（Faithfulness）、答案正确性（Answer Correctness）。这正是Langfuse等工具可以大显身手的地方，实现自动化评估。

• 八股文要点：

  • RAG 完整流程：文档加载 -> 文本分割 -> 向量化 -> 存储到向量数据库 -> 用户查询 -> 查询向量化 -> 检索相似片段 -> 组合提示词 -> LLM 生成答案。
  • 向量数据库选型：Chroma（轻量，开发），Pinecone/Weaviate（云服务，生产），PGVector（与 Postgres 生态结合）。选择时考虑维度、过滤能力、吞吐量、成本。
  • Self-Querying Retriever：让 LLM 将用户自然语言查询解析成向量搜索的过滤条件（如元数据过滤），用于“找去年三月份的销售报告”这类查询。

2.2 Agent（智能体）场景题与实战要点

Agent 的核心是“让 LLM 学会使用工具”。

• 场景题示例：“设计一个旅行规划 Agent，它可以根据用户需求查询天气、航班和酒店信息，并生成一份计划。”

  • 拆解思路：
    1. 工具定义：需要三个工具（或三个 Chain）：get_weather(city, date)，search_flights(from, to, date)，find_hotels(city, date)。每个工具都要有清晰的描述（description），供 LLM 理解其功能。
    2. Agent 类型选择：LangChain 提供了多种 Agent 类型。对于需要多步推理的，ReAct类型是经典选择。对于 OpenAI 最新模型，OPENAI_FUNCTIONS或STRUCTURED_CHAT类型可能更高效。
    3. 工作流设计：这是一个典型的有状态、多步骤、可能循环的场景。用户可能说“先看天气，如果下雨就换城市”。这用简单的 Chain 很难描述，但用LangGraph就非常合适。你可以设计一个图，节点包括“解析需求”、“查询天气”、“决策是否换城市”、“查询航班”、“查询酒店”、“汇总报告”，边根据天气结果进行条件流转。
    4. 记忆（Memory）：用户可能在规划中多次交互（“把酒店预算调高一点”）。需要在State中维护对话历史和当前规划状态。
    5. 评估与追踪：这个 Agent 的决策过程复杂，必须用Langfuse进行追踪。记录每一次工具调用、LLM 的思考过程、最终输出，并评估其规划是否合理、工具调用是否准确。这对于调试和优化至关重要。

• 实战避坑点：

  • 工具描述要精准：模糊的描述会导致 LLM 错误调用工具。
  • 控制“幻觉”和无限循环：设置max_iterations或max_execution_time来限制 Agent 的最大步数，防止陷入死循环。
  • 错误处理：工具调用可能失败（API 超时、无结果）。Agent 或 Graph 节点中需要有错误处理逻辑，比如重试或返回友好提示。
  • 成本与延迟：每一次工具调用和 LLM 思考都增加成本和延迟。在设计时要权衡，是否有些信息可以并行获取？是否有些步骤可以简化？

3. 从零搭建一个可追踪、可评估的 LangGraph Agent 实战

理论说再多，不如一个具体例子。我们以“一个能查询天气并决定是否建议外出的简单 Agent”为例，串联起 LangChain、LangGraph 和 Langfuse。

注意：以下为概念性代码和步骤，旨在展示思路。实际运行需要安装相应包并配置 API Key。

3.1 环境准备与工具定义

首先，定义我们的核心工具：一个模拟的天气查询工具。

# 安装核心库 # pip install langchain langchain-openai langgraph langfuse import os from typing import TypedDict, Annotated, Literal from langchain_core.tools import tool from langchain_openai import ChatOpenAI # 1. 定义工具 @tool def get_weather(city: str) -> str: """查询指定城市的天气情况。""" # 模拟实现，真实情况调用天气API weather_data = { "北京": "晴，15-25°C，微风", "上海": "多云，18-28°C，东南风3级", "广州": "雷阵雨，25-32°C，南风4级", } return weather_data.get(city, f"未找到{city}的天气信息。") # 初始化LLM llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) tools = [get_weather] llm_with_tools = llm.bind_tools(tools)

3.2 用 LangGraph 构建有状态的 Agent 工作流

我们将构建一个包含“思考”、“行动”、“评估”三个核心节点的图。

from langgraph.graph import StateGraph, END from langgraph.prebuilt import ToolExecutor, ToolInvocation import operator # 2. 定义状态结构 class AgentState(TypedDict): messages: Annotated[list, operator.add] # 消息历史 next: Literal["think", "act", "evaluate", "__end__"] # 下一步该去哪个节点 # 3. 创建图和节点 graph_builder = StateGraph(AgentState) # 工具执行器 tool_executor = ToolExecutor(tools) def think_node(state: AgentState): """思考节点：让LLM分析当前对话，决定下一步是行动还是结束。""" # 基于对话历史，让LLM决定下一步 system_prompt = """你是一个天气助手。根据对话历史，决定下一步： - 如果用户提供了一个城市名且你还没有查询天气，就决定去“act”查询天气。 - 如果已经查询了天气，或者用户的问题与天气无关，就决定去“__end__”结束。 只返回“act”或“__end__”。""" prompt = f"{system_prompt}\n\n历史对话：{state['messages']}" decision = llm.invoke(prompt).content.strip().lower() return {"next": decision if decision in ["act", "__end__"] else "__end__"} def act_node(state: AgentState): """行动节点：执行工具调用（查询天气）。""" # 从最后一条用户消息中提取城市（这里简化处理，实际应用需要更鲁棒的解析） last_msg = state['messages'][-1].content if state['messages'] else "" # 简单提取，可能是“北京天气怎么样” city = last_msg.replace("天气", "").replace("怎么样", "").strip() if not city: return {"messages": [{"role": "assistant", "content": "请告诉我您想查询哪个城市的天气。"}], "next": "think"} # 执行工具调用 tool_invocation = ToolInvocation(tool="get_weather", tool_input={"city": city}) result = tool_executor.invoke(tool_invocation) # 将结果添加到消息历史 new_message = {"role": "assistant", "content": f"{city}的天气是：{result}"} return {"messages": [new_message], "next": "evaluate"} def evaluate_node(state: AgentState): """评估节点：根据天气结果，给出是否外出的建议。""" last_msg_content = state['messages'][-1].content # 简单规则：如果天气包含“雨”或“雷”，不建议外出 if any(word in last_msg_content for word in ["雨", "雷", "storm"]): advice = "天气不佳，建议您今天尽量减少外出。" else: advice = "天气不错，适合外出活动！" final_message = {"role": "assistant", "content": f"{last_msg_content}\n\n建议：{advice}"} return {"messages": [final_message], "next": "__end__"} # 4. 添加节点和边 graph_builder.add_node("think", think_node) graph_builder.add_node("act", act_node) graph_builder.add_node("evaluate", evaluate_node) # 设置入口点 graph_builder.set_entry_point("think") # 根据“next”状态的值决定流向 graph_builder.add_conditional_edges( "think", lambda state: state.get("next", "__end__"), { "act": "act", "__end__": END, } ) graph_builder.add_edge("act", "evaluate") graph_builder.add_edge("evaluate", END) # 编译图 graph = graph_builder.compile()

3.3 集成 Langfuse 进行追踪和评估

现在，我们将 Langfuse 的回调处理器集成进来，记录每一次图的执行。

from langfuse.callback import CallbackHandler # 初始化 Langfuse 回调处理器（需要设置环境变量 LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY） langfuse_handler = CallbackHandler() # 使用 Langfuse 追踪执行 config = {"callbacks": [langfuse_handler]} try: # 模拟用户输入 initial_state = AgentState(messages=[{"role": "user", "content": "北京天气怎么样？"}], next="think") # 执行图 final_state = graph.invoke(initial_state, config=config) print("最终回答：", final_state["messages"][-1]["content"]) except Exception as e: print(f"执行出错：{e}")

执行后，登录你的 Langfuse 后台（本地或云服务），就能看到一个完整的 Trace。里面会包含：

• 一个根 Trace：代表这次用户查询。
• 多个 Span：对应think_node,act_node,evaluate_node的执行。
• Generation 详情：在think_node中调用 LLM 的输入和输出。
• 工具调用：act_node中调用get_weather工具的输入和输出。

3.4 在 Langfuse 中设置自动评估

追踪是第一步，评估才能衡量好坏。我们可以在 Langfuse 中为这个 Trace 设置自动评估。

1. 在 Langfuse 界面创建评估：进入项目设置，创建一个名为“外出建议合理性”的评估。
2. 定义评分标准：例如，可以设置一个 LLM 作为裁判，提示词为：“判断助手根据天气给出的外出建议是否合理。天气差时建议不外出的得高分，天气好时建议外出的得高分。只输出1-10分的整数。”
3. 关联到 Trace：Langfuse SDK 支持在代码中手动发送评估结果，也可以通过后台的“批量评估”功能，基于已有 Trace 运行自动评估。

这样，每次 Agent 运行后，你不仅能看过程，还能得到一个量化的分数，用于比较不同提示词、不同模型或不同工作流设计的优劣。

4. 面试高频“区别类”与“原理类”问题精讲

最后，集中梳理一些散落在热搜词和常见面试中的难点。

4.1 LangChain vs LangGraph vs LangSmith vs Dify

这是一个经典的“选型”问题。

面试回答要点：LangChain/LangGraph 是代码库，给开发者用的；LangSmith/Langfuse 是运维监控平台；Dify 是无代码/低代码平台，面向更广泛的用户。选择取决于你的角色（开发者 vs 业务人员）和阶段（开发 vs 生产部署）。

4.2 RAG 评估到底评估什么？

这是从“RAG评估”、“分类评估”等热词延伸的核心问题。不能只说“评估效果好坏”。

• 检索阶段评估：
  • 召回率（Recall）：对于一组问题，系统检索到的相关文档片段占所有相关片段的比例。
  • 命中率（Hit Rate）：对于一组问题，至少检索到一个相关片段的问题所占的比例。
  • 平均排名（MRR）：第一个相关片段出现位置的倒数的平均值。
• 生成阶段评估：
  • 答案相关性（Answer Relevance）：生成的答案与用户问题的匹配程度。可以用LLM基于问题对答案打分。
  • 上下文忠实度（Faithfulness）：答案中的陈述是否都能从提供的上下文中找到依据，避免幻觉。可以用LLM判断答案中的每个事实是否被上下文支持。
  • 答案正确性（Answer Correctness）：结合标准答案（如果有）进行评估，如BLEU、ROUGE或LLM裁判对比。
• 端到端评估：
  • 人工评估：黄金标准，但成本高。
  • LLM 作为裁判：用更强的LLM（如GPT-4）对答案的质量、有用性、安全性进行打分或对比评估（Pairwise）。Langfuse 的自动评估核心就是做这个。

4.3 Agent 的长期记忆（Long-term Memory）如何实现？

“LangGraph 长期记忆”是一个具体的技术点。在 LangGraph 中，记忆通过State来维护。

• 对话记忆：最简单的是在State中维护一个消息列表 (messages)。LangChain 的add_messagesreducer 就是干这个的。
• 摘要记忆：当对话很长时，可以将历史消息摘要后存储，以节省 Token 并聚焦重点。这可以在某个节点中调用 LLM 生成摘要，然后更新到 State 的一个特定字段。
• 外部知识记忆：Agent 可以将重要信息写入外部数据库（如向量库）。当需要时，通过一个“检索”工具从外部库中读取。这实现了超越单次对话的长期记忆。
• LangGraph 的 Checkpointer：这是实现持久化长期记忆的关键。Checkpointer可以将整个State序列化存储到数据库（如SQLite、Postgres）。即使应用重启，Agent 也能从上次中断的状态恢复。这对于运行时间极长的任务（如自动化研究）至关重要。

实现要点：在定义StateGraph时，传入一个checkpointer参数。然后在执行graph.invoke()时，通过config指定一个thread_id。相同thread_id的对话会共享并持久化其状态。

面对“2026大模型面试100问”这类庞杂的题库，最好的准备方法不是死记硬背，而是建立起清晰的技术地图。理解 LangChain 是构建块，LangGraph 是编排器，Langfuse 是观察镜。在回答 RAG 问题时，脑子里要有“检索-生成-评估”的完整闭环和优化漏斗。在回答 Agent 问题时，要能画出“感知-规划-行动”的循环图，并思考状态如何管理、工具如何设计、流程如何控制。

真正的面试官想看到的，是你能否把这些工具和概念，灵活地组织起来，去解决一个真实的、模糊的业务问题。所以，多动手搭一个像本文第三节那样的微型全链路项目，体会从工具定义、图构建、到追踪评估的完整过程，比你刷一百道八股文都管用。当你被问到“如何优化”或“如何设计”时，你就能自然地从一个可落地、可观测的工程视角来展开回答了。