Agent、RAG、LLM工具调用相关面试总结

Agent 相关面试总结
RAG 相关面试总结
LLM 工具调用相关面试总结

Agent 相关面试总结

1. 什么是Agent?与大模型有什么本质不同?

Agent 是基于大模型构建的具备“自主决策 + 工具调用 + 任务执行能力”的系统。
大模型本质是“输入-输出的函数”，而 Agent 是“能思考、能行动、能迭代执行的系统”。

Agent 的核心运作闭环：感知 -> 规划 -> 行动 -> 再感知

回答注意点：

Agent 有自主规划能力
Agent 能行动，通过工具调用跟外部世界交互
Agent 有闭环

2. Agent 的基本架构由哪些核心组件构成?

Agent 的四个基本组件：

LLM（推理核心）
Tools（外部能力扩展）
Memory（短期/长期记忆）
Planner / Controller（任务调度与决策）

详见：Agent架构详解

3. Workflow，Agent，Tools 这三个的概念和区别介绍一下?

Workflow：预定义流程编排（固定链路）
Agent：动态决策执行（不固定流程）
Tools：能力接口（如搜索、DB、API）

总结：

Workflow = 人设计流程
Agent = 模型自己决定流程
Tools = Agent 的手脚

4. 了解哪些其他的 Agent 设计范式? Agent 和 Workflow 的区别是什么?

常见的Agent设计范式：

ReAct（Reasoning + Acting）
Plan-and-Execute（先规划后执行）
Reflection（反思机制）
Multi-Agent（多Agent协作）

Agent 和 Workflow 的区别：

维度	Workflow	Agent
决策者	开发者（硬编码流程）	LLM（动态决策）
确定性	高，行为可预测	低
灵活性	低	高
调试难度	容易，链路清晰	困难，行为不确定
适用场景	流程相对固定的业务	需要灵活判断的复杂任务

真正的工程答案是 Agentic Workflow：整体用 Workflow 编排，在需要灵活判断的节点嵌入 Agent 。

5. Agent 推理模式有哪些? ReAct 是啥?具体是怎么实现的?

推理模式： LLM 预测输出时中间推导步骤都是隐式的，无法控制和利用。推理模式就是通过不同的方式让 LLM 把隐式思考的过程显示化出来，从而减少多步推理中的累积误差。

Agent 推理模式：

CoT（Chain of Thought）：包括Zeroshot CoT 和 Fewshot CoT（带示例）
ReAct（Reasoning + Acting）：与CoT相比，多了行动步骤，LLM 可以在推理过程中调用工具。
Plan-and-Execute（先规划后执行）：分为两个阶段规划和执行，先让 LLM 输出一个整体的执行计划（分解成多个步骤），然后逐步执行每个步骤。

实现方式：

CoT：在 prompt 中加一句让我们一步步思考，LLM 就会先把推理步骤写出来，再给答案。

React：通过 prompt 格式来约束 LLM 输出思考和行动，比如：

  1
2
3
4
5
6
7
8
9
10
11
你是一个 AI 助手，可以使用以下工具：
- search(query): 搜索互联网获取最新信息
- calculator(expr): 计算数学表达式

回答时请严格按照以下格式：
Thought: 你的思考过程（分析当前情况，决定下一步）
Action: 工具名称
Action Input: 工具的输入参数
Observation: （此行由系统填入工具返回的结果，你不用写）
... 以上可以重复多轮 ...
Final Answer: 当你确定可以回答时，在这里给出最终答案

Plan-and-Execute：先让 LLM 输出一个整体的执行计划（分解成多个步骤），然后逐步执行每个步骤。

6. ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别?实际项目中该如何选型?

ReAct：边想边做（适合开放问题）
Plan-and-Execute：先规划再执行（适合复杂任务）
Reflection：执行后自我优化（适合高质量生成）

选型：

任务不复杂、流程不固定、需要实时调整 -> ReAct
任务长、容易跑偏、需要整体结构清晰 -> Plan-and-Execute
输出要求高、不能出错 -> 在前两者基础上叠加 Reflection

进阶：

动态Replan
Reflextion：总结失败原因存到记忆中，避免重蹈覆辙。

详见：Agent三大范式详解：ReAct、Plan-and-Execute、Reflection

7. 复杂任务怎么做的任务拆分?为什么要拆分?效果如何提升?

为什么拆：
LLM 的 context window 有上限，任务越大中间状态越多，越容易出错

拆分思路：

静态拆分：提前把任务流程设计好，固定成一个 Workflow
动态拆分：让 Agent 根据当前情况动态决定下一步做什么（Plan-and-Execute）
自适应拆分：执行过程中根据每一步的实际难度动态调整

拆分结果的验证标准：

完备性：拆分后的子任务能覆盖原任务的所有需求
独立性：每个子任务相对独立，减少步骤间的耦合
可验证性：每个子任务的输出都可以被验证，便于调试和优化

8. 请你介绍一下 Agent 的记忆机制，并说明在实际开发中应该如何设计记忆模块?

Agent 需要记忆以支持多步任务中保持状态、跨任务积累知识。

记忆机制分为四层：

感知记忆：当前输入的原始内容
短期记忆：context window 内的历史交互
长期记忆：外部数据库或向量数据库存储的历史信息
实体记忆：从感知信息中抽取出的对象及其属性

设计核心问题：

存什么：只存对下次任务有价值的内容，过滤噪声
怎么存：语义内容用向量数据库，结构化内容用关系数据库，混合存储
怎么用：
- 主动检索：任务开始前去检索，把结果注入 system prompt 作为背景知识
- 被动检索：Agent在推理过程中判断当前步骤需要某类特定知识时主动发起检索

详见：Agent记忆机制

9. Agent 的长短期记忆系统怎么做的?记忆是怎么存的?粒度是多少?怎么用的?

长短期记忆系统设计：

短期记忆：就是 context window 里的对话历史，存当前任务的中间状态，任务结束就清掉
长期记忆：用向量数据库，把信息 embedding 后写入，用的时候做语义检索拿回来注入 prompt

粒度设计：

通常按一次完整交互或一个关键事件为单位
太细：检索时噪声大，效率低
太粗：检索不精准，相关信息丢失

10. 什么是Multi-Agent?

Multi-Agent 是指多个 Agent 协同工作来完成一个复杂任务，每个 Agent 负责不同的子任务或角色，通过消息传递进行协作。

为什么需要 Multi-Agent：

context 窗口太小，单个 Agent 处理了复杂任务容易窗口溢出
专业度问题，单个 Agent 很难在所有领域都表现好，多个 Agent 可以分工合作

Multi-Agent 的两种组织方式：

中心化：由一个统一的调度者来分配任务、收集结果
去中心化：Agent 之间自行协商、直接通信

11. 说说 Single-Agent 和 Multi-Agent 的设计方案?

Single-Agent：适合任务流程清晰、复杂度适中的场景，实现简单，容易维护
Multi-Agent：适合任务复杂、需要多领域专业知识的场景，设计复杂，需要解决协作和通信问题

Multi-Agent 的中心化方案：

静态路由：任务拆分和分配规则事先预定好
动态规划：Orchestrator 根据当前任务状态动态决定分配给哪个 Agent
自适应编排：Orchestrator 根据每个 Agent 的实时表现动态调整分配策略

Multi-Agent 的去中心化方案的问题：

任务分配没有协调
执行顺序没有保证
失败没有感知

详见：Single-Agent与Multi-Agent

12. Agent 记忆压缩通常有哪些方法?

Agent 记忆压缩方法：

摘要压缩：用 LLM 对历史交互进行摘要总结
滑动窗口：删除最早的交互，保持最新的 N 条
重要性过滤：给每条对话打分，低于阈值的淘汰
结构化抽取：将文本信息抽取成结构化数据，减少冗余，但是通用性较低

上述方法都是在信息层进行压缩，还有一种在计算层进行压缩的方法，叫做Prompt Caching，就是：如果 prompt 的前缀部分在多次请求之间是一样的，就把这部分计算结果缓存起来，下次请求如果前缀匹配，直接复用缓存。

详见：Agent记忆压缩方法

13. 在工程实践中，为什么有时候选择「手搓」Agent，而不是直接用成熟框架?

成熟框架存在的问题：

抽象层太多，调试的时候不知道哪里出了问题
版本升级经常有破坏性变更，稳定性难以保证
框架的通用设计不一定适合特定业务场景，可能需要大量定制化开发

手搓 Agent 的优势：

完全控制权，能针对业务需求设计最合适的架构
调试更直接，问题定位更快
没有额外的框架依赖，升级和维护更灵活

14. 如何赋予 LLM 规划能力?

三种思路：

CoT：让 LLM 把推理步骤写出来，线性地一步步推导到答案
ToT：让 LLM 同时探索多条推理路径，选最优的继续深入
GoT：图结构推理，推理节点可以复用和合并，适合更复杂的任务

详见：CoT、ToT 与 GoT：大模型推理范式进化详解

15. 讲讲Agent 的反思机制?为什么要用反思?具体怎么实现?

为什么要用反思：

LLM 第一次输出不一定是最优的，加一轮自我检查能显著提升质量

反思机制实现：

靠 prompt 驱动
步骤级：每一步都进行反思
任务级：在整个任务执行完成之后做一次整体评估

16. 如何设计多Agent 的协作与动态切换机制?

协作靠两件事：

消息传递：Agent 完成工作之后把结果发出去，下一个 Agent 取用
共享状态：所有 Agent 共同读写一个对象，记录任务进展和中间结果
- 状态分层：全局状态 + Agent 本地状态
- 写入规则：只追加不覆盖
- 错误状态处理：执行失败时错误信息也应该写入状态

动态切换：

静态路由
LLM 动态规划

工程实践：主流程静态路由保底，边缘情况交给 LLM 动态决策

RAG 相关面试总结

1. 什么是 RAG ?详细描述一个完整 RAG 系统的详细工作流程?

RAG 全称是 Retrieval-Augmented Generation，就是检索增强生成。

RAG 核心思想是：
在生成答案前，先从外部知识库检索相关信息，再将检索结果注入Prompt，最后让LLM基于“问题+证据”生成答案。

RAG 主要解决的问题：

知识过期（训练截止后新知识缺失）
幻觉风险（一本正经地胡说）
私域知识不可控（企业内部文档不在训练集）

RAG 详细工作流程：

离线阶段：
1. 文档加载
2. 文档切割
3. Embedding 计算
4. 存入向量数据库
在线阶段：
1. 用户输入 Query
2. Query 预处理（Query Rewrite）
3. Query Embedding 计算
4. 向量检索Top-K（粗排）
5. Rerank（精排）
6. 拼接 prompt：用户问题 + 精排后的 chunk
7. LLM 生成

2.相比直接微调 LLM，RAG 解决了什么问题?微调和 RAG 各自的优劣势是什么?

RAG（Retrieval-Augmented Generation）本质是“检索 + 生成”，它主要解决了微调 LLM 的几个核心痛点：

知识更新问题（核心）：解决模型的“过时”问题
私有知识问题：企业内部文档不在训练集里
成本问题：微调成本高（训练 + GPU + 数据），RAG成本低（主要是索引 + 向量检索）
幻觉控制（部分解决）

微调优劣势：

优势：
- 深度融合能力
- 推理效率高
- 更稳定的输出
劣势：
- 知识更新困难
- 私有知识难以覆盖
- 成本高昂

RAG 优劣势：

优势：
- 知识更新灵活
- 可扩展性强
- 私有知识覆盖好
- 成本较低
- 可解释性强
劣势：
- 强依赖检索质量
- 上下文窗口限制
- 推理效率较低
- 不能改变模型能力

3. RAG 文档切割(Chunking)策略?

原始文档不能直接存进向量数据库，因为向量模型输入长度限制，而且上下文太长会平均信息，所以必须先切成小块（chunk）再存。

每条 chunk 记录的结构：id + text + embedding + metadata
示例：

{
  "id": "chunk_001",
  "text": "Java是一种面向对象的编程语言，广泛用于后端开发...",
  "embedding": [0.12, -0.98, 0.33, ...],
  "metadata": {
    "source": "java_book.pdf",
    "page": 12,
    "chunk_index": 3,
    "title": "Java基础概念",
    "timestamp": 1700000000,
    "language": "zh"
  }
}

文档切割策略：

固定大小切割：一般会加上重叠（overlap）来缓解边界阶段问题
语义边界切割：按照文本的自然语义边界（如段落、句子、标题层级）进行切割
特殊内容专项处理：对于代码文件和表格等特殊内容采用专门的切割策略
父子切割：存储时同一份内容存两份：一份细粒度的小 chunk 专门用于向量检索，一份
大 chunk 用于提供完整上下文给 LLM 生成

比较新的思路：

Late Chunking：先编码再切块
句子窗口检索：存储时把文档切成单个句子，检索命中后将该句子与其前后各 N 个橘子一起返回

4. 在 RAG 中 Embedding 究竟是什么?如何选择和评估一个 Embedding 模型?

Embedding：把文本信息转换为向量信息，语义相近的文本向量距离近

常见 Embedding 模型：

OpenAI 的 text-embedding 系列
BEG 系列
新一代高性能模型

如何选择：

中英文比例
数据合规要求
向量维度

评估方法：

在自己的业务数据上构建测试集进行测试，看召回率

详见：RAG Embedding详解：模型选型、维度权衡与评估调优

5. Embedding 有哪几种算法你了解过吗?

世代	代表模型	核心特点	主要局限	RAG适用性
第一代	Word2Vec、GloVe、FastText	词级静态向量	无法处理多义词，词级非句子级	不适用
第二代	ELMo、BERT	上下文动态向量	检索时需两两拼接，速度极慢	不适用于实时搜索
第三代	SBERT、SimCSE、BEG、E5	句子级bi-encoder，对比学习	精度低于cross-encoder	标配，性能和精度平衡最优

6. 什么是向量数据库? RAG 场景为什么需要向量数据库？有没有做过向量数据库的对比选型?

向量数据库： 专门存储和检索向量数据的数据库，支持高效的相似度搜索。

RAG 场景为什么需要：

高维向量相似度搜索
大规模数据承载能力
语义检索
- 支持元数据过滤 + 向量相似度联合查询
- 混合检索：向量 + BM25 + RRF融合
- 动态更新：支持增量写入
- 权限/多租户隔离

向量数据库对比选型：

中小到大规模、团队小、快速上线 -> Qdrant
快速原型验证、中小规模 -> Chroma
数据规模在千万到亿级、需要分布式 -> Milvus
不想运维、需要云服务 -> Pinecone
已经在用PostgreSQL、数据量不大 -> pgvector（插件）

7. 向量索引算法

常见的向量索引算法：

精确最近邻（Exact Nearest Neighbor，ENN）算法
近似最近邻（Approximate Nearest Neighbor，ANN）算法：
- 基于图：⭐ HNSW（Hierarchical Navigable Small World Graph）
- 基于量化：⭐ IVF（Inverted File Index）、PQ（Product Quantization）
- 基于哈希：LSH（Locality-Sensitive Hashing）

| 算法名称 | 原理机制 | 核心优势 | 主要劣势 | 适用数据规模 |
| ------------------- | ----------------------- | --------------------------- | ---------------------- | ---------------- | |
| Flat（暴力搜索） | 遍历所有向量计算距离 | 100% 准确无损 | O(n) 复杂度，查询极慢 | < 10 万 |
| HNSW（图索引） | 分层导航的小世界图 | 查询极快，召回率极高 | 内存消耗巨大，构建耗时 | 10 万 - 1000 万 |
| IVFFLAT（倒排聚类） | 聚类 + 倒排索引桶 | 内存效率高，构建快 | 需前置训练，召回率略低 | 1000 万 - 1 亿 |
| IVF-PQ（乘积量化） | 聚类 + 向量极致压缩 | 支持海量数据，开销极低 | 精度损失较大 | > 1 亿 |
| IVF_RABITQ | 聚类 + 随机旋转比特量化 | 内存占用极低，召回率优于 PQ | 较新算法，生态支持有限 | > 1 亿 |

8. 讲讲你用的向量数据库?数据量级是多大?性能如何?遇到过性能瓶颈吗?

我们生产环境用的是Milvus。

数据量级在百万条向量左右，每条是1024维，用 HNSW 索引，单次查询的延
迟在20到50毫秒。

选Milvus主要是因为它支持分布式部署和读写分离，适合数据量大、并发高的场景。

我遇到过两个比较典型的瓶颈。

第一个是内存压力，百万级的1024维向量光原始数据就要好几个GB，后来我们
开启了标量量化SQ8，把float32压成int8，内存直接降到原来的四分之一。
第二个是大批量写入的时候会触发后台Segment合并，影响查询延迟，我们的解法是把批量写入改到业务低峰期，分批小批次写入。

9. 你使用 RAG 给大模型一个输入，系统是怎样的工作流程?

Query 预处理（Query Rewrite） -> Query Embedding（问题向量化

Query 预处理（Query Rewrite）
           ↓
Query Embedding（问题向量化）
           ↓
 向量检索（ANN）+ 多路召回
           ↓
       Rerank 精排
           ↓
       Prompt 拼装
           ↓
    大模型生成 + 溯源

10. 请你介绍一下向量检索和关键词检索的区别?

关键词检索（BM25这类）靠的是词频统计，看查询词在文档里出现了多少次，擅长精确命中
向量检索靠的是语义空间里的距离，能理解换了种表达方式的同一个意思，擅长模糊语义匹配。

两者各有盲区：

BM25遇到同义词就没辙
向量检索遇到专有名词、产品型号这类精确词就容易漏
所以RAG系统里通常两路都跑：向量检索捕获语义相关的内容，BM25 精准命中关键词，再用RRF算法把两路结果合并，这样覆盖面比单路宽很多

混合检索：

                 用户Query
                     ↓
     ┌───────────────┬───────────────┐
     │                               │
BM25检索（ES）                向量检索（Vector DB）
倒排索引                         ANN索引
     │                               │
     └───────────────┬───────────────┘
                     ↓
               结果融合（RRF / rerank）

注：RRF（Reciprocal Rank Fusion，互倒排名融合）：是一种简单有效的结果融合算法，核心思想是：不看分数，只看排名。

11. 如何润色用户的 Query(Query Rewrite)?目的是什么?

目的：
弥补用户提问方式和知识库文档表述之间的语义鸿沟。
用户的问题往往口语化、模糊、带缩写，而文档写的是正式书面语，向量相似度天然偏低，导致该召回的内容没被召回。

润色方法:

直接改写：让 LLM 把口语化的问题转成更精准的表述
HyDE：让 LLM 先生成一个假设答案，然后用答案的向量去检索
Step-back Prompting：把具体问题往上抽象一层，检索更通用的背景知识。
多 Query 扩展：生成多个不同表述的 Query，分别检索后合并结果。

12. RAG 检索优化策略有哪些?

RAG 检索优化从四层框架入手：

索引层：选择合适的向量检索算法（如 HNSW、IVF-PQ），调整索引参数（如 M、efConstruction）来平衡召回率和查询速度。
查询层：主要是对 Query 进行预处理（直接改写、HyDE、Step-back Prompting、多 Query 扩展）来提升检索的相关性。
召回层：多路召回（向量检索 + BM25）+ 结果融合（RRF）来提升覆盖率和相关性。
精排层：使用更强的模型（如 cross-encoder）对召回结果进行精排。

详见：RAG检索优化四层框架：索引层、查询层、召回层、重排序层

13. 了解哪些更复杂的 RAG范式?

RAG的发展经历了三代演进：

Naive RAG 是基础的检索加生成
Advanced RAG 在检索前后都加了优化，比如Query 改写、Rerank、混合检索这些
Modular RAG 是把各个环节做成模块可以任意组合。

在这之上还有几个我觉得值得关注的高级范式:

Self-RAG 是让 LLM 自己来决定要不要检索，以及评估检索质量
CRAG 是检索质量差的时候自动降级到网络搜索
GraphRAG 是微软推的方案，用知识图谱的社区发现和层次摘要来增强全局理解能力
Agentic RAG 是把 RAG 做成 Agent，支持多轮的动态检索。

14. 如何规避 RAG 系统中大模型的幻觉?

RAG 系统出现幻觉的原因：

检索没有召回到相关内容
检索到了相关内容但是 LLM 没有严格遵守

规避策略：

Prompt 强约束：明确告诉 LLM 只能基于提供的检索结果回答，如果没有相关信息就说不知道。
检索质量门控：Rerank 分数低于阈值就直接拒答。
生成后引用核查：每个关键的声明都要在 chunk 中找到来源依据。
结构化输出强制溯源：让 LLM 输出一个结构化的答案对象，里面包含答案和对应的证据来源。

15. 怎么量化你的 RAG 效果?

分两层来看：

检索层看该召回的有没有召回到，我用Hit@K和MRR来衡量。
生成层看答案对不对、有没有幻觉、和问题相不相关，我主要用 RAGAs 框架，里面的Faithfulness、Answer Relevancy 和 Context Recall 这三个指标是最核心的。
线上指标，就是用户的点踩率、追问率、转人工率这些，才是最终的衡量标准，离线指标只是辅助。

注：

Hit@K：在前 K 个检索结果中是否包含至少一个相关项。
MRR（Mean Reciprocal Rank）：相关项在检索结果中的平均排名的倒数。
RAGAs：是一个专门评估 RAG 系统生成质量的框架，包含多个维度的指标。
- Faithfulness：衡量生成内容与检索结果的一致性
- Answer Relevancy：衡量生成答案与用户问题的相关性
- Context Recall：衡量生成答案中包含了多少检索结果中的关键信息

16. RAG 知识库如何实现动态与持续更新?

我理解知识库更新的核心挑战是：文档变了，对应的 chunk 和向量都要跟着变，而且要做到增量处理，不能每次全量重建。

我们的通用方案是给每个文档算一个内容 hash，通过轮询或者监听数据源变更，检测到文档新增、修改、删除的时候，先清掉旧的向量，再重新切割入库。对于实时性要求比较高的场景，我会用消息队列比如 Kafka 做变更事件驱动，实现秒级的入库。

17. 在实际落地中，你觉得 RAG 最难的地方是哪里?

文档预处理：原始数据的格式五花八门，PDF 里面的表格、图片、嵌套的格式，处理不好就是一堆乱码进了知识库，进去的是垃圾出来的也是垃圾。
检索质量的调优：向量召回不准是整个系统效果的天花板，但问题来源很多，Chunking、Embedding、Query 改写，任何一个环节出问题都会影响结果，排查起来很费劲。
效果评估：答案对不对很难系统性地衡量，不知道是哪个环节出了问题，优化就变成了瞎猜。

LLM 工具调用相关面试总结

1. 什么是 Function Calling ?原理是什么?

Function Calling：开发者用 JSON schema 把工具描述好传给模型，模型判断需要调工具的时候不输出自然语言，而是直接输出一段结构化的tool_calls JSON，告诉你「我要调哪个函数、参数是什么」，你的代码拿到这段 JSON 去真正执行，把结果塞回对话，模型再生成最终答案。

整个流程本质上是两轮对话：第一轮模型说我需要调这个工具，你去执行，第二轮模型拿到执行结果说答案是这个。

我觉得最核心的设计是，模型全程只做决策，执行的事情一律由宿主代码完成，职责分得很清楚。

2. LLM 是如何学会调用外部工具的?

两种方式：

SFT（监督微调，Supervised Fine-Tuning）：给模型喂大量工具调用示范对话，让它通过模仿学会看到工具描述 -> 判断要不要调 -> 输出结构化JSON 请求这整套流程
RLHF（基于人类反馈的强化学习，Reinforcement Learning from Human Feedback）： 收集人类对哪种回答更好的判断，训练一个打分器，再用这个分数反复调整模型，让它学会什么时候不应该调工具。

3. 什么是MCP（模型上下文协议）?讲讲它的核心内容?

MCP 是 Anthropic 在2024年底推出的开放协议，我理解它主要解决的是模型接工具太碎片化的问题。

在 MCP 出现之前，每接一个新工具都要单独写集成代码、处理认证、适配格式，而且这套代码和具体模型强绑定，换个模型就得重写，非常繁琐。

MCP 的思路是把这件事标准化：工具提供方按协议实现一个Server，任何支持 MCP 的 AI客户端就能直接接进来，一次实现到处复用。

协议定义了三类能力：

Tools 用于执行有副作用的操作
Resources 是只读数据
Prompts 是提示词模板
底层通信用 JSON-RPC2.0。

我把它理解成给AI接工具这件事定了一套行业标准。

详见：MCP（Model Context Protocol）从入门到工程实践：工具发现、选择与学习全解析

4. MCP由哪几部分组成?

MCP由三层组成，可以从角色、能力、协议三个维度来理解。

角色层有三个：

Host 是 AI 应用本身(比如 Claude Desktop )
Client 是 Host 里负责和 Server 通信的模块
Server 是工具提供方实现的独立进程，一个 Host 可以同时连多个 Server。

能力层定义了 Server 能暴露三类东西：

Tools 是有副作用的操作(比如创建文件、调API)
Resources 是只读数据(比如读取文档内容)
Prompts 是预定义的提示词模板。

协议层是底层通信：

消息格式统一用 JSON-RPC 2.0，传输方式支持 stdio(本地子进程通信)和Streamable HTTP(远程HTTP 连接)两种
早期的 SSE 传输已被弃用。

这三层合在一起，就是MCP的完整组成。

5. MCP 和 FunctionCalling 有什么区别?有没有实际跑过 MCP?

我理解这两者不是竞争关系，解决的不是同一层面的问题。

FunctionCalling 是「调用语言」，定义的是模型怎么表达“我要调哪个函数、参数是什么”
MCP 是「工具生态协议」，定义的是工具怎么标准化打包、注册和被 AI 客户端发现。

MCP 底层其实还是用 FunctionCalling 来触发工具调用，只是在它之上加了一套工具管理框架，让工具实现一次、到处复用。

打个比方：FunctionCalling 像 HTTP 请求格式，MCP像 RESTAPI 的设计规范加服务注册发现机制，两者是不同层次的东西。

关于实际跑过的经验，我用 Copilot 配过文件系统和 GitHub 的 MCP Server，在配置文件里加几行就能用，Claude 会自动发现工具，完全不用写对接代码。

适用场景：

如果只是给单个应用接一两个工具、场景临时、不需要复用 -> FunctionCalling 就够了
如果要构建一个工具生态、多个应用都要用、工具会持续增加 -> MCP 就很有必要了

6. 为什么有些特定的推理模型不支持 MCP 协议?

我理解根本原因是两者的生成范式有冲突。推理模型在给出答案之前，会先跑一段完整的思维链，这个 thinking 过程是一次性连续生成的，不能中途打断。但工具调用天然是多轮交互:模型输出调用请求、暂停等工具执行、拿到结果再继续生成，这两种模式没法兼容。你没法在思考链跑到一半的时候暂停去等工具结果，否则之前的推理上下文全断了。
而 MCP 底层就是靠 Function Calling 驱动的，推理模型连 Function Calling 都支持不好，MCP 自然也用不了。当然这个问题不是无解的，后来 o3 和 Claude Extended Thinking 都找到了折中方案，比如让工具调用发生在思考阶段结束之后，保证思考过程还是一次性完整生成的。

7. Skill 是什么?

Agent Skill 是把重复性的工作流程打包成可复用模块的机制。每个 Skill 是一个文件夹，里面有一份 SKILL.md 指令文件，还可以带上脚本、模板、参考文档这些资源。

它和普通 prompt 最大的区别是：Skill 能被 Agent 自动发现和按需加载，不用你每次手动输入；和 MCP 工具的区别是：MCP 给 Agent 提供外部工具和数据的访问能力，而 Skill 教 Agent 拿到这些工具和数据之后该怎么用。

8. MCP 和 Agent Skill 的区别是什么?

MCP 和 Agent Skill 不是同类概念，不是竞争关系，而是互补的。

MCP 解决的是 Agent 怎么获得外部能力，它把数据库、API、文件系统这些外部工具标准化封装成服务，Agent 通过 MCP 就能查数据、调接口、读写文件。

Skill 解决的是 Agent 拿到这些能力之后，该按什么步骤、什么标准来完成任务，它把完成某类工作的知识和流程打包成可复用的模块。

简单记：MCP 是给 Agent 配的电脑和软件，Skill 是给 Agent 发的操作手册和 SOP。在实际系统里，两者经常同时工作，Skill 定义流程，流程中调用 MCP 提供的工具。

9. FunctionCalling、Skill、MCP 这三个有什么区别?

这三个概念在不同层次工作，不是竞争关系。

Function Calling 是 LLM 调用外部工具的执行接口，解决的是模型怎么调函数。
MCP 是统一管理和接入这些工具/Skill 的标准化协议层，使工具可以被动态发现和调用，解决的是工具怎么暴露给模型。
Skill 是基于 Function Calling + Prompt + Workflow 封装的任务能力模块，解决的是拿到工具之后按什么流程完成任务。

10. 什么是 A2A 协议?它和 MCP 协议的区别是什么?

A2A（Agent to Agent）协议是专门为 Agent 间高效、确定性协作而设计的通信规范。它要求 Agent 在相互交互时，收起“高情商”的自然语言废话，转而使用高度结构化、带有严格校验规则的数据载体（如定义了 Schema 的 JSON、XML 或特定的状态流转指令）。

它和MCP的区别：

MCP 解决的是Agent 与工具之间的通信问题。
A2A 解决的是Agent 与 Agent 之间的通信问题。

11. MCP 协议通常采用什么通信方式?

MCP支持两种主要的传输方式，分别适用于不同场景。

本地场景用 stdio，Client 把 Server 作为子进程启动，通过标准输入输出通信，延迟极低，不用开端口，也没有网络安全问题
远程场景现在推荐用 Streamable HTTP，Server 作为独立的 HTTP 服务部署，多个 Client 可以共享同一个 Server ，适合团队统一管理工具服务。
MCP 早期版本远程传输用的是 SSE(Server Sent Events)，但 2025 年规范更新后SSE 已被正式弃用，Streamable HTTP 成为了标准的远程传输方式。
不管哪种传输方式，底层消息格式都统一用 JSON-RPC 2.0，传输方式只影响怎么传，消息协议本身不变。

12. 说说 WebSocket 和 SSE 通信的区别及局限性?

我觉得最核心的区别是通信方向：SSE 是服务端单向推，客户端只能接收，想发消息只能另起一个HTTP请求；WebSocket 是全双工，双方都可以随时主动发消息。

对于 LLM 流式输出这种模型一直在推 token、用户只是看的场景，SSE 完全够用，而且轻量、HTTP 原生支持、运维简单。WebSocket 的复杂性只有在真正需要双向实时交互的时候才值得引入。

两者各有局限：

SSE 在 HTTP/1.1 下有连接数上限，只支持文本传输
WebSocket有状态、横向扩展麻烦，还容易被企业代理或防火墙拦掉。

13. 为什么 AI 实时语音要用 WebRTC 协议?它和 WebSocket 在 AI 对话流中的核心差异是什么?

我理解核心原因是 WebSocket 基于 TCP，而 TCP 的可靠性设计在实时语音场景里反而是负担。语音可以容忍丢包，但绝对不容忍延迟；一旦网络抖动丢了包，TCP 强制等重传，后续所有音频都得跟着等，延迟一堆积通话就卡。

WebRTC 走的是UDP，丢包了不等重传，直接用插值算法填补，用一点点音质损失换来稳定的低延迟，延迟能控制在50到150毫秒。
另外 WebRTC 还内置了回声消除、噪声抑制、自适应码率这些语音处理能力，这些用 WebSocket 都得自己实现。所以 OpenAI Realtime API 这类实时语音产品 WebRTC 就是因为 TCP 根本撑不住语音场景的延迟要求。