最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

一口氣徹底講清楚 Agent、RAG、Skill、MCP到底是什么

  發(fā)布時(shí)間:2026-06-05 11:38:58   作者:鏡花水月linyi   我要評論
刷到Skill、MCP、RAG、Agent這些詞時(shí),第一反應(yīng)大概率是,我是不是又落后了,這篇文章主要介紹了一口氣徹底講清楚 Agent、RAG、Skill、MCP到底是什么,文中介紹的非常詳細(xì),需要的朋友可以參考下

導(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,它可能會:

  1. 調(diào)用日志服務(wù)查詢最近的 OOM 堆棧
  2. 分析堆棧信息定位到具體的代碼路徑
  3. 讀取對應(yīng)的源碼文件
  4. 查詢該服務(wù)最近的代碼變更記錄
  5. 結(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-small1536性價(jià)比高,英文效果好
OpenAI text-embedding-3-large3072精度更高,成本也更高
BGE-large-zh1024中文效果好,可本地部署
M3E-base768輕量級,適合中文場景

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)常被混淆,澄清一下:

維度SkillPluginFunction 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_weatherget_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

維度MCPOpenAI 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è)線上問題"。

  1. Agent 接收任務(wù),規(guī)劃執(zhí)行步驟
  2. Agent 激活 oncall-dispatcher Skill(線上問題排查的標(biāo)準(zhǔn)流程)
  3. Skill 內(nèi)部通過 MCP 協(xié)議調(diào)用 JIRA Server 獲取問題詳情
  4. Skill 通過 MCP 協(xié)議調(diào)用日志查詢 Server 搜索相關(guān)日志
  5. Agent 利用 RAG 從代碼知識庫中檢索相關(guān)源碼和文檔
  6. 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。

參考鏈接

到此這篇關(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詳細(xì)攻略

    本文介紹了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

最新評論

芦山县| 滦平县| 博罗县| 滁州市| 色达县| 青冈县| 广东省| 桑日县| 钟山县| 蓬安县| 蒙自县| 潞城市| 读书| 巴林右旗| 湛江市| 韶关市| 灌云县| 德清县| 历史| 吉木萨尔县| 外汇| 礼泉县| 清流县| 漯河市| 泗洪县| 宣城市| 开化县| 房产| 县级市| 饶阳县| 合作市| 合江县| 齐河县| 搜索| 东莞市| 安新县| 衡山县| 平利县| 会东县| 康保县| 鸡东县|