什么是 Agent？与大模型有什么本质不同？
面试时答这道题，一定要点出三件事：一是 Agent 有自主规划能力，给它一个复杂目标它能自己拆解成多步；二是它能行动，通过工具调用跟外部世界真实交互；三是它有闭环，每步的结果会反馈回来指导下一步，而不是一次性生成完就结束。另外还要提一句容易混的点：模型本身只是「大脑」，工具的真正执行是你的代码，模型只负责决策。
我理解 Agent 本质上是一个能自主完成目标的 AI 系统，跟传统 AI 最核心的区别在于「自主性」和「能行动」。
传统 AI 是你问一个问题它回答一个问题，每次都是独立的，被动响应；而 Agent 有自己的规划能力，你给它一个复杂目标，它会自己把任务拆成多步，通过调工具、访问记忆、感知环境来一步步执行，直到完成。
它不只是输出文字，而是真的能做事
Agent 的基本架构由哪些核心组件构成
Workflow，Agent，Tools 这三个的概念和区别介绍一下？
Tools 是最小的能力单元，就是封装好的可调用函数，比如搜索、执行代码、发邮件，它只负责「执行」，本身没有任何决策能力。
Agent 是一个完整的决策系统，内部用 LLM 做大脑，自己判断什么时候调哪个 Tool、要不要继续、什么时候结束，是主动的。
Workflow 是更上层的编排框架，把 Agent、LLM、Tools 组织成一条确定性流程，每个节点做什么、按什么顺序流转都是开发者事先写死的。
三者最核心的区别就一句话：Tools 不做决策只执行，Agent 自己做决策，Workflow 是开发者替所有节点把决策提前写好。
Tools 没有决策能力，只负责被调用时执行；Agent 由 LLM 在运行时动态决策，同样的输入可能走不同路径；Workflow 的决策提前写死在代码里，行为完全可预测。
三者不是三选一的关系，而是可以相互嵌套的，面试时还要补一句：生产环境里最主流的不是纯 Agent，而是 Agentic Workflow，用 Workflow 固定主流程骨架，在需要灵活判断的节点嵌入 Agent，这样兼顾了可控性和灵活性。
三者怎么组合？Agentic Workflow 才是生产主流
完全靠 Agent 自主决策 的系统其实很少在生产环境里出现，原因很现实：行为太难控制，一旦出问题很难排查，成本也容易失控（LLM 调太多轮）。
完全靠 Workflow 写死 的系统又太脆，因为你没法把所有情况都穷举到代码里，遇到预料之外的输入就容易失败或者给出很差的结果。
所以目前生产环境里最主流的模式是**「Agentic Workflow」**：**用 Workflow 固定主流程的骨架，在需要灵活判断的节点嵌入 Agent，其余固定节点直接用 LLM 或 Tools。 骨架是确定的，让你能控制整体行为、便于调试；关键节点是灵活的，让你能应对各种复杂情况。**两个优点都有，两个缺点都被削弱了
总结了几种常见的 Workflow 编排模式：
2. 第一种叫「Prompt Chaining」（提示链），就是把一个大任务拆成多个小步骤，前一步的输出作为后一步的输入，像流水线一样串起来。
3. 第二种叫「Routing」（路由），先用一个 LLM 做分类判断，然后根据分类结果把请求分发到不同的处理分支，前面客服系统的例子就是典型的路由模式。
4. 第三种叫「Parallelization」（并行化），把可以同时进行的子任务并行执行，最后汇总结果，这在需要多维度分析的场景下特别有用，比如同时从多个数据源检索信息。
5. 第四种叫「Orchestrator-Workers」（编排者-工人），一个中央编排者负责分配任务，多个 Worker 各自完成子任务，适合任务可以分解但子任务之间相互独立的场景。
知识图谱：让记忆之间产生关联
在 Agent 的记忆模块里引入知识图谱，通常是和向量数据库配合使用的。向量数据库负责处理模糊的语义检索（比如用户说「之前那个项目」，向量检索能找到最相关的项目记忆），知识图谱负责处理精确的关系推理（比如查某个用户的所有相关公司和角色），两者互补。具体做法是：对话过程中用 LLM 自动提取出实体和关系，存入知识图谱。检索时先用向量检索拿到一批候选记忆，再用知识图谱补充关联信息，最后把两部分结果合并后注入 context。
还有一种非常实用但经常被忽略的模式叫**「Evaluator-Optimizer」（评估者-优化者）。**
它的核心思路是：一个 LLM 负责生成输出，另一个 LLM（或者同一个模型换一个角色）负责评估这个输出的质量，如果评估不通过就把反馈给回生成者，让它改进后重新输出，如此循环直到评估通过或者达到最大重试次数。
了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？
常见的设计范式除了纯 Agent 之外，还有 ReAct 、Plan-and-Execute、Reflection 这几种。
我理解 Agent 和 Workflow 最核心的区别是「谁来决定下一步」。Workflow 是我提前把流程写死的，每一步怎么走都是固定的，确定性高、好控制；Agent 是让 LLM 自己决定下一步做什么，灵活但不可控。
我在实际工程里用得最多的反而是把两者混用，固定流程的部分用 Workflow，需要灵活决策的节点嵌入 Agent 能力，这样既保住了整体可控，又有局部的灵活性。
Agent 三种设计范式
ReAct（Reasoning + Acting）是最常见的一种。
它的名字直接说明了它的核心机制：把推理（Reasoning）和行动（Acting）交替进行。具体来说，ReAct 的每一轮循环由三个步骤组成，形成一个完整的 Thought -> Action -> Observation 循环。
Thought 阶段，LLM 先把当前的情况分析一遍，把推理过程写出来，比如「用户想查竞品信息，我应该先用搜索工具查一下竞品 A 的最新动态」；Action 阶段，LLM 根据思考的结论决定调用哪个工具、传什么参数；Observation 阶段，工具返回的结果被反馈给 LLM，它读取这个结果，然后进入下一轮 Thought，重新分析当前局面、决定接下来怎么做。
Plan-and-Execute
它把规划和执行彻底分开，先让一个 LLM 专门做规划，输出一个完整的步骤列表，然后由另一个 LLM（或同一个模型以不同角色）逐步执行。
成熟的 Plan-and-Execute 实现里，每执行完一步都会把结果反馈给规划器，规划器会判断：当前的执行结果和预期一致吗？后续的计划还适用吗？需不需要调整？如果发现某一步的结果和预期严重偏离，规划器会修改后续的步骤，甚至插入新的步骤来应对。
Reflection（反思）
它的做法是在 Agent 完成一步或者完成整个任务之后，再让一个 LLM（可以是同一个模型也可以是专门的评估模型）来判断做得好不好、结果是否符合预期。如果评估不通过，就重试或者换一种策略。这个机制能显著提升输出质量，尤其是在代码生成、文案写作这类「质量要求高但一次做对很难」的场景下效果特别明显。
Reflection 有一个非常值得关注的变体叫 Reflexion。它和基础 Reflection 的区别在于，Reflexion 不只是简单地说「这个结果不好，重做一遍」，而是会生成一段具体的「反思总结」，记录下这次失败的原因和改进建议，然后把这段总结作为额外的上下文传给下一次尝试。
第一个雷是设计范式不熟，ReAct 是最常见的，但 Plan-and-Execute（把规划和执行解耦）和 Reflection（执行后加自我评估环节）也是必须说出来的，三个范式各有适用场景。
第二个雷是把 Reflection 当调试手段，它是正式的运行时机制，内嵌在 Agent 的执行流程里，代价是增加 token 消耗和延迟，这个取舍在面试里经常被追问。
第三个雷也是最重要的一个：以为 Agent 是生产环境的首选。实际上纯 Agent 模式在生产里用得很少，因为行为不确定、难以调试、成本容易失控。
真正的工程答案是 Agentic Workflow：整体用 Workflow 框住主流程保证可控，在需要灵活判断的节点嵌入 Agent 能力。能主动说出「为什么纯 Agent 在生产里有局限」，是这道题拿高分的关键
Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？
Agent 的推理模式我用过几种。
最基础的是直接输出答案，没有中间推理；CoT 是让 LLM 先把推理过程写出来再给答案，准确率更高；ReAct 是在 CoT 基础上加了「行动」，让 LLM 交替输出思考和工具调用，每次行动后再根据结果继续思考，形成一个循环。
我觉得 ReAct 是目前 Agent 用得最广的模式，因为它推理过程可见，又能动态利用外部工具，两个优点都有。
ReAct 是什么？
ReAct 是 Reasoning and Acting 的缩写，由 Yao 等人在 2022 年提出，核心思路是在 CoT 的推理链里，插入真实的「行动」。
它让 LLM 按照「思考 -> 行动 -> 观察」这个循环来推进任务：先思考当前该怎么做，然后调用一个工具去获取信息或执行操作，把工具返回的结果作为新的「观察」接收回来，再进入下一轮思考，直到 LLM 判断任务完成。
纯 CoT 的问题前面说过了，它只能在脑子里推理，推得再好也拿不到真实数据，遇到需要实时信息的场景就抓瞎，而且纯靠内部推理很容易产生幻觉，因为没有外部事实来校准。
纯 Act-only 走的是另一个极端，它让 LLM 直接输出工具调用序列，不写任何思考过程，看起来效率很高，但问题在于每一步行动之间没有推理链条来连接，就像一个人闷头干活但不动脑子，遇到需要调整策略的情况就容易出错。
ReAct 的实现原理，是通过 prompt 格式来约束 LLM 的输出结构，但这个循环不是 LLM 自己在转，而是由你的代码来驱动的。
ReAct 的优势在于灵活，每一步都能根据最新情况做决策，特别适合那些任务边界不太明确、需要探索性地获取信息的场景，比如开放式的问答、信息搜索这类任务。它的代价是容易漂移，而且每一步都要把完整历史带上调 LLM，步骤多了 token 消耗会线性增长。
Plan-and-Execute 的优势在于有全局视野，不容易跑偏，特别适合那些目标明确、需要多步骤协作完成的复杂任务，比如深度研究、长文写作、多工具协同的数据分析。它的代价是初始规划本身就需要一次 LLM 调用，如果任务很简单（一两步就能搞定），这个规划步骤反而是多余的开销。
面试官最想听到的核心点是两个：第一，ReAct 的本质是「思考 -> 行动 -> 观察」的循环，推理过程显式化，又能动态调用外部工具，解决了 CoT 只能纯文字推理的局限；第二，这个循环是由你的代码框架驱动的，模型每次只输出 Thought + Action，你的代码负责解析、执行工具、把 Observation 填回历史，再把完整历史传给模型进入下一轮。
把这两点说清楚之后，主动提一下 ReAct 的两个实战局限（循环漂移(每次输出的答案局部最优，但最后可能会偏移目标)和错误传播（中间某一步输出错误答案，会继续向下传播）），再顺带说一下 Plan-and-Execute 是怎么通过「先规划再执行」来解决 ReAct 的漂移问题的，以及实际项目中两者经常混合使用（规划用大模型、执行用小模型），整个回答就会很有深度。
ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？
ReAct
ReAct 最大的优势是实现简单、灵活度高、逻辑透明，出了问题好排查，新手入门零门槛。但它的短板也很明显：遇到长流程、多步骤的复杂任务，很容易走着走着就跑偏，忘了最初的目标，也容易在某一步陷入无效循环。所以它更适合流程不固定、复杂度适中的任务，比如日常信息搜索、简单问答助手、客服机器人，也是新手入门的首选。
Plan-and-Execute
Plan-and-Execute 和 ReAct 最核心的区别，就是把「规划」和「执行」完全解耦了：先有完整的执行计划，再分步执行，全程不会偏离最初的目标，而不是像 ReAct 那样边规划边执行、随时可能调整方向。和 Reflection 相比，它的核心是「先规划再执行」，没有强制的自我检查环节，但两者可以叠加使用。
优势正好补了 ReAct 的短板：整体结构清晰，执行链路可控，复杂度很高的长流程任务也不容易跑偏，还方便做并行优化，大幅降低整体耗时。
Reflection
Reflection 和前两者最本质的区别，是它不是一套独立的做事流程，而是可以叠加在 ReAct 或 Plan-and-Execute 之上的增强机制，互不冲突。前两者的核心是「把事做完」，Reflection 的核心是「把事做好」，专门解决输出质量不达标、有事实错误、逻辑漏洞的问题。
优势很直接：输出质量明显提升，幻觉、逻辑错误、细节遗漏都会减少，对严谨性要求高的场景效果尤其明显。代价是至少多一次 LLM 调用，token 消耗和延迟都会线性增加，如果没有轮次限制，还很容易陷入「为了改而改」的死循环。所以它适合对输出质量要求极高、不能出错的场景，比如写生产环境的代码、正式的商业报告、法律文书，但凡有错误就会出大问题的，都值得加上 Reflection。
进阶：动态 Replan 和 Reflexion
动态 Replan
动态 Replan 的做法是在每个步骤执行完之后，把当前结果和剩余计划一起交给规划模块，让它判断「原来的计划还合理吗，需不需要调整」。如果需要，就生成一份新的剩余步骤计划，替换掉原来的。
Reflexion
第二个是 Reflexion，它把 Reflection 的「自我反思」推到了更深的层次。普通的 Reflection 是「做完了检查一遍、发现问题就重做」，有点像考试做完检查一遍。
Reflexion 在这个基础上多做了一件关键的事：它不仅检查输出对不对，还会把每次失败的原因总结成一段「经验教训」，存进记忆里，下次再遇到类似任务时，这段教训会作为上下文传给 LLM，让它避免重蹈覆辙。
说完定位，再按维度对比三者的核心区别：ReAct 边想边干、灵活度最高但长任务容易跑偏；Plan-and-Execute 先规划再执行、结构清晰但灵活度不足；Reflection 专门解决输出质量问题，代价是增加 token 消耗和延迟。
如果面试官追问进阶内容，可以展开讲动态 Replan 是怎么解决「计划太僵硬」的问题，Reflexion 是怎么通过「错题本」机制实现跨任务经验积累的，再补充一下三种范式的 token 消耗差异。
最后给出选型口诀：任务简单用 ReAct，流程长且复杂用 Plan-and-Execute，输出要求高再加 Reflection，顺带提一句「别过度工程化、够用就好」，面试官会觉得你有实际项目经验，不是只会背概念
复杂任务怎么做的任务拆分？为什么要拆分？效果如何提升？
拆分方式主要有两种：一种是静态拆分，提前把步骤写死；另一种是动态拆分，让 LLM 自己根据目标规划步骤，更灵活但也更难控制。
我理解任务拆分的原因是 LLM 一次性处理太复杂的任务很容易出错，把大任务拆成小步骤，每步聚焦一件事，准确率会明显提升。
为什么？
把一个大目标切成多个小步骤，每个步骤只做一件事，LLM 的全部注意力都集中在这一件事上，桌面保持干净，质量自然高。
每一个步骤都是独立的输出，可以被单独检查和验证。某一步出了问题，重试那一步就行，不需要从头跑整个任务。
任务拆分两种思路
静态拆分是你提前把任务流程设计好，固定成一个确定的 Workflow **，每一步是什么、按什么顺序执行，全部事先写死。**比如「写一篇技术博客」，固定拆成：搜索资料 -> 整理大纲 -> 逐段撰写 -> 润色校对，四步顺序执行。好处是行为完全可预测，出了问题知道是哪一步的问题，好排查；坏处是灵活性低，遇到你没设计进流程的情况就容易卡住。
动态拆分则是把「任务拆解」这件事本身也交给 LLM 来做。你给它一个目标，让它先输出一个执行计划，再按计划一步步执行，这是 Plan-and-Execute 模式的核心思想。
自适应拆分：做不好就继续拆
更好的做法是：不要在开始时就把所有步骤的粒度定死，而是在执行过程中根据每一步的实际难度动态调整。核心逻辑很简单：先让执行器尝试完成当前任务，如果做得好就继续往下走，不做多余的拆分；如果明显做不好，比如超过了最大步数还没完成，或者输出质量不达标，就把这个「做不好的任务」交给规划器，让规划器把它进一步拆成更小的子任务，然后对每个子任务重复同样的流程：先试，做不好就再拆。
第一层是「为什么拆」：LLM 的 context window 有上限，任务越大中间状态越多、越容易出错，而且拆开后每步可以独立验证和重试。
第二层是「怎么拆」：静态拆分适合流程固定的场景，直接写死步骤；动态拆分用 Plan-and-Execute 让 LLM 自己规划，灵活但规划质量不稳定。
第三层是「拆完还要做的事」：分析步骤依赖关系，把能并行的步骤并发跑，关键路径时间可以降 40% 到 60%。
最后再补一句「粒度把握很重要，以原子操作为标准，既不能太细也不能太粗」，这道题就回答得很漂亮了。
请你介绍一下 AI Agent 的记忆机制，并说明在实际开发中应该如何设计记忆模块？
记忆机制分四层：感知记忆（当前输入的原始内容）、短期记忆（context window 里的对话历史）、长期记忆（存在外部数据库、语义检索召回）、实体记忆（结构化提取的关键事实）。
四种记忆类型（从最短暂到最持久）
第一层：感知记忆（ Sensory Memory ）
这是最短暂的一层，就是「当前这次调用的原始输入」，用户发来的这条消息、上传的截图、传入的文档。它的生命周期只有一次调用，处理完就消失，不会主动保留。类比到人的话，就是你刚听到的一句话，如果没有主动去记，几秒后就忘了。感知记忆就是这个「刚进来还没处理」的原始感知，它存在的意义是给模型提供一个「入口」来接收外部信息。
第二层：短期记忆（ Short-term Memory ）
这是 context window 里的 messages 列表，维持着当前任务执行过程中的完整状态，包括用户说了什么、模型输出了什么、工具调用返回了什么。只要任务还在进行，这些信息就都在；任务结束（对话关闭），这块记忆就清空了。你可以把它想象成你的「工作台」，桌上摆着的都是正在处理的东西。工作台有大小限制（token 上限），放满了就得清一清。工作台的特点是「随时可见」，不需要去翻箱倒柜地「找」，直接读就行。
第三层： 长期记忆 （Long-term Memory）
这是跨任务保留的信息，存在外部数据库里，通常是向量数据库、关系数据库或 Key-Value 存储。任务结束了，信息不会消失，下次需要时去检索拿回来用。你可以把它理解成你的「档案室」，东西放进去不会丢，但要用的时候需要主动去翻。长期记忆的关键技术是向量数据库，它支持「语义检索」：你不需要知道存的时候用了什么关键词，只要意思相近就能检索到相关内容。这比精确匹配灵活得多，比如你存的是「用户不喜欢冗长的注释」，用「代码风格偏好」去查也能找到它。
长期记忆 其实不是铁板一块，它还可以细分成三种子类型，每种存的东西和用途都不一样。
第一种是「情节记忆」（Episodic Memory），存的是具体的事件经历。比如「上周二用户让我写了一个 Python 爬虫，中间遇到了反爬问题，最后用 Selenium 解决了」，这是一段完整的任务经历，包含了时间、场景、过程和结果。情节记忆的价值在于，当 Agent 遇到类似的新任务时，可以检索出历史上的相似经历，参考上次是怎么解决的，避免重复踩坑。
第二种是「语义记忆」（Semantic Memory），存的是从多次经历中提炼出来的通用知识和规律。比如经历了好几次反爬问题之后，Agent 沉淀出一条规律：「当目标网站有 JavaScript 动态渲染时，requests 库抓不到内容，应该优先考虑 Selenium 或 Playwright」。这不再是某一次具体的事件记录，而是跨多次经验总结出来的抽象知识。语义记忆的信息密度更高，检索时也更容易命中，因为它直接存储的就是结论而不是过程。
**第三种是「程序记忆」（**Procedural Memory），存的是怎么做某件事的操作流程。比如「部署一个 Flask 应用的标准步骤：创建虚拟环境 -> 安装依赖 -> 配置 gunicorn -> 设置 nginx 反向代理 -> 启动服务」，这是一套可以直接复用的操作 SOP。程序记忆在处理重复性任务时特别有用，Agent 不需要每次都从头推理，直接调出对应的 SOP 执行就行，既快又稳。
三种子类型各有侧重，实际项目中通常会混合使用。情节记忆提供具体的参考案例，语义记忆提供抽象的知识规律，程序记忆提供可复用的操作流程，三者配合起来才能让 Agent 的长期记忆真正好用。
第四层：实体记忆（Entity Memory）
这层比长期记忆更精炼，它不是存原文，而是把对话中出现的关键实体和事实主动提取出来，存成结构化字段。比如「用户偏好 Python」「客户预算是 5 万」「项目截止日是 3 月底」，这些是从对话里提炼出来的「结论」，而不是原始对话本身。类比到人的话，就像医生的病历卡，不是把问诊录音存起来，而是结构化地记录「主诉：头痛三天；诊断：偏头痛；用药：布洛芬」。信息密度高，查询快，而且不受原始表述方式影响。
实际设计记忆模块的三个核心问题
第一个：存什么？
通常值得存的有三类：用户偏好和习惯（语言风格、技术栈偏好、工作习惯）、任务执行中产生的关键结论和决策（比如「调研发现竞品 A 的定价策略是按用量收费」）、以及外部知识（产品文档、FAQ、历史案例）。
第二个：怎么存？
需要语义检索的内容，比如文档知识、对话摘要这类非结构化的文本，适合存进向量数据库，用 embedding 编码后通过相似度检索。结构化的用户偏好和状态字段，比如语言偏好、项目配置这些可以精确查询的内容，更适合用关系数据库或 Key-Value 存储，查询速度快，不需要语义理解。整段文档或知识库则适合存进向量数据库，配合 RAG 流程做召回。
混合存储是主流做法：结构化的偏好字段用关系数据库精确查，非结构化的知识和历史用向量数据库语义检索，两者配合使用。
第三个：什么时候取出来用？
第一种叫「主动检索」，在任务开始前，用当前任务的描述去检索相关记忆，把结果注入 system prompt 作为背景知识。这样 Agent 一开始就带着「历史记忆」进入任务，不需要用户每次重新交代背景。第二种叫「被动触发」，Agent 在推理过程中，判断当前步骤需要某类特定知识时，主动发起检索。具体做法是把「查记忆」封装成一个 Tool，让 Agent 自己决定什么时候调。这种方式更灵活，但依赖模型判断什么时候该去查。
实践上两种结合效果最好：session 开始时做一次主动检索，把关于用户偏好和背景的记忆加载进 system prompt；任务执行过程中，遇到需要专业知识或历史数据的步骤，再让 Agent 按需检索
Context Window 管理：短期记忆的「工作台」不够大怎么办
最简单的是「滑动窗口」，只保留最近 N 轮对话，更早的历史直接丢弃。好处是实现简单，代价是早期的重要信息可能被丢掉。比如用户在第一轮就说了「所有代码用 TypeScript」，到了第十轮这条信息被滑出窗口了，Agent 又开始写 JavaScript，用户就会很崩溃。
进阶一点的做法是**「摘要压缩」**。当历史长度接近上限时，用 LLM 把早期的对话历史压缩成一段摘要，替换掉原始的冗长历史。比如把前面十轮的详细对话压缩成「用户要求用 TypeScript 编写一个 REST API，已完成数据库设计和路由定义，当前正在实现用户认证模块」，一段话就把关键信息保留了，token 占用从几千降到几百。代价是压缩过程本身会丢失细节，而且需要额外的 LLM 调用来做摘要。
还有一种做法是把不常用但重要的信息「卸载」到 长期记忆 里。执行过程中产生的中间结果，如果当前步骤不需要但后面可能用到，就先存到向量数据库里，从 context window 中移除，等后面某步需要时再检索回来。这相当于给工作台配了一个「抽屉」，桌面放不下的东西先收到抽屉里，要用的时候再拿出来。