面经策

解释 LangChain 框架中的 Chain 和 Agent 概念，并举例说明各自的应用场景 ​

  • 标签：大模型

🏛 业务架构师 ​

在 LangChain 里 Chain 和 Agent 是两种控制模式，我用业务场景说明：

Chain——固定流水线，人定流程。开发者预先编排好"检索→组装提示→调模型→解析输出"的固定链路，模型只负责每个节点的内容生成。典型场景：智能客服 FAQ——用户问题进来，固定走"查知识库→生成答案"，路径确定、成本可控、时延可预期。适合流程能穷举、追求稳定的生产场景。

Agent——动态决策，模型定流程。模型根据任务自主决定"下一步调什么工具、要不要再来一轮"。典型场景：内部数据分析师 Agent——"帮我看下上季度华东区为什么销量下滑"，模型自己决定先查销量表、再查竞品价格、再做对比计算，每步取决于上一步结果。适合开放性、多步骤、无法预知路径的任务。

业务选型的分界线：流程可预见且需要稳定 SLA 用 Chain；任务开放但可容错用 Agent。实践中最佳组合是"Graph 包 Agent"——用 LangGraph 定主干流程（可控、可审计），在需要灵活性的节点内嵌 Agent 自主决策。这样既拿到确定性，又保留智能性，是我给企业做 Agent 落地的默认架构。

🏗 系统架构师 ​

Chain 和 Agent 是 LangChain 的两种控制流范式，我用"谁做决策"区分：

Chain——开发者预定义的静态流水线：

  • 结构：Prompt → Model → Parser（+ 检索、工具）按固定顺序编排，LCEL 串联；
  • 场景：文档问答（检索→生成）、文本抽取、翻译摘要、固定格式转换。特点：路径确定、延迟可预估、成本可预估、容易测试；
  • 举例：客服知识库问答——查库→组装 Prompt→生成→解析，一条 LCEL 链 10 行代码。

Agent——模型动态决策的循环：

  • 结构：LLM + 工具集 + 执行循环（ReAct），模型自己决定调什么工具、调几轮；
  • 场景：路径无法预知的任务——"查一下这个客户的退款工单状态并给出处理建议"（可能要查订单、查工单、查政策，顺序不定）；
  • 代价：延迟与成本方差大（每步一次 LLM 调用）、需要熔断与重试治理。

架构师决策规则：能 Chain 不 Agent——确定性、可测性、成本可控性都是工程美德；只有"下一步做什么必须由模型根据中间结果判断"时才上 Agent，且必须配步数上限、预算熔断、工具白名单。生产系统里成熟的做法是混合体：外层 Chain 编排阶段，局部环节（工具选择）交给 Agent。

💻 全栈开发专家 ​

Chain 和 Agent 的本质区别：控制流在谁手里。Chain 是开发者写死的流水线（DAG），Agent 是模型动态决策（带循环）。

Chain 的应用场景（流程可预知）：

  • RAG 问答：检索→格式化→生成，固定两步，用 LCEL 串起来，快、稳、便宜；
  • 摘要流水线：map-reduce 长文摘要；
  • 固定 ETL：抽取→翻译→润色。
python
chain = retriever | format_docs | prompt | llm | parser  # 固定管道

Agent 的应用场景（步骤无法预知，需要模型看情况定）：

  • 运维助手：可能是查日志、也可能是重启服务、也可能要连查三步；
  • 数据分析：模型自己决定先看 schema 还是先跑 SQL；
  • 多工具客服：查订单/查物流/办退款动态组合。
python
agent = create_react_agent(llm, tools=[查订单, 查物流, 退款], prompt)

我的选择原则：能用 Chain 绝不用 Agent——Chain 无循环、延迟可控、成本可预估；Agent 每一步都是一次 LLM 调用，token 和时间都翻倍，还有跑飞风险。真实系统里经常是混合：外层 Chain 固定主干，个别节点按需挂 Agent。先问「这步是不是真的需要模型做决策」，大部分时候答案是不要。