一口氣徹底講清楚 Agent、RAG、Skill、MCP到底是什么
導(dǎo)讀:這篇文章不搞概念堆砌,而是從一個(gè)后端工程師的視角,把 Agent、RAG、Skill、MCP 這四個(gè)高頻詞拆開、講透。讀完之后,你會明白它們各自解決什么問題、技術(shù)原理是什么、彼此之間是什么關(guān)系,以及在實(shí)際工程中該如何選型和組合。
一、先搞清楚一件事:為什么會有這些概念?
大語言模型(LLM)本身是一個(gè)"有知識但沒手腳"的東西。你給它一段 Prompt,它返回一段文本——僅此而已。
但真實(shí)的業(yè)務(wù)場景遠(yuǎn)比"一問一答"復(fù)雜得多:
- 你希望 AI 能自主完成多步驟任務(wù),比如"幫我查一下線上報(bào)錯(cuò),定位到代碼,然后提交修復(fù)" → 這就需要 Agent
- 你希望 AI 的回答能基于你的私有數(shù)據(jù),而不是胡編亂造 → 這就需要 RAG
- 你希望 AI 具備特定領(lǐng)域的標(biāo)準(zhǔn)化能力,可以復(fù)用、可以分享 → 這就需要 Skill
- 你希望 AI 能調(diào)用外部工具和服務(wù),并且有一個(gè)統(tǒng)一的協(xié)議標(biāo)準(zhǔn) → 這就需要 MCP
這四個(gè)概念不是互相替代的關(guān)系,而是互補(bǔ)的,分別解決 AI 工程化落地中的不同層面的問題。

圖1 展示了四個(gè)概念在 AI 應(yīng)用技術(shù)棧中的定位。Agent 是最上層的"執(zhí)行者",RAG 為其提供知識支撐,Skill 是可復(fù)用的能力單元,MCP 是連接外部世界的標(biāo)準(zhǔn)協(xié)議。
二、Agent:讓 AI 從"應(yīng)答機(jī)器"變成"自主員工"
2.1 一句話定義
Agent = LLM + 規(guī)劃能力 + 記憶 + 工具調(diào)用。它不只是回答問題,而是能理解目標(biāo)、拆解任務(wù)、調(diào)用工具、根據(jù)反饋調(diào)整行動(dòng),直到任務(wù)完成。
2.2 跟普通 LLM 調(diào)用有什么區(qū)別?
先看一個(gè)對比:
| 維度 | 普通 LLM 調(diào)用 | Agent |
|---|---|---|
| 交互模式 | 單輪問答,你問我答 | 多輪自主執(zhí)行,目標(biāo)驅(qū)動(dòng) |
| 任務(wù)拆解 | 不具備,需要人工拆解 | 自動(dòng)將復(fù)雜任務(wù)分解為子任務(wù) |
| 工具使用 | 不支持(純文本生成) | 可調(diào)用搜索引擎、數(shù)據(jù)庫、API 等 |
| 記憶能力 | 僅限當(dāng)前上下文窗口 | 具備短期記憶和長期記憶 |
| 錯(cuò)誤處理 | 無法自我糾正 | 能根據(jù)執(zhí)行結(jié)果調(diào)整策略 |
| 執(zhí)行模式 | 同步、一次性 | 異步、持續(xù)循環(huán)直到完成 |
舉個(gè)實(shí)際的例子:你對一個(gè)普通的 ChatBot 說"幫我排查線上 OOM 問題",它只能給你一些通用的排查思路。但如果是一個(gè) Agent,它可能會:
- 調(diào)用日志服務(wù)查詢最近的 OOM 堆棧
- 分析堆棧信息定位到具體的代碼路徑
- 讀取對應(yīng)的源碼文件
- 查詢該服務(wù)最近的代碼變更記錄
- 結(jié)合以上信息給出根因分析和修復(fù)建議
整個(gè)過程中,每一步的輸出會作為下一步的輸入,Agent 自己決定下一步做什么。
2.3 Agent 的核心架構(gòu)
一個(gè)完整的 Agent 通常包含四個(gè)核心模塊:

圖2 展示了 Agent 的四大核心模塊。LLM 作為"大腦"負(fù)責(zé)推理和決策;規(guī)劃模塊負(fù)責(zé)任務(wù)拆解和執(zhí)行策略;記憶模塊提供上下文管理;工具模塊提供與外部世界交互的能力。
(1)LLM 大腦(Reasoning & Decision)
Agent 的核心是一個(gè)大語言模型,負(fù)責(zé):
- 理解用戶意圖
- 推理和決策
- 生成工具調(diào)用指令
- 分析工具返回的結(jié)果
(2)規(guī)劃模塊(Planning)
負(fù)責(zé)將復(fù)雜任務(wù)拆解為可執(zhí)行的步驟序列。常見的規(guī)劃策略有兩種:
ReAct(Reasoning + Acting)模式:交替進(jìn)行"思考"和"行動(dòng)",每一步都基于前一步的結(jié)果來決定下一步。
Thought: 用戶想排查 OOM 問題,我需要先查看日志 Action: 調(diào)用 SLS 日志查詢工具,搜索最近 1 小時(shí)的 OOM 日志 Observation: 找到 3 條 OOM 記錄,堆棧指向 UserService.batchQuery() Thought: 定位到了具體方法,我需要看看這個(gè)方法的代碼 Action: 讀取 UserService.java 文件 Observation: batchQuery() 方法中有一個(gè)未分頁的全量查詢 Thought: 找到根因了——全量查詢導(dǎo)致內(nèi)存溢出 Action: 輸出分析報(bào)告和修復(fù)建議
Plan-and-Execute 模式:先制定完整計(jì)劃,然后按計(jì)劃逐步執(zhí)行。適合任務(wù)步驟比較確定的場景。
Plan: Step 1: 查詢 OOM 日志 Step 2: 分析堆棧定位代碼 Step 3: 讀取相關(guān)源碼 Step 4: 查詢最近代碼變更 Step 5: 生成分析報(bào)告 Execute: [按計(jì)劃逐步執(zhí)行,每步完成后檢查是否需要調(diào)整計(jì)劃]
(3)記憶模塊(Memory)
Agent 需要記住"自己干過什么"和"知道些什么":
- 短期記憶(Working Memory):當(dāng)前對話的上下文,包括用戶輸入、中間推理過程、工具調(diào)用結(jié)果。受限于 LLM 的上下文窗口長度。
- 長期記憶(Long-term Memory):跨會話持久化的信息,通常存儲在向量數(shù)據(jù)庫中。比如用戶的偏好、歷史交互中學(xué)到的經(jīng)驗(yàn)。
(4)工具模塊(Tools)
Agent 的"手和腳"。通過工具,Agent 可以:
- 搜索互聯(lián)網(wǎng)
- 查詢數(shù)據(jù)庫
- 調(diào)用 REST API
- 讀寫文件
- 執(zhí)行代碼
工具的定義通常包含名稱、描述、參數(shù) Schema。LLM 根據(jù)工具描述來決定何時(shí)調(diào)用哪個(gè)工具。
2.4 用代碼感受一下
以下是一個(gè)簡化的 Agent 循環(huán),用 Python 偽代碼展示核心邏輯:
class Agent:
def __init__(self, llm, tools, memory):
self.llm = llm
self.tools = tools # 可用工具列表
self.memory = memory # 記憶模塊
def run(self, user_task: str) -> str:
"""Agent 的核心執(zhí)行循環(huán)"""
self.memory.add("user", user_task)
max_iterations = 10 # 防止無限循環(huán)
for i in range(max_iterations):
# 1. LLM 根據(jù)當(dāng)前上下文進(jìn)行推理
response = self.llm.chat(
messages=self.memory.get_messages(),
tools=self.tools.get_schemas() # 告訴 LLM 有哪些工具可用
)
# 2. 如果 LLM 決定調(diào)用工具
if response.has_tool_call():
tool_name = response.tool_call.name
tool_args = response.tool_call.arguments
# 3. 執(zhí)行工具調(diào)用
result = self.tools.execute(tool_name, tool_args)
# 4. 將工具結(jié)果加入記憶,供下一輪推理使用
self.memory.add("tool_result", result)
continue
# 5. 如果 LLM 認(rèn)為任務(wù)已完成,直接返回結(jié)果
if response.is_final_answer():
return response.content
return "達(dá)到最大執(zhí)行次數(shù),任務(wù)未能完成"
這段代碼揭示了 Agent 的本質(zhì):一個(gè)由 LLM 驅(qū)動(dòng)的循環(huán)。每一輪循環(huán)中,LLM 根據(jù)當(dāng)前的上下文(記憶)決定下一步行動(dòng)——要么調(diào)用工具獲取更多信息,要么給出最終答案。
2.5 Agent 的技術(shù)挑戰(zhàn)
Agent 聽起來很美好,但工程落地時(shí)有幾個(gè)繞不開的挑戰(zhàn):
可靠性問題:LLM 的輸出具有隨機(jī)性,Agent 可能走錯(cuò)路、調(diào)錯(cuò)工具、陷入死循環(huán)。生產(chǎn)環(huán)境中需要加入超時(shí)控制、異常兜底、人工審批等機(jī)制。
成本控制:Agent 的每一步推理都是一次 LLM 調(diào)用,復(fù)雜任務(wù)可能需要 10-20 次調(diào)用,Token 消耗和延遲都需要關(guān)注。
工具設(shè)計(jì):工具的描述直接影響 LLM 能否正確選擇和使用工具。描述寫得不好,Agent 的表現(xiàn)會大打折扣。
安全邊界:Agent 能執(zhí)行操作意味著它也能"搞破壞"。權(quán)限控制、操作審計(jì)、沙箱隔離都是必須考慮的。
三、RAG:讓 AI 說的每句話都有據(jù)可查
3.1 一句話定義
RAG(Retrieval-Augmented Generation)= 檢索增強(qiáng)生成。核心思路是:先從知識庫中檢索相關(guān)文檔,再把檢索到的內(nèi)容作為上下文喂給 LLM,讓它基于這些"證據(jù)"來生成回答。
3.2 為什么需要 RAG?
LLM 有三個(gè)固有的局限性,RAG 正好可以彌補(bǔ):
| LLM 的局限 | 具體表現(xiàn) | RAG 如何解決 |
|---|---|---|
| 知識截止 | 訓(xùn)練數(shù)據(jù)有時(shí)間截止點(diǎn),不知道最新信息 | 從實(shí)時(shí)更新的知識庫中檢索最新內(nèi)容 |
| 幻覺問題 | 會一本正經(jīng)地編造不存在的事實(shí) | 基于檢索到的真實(shí)文檔生成,可溯源 |
| 缺乏私有知識 | 不了解你的公司文檔、代碼庫、業(yè)務(wù)數(shù)據(jù) | 將私有數(shù)據(jù)索引到知識庫中 |
一個(gè)直觀的例子:你問 LLM"我們公司的請假審批流程是什么?",LLM 只能瞎編。但如果用 RAG,系統(tǒng)會先從公司的規(guī)章制度文檔中檢索相關(guān)段落,然后 LLM 基于這些段落來回答——回答既準(zhǔn)確又可以標(biāo)注出處。
3.3 RAG 的完整工作流程
RAG 分為兩個(gè)階段:離線索引和在線檢索生成。

圖3 展示了 RAG 的完整工作流程。左側(cè)是離線索引階段,負(fù)責(zé)將文檔處理并存入向量數(shù)據(jù)庫;右側(cè)是在線檢索生成階段,負(fù)責(zé)根據(jù)用戶查詢檢索相關(guān)文檔并生成回答。
階段一:離線索引(Indexing)
這個(gè)階段的目標(biāo)是把原始文檔轉(zhuǎn)換成可高效檢索的格式,存入向量數(shù)據(jù)庫。
Step 1:文檔加載(Loading)
從各種數(shù)據(jù)源加載原始文檔:PDF、Word、Markdown、HTML、數(shù)據(jù)庫記錄、API 返回等。
Step 2:文檔切分(Chunking)
原始文檔通常很長,需要切分成適當(dāng)大小的片段(Chunk)。這是 RAG 效果的關(guān)鍵環(huán)節(jié)之一。
# 常見的切分策略
class ChunkingStrategy:
"""文檔切分策略"""
@staticmethod
def fixed_size(text: str, chunk_size=512, overlap=50) -> list:
"""固定大小切分 —— 簡單但可能切斷語義"""
chunks = []
for i in range(0, len(text), chunk_size - overlap):
chunks.append(text[i:i + chunk_size])
return chunks
@staticmethod
def semantic_split(text: str) -> list:
"""語義切分 —— 按段落、章節(jié)等自然邊界切分"""
# 優(yōu)先按標(biāo)題、段落切分,保持語義完整性
sections = split_by_headers(text)
chunks = []
for section in sections:
if len(section) > MAX_CHUNK_SIZE:
# 超長段落再按句子切分
chunks.extend(split_by_sentences(section))
else:
chunks.append(section)
return chunks
切分時(shí)的幾個(gè)關(guān)鍵參數(shù):
- chunk_size:每個(gè)塊的大小。太大會引入噪聲,太小會丟失上下文。通常 256-1024 Token 之間。
- overlap:相鄰塊的重疊部分。確保切分邊界處的信息不會丟失。通常 50-200 Token。
- 切分策略:按固定大小、按語義(段落/句子)、按文檔結(jié)構(gòu)(標(biāo)題/章節(jié))。實(shí)踐中語義切分效果更好。
Step 3:向量化(Embedding)
使用 Embedding 模型將每個(gè)文本塊轉(zhuǎn)換為高維向量。語義相近的文本在向量空間中距離也相近。
from openai import OpenAI
client = OpenAI()
def embed_chunks(chunks: list[str]) -> list[list[float]]:
"""將文本塊批量轉(zhuǎn)換為向量"""
response = client.embeddings.create(
model="text-embedding-3-small", # OpenAI 的 Embedding 模型
input=chunks
)
# 返回每個(gè) chunk 對應(yīng)的向量(1536 維)
return [item.embedding for item in response.data]
常用的 Embedding 模型對比:
| 模型 | 維度 | 特點(diǎn) |
|---|---|---|
| OpenAI text-embedding-3-small | 1536 | 性價(jià)比高,英文效果好 |
| OpenAI text-embedding-3-large | 3072 | 精度更高,成本也更高 |
| BGE-large-zh | 1024 | 中文效果好,可本地部署 |
| M3E-base | 768 | 輕量級,適合中文場景 |
Step 4:存入向量數(shù)據(jù)庫
將向量和原始文本一起存入向量數(shù)據(jù)庫,建立索引。
import chromadb
# 初始化向量數(shù)據(jù)庫(以 ChromaDB 為例)
client = chromadb.Client()
collection = client.create_collection("company_docs")
# 存入文檔塊及其向量
collection.add(
ids=[f"chunk_{i}" for i in range(len(chunks))],
documents=chunks, # 原始文本
embeddings=embed_chunks(chunks), # 向量
metadatas=[{ # 元數(shù)據(jù)(用于過濾)
"source": "employee_handbook.pdf",
"chapter": "leave_policy",
"updated_at": "2025-03-01"
} for _ in chunks]
)
階段二:在線檢索生成(Retrieval & Generation)
用戶提問時(shí),實(shí)時(shí)檢索相關(guān)文檔并生成回答。
Step 1:查詢向量化
將用戶的查詢文本也轉(zhuǎn)換為向量。
Step 2:向量檢索(Retrieval)
在向量數(shù)據(jù)庫中找到與查詢向量最相似的 Top-K 個(gè)文檔塊。
def retrieve(query: str, top_k=5) -> list[str]:
"""檢索與查詢最相關(guān)的文檔塊"""
query_embedding = embed_chunks([query])[0]
results = collection.query(
query_embeddings=[query_embedding],
n_results=top_k,
where={"updated_at": {"$gte": "2025-01-01"}} # 可選:元數(shù)據(jù)過濾
)
return results["documents"][0]
Step 3:構(gòu)造增強(qiáng) Prompt
將檢索到的文檔塊拼接到 Prompt 中,作為 LLM 的參考資料。
def generate_answer(query: str, retrieved_docs: list[str]) -> str:
"""基于檢索結(jié)果生成回答"""
context = "\n\n---\n\n".join(retrieved_docs)
prompt = f"""基于以下參考資料回答用戶的問題。
如果參考資料中沒有相關(guān)信息,請明確說明"根據(jù)現(xiàn)有資料無法回答"。
請?jiān)诨卮鹬袠?biāo)注信息來源。
## 參考資料
{context}
## 用戶問題
{query}
## 回答"""
response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": prompt}]
)
return response.choices[0].message.content
Step 4:返回帶來源的回答
回答中附帶引用的文檔來源,方便用戶驗(yàn)證。
3.4 RAG 進(jìn)階:不只是"檢索 + 生成"
基礎(chǔ)版 RAG 的效果往往不夠理想,實(shí)際工程中需要多種優(yōu)化手段:
(1)查詢改寫(Query Rewriting)
用戶的原始查詢可能表述模糊,直接拿去檢索效果不好??梢杂?LLM 先改寫查詢:
def rewrite_query(original_query: str) -> list[str]:
"""將原始查詢改寫為多個(gè)更精確的檢索查詢"""
prompt = f"""請將以下查詢改寫為 3 個(gè)更具體的搜索查詢,以提高檢索效果:
原始查詢:{original_query}
改寫后的查詢(每行一個(gè)):"""
# 例如 "請假怎么操作" 會被改寫為:
# 1. "員工請假審批流程步驟"
# 2. "年假事假病假申請方式"
# 3. "OA系統(tǒng)請假操作指南"
...
(2)混合檢索(Hybrid Search)
單純的向量檢索在精確匹配(如搜錯(cuò)誤碼、方法名)時(shí)效果不佳。混合檢索結(jié)合了向量檢索和關(guān)鍵詞檢索:
def hybrid_search(query: str, top_k=5) -> list[str]:
"""混合檢索:向量相似度 + BM25 關(guān)鍵詞匹配"""
# 向量檢索結(jié)果
vector_results = vector_search(query, top_k=top_k)
# 關(guān)鍵詞檢索結(jié)果(BM25 算法)
keyword_results = bm25_search(query, top_k=top_k)
# 用 RRF(Reciprocal Rank Fusion)融合兩路結(jié)果
merged = reciprocal_rank_fusion(vector_results, keyword_results)
return merged[:top_k]
(3)重排序(Reranking)
檢索出的文檔不一定都相關(guān)。使用 Cross-Encoder 模型對檢索結(jié)果重新排序,過濾掉噪聲文檔:
from sentence_transformers import CrossEncoder
reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")
def rerank(query: str, documents: list[str], top_k=3) -> list[str]:
"""使用 Cross-Encoder 對檢索結(jié)果重排序"""
pairs = [(query, doc) for doc in documents]
scores = reranker.predict(pairs)
# 按相關(guān)性分?jǐn)?shù)排序,只保留 top_k
ranked = sorted(zip(documents, scores), key=lambda x: x[1], reverse=True)
return [doc for doc, score in ranked[:top_k] if score > 0.5] # 過濾低分文檔
3.5 RAG vs. 微調(diào):什么時(shí)候該用哪個(gè)?
這是一個(gè)高頻問題,簡單總結(jié):
| 維度 | RAG | 微調(diào)(Fine-tuning) |
|---|---|---|
| 知識更新 | 實(shí)時(shí)更新,修改文檔即可 | 需要重新訓(xùn)練模型 |
| 實(shí)現(xiàn)成本 | 較低,不需要 GPU | 較高,需要訓(xùn)練資源 |
| 幻覺控制 | 好,回答可溯源 | 較差,可能過擬合 |
| 適用場景 | 知識密集型問答、文檔檢索 | 風(fēng)格適配、特定任務(wù)格式 |
| 數(shù)據(jù)量要求 | 無明確下限 | 通常需要千級以上樣本 |
| 響應(yīng)延遲 | 多一步檢索,略慢 | 與基礎(chǔ)模型相同 |
一句話建議:如果你的需求是"讓 AI 知道更多東西",用 RAG;如果你的需求是"讓 AI 用特定方式說話或做事",用微調(diào);如果兩者都需要,可以 RAG + 微調(diào)一起上。
四、Skill:給 AI 裝上"可插拔的專業(yè)技能"
4.1 一句話定義
Skill = 預(yù)定義的、可復(fù)用的 AI 能力單元。它封裝了特定任務(wù)的 Prompt 模板、工具組合、執(zhí)行流程,使 AI 在某個(gè)領(lǐng)域的表現(xiàn)從"泛泛而談"變成"專業(yè)精準(zhǔn)"。
4.2 為什么需要 Skill?
直接跟 LLM 對話完成任務(wù)有一個(gè)很大的問題:不穩(wěn)定。
同一個(gè)任務(wù),不同的 Prompt 寫法、不同的對話上下文、甚至不同的時(shí)間點(diǎn),LLM 給出的結(jié)果質(zhì)量都可能差異很大。在生產(chǎn)環(huán)境中,這種不確定性是不可接受的。
Skill 的價(jià)值在于將最佳實(shí)踐固化下來:
- 精心調(diào)試過的 Prompt 模板 → 保證輸出質(zhì)量和格式的穩(wěn)定性
- 預(yù)綁定的工具集合 → 確保 AI 用對工具
- 明確的輸入輸出規(guī)范 → 像調(diào)用 API 一樣可預(yù)期
- 可獨(dú)立測試和迭代 → 不影響其他能力
用一個(gè)類比來理解:如果 Agent 是一個(gè)"全能員工",那 Skill 就是這個(gè)員工掌握的"標(biāo)準(zhǔn)作業(yè)流程(SOP)"。員工再聰明,沒有 SOP 也容易出錯(cuò);有了 SOP,新手也能高效執(zhí)行。
4.3 Skill 的結(jié)構(gòu)解剖
一個(gè)典型的 Skill 由以下部分組成:
# 一個(gè) Skill 的結(jié)構(gòu)描述(以代碼審查 Skill 為例)
name: "code-review"
description: "對代碼變更進(jìn)行安全性、性能、可維護(hù)性審查"
version: "1.2.0"
# 觸發(fā)條件:什么時(shí)候激活這個(gè) Skill
triggers:
- "review this code"
- "代碼審查"
- "幫我 review"
# 輸入?yún)?shù)定義
inputs:
- name: "code_diff"
type: "string"
required: true
description: "需要審查的代碼變更(diff 格式)"
- name: "language"
type: "string"
required: false
default: "auto-detect"
- name: "focus_areas"
type: "list"
required: false
default: ["security", "performance", "maintainability"]
# Prompt 模板(核心)
prompt_template: |
你是一位資深的 {{language}} 代碼審查專家。
請對以下代碼變更進(jìn)行審查,重點(diǎn)關(guān)注:{{focus_areas}}
## 審查標(biāo)準(zhǔn)
1. 安全性:是否存在注入、XSS、敏感信息泄露等風(fēng)險(xiǎn)
2. 性能:是否有 N+1 查詢、內(nèi)存泄漏、不必要的循環(huán)
3. 可維護(hù)性:命名是否清晰、是否符合項(xiàng)目規(guī)范
## 代碼變更
{{code_diff}}
## 輸出格式
按嚴(yán)重程度(Critical/Warning/Info)分類列出問題,
每個(gè)問題給出具體的行號、問題描述和修復(fù)建議。
# 綁定的工具
tools:
- "file_reader" # 讀取完整文件上下文
- "git_log" # 查看變更歷史
- "grep" # 搜索相關(guān)代碼
# 輸出格式定義
output_format:
type: "structured"
schema:
issues: list[{severity, line, description, suggestion}]
summary: string
approval: boolean
4.4 Skill 與 Plugin / Function Calling 的區(qū)別
這三個(gè)概念經(jīng)常被混淆,澄清一下:
| 維度 | Skill | Plugin | Function Calling |
|---|---|---|---|
| 粒度 | 完整的任務(wù)流程 | 單個(gè)工具或服務(wù)的封裝 | 單次函數(shù)調(diào)用 |
| 包含內(nèi)容 | Prompt + 工具 + 流程 + 約束 | 工具定義 + API 接口 | 函數(shù)簽名 + 參數(shù) |
| 智能程度 | 高,內(nèi)置領(lǐng)域知識和最佳實(shí)踐 | 低,只是工具的殼 | 無,只是調(diào)用機(jī)制 |
| 類比 | 一套完整的 SOP | 一把螺絲刀 | 擰螺絲這個(gè)動(dòng)作 |
換句話說:Function Calling 是最底層的調(diào)用機(jī)制,Plugin 是對工具的封裝,Skill 是在 Plugin 之上加入了領(lǐng)域知識和執(zhí)行策略的完整能力單元。
4.5 Skill 在 Agent 中的應(yīng)用
在 Agent 架構(gòu)中,Skill 通常作為 Agent 的"能力模塊"被組裝進(jìn)來:
class SkillBasedAgent:
"""基于 Skill 的 Agent"""
def __init__(self, llm):
self.llm = llm
self.skills = {} # 已注冊的 Skills
def register_skill(self, skill: Skill):
"""注冊一個(gè) Skill"""
self.skills[skill.name] = skill
def run(self, user_input: str) -> str:
# 1. 意圖識別:判斷應(yīng)該使用哪個(gè) Skill
matched_skill = self.match_skill(user_input)
if matched_skill:
# 2. 提取 Skill 所需的參數(shù)
params = matched_skill.extract_params(user_input)
# 3. 使用 Skill 的專業(yè) Prompt 和工具來執(zhí)行
return matched_skill.execute(self.llm, params)
else:
# 4. 沒有匹配的 Skill,走通用對話
return self.llm.chat(user_input)
def match_skill(self, user_input: str) -> Skill | None:
"""匹配最適合的 Skill"""
for skill in self.skills.values():
if skill.can_handle(user_input):
return skill
return None
這種模式的好處是:通用對話和專業(yè)任務(wù)分離。Agent 遇到它有 Skill 的任務(wù),就用 Skill 的高質(zhì)量流程來處理;遇到?jīng)]有 Skill 覆蓋的任務(wù),就用通用能力兜底。
4.6 實(shí)際案例:Claude Code 中的 Skill 體系
Claude Code(Anthropic 的 CLI 編程助手)中的 Skill 是一個(gè)很好的實(shí)際案例。它的 Skill 系統(tǒng)有以下特點(diǎn):
- 聲明式定義:每個(gè) Skill 有名稱、描述、觸發(fā)詞、執(zhí)行指令
- 自動(dòng)觸發(fā):用戶輸入匹配觸發(fā)詞時(shí)自動(dòng)激活對應(yīng) Skill
- 可組合:一個(gè) Skill 可以調(diào)用其他 Skill,形成鏈?zhǔn)綀?zhí)行
- 可獨(dú)立迭代:修改一個(gè) Skill 不影響其他 Skill
比如一個(gè)"生成博客文章"的 Skill,它內(nèi)置了:
- 文章結(jié)構(gòu)模板(引言、正文、總結(jié)的標(biāo)準(zhǔn)框架)
- 寫作風(fēng)格約束(避免 AI 套話、保持技術(shù)深度)
- 圖表生成流程(自動(dòng)調(diào)用 draw.io Skill 生成配圖)
- 質(zhì)量檢查清單(自動(dòng)檢查技術(shù)準(zhǔn)確性、代碼可運(yùn)行性)
如果沒有這個(gè) Skill,你每次都要在 Prompt 中把這些要求重復(fù)一遍,效果還不穩(wěn)定。有了 Skill,一句"幫我寫一篇關(guān)于 Redis 的文章"就能觸發(fā)整套高質(zhì)量流程。
五、MCP:AI 世界的"USB 接口"
5.1 一句話定義
MCP(Model Context Protocol)= 模型上下文協(xié)議。它是 Anthropic 在 2024 年底推出的一個(gè)開放標(biāo)準(zhǔn),定義了 AI 應(yīng)用與外部數(shù)據(jù)源、工具之間的通信協(xié)議。簡單說,MCP 就是 AI 世界的"USB 接口"——有了這個(gè)標(biāo)準(zhǔn),任何工具都可以用統(tǒng)一的方式接入任何 AI 應(yīng)用。
5.2 MCP 要解決什么問題?
在 MCP 出現(xiàn)之前,AI 應(yīng)用接入外部工具的方式是這樣的:
- 接 GitHub?寫一套 GitHub 的適配代碼
- 接 Slack?再寫一套 Slack 的適配代碼
- 接數(shù)據(jù)庫?再寫一套……
- 換一個(gè) AI 框架?所有適配代碼全部重寫
這就是經(jīng)典的 M×N 問題:M 個(gè) AI 應(yīng)用 × N 個(gè)工具,需要 M×N 個(gè)適配器。
MCP 的解決方案是:定義一個(gè)統(tǒng)一的協(xié)議標(biāo)準(zhǔn)。工具只需要實(shí)現(xiàn)一次 MCP Server,就能被所有支持 MCP 的 AI 應(yīng)用調(diào)用。AI 應(yīng)用只需要實(shí)現(xiàn)一次 MCP Client,就能接入所有 MCP Server。M×N 變成了 M+N。
這跟 USB 的故事一模一樣——USB 出現(xiàn)之前,每個(gè)外設(shè)都有自己的接口;USB 出現(xiàn)之后,一個(gè)接口走天下。
5.3 MCP 的架構(gòu)
MCP 采用經(jīng)典的客戶端-服務(wù)器(Client-Server)架構(gòu):

圖4 展示了 MCP 的三層架構(gòu)。Host 是面向用戶的 AI 應(yīng)用,Client 負(fù)責(zé)協(xié)議通信,Server 封裝了具體的工具和數(shù)據(jù)源。一個(gè) Host 可以連接多個(gè) Server,每個(gè) Server 提供不同的能力。
三個(gè)核心角色
MCP Host(宿主):面向用戶的 AI 應(yīng)用,比如 Claude Desktop、IDE 插件、自定義的 AI 應(yīng)用。Host 內(nèi)部包含 LLM,負(fù)責(zé)理解用戶意圖并決定調(diào)用哪些工具。
MCP Client(客戶端):Host 中負(fù)責(zé)與 MCP Server 通信的模塊。每個(gè) Client 與一個(gè) Server 保持一對一的連接。
MCP Server(服務(wù)端):工具和數(shù)據(jù)源的提供者。每個(gè) Server 封裝一個(gè)或一組相關(guān)的能力,通過 MCP 協(xié)議暴露給 Client。
三種核心能力
MCP Server 可以向 Client 暴露三種類型的能力:
| 能力類型 | 說明 | 示例 |
|---|---|---|
| Tools(工具) | 可以被 LLM 調(diào)用的函數(shù) | 查詢數(shù)據(jù)庫、發(fā)送消息、創(chuàng)建文件 |
| Resources(資源) | 可以被讀取的數(shù)據(jù) | 文件內(nèi)容、數(shù)據(jù)庫記錄、API 響應(yīng) |
| Prompts(提示模板) | 預(yù)定義的 Prompt 模板 | 代碼審查模板、翻譯模板 |
5.4 MCP 的通信機(jī)制
MCP 基于 JSON-RPC 2.0 協(xié)議進(jìn)行通信,支持兩種傳輸方式:
(1)Stdio(標(biāo)準(zhǔn)輸入輸出):Server 作為子進(jìn)程運(yùn)行,通過 stdin/stdout 與 Client 通信。適合本地工具。
(2)HTTP + SSE(Server-Sent Events):Server 作為獨(dú)立的 HTTP 服務(wù)運(yùn)行,Client 通過 HTTP 請求發(fā)送命令,Server 通過 SSE 推送響應(yīng)和通知。適合遠(yuǎn)程服務(wù)。
一次典型的 MCP 交互流程:
1. Client → Server: initialize(初始化握手)
Client 發(fā)送自己支持的協(xié)議版本和能力
2. Server → Client: initialize response
Server 返回自己的能力列表(支持哪些 Tools/Resources/Prompts)
3. Client → Server: tools/list(查詢可用工具)
獲取 Server 提供的所有工具的名稱、描述、參數(shù) Schema
4. [用戶提問,LLM 決定需要調(diào)用某個(gè)工具]
5. Client → Server: tools/call(調(diào)用工具)
{
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": {
"sql": "SELECT * FROM users WHERE status = 'active'"
}
}
}
6. Server → Client: tool result(返回工具執(zhí)行結(jié)果)
{
"content": [
{
"type": "text",
"text": "查詢到 42 條記錄..."
}
]
}
7. [LLM 基于工具返回結(jié)果繼續(xù)推理或回復(fù)用戶]
5.5 實(shí)現(xiàn)一個(gè) MCP Server
下面用 Python 實(shí)現(xiàn)一個(gè)簡單的 MCP Server,它提供兩個(gè)工具:查詢天氣和查詢匯率。
from mcp.server import Server
from mcp.types import Tool, TextContent
import mcp.server.stdio
# 創(chuàng)建 MCP Server 實(shí)例
server = Server("weather-exchange-server")
# 定義工具列表
@server.list_tools()
async def list_tools() -> list[Tool]:
"""聲明這個(gè) Server 提供哪些工具"""
return [
Tool(
name="get_weather",
description="查詢指定城市的當(dāng)前天氣",
inputSchema={
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名稱,如 '北京'、'上海'"
}
},
"required": ["city"]
}
),
Tool(
name="get_exchange_rate",
description="查詢貨幣匯率",
inputSchema={
"type": "object",
"properties": {
"from_currency": {"type": "string", "description": "源貨幣,如 USD"},
"to_currency": {"type": "string", "description": "目標(biāo)貨幣,如 CNY"}
},
"required": ["from_currency", "to_currency"]
}
)
]
# 實(shí)現(xiàn)工具的具體邏輯
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
"""處理工具調(diào)用請求"""
if name == "get_weather":
city = arguments["city"]
# 實(shí)際項(xiàng)目中這里會調(diào)用真實(shí)的天氣 API
weather = fetch_weather_api(city)
return [TextContent(type="text", text=f"{city}當(dāng)前天氣:{weather}")]
elif name == "get_exchange_rate":
rate = fetch_exchange_rate(
arguments["from_currency"],
arguments["to_currency"]
)
return [TextContent(
type="text",
text=f"1 {arguments['from_currency']} = {rate} {arguments['to_currency']}"
)]
raise ValueError(f"未知工具: {name}")
# 啟動(dòng) Server(使用 stdio 傳輸)
async def main():
async with mcp.server.stdio.stdio_server() as (read, write):
await server.run(read, write)
if __name__ == "__main__":
import asyncio
asyncio.run(main())
要在 Claude Desktop 中使用這個(gè) Server,只需在配置文件中添加:
{
"mcpServers": {
"weather-exchange": {
"command": "python",
"args": ["path/to/weather_server.py"]
}
}
}
配置完成后,Claude 就可以在對話中調(diào)用 get_weather 和 get_exchange_rate 這兩個(gè)工具了——整個(gè)過程不需要修改 Claude 的任何代碼。
5.6 MCP 的生態(tài)現(xiàn)狀
截至 2025 年,MCP 生態(tài)已經(jīng)有了相當(dāng)?shù)囊?guī)模:
官方支持的 Host:
- Claude Desktop
- Claude Code(CLI)
- Cursor、Windsurf 等 AI IDE
社區(qū) MCP Server:
- 文件系統(tǒng)操作(讀寫本地文件)
- GitHub / GitLab(倉庫管理、PR、Issue)
- 數(shù)據(jù)庫(PostgreSQL、MySQL、SQLite)
- Slack / Discord(消息發(fā)送和查詢)
- 瀏覽器自動(dòng)化(Puppeteer)
- 搜索引擎(Brave Search)
MCP vs. OpenAI Function Calling:
| 維度 | MCP | OpenAI Function Calling |
|---|---|---|
| 定位 | 開放標(biāo)準(zhǔn)協(xié)議 | 特定廠商的 API 特性 |
| 跨模型 | 是,任何 LLM 都可以用 | 僅限 OpenAI 模型 |
| 運(yùn)行方式 | 獨(dú)立的 Server 進(jìn)程 | 嵌入在 API 調(diào)用中 |
| 能力范圍 | Tools + Resources + Prompts | 僅 Tools |
| 有狀態(tài) | 是,支持持久連接和會話 | 否,每次調(diào)用獨(dú)立 |
| 標(biāo)準(zhǔn)化 | 有完整的協(xié)議規(guī)范 | API 接口約定 |
MCP 的野心更大——它不是要替代 Function Calling,而是要成為 AI 工具生態(tài)的通用標(biāo)準(zhǔn),就像 HTTP 之于 Web、SQL 之于數(shù)據(jù)庫。
六、四者的關(guān)系:一張圖講清楚
到這里,四個(gè)概念都講完了。最后用一張圖把它們的關(guān)系串起來:
| 概念 | 角色定位 | 解決的核心問題 | 類比 |
|---|---|---|---|
| Agent | 自主執(zhí)行者 | AI 如何自主完成復(fù)雜任務(wù) | 一個(gè)能干的員工 |
| RAG | 知識供給 | AI 如何獲取準(zhǔn)確的領(lǐng)域知識 | 員工的參考資料庫 |
| Skill | 能力單元 | AI 的能力如何標(biāo)準(zhǔn)化和復(fù)用 | 員工的標(biāo)準(zhǔn)作業(yè)流程 |
| MCP | 連接協(xié)議 | AI 如何統(tǒng)一地調(diào)用外部工具 | USB 接口標(biāo)準(zhǔn) |
它們的協(xié)作方式:
用戶下達(dá)任務(wù)
↓
Agent(自主規(guī)劃和執(zhí)行)
├── 需要知識 → 調(diào)用 RAG 檢索相關(guān)文檔
├── 匹配到專業(yè)任務(wù) → 激活對應(yīng)的 Skill 執(zhí)行
└── 需要調(diào)外部工具 → 通過 MCP 協(xié)議調(diào)用 MCP Server一個(gè)具體的場景:用戶說"幫我排查 JIRA-1234 這個(gè)線上問題"。
- Agent 接收任務(wù),規(guī)劃執(zhí)行步驟
- Agent 激活 oncall-dispatcher Skill(線上問題排查的標(biāo)準(zhǔn)流程)
- Skill 內(nèi)部通過 MCP 協(xié)議調(diào)用 JIRA Server 獲取問題詳情
- Skill 通過 MCP 協(xié)議調(diào)用日志查詢 Server 搜索相關(guān)日志
- Agent 利用 RAG 從代碼知識庫中檢索相關(guān)源碼和文檔
- Agent 綜合所有信息,輸出根因分析報(bào)告
四個(gè)概念各司其職,共同完成了一個(gè)完整的工作流。
七、技術(shù)選型指南:實(shí)際工程中怎么選?
場景一:企業(yè)知識問答機(jī)器人
核心需求:員工可以用自然語言查詢公司規(guī)章制度、技術(shù)文檔等。
推薦方案:RAG 為主。將公司文檔索引到向量數(shù)據(jù)庫,通過 RAG 管道實(shí)現(xiàn)知識問答。不需要 Agent(單輪問答就夠了),不需要 MCP(不需要調(diào)用外部工具)。
場景二:AI 編程助手
核心需求:輔助開發(fā)者編寫代碼、排查問題、做 Code Review。
推薦方案:Agent + Skill + MCP 的完整組合。Agent 負(fù)責(zé)理解意圖和編排執(zhí)行;Skill 封裝各類編程任務(wù)的最佳實(shí)踐(代碼審查 Skill、單元測試 Skill 等);MCP 連接 IDE、Git、數(shù)據(jù)庫、日志服務(wù)等外部工具。如果需要參考項(xiàng)目文檔,再加上 RAG。
場景三:智能客服系統(tǒng)
核心需求:自動(dòng)回答客戶問題,必要時(shí)執(zhí)行操作(查訂單、退款等)。
推薦方案:Agent + RAG + MCP。RAG 提供產(chǎn)品知識和FAQ;Agent 判斷什么時(shí)候需要查詢系統(tǒng)、執(zhí)行操作;MCP 連接訂單系統(tǒng)、CRM 等后端服務(wù)??梢杂?Skill 封裝常見操作的流程(查訂單、申請退款等)。
場景四:數(shù)據(jù)分析助手
核心需求:用戶用自然語言描述分析需求,AI 自動(dòng)生成 SQL 并執(zhí)行。
推薦方案:Agent + MCP。Agent 負(fù)責(zé)理解分析需求、生成 SQL、解讀結(jié)果;MCP 連接數(shù)據(jù)庫執(zhí)行查詢??梢杂?RAG 存儲表結(jié)構(gòu)和業(yè)務(wù)術(shù)語的映射關(guān)系,幫助 Agent 生成更準(zhǔn)確的 SQL。
參考鏈接
- Anthropic MCP 官方文檔
- LangChain Agent 文檔
- RAG 論文原文 - Lewis et al., 2020
- Anthropic: Building effective agents
- MCP 協(xié)議規(guī)范
- OpenAI Function Calling 文檔
到此這篇關(guān)于Agent、RAG、Skill、MCP到底是什么的文章就介紹到這了,更多相關(guān)Agent、RAG、Skill、MCP是什么內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持腳本之家!
相關(guān)文章

一文詳解Claude Code中的五層架構(gòu):MCP、Skills、Agent、Subagents、Agent Teams怎么協(xié)
5 月初 Anthropic 官方公布了 Claude Code 的五層架構(gòu)——MCP / Skills / Agent / Subagents / Agent Teams,這個(gè)分層不是營銷話術(shù),每層都有明確的職責(zé)邊界和協(xié)作方向,下面2026-05-18
一文全解Hermes Agent 的 Skills、Plugins、Gateway
本文給大家深度解析Hermes Agent 的 Skills、Plugins、Gateway的相關(guān)知識,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2026-05-09
2026年最值得安裝的10個(gè)Claude Code Skills推薦
ClaudeCodeSkills是ClaudeCode的擴(kuò)展能力系統(tǒng),通過安裝特定的Skills,讓AI在特定領(lǐng)域表現(xiàn)得更專業(yè),文章介紹了10個(gè)精選Skills,涵蓋編程、設(shè)計(jì)、內(nèi)容創(chuàng)作、營銷、辦公等領(lǐng)域,2026-05-09
本文介紹了OpenClaw使用和管理MCP的指南,涵蓋環(huán)境準(zhǔn)備、三種連接MCP的方式、配置文件路徑匯總、常見問題排查及連接第三方MCP平臺的方法,重點(diǎn)強(qiáng)調(diào)了MCP在OpenClaw中的重要性2026-04-07
openclaw部署后如何調(diào)用mcp和skills
本文主要介紹了openclaw部署后如何調(diào)用mcp和skills,包括Skills的安裝、調(diào)用和MCP的配置、調(diào)用,還提供了內(nèi)網(wǎng)離線適配的相關(guān)配置,具有一定的參考價(jià)值,感興趣的可以了解一下2026-03-27






