企业官网建设流程全解析

我最近集中看了一批 AI Agent 方向的面试记录，也帮朋友做过几轮模拟面试，一个很直观的感受是：2026 年的面试已经过了“知道几个框架名就能聊”的阶段。面试官会一路追问到细节——你的 Agent 为什么会死循环？一轮任务烧掉多少 token？工具返回的 JSON 解析失败怎么办？这些问题重复率高得惊人，绕来绕去始终没离开主流架构、token 消耗、工具调用、记忆、RAG、部署评估这几条线。

下面这套考点拆解是从几十份真实面经里筛出来的重复项，覆盖了大部分高频问题。它不是让你背答案，而是一份自检清单：每个问题你都能结合自己项目讲出“当时怎么做、踩了什么坑、最后怎么解决”，面试就成功了一大半。准备 Agent 岗位的候选人可以拿它查漏补缺，正在做 Agent 项目的开发者也可以当作架构复盘列表用。

我也提前说明一句：面试没有标准答案。同一个问题放在不同业务背景下，最优解完全不同。所以下面我尽量给的是思考框架和常见陷阱，而不是让你照抄的“满分话术”。

1. 面试官到底在筛什么能力

1.1 Agent 方向不是“会调 Prompt”，而是“能闭环”

普通 LLM 应用面试考的是模型原理、Prompt 工程、RAG 这些单点能力。Agent 面试考的是一条完整闭环：模型输出决策 → 调用工具 → 观察结果 → 修正下一步 → 输出最终答案。这个闭环能不能稳定跑完，比“你用过哪个框架”重要得多。

我见到的常见翻车现场是：候选人简历写“熟悉 ReAct、LangGraph、MCP”，但被问到“你的 Agent 什么时候停下来”就卡住。这个问题背后其实是在确认两件事：第一，你有没有真正理解 Agent 是循环系统，不是一次性问答；第二，你有没有在生产环境里处理过循环失控。如果回答停在“我设置了 max_steps=10”，面试官多半会接着问“10 步跑完还没出结果怎么办”“模型反复调用同一个工具怎么办”，这一层接不住，前面印象分基本清零。

所以准备 Agent 面试，第一优先级不是背框架名词，而是把一个最小闭环想透：谁发起、谁决策、谁执行、谁判断结束、异常往哪走。这五个问题能答清楚，基础分就有了。

1.2 六类高频考点，占比一目了然

我把面经里反复出现的题目按方向归类，重复率大致如下：

这个分布说明一个趋势：面试官越来越看重“能不能上线”，而不是“会不会写 demo”。纯考 LangGraph API 的题目反而少了，更多是让你在具体场景里做选型和取舍。候选人如果能把每个方向的问题都落到自己的真实项目里，通过率会明显提升。

2. 架构与推理循环：Agent 面试题的根

2.1 送命题：Agent 和普通 LLM 应用的本质区别是什么

这道题出现频率极高，但大部分答案停留在“Agent 能调用工具、能自主决策”。这样答没错，但太浅。面试官真正想听的是“循环”和“状态”这两个词。

我建议用这个结构答：普通 LLM 应用是“一次问答”，输入问题，模型返回答案，流程结束。Agent 是一个带循环的自主执行系统，模型在循环里反复执行“观察 → 决策 → 行动 → 再观察”，直到满足终止条件。它有两个关键设计：第一，循环的每一步都会改变上下文状态；第二，循环必须被显式控制，否则会失控。

接着可以主动补一句：“所以我会把终止条件分成三类：正常完成、到达最大步数、异常触发人工接管。”这句话一说出来，面试官就知道你不是只会调 API，而是真把 Agent 当系统设计过。

2.2 主流架构怎么选：ReAct、Plan-and-Execute、Multi-Agent

面试里让你“比较 ReAct 和 Plan-and-Execute”的题目很多，但核心不是考定义，而是考选型判断。我给一个简洁的对照框架：

我自己的选择经验是：研究型任务，比如“根据资料写一份竞品分析”，用 ReAct 更自然，因为它需要边看边调整；流程明确的运维任务，比如“每天定时巡检服务器并生成日报”，用 Plan-and-Execute 更合适，计划清楚了再执行，不容易失控；只有任务确实可以拆成多个并行子任务时，才考虑 Multi-Agent，否则就是给自己增加通信成本。

面试时如果能补一句“Multi-Agent 不是越复杂越好，我见过很多项目是为了架构好看才上多智能体，结果光协调就比原来更慢”，会显得你有真实判断力。

2.3 LangGraph/状态机：为什么“图”比“自由循环”更受面试官喜欢

LangGraph 这类框架现在几乎是 Agent 岗位的必问项。面试官爱它，是因为它把“循环”变成了显式状态机：你有节点、有边、有共享状态，还能在任意节点暂停和恢复。

用 LangGraph 做 Agent，核心概念就四个：节点、边、状态、checkpoint。节点是“调 LLM”或“执行工具”；边定义流程走向，可以是条件边，比如“如果模型说需要再查一次资料，就回到工具节点”；状态是全局共享的数据，记录所有中间信息；checkpoint 是把每一步状态保存下来，支持断点续跑。

面试里常追问 checkpoint 的作用，这是区分有没有实战经验的分水岭。我通常这样答：“checkpoint 不只是为了容错，更重要的是支持人工审批。工具节点执行前写入一个 checkpoint，把当前状态保存住，等人确认后再继续跑。否则一旦中间崩了，用户只能从头再来。”这个回答同时覆盖了技术深度和产品意识。

如果面试官让你写个最小循环，不要慌，用伪代码表达思路就够了，比如 React 的骨架：

messages = [system_prompt, user_query] for step in range(max_steps): resp = llm.chat(messages, tools=tool_schema) if resp.tool_calls: result = execute_tool(resp.tool_calls[0]) messages.append(tool_result(result)) else: print(resp.content) break

重点是讲清“工具结果必须回填到消息历史”，不要忽略了这一点。

2.4 token 是什么？为什么 Agent 面试绕不开它

很多候选人第一次听到“ai agent token 是什么意思”会愣住。其实 token 是模型处理文本的最小单位，一个汉字大约对应 1 到 2 个 token，英文常用词大约 1.3 个左右。面试官问 token，本质是问成本意识：你到底清不清楚 Agent 为什么这么烧钱。

很多人以为 token 消耗集中在用户问题，其实大头在循环本身。我常用一个例子估算：假设系统提示 800 token，用户问题 200 token，工具定义 7 个约 900 token，那么第一次调用之前的固定开销就是 1900 token。模型每迭代一轮，会产生约 400 token 的推理输出，工具再返回 800 token 的结果，也就是每轮往上下文里塞 1200 token。跑 5 轮，动态部分 6000 token，加上固定开销一共 7900 token。

更关键的是，每一轮的输入 token 都包含之前全部历史。也就是说，轮数越多，每轮成本不是线性增长，而是持续叠加。所以面试官听到你能说出“我会控制循环轮数，把工具结果做摘要再回填”这种话，会立刻知道你有成本意识。

2.5 循环失控是高频追问，别只会说 max_steps

几乎每个 Agent 项目都会遇到循环失控。高频场景是：模型反复调用同一个搜索工具，返回结果都是相似内容，但它就是不写最终答案。面试官问这个问题，想听的是“检测机制”而不是“粗暴限制”。

比较好的回答分三层：第一，设置最大步数，这是最后一道防线；第二，做重复动作检测，记录最近 N 轮的动作，如果工具名和参数都相同，就强制中断；第三，把控制权交还给用户，提供人工干预入口。伪代码如下：

from collections import deque recent_actions = deque(maxlen=3) for step in range(max_steps): action = extract_action(resp) if len(recent_actions) == 3 and len(set(recent_actions)) == 1: human_review(recent_actions[-1]) break recent_actions.append(action)

这套组合方案的价值在于：它不是一刀切停止，而是让系统在“继续尝试”和“防止空转”之间做了平衡。加上“同类动作连续出现 3 次就切换策略”的细节，面试官就会觉得你是真解决过问题的人。

3. 工具、记忆、RAG 与 MCP：Agent 的能力边界

3.1 Function Calling：原理清不清，一问便知

Function Calling 不是魔法。流程是：把工具定义成 JSON Schema 传给模型，模型在回复里输出结构化 tool_calls，程序校验参数、执行工具，再把结果作为消息回填。面试官常追问“如果模型返回的参数类型不对怎么办”，这题很多人答不上来。

正确思路是：在工具执行前加一层参数规范化。模型输出的是字符串，底层工具需要的可能是整数、布尔值、枚举，不能直接透传。规范化的同时还要做白名单校验，比如文件路径、用户 ID 这类敏感字段必须严格校验。工具类型和参数的 JSON schema 例子类似这样：

{ "function": { "name": "search_orders", "parameters": { "type": "object", "properties": { "user_id": { "type": "string" }, "limit": { "type": "integer", "maximum": 50 } }, "required": ["user_id"] } } }

另外一个高频追问是“工具执行超时怎么办”。我的处理原则是：每个工具单独设置 timeout，超时后把错误信息直接回填给模型，让它选择备用路径，而不是把错误吞掉。工具错误对模型来说是有效信息，能帮助它修正下一步决策。

3.2 记忆设计：回答“100 万条历史”这类题的正确姿势

记忆题最怕张口就是“把历史消息都存进向量数据库”。面试官听到这种答案，立刻知道你只是背过概念。记忆设计的核心是分级，不是“全塞”。

我的回答结构是：短期记忆放在当前上下文，维持模型对任务的连贯理解；长期记忆放在外部存储，比如向量库或键值库，存用户的偏好、历史结论、关键实体；写入时机比召回时机更重要，不能每条消息都写入，最好在完成一段任务后异步抽取摘要并入库。

如果面试官追问“100 万条历史怎么处理”，我会说：先做会话切分，把一个连续任务作为记忆单元；再从单元里抽取结构化信息，比如用户偏好、常用工具、上次任务状态；召回时根据当前问题做相关性检索，只把 top 5 到 top 10 条结果拼入上下文。这样既保留信息，又不至于把上下文撑爆。

3.3 RAG 在 Agent 里的位置：检索不是万能，但可以当一个工具

RAG 和 Agent 的关系，很多面试者容易搞混。RAG 适合“答案要从私有知识库里来”的任务，Agent 适合“需要多步决策和工具操作”的任务。二者最优的结合方式是：把检索做成 Agent 的一个工具，让模型自己决定“这个任务需不需要查资料”。

这样设计的优点是：知识问答时模型会主动调检索，闲聊或推理时它不会浪费一次检索调用。面试里被问到“RAG 与 Agent 怎么选”，不要答成非此即彼，而是说“RAG 解决知识来源问题，Agent 解决决策流程问题，实践里我通常把 RAG 包成 search 工具给 Agent 调用”。这个回答同时体现了系统整合能力和框架理解。

还可以补一句评估重点：不只要看回答正确率，还要看检索召回率和引用准确率。Agent 如果引用了检索结果但最后答错，也说明检索质量有问题。

3.4 MCP 是热点题，但别停留在背定义

2026 年 MCP 几乎成了 Agent 面试必聊话题。它全称是 Model Context Protocol，目标是让不同 Agent 用统一方式发现和调用外部工具与数据源。面试官常问“MCP 和 Function Calling 有什么区别”，这个问题最容易暴露理解深度。

参考回答：Function Calling 是模型层的交互能力，解决的是“模型怎么把行动意图结构化地表达出来”；MCP 是工具层的接入标准，解决的是“Agent 怎么统一连接不同服务”。一个偏模型内部协议，一个偏工程生态协议。MCP 不会替代 Function Calling，相反，它要靠 Function Calling 来落地。

如果面试官让你设计一个 MCP Server，你可以说：Server 需要暴露工具列表和调用入口，Agent 通过 Client 发现工具，把工具描述转换成模型能理解的 JSON Schema，再通过 Function Calling 触发调用。MCP 的价值在于减少重复适配，而不是让模型直接理解任意工具。

3.5 近一年热词工程题：Rust、Django、小红书自动化

面试里偶尔会出现一些“热点题”，本质上考的是工程边界。

基于 Rust 语言做 AI Agent 是个典型热点。面试官不是真想让你现场写 Rust，而是想听你怎么权衡。参考回答：Rust 的优势是性能和并发，适合做工具执行层、状态缓存、高吞吐网关；劣势是生态迭代比 Python 慢，直接实现 Agent 编排成本较高。我的方案倾向于分层：调度决策层用 Python，重 IO 的工具执行层可以用 Rust 服务化，两边通过接口通信。

用 Django 开发 Agent 也很常见。核心考点是：不要把 LLM 循环写进同步请求里，否则会因为超时阻塞大量 worker。通常是用异步任务队列执行 Agent 循环，通过 SSE 或 WebSocket 把进度推给前端；会话记录、任务状态和工具执行日志放到数据库，方便恢复和排查。

至于“让小红书自动发消息”这类题目，它本质是“内容生成 + 定时触发 + 人工审批 + 发布调度”的复合任务。回答时要突出四个设计点：任务拆解、内容模板、人审闸门、幂等重试。尤其强调：这类自动化必须遵守平台规则、控制频率、保留人工确认环节，目的是帮运营提效，不是做批量垃圾内容。这个立场既明确又安全，面试官也会认为你想问题足够全面。

4. 开发、部署与评估：从 Demo 到能上线

4.1 “你怎么证明 Agent 效果好”是必问题

几乎每个实战型面试官都会问：你怎么评估自己的 Agent？如果答“我测了几个例子，感觉效果不错”，基本就凉了。评估不能靠感觉，要有指标。

我建议按四个维度展开：任务完成率，也就是给定一组典型任务，Agent 有多大比例能正确完成；工具调用质量，包括工具调用成功率、无效调用占比、平均调用次数；成本指标，记录每轮任务的 token 消耗和平均耗时；回归能力，每次修改 Prompt 或工具 Schema 后，同一批测试用例的结果是否稳定。准备面试时，最好能从自己项目里说出两组数字，比如“测试集 50 条，任务完成率从 62% 提到 84%，无效工具调用从 21% 降到 6%”。

这类量化结果比十个概念描述都有说服力，因为它说明你有评估闭环和迭代方法，而不只是能写 demo。

4.2 生产环境的 Agent 到底加了多少东西

很多人做完 demo 就写进简历，结果面试官一问生产细节就露馅。生产环境和 demo 的差距，主要体现在这些隐藏组件上：输入校验和权限控制、任务队列、限流与重试、超时处理、状态持久化、可观测性。

以 Django 集成 Agent 为例，正确的做法是：用户发起一个任务，先创建任务记录，再把任务丢进后台 Worker 执行 Agent 循环，前端用 SSE 接收进度。循环里每一步都要做异常捕获，模型超时就自动走降级回复，工具失败就把错误信息回填给模型让它换个策略。状态持久化尤其重要，任务中间崩了，能从最近一个 checkpoint 恢复，而不是重头再来。

面试时如果能说出“我的任务表里有个 status 字段，记录 pending、running、waiting_for_review、done、failed”，面试官马上能判断你有真实工程积累。

4.3 可观测性：把看不见的循环变成可回放的数据

Agent 和传统接口最大的区别是：一次任务内部有多个模型调用和工具调用，出了问题很难复现。所以可观测性不是加分项，而是必选项。

我的建议是：每一次 Agent 运行都生成一个 trace_id，贯穿整个任务；每一步记录模型名、输入 token 数、输出 token 数、工具名、工具耗时、返回结果摘要和错误类型。日志里不要只记一句“调用失败”，要记录失败发生在第几步、模型当时看到了什么上下文。这样做的好处是，线上出现“Agent 绕圈子”时，你能直接翻出最近几轮动作，判断是模型决策问题还是工具返回不清晰。

面试时能主动提“我用 trace_id 把子任务的每个环节串起来，方便复现”，是一个很实用的亮点，也是区分“会跑通”和“能上线”的标志。

4.4 高频故障排查实录：直接能抄的表格

我把实际项目里遇到最多的四类故障整理成速查表。每一条都是真实会踩的坑，面试聊到现场排障非常加分。

这四条基本覆盖了 Agent 开发里 80% 的线上问题。面试时不用背，而是挑一段自己真实经历讲清楚“现象、定位、解决、预防”，比任何标准答案都更有说服力。

5. 高频考点速查与准备建议

5.1 自测 20 题：先别往下看，能答出几道

下面这组自测题覆盖了前面所有高频方向。建议你合上文章，先拿纸笔试答一遍，再看参考答案。

这 20 题不是“刷完就行”，而是用来暴露知识盲区。哪道题回答时只能蹦名词、讲不出自己的取舍，就说明哪块还需要补。

5.2 面试官每个问题背后在听什么

面试官问“你怎么设计记忆”，表面考方案，实际在考你有没有信息分级意识；问“token 怎么控制”，表面考成本，实际在考你对循环本质的理解；问“Django 怎么集成 Agent”，表面考框架，实际在考你懂不懂阻塞、异步、状态持久化这些后端基本功。

所以准备面试不能停留在“记住答案”，要理解问题背后的能力模型。我建议用“目标-方案-坑-量化结果”的结构来讲每个项目：项目要解决什么问题，你用了什么方案，中间遇到什么坑，最后结果和指标是什么。这样回答既有逻辑，又能自然带出细节，比按面试题顺序背熟练得多。

5.3 一周冲刺怎么准备

如果只剩一周，不建议把所有框架都刷一遍，而是按优先级推进。第一优先级是第 1、2、4、19、20 题，它们考察的是 Agent 的核心理解，任何岗位都躲不开；第二优先级是第 6、7、9、11、14 题，覆盖工具、记忆、RAG、MCP 这些高频方向；第三优先级才是 Rust、Django、LangGraph 这类偏实现细节的问题。

时间充裕的话，最好自己把一个最小 Agent 项目跑通，记录一轮任务的日志、token 消耗和失败情况，然后把它包装成一个可量化的项目故事。面试官听到你能说出“这轮任务平均消耗 8000 token，其中固定上下文占 1900”这种细节，记忆点会非常深刻。

如果时间实在有限，至少要把“循环终止、工具回填、成本估算、故障排查”四件事讲清楚。这四件事是 Agent 面试的底层骨架，覆盖它们的熟练度，基本决定了你能不能被归入“有实战感知”的候选人。

我自己带过几次模拟面试，发现一个很普遍的规律：候选人的差距往往不在懂不懂概念，而在敢不敢谈失败。循环失控、token 爆掉、工具调用被限流，这些真实坑讲出来的时候，面试官不会觉得你不行，反而会认为你有系统级的复盘能力。准备 Agent 面试，与其背二十个名词，不如把一个最小闭环跑通，再把它推到生产环境里接受考验。等你真的能说清“状态怎么恢复、成本怎么记账、死循环怎么发现”的时候，这套题库里的每一个问题，都会变成你已经踩过并解决了的故事。