场景设计与可靠性

Q：LangChain 和 LangGraph 有什么区别？分别适合什么场景？

来源：淘宝闪购 AI应用研发 一面

新手答：“LangChain 是做大模型应用的框架，LangGraph 没怎么了解。”

高手答：

两者都是 LangChain 团队的产品，但解决的问题层次不同：

LangChain：链式编排框架

核心抽象是 Chain——把 Prompt、模型调用、输出解析串成一条线性管线。适合流程固定的 LLM 应用，比如“输入→检索→生成→输出”这种 DAG 结构。

优势：上手快，生态丰富（文档加载器、向量数据库集成、Tool 抽象）。 劣势：链式抽象不支持循环和条件分支——而 Agent 的核心特征就是“根据结果决定下一步”，这需要循环。

LangGraph：有状态图执行框架

核心抽象是 Graph——用节点（Node）和边（Edge）定义执行流程，支持条件分支、循环、并行。每个节点可以读写一个共享的 State 对象。

LangChain：A → B → C（线性管线）
LangGraph：A → B → C（可以从 C 跳回 A，或者 B 分叉成 B1/B2 并行）

适合需要复杂控制流的 Agent——多轮工具调用、条件分支、人工介入（Human-in-the-Loop）、检查点恢复。

选型建议：

场景	选择	原因
简单 RAG 管线	LangChain	线性流程，不需要循环
单步工具调用	LangChain	不需要复杂控制流
多轮 Agent 交互	LangGraph	需要循环和状态管理
多 Agent 协作	LangGraph	需要图结构编排
需要断点恢复	LangGraph	内置 Checkpoint 机制

行业趋势：LangChain 团队自己也在推动从 Chain 向 Graph 迁移——LangChain v0.3 废弃了大量旧抽象，推荐用 LangGraph 做 Agent 类应用。但 LangChain 的生态组件（文档加载器、Embedding 封装）依然有价值。

差距在哪：新手只知道 LangChain 是框架，对 LangGraph 没概念。高手区分了两者的设计哲学——Chain 是线性管线、Graph 是有状态图执行，且能说清楚各自的适用场景和行业演进方向。面试官考的是你对 Agent 开发工具链的了解深度。

---

Q：模型和 Agent 的区别到底是什么？

来源：字节 Agent 开发实习一面

新手答：“Agent 就是模型加了工具调用。”

高手答：

这是 Agent 面试中最基础也最高频的问题，回答必须清晰且有结构。

一句话区分：模型是一个函数（输入 → 输出），Agent 是一个系统（目标 → 自主多步执行）。

四个关键维度的差异：

维度	模型（Model）	Agent
交互模式	单轮：问 → 答	多轮循环：观察 → 思考 → 行动 → 观察 → ...
环境感知	无法访问外部状态	能读文件、调 API、查数据库——感知并作用于环境
自主决策	生成最大概率的下一个 token	决定做什么、用哪个工具、何时停止——拥有自主性
状态管理	无状态（每次调用独立）	跨步骤维护状态（记忆、任务进度、中间结果）

用公式表达：

Agent = LLM + Tools + Memory + Planning Loop

类比：模型是一个装在罐子里的大脑——你问它问题它能回答，但它看不见、摸不着、也记不住上一次对话。Agent 是一个有眼睛、有双手、还有待办清单的大脑——它能感知环境、操作工具、记住进度，并且自主决定下一步做什么。

灰色地带——“带 function calling 的模型”算不算 Agent？

区分的关键在于循环（Loop）。如果模型调一次工具就结束，那只是“增强版模型”。如果它能不经人类干预、自主决定执行多个步骤——观察上一步结果、判断任务是否完成、决定下一步做什么——这才是 Agent。自主循环是 Agent 的定义性特征。

差距在哪：新手只看到了工具调用这一个维度——“加了工具就是 Agent”。高手从交互模式、环境感知、自主决策、状态管理四个维度拆解差异，并指出自主循环才是 Agent 和“模型 + 工具”的根本分界线。面试官用这道题考的是你对 Agent 最基础概念的认知精度——定义模糊的人，后面的架构设计也不会清晰。

---

Q：Agent 的 Self-Reflection 机制是什么？它怎么识别输出中的逻辑错误？

来源：蚂蚁 AI应用开发 二面 【小红书 Agent 开发一面追问：Planner、Executor、Critic 的职责边界】

新手答：「让模型自己检查一遍输出，发现错误就修正。」

高手答：

先把闭环里的三个角色分清：Planner 把目标、约束和当前状态转成带依赖与成功条件的计划，并在前提失效时重规划；Executor 只执行获准的当前步骤，做参数、权限、幂等校验并返回结构化 Observation，不擅自改目标；Critic 按验收标准和证据评估计划、步骤或最终结果，输出通过/拒绝、错误位置和修正建议，但不直接执行工具或静默改写状态。角色之间通过版本化的 Plan、Observation 和 Critique 通信，由编排器决定重试、重规划、终止或转人工。

独立 Critic 不等于普通 ReAct 自检。ReAct 自检通常仍由同一个决策角色在循环里根据 Observation 调整下一步，容易继承生成时的上下文偏差，重点也是局部动作是否继续；独立 Critic 使用隔离的评估上下文、固定 rubric 和外部证据，没有执行权限，可以否决结果并触发重规划。它不一定非要换一个模型，但至少要隔离角色 Prompt、可见上下文和权限，留下可审计的评价结果，否则只是“让原模型再看一遍”。

Self-Reflection 不是简单的「再看一遍」，而是一个结构化的评估-修正循环。核心机制分三层：

1. 输出评估（Critic）

生成结果后，用一个独立的评估 Prompt（或独立模型）对输出做结构化检查：

• 事实一致性：输出中的事实陈述是否与检索到的证据一致
• 逻辑连贯性：推理链条是否存在跳跃、矛盾或循环论证
• 任务对齐度：输出是否真正回答了用户的问题，而非「答非所问」

关键设计：评估 Prompt 不能是泛泛的「检查有没有错」，而要针对具体任务设计检查清单。比如代码生成任务的检查清单包括「语法正确性、边界条件、返回值类型」，客服场景的检查清单包括「信息准确性、语气合规、是否遗漏关键信息」。

2. 错误定位（Localize）

发现问题后，不是推倒重来，而是精准定位出错的步骤。在 ReAct 模式下，可以回溯 Thought-Action-Observation 链条，找到第一个出错的节点——通常是某次工具调用的参数错误，或者某个推理步骤的前提假设不成立。

3. 定向修正（Refine）

只修正出错的部分，保留正确的部分。把错误描述和修正要求拼接到新的 Prompt 中：

原始输出：[完整输出]
发现的问题：[具体错误描述]
请修正上述问题，保留其他正确部分。

底层原理：Self-Reflection 有效的前提是模型的评估能力强于生成能力——模型在「判断对错」时的准确率通常高于「一次生成正确答案」的概率。这是因为评估是一个约束更强的任务（有明确的判断标准），而生成是一个开放性任务。

工程限制：Self-Reflection 不能无限循环——通常限制 1-2 轮。多轮反思的收益递减明显，且 token 成本线性增长。如果两轮反思后仍有问题，应该触发人工介入而非继续循环。

差距在哪：新手把 Self-Reflection 理解为「让模型自查」——这太模糊了。高手展示了三层机制（评估→定位→修正），解释了它有效的底层原理（评估能力 > 生成能力），并指出了工程限制。面试官考的是你对这个机制的理解是停留在概念还是有工程化思考。

---

Q：在“推理-行动”循环中，如何设计来纠正逻辑塌缩或无效工具调用？

来源：淘天 AI Agent 一面

新手答：“失败了就重试，多试几次总能成功。”

高手答：

先定义两个核心问题：

• 逻辑塌缩：模型在推理-行动循环中陷入局部最优——反复用同一个工具、重复相同的推理模式、或者在同一组参数上死循环。本质是模型的“思维多样性”丧失了
• 无效工具调用：选错工具、参数填错、调用了不存在的工具、或者工具返回了错误但模型没有正确处理

我们的纠正体系分三层：实时检测、主动干预、结构预防。

第一层：实时检测

检测信号：
① 重复检测：连续 N 步（通常 N=3）选择同一个工具或生成相似的推理文本
② 无进展检测：执行了 K 步但任务状态没有实质变化（用状态哈希判断）
③ 工具调用异常率：最近 M 次调用中失败率超过阈值（如 >60%）
④ 推理深度超限：总步数超过预设上限（根据任务复杂度动态调整）

第二层：主动干预

检测到异常后，不是简单重试，而是根据异常类型采取不同策略：

异常类型	干预策略
逻辑塌缩（重复工具）	强制排除最近使用的工具，注入“请换一种方法”的反思提示
逻辑塌缩（推理打转）	注入任务进度摘要 + 已尝试方法列表，要求模型重新审视目标
参数错误	结构化错误信息反馈：将工具的参数 schema 和实际传入值一起喂给模型
工具不存在	将可用工具列表重新注入上下文，附带每个工具的功能摘要
多次失败	触发“策略切换”：暂停当前子任务，尝试替代路径或降级方案

第三层：结构预防

从架构上减少塌缩和无效调用的概率：

预防机制的关键设计：

1. 工具调用前置校验：在调用工具之前，用 JSON Schema 校验参数格式和取值范围，拦截明显错误
2. 多样性约束：在工具选择时引入“最近 N 步不重复”的软约束，降低塌缩概率
3. 错误分类与结构化反馈：不是把原始报错扔给模型，而是分类后构造“错误原因 + 建议修正方向”的结构化提示
4. 全局进度追踪：维护一个任务状态快照，每步执行后更新，模型能看到“已完成什么、还差什么”，减少无意义重复

差距在哪：新手只会“失败重试”——这是最低级的容错，对逻辑塌缩完全无效（重试只会重复同样的错误）。高手有检测、干预、预防三层体系：检测层识别异常模式，干预层按异常类型精准应对，预防层从架构上降低问题发生的概率。面试官考的是你对 ReAct 循环失败模式的理解深度——不只是“能跑”，而是“跑偏了怎么纠”。

---

Q：设计一个智能导购助手 Agent，描述其感知、规划、记忆和执行四大模块在分布式架构下的协同逻辑

来源：淘天 AI Agent 一面

新手答：“用大模型对接商品数据库，用户问什么就查什么。”

高手答：

智能导购助手不是一个“大模型 + 商品 API”的简单对接，而是一个四模块协同的分布式系统。

四大模块的职责划分：

模块	核心职责	关键组件
感知（Perception）	理解用户输入，提取意图和实体	多模态理解（文本/图片/语音）、意图分类器、实体抽取器
规划（Planning）	任务拆解，制定推荐策略	任务分解器、策略选择器（精准匹配/探索推荐/比较决策）
记忆（Memory）	维护用户画像和知识	用户画像服务、会话状态管理、商品知识图谱
执行（Execution）	调用下游服务完成操作	商品搜索、比价、加购、下单、库存查询

分布式架构下的协同逻辑：

模块间协同的三个关键设计：

1. 用户画像服务作为共享记忆

记忆模块不是每个请求独立维护的，而是一个独立的用户画像微服务。感知模块提取的实体信息、执行模块的操作结果，都会异步写回用户画像。规划模块每次制定策略前先读取画像，保证推荐的个性化：

用户画像结构：
├── 基础信息：尺码、偏好品牌、价格敏感度
├── 行为序列：最近浏览/购买/收藏的商品
├── 偏好模型：品类偏好向量（基于行为序列计算）
└── 会话上下文：当前对话中的临时约束（预算、场景等）

2. 商品知识图谱作为结构化知识

不是每次都用自然语言去查商品数据库。规划模块可以直接在知识图谱上做结构化查询——“跑步鞋”关联“缓震”、“透气”等属性，“宽脚”关联特定鞋楦型号。这比纯文本检索精确得多。

3. 分布式状态管理

会话状态（用户当前在比较哪几款、已经排除了什么）存在分布式缓存中（如 Redis），每个模块通过会话 ID 读写状态。关键是要做好状态一致性——执行模块发现某商品缺货时，要同步更新会话状态，规划模块下一步才不会继续推荐已缺货商品。

电商场景的特殊挑战：

挑战	应对方案
实时库存变动	执行模块在最终推荐前做库存二次校验，缺货自动替换
价格波动	比价结果加时效标记，超过 5 分钟重新查询
跨品类推荐	规划模块识别“搭配购买”意图后，并行发起多品类搜索
用户犹豫不决	规划模块切换到“对比决策”策略，主动生成对比表格

差距在哪：新手把导购助手当成简单的问答系统——用户问、模型查、返回结果。高手的回答展示了完整的分布式架构设计：四个模块各自独立部署为微服务，通过消息队列解耦；用户画像作为共享记忆保证个性化；商品知识图谱作为结构化知识提升精准度；分布式状态管理保证多模块协同的一致性。面试官考的是你能不能把一个“听起来简单”的需求设计成一个可落地的分布式系统。

---

Q：如果设计一个科研辅助 Agent，整体流程应该怎么设计？

来源：bilibili AI研发实习一面

新手答：“让大模型帮忙搜论文、写摘要。”

高手答：

科研辅助 Agent 不是“搜论文的 chatbot”，而是一个多阶段、闭环迭代的研究管线。设计的核心是把科研工作流拆成可自动化的阶段，每个阶段对应不同的 Agent 能力。

典型的科研 Agent 流程：

各阶段的设计要点：

阶段一：问题理解与分解

用户给出一个研究问题（如“大语言模型在医疗诊断中的应用现状”），Agent 需要：

• 把宽泛的问题拆解成多个具体的子问题（应用场景有哪些？效果如何？局限性？）
• 识别关键术语和概念，为后续检索做准备
• 确定研究范围和边界（时间范围、领域限定）

阶段二：文献检索与筛选

这一步不是简单的关键词搜索，而是迭代式多源检索：

• 第一轮：用关键术语在学术数据库（Semantic Scholar、arXiv API）做广泛检索
• 筛选：按引用数、发表时间、相关度做粗筛
• 第二轮：从初筛论文的引用列表中扩展检索（引文追溯），发现初始检索遗漏的关键文献
• 每轮检索后评估覆盖率，决定是否需要进一步检索

阶段三：知识提取与综合

对筛选后的文献做结构化信息抽取：

• 提取每篇论文的核心方法、实验设置、关键结论
• 跨论文比较：不同方法的效果对比、争议观点识别
• 构建知识图谱：论文之间的引用关系、方法演进脉络

阶段四：假设生成

基于综合分析，生成研究假设或研究方向建议。这一步需要模型的推理能力——不是简单总结现有文献，而是发现研究空白和潜在的创新点。

阶段五：实验设计/验证

如果是代码类研究，Agent 可以直接执行实验（调用代码执行工具跑 benchmark）；如果是理论类，生成实验方案供研究者参考。

阶段六：报告生成

按学术规范生成结构化报告，带引用、图表和结论。

工程实现的关键挑战：

挑战	解决方案
文献量大，单次上下文装不下	分阶段处理：检索阶段只看摘要和元信息，精读阶段按需加载全文
模型可能编造论文引用	所有引用必须来自实际检索结果，生成后做引用校验——对比生成的引用标题与检索结果库
研究方向需要人工判断	在假设生成后设置 Human-in-the-Loop，让用户确认方向再继续
跨学科检索困难	多轮检索 + 查询改写，每轮根据已有发现调整检索策略和关键词

和 Deep Research 产品的关系：

Gemini Deep Research、Perplexity 的深度研究功能，本质上就是这套流程的产品化——用户给一个问题，Agent 自动完成检索→筛选→综合→生成的全流程。区别在于：科研 Agent 对引用准确性和知识完整性的要求远高于通用 Deep Research 产品。

差距在哪：新手把科研 Agent 当成“搜论文+写摘要”的两步流程。高手设计了六阶段闭环管线——问题分解、迭代检索、知识综合、假设生成、实验验证、报告生成——每个阶段有明确的输入输出和质量控制。面试官考的是你能不能把一个领域的工作流拆解成可自动化的 Agent 管线。

---

Q：如何保障自然语言任务描述能精准转化为稳定、可靠的执行路径？

来源：蚂蚁 AI应用开发 二面

新手答：「优化 Prompt，让模型更好地理解任务。」

高手答：

自然语言到执行路径的转化是 Agent 系统最核心也最脆弱的环节。保障策略分四层：

1. 意图结构化（NL → Structured Intent）

不要让模型直接从自然语言跳到执行。先用一步将自然语言转为结构化意图表示——任务类型、关键参数、约束条件、期望输出格式。结构化表示是后续所有处理的基础。

用户：「帮我查一下上周北京到上海的机票，最便宜的」
→ {task: "flight_search", params: {from: "北京", to: "上海", date_range: "上周", sort: "price_asc"}}

2. 执行计划校验（Plan Validation）

模型生成执行计划后，不直接执行，先做校验：

• 参数完整性：必要参数是否都有值
• 工具可用性：计划中调用的工具是否存在且可用
• 逻辑合理性：步骤顺序是否合理（不能在查询前就尝试格式化结果）
• 安全合规：是否涉及高风险操作，需不需要人工确认

3. 确定性兜底（Deterministic Fallback）

对于高频、模式固定的任务，不依赖模型规划，而是用规则引擎或模板匹配直接路由到预设流程。模型只在规则无法覆盖的情况下才介入规划。

高频固定任务 → 规则路由（确定性100%）
中频半固定任务 → 模型规划 + 模板约束
低频开放任务 → 模型自由规划 + 校验兜底

4. 执行监控与回滚

执行过程中持续监控——每一步的输入输出是否符合预期。发现偏离时，优先尝试局部修正；修正失败则回滚到最近的正确状态，而非从头重来。

差距在哪：新手把问题简化为「优化 Prompt」。高手展示了四层保障体系——意图结构化→计划校验→确定性兜底→执行监控，且能说清楚不同任务类型适用不同的可靠性策略。面试官考的是你有没有把「NL→执行」当成一个需要系统性保障的工程问题来设计。

---

Q：多角色智能客服场景（B/C/D 端），用 RAG 还是 Skill？怎么设计？

来源：美团Keeta Agent开发一面

新手答：「全部用 RAG，建一个大知识库。」

高手答：

外卖平台智能客服的核心挑战是问题类型差异巨大——同一个平台上，C 端用户问优惠券和问订单赔偿，需要的处理方式完全不同。不能一刀切。

按问题类型选方案，而非按角色：

问题类型	方案	原因
非订单类（优惠券规则、地址查询、活动说明）	RAG 知识库	答案在文档中，检索即可，不需要操作后端系统
订单类（退款、赔偿、骑手派单异常）	Skill / 工作流	需要读订单状态、执行业务规则、调用后端 API，知识库搞不定
情绪类（投诉、差评安抚）	话术模板 + 工具联动	先安抚（检索话术库），再触发工单或转人工

为什么订单类不能用 RAG：

订单类问题的「答案」不在文档里，而是在实时业务状态中。比如用户说「我的外卖怎么还没到」——答案取决于当前订单状态、骑手位置、预计送达时间，这些是动态数据，不是知识库能预先存储的。处理逻辑也不是生成一段文字，而是执行一系列操作：查订单 → 判断状态 → 按规则赔偿/催单/转人工。

这类问题适合Skill 模式：预定义好业务流程（状态机或 DAG），Agent 在流程框架内填充参数、执行操作，而非自由生成。

多角色（B/C/D）的架构差异：

角色	典型问题	工具集	特殊约束
C 端用户	餐品问题、地址、退款、优惠券	订单查询、退款申请、优惠券查询	需要安抚情绪，赔偿有上限规则
D 端骑手	派单异常、长时间无单、导航问题	派单系统查询、异常上报、重新派单	话术简洁直接，涉及调度系统权限
B 端商户	订单管理、结算问题、评价申诉	商户后台 API、结算系统、评价管理	涉及财务敏感操作，审批链更长

三个角色共享底层能力（RAG 知识库、订单系统接口），但Skill 集合和权限边界完全不同。架构上用一个 Router 做角色识别，分发到不同的 Agent 配置（不同的 System Prompt + 不同的工具白名单）。

差距在哪：新手一刀切用 RAG——这对订单类问题完全无效。高手按问题类型（非订单/订单/情绪）选不同方案，且解释了为什么订单类必须用 Skill 而非知识库。面试官考的是你在具体业务场景下的方案选型能力——不是「什么都能用 RAG」，而是「什么场景该用什么」。

---

Q：场景题——如果有一个监控日志，给 Agent 分析，需要得到分析结果，怎么设计这个 Agent？怎么设计工具？

来源：腾讯 AI 应用开发实习一面

新手答：「把日志喂给大模型，让它分析。」

高手答：

直接把原始日志塞进 Prompt 有两个致命问题：日志量远超上下文窗口，且非结构化文本充满噪声。正确做法是把 Agent 设计成「先结构化、再分层分析」的管线：

整体架构：

Agent 设计——三阶段推理：

阶段	目标	关键动作
定位	从海量日志中缩小范围	按时间窗口、错误级别、服务名过滤，得到关键日志片段
诊断	找到根因	对错误日志做聚类，识别高频错误模式；跨服务做链路追踪
输出	结构化分析报告	根因假设 + 影响范围 + 置信度 + 建议操作

Agent 不是一次性读完所有日志——而是迭代缩小范围：先用工具查「最近 30 分钟 ERROR 级别日志」，拿到初步线索后再用工具查「相关服务的上下游调用链」，逐步聚焦。

工具设计——四个核心工具：

1. log_query(time_range, level, service, keyword)
   → 按条件筛选日志，返回结构化结果（时间戳、服务名、错误码、消息）
   → 限制单次返回条数（如 50 条），防止上下文爆炸

2. error_cluster(logs)
   → 对错误日志做文本聚类（相似错误归为一类）
   → 返回：错误模式 + 出现次数 + 首次/末次出现时间 + 代表性日志

3. trace_lookup(trace_id | service + time_range)
   → 查询分布式链路追踪，返回完整调用链和各节点耗时
   → 标出超时/失败节点

4. metric_compare(service, metric, time_range, baseline)
   → 对比当前指标和基线（如 P99 延迟、错误率、QPS）
   → 返回偏离程度和趋势

工具设计的关键原则：

1. 工具返回结构化数据而非原始文本：log_query 不返回原始日志行，而是解析后的结构化 JSON（时间、级别、服务、错误码），模型更容易推理
2. 单次返回量有上限：每个工具限制返回条数，Agent 通过缩小条件迭代查询，而非一次拉取全部
3. 工具之间可组合：log_query 的结果中提取 trace_id，传给 trace_lookup 做链路追踪——Agent 自主决定组合顺序

差距在哪：新手把日志直接喂模型——这在数据量和噪声面前完全不可行。高手的设计有三个层次：Agent 层做三阶段推理（定位→诊断→输出），工具层做结构化查询和分析，两者通过迭代缩小范围配合工作。面试官考的是你面对大规模非结构化数据时的系统设计能力——不是「模型能看多少」，而是「怎么让模型只看关键信息」。