AI Agent 面试题深度解析（一）：Agent 基础篇

核心答案#

AI Agent 是以大语言模型为推理核心、能够围绕一个目标自主规划、调用工具、观察结果并迭代执行的一类系统。它和普通 Chatbot 的根本区别不在于”能不能对话”，而在于”能不能主动完成多步骤任务”。

普通 Chatbot 的工作模式是「输入 → 单次生成 → 输出」。它主要处理单轮或多轮问答，本质是”问题—回答”的映射。即使接入了检索增强生成（RAG），它的输出也通常是一次性的、由用户追问才会触发下一轮。Chatbot 没有持续的目标感，也不会主动去调用外部系统完成任务。

AI Agent 的工作模式是「目标 → 规划 → 行动 → 观察 → 修正 → 继续」。它接收的是目标，而不是问题；在执行过程中，它会自己拆解任务、决定调用哪些工具、阅读工具返回结果、判断是否完成，并在失败时调整策略。这种”在循环里推进任务”的形态，是 Agent 区别于 Chatbot 的最关键特征。

要更具体地区分，可以从四个维度对比：

第一，目标感。Chatbot 是”被问才答”，Agent 是”领了活就干”。同一个用户输入，比如”帮我把上周的销售数据做个汇报”，Chatbot 会问”你想要哪种格式”，Agent 会自己决定要看哪些数据、用什么图表、写到哪个文档。

第二，执行深度。Chatbot 偏向单步生成，Agent 偏向多步组合。一次 Agent 任务往往要调用搜索、数据库、文件写入、可视化等多个工具，每个工具的输出又是下一步的输入。

第三，可控性与可观测性。Chatbot 的失败模式主要是”答得不对”，Agent 的失败模式还包括”调错工具、死循环、漏步骤”。所以生产级 Agent 系统必须配套轨迹记录、阶段性检查、回滚机制。

第四，能力边界。Chatbot 适合问答、解释、翻译、陪伴类任务；Agent 适合需要跨越多个系统、需要执行、需要验证的复杂任务。

关键要点#

• Agent 的核心是”目标驱动的多步执行”，不是”会思考的数字员工”。
• 区分 Chatbot 和 Agent 的关键不是”用没用 LLM”，而是”有没有 Loop、有没有 Tools、有没有目标完成判断”。
• 生产中，Agent 的难度往往不在模型能力，而在”约束、轨迹、稳定性”。

容易踩的坑#

• 把 Agent 讲成”会自动思考的机器人”，强调神秘智能，回避工程问题。
• 用”自主意识""AGI”等大词描述 Agent，反而显得不专业。
• 忽略 Agent 的失败模式，回答里只讲能力，不讲风险。

示范话术#

AI Agent 我理解是以大模型为推理核心、围绕一个目标自主规划并调用工具执行的一类系统。和普通 Chatbot 最大的区别是：Chatbot 是”被问才答”，本质是问题到回答的映射；Agent 是”领了活就干”，它会自己拆解任务、调用工具、看结果、判断是否完成，必要时调整下一步。所以判断一个系统是不是 Agent，我会看三件事：有没有明确的目标，有没有可调用的工具，有没有一个 Loop 在里面迭代推进。落到生产里，Agent 最大的难点其实不是”能不能做”，而是”做不稳”——轨迹不可控、Token 成本高、失败难排查，所以我们做项目时更多会用 Workflow 把关键路径兜住，只在必要节点让模型判断。

核心答案#

「Agent = LLM + Planning + Memory + Tools」是描述 Agent 组成最常见的公式，但它只是入门级抽象，不能直接当成生产架构。

公式里的 LLM 是推理引擎，负责理解目标、生成计划、选择工具、解释结果。Planning 是规划与决策，负责把目标拆成步骤，并在执行中根据新信息动态调整。Memory 是记忆系统，包括当前任务状态、历史对话、用户偏好和长期经验。Tools 是 Agent 与外部世界交互的接口，包括 API、数据库、文件、浏览器、代码执行环境等。

但这条公式在生产中是不够的。一个真实可用的 Agent 系统，通常还要加上：上下文管理（Context Engineering）、状态持久化（State）、验证与重试（Validation & Retry）、安全边界（Permission & Sandbox）、评测与监控（Eval & Observability）。这意味着，完整公式更接近「Agent = LLM + Harness」，其中 Harness 把上述所有非模型部分组织起来。

理解这条公式时，还有两个常见的认知偏差需要避免。

第一，它不是”模块拼装”。很多人以为只要把 LLM、记忆、工具接起来就是 Agent，结果做出来的是”调包侠脚本”。实际上，这四者必须围绕一个运行循环（Loop）协同，并且要明确每一步谁触发、谁消费、谁校验。

第二，它不是”四个独立组件”。Memory 里的内容最终会进入 LLM 的上下文窗口；Planning 产生的计划也会被记录到 Memory；Tools 返回的结果要写回 State 并影响下一步 Planning。所以这四个部分本质上是”围绕 LLM 上下文窗口”展开的协同系统。

关键要点#

• 公式是起点，不是终点。生产级 Agent 至少还要补上 Context、Harness、Eval。
• LLM 是推理核心，其他三块都在为它供给”完成任务所需要的信息”和”完成任务所需要的接口”。
• 真正决定 Agent 表现的不是单点能力，而是这四块的协同效率。

容易踩的坑#

• 把公式当成架构图去讲，显得空泛。
• 没有说明 LLM 之外其他三块的作用机制。
• 没意识到这四块是相互依赖的，比如 Memory 实际上是给 LLM 喂上下文。

示范话术#

「Agent = LLM + Planning + Memory + Tools」是我面试里最常被问到的公式，我的理解是：LLM 负责推理，Planning 负责把目标拆成步骤，Memory 负责保留任务状态和长期经验，Tools 负责让 Agent 真的能影响外部世界。但这只是入门级抽象。生产中我会把它扩展成「Agent = Model + Harness」，加上上下文管理、状态持久化、验证重试、安全沙箱和评测观测这些层。另外这四块不是孤立拼装，它们是围绕 LLM 上下文窗口协同的——Memory 写入的内容最终要喂给 LLM，Planning 产出的计划要写到 State，Tools 的结果又要回到上下文影响下一步决策。所以讲这条公式，我会强调”协同”而不是”组合”。

核心答案#

Agent Loop 是 Agent 系统的”心跳”。它的完整流程可以拆成七个阶段：接收目标 → 上下文组装 → 推理规划 → 工具调用 → 观察结果 → 反思修正 → 继续或终止。

第一步是接收目标。系统拿到用户的原始诉求，进入”待执行”状态。此时可能还要做目标澄清，比如让 LLM 主动反问几个关键参数，或者从历史记忆里恢复上下文。

第二步是上下文组装。系统把系统提示、长期记忆、当前任务状态、可用工具描述、相关历史轨迹、检索证据等材料按优先级拼装，喂给 LLM。这一步的质量直接决定 Agent 表现。

第三步是推理规划。LLM 在上下文的引导下，输出下一步动作。这一步可能是”直接给答案”，也可能是”调用某个工具”，也可能是”先更新内部计划”。Plan-and-Execute 模式还会显式输出多步计划。

第四步是工具调用。系统解析 LLM 输出，识别工具名和参数，做参数校验、权限校验，执行真实工具，并捕获返回结果。生产里这一步必须配超时、重试、限流、降级。

第五步是观察结果。工具结果被结构化解析后，写回 State 和上下文。同时要做格式校验和异常处理：成功则继续，失败则进入重试或回退路径。

第六步是反思修正。LLM 在新上下文里重新评估”是否完成目标、是否需要换路径、是否需要重做某步”。Reflection 模式会显式输出自我评价；ReAct 模式把这个反思隐式包含在下一步推理里。

第七步是继续或终止。如果任务完成，整理最终结果输出；如果没完成，跳回第三步继续循环；如果超过最大步数、Token 预算或检测到死循环，则强制终止并报错。

理解这个 Loop 时，要特别注意三个工程化细节。第一，状态写在哪里。理想做法是有显式的 State 对象，Loop 的每一步都基于 State 做更新，而不是依赖 LLM “自己记着”。第二，循环如何退出。必须同时设置”成功条件""失败条件""最大步数""最大 Token”四道闸门，否则 Agent 容易跑飞。第三，错误如何恢复。每一步都要有清晰的错误分类——是可重试错误（网络超时）、可降级错误（工具不可用）还是不可恢复错误（参数非法）。

关键要点#

• Loop 是 Agent 的最小执行单元，面试里讲不清楚 Loop，基本等于没懂 Agent。
• Loop 的每一步都要考虑”输入是什么、输出写哪里、失败怎么恢复”。
• 显式 State、显式退出条件、显式错误处理，是 Loop 工程化的三件套。

容易踩的坑#

• 只讲”推理—行动—观察”三步，漏掉上下文组装、反思、终止。
• 把 Loop 讲成线性流程，忽略它是会反复回到推理阶段的循环结构。
• 不提退出条件和错误恢复，让面试官觉得你对生产问题没概念。

示范话术#

Agent Loop 我会拆成七步：接收目标、上下文组装、推理规划、工具调用、观察结果、反思修正、继续或终止。上下文组装这一步很多人会忽略，但它直接决定模型看到什么世界；工具调用要配超时、重试、降级；观察结果要写回 State，不能只靠模型”自己记着”；反思修正是 Reflection 模式的关键；最后必须设四道闸门——成功条件、失败条件、最大步数、最大 Token，缺一个 Agent 就容易跑飞或者烧钱。讲 Loop 的时候我特别想强调一点：它是”循环”不是”流程”，所以必须明确”什么时候回到第几步”，否则就成了线性脚本。

核心答案#

要讲清 Agent 和传统编程、Workflow 的区别，最直观的方式是从”控制流由谁决定”这个维度切入。

传统编程的控制流完全由程序员写死的逻辑决定。代码怎么走、参数怎么传、异常怎么处理，都来自确定性指令。优点是稳定、可预测、可测试，缺点是只能处理程序员预设好的情况。AI 出现后，传统编程仍然是系统骨干，Agent 更多是在它之上做”智能层”。

Workflow的控制流是程序员提前编排好的路径。它由若干 Node 和 Edge 组成，Node 负责执行，Edge 负责流转，State 负责跨节点共享数据。Workflow 可以引入 LLM 作为某个 Node 的处理能力，但整条路径是确定的。优点是可控、可观测、可调试，缺点是路径不能灵活应变。

纯 Agent的控制流由 LLM 在每一轮推理中动态决定。Agent 拿到目标后自己规划步骤、自己选择工具、自己判断是否完成。优点是灵活、能处理开放任务，缺点是轨迹不稳定、成本高、调试难。

这三者的关系可以总结成一句话：传统编程是”完全确定”，Workflow 是”路径确定 + 节点智能”，纯 Agent 是”目标确定 + 路径由模型决定”。

从工程角度，还要理解三点差异：

第一，可观测性不同。传统编程可以用日志、断点、单测覆盖全部路径；Workflow 可以用可视化看到每一步走到哪里；纯 Agent 的轨迹要靠 Trace 工具记录，并且很多失败要在事后回放才能定位。

第二，失败模式不同。传统编程失败是 Exception；Workflow 失败通常是某个 Node 抛错或流转卡住；纯 Agent 失败可能是死循环、答非所问、调用错误工具。

第三，成本结构不同。传统编程主要是工程成本；Workflow 主要是流程设计成本；纯 Agent 主要是 Token 成本和重试成本。

关键要点#

• 区分这三者的关键是”控制流由谁决定”。
• 没有绝对优劣，真实项目里它们经常组合使用。
• 越灵活的系统，越需要在稳定性上补课。

容易踩的坑#

• 把 Agent 讲得”高级”，把 Workflow 讲得”低级”，显得判断片面。
• 没讲清楚 Agent 和 Workflow 经常是组合关系，而不是替代关系。
• 忽略传统编程依然是所有系统的底层。

示范话术#

我一般会从”控制流由谁决定”来区分这三者。传统编程的控制流完全由程序员写死，确定性最强；Workflow 是”路径确定 + 节点智能”，整条主干是编排好的，但每个 Node 可以让 LLM 去做判断；纯 Agent 是”目标确定 + 路径由模型决定”，LLM 自己规划、自己选择工具。三者没有绝对优劣，真实项目里反而经常组合——比如主链路用 Workflow 兜住确定性，在容易出错的节点嵌入 Agent 去做判断。讲这一题我会特别强调一点：越灵活的系统稳定性越差，所以生产里盲目追求”全 Agent”通常是个坑。

核心答案#

这四种是 Agent 领域最常被提到的执行范式，理解它们的关键不是背定义，而是搞清楚”什么时候用谁”。

ReAct（Reason + Act）把”推理”和”行动”绑在同一步，每一步都先思考再行动、然后观察、再思考。ReAct 适合步骤少、需要即时反馈、决策高度依赖上一步结果的任务，比如客服问答、简单工具链调用、单页面信息检索。它的优势是反应快、轨迹清晰，劣势是缺少长期规划，复杂任务容易卡在局部最优。

Plan-and-Execute先把目标拆成完整计划，再逐步执行。Planner 一次性产出步骤列表，Executor 严格按计划执行，必要时 Replanner 介入。适合任务可以提前规划、步骤之间有清晰依赖、长周期任务的场景，比如批量数据处理、跨系统数据迁移、报告生成。它的优势是路径可控、易调试，劣势是计划容易过期，模型变更时需要 Replanner 介入。

Reflection在每一步或每几步之后显式做”自我评价”，根据评价决定重做、修改或继续。适合质量要求高、单步结果需要复核、有明确评分标准的任务，比如代码生成、长文本写作、研究报告。它的优势是输出质量高，劣势是 Token 成本翻倍，评价器的设计本身就是难点。

Multi-Agent让多个有不同角色的 Agent 协作完成任务，比如 Planner Agent、Executor Agent、Critic Agent、Search Agent。适合任务可拆解为多个独立视角、需要多领域知识、需要博弈和对抗的场景，比如复杂研究、跨领域决策、模拟用户与专家对话。它的优势是能力上限高，劣势是通信成本、调试成本、一致性问题都很严重，生产里通常最后才考虑。

选择范式的核心判断是三个维度：任务复杂度、调试容忍度、成本承受度。复杂度低、要稳定、要省成本，就用 ReAct 或 Plan-and-Execute；复杂度中、要质量，就加 Reflection；复杂度高、能接受成本和调试代价，再考虑 Multi-Agent。

关键要点#

• 四种范式没有优劣，只有适用场景。
• 范式越复杂，调试成本和通信成本上升越快。
• 实际项目里，混合范式最常见——主干用 Plan-and-Execute，关键步骤加 Reflection。

容易踩的坑#

• 把”用 ReAct”当成 Agent 唯一正解。
• 没意识到 Reflection 的”评价器”本身就是工程难题。
• 盲目推 Multi-Agent，忽略通信、调试和一致性问题。

示范话术#

这四种范式我一般按”任务复杂度 + 调试容忍度 + 成本承受度”三维度来选。ReAct 是”想一步做一步”，适合步骤少、决策高度依赖上一步结果的轻量任务；Plan-and-Execute 是”先想清楚再动手”，适合长周期、步骤可拆解的任务，主链路更可控；Reflection 是”做完了再回头看”，适合质量要求高的场景，比如代码生成和研究报告，但要付出双倍 Token 成本；Multi-Agent 是”分角色协作”，能力上限最高，但通信、调试、一致性都是坑。落到生产里我很少用单一范式，更常见的是主干 Plan-and-Execute、关键节点加 Reflection、需要多视角时再拆 Multi-Agent。

核心答案#

工具 description 是 Agent 决定”何时调哪个工具”的唯一依据，因此它的质量直接决定 Agent 能不能选对工具。

Agent 在调用工具时，并不真正”理解”工具在做什么。它能看到的只有工具的 schema——名字、参数和 description。LLM 通过读 description 来判断”这个工具能解决我现在的子问题吗”。换句话说，description 既是工具的”自我介绍”，也是 Agent 的”调用说明书”。

一个好的 description 至少要回答三件事：这个工具能做什么、在什么场景下使用、什么时候不该用。比如同样是发邮件工具，写成”发送邮件”是远远不够的，应该写成类似”用于在用户明确确认后向指定收件人发送邮件通知；不适用于群发营销邮件，不适用于发送含敏感信息的邮件，需要先经用户授权”。

description 不好的典型后果有四种：

第一，调用错工具。description 太宽泛，模型不知道什么时候用，导致本来应该用工具 A 的场景用了工具 B。

第二，错过调用。description 写得太技术化或太抽象，模型看不懂这个工具能解决它的问题，于是选择自己瞎答。

第三，参数错乱。description 没说明参数之间的关系，模型填错参数格式或语义，导致调用失败。

第四，越权调用。description 没写边界条件，模型在不该调用的场景下也调用，比如把”删除文件”工具用到生产数据上。

实际工程里，好的 description 通常要满足五个特征：动词开头说明能力、明确触发条件、列出关键参数、说明副作用和限制、给出反例或不适用场景。同时，description 也要随工具使用情况持续迭代——可以看 Agent 实际调用的轨迹，反查哪些 description 误导了模型。

关键要点#

• description 是 LLM 理解工具的唯一窗口，写不好等于关上了 Agent 能力的天花板。
• description 要写”能做什么、什么时候用、什么时候别用、参数怎么传”。
• description 不是一次性的，需要看轨迹持续迭代。

容易踩的坑#

• 把 description 写成”一句话功能说明”，缺少触发条件和边界。
• 忽视副作用和权限提示，导致越权调用。
• description 写完后不改，靠模型自己”理解”。

示范话术#

工具 description 是 Agent 决定”什么时候调哪个工具”的唯一依据，所以它本质上既是文档也是 API。我见过的 description 问题主要有四类：写得太宽泛导致调用错工具，写得太技术化导致错过调用，没讲参数关系导致参数错乱，没讲边界导致越权调用。所以我写 description 时会强制覆盖五点：能做什么、什么时候用、关键参数怎么传、副作用是什么、不适用场景是什么。description 写完也不是一劳永逸，我会定期看 Agent 实际调用的轨迹，反查哪些 description 误导了模型，再回来迭代——很多 description 优化都是从失败轨迹里挖出来的。

核心答案#

选择”纯 Agent、Workflow、Agentic Workflow”的核心判断标准是任务路径是否能提前穷举、失败代价是否能接受、调试和合规要求有多高。

纯 Agent适合路径难提前穷举、任务高度开放、对灵活性的要求远高于确定性的场景。比如开放式研究、跨系统信息聚合、用户意图多变的助手类应用。纯 Agent 的优势是灵活、能处理意料之外的情况，劣势是轨迹不稳定、Token 成本高、难调试。

纯 Workflow适合路径明确、节点可控、需要稳定可审计的场景。比如订单处理流水线、合规审查、定时数据同步。它的优势是每一步都确定，可观测可回滚，劣势是任何超出预设路径的情况都会失败。

Agentic Workflow是现在最常见的工程折中——主干用 Workflow 把关键路径锁住，节点内部用 Agent 做局部决策。例如一个客服系统，主干是”接收请求 → 意图识别 → 资料检索 → 生成回答 → 人工复核”的工作流，但”意图识别”和”资料检索”两个节点内部嵌入 Agent，让模型自由选择工具；“生成回答”节点可以加 Reflection 让模型自评。这种结构的优势是既保留关键路径的可控性，又在节点内部享受 Agent 的灵活性。

判断时，可以问自己五个问题：

第一，任务路径能提前画出来吗？能画出来但某些节点复杂——用 Agentic Workflow；能画出来且每个节点都明确——用纯 Workflow；画不出来——考虑纯 Agent。

第二，失败一次代价多大？代价高（涉及金钱、合规、生产数据）——必须 Workflow 兜底；代价中等——Agentic Workflow；代价低（探索性任务）——可以纯 Agent。

第三，是否需要完整审计？需要——Workflow；不需要——可以 Agent。

第四，预算是否敏感？敏感——Workflow 预算可控；不敏感——可以 Agent。

第五，上线时间多紧？紧——Workflow 上线快；不紧——可以花时间做 Agent 调优。

关键要点#

• 真实项目里 Agentic Workflow 才是最常见的选择。
• 选哪种方式，本质是在”灵活性”和”可控性”之间找平衡。
• 失败代价和合规要求，往往比技术时髦度更影响选择。

容易踩的坑#

• 盲目追求”全 Agent”，把生产系统做成 Demo。
• 把 Workflow 视为”过时方案”，忽略它的可观测性和稳定性。
• 没意识到混合形态 Agentic Workflow 才是工程最优解。

示范话术#

我一般按五问来判断。任务路径能提前画出来吗？画得出来——Workflow；画得出来但某些节点复杂——Agentic Workflow；画不出来——纯 Agent。失败一次代价多大？代价高就必须 Workflow 兜底。需要完整审计吗？需要就 Workflow。预算敏感吗？敏感就 Workflow。时间紧吗？紧就 Workflow。这五问里只要有两到三个偏 Workflow，那就别硬上纯 Agent。真实项目里我做得最多的其实是 Agentic Workflow——主干用 Workflow 把关键节点和审计点锁死，里面嵌入 Agent 做局部决策，必要节点加 Reflection。完全用纯 Agent 的项目其实非常少，往往只在内部工具或研究项目里出现。

核心答案#

Multi-Agent 看起来是”多个专家协作解决问题”，能力上限高，但代价也大。生产里盲目上多 Agent 经常是 Agent 项目失控的主要原因。常见问题至少有六个。

第一，通信成本爆炸。每个 Agent 都有自己的上下文窗口，Agent 之间传递信息时，要么塞进消息、要么塞进共享 Memory，Token 消耗是单 Agent 的数倍。如果通信协议没设计好，还会出现重复信息、过期信息循环传递。

第二，调试极其困难。Multi-Agent 系统的轨迹是多条异步流，事后定位”是哪一步、哪个 Agent 出了问题”非常耗时。没有专门的 Trace 工具，几乎无法生产。

第三，一致性问题。多个 Agent 各自决策时，目标和约束可能不一致。比如 Planner Agent 决定”做 X”，Executor Agent 解读成”做 Y”，Critic Agent 又评判”为什么不做 Z”。没有明确的全局目标和冲突解决机制，整个系统会陷入内部矛盾。

第四，延迟和成本叠加。每多一个 Agent，就多一轮 LLM 调用。一个看上去简单的任务可能要走 Planner → Executor → Critic → Refiner 四轮，成本和延迟都会显著上升。

第五，错误传播和放大。上游 Agent 的错误会顺着消息传递放大到下游。第一个 Agent 跑偏一点点，到第三个 Agent 已经歪得很厉害。

第六，角色边界模糊。没有清晰的角色定义时，Agent 之间会出现能力重叠、互相推诿、越权调用，团队沟通成本和工程成本都急剧上升。

所以生产里的原则是：能用单 Agent 解决的就别拆 Multi-Agent；拆 Multi-Agent 时必须有明确的角色、全局目标、冲突解决机制和专用 Trace 工具。Multi-Agent 真正适合的场景，往往是任务本身需要多个独立视角、需要对抗、需要角色分工，比如研究类项目、复杂决策模拟，而不是”为了显得高级”。

关键要点#

• Multi-Agent 能力上限高，但工程代价高。
• 通信、调试、一致性是三个最常被低估的难题。
• 拆 Multi-Agent 前先问：单 Agent + 更好的工具和上下文，能不能解决问题？

容易踩的坑#

• 把”多 Agent”当成先进的代名词，忽略它的成本。
• 没设计全局目标和冲突解决机制，让 Agent 互相打架。
• 没有专用 Trace 工具，出问题完全无法排查。

示范话术#

Multi-Agent 我会慎用。它确实能拉高能力上限——多个专家角色协作，可以处理更复杂的任务——但代价非常高。我的看法是六个字：通信、调试、一致性。通信上，每多一个 Agent 就多一轮上下文传递，Token 成本是单 Agent 的好几倍；调试上，多条异步流混在一起，定位问题非常痛苦；一致性上，多个 Agent 各自决策，目标可能互相打架，没有全局目标和冲突解决机制就会内耗。再加上延迟叠加、错误传播、角色边界模糊，这些问题在 Demo 里看不出来，一上生产就放大。所以我的经验是：能用单 Agent 解决的就不拆 Multi-Agent，必须拆的时候也要先定全局目标、角色边界、冲突解决机制和专用 Trace 工具，再上线。