作者 | 33號實驗室/knnwang

被Agent/RAG吊打？你缺的不是智商，是這篇文章！ 親歷鵝廠IEG/WXG項目實戰，大三菜鳥用血淚debug記錄， 撕開AI基石真面目 → 黑科技本質 = ______！ 連夜肝出 「人話說明書+通關路線圖」 ， 即學即用！青銅連夜上分，幫助大家快速入門Agent/RAG （文章前半部分會介紹Agent，后半部分討論RAG，最后還分享了優化RAG的一些tips，希望能幫助到大家！！）

一、AI的記憶管家與知識向導

當AI需要靠譜的知識而不是“胡說八道”時，就是我閃亮登場的時刻！

1. 嗨，我是RAG！我決定不再讓AI“憑空想象”

你肯定遇到過那些場面：你的AI助手自信滿滿地告訴你“北京在長江以南”，或者信誓旦旦地說“牛頓發明了電燈泡”，是不是讓人啼笑皆非？這些就是所謂的“幻覺”——就像你有一個知識淵博但偶爾會“異想天開”的朋友。唉，這就是我誕生之前的AI常態。

我就是為解決這個問題而生的！

我的全名是檢索增強生成（Retrieval Augmented Generation），你可以叫我RAG。簡單說，我就是給AI裝上的那個“事實核查器”！當AI需要回答問題時，我會先讓它去查閱可靠的資料庫，而不是坐在那里閉門造車、憑空編造。想象一下，一個認真的學生在考試前會先翻書復習，而不是瞎猜答案——我就是那個督促AI“翻書”的機制。今天，就讓我親自帶你們了解一下我的工作原理、如何讓我變得更強，以及我未來會變成什么樣。雖然聽起來有點技術含量，但我會用有趣的方式講給你聽！

2. 我的基本功：強大的“查字典”技能

(1) 我是什么？

想象一下，如果你是一位外科醫生。大部分手術流程你都爛熟于心，但遇到一個罕見病例時，你會怎么辦？沒錯，你會去查醫學文獻或者請教專家。我的核心能力，就是賦予AI這種“查閱外部知識”的本事！

本質上，我是一個技術框架，巧妙地把檢索系統和生成式AI模型（比如你們熟悉的大語言模型LLM） 結合在一起。當用戶提問時，我會先指揮檢索系統去龐大的知識庫里找到最相關的信息片段，然后把這些“證據”交給LLM，讓它基于這些真實可靠的信息生成最終回答。這就相當于給AI配了一個專屬的“私人圖書館” 和一個超級高效的“圖書管理員”（那就是我啦！）——你需要什么，我立刻幫你找到、整理好！

(2) 我是怎么工作的？

我的工作流程就像一位高效的辦公助理在處理你的請求，分三步走：

• 檢索（Retrieval - 我的搜索時間）： 當你拋出問題，我立刻將它轉化成一種我能理解的“查詢向量”，然后一頭扎進知識庫的海洋，快速撈出最相關的文檔或信息片段。這就像你的助理收到任務，立刻跑去檔案柜精準查找文件。
• 增強（Augmentation - 我的整理時間）： 找到這些寶貝信息后，我可不會直接丟給LLM。我會精心地把它們和你的原始問題融合在一起，打包成一個信息更豐富、背景更清晰的“增強提示”。這就好比你的助理把找到的所有資料整理成一份重點突出、條理清晰的簡報，準備呈報給老板。
• 生成（Generation - LLM的表演時間）： 最后，LLM這位“決策者”登場了！它基于我精心準備的“增強提示”，結合自身的理解能力，生成最終的、有據可依的回答。就像老板審閱了助理的簡報后，給出了深思熟慮的解決方案。

(3) 衡量我表現的關鍵指標

想看看我這個“圖書管理員”兼“助理”干得怎么樣？主要看兩個“成績單”：

召回率（Recall - 我的找書能力）： 這衡量我在知識庫里能成功找到多少真正相關知識的比例。召回率高，說明我“找得全”，不會漏掉重要資料。就像圖書管理員能幫你找到幾乎所有相關書籍。

忠實度（Faithfulness - 我的誠實度）： 這衡量我最終讓LLM生成的內容，到底有多忠實于知識庫里的原始信息。忠實度高，說明LLM“編造”得少，傳達準確。就像你的助理在匯報時，能原原本本地傳達文件內容，而不是添油加醋或者自己瞎發揮。

3. 我的成長之路：從“菜鳥”到“高手”的優化之道

坦白說，我剛“上崗”時表現可不咋地。就像文檔里提到的，召回率才25.4%，忠實度才27.2%——活脫脫一個滿腔熱血但毛手毛腳的實習生！那我是怎么一步步變強的呢？

(1) 優化我的“字典”——知識庫

如果給我的知識庫一團糟——就像文檔里說的“知識庫混亂，評估規則口口相傳，靠經驗”——那就像給一個學生一本錯誤百出、章節亂序的教科書，我再聰明也使不上勁啊！

我的優化秘籍：

• 知識結構化（整理我的書架）： 把那些雜亂無章的非結構化文本，變成整齊的結構化數據。就像把一堆散亂的筆記，分門別類整理成清晰明了的筆記本。
• 知識更新機制（讓我的字典不過時）： 文檔里提到“構建定時器，加入裁判大模型構建自動化評估腳本”——這太關鍵了！我需要定期更新我的知識庫，并用“裁判”模型自動檢查內容質量，確保我掌握的都是最新、最準確的信息。
• 知識冗余消除（清理我的書庫）： 把那些重復的、過時的、或者互相矛盾的信息清理掉。就像圖書館定期下架舊書和處理復本一樣。

(2) 優化我的“查資料”技巧——檢索策略

召回率目標要從可憐的25.4%提升到90%！這意味著我要從“只能找到四分之一相關書”的菜鳥，變成“幾乎能找全所有資料”的資深管理員。

我的升級手段：

• 混合檢索策略（十八般武藝都用上）： 我不再只用一種方法找資料。我會結合關鍵詞檢索（按書名/作者找）、語義檢索（按意思找）、知識圖譜檢索（按知識關聯找）等多種手段。就像同時用分類號、作者索引和主題詞來幫你找書。

• 查詢重寫與擴展（理解你的言外之意）： 我會對你的原始問題進行“深加工”——改寫得更清晰，或者擴展出相關的主題。這樣就能找到更多你可能真正需要的資料。就像圖書管理員不僅給你找你要的那本書，還會推薦相關領域的其他好書。
• 上下文感知檢索（記住我們的對話）： 我會留意我們之前的聊天記錄和你的背景信息。這樣我就能更精準地理解你這次提問的意圖。就像圖書管理員記得你上次借了科幻小說，這次可能對科幻新書更感興趣。
• 檢索結果重排序（把最好的放前面）： 初步找到一堆資料后，我會進行二次排序，把最相關、最有價值的信息排在最前面。就像圖書管理員不僅找到了書，還按重要性給你排好了順序。

(3) 優化我的“表達方式”——生成策略

另一個關鍵目標是大幅降低“幻覺率”（即瞎編亂造），目標降到10%以下！這意味著我要讓LLM這個“演講者”從“大部分內容靠編”進化到“90%以上都有真憑實據”。

我的調教方法：

• 引用增強（標明信息來源）： 我會要求LLM在生成內容時，明確標注出哪些信息來自知識庫的哪部分。就像寫學術論文必須注明參考文獻一樣，清清楚楚。
• 不確定性表達（誠實比瞎猜強）： 如果知識庫里確實沒有足夠的信息來回答你的問題，我會讓LLM坦率地說“這個我不太確定”或者“目前我掌握的信息不足以回答”，而不是硬著頭皮編一個可能錯誤的答案。做個誠實的顧問很重要！
• 多樣性采樣控制（在框架內發揮）： 我會調整LLM生成過程中的“隨機性”程度，在允許它靈活表達的同時，牢牢控制它不偏離檢索到的真實信息這個核心框架。就像即興演講可以精彩，但不能跑題胡說。
• 后處理驗證（最后一道質量關）： 生成答案后，我還會請其他專門的“驗證模型”或者設定好的規則來檢查一下內容的準確性。這就像出版前的最后一道事實核查工序。

(4) 利用ragas評估自己的RAG

RAGAS (Retrieval-Augmented Generation Assessment) 它是一個框架(ragas源碼)，它可以幫助我們來快速評估RAG系統的性能，為了評估 RAG 系統。

① 環境配置

pip install ragas
pip install langchain
pip install chromadb

接下來我們需要導入存放Openai的api_key,這里我們會使用openai的gpt-3.5-turbo,對它的評估結果進行比對.

import os
import google.generativeai as genai
from dotenv import load_dotenv, find_dotenv
 
#導入.env配置文件
_ = load_dotenv(find_dotenv())

② Embeddings模型配置

from langchain.embeddings import HuggingFaceBgeEmbeddings
 
#創建BAAI的embedding
bge_embeddings = HuggingFaceBgeEmbeddings(model_name="BAAI/bge-small-zh-v1.5",
                                          cache_folder="D:\\models")

③ 加載文檔

from langchain.document_loaders import WebBaseLoader
 
urls = "https://baike.baidu.com/item/恐龍/139019"
loader = WebBaseLoader(urls)
docs = loader.load()

④ 創建父子文檔檢索器可參考這篇文章學習，在實踐過程中，父子文檔檢索是一種特別好用的技術 父子文檔技術 

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore
from langchain.vectorstores import Chroma

#創建主文檔分割器
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1000)

#創建子文檔分割器
child_splitter = RecursiveCharacterTextSplitter(chunk_size=400)

# 創建向量數據庫對象
vectorstore = Chroma(
    collection_name="split_parents", embedding_function = bge_embeddings
)
# 創建內存存儲對象
store = InMemoryStore()
#創建父文檔檢索器
retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=store,
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
#     verbose=True,
    search_kwargs={"k": 2}
)

#添加文檔集
retriever.add_documents(docs)

⑤ 創建Chain

LangChain介紹：https://www.langchain.com/

from langchain.prompts import ChatPromptTemplate
from langchain.schema.runnable import RunnableMap
from langchain.schema.output_parser import StrOutputParser
from langchain.chat_models import ChatOpenAI
# from langchain_google_genai import ChatGoogleGenerativeAI

# 創建模型實例
# model = ChatGoogleGenerativeAI(model="gemini-pro")  # 使用Gemini模型

# 創建OpenAI模型
model = ChatOpenAI()

# 創建提示模板
template = """你是一個問答助手。
請根據以下提供的上下文回答問題。
如果你不知道答案，請直接說不知道。
回答限制在兩句話以內，并保持簡潔。
問題: {question} 
上下文: {context} 
答案:
"""

# 根據模板生成提示
prompt = ChatPromptTemplate.from_template(template)

# 創建鏈式流程
chain = RunnableMap({
    "context": lambda x: retriever.get_relevant_documents(x["question"]),  # 獲取與問題相關的文檔作為上下文
    "question": lambda x: x["question"]  # 提取問題
}) | prompt | model | StrOutputParser()  # 將流程串聯：上下文+問題 -> 提示 -> 模型 -> 輸出解析

⑥ 創建文檔集

RAGAS需要以下信息:

• question：用戶輸入的問題。 answer：從 RAG 系統生成的答案(由LLM給出)。
• contexts：根據用戶的問題從外部知識源檢索的上下文即與問題相關的文檔。
• ground_truths： 人類提供的基于問題的真實(正確)答案。 這是唯一的需要人類提供的信息。

from datasets import Dataset

# 修改后的問題列表
questions = [
    "恐龍的名字是怎么來的？",
    "恐龍的分類有哪些？",
    "哪種恐龍的體型最大？",
    "最長的恐龍是什么？它是在哪里發現的？",
    "恐龍是如何繁殖后代的？",
    "恐龍是冷血動物還是溫血動物？",
    "小行星撞擊是恐龍滅絕的主要原因嗎？",
    "恐龍滅絕發生在什么時間？",
    "鱷魚和恐龍有親緣關系嗎？",
    "恐龍在英文中如何稱呼？"
]

# 修改后的參考答案列表
ground_truths = [
    ["1841年，英國科學家理查德·歐文在研究一些像蜥蜴骨頭的化石時，認為它們屬于一種史前生物，并將其命名為恐龍，意為‘令人恐懼的蜥蜴’。"],
    ["恐龍可以分為兩大類：鳥類恐龍和非鳥類恐龍。"],
    ["恐龍總體來說體型龐大，其中蜥腳類恐龍是已知的最大種類。"],
    ["目前已知最長的恐龍是梁龍，體長可達27米，它于1907年在美國懷俄明州被發現。"],
    ["恐龍通過產卵并孵化的方式繁衍后代。"],
    ["研究表明，恐龍既不是典型的冷血動物，也不是完全的溫血動物，而是介于兩者之間的一種狀態。"],
    ["最新研究顯示，小行星撞擊地球可能并非恐龍滅絕的唯一原因，當時脆弱的生態系統才是導致滅絕的關鍵因素。"],
    ["恐龍滅絕的時間大約是6500萬年前，地質年代屬于白堊紀末期或第三紀初期。"],
    ["鱷魚是恐龍的現代近親，但它們與非鳥類恐龍的關系比鳥類更遠。"],
    ["‘dinosaur’一詞由英國古生物學家理查德·歐文于1842年提出，來源于希臘語中的‘deinos’（恐怖的）和‘sauros’（蜥蜴）。"]
]

answers = []
contexts = []

# 推理過程
for query in questions:
    answers.append(chain.invoke({"question": query}))  # 調用鏈式流程生成答案
    contexts.append([docs.page_content for docs in retriever.get_relevant_documents(query)])  # 獲取相關上下文

# 構造數據字典
data = {
    "question": questions,  # 問題
    "answer": answers,      # 模型生成的答案
    "contexts": contexts,   # 相關上下文
    "ground_truths": ground_truths  # 參考答案
}

# 將字典轉換為數據集
dataset = Dataset.from_dict(data)

⑦ 評估

最后我們來讓RAGAs對我們的問答集進行評估，我們選擇了：context_precision、context_recall、faithfulness、answer_relevancy這4個作為我們的評估指標：

#openai的結果
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
)

result = evaluate(
    dataset = dataset, 
    metrics=[
        context_precision,
        context_recall,
        faithfulness,
        answer_relevancy,
    ],
)

df = result.to_pandas()
df

優化RAG的小tips： 注：如果把前面說的優化方式都做的很好了，RAG的效果大多數都可以做的很不錯，下面會介紹更底層的一些優化方式。

分詞預處理優化：

• 常規方法 文本的分詞直接通過text.split()處理，即會將空格，制表符\t、換行符\n等字符，作為分隔依據，這樣操作太過簡單。
• 改進方式：

1. 預處理：
   - 將所有非單詞字符（字母、數字、下劃線以外的）替換為空格。
   - 全角字符轉半角。
   - 轉換為小寫。
   - 繁體中文轉簡體中文。
2. 按語言切分：
   - 將預處理后的文本按語言（中文/非中文）分割成多個片段。
3. 分段處理：
   - 對于非中文（通常是英文）片段：
     - 使用 NLTK 的 `word_tokenize` 進行分詞。
     - 對分詞結果進行詞干提取 (PorterStemmer) 和詞形還原 (WordNetLemmatizer)。
   - 對于中文片段：
     - 如果片段過短（長度<2）或為純粹的英文/數字模式（如 "abc-def", "123.45"），則直接保留該片段。
     - 否則，采用基于詞典的混合分詞策略：
       a. 執行正向最大匹配 (FMM) 和逆向最大匹配 (BMM) 得到兩組分詞結果 (`tks` 和 `tks1`)。
       b. 比較 FMM 和 BMM 的結果：
          i.  找到兩者從開頭開始最長的相同分詞序列，這部分通常是無歧義的，直接加入結果。
          ii. 對于 FMM 和 BMM 結果不一致的歧義部分（即從第一個不同點開始的子串）：
              - 提取出這段有歧義的原始文本。
              - 調用 `self.dfs_` (深度優先搜索) 在這段文本上探索所有可能的分詞組合。
              - `self.dfs_` 會利用Trie詞典，并由 `self.sortTks_` 對所有組合進行評分和排序。
              - 選擇得分最高的分詞方案作為該歧義段落的結果。
          iii.繼續處理 FMM 和 BMM 結果中歧義段落之后的部分，重復步驟 i 和 ii，直到兩個序列都處理完畢。
       c. 如果在比較完所有對應部分后，FMM 或 BMM 仍有剩余（理論上如果實現正確且輸入相同，剩余部分也應相同），
          則對這部分剩余的原始文本同樣使用 `self.dfs_` 進行最優分詞。
4. 后處理：
   - 將所有處理過的片段（英文詞元、中文詞元）用空格連接起來。
   - 調用 `self.merge_` 對連接后的結果進行進一步的合并操作，
     嘗試合并一些可能被錯誤分割但實際是一個完整詞的片段（基于詞典檢查）。
5. 返回最終分詞結果字符串（詞元間用空格分隔）。

專門配置一個詞典，用來記錄常見詞匯，詞頻，詞性等信息。為加速查詢速度，構建一個Trie樹的形式(huqie.txt.trie)。

4. 文檔解析（PDF）

要用好rag的輸出增強效果，文檔解析是關鍵一環。如果文檔解析塊存在問題，那么后面檢索到的內容，也會對模型造成錯誤干擾。

經調研，開源的文檔解析產品主要有MinerU、Marker、MarkItDown、Docling四款主流產品。對于Doc2X，TextIn等未開源的收費產品，不在本文的考慮范圍之內。

這四款開源產品及對應的開發公司如下表所示：

考慮到本地部署，需要優先支持中文文檔的解析，大致瀏覽了一下這四款產品的倉庫，發現MinerU的生態非常完善，并且文檔都有中文版本，對本土開發者非常友好，于是對其進行研究。MinerU 有在線試用網頁，可讓用戶直接上傳文件進行解析。

地址如下：https://mineru.net/OpenSourceTools/Extractor

我上傳了中相同的論文，相同部分解析效果如下：

二、智能體（Agent）的定義與歷史

1. OPENAI在AGI五級分類中對agent的定義

想象一下人工智能的進化階梯，就像是從幼兒園到博士后的成長之路。OpenAI給我們畫了一幅AI成長的"五年級"照片墻：

• 第1階段：會聊天的AI（Conversational AI） 這就像是剛學會說話的小朋友，能和你有來有往地聊天，比如我們熟悉的ChatGPT。它能回答你"今天天氣怎么樣"，但別指望它能幫你收拾房間——它只會說，不會做！
• 第2階段：會思考的AI（Reasoners） 這是已經上了小學的AI，不僅會說，還會動腦筋。它能在學術領域大顯身手，解決復雜問題，就像那個總是舉手回答問題的班上小天才。"老師，我知道這道微積分題怎么解！"
• 第3階段：會自主行動的AI（Agents） 這是已經能獨立生活的青少年AI，可以自己做決定并付諸行動。它不需要你時刻盯著，能自己管理日程、回復郵件，就像你雇了一個永不疲倦的私人助理，而且不用發工資！
• 第4階段：會創新的AI（Innovators） 這是已經成為創意總監的AI，不僅解決問題，還能提出新點子。它可能某天早上醒來說："嘿，我想到了一種全新的能源技術！"然后真的幫你設計出來。這時候，人類工程師可能要開始擔心自己的飯碗了。
• 第5階段：會管理的AI（Organizers） 這是已經坐上CEO寶座的AI，能管理整個組織，協調復雜流程，效率比人類還高。想象一下，你公司的老板是個AI，每天早上準時發布完美的工作安排，從不偏袒任何人（除了可能對打印機特別友好）。

2. 智能體的核心定義

(1) 智能體（Agent）是什么？

簡單來說，智能體就是一個數字版的"全能選手"，它能看（感知）、想（決策）、做（執行）、學（學習）：

• 感知：就像你的眼睛和耳朵，智能體通過各種"傳感器"獲取信息。它的"眼睛"可能是攝像頭，"耳朵"可能是麥克風。
• 決策：這是智能體的"大腦"，通過復雜算法做出判斷。想象一個內置GPS的出租車司機，不斷計算最佳路線。
• 執行：智能體的"手腳"，可能是機械臂，也可能是軟件指令。就像你決定吃披薩后，手會自動拿起電話叫外賣。
• 學習：智能體的"成長能力"，它會從經驗中學習。就像玩游戲，玩得越多，技術越好，不會一直犯同樣的錯誤（理想情況下）。

(2) 智能體的歷史沿革

智能體的發展歷程就像是從圖書館管理員到自學成才的天才的進化：

• 1960～1980年代：規則驅動的智能體 這是"圖書館管理員"階段。所有知識都必須手動輸入，就像是給AI準備了一本厚厚的"生活指南"。問題是，一旦遇到指南上沒有的情況，它就傻眼了——"對不起，我的說明書上沒寫這個"。
• 1990～2010年代：強化學習驅動的智能體 這是"試錯學習"階段。AI開始通過不斷嘗試來學習，就像教寶寶走路——摔倒了再爬起來，慢慢就會了。"我上次這么做摔了一跤，這次我換個方法試試。"
• 2020年代至今：大模型驅動的智能體 這是"博覽群書"階段。大語言模型（LLM）讓AI能理解和生成人類語言，不需要事無巨細的指導就能完成任務。就像那個不僅讀過所有書，還能舉一反三的學霸，"雖然我沒做過這個具體任務，但根據我的知識，應該這樣解決..."

3. 與其討論 Agent，不如討論 Agentic

討論一個系統有多"Agentic"（具有智能體特性），就像討論一個人有多"成人"——關鍵在于它能自己做多少決定：

• 使用LLM將輸入路由到特定下游工作流： 這就像是個接線員，只負責把你的電話轉給合適的部門。"您好，要查詢賬單請按1，要投訴請按2..."
• 使用多個LLM進行多級路由決策： 這是升級版接線員，不僅轉接電話，還會根據你的問題做初步分析。"您說的問題涉及到賬單和配送，我先幫您轉到賬單部門，然后..."
• 如果某個步驟需要決定繼續執行還是終止： 這就像有了一定自主權的助理，能決定是否繼續一項任務。"我看這個方案行不通，讓我們嘗試另一種方法..."
• 當系統能自主構建工具、記憶工具并在后續步驟中使用： 這是真正的"自主智能體"，就像一個全能助手，不僅執行任務，還能創造新工具來解決問題。"我發現這個問題需要特殊工具，我來設計一個，然后用它來解決..."

三、基于大模型的智能體的原理

"LLM Agent：當你的AI助手突然有了上進心"

這貨可不是只會背課文的書呆子！作為大語言模型（LLM）驅動的"最強大腦"，它把簡單聊天變成了"智力奧運會"——既能跟你嘮嗑，又能干活跑腿，甚至偶爾露出"讓我想想"的沉思者表情。

本質上是個披著對話框外衣的瑞士軍刀：

• 推理能力 - 堪比福爾摩斯，只是破案速度取決于服務器負載
• 記憶功能 - 像金魚，但屬于那種會做筆記的金魚
• 自主性 - 約等于"知道主動問你要咖啡"的級別

LLM Agent的定義：

LLM Agent 是通過與自身之外的其他系統交互來服務于用戶目標的生成式 AI 系統。換句話說，它不僅依賴于自身的計算能力，還需要與其他外部系統協同工作，從而完成更復雜的任務。

LLM Agent的核心組成：

• 大語言模型（Large Language Models） ：作為智能體的核心，負責理解和處理自然語言，提供推理和決策能力。
• 工具調用（Tool Invocation） ：智能體可以調用外部工具或 API 來完成特定任務，例如查詢數據庫、操作文件等。
• 規劃（Planning） ：智能體需要根據任務目標制定計劃，決定如何使用資源和工具。
• 記憶（Memory） ：智能體需要記住之前的操作和結果，以便在后續任務中參考和優化。

LLM Agent的工作流程：

• 感知環境 ：智能體通過與外部環境交互，獲取任務需求和相關信息。
• 分析任務 ：利用大語言模型的強大推理能力，分析任務并制定解決方案。
• 執行任務 ：調用外部工具或 API 執行具體操作，逐步完成任務。
• 反饋與優化 ：根據執行結果進行學習和優化，提升未來的表現。

1. 規劃（Planning）

(1) 子目標分解

① 目的：復雜任務通常包含多個步驟，智能體（Agent）需要了解這些步驟并提前規劃。前面提到的 CoT（Chain of Thought，思維鏈）及其改進方法，本質上就是在進行任務分解。

② 任務分解實現：

• 給LLM提示詞：例如，“Steps for XYZ.\n1. What are the subgoals for achieving XYZ?”
• 使用具體任務指令：例如，對于寫小說的任務，先給出“Write a story outline.”的指令。
• 用戶直接輸入：用戶可以直接提供任務分解的步驟。

(2) 關鍵點

CoT和ToT的本質：無論是 CoT 還是 ToT（Thoughts on Thoughts），本質上都是通過精心設計的提示詞（Prompt），激發模型原有的元認知能力（Metacognition）。也就是說，通過某種線索，能夠更精準地調動模型中擅長規劃的部分。

(3) LLM+P方法

① 整體規劃：LLM+P 是一種利用規劃域定義語言（Planning Domain Definition Language, PDDL）來進行長序列任務規劃的方法。

② 工作流程：

• 問題翻譯：LLM 將問題翻譯成 PDDL 格式。
• 請求經典Planner：接著，請求經典 Planner 根據現有的領域 PDDL 生成一個 PDDL Plan（計劃）。
• 翻譯回自然語言：最后，將 PDDL 計劃翻譯回自然語言（由 LLM 完成）。

③ 前提條件：這種方法需要特定領域的 PDDL 描述和合適的 Planner。

(4) 反思與完善

Agent的自我反思能力非常重要。它能夠對歷史動作進行自我批評和反思，從錯誤中學習，并在后續步驟中不斷優化，從而提升最終結果的質量。這種 自我反思（Self-reflection） 是 Agent 不斷改進的關鍵環節。在現實世界中，犯錯是不可避免的，而自我反思在其中發揮著至關重要的作用。

(5) ReAct框架

ReAct是一種結合了 Reasoning（推理） 和 Action（行動） 的方法。它的核心思想是通過擴展 Action Space，使其包含特定任務的離散動作和語言空間的組合。具體來說：

• Reasoning：幫助 LLM 與環境進行交互。
• Action：通過提示詞，讓 LLM 使用自然語言生成完整的推理過程。

ReAct 的提示詞模板提供了一個明確的思考步驟，大致格式如下：

Thought: ... Action: ... Observation: ...

(6) ReAct的優勢

在知識密集型任務和決策任務的實驗中，ReAct 的表現優于傳統的單一 Act... 方式。這是因為 ReAct 能夠更好地結合推理和行動，使 Agent 更加靈活和高效。

(7) Reflexion框架

Reflexion 是一個讓 Agent 具備動態記憶和自我反思能力的框架，旨在提高其推理能力。它采用標準的強化學習（RL）設置：

• 獎勵模型：提供簡單的二進制獎勵（成功或失敗）。
• Action Space：在 ReAct 的基礎上，進一步擴展為特定任務的行動空間，并加入語言支持，以實現更復雜的推理步驟。

在每個行動 a(t) 之后，Agent 會計算一個啟發式函數 h(t)，并根據自我反思的結果決定是否重置環境，開始一個新的循環。

2. 記憶（Memory）

(1) 記憶的分類與實現

① 短期記憶（短期學習）

上下文學習：這是模型的一種短期記憶能力，類似于人類的短期記憶，能夠記住最近的信息或上下文。

② 長期記憶

• 長期記憶功能：為智能體提供保留和召回長期信息的能力。
• 實現方式：通過外部向量存儲和檢索來實現。

(2) 人腦中的記憶類型

記憶可以定義為用于獲取、存儲、保留和隨后檢索信息的過程。人腦中有多種類型的記憶：

① 感官記憶：

這是記憶的最早階段，是在接受原始刺激后保留的感官信息（如視覺、聽覺、觸覺）的能力。

感官記憶通常只能持續幾秒鐘，主要包括以下幾種：

• 圖示記憶（Iconic memory,視覺）：對視覺信息的短暫記憶。
• 回聲記憶（Echoic memory,聽覺）：對聽覺信息的短暫記憶。
• 觸碰記憶（Haptic memory,觸覺）：對觸覺信息的短暫記憶。

② 短時記憶（STM）或工作記憶：

• 它存儲了我們當前意識到的信息，以及執行復雜認知任務（如學習和推理）所需的信息。
• 短時記憶被認為有大約 7 個項目的容量，并能夠持續 20-30 秒。

③ 長時記憶（LTM）：

長時記憶可以將信息存儲很長時間，從幾天到幾十年不等，存儲容量基本上是無限的。

長時記憶分為兩種：

• 顯性/陳述性記憶：對事實和事件的記憶，指那些可以有意識地回憶起的記憶，包括外顯記憶（事件和經歷）和語義記憶（事實和概念）。
• 隱形/程序性記憶：這種記憶是無意識的，涉及自動執行的技能和例行程序，如騎車、在鍵盤上打字。

(3) 最大內部產品搜索（MIPS）

為了緩解關注范圍有限的限制，可以通過使用外部存儲器來優化檢索速度。常見的選擇是 ANN（人工神經網絡）算法，返回近似的 top k 個近鄰，用少量精度損失換取速度的巨大提升。以下是幾種常見的 ANN 算法選擇進行快速 MIPS 的方法：

① LSH（locality-sensitive hashing）：

引入了一種哈希函數，能夠最大限度地將相似的輸入項映射到同一個桶中，其中桶的數量遠小于輸入內容的數量。

② ANNOY（Approximate Nearest Neighbors Oh Yeah）：

核心數據結構是隨機投影樹，它是一個二叉樹集合，每個非葉子節點表示將輸入空間劃分為兩半的一個超平面，每個葉子節點存儲一個數據點。

這些樹是獨立隨機構建的，在某種程度上，它模擬了一個哈希函數的作用。

ANNOY 的搜索發生在所有樹中，迭代地搜索最接近查詢的那一半，然后聚合結果。其思想與 KD 樹非常相關，但可擴展性更強。

③ HNSW（Hierarchical Navigable Small World）

設計思想：HNSW 的設計理念來源于“小世界網絡”理論。在小世界網絡中，每個節點只需要通過很少的步驟就可以連接到任何其他節點，就像社交網絡中的“六度分隔”現象一樣。

結構特點：

• HNSW 構建了多層的小世界網絡結構，底層包含實際的數據點。
• 中間層添加了一些“快捷鍵”，用于加速搜索過程。

搜索過程：

• 在進行搜索時，HNSW 從頂層的一個隨機節點開始，逐步導航向目標節點移動。
• 如果在某一層無法接近目標，它會下降到下一層，直到到達底層。
• 在上層每一步導航都能潛在地跨越數據空間中的大距離，而在下層每一步導航可以提高搜索的質量。

④ FAISS

核心假設：FAISS 基于一個假設，即在高維空間中，節點之間的距離遵循高斯分布，因此應該存在數據聚類。

實現方式：

• FAISS 通過向量量化來實現。首先將向量空間劃分為若干集群，然后在每個集群內進行更精細的量化。
• 在搜索時，首先使用粗粒度的量化查找可能的集群候選，然后在每個候選集群內使用更細致的量化進行進一步查找。

⑤ ScaNN（Scalable Nearest Neighbor Search）

主要創新：ScaNN 算法的主要創新在于使用了各向異性向量量化。它對數據點進行向量化，使得內積 <q,> 盡可能與原始距離相似，而不是選擇最接近的量化質心點。

3. 工具使用（tool use）

對模型權重丟失的信息，agent學習調用外部API獲取額外信息，包括當前信息、代碼執行能力、專有信息源的訪問等等。

(1) 智能體與LLM的區別

① LLM

和LLM的對話就是：你輸入一個提示，大模型生成一個回答。

Plain Text 用戶輸入：幫我寫一篇科幻主題的文章 模型輸出：文章xxxxxxxxxxxxxxxxxxxxx

② Agent

和Agent的對話就是：你有一個助手，你不是簡單地直接寫，先詢問你是否需要進行一些網絡研究，然后寫下初稿，然后回顧初稿，并思考哪些部分需要修改，然后修改草稿，不斷進行思考和迭代這個過程。這個流程是一個思考+迭代的過程。

Plain Text 用戶輸入：幫我寫一篇科幻主題的文章 Step 1: 思考和規劃 Step 2: 聯網搜索 Step 3: 確定主體大綱 Step 4: 優化修改 模型輸出：文章xxxxxxxxxxxxxxxxxxxxx

(2) 與強化學習智能體的區別

• 強化學習智能體：輸入為預設好的向量化的環境狀態（或者圖像），策略通常由簡單的神經網絡結構進行初始化，輸出動作多為底層控制（移動、攻擊等）。
• 基于大模型的智能體：輸入為文字（多模態場景下也會有視覺、語音等信息），策略為預訓練的具備世界知識的大語言模型，輸出動作為文本，但可以通過結構化輸出和提取實現 function_call，進一步與現實環境進行交互。

四、智能體的分類

1. 按照數量分類

• SingleAgent：單個智能體進行任務規劃與行動。
• MultiAgent：強調多樣化的 agent profiles，agents 間交流相互作用和集體決策過程。更多動態和復雜的任務可以通過多個自主智能體的協作、辯論、討論來完成，每個智能體都具有獨特的策略和行為，并相互之間進行通信。

2. 按照行為模式分類

(1) Tool Use Agent

• MRKL system：Modular Reasoning, Knowledge, and Language（模塊化推理、知識和語言）。一個 LLM 作為 router 提供對多種工具的訪問，然后 router 可以多次調用工具獲取諸如時間、天氣等信息，然后結合這些信息給出回復。下面的相關工作都是類似的技術，大部分還包含了微調：Toolformer、Gorilla、Act-1、Hugging-gpt、ToolkenGPT。
• CRITIC：Self-Correcting with Tool-Interactive Critiquing利用工具交互評價來自我修正。首先根據 prompt 生成回答，然后同樣的 LLM 對答案中可能出現的錯位進行 criticize，最后使用相應的外部工具，如聯網搜索、代碼解釋器對部分回答進行驗證或修正。CRITIC 流程圖：

(2) Code Generation Agent

代碼編寫和執行能力也是一項重要的 Agent 能力，也可以被劃分為 Tool Use Agents（Tool 就是代碼解釋器等）。

① Program-aided LM

將問題直接轉換為 code，然后利用 Python 解釋器生成答案。

② Tool-Integrated Reasoning Agent

類似 PAL，但是 code 和推理多步交叉直到解決問題。PAL 是單個 code-gen step。下圖是 CoT、PAL 和本文的對比：

③ TaskWeaver

也是類似 PAL，但是可以利用用戶定義的插件。

Observation-based Agent：一些 Agents 被設計為通過與（gym 之類的環境）交互來解決問題，這些基于 Obs 的 Agent 會將接收到的觀測插入到 Prompt 中。

RAG Agent：從外部來源（本地知識庫等）檢索信息并插入 prompt 的范式，可以提高知識密集型任務的性能。RAG 其實也是一種特殊的 Agent，一般都是調用外部數據庫/向量庫作為工具。

④ 智能體系統分類

從架構上看，Agentic system 可以分為兩大類系統：

工作流（Workflow） ：

• 通過預定義代碼路徑編排 LLM 和工具。
• 適用于任務明確、步驟可預定義的場景。

自主智能體（Autonomous Agent） ：

• LLM 動態控制決策和工具使用。
• 自主規劃任務。
• 適用于任務步驟難以預知、需長期自主規劃的場景。

五、智能體評估框架

1. AgentBench

AgentBench 的核心思想是，將LLM作為Agent進行評估。

其8種實際場景可以歸為三類：

• 編碼 ：讓LLM生成代碼，操作系統、數據庫和知識圖譜屬于編碼類型。
• 游戲 ：讓LLM扮演游戲角色，數字卡牌游戲、橫向思維謎題、持家游戲屬于游戲類型。
• Web ：讓LLM完成與網頁相關的任務，網購和瀏覽網頁屬于Web類型。

六、智能體實踐

1.  基于openai接口實現簡單的agent

from openai import OpenAI
import json

# 初始化 OpenAI 客戶端
client = OpenAI(api_key="sk-api_key")

# 定義工具：查詢股票價格
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_stock_price",
            "description": "Get the current price of a given stock.",
            "parameters": {
                "type": "object",
                "properties": {
                    "symbol": {
                        "type": "string",
                        "description": "Stock symbol e.g. AAPL, GOOGL"
                    }
                },
                "required": ["symbol"],
                "additionalProperties": False
            },
            "strict": True
        }
    }
]

# 用戶消息：詢問某只股票的價格
messages = [{"role": "user", "content": "What's the current price of Apple stock?"}]

# 調用 OpenAI 的 chat completions API
completion = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    tools=tools,
)

# 打印模型的回復
print(completion.choices[0].message.content)

2. 基于Langchain實現一個簡單的React Agent

from langchain.chains import LLMMathChain, LLMChain
from langchain.agents import Tool, initialize_agent, AgentType
from langchain.prompts import PromptTemplate
from langchain import OpenAI
import os

# 設置 OpenAI API 密鑰
os.environ["OPENAI_API_KEY"] = "your_api_key"

# 初始化 LLM 模型
llm = OpenAI(temperature=0)

# 工具 1：翻譯工具
def translate_text(text, target_language):
    """模擬翻譯功能，將文本翻譯為目標語言"""
    # 這里可以替換為實際的翻譯邏輯，例如調用翻譯 API
    returnf"Translated text: {text} (to {target_language})"

translate_tool = Tool(
    name='Translator',
    func=lambda x: translate_text(x['text'], x['target_language']),
    descriptinotallow='Useful for translating text from one language to another.'
)

# 工具 2：天氣查詢工具
def get_weather(location):
    """模擬天氣查詢功能，返回指定位置的天氣信息"""
    # 這里可以替換為實際的天氣查詢邏輯，例如調用天氣 API
    returnf"Weather in {location}: Sunny with a high of 75°F and low of 60°F."

weather_tool = Tool(
    name='WeatherChecker',
    func=lambda x: get_weather(x['location']),
    descriptinotallow='Useful for getting the current weather for a given location.'
)

# 將所有工具存進一個數組中
tools = [translate_tool, weather_tool]

# 初始化 ReAct Agent
react_agent = initialize_agent(
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    tools=tools,
    llm=llm,
    verbose=True
)

# 測試 ReAct Agent
print(react_agent.run("What's the weather like in New York?"))
print(react_agent.run("Translate 'Hello' to Spanish."))

3. Manus分析& OpenManus技術方案

https://manus.im/share/OZB4PvsXY5N5FrvLXqqCl4?replay=1

注：這篇文章很多格式的處理就是通過manus幫我完成的

4. Manus的工作原理

Manus 是一個多智能體系統，它在完成任務時會按照以下步驟進行：

① 任務拆分：

• Manus 首先使用 PlanningTool 對任務進行規劃，將復雜任務拆分成多個子任務。
• 這些子任務會被組織成一個線性的計劃，每個任務都有明確的執行順序。

② 分配與執行：

• 每個子任務會被分配給相應的智能體（Agent）。
• Agent 在執行任務的過程中，會以 ReAct 循環的形式調用工具來完成任務。ReAct 循環指的是“思考（Reason）+ 行動（Act）”，即 Agent 會先思考如何解決問題，然后通過調用工具來執行具體的操作。

③ 記錄進度：

Manus 使用 TODO.md 文件來記錄任務的完成情況，幫助跟蹤進度。

5. Manus的核心能力

① 規劃能力：

• Manus 使用 PlanningTool 來規劃任務，形成一個清晰的任務分解計劃。
• 根據測試，這種規劃能力在 SWEBench 上的表現非常出色，解決率從 49% 提升到了 70%，其中一部分提升來自于模型本身的優化，另一部分則來自于規劃工具的效果。

② 工具使用能力：

Manus 結合了 Claude+ 和其他經過微調的模型，這些模型在工程上做了大量優化，增強了它們在不同場景下的工具使用能力。

6. OpenManus的特點

OpenManus 是基于 Manus 的規劃優勢開發的，它繼承了 Manus 的任務分解能力，并在此基礎上進行了改進。以下是 OpenManus 的主要特點：

① 極簡可插拔框架：

• OpenManus 的核心是一個簡潔的 Agent 框架，強調模塊化和擴展性。
• 開發者可以通過自由組合 Prompt（提示詞）和 Tools（工具），快速定義 Agent 的行為邏輯和功能。
• 例如，Prompt 決定了 Agent 的思考方式，而 Tools 則提供了具體的行動能力（如代碼執行、搜索、文件操作等）。

② 工具驅動的ReAct Agent：

• OpenManus 基于 ReAct（Reason + Act）模式，以工具為核心驅動 Agent 的行動。
• Prompt 引導 Agent 的推理和邏輯，而 Tools 則賦予 Agent 行動能力。
• 這種設計讓 Agent 不僅能“思考問題”，還能“執行任務”。

③ 規劃能力處理復雜任務：

• OpenManus 繼承了 Manus 的多智能體規劃優勢，通過 PlanningTool 對用戶需求進行高層次的規劃。
• 它將復雜的任務分解為線性的子任務計劃，顯著提升了任務的成功率。
• 這種“先規劃，后執行”的思路，在處理長鏈條任務時尤為有效。

動態Agent分配與工具調度：

• 當一個任務被拆解為多個子任務后，系統會根據任務類型，動態分配給預先定義或適配的 Agent。
• 這種“臨時分配 + 工具協作”的機制，最大化利用了多模型、多工具的組合優勢，提高了系統的靈活性和效率。

結束語：

“以上淺見，不過是我在鵝廠的一點實踐心得。技術之路沒有銀彈，Agent與RAG的探索也遠未到終局。文中的方案必然存在局限，懇請各位前輩同仁不吝指正。若這些血淚經驗能為您節省幾分鐘調試時間，或帶來一絲靈感火花，便已值得。AI浪潮奔涌，愿與諸君共同探索——畢竟，真正的通關地圖，永遠由所有實踐者共同繪制。”