Q1：如果让你设计一个 Agent 的规划器，怎么避免它每一步都重新规划，导致路径震荡？#

规划器不能每拿到一个 observation 就整体重算，不然很容易出现前一步刚决定检索，后一步又改成思考，再下一步又回去检索，整个执行路径会来回抖动。

更稳的做法是把规划分成**“全局计划”和”局部调整”**两层。全局计划只定义阶段目标，比如信息收集、证据校验、结果生成；局部调整只允许在当前阶段内微调具体动作。

另外要给 planner 一个明确的状态表示，比如当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束，模型会把每次新 observation 当成全新任务来理解。

线上一般还会加**“重规划阈值”**，只有在关键前提失效、连续失败或者用户目标变化时才允许重规划，这样路径会稳定很多。

Q2：如果一个 Agent 需要同时查知识库、调外部 API、再结合用户历史偏好回答，你怎么处理这三类上下文的优先级？#

这三类信息不能混着塞，要先定义优先级。通常系统规则最高，接下来是当前轮用户明确输入，再往下是外部工具返回和知识库证据，用户历史偏好通常最低。因为偏好只能影响表达方式或默认选择，不能覆盖当前轮事实。

比如用户历史里一直偏好 Python，但这轮明确说”用 Java 给我写”，那当前轮约束一定优先。

这几类上下文不能一股脑全塞进 prompt，要有分层拼接策略，每层标注来源和可信度。工具返回的结果也要做可信度排序，因为有些工具返回的是参考值，有些是精确计算。拼的时候系统约束放最前面，用户输入紧随其后，工具和知识库结果按相关性排，偏好信息放最后，作为 soft hint。

Q3：如何评估一个 Agent 的好坏？#

不能只看最终答案对不对，还要看过程。通常会从这几个维度评估：

• 任务完成率：有没有达到目标
• 步骤效率：花了多少步、有没有走弯路
• 工具调用准确率：选对工具、参数填对、返回结果正确使用
• 幻觉率：有没有编造不存在的信息或工具
• 用户满意度：用户愿不愿意继续用

评估方式分离线和在线两种：

• 离线：用 benchmark 数据集跑回归测试
• 在线：看真实用户留存、反馈和复用率

很多团队只关注离线指标，但上线后真正有用的是在线指标，因为离线数据很难覆盖边界情况和长尾场景。线上还要看异常恢复率（出了错能不能自己修回来）和人类介入率（有多少任务需要人接管），这两个指标直接反映了 Agent 的工程成熟度。

Q4：Agent 里的 Memory 机制怎么设计？#

Agent 的记忆分三层：

设计时要考虑三个核心问题：

1. 写入时机：不是所有信息都值得存，要做重要性打分和去重
2. 检索方式：相关性和时效性要兼顾
3. 遗忘策略：不然记忆库越来越大、越来越杂，检索精度反而下降

Q5：Function Calling 和 Tool Use 有什么区别？#

Function Calling 是模型侧的能力：模型在生成过程中决定要调用哪个函数、传什么参数，然后把调用意图以结构化格式输出。

Tool Use 是更广义的概念，包括 Function Calling 以及外部工具的注册、发现、调度、执行和结果回传。在实际工程里，Function Calling 只是 Tool Use 链路中的一环。

完整链路还包括：

• 工具注册：告诉模型有哪些工具、每个工具的 schema
• 工具选择：有几十个工具时怎么快速筛选候选
• 参数校验：模型填的参数可能不合法
• 执行隔离：工具执行可能出错、超时、返回异常
• 结果处理：工具返回的原始数据怎么注入回上下文

很多初学者只关注模型怎么输出 function call，忽略了前后两端的工程细节。

Q6：怎么处理 Agent 执行过程中的异常和错误？#

常见异常分四类：工具调用失败（网络超时、服务不可用、参数错误）、模型输出异常（幻觉、格式错误、输出截断）、状态不一致（上下文过长、记忆冲突）、业务逻辑异常（用户目标变更、权限不足）。

处理策略分三层：

每层都要记录详细的错误日志和上下文快照，方便后续排查。线上 Agent 一定要有熔断机制，当某个工具连续失败率超过阈值时自动熔断，避免无效调用浪费资源和时间。

Q7：你怎么理解 Agent 的 Planning 能力？#

Planning 不是简单让模型列个 to-do list，而是让模型根据当前状态和目标动态决定下一步做什么。

常见 Planning 范式：

实际工程里通常混合使用。Planning 的难点不在于生成计划，而在于：

• 如何判断计划是否偏离
• 何时需要重新规划
• 如何避免重复失败的路径

Q8：Multi-Agent 系统怎么设计？#

核心是分工、协调和仲裁：

• 分工：明确每个 Agent 的职责边界和能力范围，避免职责重叠
• 协调：统一的消息协议和状态同步机制
• 仲裁：多个 Agent 给出不同结果时，由谁决定最终输出

常见架构模式：

Q9：如何优化 Agent 的响应延迟？#

延迟优化要分阶段看：模型推理、工具调用、网络传输、上下文组装。

整体思路：能并行的并行、能缓存的缓存、能裁剪的裁剪、能预计算的预计算。

Q10：RAG 系统常见的问题和优化方案？#

核心问题三类：检索不准、上下文不够、生成质量差。

优化方案：

• 分块策略优化：按语义分块而不是固定长度
• 多路检索：向量检索 + 关键词检索 + 混合检索
• 重排序：用 reranker 对候选结果二次排序
• 上下文压缩：只保留和问题最相关的部分
• 查询改写：把用户问题改写成更适合检索的形式
• 反馈循环：根据用户满意度反向调整检索策略

Q11：如果让你做一个”可审计”的 Agent，你会保留哪些信息？#

可审计不是简单把聊天记录存下来，而是要能还原**“它为什么这样做”**。

至少要保留：

• 用户输入
• 系统 prompt 版本
• 工具候选集
• 最终工具选择
• 调用参数、工具返回
• 状态变迁
• 模型输出和最终结果

更完整的还要带上：模型版本、知识库版本、检索到的文档 ID、rerank 结果、trace_id。

线上出了问题，才能准确回放是 prompt 变了、知识库变了、模型变了，还是工具变了。真正的审计目标不是”存档”，而是**“能追责、能定因、能复现”**。

Q12：为什么很多 Agent Demo 很惊艳，但一上线就不稳定？#

因为 Demo 是在理想输入、有限工具、单次任务和短上下文下演示的，模型只要看起来会做事就行。但线上环境完全不一样——输入脏、任务长、工具多、状态复杂、异常频繁，还要考虑权限、安全、性能和成本。

Demo 能跑通，只能说明**“这个方向有可能”；上线稳定，说明的是你把模型的不确定性关进了工程笼子里**。

真正难的是做治理，不是做演示。很多团队一开始总怪模型不够强，后来才发现大量问题其实来自：状态管理、工具设计、上下文污染和缺少回放能力。

Q13：你觉得二面和一面在 AI Agent 方向上最大的区别是什么？#

一面很多时候还会看你知不知道概念，比如 RAG、Tool Calling、Memory、Multi-Agent 这些名词你能不能说清。

二面通常就不满足于名词解释了，更想知道你能不能把这些东西真正落到系统里。会追着问边界条件、失败案例、线上治理和设计取舍。不是问你”会不会”，而是问你**“为什么不这么做，不这么做会出什么问题”**。

如果你答的时候一直停留在定义层面，二面一般很容易被看出来。