Agent面试题总结

Agent 基础

AI Agent 是什么？和普通 Chatbot 有什么区别？

一句话：Agent 是一套能够感知环境、理解任务、自主规划、能调用一定外部工具最终完成任务的一套系统。

区别：普通的 ChatBot 围绕 “对话”，其中只有 LLM 一个环节，即 用户输入 -> LLM处理 -> LLM直接输出；而 Agent 则是 用户输入 -> LLM理解任务 -> LLM规划任务 -> 调用工具 -> 完成执行 的复杂流程，LLM 的输出不会直接一次性展示给用户，而是用于完成任务，这就是两者的核心区别：前者至少为了生成内容，后者则是完成任务。

细分维度：可以从以下维度对比：核心目标、行为模式（文本生成 vs 理解+决策+执行）、工具调用、自主性、记忆、任务复杂度、环境感知、反馈闭环。

更深：Agent 的核心组成？下一道题

Agent = LLM + Planning + Memory + Tools + Enviorment + Action Loop 这条公式怎么理解？

一句话：即目前 Agent 的主流架构。

细分：1.LLM 是 Agent 的大脑、核心；2.Planning 负责 Agent 对于任务的理解和拆解能力；3.Memory 赋予 Agent 记忆能力，让其对当前以及之前的任务有了清晰的认知；4.Tool 赋予 Agent 与外部直接交互的能力；5.Enviorment 赋予了 Agent 对外部的感知（例如能够通过 Tool:read 了解工作区的文件系统、edge 浏览器当前网页状态等）；6.Action Loop 则是当前 Agent 特别聚焦的一个能力，其赋予 Agent 通过当前和以前的任务决定下一步任务的能力。

Agent Loop 的完整流程是什么？

一句话：LLM 解读上下文 -> LLM 理解、规划当前任务 -> LLM 调用工具 -> LLM 获得工具结果 -> 观察环境判断是否完成任务从而决定结束任务还是自我调用继续迭代

Agent 和传统编程、Workflow 的核心区别是什么？

一句话：传统编程完全由人类智慧进行决策、执行；Workflow 则是人类给出方向、或是有向无环图固定节点流程，照着执行就行；而 Agent 则是将决策与执行闭环完全交给 LLM。

ReAct、Plan-and-Execute、Reflection、Multi-Agent 分别适合什么场景？

一句话：1.ReAct 适用于流程不固定的任务，例如 Coding、纠错等；2.Plan-and-Execute 适用于长程任务，因为可以预先设想到一条宏观路线；3.Reflection 适用于对结果质量要求高、或者是执行易出错的任务；4.Multi-Agent 适用于任务可拆分成独立不耦合的子任务，或者有若干个领域不同、硬性要求不同的任务。

优缺点：1.ReAct：可动态调整路线-只能串行执行；2.Plan-and-Execute：事先计划利于宏观把握任务-plan 本身质量不可信；3.Reflection：轻量级可无感集成进其他模式-容易陷入反思滑坡而刻意谄媚；4.Multi-Agent：适合多任务并行场景- Agent 通信问题（A2A协议解决） & Agent 之间结论易互相冲突

Tools 注册时，工具 description 为什么很关键？

一句话：description 告诉 LLM 什么时候应该调用这个工具，如果只提供 ToolName， LLM 很容易忽略该工具最终无法完成任务。

description应该写得清楚：正因为 description 是告诉 LLM 什么时候调用工具的自然语言描述性文本，所以才需要能让 LLM 简单理解。例如 搜索公开互联网信息，适用于新闻、网页、实时资料查询。不要用于搜索公司内部信息，而不是 这是一个可以帮助你进行搜索的搜索工具，它支持互联网搜索，可以搜索很多不同类型的信息，当你想获得信息的时候可能可以考虑使用它……。事实上，实际上最会写 skill 的 matt 就是这么干的，teach skill 的 description：Teach the user a new skill or concept, within this workspace.很清晰明了。

什么时候用纯 Agent，什么时候用 Workflow 或 Agentic Workflow？

一句话：Workflow 适合于有固定严格流程的任务（其实就是绝大多数前 AI 时代的业务）；Agent 适用于无法预先设想工作流程，需要按照任务推进状态动态调整任务方向；Agentic Workflow 则是将前面二者结合，适合整体流程可以大致确定，但其中节点的具体实现可以由 Agent 自行决定。

使用的本质原则：能写死就别用 LLM，是为了安全和性能考量。

Multi-Agent 协作的主要问题是什么？为什么生产里不能盲目上多 Agent？

一句话：主要问题在于 Agent 之间的协作难以量化、可控，很容易出现问题，在生产环境中绝大多数任务其实都能用固定 Workflow 和单一 Agent 完成，多 Agent 不仅不能起到正面作用，反而带来一系列问题。

带来的问题：1.通信成本，具体来说硬件性能、时间成本、token 花销都会加剧；2.状态同步问题，多 Agent 本质上就是并行任务，此时就必须考虑到同步和一致性问题（虽然说可以采用一主多从 Agent，由主 Agent 统一分配任务、接收结果）；3.任务不容易拆分，子任务之间需要非耦合可独立并行，一个大的复杂任务恰好不容易拆分。

Memory

Agent 的短期记忆和长期记忆有什么区别？

一句话：短期记忆解决 当前任务状态，长期记忆则解决 跨会话、跨任务的信息共享。也就是说，前者满足当前需求，后者满足今后需求。

长期记忆&短期记忆：短期记忆就是工作记忆，存储当前会话任务、上下文、每个 Message、工具结果、任务状态等；长期记忆就是情景记忆和语义记忆，情景记忆存储 某某会话的重要信息，目的是让 Agent 能够回忆起那次会话，语义记忆存储的是所有会话通用的知识，例如用户偏好、项目组件版本号、项目架构等。

Agent 记忆系统要解决哪些核心问题？

一句话：要解决哪些记忆需要记录、检索、遗忘、更新，以支援严格的上下文。

问题：

  1. 哪些记忆需要记？需要 LLM 有效筛选，很大程度取决于 LLM 自身的能力。

  2. 怎么检索？这个问题取决于记忆如何存储，可以原始自然语言存储、也可以转为 JSONL 存储、也可以采用向量化存储等，但是不同的存储方式会极大影响记忆的召回率。

  3. 何时触发检索？

  4. 记忆冲突怎么办？

  5. 什么时候遗忘？

  6. 记忆有错误怎么办？

  7. 记忆该如何组织进上下文？

  8. 性能问题。

向量记忆和 Markdown 记忆分别适合什么场景？

一句话：向量记忆适合信息量大、语义检索需求强、需要根据上下文找“相关内容”的场景（例如大量书籍文本向量化存储）；Markdown 适合规模较小、结构清晰、需要在长期维护不断读写的场景（例如 docs.md 等 Agent 自己维护的 md 文件）

向量化：由 Embedding 模型处理后，语义越近的文本在高维映射的向量中的距离越近，这是向量检索的理论性来源，所以使用数学运算就能检索到语义上和被搜索文本相近的文本。

Auto Memory 是什么？它为什么不能无限自动写入？

一句话：Auto Memory 指的是 Agent 在工作过程中识别有价值的记忆并将其持久化的机制；它不能无限写入是因为记忆一旦过多会产生诸如记忆冲突、错误记忆、召回率降低、性能花销增大等问题。

Memory Policy：Agent 用于评判一个记忆是否 “有价值” 的标准，其核心即：是否对未来的任务有帮助？

哪些团队共享记忆适合走 Git 和 Code Review，哪些更适合数据库？

一句话：结构清晰稳定、需要人工审查的知识适合走 git（例如 Agent 随时维护的 md 文件）；而软件过程中产生的高频 io 的记忆（比如某用户的偏好、某次会话的上下文、Trace 等），则使用数据库显然更合适。

git的限制：git 确实可以很轻松地管理不同的 diff，但是没法处理高并发的信息 io，倘若将高频变化的信息用 git 存储，无法随时即写即存，需要 reviewr 审核之后才能并入。

如何避免长期记忆污染上下文？

一句话：核心举措有两条，只记忆有用的信息 & 只检索需要的记忆。

上下文污染的原因：记忆太长，导致有效记忆的召回率过低；同时，过多的记忆更容易出现冲突和错误，影响上下文质量。

记忆压缩、记忆过期、记忆冲突应该怎么处理？

一句话：压缩是精炼与总结；遗忘通过 TTL、时间衰减、主动清退机制进行；冲突则通过时间、来源、佐证确定权威版本，必要时也可标注为历史版本并保留而非覆盖。

三者作用：压缩解决“太多”，过期解决“太旧”，冲突解决“打架”。

面试里怎么讲“有记忆”不是简单保存聊天记录？

一句话：记忆的存在是用来支持 Agent 当前与未来的工作，也就是说与 Agent 工作无用的信息应该被剔除。聊天记录内包含了大量的无用信息（比如用户在某时查询了某地的天气、某个网页响应速度发生了异常等），LLM 进行剔除，剩余的有用信息再经过提炼总结就是记忆。

Context Engineering

Prompt Engineering 和 Context Engineering 有什么区别？

一句话：Prompt Engineering 聚焦于给 LLM 提供一种完成任务的范式（比如教 LLM 怎么完成一件任务）；而 Context Engineering 则聚焦于动态地为 LLM 提供其所需的上下文信息，让 LLM 在上下文的基础上完成任务（比如告诉 LLM 所有的信息，然后直接向他提出任务要求）。

Prompt 四要素 Role、Task、Context、Format 分别解决什么问题？

一句话：Role 通过渐进式披告诉 LLM 应该聚焦于哪些领域；Task 是任务；Context 是 LLM 完成 Task 所需要的信息；Format 则规定了输出的格式

Few-Shot、CoT、任务分解、结构化输出分别适合什么场景？

一句话：这些都是属于 Prompt Engineering 的小技巧。Few-Shot 适合输出格式严格的任务；CoT 适用于能分解为多个先后步骤的任务；任务分解适用于可以拆分为多个子任务的任务；结构化输出适用于直接被软件系统消费的任务。

Prompt 注入攻击是什么？常见防护方式有哪些？

一句话：在 prompt 中注入恶意文本，诱导 LLM 执行可能造成严重后果的危险操作的行为。常见的防护方法分执行层、认知层和决策层。

细分：

  1. 执行层：将执行环境与物理服务沙箱隔离（docker等）、权限控制（执行权限细分、危险操作需要授权）；

  2. 认知层：从输入给 LLM 的 prompt 入手，使用 <> [] {} 等隔离不可信的用户 prompt 和可信的系统 prompt；

  3. 决策层：高危操作（比如数据库crud、转账、发送邮件等），执行前终端，交由人类管理员 Human in Loop 决策是否执行。

为什么 Agent 场景下只优化 Prompt 不够？

一句话：Prompt 是针对于前 Agent 时代的 AI 使用方法，聚焦的是如何教会 LLM 做好一件事，如今的 Agent 其运行则关系到记忆系统、闭环控制、工具调用等模块，单纯地优化 Prompt 已经不再适用 Agent 时代，所以引出了直接针对 Agent 运行的 Context Engineering。

Context Engineering 要解决哪些问题？

一句话：在 Agent 每一轮的执行中动态地维护 Context 让 Agent 最高效地解决问题。

维护 Context：1.动态按需检索记忆；2.对记忆进行压缩、遗忘、更新；3.尽可能提高 Context 的信息密度。

静态规则、动态信息、工具结果、记忆应该如何进入上下文？

一句话：静态规则直接拼接、动态信息用引用式按需加载、工具结果在 Agent 轮次中动态加载、记忆按照需求检索而非全盘加载。

长任务上下文溢出时，Compaction、结构化笔记、Sub-agent 分别怎么用？

一句话：Compaction 是将上下文喂给 LLM 精炼，排除没用信息保留高密度有用信息；结构化笔记是将重要信息使用文档记录下来，方便随时更新维护；Sub-agent 是开启一个新的 Agent 实例，只给其任务需要的最简短的上下文，避免其包含过多上下文，让其在较为干净的环境完成任务。

MCP & Skill

MCP 解决什么问题？为什么常被类比成 AI 领域的 USB-C？

一句话：MCP 主要解决的是非耦合外部工具的统一注册发现调用和资源共享问题；之所以被类比为 USB-C 是因为它试图统一 Agent 与工具之间的连接方式，结局工具与 Agent 高度耦合的现状。

MCP Client、MCP Server、Host 分别是什么？

一句话：Host 就是 Agent 所在的软件进程；MCP Client 是 MCP 客户端，Host 调用 Client 与服务端 Server 通信以调用工具、访问资源等操作。Client 和 Server 一一对应，之间通过 JSON RPC 2.0 进行通信。