book-to-skill:把技術書變成 Agent 技能,按需載入省下超 90% token
開源工具 book-to-skill 能將技術書或文件編譯為符合 Agent Skills 標準的結構化檔案。它一次性提取章節架構,後續按需呼叫對應章節,單次查詢僅約 5K token,比整書塞入上下文省下 24 到 51 倍消耗。支援 Claude Code、Copilot CLI 等多端使用。
買了一本 500 頁的大部頭技術書,認認真真通讀一遍,三個月後在終端裡寫程式碼,你甚至想不起來第七章講過什麼。
遇到問題,大部分人的習慣是把整本 PDF 扔進對話方塊,或者讓寫程式碼的 Agent 自己去讀。結果顯而易見:要麼上下文瞬間被撐爆,要麼模型在漫長的翻頁和目錄跳轉裡迷路,回答得牛頭不對馬嘴,還順手燒掉一大堆 token。
開源工具 book-to-skill 想解決的正是這個痛點。它把書籍和文件當成工作流裡的一個外掛,只在 Agent 需要的時候按需載入。
一次編譯,按需翻開一章
book-to-skill 並不是簡單的全文搜尋,它的核心邏輯是把非結構化的書籍變成一個「知識編譯器」。
整套流程分為兩步。第一步是由一個確定性的 Python 提取器掃一遍文件,抓取乾淨的文本與後設資料。第二步是由模型分析合併後的文本,梳理出章節脈絡、思維框架、決策規則和反模式,編譯成符合 Agent Skills 標準的結構化檔案。
這意味著你只需要為整本書支付一次結構化解析的成本。如果使用 Claude Sonnet 4.5 處理一本 400 頁的技術書,前置解析費用大約只要 1 美元。
編譯完成後,整本書被拆解成核心索引和各章節的獨立檔案。Agent 平時只加載最頂層的輕量索引,只有當你輸入類似查詢複製機制的指令時,它才會精準載入對應的第七章內容,直接基於原文細節作答。
實測資料顯示,這種按需呼叫的機制讓單次查詢只需要約 5K token。相比把整本 PDF 一股腦塞進上下文,token 消耗降低了 24 到 51 倍。
誰能用,裝在哪裡
除了常規的技術書,這個工具支援的輸入非常雜:PDF、EPUB、DOCX、TXT、Markdown、HTML、RTF 和 MOBI 格式都能處理。哪怕是公司的架構決策記錄、入職指南、品牌規範或 RFC 協議,只要是你經常需要查閱又背不下來的資料,都可以餵給它。
在相容性上,book-to-skill 遵循了開放的 Agent Skills 標準。生成的技能預設儲存在跨 Agent 的統一目錄中,GitHub Copilot CLI、Amp、Codex、OpenCode 和 OpenClaw 都能直接讀取。
如果你用的是 Claude Code,轉換器會自動在對應目錄下建立軟連結;Hermes Agent 這類按分類管理技能的主機,也可以指定路徑安裝。想要嘗試的話,終端裡執行一行 npx skills add virgiliojr94/book-to-skill 就能裝上。
為什麼重要
把長文本餵給 AI,目前行業最常用的解法是外掛 RAG 向量檢索,或者依賴超大上下文硬吃。但這兩條路在複雜工作流裡都有硬傷:RAG 經常切碎上下文,丟掉整本書的全域性框架;大上下文不僅貴,模型還容易在無關細節裡產生幻覺。
book-to-skill 的聰明之處在於,它換了一個思路:把靜態知識軟體化。它把一本書重構成了一組結構化的業務規則和按需載入的函式,讓 Agent 像呼叫工具一樣去查書。從工程上看,這種一次性預編譯加上按需解壓的結構,極大地控制了日常推理的成本。
對開發者和重度研究者來說,這意味著你可以把那些讀過就忘的參考書,真正變成手邊隨時待命的數字副駕。只要一兩美元的轉換成本,就能給終端配上幾個懂專業規範的顧問。
不過目前這套方案也存在門檻。預編譯過程依賴模型的結構化提取能力,如果原書排版混亂或公式密集,提取質量會直接影響後續問答;另外它適合框架清晰的工具書和規範,並不適用於情節分散的敘事類讀物。但我們認為,這種將領域知識編譯為標準 Agent 技能的嘗試,很可能會成為未來工程文件交付的主流形態。
來源 (1)
- github.com(在新分頁開啟)原文github.com