Skills

起因 工作上有個需求：把散落在多個內部 API 的資料整合成一份分析報告。涉及的資料源有好幾個，每個 API 的認證方式、資料格式、存取路徑都不一樣。 我手上有兩個 AI agent 環境——一個跑 Claude（Opus），是我自己長期使用的個人 agent；另一個跑 OpenAI 的模型，是公司環境。需求最終要在公司環境執行，但探索和開發的過程在個人 agent 上進行比較順手。 問題來了：怎麼把我跟個人 agent 討論出來的知識，有效地交給公司 agent 使用？ 不能只丟一段文字 最直覺的做法是把對話結論複製貼上，寫個文件丟過去。但實際試了就知道——一份平鋪直敘的文件，agent 讀完還是會問你一堆問題： 「這個 API 的 base URL 是什麼？」 「認證 token 放哪裡？」 「回傳格式是 JSON 還是 Parquet？」 「欄位名稱是 revenue 還是 acc_R100？」 每個問題都合理，但每次來回都是時間成本。尤其在 Telegram 這種非同步介面上，一個問題可能要等你看到、回覆、agent 再繼續，中間過了好幾分鐘。 Skills 作為 Agent 間的介面 後來採用的做法是把知識打包成一個 Skills 專案。這是 OpenClaw 生態系的一個概念，但核心想法跟框架無關： skills/ ├── my-skill/ │ ├── SKILL.md # 入口：agent 第一個讀的文件 │ └── references/ # 詳細參考資料 │ ├── api-guide.md │ └── data-sources.md └── knowledge/ └── domain-logic.md # 領域知識和判斷邏輯 SKILL.md 是關鍵。它不是寫給人看的文件，是寫給 agent 看的操作手冊。結構大概長這樣： ...