網(wǎng)站怎樣優(yōu)化文章關(guān)鍵詞,南通網(wǎng)站建設(shè)策劃,WordPress前端上傳大文件,app開發(fā)官網(wǎng)市場今年剛看到Manus這種Agent的時候很興奮#xff0c;所以他們?yōu)槭裁催@么興奮#xff1f; Agent這東西又為什么會出現(xiàn)#xff0c;他到底解決了哪一部分問題#xff1f;其次#xff0c;他到底能不能解決這些問題#xff0c;在解決的過程中的困難與卡點(diǎn)是什么、又要如何解…市場今年剛看到Manus這種Agent的時候很興奮所以他們?yōu)槭裁催@么興奮Agent這東西又為什么會出現(xiàn)他到底解決了哪一部分問題其次他到底能不能解決這些問題在解決的過程中的困難與卡點(diǎn)是什么、又要如何解決帶著上述問題進(jìn)入今天的學(xué)習(xí)為什么需要Agent一、為什么Agent會出現(xiàn)模型當(dāng)前雖然很強(qiáng)大但他是天生缺陷的他本身只包含了訓(xùn)練后的內(nèi)置數(shù)據(jù)這里就產(chǎn)生了第一個矛盾點(diǎn)當(dāng)前社會信息爆炸太嚴(yán)重一個星期就可以發(fā)生很多事模型首先不可能跟得上這個節(jié)奏其次他也不會去跟這些節(jié)奏因為互聯(lián)網(wǎng)上多數(shù)數(shù)據(jù)是垃圾模型不可能去吃這些垃圾垃圾吃多了會影響智商的除了市面上的信息各個企業(yè)還有很多自己私有的數(shù)據(jù)這些數(shù)據(jù)全部需要跟模型交互否則在公司場景下模型的意義就不大了所以Agent出現(xiàn)的第一個原因是他至少需要與外部世界進(jìn)行信息交流尤其是一些垂直領(lǐng)域如果數(shù)據(jù)不足模型很容易胡言亂語的。其實在這里很多同學(xué)是有疑問的如果僅僅是這個原因那直接采用Workflow的模式就好了嘛這也是最標(biāo)準(zhǔn)的RAG邏輯嘛但就簡單的信息檢索這個需求也是隨時遞增的他現(xiàn)在拿的是公網(wǎng)數(shù)據(jù)后續(xù)一會要拿A公司數(shù)據(jù)、一會要拿B公司數(shù)據(jù)這種數(shù)據(jù)源變多了后怎么辦呢誰去判斷他應(yīng)該去哪拿數(shù)據(jù)呢這種讓RAG系統(tǒng)處理起來就會很麻煩比如以下問題什么是組織結(jié)構(gòu)你們公司的組織結(jié)構(gòu)是怎么樣的A公司是怎么樣的B公司又是怎么樣的?他們?yōu)槭裁匆@么設(shè)計?直接使用RAG也能做流程是用模型判斷到底有哪些問題做下問題重寫分拆后再到各個信息渠道去獲取信息一套復(fù)雜的Workflow類RAG就能搞定。這里關(guān)于Agent最深的沖突也就出現(xiàn)了Agent能做的事情Workflow都能做那么Agent存在的意義是什么畢竟Workflow 可以做循環(huán)、可以做重試、可以做復(fù)雜策略只不過這些循環(huán)與策略必須由人顯式編碼。當(dāng)環(huán)境復(fù)雜度上升Workflow 的成本曲線會很難看在企業(yè)真實場景里復(fù)雜度增長通常來自三類“不可窮舉”**工具/系統(tǒng)不可窮舉**今天查公網(wǎng)明天查 A 公司的知識庫、后天查 B 的 CRM、再后天接入 CDE……**意圖組合不可窮舉**一個問題里同時包含“解釋概念 對比多家公司 要求給出原因 產(chǎn)出結(jié)構(gòu)化表格”。**異常與邊界不可窮舉**權(quán)限不足、字段缺失、數(shù)據(jù)沖突、召回為空、網(wǎng)頁結(jié)構(gòu)變化、接口限流…當(dāng)然可以把這些都寫進(jìn) Workflow但會變成典型的分支爆炸 維護(hù)爆炸每加一個系統(tǒng)不只是“多一個工具配置”還包括字段映射、降級策略、評測集更新等。更關(guān)鍵是你要為“工具之間如何組合、何時重試、何時換路、何時追問補(bǔ)槽、何時拒答”寫越來越多的顯式編排邏輯。這時候Agent架構(gòu)的優(yōu)勢就出來了如果多了CDE有可能增加3個工具配置有可能什么都不做搜索工具自己就兼容了。最重要的是判斷用戶意圖和怎么調(diào)用工具工具調(diào)用后的數(shù)據(jù)對不對這些繁瑣的事情全部丟給模型了當(dāng)然循環(huán)肯定會多很多次、效率肯定要低點(diǎn)、Token肯定要高點(diǎn)畢竟本身Agent就是一套 時間/成本 換架構(gòu)簡潔度的架構(gòu)。這里再加一句Agent解決的不是怎么回答的問題而是給出了一套將問題編譯為可執(zhí)行計劃的框架甚至于你把Agent這套架構(gòu)本身理解為一套Workflow也是可以的這個是一套現(xiàn)階段驗證出來很不錯的范式。最后再總結(jié)一下相較于WorkflowAgent 架構(gòu)是一種工程架構(gòu)層面的優(yōu)化它的核心不是“更聰明”而是把一部分原本由工程師在開發(fā)期顯式寫死的控制流if/else、編排、異常處理遷移到運(yùn)行時由模型來決定路由、工具選擇、多輪嘗試、失敗重試、補(bǔ)槽追問、結(jié)果校驗。Agent是用更多的成本多輪推理 多次工具調(diào)用 更高延遲/Token換開發(fā)與維護(hù)成本的下降分支更少、擴(kuò)展更快、長尾更適配在這個基礎(chǔ)之下我們再來看看整個Agent的發(fā)展史這有助于我們進(jìn)一步抓住其脈絡(luò)。二、Agent的發(fā)展史當(dāng)前最經(jīng)典的Agent架構(gòu)是ReAct他大約是在2022年提出論文《ReAct: Synergizing Reasoning and Acting in Language Models》。那時候并不支持Function Calling這種最基本工具調(diào)用的能力所以需要我們自己做實現(xiàn)這里可以用提示詞做識別并輸出、也可以做微調(diào)但成本要高點(diǎn)。其中Function Calling整體流程大概這樣做的第一我們會定義Agent會調(diào)用的所有工具這是一個JSON對象里面最核心的是description第二模型會根據(jù)用戶問題和預(yù)設(shè)的工具集去做對比看看這次要調(diào)用哪些工具當(dāng)然最主要的還是根據(jù)描述判斷第三如果這次判斷是有工具調(diào)用的話模型會返回工具的名稱然后結(jié)束這次流程第四我們拿著工具信息去各種調(diào)用拿到數(shù)據(jù)然后組裝最終的提示詞連著用戶的問題去做模型調(diào)用只不過上述動作畢竟太繁瑣于是在23年6月OpenAI提出了Function Calling將他作為ChatGPT 產(chǎn)品的正式能力后續(xù)逐漸成為事實上的標(biāo)準(zhǔn)各個基座模型都有對應(yīng)實現(xiàn)有了這個基礎(chǔ)后Agent的出現(xiàn)就變得更加順滑了。而后的事情大家就很清楚了。國內(nèi)Agent概念的火熱從年初的Manus開始但如果真要追溯早期、又出圈的Agent的話可以是2023年3月的開源項目Auto-GPT只不過就算今年的Manus在早期因為基座能力不足都表現(xiàn)不佳遑論更早期的Auto-GPT了呢從Manus發(fā)布后2025 AI應(yīng)用元年逐漸轉(zhuǎn)移成2025 AI Agent元年模型也取得了長足的發(fā)展包括整體的推理能力、上下文長度得到了極大的加強(qiáng)而且我相信各個基座模型一定在工具調(diào)用這塊做了大量微調(diào)訓(xùn)練其直接的結(jié)果是下半年的工具調(diào)用能力有明顯的加強(qiáng)。在這個階段因為基座模型大家發(fā)現(xiàn)Agent對工具的需求量極大并且一定會產(chǎn)生很多類似的工具。所以MCP的概念火了起來一方面要解決之前Function Calling留下的工程維護(hù)問題另一方面也想讓人少開發(fā)工具直接用社區(qū)的MCP也幾乎變成了事實上的標(biāo)準(zhǔn)然后Agent發(fā)展進(jìn)入了一個瘋漲的階段而后模型的穩(wěn)定性調(diào)用能力有不小的加強(qiáng)但在工具多了后依舊會有找不到、亂調(diào)用的問題。于是Claude開始收集了大量Tools調(diào)優(yōu)經(jīng)驗在25年10月正式提出了Skills技術(shù)可以認(rèn)為他是在對整體Function Calling進(jìn)行補(bǔ)足當(dāng)然Skills除了提升工具識別能力之外還做了很多其他工作。總之現(xiàn)階段使用Skills Function Calling 上下文工程已經(jīng)可以將準(zhǔn)確率做得很不錯了比如我們就能折騰到90%這在之前是很難的在工程上要做很多動作。以上是我從技術(shù)層面看到的近三年Agent發(fā)展的情況也就是說在今年之前想要做出個好的Agent幾乎不可能在今年下半年開始整體難度會小非常多最后這里的推測是之前對于Agent的很多質(zhì)疑乃至產(chǎn)品體驗差的問題在2026年應(yīng)該會得到很大的緩解。所以要說Agent直接依賴于模型能力的變遷這句話還真的沒問題你怎么優(yōu)化都可能比不上模型一次能力升級。了解了Agent為什么會出現(xiàn)發(fā)展脈絡(luò)是什么也知道了幾個關(guān)鍵點(diǎn)接下來我們就來具體聊聊這幾個關(guān)鍵點(diǎn)Function Calling、MCP和Skills三、Function Calling根據(jù)前面的描述FC是干什么的大家已經(jīng)很清晰了單說FC其實就是用一套工程架構(gòu)把之前模型判斷如何用工具的工作流給替代掉具體的交互邏輯為在對話中LLM根據(jù)用戶的問題今天北京的天氣如何判斷是否需要調(diào)用函數(shù)。如果需要它會輸出一個結(jié)構(gòu)化的JSON請求其中包含了要調(diào)用的函數(shù)名和參數(shù)然后再調(diào)用我們的程序整個官方的案例非常清晰具體的流程直接看GPT官方的定義即可# 這是給模型看的工具定義不是真正的代碼tools [{type: function,name: get_weather,description: Retrieves current weather for the given location.,parameters: { type: object, properties: { location: { type: string, description: City and country e.g. Bogotá, Colombia }, ...... }, }}]每次調(diào)用API時都需要傳遞tools參數(shù)這里直接調(diào)用GPT接口發(fā)起請求# 每次調(diào)用API時都需要傳遞tools參數(shù)調(diào)用GPT接口發(fā)起請求response client.responses.create( modelgpt-5, messages[...], toolstools # ← 這個每次都要帶)這里也可以看出來模型具有哪些工具調(diào)用能力全部是我們預(yù)定義好的模型會根據(jù)用戶輸入選擇使用哪個工具# 用戶輸入user_query 今天北京天氣怎么樣# 模型會分析# - 用戶問的是天氣 → 匹配到 get_weather 的 description# - 提到了北京 → 對應(yīng) location 參數(shù)# - 決定調(diào)用 get_weather 函數(shù)只不過模型事實上并不會直接調(diào)用工具他只會返回結(jié)構(gòu)化的調(diào)用指令這里返回這個東西是模型專門任務(wù)訓(xùn)練的結(jié)果{ function_call: { name: get_weather, arguments: {location: 北京, unit: celsius} }}真正根據(jù)返回JSON數(shù)據(jù)調(diào)用腳本的是我們后臺程序并且這里需要將調(diào)用結(jié)果給到模型# 把天氣結(jié)果返回給模型# result是返回的結(jié)果final_response llm.chat( modelgpt-5, messages[ {role: user, content: 今天北京天氣怎么樣}, {role: assistant, function_call: model_response[function_call]}, {role: function, name: get_weather, content: json.dumps(result)} ])邏輯很清晰如果意圖識別沒有工具函數(shù)調(diào)用則直接調(diào)用大模型返回給用戶如果判斷有工具調(diào)用那么就拿著首次模型返回的參數(shù)拿到結(jié)果后二次調(diào)用模型再將最終結(jié)果返回給用戶。這里有幾個點(diǎn)要特別注意如果你的工具接口掛了容錯做得不好的話那么模型就不會回答用戶了。另外還有幾個問題理解后幾乎就能了解Fuction Calling的本質(zhì)乃至為什么他用得不太頻繁的原因第一如果Tools工具過多數(shù)組過多這個也是要占用上下文長度的所以真實使用會做很多小處理第二Fuction Calling 使用好壞非常依賴于模型本身對意圖識別的能力模型判斷要不要調(diào)用一個函數(shù)主要是根據(jù)description參數(shù)來的。這里看上去風(fēng)險挺大的因為一定會出現(xiàn)模型調(diào)用出問題的情況只不過模型容錯能力強(qiáng)多拿了數(shù)據(jù)也未必會影響回答在這個基礎(chǔ)下我們再來說MCP和Skills先說MCP四、MCP那么MCP為什么會出現(xiàn)呢這東西出現(xiàn)的意義是什么要回答還得回歸Function Calling…關(guān)于Function Calling為什么會出現(xiàn)我們已經(jīng)很清楚了他解決的是單個模型怎么“按你定義的 JSON 協(xié)議”去調(diào)你自己的API的問題。但一旦工具變多后會有很多痛點(diǎn)維護(hù)起來爆炸了MCP就是為了解決這個問題而生的比較夸張的說法就是MCP是幫Function Calling “擦屁股”的…這里大家可能不太理解給個案例企業(yè)中有10個AI AgentN需要接入20個數(shù)據(jù)源/工具M(jìn)。如果每個應(yīng)用都為每個工具編寫專用適配代碼就需要200個集成點(diǎn)。這里面維護(hù)成本是較高的任何工具API變更都會很煩。并且要注意的是生產(chǎn)上的Agent不會只調(diào)用一個模型他可能同時調(diào)用ChatGPT、Gemini還有DeepSeek而他們每個Tools調(diào)用接口都不一樣這個維護(hù)起來就更麻煩了。在這個基礎(chǔ)下MCP出現(xiàn)了他引入“客戶端-服務(wù)器”架構(gòu)標(biāo)準(zhǔn)化。你只需編寫一次MCP客戶端就能接入所有符合MCP協(xié)議的服務(wù)器。而工具提供者只需實現(xiàn)一個MCP服務(wù)器就能被所有MCP客戶端使用集成點(diǎn)從N×M驟降到NM。案例說明大家可能讀起來有點(diǎn)迷糊這里給個案例這里有兩個工具Tool A get_weather(location) —— 查天氣Tool B get_stock_price(ticker) —— 查股價用戶的問題是“幫我查北京天氣再給我 騰訊 的股價最后總結(jié)一下?！眰鹘y(tǒng)的FC流程分四步一、預(yù)定義工具每次調(diào)用模型或每個會話都要把 tools 定義帶進(jìn)去tools [ { type: function, name: get_weather, description: Get weather by location, parameters: {type:object,properties:{location:{type:string}},required:[location]} }, { type: function, name: get_stock_price, description: Get stock price by ticker, parameters: {type:object,properties:{ticker:{type:string}},required:[ticker]} }]二、模型返回“工具調(diào)用指令”結(jié)構(gòu)化 JSON{ tool_calls: [ {name: get_weather, arguments: {location: Beijing}}, {name: get_stock_price, arguments: {ticker: AAPL}} ]}三、我們自己后臺程序做工具調(diào)用def get_weather(location): return weather_api.query(location)def get_stock_price(ticker): return market_api.query(ticker)四、拿到工具結(jié)果組裝提示詞最終調(diào)用模型生成回答tool_results [ {name:get_weather, content: ...}, {name:get_stock_price, content: ...}]final llm_call(messages tool_results)如果這個工具只服務(wù)了一個Agent那沒問題但如果服務(wù)了2個就會麻煩一點(diǎn)比如在工具參數(shù)變了的時候他就要改2個Agent的配置了如果應(yīng)用變成20個的話就很麻煩了因為我們大概率也記不清楚誰在調(diào)用工具了…如果有MCP后就簡單很多了他用工程的方式把一些復(fù)雜的維護(hù)封裝了把 Tool A/Tool B 的接入從“應(yīng)用內(nèi)部代碼”搬到“獨(dú)立的 MCP Server”里。AI 應(yīng)用不再直連 Weather API / Market API而是只連 MCP Server。這里其實邏輯很簡單甲乙雙方之前口頭約定參數(shù)然后兩邊寫下游發(fā)現(xiàn)老是被坑就說你他媽別約定了參數(shù)是什么你一起傳給我算了Agent也不直接連接工具AI了只連接MCP Server可以把 MCP 當(dāng)成一個“工具總線”MCP Server工具提供者暴露工具列表 接受調(diào)用 返回結(jié)果MCP Client / HostAI 應(yīng)用連接 server、發(fā)現(xiàn)工具、轉(zhuǎn)發(fā)調(diào)用、回傳結(jié)果給模型方便大家理解這里依然走個流程一、MCP Server 暴露工具Weather API / Market API 的鑒權(quán)、重試、字段映射都封裝在 server 里外界只看到“標(biāo)準(zhǔn)化工具”名字、參數(shù) schema、描述、調(diào)用結(jié)果# mcp_server.pytool(get_weather, input_schema{location:string})def get_weather(location): return weather_api.query(location)tool(get_stock_price, input_schema{ticker:string})def get_stock_price(ticker): return market_api.query(ticker)run_mcp_server(transportstdio) # 或 HTTP/SSE 等二、Host連接MCP Server并發(fā)現(xiàn)工具client MCPClient(connectstdio:python mcp_server.py)tools client.list_tools()# tools - [{name, description, input_schema, ...}, ...]三、把發(fā)現(xiàn)到的工具“翻譯/映射”給當(dāng)前使用的模型平臺如果你用 OpenAI就把它們組裝成 OpenAI 的 tools 數(shù)組如果你用 Claude/Gemini就組裝成各自需要的聲明格式注意這一步仍然需要做“向上適配模型”但這是一層通用適配不會因為 Tool A/Tool B 的內(nèi)部細(xì)節(jié)而變化。四、模型基于工具合同做決策返回 tool_callname arguments{ tool_calls: [ {name: get_weather, arguments: {location: Beijing}}, {name: get_stock_price, arguments: {ticker: 0700.HK}} ]}五、Host 不再直連外部 API而是把調(diào)用轉(zhuǎn)發(fā)給 MCP Serverfor call in tool_calls: result client.call_tool(call[name], call[arguments]) tool_results.append({name: call[name], content: result})至此基本結(jié)束了其實大家也看出來了Agent這東西黑盒是真的多啊…遺留問題雖然MCP確實可以解決工具過多的維護(hù)問題但他并不能解決工具多了亂調(diào)用、錯調(diào)用的問題而且還會有工具過多時候的爆炸問題工具如何組織的問題。當(dāng)然在比較差的架構(gòu)下團(tuán)隊能力不行FC要求開發(fā)者在每次API調(diào)用時預(yù)先聲明所有可用工具。但這個是可以被優(yōu)化的也就是每次用戶問題要過一次模型判斷這次到底要用哪些工具要用才加載只不過可能會有錯漏。因為這個機(jī)制也能做到動態(tài)添加/移除工具。但這一切依舊不太優(yōu)雅工具調(diào)用還是老是出問題所以在MCP之后又有擦屁股的工程能力誕生了他的名字叫五、Skills我們前面說了用戶無限的意圖需要用有限的工具來收斂。只不過工具多了后排列組合也多收斂不收斂不知道Agent最大詬病就是工具調(diào)用不準(zhǔn)、Agent整體響應(yīng)慢倒是真的為了解決這一切又疊加了一個新的工具Anthropic 對Skill的定義是一個文件夾里面裝著說明文檔、腳本和資源Claude 在執(zhí)行任務(wù)時會先掃一圈所有 Skills覺得哪個對當(dāng)前任務(wù)有用就把完整內(nèi)容拉進(jìn)上下文來用。翻譯翻譯是Skill 一份可反復(fù)調(diào)用的專業(yè)SOP說明書由模型自己按需加載結(jié)合之前我們說Skills的誕生原因其實就是將工具調(diào)用不準(zhǔn)的問題搬到了Skills里面不需要模型自己去語義理解自己做工具組合了Skills里面寫得很清楚該用什么工具、怎么用這樣就會緩解之前的工具錯誤。當(dāng)然除此之外Skills還有其他意義總結(jié)下來Skills誕生的原因有一、提高工具調(diào)用穩(wěn)定性絕大多數(shù)團(tuán)隊都會面臨一旦Tools多了后就會束手無策他們會被“亂調(diào)用/漏調(diào)用/參數(shù)錯/順序不穩(wěn)/失敗不重試”折磨直接導(dǎo)致體驗差、不可交付。Skills 的核心價值之一就是把“怎么用工具把事做對”的套路選擇條件、步驟、校驗、兜底沉淀成可復(fù)用模塊從而顯著降低隨機(jī)性。其實這個之前是做到ReAct工程架構(gòu)里的現(xiàn)在有Skills可以有效降低工程難度只不過要特別注意Skills也不能徹底解決Tools調(diào)用錯誤問題還得有其他工程手段。二、長提示詞與硬編碼流程的維護(hù)問題關(guān)于這點(diǎn)很有點(diǎn)之前MCP出來的重要原因都是項目大了會導(dǎo)致的煩躁工程維護(hù)問題。維護(hù)提示詞多的同學(xué)會有感受現(xiàn)在提示詞正在往偽代碼的方向發(fā)展為了讓模型穩(wěn)定輸出需要往里面不斷加?xùn)|西比如一個數(shù)據(jù)分析的案例業(yè)務(wù)規(guī)則指標(biāo)口徑、過濾條件、時間粒度數(shù)據(jù)規(guī)則字段映射、缺失值處理、異常檢測工具規(guī)則SQL 工具怎么用、什么時候用、失敗怎么重試輸出規(guī)則必須給表格、必須給結(jié)論、必須給風(fēng)險提示合規(guī)規(guī)則脫敏、禁用詞、免責(zé)聲明還塞一堆示例few-shot結(jié)果上下文常駐每次對話都帶著一大坨“未必用得上”的規(guī)則成本高、干擾大版本不可控某個字段改名了、口徑變了你改 Prompt影響全局回滾困難復(fù)制漂移A 項目 copy 一份B 項目再 copy 一份三個月后都不一致排障困難出錯了不知道是“規(guī)則寫錯”“規(guī)則太長模型沒讀到”“示例沖突”還是“工具返回異常”Skills的解題思路就跟之前MCP很類似了把所有的這類配置信息全部寫到統(tǒng)一的地方需要用到時候再拿出來。另一個角度既然提示詞現(xiàn)在越來越像代碼工程了那么對應(yīng)的版本管理的概念就會出現(xiàn)包括追求的灰度和回滾等問題而Skills正是處理提示詞工程管理復(fù)雜而誕生的。這里給個案例做為什么需要Skills的說明案例對比幫我查一下技術(shù)部張三上周的差旅報銷總額然后按項目拆分一下這里直接使用FC的話[ { name: get_employee_info, description: 獲取員工基本信息, parameters: { employee_name: string } }, { name: get_department_info, description: 獲取部門信息, parameters: { department_name: string } }, { name: query_reimbursements, description: 查詢報銷記錄, parameters: { employee_id: string, start_date: string, end_date: string } }, { name: query_projects, description: 查詢項目信息, parameters: { department_id: string } }, { name: analyze_reimbursement_data, description: 分析報銷數(shù)據(jù), parameters: { reimbursement_data: array, group_by: string } }]在ReAct架構(gòu)中需要自己去實現(xiàn)正確的調(diào)用邏輯先調(diào) get_employee_info(“張三”) 拿到員工ID調(diào) get_department_info(“技術(shù)部”) 拿到部門ID調(diào) query_reimbursements(employee_id, 上周起止日期) 拿到報銷列表調(diào) query_projects(department_id) 拿到項目列表調(diào) analyze_reimbursement_data(…) 進(jìn)行分析這里常見問題就產(chǎn)生了**亂序調(diào)用**先查項目結(jié)果沒部門ID參數(shù)**參數(shù)錯誤**時間格式不對“上周” vs “2025-12-08”**漏調(diào)工具**忘記調(diào)analyze直接返回原始數(shù)據(jù)**無限循環(huán)**某個工具失敗后不會自動重試或換方案能不能解決呢也是可以的但會加大工程復(fù)雜度可能加大循環(huán)次數(shù)最終響應(yīng)速度和成本都會有影響。而使用Skills后相當(dāng)于認(rèn)為的為這個需要加了一套強(qiáng)的工作流或者CoT用戶: 張三上周差旅報銷模型: 檢測到報銷關(guān)鍵詞 → 加載報銷查詢Skill按Skill流程執(zhí)行:1. 自動調(diào)用get_employee_info(張三) → 拿到ID: 1232. 自動調(diào)用時間解析(上周) → 得到: 2025-12-08 ~ 2025-12-14 3. 調(diào)用query_reimbursements(employee_id123, start_date..., end_date...)4. 發(fā)現(xiàn)用戶沒提項目 → 跳過項目拆分步驟5. 調(diào)用標(biāo)準(zhǔn)化報告模板生成結(jié)果直接返回: 張三上周差旅報銷總額5,200元共3筆...用戶體驗: ? 好 - 一次搞定CoT都出來了穩(wěn)定性肯定高啊這里再說下維護(hù)性問題如果財務(wù)的差旅標(biāo)準(zhǔn)變了之前所有涉及提示詞部分的數(shù)據(jù)需要改但用Skills就只需要改一個地方很清晰的。其他案例在一個老板 BI Agent里配置了一批 Tools/MCP 工具get_sales_reportget_marketing_spendget_cashflow_status兩個 Skillsboss_bi_dashboard_cn教模型如何用上面幾個工具按老板視角解釋數(shù)字、寫結(jié)論里面有詳細(xì)的 KPI 口徑、話術(shù)、注意事項excel_analysis_skill教模型如何用 code execution 對上傳的 Excel 做分析這時候觸發(fā)條件來了幫我看看今年 Q3 的營收和投放簡單說說是不是該收一收預(yù)算這里具體的流程是一、先走Skill檢索模型首先會理解這是一個老板視角的財務(wù)分析 決策建議接下來模型會遍歷Skills里所有的meta發(fā)現(xiàn) boss_bi_dashboard_cn 的描述里有類似用于解讀公司經(jīng)營指標(biāo)、營收、成本、預(yù)算輸出老板視角決策建議所以它會激活這個 Skill讀取 instructions.md把這份“說明書 SOP”拉進(jìn)當(dāng)前上下文。此時Tools/MCP 還沒被調(diào)用模型完成了從很多工具定義 一堆 Skills里選出一個最合適的技能包。二、Skill里面決定工具調(diào)用boss_bi_dashboard_cn 的 instructions.md 可能會寫類似這樣的話如果用戶問的是某個時間段的“營收 投放”先調(diào)用 get_sales_report 拿營收數(shù)據(jù)再調(diào)用 get_marketing_spend 拿投放數(shù)據(jù)然后根據(jù)「同比 / 環(huán)比 / ROAS」給出老板能看懂的判斷輸出結(jié)論時要用以下結(jié)構(gòu)一句話結(jié)論2–3 個關(guān)鍵數(shù)字建議動作風(fēng)險提示Claude 讀了這份說明后就知道下一步應(yīng)該先查 KPI → 需要工具然后就是具體工具調(diào)用get_sales_report({period: 2024-Q3})get_marketing_spend({period: 2024-Q3})到這里Function Calling / MCP 出場了。三、數(shù)據(jù)處理 SOP這里走Function Calling的邏輯拿到最終反饋數(shù)據(jù)即可這里不展開{ sales: 12345678, growth_rate: 0.12, gross_margin: 0.31}然后就是數(shù)據(jù)使用這個instructions.md里面已經(jīng)說得很清楚了輸出結(jié)構(gòu)怎么寫哪些數(shù)字要重點(diǎn)強(qiáng)調(diào)語氣要偏老板視角少講實現(xiàn)多講結(jié)論和動作有哪些“常見坑”要避開# 輸出案例結(jié)論Q3 的營收仍在增長但投放效率明顯走低建議適度收縮預(yù)算、把錢放到 ROAS 更高的渠道上。......后面是建議 風(fēng)險......以上就是Skills相信大家搞懂了最后說下Agent架構(gòu)的核心ReAct。六、ReAct框架了解了Agent的最原子能力依賴后我們就要進(jìn)入其真正的編排層核心ReAct了編排層是智能體系統(tǒng)的核心控制單元負(fù)責(zé)組織信息流和執(zhí)行推理循環(huán)。它模擬人類在做復(fù)雜任務(wù)時的認(rèn)知過程先獲取信息、然后制定計劃、執(zhí)行行動、再根據(jù)反饋調(diào)整計劃不斷循環(huán)直到完成目標(biāo)。一個常見的比喻是**“廚師準(zhǔn)備復(fù)雜菜品”**廚師會根據(jù)顧客需求獲取食材信息思考烹飪步驟然后實際烹飪過程中可能根據(jù)味道反饋不斷調(diào)整方法。類似的Agent的編排層會按照設(shè)定的推理框架反復(fù)迭代驅(qū)動模型生成“思考”并做出“行動”決策。常見的推理框架大同小異這里一定需要了解的是兩個東西ReAct與CoT除此之外可以延伸到ToTReAct在前面我們做了基礎(chǔ)介紹該框架強(qiáng)調(diào)模型在回答前進(jìn)行連續(xù)的內(nèi)省和行動選擇有助于提高答案的準(zhǔn)確度和可追溯性**CoT思維鏈**引導(dǎo)模型通過生成中間推理步驟來分解問題促使其在最終答案前先列舉思考過程這種框架可以增強(qiáng)模型解決復(fù)雜問題時的準(zhǔn)確性幻覺問題。**ToT思維樹**是在 CoT 的基礎(chǔ)上允許模型在多個備選思路間做比較適用于需要探索多種方案的策略性任務(wù)目的依舊是提升對復(fù)雜問題的解決能力。篇幅有限我們只討論ReAct和CoT的配合即可其他的都類似ReAct和CoT首先ReAct與CoT都是推理策略框架也就是Agent四大組件核心的編排層具象化實現(xiàn)他們都描述的是如何組織模型的推理過程、生成步驟、提示詞結(jié)構(gòu)。換句話說ReAct是代碼的核心是AI工程的核心他會決定如何去與記憶系統(tǒng)、工具系統(tǒng)做配合。然后ReAct邏輯上與CoT是同級別的但現(xiàn)在更多的是在組合使用顯得CoT是ReAct的一個過程產(chǎn)物其實并不是的邏輯上CoT也可以調(diào)用工具只不過現(xiàn)在從流行范式的角度來說ReAct被用作主框架的時間會多一點(diǎn)并且過程中會包含很多CoT的部分這里的結(jié)果是ReAct 是容器CoT 是內(nèi)容。ReAct 是最“Agent”化的、CoT 是最基礎(chǔ)的。ReAct 規(guī)定了先思考Thought→ 行動Action→ 等待結(jié)果Observation→ 再思考…而這個“Thought”怎么寫通常就是一個 Chain of Thought 推理塊。舉個簡單例子讓 Agent 回答“某公司員工請假流程”的問題Agent 需要讀取用戶的問題從知識庫中檢索文檔分析內(nèi)容結(jié)構(gòu)輸出清晰步驟這塊的簡要流程是User: 請問我們公司請假流程是什么Step 1:Thought: 先查找關(guān)于“請假流程”的文檔。Action: search_docs(請假流程)Observation: 找到文檔《員工手冊》第4章列出了流程步驟。Step 2:Thought:首先讀取這部分內(nèi)容理解流程的順序。- 第一步是員工提交請假申請- 第二步是直屬上級審批- 第三步是HR備案因此我可以組織一份清晰的回答。Action: NoneFinal Answer: 請假流程如下1提交申請2主管審批3HR備案。這個 “Step 2” 的 Thought 部分就是一個簡單的 CoT模型在沒有行動前分步思考、提取、組織信息這是典型的思維鏈。為什么這么用也很簡單Agent架構(gòu)中也不可能每一步都調(diào)用工具很多時候只是在“組織思維/語言”CoT可以有效降低幻覺率?？偠灾甊eAct 框架里可以有很多 CoT 內(nèi)容穿插其中這種組合也是最常見、最穩(wěn)的做法大家記住這點(diǎn)就行這就是Agent的編排層。七、結(jié)語然后就是記憶系統(tǒng)了這個其實才是整個Agent項目里面最惱火、最煩躁的部分因為太過于復(fù)雜我們今天就不繼續(xù)了后面有專門的課題。最后總結(jié)一下市場之所以為 Manus 這類 Agent 興奮不是因為它“更聰明”而是因為它把原本需要工程師在 Workflow 里寫死的路由、工具選擇、重試等控制流遷移到運(yùn)行時由模型來決定從而在“工具多、意圖組合多、異常多”的企業(yè)場景里顯著降低開發(fā)與維護(hù)成本。過去三年的脈絡(luò)也很清晰ReAct 提供推理行動的循環(huán)框架Function Calling 讓工具調(diào)用標(biāo)準(zhǔn)化MCP 緩解工具爆炸帶來的集成維護(hù)成本Skills 把“怎么把工具用對”的 SOP 沉淀下來提升穩(wěn)定性。25年工具調(diào)用這塊模型已經(jīng)取得了長足進(jìn)步但記憶模塊依舊是老大難問題我認(rèn)為2026年底層模型一定會在這塊做出突破那種本地部署的模型高階向量數(shù)據(jù)庫是可能誕生的讓我們拭目以待吧…如何學(xué)習(xí)大模型 AI 由于新崗位的生產(chǎn)效率要優(yōu)于被取代崗位的生產(chǎn)效率所以實際上整個社會的生產(chǎn)效率是提升的。但是具體到個人只能說是“最先掌握AI的人將會比較晚掌握AI的人有競爭優(yōu)勢”。這句話放在計算機(jī)、互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)的開局時期都是一樣的道理。我在一線互聯(lián)網(wǎng)企業(yè)工作十余年里指導(dǎo)過不少同行后輩。幫助很多人得到了學(xué)習(xí)和成長。我意識到有很多經(jīng)驗和知識值得分享給大家也可以通過我們的能力和經(jīng)驗解答大家在人工智能學(xué)習(xí)中的很多困惑所以在工作繁忙的情況下還是堅持各種整理和分享。但苦于知識傳播途徑有限很多互聯(lián)網(wǎng)行業(yè)朋友無法獲得正確的資料得到學(xué)習(xí)提升故此將并將重要的AI大模型資料包括AI大模型入門學(xué)習(xí)思維導(dǎo)圖、精品AI大模型學(xué)習(xí)書籍手冊、視頻教程、實戰(zhàn)學(xué)習(xí)等錄播視頻免費(fèi)分享出來。第一階段10天初階應(yīng)用該階段讓大家對大模型 AI有一個最前沿的認(rèn)識對大模型 AI 的理解超過 95% 的人可以在相關(guān)討論時發(fā)表高級、不跟風(fēng)、又接地氣的見解別人只會和 AI 聊天而你能調(diào)教 AI并能用代碼將大模型和業(yè)務(wù)銜接。大模型 AI 能干什么大模型是怎樣獲得「智能」的用好 AI 的核心心法大模型應(yīng)用業(yè)務(wù)架構(gòu)大模型應(yīng)用技術(shù)架構(gòu)代碼示例向 GPT-3.5 灌入新知識提示工程的意義和核心思想Prompt 典型構(gòu)成指令調(diào)優(yōu)方法論思維鏈和思維樹Prompt 攻擊和防范…第二階段30天高階應(yīng)用該階段我們正式進(jìn)入大模型 AI 進(jìn)階實戰(zhàn)學(xué)習(xí)學(xué)會構(gòu)造私有知識庫擴(kuò)展 AI 的能力?？焖匍_發(fā)一個完整的基于 agent 對話機(jī)器人。掌握功能最強(qiáng)的大模型開發(fā)框架抓住最新的技術(shù)進(jìn)展適合 Python 和 JavaScript 程序員。為什么要做 RAG搭建一個簡單的 ChatPDF檢索的基礎(chǔ)概念什么是向量表示Embeddings向量數(shù)據(jù)庫與向量檢索基于向量檢索的 RAG搭建 RAG 系統(tǒng)的擴(kuò)展知識混合檢索與 RAG-Fusion 簡介向量模型本地部署…第三階段30天模型訓(xùn)練恭喜你如果學(xué)到這里你基本可以找到一份大模型 AI相關(guān)的工作自己也能訓(xùn)練 GPT 了通過微調(diào)訓(xùn)練自己的垂直大模型能獨(dú)立訓(xùn)練開源多模態(tài)大模型掌握更多技術(shù)方案。到此為止大概2個月的時間。你已經(jīng)成為了一名“AI小子”。那么你還想往下探索嗎為什么要做 RAG什么是模型什么是模型訓(xùn)練求解器 損失函數(shù)簡介小實驗2手寫一個簡單的神經(jīng)網(wǎng)絡(luò)并訓(xùn)練它什么是訓(xùn)練/預(yù)訓(xùn)練/微調(diào)/輕量化微調(diào)Transformer結(jié)構(gòu)簡介輕量化微調(diào)實驗數(shù)據(jù)集的構(gòu)建…第四階段20天商業(yè)閉環(huán)對全球大模型從性能、吞吐量、成本等方面有一定的認(rèn)知可以在云端和本地等多種環(huán)境下部署大模型找到適合自己的項目/創(chuàng)業(yè)方向做一名被 AI 武裝的產(chǎn)品經(jīng)理。硬件選型帶你了解全球大模型使用國產(chǎn)大模型服務(wù)搭建 OpenAI 代理熱身基于阿里云 PAI 部署 Stable Diffusion在本地計算機(jī)運(yùn)行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何優(yōu)雅地在阿里云私有部署開源大模型部署一套開源 LLM 項目內(nèi)容安全互聯(lián)網(wǎng)信息服務(wù)算法備案…學(xué)習(xí)是一個過程只要學(xué)習(xí)就會有挑戰(zhàn)。天道酬勤你越努力就會成為越優(yōu)秀的自己。如果你能在15天內(nèi)完成所有的任務(wù)那你堪稱天才。然而如果你能完成 60-70% 的內(nèi)容你就已經(jīng)開始具備成為一名大模型 AI 的正確特征了。這份完整版的大模型 AI 學(xué)習(xí)資料已經(jīng)上傳CSDN朋友們?nèi)绻枰梢晕⑿艗呙柘路紺SDN官方認(rèn)證二維碼免費(fèi)領(lǐng)取【保證100%免費(fèi)】