1. 項目概述當智能體技能庫爆炸增長我們?nèi)绾尉珳省皩殹弊罱诟愦笠?guī)模智能體系統(tǒng)最頭疼的一個問題就是“技能檢索”。想象一下你手底下有成千上萬個智能體每個都身懷絕技技能比如“調(diào)用天氣API”、“生成SQL查詢”、“解析PDF表格”。當用戶提出一個復(fù)雜請求比如“幫我分析上個月的銷售數(shù)據(jù)并生成一份帶圖表的報告”時系統(tǒng)需要快速、準確地從這海量技能池里找出完成這個任務(wù)所需的那一串技能組合。這可不是簡單的關(guān)鍵詞匹配因為技能之間往往存在復(fù)雜的依賴關(guān)系——生成圖表前你得先有數(shù)據(jù)分析數(shù)據(jù)前你得先能查詢數(shù)據(jù)庫。傳統(tǒng)的基于語義相似度的檢索方法比如直接把用戶query和技能描述做向量匹配在這里就很容易“翻車”。它可能會給你返回一堆語義相關(guān)但邏輯上無法串聯(lián)的孤立技能就像給你一堆高級樂高零件卻沒給拼裝說明書。這就是“Graph-of-Skills: Dependency-Aware Structural Retrieval for Massive Agent Skills”這個項目要啃的硬骨頭。它的核心目標非常明確為大規(guī)模智能體技能庫構(gòu)建一個能理解技能間依賴關(guān)系的、圖結(jié)構(gòu)化的檢索系統(tǒng)。簡單說就是把技能當成節(jié)點把依賴關(guān)系比如A技能的輸出是B技能的輸入當成邊構(gòu)建一張巨大的“技能圖譜”。當用戶任務(wù)到來時系統(tǒng)不是找單個最相似的技能而是從這張圖譜里檢索出一個能連貫執(zhí)行、滿足所有前后置條件的“技能子圖”或“技能鏈”。我為什么覺得這個方向特別有意思因為在實踐中我們早就受夠了“檢索結(jié)果看起來都對一跑就報錯”的窘境。這個項目試圖將檢索過程從“語義匹配”升級到“邏輯規(guī)劃”讓智能體系統(tǒng)在“思考如何完成任務(wù)”的第一步就建立在堅實、可執(zhí)行的結(jié)構(gòu)化基礎(chǔ)之上。它適合所有正在構(gòu)建或研究復(fù)雜智能體應(yīng)用、AI工作流自動化、以及任何需要動態(tài)組合多種AI能力的開發(fā)者與研究員。接下來我就結(jié)合自己的理解和一些常見的工程實踐拆解一下實現(xiàn)這樣一個系統(tǒng)的核心思路、關(guān)鍵技術(shù)與那些容易踩坑的細節(jié)。2. 核心設(shè)計思路從“語義檢索”到“圖譜規(guī)劃”傳統(tǒng)的技能檢索可以看作一個“點對點”的匹配問題。系統(tǒng)有一個技能列表每個技能有一段自然語言描述。當用戶輸入查詢時系統(tǒng)用Embedding模型將所有技能描述和查詢都轉(zhuǎn)換成向量然后計算余弦相似度返回Top-K個最相似的技能。這種方法在技能數(shù)量少、技能間獨立性高時是有效的。但是當技能規(guī)模變大且技能間存在復(fù)雜依賴時這種方法的問題就暴露無遺忽略依賴它可能返回一個需要特定輸入格式的技能但這個技能所依賴的前置技能卻沒有被檢索出來。缺乏連貫性返回的多個技能之間可能無法連接無法形成完整的工作流。冗余與沖突可能返回功能重復(fù)的技能或者甚至返回在邏輯上相互沖突的技能比如兩個技能都試圖修改同一個系統(tǒng)狀態(tài)。Graph-of-Skills的思路本質(zhì)上是將問題從“檢索相似項”轉(zhuǎn)變?yōu)椤霸趫D結(jié)構(gòu)上尋找滿足約束的路徑或子圖”。這背后是思維范式的轉(zhuǎn)變。2.1 為什么是“圖”結(jié)構(gòu)圖Graph是描述實體及其關(guān)系最自然的數(shù)學(xué)結(jié)構(gòu)之一。在這個場景下節(jié)點Node代表一個具體的技能Skill。每個節(jié)點需要包含豐富的元數(shù)據(jù)例如技能描述自然語言描述用于語義檢索。輸入模式Input Schema明確聲明該技能需要什么樣的輸入。例如{“date”: “string”, “city”: “string”}。輸出模式Output Schema明確聲明該技能會產(chǎn)生什么樣的輸出。例如{“weather_condition”: “string”, “temperature”: number}。執(zhí)行代價預(yù)估的計算時間、費用或可靠性指標。邊Edge代表技能間的依賴關(guān)系。這是最關(guān)鍵的部分。依賴關(guān)系主要基于輸入輸出模式的匹配。類型一數(shù)據(jù)流依賴。這是最主要的邊。如果技能A的輸出模式能夠滿足技能B的輸入模式或其中一部分那么就存在一條從A到B的邊。這表示B可以在A執(zhí)行后執(zhí)行。類型二控制流依賴。例如技能B只有在技能A執(zhí)行成功或失敗時才能執(zhí)行。類型三資源/狀態(tài)依賴。例如兩個技能需要互斥地訪問同一個外部資源。將技能庫建模成圖之后一個復(fù)雜的用戶任務(wù)就可以被轉(zhuǎn)化為一個圖查詢問題給定一個用戶查詢起始狀態(tài)/目標描述在技能圖譜中找到一個連通子圖使得這個子圖能夠從初始輸入或可用數(shù)據(jù)出發(fā)經(jīng)過一系列節(jié)點技能執(zhí)行最終產(chǎn)生符合用戶期望的輸出。2.2 “Dependency-Aware”與“Structural Retrieval”意味著什么Dependency-Aware依賴感知這是系統(tǒng)的“認知”能力。檢索過程必須“知道”技能之間誰依賴誰。在計算一個技能與查詢的相關(guān)性時不僅要看它本身的描述還要考慮它的“上下文”——它的前驅(qū)技能是否也被檢索到它的后繼技能是否對完成最終目標有幫助這通常需要在檢索算法中引入圖傳播機制例如使用圖神經(jīng)網(wǎng)絡(luò)GNN來聚合鄰居節(jié)點的信息從而獲得包含結(jié)構(gòu)上下文的節(jié)點表征。Structural Retrieval結(jié)構(gòu)化檢索這是系統(tǒng)的“輸出”形式。它不再返回一個無序的技能列表而是返回一個結(jié)構(gòu)化的結(jié)果。這個結(jié)果可能是一條技能鏈一個有序序列也可能是一個技能DAG有向無環(huán)圖代表可以并行執(zhí)行的部分。這個結(jié)構(gòu)本身就直接是一個可執(zhí)行的工作流藍圖包含了執(zhí)行順序和數(shù)據(jù)的流動方向。這種設(shè)計思路的優(yōu)勢是巨大的。它讓智能體系統(tǒng)具備了初步的“規(guī)劃”能力。系統(tǒng)不再是被動地匹配關(guān)鍵詞而是主動地“組裝”解決方案。這對于實現(xiàn)真正的自主智能體Autonomous Agent至關(guān)重要。3. 系統(tǒng)核心模塊拆解與實現(xiàn)要點要構(gòu)建一個Graph-of-Skills系統(tǒng)我們可以將其分解為幾個核心模塊。下面我以一個假設(shè)的工程實現(xiàn)為例拆解每個部分的關(guān)鍵點。3.1 技能圖譜的構(gòu)建與表示這是所有工作的基石。圖譜的質(zhì)量直接決定了檢索的上限。3.1.1 技能定義與標準化首先我們需要一個嚴格的技能定義規(guī)范。每個技能必須用結(jié)構(gòu)化的方式描述。我推薦使用類似JSON Schema的格式來定義輸入輸出。{ skill_id: fetch_weather, name: 獲取城市天氣, description: 根據(jù)給定的城市名和日期查詢該城市當天的天氣情況。, input_schema: { type: object, properties: { city: {type: string, description: 城市名稱如‘北京’}, date: {type: string, description: 日期格式Y(jié)YYY-MM-DD} }, required: [city, date] }, output_schema: { type: object, properties: { weather_condition: {type: string, description: 天氣狀況如‘晴’、‘多云’}, temperature_high: {type: number, description: 最高氣溫攝氏度}, temperature_low: {type: number, description: 最低氣溫攝氏度} } }, endpoint: http://api.internal/weather, // 技能的執(zhí)行端點 cost: 0.001 // 執(zhí)行代價可用于優(yōu)化 }注意description字段至關(guān)重要它將是語義Embedding的主要來源。描述要盡可能準確、包含關(guān)鍵實體和動作避免歧義。3.1.2 依賴邊Dependency Edge的自動發(fā)現(xiàn)手動為成千上萬的技能建立依賴關(guān)系是不現(xiàn)實的。必須實現(xiàn)自動化。核心思路是模式匹配。輸出模式與輸入模式的匹配這是最直接的依賴。我們可以計算兩個模式之間的兼容性。一個簡單但有效的方法是基于描述的匹配將技能A的output_schema中每個字段的description拼接起來生成一段文本“輸出包含[字段1描述]、[字段2描述]...”。將技能B的input_schema中每個字段的description拼接起來生成一段文本“需要輸入[字段1描述]、[字段2描述]...”。使用一個輕量級的句子相似度模型如Sentence-BERT計算這兩段文本的相似度。如果相似度超過閾值如0.7則認為A的輸出“可能”滿足B的輸入建立一條從A到B的候選邊。類型與名稱匹配除了描述還可以結(jié)合字段的name和type。如果A的輸出有一個字段{name: city, type: string}而B的輸入有一個字段{name: location, type: string}即使描述不同通過名稱和類型的相似度可用編輯距離、詞向量相似度也能發(fā)現(xiàn)潛在關(guān)聯(lián)。人工校驗與反饋閉環(huán)自動發(fā)現(xiàn)的邊必然存在噪聲。初期需要引入人工校驗環(huán)節(jié)對高置信度或高頻使用的邊進行確認。同時系統(tǒng)在運行時可以收集數(shù)據(jù)如果技能B在實際執(zhí)行中經(jīng)常成功使用技能A的輸出作為輸入那么這條邊的權(quán)重就應(yīng)該增強。這形成了一個動態(tài)演化的圖譜。3.1.3 圖譜的存儲與索引對于大規(guī)模圖譜我們需要專門的圖數(shù)據(jù)庫如Neo4j, NebulaGraph或支持圖查詢的向量數(shù)據(jù)庫如Weaviate, Milvus 2.0。圖數(shù)據(jù)庫擅長處理復(fù)雜的圖遍歷查詢。我們可以很方便地查詢“從技能X出發(fā)3步之內(nèi)能到達的所有技能”。向量數(shù)據(jù)庫擅長基于向量的相似性搜索。我們需要存儲每個技能的向量化表征基于描述生成?；旌戏桨敢粋€常見的實踐是使用向量數(shù)據(jù)庫存儲節(jié)點技能的嵌入向量用于快速的語義檢索同時維護一個輕量的圖結(jié)構(gòu)在內(nèi)存或圖數(shù)據(jù)庫中用于執(zhí)行依賴感知的排序和路徑查找。兩者通過技能ID關(guān)聯(lián)。3.2 依賴感知的檢索算法這是系統(tǒng)的“大腦”。當用戶查詢到來時算法需要在圖譜中尋找最優(yōu)的技能子圖。這個過程通常是多階段的。3.2.1 檢索階段一語義召回Semantic Recall目標快速從海量技能中找到一批與用戶查詢語義相關(guān)的“種子技能”。操作將用戶查詢q編碼成向量v_q。在向量數(shù)據(jù)庫中搜索與v_q最相似的Top-N個技能節(jié)點比如N50。這一步不考慮依賴只求全防止遺漏。技術(shù)要點這里的Embedding模型選擇很重要。通用模型如text-embedding-ada-002可能不夠好。如果領(lǐng)域特定可以考慮用技能描述和查詢樣本對微調(diào)一個模型讓模型更能理解“技能”這種特殊文本的語義。3.2.2 檢索階段二圖傳播與重排序Graph Propagation Re-ranking目標對召回的一批種子技能利用圖譜中的依賴關(guān)系評估其作為“解決方案一部分”的合理性并進行重排序。操作以每個種子技能為起點或終點在圖譜上進行有限步數(shù)如2-3步的游走或信息傳播。例如前向傳播如果一個技能被檢索到那么它的后繼技能它能夠“激活”的技能也可能相關(guān)即使其描述與查詢直接相似度不高。后向傳播如果一個技能被檢索到那么它的前驅(qū)技能能夠“產(chǎn)生”它所需輸入的技能也應(yīng)該被考慮進來以確?？蓤?zhí)行性。算法示例 - 個性化PageRank變體我們可以將用戶查詢與技能的初始相關(guān)度作為節(jié)點的初始“能量”然后在圖譜上運行隨機游走。技能節(jié)點之間的邊權(quán)重可以根據(jù)模式匹配的置信度來設(shè)置。經(jīng)過幾輪迭代后每個節(jié)點會獲得一個新的分數(shù)這個分數(shù)既反映了它與查詢的語義相似度也反映了它在圖譜結(jié)構(gòu)中的“樞紐”地位——即它是否連接著許多其他相關(guān)技能。分數(shù)高的節(jié)點更可能成為工作流中的關(guān)鍵環(huán)節(jié)。輸出經(jīng)過圖傳播重排序后我們得到一個新的、考慮了結(jié)構(gòu)信息的技能列表。3.2.3 檢索階段三子圖搜索與規(guī)劃Subgraph Search Planning目標將重排序后的技能列表組合成一個連貫、可執(zhí)行的技能子圖工作流。操作這本質(zhì)上是一個搜索問題。我們可以將用戶查詢的“目標”和“初始輸入”也視為特殊的節(jié)點。然后使用圖搜索算法如A*搜索、束搜索Beam Search在技能圖譜中尋找一條或多條從“初始輸入”節(jié)點到“目標”節(jié)點的路徑。搜索的關(guān)鍵是定義一個好的代價函數(shù)。代價可以包括路徑上所有技能的執(zhí)行代價總和。技能節(jié)點與查詢目標的語義距離。路徑的復(fù)雜度節(jié)點數(shù)、分支數(shù)。結(jié)果算法輸出一個或多個技能序列鏈或技能DAG。對于簡單任務(wù)可能是一條鏈對于復(fù)雜任務(wù)如“獲取天氣并生成詩歌”可能需要一個能合并多個信息源并行的DAG。3.3 系統(tǒng)架構(gòu)與工作流一個完整的系統(tǒng)架構(gòu)可能如下所示用戶查詢 | v [查詢理解與向量化模塊] | v [語義召回模塊] (向量數(shù)據(jù)庫) | - 召回Top-N技能ID列表 v [圖譜服務(wù)] (圖數(shù)據(jù)庫/內(nèi)存圖) | - 獲取召回技能的鄰居、執(zhí)行圖傳播算法 v [規(guī)劃器模塊] | - 執(zhí)行子圖搜索生成候選工作流 v [工作流編排與執(zhí)行引擎] | - 按依賴關(guān)系調(diào)度技能執(zhí)行 v 最終結(jié)果實操心得冷啟動問題系統(tǒng)初期技能少依賴邊更少圖傳播的效果不明顯。此時可以更多地依賴語義召回并可以引入一些啟發(fā)式規(guī)則如優(yōu)先選擇輸入簡單的技能作為起點。增量更新技能庫是動態(tài)增長的。系統(tǒng)需要支持增量更新圖譜和向量索引不能每次新增技能都全量重建。評估指標如何評估檢索結(jié)果的好壞不能只看檢索出的技能本身要看最終組裝的工作流的執(zhí)行成功率。需要建立一套離線評估體系用歷史任務(wù)或合成任務(wù)來測試。4. 關(guān)鍵挑戰(zhàn)與應(yīng)對策略實錄在實際構(gòu)建這類系統(tǒng)時會遇到許多預(yù)料之中和預(yù)料之外的挑戰(zhàn)。下面分享幾個我遇到或預(yù)見到的主要問題及其應(yīng)對思路。4.1 挑戰(zhàn)一技能描述的模糊性與歧義技能描述由人編寫質(zhì)量參差不齊?！疤幚頂?shù)據(jù)”這種模糊描述可能對應(yīng)清洗、轉(zhuǎn)換、分析等多種具體技能。問題表現(xiàn)基于描述的語義檢索準確率低依賴邊自動發(fā)現(xiàn)錯誤率高。應(yīng)對策略制定嚴格的描述規(guī)范要求描述必須包含“動作對象約束”三要素。例如將“處理數(shù)據(jù)”改為“使用Pandas對結(jié)構(gòu)化CSV數(shù)據(jù)進行缺失值填充和去重”。多模態(tài)技能表征不僅僅依賴文本描述?？梢越Y(jié)合技能的代碼片段如果有、輸入輸出示例Example I/O來生成更豐富的向量表征。例如將描述、輸入JSON Schema示例、輸出JSON Schema示例拼接起來再編碼。利用執(zhí)行日志如果技能已被使用過收集其真實的輸入輸出數(shù)據(jù)。這些數(shù)據(jù)是描述其功能最準確的“Ground Truth”可以用來微調(diào)Embedding模型或驗證依賴邊。4.2 挑戰(zhàn)二依賴關(guān)系的復(fù)雜性與動態(tài)性依賴不僅僅是“A的輸出給B用”。還有條件依賴、資源競爭、副作用等。問題表現(xiàn)檢索出的技能鏈在邏輯上正確但實際執(zhí)行時因資源沖突或狀態(tài)不符而失敗。應(yīng)對策略細化依賴類型在圖譜中定義多種邊類型。除了主要的數(shù)據(jù)流依賴provides_input_for可以增加requires_resource需要資源、mutually_exclusive_with互斥、followed_by通常緊隨其后等類型。引入狀態(tài)與上下文在檢索和規(guī)劃時不僅考慮技能本身還要考慮當前的系統(tǒng)狀態(tài)如已加載的數(shù)據(jù)、占用的資源。這需要將“狀態(tài)”也建模為圖譜中的節(jié)點技能執(zhí)行會改變狀態(tài)節(jié)點。實時驗證在最終執(zhí)行前加入一個“預(yù)驗證”步驟。規(guī)劃器生成工作流后用一個輕量的模擬器快速檢查關(guān)鍵依賴特別是資源類是否可能沖突。4.3 挑戰(zhàn)三檢索效率與規(guī)模的平衡當技能庫達到十萬、百萬級別時進行多階段的圖檢索和規(guī)劃耗時可能無法滿足實時交互的需求。問題表現(xiàn)用戶查詢響應(yīng)慢體驗差。應(yīng)對策略分層索引對技能進行分層或分簇。先根據(jù)粗粒度類別如“數(shù)據(jù)獲取”、“文本處理”、“圖像生成”過濾掉大量不相關(guān)的技能再在相關(guān)類別內(nèi)進行精細的圖檢索。近似搜索與剪枝在圖傳播和子圖搜索中使用近似算法。例如在個性化PageRank中只迭代有限輪數(shù)在束搜索Beam Search中只保留最優(yōu)的K條路徑。緩存結(jié)果對于常見或相似的查詢可以直接緩存其檢索出的工作流模板。當新查詢到來時先與緩存中的查詢進行相似度匹配如果匹配度高則直接返回緩存的工作流只需替換其中的具體參數(shù)。離線預(yù)計算可以離線運行一些常見目標或“虛擬查詢”的規(guī)劃預(yù)生成一些常用的技能鏈模板在線檢索時直接匹配和微調(diào)這些模板。4.4 挑戰(zhàn)四評估與迭代閉環(huán)如何知道系統(tǒng)在變好需要一個可靠的評估體系。問題表現(xiàn)改了算法但不知道效果是提升還是下降。應(yīng)對策略構(gòu)建測試任務(wù)集收集或人工編寫一批有標準答案的復(fù)雜任務(wù)。每個任務(wù)對應(yīng)一個或多個理想的技能工作流。定義多維度指標召回率K理想工作流中的技能有多少出現(xiàn)在檢索結(jié)果的前K位。規(guī)劃成功率系統(tǒng)生成的技能鏈能否在不報錯的情況下執(zhí)行完畢。執(zhí)行結(jié)果質(zhì)量最終輸出與期望結(jié)果的匹配度可用文本相似度、任務(wù)特定指標衡量。規(guī)劃效率生成工作流所需的時間。在線A/B測試在真實產(chǎn)品流量中對比新舊檢索算法的效果核心看任務(wù)最終完成率和用戶滿意度。5. 進階思考從檢索到生成與協(xié)同Graph-of-Skills提供了一個強大的結(jié)構(gòu)化檢索基礎(chǔ)但它的潛力不止于此。結(jié)合當前AI的發(fā)展我們可以展望幾個進階方向。5.1 與LLM協(xié)同的混合規(guī)劃大語言模型LLM在理解和分解復(fù)雜任務(wù)方面展現(xiàn)出驚人能力但在精確遵循規(guī)則、保證邏輯嚴謹性上時有不足。而Graph-of-Skills強于邏輯和結(jié)構(gòu)但對開放域、未見過的任務(wù)理解有限。兩者可以形成完美互補。工作流LLM作為“任務(wù)分解器”用戶輸入復(fù)雜任務(wù)后先由LLM將其分解為一系列清晰的子目標Step-by-Step。LLM還可以為每個子目標生成一個詳細的“需求描述”。Graph-of-Skills作為“技能匹配與組裝器”將LLM生成的每個子目標“需求描述”作為查詢輸入到技能圖譜檢索系統(tǒng)中。系統(tǒng)為每個子目標找到最匹配的技能或技能鏈。LLM作為“粘合劑”與“校驗器”將檢索出的技能鏈組裝成完整工作流后可以再交給LLM進行“自然語言審查”。LLM可以判斷這個工作流在常識上是否合理并生成給用戶看的、通俗易懂的執(zhí)行計劃說明。在執(zhí)行過程中如果某個技能失敗LLM還可以根據(jù)錯誤信息嘗試調(diào)整需求描述重新觸發(fā)檢索。這種混合架構(gòu)既利用了LLM的泛化理解能力又依靠結(jié)構(gòu)化圖譜保證了解決方案的可靠性和可執(zhí)行性是當前構(gòu)建可靠智能體系統(tǒng)的熱門架構(gòu)。5.2 動態(tài)技能圖譜與終身學(xué)習(xí)技能庫不是靜態(tài)的。新的技能會被不斷創(chuàng)建現(xiàn)有技能也可能被更新或淘汰。技能圖譜需要支持動態(tài)演化。實現(xiàn)思路自動化圖譜更新流水線當一個新的技能被注冊到系統(tǒng)時自動觸發(fā)以下流程1生成技能向量存入向量庫2基于模式匹配自動發(fā)現(xiàn)與該技能相關(guān)的潛在依賴邊入邊和出邊以低置信度加入圖譜3將新技能及候選邊推送給管理員或通過眾包進行確認。基于執(zhí)行的反饋學(xué)習(xí)這是讓圖譜“活”起來的關(guān)鍵。系統(tǒng)記錄每次工作流的執(zhí)行軌跡哪些技能被依次成功執(zhí)行了。這些成功的軌跡是最可靠的依賴關(guān)系證據(jù)。我們可以用這些數(shù)據(jù)來強化已有邊對于軌跡中連續(xù)出現(xiàn)的技能對(A-B)提高它們之間依賴邊的權(quán)重。發(fā)現(xiàn)隱藏邊可能有些依賴無法通過模式匹配發(fā)現(xiàn)但執(zhí)行日志顯示它們總是一起出現(xiàn)這提示我們可能存在未定義的依賴需要人工審查添加。淘汰無效邊如果一條邊從未出現(xiàn)在成功軌跡中或者其連接的兩個技能在連續(xù)執(zhí)行時總是失敗那么這條邊的權(quán)重應(yīng)該被降低直至被移除。這樣一個系統(tǒng)就具備了終身學(xué)習(xí)的能力隨著使用越來越頻繁它對技能間關(guān)系的理解會越來越精準。5.3 面向復(fù)雜目標的層次化圖譜對于超大規(guī)模技能庫扁平的圖譜可能變得難以管理和檢索。我們可以引入層次化結(jié)構(gòu)。抽象技能Meta-Skill將一系列經(jīng)常連續(xù)執(zhí)行、完成一個特定子目標的技能鏈打包成一個“抽象技能”。例如“數(shù)據(jù)獲取與清洗”這個抽象技能內(nèi)部可能包含了“調(diào)用API A”、“解析JSON”、“數(shù)據(jù)去重”三個具體技能。構(gòu)建層次化圖譜圖譜中既有底層的具體技能節(jié)點也有上層的抽象技能節(jié)點。抽象技能節(jié)點通過“包含”邊連接到其下屬的具體技能子圖。當用戶查詢一個高級目標時系統(tǒng)可以先在抽象技能層進行檢索找到合適的抽象技能后再將其展開為具體的工作流。好處這大大提高了檢索效率和可管理性。同時也更符合人類的思維習(xí)慣——我們思考復(fù)雜任務(wù)時也是先分解成幾個大步驟再細化每個步驟。構(gòu)建一個真正可用、好用的Graph-of-Skills系統(tǒng)是一項充滿挑戰(zhàn)但也極具價值的工程。它不僅僅是實現(xiàn)一個檢索算法更是為智能體系統(tǒng)構(gòu)建一個可擴展、可演化、具備常識的“技能大腦”。從精準的技能定義開始到自動化的依賴發(fā)現(xiàn)再到高效的混合檢索與規(guī)劃每一步都需要精心設(shè)計。在這個過程中最大的體會是數(shù)據(jù)和反饋閉環(huán)比算法本身更重要。一個能從每一次成功和失敗中學(xué)習(xí)的動態(tài)圖譜遠比一個靜態(tài)的、精心設(shè)計的圖譜更有生命力。