企业官网建设流程全解析

大家好，我是浩哥，这是我输出AI agent面试专题第二章，后面还有八期。建议加入粉丝，后面粉丝可见。

导语：本题型考察多智能体协作设计（编排/动态切换/反模式）与记忆机制（短/长期/压缩），是 Agent 架构师的核心基本功。回答的合格线不是「背出定义」，而是能在「单体 vs 多体、中心化 vs 去中心化、信息层 vs 计算层」等维度上做出有取舍的架构决策，并能把记忆拆成可落地的读写闭环。

• 2026年最新AI agent面试（01）_Agent基础与推理范式
• 2026年最新AI agent面试（02）_MultiAgent与记忆
• 2026年最新AI agent面试（03）_工具协议MCP_A2A_FC
• 2026年最新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编程ClaudeCode
• 2026年最新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 但无真实分工，本质是伪多体；以及「为了用而用」，导致通信开销与调试成本远超收益。
• 常见追问：
  1. 那是不是 Context 窗口做大到 200 万 token 就不需要 Multi-Agent 了？（答：Context 解决容量不解决专业度与隔离性，长链路下注意力稀释与单点故障仍在，分工价值不依赖窗口大小。）
  2. 单体到多体的拆分粒度怎么定？按什么维度切 Worker？
• 2026 延伸：可对照 Anthropic 公开的 multi-agent research system 经验——其结论正是「把检索/阅读等重负载丢给 subagents，主 Agent 只保留 orchestration，能显著降低主上下文污染」；Google 的 ADK 与 A2A（Agent2Agent）协议、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 既调度又干活，重新制造单点瓶颈。
• 常见追问：
  1. 中心化 Orchestrator 本身会不会成为瓶颈或单点故障？如何缓解？
  2. 有没有半中心化/分层的折中（如多级 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，成本与时延失控。
• 常见追问：
  1. 如何给动态路由加「终止条件」和「循环检测」防止无限切换？
  2. 消息传递与共享状态能否在同一系统混用？边界怎么划？
• 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 按需触发，避免长上下文常驻。
• 常见追问：
  1. 实体记忆和长期记忆会不会冗余？什么时候该抽实体、什么时候直接存原文？
  2. 语义检索召回不准（召回噪声/漏召）怎么治？
• 2026 延伸：Mem0、Zep（图谱化记忆）、LangMem 等专用 Agent Memory 层已把「分层记忆 + 自动抽取实体 + 语义/精确混合检索」产品化；可结合这类方案谈工程落地而非自研全部链路。

Q5. Agent 的长短期记忆系统具体怎么落地（存储、粒度、读写闭环）？ ［来源：鹅厂 + 淘天］

• 核心答案：长短期记忆用两层解决两类不同问题。短期记忆即每次调 LLM 传入的 messages 列表（role+content），维护一个追加式列表，每次调用带完整历史以保任务状态，任务结束即清空——代价是随步骤增长终将撑爆 context。长期记忆以向量数据库 + Embedding 为核心：写入时把内容转向量与原文、元数据一并存储，召回时把查询也转向量、按语义距离取 top-k 注入 prompt，实现「跨任务」语义级记忆。关键的工程细节是粒度——太细则检索碎片化（偏好被拆成多条只命中部分）、太粗则命中噪声大（两千 token 里仅百字相关）；合理粒度是「一次完整交互」或「一个独立知识点/事件」。两层通过「读→用→写」闭环配合：任务前主动读长期记忆注入 system prompt，执行中靠短期记忆保持连贯，结束后把新结论/偏好写回长期与实体记忆。
• 关键点 / 展开：
  • 短期记忆实现要点：是「工作台」不是「最新一条」，每次传完整 messages；role 分 user/assistant/tool 三类；任务结束 clear() 释放。
  • 长期记忆实现要点：Embedding 把文字变高维向量，语义相近→向量距离近；向量库做相似度检索（类比图书馆索引卡）；存向量(索引)+原文(返回)+metadata(时间/类型/重要度)。
  • 粒度三档：细（每句一条，碎片化、易漏）、粗（整次任务一条，噪声大、干扰 LLM）、合理（一次交互或一知识点，信息完整且检索聚焦）。
  • 读→用→写闭环：① 读——任务前用描述检索长期记忆 + 取实体偏好，拼进 system prompt 顶部；② 用——执行中短期记忆全程承载，必要步骤把「查记忆」封装为 Tool 按需召回；③ 写——任务后把新偏好更新实体字段、把有价值结论摘要 embedding 入库，再清空短期记忆。
  • 反模式：把短期记忆当长期用（不落库导致跨任务失忆）；长期记忆粒度不加管控导致检索信噪比崩塌；每次都把全部历史无条件注入 prompt 造成 context 浪费。
• 常见追问：
  1. 长期记忆写入时如何判定「这条值得存」？谁来触发写（模型自决还是规则）？
  2. 多用户/多会话场景下长期记忆如何隔离与权限控制？
• 2026 延伸：生产系统常把短期记忆的 State 用 LangGraph Checkpointer 持久化、长期记忆接 Mem0/Zep 这类托管层，并配合 Prompt Caching 降低重复前缀的计算开销——记忆系统正从「手搓 messages + Chroma」走向「编排框架 + 专用记忆服务」的分层架构。

Q6. Agent 记忆压缩通常有哪些方法？ ［来源：腾讯］

• 核心答案：记忆压缩的本质是在「空间有限、成本有压力」下保关键信息、减 token 占用，常见四类方法从三个不同维度解决问题：滑动窗口（只保留最近 N 轮，最粗糙、零额外开销但硬截断）、摘要压缩（丢弃前先让 LLM 总结成精华，损失细节但保脉络）、重要性过滤（按价值而非时间打分筛选，规则打分快但粗、LLM 打分准但贵）、结构化抽取（把事实/状态抽成结构化字段存储，信息损失最小、信息密度最高但开发成本最高）。工程上最常用且稳健的组合是「滑动窗口 + 摘要」：窗口控总长度、摘要在丢弃前提炼关键信息，避免硬截断。此外还有一个互补的计算层手段Prompt Caching（Claude/OpenAI 已支持）：对多次请求间相同的前缀缓存 prefill 结果，降延迟降成本至约十分之一——它与信息层压缩解决不同问题，可叠加使用。
• 关键点 / 展开：
  • 方法维度归并：滑动窗口/摘要压缩解决「历史太长怎么截」（前者直接截、后者截前先提炼）；重要性过滤解决「内容不等价怎么挑」（打破时间序按价值）；结构化抽取解决「对话文本是否最佳载体」（换更高效载体）。
  • 组合使用：先重要性过滤筛低价值 → 摘要压缩处理剩余 → 对关键类型做结构化抽取，多法配合而非互斥。
  • 重要性打分两路：规则打分（含「决定/确认/需求」关键词加分、被引用次数加分、闲聊降分，快但有边界误判）；LLM 打分（逐条判断更准，但每条一次调用，适合批量清理而非实时）。
  • 结构化抽取类比病历卡：不存对话原文，而存「主诉/诊断/用药」结构化字段，信息密度远高于原文、下次直接读字段。
  • Prompt Caching 定位：信息层压缩管「哪些内容进历史」，计算层缓存管「已决定进的内容少重复算」，二者互补不替代。
  • 反模式：只用滑动窗口做「金鱼记忆」式硬截断丢关键决策；为保细节不做任何压缩导致成本与遗忘双失控；把摘要当唯一真相源却不保留原文兜底（细节回溯无能）。
• 常见追问：
  1. 摘要压缩会丢细节，如何设计「摘要 + 原文索引」的两级结构以便回溯？
  2. 长对话场景下，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 在计算层降本，信息层与计算层互补不替代。