[0:00]AI圈子裡每天都在冒新名詞,LLM,Token,Context,Prompt,Tool,MCP,Agent,Agent Skill. 這些詞你可能都聽說過,但是我問大家,你真的能準確的說出其中每一個概念的確切含義嗎? 這期視頻,我們不著那些虛頭巴腦的商業概念,我們就從最底層的工程視角出發,一個一個的把這些概念拆開,揉碎,講清楚。 看完這期視頻,相信你對AI的理解絕對會上升一個台階。 我們先從最底層的東西開始,一層一層的往上搭,最底層的,就是LLM。
[0:34]LLM全稱是Large Language Model,翻譯成中文就是大語言模型,簡稱大模型。 基本上現在所有的大模型都是基於Transformer這套架構訓練出來的。 這個架構看起來很複雜,不過不用擔心,這張圖你現在看不懂是完全正常的。 我們今天呢,也不打算研究它,你只需要知道,大模型的底層引擎就是它。 Transformer架構最早其實是由Google團隊在2017年的時候提出來的。 對應的論文名是叫做Attention is all you need。 很有戲劇性的是,雖然Google發明了火種,但真正把它點燃,並且引爆全世界的卻是OpenAI。 大家應該都記得2022年底,GPT3.5橫空出世,它應該算是第一個真正達到可用級別的大模型了。 相信當時用過的人都能感受到它的強大,但它還沒完。 僅僅幾個月之後,在2023年的3月份,GPT4發布,它呢是直接把AI的能力天花板拉到了一個新的高度。 可以說GPT系列就是我們今天AI浪潮的絕對鼻祖了。 甚至時至今日,GPT家族依然非常強大,比如現在的GPT5.4就是業界的標杆之一。 不過如今的AI賽道早已經不再是OpenAI的獨角戲了,像Cloud,Gemini等優秀的後期之秀,都在各自擅長的領域與它同台競技。 好,前面我們說了大模型的搭置由來,那大模型到底是怎麼工作的呢? 其實非常的樸素,它本質上呢就是一個文字接龍遊戲。 我們來看一個具體的例子,假設你向大模型提問,馬克的視頻怎麼樣? 模型接收到這句話之後,經過內部的一通運算,它會預測下一個概率最高的詞,比如特別。 關鍵點來了,模型吐出特別這個詞之後,它並不會停下來,它會把這個剛吐出來的特別這個詞抓回來, 追加到你剛才的那個輸入的後面,然後它拿著這個新的輸入,再去預測下一個字,比如說是德。 接著它再把德塞回去,然後再預測下一個詞,比如說是棒,然後呢,它會把棒這個字也塞回到輸入裡面。 這個時候大模型會發現它要說的話已經全部說完了,此時它就會輸出一個特殊的結束標識符。 整個回到這裡就算是徹底結束了,這樣我們就拿到了大模型的完整回答,特別的棒。 這是大模型最底層的生產原理了,理解了這一點,你就明白了為什麼大模型要一個詞一個詞的輸出答案,因為它就是這麼運作的。 好,我們剛才說了用戶提交問題給大模型之後,大模型每次都會吐出一個詞。 但其實這是為了方便你理解而簡化的一個理論。 現實情況是這樣的,大模型本質上是一個龐大的數學函數,裡面跑的全是矩陣運算。 它接收的呢是數字,輸出的也是數字,壓根就不認識人類寫的文字。 所以呢在人類和大模型之間必須有一個中間人來做翻譯,這個中間人呢就叫做Tokenizer,它負責的是編碼和解碼兩件事情。 編碼就是把文字變成數字,解碼反過來是把數字還原成文字。 還是拿剛才的那個例子來說,用戶提問,馬克的視頻怎麼樣? 這句話呢會先交給Tokenizer處理,它要把這些文字轉換成數字,這個呢就是編碼環節在發揮作用了。 我們來把編碼的過程拆開來仔細看一下,搞清楚它究竟是怎麼把文字變成數字的。 這個過程分兩步驟,第一步,切分,它把用戶的問題接過來,把它拆成一個一個最小的片段,這些片段呢就叫做Token。 我們這裡呢一共是切出了四個Token,第二步,映射,由於模型只認數字, Tokenizer呢就會把每一個Token對應到一個數字上去,這個數字呢就叫做Token ID。 Token ID和Token是一對一綁定的,Token是文字,Token ID是數字,這兩個呢,其實本質上是一個意思,只不過是換了種表達方式而已。 經過了這兩步,原來的一句話就變成了一串Token ID組成的列表,然後Tokenizer會把這串列表送進模型。 模型在內部一頓運算,最終吐出了一個Token ID,這個時候Tokenizer再次出場,把這個Token ID翻譯回Token。 這個呢就是解碼環節的工作了,解碼只有一步,那就是映射,方向呢是跟編碼反過來,把數字轉換成文字。 要注意的是解碼環節是不需要切分的,因為模型每次只會給出一個Token,並沒有什麼好切分的。 解碼完成後,我們就拿到了大模型輸出的第一個Token,特別,如果模型的話還沒有說完,就繼續吐第二個,第三個Token,後面的流程呢,其實都是一樣的,這裡就不再重複了。 所以你看到了嗎?Token才是大模型處理文本的最基本單位。 大模型一個Token一個Token的接收輸入,然後再一個Token一個Token的輸出結果。 現在我們回頭看剛才的那個例子,馬克的視頻怎麼樣? 它呢是被切分成了四個Token,馬克,德,視頻和怎麼樣。 你有沒有注意到,這裡每個Token好像都正好對應一個詞啊。 所以你可能會想,Token就是詞,對吧?但其實不一定。 Token和詞呢,並不是一對一的關係,剛才那個例子只是恰好而已。 我們換幾個例子你就明白了,比如說我的頻道呢是叫做馬克的技術工作坊。 如果按照詞的標準來劃分的話,那應該是有四個Token,分別是叫做馬克,德,技術和工作坊。 那真的是這樣嗎?OpenAI提供了一個把文本轉換為Token的頁面,我們不妨去試一下。 首先粘貼上我們要切分的文本,也就是馬克的技術工作坊。 你看,它把我頻道名轉換成了五個Token,其中每個顏色代表一個Token。 這裡還能看到對應的Token ID。 這裡要注意了,OpenAI把工作坊拆成了兩個Token,工作和坊分別代表一個Token。 這跟我們預想的不一樣,在我們的預想中,工作坊應該是一個詞,那它應該正好對應一個Token才對。 不過呢,實際上它會被拆成兩個Token。 當然,你也會說,工作坊是不是也不能算作一個詞啊。 好,那我們再看一個更明顯的例子,程序員,這一總算是一個完整的詞了吧。 但在Tokenizer裡面,它被切成了兩個Token,程序和原。 這個呢是中文的情況,那英文呢,一個英文單詞對應一個Token嗎? 對於常見單詞確實是這樣的,比如hello是一個Token。 going也是一個Token,不過這個呢也不是鐵律,比如helpful這個單詞就被拆成了兩個Token,help和for,甚至在某些情況下,一個字符會被切分成多個Token來用。 比如對勾這個字符就需要三個Token來表示它,不過這三個Token沒有對應的顯示字符,所以在這裡面顯示的就是問號了。 這種情況下,看Token ID可能還更直觀一些,你看確實是三個。 所以我們總結一下,詞和Token並沒有什麼明確的一對一的關係,你可以把Token理解成模型自己學會的一套文本切分規則, 切出來的每一塊就是它一次能夠處理的最小單位,平均來講,一個Token大概是等於0.75個英文單詞, 或者是一點五到兩個漢字,比如40萬個Token大概呢就是60到80萬個漢字或者是30萬個英文單詞。 如果你對Token的切分原理感興趣,想詳細了解下Token到底是怎麼生成出來的,可以看一下我的這個視頻,它詳細講述了如何使用BPE算法來訓練和使用Tokenizer。 好,我們剛才講了Token,知道了它是大模型處理文本的基本單位,下面我們來看一件你可能一直覺得理所當然,但其實很值得想一想的事情。 我們平時和大模型聊天,它好像能記住之前說的話,比如說你開頭告訴它,我叫馬克, 它給你回复了以後,你再問它我叫什麼,它還是能夠回答得出來,但問題是大模型本質上只是一個數學函數, 你給它輸入,它就給你輸出,它不像人一樣真的有記憶,那它是怎麼記住之前的聊天內容的呢? 答案就是我們每次給大模型發送消息的時候,並不只會發我們的問題。 背後的程序會自動把你之前的整段對話歷史找出來一起發過去,這樣的話呢,有了用戶問題,有了對話歷史, 模型每次看到的就是完整的對話內容了,所以它才能夠知道之前發生了些什麼。 這就引出了Context這個概念,中文呢是叫做上下文,它代表大模型每次處理任務時所接收到的信息總和。 我們剛才聊到用戶問題和對話歷史都是大模型所接收到的消息,所以呢它們都是Context的一部分。 除了它們之外,Context裡面還有很多其他的內容,比如說大模型正在輸出的每一個Token也會被追加進來。 除此之外呢,這裡面還會有工具列表,System Prompt等信息,這些概念呢,我們後面會一個一個的講到,你暫且不用關心。 現在你只需要記住一件事情,Context呢就是大模型每次處理任務時所接收到的信息總合。 從某種程度上,我們也可以把它看成是大模型的一個臨時記憶體,理解了Context,下一個問題就自然而然的出來了。 這個Context能有多大,它能塞多少Token呢?這個呢就引出了Context Window這個概念。 翻譯過來呢,就叫做上下文窗口,它呢就代表了Context能夠容納的最大Token數量。 舉個例子,Context Window為1萬,就代表模型最多能夠處理1萬個Token。 不過1萬的Context Window算是很小的了,目前主流的大模型都有著非常大的Context Window。 比如說GPT5.4的Context Window是105萬,Gemini3.1 Pro的Context Window是100萬,Claude Opus4.6的Context Window是100萬。 我們之前說過,一個Token大概是等於1.5個漢字,那麼100萬個Token呢,差不多就是150萬個漢字了,那整個哈利波特全集的內容都能裝下。 算是很大的了,好,相信大家對Context已經有一個初步的了解了,下面我來問大家一個問題。 假如你有一個上千頁的公司產品手冊,你希望大模型根據這個產品手冊來回答用戶的各種疑問,那這要怎麼實現呢? 你要把這個手冊的全部內容跟著用戶問題一起扔給大模型嗎?這其實不是一個很好的解決方案,因為這個產品手冊太長了, 即使模型的Context Window不會被撐爆,你的成本也無法控制,那這該怎麼辦呢? 這就需要一個叫做Rag的技術了,它可以從產品手冊中抽取用戶問題最為匹配的幾個片段,然後只把這幾個片段發給大模型, 讓大模型只根據這幾個片段來回答用戶的問題,這樣大模型接到的就不是一整本書了,可能只是幾段話。 這樣就不受Context Window大小限制了,成本也會低很多,如果你對Rag技術感興趣,想深入了解下它的實現原理的話, 歡迎看一下我的這個視頻。
[12:45]Prompt中文為提示詞,它是大模型接收的具體問題或指令。 比如說你向大模型提需求,幫我寫一首詩,這句話呢就是Prompt。 對,不要把Prompt想成特別複雜高端的東西,它只不過就是給大模型的一個問題或者是指令而已。 接到了這個輸入之後,大模型才會開始運轉,然後呢才會給你一個對應答案,但這裡面會有個問題。 如果你只是簡單的說幫我寫一首詩,大模型可能會給你寫故事,就像屏幕上給你展示的這樣,但也可能會給你寫現代詩, 甚至可能來一手打油詩,為什麼呢?因為你的Prompt太模糊了,它不知道你具體想要什麼。 所以Prompt怎麼寫直接決定了大模型的輸出質量,一個好的Prompt應該是清晰的,具體的,明確的。 比如說你可以這樣寫,請幫我寫一首五言絕句,主題是秋天的落葉,風格要悲涼一點。 這樣一來,大模型就清楚多了,它生成的內容也就更符合你的預期,這就是為什麼有個專門的領域叫做Prompt Engineering,也就是提示詞工程。 說白了,就是研究怎麼把話說清楚,讓大模型更精準的理解你的意圖。 當然,這個領域雖然曾經比較火,但現在還在提它的人其實寥寥無幾,一方面是因為門檻太低,本質上就是把話說清楚嘛。 另一方面呢是大模型的能力越來越強了,即使提示詞含糊不清,大模型也能大致猜出你的意圖來,這種情況下也就不需要再提示詞上花太多功夫了。 好,到這裡,Prompt基本概念應該是搞清楚了,但是事情還沒有完。 你有沒有想過一個問題,有些時候我們不僅要告訴大模型它要處理的具體任務, 還要告訴他人設和做事規則,也就是告訴大模型它是誰,它應該按照什麼規則做事。 所以呢,這就引出了兩種不同的Prompt,說明具體任務的是User Prompt,中文為用戶提示詞,它是用戶自己輸入的。 說明人設和做事規則的是System Prompt,中文為系統提示詞,它是開發者在後台配置的。 讓我們來用一個具體的例子解釋這兩個概念,假設你要做一個數學輔導機器人, 你希望它不要直接告訴學生答案,而是要引導學生思考,這時候呢你需要兩種Prompt。 第一種呢是System Prompt,你在後台這樣設置,你是一位耐心的數學老師。 當學生問你數學問題時,不要直接給出答案,而是要一步一步引導學生思考,幫助他們理解解題思路。 注意,這句話是你作為開發者在後台設置的,用戶根本看不到,但它會一直影響大模型的行為。 然後學生在對話框裡輸入,3加5等於幾,這就是第二種User Prompt。 用戶在對話框裡直接輸入的問題,大模型看到這兩個Prompt之後,它會這樣想,我的角色是數學老師, 我要引導學生思考,不能直接說答案,好,那我就這樣回答,我們可以這樣想,你手裡有三個蘋果,然後又拿了五個, 現在一共有多少個呢,你可以數一數看,看到了嗎?如果沒有System Prompt,大模型可能就直接說八了。 但因為有了System Prompt約束,它知道自己要扮演一個引導式的老師,所以回答就完全不一樣了。 相信你現在可以理解User Prompt和System Prompt的區別了,有了他們的配合, 大模型既能手住規矩,又能能夠完成你的具體需求,好,Prompt呢,我們就講到這裡了。 我們再來下個概念Tool。 我們再來談一下大模型的一個弱點,它無法感知外界環境,我來舉個例子,假設你問大模型, 今天上海的天氣怎麼樣?它可能會說,抱歉,我無法獲取實時天氣信息,我的知識庫截止到2025年10月, 無法提供當前的天氣數據,為什麼呢?因為大模型只是個文字接龍遊戲,它的能力是根據訓練數據來預測下一個詞, 但它真的沒辦法去查天氣預報網站拿到實時的天氣數據,這該怎麼辦呢?這就需要Tool了。 Tool翻譯成中文就是工具,工具這個詞不太好理解,我們再換一個詞,函數。 對,沒錯,Tool本質上呢就是一個函數,你給它輸入,它就給你輸出,比如說一個天氣查詢工具,它的輸入呢可能包含兩個參數, 分別是城市和日期,傳入後它內部一通操作,比如說它可能會去調用氣象局的接口, 但不管怎麼樣,最後它都會給你一個輸出,告訴你對應的天氣信息,有了它,大模型就可以回答天氣相關的問題了。 讓我們來看一下從用戶提問到大模型回答的完整流程,整個流程所涉及到角色呢是包括用戶,大模型,天氣查詢工具,還有平台。 你可能會問平台是什麼,你可以把平台理解為一個傳話筒,因為用戶大模型天氣查詢工具這三個角色沒辦法直接對話, 所以呢我們就需要平台這個角色來做傳遞信息的工作,它本質上呢就是一段代碼用來負責上傳下達。 你可能還有點懵,沒事,現在不明白也沒關係,你看完流程就懂了,在流程一開始的時候, 用戶的問題會首先發給平台,平台會把用戶的問題轉發給大模型,不過發給大模型的,可不只有用戶問題, 還有目前可用的工具列表,比如說是天氣查詢工具,計算器工具等等,大模型收到這個問題之後,它會自己分析, 用戶想知道天氣,而我沒有實時的天氣數據,但是這裡面有一個天氣查詢工具可以用,好,那我就調用這個工具。 注意,大模型無法自己調用工具,它唯一的能力就是輸出文本,如果它想調用某個工具的話,它就只能藉助平台的力量。 所以此時大模型會生成一個調用天氣查詢工具的指令,大概就是這樣子的。 這個指令標識了要用的工具名稱和對應的參數,它呢會發到平台那邊去。 平台接收到這個指令之後,就會真的調用這個工具,其實也就是調用了工具背後所對應的一個函數。 調用結束之後,平台會拿到對應的天氣信息,大概呢是這個樣子的。 在平台拿到了工具的調用結果之後,它就會把這個信息返回給大模型,大模型拿到這個結果後,會把它整理成一句人話輸出給平台, 比如說是什麼今天上海的天氣不錯,晴天,溫度在15度到25度之間,諸如此類的。 然後呢平台會繼而把這句話轉發給用戶,這樣用戶就可以看到結果了。 可以看到在這個過程中,每個角色都有著自己的職責,其中大模型的職責呢是有兩個。 第一個是選擇工具,具體來說就是選擇需要調用的工具,並生成對應的工具參數。 第二個是歸納總結,也就是在拿到工具的執行結果之後,模型需要對工具的結果做一個歸納總結。 工具的職責呢,則是完成查詢天氣這個動作,而剩下的一個角色,平台,它負責處理的就是串聯整個流程了。 比如說告訴模型哪些工具可用,根據模型的工具調用指令來調用工具等等。 所以呢,大家要分清楚每個角色在幹什麼,有人可能以為調用工具的是模型。 尤其是初學者很容易就會這麼想,但是模型能做的呢,僅僅是輸出一小段文本,告訴平台它想要調用哪個工具, 調用工具這個事情最終還是要用平台來完成,所以最後總結一下,Tool的本質呢就是給大模型提供一套它可以用到的外部能力, 讓大模型能夠感知和影響外部環境,好,Tool的概念呢就到這裡了。 我們來講下一個概念MCP。 剛才我們講了使用工具的全流程,但這裡面有個工程上的大問題,看這兩部分。 第一,平台要把工具列表傳給模型,第二,還要能調用工具,要做的這些,我們首先就得把工具接入到平台裡面去。 這樣平台才知道可用工具列表,以及每個工具的用途,參數和調用方法等等。 那問題來了,這套接入的規範每個平台都不一樣,如果你用的是Chat GPT,你得按照OpenAI的接入規範寫一套接入代碼。 如果你用的是Claude,你得按照Anthropic的規範再寫一套接入代碼,如果你用的是Gemini,你得按照Google的規範再寫一套。 看出問題了嗎?同一個工具你要寫三遍,因為每個平台的接入標準都不一樣。 所以呢AI圈子裡就有人想,能不能搞一個統一的標準呢?讓所有的平台都遵循這個標準,這樣工具的開發者只需要寫一次代碼就可以在所有的平台上使用了。 這個呢就是MCP的由來了,MCP就是這個統一的接入規範。 MCP的全稱呢是叫做Model Context Protocol,翻譯過來是叫做模型上下文協議。 這個名字起的有點學術,不太好理解,你就把它理解成一套統一的工具接入標準就好了。 有了MCP之後,工具的開發者只需要按照MCP的規範開發一次工具,這個工具就可以被所有支持MCP的平台使用。 這就像是所有的手機都有Type-C接口一樣,有了統一的標準,大家都會方便很多。 那這個就是MCP的由來和作用了,如果你想更深入的了解MCP協議的內容的話,可以看一下我之前出過的MCP終極指南系列,分三期, 從使用到原理,把MCP協議扒了個底朝天,相信看完之後呢,你會對MCP有一個非常全面的理解。 我們現在知道Agent能夠自主規劃,調用工具,持續工作直到完成任務了,聽起來已經很厲害了,對吧? 但在實際的高頻使用中,你馬上就會遇到一個新的痛點,舉個例子,假設你希望大模型成為你的出門小助手, 每次出門前幫你掃一眼天氣,並提醒你帶東西,你肯定有一套自己的出門習慣,比如說下雨帶傘, 光照強帶帽子,空氣差戴口罩,風大穿防風外套,無論如何呢,手機必帶。 不僅如此,你可能還是個強迫症,希望它的回答不要太囉嗦,必須按照特定的格式來輸出。 比如說先來一句總結,然後呢再列出帶原因的物品清單,在沒有額外設置的情況下,假定你只問一句, 我馬上要出門,該帶些什麼?Agent的回答會查天氣,但它不知道你的這些私人規則和格式要求。 大概率呢會給你一堆廢話,它不能按照你的出門習慣來判斷要帶的東西,最終的輸出格式也無法滿足你的要求,畢竟它都不知道嘛。 為了拿到讓你滿意的結果,你每次提問的時候呢,就不得不帶上一大串尾巴,把你的所有的規則, 所有的格式要求甚至勢力全部都複製粘貼到Prompt裡面發給它,試想一下,每次出門都要敲這麼一大串串要求,是不是太煩人類了? 別擔心,這個時候就該Agent Skill登場了,Agent Skill本質上就是你提前寫好,塞給Agent的一份說明文檔。 比如說剛才的那個出門的場景,我們就可以寫成這樣的一個Agent Skill。 可以看出它本質上呢就是一個markdown文檔,它的整體結構可以分成兩部分。 上面的這一部分呢是叫做原數據層,它相當於這本說明文檔的封面,告訴Agent這個技能叫什麼,是負責做什麼事情的。 這一部分呢,至少要有兩個屬性,分別是name和description,name代表這個Agent Skill的名字,比如我們的Agent Skill名稱是叫做go out checklist,也就是出門清單的英文。 剩下的description呢就是描述了,然後下面的這一段從目標開始,到這個說明文檔的結束,這一大片都叫做指令層。 這一層的格式不做具體要求,只要能把事情向Agent說明白就行,格式自己來定。 比如說我這裡就寫了要完成的目標,執行步驟,判斷規則,輸出格式以及勢力。 比如說我們在執行步驟裡面就告訴Agent需要先調用定位工具,獲取經緯度,然後呢再調用天氣工具,獲取天氣信息。 拿到天氣信息之後呢,需要根據天氣的數據結果,按照下方的判斷規則整理出門所需攜帶的物品,判斷規則呢就寫在這裡面。 最後呢是需要嚴格按照下方的輸出格式,向用戶輸出最終的結果,輸出格式呢我們就寫在這裡,一共是需要輸出兩段話。 在指令層的最後,我們還給了它一個勢力,在這個勢力裡面我們假定用戶的問題呢是這個樣子的,我馬上要出門,幫我看看今天要帶什麼東西。 然後工具的返回呢,我們假設是這樣子的,定位工具返回,假設這樣,天氣工具返回,假設是這樣。 在這種情況下,Agent就必須輸出這樣的一份結果,這個就是我們所需要的Agent Skill的整體結構了。 定義好之後,我們需要把它存到硬盤裡面指定的地方,那Cloud Code為例,你需要找到用戶目錄下面的是點Cloud Skills文件夾。 然後接下來的存放操作呢,有兩個規定,大家千萬不要搞錯,第一,我們需要在這個目錄下面新建一個文件夾, 而且文件夾的名字必須與Agent Skill的名字相同,我們的Agent Skill叫做go out checklist,所以我們的文件夾也必須叫這個名字。 第二點,進入到這個文件夾裡面之後,我們需要新建一個文件,把剛才的內容全部貼進來,重點來了, 這個文件名必須叫做skill.md,其中skill是大寫,這個呢是Agent Skill的硬性規範,算是個接頭愛好。 如果你隨便起別的名字,系統是絕對不會認的,好,我們把它全部給粘貼進來,然後保存退出。 存好之後呢,我們這個Agent Skill就算是創建完成了。 然後我們來隨便找一個空的文件夾,啟動Cloud Code。 在啟動的過程中,Cloud Code就會發現Skills文件夾裡面多了一個叫做go out checklist的Agent Skill。 它呢就會去讀取對應的Skill.MD文件裡面的原數據,也就是名稱和描述。 下面的指令層暫時先不讀,因為指令層的內容有可能會比較大,所以呢Cloud Code只會在用戶問題與Agent Skill的名稱和描述相關的時候才會去讀取對應的指令層。 另外順便提一下,這個Agent Skill明確要求需要定位和天氣這兩個工具。 我已經提前把它們做成MCP工具導入到Cloud Code裡面了,運行這個-MCP就可以驗證。 這個location呢就是定位工具,下面的那個weather呢就是天氣工具。 這兩個工具的返回結果都是我編的,到時候你就會看出來了,主要呢是為了演示整個流程。 好,言歸正傳,下面呢我們輸入問題,我出門了,告訴我要帶什麼,提交。 可以看到Cloud Code開始工作了,讓我們稍微等待一下。 它首先是請求調用定位工具,我們同意。 然後呢,它再調用天氣工具,我們還是同意。 最後拿到了所有需要的信心之後,Cloud Code就會把答案整理成Agent Skill中所需要的格式給到我們,沒錯,Agent Skill的基本功能呢就是這麼簡單。 它就是一個文檔,一個給Agent看的說明文檔,當然Agent Skill呢還有很多高層的功能, 比如說是運行代碼,引用資源等等,它的漸進式披露機制呢也是一大特色,可以節省很多的Token。 如果你對此感興趣,希望深入了解一下的話,歡迎看一下我的這個視頻,一次把Agent Skill的使用和原理全部都說明擺。
[32:04]好,到這裡,我們把所有的概念都講完了,讓我們回顧一下這個體系。 LLM代表大模型,它是所有AI技術的核心,Token是大模型處理數據的最基本單元。 Context是大模型每次處理任務時接收到的信息總合,你可以把它看作是大模型的臨時記憶體。 Context Window則代表大模型Context最多能夠存儲的Token量,Prompt是用戶或系統當前給大模型下達的具體指令或問題, 它分為User Prompt和System Prompt兩大類,Tool是大模型用來感知和影響外部環境的函數。 MCP呢則是統一了工具接入格式的標準協議,Agent是能自主規劃,自主調用工具,持續運作,直至解決用戶問題的一個程序。 Agent Skill呢是給Agent看的一個說明文檔,主要就是用來規定做事步驟和規則的。 大致呢就是這個樣子的了,理解了這些概念,你就能看懂AI圈子裡面的各種新產品新技術了,無論是Cloud Code,Codex,Code Work還是Open Claw, 他們本質上都是在這個框架下運作的,好,這期視頻呢到這裡就結束了,如果對你有幫助,別忘了點贊關注,我是馬克, 用最通俗的語言將最硬核的技術,我們下期再見,拜拜。
