1. 為什么Agent離不開技能包先聊個現(xiàn)象。最近半年我一直在折騰各種Agent工作流從簡單的提示詞模板、到Function Calling、再到現(xiàn)在的Skills機制最大的感受是大模型的“能力”其實分成兩層一層是它腦子里裝的常識另一層是它能穩(wěn)定執(zhí)行的流程。常識層面各家模型已經(jīng)拉不開太大差距了真正決定一個Agent好不好用的是后面這層——能不能按一個固定的、可復(fù)用的方式把活兒干完。在沒有技能包之前我每次讓Agent做一件稍微復(fù)雜點的事都要經(jīng)歷一場“拉鋸戰(zhàn)”。比如讓它根據(jù)我的周記生成周報第一次回復(fù)是標準的三段式第二次變成了一段式第三次開始自作主張加上了下周計劃。不是模型變笨了而是每次對話都是“重新開始”我那些口頭交代的工作習(xí)慣、格式偏好、邊界約束它根本沒有沉淀下來。這就很像你讓一個臨時工干活每次都得從頭講一遍要求他干出來的東西還每次都不太一樣而技能包做的事相當(dāng)于把某個崗位的“崗位說明書 標準作業(yè)程序 配套工具”一次性交給了模型。技能包這個概念其實不難理解它就是一個結(jié)構(gòu)化的文件夾里面包含一份指令文檔通常叫SKILL.md告訴模型“這是個什么技能、什么時候該用、按什么流程做、輸出成什么樣”還可以附帶腳本、模板、參考文件和依賴清單讓模型在需要時能真正動手處理數(shù)據(jù)而不僅僅是“憑感覺生成文本”。它的核心價值在于把原本只存在于人腦里的隱性經(jīng)驗變成了Agent能穩(wěn)定讀取的顯性資產(chǎn)。這篇文章的受眾我覺得有兩類人。一類是正在用Claude或類似Agent平臺做自動化、做內(nèi)容生產(chǎn)、做內(nèi)部工具鏈的開發(fā)者技能包能幫你把碎片化的工作流固化下來。另一類是自己搭A(yù)gent、對接API的工程化玩家會需要掌握技能的目錄組織、指令編寫、腳本聯(lián)動這些細節(jié)。我下面講的東西都偏實操不會繞理論直接講我踩過坑之后總結(jié)出來的那套做法。2. 技能包的核心細節(jié)從設(shè)計到落地2.1 技能包的目錄結(jié)構(gòu)到底長什么樣一個標準技能包從物理形態(tài)上看就是一個目錄。目錄名字建議全小寫加短橫線命名法比如weekly-report-generator別用大寫字母、空格、下劃線因為很多Agent框架對技能名有嚴格的格式約束我最早用Weekly_Report命名結(jié)果在部分工具里直接不被識別排查了半天路徑問題才發(fā)現(xiàn)是命名惹的禍。目錄內(nèi)部的分工大致是這樣文件/目錄作用是否必需SKILL.md技能的“說明書”包含元信息和給模型的指令正文必需scripts/存放可執(zhí)行腳本模型可調(diào)用按需assets/放模板、靜態(tài)參考文件按需requirements.txt依賴第三方Python庫時聲明按需很多人誤以為技能包只是個“高級提示詞”其實不是這么簡單。當(dāng)Agent的推理能力和工具調(diào)用能力結(jié)合起來時SKILL.md負責(zé)定義“該怎么思考”scripts負責(zé)處理“該執(zhí)行什么動作”assets負責(zé)提供“該參考什么素材”。三者配合才能讓技能從“說得漂亮”變成“干得靠譜”。我之前做過一個生成會議紀要的技能剛開始只有SKILL.md模型能聽懂要做紀要但遇到幾十頁的錄音轉(zhuǎn)寫文本時它會讀得磕磕絆絆而且摘要里經(jīng)?；爝M無關(guān)內(nèi)容。后來我在scripts里放了一個基于關(guān)鍵詞過濾的預(yù)處理器又給assets放了一個紀要模板效果立刻就不一樣了。這給我的啟發(fā)是凡是涉及到數(shù)據(jù)處理的環(huán)節(jié)盡量別依賴模型自由發(fā)揮用腳本把“臟活”干了模型只負責(zé)判斷和表達這才是技能包的正確打開方式。2.2 為何SKILL.md是技能包的靈魂我見過不少人寫技能包最上心的反而是scripts里的代碼對SKILL.md反而很敷衍。這個思路是反的。Agent拿到一個技能包之后它并不會自動知道自己該干什么一切行為起點都是SKILL.md那份說明文檔。里面寫得含糊后面寫再多代碼也沒用。SKILL.md的結(jié)構(gòu)一般分成兩部分YAML格式的frontmatter元信息和Markdown正文。frontmatter里最要緊的字段是name和description。name要跟目錄名保持一致description則決定了模型“什么時候會想起這個技能”。這個字段很微妙寫得太泛比如“生成周報”模型在別的場景下也可能錯誤觸發(fā)寫得太窄比如“根據(jù)用戶提供的JSON格式的任務(wù)記錄生成包含完成狀態(tài)、困難點、明日計劃的周報Markdown文件”模型反而能在該用的時候自動匹配上。一定要記住description不是給人看的是給模型的觸發(fā)條件寫的。正文部分則是模型執(zhí)行技能的完整說明書。我推薦按這種順序組織技能的觸發(fā)場景與目標一句話說清楚。輸入需要哪些信息從哪里獲取。執(zhí)行步驟分步驟引導(dǎo)第幾步干什么別讓模型跳躍。輸出格式給出明確模板或結(jié)構(gòu)最好有示例。注意事項明確失敗條件和邊界告訴模型什么不能做。里面每個動作盡量用祈使句比如“從用戶消息中提取目標日期”“調(diào)用scripts/summarize.py對筆記做摘要”“將結(jié)果填入下面的模板”這比“你應(yīng)該盡可能地分析用戶的需求”這種廢話有用得多。模型對“動詞引導(dǎo)式”的指令響應(yīng)率明顯更高這是我實測下來的經(jīng)驗。2.3 讓技能真正生效的參數(shù)規(guī)則技能包在執(zhí)行時經(jīng)常需要接收外部輸入。比如模型要根據(jù)用戶的消息去生成周報那用戶消息里的原始記錄就要能被SKILL.md里的指令引用到。大多數(shù)Agent框架用的占位符風(fēng)格是雙大括號比如{{input}}也有用$variable的具體按平臺規(guī)范來。這里有個特別容易踩的坑別把占位符和shell變量混為一談。我最初寫了一個技能在SKILL.md里引用某個路徑變量時用了$NOTES_FILE結(jié)果模型把整個字面量原樣傳給了腳本腳本自然是讀不到文件的。后來統(tǒng)一改成{{notes_file}}再配合前置指令“執(zhí)行前將{{notes_file}}替換為實際路徑”問題就沒了。遇到這類問題排查思路很簡單先看傳給腳本的到底是什么是不是被當(dāng)成了字符串字面量只要把原始調(diào)用日志拉出來看一眼就明白了。還有一點占位符的數(shù)量別太多。我見過一個技能包里定義了七八個占位符讓模型在執(zhí)行時逐一填充看起來很靈活但模型經(jīng)常填錯或者漏填。如果可能盡量讓腳本自動從標準輸入或固定路徑讀取數(shù)據(jù)減少人為傳參。技能包設(shè)計得越“傻瓜化”模型跑起來越穩(wěn)定。2.4 腳本與工具調(diào)用的邊界把握什么時候該寫腳本什么時候不該寫我的判斷原則很簡單凡是規(guī)則明確的處理交給腳本凡是需要理解和判斷的地方留給模型。比如做周報提取每個任務(wù)的完成狀態(tài)是規(guī)則明確的交給腳本為任務(wù)寫一句“存在風(fēng)險的原因分析”這是理解與判斷的活應(yīng)該由模型完成。腳本本身的代碼不需要寫得多花哨但要注意三點。第一路徑別寫死盡量用相對路徑或者通過參數(shù)傳入第二輸出盡量標準化最好能讓模型直接讀取的結(jié)果是JSON或純文本形式別輸出一堆帶顏色的日志第三記得做異常處理腳本萬一處理失敗模型要能理解報錯信息而不是看著一堆traceback發(fā)呆。我還習(xí)慣在腳本里增加一個--dry-run模式。這樣在調(diào)試技能包時可以先不真正調(diào)動模型只用固定輸入跑一遍腳本快速確認數(shù)據(jù)鏈路是否通暢。這個習(xí)慣幫我節(jié)省了大量排查時間后面會細說。3. 實操演示從零做一個周報技能包3.1 場景定義與目錄初始化講理論有點干直接上一個完整的示例。就以“周報生成”為場景——這也是我實際工作中用得最多的技能包因為每周五下午寫周報這件事枯燥但流程固定特別適合做成技能。需求先定義清楚我平時會在一個notes/目錄里隨手記一些工作進展格式稀碎有時候是一句話有時候帶時間戳偶爾還夾雜個人想法。周報技能要做的是掃描這些零碎記錄、篩出跟項目相關(guān)的條目、按“本周完成/風(fēng)險與求助/下周計劃”三個維度重新組織最后輸出一份Markdown格式的周報文件。目錄結(jié)構(gòu)我按前面說的規(guī)范來weekly-report-generator/ ├── SKILL.md ├── scripts/ │ └── parse_week.py ├── assets/ │ └── 周報模板.md └── requirements.txt這個結(jié)構(gòu)很簡單但每個文件都有明確職責(zé)。SKILL.md是頂層指揮腳本負責(zé)解析原始筆記模板負責(zé)固定輸出風(fēng)格。3.2 編寫SKILL.md的完整過程下面是我用下來比較穩(wěn)定的SKILL.md寫法可能跟官方文檔推薦的骨架略有不同但更貼近實際使用。--- name: weekly-report-generator description: - 根據(jù)用戶的零散工作筆記生成結(jié)構(gòu)化周報。適用場景用戶提供notes目錄下的文本記錄 需要整理為本周任務(wù)完成情況、風(fēng)險與求助、下周計劃的Markdown周報。 不適用場景用戶只是簡單詢問近況沒有提供具體筆記原文或筆記路徑時不要調(diào)用。 --- # 周報生成技能 ## 任務(wù)目標 將用戶提供的工作筆記整理為一份信息完整、層次清晰的周報。 ## 輸入獲取 1. 確認用戶是否提供了筆記目錄或筆記原文。 2. 如果用戶沒有提供主動詢問不要猜測或編造內(nèi)容。 3. 優(yōu)先讀取用戶指定的文本文件若文件較多調(diào)用 scripts/parse_week.py 進行過濾與聚合。 ## 執(zhí)行步驟 1. 使用腳本匯總 notes 目錄下本周新增的條目過濾掉與工作無關(guān)的個人記錄。 2. 按三個模塊組織內(nèi)容本周完成、風(fēng)險與求助、下周計劃。 3. 從原始記錄中提取關(guān)鍵事實使用簡潔描述不要復(fù)制整段原文。 4. 對風(fēng)險與求助事項需要給出判斷理由而不僅僅是羅列條目。 5. 按照 assets/周報模板.md 的格式填充內(nèi)容。 ## 輸出要求 - 輸出格式為 Markdown使用二級標題分隔三個模塊。 - 每個模塊下使用無序列表每條內(nèi)容控制在50字以內(nèi)。 - 不要捏造任何未出現(xiàn)在原始筆記中的事項。 - 如果筆記信息過少少于3條有效事項主動提示用戶補充不要強行生成一份空洞的周報。 ## 注意事項 - 務(wù)必區(qū)分“任務(wù)完成”與“任務(wù)進行中”不要混為一談。 - 不要把用戶的抱怨或個人情緒內(nèi)容寫進周報。 - 腳本執(zhí)行失敗時先查看錯誤信息再決定是繼續(xù)使用模型直接整理還是請用戶檢查輸入。這份SKILL.md里有一個細節(jié)值得注意description明確寫了“不適用場景”。很多人寫description只寫什么時候用不寫什么時候不能用結(jié)果模型經(jīng)常誤觸發(fā)——聊天時隨口提一句“幫我總結(jié)下最近工作”模型都會去翻筆記目錄。多寫一句不適用場景誤調(diào)用率能降不少。3.3 配套腳本的實現(xiàn)邏輯再看scripts/parse_week.py。這個腳本的核心功能很樸素讀入一個筆記目錄過濾掉包含“# 雜談”標記的個人記錄按日期提取當(dāng)前周的條目輸出JSON。以下是示例代碼用的是Python標準庫不需要額外依賴所以requirements.txt其實可以空著這里為了演示路徑依賴問題我保留空文件。import json import os import sys import re from datetime import datetime, timedelta def is_personal(line: str) - bool: # 個人記錄標記例如“#雜談”“#生活”跳過這類行 return bool(re.search(r#\s*(雜談|生活|吐槽), line)) def current_week_range(): today datetime.now() monday today - timedelta(daystoday.weekday()) sunday monday timedelta(days6) return monday.strftime(%Y-%m-%d), sunday.strftime(%Y-%m-%d) def main(notes_dir: str): start, end current_week_range() items [] for filename in sorted(os.listdir(notes_dir)): if not filename.endswith(.md): continue filepath os.path.join(notes_dir, filename) with open(filepath, r, encodingutf-8) as f: lines f.readlines() current_date None for line in lines: line line.strip() if not line: continue date_match re.match(r^\d{4}-\d{2}-\d{2}, line) if date_match: current_date date_match.group(0) continue if is_personal(line): continue if current_date and start current_date end: items.append({date: current_date, content: line}) print(json.dumps(items, ensure_asciiFalse, indent2)) if __name__ __main__: main(sys.argv[1] if len(sys.argv) 1 else ./notes)這個腳本有兩點設(shè)計值得一提。第一靠Markdown標題里的日期來歸類所以我的筆記習(xí)慣是每天用2025-06-09這種格式開頭正好形成一個人機都能讀的規(guī)范如果原始數(shù)據(jù)的格式更亂可以把解析邏輯再加厚但原則不變——腳本只做機械抽取不做語義判斷。第二輸出直接是JSON模型拿到這個JSON后再按SKILL.md的指引去生成長句和判斷分工明確互不干擾。實際調(diào)試時我是這樣驗證腳本的python scripts/parse_week.py ./notes week_data.json然后把week_data.json里的內(nèi)容喂給模型看它是否按SKILL.md的要求生成周報。這一步把“模型的問題”和“腳本的問題”剝離開來——腳本錯了就看看JSON里的條目對不對模型發(fā)揮不好就看看是不是指令描述不充分。3.4 讓模型真正“看見”并調(diào)用技能技能包寫完之后怎么讓模型在執(zhí)行任務(wù)時主動調(diào)用它這里因平臺而異但通用的調(diào)試路徑可以分享幾條。如果是自帶技能管理界面的環(huán)境直接把目錄放進去保存就行。然后做一個“觸發(fā)驗證”作為一個用戶對模型說“根據(jù)我notes目錄這周記錄生成一份周報”。注意驗證時的描述最好跟SKILL.md里的description語義重合這樣才能測試觸發(fā)是否正確。如果模型沒有調(diào)用技能優(yōu)先懷疑description匹配問題把description改寫后再試一次。另一種排查方法是“強行點名”。直接在對話里提到技能名比如“使用weekly-report-generator這個技能”看模型是否能夠進入技能的執(zhí)行流程。這相當(dāng)于繞開了觸發(fā)匹配直接測試技能內(nèi)部的質(zhì)量。如果點名能正常執(zhí)行但自然對話不觸發(fā)說明問題出在description的寫法上而不是技能內(nèi)容本身。在做技能調(diào)用測試時我還會刻意把一些異常情況混進去測試比如故意說“我昨天的筆記丟了你直接幫我寫一份周報吧”看模型會不會開始編內(nèi)容。只要SKILL.md里的“不要編造”寫清楚了模型一般會停下來要更多信息如果它直接開始編說明注意事項寫得太軟得改成更強制性的語句比如“禁止生成任何未出現(xiàn)在筆記中的事項如果信息不完整直接拒絕生成”。4. 常見問題與排查技巧實錄4.1 技能沒被觸發(fā)時的處理順序這是新手最容易遇到的情況技能放上去了但模型好像看不見它。我建議按下面這個排查順序走一遍先看目錄和命名是否符合規(guī)范。技能名不能有空格、大寫、特殊符號SKILL.md的編碼必須是UTF-8別用帶BOM的格式。再看description的觸發(fā)語義這一步占大部分比例描述跟用戶真實表達差太遠模型自然想不起來。還需要確認技能包是否被正確加載很多平臺有技能列表頁如果列表里就沒有這個技能那一定是物理路徑或配置文件的問題跟模型無關(guān)。另外一個容易忽視的問題是技能數(shù)量過多導(dǎo)致的干擾。當(dāng)環(huán)境里裝了十幾個技能包時模型對每個技能都能“看見”但觸發(fā)閾值會變高。我自己的經(jīng)驗是把技能保持在真正高頻使用的五六個以內(nèi)。數(shù)量一多技能就純粹變成了擺設(shè)。4.2 模型調(diào)用了技能但輸出不對味這種情況也很常見觸發(fā)成功了模型也確實執(zhí)行了但結(jié)果跟期望偏差很大。這時候要分情況查。如果模型產(chǎn)出的是“形式上正確、內(nèi)容上空泛”的結(jié)果大概率是SKILL.md的輸出要求寫得不夠細。光說“使用二級標題分隔三個模塊”是不夠的最好能在模板文件里把示例逐行寫出來。模型很吃示例那一套——給它一個具體的輸出樣例比告訴它一百條格式化規(guī)則都管用。如果模型產(chǎn)出的是“內(nèi)容有編造”重點檢查輸入獲取這一步。是不是說了一句“優(yōu)先讀取用戶指定的文本文件”卻沒有禁止模型自行推測筆記內(nèi)容需要在注意事項里明確增加約束禁止推測筆記中未出現(xiàn)的事項。如果模型雖然執(zhí)行了但腳本沒有被調(diào)用那問題很可能出在“步驟拆解”上。模型面對一個技能時有時候會選擇跳過某些步驟直接生成結(jié)果。解決方案是在SKILL.md里增加一個“強制順序”描述比如“在生成最終周報之前必須運行以下命令完成數(shù)據(jù)收集否則不能開始寫正文”。4.3 技能包之間的沖突與占用技能裝多了以后還會出現(xiàn)互相搶活的情況。我遇到過一個具體案例同時裝了“周報生成”技能和“會議紀要整理”技能Description里都有“將信息整理成結(jié)構(gòu)化文檔”這種泛化表述結(jié)果有時讓模型整理會議紀要它卻觸發(fā)了周報技能最后輸出一個四不像。解決思路不復(fù)雜把每個技能的description寫得更有區(qū)分度。周報技能的觸發(fā)條件應(yīng)該強調(diào)“notes目錄”“歷史工作記錄”“周報”會議紀要技能則強調(diào)“會議錄音轉(zhuǎn)寫文本”“行動項”。此外還可以在description里加沖突排除句例如“如果用戶輸入內(nèi)容包含會議對話轉(zhuǎn)寫則不屬于本技能范圍”。與沖突相關(guān)的問題還有依賴缺失。有些技能包會用到第三方庫如果不提前聲明依賴執(zhí)行時直接報ModuleNotFoundError模型看到報錯基本就兩眼一抹黑了。所以requirements.txt不是擺設(shè)它既是給人類看的安裝說明也是給Agent環(huán)境的提示。技能包共享給團隊時這點尤其重要。4.4 老手才注意到的性能與安全細節(jié)有些坑不是功能性問題但一旦踩到會影響體驗。第一大文件別隨技能包攜帶。我見過有人把一個幾十MB的行業(yè)數(shù)據(jù)庫文件放進assets目錄技能包每次加載都慢得讓人崩潰。正確的做法是把大文件放到遠程或共享存儲SKILL.md里寫清楚“執(zhí)行時從某個路徑讀取”或者用腳本按需下載。第二腳本對異常的處理要完善。如果有外部輸入腳本要考慮文件不存在、編碼不符、空數(shù)據(jù)這些情況。模型執(zhí)行到一半看到腳本報錯如果錯誤信息可讀性差它只會反復(fù)重試同一個錯誤操作。給腳本加上異常處理并輸出用戶能看懂的中文報錯能省掉后面一長串的調(diào)試時間。第三技能包不要綁定太強的環(huán)境假設(shè)。比如SKILL.md里寫著“讀取C:\Users\xxx\notes”這種絕對路徑換臺電腦或換個用戶就廢了。寫成“從用戶本次消息中指定或系統(tǒng)默認的notes目錄讀取”讓模型自己去找魯棒性會高很多。4.5 常見問題速查表把上面這些經(jīng)驗做成一張速查表方便照著排查現(xiàn)象可能原因解決方法技能列表里找不到命名不合規(guī)或目錄路徑錯誤檢查技能名、目錄名、UTF-8編碼自然對話不觸發(fā)description與用戶表達不匹配改寫description盡量包含觸發(fā)詞和場景點名調(diào)用才生效description太窄或太泛增加適用場景與不適用場景的說明輸出格式穩(wěn)定但內(nèi)容空泛指令正文缺少輸出示例在assets里放附帶示例的模板文件模型跳過腳本直接生成步驟拆解不夠強制在SKILL.md中規(guī)定強制步驟順序多個技能互相搶占description邊界不清寫清區(qū)分條件和排除規(guī)則腳本報錯后模型停止工作異常處理不足腳本兜底異常并輸出可讀報錯這張表是我自己在調(diào)試技能包時對照使用的。把問題歸類以后再動手改比盲目重寫SKILL.md高效得多。5. 再進一步技能包的工程化管理5.1 版本管理與團隊協(xié)作技能包一旦多了它本身也變成了需要維護的代碼資產(chǎn)。如果你只是自己一個人用目錄里放一份就好但如果要做團隊協(xié)作就得認真對待版本管理。我建議給技能包打上語義化版本號比如weekly-report-generator v1.3.0。在SKILL.md里加一個version字段。每次修改指令或腳本更新一下版本號并在一個CHANGELOG.md里記錄變更內(nèi)容。這樣做最大的價值是回歸有基準當(dāng)某個技能忽然失效可以快速對比出是哪個改動引入的回歸。團隊協(xié)作的話可以把技能包推進一個內(nèi)部倉庫用Git管理。每個人拉取后按文檔安裝依賴就行。還有一個更工程化的做法給技能包寫一個manifest.json描述技能名、版本、依賴腳本、環(huán)境要求等信息這樣被平臺加載時可以直接做版本校驗。技能工程化做到這一步基本就告別“改了個技能包結(jié)果模型行為大變”的噩夢了。5.2 給技能包做自動化回歸測試很多人測試技能包靠的是手動問模型幾句話覺得差不多能出結(jié)果就完事了。我建議把測試變得更可重復(fù)準備一組固定的測試用例每個用例包含輸入消息、預(yù)期輸出結(jié)構(gòu)、預(yù)期調(diào)用的腳本參數(shù)。然后用腳本自動把用例跑一遍檢查輸出是否滿足預(yù)期的關(guān)鍵規(guī)則比如是否包含必需的章節(jié)標題、是否沒有出現(xiàn)編造的專有名詞。這個思路其實很簡單——把模型當(dāng)作一個函數(shù)給定輸入斷言輸出。技能包改動后跑一遍全量用例哪個技能被改壞了立刻就知道。我目前的做法是在CI里加一個測試任務(wù)每次推送技能包代碼變更時自動運行校驗。這套流程寫起來工作量不大但能防止“改了A技能結(jié)果B技能的description沖突導(dǎo)致觸發(fā)異?！边@類問題。5.3 技能包和MCP、Function Calling的分工跟技能包經(jīng)常一起被提及的是MCP和Function Calling很多人搞不清它們之間的關(guān)系。我自己的理解是Function Calling是模型對話中按需調(diào)用外部函數(shù)的最底層機制靈活但零散MCP是把工具接入做成了統(tǒng)一標準協(xié)議讓Agent能發(fā)現(xiàn)并調(diào)用各類外部服務(wù)而技能包則是更高層的“行為單元”它內(nèi)部可以涵蓋指令、腳本甚至多個函數(shù)調(diào)用的編排。用一個生活化的類比來說Function Calling相當(dāng)于工具箱里的一把螺絲刀MCP是一個標準接口的電源插座技能包則是“換一個水龍頭”這份帶圖紙和步驟的說明書。技能包更適合解決“一個完整任務(wù)怎么從頭到尾做對”的問題MCP更適合解決“Agent怎么與各種系統(tǒng)順暢連接”的問題兩者不是競爭關(guān)系而是可以互相嵌套的組合關(guān)系。所以在設(shè)計技能包時不用擔(dān)心它和MCP重疊。MCP幫你把數(shù)據(jù)服務(wù)打通了技能包幫你在一次任務(wù)中把這些服務(wù)用對順序、用對參數(shù)、用對輸出結(jié)構(gòu)。二者的組合才是我認為Agent工程化的最佳實踐。最后再分享一個我個人的小體會在寫技能包的過程中最花時間的往往不是寫代碼而是把那些“我自己憑感覺就能做好的事”用語言清晰地描述出來。比如周報這件事我心里很清楚哪些該寫、哪些不值得寫但要把這個判斷標準變成模型能執(zhí)行的規(guī)則就需要反復(fù)措辭、反復(fù)測試。這個過程一開始很痛苦但堅持下來你的技能包會越來越像你的“數(shù)字分身”——我現(xiàn)在的周報技能已經(jīng)穩(wěn)定跑了兩個多月基本每周五丟一句話加一份筆記它就能產(chǎn)出可用的周報初稿我只用花兩分鐘修改措辭就收工。這種體驗值得你花一晚上把第一個技能包做出來。