小林大模型｜大模型面试高频知识点合集2

什么是 Agent与大模型有什么本质不同面试时答这道题一定要点出三件事一是 Agent 有自主规划能力给它一个复杂目标它能自己拆解成多步二是它能行动通过工具调用跟外部世界真实交互三是它有闭环每步的结果会反馈回来指导下一步而不是一次性生成完就结束。另外还要提一句容易混的点模型本身只是「大脑」工具的真正执行是你的代码模型只负责决策。我理解 Agent 本质上是一个能自主完成目标的 AI 系统跟传统 AI 最核心的区别在于「自主性」和「能行动」。传统 AI 是你问一个问题它回答一个问题每次都是独立的被动响应而 Agent 有自己的规划能力你给它一个复杂目标它会自己把任务拆成多步通过调工具、访问记忆、感知环境来一步步执行直到完成。它不只是输出文字而是真的能做事Agent 的基本架构由哪些核心组件构成WorkflowAgentTools 这三个的概念和区别介绍一下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 编排模式第一种叫「Prompt Chaining」提示链就是把一个大任务拆成多个小步骤前一步的输出作为后一步的输入像流水线一样串起来。第二种叫「Routing」路由先用一个 LLM 做分类判断然后根据分类结果把请求分发到不同的处理分支前面客服系统的例子就是典型的路由模式。第三种叫「Parallelization」并行化把可以同时进行的子任务并行执行最后汇总结果这在需要多维度分析的场景下特别有用比如同时从多个数据源检索信息。第四种叫「Orchestrator-Workers」编排者-工人一个中央编排者负责分配任务多个 Worker 各自完成子任务适合任务可以分解但子任务之间相互独立的场景。还有一种非常实用但经常被忽略的模式叫「Evaluator-Optimizer」评估者-优化者。它的核心思路是一个 LLM 负责生成输出另一个 LLM或者同一个模型换一个角色负责评估这个输出的质量如果评估不通过就把反馈给回生成者让它改进后重新输出如此循环直到评估通过或者达到最大重试次数。了解哪些其他的 Agent 设计范式Agent 和 Workflow的区别是什么常见的设计范式除了纯 Agent之外还有ReAct、Plan-and-Execute、Reflection这几种。我理解 Agent 和 Workflow 最核心的区别是「谁来决定下一步」。Workflow 是我提前把流程写死的每一步怎么走都是固定的确定性高、好控制Agent 是让 LLM 自己决定下一步做什么灵活但不可控。我在实际工程里用得最多的反而是把两者混用固定流程的部分用 Workflow需要灵活决策的节点嵌入 Agent 能力这样既保住了整体可控又有局部的灵活性。Agent 三种设计范式ReActReasoning 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 三种范式有什么核心区别实际项目中该如何选型ReActReAct 最大的优势是实现简单、灵活度高、逻辑透明出了问题好排查新手入门零门槛。但它的短板也很明显遇到长流程、多步骤的复杂任务很容易走着走着就跑偏忘了最初的目标也容易在某一步陷入无效循环。所以它更适合流程不固定、复杂度适中的任务比如日常信息搜索、简单问答助手、客服机器人也是新手入门的首选。Plan-and-ExecutePlan-and-Execute 和 ReAct 最核心的区别就是把「规划」和「执行」完全解耦了先有完整的执行计划再分步执行全程不会偏离最初的目标而不是像 ReAct 那样边规划边执行、随时可能调整方向。和 Reflection 相比它的核心是「先规划再执行」没有强制的自我检查环节但两者可以叠加使用。优势正好补了 ReAct 的短板整体结构清晰执行链路可控复杂度很高的长流程任务也不容易跑偏还方便做并行优化大幅降低整体耗时。ReflectionReflection 和前两者最本质的区别是它不是一套独立的做事流程而是可以叠加在 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 中移除等后面某步需要时再检索回来。这相当于给工作台配了一个「抽屉」桌面放不下的东西先收到抽屉里要用的时候再拿出来。知识图谱让记忆之间产生关联在 Agent 的记忆模块里引入知识图谱通常是和向量数据库配合使用的。向量数据库负责处理模糊的语义检索比如用户说「之前那个项目」向量检索能找到最相关的项目记忆知识图谱负责处理精确的关系推理比如查某个用户的所有相关公司和角色两者互补。具体做法是对话过程中用 LLM 自动提取出实体和关系存入知识图谱。检索时先用向量检索拿到一批候选记忆再用知识图谱补充关联信息最后把两部分结果合并后注入 context。记忆整合从碎片到知识回答 Agent 记忆机制这道题先把四层分类说清楚感知记忆是当次调用的原始输入最短暂短期记忆是 context window 里的 messages维持任务状态长期记忆是存在向量或关系数据库里、跨任务持久化的内容实体记忆是从对话中提炼出来的结构化事实信息密度最高。说完分类再答三个工程核心问题存什么只存对下次任务有价值的内容过滤噪音、怎么存语义内容用向量数据库结构化偏好用关系数据库混合存储是主流、什么时候取任务开始前主动检索加载背景执行中按需检索特定知识。最后用「读 - 用 - 写」三阶段闭环收尾整个回答结构清晰、有深度面试官很难挑剔。Agent 的长短期记忆系统怎么做的记忆是怎么存的粒度是多少怎么用的短期记忆就是 context window 里的对话历史存当前任务的中间状态任务结束就清掉长期记忆用向量数据库存把信息 embedding 后写入用的时候做语义检索拿回来注入 prompt。再多说一层长期记忆其实还可以按「类型」细分成三种。第一种是语义记忆Semantic Memory存的是事实性知识比如「用户是 Python 开发者」「项目预算上限 5 万」这些是不随时间变化的客观信息。第二种是情节记忆Episodic Memory存的是具体事件的经历比如「上周二用户让我写了一个爬虫中间因为反爬策略改了三次方案」它带有时间线和因果关系。第三种是程序记忆Procedural Memory存的是「怎么做某件事」的方法论比如「给这个用户写代码时先确认风格偏好再写主逻辑最后加注释」它更像是 Agent 积累下来的行为模式。第一个雷是把长期记忆说成「存数据库靠关键词搜索」这暴露了不了解向量检索长期记忆的核心是 Embedding 向量数据库靠语义相似度而不是字符串匹配来检索这一点一定要说清楚。第二个雷是以为粒度越细越好实际上粒度太细会导致记忆碎片化检索时拿到不完整的信息合理粒度是「一次完整交互」或「一个独立知识点」。第三个雷是搞不清两层记忆各自的作用时机短期记忆是任务执行中的「工作台」任务结束就清空长期记忆是任务前检索注入、任务后写入沉淀两者分工不同配合使用才能让 Agent 既不中途失忆、又能跨任务积累。什么是 Multi-AgentMulti-Agent 之间的协作方式主要有三种模式。第一种是顺序流水线Sequential PipelineAgent A 做完把结果交给 Agent BB 做完交给 Agent C就像工厂流水线一样每个环节依次处理。第二种是并行扇出Fan-out一个调度者把多个独立子任务同时分发给不同的 Worker Agent它们各自并行执行最后由调度者收集汇总。第三种是辩论/评审模式Debate/Review多个 Agent 对同一个问题各自给出方案然后由一个裁判 Agent 或者它们互相评审来筛选最优解这种模式在需要高质量决策的场景特别有用比如代码评审、方案选型这道题的核心在于能不能说清楚「为什么需要 Multi-Agent」而不是泛泛地说「多个 AI 一起工作效率更高」。面试官最想听到的是两个具体的技术驱动因素第一是 context window 的硬上限单个 Agent 处理复杂任务时信息量一旦超出窗口就开始「遗忘」这是结构性的限制不是努力优化能绕过去的第二是专业度问题让一个 Agent 身兼数职每件事都做得不够专注分工之后每个 Agent 的 context 是干净的只装自己那块的信息专业能力也更强。回答时还要提到并行执行这个好处多个 Worker 同时跑整体效率有实质提升。把这三个点说清楚这道题就答到位了。说说 Single-Agent 和 Multi-Agent 的设计方案Single-Agent 适合任务流程清晰、复杂度适中的场景实现简单、好维护Multi-Agent 适合需要专业分工、任务量大或者需要并行执行的复杂场景。Multi-Agent 架构上主要有两种拓扑中心化的 Orchestrator 模式由一个主 Agent 统一调度各个 Worker去中心化的 Peer-to-Peer 模式Agent 之间直接通信。我在工程里用中心化用得更多因为好控制、好调试出问题链路清晰。Single-Agent缺点Single-Agent 真正开始力不从心是在遇到这几类任务的时候任务太长、信息量太大context 撑爆Agent 开始遗忘不同步骤需要完全不同的专业能力什么都塞进一个 Agent每件事都做得不够专注任务中有多个独立子任务理论上可以并行但单 Agent 只能一个个来Multi-AgentPeer-to-Peer缺点总结下来去中心化系统里这几类问题会频繁出现任务分配没有协调、执行顺序没有保证、失败没有感知、没有人来确认「任务整体完成了」。类比一个没有项目经理的团队每个人都很能干但没有人协调时间节点和接口最后交出来的可能是互不兼容的结果而且没有人知道整体进度到底怎么样了。这就是为什么去中心化方案更多停留在学术研究里探索研究的是「AI 系统能不能实现自主协调」这个更宏观的问题。而生产环境里几乎所有正经项目都选 Orchestrator 模式因为可控、可追踪、出了问题能排查这才是工程上真正需要的。这道题最容易犯的错误有三个对应开头对话里踩的三个雷。第一选型标准不能只说「任务复杂就用 Multi-Agent」要说出具体的三类场景context 要撑爆了、需要不同专业分工、有子任务可以并行不属于这三类就用 Single-Agent盲目引入 Multi-Agent 只会增加系统复杂度带不来对应收益。第二Multi-Agent 架构方案要主动提中心化和去中心化两种而且要明确说出工程里几乎都选 Orchestrator 中心化模式因为可控、可追踪、出了问题能顺着调度链路排查。第三去中心化「听起来灵活」但要能说清楚它的实际问题任务分配没协调、执行顺序没保证、失败没有感知这才是它在生产环境里不可用的根本原因。Agent 记忆压缩通常有哪些方法记忆压缩常见有四种方法摘要压缩、滑动窗口、重要性过滤、结构化抽取。摘要压缩是把长对话总结成简短摘要滑动窗口是只保留最近 N 轮对话重要性过滤是打分筛选只留重要内容结构化抽取是把关键信息抽成结构化数据存起来。我在实际项目里最常用的是摘要压缩和滑动窗口而且经常组合用滑动窗口丢弃前先做一次摘要尽量不丢重要信息第一种方法滑动窗口最简单的方案也是最粗糙的滑动窗口是最符合直觉的做法就像手机聊天记录默认只显示最近 200 条超出就从最老的开始删只保留最近 N 轮对话。第二种方法摘要压缩丢之前先提炼一遍不直接丢弃即将超出窗口的历史而是先让 LLM 把这段历史总结成一段精华摘要用摘要替换原始对话再继续往前。这个方案单独用时通常的做法是「旧的压缩成摘要近的保持完整」最近几轮对话往往和当前任务关系最密切保持原文更早的历史相关性低压缩成摘要。进阶一点的做法是层级式摘要Hierarchical Summarization。不是对所有旧历史做一次性摘要而是分层处理最近 10 轮保持原文10 到 50 轮的历史压缩成一份「中期摘要」50 轮之前的历史进一步压缩成更精炼的「长期摘要」最常见的工程组合滑动窗口 摘要在实际工程里这两种方法通常一起用而不是单独用其中一种。滑动窗口负责控制对话历史的总长度上限摘要压缩负责在历史被丢弃之前做一次提炼把关键信息留下来。这样既有长度控制又不是直接硬截断是目前最常见的工程方案。第三种方法重要性过滤按价值筛选不按时间筛选按内容的实际价值来决定去留给每条对话记录打一个重要性分数低于阈值的淘汰高分的保留。还有一种更激进的重要性过滤思路叫观察遮蔽Observation Masking。它的做法不是删除低分内容而是在构造 prompt 时选择性地「隐藏」某些历史条目比如写代码与需求相关的片段不会传入进来只会把相关的信息传入进来主动压缩的思路是Agent 在每一步执行完之后主动判断哪些中间过程可以压缩。第四种方法结构化抽取换一种载体存信息把这些信息主动提取出来存成结构化字段后续注入 prompt 时直接用这些字段比传一大段对话文本要高效得多信息密度也高得多。Prompt Caching在「计算层」的互补手段Prompt Caching 的思路是如果 prompt 的前缀部分在多次请求之间是一样的就把这部分的计算结果缓存起来下次请求如果前缀匹配直接复用缓存不重新计算。费用和延迟都大幅降低某些场景下能降到原来的十分之一。回答时要覆盖四种方法并且能说清楚它们解决的是不同维度的问题滑动窗口和摘要压缩解决「历史太长怎么截」前者直接硬截后者截之前先提炼重要性过滤解决「内容不等价怎么挑」打破时间顺序按价值保留结构化抽取解决「对话文本是不是最佳载体」换一种信息密度更高的形式存储。另外Prompt Caching 要和记忆压缩区分清楚它是「计算层」的优化对已经决定带进去的内容减少重复计算和「信息层」的压缩是互补关系不是替代关系这个区别如果能主动点出来会给面试官留下很好的印象。在工程实践中为什么有时候选择「手搓」Agent而不是直接用成熟框架第一是抽象层太多调试的时候不知道哪步出了问题得一层层往下扒第二是版本升级经常有破坏性变更线上稳定性难保证第三是框架的通用设计往往和具体业务需求有偏差定制起来反而更费劲。手搓的代码完全在自己掌控之内可观测性好、出问题好排查也更方便做性能优化。所以我现在的策略是核心逻辑手写只在边缘功能上用框架的工具手搓的本质优势完全掌控首先是链路透明、可观测性好。手搓的每一行代码你都知道在干什么可以在任意位置加日志、打断点、插入监控没有任何黑盒。线上出了问题靠日志复现故障是最快的方式链路越清晰定位根因越快。第一框架的价值是真实的POC 阶段省时省力不要一开口就否定框架。第二框架的痛点要说具体抽象层太多导致排查困难、版本升级带来 breaking change、通用性设计产生隐性性能开销这三个是实际生产中最常遇到的问题泛泛说「框架有缺点」没有说服力。第三手搓的核心价值是「完全掌控」可观测性好、稳定不受外部升级影响、性能可以精确裁剪这些在生产环境里是真实的成本节省。第四最容易被忽略的是折中方案核心逻辑手写周边工具性功能借用框架这才是实际项目里最常见也最务实的选择面试官通常很认可这个答法。最后要记住一句框架不是问题「不理解就依赖」才是。如何赋予 LLM 规划能力给 LLM 加规划能力主要靠这几种思路。• CoT 是让 LLM 把推理步骤写出来线性地一步步推导到答案• ToT 是让它同时探索多条推理路径选最优的继续深入• GoT 是图结构推理推理节点可以复用和合并适合更复杂的任务。工程上我用 CoT 最多因为实现成本最低就是改个 promptToT 效果更好但调用次数多成本大概是 3 到 5 倍GoT 目前还比较学术生产环境我没见过有人真正落地用的CoT最简单的激活方式加一句话就够了CoT 的全称是 Chain of Thought思维链核心思路极其简单在 prompt 里加一句「请一步步思考」LLM 就会把推理过程逐步写出来而不是直接蹦出答案。第一种叫 Zero-shot CoT就是直接在 prompt 末尾加「让我们一步步思考」LLM 自己展开推理不需要额外例子• 第二种叫 Few-shot CoT给几个带有完整推理过程的例子让 LLM 模仿这种推理格式来回答新问题效果通常更稳定。CoT 的局限很明显它只有「一条推理路径」。如果一开始走错了方向整条链就歪了没有任何纠偏机制。ToT从「一条链」到「一棵树」解决走错方向的问题核心改变是把「生成一条推理链」变成「同时探索多条推理路径边探索边剪枝最终选出最优路径」。用一个生活类比来理解CoT 像你做题时只想了一个解法一路做到底ToT 像你先想了三种可能的解题思路评估了一下哪种最靠谱选了最好的那条继续深入另外两条直接放弃。GoT从「树」到「图」解决推理结果不能复用的问题ToT 虽然引入了多路径探索但它是树形结构不同分支之间完全独立两条推理路径上的中间结论无法互相借用。GoT 把推理结构换成了图允许不同路径的中间结果合并、复用也就是说一个推理节点可以接收来自多个前置节点的输出作为输入。CoT 解决了「要不要把推理显式化」的问题答案是要把过程写出来就能显著减少跳步出错。ToT 解决了「走错方向怎么办」的问题答案是先多探索几条路边走边评估边剪枝。GoT 解决了「不同推理路径的中间结论能不能复用」的问题答案是把结构从树换成图自然支持结论汇聚与复用。每一步都是在前一步的基础上发现局限、针对性改进。工程里真正常用的规划模式Plan-and-Execute具体执行流程分三步。• 第一步Planner规划器接收用户任务生成一份步骤清单比如「第一步搜索相关资料第二步整理关键信息第三步撰写总结报告」。• 第二步Executor执行器按照清单一步步执行每步可能涉及工具调用或 LLM 推理。• 第三步也是容易被忽略的关键每执行完一步会有一个 Re-planner重新规划器回顾当前进展判断原来的计划还适不适用如果中间发现了新的信息或者某步执行结果不符合预期就动态调整后续步骤。这个模式和 ReAct 是什么关系ReActReasoning Acting是一种让 LLM 在每一步都先「思考」再「行动」再「观察」的循环模式它的特点是每步都是即时决策没有提前规划。Plan-and-Execute 则是在 ReAct 的基础上加了一层全局规划你可以理解成 ReAct 负责每一步怎么执行Plan-and-Execute 负责这些步骤的整体编排和动态调整。两者不是替代关系而是经常搭配使用的。首先要说清楚为什么需要规划能力LLM 默认「一口气」生成答案没有显式推理过程多步推理任务容易跳步出错规划机制就是把隐式推理过程显式化。然后要说三种机制的演进逻辑CoT 解决「要不要把推理写出来」ToT 解决「走错了方向怎么纠偏」GoT 解决「不同路径的中间结论能不能复用」每一个都是针对上一个的局限性改进。最容易被忽略的考点是工程取舍CoT 几乎零成本ToT 效果更好但典型调用次数是 CoT 的 3-5 倍具体看路径数和深度要明确说出这个数字GoT 目前学术阶段生产环境没有成熟落地。