企业官网建设流程全解析

1. 为什么 Agent 工程师的面试突然变难了

1.1 从“会调 API”到“会设计系统”的分水岭

2024 年的时候，你只要能在简历上写一句“熟悉 LangChain，做过 RAG 问答”，面试官基本就不会为难你。到了 2025 年下半年，情况完全变了。我身边好几个团队在招 Agent 方向的人，面试通过率从之前的 30% 左右直接掉到了个位数。不是候选人变少了，而是面试官的问法变了。

以前问的是“你用过哪些框架”，现在问的是“你的 Agent 在工具调用失败第三次的时候，状态机是怎么回滚的”。以前问的是“Prompt 怎么写”，现在问的是“你怎么量化一个 Agent 的决策质量，用什么指标做回归测试”。这个转变的本质是：行业对 Agent 工程师的定义，从“会调 API 的应用层开发者”升级成了“能设计可靠自治系统的工程师”。

我参与过几轮团队内部的面试出题，也和几个做 Agent 产品的朋友聊过他们的考察标准。大家有一个共识：一个合格的 Agent 工程师，必须同时具备三个层面的能力——对 LLM 能力边界的清醒认知、对分布式系统设计原则的扎实掌握、对业务场景中不确定性的工程化处理能力。这三样缺一个，在实际项目中就会出问题。

1.2 这 10 道题到底在考什么

标题里说的“10 道面试题”，并不是网上那种背八股就能过的题库。我梳理了一下当前一线团队最常问的方向，大致可以归为四类：Agent 架构设计类、工具调用与编排类、记忆与状态管理类、评估与可观测性类。每一类下面都有若干变体，但核心考察点就那么几个。

这篇文章我会把这 10 道题逐一拆开，不是给你标准答案让你去背，而是告诉你每道题背后面试官真正想听什么、你应该从哪个角度去组织回答、以及在实际项目中有哪些坑是你必须知道的。如果你正在准备 Agent 方向的面试，或者团队里要招这样的人，这篇内容应该能帮你省不少时间。

注意：下面涉及的代码示例和架构方案，都是基于当前主流开源生态的常见实践，具体选型要根据你的业务场景和团队技术栈来定，不要照搬。

2. 第一类：Agent 架构设计能力

2.1 题目一：请设计一个能处理多步推理任务的 Agent 架构

这道题几乎是必问的，区别只在于面试官会给你什么场景。可能是“帮我订一张从 A 到 B 的机票，中间要转机，且需要符合公司差旅标准”，也可能是“分析这份财报，找出三个异常指标并给出可能原因”。场景不同，但考察的核心是一样的：你能否把一个模糊的用户意图拆解成可执行的步骤序列，并且设计好每一步之间的状态传递和错误处理。

面试官想听到的关键词包括：任务分解、状态机、工具选择策略、失败重试机制、人工介入点。如果你只回答“用 ReAct 模式循环调用工具直到完成”，那基本就挂了。因为 ReAct 只是最基础的循环，它解决不了长链路任务中的状态丢失、工具选择错误累积、以及无限循环的问题。

我在实际项目中用过的一种方案是分层架构：最上层是一个 Planner，负责把用户意图拆成 DAG（有向无环图）形式的子任务；中间层是 Executor，负责按拓扑顺序执行每个子任务，并维护一个全局的 State Store；最下层是 Tool Layer，每个工具都有明确的输入输出 schema 和失败语义。Planner 和 Executor 之间通过一个结构化的任务描述协议通信，而不是靠自然语言传递。

这样做的好处是，当某个子任务失败时，Executor 可以根据失败类型决定是重试、跳过还是回滚到上一个稳定状态，而不是让整个 Agent 从头再来。另外，DAG 结构天然支持并行执行没有依赖关系的子任务，对于 I/O 密集型的工具调用场景，整体延迟能降低不少。

实操心得：Planner 的输出一定要做 schema 校验。我见过太多项目因为 Planner 返回了一个格式不对的 JSON，导致整个执行链路崩溃。用 Pydantic 或者 JSON Schema 做一层强校验，成本很低，收益很大。

2.2 题目二：Agent 的循环终止条件你怎么设计

这道题看起来简单，但能答好的人不多。大部分人的第一反应是“设置最大迭代次数”，比如 10 次或者 20 次。这个答案只能拿 30 分。面试官接着会问：如果任务确实需要 15 步，你设 10 次就断了怎么办？如果任务 3 步就能完成，但 Agent 一直在做无意义的工具调用，你怎么让它提前停？

一个完整的终止条件设计应该包含至少四个维度。第一是硬性上限，防止无限循环，这个必须有，但具体数值要根据任务复杂度动态调整，而不是写死。第二是目标达成检测，Agent 需要有一个机制来判断当前状态是否已经满足用户意图，这个判断可以是一个轻量级的分类模型，也可以是一组规则。第三是收益递减检测，如果连续 N 步的工具调用没有带来任何新信息，就应该触发终止。第四是异常终止，当工具连续失败或者状态出现不一致时，要能安全退出并给出有意义的错误信息。

我在一个客服工单处理 Agent 里用过这样的组合策略：硬性上限设为 12 步，目标达成检测用一个微调过的小模型做二分类，收益递减检测看的是连续三步的工具返回结果相似度是否超过阈值。实测下来，平均任务完成步数从原来的 9.3 步降到了 6.1 步，无效工具调用减少了大约 40%。

2.3 题目三：多 Agent 协作和单 Agent 多工具，你怎么选

这个问题没有标准答案，但面试官想看你有没有清晰的判断逻辑。我的经验是，选择依据主要看三个因素：任务是否可并行、子任务之间是否需要频繁通信、以及团队对系统复杂度的容忍度。

多 Agent 协作适合那种子任务边界清晰、彼此独立性强的场景。比如一个内容生产流水线，研究 Agent 负责搜集资料，写作 Agent 负责生成初稿，审核 Agent 负责事实核查，三者之间只需要通过结构化的中间产物传递信息，不需要频繁对话。这种场景下，多 Agent 的好处是每个 Agent 的 Prompt 可以更专注，工具集可以更精简，整体可靠性反而更高。

但如果子任务之间需要大量来回沟通，比如一个需要反复讨论才能达成共识的决策场景，多 Agent 的通信开销就会成为瓶颈。每次 Agent 之间的消息传递都是一次 LLM 调用，成本高、延迟大，而且容易出现信息在传递过程中失真的问题。这种情况下，单 Agent 配合多个工具，用一个统一的上下文来管理状态，反而更高效。

注意：多 Agent 系统的一个常见坑是“责任扩散”。当多个 Agent 都可以处理某个子任务时，容易出现互相推诿或者重复劳动。解决办法是在编排层明确每个 Agent 的职责边界，并且用一个中央协调器来分配任务，而不是让 Agent 之间自由协商。

3. 第二类：工具调用与编排的细节考察

3.1 题目四：工具调用的参数校验和错误处理你怎么做

这道题是区分“写过 Demo”和“上过生产”的分水岭。Demo 级别的代码通常是这样的：LLM 返回一个工具调用请求，直接解析 JSON，然后调用对应的函数，如果报错就返回错误信息给 LLM 让它重试。生产级别的做法要复杂得多。

首先，参数校验必须在调用工具之前完成。LLM 生成的参数经常会出现类型错误、缺少必填字段、或者值超出合理范围的情况。我通常会用两层校验：第一层是 JSON Schema 校验，确保结构正确；第二层是业务规则校验，比如日期不能是过去的时间、金额不能为负数等。校验失败时，不是简单地把错误扔回给 LLM，而是要把具体的校验失败原因和期望的格式一起返回，这样 LLM 才能有针对性地修正。

其次，错误处理要区分可重试错误和不可重试错误。网络超时、服务暂时不可用属于可重试错误，可以用指数退避策略重试两到三次。参数错误、权限不足属于不可重试错误，应该直接返回给 LLM 让它调整策略，而不是浪费重试次数。还有一种情况是工具返回了成功状态但结果不符合预期，这种“静默失败”最难处理，需要在工具层加一层结果合理性检查。

# 工具调用参数校验的简化示例 from pydantic import BaseModel, ValidationError, field_validator class FlightSearchParams(BaseModel): origin: str destination: str departure_date: str @field_validator('departure_date') def date_not_in_past(cls, v): from datetime import datetime if datetime.strptime(v, '%Y-%m-%d') < datetime.now(): raise ValueError('出发日期不能是过去的时间') return v def validate_and_call(tool_name, raw_params): try: params = FlightSearchParams(**raw_params) except ValidationError as e: return { 'status': 'validation_error', 'errors': e.errors(), 'hint': '请检查参数格式，日期格式为 YYYY-MM-DD' } # 继续调用实际工具...

3.2 题目五：你怎么防止 Agent 调用危险工具

这个问题在涉及真实业务系统的场景中特别重要。面试官想看你有没有安全意识，以及知不知道怎么在架构层面做防护，而不是靠 Prompt 里写一句“不要执行危险操作”就完事了。

我的做法是三层防护。第一层是工具分级，把所有工具分为只读、写入、危险三个级别。只读工具可以自由调用，写入工具需要确认，危险工具（比如删除数据、发送邮件、执行支付）必须经过人工审批或者二次验证。第二层是参数白名单，对于写入类工具，限制参数的取值范围，比如文件路径必须在指定目录下、SQL 只能执行 SELECT 和 INSERT 不能执行 DROP。第三层是调用频率限制，防止 Agent 在异常状态下疯狂调用某个工具。

实操心得：我见过一个项目因为 Agent 误调用了发送邮件的工具，给全公司发了一封测试邮件。后来他们在工具层加了一个“干运行”模式，所有写入操作先模拟执行并记录日志，确认无误后再真正执行。这个模式在开发和测试阶段特别有用。

3.3 题目六：工具数量多了之后，怎么让 Agent 选对工具

当工具数量超过 20 个的时候，把所有工具的 description 塞进 Prompt 里会导致两个问题：一是 token 消耗大，二是 LLM 的选择准确率会下降。我实测过，工具数量从 10 个增加到 30 个时，选择准确率从 92% 掉到了 78% 左右。

解决办法是分层路由。先用一个轻量级的分类器或者关键词匹配，把用户意图路由到某个工具类别，然后只把该类别的工具描述传给 LLM。比如用户说“帮我查一下明天的天气”，先路由到“信息查询”类别，然后只传天气相关的工具。这样每次 LLM 看到的工具数量控制在 5 到 8 个，选择准确率能回到 90% 以上。

另一个技巧是给工具描述加上“使用场景”和“不适用场景”。比如一个搜索工具的描述里写“适用于需要最新信息的查询，不适用于查询历史订单”，这样 LLM 在边界情况下更容易做出正确选择。

4. 第三类：记忆与状态管理的深水区

4.1 题目七：长对话中 Agent 的记忆怎么管理

这道题考察的是你对上下文窗口限制的理解和应对策略。很多人会回答“用向量数据库做 RAG”，但这只是记忆管理的一种手段，而且不是所有场景都适用。

一个完整的记忆管理方案应该包含短期记忆、长期记忆和工作记忆三个层次。短期记忆就是当前对话的最近几轮交互，直接放在上下文里。长期记忆是跨会话需要保留的信息，比如用户偏好、历史订单等，通常存在外部数据库里，需要时检索出来。工作记忆是当前任务执行过程中的中间状态，比如已经完成了哪些步骤、当前正在处理哪个子任务，这个通常用一个结构化的 State 对象来维护。

关键难点在于：什么时候把短期记忆写入长期记忆、什么时候从长期记忆检索、以及检索出来的信息怎么和当前上下文融合。我的经验是，写入时机应该由事件驱动，比如用户明确说“记住我喜欢靠窗座位”时触发写入。检索时机应该由任务驱动，当 Agent 判断当前任务需要历史信息时主动检索。融合的时候要注意去重和冲突处理，如果检索到的历史信息和当前对话矛盾，要以当前对话为准。

4.2 题目八：多轮对话中状态丢失怎么排查

这是一个实操性很强的问题，面试官通常会给一个具体的 bug 场景让你分析。比如“用户在第一轮说了要订下周三的机票，第三轮 Agent 却问用户要订哪天的票”。这种问题的根因通常有几个：状态存储的 key 设计不合理导致覆盖、上下文截断时把关键信息截掉了、或者多个 Agent 之间的状态没有同步。

排查思路是从状态的生命周期入手。先确认状态是在哪一步写入的，写入的内容是什么，然后在后续每一步检查状态是否被正确读取。我通常会在开发阶段加一个状态快照的日志，每次状态变更都记录变更前后的 diff，这样出问题时能快速定位到是哪一步把状态弄丢了。

注意：上下文截断是状态丢失的高发区。很多框架默认从最早的消息开始截断，但最早的消息往往包含用户最初的需求描述。更好的做法是保留第一条 system message 和第一条 user message，从中间开始截断。

5. 第四类：评估、可观测性与成本控制

5.1 题目九：你怎么评估一个 Agent 的好坏

这道题是高级岗位的必问题。初级工程师会说“看任务完成率”，高级工程师会从多个维度来回答。我通常会把评估分为四个层面：任务成功率、效率指标、成本指标、以及安全性指标。

任务成功率不能只看最终结果，还要看中间步骤的正确性。比如一个订票 Agent 最终订到了票，但中间查错了日期又改回来，这种虽然成功了但体验很差。效率指标包括平均完成步数、平均延迟、工具调用次数等。成本指标主要是 token 消耗和 API 调用费用。安全性指标包括危险操作拦截率、敏感信息泄露检测等。

评估方法上，我建议至少要有离线评估和在线监控两套。离线评估用标注好的测试集，每次 Prompt 或模型变更后跑一遍回归。在线监控用真实流量，关注异常率和用户反馈。两者结合才能全面反映 Agent 的表现。

5.2 题目十：Agent 的 token 成本怎么优化

这道题非常务实，因为很多团队在 PoC 阶段跑得很好，一上量就发现成本扛不住。优化手段我按投入产出比排序，从高到低分别是：Prompt 压缩、缓存、模型分级、以及输出长度控制。

Prompt 压缩是最直接的，把工具描述、系统指令、few-shot 示例都精简一遍，通常能省 30% 到 50% 的 token。缓存包括两部分：一是 LLM 响应的缓存，对于相同或相似的输入直接返回缓存结果；二是工具调用结果的缓存，比如天气查询结果在 10 分钟内可以复用。模型分级是指简单任务用小模型，复杂任务才用大模型，这个需要有一个可靠的任务复杂度判断逻辑。输出长度控制是在 Prompt 里明确要求 LLM 简洁回答，并且设置 max_tokens 上限。

我在一个项目里综合用了这四种手段，单次任务的平均成本从 0.12 元降到了 0.04 元，降幅超过 60%。其中贡献最大的是 Prompt 压缩和缓存，分别贡献了约 25% 和 20% 的降幅。

6. 面试之外的实战建议

6.1 怎么准备才能真的答上来

如果你只是背题，面试官稍微换个场景你就露馅了。我的建议是，至少动手做一个完整的 Agent 项目，从需求分析到上线监控全流程走一遍。不需要多复杂，一个能处理真实任务的客服 Agent 或者数据分析 Agent 就够了。关键是在做的过程中，你会遇到各种真实的问题：工具调用超时怎么办、LLM 返回格式不对怎么办、用户输入模糊怎么办。这些问题解决一遍，面试时就有真实的经验可以讲。

另外，多看看开源项目的 issue 区和讨论区。很多你没想到的边界情况，别人已经踩过坑了。比如 LangChain 和 AutoGen 的 GitHub issue 里，有大量关于状态管理、错误处理、成本控制的讨论，这些都是很好的学习材料。

6.2 面试中展示思考过程比给答案更重要

我面过不少人，发现一个规律：那些能拿到高评价的候选人，往往不是第一个给出答案的人，而是能把思考过程讲清楚的人。面试官问“你怎么设计终止条件”，你如果直接说“设最大迭代次数”，那就结束了。但如果你说“我会从四个维度来考虑，首先是硬性上限，因为...其次是目标达成检测，因为...”，即使某个维度答得不够好，整体评价也不会低。

因为 Agent 这个领域本身就没有标准答案，面试官更看重的是你的分析框架和权衡逻辑。你能说清楚为什么选 A 不选 B，比你知道 A 是什么更重要。

6.3 这个方向后续还可以这样扩展

Agent 工程师的能力模型还在快速演进。我观察到几个值得关注的方向：一是 Agent 的安全和对齐，随着 Agent 开始操作真实系统，怎么保证它不做坏事会越来越重要；二是多模态 Agent，不只是文本，还要能处理图像、音频、视频；三是 Agent 的自我进化，怎么让 Agent 从失败中学习并自动优化策略。这些方向目前都还没有成熟的方案，但已经在一些前沿团队里开始探索了。

如果你现在正在准备面试，我的建议是先把上面这 10 道题涉及的基础能力打扎实，然后在某一个方向上深入下去。面试官通常会对有深度思考的候选人更感兴趣，哪怕你的深度只体现在一个小点上。