真实面经题目 · 原创解析
这题考察的是 AI 工作流编排的技术选型，而不是问 LangChain 好不好。高质量回答要先拆清楚业务复杂度：只是单轮模型调用、少量 prompt 链、RAG 检索增强、工具调用、长流程状态机、多 Agent 协作，还是需要可视化编排、回放、权限、灰度和审计。原生调用的优势是简单、可控、性能和依赖风险低，适合链路短、业务稳定、团队希望自己掌握协议的场景；LangChain 的优势是生态组件多、原型快、抽象现成，适合探索期和标准 RAG/Tool/Agent 流程，但瓶颈是抽象层厚、版本变化、调试复杂、性能和可观测性需要补强；自研引擎适合业务流程复杂、稳定性和治理要求高、需要平台化复用的场景，但成本高、周期长，容易重复造轮子。最终选型不是三选一的宗教问题，而是按阶段演进：原型期可以用框架提速，核心生产链路要收敛成自己的稳定接口和可观测执行模型。
我会先按复杂度选型。如果只是几个固定 prompt、一次 RAG 检索或简单工具调用，原生调用最合适，因为代码路径短、依赖少、延迟和错误都可控；把模型 client、prompt 模板、重试、日志和 schema 校验封装好就够了。如果处在探索期，需要快速验证 RAG、tool calling、memory、agent executor、向量库连接和各种 loader，LangChain 能显著提高原型速度，生态也方便。但生产化时要警惕抽象过厚、版本不稳定、链路调试困难、token/成本不可见、异步和并发控制不细等问题，所以要加 tracing、callback、超时、限流和自己的 adapter。自研引擎适合工作流很多、状态复杂、需要 DAG/状态机、人工审批、回放补偿、权限、灰度、审计和统一观测的平台场景；缺点是研发成本高，早期容易过度设计。我的建议是：探索用 LangChain，简单高频链路用原生，复杂且可复用的核心链路沉淀自研编排内核；同时用统一节点接口、状态模型和 trace，把三者隔离在可替换边界内。
选型前要判断工作流形态。第一类是单次 LLM 调用或少量 prompt 串联，核心是稳定调用和输出解析；第二类是 RAG，包含 query rewrite、召回、rerank、上下文拼接和答案生成；第三类是工具调用和 Agent，涉及计划、执行、观察、重试和循环控制；第四类是企业级流程，包含多节点状态、人工审核、权限、补偿、回放、版本和审计。复杂度越低，框架收益越小；复杂度越高，原生手写越容易散落成不可维护的流程代码。
原生调用本质是直接使用模型 SDK/HTTP API，加一层自己的 client 封装。优势是路径短、延迟低、依赖少、调试直接、错误边界清楚，对流式输出、取消、超时、结构化解析和日志都能精细控制。适合高频生产接口、固定 prompt、严格 SLA、对性能敏感或安全合规敏感的场景。瓶颈是当流程节点变多后，重试、状态传递、分支、并行、工具注册、上下文管理会分散在业务代码里，复用和可观测性变差。
LangChain 的价值在于现成抽象和生态：LLM wrapper、PromptTemplate、Retriever、VectorStore、Tool、Agent、Chain、Callback、OutputParser 等可以快速拼出 RAG 或工具调用 demo。它适合探索期、POC、团队对 LLM 组件不熟悉、需要快速接多种向量库或工具的场景。问题在于抽象层可能掩盖真实请求和状态流，版本演进较快，错误栈较深，性能开销和 token 成本不一定透明。生产化必须把 trace、节点输入输出、超时、重试、并发、缓存、schema 校验和安全策略纳入自己的治理体系。
自研不是从第一天就写一个庞大框架，而是在业务复杂到需要统一执行模型时才有意义。例如有大量 AI 工作流、每个流程有 DAG/状态机、节点可复用、需要人工审核、失败补偿、断点续跑、灰度、版本、权限、审计和成本核算。自研引擎可以定义自己的 node interface、state store、scheduler、event log、retry policy、tool registry 和 observability，和公司内部权限、数据、发布系统深度集成。瓶颈是研发投入高、抽象难度大、早期功能不如开源生态丰富，还要长期维护文档、SDK 和运行时稳定性。
选型要看多个维度。开发效率：LangChain 通常最快，原生次之，自研最慢；运行性能和可控性：原生和自研更强，框架要看封装深度；可观测性：自研最好统一，LangChain 需要接入 callbacks/tracing，原生需要自己埋点；生态：LangChain 更丰富；长期维护：原生简单但流程多时会碎片化，自研统一但成本高；团队能力：如果团队没有平台研发和 LLM 工程经验，贸然自研容易失败。面试中最好明确“短期交付”和“长期平台化”的取舍。
一个务实路径是：探索期用 LangChain 快速验证 prompt、检索、工具和 Agent 思路；当某条链路进入生产高频调用时，把关键路径沉淀为原生或内部 SDK，减少不必要抽象和依赖；当多个业务都在复制类似的节点、状态和治理需求时，再抽象自研工作流引擎。这样不会为了简单链路过度设计，也不会让复杂流程长期堆在业务代码里。即使使用 LangChain，也应该通过内部接口封装，避免业务直接到处依赖框架类型。
AI 工作流的生产难点不是把节点连起来，而是运行中如何解释和控制。Agent 可能循环调用工具导致 token 爆炸；RAG 可能召回噪声导致幻觉；异步并发可能带来状态竞争；流式输出和工具调用组合后错误恢复复杂；不同节点的 token 成本、耗时和失败率如果不可见，就无法优化。无论选 LangChain、原生还是自研，都必须有 step-level trace、输入输出快照、节点耗时、模型 usage、错误分类、重放能力和灰度开关。
现实中常常不是单选。可以定义内部 `WorkflowNode`、`Tool`、`ModelClient`、`Retriever`、`StateStore` 接口，下面既可以有原生实现，也可以包装 LangChain 组件，还可以接入自研引擎。业务层只依赖内部接口和执行记录，不直接依赖框架细节。这样探索项目可以复用 LangChain 生态，核心生产链路可以替换为原生实现，平台化流程可以迁入自研引擎，迁移成本和框架锁定风险都会低很多。
如果链路非常短、SLA 很严格、需要精细控制流式输出和取消、依赖审计严格，或者团队已经有成熟模型网关和工具调用封装，就不一定需要 LangChain。框架会引入额外抽象和依赖，简单场景下收益可能小于调试和维护成本。
不要一开始做大而全平台。最小版本可以包含统一节点接口、状态对象、顺序/分支执行、超时重试、事件日志、trace、配置化模型调用和输出校验。等多业务复用后再扩展 DAG 可视化、人工审批、补偿、权限和版本管理。关键是先解决真实重复问题。
要补齐超时、重试、限流、熔断、结构化输出校验、节点级 trace、token 和成本统计、prompt 版本管理、错误分类、输入输出脱敏、缓存策略和评测集。还要确认框架版本锁定、依赖安全、异步并发行为和 provider adapter 的稳定性，不能把 demo 代码直接放到线上。
即使用原生，也要抽象出 ModelClient、PromptTemplate、OutputParser、ToolExecutor、Retriever、TraceRecorder 等轻量模块，流程状态要显式传递，节点输入输出要可记录。否则多个业务复制粘贴 prompt 和重试逻辑，后期同样难维护。原生不是裸写，而是少量必要抽象。
不要只看能不能跑通。要看开发迭代速度、线上成功率、节点耗时、token 成本、错误可定位性、回放能力、输出质量、人工介入率、灰度回滚能力和业务指标提升。编排方案的价值是让 AI 流程可控、可解释、可演进，而不是制造更多黑盒。
