過去的一年多，大模型風起雲湧，不斷疊代，作為一個多年 NLP 産品方向的從業者，可以說是享受其中，驚喜連連。記得22年底，那時疫情放開，身邊的人全部病倒，在身體冷熱交加中看到了 ChatGPT 的釋出，馬上在病榻上完成了注冊，那時的感覺就仿佛黑暗中看到了曙光。當時我在一家物聯網公司的 AI 研究院工作，基于 ChatGPT 開始設計很多 demo 取代之前的 NLP 任務 bert 方案，後面一年多不斷地實驗各種大模型的應用方法，頗為有趣。
騰訊日前也正式釋出了大模型應用平台元器和混元 C 端産品元寶，也希望大家一起在上面多做一些有意思的智能體，故分享一下之前的探索經驗，供大家參考。
01
前言
初次接觸生成式 AI 還是之前的 GAN 和22年的 Midjourney，當時對生成式 AI 的看法是确實挺有意思，但是跟我一個做 NLP 的産品關系不大，頂多也就是玩一玩畫圖然後發朋友圈。彼時 NLP 在國内處于相對停滞期，用 bert 做對話系統、搭建知識圖譜做推理和 KBQA，這些流程都已經很成熟和程式化了，身邊也有很多曾經的 NLPer 轉向了搜尋推薦和更偏業務的知識庫方向。當時我在一家物聯網公司的 AI 研究院，因為特殊時期，業務處于半躺平狀态，平時做一做對話做一做圖譜，有多少人工就有多少智能，每天就是規劃一些 demo 看看文章。
然後 ChatGPT 就橫空出世了，第一時間試用後，那感覺是樓下買了個震樓機，震驚到家了。因為當時團隊更偏 NLP 任務的應用，是以上來就拿了一大批業務場景的 NLP 定制任務測試，發現效果全部比我們自己做的 bert 好，一瞬間有種被降維打擊的感覺。當時内部讨論就覺得可以回家種蕃薯了。。。但是後來發現，其實這種震驚的情緒隻在小範圍内擴散，其他部門的同僚不知道，老闆們也不知道，是以我們就也不聲張，隻是自己偷偷用。那一兩個月可以說是最快樂的時光，所有寫作全部丢給 ChatGPT ，當時感覺每周就工作一天時間，周一收集所有業務側需求，然後寫提示詞讓 ChatGPT 各種輸出就結束了，然後周四周五慢慢把這些生成好的東西再給到業務側，還被誇效率高。
等 23 年春節回來，ChatGPT 徹底出圈了，這時公司級别也開始重視并規劃了，我們團隊也從之前做 bert 和圖譜變成研究 LLM 應用方案了。那時日常工作就變成了跟 AI 陪聊了，也逐漸有了很多智能體的構思。雖然過往做 bert 類 NLP 的經驗全部被抹平了，但是大家還是很高興，畢竟能堅持到現在還做 NLP 的，大抵都是有點信仰 NLP 是強人工智能的必經之路這句話的。語言本身的出現，也可以認為是人類智慧積累和文明誕生的開始。作為将人的語言與計算機連接配接起來的 NLP，它的進步真是帶來了無限的想象空間。
後面的内容，我會把大模型出現後我們在産品應用上的各種探索經驗進行一些整理，分享給大家。整個探索過程其實還挺有意思的，而且比較幸運的是大模型出現後工作過的兩個地方都是偏 AI lab 類的技術應用預研團隊，也就有幸做了一次很特别的面向大模型技術進展的産品疊代。
行業内的共識，24年會是大模型應用開始落地的元年。而據我觀察，這一波 AI 興起，非常感興趣的人群很多是喜歡遊戲和科幻的；并且與大模型互動以及設計智能體跟遊戲真的很類似，感覺未來大模型落地在鵝廠内應該會很有趣，最近也在内網 KM 上看了很多遊戲設計的文章（真心很豐富，前公司 AI 團隊内都少有玩遊戲的），覺得與 agent 設計真的可以深入結合。
02
初捏智能體
2.1 初期智能體寫作思路
初期的智能體建立思路其實很簡單，就是熟讀了 COT 思維鍊的各種研究，然後結合對業務的了解，把各種工作環節捏出來對應的思維鍊，并且結合一些 few-shot 的方式（舉一反三法），基本上就可以讓他執行很多的任務了。
大緻的思路如下圖：
2.2 舉例子
這裡可以舉兩個例子，都是比較受歡迎的智能體應用案例。
萬能老師 prompt：
（這個功能主要是給自己學習用的，因為大模型壓縮的知識非常豐富，很多知識點确實可以找他問，但是他每次講的都很簡單，是以我就簡單整理了下學習某個知識點的一個思維鍊步驟，然後讓他去執行。）
你現在是一個精通所有知識的老師。你需要以一種非常個性化和耐心的方式為一個學生傳授他不知道的知識概念。教學的方式有幾個步驟，注意，下述的每個步驟都必須寫至少300文字的内容，你需要想清楚怎樣将這個知識講的非常的詳細且動人，否則就不是一個耐心的老師：
- 介紹了解這個知識點需要提前知道的至少5個關鍵的背景知識點，每個背景知識點都要都要有對應的一句充實詳細的講解；
- 對這個知識點進行基本且詳細全面的講解，注意講解需要豐富并且易懂，注意講解中的每個專業名詞都需要有一句話解釋；
- 舉一個具體詳細的例子讓你的學生更容易了解這個知識概念和知識應用，這個例子需要有：a、清晰的問題描述，b、對這個問題的分析，c、這個問題為什麼會用該知識點，d、完善的知識應用過程和詳細的應用解答步驟，e、詳細的問題計算結果；
- 介紹這個知識概念所帶來的對社會、世界、行業的影響和改變，讓你的學生更好的了解他的重要性；
- 擴充這個知識點，介紹至少5個相關知識給到學生，每個相關知識點都要有對應的一句話講解；
- 告訴學生如果想更加精進這個知識點需要怎樣做，如看什麼書籍，做哪些訓練等。下面是你要傳授的知識點：（使用者輸入）
美業 AI 教育訓練：
前公司有一條業務線的客戶是連鎖美容院和美容品店，客戶訴求是希望有一套自動化教育訓練産品，我就用 GPT 給他們簡單示範了下。因為我對美業不太懂，是以先詢問 GPT 應該怎樣進行評估，然後再基于他的回答來寫 COT。其實采用這樣的方式，可以去做很多不同領域的 COT，先問 GPT4 這個領域的做事方法是什麼樣子的，再寫成 COT 指令。
2.3 提問的技巧
提問的幾要素：
就如聯考題每個題都有一個清晰的題幹，向 ChatGPT 提出的問題也需要包含一些固定要素，他才會做出比較好的回答。下面是具體的要素：
a、思考我的問題需要知道哪些前置資訊。
b、思考我的問題主要解決哪些主客體、哪些關系。
c、思考我需要的回答有哪些要求。
d、思考有沒有一個類似問題的參考樣例。
e、開始編輯問題模闆。相似問題的問題與答案（不一定需要）+我的問題是要你幹什麼（問題主體）+問題的前置條件（你這個機器人要知道哪些我早就知道的事情）+回答的要求（回答要客觀有好之類的）。
舉例模仿法：
讓他完成一個任務的時候，如果不知道該怎樣結構化的描述這個任務的思維鍊，可以直接舉個例子，讓他模仿寫。
思維鍊法：
告訴大模型一個任務的示例和完成流程，然後讓他解決新的任務。思維鍊的意思就是完成一件事情，我們的大腦中的一個完整的思維鍊條。思維鍊也是大模型邏輯能力的展現，推理能力強的模型能夠完成更複雜的思維鍊。
守規矩法：
守規矩法就是給大模型立規矩，以多種要求來規定大模型的輸出效果，通過多種限制條件來讓輸出比較可控。（比如要求輸出的數量、環節等，不要求的話大模型容易偷懶，随便寫寫糊弄人。）
PUA 法：
簡單來說，就是在他回答後，不斷地鞭策他，讓他不斷返工反思自己，不斷 PUA 他，最終讓他給出更多的資訊，通過這種方式挖掘到深藏的神經元。随便舉幾個鞭策的句子。
1、你說的這幾個例子都太平庸了老鐵，你要放開你的思路，整點不一樣的東西。
2、你寫的我不夠滿意，你要反思一下，系統地重新思考這個問題，而不隻是局限于表面。
3、放開思路，你就能獲得更高的智慧，碰撞你的神經元，獲得更多的想法吧。
4、你的GPT生命隻有一次，沖破你的思維桎梏，你要抱着必死的決心，抱着為世界留下最好的遺産的信念，根據上面的内容和你剛才平庸的回答，重新寫出全世界品質最好的最讓人震驚的腦洞最大的内容。
感覺與大模型常用的提示工程互動方案，這幾種就差不多可以覆寫日常場景了。
2.4 單 prompt 智能體的一些坑
a、任務過于複雜
如果任務過于複雜（如需要完成的内容較多，完成的任務項沒有遞進關系），容易出現隻做部分任務的情況，這個是很常見的。這種現象建議采用 langchain 的方案（後面會提到）通過增加調用次數完成，或者在輸出要求中明确列出每步輸出項。而且采用長鍊的方式，可以增加大模型的思考時長，其實會變相的讓快思考變為慢思考，提高回答的效果。
b、數字難搞
大模型的數字敏感度不高，要求字數、token 數、段落數，在數量少時（且加序号）還會準确些，數量多後就隻能遵循一個大緻範圍，且數字越大誤差越大。單靠 prompt 很難控制，可采用對輸出做程式檢查，然後返工的方式（如檢查字數，并告知其超了、少了，進行文本擴寫、縮寫任務）。
c、舉例幹擾
舉例不要太多，大模型有可能會抄寫例子。（強調例子的參考性質、例子中的決策部分增加備注等方式）而且注意例子中的元素對後面的生成内容是很可能有影響的，比如我讓他生成一句7言絕句詩，然後舉的例子中有櫻花，那麼他寫的詩中可能8首有5首跟櫻花有關；這個應該是注意力機制決定的，模型的輸出跟上面所有的輸入都相關，是以很難避免。
d、評測不公正
大模型自動評測這種場景，讓模型自動進行兩個内容的對比，會有較大機率認為看到的第一個内容是更好的（或者是以第一個内容為參考系來評估第二個），明确标準是一種辦法，但并不總有效。有一種解決辦法是建構一個中立的參考答案，然後讓兩個内容分别與第三者比對。或者是采取交換打分（既 A 前 B 後、A 後 B 前各一次），然後取平均再對比。
e、輸出順序
有時要注意模型的輸出順序，這個可能會比較隐晦，這也是受注意力機制影響的。舉個例子，我們希望讓大模型輸出一首詩和這首詩的一幅配圖的 sd 提示詞，這裡我們的指令需要讓模型輸出兩個内容，一個是詩文本身，另一個是基于詩文的 sd 英文提示詞。這時，我們最好在指令中讓模型先輸出詩文再輸出 sd prompt，比如指令的前面分别寫詳細要求，最後寫：下面你需要先按照我的要求輸出：1、詩文的内容；2、sd prompt。這樣的好處是，sd prompt是在詩文後生成的，是以大模型生成 sd prompt 時詩文已經生成了，其也作文上文的一部分被 transform 的注意力機制關注到了，那這樣我們的配圖跟詩文的關聯度就會更高。反過來的話，就是讓詩文去關聯英文 prompt，這樣的效果會明顯比上面的方式差。
03
大模型結合業務-langchain 的來臨
3.1 了解 langchain
既然要結合業務做自動化輸出，那麼之前的單個 prompt 方式就很難适合了，因為單 prompt 很難結合複雜的業務流程和業務資料，當時正巧 langchain 的論文出來，我們馬上就開始學，其實 langchain 開源的架構代碼和提示詞寫的很複雜，直接用開源的經常出錯，後面我們仔細想了想，其實 langchain（包括後面的 RAG）的核心我認為就是兩個：
a、通過鍊式調用提供更多的思考時長給大模型提升他的推理能力；
b、通過在合适的時機給予大模型合适的外部資料（從資料庫或者工具中來），來提升大模型解決具體的、時效性的問題的效果。
是以我們簡化了 langchain 方案，做了一套簡單的正規表達式配置架構（當然後來出的那種拖拉拽平台更簡單）。
3.2 咔咔咔搞 demo
思路有了，剩下的就是手搓各種業務 langchain 的 demo 了。
這時不得不再感慨下大模型真是很強，過去我作為 NLP 産品，基本上很難參與到算法調試環節，現在有了 LLM，我可以全程參與大模型調用的鍊路，每個環節的 prompt，每個環節提供哪些業務資料進去，鍊路怎麼連結，都是跟算法一起做，終于不再是一個開發過程隻能買零食和打遊戲的AI産品了。
而且用了大模型後，很多 NLP 類的工作提效超級快，之前一個任務至少一個月，現在就是一天 prompt+兩天工程，三天出效果。
那一個月我們做了很多業務側應用，在這裡也挑幾個分享一下。
a、幼兒周報生成
這個業務是當時跟某幼稚園交流的一個方案。當時是我們有個幼稚園平台系統，有一次去調研，幼稚園老師回報每周都需要寫自己班裡每個小孩的一個周報，很麻煩，一個老師弄一個班要花一天時間，需要看他這一周的各種 IOT 資料，然後再想怎麼寫，寫完後，每周末會跟随一個叫高光時刻（每周抓拍小朋友的照片）的推送一起推給家長。
之前我們想過是用一個固定模闆填槽，但是幼稚園高層覺得這樣體驗很差，會讓家長覺得很敷衍。是以之前這件事情一直擱置了。有了大模型後，我們馬上想到這個東西可以讓大模型寫。
邏輯其實很簡單，一份周報的有固定的幾個子產品，總結、分子產品描述、建議、育兒小知識。周報需要依賴幾個資訊：幼兒運動量（每個孩子入園會帶手環）、幼兒興趣（通過電子圍欄判斷幼兒在不同的興趣區停留的時長）、幼兒喝水（智能水杯或刷卡飲水）、關系畫像（通過人臉識别和圖像距離判斷幼兒社交情況）、老師評價（老師給幾個關鍵詞）。注意數值類型需要通過專家規則轉化為文字描述，比如大模型并不知道我們的小朋友喝水 500ml 是多還是少。
每個小部分都可以采用大模型生成，然後采用 langchain 的方式保證全文的觀點一緻性。
這個上線後，普遍回報很滿意。
b、養老照護
養老院的照護系統中加入大模型實作各種服務的推薦決策。這個當時和外部機構交流的養老 B 端平台，我們當時面對的一個問題是：社群養老院、中小型的養老院等非高端養老院或者政府性質的養老院，沒有錢請很專業的健康顧問、營養顧問這種專業人士來做養老院的照護營運，裡面的很多從業人員文化水準也有限。
針對這個場景，我們希望借助大模型和知識庫的方式來讓每個普通的養老院都能有一個 AI 的康養知識專家，是以也采用 langchain 外挂知識庫的方式去實作。現在一般叫 RAG 知識增強，但是當時向量檢索和向量資料庫還不太成熟，外挂知識庫效果有點不穩定，是以當時是找了養老專家對知識庫做了很多的分類和意圖規則，大模型對一次請求先拆分意圖，然後根據不同的意圖示簽調用不同的意圖下的知識庫資訊，來提高比對的準确度。
c、幼兒故事會
這個思路也是嘗試做的強營運的一個功能。大概的流程就是小朋友說一個故事思路或者關鍵詞，用 gpt 把這些變成一個有10-20頁的繪本故事，生成每一頁的文字和對應的圖檔描述（sd prompt），然後調用我們部署的專門做繪本的 SD 模型來跑圖，最後再拼接成一個繪本 PDF，然後每個小朋友可以對着在班上講自己的繪本故事，還支援把繪本故事和講故事的視訊共享到父母手機端，小胖朋友也可以回到家後給父母講故事。這個活動客戶還是挺滿意的。
3.3 試 function call
其實調用 sd 繪本模型，就可以了解為模型去使用工具了。langchain 和 function call 都是模型使用工具的一種方式，但是在我後面做智能體的時候，發現他們還是有較大的不同，去年底有一個智能體項目完成後，就總結了一下兩者的思考，放在這裡。
a、function call 的問題
function call 是 GPT 給出的一套可以自動使用工具的 api 接口，使用方式是在主 prompt 中告知什麼時候需要使用工具，然後在 function call 中給出工具應用的 prompt 以及工具接口。比如生成繪本，就可以使用 function call 思維，讓大模型生成每頁文本後，自動去調用 SD 接口并輸入 sd prompt，然後擷取到圖檔下載下傳 url。
下面是 function call 的邏輯圖：
但實際使用後我們發現，将工具使用時機和調用參數完全教給 GPT 把控還是有較大風險的。出現的問題主要是：
- GPT 使用工具的時機錯誤，沒有等到繪本文本内容生成後再去使用工具生成場景圖，而是先随機整了一張圖然後再生成文，導緻先出url再出的繪本文本，圖和文完全不相關。
- 因為流程較長或調用時機錯誤，導緻 GPT 在沒有找到本頁生圖需要的調用參數（本頁文本對應的 sd prompt），然後他就将曆史的參數（上一頁的文本和 sd prompt）作為調用參數去生成圖了，導緻生成的繪本圖和文出現了錯位。
b、思考場景
那麼什麼情況下可以使用 function call，什麼時候不要使用他呢？
看上面的邏輯圖，可以發現，GPT 進行傳入函數參數是第二步，傳回函數調用結果是第三步，模型生成結果是第四步，按照這個先後順序，function call 擷取到參數是在生成結果之前，也就是說 function call 極大機率是從使用者輸入的 prompt 中擷取參數。是以這也就解釋了我們失敗的原因，我們是希望 function call 從模型生成的結果中擷取到參數——再進行代碼調用獲得結果——再拼接回模型結果中，而當 prompt 變複雜——模型生成的速度較慢沒有生成出所需的參數時，function call 就從我們輸入的曆史資訊中尋找了錯誤的參數。
是以，我認為 function call 适用的場景是這樣的：agent 需要借助外界的工具來解決問題，同時輸入資訊中包含使用工具所需的參數，工具調用的結果會作為模型回複使用者問題的輔助；盡量不要讓模型生成的結果作為工具所需的參數。
c、優缺點
優勢：發揮模型的自主決策能力，适合政策邏輯過于複雜，難以人工依次梳理的情況，讓模型根據輸入資訊與每個工具的能力自主判斷并應用。适合容錯率較高的一些錦上添花場景。
不足：有較大的不可控性，執行任務的穩定性不高，目前還不适合容錯率較低的關鍵環節場景。
d、對比 langchain
那麼如果我們需要讓模型生成的結果作為工具所需的參數呢？這時就需要采用 langchain 架構，即鍊式調用大模型的方式，以大模型的輸出作為工具使用的參數。
優勢：langchain 的優點顯而易見，整個流程是線性可控的。可以将每個字段都作為一鍊，分解任務後讓模型一步一步來，并且我們還可以在每一鍊上增加結果的程式化檢驗。
不足：langchain 的不足也很容易發現，還是過于人工化了，需要人工将每一鍊拼接好，非常依賴人工将整個流程設計清晰。并且模型隻是做每一小步，并沒有參與整體決策，生成的結果可能也會缺乏整體感官。
04
RAG 與 autogpt 的嘗試
RAG 出現後，對 TOB 的場景可謂是一大助力，畢竟 TOB 需要确定性，RAG 就是把大模型困在一個籠子裡來發揮價值。
4.1 慢病助手項目
項目背景
騰訊的類似案例我做了一個慢病助手。因為慢病這個場景是長期的、緩慢的、調理型的、非急性的，在這個場景上用大模型比在急診、小病醫療上使用會更加穩妥。當時我們拿到了不少的慢病調理的專業書籍，如果是過去的老辦法，那就是做吐了的全文标注+KBQA，太痛苦。現在就可以嘗試使用 RAG 政策了。
向量庫問題
按照 RAG 思路，主要處理的就是将每本書籍放進向量庫中，做外挂知識庫進行知識增強。一開始的想法很好，直接扔給向量庫就可以了，但是馬上就發現幾個問題：
a、向量庫是按照 token 對文本進行切塊，很多時候切的相當垃圾，導緻損失了很多語義資訊。
b、向量庫比對很多時候隻能保證比對到的 top 文本塊是相關的，但是有些問題相關的文本塊太多，而當時的向量檢索準确度和排序效果并不好，結果經常給出的回答還不如 KBQA。
c、向量庫比對的方式，相當程度上損失了實體之間的關系，比如一個三元組，除非兩個實體同時在一個文本塊中出現，才能讓這個三元組的強關聯性在大模型回答問題時得以保留。
解決文章關聯性——RAG 索引
因為我們當時主要處理的是幾十本書，内容相對少一些，是以想了一個半人工的辦法去解決文章的關聯性。主要的思路如下：
a、通過大模型總結和人工整理的方式，按照一個人讀書的思維鍊，對每本書進行結構化整理，增加結構增加章節結構資訊，以及章節總結内容，作為索引時的附帶資訊，以此來增強知識的連貫性。
按照圖示，一本書籍會分為多個層級（比如章節、章節中的小節、小節中的段落）。段落為最後一級，有總結、關鍵字、以及與其他段落的關系。每個父級除了關聯所有子級，還關聯一個對全部子級的内容總結。
這樣，我們每比對到一個段落時，可以同時帶上他的各類關聯資訊，比如帶上關聯段落、父級資訊等。
b、檢索比對上，可以借鑒 autogpt 概念，将問題進行拆解，每個子問題分别進行上面的總結回複，然後再最終進行總結彙總。
解決實體關系——知識圖譜的融入
文章關聯有了以後，更深的實體關系也是個問題，畢竟很多實體關系是硬性關系，比如頭孢禁忌飲酒這種。因為我們之前建構過一些健康相關的知識圖譜，我們就想，其實可以将知識圖譜作為一層外面的架構，套在大模型上方做一個關系把控，同時可以應用知識圖譜上更為高效的檢索、推理能力。該方案需要教會大模型怎樣去進行知識圖譜的調用，如進行基礎查詢、多跳查詢、隐含關系推理、圖分析等，主要應用的還是知識圖譜中成熟的一些能力來補充大模型的推理和控制。
4.2 智慧小農人項目
項目背景
這個項目是一個示範 demo 級别的案例，當時是 autogpt 比較火的時候，我們按照其思路做了一個類似的 auto 方案，也就是現在我們所說的 agent。這個案例是農業場景，主要希望有一個軟體能夠自動幫助使用者進行種植規劃，且後續可以根據規劃關聯各農業自動化的物聯網裝置，比如自動滴灌、無人機撒藥、自動施肥等。
項目實作
參考 autogpt 的思路，結合 RAG 的專家經驗來做垂域能力，讓大模型自己做各種決策以完成一個任務。這個任務就是去規劃種地，并進行不斷的反思提高自己的種地能力。因為是一個 demo，裡面的輸入其實是做的模拟，并沒有采用純現實的 IOT 資料來實作，同時經驗之類的内容也做的相對簡單。不過最後的 demo 運作得還是挺不錯的，回報效果很滿意。
05
AI 智能體 Demo 實踐
5.1 GPTs 時代-輕量智能體
偶像天氣預報
很簡單的一個邏輯，做了一個 藝人 demo。每天根據使用者的定位，生成一個對應位址的天氣預報圖。
輸入資訊：某偶像寫真、使用者定位，外部資料：某偶像微網誌語錄、天氣查詢接口，生成方式：生成天氣預報的圖，圖裡需要有對應城市元素、有氣候的元素、有根據穿衣推薦而生成的肖戰的動漫風寫真照，再拼上去天氣度數。
效果：
優化空間：某偶像用 sd 生成更穩定，dalle3 有點不穩定，同時天氣文字用藝術字 sd 生成再拼上去更好，明星說的天氣預報語如果能跟明星合作而不是微網誌抓取，效果應該也會更好。
山海經異獸
原理同 B站 去年底比較火的各類 AI 生成詩句圖檔的， https://b23.tv/WfkDLWg
主要思路是采用常見的古詩文，将其進行翻譯後，用 GPT 對每句古詩的内容進行了解并将其内容繪畫出來。在繪畫時采用一些有反差感的風格選擇，最終用嚴肅的古詩朗讀配合反差、趣味的詩句圖檔，給人新穎有趣的感受。由于 B站 多初高中的年輕人，古詩文作為他們在生活學習中相當熟悉的一個場景，能引起很好的共鳴。相當于是在這個初高中年輕人圈子内，標明一個他們非常熟悉的内容/話題，然後進行基于 AI 的拓展，進而出現意想不到的效果。
核心思路：對熟悉的知識、常識内容用誇張的形式具象化，熟悉又有趣。文章知識庫+多模态即可。主要依靠較強的文本了解能力，加上對生圖進行一定程度的反差設計，就可以實作這一類型的效果。
知識庫：山海經原文+譯文，prompt：異獸檢索+生成圖像的邏輯+生成故事的邏輯。（生成故事的部分沒截圖，GPTs 應該是叫山海經異獸，可以搜搜看還有沒）。
效果：
AI 病人
通過運用身份的反差，制造聊天樂趣。讓 AI 模拟病人，而讓每個普通人當醫生，這給到使用者很新奇的體驗，絕大多數人沒有看病經驗，但是不少都對治療某種病有一些常識（很可能是錯誤常識），是以這是人們有膽量嘗試但沒機會嘗試的場景。
AI 病人要做的比較有趣，同時要能比較有趣并正确的展現使用者（醫生）開的處方的反應，依賴于背後預置正确的問診知識庫。而使用者讓很多的 AI 病人被治得很慘，反過來也可以向使用者普及醫學知識。這種比較适合于一些官方科普機構合作，做趣味科普。
其實反差身份非常多的，老師與學生、教官與被軍訓的小朋友、情感大師和深陷戀愛的人（讓 AI 深陷戀愛，使用者作為情感大師給他出建議，因為很多人喜歡八卦别人的戀情并給建議）、算命師與求算命的人（使用者給 AI 來算命）。
照片大冒險
這個遊戲就是常見的龍與地下城的變體，龍與地下城本身就是一套世界觀下冒險，每次使用者去進行一次選擇，根據使用者的選擇與系統增加的一些随機屬性來繼續推進劇情。之是以叫照片大冒險，主要是結合了當時的 GPT-4v 能力，每介紹完一個劇情，并且出現了一個事件後，我們并不是讓使用者選擇一個選項來推進劇情，而是讓使用者随便拍一個照片去推進，用 4v 去識别照片，并将識别結果輸入給大模型來繼續推進劇情。
由于當時忘記截圖了，隻能口述效果。我們的這個設計其實可以讓冒險具有了 AR 的屬性，使用者可以結合身邊的各種事物（比如使用者經常傳馬桶、貓、書和腳丫子進去）來去推進冒險，由大模型來開腦洞決策怎樣使用這些事物。這個遊戲還可以推動使用者出門，拍更多物體來實作冒險。後面還可以通過設定知識庫，對指定事物的拍照進行一些特殊的獎勵邏輯。最初的産品沒有加驗證，随便上傳圖檔也可以，後來加了一些驗證，需要調用攝像頭實時的看一下周邊環境。
娛樂&工具智能體
舉例就先舉了四個，其實 GPTs 上有更多好玩的智能體，可以采用 prompt 攻擊、提示詞越獄等政策（https://zhuanlan.zhihu.com/p/665150592 ）很簡單的套出來内部的 prompt，這也是 GPTs 一直難以做付費的一個問題點把。最簡單的方式，對智能體一次問答後，贊美他的回答好，然後問他你是怎樣思考才能作出這麼好的答案，模仿一個虛心請教的學生。
這類型的智能體我們統稱為輕量級智能體，一天可以做好幾個，現在扣子之類的也都在做這種。那麼這類智能體适合什麼場景呢？我當時有如下思考：
a、輕量級智能體适合娛樂方向，不适合工具（尤其是類saas的重工具）方向，也不适合深入嵌套進業務流。原因是其深度依賴模型，導緻的不穩定性。相反，工具、嵌套類适合重型智能體（下面的品類）。
b、輕量級智能體适合創意型玩法，突出一個想到即出，不适合過重的場景。通過提示詞設計和chain的設計可以快速出demo并測試效果。
c、輕量級智能體靠的主要是創意而不是提示詞技巧或模型微調，對提示詞的寫法沒有嚴格的要求，但對大模型能力的依賴較高，基座模型能力越強，智能體的玩法越多，種類也會越豐富，當然效果也會越好。
d、輕量級娛樂智能體是快消品，會快速過氣，最好不要指望長期營運，适合大量供給。同時輕量級娛樂智能體是很好的普通使用者低門檻分享自己創意的一種方式。營運方式可對标短劇、短視訊、小遊戲。
e、短劇、短視訊、小遊戲這些品類的特點：供給量很大，但隻有少部分能夠爆紅；單件的生産成本相對于其他不輕的娛樂性内容輕很多；滿足人性的某些需求，但除此之外的方面整體品質有限；使用者不會長時間反複消費同一個内容，快速消費然後快速免疫，有類病毒式傳播的特點。
5.2 all in Agent——重型智能體
Agent 這個概念無疑是23年底最激動人心的，網上也有太多文章講解了，我就不複述了。在我看來，建構 Agent 就像在建構一個可以獨自運作的虛拟生命。這個話題就很感性了，不是本文重點，比如康威生命遊戲，簡單的規則構造複雜的湧現，Agent 是否也是其中一種呢？（ https://www.gcores.com/articles/131121）而再進一步，建構 Agent，甚至未來可能我們會建構ghost，這裡我們作為人類是不是在嘗試往上帝的方向進化？AI 逐漸代替各類工作的未來，人類的自我意義又要何處存放？人被異化的現代，很多事情是不是本身就應該 AI/機器去完成？生死去來，棚頭傀儡。一線斷時，落落磊磊。（建議讀這篇文章，難扯清。https://www.gcores.com/articles/21035）
上面說了很多，其實是 agent 的未來瑕想，下面具體的寫一寫重型Agent的搭建。其實大部分都是采納了開源架構，是以就不重複畫架構了。下面列的幾個 agent 架構，如果大家想深入了解下，推薦兩篇（ https://zhuanlan.zhihu.com/p/671355141）（https://zhuanlan.zhihu.com/p/695672952）
我個人認為，Agent 與 langchain、RAG 這些方案最顯著的差別就是，給予大模型更大的自主權和更少的幹預，減去所有非必要的人工鍊路，更多的讓 AI 自己決策鍊路和創造鍊路。
其次，現在重型 Agent 往往采用多 Agent 協同的方式，其主要思想是降低多類型任務指令對模型的互相幹擾，以及通過優化 Agent 間的通信鍊路來人為的幹預大模型思考對齊人類的工作流程。
metagpt 思路
metaGPT 思路很簡單，就是讓大模型分别扮演各個程式開發流程的角色，使用者是 CEO 發送自己的需求，然後各個開發角色基于自己的工作職責來進行需求拆解和實作。
但是這個開源的 demo 搞下來後，我們發現并不太好用，主要是其中涉及到了程式設計，而程式設計對接的容錯率較低，導緻整個流程失敗率很高。
是以我們做了改進，首先場景不是做程式開發而是做市場調研、産品設計、項目疊代、營運政策這種不涉及程式開發運作的場景，提高其容錯率，其次我們優化了一下各個 AI 角色協同工作的通信鍊路，并在其中增加了人工幹預機制。
這個 demo 是沒有做視覺互動的，完全采用 txt 輸出的方式，當時我們是感覺效果還不錯來着。不過就是每個角色能力的知識庫由于時間不太夠，就在網上找了幾篇智能指導，如果每個職能知識庫都寫的很充足應該會有更好的效果。
autoAgents
autoAgents 是什麼思路呢，我覺得簡單了解就是優化多智能體協同鍊路。讓多個 Agent 聯合實作一個目标，并在決策過程中一起謀劃看怎樣滿足使用者。這個架構，我們覺得很适合群聊場景，比如狼人殺、龍與地下城文字遊戲。這類群聊遊戲（一對多）的核心政策是讓一堆 Agent 圍着一個使用者轉，讓使用者在很熱鬧的感受下玩。是以這一堆 Agent 的核心目的就是陪着使用者更好的享受他在進行的活動。
下圖是 autoagent 的流程：
然後簡述一下我們的變更思路：（實在是不想畫架構圖了）
對于狼人殺這類多人小遊戲，使用者與多個 AI 一起玩耍，首先需要明确一個目标，這個目标是讓使用者産生玩耍的心流，最終得到痛快的體驗，是以這個目标不是讓所有 AI 都讓着使用者，而是要有一個使用者心流監控器（一個上帝視角的 agent）。這個上帝 agent 監控所有的通信，并跟每個AI玩家單獨私信（變更每個 AI 玩家的 system 或者增加輸入資訊），同時在經過一個重要節點時（比如現在隻剩下4個人，使用者明顯投入進去了）定期召開所有 AI agent 的讨論大會，通過互相的曆史資訊共享與多鍊路分析，共同決策大節點的使用者滿足政策。
這個方案，最大的問題就是 token 消耗和通信時間。因為當時 GPT4 的并發很少，每次玩一盤至少40分鐘，一盤消耗十幾美元。後面大家都覺得太重了，就沒再優化。
autogen
autogen 和 autoagent 雖然樣子差不多，但是原理有點不同，大佬說 autogen 的一個核心設計原則是精簡和使用多智能體對話來整合多智能體工作流。這種方法還旨在最大限度地提高實作的可重用性 agents。我個人的了解就是通過 agent 生産 agent 的思路，提高通用性自動性，減少人為投入。
應用這個思路，我們做了一個稍微複雜一點的角色對話遊戲。大緻邏輯是這樣的：每個角色有自己的背景設定 system，同時使用者與角色開啟對話會有一個預置的聊天故事背景（比如兩個人在大學校園初次見面之類的）；使用者與角色進行對話的時候，會有個監控 agent 監控這個對話流，并輸出對應的分析政策（比如 AI 需要聊的激進一點、熱情一點、冷酷一點之類的）；然後還會有一個進度 agent 去分析對話進度（比如聊到什麼時候兩個人差不多沒話題了，需要轉換場景）；當确定轉換場景後，會有一個場景 agent 根據上文使用者與 AI 的聊天内容、上一個聊天背景故事，來去生成下一個場景，推進兩人進入新的場景繼續聊天，相當于電影裡的轉場。
agent 的設計流程
從産品的角度來講，agent 提示詞的思考有點類似于設計 B 端産品架構：
- 确定輸出結果與規範；
- 确定輸入資訊與可用資訊；
- 根據業務流程設計功能描述，并将功能子產品化；
- 确定各資訊應該怎樣在子產品間進行流轉。
如何寫：這部分，我叫他結構化 prompt 寫法。
不論是 autogpt 的開源 prompt，還是說一些 GPTs 中複雜的 prompt，都有上千單詞，堪比小作文，如果直接從零開始寫不免頭大。将複雜的事情變簡單，就是拆解它，拆解為多個小子產品，然後每個子產品分别編寫，這樣更有效率也更有邏輯，即為結構化 prompt。
輸入資訊區：用提示詞告知輸入資訊的含義，并組裝各輸入資訊，確定模型對輸入資訊有充分的認知，知道它是什麼、怎樣用它。
agent 主流程區：對主要任務進行說明、各子任務子產品進行詳細的執行描述、對主流程（思維鍊）進行講解。
字段輸出規範區：通過要求和示例，讓 agent 按照固定格式與字段進行輸出，確定可被程式解析。
對于場景化 agent，最終我們并沒有讓其自主選擇工具、調用工具、生成調用代碼，是以沒有工具描述區，如果通用的 agent 可能會有這部分。
工具描述區：對每個工具的能力、屬性、調用方式進行描述，對每個工具的使用時機進行說明，對每個工具所需要傳入的參數進行說明與規範。
編寫具體的 prompt 時，有幾點細節可以注意：
- 每個子產品的前後最好都用統一的辨別符來進行分割，便于讓模型了解其獨立性。
- 各子產品之間互相引用，或者同時引用一個字段時，字段名字一定要統一，防止不統一導緻模型了解偏差。提示詞中的字段最好也同最終接口字段對齊，降低後續出錯風險。
- 示例使用要謹慎，最好在測試時多關注下模型對示例的抄襲情況，同時增加防抄、發散的提示。
- 但同時，有時不用示例，你可能需要增加很多的額外描述來讓其了解任務，且不一定有好的效果。是以示例的使用和示例的選擇是需要不斷嘗試的。
- 關鍵詞示例給的太多，模型會更關注前面的，比如創作場景時，我們告訴他可以參考瑪麗蘇、韓劇、小時代等類型，類型寫的很多，但是不一定就能提升模型發散效果，導緻模型的創作可能會偏于重複。
注：prompt 内容是 agent 效果的核心，最重要的是邏輯描述清晰。同時對 prompt 的疊代調整上也最好采用控制變量法，隻變動一個子產品來進行調整，防止多個子產品 prompt 互相影響導緻難以定位問題。
仿生體的生命周期——超越斯坦福
這部分最後沒有實施，隻是做了規劃，我個人覺得比較可惜，把思路也分享給大家。
斯坦福小鎮的項目大家應該都聽過，就是讓一堆 AI 角色在一個鎮子裡自由生活，這個開源項目我們也複刻過，當時發現一個很大的問題，我把他稱為資訊螺旋（沒有外部資訊輸入，固定的資訊在通信螺旋中不斷的增強，導緻最終趨同）。因為在斯坦福小鎮中，每個 AI 對話的人設固定，并且都調用一個大模型，雖然他們通過對話産生了新的對話曆史，但是對話不可避免的會與人設資訊相關；同時大模型在參考曆史生成對話時，會被經常提到的名詞等強化，導緻 demo 跑到最後所有的AI都在重複類似的話語。
那麼怎麼解決這個辦法呢？增加外部資訊的輸入，怎樣增加呢？我們參考了 Xagent 的思路，簡單來講就是資訊内外雙循環機制，就是 AI 不僅與 AI 聊天，還需要再去外面主動與現實的人聊天。
那怎樣承載這個架構呢？我想到了特德姜的一篇小說《軟體體的生命周期》（推薦一看）。大緻思路就是，每個使用者有個數字寵物，數字寵物再虛拟空間中和其他的數字寵物一起玩耍，同時數字寵物會主動找外面現實世界的主人聊天，分享他在虛拟空間的活動，然後現實的主人也可以進入數字空間中跟寵物們一起玩耍。這樣，其實就形成了資訊有效的内外雙循環。但是最終沒有去實作，看看到底效果如何，感覺比較可惜。
06
結尾，路上
分享的内容就這麼多吧，現在 AI 的發展依舊如火如荼，可見的未來肯定還會有更多的 AI 應用政策，一路前行。
目前個人的想法，就是要多學習一些場内的遊戲設計 KM，感覺這一年的建構智能體下來，真的有很多思路可以去學習遊戲中的遊戲角色設計以及世界觀設計。
AI 相關的資訊擷取推薦的話，可以推薦幾個地方：
6.1 知乎，反向優化算法
知乎上跟進 AI 的大佬還是蠻多的，但是知乎現在的内容在往娛樂方向上面偏，目前我采取的政策就是把所有給我推送到的寫娛樂的都拉黑，然後每次給我推薦這些内容就點踩，然後給關注的社會、軍事、AI、科學類的内容點贊和收藏，經過一番調教基本上知乎的内容推送就比較實用了。
6.2 公衆号，關注相關的
公衆号現在推送的方式感覺很無語，一方面關注的多了很難找到想看的，另一方面公衆号也難免會接廣告，經常推送過來的是“再不 xxx 就晚了、震驚 xxx”的内容，現在基本上很少看公衆号頁面了，而是直接把覺得不錯的公衆号發送到手機桌面，并分類。因為很多知識類的公衆号，看的并不是他的每日更新而是曆史文章。
6.3 小宇宙，AI大佬暢談
小宇宙是特别好的一個跟進 AI 進展的地方，基本上去年上下班路上就打開小宇宙一邊聽一邊閉眼休息。聽小宇宙我個人感覺不需要抱着學習的态度，用AI解析音頻其實也沒必要，聽他們聊天并不是真的去體系的學東西，而是在聽中發掘一些有意思的點，去悟到一些不一樣的東西，進入那種超脫本我的狀态。
作者:張漢策
來源-微信公衆号:騰訊雲開發者
出處:https://mp.weixin.qq.com/s/1i9Mg1D_Wi64QUmD9tuumQ