协议与上下文八股：AI PM 面试必会的 6 个工程术语
📍 AI 求职速查
你会遇到的开场
Section titled “你会遇到的开场”这一组术语是 2026 年面试的「新八股」 —— 2024 年还没人问，现在面试官几乎一定要扫一遍：
「MCP 是啥？你用过吗？」
「你做过 Tool Use / Function Calling 吗？和 MCP 啥关系？」
「Long Context 200K 是不是越大越好？」
「你怎么把 LLM 成本砍一半？」
答得准 = 显示你真做过生产环境的 AI 产品；答不出 = 被归到「只看过 demo（演示）」。
这一篇把 6 个核心术语讲清楚 —— 重点是实战判断口径；文末再加餐一个 2026 年常被追问的「上下文工程」。
先建立大局观
Section titled “先建立大局观”这一组 6 个术语分两组：
协议组(3 个)：怎么让 LLM 接外部世界(数据 / 工具 / API)
- MCP / Tool Use / Custom MCP Server
上下文 + 成本组(3 个)：怎么让 LLM 跑得起 + 跑得便宜
- Long Context / Prompt Caching / Token Cost 管控
两组合起来 = 生产环境 LLM 产品的两个核心工程问题。
一、MCP(Model Context Protocol)
Section titled “一、MCP(Model Context Protocol)”是啥:Anthropic 2024 年底推出的协议 —— AI 圈的 USB-C。让 LLM 能用标准化方式接外部工具 / 数据 / 系统。
核心 4 个概念：
| 概念 | 啥意思 | 例子 |
|---|---|---|
| Server（服务端） | 提供工具 / 资源 / 提示词 | GitHub MCP / Slack MCP / Postgres MCP |
| Host / Client（宿主 / 客户端） | 宿主应用负责跟用户对话、调模型，内部为每个 server 各开一个 client 连接去调用 | Claude Desktop / Claude Code / Cursor |
| Tool（工具） | 函数调用 | github_create_issue |
| Resource（资源） | 可读数据 | 文件 / 数据库一行 |
为啥 2026 年特别热：
- Anthropic 推 Claude 生态标配 —— Claude Desktop / Claude Code 原生支持
- OpenAI 2025 年也跟进：Agents SDK、Responses API（能直连远程 MCP 服务器）和 ChatGPT（开发者模式）都原生支持 MCP —— 出现了跨厂商标准
- 2025-12-09 Anthropic 把 MCP 捐给 Linux 基金会 —— 交给新成立的中立机构 Agentic AI Foundation（AAIF）托管，MCP 从一家公司的协议变成全行业标准（这是 2026 年面试官最爱问的关键事件）
- 2026-07-28 新版规范：协议改成无状态（去掉初始化握手和会话，每个请求自带版本和能力信息），Tasks（异步任务）移出核心、变成官方扩展，Sampling（server 借 client 的模型做推理）等进入弃用期；官方 Python SDK 同一天升到 2.0
- SaaS（在线订阅软件）厂商都在推自家 MCP（Slack / Linear / Notion / GitHub / 字节 / 国内厂商）
面试怎么答：
「MCP 是 2026 年最值得关注的标准 —— 解决『每家 LLM 都自己定义工具协议』的乱象。类比 USB-C：以前 iPhone 一个口 / 安卓一个口 / 电脑一个口，USB-C 统一后大家都能用。MCP 给 LLM 生态干一样的事。Anthropic 推动 + OpenAI 跟进 + 交给 Linux 基金会中立托管 = 这个标准基本稳了。」
常被连着问：MCP 和 A2A 啥关系？
A2A（Agent2Agent，智能体之间的通信协议）由 Google 发起，2025-06-23 捐给 Linux 基金会，2026-03 发布 1.0，2026-08-17 也加入了 AAIF。口径：MCP 管 agent 接工具和数据，A2A 管 agent 和 agent 之间协作（互相发现、派活、回传结果），两者互补，不是二选一。
💡 想深入 MCP 协议设计哲学 → MCP 协议详解 那一篇。
二、Tool Use / Function Calling
Section titled “二、Tool Use / Function Calling”是啥:LLM 决定调用外部函数。流程：
1. 用户提问 ↓2. LLM 判断:"这个问题我自己答不了,得调函数" ↓3. LLM 输出:"请调用 X 函数,参数 Y" ↓4. 后端执行函数,拿到结果 ↓5. 结果返给 LLM ↓6. LLM 基于结果生成最终答案
Tool Use vs RAG:
| 维度 | RAG | Tool Use |
|---|---|---|
| 数据 | 静态文档(知识库) | 动态计算(实时查 API / 改数据) |
| 例子 | 查公司政策 | 查实时天气 / 下单 / 发邮件 |
| 状态 | 只读 | 可读可写 |
主流实现（分两层，别当成三选一）：
| 层 | 名字 | 管什么 |
|---|---|---|
| 模型层 | Function Calling（OpenAI）/ Tool Use（Anthropic）等，各家格式不同 | 模型「说要调哪个工具、传什么参数」的能力 |
| 接入层 | MCP（跨厂商） | 工具服务怎么被发现、怎么被调用的统一标准；MCP 服务器里的工具，最后还是交给模型的工具调用能力去用 |
面试怎么答：
「Tool Use 跟 RAG 是 agent 接外部世界的两条腿 —— RAG 拿信息，Tool Use 干事情。我做产品时区分：只读 + 静态文档 走 RAG，实时 / 可写 / 有副作用（会改变外部状态，比如下单、发邮件）走 Tool Use。两者经常组合用 —— 先 RAG 拿背景，再 Tool Use 执行操作。至于和 MCP 的关系：MCP 不替代工具调用，它把工具的接入方式标准化，模型最后还是用自己的工具调用能力去调 MCP 服务器里的工具。」
三、Custom MCP Server(自建 MCP 服务)
Section titled “三、Custom MCP Server(自建 MCP 服务)”是啥:自己写一个 MCP server，把自家内部 API / 数据暴露给 LLM 调用。
典型用例:
公司内部 CRM / 数据库 / 监控系统包成 MCP server → 让 Claude Code / Cursor / TraeCode 等所有支持 MCP 的客户端都能调用。
啥时候自建 vs 直接 API：
| 场景 | 选什么 |
|---|---|
| 多个客户端要复用（Claude / Cursor / TraeCode） | 自建 MCP server |
| 只有一个客户端用 | 直接 API（MCP 多此一举） |
| 要跟开源生态对接 | MCP server（社区已经有 Notion / Linear / GitHub 等开源 MCP） |
实操（简化版，Python + 官方 SDK 的 MCPServer，1.x 版本时叫 FastMCP）：
from mcp.server.mcpserver import MCPServer
mcp = MCPServer("我的公司 CRM")
@mcp.tool()def get_customer(customer_id: str) -> dict: """查询客户信息""" return crm_api.fetch(customer_id) # crm_api 换成你公司自己的接口
if __name__ == "__main__": mcp.run()10 行代码，就这样。crm_api 只是示意，要换成你公司自己的接口，不然调用时会报错。
注意版本：官方 Python SDK 在 2026-07-28 发布 2.0，pip install mcp 现在装到 2.x，FastMCP 改名成了 MCPServer。网上旧教程里的 from mcp.server.fastmcp import FastMCP 在 2.x 下一运行就报 ModuleNotFoundError；想继续用旧写法，就装 pip install "mcp<2"。
面试怎么答:
“PM 不必亲自写 MCP server，但要知道啥时候建议团队建 MCP。判断口径：这个内部 API 是不是会被多个 LLM 客户端用？ 是的话建 MCP(一次写多处复用)，不是的话直接 API(MCP 反而是工程负担)。”
💡 想看 MCP server 完整写法 → MCP 协议详解 里有一个实测能跑的 Python 完整示例，还有接进 Claude Code 的步骤。
四、Long Context(超长上下文)
Section titled “四、Long Context(超长上下文)”是啥：大上下文窗口模型能装一本书 / 一个仓库 / 几百页文档。
主流 200K+ 模型(2026 年) —— 模型表 RAG 八股 那篇已经列过，这里从账单视角换个切入角度:
真实账单震撼：
假设你做一个公司客服 bot，每天 1 万次提问。系统提示词 5K + 检索文档 20K + 用户问题 1K = 每次 26K 输入。下表按 Sonnet 5.5 的标价估算（截至 2026-10-12：输入 $2、缓存读取 $0.10，都是每百万 token；缓存读取价在 2026-10-07 从 $0.20 降了一半，见官方价格页）：
| 方案 | 每次输入成本 | 月度成本（30 天 × 1 万次） |
|---|---|---|
| 不开 Prompt Caching | 约 $0.052 | 约 $15,600 |
| 只缓存 5K 系统提示词（检索文档每次都不一样，缓存不了） | 约 $0.0425 | 约 $12,750 |
| 再把检索文档压到约 4K（共 10K 上下文，系统提示词照样缓存） | 约 $0.0105 | 约 $3,150 |
| 换个场景：资料是固定知识库（系统提示词 + 资料共 25K，整段缓存） | 约 $0.0045 | 约 $1,350 |
（缓存写入的一次性加价很小，这里忽略不计。）
数字直观告诉你：上下文不是越长越省事，是越长越烧钱；而且缓存不是万能的，只有每次都一模一样的前缀才能缓存。RAG 每次检索回来的文档不一样，只能靠少放、放准来省；知识库小（官方经验是小于约 20 万 token）又固定，才适合整份放进提示词再开缓存。
3 个权衡(详细比对见 RAG 八股 Long Context 段):
- 越长越贵 —— 按输入 token 算钱
- 越长越慢 —— 200K 输入要 30-60 秒返回
- 「中间丢失」效应 —— 太长上下文里中间的内容模型注意力弱化
面试怎么答：
「我看一个 AI 产品的 Long Context 策略，先看月账单数字，再分清哪部分是每次都不变的前缀：系统提示词、固定知识库这类不变的，上 Prompt Caching，这部分输入费能省九成；每次检索回来的内容缓存不了，只能靠少放、放准来省。如果你真的每次都要 200K，先反问『真的需要 200K 吗，80K + 分层摘要能不能等效？』—— 大部分 200K 用法是过度设计。」
五、Prompt Caching(提示词缓存)
Section titled “五、Prompt Caching(提示词缓存)”是啥:Anthropic / OpenAI 都推出的成本优化机制。把 prompt 中不变的部分(system prompt / 知识库 / 历史对话)缓存起来，下次调用直接用缓存，不重新计算。
Anthropic Prompt Caching（截至 2026-10-12，见官方价格页）：
| 操作 | 价格 |
|---|---|
| 写入缓存 | 1.25 倍普通输入价（5 分钟档） |
| 读取缓存 | 0.1 倍普通输入价（便宜九成）；有三款更低：Opus 5.5 和 Sonnet 5.5 是 0.05 倍（Sonnet 5.5 是 2026-10-07 降下来的），Fable 5.1 是 0.025 倍 |
| 默认有效期 | 5 分钟（每读一次会续期） |
| 长有效期 | 1 小时（写入 2 倍价；读取价和 5 分钟档一样，好处是两次请求隔超过 5 分钟也不用重新写入） |
OpenAI Prompt Caching（截至 2026-10-05，见官方说明，英文）：
- 默认自动缓存（不用手动开）；GPT-5.6 起也能自己指定缓存断点
- GPT-5.6 及之后的模型（含 GPT-6 系列）：写入按 1.25 倍收费，读取 0.1 倍（2026-09-29 发布的 GPT-6.1 Sol 更低，是 0.05 倍），缓存至少保留 30 分钟
- 更早的模型：写入不额外收费，读取打几折看具体模型
DeepSeek 上下文硬盘缓存（国内项目常用）：
- 默认开启，不用改代码；后面的请求和之前的请求前缀完全一样，重复部分才算「缓存命中」
- 命中价是未命中价的 1/50（deepseek-flash）或 1/30（deepseek-v4-pro），截至 2026-09-26，见官方价格页
省钱直观例子：
场景：100K 系统提示词不变，每次 1K 用户提问，按 Sonnet 5.5 标价算（输入 $2、缓存读取 $0.10，每百万 token）。
| 方案 | 单次成本 |
|---|---|
| 不开缓存 | 101K × $2/M ≈ $0.20 |
| 开缓存 | 缓存读 $0.01 + 1K 提问 $0.002 ≈ $0.012 |
| 节省 | 约 94% |
面试怎么答（高频题）：
「Prompt Caching 是 2025–2026 年成本优化的必修招。我看到团队 LLM 月账单超预算，第一招就是开 prompt caching。关键判断：你的 prompt 里有多少是每次都一模一样的前缀（系统提示词、固定知识库）—— 缓存只认完全相同的前缀，每次检索回来的文档一变就命中不了；不变的部分占九成，输入费大约能省八成。注意默认 5 分钟有效期，流量稀疏、两次请求常隔 5 分钟以上时，可以开 1 小时 TTL（缓存有效期）：写入贵一些，但省掉反复重写；也可以定期发个小请求把缓存『热』着（不要等用户调用）。」
六、Token Cost 管控
Section titled “六、Token Cost 管控”是啥:管 LLM 输入 + 输出 token 消耗，控制月度账单。
3 个核心指标:
| 指标 | 含义 |
|---|---|
| token / user / month | 每用户月度 token 消耗 |
| $ / user / month | 每用户月度成本 |
| $ / answered query | 每答一个问题的成本 |
6 个优化手段(优先级从高到低):
| # | 手段 | 省多少 |
|---|---|---|
| 1 | Prompt Caching | 60-90%(不变 prompt 占比高时) |
| 2 | 便宜模型干便宜活（Haiku 5.5 跑分类 / 摘要，Opus 跑复杂推理） | 单价降到 1/4 至 1/40（截至 2026-10-12 的标价，看提示长短和原来用的型号） |
| 3 | 缩短 system prompt(去废话 + 用结构化代替散文) | 30-70% |
| 4 | 限制输出长度(max_tokens 上限) | 20-50% |
| 5 | 限制上下文(RAG 头部 K 砍小 / 切分块砍小) | 20-40% |
| 6 | 用户提问缓存(相同提问重用历史答案) | 看场景 |
面试怎么答(高频题 + jackpot 题):
“Token Cost 管控我有套先开个大招，再精修的口径：第一招开 Prompt Caching(60-90% 立省),第二招按任务分级用模型(Haiku 跑简单 / Opus 跑复杂),第三招缩短系统提示词(从散文式改成结构化经常能砍 50%+)，后面再调输出长度 / 上下文 / 缓存提问。先做大的，小的不动也行；盲目调 K 或者切分块，收益小还容易副作用。”
💡 想看一个把 AI 改一处网页的 token 从约 3,500 压到约 100 的真实案例（按项目自己公布的数字；产品已停止运营，方法仍适用）→ Mold 案例篇。
加餐：上下文工程（Context Engineering）
Section titled “加餐：上下文工程（Context Engineering）”是啥：Anthropic 在 2025-09-29 的工程文章《Effective context engineering for AI agents》（英文）里，把它看作提示词工程的自然延伸：不只是把一段提示词写好，而是在 agent 干活的每一步，决定上下文窗口里放哪些信息、不放哪些。文章提到，窗口里的内容越多，模型从中准确找回信息的能力越会下降（原文叫 context rot，可以理解成「上下文腐化」），所以窗口再大也得精打细算。
4 个常用手法：
| 手法 | 做法 | Claude Code 里的例子 |
|---|---|---|
| 压缩 | 快装满时把前面的对话总结成摘要，带着摘要接着干 | /compact 和自动压缩 |
| 记忆（结构化笔记） | 把进度、决定写进窗口外的文件，需要时再读回来 | CLAUDE.md、auto memory（自动记忆） |
| 按需加载 | 工具说明、技能、资料先只放名字或路径，用到时才加载全文 | MCP 工具搜索、Skills（技能） |
| 子智能体隔离 | 把查资料、跑测试这类会产生大量中间内容的活派给子智能体，它在自己的窗口里干，只把结论带回来 | Subagents（子智能体） |
面试怎么答：
「Long Context 解决的是『装得下』，上下文工程解决的是『该装什么』。我会先看每一步真正需要哪些信息：固定的规则放系统提示词并开缓存，大段资料按需检索，长任务定期压缩、把进度记到文件里，会产生大量中间结果的活交给子智能体。窗口越大越要管，不然既贵又容易让模型分心。」
💡 想看 Claude Code 里怎么查上下文用量、什么时候压缩 → 上下文窗口怎么算。
总结：6 个术语怎么记
Section titled “总结：6 个术语怎么记”按协议组 vs 上下文成本组分：
协议组（让 LLM 接外部世界）：
- MCP —— 跨厂商标准
- Tool Use —— 单厂商函数调用
- Custom MCP Server —— 自家系统接进来
上下文成本组（让 LLM 跑得起 + 跑得便宜）：
- Long Context —— 能装多少
- Prompt Caching —— 怎么省
- Token Cost 管控 —— 整体管控
加餐：上下文工程 —— 每一步往窗口里放什么
面试加分小贴士
Section titled “面试加分小贴士”- 能讲 MCP 跟 Tool Use 的关系 > 单独讲 MCP(显示你懂演化)
- 能讲上下文工程（每一步该往窗口里放什么）> 只比谁的窗口大（显示你真做过 agent）
- 能讲 Long Context 不是越长越好 > 鼓吹「Gemini 1M 牛」(显示成熟度)
- 能给省钱数字 > 泛泛说「prompt caching 有用」（缓存读取便宜九成、开缓存省 60-90%、换便宜模型单价降到 1/4 至 1/40）
- 能讲优化优先级 > 列所有手段(知道先做啥后做啥)
- 能讲为啥不上 MCP > 万物 MCP 化(单客户端不必上)
- 想深入 MCP 协议 → MCP 协议详解