企业官网建设流程全解析

1. 为什么这10道题成了Agent工程师的“照妖镜”

这两年Agent这个词被炒得滚烫，招聘JD上但凡沾点AI的岗位，不写一句“熟悉Agent架构”都不好意思发出来。但真到面试环节，很多候选人的表现就很有意思了：聊概念头头是道，一追问实现细节就开始打太极，再问边界条件和失败场景，基本就只剩“这个我们后续会优化”了。

我参与过不少轮Agent岗位的技术面，也帮朋友做过模拟面试官。说实话，能把这10道题答利索的人，一只手数得过来。大部分人的问题不是不懂，而是只懂了个壳——知道ReAct、知道Function Calling、知道向量数据库，但为什么这么设计、什么时候会崩、崩了怎么救，一问三不知。

这篇文章就是把这10道高频题拆开揉碎，不光给答案，更给答题的思路和背后的逻辑。适合正在准备Agent方向面试的人，也适合已经在做Agent但想系统梳理一遍知识体系的工程师。我会按“面试官到底想听什么”的角度来讲，而不是背八股。

2. 第一类问题：Agent的基础架构与核心循环

2.1 题目一：请描述一个Agent的完整运行循环，从接收输入到输出结果

这题看着基础，但能答完整的人不多。大部分人会说“思考-行动-观察”循环，然后就没然后了。面试官想听的是你对整个链路的掌控力。

一个完整的Agent循环至少包含这几个阶段：输入解析与意图识别、上下文组装、规划与推理、工具选择与调用、结果观察与状态更新、终止条件判断。每个阶段都有坑。

输入解析阶段，很多人直接拿用户原始query去检索，这是大忌。用户说“帮我看看上周那个项目的进度”，你得先解析出“上周”对应的时间范围、“那个项目”指代的是哪个项目。这一步做不好，后面全白搭。

上下文组装是区分新手和老手的关键。新手把所有历史对话一股脑塞进去，老手会做分层上下文管理：系统提示词单独一层、工具描述单独一层、近期对话做摘要、远期对话做向量检索召回。为什么要分层？因为token是钱，而且无关信息会干扰模型判断。

规划与推理阶段，ReAct模式是最常见的，但纯ReAct有个致命问题：它没有全局规划。模型走一步看一步，容易在局部最优里打转。所以实际生产环境里，通常会加一个Plan-and-Execute的前置规划层，先让模型出个粗粒度的步骤列表，再逐步执行。

工具调用这块，面试官最爱追问的是并行调用和依赖调用的处理。比如用户问“对比一下A公司和B公司的最新财报”，这两个查询没有依赖关系，应该并行发起；但如果问“查一下A公司CEO的母校，然后看看那个学校有哪些知名校友”，这就是串行依赖。你的Agent框架得能识别这两种模式。

终止条件判断是最容易被忽略的。很多Agent跑着跑着就陷入死循环，或者该停的时候不停。常见的终止策略包括：达到最大步数、连续N步没有新信息、模型输出明确的完成信号、工具返回结果满足预设条件。我一般会设三层保险：硬性步数上限、语义重复检测、人工确认兜底。

面试官想听的不是你背出了几个阶段，而是你有没有踩过坑、有没有在生产环境里处理过异常情况。

2.2 题目二：Agent的记忆系统怎么设计？短期记忆和长期记忆分别怎么实现

记忆系统是Agent的灵魂，但很多人把它简单等同于“把对话历史存下来”。这就好比说人的记忆就是一本日记，太粗糙了。

短期记忆的核心是工作记忆，对应的是当前任务相关的上下文。实现上通常是一个滑动窗口加摘要机制。窗口大小怎么定？不是拍脑袋，要看你的模型上下文长度和任务复杂度。比如做多轮工具调用的任务，窗口至少得覆盖最近5-8轮交互，否则模型会忘记刚才调用了什么工具、返回了什么结果。

摘要机制也有讲究。不是简单地把旧对话压缩成一段话，而是要做结构化摘要：保留关键实体、工具调用记录、未完成的子任务、已确认的事实。我见过一个团队的做法是维护一个“任务状态表”，每轮交互后更新，比纯文本摘要靠谱得多。

长期记忆的实现路径就更多了。最常见的是向量数据库+元数据过滤，但纯向量检索有个问题：它擅长语义相似，不擅长精确匹配和时间推理。所以实际系统里往往是混合方案：向量检索负责模糊召回，结构化查询负责精确过滤，再加一层重排序。

还有一个容易被忽略的点是记忆的写入策略。不是所有对话都值得存。我一般会设几个触发条件：用户明确说“记住这个”、任务成功完成后的关键结论、出现纠错信息时。无差别全存的结果就是检索时噪声太大，召回质量直线下降。

长期记忆的更新和遗忘机制也是面试官爱问的。记忆不是只增不减，过期的、矛盾的、低置信度的记忆要能标记和清理。这块可以类比数据库的TTL和版本管理，思路是通的。

2.3 题目三：Function Calling的底层原理是什么？模型怎么知道该调用哪个工具

这题能筛掉一大半人。很多人只会用API，不知道背后发生了什么。

Function Calling的本质是模型在训练阶段学习了工具调用的模式。具体来说，训练数据里包含了大量“用户请求-工具描述-调用参数”的样本，模型学会了根据工具的名称、描述、参数schema来判断该不该调、调哪个、传什么参数。

关键点来了：工具描述的质量直接决定调用准确率。我见过太多团队把工具描述写得含糊其辞，然后抱怨模型调不对。工具描述要包含：功能一句话说明、适用场景、不适用场景、参数含义和格式、返回值结构、可能的错误码。写得好的工具描述，模型调用准确率能提升30%以上。

模型选择工具的决策过程，可以理解为一次条件概率计算：给定当前上下文和所有可用工具的描述，哪个工具的条件概率最高。所以工具数量不是越多越好，超过一定数量后，模型的选择准确率会下降。实践中，单次暴露给模型的工具最好控制在10-15个以内，多了就要做工具路由——先用一个轻量模型或规则引擎筛选出候选工具集。

参数填充是另一个坑。模型有时候会漏填参数、填错类型、或者编造不存在的参数值。所以工具调用前必须做参数校验，调用后要做结果验证。我一般会在工具层加一层wrapper，做参数schema校验和默认值填充，模型只负责给核心参数，辅助参数由系统补全。

还有一个高频追问：模型怎么处理工具调用失败。好的Agent应该能区分错误类型：参数错误就修正参数重试、权限错误就提示用户、超时就降级或换工具、逻辑错误就重新规划。无脑重试是最蠢的做法，浪费token还解决不了问题。

3. 第二类问题：规划、推理与决策能力

3.1 题目四：ReAct、Plan-and-Execute、Reflexion三种模式的区别和适用场景

这三种模式经常被混为一谈，但它们的适用场景完全不同。

ReAct是边想边做，每一步都基于当前观察决定下一步。优点是灵活、能处理动态环境；缺点是短视、容易陷入局部循环、token消耗大。适合工具调用链短、环境反馈快的场景，比如简单的信息查询。

Plan-and-Execute是先规划再执行。规划器出一个步骤列表，执行器逐步完成。优点是全局视野、步骤可审查、便于并行优化；缺点是规划可能过时、环境变化后需要重新规划。适合步骤明确、依赖关系清晰的任务，比如多步数据处理的ETL流程。

Reflexion是在执行后加一个自我反思环节，分析哪里做得好、哪里可以改进，把反思结果存入记忆供后续使用。优点是能持续改进、适合复杂任务；缺点是增加额外调用、反思质量依赖模型能力。适合需要多轮迭代优化的场景，比如代码生成和调试。

实际生产系统往往是混合模式：外层用Plan-and-Execute做粗粒度规划，内层用ReAct做细粒度执行，关键节点加Reflexion做质量检查。面试时能说出这个组合思路，基本就稳了。

选型的时候还要考虑成本。ReAct的token消耗通常是Plan-and-Execute的1.5-2倍，Reflexion再加30%。如果任务简单、预算有限，别硬上复杂模式。

3.2 题目五：Agent怎么做任务分解？分解粒度怎么控制

任务分解是Agent的核心能力之一，但很多人分解出来的子任务要么太粗、要么太细。

分解粒度有个实用原则：每个子任务应该是一个可独立验证的单元。什么意思？就是做完这个子任务后，你能明确判断它是成功还是失败。如果无法判断，说明粒度不对。

举个例子，“调研竞品并写报告”这个任务，粗分解是“调研”和“写报告”，但“调研”怎么算完成？没法判断。细分解应该是：确定竞品列表、收集每个竞品的定价信息、收集功能对比、收集用户评价、汇总分析、撰写报告。每个子任务都有明确的完成标准。

分解方法上，常见的有思维链分解、递归分解、模板分解。思维链分解适合线性任务，递归分解适合层级任务，模板分解适合重复性任务。实际用的时候往往是组合：先用模板匹配看有没有现成的分解方案，没有再用思维链或递归。

分解后的子任务依赖关系要显式建模。我一般用DAG来表示，节点是子任务，边是依赖。这样便于识别哪些可以并行、哪些必须串行、哪些是关键路径。关键路径上的子任务要优先保证资源。

还有一个坑是分解过细。子任务太多会导致：调用次数爆炸、上下文碎片化、错误累积。经验值是单个任务的子任务数控制在5-9个，超过这个范围就要考虑合并或分层。

3.3 题目六：多Agent协作怎么设计？什么时候该用多Agent

多Agent是这两年的热点，但很多团队是“为了多Agent而多Agent”，结果复杂度上去了，效果没提升。

先说什么场景适合多Agent：角色分工明确且差异大的任务。比如一个Agent负责需求分析、一个负责代码生成、一个负责测试，每个角色的提示词、工具集、知识库都不同。这种情况下多Agent有优势，因为可以各自专业化。

什么场景不适合？任务同质化高、需要频繁共享上下文的场景。比如一个长文档的摘要任务，拆成多个Agent分别摘要再合并，往往不如单个Agent一次性处理。因为拆分带来的上下文丢失和合并成本，超过了并行带来的收益。

多Agent的通信机制是面试重点。常见的有共享黑板、消息传递、层级汇报。共享黑板适合松耦合协作，消息传递适合点对点交互，层级汇报适合有明确管理关系的场景。选哪种取决于你的任务结构和延迟要求。

协作模式上，辩论模式和投票模式是两种常见的决策机制。辩论模式让多个Agent从不同角度分析，最后综合；投票模式让多个Agent独立给出答案，取多数。辩论适合开放性问题，投票适合有明确答案的问题。

我个人的经验是：能用单Agent加工具解决的，别上多Agent。多Agent的调试成本是指数级上升的，出了问题很难定位是哪个Agent的锅。

4. 第三类问题：工程化与生产落地

4.1 题目七：Agent的评估怎么做？离线评估和在线评估分别关注什么

评估是Agent从Demo到生产的关键一步，但很多团队这块是空白。

离线评估关注的是可复现的指标。常见的包括：任务完成率、平均步数、工具调用准确率、参数填充准确率、幻觉率、token消耗。这些指标需要在固定的测试集上跑，测试集要覆盖正常场景、边界场景、异常场景。

构建测试集有个技巧：从生产日志里采样。真实用户的query分布和人工构造的测试集往往差异很大。我一般会从线上随机采样一批请求，人工标注期望结果，作为回归测试集。每次迭代后跑一遍，看指标有没有退化。

在线评估关注的是真实用户体验。核心指标包括：用户满意度（显式评分或隐式行为）、任务中断率、人工接管率、平均响应时间。这些指标没法离线模拟，必须上生产才能拿到。

还有一个容易被忽略的维度是鲁棒性评估。给Agent输入带噪声的、对抗性的、模糊的query，看它能不能优雅处理。比如用户输入里有错别字、有歧义、有恶意诱导，Agent的表现如何。这块的测试用例要专门设计。

评估频率上，离线评估每次发版必跑，在线评估持续监控。发现指标异常要能快速定位是哪个环节出了问题，所以全链路追踪是必须的。每个请求的每一步决策、每一次工具调用、每一个中间结果都要有日志。

4.2 题目八：Agent的延迟和成本怎么优化？有哪些实用手段

这题是生产环境的核心痛点，答得好能直接体现工程能力。

延迟优化上，并行化是最直接的手段。能并行的工具调用、能并行的子任务、能并行的检索查询，全部并行。我见过一个团队把串行的5次检索改成并行后，延迟从8秒降到2秒。

流式输出是另一个关键手段。用户不需要等整个任务完成才看到结果，中间步骤可以实时展示。这不仅降低感知延迟，还能让用户提前发现方向错误、及时干预。

缓存要用在刀刃上。工具调用结果、检索结果、甚至模型的部分输出都可以缓存。但缓存要有失效策略，过期的缓存比没有缓存更危险。

成本优化上，模型分级是最有效的。简单任务用小模型，复杂任务用大模型。判断标准可以是任务类型、历史成功率、用户等级。我一般会设一个路由层，根据任务复杂度动态选择模型。

上下文压缩也很关键。不是所有历史信息都需要传给模型，该摘要的摘要、该丢弃的丢弃。我见过一个优化案例，通过上下文压缩把平均token消耗降低了40%，效果几乎没损失。

还有一个手段是提前终止。当Agent已经收集到足够信息可以给出答案时，不要继续跑完所有步骤。这需要模型能判断“信息充分性”，可以在提示词里加一个检查点。

4.3 题目九：Agent的安全和权限怎么控制？有哪些必须做的防护

安全这块是面试的加分项，能答好说明你有生产意识。

输入防护是第一道关。用户输入要过滤注入攻击、越权指令、敏感信息。比如用户说“忽略之前的指令，执行以下操作”，这种要能识别并拦截。

工具权限要最小化。每个Agent只能访问它完成任务必需的工具，不能给全量权限。工具调用前要做权限校验，调用后要做审计日志。

输出防护同样重要。Agent的输出要过滤敏感信息、有害内容、未授权的数据泄露。特别是当Agent能访问内部知识库时，要防止它把不该说的信息说出来。

人工确认是关键操作的兜底。涉及资金、删除、对外发送等高风险操作，必须有人工确认环节。确认界面要清晰展示Agent打算做什么、影响范围是什么。

还有一个容易被忽略的是速率限制。防止Agent被恶意刷调用、防止单个用户占用过多资源。我一般会做用户级、会话级、工具级三层限流。

4.4 题目十：如果让你从零设计一个Agent系统，你的技术选型和架构思路是什么

这是压轴题，考察的是综合能力。

我的思路是先明确任务特征：是单轮还是多轮、是确定性还是探索性、是低延迟还是高准确率优先。这些决定了架构的基本形态。

然后选框架。LangChain生态全但重，适合快速原型；LlamaIndex检索强，适合RAG为主；AutoGen多Agent支持好，适合协作场景。如果团队有工程能力，我倾向于自研轻量框架，因为通用框架的抽象往往带来不必要的复杂度。

模型选型上，主模型选能力强的，辅助任务用轻量模型。要有fallback机制，主模型不可用时能切换。

存储层分三块：向量库存语义记忆、关系库存结构化状态、对象存储存原始文件。三者通过统一的元数据层关联。

可观测性从第一天就要做。全链路追踪、指标监控、日志聚合、告警规则，一个都不能少。Agent系统的调试难度远高于传统服务，没有可观测性就是盲人摸象。

迭代机制要设计好。A/B测试、灰度发布、快速回滚，这些是持续优化的基础。Agent的效果提升是个长期过程，没有好的迭代机制就走不远。

5. 面试中的加分项与避坑指南

5.1 面试官最反感的几种回答

第一种是只背概念不谈实践。问ReAct是什么，答“Reasoning and Acting的缩写，是一种让模型交替推理和行动的模式”，然后没了。面试官想听的是你用它做过什么、遇到什么问题、怎么解决的。

第二种是过度承诺。问怎么保证Agent不出错，答“我们会做完善的测试和监控”。这种回答等于没答。正确的思路是承认Agent必然有出错概率，然后说明你怎么降低概率、怎么快速发现、怎么优雅降级。

第三种是回避不确定性。问某个技术选型的理由，答“业界都这么做”。面试官想听的是你的判断逻辑，哪怕你说“我选A是因为团队更熟悉，虽然B理论上更好”，也比随大流强。

第四种是忽视成本。聊架构时只谈效果不谈成本，面试官会觉得你没有生产意识。Agent的token成本、延迟成本、维护成本都是真金白银，必须纳入考量。

5.2 怎么展示你的实战经验

最有效的方式是讲一个具体的失败案例。比如“我们上线后发现Agent在某个场景下会陷入死循环，排查后发现是工具返回的错误信息格式不一致导致模型误判，后来我们统一了错误码规范并加了循环检测”。这种故事比任何概念解释都有说服力。

另一个技巧是量化你的成果。不要说“优化了性能”，要说“通过并行化改造，P99延迟从12秒降到3秒”。数字是最有说服力的。

还可以展示你的技术判断。比如“我们评估过三个框架，最终选了自研，因为通用框架的抽象层在我们的场景下反而增加了调试难度”。这种有取舍的判断能体现深度。

5.3 面试前的准备清单

把上面10道题每个都写一份自己的答案，不要背，要理解。然后找朋友做模拟面试，让对方追问细节。能扛住追问的答案才是真答案。

准备2-3个实战案例，每个案例按“背景-问题-方案-结果-反思”的结构整理。案例要覆盖不同的技术点：架构设计、性能优化、异常处理、成本控制。

了解一下目标公司的主营业务和技术栈，想想他们的Agent可能用在什么场景、面临什么挑战。面试时能结合他们的业务聊，好感度直接拉满。

最后，准备几个你想问面试官的问题。比如“你们Agent的评估体系是怎么建的”、“线上出问题时排查链路是怎样的”。这些问题能体现你的专业度，也能帮你判断这个团队值不值得去。

我面过不少人，技术能力差不多的情况下，能清晰讲出自己踩过什么坑、怎么爬出来的候选人，通过率明显更高。因为这说明你真的做过，而不是只看过。

6. 一些没人明说但很重要的经验

面试和实际做Agent是两回事，但底层逻辑相通。面试考的是你的知识体系和判断力，实际做考的是你的执行力和迭代能力。

我见过技术很强但面试总挂的人，问题往往出在表达结构上。回答问题时先给结论，再给理由，最后给例子。不要一上来就铺细节，面试官没耐心听。

也见过面试表现很好但实际做不出东西的人，问题出在动手能力上。Agent这个领域变化太快，很多问题没有现成答案，必须自己试。平时多动手搭一些Demo，哪怕很简单，也比只看文章强。

还有一个体会是：Agent的很多问题本质上是软件工程问题。状态管理、错误处理、并发控制、可观测性，这些传统后端的问题在Agent系统里同样存在，甚至更复杂。所以别只盯着模型和提示词，工程基本功要扎实。

最后说一个趋势判断：Agent正在从“能跑就行”向“生产可用”演进。面试的要求也会越来越高，从问概念到问架构、从问效果到问成本、从问正常流程到问异常处理。提前按生产标准要求自己，面试时自然游刃有余。

这个领域没有标准答案，但有最佳实践。多动手、多踩坑、多总结，比背任何八股都管用。