這是蒼何的第 546 篇原創!
大家好,我是蒼何。
最近我在 GitHub 上刷到一個很有意思的開源項目。
![]()
讓 Agent 學會自己組織技能
這個項目叫 OpenSquilla,目前已經拿了 3700 多 Star。
它的核心方向是 Harness 層優化,通過智能模型路由來降低 token 成本。
最新推出的 MetaSkill 3.0,更是把 Agent 從「會調用工具」推進到了「會自組織技能、穩定交付工作流」。
![]()
說實話,看完它的設計理念,我第一時間就想到了 WeSight。
WeSight 的定位是一個入口管理所有 Agent,而 OpenSquilla 的定位是 Agent 的「自組織技能大腦」。
一個管入口和可視化,一個管路由和技能編排。
這不就是天作之合嗎?
好家伙,說干就干。
我直接把 OpenSquilla 作為引擎接進了 WeSight。
![]()
在 WeSight 中選擇 OpenSquilla 引擎使用,一句話就可以將公眾號文章轉為小紅書圖文。
![]()
我做內容有個痛點:
公眾號文章寫完了,想同步到小紅書,得重新寫標題、改文案、做封面。
一套下來,至少半小時。
能不能讓 Agent 自己把這件事辦了?
寫死工作流那套太死板了,我要的是讓 Agent自己發現該用什么技能、自己決定怎么組合、自己把活干完。
于是我在 WeSight 里新建了一個任務,選擇 OpenSquilla 引擎。
然后只輸入了一句話:
幫我把這篇公眾號文章轉成小紅書圖文,風格要種草感強一點。
接著貼入文章鏈接。
![]()
接著 OpenSquilla 沒有直接瞎干,而是先在后臺檢索了一圈可用的 skill。
它在 WeSight 的技能面板里「發現」了三個原子技能:
wechat-article-extractor(解析公眾號文章)
xiaohongshu-text-skill(生成小紅書文案)
xiaohongshu-cover-generator(生成小紅書封面圖)
然后,它自己把這三個技能按依賴關系拼成了一個工作流。
先解析,再改寫,最后出圖。
DAG 關系清清楚楚。
![]()
第一步,公眾號文章鏈接解析完成,markdown 文件出現在文件面板。
![]()
并保存為 markdown 文件:
![]()
實際是調用 wechat-article-extractor(解析公眾號文章)技能
第二步,根據解析完成的 md 文檔改寫成小紅書風格的標題和文案。
![]()
實際是調用 xiaohongshu-text-skill(生成小紅書文案)技能
第三步,根據內容整體風格調用 gpt-image 2 進行封面圖生成。
![]()
實際是調用 xiaohongshu-cover-generator(生成小紅書封面圖)技能
整個過程大概 40 秒。
我檢查了一下產出質量。
標題帶了 emoji,文案分段短、有網感,封面圖風格也符合小紅書的審美。
雖然不是 100% 完美,但作為一個「一句話需求」的自動化結果,已經相當能打了。
更關鍵的是:這個工作流不是我提前寫好的,是 OpenSquilla 現場自己組出來的。
它是怎么做到的
這就要說到 OpenSquilla 的 MetaSkill 協議了。
傳統的 Agent 工作流,要么是硬編碼的腳本,要么是人工拖拽的節點圖。
你得提前告訴它:第一步做什么,第二步做什么,如果失敗怎么辦。
但 MetaSkill 的思路完全不一樣。
它是一份「元 markdown」,本質上是在告訴模型:
如何檢索、篩選、組合原子 Skill。
比如剛才在 WeSight 中的側邊欄,我們可以直接進入 OpenSquilla 后臺看到這個元 skill。
![]()
點進去進入 skill 管理界面,就能看到剛才我們的新建的這個元技能:
![]()
點開詳情看下,果不其然就是調用的前面說的那三個 skill。
![]()
換句話說,它沒走寫死流程那條路,搞的是一套「組織技能的協議」。
剛才那個公眾號轉小紅書的 case,背后就是這樣一份 MetaSkill:
![]()
你可以看到,這里面沒有任何具體的業務邏輯。
只有步驟聲明、依賴關系和輸入輸出映射。
真正的「怎么解析」「怎么改寫」「怎么出圖」,全部下沉到了原子 Skill 里。
MetaSkill 只負責一件事:在正確的時間,把正確的 Skill 串成正確的順序。
這就帶來了一個巨大的好處:
當社區里有新的 Skill 出現時,MetaSkill 可以自動把它納入可選范圍,而不需要修改工作流本身。
比如哪天社區里出現了一個更牛的「公眾號解析器」,OpenSquilla 會自動發現它、評估它、在合適的時候替換掉舊的那個。
這才是真正的「自進化」。
為什么這件事很重要
我知道你可能在想:不就是把幾個工具串起來嗎?有什么了不起的?
好,我們來算一筆賬。
現在各種 Agent 框架、MCP 工具、開源 Skill 正在爆發式增長。
你本地可能裝了 Claude Code、Codex、OpenClaw,又接了一堆 MCP,再加上各種自定義 Skill。
技能數量很快就從幾十個漲到幾百個,甚至上千個。
這時候問題就來了:
你知道這 1000 個技能里,哪幾個能組合起來解決你當前的問題嗎?
你大概率不知道。
你要一個個翻文檔、試組合、調參數,試到最后可能已經忘了自己本來要干嘛。
這就是 OpenSquilla 提到的「組合災難」。
更麻煩的是,今天的 Skill 組合還嚴重依賴「專家經驗」。
你得知道先調 A 再調 B,A 的輸出格式要匹配 B 的輸入格式,C 失敗了要用 D 兜底。
這些約束全寫在人的腦子里,或者硬編碼在腳本里。
一旦 Skill 社區更新了,你的腳本可能就廢了。
MetaSkill 解決的就是這個問題。
它讓 Agent 像人類組織專業知識那樣,學會自我組織技能。
不需要你記住每個 Skill 的能力邊界,不需要你手動拼接流程圖。
你只需要用自然語言描述目標,剩下的交給 Harness 層。
![]()
這也引出了一個更有意思的判斷:
Agent 的下一輪效率紅利,可能不來自模型升級,而來自 Harness 層優化。
模型再強,如果只會一個任務一個任務地硬干,成本也高不到哪去。
真正拉開差距的,是能不能在 Skill 組織層做「輸入減量化」。
把優化前置到 Skill 組合層,比讓 Agent 在線反復 trial-and-error 有效得多。
OpenSquilla 的智能路由也是這個思路:
簡單任務用便宜模型,復雜任務用好模型,緩存命中的直接復用結果。
比如這里 DeepSeek-v4-flash 和 DeepSeek-v4-pro 就會根據任務復雜程度自動選擇,對于復雜的任務,OpenSquilla 會把它移交給 pro 處理。
![]()
MetaSkill 建立在這層路由之上,進一步把工作流的編排也自動化了。
從 1.0 的智能路由,到 3.0 的 MetaSkill,能看出這是一條很清晰的產品主線。
我把 OpenSquilla 接進 WeSight 之后,最大的感受是:
Agent 開始像人了。
說話像不像人不重要,關鍵是它干活的方式像人。
遇到一個新問題,它會先看看自己會不會,不會就去找資料,找到資料再組織成方案,最后執行。
這套「自組織」的能力,才是 Agent 真正走向實用的關鍵一步。
當然,OpenSquilla 現在也不是完美的。
有些復雜的工作流,它編排起來還不夠穩;有些 Skill 的依賴關系,它判斷得也不夠準。
但至少方向是對的。
讓 Agent 學會自己造工具,比給 Agent 造更多工具,重要得多。
如果你對這個方向感興趣,可以去 GitHub 搜 OpenSquilla 看看,給個 Star 支持下開源社區。
我也在繼續打磨 WeSight 和 OpenSquilla 的集成體驗,后續有新的玩法再跟大家分享。
你覺得 Agent 自組織技能這件事,靠譜嗎?歡迎在評論區聊聊。
好的工具,就是讓你少想一件事。
當 Agent 學會自己組織技能的那天,我們也許真的只需要專注于創意本身了。
剩下的,交給它們吧。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.