MCP、Function Calling 与 Agent：原理、使用与高频面试题梳理

面向准备 AI Agent / LLM 应用工程师面试的中文复习文档。
核对日期：2026-01-23。MCP 官方 latest 当前指向 2025-11-25。
关键词：MCP、Function Calling、Tools、Agent Loop、RAG、Memory、Guardrails、Human-in-the-loop。

0. 参考资料

• MCP Specification latest
• MCP Architecture
• MCP Tools
• MCP Lifecycle
• MCP Transports
• OpenAI Function Calling
• OpenAI Agents SDK Tools
• OpenAI Agents SDK Agents

1. 一句话总览

MCP 是把外部上下文、工具和提示词接入 LLM 应用的标准协议；Function Calling 是模型通过结构化 JSON 参数“请求应用调用工具”的机制；Agent 是围绕目标不断观察、推理、调用工具、处理结果并终止的运行范式。

面试中最容易混淆的是：模型不会真的执行函数，模型只生成工具调用意图和参数；真正执行工具的是应用、SDK、MCP client/server 或托管工具运行时。MCP 也不是某个 Agent 框架，它更像一套“外部能力接入协议”。

1
2
3
4
5
6
7
8
9
10
11
12

flowchart LR
    U["用户目标"] --> H["Host / Agent App"]
    H --> M["LLM"]
    M -->|"Function Calling: 生成 tool_call + args"| H
    H -->|"执行本地函数 / API"| T["Function Tool"]
    H -->|"MCP Client: tools/list, tools/call"| S["MCP Server"]
    S --> R["Resources / Tools / Prompts"]
    T --> H
    S --> H
    H -->|"整理工具结果"| M
    M -->|"最终回答或继续调用"| H
    H --> U

1.1 三者关系速记

1.2 面试前 30 秒答案

如果被问“你怎么理解 MCP、Function Calling 和 Agent”，可以这样答：

MCP 是 LLM 应用接入外部上下文和工具的开放协议，定义 Host、Client、Server 之间用 JSON-RPC 通信，服务端暴露 Resources、Prompts、Tools，客户端可以提供 Sampling、Roots、Elicitation 等能力。Function Calling 是模型 API 里的工具调用机制：应用把函数的 JSON Schema 提供给模型，模型选择函数并生成结构化参数，应用执行函数后把结果回传。Agent 则是更上层的任务执行范式，它把模型推理、工具调用、状态管理、错误恢复、权限控制和终止条件串成循环。三者可以组合：Agent App 作为 Host，通过 MCP Client 发现远端工具，再把这些工具映射成模型可调用的 function tools。

1.3 常见误区

• 误区 1：Function Calling 会自动执行函数。实际是模型生成调用请求，应用负责执行。
• 误区 2：MCP Server 能看到完整对话。规范设计上 Host 负责隔离，Server 应只拿到必要上下文。
• 误区 3：Agent 就是“多次调用 LLM”。真正工程化 Agent 还需要状态、工具、权限、恢复、观测和终止。
• 误区 4：工具越多越强。工具过多会增加选择难度、token 成本、误调用和权限风险。
• 误区 5：RAG、MCP、Function Calling 是竞争关系。它们常常互补：RAG 提供知识检索，MCP 提供接入协议，Function Calling 提供调用格式。

2. MCP 原理与使用

2.1 MCP 是什么

MCP，全称 Model Context Protocol，是一个开放协议，用来让 LLM 应用和外部数据源、工具、工作流进行标准化集成。它的目标不是替代模型 API，而是让不同应用和工具之间有统一的通信方式。

MCP 使用 JSON-RPC 2.0 消息，具有状态化连接、生命周期、能力协商、错误处理、取消、进度、日志等协议能力。它借鉴了 Language Server Protocol 的思想：不是每个 IDE 都为每种语言重写一套能力，而是通过协议把语言能力标准化；MCP 类似地把 AI 应用的外部上下文和工具接入标准化。

2.2 Host / Client / Server

关键点：

• 一个 Host 可以管理多个 Client。
• 每个 Client 通常维护到一个 Server 的隔离会话。
• Server 应聚焦具体能力，不应拥有完整对话上下文。
• Host 负责用户授权、策略控制、上下文聚合和安全边界。

2.3 生命周期

MCP 连接通常分三段：

1. Initialization：客户端发送 initialize，包含协议版本、客户端能力和客户端信息；服务端返回协议版本、服务端能力和服务端信息。
2. Operation：双方按能力协商结果进行正常 JSON-RPC 通信。
3. Shutdown：连接关闭或会话终止。

能力协商是 MCP 的关键。比如服务端只有声明 tools capability，客户端才应该调用工具相关接口；客户端只有声明 sampling，服务端才可以发起采样请求。

2.4 Transports

MCP 当前标准 transport 主要包括：

安全上，Streamable HTTP 要特别关注 Origin 校验、认证、localhost 绑定、会话 ID 保护和 DNS rebinding 风险。

2.5 Server Features：Resources、Prompts、Tools

Resources 偏“读上下文”，Tools 偏“执行动作”，Prompts 偏“复用任务模板”。面试中要强调：Tool 可能产生副作用，因此需要更强权限控制。

2.6 Client Features：Sampling、Roots、Elicitation

MCP 的一个设计原则是 Server 不应该直接读取整个对话，也不应该越过 Host 做用户交互。Sampling 和 Elicitation 都是通过 Client/Host 受控完成。

2.7 Tools 协议消息

tools/list

客户端发送 tools/list 发现服务端工具。返回值包含工具列表、分页 cursor 等。每个工具通常包括：

• name：工具唯一标识。
• title：面向 UI 的可选名称。
• description：说明工具做什么、何时使用。
• inputSchema：JSON Schema 参数定义。
• outputSchema：可选，结构化输出定义。
• annotations：可选工具行为提示，但不应盲目信任。
• execution：可选执行属性，例如 task support。

tools/call

客户端发送 tools/call 调用工具，参数包含工具名和 arguments。服务端返回 tool result，可能包括：

• content：非结构化内容块，如 text、image、audio、resource link、embedded resource。
• structuredContent：结构化 JSON 对象。
• isError：工具执行错误标记。

面试重点：MCP tool result 可以同时给自然语言可读内容和结构化内容。若工具定义了 outputSchema，结构化结果应符合 schema，客户端也应做校验。

2.8 MCP 工具错误

MCP Tools 有两类错误：

工程实践中，工具执行错误应该返回足够具体但不泄露敏感信息的提示。

2.9 MCP 安全边界

MCP 安全要点：

• Host 负责用户授权和安全策略。
• Tool 调用前应让用户看见工具名、参数和影响范围。
• Server 必须验证输入、控制权限、限流、清洗输出。
• Client 应对敏感操作进行确认、设置超时、记录审计日志。
• Tool annotations 来自非可信 server 时不能直接相信。
• Resources 和 tool output 可能包含 prompt injection，进入模型前要做隔离和标注。

2.10 MCP 使用步骤

一个典型接入流程：

1. 选择 transport：本地 stdio 或远程 Streamable HTTP。
2. Host 创建 MCP Client 并连接 Server。
3. 发送 initialize，完成版本和能力协商。
4. 调用 tools/list、resources/list 或 prompts/list 发现能力。
5. 将可用工具映射到 Agent 的 tool registry 或模型 API 的 function tools。
6. 模型产生工具调用意图后，Host 决定是否允许调用。
7. Client 发送 tools/call 给 MCP Server。
8. Host 将结果整理后回传模型。
9. 记录调用链路、延迟、错误、权限决策。

3. Function Calling 原理与使用

3.1 Function Calling 是什么

Function Calling 是模型 API 支持的一种工具调用方式。应用把工具定义传给模型，工具定义通常包含函数名、描述、参数 JSON Schema、严格模式等。模型根据上下文决定是否调用某个工具，并生成符合 schema 的参数。

关键点：模型输出的是“调用请求”，不是执行结果。应用必须解析调用请求、执行真实函数或 API，再把工具结果作为后续输入回传模型。

3.2 基本流程

1
2
3
4
5
6
7
8
9
10
11

sequenceDiagram
    participant App as 应用
    participant LLM as 模型
    participant Tool as 本地函数/API
    App->>LLM: 输入 + tools schema
    LLM-->>App: function_call(name, arguments, call_id)
    App->>App: 校验参数、权限判断
    App->>Tool: 执行真实函数
    Tool-->>App: 返回结果
    App->>LLM: function_call_output(call_id, output)
    LLM-->>App: 最终回答或继续调用工具

3.3 Function Schema

典型字段：

好的 schema 会显著影响工具选择和参数质量。差的 schema 常见问题是描述含糊、参数过宽、多个工具语义重叠、没有枚举约束、返回格式不稳定。

3.4 tool_choice

tool_choice 用来控制模型是否、何时、必须调用工具。不同 API/SDK 具体写法可能不同，但常见策略包括：

• auto：模型自行决定是否调用。
• none：禁止调用工具。
• 指定某个工具：强制调用特定工具。
• required 类策略：要求至少调用工具。

工程上不要滥用强制调用。强制调用适合表单抽取、必须查实时数据、必须执行校验等场景；开放问答、总结、闲聊通常保持自动或禁用工具更合适。

3.5 结构化输出与 Function Calling 的区别

结构化输出关注“最终答案必须是某个 JSON 结构”；Function Calling 关注“中间过程是否调用工具”。两者可以组合：Agent 先调用工具查数据，最后要求模型输出结构化报告。

3.6 并行和多步工具调用

模型可能一次返回多个 tool call，也可能多轮调用。应用要处理：

• 多个调用的 call_id 对应关系。
• 并行执行是否安全。
• 工具之间是否有依赖。
• 某个工具失败时是否继续其他工具。
• 是否允许模型基于工具错误自我修正。

有副作用的工具通常不应盲目并行，例如扣款、发邮件、删除文件。只读查询工具更适合并行。

3.7 常见失败模式

4. Agent 原理

4.1 Agent 是什么

Agent 是一个围绕目标执行任务的系统。它通常包含：

• 模型：负责理解、推理、规划、生成调用。
• 工具：外部 API、本地函数、MCP server、托管工具等。
• 状态：对话历史、运行上下文、任务进度、短期记忆。
• 记忆：长期偏好、用户画像、知识库、历史决策。
• 控制器：循环调度、权限、终止条件、错误恢复。
• 观测：日志、trace、token、延迟、工具调用记录。
• 保护：guardrails、输入输出校验、人工审批。

4.2 Agent Loop

常见 Agent loop：

1. Receive：接收用户目标和上下文。
2. Think/Plan：模型判断是否需要分解任务。
3. Act：选择工具或直接回答。
4. Observe：读取工具结果。
5. Reflect/Repair：必要时修正参数、换工具、补充查询。
6. Finish：满足终止条件后输出结果。

伪代码：

1
2
3
4
5
6
7
8
9
10
11
12

state = init(user_goal)
for turn in range(max_turns):
    decision = model(state, tools)
    if decision.type == "final":
        return decision.answer
    if decision.type == "tool_call":
        if not policy.allow(decision.tool, decision.args):
            state.add("tool denied")
            continue
        result = execute_tool(decision.tool, decision.args)
        state.add_observation(result)
return fail("max turns exceeded")

4.3 Planner / Executor

Planner 负责拆解任务、决定策略；Executor 负责执行具体工具调用。简单任务可以一个模型同时做规划和执行；复杂任务可拆成多 Agent 或 manager/worker 模式。

设计取舍：

• 单 Agent：简单、成本低、上下文集中，但复杂任务容易混乱。
• Planner + Executor：可控、可观测，但延迟和实现复杂度更高。
• 多 Agent：职责清晰，适合专业化任务，但协调成本和错误传播风险更高。

4.4 Memory

Memory 可分为：

面试要点：Memory 不是把所有历史塞进 prompt，而是存储、检索、压缩、校验和过期策略的组合。

4.5 RAG 与 Agent

RAG 是 Retrieval-Augmented Generation，核心是检索外部知识再生成。Agent 可以把 RAG 当作一个工具，也可以在执行过程中多次检索、交叉验证、基于结果决定下一步。

RAG 解决“知识在哪里”，Agent 解决“任务怎么推进”。MCP 可以标准化暴露检索工具或资源。

4.6 Guardrails

Guardrails 是 Agent 的安全和质量控制层，包括：

• 输入校验：识别越权、敏感、恶意 prompt。
• 工具参数校验：schema、业务规则、权限。
• 输出校验：格式、事实、合规、敏感信息。
• 人工审批：高影响操作前暂停。
• 运行预算：max turns、超时、token、费用。
• 审计：记录谁在何时调用了什么工具。

4.7 终止条件

常见终止条件：

• 模型输出 final answer。
• 达到最大轮数或最大工具调用次数。
• 达到时间、token、费用预算。
• 工具返回不可恢复错误。
• 用户拒绝授权。
• 检测到重复调用或循环。
• 输出通过结构化校验和业务验收。

5. Python + TypeScript 示例

示例用于解释工程形态，不绑定某一家 SDK 的所有细节。真实项目应以所用 SDK 的当前文档为准。

5.1 Python：Responses API Function Calling 基础循环

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

from __future__ import annotations

import json
from typing import Any
from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "name": "get_order_status",
        "description": "查询订单状态。只在用户提供明确 order_id 时调用。",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "订单号，例如 OD20260608001",
                }
            },
            "required": ["order_id"],
            "additionalProperties": False,
        },
        "strict": True,
    }
]


def get_order_status(order_id: str) -> dict[str, Any]:
    # 真实项目中这里会查数据库或调用订单 API。
    return {
        "order_id": order_id,
        "status": "shipped",
        "eta": "2026-06-10",
    }


def dispatch_tool(name: str, arguments: dict[str, Any]) -> dict[str, Any]:
    if name == "get_order_status":
        return get_order_status(arguments["order_id"])
    raise ValueError(f"Unknown tool: {name}")


input_items: list[Any] = [
    {"role": "user", "content": "帮我查一下订单 OD20260608001 到哪了"}
]

for _ in range(5):
    response = client.responses.create(
        model="gpt-5.5",
        input=input_items,
        tools=tools,
        instructions="你是客服助手。需要实时订单状态时必须调用工具，不要猜测。",
    )

    # 对 reasoning models，带工具调用的响应中返回的 reasoning items 也要保留回传。
    input_items += response.output

    tool_calls = [item for item in response.output if item.type == "function_call"]
    if not tool_calls:
        print(response.output_text)
        break

    for call in tool_calls:
        args = json.loads(call.arguments)
        result = dispatch_tool(call.name, args)
        input_items.append(
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result, ensure_ascii=False),
            }
        )
else:
    raise RuntimeError("Agent exceeded max tool turns")

要点：

• tools 只是告诉模型有哪些可调用工具。
• dispatch_tool 才是真正执行函数的位置。
• call_id 用于把工具结果和模型的某次调用对应起来。
• 必须设置最大轮数，避免无限循环。

5.2 TypeScript：Agents SDK 风格 Function Tool

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import { Agent, run, tool } from "@openai/agents";
import { z } from "zod";

const getOrderStatus = tool({
  name: "get_order_status",
  description: "查询订单状态。只在用户给出明确 orderId 时调用。",
  parameters: z.object({
    orderId: z.string().describe("订单号，例如 OD20260608001"),
  }),
  async execute({ orderId }) {
    return {
      orderId,
      status: "shipped",
      eta: "2026-06-10",
    };
  },
});

const supportAgent = new Agent({
  name: "Support Agent",
  instructions: "你是客服助手。不要猜测订单状态，必要时调用工具。",
  tools: [getOrderStatus],
});

const result = await run(
  supportAgent,
  "请帮我查询订单 OD20260608001 的配送进度"
);

console.log(result.finalOutput);

要点：

• SDK 把本地函数包装成模型可见工具。
• Zod schema 既约束参数，也帮助模型理解参数。
• Agent SDK 还可以接入 hosted tools、MCP servers、agents as tools、guardrails 等。

5.3 Python：MCP Server 暴露工具的基本形态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("orders")


@mcp.tool()
def get_order_status(order_id: str) -> dict:
    """查询订单状态。order_id 必须是明确订单号。"""
    return {
        "order_id": order_id,
        "status": "shipped",
        "eta": "2026-06-10",
    }


if __name__ == "__main__":
    mcp.run()

要点：

• MCP Server 暴露的是协议能力，不直接等同于模型 API 工具。
• Host 需要通过 MCP Client 连接该 Server，发现工具，再决定是否映射给模型。
• Server 仍要做鉴权、输入校验、限流、输出清洗。

5.4 TypeScript：MCP Server Tool 与结构化输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "orders",
  version: "1.0.0",
});

server.registerTool(
  "get_order_status",
  {
    title: "Order Status",
    description: "查询订单状态。orderId 必须是明确订单号。",
    inputSchema: {
      orderId: z.string(),
    },
    outputSchema: {
      orderId: z.string(),
      status: z.enum(["pending", "paid", "shipped", "delivered", "cancelled"]),
      eta: z.string().optional(),
    },
  },
  async ({ orderId }) => {
    const structuredContent = {
      orderId,
      status: "shipped" as const,
      eta: "2026-06-10",
    };

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(structuredContent),
        },
      ],
      structuredContent,
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

要点：

• inputSchema 描述入参。
• outputSchema 描述结构化结果。
• structuredContent 给客户端和模型更稳定的解析依据。
• content 仍可保留兼容性文本。

5.5 Agent 工具编排伪实战

1
2
3
4
5
6
7
8

用户：分析过去一周客服投诉，找出前三类问题，并给出处理建议。

Agent:
1. 调用 ticket_search 查询过去一周工单。
2. 调用 classify_complaints 对工单分类。
3. 调用 policy_lookup 查询每类问题的处理政策。
4. 如果某类样本不足，继续检索或说明置信度。
5. 输出结构化报告：问题类别、数量、证据、建议、风险。

工程上这类任务不要只靠模型自由发挥，最好给 Agent 明确的步骤、工具边界、输出 schema、最大调用次数和失败处理策略。

6. 高频面试题库

A. 基础概念

Q1：MCP 是什么？

参考答案：MCP 是 Model Context Protocol，一个用于 LLM 应用和外部数据源、工具、提示词工作流之间通信的开放协议。它通过 JSON-RPC、生命周期、能力协商和标准 primitives，让 Host 可以接入多个 Server 暴露的 Resources、Prompts、Tools。

表达要点：协议层、上下文接入、Host/Client/Server、JSON-RPC、能力协商。

常见误区：把 MCP 当成模型、Agent 框架或单纯的函数调用 API。

Q2：Function Calling 是什么？

参考答案：Function Calling 是模型 API 中让模型生成结构化工具调用请求的机制。应用提供工具 schema，模型返回函数名和参数，应用执行函数后把结果回传模型。

表达要点：模型只生成调用意图；应用执行；参数由 JSON Schema 约束。

常见误区：认为模型能直接访问数据库或直接运行代码。

Q3：Agent 是什么？

参考答案：Agent 是一种任务执行系统，把 LLM、工具、状态、记忆、策略、权限和终止条件组合成循环，使系统能围绕目标多步行动并产出结果。

表达要点：目标驱动、多步循环、工具调用、状态管理、终止条件。

常见误区：把 Agent 简化成“一个 prompt”或“自动聊天机器人”。

Q4：MCP、Function Calling、Agent 的区别？

参考答案：MCP 是工具和上下文接入协议；Function Calling 是模型请求调用工具的结构化输出机制；Agent 是使用模型和工具完成任务的运行范式。三者可以组合，但层次不同。

表达要点：协议、机制、范式三层区分。

常见误区：把 MCP 和 Function Calling 视为互斥方案。

Q5：为什么需要 MCP？

参考答案：没有 MCP 时，每个 Agent 应用都要为每个外部系统写专用连接方式。MCP 提供统一协议，让工具和上下文 server 可以被多个 Host 复用，并通过能力协商和安全边界降低集成复杂度。

表达要点：标准化、复用、互操作、隔离、安全。

常见误区：只从“省代码”角度理解，而忽略权限和生态互操作。

Q6：为什么需要 Function Calling？

参考答案：自然语言输出不稳定，难以直接驱动系统动作。Function Calling 用 schema 约束模型输出，使应用能可靠解析工具名和参数，从而接入实时数据、业务系统和外部 API。

表达要点：结构化、可校验、可执行、连接外部系统。

常见误区：认为它能完全消除幻觉；实际仍需校验和权限控制。

Q7：为什么需要 Agent？

参考答案：单次 LLM 调用适合简单问答，但复杂任务需要多步计划、工具调用、错误恢复和状态跟踪。Agent 提供任务闭环，让系统能根据观察结果继续行动，直到满足目标或终止条件。

表达要点：多步任务、闭环、状态、恢复、终止。

常见误区：把 Agent 设计成无限自主，不设预算和边界。

Q8：Tool 和 Resource 的区别？

参考答案：Resource 通常是可读取的上下文或数据，偏“读”；Tool 是可被模型触发的动作，可能查询、计算或产生副作用，偏“做”。Tool 的权限和审计要求更高。

表达要点：读 vs 动作；副作用；安全等级不同。

常见误区：把所有数据访问都做成 Tool，导致权限和调用复杂度上升。

Q9：Prompt 在 MCP 中是什么？

参考答案：Prompt 是服务端提供的模板化消息或工作流，用于让用户或 Host 快速启动某类任务。它不是模型参数，而是可复用的任务模板。

表达要点：模板、工作流、可发现、可复用。

常见误区：把 Prompt 当成系统提示词的唯一来源。

Q10：工具调用和结构化输出有什么区别？

参考答案：工具调用是中间动作，模型输出调用请求，应用执行后再回传；结构化输出通常约束最终答案格式。两者可以结合使用。

表达要点：中间动作 vs 最终格式。

常见误区：用结构化输出替代真正的工具执行。

Q11：什么是 tool registry？

参考答案：tool registry 是应用或 Agent 维护的可用工具目录，包含工具名、描述、schema、权限、执行器、超时和审计配置。模型看到的是其中一部分工具定义。

表达要点：注册、发现、执行映射、权限策略。

常见误区：只维护函数列表，不维护权限和运行时策略。

Q12：LLM 工具调用的本质是什么？

参考答案：本质是模型在上下文中基于工具描述和 schema 做路由与参数生成，然后由外部运行时执行真实动作。它是一种“语言模型决策 + 程序执行”的组合。

表达要点：模型决策、程序执行、schema 约束。

常见误区：把模型生成的参数天然当作可信输入。

Q13：Agent 和 Workflow 的区别？

参考答案：Workflow 通常是预定义流程，步骤和分支较固定；Agent 更依赖模型根据上下文动态决定下一步。实际工程中常用“workflow 外壳 + agent 局部决策”的混合模式。

表达要点：固定流程 vs 动态决策；混合设计。

常见误区：所有任务都用完全自治 Agent。

Q14：什么任务不适合 Agent？

参考答案：强确定性、低容错、固定规则、强合规或高频低延迟任务通常不适合完全开放式 Agent。比如核心交易扣款、权限变更、生产删除操作，应使用显式 workflow 和审批。

表达要点：确定性、高风险、低延迟、合规。

常见误区：为展示 AI 能力而把简单规则系统复杂化。

Q15：什么是 human-in-the-loop？

参考答案：human-in-the-loop 是在关键节点让用户或审核员参与决策，例如授权工具调用、确认高影响操作、纠正模型计划或审核最终输出。

表达要点：审批、确认、纠偏、安全。

常见误区：只在 UI 上显示日志，不给用户真正拒绝或修改的能力。

B. MCP 协议原理

Q16：MCP 的 Host、Client、Server 分别做什么？

参考答案：Host 是 LLM 应用容器，管理模型、用户授权、上下文聚合和多个 client；Client 是 Host 内部到某个 Server 的连接器；Server 暴露特定资源、工具和提示词能力。

表达要点：Host 管总控；Client 维护连接；Server 提供能力。

常见误区：把 Client 当成最终用户，或把 Server 当成模型运行环境。

Q17：为什么 MCP 中 Client 与 Server 通常是一对一连接？

参考答案：一对一连接有利于隔离会话、权限、上下文和通知，避免一个 Server 看到另一个 Server 的数据，也方便 Host 对不同 Server 设置不同策略。

表达要点：隔离、安全、生命周期清晰。

常见误区：为了省连接把多个 Server 混在同一通道里。

Q18：MCP 为什么使用 JSON-RPC？

参考答案：JSON-RPC 简单、语言无关、适合请求、响应和通知模型，也易于在 stdio、HTTP、SSE 等 transport 上承载。它比自定义文本协议更易验证和互操作。

表达要点：标准消息格式、请求响应通知、跨语言。

常见误区：把 JSON-RPC 当成只能走 HTTP 的协议。

Q19：MCP 初始化阶段做什么？

参考答案：初始化阶段通过 initialize 交换协议版本、能力和实现信息。服务端响应后，客户端发送 notifications/initialized 表示进入正常操作。

表达要点：版本协商、能力协商、实现信息、initialized notification。

常见误区：连接建立后直接调用工具，不检查能力。

Q20：能力协商有什么价值？

参考答案：能力协商让双方明确本会话可用功能，例如服务端是否支持 tools、resources subscriptions，客户端是否支持 sampling、roots、elicitation。这样可以保持扩展性和兼容性。

表达要点：可用功能声明、扩展、兼容。

常见误区：只靠接口是否报错判断能力。

Q21：MCP 的 stdio transport 怎么工作？

参考答案：Client 启动 MCP Server 子进程，Server 从 stdin 读取 JSON-RPC 消息，从 stdout 写回 JSON-RPC 消息，stderr 可用于日志，但 stdout 不能混入非协议内容。

表达要点：本地子进程、stdin/stdout、换行分隔、stdout 只放协议消息。

常见误区：在 stdout 打印调试日志导致协议解析失败。

Q22：Streamable HTTP transport 适合什么场景？

参考答案：适合远程 MCP Server、多客户端连接、需要认证和会话管理的服务。它使用单一 MCP endpoint，支持 POST/GET 和可选 SSE 流式消息。

表达要点：远程、HTTP endpoint、SSE、session。

常见误区：仍按旧 HTTP+SSE 两端点方案设计新服务。

Q23：Streamable HTTP 有哪些安全注意点？

参考答案：要校验 Origin 防 DNS rebinding，本地服务绑定 localhost，远程服务做认证和授权，保护 MCP-Session-Id，必要时限制跨域和网络来源。

表达要点：Origin、认证、localhost、session id。

常见误区：本地调试 server 监听 0.0.0.0 且无认证。

Q24：tools/list 的作用是什么？

参考答案：tools/list 用于让 Client 发现 Server 当前可用工具，工具定义包含名称、描述、输入 schema、可选输出 schema 等。

表达要点：发现工具、分页、schema、listChanged。

常见误区：把工具列表硬编码在 Host，忽略动态变化。

Q25：tools/call 的作用是什么？

参考答案：tools/call 是 Client 请求 Server 执行某个工具的方法，参数包含工具名和 arguments，返回 tool result。

表达要点：调用工具、arguments、content、structuredContent、isError。

常见误区：让模型直接向 MCP Server 发请求，绕过 Host 权限。

Q26：MCP Tool 的 inputSchema 有什么要求？

参考答案：inputSchema 是 JSON Schema，用来定义工具参数。它必须是有效 JSON Schema 对象，不能是 null。无参数工具也应显式声明空对象 schema。

表达要点：JSON Schema、参数约束、无参数工具。

常见误区：用自然语言描述参数而不提供结构化 schema。

Q27：MCP Tool 的 outputSchema 有什么价值？

参考答案：outputSchema 描述结构化输出格式，帮助客户端验证结果，也让模型和程序更稳定地解析工具输出。它与 structuredContent 配合效果最好。

表达要点：结构化结果、校验、类型信息、解析稳定。

常见误区：只返回一段文本，让模型自行猜字段。

Q28：structuredContent 是什么？

参考答案：structuredContent 是 tool result 中的结构化 JSON 对象。它适合承载可机器解析的数据，通常也会把序列化 JSON 放在 text content 中以兼容旧客户端。

表达要点：结构化 JSON、兼容性、和 outputSchema 配合。

常见误区：把它当成自然语言回答字段。

Q29：MCP tool result 里的 content 可以有哪些类型？

参考答案：可以有 text、image、audio、resource link、embedded resource 等内容块。不同内容块可带 annotations，用于说明 audience、priority 等元信息。

表达要点：多模态内容块、resource link、embedded resource。

常见误区：认为工具结果只能是字符串。

Q30：Protocol Error 和 Tool Execution Error 区别？

参考答案：Protocol Error 是协议层错误，如未知方法、请求格式错误；Tool Execution Error 是工具执行失败，如业务校验失败、API 失败，通常通过 isError: true 放在工具结果中。

表达要点：协议结构问题 vs 业务执行问题。

常见误区：所有错误都用 JSON-RPC error，导致模型难以自我修复。

Q31：MCP 中 Sampling 是什么？

参考答案：Sampling 允许 Server 通过 Client 请求 LLM 生成内容，但必须由 Client/Host 控制模型、prompt、权限和用户审批，避免 Server 任意访问模型或上下文。

表达要点：Server 发起、Client 控制、LLM 调用、安全。

常见误区：让 MCP Server 直接拿完整对话去调用模型。

Q32：MCP 中 Roots 是什么？

参考答案：Roots 是 Client 提供给 Server 的 URI 或文件系统边界，告诉 Server 可以在哪些范围内操作或检索。

表达要点：边界、最小权限、文件系统范围。

常见误区：给 Server 整个磁盘或整个组织数据权限。

Q33：MCP 中 Elicitation 是什么？

参考答案：Elicitation 是 Server 通过 Client 向用户请求补充信息的能力，比如缺少字段、需要表单输入或需要用户打开某个 URL。

表达要点：Server 请求、Client 展示、用户补充。

常见误区：Server 直接弹窗或绕过 Host 与用户交互。

Q34：MCP Server 是否应该保存用户隐私数据？

参考答案：默认不应保存超出任务所需的数据。Server 只应接收必要上下文，遵循最小权限、明确授权、访问控制和数据保留策略。

表达要点：最小权限、数据最小化、授权、保留策略。

常见误区：为了“更聪明”把所有对话和工具结果都持久化。

Q35：如何把 MCP 工具接入模型 Function Calling？

参考答案：Host 通过 MCP Client 调用 tools/list 获取工具定义，将 MCP 工具映射为模型 API 可见的 function tools；模型返回 tool call 后，Host 再通过 MCP Client 调用 tools/call，最后把结果回传模型。

表达要点：发现、映射、调用、回传；Host 控制中间过程。

常见误区：以为 MCP Server 自动变成模型内置工具。

C. Function Calling 面试题

Q36：Function Calling 的完整调用链是什么？

参考答案：应用发送用户输入和 tools schema 给模型；模型返回 function call；应用解析和校验参数；应用执行函数；应用把 function_call_output 或 tool message 回传；模型基于结果生成最终答案或继续调用。

表达要点：schema、tool call、执行、结果回传、继续循环。

常见误区：忘记第二次模型调用，导致只有工具结果没有最终回答。

Q37：函数描述应该怎么写？

参考答案：描述应说明工具做什么、何时用、何时不要用、输入要求和副作用。多个工具相似时，要写清边界和差异。

表达要点：清晰、边界、反例、副作用。

常见误区：描述写成“useful tool”这类泛化词。

Q38：为什么 JSON Schema 很重要？

参考答案：JSON Schema 约束参数类型、必填字段、枚举、嵌套结构和额外字段，有助于提升参数可解析性、减少幻觉和便于应用校验。

表达要点：类型、必填、枚举、校验、稳定性。

常见误区：只在 prompt 里要求格式，不做 schema 校验。

Q39：strict: true 的意义是什么？

参考答案：严格模式要求模型生成更符合 schema 的调用参数，并让 SDK 或 API 对不合法参数更早报错或拒绝。它提升可靠性，但 schema 必须设计得足够准确。

表达要点：严格参数、可靠性、schema 质量。

常见误区：开启 strict 后就不做业务校验。

Q40：call_id 有什么作用？

参考答案：call_id 用于关联某次模型生成的工具调用和应用回传的工具执行结果。多个并行 tool call 时尤其重要。

表达要点：关联、并行、多轮。

常见误区：只按工具名回传结果，导致结果匹配错乱。

Q41：工具结果应该返回自然语言还是 JSON？

参考答案：优先返回结构化 JSON，必要时附带简短自然语言解释。结构化结果便于模型和程序解析，自然语言便于最终表达和兼容。

表达要点：结构化优先、兼容文本。

常见误区：返回长篇日志，让模型在噪声中找关键字段。

Q42：如何防止模型调用不存在的工具？

参考答案：应用端必须根据 tool registry 校验工具名。未知工具应作为错误处理，不应动态执行任意函数名。

表达要点：白名单、registry、拒绝未知工具。

常见误区：用反射按模型返回的名称直接调用函数。

Q43：如何处理模型生成的非法参数？

参考答案：先做 schema 校验和业务校验。可恢复错误以工具错误形式回传模型，让模型修正；不可恢复或高风险错误应中止或请求用户补充。

表达要点：schema 校验、业务校验、自修复、用户补充。

常见误区：自动补默认值导致业务含义错误。

Q44：什么时候应该强制调用工具？

参考答案：当回答必须依赖实时数据、数据库状态、权限校验、外部计算或结构化抽取时可以强制调用。开放式解释、常识问答或工具不必要场景不应强制。

表达要点：实时、必须、校验、抽取。

常见误区：所有问题都强制工具调用，增加延迟和误用。

Q45：什么时候禁止调用工具？

参考答案：当用户只是要求解释概念、总结已给文本，或上下文不允许外部访问时可禁止调用。安全审查阶段也可能先禁止工具。

表达要点：纯生成、隐私、安全、节省成本。

常见误区：让模型在敏感 prompt 中自由使用外部工具。

Q46：如何处理多个 tool call？

参考答案：先判断工具是否只读、是否相互依赖、是否有副作用。只读无依赖可并行；有依赖按顺序执行；有副作用需审批和幂等保护。

表达要点：并行、依赖、副作用、幂等。

常见误区：所有工具调用无脑并发。

Q47：Function Calling 会不会产生幻觉？

参考答案：会。模型可能选错工具、编造参数或误读结果。Function Calling 降低的是输出格式不稳定，不是彻底消除推理错误。

表达要点：格式可靠性提高，语义仍需校验。

常见误区：把工具调用结果当成天然事实，不检查来源和权限。

Q48：工具参数中缺少必要信息怎么办？

参考答案：不应让模型猜关键字段。可以让模型追问用户，或通过 MCP Elicitation / UI 表单补充信息，再调用工具。

表达要点：追问、补字段、不猜测。

常见误区：根据上下文猜身份证、订单号、账户等关键字段。

Q49：Function Calling 和 API 调用有什么区别？

参考答案：API 调用是应用代码直接调用外部接口；Function Calling 是模型决定要调用哪个工具以及生成参数，然后应用再执行 API 调用。

表达要点：模型决策层 vs 程序执行层。

常见误区：把 function schema 当作真实 HTTP API。

Q50：如何设计工具返回错误？

参考答案：错误应简洁、可操作、无敏感泄露。例如说明哪个字段非法、允许范围是什么、是否可重试。不要把完整栈、token、内部 SQL 返回给模型。

表达要点：可操作、脱敏、可重试信息。

常见误区：返回“failed”导致模型无法修正。

Q51：如何避免工具调用无限循环？

参考答案：设置最大轮数、最大工具调用次数、重复调用检测、预算限制；如果同一工具同一参数多次失败，应中止或请求人工介入。

表达要点：max turns、重复检测、预算、失败策略。

常见误区：只相信模型会自己停下来。

Q52：工具 schema 太多会怎样？

参考答案：工具过多会增加 token 成本、选择难度和误调用概率。应按场景动态暴露工具，使用 namespace 或工具检索，保持工具职责单一。

表达要点：动态工具集、namespace、职责单一。

常见误区：把全公司 API 一次性塞给模型。

Q53：如何做工具版本管理？

参考答案：工具名或 schema 变更要考虑兼容性。破坏性变更可使用版本后缀或新工具名，旧工具保留一段时间；同时更新描述、测试和审计。

表达要点：兼容、版本、灰度、测试。

常见误区：直接改参数名，导致模型和客户端调用失败。

Q54：为什么工具输入必须再校验？

参考答案：模型输出不可信，用户输入也不可信。即使 schema 校验通过，也可能违反业务规则、权限规则或安全策略。

表达要点：模型不可信、业务校验、权限校验。

常见误区：schema 校验等于安全校验。

Q55：Function Calling 与 MCP Tool 有什么映射关系？

参考答案：Function Calling 的 function schema 可由 MCP Tool 的 inputSchema、描述和名称映射而来；模型生成 function call 后，应用再通过 MCP tools/call 执行真实 MCP Tool。

表达要点：schema 映射、Host 执行、MCP Client 中转。

常见误区：把 MCP tools/call 暴露给模型直接生成 JSON-RPC。

D. Agent 原理面试题

Q56：Agent loop 的核心步骤？

参考答案：接收目标，构建上下文，模型决策，工具调用，观察结果，更新状态，必要时继续循环，满足终止条件后输出。

表达要点：observe-think-act-observe-finish。

常见误区：没有状态更新和终止条件。

Q57：Agent 如何做规划？

参考答案：简单任务可隐式规划；复杂任务可显式生成 plan，拆分子任务，逐步执行并根据观察修正。工程上要限制计划粒度和最大步骤。

表达要点：显式/隐式规划、子任务、修正、限制。

常见误区：让模型生成很长计划但不验证执行。

Q58：Planner/Executor 架构有什么优缺点？

参考答案：优点是职责清晰、可观测、便于控制；缺点是延迟高、成本高、可能出现计划和执行脱节。适合复杂或高风险任务。

表达要点：职责、可控、成本、脱节风险。

常见误区：简单任务也上复杂架构。

Q59：Agent 如何选择工具？

参考答案：模型基于工具名称、描述、schema、上下文和指令选择工具。系统可通过动态工具暴露、工具分组、路由器模型和规则策略辅助选择。

表达要点：描述、schema、动态暴露、路由。

常见误区：只靠工具名，不写清楚使用边界。

Q60：Agent 的状态包括什么？

参考答案：状态包括用户目标、对话历史、已执行步骤、工具结果、错误、预算、权限决策、短期记忆和最终输出草稿。

表达要点：任务状态、工具观察、预算、权限。

常见误区：只保存聊天消息，不保存工具调用和决策。

Q61：短期记忆和长期记忆区别？

参考答案：短期记忆服务当前任务，通常存在上下文或运行状态中；长期记忆跨会话保存偏好、历史事实或用户信息，需要检索、更新、过期和隐私控制。

表达要点：当前任务 vs 跨会话；检索和隐私。

常见误区：把所有对话永久写入长期记忆。

Q62：Agent 如何使用 RAG？

参考答案：Agent 可以把检索作为工具，在需要外部知识时查询文档库，再基于检索结果回答或继续行动。复杂任务可多轮检索、重排、交叉验证。

表达要点：检索工具、上下文增强、多轮验证。

常见误区：一次检索结果不管质量直接生成。

Q63：Agent 如何避免上下文爆炸？

参考答案：使用摘要、状态压缩、检索式记忆、只保留关键工具结果、窗口裁剪和结构化 scratchpad。不要把所有日志原样塞回模型。

表达要点：压缩、检索、裁剪、结构化。

常见误区：上下文越多越好。

Q64：Agent 如何处理工具失败？

参考答案：根据失败类型决定重试、改参数、换工具、请求用户补充或中止。要限制重试次数，并记录错误链路。

表达要点：分类处理、重试限制、错误链路。

常见误区：失败后让模型无限尝试。

Q65：Agent 如何做权限控制？

参考答案：在工具执行前进行策略检查，包括用户身份、工具权限、参数范围、副作用级别和审批状态。模型建议不能绕过应用权限。

表达要点：执行前检查、最小权限、审批。

常见误区：在 prompt 里说“不要越权”就算权限控制。

Q66：Agent 如何保证输出质量？

参考答案：可用结构化输出、引用证据、工具结果校验、事实检查、输出 guardrails、评测集和人工审核。高风险场景要保留来源和置信度。

表达要点：结构化、证据、校验、评测。

常见误区：只看单次 demo 表现。

Q67：多 Agent 适合什么场景？

参考答案：适合任务可明显分工、需要不同专业能力或上下文隔离的场景，如研究、写作、代码审查、客服分流。简单任务不需要多 Agent。

表达要点：分工、专业化、隔离、协调成本。

常见误区：用多个 Agent 增加复杂度但没有收益。

Q68：Agent as Tool 和 Handoff 有什么区别？

参考答案：Agent as Tool 是主 Agent 把子 Agent 当作一个工具调用，控制权仍在主 Agent；Handoff 更像把对话或任务控制权转交给另一个 Agent。

表达要点：调用子能力 vs 转交控制权。

常见误区：所有分工都用 handoff，导致上下文和责任不清。

Q69：如何设置 Agent 终止条件？

参考答案：终止条件包括模型 final answer、任务验收通过、最大轮数、超时、预算耗尽、重复调用、不可恢复错误或用户拒绝授权。

表达要点：成功和失败都要有终止。

常见误区：只设置成功终止，不设置失败终止。

Q70：Agent 的可观测性要记录什么？

参考答案：记录输入、模型输出、工具调用、参数、结果摘要、错误、延迟、token、费用、审批、trace id 和最终结果。敏感信息要脱敏。

表达要点：trace、tool logs、metrics、脱敏。

常见误区：只记录最终回答，无法 debug 中间过程。

Q71：Agent 的评测怎么做？

参考答案：要覆盖任务成功率、工具选择正确率、参数正确率、事实准确率、安全拒答、成本延迟和用户满意度。可用离线 golden set、模拟工具、在线 A/B 和人工抽检。

表达要点：多指标、离线在线、模拟工具。

常见误区：只用 BLEU 或只看人工主观印象。

Q72：Agent 和传统后端服务如何结合？

参考答案：Agent 负责理解和动态决策，传统后端负责确定性业务逻辑、权限、数据一致性和事务。关键操作应落在后端服务中执行。

表达要点：LLM 决策，后端执行和约束。

常见误区：让 Agent 直接操作数据库绕过服务层。

Q73：Agent 如何处理实时数据？

参考答案：通过工具调用查询实时系统，不应依赖模型训练知识。工具返回数据要带时间戳、来源和有效期，模型回答中说明数据时点。

表达要点：工具实时查询、时间戳、来源。

常见误区：用模型记忆回答库存、价格、状态等实时问题。

Q74：Agent 中反思机制有什么风险？

参考答案：反思可帮助修正错误，但也会增加成本、延迟和自我确认偏差。工程上应基于明确触发条件使用，如校验失败或高风险输出。

表达要点：收益、成本、触发条件。

常见误区：每一步都反思，导致效率低且未必更准。

Q75：如何防止 Agent 自主做高风险操作？

参考答案：把高风险工具设为需要审批，使用 dry run 展示影响，加入幂等键和回滚方案，限制参数范围，并在服务端再次校验权限。

表达要点：审批、dry run、幂等、回滚、服务端校验。

常见误区：只依赖模型“谨慎行事”的提示。

E. 工程实践与系统设计

Q76：设计一个企业知识库 Agent，你会怎么做？

参考答案：使用 RAG 检索文档，按用户权限过滤索引或结果，工具化检索、文档读取和引用生成，最终输出带来源。可用 MCP 暴露文档资源和检索工具。

表达要点：权限过滤、检索、引用、MCP resources/tools。

常见误区：先检索再过滤权限，可能泄露摘要或元数据。

Q77：设计一个客服 Agent，你会提供哪些工具？

参考答案：订单查询、用户资料读取、知识库检索、工单创建、退款申请 dry run、人工转接。写操作和退款类工具需要审批或业务规则限制。

表达要点：读写分离、审批、人工转接。

常见误区：让 Agent 直接退款或改地址。

Q78：如何为 Agent 设计工具粒度？

参考答案：工具应职责单一但不要过碎。一个工具完成一个稳定业务动作，参数明确，返回结构化结果。多个强相关小动作可封装成后端 workflow。

表达要点：单一职责、稳定动作、不要过碎。

常见误区：把底层 CRUD 全暴露给模型。

Q79：如何做动态工具加载？

参考答案：根据用户意图、权限、任务阶段和上下文选择工具子集。可使用工具检索、namespace、MCP tools/list 动态发现，减少 token 和误调用。

表达要点：权限、意图、阶段、工具检索。

常见误区：全量工具常驻上下文。

Q80：如何设计工具的幂等性？

参考答案：对写操作使用 idempotency key、操作预览、确认令牌和状态检查，避免重复调用导致重复扣款、重复发送或重复创建。

表达要点：幂等键、预览、确认、状态检查。

常见误区：只在前端按钮防重复，不在服务端防重复。

Q81：如何处理工具调用超时？

参考答案：为每个工具设置超时，区分可重试和不可重试；返回可操作错误给模型；长任务可用异步任务、进度通知或 task support。

表达要点：超时、重试、异步、进度。

常见误区：让模型一直等待，阻塞整个 Agent loop。

Q82：如何做成本控制？

参考答案：限制 max turns、动态工具子集、压缩上下文、缓存检索结果、并行只读工具、选择合适模型、监控 token 和工具费用。

表达要点：轮数、上下文、缓存、模型选择、监控。

常见误区：只优化模型单价，不优化调用次数。

Q83：如何做延迟优化？

参考答案：减少不必要工具、并行只读调用、缓存、流式输出、预取上下文、使用小模型路由和大模型处理复杂任务。

表达要点：并行、缓存、路由、流式。

常见误区：所有步骤串行等待。

Q84：如何做工具调用审计？

参考答案：记录用户、会话、工具名、参数摘要、权限决策、审批人、结果摘要、错误、时间、trace id。敏感字段脱敏或加密。

表达要点：谁、何时、调用什么、为何允许、结果如何。

常见误区：记录完整明文参数，造成二次泄露。

Q85：如何上线 Agent 功能？

参考答案：先离线评测，再灰度发布；只读工具先上线，写工具加审批；监控成功率、拒绝率、工具错误、成本、延迟和用户反馈；保留回滚开关。

表达要点：离线、灰度、只读先行、监控、回滚。

常见误区：直接给全量用户开放写操作。

Q86：如何处理模型版本变化？

参考答案：建立评测集和回归测试，记录模型版本，灰度切换，对工具选择率、参数错误率和安全指标做对比，必要时调整 prompt 和 schema。

表达要点：版本记录、评测、灰度、回归。

常见误区：换模型后只看几个样例。

Q87：如何设计 Agent 的 fallback？

参考答案：fallback 包括降级到普通问答、切换备用工具、请求人工介入、返回部分结果、提示用户补充信息。关键是不要假装完成。

表达要点：降级、备用、人工、部分结果、诚实失败。

常见误区：工具失败后模型编造结果。

Q88：如何处理并发会话？

参考答案：每个会话维护独立状态和权限上下文；工具调用使用 trace id 和 idempotency key；共享资源操作由后端事务和锁控制。

表达要点：会话隔离、trace、幂等、事务。

常见误区：把全局变量当作 Agent 状态。

Q89：如何处理敏感信息？

参考答案：输入和工具结果做数据分级、脱敏、最小化传递；敏感工具需要审批；日志加密或脱敏；长期记忆写入前需要明确策略。

表达要点：分级、脱敏、最小化、审批、日志保护。

常见误区：把完整用户资料放进 prompt。

Q90：如何把 MCP Server 纳入企业权限体系？

参考答案：远程 server 使用认证授权，server 端校验用户和 scope，Host 端做策略控制，工具级权限配置，审计所有调用。Resources 也要按用户权限过滤。

表达要点：双端权限、scope、工具级策略、审计。

常见误区：只在 Host 端过滤，Server 端完全信任调用方。

F. 安全、Debug 与辨析

Q91：什么是 prompt injection？

参考答案：prompt injection 是外部内容或用户输入试图覆盖系统指令、诱导模型泄露数据或误用工具的攻击。RAG 文档、网页、工具结果都可能携带注入内容。

表达要点：外部内容不可信、指令隔离、工具风险。

常见误区：只防用户输入，不防检索文档和工具输出。

Q92：如何防 prompt injection？

参考答案：区分指令和数据，对外部内容加边界标注；工具权限最小化；敏感操作审批；不要让检索内容决定安全策略；输出和工具参数做校验。

表达要点：隔离、最小权限、审批、校验。

常见误区：靠一句“忽略恶意指令”解决。

Q93：工具结果能否直接信任？

参考答案：不能。工具可能返回错误、过期数据、被污染数据或包含注入文本。应用应验证结构、来源、权限和时间戳。

表达要点：结构校验、来源、时间、权限。

常见误区：工具输出进模型前不做任何处理。

Q94：如何 debug Agent 选错工具？

参考答案：查看当轮 prompt、工具列表、工具描述、schema、模型输出和上下文；减少重叠工具；增强描述边界；用测试集统计工具选择率。

表达要点：trace、工具描述、上下文、测试集。

常见误区：只改系统 prompt，不看工具 schema。

Q95：如何 debug 参数生成错误？

参考答案：检查 schema 是否精确、字段描述是否清晰、required 和 enum 是否合理、用户信息是否充足、上下文是否有冲突。应用端给出可操作错误帮助模型修正。

表达要点：schema、字段描述、上下文、错误反馈。

常见误区：在执行器里静默修正所有参数。

Q96：如何 debug Agent 循环不停止？

参考答案：检查终止条件、工具错误是否可恢复、模型是否收到工具结果、是否重复同一调用、是否缺少最终回答指令。加 max turns 和重复检测。

表达要点：终止、结果回传、重复检测。

常见误区：继续提高 max turns 试图让它自然结束。

Q97：如何 debug 最终回答与工具结果不一致？

参考答案：检查工具结果是否结构化、是否被长上下文稀释、是否有冲突来源、模型是否被要求引用证据。可让最终输出基于固定字段生成。

表达要点：结构化、证据、冲突处理、字段约束。

常见误区：只要求“请准确回答”。

Q98：MCP 相比插件系统的优势是什么？

参考答案：MCP 提供标准化协议、能力协商、生命周期、transport 和 primitives，使不同 Host 与 Server 可互操作。传统插件系统往往绑定单一应用或平台。

表达要点：开放协议、互操作、可组合。

常见误区：认为 MCP 只是换了名字的插件。

Q99：MCP 相比 REST API 有什么不同？

参考答案：REST API 是通用 Web API 风格；MCP 是面向 LLM 应用的上下文和工具协议，内置工具发现、资源、提示词、能力协商、采样和用户交互等语义。

表达要点：REST 是接口风格，MCP 是 AI 应用接入协议。

常见误区：认为 MCP Server 不需要认证，因为它不是 REST。

Q100：Function Calling 相比直接生成 JSON 有什么优势？

参考答案：Function Calling 有明确工具列表、函数名、参数 schema、调用 ID 和运行时回传机制，更适合多轮工具执行。直接 JSON 更适合最终结构化输出。

表达要点：工具语义、call id、多轮执行。

常见误区：用直接 JSON 模拟复杂工具编排。

Q101：RAG 与 Function Calling 的关系？

参考答案：RAG 可以实现为一个或多个 Function Tool，例如 search_docs 和 read_doc。Function Calling 提供调用检索工具的方式，RAG 提供知识增强能力。

表达要点：RAG 是能力，Function Calling 是调用机制。

常见误区：把二者视为只能选一个。

Q102：RAG 与 MCP 的关系？

参考答案：MCP Server 可以暴露文档 Resources、检索 Tools 或 Prompt 模板，从而把 RAG 系统标准化接入多个 Host。

表达要点：MCP 标准化暴露 RAG 能力。

常见误区：认为用了 MCP 就不需要检索质量优化。

Q103：Agent 如何处理合规审计？

参考答案：要有权限策略、人工审批、工具调用日志、模型版本记录、数据脱敏、结果留痕和回滚路径。高风险行业还需要评测和人工复核。

表达要点：策略、日志、版本、脱敏、复核。

常见误区：只保存聊天记录作为审计。

Q104：工具调用结果要不要进入长期记忆？

参考答案：默认不要。只有明确有长期价值、用户授权且通过隐私策略的数据才应写入长期记忆，并应支持过期和删除。

表达要点：授权、价值、隐私、过期。

常见误区：把所有工具结果都写入 memory。

Q105：如何回答“Agent 是否可靠”？

参考答案：Agent 的可靠性来自工程约束，而不是模型本身。需要 schema、工具校验、权限控制、状态管理、评测、监控、fallback 和人工审批共同保证。

表达要点：工程系统可靠性、分层防护。

常见误区：只讨论模型准确率。

Q106：如何回答“工具越多越好吗”？

参考答案：不是。工具越多，模型选择成本和误调用风险越高。应按任务动态暴露最小必要工具集，并保持工具职责清晰。

表达要点：最小必要、动态暴露、选择风险。

常见误区：把工具数量当作 Agent 能力指标。

Q107：如何回答“Agent 会替代后端吗”？

参考答案：不会。Agent 适合自然语言理解和动态决策，后端仍负责确定性业务逻辑、数据一致性、权限、事务和合规。Agent 应调用后端，而不是替代后端。

表达要点：Agent 决策，后端约束执行。

常见误区：让模型直接写数据库。

Q108：如何回答“怎么降低 Agent 幻觉”？

参考答案：使用工具查询事实、RAG 引用来源、结构化输出、事实校验、检索重排、拒答策略、评测集和人工审核。幻觉不能靠单句 prompt 根除。

表达要点：工具、证据、校验、评测、拒答。

常见误区：把 temperature 调低当作唯一方案。

Q109：如何回答“怎么判断该用 Agent 还是普通 Workflow”？

参考答案：如果流程固定、规则明确、容错低，用 Workflow；如果目标开放、路径不确定、需要根据中间结果动态决策，可用 Agent。很多生产系统采用混合模式。

表达要点：固定 vs 动态；混合模式。

常见误区：所有 AI 功能都做成 Agent。

Q110：如何回答“Agent 失败时应该怎么办”？

参考答案：应识别失败类型，能重试则有限重试，不能重试则降级、请求用户补充、转人工或返回部分结果。不要编造完成状态。

表达要点：分类、有限重试、降级、人工、诚实失败。

常见误区：失败后让模型生成一个看似完整的答案。

7. 核心对比表

7.1 MCP vs Function Calling vs Agent

7.2 Tools vs Resources vs Prompts

7.3 Agent、Workflow、RAG

8. 面试前 10 分钟背诵卡

1. MCP 是协议，不是 Agent 框架；Function Calling 是调用机制，不是真正执行；Agent 是运行范式，不是单次 prompt。
2. MCP 架构：Host 管控，Client 连接，Server 暴露 Resources、Prompts、Tools。
3. MCP 通过 initialize 做版本和能力协商；正常操作前不要假设工具可用。
4. MCP transport：stdio 适合本地子进程；Streamable HTTP 适合远程和多连接。
5. MCP tool：tools/list 发现，tools/call 调用；inputSchema 定义入参，outputSchema 和 structuredContent 提升结果可靠性。
6. Function Calling：应用传 tools schema，模型返回 tool call，应用执行，结果带 call_id 回传。
7. 模型输出的工具参数永远不可信，必须 schema 校验、业务校验、权限校验。
8. Agent loop：目标、推理、行动、观察、修正、终止。
9. Agent 工程重点：状态、工具、权限、预算、错误恢复、可观测性、评测。
10. 安全重点：最小权限、human-in-the-loop、prompt injection 防护、工具审计、敏感信息脱敏。

9. 可直接套用的面试回答模板

9.1 解释三者关系

MCP、Function Calling 和 Agent 是三个层次。MCP 是协议层，负责把外部资源、工具和提示词以标准方式接入 LLM 应用；Function Calling 是模型 API 层的结构化工具调用机制，模型生成函数名和参数，但应用负责执行；Agent 是应用层的运行范式，负责围绕目标循环调用模型和工具、维护状态、处理错误并终止。实际系统里，Agent Host 可以通过 MCP Client 发现 MCP Server 的工具，再把它们映射成模型可调用的 function tools。

9.2 解释工具调用安全

工具调用安全不能只靠 prompt。我的设计会分三层：第一层是工具 schema 和业务校验，保证参数合法；第二层是权限和审批，高风险工具必须 human-in-the-loop；第三层是运行时审计和限制，包括超时、限流、幂等、日志、敏感信息脱敏。对于 MCP，还要保证 Server 只拿到必要上下文，Client/Host 负责隔离不同 Server。

9.3 解释 Agent 可靠性

Agent 可靠性来自系统工程，而不是模型单点能力。需要限制工具集、设计清晰 schema、使用结构化输出、设置 max turns、对工具错误做分类恢复、对高风险操作加审批，并通过 trace 和评测集持续监控工具选择率、参数错误率、任务成功率、成本和延迟。

9.4 解释何时不用 Agent

如果任务流程固定、规则明确、容错率低或存在强事务要求，我会优先用传统 workflow 或后端服务，只在自然语言理解、检索总结、复杂分流等局部引入 LLM。Agent 更适合路径不确定、需要动态决策的任务，不适合无边界地接管核心业务操作。

10. 最后复盘

面试中回答 MCP、Function Calling、Agent 时，最重要的是把“边界”说清楚：

• 模型负责推理和生成调用意图。
• 应用负责执行、权限、状态和审计。
• MCP Server 负责按协议暴露特定能力。
• Agent 负责把这些组件编排成任务闭环。

能把这四句话说清，再结合 schema、tool result、human-in-the-loop、prompt injection、max turns、trace 和评测，基本就能覆盖大多数 AI Agent 工程面试追问。

__END__