面试官视角：如何识别“LangChain 模板工程师”（以及怎么追问出真实能力）
很多候选人能把 LangChain/LlamaIndex 例子跑起来，但一遇到线上问题就无从下手：结构化输出崩、工具超时重试风暴、日志只有聊天记录、成本失控。本文给面试官一套可复用的追问路径与评分标准，快速区分“会拼模板”与“能做工程”：从失败模式、工具契约、观测与评测、到发布灰度与回滚。
📷 Photo by cottonbro studio via Pexels
先说明：你要识别的不是“会不会 LangChain”，而是“能不能把系统跑稳”
很多团队面试 AI 工程师时会掉进一个误区：
- 看候选人能否快速搭一个 RAG/Agent demo
但真实工作里，价值更大的是：
- 出问题能不能定位
- 成本能不能控制
- 能不能灰度发布与回滚
- 能不能把能力做成可迭代组件
所以这篇文章提供的是一套“追问脚本”。你可以直接拿去用。
一、快速筛查：3 个问题 5 分钟定性
问题 1：你做过的 Agent 系统，最常见的失败是什么？你怎么定位？
模板型回答：
- “偶尔会幻觉，我们加了 prompt”
工程型回答（至少包含 2 个维度）：
- 失败分类（解析错/工具错/超时/限流/回执漂移/权限）
- 定位手段（事件日志、trace、回放、样本集）
- 修复闭环（加校验、改 schema、降级策略、灰度验证）
如果候选人只能讲“调 prompt”，基本可以归为“模板熟练但工程薄”。
问题 2：结构化输出崩了怎么办？
追问要点：
- JSON Schema 是否严格（
additionalProperties: false） - 解析失败后是否有修复链路（re-ask、repair、fallback）
- 输出是否有“合同”（必填字段、枚举、错误码）
可参考这类工程化视角：
问题 3：工具超时/429 怎么治理？
听答案里是否包含：
- 超时预算（总 budget + 分段 budget）
- 退避与抖动（避免重试风暴）
- 降级策略（缓存/弱一致/延后任务）
- 熔断与隔离（避免拖垮全局）
这类回答能直接映射到稳定性基线：
二、深入追问脚本：从“能跑”追到“能上线”
下面是一套顺序很重要的追问路径：
1）追问：你的 Agent 任务是怎么定义“完成”的？
要点：
- 输出合同（格式、字段、失败与追问）
- 校验器（verifier）在链路的哪个位置
- 不满足合同如何处理（追问/停止/降级）
能讲清这一步的人，往往不是“拼模板”。
2）追问：你怎么避免重复执行与副作用？
听是否出现：
- 幂等键（write 操作必备）
- 去重策略（消息重复投递/用户连点）
- 补偿事务（失败如何恢复）
如果候选人只讲“重试”，但没讲幂等，风险很大。
3）追问：日志长什么样？你能回放一次失败吗？
模板型系统常见现状：只有聊天记录。
工程型系统会有：
- 事件日志（工具输入/回执/耗时/错误码）
- trace（跨服务链路）
- 运行 ID（runId）与 stepId
- 可回放（replay）机制
如果候选人说不清日志结构，后续几乎做不了运营与迭代。
可观测基线参考：
4）追问：你怎么评估质量？如何证明改动有效？
要点：
- 离线评测集（真实样本，不是自己编的 3 条）
- 在线 A/B 或灰度
- 指标：通过率、返工率、追问轮数、成本、时延
“没有评测，只看感觉”基本就是模板工程。
5）追问：成本怎么控？什么时候开/关某些能力？
听是否出现：
- token 预算与工具预算
- 动态路由（小模型优先/大模型兜底）
- 按需触发（例如仅高价值任务启用多采样）
如果候选人能把 ROI 说成“可算”，基本是强工程型。
三、给面试官的评分表（建议直接打分）
你可以按 5 个维度各 0-2 分打分，总分 10 分：
- 正确性：输出合同 + 校验器
- 可靠性：超时/限流/幂等/熔断
- 可观测：事件日志 + trace + 回放
- 可迭代：评测集 + 灰度 + 回滚
- 成本意识：预算、路由、触发策略
经验上：
- 0-3 分：模板型（能跑 demo）
- 4-7 分：可培养（能理解工程化，但细节不足）
- 8-10 分：工程型（能上线、能运营、能迭代）
四、对候选人的建议：如何避免被判成“模板工程师”
如果你是候选人，想快速提升这题的答法，可以把你做过的项目补齐四块：
- 失败分类（你见过哪些失败，如何处理）
- 合同与校验（Schema、verifier、fallback）
- 可观测（事件日志、trace、runId）
- 评测与灰度（样本集、指标、回滚）
哪怕你没做过大型系统，只要你能清晰讲出“如果让我做，我会怎么做，为什么这么做”，也能明显拉开差距。
常见问题
面试里到底要不要考 LangChain 细节 API？
不建议。框架 API 会变，也不代表工程能力。更好的做法是考：契约、容错、观测、评测、成本。让候选人用熟悉的框架表达即可。
如何让题目更贴近真实工作？
给一个带失败的场景：例如“一个写操作工具偶发超时，系统开始重试导致重复扣费”，让候选人讲端到端处理与止损。真正做过系统的人会自然提到幂等键、重试策略、事件日志与回滚。