個人大腦作業系統：為 AI 代理設計檔案型上下文架構
日期: Sat Feb 21 19:07:04 +0000 2026
標籤:
AI代理系統上下文工程知識管理
來源: @koylanai (Muratcan Koylan) 日期: 2025-03-06 標籤:
AI工具Context Engineering知識管理Agent Skills
檔案系統就是新資料庫：我如何為 AI 代理打造個人作業系統
每次 AI 對話都以同樣方式開始。你解釋你是誰、你在做什麼、貼上你的風格指南、重新描述你的目標。你給出昨天、前天、大前天都給過的相同脈絡。然後，對話進行到 40 分鐘時，模型忘記了你的聲音，開始像新聞稿一樣寫作。
我厭倦了這種情況。所以我建立了一個系統來解決它。
我稱之為 Personal Brain OS。這是一個基於檔案的個人作業系統，存放在 Git repository 中。複製它，在 Cursor 或 Claude Code 中打開，AI 助手就擁有一切：我的聲音、我的品牌、我的目標、我的聯絡人、我的內容管道、我的研究、我的失敗。沒有資料庫、沒有 API keys、沒有建置步驟。只有 80 多個 markdown、YAML 和 JSONL 檔案，人類和語言模型都能原生讀取。
我分享完整的架構、設計決策和錯誤，讓你可以建立自己的版本。不是我的複製品；而是你自己的。具體的模組、檔案架構、技能定義會因你的工作而不同。但模式是可轉移的。為 AI 代理結構化資訊的原則是通用的。採用適合的部分，忽略不適合的，然後交付一個讓你的 AI 真正有用而不是泛泛有用的東西。
以下是我如何建立它、為什麼架構決策很重要，以及我艱難學到的經驗。
1) 核心問題：脈絡，而非提示詞
大多數人認為 AI 助手的瓶頸在於提示詞。寫更好的提示詞，得到更好的答案。對於單次互動和生產環境的 agent prompts 來說這是對的。但當你希望 AI 在數週和數月間跨越數十個任務像你一樣運作時，這就不適用了。
注意力預算 (Attention Budget)：語言模型有有限的脈絡視窗，而且並非所有部分都是平等創建的。這意味著把你知道的一切都倒進系統提示詞中不僅浪費，還會主動降低性能。你添加的每個 token 都在競爭模型的注意力。
我們的大腦以類似方式運作。當有人在會議前向你簡報 15 分鐘，你會記住他們說的第一件事和最後一件事。中間的部分會模糊。語言模型有相同的 U 型注意力曲線，只是它們的曲線是數學上可測量的。Token 位置影響回憶機率。較新的模型在這方面有所改善，但仍然，你正在分散模型對最重要事物的注意力。知道這一點會改變你為 AI 系統設計資訊架構的方式。
我沒有寫一個龐大的系統提示詞，而是將 Personal OS 分成 11 個獨立模組。當我要求 AI 寫部落格文章時，它載入我的聲音指南和品牌檔案。當我要求它準備會議時，它載入我的聯絡人資料庫和互動歷史。模型在內容任務期間永遠不會看到網路資料，在會議準備任務期間也永遠不會看到內容模板。
漸進式揭露 (Progressive Disclosure)：這是讓整個系統運作的架構模式。系統不是一次載入所有 80 多個檔案，而是使用三個層級。Level 1 是始終載入的輕量級路由檔案。它告訴 AI 哪個模組是相關的。Level 2 是模組特定的指令，只在需要該模組時載入。Level 3 是實際資料——JSONL 日誌、YAML 配置、研究文件，只在任務需要時載入。
這反映了專家的運作方式。三個層級創建了一個漏斗：廣泛路由、然後模組脈絡、然後特定資料。在每一步，模型擁有它需要的一切，僅此而已。
我的路由檔案是 SKILL.md，它告訴代理「這是內容任務，載入品牌模組」或「這是網路任務，載入聯絡人」。模組指令檔案（CONTENT.md、OPERATIONS.md、NETWORK.md）各 40-100 行，包含檔案清單、工作流程序列，以及一個 <instructions> 區塊，包含該領域的行為規則。資料檔案最後載入，只在需要時。AI 逐行從 JSONL 讀取聯絡人，而不是解析整個檔案。三個層級，最多兩跳到達任何資訊片段。
Agent 指令階層 (Agent Instruction Hierarchy)：我建立了三層指令，在不同層級界定 AI 的行為範圍。在 repository 層級，CLAUDE.md 是入職文件——每個 AI 工具首先讀取它並獲得專案的完整地圖。在 brain 層級，AGENT.md 包含七個核心規則和一個決策表，將常見請求映射到精確的行動序列。在模組層級，每個目錄都有自己的指令檔案，包含領域特定的行為約束。
這解決了困擾大型 AI 專案的「衝突指令」問題。當所有東西都存在於一個系統提示詞中時，規則會相互矛盾。內容創建指令可能與網路指令衝突。通過將規則限定在它們的領域，你消除了衝突，並給代理清晰、不重疊的指導。階層也意味著你可以更新一個模組的規則，而不會冒著另一個模組行為倒退的風險。
我的 AGENT.md 是一個決策表。AI 讀取「使用者說『發送電子郵件給 Z』」，立即看到：
- 步驟 1，在 HubSpot 中查找聯絡人
- 步驟 2，驗證電子郵件地址
- 步驟 3，通過 Gmail 發送
模組層級的檔案如 OPERATIONS.md 定義優先順序等級（P0：今天做、P1：本週、P2：本月、P3：待辦事項），因此代理一致地分類任務。代理遵循我使用的相同優先順序系統，因為系統是編碼的，而不是隱含的。
2) 檔案系統作為記憶
我做的最違反直覺的決定之一：沒有資料庫。沒有向量儲存。除了 Cursor 或 Claude Code 的功能外，沒有檢索系統。只有磁碟上的檔案，用 Git 版本控制。
格式-功能映射 (Format-Function Mapping)：系統中的每種檔案格式都是基於 AI 代理如何處理資訊的特定原因選擇的。JSONL 用於日誌，因為它在設計上是僅附加的、對串流友好的（代理逐行讀取而不解析整個檔案），並且每一行都是自包含的有效 JSON。YAML 用於配置，因為它乾淨地處理階層資料、支援註釋，並且人類和機器都可以讀取，沒有 JSON 括號的雜訊。Markdown 用於敘述，因為 LLM 原生讀取它、在任何地方渲染，並且在 Git 中產生乾淨的 diff。
JSONL 的僅附加特性防止了一類 bug，即代理意外覆蓋歷史資料。我見過這種情況發生在 JSON 檔案上——代理寫入整個檔案，丟失三個月的聯絡人歷史。使用 JSONL，代理只能添加行。刪除是通過將條目標記為 "status": "archived" 來完成的，這保留了完整歷史以進行模式分析。YAML 的註釋支援意味著我可以用代理讀取但不污染資料結構的脈絡來註釋我的目標檔案。Markdown 的通用渲染意味著我的聲音指南在 Cursor、GitHub 和任何瀏覽器中看起來都一樣。
我的系統使用 11 個 JSONL 檔案（posts、contacts、interactions、bookmarks、ideas、metrics、experiences、decisions、failures、engagement、meetings）、6 個 YAML 檔案（goals、values、learning、circles、rhythms、heuristics）和 50 多個 Markdown 檔案（voice guides、research、templates、drafts、todos）。每個 JSONL 檔案都以 schema 行開始：{"_schema": "contact", "_version": "1.0", "_description": "..."}。代理在讀取資料之前始終知道結構。
情節記憶 (Episodic Memory)：大多數「第二大腦」系統儲存事實。我的系統也儲存判斷。memory/ 模組包含三個僅附加日誌：experiences.jsonl（具有情感權重分數 1-10 的關鍵時刻）、decisions.jsonl（關鍵決策及其推理、考慮的替代方案和追蹤的結果）和 failures.jsonl（出了什麼問題、根本原因和預防步驟）。
擁有你的檔案的 AI 和擁有你的判斷的 AI 之間有區別。事實告訴代理發生了什麼。情節記憶告訴代理什麼重要、我會做什麼不同的事，以及我如何思考權衡。當代理遇到類似於我記錄過的決策時，它可以參考我過去的推理，而不是產生泛泛的建議。失敗日誌最有價值——它編碼了需要真正痛苦才能獲得的模式識別。
當我決定是接受 Antler Canada 的 25 萬美元投資還是加入 Sully.ai 擔任 Context Engineer 時,決策日誌捕獲了兩個選項、每個選項的推理和結果。如果出現類似的職業權衡,代理不會給我泛泛的職業建議。它參考我實際如何思考這些決策：「學習 > 影響 > 收入 > 成長」是我的優先順序，「我能接觸一切嗎？我會在我能力的邊緣學習嗎？我尊重創辦人嗎？」是我的公司加入框架。
跨模組引用 (Cross-Module References)：系統使用平面檔案關聯模型。沒有資料庫，但結構足夠讓代理跨檔案連接資料。interactions.jsonl 中的 contact_id 指向 contacts.jsonl 中的條目。ideas.jsonl 中的 pillar 映射到 identity/brand.md 中定義的內容支柱。書籤餵養內容想法。文章指標餵養每週回顧。模組為了載入而隔離，但為了推理而連接。
沒有連接的隔離只是一堆資料夾。跨引用讓代理在需要時遍歷知識圖。「準備我與 Sarah 的會議」觸發查找鏈：在聯絡人中找到 Sarah、拉取她的互動、檢查涉及她的待辦事項、編譯簡報。代理跨模組遵循引用，而不載入整個系統。
我的會前工作流程鏈接三個檔案：contacts.jsonl（他們是誰）、interactions.jsonl（按 contact_id 過濾的歷史）和 todos.md（任何待辦項目）。代理產生一頁簡報，包含關係脈絡、最後對話摘要和未完成的後續行動。無需手動組裝。資料結構使工作流程成為可能。
3) 技能系統：教 AI 如何做你的工作
檔案儲存知識。技能編碼流程。我按照 Anthropic Agent Skills 標準建立了 Agent Skills——結構化指令，告訴 AI 如何執行特定任務，並內建品質關卡。
自動載入與手動調用 (Auto-Loading vs. Manual Invocation)：兩種類型的技能解決兩個不同的問題。參考技能（voice-guide、writing-anti-patterns）在其 YAML frontmatter 中設定 user-invocable: false。代理讀取描述欄位，並在任務涉及寫作時自動注入它們。我從不調用它們——它們每次都靜默啟動。任務技能（/write-blog、/topic-research、/content-workflow）設定 disable-model-invocation: true。代理不能自行觸發它們。我輸入斜線命令，技能成為代理該任務的完整指令集。
自動載入解決了一致性問題。我不必每次要求草稿時都記得說「使用我的聲音」。系統為我記住。手動調用解決了精確性問題。研究任務與部落格文章有不同的品質關卡。將它們分開可防止代理混淆兩個不同的工作流程。YAML frontmatter 是機制，幾個元資料欄位控制整個載入行為。
當我輸入 /write-blog context engineering for marketing teams 時，五件事自動發生：聲音指南載入（我如何寫作）、反模式載入（我永遠不寫什麼）、部落格模板載入（7 個部分結構，每部分有字數目標）、檢查 persona 資料夾中的受眾設定檔、檢查研究資料夾中的現有主題研究。一個斜線命令觸發完整的脈絡組裝。技能檔案本身說「讀取 brand/tone-of-voice.md」，它引用來源模組，從不複製內容。單一事實來源。
聲音系統 (The Voice System)：我的聲音被編碼為結構化資料和一些氛圍。聲音設定檔在 1-10 刻度上評分五個屬性：正式/隨意 (6)、嚴肅/俏皮 (4)、技術性/簡單 (7)、保留/表達 (6)、謙遜/自信 (7)。反模式檔案包含 50 多個禁用詞，分為三層、禁用開場、結構陷阱（強制三原則、copula 迴避、過度避險），以及每段一個破折號的硬性限制。
大多數人用形容詞描述他們的聲音：「專業但平易近人」。這對 AI 來說毫無用處。技術性/簡單刻度上的 7 告訴模型確切的落點。禁用詞清單更強大；定義你不是什麼比定義你是什麼更容易。代理檢查每個草稿是否符合反模式清單，並重寫任何觸發它的內容。結果是聽起來像我的內容，因為護欄防止它聽起來像 AI。
每個內容模板都包含每 500 字的聲音檢查點：「我是否以洞察力領先？我是否用數字具體說明？我真的會發布這個嗎？」部落格模板有內建的 4 遍編輯流程：結構編輯（鉤子是否吸引人？）、聲音編輯（禁用詞掃描、句子節奏檢查）、證據編輯（聲明有來源嗎？）和大聲朗讀測試。品質關卡是技能的一部分，而不是我事後添加的東西。
模板作為結構化腳手架 (Templates as Structured Scaffolds)：五個內容模板定義不同內容類型的結構。長篇部落格模板有七個部分（Hook、Core Concept、Framework、Practical Application、Failure Modes、Getting Started、Closing），每部分有字數目標，總計 2,000-3,500 字。推文串模板定義 11 則貼文結構，包含鉤子、深入探討、結果和 CTA。研究模板有四個階段：景觀映射、技術深入探討、證據收集和差距分析。
模板不僅限制創造力，也限制混亂。沒有結構，代理產生無定形的文字團塊。有了結構，它產生有節奏、有進展、有回報的內容。每個模板還包括品質檢查清單，因此代理可以在呈現草稿之前進行自我評估。
研究模板輸出到 knowledge/research/[topic].md，採用結構化格式：Executive Summary、Landscape Map、Core Concepts、Evidence Bank（包含統計數據、引用、案例研究和論文，每個都標註來源和日期）、Failure Modes、Content Opportunities 和 Sources List（在可靠性上分級為 HIGH/MEDIUM/LOW）。該研究文件然後餵養到部落格模板的大綱階段。一個技能的輸出成為下一個技能的輸入。管道在自身基礎上建立。
4) 作業系統：我實際上如何每天使用它
沒有執行的架構什麼都不是。以下是系統在實踐中的運作方式。
內容管道 (The Content Pipeline)：七個階段：Idea、Research、Outline、Draft、Edit、Publish、Promote。
想法被捕獲到
ideas.jsonl，採用評分系統，每個想法在與定位的一致性、獨特洞察、受眾需求、時效性和努力與影響之間進行 1-5 評分。如果總分達到 15 或更高則繼續。研究輸出到知識模組。
草稿經過四遍編輯。
已發布內容記錄到
posts.jsonl，包含平台、URL 和參與度指標。推廣使用推文串模板創建 X 公告和 LinkedIn 改編。
我在星期日批次創建內容：3-4 小時，目標輸出 3-4 篇草稿和大綱。內容日曆將每一天映射到平台和內容類型。
個人 CRM (The Personal CRM)：聯絡人組織成四個圈子，具有不同的維護節奏：內圈（每週）、活躍（兩週一次）、網路（每月）、休眠（季度重新啟動）。每個聯絡人記錄都有 can_help_with 和 you_can_help_with 欄位，實現介紹匹配系統。交叉引用這些欄位會浮出互惠有價值的介紹。互動被記錄並進行情感追蹤（positive、neutral、needs_attention），因此關係健康狀況一目了然。
大多數人將聯絡人保存在腦中，並因疏忽而讓關係衰退。stale_contacts 腳本交叉引用聯絡人（他們是誰）、互動（我們上次何時交談）和圈子（我們應該多久交談一次）以浮出外展需求。每週 30 秒掃描向我顯示哪些關係需要關注。
circles.yaml 中的專門群組——founders、investors、ai_builders、creators、mentors、mentees，各有明確的關係發展策略。對於 AI builders：分享有用內容、在開源上協作、提供工具反饋、放大他們的工作。對於 mentors：帶來具體問題、更新先前建議的進展、尋找增加價值的方法。這些是代理在我問「本週我應該聯繫誰？」時遵循的操作指令。
自動化鏈 (Automation Chains)：五個腳本處理重複工作流程。它們鏈接在一起進行複合操作。星期日每週回顧按順序運行三個腳本：metrics_snapshot.py 更新數字、stale_contacts.py 標記關係、weekly_review.py 生成摘要文件，包含已完成與計畫、指標趨勢和下週優先事項。內容創意鏈讀取最近的書籤、檢查未開發的想法、生成新建議，並與內容日曆交叉引用以找到排程空檔。這些不是 cron 作業——代理在我要求回顧時運行它們，或者我用 npm run weekly-review 觸發它們。
以代理可讀格式輸出到 stdout 的腳本在資料和行動之間建立迴路。每週回顧腳本不僅告訴我發生了什麼——它引用我的目標並識別哪些關鍵結果在軌道上、哪些落後，以及下週優先考慮什麼。腳本從代理在正常操作期間讀取的相同檔案讀取，因此沒有資料重複或同步問題。
運行每週回顧後，代理擁有更新下週 todos.md、調整 goals.yaml 進度數字並建議與表現不佳的關鍵結果一致的內容主題所需的一切。回顧不是報告——它是下週規劃的起點。自動化創建反饋迴路：目標驅動內容、內容驅動指標、指標驅動回顧、回顧驅動目標。
5) 我做錯了什麼以及我會做什麼不同
我在第一遍過度工程化了 schema。我最初的 JSONL schemas 每個條目有 15 個以上的欄位。大多數是空的。代理難以處理稀疏資料——它們試圖填充欄位或評論缺失。我將 schemas 削減到 8-10 個必要欄位，並且僅在實際有資料時才添加可選欄位。更簡單的 schemas，更好的代理行為。
聲音指南一開始太長。版本一的
tone-of-voice.md有 1,200 行。代理會開始強勁，然後在第四段漂移，因為聲音指令落入中間遺失區域。我重新構建它，在前 100 行優先載入最獨特的模式（標誌性短語、禁用詞、開場模式），擴展範例在更下方。關鍵規則需要在頂部，而不是中間。模組邊界比你想像的更重要。我最初將 identity 和 brand 放在一個模組中。當代理只需要我的禁用詞清單時，它會載入我的整個簡歷。將它們分成兩個模組將僅聲音任務的 token 使用量減少了 40%。每個模組邊界都是一個載入決策。弄錯了，你會載入太多或太少。
僅附加是不可協商的。我早期因為代理重寫
posts.jsonl而不是附加到它而丟失了三個月的文章參與度資料。JSONL 的僅附加模式不僅僅是慣例——它是一種安全機制。代理可以添加資料。它不能破壞資料。這是系統中最重要的架構決策。
6) 結果和背後的原則
真正的結果比任何指標都簡單。我打開 Cursor 或 Claude Code，開始對話，AI 已經知道我是誰、我如何寫作、我在做什麼以及我關心什麼。它用我的聲音寫作，因為我的聲音被編碼為結構化資料。它遵循我的優先事項，因為我的目標在 YAML 檔案中，它在建議做什麼之前讀取。它管理我的關係，因為我的聯絡人和互動在它可以查詢的檔案中。
這一切背後的原則：這是 context engineering，而不是 prompt engineering。Prompt engineering 問「我如何更好地表達這個問題？」Context engineering 問「這個 AI 需要什麼資訊才能做出正確決策，以及我如何結構化該資訊以便模型實際使用它？」
轉變是從優化個別互動到設計資訊架構。這是寫一封好電子郵件和建立一個好的歸檔系統之間的區別。一個幫助你一次。另一個每次都幫助你。
整個系統適合一個 Git repository。將它複製到任何機器，將任何 AI 工具指向它，作業系統就在運行。零依賴。完全可攜性。而且因為它是 Git，每個變更都有版本控制、每個決策都可追溯，沒有什麼是真正丟失的。
Muratcan Koylan 是 Sully.ai 的 Context Engineer，他在那裡為醫療保健 AI 設計 context engineering 系統。他關於 context engineering 的開源工作（8,000+ GitHub stars）在學術研究中與 Anthropic 一起被引用。此前在 99Ravens AI 擔任 AI Agent Systems Manager，建立處理每週 10,000+ 互動的多代理系統。
Framework: Agent Skills for Context Engineering