如何快速實現REST API集成以優化業務流程
ReAct 原理很簡單，沒有 ReAct 之前，Reasoning 和 Act 是分割開來的。舉個例子，你讓孩子幫忙去廚房里拿一個瓶胡椒粉，告訴 ta 一步步來（COT提示詞策略）：
- 先看看臺面上有沒有；
- 再拉開灶臺底下抽屜里看看；
- 再打開油煙機左邊吊柜里看看。
沒有 React 的情況就是：
不管在第幾步找到胡椒粉，ta 都會把這幾個地方都看看（Action）。
有 React 的情況是：Action1：先看看臺面上有沒有；Observation1: 臺面上沒有胡椒粉，執行下一步；Action2：再拉開灶臺底下抽屜里看看；Observation2：抽屜里有胡椒粉；Action3: 把胡椒粉拿出來。
是的，就是這么簡單，在論文的開頭作者也提到人類智能的一項能力就是 Actions with verbal reasoning，即每次執行行動后都有一個“碎碎念(Observation”：我現在做了啥，是不是已經達到了目的。這相當于讓 Agent 能夠維持短期記憶。
在看過幾個人的開源代碼后，拿出一個最容易被產品經理理解的代碼來解讀。看完你會發現本質上所有的 Agent 設計模式都是將人類的思維、管理模式以結構化prompt的方式告訴大模型來進行規劃，并調用工具執行，且不斷迭代的方法— 明白這一點非常重要。
代碼鏈接: https://github.com/samwit/langchain-tutorials/blob/main/agents/YT_Exploring_ReAct_on_Langchain.ipynb
我將代碼邏輯梳理為下圖(要仔細看)：
接下來結合代碼內容詳細解讀。
1.生成提示詞。首先，將代碼中預設好 ReAct 的提示詞模板(格式為Quesion->Thought->Action->Observation)和用戶的問題進行合并。得到的提示詞是這樣的。
如果需要針對你自己的領域定制，需要將 fewshot 里的內容更換為更合適的內容，比如你的 Action 里可能會有”Send message to someone”， 這里的 Action “Send message” 可能就對應一個外部工具的 API 接口。
2.調用大模型生成Thought+Action。 接下來將 few shot 提示詞發給大模型。如果直接將上述提示詞發給大模型，大模型生成將針對用戶問題生成一堆 Thought，Action 和 Observation，但顯然這里 Action 還沒有展開，我們并不希望大模型輸出 Observation。在代碼里通過 Stop.Observation 來控制大模型遇到Observation后停止輸出，于是大模型僅僅返回 Thought 和 Action，而不會把 Observation 給生成出來。
3.調用外部工具。拿到 Action 之后，大模型就可以調用外部工具了。首先判斷這里的 Action 是不是 Finish，如果不是我們就可以利用大模型把 Action 后面的自然語言轉換為外部工具能識別的 API 接口，這個轉換過程就是大模型的 function calling 功能，本質上是對大模型進行微調，專門用于語言格式轉換的模型，但并非所有的大模型都支持 function calling。
4. 生成Observation。API 接口返回后，還會將接口返回內容轉換為自然語言輸出，生成 Observation，然后將 Observation 的內容，加上剛剛的 Thought， Action 內容輸入給大模型，重復第 2，3 步，直至 Action 為Finish 為止。
5.完成輸出。將最后一步的 Observation 轉化為自然語言輸出給用戶。
由此，我們可以看到 Agent 要落地一個場景，需要定制兩項內容。
- Prompt 模板中 few shot 中的內容。
- function calling 中的外部工具定義。
而 Prompt 模板中 fewshot 本質上就是人類思維模式的結構化體現，通過查閱各個設計模式的 prompt 模板是很好的學習 Agent 設計模式的方法，習得這個方法，可以用同樣的方法理解其他的設計模式，以下模式不再進行代碼解讀，大家可以公眾號回復“Agent”獲得所有設計模式的代碼鏈接進行學習。
顧名思義這種設計模式是先有計劃再來執行。如果說 ReAct更適合 完成“廚房拿胡椒粉”的任務，那么 Plan & solve 更適合完成“西紅柿炒雞蛋”的任務：你需要計劃，并且過程中計劃可能會變化（比如你打開冰箱發現沒有西紅柿時，你將購買西紅柿作為新的步驟加入計劃)。
提示詞模板方面，論文標題中說得很直白，《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》，簡言之就是 Zero shot 的提升，下圖是作者代碼中給出的一些 PS-Plan and Solve 提示詞。
架構上它的組成是這樣的：
- 規劃器：負責讓 LLM 生成一個多步計劃來完成一個大任務。代碼中有 Planner 和和 Replanner，Planner 負責第一次生成計劃；Replanner 是指在完成單個任務后，根據目前任務的完成情況進行 Replan，所以 Replanner 提示詞中除了 Zeroshot，還會包含：目標，原有計劃，和已完成步驟的情況。
- 執行器：接受用戶查詢和規劃中的步驟，并調用一個或多個工具來完成該任務。
REWOO(Reason without Observation)這種方法是相對 ReAct中的Observation 來說的，ReAct 提示詞結構是 Thought→ Action→ Observation, 而 REWOO 把 Observation 去掉了。但實際上，REWOO 只是將 Observation 隱式地嵌入到下一步的執行單元中了，即由下一步驟的執行器自動去 observe 上一步執行器的輸出。
舉個例子，常見的審批流都是環環相扣的，比如我們的目標是完成 c，我們的步驟是：
- 我們需要從部門 A 中拿到 a 文件，
- 然后拿著 a 文件去部門 B 辦理 b 文件，
- 然后拿著 b 文件去部門 C 辦理 c 文件- 任務完成。
這其中第 2，3 步驟中 B，C 部門對 a，b 文件的審查本身就是一類Observation。又比如下面提示詞模板中給出 one shot 內容中定義出每一步的 plan 都會依賴上一步的輸入。
架構上它由三個組件組成：
- Planner：負責生成一個相互依賴的“鏈式計劃”，定義每一步所依賴的上一步的輸出。
- Worker：循環遍歷每個任務，并將任務輸出分配給相應的變量。當調用后續調用時，它還會用變量的結果替換變量。
- Solver：求解器將所有這些輸出整合為最終答案。
Compiler-編譯一詞在計算機科學的意義就是如何進行任務編排使得計算更有效率，原論文題目是《An LLM Compiler for Parallel Function Calling》，很直白，就是通過并行Function calling來提高效率，比如用戶提問張譯和吳京差幾歲，planner 搜索張譯年齡和搜索吳京年齡同時進行，最后合并即可。
提示詞里對 Planner 的要求是這樣的，重點是希望生成一個 DAG(Direct Acyclic Graph, 有向無環圖。
架構上有一個 Planner(規劃器)，有一個 Jointer(合并器)。
Basic Reflection 可以類比于學生(Generator)寫作業，老師(Reflector)來批改建議，學生根據批改建議來修改，如此反復。
提示詞就是復刻師生之間的交互。
架構上有一個 Generator，一個 Reflector。
Reflexion 是 Basic reflection 的升級版，相應論文標題是《Reflexion: Language Agents with Verbal Reinforcement Learning》，本質上是強化學習的思路。和 Basic reflection 相比，引入了外部數據來評估回答是否準確，并強制生成響應中多余和缺失的方面，這使得反思的內容更具建設性。
提示詞方面：會讓大模型針對問題在回答前進行反思和批判性思考，反思包括有沒有漏掉(missing)或者重復(Superfluous)，然后回答問題，回答之后再有針對性的修改(Revise)
架構上，有一個 Responder：自帶批判式思考的陳述 Critique；有一個 Revisor：以 Responder 中的批判式思考作為上下文參考對初始回答做修改。
LATS 相應論文標題是《Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models》，很直白：是 Tree search + ReAct+Plan&solve 的融合體。在原作的圖中，我們也看到 LATS 中通過樹搜索的方式進行 Reward(強化學習的思路)，同時還會融入 Reflection，從而拿到最佳結果。所以：
提示詞模板方面和之前的 reflection，plan&solve，ReAct 差別不大，只是上下文中多了對樹搜索結果的評估和返回結果。
架構上，就是多輪的 Basic Reflection， 多個 Generator 和 Reflector。
Self-discover 的核心是讓大模型在更小粒度上 task 本身進行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要補充，而 Self-discover 是對 task 本身進行反思。
提示詞方面，Self-discover 列出一系列的反思方式讓 agent 來選擇：
結構上，Self-Discover 如下圖所示：
- Selector: 從眾多的反省方式中選擇合適的反省方式；
- Adaptor: 使用選擇的反省方式進行反省；
- Implementor: 反省后進行重新 Reasoning;
Storm 相應論文標題是《 Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models》，很直白：可以從零生成一篇像維基百科的文章。主要思路是先讓 agent 利用外部工具搜索生成大綱，然后再生成大綱里的每部分內容。
提示詞模板方面主要圍繞如何生成大綱，如何豐富大綱內容來展開。
架構上，就是先有 topic， 然后生成大綱，根據大綱豐富內容。這里會有一個大綱生成器，一個內容生成器。
好了，以上就是目前所總結的 Agent 九大設計模式，其實 Agent 中沒有最好的設計模式，只有最適合的設計模式 ，最終還是要從用戶需求出發來選擇。
本文章轉載微信公眾號@產品二姐
