你被“模型選錯工具”折磨過嗎我遇到過。項目初期我把每個小操作都注冊成function calling工具搜索、打開網(wǎng)頁、解析PDF、發(fā)郵件、寫文件全都平鋪在工具列表里。結(jié)果用戶說“幫我查一下XX公司最近動態(tài)”模型打開了郵件發(fā)送窗口。后來我把散落的工具重構(gòu)成一套可插拔的能力單元倉庫代號就叫 agent-skills。它解決的問題很簡單讓LLM智能體在面對幾十個操作入口時能像人一樣先判斷“這是哪類任務(wù)”再按一套標(biāo)準(zhǔn)作業(yè)流程執(zhí)行而不是在工具海洋里瞎猜。如果你也在做Agent或自動化應(yīng)用或者正被工具描述詞窮搞到頭大這篇內(nèi)容值得你看完。1. 為什么需要“技能層”工具函數(shù)與技能的差別在哪里1.1 工具函數(shù)“散裝”模式的崩潰點在做 agent-skills 之前我經(jīng)歷了一段非常典型的“工具爆炸”階段。當(dāng)時Agent要支持的能力包括搜索公開網(wǎng)頁、抽取網(wǎng)頁正文、解析PDF、識別圖片里的大段文字、讀取Excel、執(zhí)行一段Python代碼、發(fā)郵件、寫本地文件、調(diào)用內(nèi)部API。為了趕進(jìn)度我把這些能力全部注冊成一個個獨立的function直接傳給模型。一開始只有十個左右效果勉強能接受等數(shù)量加到幾十個問題開始集中爆發(fā)。最明顯的就是模型經(jīng)常選錯工具。用戶說“幫我把這個PDF里的結(jié)論整理到表格里”模型可能先調(diào)用“打開PDF”再去調(diào)“讀取Excel”最后也沒把結(jié)論整理出來。還有更常見的模型能選對工具但參數(shù)填得亂七八糟時間范圍寫成“最近三天”搜索API實際要求的是7d這種格式文件路徑給了相對路徑技能里處理路徑的代碼卻是按絕對路徑寫的。當(dāng)時我以為是模型能力不行反復(fù)換模型、調(diào)溫度結(jié)果都沒用。后來我看明白了問題不在模型在我的設(shè)計。把幾十個零散工具直接暴露給模型相當(dāng)于讓一個實習(xí)生站在堆滿零件的工作臺前不給他任何流程手冊卻指望他每次都準(zhǔn)確挑出合適的零件并把設(shè)備裝好。模型天然不擅長在超長列表里做高密度選擇。于是我決定把“工具”升級為“技能”把描述粒度從“單個動作”拉高到“一個完整的能力場景”。1.2 技能層的核心設(shè)計哲學(xué)給模型一份SOP那工具和技能的核心差別到底是什么工具描述的是“我能做什么動作”技能描述的是“什么場景下該用我、怎么用、出了問題怎么辦”。一個人知道扳手怎么握不代表他能換輪胎但給一個人一份“換輪胎作業(yè)指導(dǎo)書”里面寫了頂車位置、螺絲拆卸順序、扭矩要求、滑絲處理方法他就有機會獨立完成整個任務(wù)。技能層就是給模型的那份作業(yè)指導(dǎo)書。在 agent-skills 里每個技能不再只是一段Python函數(shù)和一句description而是一個完整的獨立單元它有自己的元信息聲明、參數(shù)校驗、實現(xiàn)代碼、依賴文件、測試用例甚至權(quán)限聲明。模型看到的是收斂后的“技能清單”選中某一個技能后運行器才會把該技能的詳細(xì)操作步驟注入上下文。這樣既避免了把大量內(nèi)部邏輯塞給模型也讓每個技能可以單獨打磨、單獨測試、單獨隔離權(quán)限。用表格對比一下這種差異方便你在自己項目里做判斷對比維度工具函數(shù)Function Calling技能Skill粒度單個原子動作完整能力場景可含多個步驟描述重點參數(shù)和功能適用場景、觸發(fā)條件、邊界、錯誤恢復(fù)模型負(fù)擔(dān)每次都要在長列表里單選先選技能再按技能內(nèi)說明執(zhí)行維護(hù)方式散落在各段業(yè)務(wù)代碼中獨立目錄依賴、測試、權(quán)限內(nèi)聚權(quán)限控制粗粒度所有工具同權(quán)限按技能聲明所需權(quán)限便于沙箱隔離錯誤處理常常直接拋異常內(nèi)建恢復(fù)路徑給Agent可讀的錯誤反饋我得強調(diào)一句這不代表 function calling 沒有價值。它依然是技能層底下最核心的協(xié)議技能最終還是要通過函數(shù)的形態(tài)暴露給模型。只是你不該讓模型直接面對那一堆零碎函數(shù)而是先暴露技能清單把實現(xiàn)細(xì)節(jié)藏在后面。2. agent-skills 的目錄設(shè)計先把骨架搭穩(wěn)2.1 每個技能一個目錄天然隔離邊界我最終采用的目錄結(jié)構(gòu)是這樣agent-skills/ ├── runner/ # 技能運行器 注冊邏輯 │ ├── loader.py │ ├── schema_validator.py │ └── sandbox.py ├── skills/ │ ├── web_search/ # 一個技能一個目錄 │ │ ├── SKILL.md # 技能聲明 │ │ ├── main.py # 技能實現(xiàn) │ │ ├── requirements.txt # 獨立依賴 │ │ └── tests/ │ │ └── test_search.py │ ├── pdf_extract/ │ │ ├── SKILL.md │ │ ├── main.py │ │ └── ... │ └── code_executor/ │ ├── SKILL.md │ ├── main.py │ └── ... ├── agents/ │ └── demo_agent.py # 接入了技能注冊中心的最小Agent └── pyproject.toml為什么不讓所有技能代碼平鋪在一個包里三個原因。第一依賴隔離。 web_search 要用 httpxpdf_extract 要裝 pdfplumbercode_executor 可能要起一個臨時子進(jìn)程環(huán)境。技能之間不應(yīng)該共享同一套依賴否則裝一個技能就可能導(dǎo)致另一個技能跑不起來。第二權(quán)限邊界清晰。沙箱執(zhí)行時可以按目錄判定技能聲明的權(quán)限比如 code_executor 需要高風(fēng)險權(quán)限web_search 只需要網(wǎng)絡(luò)權(quán)限。給單個技能單獨開沙箱比給整個Agent進(jìn)程開權(quán)限要安全得多。第三版本管理方便。每個技能可以單獨發(fā)版甚至用 Git submodule 組織成共享技能庫多團(tuán)隊各自維護(hù)技能互不阻塞。2.2 SKILL.md技能的門面也是模型的說明書每個技能目錄里最重要的文件是 SKILL.md。它的結(jié)構(gòu)是 YAML frontmatter 加自由正文有點類似靜態(tài)站點的 Markdown 文檔。frontmatter 是給運行器和模型做“選擇決策”用的正文是技能被選中后給模型看的具體執(zhí)行說明。--- name: web_search version: 1.3.0 description: 在互聯(lián)網(wǎng)上搜索公開網(wǎng)頁內(nèi)容返回標(biāo)題、鏈接和摘要。適合查找事實、新聞、產(chǎn)品資料不適合訪問需要登錄的頁面也不能讀取本地文件。 permissions: network: true filesystem: none subprocess: false timeout: 30 inputs: - name: query type: string description: 搜索關(guān)鍵詞盡量用完整短語不用URL編碼 required: true - name: max_results type: integer description: 最多返回多少條結(jié)果默認(rèn)5最大10 default: 5 outputs: - result: type: array description: 搜索結(jié)果列表每項包含title, url, snippet --- # web_search 在調(diào)用本技能前先確認(rèn)用戶意圖是否滿足“搜索公開網(wǎng)頁”這一條件。 如果用戶需要的是當(dāng)前日期、天氣、股票行情這類動態(tài)數(shù)據(jù)這個技能同樣適用。 但如果是查詢數(shù)據(jù)庫或內(nèi)部文檔系統(tǒng)請改用 database_query 技能。 ## 使用步驟 1. 從參數(shù)中拿到 query。 2. 調(diào)用搜索引擎接口。 3. 對結(jié)果做去重排序。 4. 如果結(jié)果為空返回錯誤碼 EMPTY_RESULTS。 ## 邊界條件 - 不訪問需要登錄的頁面。 - 不下載二進(jìn)制文件。 - 只返回前 max_results 條結(jié)果。這份文件同時服務(wù)人和模型。模型主要通過 description 字段做技能選擇自由正文則是當(dāng)模型選中技能后由Agent執(zhí)行器注入到上下文里的操作指引。所以 description 要克制正文可以放開寫。很多項目的教訓(xùn)是正文寫太短模型等于拿著殘缺流程干活description 寫太長模型還沒選技能就已經(jīng)被超大上下文弄暈了。2.3 搭骨架時踩過的坑第一坑技能名用了英文空格和大小寫混拼比如Web Search、PDF_Extract_File。模型真的會記錯名字而且不同模型對駝峰和下劃線的處理不完全一致。后來我統(tǒng)一改成全小寫加下劃線snake_case并在加載時做了別名映射老調(diào)用還能兼容。第二坑description 寫得像功能宣傳冊塞進(jìn)了“支持并發(fā)、支持自定義超時、支持重試”這類實現(xiàn)細(xì)節(jié)。模型面對這種描述無法判斷它該什么時候用只覺得這工具很全能于是什么都想讓它做。描述應(yīng)該寫“什么時候用、什么時候千萬別用”而不是“我有多強”。第三坑requirements.txt 不鎖版本。demo時沒事?lián)Q臺機器跑依賴大版本升級技能直接崩。踩了一次之后就老老實實鎖版本并在CI里加“干凈環(huán)境安裝冒煙測試”的步驟。凡是能自動化驗證的盡量不要靠人肉記憶。3. 讓模型真正“會用”技能從描述到參數(shù)再到輸出3.1 description 是路由信號不是宣傳文案技能注冊給模型時模型要在一次推理里決定從所有技能中選哪個。這個決策幾乎完全依賴技能名和description。我的經(jīng)驗是description 最好采用“一句話觸發(fā)條件 一句話反例 一兩個核心關(guān)鍵詞補充”的結(jié)構(gòu)總長度控制在300個漢字以內(nèi)。不要堆形容詞不要寫實現(xiàn)細(xì)節(jié)。舉個例子差web_search 技能通過各大搜索引擎獲取搜索結(jié)果支持高級檢索語法可以自定義時間范圍支持批量查詢內(nèi)置結(jié)果解析性能可靠。好搜索公開網(wǎng)頁返回標(biāo)題鏈接摘要。適合找事實、新聞、產(chǎn)品資料。不適合讀本地文件、不適合查內(nèi)部系統(tǒng)。第一版描述的問題是模型會高估能力范圍。比如用戶說“幫我把這份PDF里的結(jié)論搜出來”模型可能會誤以為 web_search 能直接讀PDF。正確描述要主動劃清邊界。不要怕在description里寫“不擅長什么”這些否定信息才是真正幫助模型做路由決策的。3.2 參數(shù)Schema給模型看的注釋比類型重要很多人在注冊工具時只寫一個JSON Schema雛形字段類型、required 標(biāo)一下就完事。但我后來發(fā)現(xiàn)模型對參數(shù)的理解主要來自字段名和description當(dāng)字段名有歧義時參數(shù)就會填錯。比如搜索時間范圍有人寫time_range類型是字符串模型根本不知道格式是7d、1m還是2024-01-01~2024-02-01。正確的做法是在 description 里給一個具體格式并且配合examples{ type: object, properties: { query: { type: string, description: 搜索關(guān)鍵詞完整短語不要URL編碼, examples: [大模型 Agent 開源工具] }, time_range: { type: string, description: 時間范圍可選值1d/7d/30d/1y/all, enum: [1d, 7d, 30d, 1y, all], default: all } }, required: [query] }如果參數(shù)值只能有幾個固定選項務(wù)必用 enum如果格式有嚴(yán)格要求在 description 里寫正則或直接給示例。這不算對模型的“溺愛”而是降低自由度的有效手段。Agent應(yīng)用里參數(shù)合法率直接決定任務(wù)成功率一個填錯的路徑或者時間格式可能讓后面的所有邏輯全部白跑。3.3 輸出結(jié)構(gòu)讓Agent在下一步能接著用技能執(zhí)行完不能只丟一段文本。比如 web_search 如果返回一段帶HTML標(biāo)簽的文本模型還要自己解析如果技能返回 JSON模型就能直接提取字段去進(jìn)行下一步。我統(tǒng)一用一套輸出結(jié)構(gòu){ success: true, result: [...], error_code: null, message: 共找到6條結(jié)果 }錯誤時{ success: false, result: null, error_code: EMPTY_RESULTS, message: 沒有搜索結(jié)果可以嘗試更換關(guān)鍵詞或擴大時間范圍 }這里的 message 字段是寫給模型看的補救建議不是單純報錯。模型拿到EMPTY_RESULTS之后自然會生成“那我換個關(guān)鍵詞再搜一次”的下一步動作。如果你的技能只是返回一個空列表模型往往會愣住然后開始編造一個不存在的搜索結(jié)果這是Agent應(yīng)用里非常危險的幻覺來源。所以不要指望Agent去猜失敗原因直接把恢復(fù)路徑寫進(jìn)錯誤消息。3.4 技能內(nèi)錯誤恢復(fù)的落地方案在技能實現(xiàn)里我會在統(tǒng)一入口包一層 try/except把異常轉(zhuǎn)成上文的錯誤結(jié)構(gòu)。比如調(diào)用搜索接口超時如果是可重試的5xx錯誤技能內(nèi)部自動重試兩次如果重試還失敗返回錯誤碼SEARCH_API_ERRORmessage 里寫“接口暫不可用建議稍后再試或縮小搜索范圍”。這樣模型不需要自己學(xué)會寫重試邏輯因為技能層已經(jīng)處理掉了。另外技能的冪等性也值得考慮。一個技能如果可能被Agent連續(xù)調(diào)用兩次它不應(yīng)該在第二次產(chǎn)生額外副作用。搜索、PDF抽取這類操作天然安全文件寫入、發(fā)郵件、創(chuàng)建訂單這類技能就要非常小心。我在 SKILL.md 里增加了一個side_effect字段標(biāo)注該技能是否會產(chǎn)生外部副作用Agent執(zhí)行前會據(jù)此做二次確認(rèn)。這個字段看起來不起眼但上線后救過我好幾次。4. 調(diào)試與評測技能庫不是能跑通demo就夠了4.1 每項技能都要有最小驗證樣本加入一個新技能時我會同時寫一個tests/test_sanity.py用最小輸入跑一遍斷言輸出結(jié)構(gòu)是合法的。比如 web_search 的 sanity test 就是傳一個簡單的 query斷言返回結(jié)果是數(shù)組數(shù)組里的每一項都有 title、url、snippet。CI 里對所有技能并行跑 sanity test確保技能之間不互相污染。這一步成本不高但能攔住大量低級問題。更關(guān)鍵的是這個 sanity test 要在干凈的虛擬環(huán)境里跑。技能目錄里的 requirements.txt 就是為這個準(zhǔn)備的。很多項目里的技能在開發(fā)機上跑得好好的部署到新環(huán)境就崩絕大多數(shù)原因都是依賴沒鎖好。把“干凈環(huán)境安裝冒煙測試”加進(jìn)CI之后這個問題基本絕跡。4.2 記錄調(diào)用軌跡做成回歸測試調(diào)Agent類應(yīng)用時我最后悔的事就是沒有從第一天開始記錄調(diào)用軌跡。所謂調(diào)用軌跡就是每一次“用戶請求 → 模型選擇了哪個技能 → 參數(shù)是什么 → 技能返回什么 → 用戶怎么反饋”的完整記錄。后來我把這些記錄轉(zhuǎn)成回歸測試集固定輸入再跑一遍看技能選擇有沒有偏移?；貧w里最典型的一個案例我把某技能的 description 增加了一個“不適合做XX”的反例結(jié)果原本正確的選擇反而飄了模型開始頻繁選另一個技能。原因可能是總體上下文變長模型注意力被稀釋。這類問題非常容易出現(xiàn)在“描述越寫越長”之后。所以我的規(guī)則是每次改描述必須跑一遍回歸集不能只看單條效果。4.3 我用來量化的幾個指標(biāo)指標(biāo)含義我的達(dá)標(biāo)線技能選擇準(zhǔn)確率正確技能是否被選中不低于95%參數(shù)合法率參數(shù)通過JSON Schema校驗不低于98%任務(wù)成功率端到端用戶目標(biāo)達(dá)成不低于80%平均調(diào)用輪數(shù)完成任務(wù)所需模型調(diào)用次數(shù)越低越好技能返回可解析率輸出能被下一步直接消費不低于99%參數(shù)合法率這個指標(biāo)我單獨看因為很多“Agent效果差”最后都能歸因到參數(shù)填錯時間格式錯、路徑寫錯、JSON里套了多余引號。技能消費的對象是模型而不是人所以參數(shù)校驗要嚴(yán)格一點一旦非法就直接讓模型重填不要硬著頭皮執(zhí)行。4.4 本地評測時我常用的套路本地評測我習(xí)慣用一個 fake LLM 來模擬“會按腳本調(diào)用技能的 Agent”而不是每次都燒真實模型。先用少量真實調(diào)用記錄生成樣本再在 pytest 里構(gòu)造一個最小 agent runner把技能選擇器配置成手工指定然后跑一遍技能邏輯。這樣能快速發(fā)現(xiàn)技能實現(xiàn)本身的bug而不是把模型判斷和技能實現(xiàn)混在一起排查。排查順序也有講究先懷疑技能實現(xiàn)再懷疑描述最后才懷疑模型。因為數(shù)據(jù)和代碼的bug是確定的描述和模型是概率性的。我見過太多人一遇到Agent效果不穩(wěn)就怪模型查下來卻是技能輸出結(jié)構(gòu)不統(tǒng)一模型被迫去猜“這個結(jié)果到底成功了沒”那它只能亂說。5. 把 agent-skills 接到真實 Agent 里加載、沙箱與生產(chǎn)細(xì)節(jié)5.1 動態(tài)加載與注冊技能運行器最核心的一件事掃描 skills 目錄解析 SKILL.md把技能注冊成模型可調(diào)用的工具列表。簡化版 loader 長這樣import pathlib import yaml import importlib.util SKILLS_ROOT pathlib.Path(skills) def load_skills(): tools [] for skill_dir in SKILLS_ROOT.iterdir(): manifest_path skill_dir / SKILL.md if not manifest_path.exists(): continue raw manifest_path.read_text(encodingutf-8) frontmatter parse_frontmatter(raw) # 從 --- 之間取 YAML module load_skill_module(skill_dir, frontmatter[name]) tools.append({ type: function, function: { name: frontmatter[name], description: frontmatter[description], parameters: frontmatter[inputs], }, handler: module.run, }) return tools這里有個關(guān)鍵點模型看到的 parameters 一定是從 SKILL.md 里解析出來的 JSON Schema而不是實現(xiàn)函數(shù)的 Python 類型。我見過有人直接拿inspect.signature生成工具 schema結(jié)果 Python 的類型系統(tǒng)跟模型期待的不是一回事字段說明和描述全丟模型自然填錯參數(shù)。寧可維護(hù) SKILL.md 里的 schema也不要靠自動推斷。5.2 沙箱隔離與權(quán)限聲明權(quán)限是技能庫上線前必須想清楚的事。web_search 只需要出網(wǎng)PDF抽取只需要讀文件code_executor 可能要執(zhí)行任意代碼。這些技能絕不能跑在同一個無限制進(jìn)程里。我在 manifest 里用 permissions 字段聲明runner 拿到權(quán)限后決定用普通 subprocess 還是容器環(huán)境permissions: network: true filesystem: read_temp subprocess: false實際落地時我用的是一個帶超時控制的 subprocess runner每個技能跑在獨立進(jìn)程里超過 timeout 直接殺掉返回 TIMEOUT。對于需要更強隔離的技能可以放到容器里通過標(biāo)準(zhǔn)輸入輸出傳遞參數(shù)和結(jié)果。技能的輸出只允許走 JSON 通道不能有別的旁路這樣沙箱邊界才清晰。5.3 超時、并發(fā)與緩存LLM 應(yīng)用里模型調(diào)用本身就有延遲技能執(zhí)行再拖幾秒用戶體驗會很差。我給技能設(shè)置了默認(rèn)30秒超時代碼執(zhí)行類技能可以放寬到120秒但必須給模型提示“這個操作可能需要更久”。并發(fā)方面用 semaphore 控制同時運行的技能數(shù)量尤其是搜外部 API 時防止自己的 key 被打爆。結(jié)果緩存也是容易忽視的點。同一個技能對于相同參數(shù)結(jié)果往往是一樣的。我在 runner 層做了“參數(shù)哈希 → 結(jié)果”緩存TTL 按技能類型配置web_search 可以設(shè)5分鐘PDF 抽取結(jié)果不變就設(shè)24小時。這里要注意有副作用的技能不能開緩存。side_effect 字段這時候又派上用場了。5.4 多技能協(xié)作的路徑選擇最開始我把所有技能平鋪給模型讓模型自由選。技能少還行到20個以上時模型的選擇開始漂。我的方案是對技能做分組路由。比如“信息獲取類”“文件操作類”“代碼執(zhí)行類”先用一個輕量分類或 embedding 相似度把候選集縮到5個以內(nèi)再讓模型在這些候選項里選。這樣模型的選擇壓力小很多準(zhǔn)確率也會明顯上來。如果你的 Agent 已經(jīng)有比較固定的工作流也可以直接用 workflow 把技能串起來。比如“搜索資料 → 抽取正文 → 總結(jié)成 Markdown”這三個技能用一段 DSL 編排模型只在關(guān)鍵分叉點做選擇。這個思路比讓模型完全自由發(fā)揮可靠得多尤其適合面向外部用戶的 Agent。6. 當(dāng)前局限、設(shè)計取舍和下一步打算6.1 先說說這套設(shè)計“不擅長”的事agent-skills 把每個技能做成了獨立目錄在中小規(guī)模場景下非常舒服但當(dāng)技能數(shù)量膨脹后會遇到三個問題。第一個是選擇問題四五十個技能如果全部注入到模型上下文token 消耗會明顯上升而且模型在長列表里選技能的錯誤率也會上升如果只注入一部分又可能漏掉真正需要的技能。第二個是協(xié)作問題技能是孤立的彼此之間不知道對方產(chǎn)生什么數(shù)據(jù)模型只能靠上下文把前一個技能的輸出傳給下一個這個鏈路易斷。第三個是版本問題技能升級后老的 Agent 還在用舊版本如果不做版本鎖定功能變化會直接影響線上效果。這些都不是 agent-skills 目前能完全解決的。我現(xiàn)在的處理方式很務(wù)實技能列表超過一定規(guī)模就對技能做優(yōu)先級分級高頻技能進(jìn)主列表低頻技能進(jìn)“候選池”靠額外的檢索步驟召回。6.2 我在取舍上堅持的兩個原則第一個原則技能描述是核心資產(chǎn)不是附屬品。在設(shè)計 agent-skills 時我默認(rèn) SKILL.md 里的描述需要跟代碼一起評審、一起測試甚至比實現(xiàn)代碼更值得打磨。因為代碼只影響執(zhí)行正確性描述還影響模型會不會選到這個技能、選到之后能不能正確執(zhí)行。第二個原則不要把技能做成“萬能瑞士軍刀”。如果一個技能什么都能干它的描述一定會變得模棱兩可模型會高頻誤選。寧可把“搜索網(wǎng)頁”和“搜索數(shù)據(jù)庫”拆成兩個技能也不要寫一個“萬能搜索”然后在內(nèi)部做一堆分支判斷。技能邊界越清晰模型路由越容易。6.3 我接下來的三個演進(jìn)方向我會繼續(xù)把技能庫往“可路由、可組合、可評測”這三個方向補?？陕酚删褪墙o SKILL.md 增加向量索引字段做語義預(yù)篩降低模型面對長技能列表的選擇壓力。可組合就是增加requires_skills、produces_data這類顯式依賴讓運行器能做數(shù)據(jù)流拼接而不是全靠模型用上下文傳參。可評測就是把每個技能的成功標(biāo)準(zhǔn)寫進(jìn)測試集每次技能更新先跑評測過了才允許發(fā)布。這個路線可能不會讓 agent-skills 變成一個龐大的框架但至少能讓“技能”這個單元越來越接近工程化。對一個要長期迭代的Agent項目來說單元穩(wěn)定比框架花哨重要得多。6.4 一個實用的起步建議如果你也想在自己項目里沉淀一套技能庫不用急著照搬全部設(shè)計。先挑一個你每天都會手寫的操作比如“網(wǎng)頁正文提取”或“PDF轉(zhuǎn)Markdown”把它按 SKILL.md main.py tests 三件套拆出來跑兩個真實場景。跑順以后把第二個、第三個技能加進(jìn)來你會發(fā)現(xiàn)自己的Agent行為開始變得有規(guī)律調(diào)試效率也比散裝工具時代高很多。這也是我整理 agent-skills 時最大的收獲——先形成最小閉環(huán)再談規(guī)模。技能庫從三個能打的核心技能開始永遠(yuǎn)比一開始就堆五十個沒人維護(hù)的“花架子”技能更有實用價值。