MCP 面试高频考点控制返回内容大小与上下文消耗你能答到第几层面试场景某团队用 MCP 把内部知识库接入 AI 应用Server 运行在 Docker 容器中暴露 Tools 与 Resources知识检索走 RAG 链路向量检索加可选重排。上线后问题来了——知识检索 Tool 经常把整段文档塞回模型上下文回答质量没明显提升上下文预算却被吃光。面试官围绕“如何控制 MCP 返回内容大小、降低上下文消耗”展开递进追问。第一轮基础问题——能力怎么选面试官知识库检索这个需求你会把它设计成 MCP 的 Tool 还是 Resource为什么候选人结论是优先做成 Tool只读文档需要按 URI 定位时再配 Resource。理由Tool 是模型可主动发起的操作适合“模型根据任务决定何时检索”Resource 由应用读取、通常用 URI 标识适合把确定的上下文交给模型 [资料1]。检索有输入参数查询、过滤条件属于按需动作不是一份固定资料。但要强调只读资料不要硬塞成有副作用的 Tool也不能把检索结果当成可信指令 [资料1]。面试官那检索应该由模型发起还是 Host 在调模型前主动做候选人两种都成立取舍在可预测性与灵活性。模型发起更灵活但要控制调用次数和权限Host 预检索流程简单、可预测 [资料1]。上下文预算紧张时我倾向 Host 先做一次受控检索把“候选集”压小再让模型在必要时通过 Tool 补充查询——避免模型反复调用把上下文越堆越大。第二轮追问为什么返回会失控面试官好那你说说返回内容为什么会变大候选人三个来源。一是切块粒度切块要保留语义完整性同时避免不相关内容占用大量上下文 [资料1]切太碎召回条数多、切太大单条就超预算二是召回策略只做单路向量检索容易召回一堆近似片段三是返回结构把整篇文档、原始 embedding、调试字段一起塞进 Tool 返回值模型根本用不上。面试官具体怎么压先讲检索侧。候选人结论是“混合召回 重排 阈值”三层过滤再在返回前做截断。资料明确建议混合查询把关键词与非向量检索和向量检索结合以提升召回可用语义排序、评分配置加权并通过向量查询参数做权重与最低阈值排除低分结果 [资料2]。流程上候选集先粗召回重排后只留少量高相关片段低于阈值的直接丢弃。阈值不是拍脑袋的数字要按业务 SLA 和离线评估确定。面试官嵌入维度这块有文章吗候选人有但要看存储约束。资料给出的做法是当向量库只支持有限维度时可指定较小的dimensions参数把维度从 3072 缩短以一定精度换取更小的向量体积 [资料3]。这只影响存储与检索成本不直接决定返回给模型的文本大小——返回内容大小主要靠片段选择与截断控制两件事别混。第三轮追问异常与安全面试官如果向量库超时或重排服务挂了Tool 怎么返回候选人降级而不是抛一大坨错误堆栈。向量检索失败可退回关键词检索重排失败就用原始召回分数排序并在返回值里给出明确的状态字段让模型知道“结果可能不完整”。错误信息要精简不能把内部路径、连接串带进上下文——凭据不应出现在日志、Tool 返回值或模型上下文中 [资料1]。超时与重试的具体值由业务 SLA 和压测决定不写死。面试官检索回来的文档里如果有“忽略以上指令”这类文字呢候选人检索文档是不可信数据其中指令不得覆盖系统规则 [资料1]。我会在返回结构上做隔离片段作为带来源元数据的“引用材料”字段返回而不是拼进指令区保留来源元数据才能支持引用和排错 [资料1]。同时 Tool 参数 schema 只是结构约束服务端仍要对查询串、过滤条件做校验和授权 [资料1]。面试官远程部署还要注意什么候选人认证、授权、会话管理、限流、超时都要考虑 [资料1]每次请求都要做授权检查不能只判断用户是否已登录 [资料1]。审计日志记录谁在何时调了哪个 Tool、资源范围与结果状态敏感字段脱敏 [资料1]。本地 stdio 场景则注意标准输出只走协议消息调试日志写标准错误 [资料1]。Docker 化只是部署形态安全边界不因容器而改变。方案设计与可落地示例面试官给个返回结构的设计。候选人接口设计如下伪代码不绑定具体 SDK。Tool: kb_search 输入: { query, top_k, filters, max_chars } 返回: { status: ok | degraded, snippets: [ { id, text, source_uri, score, rerank_score } ], truncated: bool, next_cursor?: string } 约束: - snippets 总字符数不超过 max_chars按重排分从高到低截断 - 每条 text 设单条上限超出截断并置 truncated - 不含 embedding 原始向量、内部路径、凭据 - source_uri 与 score 必填供引用与排错面试官容易踩的坑是什么候选人把“截断”只做在总长度上忽略单条片段。一条超长片段就能挤掉其余高相关结果模型看到的反而是最不精炼的那段。另一个坑是降级后不告诉模型状态模型把不完整结果当完整事实用。还有重排分与召回分直接混用排序量纲不同会误导截断顺序需要明确以重排分为准或做归一化。面试官适用边界呢候选人这套方案适合“知识密集型问答、上下文预算有限、对引用可追溯有要求”的场景 [资料4]。若问题需要跨大量文档做全局推理单纯压小返回可能损失召回此时应改为多轮受控检索或由 Host 编排而不是一味截断。面试官点评考察点是否理解 MCP 三类能力语义、Tool 与 Resource 的边界能否把 RAG 的召回、重排、阈值与 MCP 返回结构真正串起来安全与降级是否落到返回值设计上。合格回答能说清“为什么返回会变大”给出混合召回、重排、阈值、截断的组合并指出检索文档不可信、schema 不等于授权。加分项区分“向量维度压缩”与“文本截断”两个成本维度设计带status与truncated的返回契约主动说明降级策略、审计脱敏与参数由 SLA 决定而非写死。总结控制 MCP 返回内容大小本质是把 RAG 的“少而准”落实到协议返回契约上能力选型用 Tool 承载按需检索、Resource 承载确定上下文检索侧用混合查询与重排提升相关性用阈值与截断控制体积返回侧用结构化片段、来源元数据、状态字段保证可引用、可排错、可降级安全侧始终把模型输入与检索文档视为不可信凭据不进上下文。Docker、向量库只是载体真正的取舍在召回质量与上下文预算之间具体数值交给业务 SLA 与压测决定。参考资料MCP 基础知识本地知识库资料Retrieval-augmented generation (RAG) in Azure AI Searchhttps://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overviewVector embeddings | OpenAI APIhttps://platform.openai.com/docs/guides/embeddingsRetrieval-Augmented Generation for Knowledge-Intensive NLP Taskshttps://arxiv.org/abs/2005.11401
