面经策

LangChain 的 Agent 执行流程是怎样的？ ​

  • 标签：LangChain、Agent 原理

🏛 业务架构师 ​

LangChain Agent 的执行流程（以现代 create_react_agent / AgentExecutor 为准）：

1. 输入装配：用户输入 + System Prompt（角色、规则）+ 工具清单描述（名称/功能/参数 Schema）+ 对话历史（可选）——组装进模型上下文。

2. 模型决策：LLM 分析任务，输出两种可能——直接回答（文本）或工具调用意图（结构化的工具名+参数）。

3. 分支处理：

  • 有工具调用 → 进入执行：框架对参数做校验 → 执行工具（真实 API 调用）→ 结果作为 ToolMessage 回填消息列表；
  • 无工具调用（finish）→ 输出最终答案，流程结束。

4. 循环：回填后把更新过的消息列表再次交给模型——模型看到工具结果继续决策（再调工具、或生成答案）……循环直到：模型给出最终答案 / 触发 max_iterations / 超时 / 错误熔断。

5. 收尾：输出答案 + 记录 trace（每步的输入输出、token、耗时——Callback 机制采集）。

业务视角看流程里的治理点：

  • 第 2 步的工具描述质量决定选对率（描述是给模型看的说明书）；
  • 第 3 步是权限与审计的卡口（鉴权、限流、幂等、日志都建在工具执行前后）；
  • 第 4 步的熔断参数（最大步数/预算）决定失控面；
  • 全程的 trace 决定可运营性。

一句话总结：Agent 执行流程就是"ReAct 循环的工程化"——模型出意图、框架管执行、循环有熔断、全程有留痕。理解流程的目的不是背步骤，而是知道在哪个环节治理什么风险。

🏗 系统架构师 ​

LangChain Agent 的执行流程（以 ReAct 型 / LangGraph 的 create_agent 为准）：

六步循环：

  1. 上下文装配：System Prompt（角色+规则）+ 对话历史 + 工具定义（name/description/schema）注入模型；
  2. 模型决策：LLM 分析任务 → 三种输出之一：(a) 最终文本答案（循环结束）、(b) 工具调用意图 {"name":..., "args":...}（可能并行多个）、(c) 追问用户；
  3. 工具执行：框架解析意图 → Schema 校验 → 权限检查 → 执行（同步/异步，沙箱内）→ 异常捕获转结构化错误；1.x 后这步由 ToolNode 统一处理（含并发执行）；
  4. 结果回填：工具结果封装为 ToolMessage 追加到消息列表（超大结果先截断/摘要）；错误也回填——模型读错误改道；
  5. 循环判断：回到第 2 步继续推理；终止条件——无工具调用的输出 / 步数上限 / token 预算 / 超时熔断；
  6. 收尾：输出最终答案 + trace（每步的决策与工具调用记录——审计与调试资产）。

生产化的关键外壳（架构师强调）：

  • 循环必须戴镣铐：max_iterations、token/成本预算、同工具同参重复检测——裸循环 = 死循环烧钱事故；
  • 状态持久化：LangGraph checkpointer 每步快照——中断恢复、时间旅行调试、human-in-the-loop（工具审批挂起等待人工放行）；
  • 错误语义设计：工具错误"原因+建议"结构化返回，模型可自救；连续失败升级人工；
  • 可观测：每步打点（决策理由、工具延迟、token 消耗）——Agent 的调试靠 trace 不靠猜。

本质：Agent 执行 = 以 LLM 为状态转移函数的循环，可靠性来自循环外的工程约束。

💻 全栈开发专家 ​

LangChain Agent 的执行流程（新版 create_agent/LangGraph 视角，原理同 AgentExecutor）：

循环六步：

1. 组装输入：system prompt + 对话历史 + 工具 schema 列表 + 用户问题
2. LLM 决策：模型输出 —— 纯文本（候选最终答案）或 tool_calls（工具名+参数）
3. 工具路由：解析 tool_calls，逐个匹配注册的工具
4. 执行工具：参数校验 → 调用（超时/异常捕获）→ 结果格式化
5. 回填观察：结果作为 ToolMessage 追加到消息列表
6. 循环判定：回到 2 继续推理，直到模型不再发起调用（Final Answer）或触发终止条件
python
from langgraph.prebuilt import create_react_agent
agent = create_react_agent(llm, tools=[search, calculator])
result = agent.invoke(
    {"messages": [("user", "A城市的房租中位数是多少，乘以12")]})

生产必配的控制参数：

  • recursion_limit / max_iterations：步数硬上限（防死循环的第一道闸）；
  • 工具执行异常转文本回喂——「工具 X 超时，请换一种方式」让模型自纠，而不是炸循环；
  • handle_parsing_errors：模型输出格式坏时的重试策略；
  • 每步 trace 落盘（LangSmith/自研）——多步循环没有 trace 等于黑盒。

一个真实执行的样貌：用户问复合问题 → 模型先调 search 拿房租数据 → 观察结果 → 再调 calculator 乘 12 → 综合两步结果作答。整个过程 2~3 轮 LLM 调用，token 成本约为单轮问答的 3~5 倍——Agent 的便利是用推理次数买的，简单任务别上 Agent。