大家好哇，最近忙着改毕业论文和准备春招面试，发现现在面试官张嘴闭嘴就是 AI Agent，连面纯 Java 后端岗都躲不掉 😅。前阵子看到二哥整理的一份 Agent 高频面试题，感觉挺系统的，就结合自己写多租户 AI 客服中台时的一些理解，整理成这篇笔记。纯粹是个人学习记录，如果有理解不到位的地方，欢迎评论区指正。

---

一、先搞清楚：Agent 到底是个啥？

说实话，一开始我也觉得 Agent 不就是给大模型套几个 API 调用吗？直到自己用 LangChain4j 搭了一个客服工单自动分类的 demo，才发现事情没那么简单。

一个完整的 Agent 通常拆成四块：

表格

模块	作用	类比
LLM	推理和决策，决定下一步干嘛	相当于 CPU
记忆（Memory）	短期记忆存对话上下文，长期记忆要外挂数据库	相当于内存 + 硬盘
工具集（Tools）	搜索、查数据库、调外部 API	相当于外设接口
执行器（Action Executor）	真正去调工具，把结果喂回给 LLM	相当于总线

这里有个面试常问的点：Agent 和传统的 LLM Chain 有什么区别？

我的理解是，Chain 是剧本，你提前写好了每一步：先调模型 A，再调模型 B，最后输出。流程是死的，中间出问题了它也不会停下来想想。

Agent 是即兴表演，每一步都是LLM根据当前状态重新决定的。比如用户问"帮我查一下最近 RAG 优化的论文"，Agent 会先想"我要搜一下"，搜完发现摘要太长，再决定"我要筛选三篇最相关的"，最后才输出。这个路径不是提前写死的，是实时推理出来的。

---

二、ReAct 模式（面试必考）

ReAct 应该是 Agent 面试里被问最多的了。我第一次被问到的时候，就背了句"Reasoning + Acting"，面试官明显不满意 😂。

后来自己画图理了一下，其实 ReAct 就是一个不断循环的三步走：

Thought（思考）→ Action（行动）→ Observation（观察）

具体来说：

1. Thought：LLM 内部推理，比如"用户问天气，我需要调天气查询工具，参数是北京"

2. Action：LLM 输出一个结构化调用，比如 JSON 格式的工具调用指令

3. Observation：系统执行完工具，把结果（比如"北京晴，26°C"）返回给 LLM

然后 LLM 拿着这个新信息，再进入下一轮 Thought，判断任务做完了没。没做完就继续循环，做完了就给最终答案。

关键点：这个循环的控制逻辑是外部程序负责的，不是 LLM 自己控制的。所以你在用 LangChain4j 或者自己写 Agent 框架的时候，怎么拼上下文、怎么判断循环终止，这些工程细节面试官很喜欢问。

---

三、Agent 记忆

做客服中台的时候，记忆这块踩过坑。用户聊了半天，刷新一下页面，Agent 就失忆了，体验很差。

Agent 的记忆分两层：

短期记忆：就是当前对话窗口里的内容，存在内存里。问题是会话结束就没了，而且上下文长度有限，不能无限堆。

长期记忆：必须持久化，常见的三种做法：

方案	原理	优缺点
向量数据库	历史对话向量化，查询时做相似度检索，把相关片段塞进 Prompt	最主流，灵活，但检索质量依赖 Embedding 和分块策略
结构化存储	用 MySQL/PostgreSQL 存用户偏好、历史工单	精确查询，但不适合语义模糊的场景
摘要压缩	对话长了之后，让 LLM 压缩成一段摘要	省 token，但会丢细节

我在项目里用的是 Qdrant + 摘要压缩 的混合方案：最近几轮对话保留原文，更早的历史压缩成摘要，同时把关键实体（比如用户提到的订单号、产品型号）抽出来存到结构化表里。这样既能保证上下文不爆炸，又能精准查到用户之前提过的具体信息。

---

四、Multi-Agent：什么时候需要多个 Agent？

单 Agent 搞不定的时候，就得考虑多 Agent 协作了。三种典型场景：

1. 上下文塞不下：复杂任务信息量太大，一个 LLM 的窗口装不下

2. 专业度不够：让一个 Agent 同时干代码审查、数据分析、文案撰写，效果肯定不如三个专精的

3. 串行太慢：很多子任务其实没依赖关系，完全可以并行跑

常见的协作模式有四种：

模式	特点	适用场景
流水线（Pipeline）	Agent A 的输出作为 Agent B 的输入，一环扣一环	有明确先后顺序，比如"爬取 → 解析 → 总结 → 推送"
主从（Orchestrator-Workers）	一个指挥官拆解任务，分给多个执行者并行处理	复杂任务，目前最主流，LangGraph 里很常见
并行（Parallel）	多个 Agent 同时处理不同子任务，最后汇总	无依赖关系的并发任务
辩论（Debate）	多个 Agent 从不同角度回答，最后综合或裁判决策	需要多视角验证，降低幻觉风险

面试的时候如果让你设计一个多 Agent 系统，建议优先提 主从模式，因为最实用，也最好讲清楚任务拆解和结果汇总的逻辑。

---

五、工作流 vs 智能体：工程里怎么选？

这个点我在面一家做 SaaS 的公司时被问到过，当时答得有点啰嗦。现在我的理解是：

• 工作流：流程是开发者提前写死的，LLM 只在固定节点做决策。好处是可控、稳定、出了问题好排查。缺点是遇到预设之外的情况直接抓瞎。

• 智能体：给目标后自己规划路径、调工具。好处是灵活，能处理开放式任务。缺点是推理路径不透明，token 成本高，延迟也不稳定。

选型原则：任务边界清晰、步骤能枚举 → 工作流；任务开放、需要大量动态判断 → 智能体。

但实际项目里很少二选一，更多是混合架构。比如我们的客服中台，外层是固定工作流（接收问题 → 分类 → 查知识库 → 回复），但"查知识库"这一步内部用 Agent 自己决定检索策略，是用关键词匹配还是向量检索，要不要调 rerank。

---

六、多 Agent 的坑

如果面试问到 Multi-Agent 的难点，可以提这两个：

无限循环：Agent A 等 Agent B，Agent B 等 Agent A，或者某个子任务永远解不完。防护手段就三样：最大步数限制、状态哈希检测（发现重复状态就中断）、超时熔断。

通信冗余：多个 Agent 同时汇报类似结果，或者中间过程产生大量无意义消息，把指挥官淹没了。解决办法是消息协议规范化（带上 Agent ID、任务 ID、消息类型），指挥官只处理"最终结果"，中间状态过滤掉，再加个消息去重队列。

---

七、写在最后

整理完这些，最大的感受是 Agent 这个领域虽然概念多，但落到工程上还是有套路的。ReAct、记忆设计、多 Agent 协作模式，这些都不是纯理论，而是能直接对应到代码里的东西。

我目前还在啃 LangGraph 和 MCP 协议，后面如果有新的理解再继续更新。如果你也在准备 Java + AI 方向的面试，或者在做类似的多租户智能客服项目，欢迎一起交流，互相避坑 🙌

最近改论文改到怀疑人生，希望春招能有个好结果吧，共勉。