分享一個把200k的Github項目轉成元Skill工作流的方法！

兩天前，我在朋友圈分享了把Superpowers這個20萬的GitHub項目做成垂直Agent的方法。

沒多久就收到一句吐槽，這14個Skill組合起來太啰嗦了，還燒Token。

確實這是我這段時間一直在想解決問題，

好的Skill很多，但很多時候都是讓Agent去盲選調用順序。

Superpowers三個月前還是10萬star，現在又翻倍了

雖然它在Readme里面塞了一個基本工作流，但是我并不是每一次調用都需要那么多skill的。

想來想去，還是每個人按照自己的習慣，安排一套這個skill的調用順序最合適。

而且把Skills定好調用順序之后，我還可以把其他框架上跟它重疊但不重復的技能納入到這個工作流里面。

比方說我就很喜歡在開發(fā)流程的最后一句觸發(fā)compound里面的持續(xù)學習。

這個問題可以被具體化成，

到底該怎么用這一組Skill？

一組Skill就像一個百寶工具箱。你知道我知道大家都知道里面有好東西，但每次執(zhí)行的時候，還是得判斷今天該用哪個，順序是什么，要不要全塞進上下文，哪些步驟可以跳過等等等等。

更麻煩的是，每讀一個Skill的說明燒的都是我的TOKEN啊，Agent自己不心疼，我心疼。

這種麻煩在最近狂用Codex的/goal命令的時候達到了頂點，我的周額度居然在周五就沒了，重生之72小時我成古法手寫程序猿了屬于是。

這兩天在GitHub上大搜特搜省TOKEN還不降模型智商和體驗的項目，

Bad case是這個，說是會給Claude Code剩下65%的TOKEN，結果給我Claude干成呆瓜了。

還有一種新玩法是從Skills的組織入手的，

叫做，OpenSquilla

他把多個Skills組織抽象成了Meta Skill。

普通Skill解決的是，我會什么。

Meta Skill解決的是，現在這個任務，我該怎么把這些能力串起來。先做哪一步，后做哪一步，哪一步依賴前一步，哪一步沒完成就別往下跑。

不過這個項目跟OpenClaw比star差了快兩百倍，所以我們還是先來看看紙面實力，在PinchBench 1.2.1上，三個模型混著用的OpenSquilla跟Claude Opus 4.7版的OpenClaw得分幾乎一樣，但Token少了將近一半，成本不到1/9。

超光速看了一下項目代碼，一個很突出的差異點是，OpenSquilla的Meta Skill會讓我們多寫一份SKILL.md。

這份文件不是一段提示詞。

它是在用YAML定義Meta Skill的步驟、順序和依賴。

看到depends_on: [classify]了吧，

翻譯成人話，就是先給輸入做分類，是bug，提問，還是其他情況。

沒分完類，就不準往下走。

看到的時候我第一反應是，這不就是寫了一套rules嗎？

區(qū)別在硬約束，

rules靠模型自覺，上下文一長，模型就可能突破約束。MetaSkill不一樣，它會在Runtime層先檢查一遍。步驟順序對不對，依賴有沒有閉環(huán)，權限夠不夠。

通不過校驗，0次API調用，一分錢都花不著。

為了測試我故意寫了一個壞依賴，depends_on: [missing_step]，指向一個不存在的步驟。真就直接在Plan Validation階段攔截了，連LLM調用都沒發(fā)出去。

以前我們是靠寫Rules讓模型遵守約定。

現在變成了先用代碼轉一圈看看，這條工作流本身成立嗎？

那我直接上手把把Superpowers底下Skills組合做成Meta Skill，

brainstorm負責想需求，write_plan負責寫計劃，verify負責檢查風險，作為我日常的固定搭配流程。

打包成一個Meta Skill后就不需要Agent每次來考慮這次需不需要，一套流程定下來，跟著規(guī)定走，不能遺漏也不能跳步。

用同一個提示語任務測了三輪，提示語都是搜索3個2026年AI agent跑生產環(huán)境的風險，再寫一段給工程經理看的總結。

能看出來有沒有Meta Skill差距還是蠻大的，

同樣是成功跑完了內容，Meta Skill把輸入TOKEN就壓到67%。

每一步思考過程減少了，也不再把Token消耗在遷移途中的說明上，

用人話說的話，它用更長的前置運行時間，換來更少的重復上下文消耗。

對于模型切換 ，OpenSquilla支持多家模型，自帶了一個本地小模型，我發(fā)的請求在要發(fā)給干活的大模型之前會先做個分類是簡單還是復雜任務。

不過這個模型切換只能在是在新開session或者新建立對話情況下才實現。

我覺得還是為了切起來夠穩(wěn)定，

如果在同一個Session中頻繁換模型，很容易就會出現上下文緩存，工具格式和日志混亂等等問題。主要是我心痛我Claude的一小時緩存。

還有，我留意到一個細節(jié)，

OpenSquilla用子Agent去理解和壓縮上下文，也就是說在一個上下文是 400K左右的模型，到了300多接近400K的時候，還是能夠能記住我之前說的點。提示語長這樣，

含 Executive Summary、Key Findings、對比表、協(xié)議矩陣、局限性分析

同一個對話里，從你是誰到寫一份8個框架的調研報告，全跑通沒有忘記上下文。并且在話題結束，給出一份巨巨巨詳細的花銷明細。

從自我介紹到8框架競品報告，

同一會話花了7美分都花在哪了。

OpenSquilla把這一切都攤開了。

每個Session的Token數和成本精確到小數點后四位。這一輪測下來，只能說星不可貌相啊，全是狠活。

過去半年，

Agent是先卷模型，再卷MCP，接著卷Skill。

Skill都卷到Clawhub上有6w多了，

正常一個Agent也就常用的也就50個70個。

可能挑了很久，終于選了一個Skill帶回家，

但過幾天，新的又來了，舊Skills也就被忘了。但Agent每輪都還是會讀舊Skills的說明書，

對我來說過多的Skills只是散落在倉庫里的文件，但Agent會因為Skills里內置的各種規(guī)則誤導，

規(guī)則加太少，Agent容易失去了方向，

規(guī)則加太多，Agent就左腦打右腦了。

真正拉開差距的，從來都不是誰的Skill更多，

這跟一周能不能燒掉一億token一樣沒有意義。

能不能把Skill串成一條穩(wěn)定的工作流，

別讓Agent在完全沒有限制的空間里臨場發(fā)揮。

我們真正需要的是讓它知道,

第一步做什么，要不要繼續(xù)。

哪一步沒必要，能不能省略。

這一步的問題，要怎么定位。

每次對話的下一次都能跑更穩(wěn)定，

把好的步驟做的更好，

壞的Bug也不再發(fā)生。

@ 作者 / 卡爾

最后，感謝你看到這里如果喜歡這篇文章，不妨順手給我們點贊｜在看｜轉發(fā)｜評論

如果想要第一時間收到推送，不妨給我個星標

如果你有更有趣的玩法，歡迎在評論區(qū)聊聊

更多的內容正在不斷填坑中……