从 Manus 出圈，再到小龙虾爆火，Agent 的各种东西扑面而来。
各种新名词层出不穷：Context、Memory、Function Calling、MCP、Skill、RAG、Subagent......
这篇文章，就让我们从头到尾进行一次盘点，整理一下这些 "新名词"。
虽然名字多，但其实都在讲一件事：让大模型不只会聊天，还能围绕目标把事情做完。
1. 什么是 Agent
我们都知道大模型，它是这样工作的：你问一句，它答一句。
而 Agent 是这样：理解目标 -> 拆步骤 -> 调工具 -> 看结果 -> 继续下一步步骤的任务知道完成目标。
如果把大模型比作会思考、会表达的大脑。
Agent 是给这个大脑配上手脚、工具箱，以及一套能持续推进的工作流程。
2. 什么是 Context
在大模型还没现在这么强大之前，我们常常遇到这样的情况：跟AI对话到一半，AI 突然答非所问。
原因很简单，上下文有长度上限，可以把它想成一根管道：一边进，一边出。
随着历史消息的增加，旧内容会被挤出去，被挤出去的那部分，模型自然就不记得，但随着大模型的发展，现在模型的上下文越来越大了，这种情况也随之减少。
但在处理大型工程的时候，有时候上下文还是捉襟见肘，所以做好上下文管理，还是很有必要的。
3. 什么是 Memory
Context 和 Memory 经常被混为一谈，其实差很多。
具体差别：
- Context：模型此刻能看到的输入窗口
- Memory：为了跨时间、跨会话保持连贯，系统另外做的一整套机制
必须明确一点，大模型本身是无状态的，所谓记忆，都是外面存了东西，下次再组装成 Context 提交给大模型。
如下图：
4. 什么是 Function Calling
很多问题大模型没办法直接给出答案，而需要依托于外部写的工具，这时候就需要Function Calling。
比如用户说：帮我查一下上海明天的天气。
这个问题大模型是没办法直接回答的，但有了 Function Call, 就可以在请求里告诉模型：你有这些工具可用，例如 get_weather(city, date)。
大模型觉得自己回答不了，但有工具可以调用，就返回需要调用的工具和参数，如下 ：
json
{
"name": "get_weather",
"arguments": {
"city": "上海",
"date": "2026-03-09"
}
}Agent 拿到后去执行工具，然后把结果塞回对话，模型最后组织成自然语言进行回答。
如下：
5. 什么是 MCP
MCP 的作用很像 Function Call, 但它并不是一个功能，而是一个协议。
它约定了 AI 应用怎么发现外部能力、外部系统怎么暴露工具和资源、双方怎么用统一方式通信。
可以看一个具体案例交互案例：
6. 什么是 Skill
把一类重复任务的做法，提前写成可复用的说明文档，包括步骤、规则、边界、可调用的工具，输出要求等内容，让 Agent 根据需要选择对应的文档并按照文档的说明进行操作。
这就是 SKill, Agent 工作的 SOP 文档，有了 Skill 之后，Agent 就可以先读取对应文档，然后按预设流程推进。
7. 什么是 RAG
RAG，全称是 Retrieval-Augmented Generation，它在 Agent 中发挥的作用核心就一句话：先检索知识库，再把问题跟检索到的知识内容，一起发给大模型。
工作上分两大阶段：
建立知识库：收集资料 -> 清洗 -> 切块 -> 向量化 -> 建索引，做成能按语义检索的仓库。
接入知识库进行问答：问题也向量化 -> 检出最相关的几段 -> 和问题一起交给模型 -> 基于材料回答。
它不直接修改改模型本身，但能让回答变得有据可依，在企业内部文档问答、客服知识库这类场景特别常见。
8. 什么是 Subagent
在工作中，遇到复杂的问题，我们会进行拆解，把问题拆成一个个子问题进行解决。
Subagent 也是这个思路，单个 Agent 处理复杂的任务时，上下文容易又长又杂，带来的直观感受就是模型降智了。
有了 Subagent 之后，主 Agent 就可以把大任务拆成更小、更聚焦的子任务，交给 Subagent。
这样，每个子任务就可以在干净的上下文里干活，很多场景下不同的子任务可以同时进行，这也加速了 Agent 的干活效率。
总结
虽然名词很多，但我们从中也可以回顾到整个 Agent 的发展历程。
每一个新名词的出现，都是为了解决 Agent 在某个阶段所遇到的问题。
也是如此，才造就了我们现在如此强大的 Agent。