框架选型

Q201. LangChain 和 LangGraph 到底有什么区别？

来源：官方文档 docs.langchain.com · 官方博客《LangChain and LangGraph 1.0》《3 Years of Graph Engineering with LangGraph》

核心要点（先记住官方定位）：

• 官方把 Agent 技术栈分成三层：Framework（LangChain）→ Runtime（LangGraph）→ Harness（Deep Agents 等）。
• LangChain = 高层 Agent 框架：提供模型/工具/循环的现成抽象和几百个集成，目标是“快速上手、快速交付”。
• LangGraph = 低层编排运行时：不抽象 prompt 和架构，只提供状态图执行引擎 + 持久化 + 流式 + 人工介入，目标是“生产级、长时间、可恢复”。

七个维度对比：

关键事实（面试加分）：

• LangChain 1.0 的 create_agent 底层就跑在 LangGraph 上——两者不是二选一，是“渐进式技术栈”，可以无缝混用。
• 2025.10 两者同时发 1.0：LangChain 放弃早期 Chain/LCEL 设计，收窄到核心 Agent Loop + Middleware；create_react_agent（langgraph.prebuilt）被 create_agent（langchain.agents）取代。
• LangGraph 设计受 Pregel 和 Apache Beam 启发，接口风格像 NetworkX。
• 官方复盘强调：生产级 Agent 图通常不是 DAG，而是有环图（重试、追问、校验、人工暂停都是环）；“Loop 就是最简单的一种图”。
• 什么时候不该用图：深度研究这类路径无法预先固定的任务，强行硬编码图反而不如更 Agentic 的 Harness（Deep Agents）。

代码级对比（记感觉）：

• LangChain 1.0：

from langchain.agents import create_agent
agent = create_agent(model="openai:gpt-4o", tools=[get_weather], system_prompt="客服助手")
agent.invoke({"role": "user", "content": "上海天气？"})

• LangGraph：

from langgraph.graph import StateGraph, START, END
graph = StateGraph(State)
graph.add_node("llm", call_llm).add_node("tools", call_tools)
graph.add_edge(START, "llm")
graph.add_conditional_edges("llm", route)  # 自己决定下一步
graph.add_edge("tools", "llm").add_edge("llm", END)  # 循环
app = graph.compile(checkpointer=memory)

面试怎么答（30 秒版）：LangChain 是高层框架，帮你几行代码搭标准 Agent，默认是一个 ReAct 循环，1.0 后用 middleware 挂生产能力；LangGraph 是底层状态图运行时，把流程显式建模成节点/边/状态，原生支持循环、并行、持久化、断点恢复和人工介入，适合复杂多 Agent 与长任务。关键点：LangChain 1.0 本身构建在 LangGraph 之上，所以是渐进式关系不是竞争关系——先用 LangChain 快速起步，需要精细控制时下沉到 LangGraph，甚至可以 create_agent 当图里的一个节点。

Q202. 主流 Agent / AI 框架全景（还有哪些？）

来源：官方文档 · 卡码框架横评 · AgentGuide

选型四问（面试答法）：① 流程可预知吗？可预知→Workflow/图，开放→Harness；② 需要长时运行/断点恢复吗？需要→LangGraph/Deep Agents 这类带持久化的运行时；③ 团队技术栈？Java 用 Spring AI，Python 用 LangChain 系；④ 生态与可控性平衡：快速上线选高层框架，精细控制下沉低层运行时。

Q203. LangGraph 里 State / Node / Edge 分别解决什么问题？

来源：官方文档 · 卡码 Graph Engineering

核心要点：

• State：节点间传递的结构化数据（消息、任务进度、中间产物、预算、审批结果），是可持久化的核心。
• Node：做事的单元，可以是确定性代码、单次 LLM 调用、工具调用，甚至一个完整的子 Agent（内含自己的循环）。
• Edge：决定下一步，可以是确定性边，也可以是基于状态/模型结果的条件路由。
• 高级能力：Send 动态扇出（map-reduce，运行前不知道多少个子任务）、Checkpointer 断点、interrupt 人工审批后恢复。

衍生追问：

• LangGraph 相比手写状态机优势？自带持久化、重放、可视化调试、与 LangChain 生态互通，且天然支持循环（生产 Agent 大多是有环图）。
• 为什么不用 LangGraph 硬编码所有路径？深度研究这类任务路径不可预知，过度约束反而牺牲 Agent 自主性，Harness 更合适。

Q204. LangGraph 的图主要抽象了哪些流程？

来源：官方文档 Graph API / Use the Graph API

核心要点（官方一句话：Nodes do the work, edges tell what to do next）：

LangGraph 把 Agent 工作流抽象成三类核心组件 + 一套 Pregel 式执行模型：

1. State（状态流）：共享数据结构，是应用当前快照；定义 Schema（TypedDict/Pydantic）+ Reducer（节点更新如何合并：默认覆盖、add 追加、add_messages 按消息 ID 合并去重）。可拆分输入/输出/私有 Schema，内部节点间可传不对外暴露的中间数据。
2. Nodes（动作单元）：普通函数，接收 state、返回更新；可以是确定性代码、单次 LLM 调用、工具调用，甚至一个完整子 Agent（内含自己的循环）。
3. Edges（转移规则）：决定下一步执行哪个节点；固定边或基于状态/模型结果的条件边。
4. 执行模型（运行时抽象）：底层是受 Google Pregel 启发的消息传递算法，按“super-step”推进：节点收到消息才激活，执行完沿边发消息，全部无消息则终止——这层抽象让图天然支持并行和循环。

图抽象出来的具体流程模式：

多 Agent 编排流程：supervisor（主管-工人）、handoff（交接转移）、swarm（对等协作）、层级嵌套（子图作为节点）。

图不抽象什么：prompt、模型接口、工具定义——这些留在 LangChain 层；图只负责“谁在什么时候做什么、状态怎么流、失败怎么恢复”。

Q205. State 状态流主要存什么信息？

来源：官方文档 Graph API · MessagesState · Checkpointer / Store

核心要点（State = 应用当前快照）：

• 官方定义：State 是共享数据结构，代表应用在某时刻的完整快照；节点读它、返回更新，Reducer 决定更新怎么合并。

按信息类别拆：

官方 Channel 类型（决定“怎么存”）：

• LastValue：只保留最新值（默认覆盖语义），适合 route/step/answer。
• BinaryOperatorAggregate：用 reducer 累加（add 追加列表、计数器），适合 messages/中间产物。
• Topic：收集执行期间产生的所有值，适合事件流、审计日志。
• EphemeralValue：跨 super-step 重置的临时计算值，不持久化。

示例（一个客服 Agent 的 State）：

class AgentState(TypedDict):
    messages: Annotated[list[AnyMessage], add_messages]   # 对话历史
    intent: str                                           # 意图路由结果
    documents: list[str]                                  # RAG 检索结果
    retry_count: int                                      # 工具失败重试次数
    budget_used: float                                    # token/成本预算
    approval: str                                         # 高风险操作审批状态
    done: bool                                            # 终止标志

什么不该放 State：

• 大体积工具原始返回（应截断/摘要/存引用，需要时再取详情）。
• 密钥、Token、隐私原文（安全与合规红线）。
• 可重算的临时数据（浪费持久化开销）。

衍生追问：

• State 和数据库/缓存的区别？State 是图执行期间的“工作记忆”，Checkpointer 把它持久化；跨会话的画像/知识放 Store（长期记忆），业务大表仍存数据库。
• 为什么 messages 用 add_messages 而不是 operator.add？add_messages 按消息 ID 合并：新消息追加，已存在的消息能被人工修改（HITL）覆盖，避免重复与错乱。

Q206. Node 节点主要是工具调用吗？

来源：官方文档 Graph API（“Nodes and Edges are nothing more than functions—they can contain an LLM or just good ol’ code.”）

核心要点（先纠正：Node 只是函数，工具调用只是其中一种）：

官方定义：Node 是普通函数（同步/异步），接收 state、返回更新；它可以是任何东西：

1. 确定性代码节点：校验、过滤、格式转换、聚合、字段映射——不碰 LLM。
2. LLM 决策节点：意图分类、路由判断、生成回答、打分评估。
3. 工具执行节点：调 API、检索、执行代码、发消息。
4. 子 Agent 节点：一个完整 Agent（内含自己的 Loop）作为一个节点，形成层级编排。
5. 子图节点：编译好的另一个 StateGraph 嵌进来，组合复用。
6. 人工节点：interrupt 暂停等人工审批/输入，也是节点。

ReAct 模式的典型误解：常见的工具调用循环其实是“双节点”：LLM 决策节点（决定调哪个工具、生成参数）+ 工具执行节点（真正执行并返回 Observation）→ 再回 LLM 节点。所以工具调用通常不是单节点，而是“决策 + 执行”两个节点组成的一环。

生产图里节点分布（经验值）：一个客服/文档 Agent 图里，确定性代码节点（校验、聚合、路由）往往比 LLM 节点多；图的价值正是“能确定的部分用代码，需要判断的部分才用 LLM”，而不是把所有东西都塞给工具调用。

面试答法：Node 是执行单元，可以是代码、LLM 调用、工具执行、子 Agent 或人工审批；工具调用只是其中常见的一类，而且 ReAct 里通常拆成“决策节点 + 执行节点”两个 Node 形成循环。

Q207. LLM 决策节点（意图分类 / 路由 / 打分 / 生成）代码怎么写？

来源：LangGraph + LangChain 官方 API 实践

核心要点：

• 决策类节点统一套路：LLM.with_structured_output(Pydantic模型) → 节点函数读 state、invoke、把结构化结果写回 state → 条件边根据 state 里的决策字段选下一步。
• 工程三原则：temperature=0（决策要稳定）、结构化输出（下游好解析）、失败兜底（解析失败/重试计数）。

1. 准备：State + LLM

from typing import Annotated, TypedDict
from langchain_openai import ChatOpenAI
from langchain_core.messages import AnyMessage, HumanMessage, AIMessage
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from pydantic import BaseModel, Field

llm = ChatOpenAI(model="gpt-4o", temperature=0)  # 决策稳定：temperature 归零

class State(TypedDict):
    messages: Annotated[list[AnyMessage], add_messages]  # 对话历史
    intent: str              # 意图分类结果
    confidence: float        # 分类置信度
    documents: list[str]     # RAG 检索结果
    answer: str              # 生成的回答
    score: float             # 打分评估结果
    passed: bool             # 是否通过评估
    retry_count: int         # 重试次数

2. 意图分类节点（结构化输出）

class Intent(BaseModel):
    intent: str = Field(description="retrieve=查知识库 / act=调工具 / chat=直接回答")
    confidence: float = Field(ge=0, le=1, description="置信度 0~1")

classifier = llm.with_structured_output(Intent)

def classify_node(state: State) -> dict:
    result: Intent = classifier.invoke(
        [HumanMessage(content=f"判断用户意图：{state['messages'][-1].content}")]
    )
    return {"intent": result.intent, "confidence": result.confidence}

3. 路由判断：条件边（Edge 读 State 决定下一步）

def route_after_classify(state: State) -> str:
    if state["intent"] == "retrieve":
        return "retrieve"      # 走 RAG
    if state["intent"] == "act":
        return "tools"         # 走工具
    return "generate"          # 直接生成

def retrieve_node(state: State) -> dict:
    # 伪代码：向量库检索
    docs = ["文档1", "文档2"]
    return {"documents": docs, "messages": [HumanMessage(content=f"检索结果：{docs}")]}

4. 生成回答节点（普通 LLM 调用，结果进 messages）

def generate_node(state: State) -> dict:
    resp: AIMessage = llm.invoke(state["messages"])   # 带完整上下文生成
    return {"messages": [resp], "answer": resp.content}

5. 打分评估节点（LLM-as-Judge）

class Verdict(BaseModel):
    score: float = Field(ge=0, le=10, description="0~10 质量分")
    reason: str = Field(description="打分依据")
    passed: bool = Field(description="是否达到通过线")

judge = llm.with_structured_output(Verdict)

def evaluate_node(state: State) -> dict:
    prompt = (
        "你是质检员。依据以下标准给回答打分（0~10，>=7 通过）：\n"
        "1. 是否忠于提供的文档；2. 是否完整回答用户问题；3. 是否有幻觉。\n"
        f"问题：{state['messages'][0].content}\n"
        f"回答：{state['answer']}\n"
        f"参考文档：{state.get('documents', [])}"
    )
    v: Verdict = judge.invoke([HumanMessage(content=prompt)])
    return {"score": v.score, "passed": v.passed, "reason": v.reason}

6. 兜底重试路由 + 编译成图

def route_after_eval(state: State) -> str:
    if state["passed"] or state["retry_count"] >= 2:
        return END          # 通过或重试超限 → 结束
    return "generate"       # 不通过 → 带着质检意见重新生成

builder = StateGraph(State)
builder.add_node("classify", classify_node)
builder.add_node("retrieve", retrieve_node)
builder.add_node("tools", tools_node)      # 你的工具执行节点
builder.add_node("generate", generate_node)
builder.add_node("evaluate", evaluate_node)

builder.add_edge(START, "classify")
builder.add_conditional_edges("classify", route_after_classify,
                              {"retrieve": "retrieve", "tools": "tools", "generate": "generate"})
builder.add_edge("retrieve", "generate")
builder.add_edge("tools", "generate")
builder.add_edge("generate", "evaluate")
builder.add_conditional_edges("evaluate", route_after_eval)  # 键名=节点名时可省略映射

app = builder.compile()
result = app.invoke({"messages": [HumanMessage(content="公司年假政策是什么？")],
                     "retry_count": 0})

执行链路：classify（意图）→ retrieve/tools/generate（干活）→ generate（回答）→ evaluate（质检）→ 不通过带原因回 generate 重试（retry_count+1）→ 超限终止。

衍生追问：

• 为什么决策节点用结构化输出？路由/打分/分类都要被代码消费，JSON Schema 卡死字段最稳；解析失败还有兜底（重试/默认路由）。
• 打分评估节点怎么防止“自我偏好”？换更小/不同模型做 judge、交换顺序盲评、人工抽样校准。
• 条件边返回的值和节点名不一致怎么办？用映射字典显式对应，如 {"retrieve": "retrieve", ...}；键名等于节点名时可省略。

Q208. Node 怎么知道该“思考”还是“调工具”？这个决定是谁做的？

来源：LangGraph 官方 ReAct 实现 · OpenAI Function Calling 机制

核心要点（先纠正认知：LangGraph 不知道，模型才知道）：

• LangGraph 不是 LLM，它没有任何“判断能力”；Node 只是你写死的函数。
• “思考还是调工具”的决定发生在 LLM 节点内部：你把工具 schema 通过 bind_tools 注入模型，模型按训练学到的 Function Calling 能力，自己决定输出纯文本（思考/回答）还是 tool_calls（要调工具）。
• 图只负责一件事：检查模型输出的信号，按你写好的路由规则走——有 tool_calls 就进工具执行节点，没有就进回答/结束。

一句话流程：模型“看”到工具清单 → 输出两种信号之一（文本 or tool_calls）→ 路由函数检查信号 → 有调用去执行，没有就结束。

最小代码（ReAct 双节点）：

# 1. LLM 节点：模型带着工具清单“思考”
model_with_tools = llm.bind_tools([search_api, send_email])   # 工具 schema 进 prompt/API

def agent_node(state: State) -> dict:
    resp = model_with_tools.invoke(state["messages"])  # 模型自己决定：文本 or tool_calls
    return {"messages": [resp]}

# 2. 路由函数：检查模型输出的是什么信号
def should_continue(state: State) -> str:
    last = state["messages"][-1]
    if getattr(last, "tool_calls", None):   # 模型要调工具
        return "tools"                       # → 工具执行节点
    return END                               # 模型直接回答 → 结束

# 3. 工具执行节点：只负责“执行”，不做任何决定
def tools_node(state: State) -> dict:
    last = state["messages"][-1]
    results = []
    for call in last.tool_calls:             # 执行模型要调的所有工具
        out = execute_tool(call["name"], call["args"])   # 你的实际函数
        results.append(ToolMessage(content=str(out), tool_call_id=call["id"]))
    return {"messages": results}             # 观察结果塞回上下文

# 4. 连成循环：LLM → (有调用) tools → 回 LLM；LLM → (无调用) END
builder.add_node("agent", agent_node)
builder.add_node("tools", tools_node)
builder.add_edge(START, "agent")
builder.add_conditional_edges("agent", should_continue, {"tools": "tools"})
builder.add_edge("tools", "agent")          # 观察完必须回 LLM 再决策

执行过程还原：

1. agent_node 把 messages + 工具定义交给模型；模型若认为需要外部信息，输出 tool_calls=[{name, args}]。
2. should_continue 看到 tool_calls → 路由到 tools_node。
3. tools_node 执行真实函数，把结果包成 ToolMessage 追加进 State。
4. 边 tools → agent 把控制权交回模型：模型现在能看到观察结果，再决定下一步（继续调 / 思考 / 结束）。

关键认知（面试必答）：

• 模型“知道有工具”是因为 bind_tools 把工具名/参数 schema 序列化进了请求；这是模型层的 Function Calling 能力，不是图的魔法。
• “思考”（CoT/推理 token）发生在模型的单次输出内部，LangGraph 不需要单独的“思考节点”；只有当你想要显式“先规划后执行”时，才自己拆 planner / executor 两个节点。
• 工具节点永远不做决定：它只执行 tool_calls 并返回观察；决定权始终在 LLM 节点 + 你写死的路由规则手里。

Q209. LangGraph 的 Node 类型完整清单？

来源：官方文档 Graph API · LangChain 1.0 预置能力

核心要点（按“业务职责”分 7 类）：

1. 确定性代码节点：校验、过滤、聚合、格式转换、字段映射、幂等检查——不碰 LLM，图里最容易被低估的一类。
2. LLM 决策节点：意图分类、路由判断、打分评估、生成回答——内部用 with_structured_output 或 bind_tools。
3. 工具执行节点：执行 tool_calls（调 API、检索、执行代码、发消息），只执行不决定。
4. 子 Agent 节点：一个完整 Agent（自己的循环）作为单个节点，层级编排。
5. 子图节点：编译好的 StateGraph 作为节点嵌入，图组合复用。
6. 人工节点：interrupt() 暂停执行，等人工审批/输入后 resume；高风险操作标配。
7. 虚拟节点：START（入口）和 END（终止），不是函数，是图的边界标记。

按“API 实现”分 5 类：

1. 普通函数节点：def node(state, config, runtime) -> dict，同步或异步（async def 自动支持）。
2. Runnable 节点：直接传 LangChain Runnable（Chain / 模型 / 工具）作为节点，框架自动包装调用。
3. Command 节点：节点返回 Command(update=..., goto=...)，一个节点内同时“更新状态 + 指定下一步”，适合动态跳转。
4. 预置 Agent 节点：create_agent(...) / create_react_agent(...) 生成的完整 Agent 直接当节点；create_agent 内部就是 StateGraph 运行时。
5. Send 动态子任务节点：严格说是“动态扇出机制”不是节点类型——一个节点用 Send(node, payload) 在运行时按数据量创建多个并行子任务（map-reduce）。

容易混淆的边界：

• 条件分支/路由是 Edge 的职责，不是 Node；Node 只做事。
• 并行不是一种节点，而是多个节点在同一 super-step 被同时激活；Send 是实现动态并行的机制。
• interrupt 不是独立节点类，是普通节点内部的暂停原语；暂停后图的状态被 Checkpointer 保存，resume 继续。

面试答法：Node 按职责分七类——代码节点、LLM 节点、工具节点、子 Agent、子图、人工节点、START/END；按实现分五类——函数、Runnable、Command、预置 Agent、Send 子任务。工具节点只是其中一种，而且决定权不在它手里。

Q210. AI 怎么知道走到某节点要审批？Node 里存了任务提示词吗？

来源：LangGraph 官方 HITL（Human-in-the-loop）文档与 interrupt 机制

核心要点（先纠正三个误解）：

1. AI 不会“走到”节点：图是 Python 运行时在遍历，Node 是函数；AI 只会在“包含 LLM 调用的节点”里被运行时调用一次。AI 永远看不到地图，只看得到你喂给它的 messages + 工具 + 提示词。
2. “需要审批”不是 AI 判断的，是你硬编码的：审批节点是图结构里固定的一条路径——要么“这条边必经审批”，要么“路由函数发现敏感操作就进审批”。AI 没有被问过“要不要审批”。
3. Node 里不存放“任务提示词”：提示词在 LLM 调用时传入；审批节点的本质是 interrupt() 暂停原语 + 给人类看的载荷，不是给 AI 的指令。

审批节点的真实机制（interrupt）：

def approve_node(state: State) -> dict:
    decision = interrupt({
        "question": "是否允许执行以下操作？",
        "action": state["pending_action"],     # 例如 send_email
        "params": state["pending_params"],     # 例如 收件人/内容摘要
    })  # ← 图在这里暂停：状态已存 Checkpointer，等人类回复
    return {"approval": decision}              # 人类决定写回 State

怎么“走到”审批节点的（两种方式）：

# 方式 A：静态必经——发邮件前永远先审批
builder.add_edge("prepare_send", "approve")   # 无条件先过审批
builder.add_edge("approve", "send")

# 方式 B：条件路由——代码检查模型要调的工具，敏感操作才审批
def route_by_tool(state: State) -> str:
    last = state["messages"][-1]
    if last.tool_calls and last.tool_calls[0]["name"] in {"send_email", "delete_record", "pay_order"}:
        return "approve"        # 模型想调危险工具 → 拦截进审批
    return "execute"            # 普通工具直接执行

builder.add_conditional_edges("agent", route_by_tool,
                              {"approve": "approve", "execute": "execute"})

审批后的恢复（resume）：

# 人类在 UI/命令行给决定，运行时用 Command 恢复执行
from langgraph.types import Command
app.invoke(Command(resume={"allow": True, "comment": "同意，收件人已确认"}),
           config={"configurable": {"thread_id": "order-123"}})
# approve_node 的 interrupt() 返回这个值 → 写入 State["approval"] → 边决定 send/cancel

执行过程还原（一个“AI 想发邮件”的完整链路）：

1. agent（LLM）输出 tool_calls=[send_email]——AI 只做了“想发邮件”这个决定。
2. 路由函数发现工具名在敏感清单里 → 返回 "approve"（这是你的代码，不是 AI 的提示词）。
3. 运行时进入 approve_node，调用 interrupt() → 暂停，Checkpointer 保存状态，等待人工。
4. 人类看到载荷（动作+参数+问题），回复允许/拒绝。
5. interrupt() 返回值被写进 State，边路由到 send 或 cancel。

那提示词在哪？ 提示词只出现在两类地方：

• 你调用 LLM 的节点里：system_prompt="你是客服，发邮件前必须说明收件人与内容"——这是给 AI 的行为约束，不是审批机制。
• 审批 UI 给人类看的文案（question 字段）——这是给人看的，AI 根本不读。

面试一句话：审批是图结构层面的“安全闸门”，不是 AI 的能力；AI 只负责输出意图（tool_calls），路由代码决定敏感操作必须进 interrupt() 的人工节点，人类决定后通过 Command(resume=...) 恢复执行。

Q211. LangGraph 是不是用来“规范 AI 要进行哪些操作”的？

来源：LangGraph 官方“Nodes do the work, edges tell what to do next”设计哲学

核心要点（是的，但规范方式不是“给 AI 看流程图”）：

LangGraph 确实是“规范 AI 操作”的编排层，但它的规范靠三条代码手段，而不是把任务清单存在 Node 里让 AI 自己读：

手段一：路径规范（图结构决定 AI 何时被调用、调用几次）

• 图决定 AI 在哪个节点出现：比如 classify 节点调一次模型、agent 节点在循环里反复调模型。
• 图决定能不能回头：tools → agent 允许 AI 再次决策；recursion_limit 限制循环次数。
• AI 自己不知道这些——它只是“被叫上场演戏的演员”。

手段二：输入规范（调用 AI 时，你只给它看你想让它看的）

def agent_node(state):
    resp = model.bind_tools([search, calculator]).invoke([
        SystemMessage("你是客服，只能查资料和算数，不要做其他事"),
        *state["messages"]
    ])
    return {"messages": [resp]}

• 系统提示词规定行为边界；bind_tools 只暴露允许的工具——模型根本不知道危险工具存在，这就是最强规范。

手段三：输出规范（AI 说了不算，代码校验 + 路由 + 拦截）

def route(state):
    calls = state["messages"][-1].tool_calls
    if calls and calls[0]["name"] not in ALLOWED_TOOLS:   # 白名单
        return "reject"                                     # 越权直接拒绝
    if calls and calls[0]["name"] in SENSITIVE_TOOLS:      # 敏感操作
        return "approve"                                    # 进人工审批
    return "execute"

• 模型输出的 tool_calls 只是“提议”，要不要执行由代码决定：白名单校验、参数 schema 校验、敏感操作审批。

“规范 AI 操作”的分工表（面试直接背）：

一句话总结：LangGraph 规范 AI 操作的方式是“外部流程控制”——图规定 AI 什么时候上场、传什么剧本（prompt/工具）、演完按什么规则下场（路由/白名单/审批）；AI 永远看不到流程图，它只是被图调用的判断引擎。这也正是面试常说的“模型负责判断，代码负责规则”。