本文内容基于 Hello-Agents 开源项目的学习笔记整理，约2000字，预计阅读用时7分钟。

目录

先设定一个场景

第一层：上下文工程

上下文腐蚀

上下文的结构

长任务的上下文管理

第二层：记忆系统与 RAG

Agent 的记忆

RAG 所解决的问题

检索时真正麻烦的问题

第三层：MCP——标准化连接外部世界

没有标准协议时的问题

三层架构

模型怎么决定用哪个工具

三种能力类型

和 Function Calling 的关系

三层协同：回到最初的场景

---

刚开始用 ChatGPT 的时候，很明显能感受到它的局限：每次新开对话就是一张白纸，之前聊过的东西全没了；问它今天发生了什么，给你说的是训练数据截止前的事；让它帮你订机票，它只能告诉你"你可以去 xx 网站订"。现在这些问题陆续被解决了——有的产品加了记忆功能，有的能联网搜索，有的能真的帮你完成操作（比如最近大热的OpenClaw）。但这些能力并非凭空出现，而是背后有一套具体的工程机制在支撑。

大语言模型本身是无状态的，没有记忆，不连网，也没法真的执行操作。那现在那些"能干活"的 AI Agent，是怎么突破这些限制的？

答案其实可以拆成三层：上下文工程、记忆系统与 RAG、MCP 协议。它们各自解决不同的问题，但在一个跑起来的 Agent 里是同时协作的。在这篇文章里我们将用一个具体的任务场景把它们串起来。

---

先设定一个场景

假设有一个 Agent，任务是：读取本周的会议记录文件，结合项目历史背景，生成一份进度摘要，发邮件给团队。

执行这个任务，Agent 面临三个本质上不同的问题：

• 当下：该把什么信息放进模型的上下文窗口？
• 历史：项目背景、上周的结论——这些超出当前窗口的信息，怎么按需取用？
• 行动：读文件、发邮件，这些实际操作怎么执行？

三个问题，分别对应三层机制。

---

第一层：上下文工程

上下文腐蚀

有一个大家在日常使用中可以明显感受到的现象：随着上下文里的内容越堆越多，模型从中提取信息的准确率反而会下降。研究里把这个叫做上下文腐蚀（Context Rot），几乎在所有主流模型上都能观察到。

所以上下文工程的核心不是尽可能多地写入信息，而是在有限的窗口里放尽量高密度、高相关性的信息。

上下文的结构

工程化的上下文通常由三部分构成。

系统提示定义模型的角色和行为规则。两种常见的失败方式：写得太空泛，缺乏细节（"你是一个有帮助的助手"，没有任何具体信号），或者写得太臃肿，加入了太多细枝末节的内容（把所有边界情况全堆进去，需求一变全要改）。比较好的做法是分区组织：

<background>  你是一个项目管理助手，负责软件开发团队的周报整理  </background>
<tools>  你可以使用 read_file 读取文件，send_email 发送邮件  </tools>
<output_format>  返回 Markdown 格式，包含：本周进展、阻塞项、下周计划  </output_format>

工具定义告诉模型有哪些工具可用。工具集不是越大越好——如果两个工具的功能边界不清晰，模型选工具时就会出问题。维护一个精简的、每个工具职责单一的集合，稳定性往往更好。

少样本示例（Few-shot） 直接给几个输入输出的对照例子，比长篇指令更直接有效。挑典型的、有代表性的，不需要穷举所有情况。

长任务的上下文管理

单次任务相对来的比较易于处理，但如果 Agent 要执行一个持续很长时间的任务，上下文窗口迟早会满，这时候我们主要有三种应对方式：

压缩整合（Compaction）：接近上限时对历史进行总结，保留关键决策和未解决的问题，用摘要重启一个新窗口，继续执行。

结构化笔记：Agent 把关键信息主动写进外部文件，需要时再读取。这不是记忆系统，是对外部状态的主动管理。Hello-Agents 里有一个 NoteTool，就是做这个的，用 Markdown + YAML 存状态，支持 Git 版本控制，人也可以直接读和编辑。

子代理架构：主 Agent 负责规划，把子任务分给多个子 Agent，每个子 Agent 在干净的上下文窗口里独立工作，最后只把摘要返回主 Agent。这样复杂的上下文留在子 Agent 那边，主 Agent 的窗口保持干净。

---

第二层：记忆系统与 RAG

Agent 的记忆

记忆系统要解决的问题是：哪些信息应该保留，保留多久，什么时候取出来用。

按时间维度可以分三类。短期记忆就是当前对话的上下文，直接存在模型的上下文窗口里，保证对话连贯。工作记忆是任务执行过程中的临时缓冲，比如推理的中间步骤，任务结束后清空或选择性归档。长期记忆跨越不同会话持久存储，用向量数据库实现——把历史信息转成向量，需要时通过相似度检索取回来。

核心操作流程是四步：写入、存储、检索、反思。写入是把交互内容存进去；存储阶段会做压缩，要么总结成摘要，要么转成 Embedding 存入数据库；检索是新请求来了从记忆库里找最相关的片段注入上下文；反思是 Agent 审视过去的经验，从中提炼规律，这也是 Agent 能持续"成长"的关键。

RAG 所解决的问题

记忆系统管的是 Agent 从与用户交互中积累的信息。但还有另一类知识——公司文档、技术手册、最新资讯——这些不来自交互过程，而是外部知识库。这是 RAG（检索增强生成）要解决的问题。

核心思路是：知识不需要内嵌在模型里，用的时候再查就行。文档切片 → 向量化 → 存入向量数据库，查询时检索相关片段，注入 Prompt，模型基于原文生成答案。这样知识库可以随时更新，也不依赖模型的训练数据截止时间。

检索时真正麻烦的问题

用户的提问和文档里的表述，往往不在同一个语义空间。比如用户问"怎么修 Python 内存泄漏"，文档里写的是"tracemalloc 可定位泄漏位置"，直接向量匹配很难命中。

两种进阶策略：

多查询扩展（MQE）：对同一个问题自动生成多种不同表述，并行检索，合并结果。用词多样性导致的漏检问题，基本上靠这个解决。

假设文档嵌入（HyDE）：让模型先生成一个假设性的答案，再用这个假设答案去检索真实文档：

用户问题："如何修复 Python 中的内存泄漏？"
         ↓ LLM 生成假设回答
"通常需要先使用 tracemalloc 或 memory_profiler 定位泄漏位置，
 然后检查循环引用..."
         ↓ 用假设回答做向量检索
命中：《Python 内存管理最佳实践》《Python 性能调优指南》

假设答案和真实文档都是陈述性表达，语义距离比原始问句更近。内容不需要完全正确，只要领域术语和表述风格接近，检索精度就会有明显提升。

---

第三层：MCP——标准化连接外部世界

没有标准协议时的问题

前两层处理的都是"思考"的问题。现在 Agent 要真正行动了——读文件、发邮件、查数据库。

如果为每个服务单独写适配器，接入 GitHub 一套代码，接入 Slack 一套，接入数据库又一套，某个 API 改了接口就要到处改。随着接入服务增多，维护成本会越来越高。

MCP（Model Context Protocol）定义了一套 Agent 与外部工具通信的标准协议，让不同的工具和不同的 Agent 框架都能通过同一套接口交互。

三层架构

用户 ↔ Host（Claude Desktop / 你的 Agent 应用）
         ↕ MCP Client（内嵌在 Host 中）
         ↕ MCP Server（文件系统 / GitHub / 数据库 / 邮件...）

Host 是用户交互的界面，管理对话流程；Client 是协议层，负责连接 Server、发请求、收响应；Server 是实际执行功能的服务。

这个设计的关键是：开发者只需要写 Server，不用关心 Host 和 Client 的实现。用户不管用哪个支持 MCP 的客户端，都能用同一套工具。

模型怎么决定用哪个工具

MCP Client 连上 Server 后，先调用 list_tools() 拿到所有工具的名称、描述和参数定义，然后把这个列表转成模型能读懂的格式，注入系统提示。模型根据用户问题和工具描述，自己决定要不要调用工具、调哪个。

所以工具的描述质量直接影响它能不能被正确调用。一个描述含糊的工具，和没有工具差不多。

三种能力类型

能力	特点	例子
Tools	主动执行，有副作用	发邮件、写文件、调用 API
Resources	只读，被动提供数据	读文件内容、查询数据库
Prompts	提供标准化指令片段	代码审查模板、报告格式

和 Function Calling 的关系

这两个概念经常被混淆，Function Calling 是模型层的能力，解决的是"模型什么时候、怎么生成工具调用参数"；MCP 是工程层的协议，解决的是"工具和模型怎么标准化连接"。两者不冲突，在同一个系统里协同工作。

---

三层协同：回到最初的场景

把三层放在一起，"整理会议记录发邮件"这个任务的信息流大概是这样的：

用户输入
    ↓
[上下文工程]
系统提示 + 工具定义 + 压缩后的历史摘要
    ↓
[记忆 & RAG]  ← 运行时动态注入
情景记忆（上周的讨论结论）
语义记忆（用户偏好、项目规则）
RAG 检索（相关文档片段）
    ↓
模型推理 → 决定调用工具
    ↓
[MCP]
通过 MCP Server 执行实际操作（读文件 / 发邮件）
    ↓
结果注入上下文 → 模型生成最终输出

上下文工程管的是"当下这一刻模型能看到什么"，记忆与 RAG 负责"历史信息和外部知识按需可达"，MCP 负责"实际执行操作"。三层缺一不可，也正是这三层组合在一起，让 Agent 从"能对话"变成了"能干活"。

---

本文内容基于 Hello-Agents 开源项目的学习笔记整理。