第 06 讲 | Agent 的核心支撑技术：MCP、Tool Calling、记忆与缓存

本节我们将掌握：
Model Context Protocol（MCP）的定位和 2026 年重大变更
Tool Calling 的机制和工程实践
Agent 记忆的多层架构和调用链缓存
无框架趋势：什么时候不该用框架

MCP：Agent 的 USB-C 接口

没有 MCP 之前，每个客户端 Agent 应用（Claude Code、Codex、Cursor）和每个生产框架（LangGraph、CrewAI）都要自己写连接器连每个工具。N 个应用 × M 个工具 = N×M 个连接器。换模型？工具得重新适配。换框架？工具又得重写。

MCP 的思路：把工具提供和工具调用拆成 CS 架构，类似 LSP（Language Server Protocol）——编辑器无关，语言服务器一套就行。

它的定位一句话：Agent 世界的 USB-C 接口。

没有 MCP：每个客户端自己写连接器，N×M 个
有了 MCP：工具实现一次 MCP Server，所有 MCP Client 都能用（统一标准）

MCP 已经是事实标准。不支持 MCP 的客户端应用和生产框架都会被淘汰。

Russell经验⭐：MCP 是统一标准，但并不是迁移 0 成本。有的客户端应用内置 MCP 多，有的少。

2026 年 7 月重大规范重写

2026-07-28 版本是自发布以来最大规模的重写，核心变更：

变更	说明
无状态核心	协议变无状态，支持水平扩展和多实例部署，解决了生产环境最痛的扩缩容问题
废弃	Roots、Sampling、Logging 三个原语被移出核心规范
MCP Server Cards	通过 `.well-known` URL 暴露服务器元数据，浏览器和注册表可以直接发现能力
Tasks 扩展	Agent 间可靠通信的 call-now / fetch-later 模式，补齐了重试语义和结果过期策略
安全增强	OAuth 2.1、MCP Security Top 10、IETF 安全草案、Gateway 模式标准化

💡 一句话总结：MCP 解决了"每换一个 Agent 框架工具就得重包"和"多 Agent 工具复用/权限/日志"的问题。

MCP 在 2026 年的生产部署架构

用户请求 → API Gateway → MCP Gateway（认证/限流/审计）
                              ↓
                    MCP Client（我们的应用）
                              ↓
                    MCP Server A（天气服务）
                    MCP Server B（订单系统）
                    MCP Server C（知识库）

MCP Gateway 是 2026 年企业部署的新角色：

认证传播：SSO 登录态透传到各 MCP Server
限流：每个 Client 的调用频率控制
审计：记录所有工具调用，满足合规要求
会话管理：无状态协议下的会话恢复

Tool Calling：Agent 的手

Tool Calling 是 LLM 调用外部工具的标准方式。MCP 管的是"怎么连"，Tool Calling 管的是"怎么调"。

注意区分：ReAct 是 prompt 层模拟工具调用（"Action: search(x)" 然后自己解析），Function Calling 是模型侧原生能力（OpenAI 的 tools 字段、Claude 的 tool_use），模型输出结构化 JSON，直接 dispatch。

它怎么工作

场景：Agent 需要查天气 → 模型发现需要调用工具 → 输出结构化调用请求 → 执行工具 → 返回结果。

用户问："北京今天适合跑步吗？"

── Step 1: LLM 分析 ────────────────────────────────────
系统提示词中定义了工具：
  - get_weather(city, date): 查询天气
  - get_air_quality(city): 查询空气质量

LLM 输出（不是文本，是结构化调用）：
  { "tool": "get_weather", "arguments": {"city": "北京", "date": "2026-07-04"} }

── Step 2: 执行工具 ────────────────────────────────────
调用 get_weather("北京", "2026-07-04")
返回：{ temp: 35, humidity: 80, wind: 5 }

── Step 3: 结果回灌 ────────────────────────────────────
把工具结果追加到 context，再次调用 LLM
LLM 基于天气数据生成自然语言回答
→ "北京今天 35°C、湿度 80%，体感闷热，不建议户外跑步"

工程实践

工具描述要精确。"查询天气"太模糊；"查询指定城市、指定日期的温度、湿度、风速"才够模型判断何时调用。描述写得烂 → 模型选错工具，这是 Function Calling 翻车头号原因。

工具数量有上限。一次给模型 20+ 个工具，模型容易选错。2026 年的实践：按需加载工具，根据用户意图动态注册相关工具，而不是一次性全量注册。尤其是子 Agent，可以限定用哪些，而不是默认继承所有工具。

参数校验：永远别直接信任模型输出。Pydantic / JSON Schema 校验 → 过了才 dispatch → 不过让模型重填（带错误信息回去）。

并行调用：如果模型需要同时查天气和空气质量，可以并行发多个工具调用，等所有结果回来再一起回灌。OpenAI 和 Anthropic 的 API 都支持并行 tool_calls。生产里常做 tool call pool + semaphore，防把 API 打爆。

💡 一句话总结：Function Calling 是模型说"我要调啥"的机制，MCP 是工具那边怎么标准化暴露——两者是上下位，不是替代。

无框架趋势：模型越来越强，框架越来越重

2026 年出现了一个明显的反框架趋势。框架带来的成本：编写成本、学习成本、理解成本、排查成本。当模型本身足够强时，先从无框架开始，遇到管理复杂度时再逐步升级。

分层决策：

复杂度	方案	例子
简单	直接调用 API	查天气 → 回答；做简单分析 → 回答并摘要
中等	模型厂商原生 SDK	OpenAI SDK、Anthropic SDK
复杂	专业框架	LangGraph（状态机）、CrewAI（多Agent）
企业级	框架 + 自研	LangGraph + 自研业务层

注意区分"客户端 Agent 应用"和"生产 Agent 框架"：

客户端应用（Claude Code、Cursor、Windsurf）是开箱即用的工具，我们直接用它
生产框架（LangGraph、CrewAI）是编排底座，我们基于它搭建自己的系统

两者解决的问题不同，不要混为一谈。

💡 一句话总结：不要一上来就引入重型框架。能 API 直调就用 API，能 SDK 直写就用 SDK，遇到协作复杂度再上框架。

Context Engineering：精确供给上下文

2026 年 LlamaIndex 提出了 Context Engineering 原则：不是给 Agent 越多上下文越好，而是精确供给。

核心观点：

Context files 成为 agentic 配置的主导机制——通过 .md 文件显式告诉 Agent 项目的结构、规范、当前状态
过量上下文反而降低 Agent 表现——塞满整个代码库，Agent 找不到重点
上下文优化是 Agent 性能的最大杠杆——比调模型、改 prompt 更有效

工程实践：

给 Agent 只给它需要的文件，不默认给全部
用摘要替代全文——"auth 模块有 3 个 API，处理 JWT 和 OAuth2" 比贴整个 auth.py 有效
动态注入——根据 Agent 当前任务阶段，按需加载不同上下文

这和第 05 讲（编排与工作流）的 Loop Engineering 紧密相关：Loop 的 Context Management 组件，核心就是 Context Engineering 的工程化落地。

💡 一句话总结：Prompt Engineering 解决"怎么说"，Context Engineering 解决"给什么"。2026 年，给什么比怎么说更重要。

Agent 记忆与缓存⭐：不只是"记住上次说了什么"

2026 年被不少人称为"AI Agent 记忆之年"。但记忆远不止"短期记忆"和"长期记忆"两个分类那么简单。

为什么需要记忆与缓存？

两个根本原因：

大模型天生无状态——每次对话都是一次独立的推理，多轮交互必须把所有历史塞进上下文窗口
Token 很贵，全量重算很慢——如果每次重复计算相同的 System Prompt、工具定义、历史摘要，既烧钱又拖慢首包延迟

为了解决这两个问题，整个调用链上的参与者——Agent 应用（Claude Code / Codex / OpenClaw）、网关（OpenRouter / Cloudflare）、大模型厂商（Anthropic / 阿里百炼）——都在使用多级缓存。但缓存只是故事的一半。另一半是 Agent 如何管理自己的记忆：该记住什么、该忘掉什么、该从哪里取回。

调用链缓存：调用前就能省钱

调用链缓存决定"塞出去后能不能打折"。两层：

层级	名称	怎么工作	通俗例子
C1	网关响应缓存	把完整请求做哈希，一样的请求直接返回上次结果，不去厂商	我们问两次"今天天气怎么样"，第二次门卫直接告诉我们答案，不用再跑一趟
C2	厂商 Prompt Cache	system prompt、工具定义等不变部分存下来，下次相同前缀直接复用	我们每次点外卖都写"不要香菜不要葱"，老板记住了，后面我们只说"来个炒饭"，老板自动加备注

实际省钱效果：

OpenRouter 重复请求命中缓存，不收费
阿里云显式缓存：创建缓存收 1.25 倍 Token 费用，后续命中缓存的文章 Token 按照1 折收费
Anthropic cache_control：显式断点，最多 4 个，命中后 input 成本大幅降低

Claude Code 这类编码 Agent 不配 C2，账单直接 3-4 倍（实际节省可达 3-8 倍来源）。因为每次请求都带着相同的 CLAUDE.md + 工具定义 + system prompt，这些稳定前缀占大量 token，命中 C2 后 input 成本仅为全价的 10%。

Agent 记忆：该记住什么

缓存解决"怎么省钱"，记忆解决"怎么记住"。四层：

层级	名称	存什么	生命周期	通俗例子
M0	瞬时记忆（工作记忆）	当前这一轮的用户输入、工具返回结果	Turn 级（用完即弃）	便利贴：写上这步要算什么，算完就撕掉
M1	会话记忆（情节记忆）	本次对话的历史摘要或最近 N 轮	Session 级（一次对话到 END）	聊天记录 + 关键摘要：我们跟客服说"我上次投诉过"，客服翻前面的摘要知道我们说的是哪件事
M2	任务记忆（程序记忆）	Skill 定义、流程模板、任务状态	天～周（任务绑定）	菜谱：学会了做红烧肉，步骤写在卡片上，下次直接翻
M3	长期记忆（语义记忆）	用户画像、公司规则、领域知识、历史偏好	月～永久	通讯录：存着朋友的地址、生日、忌口，每次需要时翻

这两条线正交协作：记忆层决定"塞多少"，缓存层决定"塞出去后能不能打折"。

Agent 记忆与缓存协作案例

Claude Code 启动一个 3 人 Agent Team（Lead + 2 个 Teammate）重构一个模块：

C2 缓存：CLAUDE.md + 工具定义 + system prompt 作为稳定前缀（假设 12K token），每个 teammate 独立 context 但前缀相同，全部命中 C2，缓存部分按全价的 10% 计费
M1 会话记忆：每个 teammate Agent 有自己的 session 历史（checkpointer 保存），可随时回溯之前的思考过程
M2 任务记忆：Lead Agent 通过共享 task list 分配任务，Teammate A 完成后标记"done"，Teammate B 自动领取下一个
M3 长期记忆：项目知识库（API 文档、架构决策记录）通过 RAG 按需注入

最终账单：单 Agent 完成该任务需 60K token，Agent Teams 总 token 约 180K，但由于 C2 命中 12K×3=36K（按 10% 计费），实际等效 token 为 147.6K，仅 2.46 倍（而非理论 3 倍）。这就是记忆与缓存协同的价值——"更快更省更好"。

缓存和记忆的工程代价

技术复杂度：构建缓存和记忆涉及上下文压缩、检索策略、过期管理等多个技术点，每个展开都不简单。

缓存和记忆过期：空耗资源，无法处理，成本反而增加，甚至造成误导。又不能每次压缩/修改，边界难确定。

记忆污染：存了错误记忆后 Agent 行为会持续偏离。必须有记忆淘汰和校验机制。

检索准确性（主要是长期记忆）：向量搜索不一定能找到最相关的记忆。2026 年的最佳实践是混合检索——向量相似度 + 关键词匹配 + 时间衰减。

成本：每次对话都做记忆检索，增加延迟。2026 年的趋势是按需检索——只在用户问题涉及历史信息时才查记忆，而不是每次必查。

💡 一句话总结：记忆和缓存不是"要不要"的问题，而是"分几层、每层怎么配"的问题。四层记忆 + 两层缓存是 2026 年的生产标配。

研发过程视角：MCP 就是我们的工具链骨架

我们每天用的 Claude Code，底层就在用 MCP 连接各种工具。

当我们安装一个 MCP Server（比如拓令通 TokSlash 的 Markdown 编辑工具），Claude Code 通过 MCP 协议发现它的能力，然后在对话中自动调用——这就是 MCP 的标准流程。

关键洞察：MCP 不只是"为产品造连接"的协议，它同样是我们自己开发者工具链的底层标准。每次我们在 Claude Code 里装一个新工具，我们都在体验 MCP 协议的"即插即用"能力。

理解 MCP 对架构师的价值：当我们要为团队搭建 AI 工具时，与其写死连接器，不如把工具封装成 MCP Server——Claude Code、Cursor、Windsurf 等所有 MCP Client 都能直接用。

选型决策

架构师决策清单：
工具连接 → 用 MCP 协议封装，一次实现，所有 Client 都能用。
Tool Calling → 工具描述要精确，按需加载，参数校验，不要一次性全量注册。
调用链缓存 → C1 网关缓存 + C2 厂商缓存必配，编码 Agent 不配 C2 账单 3-4 倍。
Agent 记忆 → 四层架构（M0 瞬时 / M1 会话 / M2 任务 / M3 长期），M3 混合检索，按需检索。
框架选择 → 简单任务不用框架，中等用 SDK，复杂上框架。
MCP 生产部署 → 加 MCP Gateway（认证/限流/审计），无状态协议下做会话恢复。
拍板点：先直连 API 跑通 MVP，遇到连接复杂度再引入 MCP；先 SDK 直写跑通流程，遇到协作复杂度再引入框架。

面试回答要点

Q：Agent 的核心支撑技术有哪些？你怎么选型？

答（抓本质 + 讲架构）：

三大支撑技术——

MCP（Model Context Protocol）：Agent 与外部工具/数据源的标准连接协议。2026 年 7 月最大规模重写：无状态、Server Cards、Tasks 扩展、安全增强。已是事实标准。和 Function Calling 是上下位不是替代：FC 是模型说"我要调啥"，MCP 是工具那边怎么标准化暴露。
Tool Calling：LLM 调用外部工具的原生机制。关键是工具描述精确、按需加载、支持并行、参数校验。OpenAI / Anthropic / 百炼 API 都原生支持。
Agent 记忆：四层架构管"存什么、存哪、活多久"——M0 瞬时（工作记忆）/ M1 会话（情节）/ M2 任务（程序，Skill / task list）/ M3 长期（语义，用户画像 / RAG）。M3 召回常用混合检索（向量 + 关键词 + 时间衰减）。

选型思路（按场景加码）：

单会话 Chatbot → Tool Calling + M0/M1 够
个人助手（多 turn）→ 加 M3（Obsidian / Vector Store）
多 Agent 协作 / 跨 session 任务 → 加 M2（Skill / task list）+ MCP（多工具复用）
别忘了调用链缓存（C1 网关 / C2 厂商）——不算 Agent"核心技术"但选型必配，不配 C2 账单 3-4 倍。

深度追问：

"MCP 和直接调 API 有什么区别？" → 直接调 API 是点对点连接；MCP 是标准化接口，一次实现，所有 MCP Client 都能用。类比：USB-C vs 专用充电线。
"Agent 记忆怎么保证准确性？" → 混合检索 + 记忆淘汰 + 校验机制。不能只靠向量相似度，要加时间衰减（旧记忆权重低）和关键词匹配。

小结

MCP 是 Agent 的 USB-C 接口：2026 年 7 月重大重写（无状态、Server Cards、Tasks、安全增强），已事实标准
Tool Calling 是 Agent 的手：精确描述、按需加载、并行调用、参数校验
记忆与缓存是四层记忆 + 两层缓存：M0/M1/M2/M3 记忆 + C1/C2 缓存，2026 年生产标配
无框架趋势：模型越来越强，框架越来越重。按复杂度逐步升级，不要一上来就引入重型框架

思考题

我们的团队要为内部 ERP 系统搭建一个 Agent 助手，需要连接订单查询、库存管理、物流追踪三个系统。我们会直接调 API 还是封装成 MCP Server？为什么？如果未来要让 Claude Code 和 Cursor 都能用这个工具，我们的选择会变吗？
我们设计了一个带记忆的客服 Agent，但用户反馈"Agent 总是记错我上次说的话"。从记忆架构角度，可能的原因有哪些？（提示：检索准确性、记忆污染、上下文窗口截断各是一种可能）我们会怎么逐一排查？

第 06 讲 | Agent 的核心支撑技术：MCP、Tool Calling、记忆与缓存 ​

MCP：Agent 的 USB-C 接口 ​

2026 年 7 月重大规范重写 ​

MCP 在 2026 年的生产部署架构 ​

Tool Calling：Agent 的手 ​

它怎么工作 ​

工程实践 ​

无框架趋势：模型越来越强，框架越来越重 ​

Context Engineering：精确供给上下文 ​

Agent 记忆与缓存⭐：不只是"记住上次说了什么" ​

为什么需要记忆与缓存？ ​

调用链缓存：调用前就能省钱 ​

Agent 记忆：该记住什么 ​

Agent 记忆与缓存协作案例 ​

缓存和记忆的工程代价 ​

研发过程视角：MCP 就是我们的工具链骨架 ​

选型决策 ​

面试回答要点 ​

小结 ​

思考题 ​