7、记忆、MCP 与多智能体
Q7-1. 上下文窗口、短期记忆、长期记忆分别是什么关系？
上下文窗口是模型单次推理能看到的内容上限，短期记忆是会话级状态，长期记忆是跨会话保留的用户或任务信息。
工程上不能把这三者混为一谈。窗口是昂贵资源，不能无限塞历史。短期记忆一般保留当前任务相关历史、摘要、线程状态。长期记忆则更适合存偏好、画像、历史结论和可复用事实，需要按需检索，不应该每次全量放进 prompt。
所以一个成熟的系统通常是：窗口里只放高信号上下文，短期记忆保证当前线程不断档，长期记忆通过数据库或向量库按需召回。
常见追问：
- 记忆和 RAG 的区别是什么？
- 为什么说记忆不是训练模型？
- Redis 在记忆里适合做什么？
- 如果上下文太长被截断了，你会选滑动窗口、摘要压缩还是检索式补充？怎么判断？
重要度：必刷（出现次数：3次） | 难度：中等
**考察点：**对话系统和 Agent 的状态设计能力。
对应章节：16 记忆与对话历史 §1、记忆简介；25 LangGraph高级特性 §2、状态持久化（Persistence）
Q7-2. 如何为 Agent 设计短期记忆和长期记忆系统？技术上通常怎么落地？
先把“记忆”拆成两层，不然很容易把所有信息都塞进上下文，最后变成又贵又乱。
- 短期记忆：解决当前会话或当前线程不断档的问题，核心是“读历史 -> 拼进提示 -> 调模型 -> 写回历史”。
- 长期记忆：解决跨会话保留用户偏好、画像、历史结论和可复用事实的问题，核心是“存结构化信息，按需召回”，而不是每轮全量塞进 prompt。
技术上，短期记忆常见做法是把消息历史或线程状态持久化到内存、Redis 或 checkpointer 里，再通过 MessagesPlaceholder 或图状态在下一轮重新注入；长期记忆更适合放在数据库、向量库，或者在关系很重要的场景里放进知识图谱。一个比较稳的工程思路是：短期记忆服务当前任务连续性，长期记忆服务跨任务复用，二者分开设计。
在 LangChain / LangGraph 体系下，RunnableWithMessageHistory + BaseChatMessageHistory 更适合理解为“对话历史注入”，而 LangGraph persistence / checkpointer 更适合理解为线程级状态持久化。前者更适合先把“历史消息怎么读写”讲明白，后者更适合 Agent、图编排和线程级状态管理。
因此，真正落地时通常这样划分：
- 聊天助手或轻量多轮问答：优先消息历史方案。
- 复杂 Agent 或 LangGraph：优先
thread_id + checkpointer方案。 - 跨会话偏好、事实、用户画像：走长期存储，按需检索，不直接硬塞上下文。
如果继续追问“超长多轮对话如何兼顾不断档和节省 token”，通常还会补充四种常见手段：
- 滑动窗口：只保留最近 N 轮原文，简单直接，但容易丢早期约束。
- 周期性摘要：每隔几轮把历史压成结构化总结，保留目标、已确认事实、待办和偏好。
- 检索式补充：把旧对话写入向量库或长期存储，按当前问题召回相关片段，而不是把所有旧消息都塞回窗口。
- 结构化记忆槽：像城市、会员等级、偏好、关键状态这类固定信息直接落键值或数据库，不让模型每次“回忆”。
所以记忆系统不是“历史保存得越多越好”，而是要区分什么该原样保留，什么该摘要，什么该结构化，什么该按需检索。
常见追问：
RunnableWithMessageHistory和 LangGraph persistence / checkpointer 怎么理解各自的定位？- Redis 更适合拿来做短期记忆持久化，还是长期记忆？
重要度：高频（出现次数：2次） | 难度：较难
**考察点：**记忆分层设计能力，以及对短期状态、长期知识、外部存储边界的理解。
对应章节：16 记忆与对话历史 §4、RunnableWithMessageHistory 与 BaseChatMessageHistory；25 LangGraph高级特性 §2、状态持久化（Persistence）
Q7-3. 什么是 MCP？它解决的核心问题是什么？它和 Tool、RAG、Agent 有什么区别？
如果先给一句定义，MCP 是 Model Context Protocol，也就是模型上下文协议。它是一套开放标准，用来规范 AI 应用如何以统一方式连接外部工具、资源和提示模板。
MCP 本质上是在做“模型能力接入的统一协议层”，解决的不是“模型能不能调工具”，而是“不同 AI 应用怎样用统一方式接外部工具、资源和上下文”。
更直观的理解是，MCP 最适合被看成 AI 世界的统一插口。它统一的不是模型本身，而是 Host、Client、Server 之间发现、暴露和调用能力的方式。MCP Server 不只会暴露 Tools，还可以暴露 Resources 和 Prompts。
- Tool / Function Calling：解决模型如何表达“我要调用哪个工具、传什么参数”。
- RAG：解决模型如何拿到外部知识。
- Agent：解决谁来规划、决策、调用这些能力。
- MCP：解决这些外部能力如何被标准化暴露和接入。
所以 MCP 不等于 Agent，也不等于 Tool。它更偏协议和生态层，价值在于一次暴露、多处复用、统一 schema、降低接入成本。
常见追问：
- MCP Server 通常暴露哪些能力？
- STDIO 和 HTTP 传输怎么选？
- 为什么企业会关心 MCP？
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**协议层理解能力。
对应章节：20 MCP模型上下文协议 §2、MCP 简介；20 MCP模型上下文协议 §3、MCP 能做什么
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q7-4. MCP 和 Function Calling 的关系是什么？
Function Calling 更接近模型侧的“结构化调用机制”，MCP 更接近应用侧的“统一能力接入协议”。
前者解决的是模型如何表达“要调用哪个函数、传什么参数”；后者解决的是不同外部工具、资源、提示模板如何用统一标准暴露给客户端。两者不是替代关系，而是上下层关系。
可以简单理解为：Function Calling 更靠近模型决策，MCP 更靠近生态接入和协议标准化。真正落地时，Agent 完全可以在 MCP 暴露的能力之上继续用 Function Calling 做调用决策。
重要度：高频（出现次数：1次） | 难度：中等
**考察点：**协议层和调用机制的边界理解。
对应章节：20 MCP模型上下文协议 §2、MCP 简介；17 Tools工具调用 §2、工具调用的工作方式
Q7-5. MCP 是如何做到跨平台兼容的？
MCP 的跨平台兼容，本质上来自“统一协议，而不是统一实现”。
也就是说，不同平台、不同语言、不同宿主程序，只要都遵循同一套消息结构、能力暴露方式和调用约定，就能在协议层互通。这样客户端不需要为每一个外部系统写一套私有接入方式，服务端也能按标准暴露能力。
所以 MCP 的价值不在于它绑定了某个技术栈，而在于它把接入差异收敛成了统一的协议面。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**协议标准化的理解。
对应章节：20 MCP模型上下文协议 §5、MCP 架构知识
Q7-6. MCP 技术协议的主体内容是什么？
如果从协议层展开，MCP 的主体内容按四层来讲最清楚：
- 参与角色：Host、Client、Server。
- 能力类型：Tools、Resources、Prompts。
- 通信机制：能力发现、请求、响应、错误、通知。
- 传输方式：stdio、Streamable HTTP 等承载协议的通道。
这里还需要补充一句细节：
- Tools 更偏 model-controlled，适合让模型自动决定要不要调用。
- Resources 更偏 application-driven，通常由宿主决定如何纳入上下文。
- Prompts 更偏 user-controlled，适合复用提示模板或工作流模板。
这样答出来，面试官通常能看出你理解的是协议本身，而不是只把 MCP 当成某个“现成插件市场”。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解 MCP 协议层的基本构成。
对应章节：20 MCP模型上下文协议 §5、MCP 架构知识；20 MCP模型上下文协议 §3、MCP 能做什么
Q7-7. MCP 服务器开发流程是什么？
一个 MCP Server 的典型开发流程通常是：
- 明确要暴露的能力边界，是工具、资源还是提示模板。
- 定义输入输出 schema 和错误处理方式。
- 选择传输方式，比如 STDIO 或 HTTP。
- 实现服务端逻辑，并补齐鉴权、日志、超时和异常处理。
- 在客户端完成注册、发现、调用和联调测试。
工程上最容易被忽略的是能力边界和错误处理。MCP Server 不是简单把现有 API 套一层壳，而是要把能力设计成真正适合模型消费的接口。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**是否理解 MCP 不只是“会用”，还包括服务端建设。
对应章节：20 MCP模型上下文协议 §4、怎么用 MCP；20 MCP模型上下文协议 §6、案例实战：本地 MCP 天气服务与客户端
Q7-8. Agent 应该如何接入 MCP 工具？
Agent 接入 MCP 工具，核心是把 MCP 暴露出来的能力纳入自己的工具注册和调度体系。
通常的思路是：
- 先发现 MCP Server 暴露的工具或资源。
- 再把这些能力转换成 Agent 能消费的工具描述和 schema。
- 在执行时让模型决定何时调用，宿主负责真正发起 MCP 请求。
- 把结果回传给 Agent，进入下一轮决策。
真正的关键不在“接通”，而在“如何保证接通之后仍然可控”，包括权限、超时、失败重试、观测和审计。
常见追问：
- MCP 在你的架构里是只做权限检查，还是会和环境级安全沙箱一起工作？
- 如果已经有 MCP，为什么还需要容器、只读挂载或系统级隔离？
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**Agent 架构与 MCP 的结合方式。
对应章节：20 MCP模型上下文协议 §4、怎么用 MCP；20 MCP模型上下文协议 §6、案例实战：本地 MCP 天气服务与客户端
Q7-9. MCP 的流式 HTTP 传输核心优势是什么？
流式 HTTP 的核心价值，是让结果可以边产生边返回，而不是必须等整次调用结束后一次性返回。
这样做有三个直接好处：
- 降低首包延迟，用户更快看到反馈。
- 支持长任务的中途进度回传，减少“卡死感”。
- 更利于宿主做取消、超时和部分结果处理。
对于 Agent 或研究型任务，这种能力尤其重要，因为很多调用本来就不是“瞬时完成”的。
重要度：中频（出现次数：1次） | 难度：中等
**考察点：**流式协议在体验和并发上的价值理解。
对应章节：20 MCP模型上下文协议 §5、MCP 架构知识
Q7-10. MCP 调用如何保证并发？
MCP 并发能力不只是协议本身决定的，更取决于宿主和服务端如何设计请求处理模型。
要保证并发，通常要关注：
- 请求是否有唯一标识，避免响应错配。
- 服务端是否支持并行处理，而不是串行阻塞。
- 工具执行是否有超时、限流和优先级控制。
- 客户端是否能正确管理多请求上下文。
如果底层工具本身很慢，协议再好也救不了，所以并发治理要看“协议层 + 服务层 + 工具层”三层一起设计。
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**高并发调用下的协议和宿主设计能力。
对应章节：20 MCP模型上下文协议 §5、MCP 架构知识
Q7-11. A2A 和 MCP 的区别是什么？什么时候需要多智能体？
MCP 更关注“模型和外部能力怎么接”，A2A 更关注“Agent 和 Agent 之间怎么协作”。
前者偏工具与资源接入标准，后者偏多智能体通信和分工协作。如果系统只是需要接搜索、数据库、文件系统，MCP 的价值更明显；如果系统已经演化出多个角色明确、职责分离的 Agent，比如规划、检索、执行、审阅各自独立，那么 A2A 或多智能体编排才有意义。
多智能体不是越早越好。任务如果单 Agent 就能清晰处理，多智能体只会增加通信、调试和治理成本。只有在职责边界清晰、单 Agent prompt 已经过载、流程确实需要角色分治时，拆分才划算。
常见追问：
- Supervisor 和 Handoff 怎么选？
- 多智能体最常见的失败点是什么？
- 什么情况下 Skill 比独立 Agent 更合适？
- A2A 和 LangGraph 这类应用内编排框架、普通 Agent 框架的边界到底是什么？
- Agent Skills 和 Tool、独立 Agent 的边界怎么理解？什么时候更适合做成 Skill 而不是再拆一个 Agent？
重要度：中频（出现次数：1次） | 难度：较难
**考察点：**协议边界和系统拆分能力。
对应章节：26 LangGraph多智能体与A2A §1、A2A 协议与多智能体架构；26 LangGraph多智能体与A2A §2、Supervisor 与 Handoff；26 LangGraph多智能体与A2A §3、Skills 与多智能体的边界；27 Agent Skills智能体技能与AI编程工具实践
**来源：**腾讯AI后台工程师一面（实际大厂面试题）
Q7-12. 有哪些热门的 MCP 工具？
常见受关注的 MCP 工具通常集中在几类：
- 浏览器自动化类，比如 Playwright。
- 数据与后端类，比如数据库、Supabase 一类服务。
- 文件与代码类，比如本地文件系统、代码库。
- 搜索与知识类，比如网页搜索、知识库检索。
面试里更重要的不是背全名字，而是知道为什么这些工具受欢迎：因为它们覆盖了 Agent 最常见的外部能力需求。
重要度：低频（出现次数：1次） | 难度：基础
**考察点：**对 MCP 生态有基本了解，但不要求死记硬背。