Agent 面试通关 / 01

架构选型：ReAct、Plan-and-Execute 与 ToT 怎么选

架构选型是 Agent 面试的第一类高频题。面试官不关心你能不能背出 ReAct 的定义——他关心的是：给你一个真实场景，你怎么选、为什么选、选完怎么落地。

推理范式与架构选型

Q：你用 ReAct 还是 Plan-and-Execute？为什么？

来源：腾讯 Agent 岗终面 【蚂蚁AI应用开发二面同题：ReAct 核心原理与复杂任务提升逻辑】【字节二面同题：ReAct vs Plan-and-Execute 理解与优劣对比】

新手答：“看情况，复杂用 ReAct，简单用 Plan。”

高手答：

先明确两者的核心机制。ReAct（Reasoning + Acting）是推理与行动交替的循环——模型先 Thought（思考当前该做什么）、再 Action（调用工具）、拿到 Observation（工具返回），根据新信息再 Thought，循环直到任务完成。它的特点是每一步决策都基于上一步的真实反馈，天然适应不确定性。Plan-and-Execute 则是规划与执行分离——Planner 先一次性生成完整步骤序列，Executor 按序执行，互不干扰。它的特点是全局最优、可预测、可审计，但对中间变化的适应性弱。

我们按任务不确定性来选。流程固定的内部工具（如日报生成）用 Plan-and-Execute，省成本。面对用户的开放任务（如旅行规划）必须用 ReAct，因为用户下一秒就可能改需求。

核心技巧是在 Plan 的每个步骤里嵌入“ReAct 式检查点”——比如调用天气 API 后，自动检查返回字段是否完整，不完整立刻触发修复，而不是让整个计划崩掉。

差距在哪：新手只说了“看情况”，但没有给出判断标准。高手的回答有三个层次：① 明确的选择维度（任务不确定性）；② 具体的业务对应（内部工具 vs 用户任务）；③ 混合方案的工程技巧（检查点机制）。面试官要的不是“我知道这两个东西”，而是“我在实际系统里怎么选、怎么用”。

追问：CoT 和 ReAct 的核心区别是什么？

来源：淘天 AI Agent 二面

很多人把 CoT 和 ReAct 混为一谈，认为“ReAct 就是带工具的 CoT”——这只对了一半。

关键区别：信息闭环 vs 信息开环

CoT 是闭环推理——所有信息在推理开始时就已经确定，模型只是把隐式推理显式化。ReAct 是开环推理——每一步行动的结果会改变后续推理的方向，信息在推理过程中动态增加。

CoT：已知信息 → 推理步骤1 → 推理步骤2 → 答案
ReAct：已知信息 → 推理 → 行动（搜索/查询）→ 新信息 → 推理 → 行动 → 答案

所以判断用哪个的标准很简单：回答这个问题需不需要模型目前不知道的信息？ 需要就用 ReAct，不需要就用 CoT。

追问：Plan-and-Execute 架构里，Planner 和 Executor 之间是如何通信的？

来源：字节后端 Agent 二面

Planner 和 Executor 之间的通信是 Plan-and-Execute 架构的核心设计点——通信格式决定了系统的灵活性和可调试性。

标准通信协议：

Planner 输出的不是自然语言描述，而是结构化的执行计划：

{
  "plan": [
    {"step": 1, "action": "search_flights", "params": {"from": "北京", "to": "上海", "date": "2026-05-10"}, "depends_on": []},
    {"step": 2, "action": "search_hotels", "params": {"city": "上海", "checkin": "2026-05-10"}, "depends_on": []},
    {"step": 3, "action": "generate_itinerary", "params": {}, "depends_on": [1, 2]}
  ]
}

Executor 按依赖关系执行每步，返回结构化结果：

{"step": 1, "status": "success", "result": {"flights": [...]}}

三种通信模式：

生产中最常用迭代式重规划——每步执行完 Planner 都重新评估，兼顾了计划性和灵活性。关键是 Executor 返回的结果要带上足够的上下文（成功/失败/部分成功 + 关键数据），让 Planner 有足够信息做判断。

Q：Tree of Thoughts (ToT) 在线上系统里能用吗？成本不高？

来源：腾讯 Agent 岗终面

新手答：“理论上可以，但成本高，一般不用。”

高手答：

重度 ToT 线上不能用，但轻量化版本是杀手锏。

我们用在“客服话术生成”上：当用户投诉时，让模型并行生成 3 条不同风格（共情、解释、补偿）的回复草稿，然后用一个非常轻量的评判模型（甚至是一组规则）快速选出一条最合适的，再继续细化。

这本质是束搜索（Beam Search），成本是单次生成的 3 倍，但换来的是回复质量质的提升，在关键场景 ROI 很高。

差距在哪：新手只回答了“能不能用”，结论是“不能”——这等于没回答。高手的思路是“原版不能直接用，但核心思想可以工程化降级”，并给了一个具体场景。面试官考的是“你能不能把论文里的方法落地”，这需要理解方法的本质（并行搜索 + 评估筛选）而不是只记住名字。

Agent 组成与设计边界

Q：Agent 的架构设计？从系统角度来拆分

来源：阿里 AI Agent 开发一面

新手答：“用大模型接工具就行。”

高手答：

一个完整的 Agent 不是单独一个大模型就能跑，核心拆成四层：

1. 任务入口层：负责接收用户问题和上下文
2. 决策层：意图识别、任务拆解、规划、工具选择
3. 执行层：真正去调工具、查知识库、访问服务
4. 记忆与状态层：维护多轮上下文、历史执行结果和中间变量

如果做得再工程化一点，通常还要加一个校验层——模型规划出来的步骤不一定对，工具参数也可能填错，所以在执行前后都要做检查：参数合法性校验、工具返回结构校验、结果一致性校验。

Agent 正确的地方不是“能不能想”，而是“想完能不能稳定执行”。

差距在哪：新手把 Agent 等同于“大模型 + Prompt”。高手的回答展示了分层架构的思维——入口、决策、执行、记忆各司其职，还有校验层做兜底。面试官想看你脑子里有没有系统设计的概念。

Q：Agent 在学术上由哪些部分组成？

来源：字节后端开发 Agent 一面

新手答：“大模型加上工具调用。”

高手答：

按学术界的主流框架（参考 Lilian Weng 的综述），Agent 由四个核心模块组成：

Agent = LLM（大脑）+ Planning（规划）+ Memory（记忆）+ Tool Use（工具使用）

1. LLM（大脑）：核心推理引擎，负责理解任务、生成决策。它不等于 Agent——它是 Agent 的一个组件
2. Planning（规划）：把复杂任务拆解成可执行的步骤序列。包括任务分解（Task Decomposition）、自我反思（Self-Reflection）、方案修正。典型方法：Chain of Thought、Tree of Thoughts、ReAct
3. Memory（记忆）：分短期记忆（当前上下文窗口内的信息）和长期记忆（持久化存储的历史信息、知识、用户偏好）。短期记忆就是 in-context learning，长期记忆通常靠外部存储 + 检索
4. Tool Use（工具使用）：调用外部 API、数据库、搜索引擎、代码执行器等。让 Agent 能做 LLM 本身做不到的事——精确计算、实时信息获取、执行操作

进阶补充：工业界还会加两个模块——Perception（感知） 处理多模态输入，Action（执行） 管理对外部环境的操作和副作用控制。

差距在哪：新手只看到了“大模型 + 工具”两个组件。高手的回答基于学术框架，把 Agent 拆成四个独立模块，每个模块有明确的职责和典型方法。面试官想确认你读过核心论文，对 Agent 有结构化的认知。

Q：了解过 Agent 的设计范式吗？

来源：字节后端开发 Agent 一面 【淘宝闪购一面同题：Agent 有哪些模式】

新手答：“ReAct，就是边想边做。”

高手答：

主流的 Agent 设计范式有四种，适用场景不同：

1. ReAct（Reason + Act）

循环：思考 → 行动 → 观察 → 思考 → 行动 → ...

每一步先推理下一步该做什么，执行后观察结果，再决定下一步。灵活，适合开放性任务，但 token 消耗大，且容易在循环中迷失方向。

2. Plan-and-Execute

先规划：任务 → 拆解成步骤列表
再执行：逐步执行，不回头修改计划

先出完整计划再执行，适合流程固定的任务（如日报生成、数据 ETL）。省 token，但不灵活——中间出了预期外的情况没有修正机制。

3. 反思范式（Reflexion / Self-Refine）

生成 → 评估 → 修正 → 再生成

生成结果后，用另一个 Prompt（或另一个模型）评估结果质量，发现不足后修正并重新生成。适合质量要求高的场景（代码生成、文案润色）。代价是多轮调用，延迟和成本翻倍。

4. 多 Agent 协作范式

多个角色 Agent，各负其责，通过消息协作

把复杂任务拆给不同角色的 Agent——程序员、审查员、产品经理等。适合需要多视角的复杂任务。工程复杂度最高，需要解决通信、冲突、一致性等问题。

实际工程中怎么选：

任务确定性高 + 流程固定  → Plan-and-Execute
任务开放 + 需要灵活应变   → ReAct
输出质量要求极高           → Reflexion
任务复杂 + 需要多视角      → 多 Agent 协作

大多数生产系统是混合范式——宏观用 Plan-and-Execute 做任务分解，微观用 ReAct 处理每个步骤，关键输出用 Reflexion 做质量检查。

差距在哪：新手只知道一种范式。高手列出了四种范式、各自的适用场景和代价，且指出生产系统通常是混合范式。面试官考的是你有没有对 Agent 设计范式的全局认知——不是只知道一种，而是知道多种，并且能说清楚什么场景用哪种。

Q：如果让你设计一个 Agent 的规划器，怎么避免它每一步都重新规划，导致路径震荡？

来源：腾讯大模型应用开发二面

新手答：“加个缓存，记住之前的计划就行。”

高手答：

规划器不能每拿到一个 observation 就整体重算，不然很容易出现前一步刚决定检索、后一步又改成总结、再下一步又回去检索——整个执行路径来回抖动。

更稳的做法是把规划分成“全局计划”和“局部调整”两层：

1. 全局计划只定义阶段目标，比如信息收集 → 证据检验 → 结果生成
2. 局部调整只允许在当前阶段内微调具体动作，不回头改全局计划

另外要给 planner 一个明确的状态表示——当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束，模型会把每次新 observation 当成全新任务来理解。

线上一般还会加“重规划阈值”，只有在关键前提失效、连续失败或者用户目标变化时才允许重新规划，日常微调不触发全局重规划。这样路径会稳定很多。

差距在哪：新手没有意识到路径震荡的根因——每次重规划等于丢弃之前的决策积累。高手用“全局 + 局部”两层分离解决了稳定性问题，且引入了状态表示和重规划阈值两个工程手段。面试官考的是你有没有把规划器当成一个需要工程约束的系统来设计。

Q：如果模型特别擅长生成，但不擅长严格遵守流程，你会怎么把它放进一个强约束工作流里？

来源：腾讯大模型应用开发二面

新手答：“在 Prompt 里强调让模型按步骤执行。”

高手答：

最常见的办法是把“生成自由度”和“流程控制权”拆开。模型只负责局部判断和内容生成，流程推进由外部状态机控制。

比如工作流规定必须先做参数校验 → 再检索知识 → 再调用工具 → 最后生成答复。模型不能跳步，能做的只是当前节点下的判断，例如“检索关键词应该怎么改写”“看了这些证据后怎么总结”。

状态机控制：参数校验 → 知识检索 → 工具调用 → 结果生成
模型负责：  每个节点内的局部判断和内容生成

这样一来，模型仍然发挥语言理解优势，但不会破坏整体流程。真正线上稳定的 Agent，很多都不是纯模型自治，而是“系统控流程，模型控局部智能”。

差距在哪：新手试图用 Prompt 约束模型行为——这是最弱的防线。高手的回答把流程控制权从模型手里拿走，交给外部状态机，模型只在受控的节点内发挥能力。面试官考的是你理不理解“生产级 Agent = 系统控流程 + 模型控智能”这个核心设计原则。

系统设计原则与模式

Q：设计一个 AI Agent 爬取短视频平台内容，如何设计？

来源：字节 Agent 实习一面

新手答：“写个爬虫脚本，调 API 下载视频。”

高手答：

这道题考的不是爬虫技术，而是如何用 Agent 架构解决一个复杂的端到端任务。系统设计分四层：

1. 任务规划层：

• Agent 接收用户需求（如“爬取某话题下的热门视频及评论”），先做任务分解：
  • 目标页面发现 → 内容抓取 → 数据解析 → 结构化存储
• 每个子任务可能需要不同工具，规划器负责编排执行顺序和依赖关系

2. 工具执行层：

3. 反爬对抗层（这是核心难点）：

• 请求频率控制：Agent 需要感知限流信号（429 状态码、验证码），自动降频或切换策略
• 身份伪装：UA 轮换、Cookie 池、代理 IP 池。Agent 根据被封情况动态调整
• 动态渲染：很多内容是 JS 动态加载的，需要无头浏览器渲染后再抓取
• 失败恢复：Agent 记录爬取进度，断点续爬，不因单次失败丢失已有成果

4. 数据质量层：

• 去重：相同视频不同入口可能重复，按 video_id 去重
• 校验：检查视频是否下载完整、元信息是否齐全
• 合规：过滤违规内容，遵守 robots.txt 和平台 ToS

关键设计决策：优先走 API 接口（速度快、结构化好），API 被封时降级到浏览器模拟（慢但稳）。Agent 的价值在于能根据反爬反馈自适应切换策略，而不是写死一套流程。

差距在哪：新手只想到写爬虫脚本。高手把问题转化成一个 Agent 系统设计——任务规划、工具编排、反爬对抗、数据质量四层架构。面试官考的是你能不能用 Agent 的思维方式（规划 + 工具 + 自适应）解决一个复杂的端到端工程问题。

Q：什么时候该做 Agent？和 Workflow 的边界在哪？

来源：Agent 开发面试 30 题

新手答：“需求复杂就用 Agent，简单就用 Workflow。”

高手答：

判断标准不是“复杂不复杂”，而是决策路径是否在设计时可穷举：

更精确的判断框架：

1. 决策维度是否开放：用户输入只需分成有限几类去处理 → Workflow。用户可能提出任何要求，且处理路径取决于中间结果 → Agent
2. 是否需要运行时工具选择：处理流程固定（先查数据库 → 再格式化 → 返回）→ Workflow。“查什么、用什么工具”要根据当前情况判断 → Agent
3. 是否需要自我修正：Workflow 出错只能按预设路径降级。Agent 能根据错误原因调整策略——这是核心区别

Agent 和 Workflow 的本质区别：Workflow 是“编排”——设计者画好流程图，系统按图执行。Agent 是“委托”——给一个目标，让系统自己决定怎么达成。Workflow 的确定性更高，Agent 的灵活性更高。

大部分真实需求的答案是：用 Workflow 做主干流程控制，在需要灵活判断的节点嵌入 Agent。纯 Agent 系统太不可控，纯 Workflow 系统太僵化。

差距在哪：新手用“复杂度”做判断，但复杂的 ETL 也可以是 Workflow。高手用“决策路径可否穷举”这个精确标准，且给出了三个具体判断维度和两者的本质区别。面试官考的是你选方案时有没有明确的决策框架。

Q：为什么很多团队做到最后是“Workflow + Agent 节点”的混合架构？

来源：Agent 开发面试 30 题

新手答：“因为纯 Agent 不够稳定。”

高手答：

不是 Agent“不够好”，是不同环节对确定性的要求不同。一个完整的业务流程里，80% 的步骤是确定性的（权限校验、数据查询、格式转换），只有 20% 需要智能判断（意图理解、方案推荐、自然语言生成）。

如果全用 Agent：

• 确定性步骤被模型处理 → 偶尔出错，不如规则可靠
• 成本翻倍 → 每个确定性步骤都消耗 token，毫无必要
• 可测试性差 → 模型输出概率性的，同样输入不一定同样输出

flowchart LR
    A["用户请求"] --> B["Workflow：\n鉴权/限流/参数校验"]
    B --> C["Agent 节点：\n意图理解+规划"]
    C --> D["Workflow：\n工具调用编排"]
    D --> E["Agent 节点：\n结果整合+回复生成"]
    E --> F["Workflow：\n日志/审计/返回"]

混合架构的原则是：确定性环节用 Workflow（可靠、可测、低成本），不确定性环节用 Agent（灵活、智能）。Agent 节点像状态机里的“智能节点”——系统控制它何时被调用、输入什么、输出约束是什么，但节点内部允许模型自由推理。

这也解释了为什么纯 Agent 创业项目容易死——不是技术不行，是把本该确定性处理的东西也交给了模型，导致系统整体可靠性无法保证。

差距在哪：新手只说了“不稳定”。高手分析了根因——不同环节对确定性的要求不同，且给出了 80/20 的量化认知和混合架构的设计原则。面试官考的是你有没有把 Agent 从 Demo 推到生产的实战认知。

Q：Agent 系统里，模型和系统代码的职责边界怎么划？

来源：Agent 开发面试 30 题

新手答：“模型负责思考，代码负责执行。”

高手答：

方向对但太粗。精确的边界划分：

模型负责的（需要语言理解/生成/推理的）：

• 意图识别：理解用户到底想做什么
• 参数抽取：从自然语言中提取结构化参数
• 方案选择：在多个可行路径中选最优的
• 内容生成：自然语言回复、代码、摘要

系统代码负责的（需要确定性保证的）：

• 流程控制：任务状态机、步骤编排、超时管理
• 参数校验：类型检查、范围约束、必填项检查
• 权限管控：工具访问控制、操作审批
• 状态持久化：中间结果存储、断点恢复
• 安全兜底：输出过滤、敏感信息脱敏、成本熔断

核心原则：永远不要让模型做它不擅长的事——精确计算、状态维护、流程控制、安全决策。

一个简单的验证标准：如果这个环节出错后果严重且不可接受 → 系统代码负责。如果这个环节出错可以通过重试/降级补救 → 可以交给模型。

差距在哪：新手的“思考 vs 执行”太笼统。高手把两者的职责列表拉出来对比，且给出了一个实用的验证标准（出错后果是否可接受）。面试官考的是你能不能精确划分系统设计中的职责边界。

Q：如果面试官说“Agent 本质上就是套壳调用工具”，你怎么反驳？

来源：Agent 开发面试 30 题

新手答：“不是套壳，Agent 更智能。”

高手答：

这句话的逻辑类似于说“操作系统就是套壳调硬件”——技术上没错，但忽略了中间层的价值。

“套壳调工具”只描述了 Agent 的最表层行为（接收输入 → 调工具 → 返回结果），但 Agent 的核心价值在于三个“套壳”做不到的能力：

1. 动态规划：不是“收到请求 → 调固定工具 → 返回”，而是“理解意图 → 拆解任务 → 根据中间结果动态选择下一步”。一个订机票的 Agent 可能需要先查航班 → 发现满了 → 改查临近日期 → 发现价格高 → 问用户是否接受 → 最终下单。这个决策链在设计时不可穷举
2. 自我修正：调工具失败后不是报错，而是分析失败原因、换一个工具或调整参数重试。这种“错了知道怎么补救”的能力是纯工具链做不到的
3. 上下文推理：能把多轮对话、用户画像、当前任务状态综合起来做决策，而不是每次请求都是无状态的

API Wrapper 是确定性的——同样输入永远同样输出。Agent 是概率性的但有推理能力——面对未见过的输入也能给出合理响应。这个区别就像“if-else 路由器”和“有经验的客服”的区别。

差距在哪：新手的反驳苍白无力。高手从动态规划、自我修正、上下文推理三个具体能力点说明 Agent 不是“套壳”，且用“操作系统 vs 硬件”类比让论证更有力。面试官用这种挑衅式问题考的是你对 Agent 的理解有多深。

Q：生产级 Agent 的执行循环包含哪些阶段？哪些必须显式状态化？

来源：Agent 开发面试 30 题

新手答：“就是思考 → 行动 → 观察的循环。”

高手答：

ReAct 的“思考 → 行动 → 观察”只是学术简化。生产级 Agent 的执行循环至少包含七个阶段：

flowchart TB
    A["1. 输入解析\n意图识别+参数抽取"] --> B["2. 上下文组装\n记忆召回+状态注入"]
    B --> C["3. 规划/决策\n选工具+定参数"]
    C --> D["4. 参数校验\n类型检查+业务规则"]
    D --> E["5. 工具执行\n调用+超时控制"]
    E --> F["6. 结果校验\n格式+语义+一致性"]
    F --> G["7. 状态更新\n进度+中间结果+日志"]
    G -->|未完成| B
    G -->|已完成| H["输出生成"]

哪些必须显式状态化（不能靠模型上下文承载）：

不需要状态化的：模型的中间推理过程、工具返回的原始 JSON（提取关键字段后可丢弃）。

核心认知：学术论文里的 Agent 循环是三步（think-act-observe），生产级的是七步，多出来的四步（输入解析、参数校验、结果校验、状态更新）全是工程防线。没有这四步，Agent 能跑 Demo 但上不了生产。

差距在哪：新手只知道 ReAct 三步循环。高手展示了生产级的七阶段循环，且明确了哪些状态必须显式持久化——这是“做过”和“听过”的本质区别。面试官考的是你对生产级 Agent 工程化的理解深度。

Q：什么样的任务适合先全局规划再执行，什么样的任务更适合边走边决策？

来源：Agent 开发面试 30 题

新手答：“简单任务边走边做，复杂任务先规划。”

高手答：

不是“简单 vs 复杂”，而是任务的信息完备度和可预测性：

适合先规划再执行（Plan-and-Execute）：

• 任务目标明确、步骤可预知：日报生成、数据 ETL、固定流程的表单填写
• 所有需要的信息在开始时就已具备
• 步骤之间有强依赖，必须按顺序执行
• 关键特征：开始时就能画出完整的流程图

适合边走边决策（ReAct）：

• 下一步取决于上一步的结果：故障诊断、信息调研、开放式对话
• 用户可能随时改变需求
• 中间步骤可能失败，需要动态调整路线
• 关键特征：开始时画不出完整流程图，因为分支取决于运行时的数据

混合策略（实际生产中最常见）：先做一次粗粒度规划（定义 3-5 个阶段目标），每个阶段内部用 ReAct 灵活执行。阶段目标变化时才触发重规划，不是每步都重规划。

粗规划：信息收集 → 方案对比 → 用户确认 → 执行操作
每个阶段内部：ReAct（边做边调整）
重规划触发：用户改需求 / 关键前提失效 / 连续失败

差距在哪：新手用“简单 vs 复杂”做判断——但“简单”的信息调研可能需要边走边做，“复杂”的 ETL 反而适合先规划。高手用“信息完备度”和“可预测性”两个维度做判断，且给出了混合策略。面试官考的是你在选执行策略时有没有清晰的判断标准。

Q：现在的 Agent 架构和之前有什么本质不同？渐进式披露是什么思路？

来源：蚂蚁集团 Agent 开发二面

新手答：“现在用更强的模型了。”

高手答：

Agent 架构正在经历从“一次性全量加载”到“渐进式按需披露”的范式转变。

之前的架构思路——全量预加载：

系统启动时就把所有工具、所有知识、所有规则一次性塞进上下文。Agent 拿到全部信息后做决策。

问题：① 上下文爆炸——100 个工具的 schema 占掉大半窗口；② 信息干扰——和当前任务无关的工具描述反而影响模型判断；③ 不可扩展——工具或知识增长后系统无法线性扩展。

现在的架构思路——渐进式披露（Progressive Disclosure）：

不预加载所有信息，而是根据任务进展逐步暴露相关能力。Agent 在每个阶段只看到当前阶段需要的工具、知识和规则：

flowchart TB
    A["用户请求"] --> B["第一层：意图识别\n（轻量模型 + 基础工具）"]
    B --> C["第二层：任务规划\n（加载该类任务的工具集 + 领域知识）"]
    C --> D["第三层：执行\n（按需加载具体工具 schema + 精确上下文）"]
    D --> E["第四层：验证\n（加载校验规则 + 评估标准）"]

关键设计原则：

1. 按需加载工具：不是一次性给模型 100 个工具，而是先给 5-8 个工具大类，选中大类后再展开具体工具
2. 上下文随阶段演化：规划阶段看全局信息，执行阶段只看当前步骤的精确上下文，验证阶段切换到评估视角
3. 能力逐级升级：简单请求用小模型 + 少量工具处理；判断需要更强能力时才升级到大模型 + 完整工具集

和传统分层架构的区别：传统分层是静态的——每层负责什么在设计时就定死了。渐进式披露是动态的——每层暴露什么取决于运行时的任务状态。同一个请求，在不同执行阶段看到的“系统”是不一样的。

这也是为什么上下文工程成为 2026 年 Agent 开发的核心挑战——不是“怎么把信息塞进去”，而是“怎么在正确的时机给出正确的信息”。

差距在哪：新手只看到了模型变化。高手理解了架构范式的本质转变——从全量预加载到渐进式按需披露。面试官考的是你对 Agent 架构演进方向的认知，以及你理不理解“上下文不是越多越好”这个核心洞察。

系统集成与规划保障

Q：Skill、MCP、Rule 三者有什么区别？

来源：蚂蚁集团一面

新手答：“都是给 Agent 加功能的方式吧。”

高手答：

三者解决的是 Agent 系统中不同层次的扩展问题，看起来都是“给 Agent 加东西”，但职责完全不同：

Rule（规则/约束）：

定义 Agent 的行为边界和决策偏好。不是“能力”，而是“约束”：

Rule 示例：
- 禁止执行 rm -rf 命令
- 回答必须使用中文
- 代码修改前必须先读取文件
- 敏感操作需要用户确认

Rule 通常写在配置文件中（如 CLAUDE.md），在每次对话中持续生效。它约束的是 Agent 的所有行为，不绑定特定任务。

Skill（技能模块）：

封装了完成某类特定任务的完整流程——包括步骤定义、输入输出格式、注意事项、甚至子工具的组合使用方式：

Skill 示例：
- "代码审查"技能：定义了审查流程、检查维度、输出格式
- "文章写作"技能：定义了写作风格、结构模板、质量标准
- "面试题分类"技能：定义了分类维度、插入格式、来源标注规范

Skill 是按需激活的——用户触发特定任务时才加载。它解决的是“同类任务每次都要从头教 Agent 怎么做”的问题。

MCP（Model Context Protocol）：

标准化的工具连接协议。解决的不是“怎么用工具”，而是“怎么发现和接入工具”：

MCP 示例：
- 数据库 MCP Server：暴露 query、insert、update 等工具
- GitHub MCP Server：暴露 create_pr、list_issues 等工具
- 搜索 MCP Server：暴露 web_search、image_search 等工具

MCP 的价值是标准化——任何工具只要实现 MCP 协议，任何 Agent 都能即插即用，不需要为每个工具写适配代码。

三者的协作关系：

flowchart TB
    R["Rule（约束层）\n定义行为边界"] --> S["Skill（能力层）\n定义任务流程"]
    S --> M["MCP（连接层）\n接入外部工具"]
    
    R -.->|"约束 Skill 的执行"| S
    R -.->|"约束工具调用权限"| M
    S -.->|"Skill 内部通过 MCP 调工具"| M

Rule 是最上层的约束，贯穿所有行为；Skill 在 Rule 的约束下定义任务流程；Skill 内部通过 MCP 调用具体工具。三者不是平行关系，而是约束 → 能力 → 连接的层次关系。

本地工具 vs MCP Tools vs Skill 的三层对比：

面试中经常把这三者放一起问，核心区别在于抽象层级不同：

关键洞察：本地工具是“能力”，MCP 是“能力的标准化接口”，Skill 是“怎么用能力的知识”。三者不是替代关系，而是互补的不同层级。一个完整的 Agent 系统通常同时需要这三层。

差距在哪：新手把三者混为一谈。高手从“约束 / 能力 / 连接”三个层次清晰区分了三者的职责，且说明了它们的层次关系和协作方式。面试官考的是你对 Agent 系统扩展机制的架构理解——不是“都能加功能”，而是“在不同层次解决不同问题”。

Q：微服务怎么接入一个 Agent 系统？

来源：蚂蚁集团一面

新手答：“Agent 调微服务的 API 就行。”

高手答：

“调 API”只是最表面的一层。微服务接入 Agent 系统要解决发现、适配、治理三个层面的问题：

1. 服务发现与注册（Agent 怎么知道有哪些微服务可用）

不能把所有微服务的 API 文档硬编码在 Agent 的 Prompt 里——微服务会增删改。需要一个动态的工具注册中心：

微服务 A 注册：
  name: "订单查询服务"
  capabilities: ["查询订单状态", "查询订单详情", "查询历史订单"]
  endpoint: "order-service.internal:8080"
  schema: OpenAPI 3.0 spec
  auth: Bearer Token
  rate_limit: 100 RPM

Agent 在需要时从注册中心按能力描述检索合适的服务，而不是预加载所有服务。这就是 MCP 协议在解决的问题——用标准化的方式让 Agent 发现和调用工具。

2. 协议适配（微服务的接口怎么变成 Agent 能理解的工具）

微服务的 REST/gRPC 接口和 Agent 的工具调用接口之间需要适配层：

关键：适配层不只是格式转换，还需要把技术概念翻译成模型能理解的语义描述。比如微服务返回 {"code": 40301, "msg": "insufficient_balance"}，适配层要翻译成“用户余额不足，无法完成支付”。

3. 治理（接入后怎么保证稳定可控）

flowchart LR
    A["Agent"] --> GW["API 网关"]
    GW --> |"鉴权"| AUTH["认证服务"]
    GW --> |"限流"| RL["限流器"]
    GW --> |"路由"| SVC["微服务集群"]
    GW --> |"日志"| LOG["审计日志"]

• 鉴权：Agent 调微服务不能用同一个“超级 Token”，应该按任务类型分发不同权限的临时凭证
• 限流：Agent 可能短时间内高频调用某个服务（比如循环查询），需要在网关层做 Agent 维度的限流
• 熔断：某个微服务不可用时，Agent 不能死等，需要快速感知并切换策略
• 可观测：每次调用的入参、出参、延迟、状态码都要记录，方便排查 Agent 行为异常时的根因

差距在哪：新手只想到“调 API”。高手从服务发现、协议适配、运行治理三层说清了微服务接入 Agent 的完整方案，且指出了“语义翻译”和“Agent 维度限流”这两个 Agent 系统特有的难点。面试官考的是你能不能把传统微服务架构的经验迁移到 Agent 系统中。

Q：如何保证规划 Agent plan 的结果正确？

来源：AI 工程师面试

新手答：“让模型多想想，加个 CoT 就行。”

高手答：

Plan 的正确性不能只靠模型“想得好”，要从事前约束、事中校验、事后修正三个阶段建立保障机制：

事前——约束 Plan 的输出质量：

1. Structured Output：强制模型以 JSON 格式输出 plan，每个步骤必须包含 step_id、action、tool、expected_output、dependencies。格式约束本身就能过滤掉“一句话笼统计划”
2. Few-shot 示范：在 Prompt 中给出 2-3 个高质量的 plan 示例，让模型学到正确的粒度和结构
3. 领域知识注入：把当前任务相关的工具列表、能力边界、业务规则注入上下文，避免模型规划出“做不到的步骤”

事中——引入 Critic 校验：

1. Critic Agent：用另一个模型（或同一个模型不同 Prompt）审查 plan，检查逻辑一致性、步骤可执行性、是否有遗漏
2. 规则校验器：用代码检查 plan 的结构合法性——步骤依赖是否成环、引用的工具是否存在、参数是否完整

flowchart LR
    A["Planner 生成 Plan"] --> B["结构校验\n（规则引擎）"]
    B --> C["Critic Agent\n（逻辑审查）"]
    C -->|"通过"| D["进入执行"]
    C -->|"不通过"| E["反馈修改意见"]
    E --> A

事后——执行中反馈修正：

1. Self-Reflection：每个步骤执行完后，检查实际结果和 plan 预期是否一致，不一致时触发局部修正
2. Re-plan 机制：当关键前提失效（如某个工具不可用、用户改了需求）时，允许重新规划，但保留已完成步骤的成果
3. Plan 版本管理：每次修改 plan 都保存历史版本，方便回溯和复盘

核心认知：Plan 的正确性不是一次生成就能保证的，而是通过“生成 → 审查 → 执行 → 反馈 → 修正”的闭环逐步收敛的。只靠 Prompt 调优永远不够，必须有外部校验机制。

差距在哪：新手只想到让模型“想清楚”——这是最弱的保障。高手从事前（格式约束 + Few-shot + 知识注入）、事中（Critic + 规则校验）、事后（反馈修正 + Re-plan）三个阶段构建了完整的 Plan 质量保障体系。面试官考的是你对规划可靠性的工程化认知。

Q：规划完成后需要人工介入修改大纲，SSE 怎么实现这种 Human-in-the-Loop？前端怎么让用户输入？

来源：AI 工程师面试

新手答：“弹个输入框让用户改就行。”

高手答：

这道题考的是Human-in-the-Loop（HITL）的工程实现——Agent 执行到某个节点时暂停，等待人类输入后再继续。核心挑战是：后端是异步流式的（SSE），前端需要在正确的时机切换到“等待用户输入”状态。

后端实现（以 LangGraph 为例）：

LangGraph 原生支持 interrupt_before 机制——在指定节点执行前暂停 graph，等待外部输入：

graph = create_graph()
# 在 search_node 之前中断，等待人工确认/修改大纲
app = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=[“search_node”]
)

执行流程：

flowchart TB
    A["Plan Agent 生成大纲"] --> B["触发 interrupt_before"]
    B --> C["SSE 推送暂停事件\ntype: interrupt, data: outline"]
    C --> D["前端展示大纲\n+ 编辑器"]
    D --> E["用户修改大纲\n提交"]
    E --> F["POST /resume\n携带修改后的大纲"]
    F --> G["graph.update_state()\n注入用户修改"]
    G --> H["graph.stream(None, config)\n从断点继续执行"]

关键 API 调用：

# 1. 用户修改后，更新 graph 状态
graph.update_state(
    config,
    {“outline”: user_modified_outline},
    as_node=”plan_node”  # 以 plan_node 的身份写入状态
)

# 2. 传入 None 表示从上次中断处继续
for event in graph.stream(None, config):
    send_sse_event(event)

SSE 通信协议设计：

后端通过 SSE 推送不同类型的事件，前端根据事件类型切换 UI 状态：

event: node_output      # 普通节点输出，前端展示流式内容
data: {“node”: “plan”, “content”: “...”}

event: interrupt         # 中断事件，前端切换到编辑模式
data: {“node”: “plan”, “outline”: [...], “editable”: true}

event: resumed           # 恢复执行，前端切回流式展示模式
data: {“node”: “search”}

前端交互设计：

1. 监听 SSE 事件流：收到 interrupt 事件时，停止流式展示，渲染大纲编辑器
2. 用户编辑并提交：提交时调用 POST /resume 接口，携带修改后的大纲和当前 thread_id
3. 恢复流式展示：收到 resumed 事件后，前端切回流式输出模式，继续展示后续节点的输出

核心认知：HITL 不是简单的“弹窗确认”，而是后端状态暂停 + 前端模式切换 + 状态注入恢复的完整链路。LangGraph 的 interrupt_before + update_state + stream(None) 三板斧是标准实现。

差距在哪：新手只想到前端交互。高手从后端中断机制（interrupt_before）、SSE 事件协议设计、前端状态切换、恢复执行（update_state + stream(None)）四个环节说清了完整的 HITL 实现方案。面试官考的是你对 Agent 系统中“人机协作”的全链路工程化理解。

Q：Agent 的任务规划是怎么做的？规划由模型完成还是规则实现？

来源：快手 AI Agent 开发一面

新手答：“让模型自己决定每一步做什么。”

高手答：

生产级 Agent 的规划几乎都是模型 + 规则的混合架构，纯模型或纯规则都有致命缺陷：

混合架构的典型做法：

规则层：定义任务的主干流程（必经节点、禁止操作、超时限制）
模型层：在规则允许的范围内，负责子任务拆解和具体决策
验证层：每步规划结果经过规则校验后才执行

flowchart TB
    U["用户需求"] --> M["模型生成\n初始规划"]
    M --> V{"规则校验\n合法性检查"}
    V -->|"通过"| E["执行当前步骤"]
    V -->|"不通过"| R["反馈约束条件\n要求模型重新规划"]
    R --> M
    E --> C{"任务完成？"}
    C -->|"否"| M
    C -->|"是"| D["返回结果"]

多工具调用时如何决定调用顺序：

1. 显式依赖：工具 B 的输入依赖工具 A 的输出 → A 必须先执行，由 DAG（有向无环图）描述依赖关系
2. 无依赖并行：工具之间无数据依赖 → 并行执行，总延迟取最慢的那个
3. 模型推理：依赖关系不明确时，让模型根据任务上下文判断调用顺序，但要加防护——限制最大步数、禁止循环调用

工程实践：先用规则解析工具间的硬依赖（参数传递关系），
再用模型判断软依赖（逻辑上应该先查天气再推荐穿搭），
无依赖的全部并行

工具调用失败的处理：

差距在哪：新手把规划全交给模型——这在生产中不可控。高手用“模型规划 + 规则校验”的混合架构，在灵活性和安全性之间找到了平衡。多工具调用有 DAG 依赖分析 + 并行优化，失败有分类处理策略。面试官考的是你能不能设计一个既灵活又可控的规划系统。

场景设计与可靠性

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

来源：淘天 AI Agent 一面

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

高手答：

先定义两个核心问题：

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

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

第一层：实时检测

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

第二层：主动干预

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

第三层：结构预防

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

flowchart TB
    T["模型生成\n推理 + 工具调用"] --> V{"预执行校验"}
    V -->|"参数合法\n工具存在"| E["执行工具"]
    V -->|"参数非法"| F1["结构化错误\n反馈给模型"]
    V -->|"工具不存在"| F2["注入可用工具列表\n要求重选"]
    F1 --> T
    F2 --> T
    E --> O{"结果检查"}
    O -->|"有效结果"| P["更新状态\n继续下一步"]
    O -->|"无效/重复"| D{"重复检测"}
    D -->|"未超限"| R["注入反思提示\n要求换策略"]
    D -->|"超限"| S["强制策略切换\n或降级退出"]
    R --> T
    S --> T

预防机制的关键设计：

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

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

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

来源：淘天 AI Agent 一面

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

高手答：

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

四大模块的职责划分：

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

flowchart TB
    U["用户输入\n'帮我挑一款适合跑步的运动鞋\n预算500以内'"] --> P["感知模块"]
    
    P -->|"意图：商品推荐\n品类：运动鞋\n场景：跑步\n预算：≤500"| MQ1["消息队列"]
    
    MQ1 --> PL["规划模块"]
    
    PL -->|"读取用户画像"| M["记忆模块"]
    M -->|"历史偏好：Nike/Asics\n脚型：宽脚\n上次购买：3个月前"| PL
    
    PL -->|"任务计划：\n1.搜索跑步鞋\n2.按画像过滤\n3.比价排序\n4.生成推荐理由"| MQ2["消息队列"]
    
    MQ2 --> EX["执行模块"]
    EX -->|"搜索API"| S1["商品搜索服务"]
    EX -->|"库存API"| S2["库存服务"]
    EX -->|"价格API"| S3["比价服务"]
    
    S1 --> EX
    S2 --> EX
    S3 --> EX
    
    EX -->|"执行结果"| PL
    PL -->|"生成推荐话术"| R["返回用户\n推荐3款鞋+理由"]
    
    EX -->|"更新交互记录"| M

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

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

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

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

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

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

3. 分布式状态管理

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

电商场景的特殊挑战：

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

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

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

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

高手答：

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

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

四个关键维度的差异：

用公式表达：

Agent = LLM + Tools + Memory + Planning Loop

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

flowchart LR
    subgraph model["模型（Model）"]
        direction LR
        I1["输入"] --> M["大脑\n（推理引擎）"] --> O1["输出"]
    end

    subgraph agent["Agent"]
        direction TB
        G["目标"] --> P["规划\n（Planning）"]
        P --> A["行动\n（Tools）"]
        A --> OB["观察\n（环境反馈）"]
        OB --> MEM["记忆\n（Memory）"]
        MEM --> P
    end

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

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

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

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

来源：bilibili AI研发实习一面

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

高手答：

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

典型的科研 Agent 流程：

flowchart TB
    U["用户输入研究问题"] --> A["阶段一：问题理解与分解"]
    A --> B["阶段二：文献检索与筛选"]
    B --> C["阶段三：知识提取与综合"]
    C --> D["阶段四：假设生成"]
    D --> E["阶段五：实验设计/验证"]
    E --> F["阶段六：报告生成"]
    
    C -->|"发现知识缺口"| B
    E -->|"验证失败"| D

各阶段的设计要点：

阶段一：问题理解与分解

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

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

阶段二：文献检索与筛选

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

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

阶段三：知识提取与综合

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

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

阶段四：假设生成

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

阶段五：实验设计/验证

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

阶段六：报告生成

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

工程实现的关键挑战：

和 Deep Research 产品的关系：

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

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

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）、检查点恢复。

选型建议：

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

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

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

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

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

高手答：

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应用开发 二面

新手答：「优化 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 端用户问优惠券和问订单赔偿，需要的处理方式完全不同。不能一刀切。

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

flowchart TB
    Q["用户问题"] --> CLS{"问题分类"}
    CLS -->|"非订单类\n（优惠券、地址、规则）"| RAG["知识库 RAG"]
    CLS -->|"订单类\n（退款、赔偿、派单异常）"| SKILL["Skill / 工作流"]
    CLS -->|"情绪类\n（投诉、安抚）"| HYBRID["话术库 + 工具联动"]

    RAG --> R1["FAQ 检索 → 生成回答"]
    SKILL --> S1["读订单状态 → 执行规则 → 操作"]
    HYBRID --> H1["情绪识别 → 话术选择 → 触发工单"]

为什么订单类不能用 RAG：

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

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

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

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

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

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

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

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

高手答：

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

整体架构：

flowchart TD
    L["监控日志源\nK8s/ELK/文件"] --> P["预处理工具\n过滤+结构化"]
    P --> A["分析 Agent"]
    A --> T1["日志查询工具\n按时间/级别/服务筛选"]
    A --> T2["模式识别工具\n错误聚类+频率统计"]
    A --> T3["关联查询工具\n跨服务链路追踪"]
    A --> T4["指标对比工具\n和基线比较异常指标"]
    A --> R["分析报告\n根因+影响范围+建议"]

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 层做三阶段推理（定位→诊断→输出），工具层做结构化查询和分析，两者通过迭代缩小范围配合工作。面试官考的是你面对大规模非结构化数据时的系统设计能力——不是「模型能看多少」，而是「怎么让模型只看关键信息」。

Q：Skill 和 Workflow 的区别是什么？什么场景该用 Skill 而不是 Workflow？

来源：快手AI应用开发一面

新手答：“Skill 就是一个功能模块，Workflow 是流程编排，两个差不多吧。”

高手答：

Workflow 是面向业务流程的编排，适合步骤稳定、分支明确、有审批和状态流转的任务，比如“提交理赔申请 → 校验材料 → 人工审核 → 打款”。它强调的是顺序、状态、重试和完整性。

Skill 是面向能力复用的封装，适合被不同 Agent、不同流程按需调用。它有明确的输入输出契约，强调可组合、可编排。

graph TB
    subgraph Workflow["Workflow（面向流程）"]
        W1[提交申请] --> W2[校验材料]
        W2 --> W3[人工审核]
        W3 --> W4[打款]
    end
    subgraph Skill["Skill（面向能力）"]
        S1[药品目录匹配]
        S2[解析发票]
        S3[生成拒赔解释]
    end
    W2 -.->|调用| S1
    W2 -.->|调用| S2
    W3 -.->|调用| S3

关键判断标准：

以理赔场景为例：门诊理赔、住院理赔、药品理赔三条 Workflow 都需要“药品目录匹配”能力。如果做成 Workflow 节点，三条流程各复制一份，改一处要改三处。做成 Skill 后只维护一份，任何流程按需调用。

Skill 的定义更像一个稳定接口：

{
  "skillName": "medical_catalog_match",
  "input": {
    "drugName": "string",
    "diagnosisCode": "string"
  },
  "output": {
    "covered": "boolean",
    "matchedRuleId": "string",
    "reason": "string"
  }
}

差距在哪：新手分不清 Skill 和 Workflow，混为一谈或者觉得 Skill 只是小功能。高手能清晰说出两者的设计目标不同——Workflow 关注流程完整性和状态流转，Skill 关注能力复用和可组合性。面试官考的是你对系统解耦和能力沉淀的理解：什么时候该固化流程，什么时候该抽取通用能力。

Q：DAG 与含循环图在 Agent 编排中的区别和适用场景

来源：猎豹移动Agent全栈开发

新手答：“DAG 就是不能有环的图，有环就是循环图。”

高手答：

这涉及 Agent 编排的底层拓扑选择：

DAG（有向无环图）：

• 特点：每个节点只执行一次，执行路径确定，可以拓扑排序
• 适合场景：确定性工作流（数据 ETL、文档处理管线、审批流程）
• 优势：可预测执行时间和成本、容易做并行优化、调试简单
• LangGraph 中：用条件边但无回边，本质是分支-汇聚结构

含循环图（如循环 RAG、ReAct Loop）：

• 特点：允许回边，节点可能多次执行，需要终止条件
• 适合场景：需要迭代精化的任务（多轮检索、自我修正、Plan-Execute-Reflect）
• 优势：能处理不确定性任务，支持 self-reflection 和渐进式解决
• 风险：死循环、成本不可控，需要 max_iterations + 循环检测

混合架构：实际生产中常见——外层 DAG 控制大流程（如：理解→规划→执行→验证），内层节点允许循环（如执行节点内的 ReAct loop）。

差距在哪：面试官要看你是否理解“确定性和灵活性的 trade-off”——DAG 省钱可控但傻，循环图聪明但贵且危险，工程上常常混合使用。

Q：基于强化学习的 Agent 与传统基于 Prompt 的 Agent 有何区别？各自的适用场景？

来源：Agent开发八股合集（南京大学）

新手答：“RL Agent 就是用强化学习训练模型，Prompt Agent 就是写提示词让模型做事，RL 更高级。”

高手答：

这两种范式解决的核心问题不同：Prompt-based Agent 依赖模型的 in-context learning 能力做决策，RL-based Agent 通过环境反馈直接优化策略网络。

适用场景对比：

• Prompt-based：任务多样、需要通用推理、环境复杂且难以模拟（如代码编写、开放对话、信息检索）。大多数企业级 Agent 产品用这种。
• RL-based：环境可模拟、奖励信号明确、动作空间有限（如游戏 AI、机器人控制、特定优化任务）。WebArena 类 benchmark 中 RL fine-tuned Agent 效果好。

现实中的融合趋势（RLHF/GRPO）：

当前 LLM Agent 实际上已经融合了两者——基座模型用 RL（RLHF/GRPO）对齐人类偏好后，部署时以 Prompt-based 方式运行。更前沿的方向如 Agentic RL（Agent 在环境中探索生成轨迹，再用 RL 优化推理策略）正在模糊这条界限。

差距在哪：面试官考的是你对“Agent 决策机制”的深度理解。新手把 RL 和 Prompt 当成对立面，高手能指出两者解决不同层面的问题，并能说出当前“基座用 RL 训练 + 推理用 Prompt 驱动”的融合范式，体现你对技术全栈的理解。

Agent 中间件（Middleware）

Q：讲一讲 Agent 的 Middleware（中间件）是什么？

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

新手答：“就是后端框架里的中间件吧，处理请求的。”

高手答：

Agent Middleware 和 Web 框架的中间件思想相同——在核心执行流的前后插入可组合的横切逻辑——但作用对象从 HTTP 请求变成了 Agent 的每一步决策。

Agent Middleware 的典型处理位置：

flowchart LR
    A[用户输入] --> M1[鉴权/限流]
    M1 --> M2[输入安全检查]
    M2 --> M3[上下文注入/裁剪]
    M3 --> C[LLM 推理]
    C --> M4[输出格式校验]
    M4 --> M5[敏感信息过滤]
    M5 --> M6[日志/Trace记录]
    M6 --> B[返回用户]

常见 Middleware 类型：

为什么用中间件模式而不是硬编码：

1. 可组合：不同场景按需组装不同中间件栈，不用改核心逻辑
2. 可复用：安全检查、日志记录等横切关注点写一次到处用
3. 可测试：每个中间件可以独立单测
4. 关注点分离：核心推理逻辑不被安全、日志、格式化等代码污染

差距在哪：面试官用这题测试你对“Agent 不只是一个 LLM 调用”的理解。只会调 API 的人不知道生产级 Agent 需要多少横切逻辑。能说出 Middleware 栈的分层设计 + 每层的职责，说明你理解从 Demo 到生产之间的工程距离。

这类题的答题模式

架构选型题的高分回答有一个固定结构：

1. 给出明确的选择维度（不说"看情况"）
2. 用具体的业务场景说明怎么选
3. 说出混合方案或工程化降级的技巧
4. 点一句代价和适用边界

面试官听到“看情况”就知道你没做过。听到具体的判断维度和混合方案，才会继续追问——而追问意味着你已经通过了这道题。

下一篇建议继续看：

• 工具管理：参数校验、工具路由与百级工具库