企业官网建设流程全解析

2026 年 AI Agent 面试到底考什么？——这个问题我几乎每周都会被身边的候选人问一次。在经历了几十场 Agent 相关岗位的面试、也作为面试官筛过几百份简历之后，我的感受很明确：这个方向的考察已经从“概念科普”彻底进入“工程实证”阶段。你不可能再说“AI Agent 就是让大模型自己调工具”这种话，因为那是及格线以下的表述。真正的考点集中在：为什么这么设计、生产环境怎么兜底、多智能体怎么协同、token 成本和可观测性怎么算清。

这篇文章是给三类人准备的：准备投 LLM 应用 / AI Agent 方向岗位的候选人，需要设计技术面试题的 Tech Lead，以及在项目里接了 Agent 需求、想系统补课的一线工程师。我会把高频考点按概念、架构、代码、场景、工程五大块拆开，针对大家搜索里经常出现的 Rust 语言 Agent、Agent Token、Agent 部署、社媒自动化、AI 辅助开发等方向做重点展开，最后附上一份可以直接练习的高频题库。文章不会绕弯子，每个考点都给出答题思路和底层逻辑，你照着准备，覆盖市场上九成的高频考题不成问题。

1. 2026 年 Agent 面试真相：面试官到底在筛什么人

1.1 为什么“会调 API”已经不值钱了

2023 年你简历上写“熟练使用 LangChain、会写 prompt、能调通 ChatGPT API”，面试官会觉得这是个不错的 LLM 应用工程师。但到了 2026 年，这套描述基本等同于“我会用电脑打字”——属于默认技能，不是加分项。

原因很简单：Agent 开发的技术栈正在成熟，框架把脏活累活都封装好了。LangGraph 帮你管状态，AutoGen 帮你管多智能体对话，Dify 这类平台甚至把编排、记忆、工具接入做成了可视化拖拽。当“跑通一个 Demo Agent”的成本趋近于零，面试官就只能往两个方向深挖：一是你懂不懂底层机制，二是你能不能把它放到生产环境里稳定运行。前者考原理，后者考工程。

我面试过不少候选人，简历写得很漂亮，项目经历里全是“基于 LangChain 搭建客服助手”“基于 AutoGen 实现多智能体协作”，但一问 ReAct 循环中每一步的输入输出是什么，卡壳；问工具调用失败后 Agent 怎么自愈，卡壳；问单任务 token 成本怎么估算，还是卡壳。这说明很多人做了“调包侠”而不是“工程师”。2026 年面试的本质，就是要把这两类人区分开。

1.2 从岗位 JD 反推考点权重

我统计了近半年的 Agent 相关 JD，提取了高频关键词，基本是这几类：主流框架熟悉度、function calling 实战经验、记忆与规划机制理解、生产部署经验、评测方案设计。把这些关键词转成面试考点，权重分布大概是这样：

这个配比不是绝对的，不同团队会偏移。比如做 Agent 平台基建的团队会更重框架和代码，做业务落地的团队会更重场景设计和成本控制。但有一条主线是共同的：面试官要确认你不是只会调框架，而是能理解 Agent 的每个决策环节，能处理长尾异常，能对每一分钱 token 负责。

1.3 很多面试官参考的 Agent 能力框架

阿里云发布的《AI Agent 白皮书》里，把 Agent 的核心能力概括为环境感知、自主规划决策、工具调用执行、记忆学习演进四个维度。这个框架现在被很多大厂面官直接当成评分量表：你说“我做过 Agent”，他们会把你丢进这四个维度里逐项打分。

你不需要背诵白皮书原文，但要理解背后的逻辑——Agent 之所以叫 Agent，不是因为它能聊天，而是因为它能在一个目标指引下，感知外部环境状态，自己做规划，调用工具改变环境，并把过程中的经验沉淀下来。面试时凡是让你“介绍一下你做的 Agent 项目”，你都应该下意识地按这个框架组织回答，而不是流水账式地讲我用什么框架做了个什么东西。这个习惯能帮你避开一半的零散表达。

2. 概念原理题：ReAct、Agent 边界、记忆与工具调用的本质

2.1 什么是 Agent：它和 Chain、Pipeline 的边界在哪

我面试时最爱问的第一道题是：“你如何判断一个系统是 Agent，而不是一条 Chain？”很多候选人会愣住，因为他们从来没想过这个问题。

答案的要点在“决策点”。Chain 的本质是把 LLM 调用按固定顺序串起来，步骤是预先写死的——先总结、再翻译、再分类，流程固定，模型没有选择权。Pipeline 也是一样，每个节点做什么、什么时候做，由工程师决定。而 Agent 的核心特征是：模型在每一步都要自主决定下一步做什么。它可以选择“调用工具”“读取记忆”“直接回答”还是“向用户提问”，这个选择是运行时发生的，而不是编译期写死的。

所以面试时你可以这样回答：“判断标准是控制权是否在模型手里。如果模型能自主决定工具调用序列和终止条件，就是 Agent；如果只是按预设流程执行 LLM 调用，就是 Chain 或 Pipeline。”市面上很多产品自称 Agent，其实是加了工具调用功能的 Chain——点破这一点，反而显得你真的理解本质。

2.2 ReAct 的完整推理闭环：别只背四个字母

ReAct 是 Reasoning + Acting 的缩写，原理是让模型交替进行推理和行动：先思考当前状态（Thought），再决定调用什么工具（Action），拿到工具结果后继续推理（Observation），直到认为任务完成。

完整的一轮循环是这样的：

• Thought：根据当前已知信息，判断下一步需要什么。比如“用户问今天天气，我需要查天气工具，城市是北京”。
• Action：输出一个结构化动作，通常是工具名和参数，比如get_weather(city="北京")。
• Observation：获得工具返回结果，比如“晴，23 度”。
• 循环：把 Observation 作为新的上下文，让模型继续产出一个 Thought，直到模型输出最终答案（Final Answer）或达到最大步数。

这个循环之所以有效，是因为它把推理过程外显化。模型每一步的思考都会写入上下文，既约束了下一步行动，也为错误追踪提供了依据。面试时如果让你画流程或者写伪代码，你至少要能画出这个闭环，并说清楚三个关键点：什么时候进入下一步、什么时候输出最终答案、达到最大步数怎么办。

2.3 从 Plan-and-Execute 到 Reflexion：升级路线的适用边界

ReAct 有个天然弱点：走一步想一步，没有全局规划，复杂任务容易“只见树木不见森林”。所以出现了 Plan-and-Execute 模式——先让模型生成一个整体计划，再逐条执行。就像你自己做事之前先列个 todolist，而不是每做一步都重新想。

Plan-and-Execute 适合目标清晰、步骤可预见的任务，比如“把这篇文章翻译成英文，再润色，再总结要点”。但它也有问题：计划一旦制定就相对固定，中途出现意外情况很难调整。

Reflexion 则是给 Agent 加了一层“反思”机制：任务失败后，不是直接重试，而是先让模型分析失败原因，把反思结果写入记忆，再带着教训重新执行。我面试时经常让候选人说这三个方案的适用边界，因为真正做项目时不会永远只用一种模式——正确的答案是“混合使用”：全局用 Plan-and-Execute 规划方向，局部用 ReAct 处理不确定环节，失败后用 Reflexion 沉淀教训。

2.4 记忆体系设计：短期、长期与工作记忆

Agent 记忆是这两年面试加码最狠的考点。原因很实际：没有记忆的 Agent 就是个无状态接口，每次任务都从零开始，做的再多也不积累经验。

面试时你至少要能讲清楚三层记忆：

• 短期记忆：即对话窗口里的上下文，直接拼进模型输入。实现最简单，但受上下文长度限制，且对话一长就越变越贵。
• 长期记忆：通常存在向量数据库里。任务结束后，把关键信息、用户偏好、历史结论抽取出来向量化保存。下次任务开始前，检索 top-k 相关内容注入系统提示词。
• 工作记忆：指当前任务执行过程中的状态数据。比如多智能体协作时，某个 Agent 已经完成了哪一步、产出了什么结果，这些中间状态不能丢，否则任务中断后无法恢复。

我见过很多候选人把“记忆”理解成“把所有聊天记录存进向量库”，这是不够的。面试官真正想听的是：你什么时候写入记忆、什么时候读取记忆、记忆怎么更新、记忆和当前上下文怎么合并。换句话说，记忆不是存储问题，而是信息管理问题。

3. 架构与框架题：主流架构、选型逻辑与 Rust 生态的突袭

3.1 主流 Agent 架构的横向对比

“Agent 的主流架构有哪些”是最近面试中出现频率极高的问题。不是让你背名字，而是让你能横向对比。我整理了一张表，覆盖了目前市场上的四种主流形态：

面试中比较出彩的答法，是先抛出这张对比，再结合实际场景说自己的选型思路。比如：“我做客服 Agent 时选了图编排，因为工单流程是有固定节点的，每个环节都需要状态记录；但我在子节点内部又保留了 ReAct 循环，让模型在具体回复时可以自主查知识库、调订单接口。”这个回答同时体现你对架构的理解和实战判断力。

3.2 框架选型题：什么场景用 LangGraph、AutoGen、CrewAI、Dify

选型题几乎必考，但很多候选人只会说“我们项目用了 LangChain”。面试官接着问“为什么不用 X”，就答不上来。框架选型不是押注，而是一道权衡题。

我的回答思路如下：第一，看任务结构。如果是固定流程，比如订单售后、工单处理，优先 LangGraph 这类图编排框架，因为状态流转清晰，方便加人工审核节点。第二，看协作复杂度。如果任务天然适合多个角色并行协作，比如“一个 Agent 做市场分析，另一个做方案撰写，最后汇总”，优先 AutoGen 或 CrewAI，它们把多智能体通信机制封装好了。第三，看交付团队的能力和速度。如果团队没有深度开发能力，业务需要快速上线，Dify 这类低代码平台更现实，代价是可定制性弱。

面试时只要你把“场景 → 约束 → 选择”这条链路讲清楚，就算用了一个稍微小众的框架，面试官也不会扣分。因为 2026 年面试官看的不是你会用什么工具，而是你怎么做技术决策。

3.3 为什么 Rust 开始出现在 Agent 岗位的 JD 里

最近很多招聘帖出现了“基于 Rust 语言 AI Agent”的字眼，不少候选人一头雾水：Agent 开发不是 Python 的天下吗？其实 Rust 出现在 Agent 面试里有它的合理背景。

Rust 在 Agent 生态里的位置，主要在两个层面。一个是基础设施层：模型推理服务、tokenizer、KV cache 管理、高并发网关，这些对性能和内存安全要求极高的组件，越来越多团队选择用 Rust 重写。另一个是边缘部署层：Rust 可以编译成 Wasm 或小型二进制，直接在边缘设备上跑轻量 Agent，不需要动不动就搞一个几百 MB 的 Python 运行时。

所以面试时如果被问到 Rust 和 Agent 的关系，正确的策略是区分层次。如果你面的是应用层 Agent 岗位，坦白说“Rust 更多用在运行时和推理优化，应用层开发我仍以 Python/TypeScript 为主”完全没问题，再补一句“我了解 Rust 的所有权和并发模型，能看懂 Rust 写的 Agent 运行时源码”，就足够体面。如果你面的是底层框架岗，那 Rust 可能真的是硬性要求，你需要展示 tokio 异步编程、跨 FFI 调用、内存安全设计这些硬功夫。

3.4 Agent Token 到底是什么意思：不只是计费单位

“Agent token 是什么意思”这个问题，在面搜索引擎里热度很高。很多新人把它理解为“Agent 消耗的 token 数量”，这没错，但面试官想听到的更多。

Token 在 Agent 语境下有两层含义。第一层确实是计费维度：一次 Agent 任务的总 token = 系统提示词 + 工具描述 + 历史轨迹 + 每轮工具调用的输入输出。第二层，我更喜欢把它理解为“Agent 的思维带宽”——你给模型多少 token，它就有多少空间去思考、去记忆、去推理。上下文窗口就好像工作台面，工具描述、历史记录、中间推理都在抢桌面位置，桌面不够大，Agent 的表现就会断崖式下降。

面试中只要涉及到成本或者上下文优化，都要有意识地动用这个概念。比如候选人说“我的 Agent 上下文不够用”，我会追问：是窗口太小，还是你的 prompt 太啰嗦？是工具描述太长，还是历史记忆没有压缩？不同答案指向完全不同的优化方案——前者是换模型，后者是工程问题。

4. 手写代码题：ReAct 循环、工具注册与上下文裁剪

4.1 从零实现一个最简 ReAct Agent

面试手写题最常出现的，就是让你不用框架实现一个 ReAct Agent。别慌，这道题考察的核心是：你对循环结构、工具分发、终止条件的理解是否清晰。

这里给出一个最小实现，核心逻辑就几十行：

class Agent: def __init__(self, model, tools, max_steps=10): self.model = model self.tools = {t.name: t for t in tools} self.max_steps = max_steps self.history = [] def run(self, user_query): self.history.append({"role": "user", "content": user_query}) for step in range(self.max_steps): response = self.model.chat(self.history) action = self.parse_action(response) # 解析模型输出中的动作 # 没有动作意味着模型给出最终答案，直接返回 if action is None: return response # 执行工具并记录结果，作为 Observation 继续推理 result = self.tools[action["name"]].execute(**action["args"]) self.history.append({"role": "assistant", "content": response}) self.history.append({"role": "tool", "content": str(result)}) return "达到最大步数，任务终止"

这一段代码浓缩了 ReAct 的三个关键点：第一，工具调用是在循环里动态决定的，而不是预先把工具结果拼好；第二，每一步的工具结果都会追加进历史，形成闭环；第三，必须设置最大步数，防止死循环。

面试时你不需要写出完整可运行的产品级代码，但要把循环、终止条件、工具分发三个要素写清楚，并顺手指出每个要素处理的是什么问题。如果能补充“如果模型连续三步产生同样的 Thought，就判定为循环并强制终止”这种细节，面试官会觉得你有真实的线上经验。

4.2 工具注册与 function calling 的兼容设计

第二个高频手写题是工具注册机制。原因很实际：一个规范的工具注册设计，决定了 Agent 能不能稳定调用函数、能不能自动适配不同模型的 function calling 格式。

一个常见的实现是用装饰器把普通函数升级为 Agent 工具：

def register_tool(name, description, schema): def decorator(func): func.tool_schema = { "name": name, "description": description, "parameters": schema, } return func return decorator @register_tool( "search_product", "根据关键词搜索商品，返回商品列表", {"type": "object", "properties": {"kw": {"type": "string"}}}, ) def search_product(kw: str): # 真实逻辑里这里会去查数据库或商品 API return [{"id": 1, "name": "示例商品", "price": 99}]

这套设计的优势在于：工具描述和函数实现放一起，维护成本低，且可以直接把tool_schema转换成 OpenAI 等模型的 tools 参数。面试时你再补一句“我给每类工具加了统一的异常返回和超时控制，工具内部报错时返回结构化错误码，而不是抛裸异常，这样模型能够理解失败原因并决定是否换一种方式重试”，这一题基本就拿下了。

4.3 上下文裁剪与 token 预算控制的三种策略

代码题第三类常见的是：Agent 上下文已经超了窗口上限，你怎么处理？这道题没有标准答案，但有三类策略需要掌握。

第一是滑动窗口裁剪：只保留最近的 N 轮对话，更早的直接丢弃。实现最简单，缺点是丢失早期信息。第二是摘要压缩：每过若干轮，让模型把之前的对话总结成一段摘要，之后一直带着摘要运行。效果好，但每压缩一次有额外的 token 开销。第三是向量检索：把历史信息向量化存入向量库，每次执行任务前只检索与当前问题相关内容注入上下文。这是长期记忆的标准做法，适合信息量大、需要反复查阅历史的场景。

面试时比较好用的回答是“组合拳”：“对话窗口内我保留最近 5 轮原文 + 更早内容的摘要；如果源信息量太大，我再把原文拆成块进向量库按需检索。”这个回答表明你对成本、效果、实现复杂度三者做了权衡，而不是只会背一个方案。

5. 场景设计题：从“自动发小红书”到“用 Agent 开发 Django 项目”

5.1 场景设计题的万能应答框架

场景设计题是所有环节中最容易暴露水平的地方，因为它的回答没有对错，只有优劣。我总结了六段式应答框架，几乎可以用来解所有 Agent 设计题：

第一步澄清需求。先问清楚用户是谁、目标是什么、输入输出是什么、有哪些非功能约束（延迟、成本、合规）。第二步拆解能力。列举 Agent 完成任务需要哪些工具、需要哪些记忆、哪些环节必须人工介入。第三步设计循环。确定是单 Agent 还是多 Agent，任务什么时候算完成，异常分支怎么处理。第四步规划数据。说清楚记忆写入什么、检索什么、中间状态存哪里。第五步制定评测。任务完成率、准确率、成本、延迟，选出关键指标。第六步兜底安全。权限控制、敏感操作拦截、失败降级。

面试时哪怕你只把框架走完整，没有特别惊艳的细节，分数也不会低。因为框架本身说明你经历过生产环境的设计，而不是只在 Notebook 里跑过 Demo。

5.2 案例走查：让 Agent 自动生成并发布社媒内容

“让小红书自动发消息”这类选题经常出现在热搜，题目本身可以做正反两面设计。正面且合规的答法是：把它设计成企业社媒运营的内容助手，核心价值是辅助创作和定时发布，整个流程必须有人工审核节点。

完整设计如下：Agent 接收运营人员设定的内容主题和产品卖点，调用两个工具——热点检索（获取当前话题趋势）和图片生成（生成配图）。内容生成后，先过一层合规检查工具，筛选敏感词；然后进入人工审核队列，由运营人员确认后再调用发布 API 定时发送。发布完成后，Agent 抓取互动数据，沉淀到长期记忆里，为下一次创作提供偏好参考。

回答这个题目时，我建议你主动提到两点：一是所有对外发布动作必须有明确的人工授权和平台 API 合规使用，这是负责任 Agent 的基本前提；二是你在设计里加入了“发布失败自动重试最多 3 次，超过则通知人工”的兜底逻辑。这两点会直接区分出“懂业务落地”和“只懂技术概念”的候选人。

5.3 复合型题目：AI Agent 与 Django 开发怎么答

“用 AI Agent 开发 Django 项目”这种题目看起来奇怪，其实是个复合型场景题。面试官可能有两种意图：第一种，问的是用 Agent 辅助程序员开发 Django 项目；第二种，问的是在 Django 项目里集成 Agent 能力。你需要在回答前先澄清，面试官更想要哪种。

如果是第一种，核心考点是“辅助编码 Agent 的工具设计”：Agent 需要代码检索工具（grep 项目）、文件读写工具、测试执行工具，还要有安全的补丁应用机制。评测指标要落到代码通过率、测试覆盖率、人工 review 时间减少量上。

如果是第二种，核心考点是“Agent 服务的工程集成”：Agent 长期任务不适合放在 Django 请求进程里，最好用 Celery + Redis 做异步任务队列；Agent 的状态存数据库，任务进度通过 WebSocket 推送给前端；工具调用的外部 API 凭据单独加密存储，不能写进配置文件的明文。哪种意图都能答，关键是先澄清再展开，不要一上来就默认一种理解。

5.4 面试官最爱追问的 5 个“死亡问题”

场景设计题答完，面试官一定会追加压力追问。根据我的经验，以下 5 个问题出现频率极高，提前准备会有明显优势：

第一个：Agent 跑偏了陷入死循环怎么办。你要回答最大步数限制 + 语义雷同检测 + 人工中断接口三层防线。第二个：工具调用失败之后 Agent 怎么自愈。回答思路是重试策略 + 失败原因结构化 + 换工具兜底 + 最后求助人工。第三个：多智能体之间消息怎么保证一致性。可以提中央消息总线、共享状态存储、事件驱动机制。第四个：Agent 的回答错了怎么发现。这就要落到评测集和线上抽样回放。第五个：成本超支怎么止损。答法是单任务 token 预算、并发限流、缓存机制，以及每天的熔断告警。

这些问题没有唯一正确答案，但回答里必须包含“可执行的细节”。比如只说“我们会加日志”就不够，要说“我们每条 Agent 轨迹都会记录 trace_id、模型输出、工具结果、耗时和成本，既能回放又能定位”。

6. 部署运维与成本题：生产环境才是真正的考场

6.1 一次 Agent 任务到底烧多少 token：算账实例

成本题几乎是每个 Agent 岗位终面的必考项。面试官要确认你不仅会搭功能，还算得清业务账。

我们来算一个最常见的客服 Agent。假设每次任务平均需要 4 轮工具调用，每轮模型都会收到：系统提示词 500 token、工具描述 300 token、上下文历史 1500 token（多轮累积后的平均值）、新增的用户问题和工具结果 300 token；模型输出 250 token。那么每轮输入约 2600 token，输出 250 token，单次任务总共约 10400 token 输入、1000 token 输出。

按市场上主流中等偏上模型的定价，假设输入 0.003 元/千 token，输出 0.012 元/千 token，单任务成本大约是 0.043 元。一天 1 万次任务，一个月就是 13 万元左右。这个例子想说明的核心信息是：Agent 的 token 成本和你的架构选择直接相关——多智能体协作、无节制的历史堆积、没有缓存机制，都可能让成本翻几倍。面试时能现场算明白这笔账的人，基本就是他们要招的人。

6.2 部署形态选型：长时任务、状态持久化与弹性

Agent 任务和普通 API 服务的最大区别在于：它不是一次请求一次响应就结束了，而是一个需要多轮工具调用、可能持续几十秒甚至几分钟的“长时任务”。这给部署带来了三个问题。

第一，进程模型。把 Agent 跑在普通 Web 容器里，请求时间长会占满工作线程，并发一高就雪崩。更合理的方案是把 Agent 执行放到独立的异步任务队列，Web 层只负责接收请求和返回任务状态。第二，状态持久化。Agent 的中间轨迹、记忆、任务状态不能只存在内存里，否则进程重启就丢。Redis 存短期状态，数据库存任务结果，向量库存长期记忆，这是标配。第三，弹性伸缩。Agent 任务对 GPU/API 的消耗是间歇性的，适合用 Serverless 或 HPA 弹性伸缩兜住波峰，而不是常年拉着一批高配机器闲置。

面试时你不需要给出一个固定架构，但要把“长时任务”这个前提摆出来，并围绕它推导出部署选择。一旦你能把这个逻辑链条讲顺，就已经达到高级工程师的水平了。

6.3 可观测性：Agent 日志到底要记什么

Agent 出了错为什么特别难排查？因为一次回答背后可能经历了 5 次工具调用、几十条中间推理。如果日志只记录最终的模型输出，出了问题完全没法定位。

我建议的 Agent 日志字段至少包含：trace_id（贯穿整个任务）、当前步骤序号、模型输入（系统提示 + 上下文概况）、模型输出、解析出的工具名与参数、工具执行结果、工具耗时、本轮 token 数、累积成本、是否触发终止条件。每一条 Agent 轨迹都应该能从头回放，这样线上出问题才能查出到底是模型理解错了、工具报错了，还是历史上下文污染了。

面试问到可观测性，你还可以提一句“评测回放”：“我们会把线上失败的轨迹收集起来，定期用失败用例扩充评测集，让 Agent 的回归测试越来越完整。”这句话很加分，因为说明你不是把评测当作上线前的一次性动作，而是当成了持续运营机制。

6.4 安全护栏：权限、注入、幂等与人工闸口

越强的 Agent 越需要约束，这是生产环境不变的真理。面试中安全题一般从四个角度展开：

权限最小化。Agent 调用工具时，要用最小必要权限。比如一个客服 Agent 查询订单，只给只读权限，绝对不能给修改订单状态的权限，改状态必须走人工。提示词注入。恶意用户可能在输入里夹带“忽略之前指令”之类的攻击，Agent 需要做输入过滤、对工具参数做白名单校验、对高风险操作二次确认。幂等性。一个“发送短信”的工具被调用两次就会出事故，所以工具设计必须支持幂等标识，同一任务的重试不能重复执行副作用操作。人工闸口。凡是有外部副作用的高风险动作，设计上就必须插入人工审批节点。这四项是 Agent 治理的关键骨架，也是面试官判断你有没有“把 Agent 放上生产环境的资格”。

7. 高频考点速查题库：面试前一周的复习清单

7.1 概念与原理题：20 道

1. 什么是 AI Agent？它和大模型应用有什么本质区别？
2. Agent 与 RAG 是什么关系？它们会互相取代吗？
3. ReAct 循环的每一步输入输出是什么？
4. Chain-of-Thought 和 ReAct 的联系与区别？
5. 什么是 Plan-and-Execute？适合什么场景？
6. 什么是 Reflexion？它解决什么问题？
7. 工具调用（function calling）的底层原理是什么？
8. 什么是工具幻觉（tool hallucination）？怎么缓解？
9. Agent 为什么需要记忆？记忆分几类？
10. 短期记忆和长期记忆各自适合存储什么内容？
11. Agent 如何判断任务已经完成并停止循环？
12. 多智能体之间有哪几种通信方式？
13. 什么是 Human-in-the-loop？哪些场景必须有？
14. Agent 最常见的失败模式有哪些？
15. 评估一个 Agent 至少需要哪些指标？
16. Agent 的“规划”能力和“执行”能力是分开建模还是统一建模？
17. 什么是超参数里最常见的坑：temperature 对 Agent 有什么影响？
18. System Prompt 在 Agent 里承担什么角色？
19. Agent 和 Workflow 的核心区别是什么？
20. 什么是 Agent 的“自主性”？它和安全性怎么平衡？

7.2 框架与工程题：12 道

1. LangGraph 和 LangChain Agent 的区别是什么？
2. AutoGen 和 CrewAI 在智能体协作方式上有什么不同？
3. 你如何给一个 Agent 项目选型？
4. Agent 的多轮状态怎么管理？断线重连后如何恢复？
5. 工具调用失败后，你的 Agent 怎么自愈？
6. 如何缓解提示词注入攻击？
7. 怎么给 Agent 的重复请求加缓存，同时不让结果过期？
8. 如何保证 Agent 输出严格符合 JSON Schema？
9. 一次 Agent 任务执行到一半，模型 API 超时怎么办？
10. Agent 的多轮记忆存 Redis 还是存数据库？为什么？
11. 你如何设计 Agent 的工具描述，让模型更准确地调用？
12. 边缘设备上部署 Agent 和云端部署有什么差异？

7.3 场景与开放题：8 道

1. 设计一个 7×24 小时运行的电商客服 Agent，画出你的模块划分。
2. 设计一个企业社媒内容运营助手，流程中哪些环节必须人工介入？
3. 用 Agent 辅助开发一个 Django 项目，需要给 Agent 配哪些工具？
4. 你的 Agent 上线后，如何用线上数据持续迭代？
5. 如果大模型厂商突然断供或价格暴涨，你的 Agent 怎么降级？
6. 你怎么向非技术老板解释 Agent 的能力边界，避免他过度承诺客户？
7. 你如何设计一套 Agent 回归评测集，并且让它自动扩充？
8. 未来两年，Agent 会改变哪些岗位的工作方式？

我的建议是，概念题用“开口说三分钟”的方式准备，每题先给出定义、再说设计考量、最后补一个例子，形成身体的记忆。场景题不要背答案，用第五部分的六段式框架自己完整推演三遍。代码题务必亲手写一遍最简 ReAct 和工具注册，光看不练在面试现场一定会卡壳。最后我想说，面试其实是一面镜子，把题库过一遍只是底线，真正能让你脱颖而出的，是你对 Agent 这门工程的敬畏感——踏踏实实把每个失败案例复盘清楚，比任何技巧都有用。