大家好我是浩哥这是我输出AI agent面试专题第二章后面还有八期。建议加入粉丝后面粉丝可见。导语本题型考察多智能体协作设计编排/动态切换/反模式与记忆机制短/长期/压缩是 Agent 架构师的核心基本功。回答的合格线不是「背出定义」而是能在「单体 vs 多体、中心化 vs 去中心化、信息层 vs 计算层」等维度上做出有取舍的架构决策并能把记忆拆成可落地的读写闭环。2026年最新AI agent面试01_Agent基础与推理范式2026年最新AI agent面试02_MultiAgent与记忆2026年最新AI agent面试03_工具协议MCP_A2A_FC2026年最新AI agent面试04__工具工程网关外部2026年最新AI agent面试05_RAG基础应用2026年最新AI agent面试06_RAG文档与检索2026年最新AI agent面试07_大模型架构基础2026年最新AI agent面试08_大模型训练评测2026年最新AI agent面试09_AI编程ClaudeCode2026年最新AI agent面试10_通信与行业动态总目录可见 2026年最新AI agent面试0概述篇Q1. 什么是 Multi-Agent单体 Agent 遇到瓶颈时为什么、何时该上 Multi-Agent 来源字节 京东核心答案Multi-Agent 是指由多个职责单一的 Agent 协作完成复杂任务的系统范式本质是用「团队作战」替代「单打独斗」每个 Agent 只负责一类职能检索/分析/编码/评审做完即退出彼此通过上下文传递衔接。它诞生于单体 Agent 的两类硬约束其一是Context 窗口上限长任务中早期决策与资料会被「挤出桌面」导致遗忘其二是单点能力过载一个 Agent 同时承担需求、编码、测试、文档精力分散且缺乏隔离性任何一环出错整条链路卡死。Multi-Agent 通过专业分工让每个 Worker 的 Context 干净、专注并通过子任务并行压缩整体时延。但选型的第一原则仍是「能单不双」——只有当任务确实超出单体边界过长/信息过载、需要多种专业能力、存在可并行的独立子任务时引入多体才划算为「显得高级」而上 Multi-Agent 只会增加维护成本而无收益。关键点 / 展开单体瓶颈三信号① 任务过长或信息量大context 撑爆开始遗忘② 不同阶段需要截然不同的专业能力单 Agent 件件不精③ 存在多个可并行的独立子任务但单 Agent 只能串行。Multi-Agent 的核心收益Context 隔离每个 Worker 只装本职信息、专业分工专人专事、子任务并行如编码与测试框架可同时推进。架构师级取舍先问「单体能搞定吗」→ 流程清晰、适中复杂度的任务用单体链路透明、好排障再问「能否接受行为不可控」→ 生产环境几乎必答「不能」故走可控的中心化编排。反模式把「会调用 LLM 的几个函数」包装成多 Agent 但无真实分工本质是伪多体以及「为了用而用」导致通信开销与调试成本远超收益。常见追问那是不是 Context 窗口做大到 200 万 token 就不需要 Multi-Agent 了答Context 解决容量不解决专业度与隔离性长链路下注意力稀释与单点故障仍在分工价值不依赖窗口大小。单体到多体的拆分粒度怎么定按什么维度切 Worker2026 延伸可对照 Anthropic 公开的 multi-agent research system 经验——其结论正是「把检索/阅读等重负载丢给 subagents主 Agent 只保留 orchestration能显著降低主上下文污染」Google 的 ADK 与 A2AAgent2Agent协议、Microsoft AutoGen 也都在工程化这一范式。Q2. Multi-Agent 的两种拓扑中心化 Orchestrator vs 去中心化 Peer-to-Peer如何取舍 来源京东核心答案Multi-Agent 的拓扑只有两类。中心化Orchestrator 模式由一个「总调度员」统一负责拆解大目标 → 把子任务分派给 Worker → 收集产出拼成最终答案Worker 无状态、只做本职、做完即退。去中心化Peer-to-Peer则没有调度者多个 Agent 通过共享消息队列或状态空间自行协商、直接通信。生产环境几乎一律选中心化因为可控、可追踪、出问题能沿调度链路精准定位去中心化虽理论上更「自治灵活」但工程上会同时暴露「任务分配无协调、执行顺序无保证、失败无感知、完成无确认」四类问题因此主要停留在学术探索「AI 能否自主协调」的层面。关键点 / 展开Orchestrator 三职责读懂用户大目标并拆解按能力把子任务路由给对应 Worker聚合各 Worker 结果。它本身不做具体工作是架构中的「项目经理」。Worker 设计纪律不知道整体任务、不知道其他 Worker 在做什么、只接本职指令、返回结果后退出——由此保证 Context 干净、职责清晰、故障隔离。去中心化的真实代价无统筹导致重复劳动A、B 搜重叠内容、汇合点无信号C 不知 A/B 何时算完、局部失败无人感知系统甚至不知道结果不完整。类比「无 PM 的团队交付物互不兼容且没人知道进度」。选型对比维度架构师应张口即来架构复杂度、Context 压力、专业能力、并行能力、可控性、调试难度、工程实用性、适用场景——中心化在可控性/调试/实用性上全面占优。反模式在去中心化里指望「Agent 自己协调好一切」而不设完成信号与失败兜底或在中心化里让 Orchestrator 既调度又干活重新制造单点瓶颈。常见追问中心化 Orchestrator 本身会不会成为瓶颈或单点故障如何缓解有没有半中心化/分层的折中如多级 Orchestrator什么场景需要2026 延伸LangGraph 的 StateGraph 即中心化共享状态思路的落地Google A2A 协议与 Anthropic/OpenAI 的 agent 协作范式都把「可控编排 标准化 Agent 间消息」作为生产优先项印证中心化的工程主流地位。Q3. 多 Agent 之间如何协作「切换/路由」的动态机制怎么设计 来源字节跳动核心答案协作解决「Agent 做完后结果怎么传给下一个」与「下一步该叫谁接棒」两件事分协作机制与切换机制两层。协作有两种范式消息传递Agent 把结果发到消息队列下游订阅取用强解耦但需消息中间件与共享状态所有 Agent 读写同一状态对象如 LangGraph 的 State前序写入后序直读依赖强时更直接。切换即「路由决策」由 Orchestrator 承担分静态路由规则写死「含搜索→Researcher」与动态路由把任务上下文交给 LLM 实时判断下一步交谁。工程上最稳健的是混合路由主流程用静态路由保稳定可预测仅边缘/未匹配规则的异常路径交给 LLM 动态决策兜底二者互补。关键点 / 展开协作模式对比消息传递像「发邮件」发送方不知谁接收、接收方不知谁发送解耦清晰、部署成本略高共享状态像「共享白板」所有部门盯同一块板依赖关系强时更直接、可追溯。选型原则步骤间强前后依赖 → 共享状态要求 Agent 互相不感知、独立并行 → 消息传递。静态路由类工厂流水线确定性强、好调试、零额外 LLM 调用缺陷是覆盖不了未预定义路径。动态路由LLM 基于「当前任务 已完成 可用 Agent 列表」做选择灵活能兜异常代价是每次多一次 LLM 调用延迟成本且偶发路由错误、可预测性下降。反模式① 通信冗余——中心化里 Workers 互发消息绕开 Orchestrator破坏可追踪性② 无限循环——动态路由无终止条件Agent A→B→A 反复横跳③ 全量动态路由把每条确定性切换都交给 LLM成本与时延失控。常见追问如何给动态路由加「终止条件」和「循环检测」防止无限切换消息传递与共享状态能否在同一系统混用边界怎么划2026 延伸Microsoft AutoGen 的 GroupChat/Conversation 与 CrewAI 的 Flow 都提供了「消息传递 角色路由」的编排原语Google A2A 进一步把 Agent 间消息标准化为跨厂商协议是动态协作在生产落地的重要基础设施。Q4. Agent 的记忆机制分哪几层各层怎么定位 来源淘天核心答案记忆机制把 Agent 从「单次问答工具」变成「真正助手」按从最短暂到最持久可分为四层感知记忆当次输入的原始内容仅一次调用生命周期、短期记忆context window 里的 messages 列表维持当前任务完整状态、长期记忆向量/关系数据库中的持久化信息靠语义检索召回、实体记忆从对话中结构化抽取的关键事实与字段如「用户偏好 Python、预算 5 万」。设计记忆模块要回答三个工程问题——存什么按「下次任务开始时知道它是否做得更好」判断偏好/关键结论/外部知识值得存中间推理与闲聊不存、怎么存按信息类型选介质语义类进向量库、结构化偏好进关系库/KV、何时取主动检索注入 system prompt 按需检索封装成 Tool 让 Agent 自决。关键点 / 展开四层横向对比面试必背表感知记忆当次输入/极小/单次调用/即时短期记忆context window/受 token 限/一次任务/直接读长期记忆向量或关系库/无限/持久/语义检索实体记忆结构化存储/无限/持久/精确查询。分层目的短期管「当下任务不翻车」长期与实体管「跨任务攒经验」感知是模型接收外部信息的入口。存什么的判断标准「这条信息下次任务开始时如果知道会让 Agent 做得更好吗」——是则存否则是噪音会稀释检索信噪比。混合存储是主流结构化偏好字段用关系库精确查非结构化知识与历史用向量库语义检索两者配合而非一刀切全进向量库。召回策略组合session 开始主动检索用户画像注入 system prompt执行中把「查记忆」封装成 Tool 按需触发避免长上下文常驻。常见追问实体记忆和长期记忆会不会冗余什么时候该抽实体、什么时候直接存原文语义检索召回不准召回噪声/漏召怎么治2026 延伸Mem0、Zep图谱化记忆、LangMem 等专用 Agent Memory 层已把「分层记忆 自动抽取实体 语义/精确混合检索」产品化可结合这类方案谈工程落地而非自研全部链路。Q5. Agent 的长短期记忆系统具体怎么落地存储、粒度、读写闭环 来源鹅厂 淘天核心答案长短期记忆用两层解决两类不同问题。短期记忆即每次调 LLM 传入的 messages 列表rolecontent维护一个追加式列表每次调用带完整历史以保任务状态任务结束即清空——代价是随步骤增长终将撑爆 context。长期记忆以向量数据库 Embedding 为核心写入时把内容转向量与原文、元数据一并存储召回时把查询也转向量、按语义距离取 top-k 注入 prompt实现「跨任务」语义级记忆。关键的工程细节是粒度——太细则检索碎片化偏好被拆成多条只命中部分、太粗则命中噪声大两千 token 里仅百字相关合理粒度是「一次完整交互」或「一个独立知识点/事件」。两层通过「读→用→写」闭环配合任务前主动读长期记忆注入 system prompt执行中靠短期记忆保持连贯结束后把新结论/偏好写回长期与实体记忆。关键点 / 展开短期记忆实现要点是「工作台」不是「最新一条」每次传完整 messagesrole 分 user/assistant/tool 三类任务结束 clear() 释放。长期记忆实现要点Embedding 把文字变高维向量语义相近→向量距离近向量库做相似度检索类比图书馆索引卡存向量(索引)原文(返回)metadata(时间/类型/重要度)。粒度三档细每句一条碎片化、易漏、粗整次任务一条噪声大、干扰 LLM、合理一次交互或一知识点信息完整且检索聚焦。读→用→写闭环① 读——任务前用描述检索长期记忆 取实体偏好拼进 system prompt 顶部② 用——执行中短期记忆全程承载必要步骤把「查记忆」封装为 Tool 按需召回③ 写——任务后把新偏好更新实体字段、把有价值结论摘要 embedding 入库再清空短期记忆。反模式把短期记忆当长期用不落库导致跨任务失忆长期记忆粒度不加管控导致检索信噪比崩塌每次都把全部历史无条件注入 prompt 造成 context 浪费。常见追问长期记忆写入时如何判定「这条值得存」谁来触发写模型自决还是规则多用户/多会话场景下长期记忆如何隔离与权限控制2026 延伸生产系统常把短期记忆的 State 用 LangGraph Checkpointer 持久化、长期记忆接 Mem0/Zep 这类托管层并配合 Prompt Caching 降低重复前缀的计算开销——记忆系统正从「手搓 messages Chroma」走向「编排框架 专用记忆服务」的分层架构。Q6. Agent 记忆压缩通常有哪些方法 来源腾讯核心答案记忆压缩的本质是在「空间有限、成本有压力」下保关键信息、减 token 占用常见四类方法从三个不同维度解决问题滑动窗口只保留最近 N 轮最粗糙、零额外开销但硬截断、摘要压缩丢弃前先让 LLM 总结成精华损失细节但保脉络、重要性过滤按价值而非时间打分筛选规则打分快但粗、LLM 打分准但贵、结构化抽取把事实/状态抽成结构化字段存储信息损失最小、信息密度最高但开发成本最高。工程上最常用且稳健的组合是「滑动窗口 摘要」窗口控总长度、摘要在丢弃前提炼关键信息避免硬截断。此外还有一个互补的计算层手段Prompt CachingClaude/OpenAI 已支持对多次请求间相同的前缀缓存 prefill 结果降延迟降成本至约十分之一——它与信息层压缩解决不同问题可叠加使用。关键点 / 展开方法维度归并滑动窗口/摘要压缩解决「历史太长怎么截」前者直接截、后者截前先提炼重要性过滤解决「内容不等价怎么挑」打破时间序按价值结构化抽取解决「对话文本是否最佳载体」换更高效载体。组合使用先重要性过滤筛低价值 → 摘要压缩处理剩余 → 对关键类型做结构化抽取多法配合而非互斥。重要性打分两路规则打分含「决定/确认/需求」关键词加分、被引用次数加分、闲聊降分快但有边界误判LLM 打分逐条判断更准但每条一次调用适合批量清理而非实时。结构化抽取类比病历卡不存对话原文而存「主诉/诊断/用药」结构化字段信息密度远高于原文、下次直接读字段。Prompt Caching 定位信息层压缩管「哪些内容进历史」计算层缓存管「已决定进的内容少重复算」二者互补不替代。反模式只用滑动窗口做「金鱼记忆」式硬截断丢关键决策为保细节不做任何压缩导致成本与遗忘双失控把摘要当唯一真相源却不保留原文兜底细节回溯无能。常见追问摘要压缩会丢细节如何设计「摘要 原文索引」的两级结构以便回溯长对话场景下Prompt Caching 与记忆压缩的边界如何划分、如何一起收益最大化2026 延伸Anthropic 与 OpenAI 均已将 Prompt Caching 作为降低长上下文成本的一等能力结合「自动压缩 分层记忆Mem0/Zep」是当前生产 Agent 控制 context 成本的主流组合腾讯笔记中「信息层 vs 计算层」的二分法与此完全一致。 本题型速记 Checklist单体 vs 多体先问「单体能搞定吗」流程清晰、适中复杂度用单体不要为炫技上多体。单体瓶颈三信号context 撑爆、需多专业能力、有可并行子任务——命中才上 Multi-Agent。拓扑二选一中心化 Orchestrator可控可追踪vs 去中心化 Peer-to-Peer学术为主生产默认中心化。Orchestrator 纪律只调度不干活Worker 无状态、只做本职、做完即退保证 Context 干净与故障隔离。协作两范式消息传递解耦、需中间件vs 共享状态强依赖更直接如 LangGraph State。切换两策略静态路由规则、稳、零额外调用为主动态路由LLM 决策、灵活、贵兜底边缘混合最稳。三大反模式必提无限循环路由无终止、通信冗余Worker 绕开 Orchestrator 互发、伪多体有壳无分工。记忆四层感知 / 短期(context) / 长期(向量库语义检索) / 实体(结构化字段)由短到长。记忆三问存什么下次有用才存、怎么存结构化用关系库、语义用向量库、何时取主动注入 按需 Tool。长短期落地短期messages 列表用完清长期Embedding向量库语义召回粒度取「一次交互/一知识点」忌过细碎片化与过粗噪声化。读写闭环任务前读、执行中用、结束后写形成「读→用→写」记忆积累飞轮。压缩四法 一缓存滑动窗口 / 摘要压缩 / 重要性过滤 / 结构化抽取常配「窗口摘要」另上 Prompt Caching 在计算层降本信息层与计算层互补不替代。