面试官问你用过 LangChain 吗你说用过。然后他问“那你说说 LangChain 的 Agent 和 LangGraph 的 Agent 有什么本质区别”你停了三秒。这三秒就是 Agent 架构面试的分水岭。用过框架和理解框架是两件完全不同的事。这篇文章把 Agent 架构与框架面试的 15 道核心题全部拆开——从五大组件的串联逻辑到 ReAct/Plan-and-Execute/Reflexion 三种推理模式的本质差异从 LangGraph 的 State Graph 核心概念到框架选型的决策树再到从零实现一个最小 Agent的代码级考题。读完之后面试官问然后呢你能接住。模块一架构基础Q1Agent 的五大核心组件是什么它们怎么串联起来工作这是 Agent 架构面试的第一道题也是后续所有问题的基础。很多候选人能说出感知、记忆、推理、行动但说不清楚它们之间的数据流。五大组件组件英文职责类比感知Perception接收外部输入文本/图像/工具返回值眼睛和耳朵记忆Memory存储上下文、历史、知识大脑的记忆区推理Reasoning基于输入和记忆决定下一步行动大脑的决策区行动Action执行工具调用、生成输出手和嘴反馈Feedback接收行动结果更新状态神经反射弧串联逻辑数据流外部输入 ↓ Perception解析输入转为 Agent 可理解的格式 ↓ Memory检索相关历史和知识注入上下文 ↓ ReasoningLLM 推理该做什么调哪个工具 ↓ Action执行工具调用 / 生成回答 ↓ Feedback工具返回结果 / 用户反馈 ↓ 回到 Memory更新状态写入新记忆 ↓ 回到 Reasoning判断是否完成还是继续循环面试追问“这五个组件哪个是 Agent 和普通 LLM 调用的本质区别”是Feedback 驱动的循环。普通 LLM 调用是单次的输入 → 输出结束。Agent 是循环的输出的结果会作为新的输入驱动下一轮推理直到任务完成。这个循环 工具调用的组合才是 Agent 的本质。“五大组件里哪个最容易出问题”Reasoning。感知、记忆、行动都是相对确定的工程问题但推理依赖 LLM而 LLM 是概率性的——它可能推理出错误的行动计划可能陷入死循环可能在工具调用失败后不知道怎么恢复。这也是为什么 Agent 可靠性是面试的重点考察方向。Q2Agent 和 Workflow 的本质区别是什么什么时候该用 Agent什么时候该用 Workflow这道题考的是你对 Agent 适用边界的理解。很多候选人把所有自动化任务都叫Agent面试官会追问。核心区别维度WorkflowAgent控制流预定义DAG/状态机动态LLM 决策分支逻辑硬编码运行时推理工具调用固定顺序按需选择适应性低输入变化就可能失败高能处理未预见的情况可预测性高低成本低无额外 LLM 推理高每步都要 LLM 决策调试难度低高选型原则用Workflow的场景• 流程固定输入输出格式明确如发票 OCR → 字段提取 → 写入数据库• 对可靠性要求极高不能有随机性• 成本敏感不能每步都调 LLM用Agent的场景• 任务需要根据中间结果动态调整路径如研究助手不知道要搜几次才够• 工具的选择和顺序无法预先确定• 需要处理异常情况并自主恢复一个判断标准如果你能把任务的所有分支都画成流程图用 Workflow。如果流程图画不完用 Agent。面试追问“LangGraph 是 Workflow 还是 Agent”两者都可以。LangGraph 本质上是一个图编排框架你可以用它实现确定性的 Workflow每条边都是固定的也可以用它实现 Agent加入 LLM 决策的条件边。这也是 LangGraph 比早期 LangChain Agent 更受欢迎的原因——它给了开发者更精细的控制权。Q3ReAct、Plan-and-Execute、Reflexion——三种推理模式的本质差异是什么这是架构面试的核心题。能把三种模式说清楚说明你不只是用过而是理解了。ReActReasoning Acting核心思想推理和行动交替进行每一步都基于上一步的观察结果。Thought: 我需要查一下今天的天气Action: search(北京今天天气)Observation: 晴25°CThought: 天气不错我可以告诉用户适合出行Action: finish(今天北京晴天25°C适合出行)特点• 优点简单、透明、每步可追踪• 缺点没有全局规划容易在复杂任务中走弯路每步都要 LLM 推理成本高适用场景任务步骤不超过 5-7 步工具调用结果能直接指导下一步的场景。Plan-and-Execute规划后执行核心思想先用 LLM 生成完整的执行计划再按计划逐步执行。[规划阶段]Planner: 任务是写一份竞品分析报告Plan: Step 1: 搜索竞品 A 的最新功能 Step 2: 搜索竞品 B 的最新功能 Step 3: 对比两者的差异 Step 4: 生成报告[执行阶段]Executor: 按 Plan 逐步执行每步调用对应工具特点• 优点有全局视野不容易走弯路执行阶段可以用更小的模型降低成本• 缺点规划阶段的计划可能不准确中途遇到意外情况需要 re-plan增加复杂度适用场景任务步骤多7步、需要并行执行多个子任务的场景。Reflexion反思强化核心思想Agent 执行任务后生成自然语言反思反思结果写入记忆指导下次执行。[第一次尝试]Action: 执行任务Result: 失败测试用例不通过[反思阶段]Reflection: 我在第 3 步没有处理边界情况下次应该先检查输入是否为空[第二次尝试]Memory: 检索到上次的反思Action: 执行任务加入了边界检查Result: 成功特点• 优点能从失败中学习随着迭代次数增加成功率提升• 缺点需要多次尝试延迟高反思质量依赖 LLM 能力适用场景代码生成、数学推理等有明确对错标准的任务允许多次迭代的场景。三种模式对比维度ReActPlan-and-ExecuteReflexion规划方式逐步推理先全局规划迭代改进适合任务长度短7步长7步任意需多次迭代成本中低执行阶段可用小模型高多次尝试错误恢复弱需 re-plan强从失败中学习实现复杂度低中高Q4LLM 是无状态的Agent 的状态存在哪里这道题考的是你对 Agent 状态管理的理解是很多候选人的盲区。核心问题LLM 每次调用都是全新的不记得上一次说了什么。那 Agent 的我现在执行到第几步了、“上一个工具返回了什么”存在哪里答案状态存在 Agent 框架的 State 对象里不在 LLM 里。# LangGraph 的 State 示例from typing import TypedDict, Annotatedfrom langgraph.graph import add_messagesclass AgentState(TypedDict): messages: Annotated[list, add_messages] # 对话历史 current_step: int # 当前执行步骤 tool_results: dict # 工具调用结果 plan: list[str] # 执行计划Plan-and-Execute 模式 is_complete: bool # 任务是否完成状态的生命周期用户输入 → 初始化 State ↓每次 LLM 推理把 State 序列化为 Prompt消息历史 当前上下文 ↓LLM 输出 → 解析结果 → 更新 State ↓工具调用 → 工具结果写入 State ↓判断是否完成读 State→ 继续循环 or 结束面试追问“State 存在内存里Agent 崩溃了怎么办”这就是Checkpoint的作用。LangGraph 的 Checkpointer 会在每个节点执行后把 State 持久化到存储SQLite/PostgreSQL/RedisAgent 崩溃后可以从最近的 Checkpoint 恢复不需要从头开始。这也是 LangGraph 相比早期 LangChain Agent 的重要工程改进。模块二推理模式深入Q5ReAct 的 Prompt 模板长什么样不同模型的差异在哪这道题考的是你有没有真正写过 ReAct Prompt而不只是调用了框架的封装。标准 ReAct Prompt 模板你是一个 AI 助手可以使用以下工具{tools_description}使用以下格式Thought: 你对当前情况的思考Action: 要使用的工具名称必须是 [{tool_names}] 之一Action Input: 工具的输入参数JSON 格式Observation: 工具返回的结果...可以重复 Thought/Action/Observation 多次Thought: 我现在知道最终答案了Final Answer: 对用户问题的最终回答开始Question: {input}{agent_scratchpad}关键设计点agent_scratchpad这是 ReAct 的核心——把之前所有的 Thought/Action/Observation 都放在这里让 LLM 看到完整的推理历史才能做出正确的下一步决策。工具描述的质量工具描述写得好不好直接影响 LLM 选工具的准确率。好的工具描述要说清楚做什么、输入格式、输出格式、什么时候用。不同模型的差异模型ReAct 表现特点注意事项GPT-4o格式遵循好工具选择准确成本高适合复杂任务Claude 3.5 Sonnet推理链质量高不容易陷入死循环对 Prompt 格式要求稍宽松Llama 3.1 70B需要更明确的格式约束建议用 Function Calling 而非纯文本 ReActGPT-4o-mini简单任务够用复杂任务容易出错适合作为 Plan-and-Execute 的执行模型面试追问“ReAct 和 Function Calling 有什么关系”ReAct 是一种推理模式Thought → Action → Observation 的循环Function Calling 是 LLM 的一种能力结构化输出工具调用参数。现代 Agent 框架通常用 Function Calling 来实现 ReAct 的 Action 步骤——用 Function Calling 替代纯文本的Action: tool_name\nAction Input: {...}格式更可靠解析更稳定。Q6Plan-and-Execute 的规划失败了怎么办Re-plan 策略怎么设计这是 Plan-and-Execute 模式的核心工程挑战能答出来说明你真正用过这个模式。规划失败的三种场景场景一计划步骤不可执行• 例如Planner 生成了Step 3: 调用 X 工具但 X 工具不存在• 解决执行前做计划验证检查每个步骤引用的工具是否存在场景二中途遇到意外情况• 例如Step 2 的工具返回了数据不存在后续步骤依赖这个数据• 解决Executor 检测到异常后触发 Re-planner场景三计划完成但结果不符合预期• 例如报告生成了但用户说这不是我要的格式• 解决Human-in-the-loop让用户确认后 re-planRe-plan 策略设计from langgraph.graph import StateGraphdefshould_replan(state: AgentState) - str: 判断是否需要 re-plan last_result state[tool_results].get(last_result) # 工具调用失败 if last_result and last_result.get(error): returnreplan # 执行了 3 步还没有进展 if state[current_step] 3andnot state[has_progress]: returnreplan # 正常继续 returncontinue# 在 LangGraph 中加入条件边graph.add_conditional_edges( executor, should_replan, { replan: planner, # 回到规划节点 continue: executor# 继续执行 })Re-plan 的上下文注入Re-plan 时要把失败原因和已完成的步骤告诉 Planner避免重复犯同样的错误replan_prompt f原始任务{original_task}原始计划{original_plan}已完成步骤{completed_steps}失败原因{failure_reason}请基于以上信息生成一个修正后的执行计划面试加分点提到 Re-plan 的次数限制——如果允许无限 re-planAgent 可能陷入死循环。生产环境通常设置最大 re-plan 次数如 3 次超过后降级为人工处理。Q7Reflexion 和 Few-shot 的本质区别是什么这道题很多候选人答不清楚因为两者表面上都是给 LLM 一些例子。Few-shot静态的你手动写几个示例放在 Prompt 里每次调用都用同样的示例。few_shot_prompt 示例 1输入计算 22输出4示例 2输入计算 3×5输出15现在输入{user_input}输出Reflexion动态的Agent 从自己的失败中自动生成新的示例写入记忆下次自动检索使用。# Reflexion 的核心循环defreflexion_loop(task: str, max_attempts: int 3): memories [] for attempt inrange(max_attempts): # 检索历史反思 relevant_reflections retrieve_reflections(task, memories) # 执行任务注入历史反思 result execute_with_reflections(task, relevant_reflections) # 评估结果 if is_success(result): return result # 生成反思失败时 reflection generate_reflection(task, result) memories.append(reflection) return result # 返回最后一次尝试的结果核心差异维度Few-shotReflexion示例来源人工编写Agent 自动生成更新方式静态不会变动态每次失败后更新适应性低只适应预见的情况高能适应新的失败模式成本低高需要多次尝试适用场景格式固定的任务有明确对错标准的复杂任务面试追问“Reflexion 的反思质量怎么保证”反思质量取决于两点一是评估函数的准确性能不能正确判断成功/失败二是 LLM 的反思能力能不能从失败中提炼出有用的经验。如果评估函数不准Reflexion 可能强化错误的行为。所以 Reflexion 最适合有明确评估标准的任务如代码测试通过/不通过、数学答案对/错。模块三主流框架拆解Q8LangGraph 的核心概念是什么State/Node/Edge/Checkpoint 怎么理解LangGraph 是 2025-2026 年 Agent 面试的最高频框架必须给代码级的理解。四大核心概念① State状态Agent 的大脑存储所有中间状态。from typing import TypedDict, Annotatedfrom langgraph.graph import add_messagesclass AgentState(TypedDict): messages: Annotated[list, add_messages] # add_messages 是 reducer自动追加而非覆盖 next_action: str iteration_count: int② Node节点执行具体逻辑的函数接收 State返回更新后的 State。def call_llm(state: AgentState) - AgentState: 调用 LLM 推理节点 response llm.invoke(state[messages]) return {messages: [response]} # 只返回需要更新的字段def call_tool(state: AgentState) - AgentState: 工具调用节点 last_message state[messages][-1] tool_result execute_tool(last_message.tool_calls[0]) return {messages: [ToolMessage(contenttool_result)]}③ Edge边定义节点之间的流转关系。from langgraph.graph import StateGraph, ENDgraph StateGraph(AgentState)# 添加节点graph.add_node(llm, call_llm)graph.add_node(tool, call_tool)# 固定边graph.add_edge(tool, llm) # 工具执行完回到 LLM# 条件边动态路由defshould_continue(state: AgentState) - str: last_message state[messages][-1] if last_message.tool_calls: returntool # 有工具调用去执行工具 return END # 没有工具调用结束graph.add_conditional_edges(llm, should_continue)graph.set_entry_point(llm)④ Checkpoint检查点持久化 State支持暂停/恢复/Human-in-the-loop。from langgraph.checkpoint.memory import MemorySaverfrom langgraph.checkpoint.postgres import PostgresSaver# 开发环境内存 Checkpointercheckpointer MemorySaver()# 生产环境PostgreSQL Checkpointercheckpointer PostgresSaver.from_conn_string(postgresql://...)# 编译时注入 Checkpointerapp graph.compile(checkpointercheckpointer)# 运行时指定 thread_id同一 thread_id 的对话共享状态config {configurable: {thread_id: user_123_session_456}}result app.invoke({messages: [HumanMessage(帮我分析这份报告)]}, configconfig)Human-in-the-loop 的实现# 在需要人工确认的节点前设置 interruptapp graph.compile( checkpointercheckpointer, interrupt_before[execute_action] # 执行前暂停等待人工确认)# 运行到 interrupt 点后暂停result app.invoke(input, config)# 此时 Agent 暂停等待人工确认# 人工确认后继续app.invoke(None, config) # 传 None 表示继续执行面试追问“LangGraph 和早期 LangChain Agent 的本质区别是什么”早期 LangChain Agent 是黑盒的——你告诉它工具列表和目标它自己决定怎么做你很难控制中间步骤。LangGraph 是白盒的——你明确定义每个节点做什么、每条边怎么流转Agent 的行为完全可预测、可调试。这是从魔法盒子到可控工程的转变。Q9CrewAI 的四层架构是什么Task/Agent/Crew/Process 怎么理解CrewAI 是基于角色的多 Agent 框架面试中经常被拿来和 LangGraph 对比。四层架构Crew团队 └── Process执行流程Sequential / Hierarchical └── Agent角色有名字、目标、背景故事、工具 └── Task任务有描述、期望输出、负责人代码示例from crewai import Agent, Task, Crew, Processfrom crewai_tools import SerperDevTool, WebsiteSearchTool# 定义工具search_tool SerperDevTool()# 定义 Agent角色researcher Agent( roleAI 研究员, goal收集关于 {topic} 的最新信息, backstory你是一名专注于 AI 领域的资深研究员擅长从海量信息中提炼关键洞察, tools[search_tool], verboseTrue, llmgpt-4o)writer Agent( role技术写作专家, goal将研究结果整理成清晰易读的报告, backstory你是一名技术写作专家擅长将复杂的技术内容转化为通俗易懂的文章, verboseTrue, llmgpt-4o-mini# 写作任务用更便宜的模型)# 定义 Task任务research_task Task( description搜索关于 {topic} 的最新进展整理出 5 个核心要点, expected_output包含 5 个核心要点的结构化研究报告, agentresearcher)writing_task Task( description基于研究结果撰写一篇 800 字的技术文章, expected_output一篇结构清晰、语言流畅的 800 字技术文章, agentwriter, context[research_task] # 依赖 research_task 的输出)# 组建 Crewcrew Crew( agents[researcher, writer], tasks[research_task, writing_task], processProcess.sequential, # 顺序执行 verboseTrue)# 执行result crew.kickoff(inputs{topic: LangGraph 最新特性})Sequential vs Hierarchical ProcessProcess说明适用场景Sequential任务按顺序执行前一个任务的输出是后一个的输入流程固定的任务研究→写作→审核Hierarchical有一个 Manager Agent 负责分配任务和协调任务分配需要动态决策的场景面试追问“CrewAI 和 LangGraph 怎么选”这是框架选型的核心问题下一题会详细讲。简短版CrewAI 适合角色分工明确、流程相对固定的场景上手快LangGraph 适合需要精细控制流程、有复杂条件分支、需要 Human-in-the-loop的场景灵活性更高但学习成本也更高。Q10LangChain vs LangGraph vs LlamaIndex vs CrewAI——框架选型决策树这是面试中最常见的开放题考的是你的工程判断力。先理解各框架的定位框架核心定位最擅长LangChainLLM 应用开发工具箱快速原型、Chain 组合、工具集成LangGraphAgent 编排框架复杂 Agent 流程、状态管理、Human-in-the-loopLlamaIndex数据框架RAG、知识库、文档处理CrewAI多 Agent 协作框架角色分工、任务委托、团队协作选型决策树你的任务是什么│├── 主要是 RAG / 知识库 / 文档处理│ └── → LlamaIndex数据处理能力最强│├── 单个 Agent需要精细控制流程│ ├── 流程简单快速原型→ LangChain上手最快│ └── 流程复杂需要 Checkpoint/Human-in-the-loop→ LangGraph│├── 多个 Agent 协作│ ├── 角色分工明确流程相对固定→ CrewAI上手快│ └── 需要动态路由、复杂协调逻辑→ LangGraph灵活性最高│└── 生产级系统需要可观测性和可靠性 └── → LangGraph LangSmith最完整的工程化支持一个真实的选型案例场景构建一个智能研究助手用户输入研究主题Agent 自动搜索、阅读、总结生成报告。• 如果是 MVP 阶段用 CrewAI3 个 Agent搜索员/阅读员/写作员Sequential Process一天内跑通• 如果是生产阶段用 LangGraph精细控制每个步骤加 Checkpoint 支持断点续传加 Human-in-the-loop 让用户确认搜索方向面试追问“你们团队用的是哪个框架为什么选它”这是考你实战经验的题。如果你真的用过说出具体的选型理由和踩过的坑。如果没用过可以说我在项目中用过 X选它的原因是 Y遇到的最大问题是 Z解决方案是 W——有具体细节比泛泛而谈更有说服力。Q11LangChain 为什么被社区诟病它的核心问题在哪这道题考的是你对框架的批判性思考能答出来说明你不是框架粉。LangChain 的三大核心问题① 过度抽象调试困难LangChain 的 Chain 和 Agent 封装了太多细节当出问题时很难定位是哪一层出了错。一个简单的工具调用失败可能需要翻好几层源码才能找到原因。② 版本迭代快API 不稳定LangChain 的 API 在早期版本中变化频繁很多教程代码在新版本里直接跑不通。这对生产环境是个噩梦。③ 依赖过重安装 LangChain 会带来大量依赖很多是用不到的。对于只需要某个功能的项目这是不必要的负担。LangChain 的反驳• 对于快速原型LangChain 的封装确实能节省大量时间• LangChain 的生态最完整支持的 LLM 和工具最多• LangGraph 是 LangChain 团队推出的两者可以配合使用面试加分点能说出我在什么场景下会用 LangChain在什么场景下会绕过它直接用 LangGraph 或原生 API——这说明你有实际的工程判断不是非此即彼。模块四工程实践Q12从零实现一个最小 Agent——不用框架需要哪些模块这是高级面试题考的是你对 Agent 底层机制的理解。能从零实现说明你不依赖框架。最小 Agent 的五个核心模块import jsonfrom openai import OpenAIfrom typing importCallableclient OpenAI()# ① 工具注册表classToolRegistry: def__init__(self): self.tools: dict[str, Callable] {} self.schemas: list[dict] [] defregister(self, name: str, func: Callable, description: str, parameters: dict): self.tools[name] func self.schemas.append({ type: function, function: { name: name, description: description, parameters: parameters } }) defexecute(self, name: str, arguments: dict) - str: if name notinself.tools: returnfError: Tool {name} not found try: returnstr(self.tools[name](**arguments)) except Exception as e: returnfError: {str(e)}# ② 状态管理classAgentState: def__init__(self): self.messages: list[dict] [] self.iteration: int 0 self.max_iterations: int 10 defadd_message(self, role: str, content: str, **kwargs): msg {role: role, content: content} msg.update(kwargs) self.messages.append(msg)# ③ LLM 推理defcall_llm(state: AgentState, tools: list[dict]) - dict: response client.chat.completions.create( modelgpt-4o, messagesstate.messages, toolstools, tool_choiceauto ) return response.choices[0].message# ④ 工具执行defexecute_tools(message, registry: ToolRegistry) - list[dict]: results [] ifnot message.tool_calls: return results for tool_call in message.tool_calls: name tool_call.function.name args json.loads(tool_call.function.arguments) result registry.execute(name, args) results.append({ role: tool, tool_call_id: tool_call.id, content: result }) return results# ⑤ Agent 主循环defrun_agent(user_input: str, registry: ToolRegistry) - str: state AgentState() state.add_message(system, 你是一个有用的 AI 助手可以使用工具来回答问题。) state.add_message(user, user_input) while state.iteration state.max_iterations: state.iteration 1 # LLM 推理 message call_llm(state, registry.schemas) # 把 LLM 输出加入消息历史 state.messages.append(message) # 没有工具调用 → 任务完成 ifnot message.tool_calls: return message.content # 执行工具 tool_results execute_tools(message, registry) state.messages.extend(tool_results) return达到最大迭代次数任务未完成# 使用示例registry ToolRegistry()registry.register( nameget_weather, funclambda city: f{city}今天晴天25°C, description获取指定城市的天气, parameters{ type: object, properties: {city: {type: string, description: 城市名称}}, required: [city] })result run_agent(北京今天天气怎么样, registry)print(result)这个最小实现展示了 Agent 的核心机制工具注册 → 状态管理 → LLM 推理 → 工具执行 → 循环判断。框架LangChain/LangGraph做的事情本质上就是把这些模块封装得更好用、更可靠。Q13Agent 的流式输出怎么实现异步工具调用怎么编排这是工程实践题考的是你有没有处理过 Agent 的性能问题。流式输出Streaming用户等待 Agent 响应时如果要等所有工具调用完成才输出体验很差。流式输出让用户能实时看到 Agent 的推理过程。# LangGraph 的流式输出from langgraph.graph import StateGraphapp graph.compile()# stream() 方法逐步返回每个节点的输出for chunk in app.stream( {messages: [HumanMessage(帮我分析这份报告)]}, config{configurable: {thread_id: 123}}): for node_name, node_output in chunk.items(): print(f[{node_name}]: {node_output})异步工具调用当 Agent 需要并行调用多个工具时串行执行会浪费时间。import asynciofrom langchain_core.tools import tooltoolasyncdefsearch_web(query: str) - str: 搜索网络 # 异步 HTTP 请求 asyncwith aiohttp.ClientSession() as session: result await session.get(fhttps://api.search.com?q{query}) returnawait result.text()toolasyncdefsearch_database(query: str) - str: 搜索数据库 # 异步数据库查询 result await db.execute(fSELECT * FROM docs WHERE content LIKE %{query}%) returnstr(result)# 并行执行多个工具asyncdefparallel_tool_execution(tool_calls: list) - list: tasks [ execute_tool_async(tc.function.name, tc.function.arguments) for tc in tool_calls ] results await asyncio.gather(*tasks, return_exceptionsTrue) return results面试追问“并行工具调用有什么风险”主要有两个一是工具之间有依赖关系时不能并行Tool B 的输入依赖 Tool A 的输出二是并发请求可能触发 API 限流。解决方案在工具 Schema 里标注依赖关系框架自动判断哪些可以并行对外部 API 调用加限流控制Semaphore。Q14State Machine vs Graph——什么时候该用哪种 Agent 架构这道题考的是你对不同 Agent 架构范式的理解。状态机 AgentState Machine状态[等待输入] → [分析意图] → [调用工具] → [生成回答] → [等待输入]转换由明确的条件触发如意图是查询天气→ 转到调用天气工具特点• 状态和转换完全预定义• 可预测、可测试• 适合流程固定的场景如客服机器人的标准流程图 AgentGraph-based如 LangGraph节点每个节点是一个处理函数边固定边 条件边由 LLM 或规则动态决定特点• 流程可以动态变化• 支持循环、分支、并行• 适合复杂的 Agent 任务选型原则场景推荐架构理由客服标准流程问候→意图识别→处理→结束状态机流程固定可预测性高研究助手搜索次数不确定图 Agent需要动态决定搜索几次代码生成写→测试→修复→测试图 Agent Reflexion需要循环迭代表单填写引导状态机每个字段是一个状态转换明确面试加分点提到混合架构——外层用状态机定义大的业务流程内层用图 Agent 处理需要动态决策的子任务。这是生产环境中最常见的模式。模块五真题实战Q15白板题——画一个智能客服 Agent的架构图并说明每个组件的设计决策这是 Senior 级别面试的标配白板题。考的不只是你能不能画出来而是你能不能说清楚每个设计决策背后的 trade-off。需求分析• 用户通过文字/语音提问• Agent 能回答产品问题、处理退款申请、查询订单状态• 需要支持多轮对话• 复杂问题需要转人工• 支持 10 万日活用户架构图用户输入文字/语音 ↓[输入处理层] - 语音转文字ASR - 意图识别分类产品咨询/退款/订单查询/其他 - 敏感词过滤 ↓[路由层] - 简单问题 → FAQ 检索RAG - 复杂问题 → Agent 处理 - 超出能力范围 → 转人工 ↓[Agent 核心LangGraph] ┌─────────────────────────────────┐ │ State: {messages, user_id, │ │ intent, order_info} │ │ │ │ Node: LLM 推理 │ │ Node: 工具调用 │ │ - query_order_db() │ │ - process_refund() │ │ - search_faq() │ │ Node: 人工转接判断 │ └─────────────────────────────────┘ ↓[记忆层] - 短期Redis当前会话 - 长期PostgreSQL pgvector用户历史 ↓[输出层] - 回答生成 - 满意度收集 - 对话日志LangSmith关键设计决策面试官最想听的部分① 为什么在 Agent 前加路由层不是所有问题都需要 Agent。FAQ 类问题用 RAG 直接回答成本是 Agent 的 1/10延迟也更低。路由层把简单问题过滤掉让 Agent 只处理真正需要推理的复杂问题。② 为什么用 LangGraph 而不是 CrewAI客服场景需要精细控制什么时候转人工置信度低于阈值、什么时候需要用户确认退款金额超过 500 元。LangGraph 的interrupt_before机制能精确控制这些节点CrewAI 做不到这种粒度。③ 记忆层为什么要冷热分离10 万日活用户如果所有记忆都放向量数据库成本很高。7 天内活跃用户的记忆放 Redis热数据快历史记忆放 PostgreSQL pgvector温数据便宜。90 天以上不活跃的用户记忆归档到 S3冷数据极便宜。④ 转人工的触发条件怎么设计三种触发条件置信度低于阈值LLM 输出的 confidence score 0.7用户明确要求“我要找人工”敏感操作退款金额 1000 元需要人工审核面试追问“这个架构的最大风险是什么”最大风险是Agent 的不可预测性——LLM 可能在某些边缘情况下给出错误的回答或执行错误的操作如错误地触发退款。缓解方案对所有写操作退款、修改订单加 Human-in-the-loop 确认对 Agent 的输出做后处理验证建立完善的监控和告警LangSmith 自定义指标。总结面试官真正在考什么Agent 架构面试表面上考框架实际上考三件事① 你有没有系统性认知能不能把 ReAct/Plan-and-Execute/Reflexion 的差异说清楚能不能给出框架选型的决策树而不是我用过 LangChain挺好用的。② 你有没有工程判断力LangGraph vs CrewAI 怎么选状态机 vs 图 Agent 怎么选流式输出 vs 批量输出怎么选——每个选择背后都有 trade-off能说出 trade-off 才是真正的工程判断。③ 你有没有踩过坑Re-plan 的次数限制、并行工具调用的限流问题、LangChain 的调试困难——这些坑只有真正用过的人才知道。这 15 道题覆盖了 Agent 架构面试的完整知识图谱。建议重点练 Q3三种推理模式对比、Q8LangGraph 核心概念、Q10框架选型决策树、Q15白板题这四道高频题——这四道题能答好Agent 架构面试基本稳了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】