DMBlog onepage/ fable-5-second-brain
Machina · X Article · 2026-07-03

Fable 5 第二大腦:用 Obsidian 讓 Agent 讀懂你的業務

Machina 的文章把 Fable 5 的差異化拉回一個很務實的問題:同一個模型,為什麼有人得到制式輸出,有人得到像是熟悉自己業務的產物?答案不是神奇 prompt,而是讓 agent 能穩定讀取你的知識庫、風格、決策與研究證據。

Source type
X Article
Main topic
Agent memory
Base tool
Obsidian
Core claim
Context compounds
Read first

這篇文章不是在教筆記術,而是在教 agent 的上下文工程

Machina 的核心觀點是:模型本身再強,如果完全不知道你的業務、受眾、架構、過去決策與語氣,它只能用一般化的模式猜。把模型接上一個你擁有、可讀、可維護的 markdown vault,同一個模型才會開始產生差異化輸出。

Obsidian 在這裡不是被當成漂亮筆記 app,而是被當成 agent 可以直接操作的檔案系統。人用 Obsidian 看圖譜、編輯筆記;agent 用 Claude Code 或類似終端環境讀寫 markdown。雙方看的是同一個資料夾,這讓知識庫能同時服務人腦與機器。

01 / Ownership

記憶要在你自己的檔案裡

文章主張用本機 markdown,而不是把所有知識綁進某個黑箱資料庫。可讀、可 diff、可備份,才適合長期交給 agent 使用。

02 / Structure

資料夾結構比工具品牌重要

raw、entities、concepts、INDEX.md 這四塊把原始證據、整理後知識與導航入口分開,避免知識庫變成一堆搜尋噪音。

03 / Compounding

每次整理都應該讓下次更好

好的第二大腦不是儲藏室,而是會透過連結、來源、維護循環與研究流程,把新的材料變成下次任務可用的上下文。

The build

Machina 的第二大腦可以拆成六個實作層

這套方法的重點不是一次做一個完美知識庫,而是先建立能讓 agent 穩定讀、穩定寫、穩定查證的最小系統。下面是文章精神整理後的工程版流程。

01

先把 raw/ 當成不可改的事實層

所有捕捉到的資料先放進 raw:訪談、舊聊天、書籤、逐字稿、客戶文件、研究材料。agent 可以引用與整理,但不應把原始資料改寫成自己的二手記憶。

02

把 entities 與 concepts 當成編譯後知識

agent 從 raw 中萃取具體對象與抽象模式,更新既有頁面,而不是每次都開新檔。這能讓客戶、工具、策略與教訓逐步累積。

03

用 INDEX.md 降低讀取成本

INDEX 是知識庫的地圖。agent 先看索引,再沿著連結與關鍵字打開少量相關頁面,避免把整個 vault 塞進昂貴的上下文視窗。

04

用 /goal 或長任務回填歷史資料

先把舊材料丟進 raw,再讓 agent 逐批整理成 entities 與 concepts。每次更新都應該能用 diff 與 source link 證明,不要只相信模型口頭宣稱。

05

用排程維護,而不是靠記憶維護

文章建議把維護拆成 session 結束後的擷取、每日低成本整理、每週 lint、每週高階綜合。這讓 vault 不會三週後變成沒人敢碰的資料堆。

06

把研究流程接進知識庫

研究不是問一次 chatbot,而是拆問題、平行查不同來源、留下 claim/source/date,再讓懷疑者角色攻擊每個結論。通過檢查的結果才進入 vault。

Why it works

第二大腦的價值不是保存更多文字,而是讓 agent 在每次任務開始時,能找到與這次問題真正相關的少量可信上下文。

本頁依公開 X Article payload 改寫;數字與案例屬原作者論述,未視為第三方驗證結論。
Cost control

真正的難點是讓 agent 讀得準、讀得少、讀得值得

文章很強調 token 成本:知識庫如果每次都整包載入,很快就會變成昂貴又遲鈍的系統。比較好的設計是讓常駐規則保持短小,只告訴 agent 去哪裡找;真正內容按需讀取。

大型問題可以交給子 agent 先讀很多頁,再把濃縮結論回傳主對話。主上下文保留決策、矛盾與下一步,不承擔整座資料庫。這個分工把「閱讀」和「決策」拆開,才有機會在長期任務中維持成本可控。

CLAUDE.md 只放路標,不放整座圖書館固定啟動檔應該短,指向 vault 的讀取規則、資料夾位置與引用要求即可。
先索引,再連結,再少量開檔讓 agent 從 INDEX.md、wikilinks 與 grep 開始,而不是第一步就掃完整個資料夾。
讓子任務消化材料大範圍閱讀可以放進獨立 context,主任務只接收結論、來源與不確定性。
每個結論都要能回到 raw沒有來源鏈的整理頁,不應該被當成可信記憶。這是避免知識庫自我污染的底線。
Builder view

對工程師的實用解讀

如果你正在做 coding agent、研究助理、內容流水線或客戶服務 copilot,這篇文章的實用訊息是:不要只評估模型排行榜,也要評估模型能否穩定接上你的私有上下文。模型越強,越需要一套能讓它正確引用、更新與檢查知識的外部記憶。

最小可行版本不需要龐大架構:一個 Obsidian vault、四個入口、十幾份關鍵文件、一份短規則檔、一個整理任務、一個每週檢查流程,就足以讓 agent 開始從「一般助手」變成「熟悉你業務的工作者」。

TL;DR