题目分类方向主流 Agent 框架生态 / LangChain Chain 与 Agent 选型面试属性LLM 应用编排与架构选型题适合考察候选人能否区分固定工作流和动态决策循环并根据确定性、成本、风险和工具需求选择方案考察点能否说明 Chain 是开发者预先定义步骤和数据流的固定编排现代 LangChain 中常由 Runnable / LCEL 表达能否说明 Agent 由模型根据当前状态动态选择工具和下一步动作但真实执行与终止仍由 Runtime 控制能否从控制权、执行路径、调用次数、状态、延迟、成本、可测试性和风险比较两者能否给出固定 RAG、抽取、分类等 Chain 场景以及跨系统查询、研究、工单处理等 Agent 场景能否坚持“能用 Chain 就不用 Agent”的最小复杂度原则同时识别需要动态决策的真实条件能否说明 Chain 与 Agent 可以组合并覆盖权限、幂等、预算、Trace、评估、降级和人工审批通俗讲解Chain 和 Agent 都是在组织模型完成任务但它们最大的区别是下一步由谁决定。Chain 像一条提前设计好的流水线。开发者规定先做什么、后做什么例如用户问题 → 检索知识库 → 拼接 Prompt → 调用模型 → 校验引用 → 返回答案无论用户问什么请求都沿着代码定义的路径执行。某一步可以调用 LLM但“下一个节点是谁”主要由程序决定。Agent 更像一个受控调度员。开发者提供目标、工具和规则模型根据当前任务与工具结果提出下一步动作例如先查订单再查物流发现异常后创建工单。执行工具、检查权限、记录状态和判断是否超出预算仍由 Agent Runtime 完成。不要把它理解成“Chain 不智能Agent 更高级”。如果任务路径稳定用 Agent 只会增加模型调用、延迟、成本和不确定性。真正的工程原则通常是固定流程优先 Chain只有步骤、工具或循环次数无法预先确定时才使用 Agent。知识讲解在 LangChain 中Chain 和 Agent 代表两种不同的任务编排方式。Chain 强调开发者定义的数据流与执行顺序Agent 强调模型在受控循环中根据 Observation 动态选择 Action。1. Chain 是什么Chain 是由多个可执行步骤组成的固定调用链。输入会按照预先定义的顺序经过 Prompt、Model、Retriever、Parser、业务函数或其他 Runnable最终形成输出。现代 LangChain 更常用 Runnable 和 LangChain Expression LanguageLCEL表达这种组合。历史版本中的许多专用 Chain 类已经不再是理解框架的唯一入口但“固定工作流”这一概念仍然成立。Chain 的关键特征是路径由代码定义模型通常不决定下一步调用哪个节点。输入输出契约更清楚容易做单元测试、回放和故障定位。模型调用次数通常可预估因此延迟和成本更可控。适合稳定、重复、可分解为确定步骤的任务。典型场景包括固定 RAG 问答、文本摘要、分类、信息抽取、翻译、内容审核、结构化输出以及“检索后生成再校验”这类确定流水线。2. Agent 是什么Agent 是由模型参与控制流决策的任务执行机制。模型读取用户目标、消息状态、可用工具及已有 Observation决定是调用某个工具、继续推理还是返回最终答案。一次典型 Agent 循环是Runtime 组装用户任务、状态、规则和工具描述。模型输出最终回答或结构化 Tool Call。Runtime 校验工具名、参数、权限和风险等级。应用代码执行工具把结果作为 Observation 写回状态。模型根据新状态决定下一步直到完成、失败、暂停或达到预算。现代 LangChain 的createAgent使用 LangGraph Runtime 构建图式 Agent。模型拥有的是“提出下一步意图”的权力不是绕过系统直接执行数据库、支付、邮件或文件操作的权力。典型场景包括多来源研究助手、跨系统客服处置、动态故障排查、旅行规划、代码修复和需要根据中间结果选择不同工具的任务。图解 1下面这张图对比 Chain 的固定流水线与 Agent 的动态决策循环。3. Chain 和 Agent 的核心区别控制权不同。Chain 的控制流主要写在代码里Agent 允许模型在工具白名单和运行时规则内决定下一步。路径稳定性不同。Chain 的节点和顺序通常确定Agent 可能因用户问题、模型输出和工具结果产生不同路径、分支和循环次数。成本与延迟不同。Chain 的模型调用次数较稳定Agent 可能多轮调用模型和工具成本、延迟与失败概率会随循环步数增长。测试方法不同。Chain 可逐节点断言输入输出Agent 除了最终答案还要评估工具选择、参数正确率、轨迹、步数、停止原因、任务成功率和人工接管率。风险不同。Chain 更容易限制副作用Agent 会动态选择动作需要额外处理工具注入、越权、重复执行、死循环、上下文污染和 reward hacking 等问题。适用问题不同。Chain 适合已知解法和稳定 SOPAgent 适合“目标明确但完成路径不能提前写死”的任务。4. Chain 的应用场景示例固定 RAG 是最典型的 Chain问题先经过 query rewrite再检索文档、Rerank、组装上下文、调用模型并校验引用。每一步都可提前定义不需要模型决定“今天是否应该跳过权限过滤”。合同字段抽取也适合 Chain文档解析、分段、字段抽取、JSON Schema 校验、业务规则校验和人工复核阈值都是固定步骤。即使中间使用 LLM控制流依然确定。批量内容处理同样适合 Chain例如对客服对话依次做脱敏、分类、摘要和质检打分。固定链路更便于并发、缓存、重试和成本核算。5. Agent 的应用场景示例跨系统客服处置适合 Agent。用户只说“我的退款为什么还没到账”系统可能需要查订单、支付记录、退款流水、物流状态和客服规则。具体调用哪些工具、调用顺序和是否创建工单取决于每一步返回的数据。研究助手也适合 Agent。模型可能先拆解问题搜索多个来源发现证据冲突后补充检索再运行计算工具或读取文件最后生成带引用结论。路径和迭代次数难以完全预先定义。生产故障排查可以使用受控 Agent。它根据告警先查指标再按结果选择日志、Trace、配置或发布记录工具。但重启服务、回滚版本等高风险动作必须要求审批不能只根据模型输出直接执行。6. Chain 与 Agent 可以组合真实系统通常不是二选一。更稳妥的架构是“确定性外壳 有限 Agent 岛”入口鉴权、数据脱敏、预算、结果校验和发布动作使用固定 Chain只有确实需要动态判断的局部环节交给 Agent。Agent 也可以把一个成熟 Chain 包装成 Tool例如把固定 RAG Chain 暴露为search_internal_knowledge让 Agent 决定何时调用但检索、权限过滤、Rerank 和引用校验仍在 Chain 内确定执行。反过来Chain 也可以在某个明确节点调用 Agent然后继续进入固定的输出校验和审批流程。这种组合能在自治性和可控性之间取得平衡。图解 2下面这张图展示如何根据路径确定性、工具选择和风险决定使用 Chain、Agent 或混合架构。代码示例下面使用当前 LangChain JavaScript 风格分别展示固定 Chain 和动态 Agent。示例重点是控制流差异模型名和业务函数应按实际项目替换。固定 Chain开发者定义 Prompt、Model 和 Parser 的执行顺序。代码语言TypeScript自动换行AI代码解释import { ChatPromptTemplate } from langchain/core/prompts; import { StringOutputParser } from langchain/core/output_parsers; import { RunnableSequence } from langchain/core/runnables; import { ChatOpenAI } from langchain/openai; const model new ChatOpenAI({ model: your-chat-model }); const summaryChain RunnableSequence.from([ ChatPromptTemplate.fromTemplate( 请把下面的客服对话总结成问题、处理结果、待办事项。\n\n{dialogue}, ), model, new StringOutputParser(), ]); const summary await summaryChain.invoke({ dialogue: 用户退款还没到账。客服我会核对支付流水。, });动态 Agent模型根据任务和 Observation 决定调用哪个工具以及是否继续。代码语言TypeScript自动换行AI代码解释import * as z from zod; import { createAgent, tool } from langchain; const getOrder tool( async ({ orderId }) orderService.getOrder(orderId), { name: get_order, description: 查询当前用户可访问的订单状态, schema: z.object({ orderId: z.string() }), }, ); const getRefund tool( async ({ orderId }) paymentService.getRefund(orderId), { name: get_refund, description: 查询订单对应的退款流水, schema: z.object({ orderId: z.string() }), }, ); const supportAgent createAgent({ model: your-provider:your-chat-model, tools: [getOrder, getRefund], systemPrompt: 只查询当前用户有权限访问的数据缺少订单号时先询问。, }); const result await supportAgent.invoke({ messages: [ { role: user, content: 订单 A1024 的退款为什么还没到账 }, ], });代码讲解summaryChain的三个节点和顺序由开发者提前定义。模型只负责其中的生成步骤不会临时决定去查询订单或创建工单。它适合稳定摘要任务调用次数、失败位置和输出类型容易预测。supportAgent获得两个工具后可以根据问题先选择订单查询或退款查询再根据 Observation 决定是否继续。createAgent负责组织模型节点、工具节点和循环但模型产生 Tool Call 不等于工具已执行工具包装器和 Runtime 仍需要做身份、权限、Schema、超时、审计和错误处理。示例中的 system Prompt 只能表达行为要求不能替代权限边界。orderService和paymentService必须使用可信的当前用户身份执行服务端授权不能接受模型自行生成的 userId 作为访问依据。工程深挖第一默认选择最小必要复杂度。如果固定 Chain 可以达到目标就不应为了“更像 Agent”而引入动态循环。更复杂的控制流意味着更多模型调用、更多状态、更难复现的失败和更高评估成本。第二Agent 的工具集合要小而明确。工具过多会占用上下文并提高误选概率工具描述重叠会让路由不稳定。可以按用户权限、任务阶段和 feature flag 动态过滤工具但过滤逻辑必须由系统控制。第三所有副作用都要在 Runtime 层治理。发邮件、退款、删除数据、创建工单等动作需要参数校验、权限、审批、幂等键和审计。模型负责提出候选 Action不能成为最终授权主体。第四两者的 Trace 粒度不同。Chain 要记录每个 Runnable 的输入输出、版本、耗时和错误Agent 还要记录每轮模型决策、Tool Call、Observation、状态变化、循环步数、stop reason、token、成本和人工介入。第五评估不能只看最终答案。Chain 需要节点级与端到端测试Agent 还应评估工具选择准确率、参数正确率、轨迹效率、任务成功率、越权率、重复副作用率、平均步数和预算超限率。第六要为 Agent 设置硬停止条件包括最大步数、总 token、总耗时、单工具超时、失败重试次数和人工接管条件。Prompt 中写“不要死循环”不是运行时控制。第七复杂长流程不要堆进黑盒 Agent。涉及显式分支、持久化、暂停恢复、人工审批和跨系统事务时应使用 LangGraph 等状态图把控制流建模出来而不是依赖模型隐式记住流程。面试回答LangChain 里的 Chain 和 Agent 都用于组织 LLM 应用但核心区别是下一步由谁决定。Chain 是开发者预定义的固定工作流。输入会按照确定顺序经过 Prompt、Retriever、Model、Parser 或业务函数。现代 LangChain 中通常可以用 Runnable 和 LCEL 组合这类链路。它的优势是路径稳定、容易测试、延迟和成本可估算适合固定 RAG、摘要、分类、抽取、翻译和结构化输出。Agent 是模型参与控制流决策的受控循环。模型根据任务、状态和工具描述提出下一步 Tool CallRuntime 校验并执行工具再把 Observation 返回模型直到模型给出最终答案或触发停止条件。它适合完成路径不能提前确定的任务例如跨系统客服处置、研究助手和动态故障排查。我不会把 Agent 理解成比 Chain 更高级。工程上应该能用 Chain 就先用 Chain因为 Agent 会增加模型调用、状态、延迟、成本和失败面。只有工具选择、步骤顺序或循环次数确实依赖中间结果时才引入 Agent。真实项目通常采用混合架构鉴权、脱敏、预算、校验和高风险动作放在确定性 Chain 中局部动态决策交给 Agent成熟的 RAG Chain 也可以包装成 Agent Tool。无论使用哪种方式都要有 Trace、Eval、权限、幂等、超时、降级和回滚。面试官追问Chain 中使用了 LLM为什么还说它是确定性的回答方向模型输出本身可能随机但节点顺序和控制流由代码预定义确定性描述的是编排路径而不是保证文本输出完全相同。Agent 是不是可以直接执行工具回答方向模型只生成 Tool Call 意图Runtime 或应用代码负责校验、授权、真实执行和 Observation 回传。什么情况下应该从 Chain 升级为 Agent回答方向当下一步工具、执行顺序或循环次数必须根据中间结果动态决定并且固定分支已经难以维护时。Chain 和 Agent 能否组合回答方向可以。Agent 可把固定 Chain 当 ToolChain 也可在局部节点调用 Agent并在外层保留鉴权、校验和审批。Agent 为什么更难测试回答方向路径和步数动态变化需同时评估结果、工具选择、参数、轨迹、停止原因、成本和安全而不只是单次输出。Agent 出现死循环怎么处理回答方向Runtime 设置最大步数、预算、超时、重复 Action 检测和人工接管并通过 Trace 定位无进展循环。Chain、Agent 和 LangGraph 是什么关系回答方向Chain 表达固定 Runnable 流程LangChain Agent 提供高层动态工具循环复杂分支、状态、暂停恢复和人工介入可显式使用 LangGraph 编排。高分回答要点用“下一步由代码还是模型决定”快速抓住 Chain 与 Agent 的核心边界能区分固定控制流和模型输出随机性不把 Chain 错说成结果完全确定能给出固定 RAG、抽取与跨系统处置、研究助手等真实场景能坚持最小复杂度原则并说明 Agent 带来的延迟、成本和评估负担能解释模型提出工具意图、Runtime 执行工具的责任边界能给出确定性外壳、局部 Agent 和 Chain-as-Tool 的混合架构常见扣分回答只说 Chain 是链、Agent 是智能体没有解释控制权和运行机制把 Chain 说成输出必然相同混淆固定路径与模型生成随机性认为 Agent 天然比 Chain 高级所有 LLM 应用都应该使用 Agent认为模型会直接执行工具忽略权限、Schema、幂等、审批和审计只比较功能不讨论调用次数、延迟、成本、测试和失败恢复对复杂 Agent 没有 Trace、预算、停止条件和人工接管设计项目结合话术做企业知识助手时我会先把权限过滤、检索、Rerank、Prompt 组装、引用校验和输出解析做成固定 Chain因为这条路径稳定、易测也便于定位召回和生成问题。当业务升级为跨系统办事助手需要根据用户问题动态选择知识库、订单、支付和工单工具时再在外层引入 Agent。Agent 只负责选择下一步 Action各工具仍使用服务端身份做权限校验退款、发信等副作用动作必须审批和幂等。固定 RAG Chain 可以封装成一个 Tool 供 Agent 调用全链路记录 Runnable span、Tool Call、Observation、耗时、成本和 stop reason并设置最大步数与降级到人工的条件。一句话总结Chain 让代码控制固定流程Agent 让模型在受控 Runtime 中动态选择下一步选型应从路径是否可预定义出发优先固定 Chain必要时只在局部引入 Agent。参考来源c4g7v1.nuofulai.coms9k2x5.nuofulai.comb3h8r6.nuofulai.comLangChain DocsAgentsLangChain DocsOverviewLangChain DocsToolsLangChain DocsRuntimeLangGraph DocsWorkflows and agentsLangChain v1 release notes