AI 時代的個人知識庫：Obsidian、RAG 與 Agent 該怎麼分工？

以前談個人知識管理，很多人關心的是「怎麼把東西記下來」。

用什麼筆記軟體？要不要做雙向連結？資料夾怎麼分類？標籤怎麼設計？這些問題都很重要，但當筆記累積到一定數量之後，真正麻煩的通常不是記錄，而是重新取用。

你知道自己以前寫過某個想法，但找不到。
你記得某篇文章提過一個概念，但忘了放在哪裡。
你想寫一篇文章，結果需要翻十幾篇舊筆記、剪貼、整理、重組，最後反而卡在準備工作。

AI 出現之後，這個問題變得更有趣。

我們開始可以讓模型幫忙摘要、整理、改寫，甚至產生草稿。但如果只是把一大堆筆記丟給聊天機器人，得到的常常不是更好的知識工作流，而是一段看起來很完整、實際上不知道根據哪裡來的回答。

所以問題不是「要不要用 AI 管理筆記」。

問題是：
Obsidian、RAG 和 AI Agent 各自應該負責什麼？

如果分工不清楚，最後很容易變成三種混亂疊在一起：

• Obsidian 裡的筆記沒有結構
• RAG 找到的資料不夠準
• Agent 很努力產出內容，但你不知道它根據什麼寫出來

我比較喜歡把它們想成一套工作系統，而不是單一工具。

• Obsidian：保存知識
• RAG：找出相關內容
• Agent：整理、重組、產出
• CLI / Local workflow：把流程固定下來

這樣看，事情會清楚很多。

Obsidian 負責保存，不該負責全部

Obsidian 很適合當個人知識庫的底層。

它使用 Markdown，檔案存在本機，不太綁平台。你可以用資料夾整理，也可以用雙向連結建立脈絡。更重要的是，這些筆記不是被鎖在某個服務裡，而是你可以直接打開、搬移、搜尋、備份的一堆文字檔。

這件事在 AI 工作流裡很重要。

因為只要資料是一般檔案，就可以被其他工具讀取。CLI 可以處理它，搜尋工具可以索引它，Agent 也可以直接操作它。

但 Obsidian 本身不應該負責所有事情。

它不是資料庫，也不是自動化系統。它可以讓人閱讀和編輯筆記，但不會自動幫你判斷哪些內容可以合併，哪些內容可以變成文章，哪些舊筆記其實已經過期。

更麻煩的是，如果 vault 本身很亂，AI 只會把混亂放大。

例如：note1.md、new.md、untitle.md、想法.md

這種命名方式，人類自己過幾個月都不一定看得懂，更不用說要讓 Agent 穩定處理。

所以在談 RAG 或 Agent 之前，Obsidian vault 本身至少要有基本結構。

不一定要很複雜，但要穩定。

例如：

1
vault/
2
├─ inbox/
3
├─ notes/
4
├─ refs/
5
├─ drafts/
6
├─ projects/
7
├─ meetings/
8
└─ templates/

每個資料夾的用途要清楚：

• inbox/ 放還沒整理的零散內容
• notes/ 放長期保存的知識筆記
• refs/ 放外部文章、書籍、資料來源
• drafts/ 放文章草稿
• projects/ 放專案相關筆記
• meetings/ 放會議紀錄
• templates/ 放固定格式

Frontmatter 也最好維持一致。

1
---
2
title: RAG 與個人知識庫
3
created: 2026-05-28
4
tags:
5
  - rag
6
  - obsidian
7
  - ai-agent
8
status: draft
9
---

這些東西看起來很瑣碎，但它們是後面工作流能不能穩定的基礎。

Obsidian 的價值不是自動化，而是讓知識保持可讀、可改、可長期保存。

RAG 負責查到正確資料

RAG 的全名是 Retrieval-Augmented Generation，中文通常翻成檢索增強生成。

名字聽起來很大，但放在個人知識庫裡，它做的事情其實很直覺：

先查資料，再讓 AI 回答。

這解決的是 LLM 很常見的一個問題：模型很會生成文字，但不一定知道你的資料。

如果你問模型「我之前寫過哪些關於 Obsidian 的想法？」它不可能憑空知道你的 vault 裡有什麼。除非你把相關內容提供給它，否則它只能猜。

RAG 的角色就是補上這一段。

大致流程會像這樣：

1
1. 將筆記切成 chunks
2
2. 用 embedding 模型把文字轉成向量
3
3. 儲存到向量資料庫或索引中
4
4. 查詢時，把問題也轉成向量
5
5. 找出語意上最接近的筆記片段
6
6. 把這些片段交給 LLM 生成回答

這裡最重要的不是「用了多厲害的模型」，而是檢索結果有沒有找對東西。

如果 RAG 找到的內容不相關，後面的 LLM 寫得再流暢也沒有用。它只是把錯的上下文包裝得比較像答案。

對個人知識庫來說，RAG 最大的價值不是讓 AI 變聰明，而是讓 AI 少一點亂猜。

例如你想寫一篇關於「AI 筆記工作流」的文章，RAG 可以先幫你找出：

• 你以前寫過的 Obsidian 筆記
• 關於 RAG 的技術整理
• 你保存過的外部文章摘錄
• 相關專案中的決策紀錄
• 曾經寫到一半的草稿

這些資料被找出來之後，Agent 才有東西可以操作。

沒有 RAG 的 Agent 很容易變成單純的聊天機器人。
有 RAG 的 Agent 才比較像是在你的資料上工作。

但 RAG 也不是魔法。

它很吃幾個前置條件：

• 筆記切分方式是否合理
• 每個 chunk 是否保留足夠上下文
• metadata 是否有標題、日期、標籤、來源
• 查詢語句是否清楚
• 檢索結果是否需要 rerank
• 過期筆記是否仍然被搜出來

所以 RAG 不是裝上去就好。它比較像是給知識庫加上一層語意搜尋能力。

搜尋變好了，但內容本身還是要整理。

Agent 負責把資料變成行動

如果說 RAG 是「找資料」，Agent 就是「用資料做事」。

這是兩者最重要的差別。

RAG 找出相關筆記，然後呢？
如果最後還是要你自己一篇篇打開、複製、貼上、整理，那它只是比較聰明的搜尋。

Agent 的價值在於它可以執行多步驟任務。

例如：

1
1. 搜尋和某個主題相關的筆記
2
2. 讀取這些筆記
3
3. 整理出共同觀點
4
4. 找出重複或矛盾的地方
5
5. 產生文章大綱
6
6. 寫入 drafts/
7
7. 等人類最後編輯

這裡的關鍵不是「AI 幫我寫文章」，而是「AI 幫我處理寫作前最耗力的整理工作」。

以部落格寫作來說，Agent 很適合做這些事：

• 從舊筆記中整理主題
• 把零散想法變成大綱
• 根據既有文章風格產生初稿
• 補上可延伸閱讀的內部連結
• 檢查文章是否有重複段落
• 幫草稿補 frontmatter
• 把會議紀錄整理成可追蹤的 action items

但它不適合完全接管判斷。

我不會讓 Agent 自動決定哪些筆記應該刪除，也不會讓它直接把一批舊文章全部改寫後覆蓋。這些事情太容易出問題，而且錯了不一定馬上看得出來。

比較安全的方式是讓 Agent 產生新檔案，而不是直接覆蓋原始資料。

例如：

1
notes/obsidian-ai-workflow.md
2
refs/rag-embedding-notes.md
3
refs/local-first-ai.md
4

5
↓ Agent 整理
6

7
drafts/ai-personal-knowledge-base-outline.md

這樣原始筆記還在，AI 輸出也可以檢查。你可以接受、修改，或整份刪掉。

Agent 應該像一個能幫你整理書桌的人，而不是一個可以自己丟掉你所有文件的人。

CLI 讓流程變得可重複

只用聊天介面操作 AI，常常會有一個問題：流程很難重複。

今天你貼了三篇筆記，請 AI 整理成大綱。
明天你又貼了五篇，請它照昨天的方式處理。
過幾天你忘了 prompt 怎麼寫，輸出格式又變了。

如果只是偶爾使用，這沒什麼問題。
但如果你想把它變成長期工作流，就需要更固定的流程。

這時候 CLI 或本機腳本就很有用。

你可以把任務拆成幾個明確步驟：

1
read → retrieve → transform → write → review

例如一個「產生文章草稿」的流程可能是：

1
1. 從 notes/ 和 refs/ 搜尋主題
2
2. 找出最相關的 10 個片段
3
3. 將片段整理成文章大綱
4
4. 根據大綱產生初稿
5
5. 寫入 drafts/
6
6. 保留來源引用，方便人工檢查

這樣做的好處是，每一步都可以被檢查。

如果結果不好，你可以知道問題在哪裡：

• 是資料找錯？
• 是 chunk 太小？
• 是 prompt 寫得不清楚？
• 是 Agent 寫作風格太平？
• 是原始筆記本來就不夠完整？

工作流一旦拆開，就比較容易修。

這也是我覺得 local-first workflow 很有吸引力的地方。它不是把所有東西都交給某個雲端服務，而是讓資料、流程和輸出都盡量留在自己可控的環境中。

一個最小可行的個人知識工作流

如果要從零開始，不需要一開始就做完整 RAG 系統，也不需要馬上接很多 Agent 工具。

可以先從一個很小的流程開始。

例如：把零散筆記整理成文章大綱。

1. 先整理資料夾

1
vault/
2
├─ inbox/
3
├─ notes/
4
├─ refs/
5
└─ drafts/

先不用太多分類。能穩定使用比較重要。

2. 統一筆記格式

每篇筆記至少有標題、日期、標籤、狀態。

1
---
2
title: AI agent 與筆記整理
3
created: 2026-05-28
4
tags:
5
  - ai-agent
6
  - obsidian
7
status: note
8
---

3. 把原始想法放進 inbox

不要急著整理。先收集。

1
inbox/2026-05-28-ai-writing-ideas.md
2
inbox/2026-05-28-rag-notes.md

4. 定期整理成 notes 或 refs

自己判斷哪些是長期有用的想法，哪些只是暫時資料。

1
notes/personal-knowledge-base.md
2
refs/rag-retrieval-notes.md

5. 讓 Agent 產生草稿

任務可以寫得很具體：

1
請讀取 notes/ 和 refs/ 中與 "AI 個人知識庫" 相關的筆記，整理出一篇部落格文章大綱，輸出到 drafts/ai-personal-knowledge-base.md。
2

3
請保留引用到的來源筆記檔名，不要修改原始筆記。

這裡有幾個重點：

• 指定讀取範圍
• 指定輸出位置
• 要求保留來源
• 明確禁止修改原始筆記

這樣 Agent 比較不會亂跑。

6. 人類最後編輯

最後一步還是要回到人。

AI 可以整理資料，但文章裡真正重要的通常是你的判斷：

• 哪個觀點你認同？
• 哪個工具你用起來其實不順？
• 哪些流程看起來很美，但實際上很難維持？
• 哪些限制你踩過坑？

這些東西 AI 可以模仿，但最好不要讓它憑空發明。

不要把所有事情都交給 AI

AI 很適合處理文字工作，但不是所有文字工作都該交給它。

尤其是個人知識庫，裡面的東西通常很雜。有些是公開資料，有些是私人想法，有些可能包含工作內容、客戶資訊、會議紀錄或尚未整理的判斷。

幾件事我會特別避免：

不要讓 AI 自動刪筆記

刪除是不可逆的知識管理動作。

AI 可以建議哪些筆記可能重複，或哪些內容可能已經過期，但最後要不要刪，最好還是自己決定。

比較安全的做法是：

1
archive/

先歸檔，不要直接刪。

不要讓 AI 決定最終觀點

AI 很會把資料整理成看似平衡的說法，但文章真正有價值的地方常常不是平衡，而是取捨。

你可以讓 AI 幫忙列出不同觀點，但最後應該由你決定文章要站在哪裡。

不要讓 AI 把未確認內容寫成事實

這在草稿裡很常見。

例如 AI 可能會把「我猜這可能跟效能有關」改成「這會導致效能問題」。
語氣變得更肯定，但事實基礎沒有變多。

所以最好在 prompt 裡要求它區分：

• 已確認事實
• 推測
• 待查證
• 個人觀點

不要讓 AI 大規模覆蓋 vault

批次修改很誘人，但也很危險。

尤其是 frontmatter、標籤、連結這些東西，一次改錯可能會讓整個 vault 的結構變得很難追。

我比較建議 Agent 先輸出修改建議，或產生 patch，再由人確認。

不要忽略資料隱私

如果筆記裡有敏感資料，就要想清楚模型在哪裡執行。

本機模型、雲端模型、公司內部模型，風險不一樣。不是所有內容都適合送出去。

知識庫會從收藏系統變成產出系統

過去建立個人知識庫，常常像是在建立一個收藏系統。

看到好文章，存起來。
想到好句子，記下來。
讀到有用的概念，放進筆記。

這些都沒錯，但收藏本身不會自動變成產出。

AI Agent 出現之後，個人知識庫開始有另一種可能：它不只是保存資訊，而是可以被查詢、整理、重組，最後變成文章、簡報、決策紀錄或專案文件。

但前提是分工要清楚。

Obsidian 負責保存。
RAG 負責檢索。
Agent 負責操作。
CLI 或固定流程負責讓這件事可以重複。

如果這幾層混在一起，很容易變成一套看起來很先進、實際上很難維護的系統。

我現在比較相信的方向是：先不要追求全自動。

先讓 AI 幫你完成一個小任務就好。

例如：

1
把三篇舊筆記整理成一篇文章大綱。

如果這件事穩定，再往下做：

1
把一週的 inbox 整理成 notes。

再更進一步：

1
從 notes 和 refs 產生草稿。

個人知識庫不需要一開始就變成完整的 AI 系統。
它可以從一個資料夾、一種筆記、一個流程開始。

重點不是讓 AI 替你思考，而是讓你過去累積的知識更容易被重新使用。

這可能才是 AI 對個人知識管理最實際的幫助。