RAPTOR 和 GraphRAG 代表了學術界對知識組織的探索，而字節跳動火山引擎開源的OpenViking提出第3種哲學：文件系統典範。它不將上下文視為扁平的向量碎片或圖譜節點，而是將所有上下文 -- 記憶、資源、技能 -- 映射為虛擬文件系統中的目錄和文件，每個條目擁有唯一URL：

這裡的vikeing://是一種虛擬URL--形式上類似http://orfile://，但它並不指向某個具體的物理位置。Agent通過該地址訪問知識，框架在背後決定內存、磁盤還是遠程加載。
後面提到的L0/L1/L2，3層也由框架根據訪問頻率和檢索深度自動分配，Agent只需統一路徑與URL引用即可。

核心設計是L0/L1/L2三層上下文按需加載。
資源寫入時，系統自動將原始內容提煉為3個抽象層次：L0(摘要) 約100 tokens的一句話概述，用於快速判斷目錄相關性; L1(概覽) 約2000 tokens的核心訊息與使用場景，供Agent規畫決策; L2(全文) 為完整原始內容，僅在需要深入時按需加載。每個目錄下自動生成.abstract(L0)&.overview(L1)文件，形成根到葉的層次化摘要結構。若在L0層即判定無關，則無須加載L1&L2 --大部分查詢加載到L1即可完成決策， token消耗因此大幅降低。這套"摘要常駐、按需取全文"的思路，與Skills的"漸進式披露"如出一轍-- 都是先讓Agent只看到輕量的原訊息，確有需要時再逐層拉取完整內容，把token花在刀口上。

選擇markdown純文本而非專用數據庫作為知識的底層表達，是一個看似反常直覺但深思熟慮的工程決策。純文本意味著用戶可直接閱讀、邊輯和修正Agent的知識; 可通過Git版本控制和回滾; 更重要的是Agent擁有write_file能力後可在工作分支上自主紀錄和組織知識，再通過審核流程合入主庫。對話結束時，系統可以提議把用戶偏好更新寫入user/memories/，把操作紀錄寫入agent/memories/。前者屬於用戶知識管理; 後者只有經過結果評估、跨軌跡歸納和後續驗證，才有機會成為"經驗學習"(不會講到的內容)，而不是把任意依次操作直接當成可靠經驗。

!目前有在使用agent做專案開發都會知道，(或是你有看我文章)，我們在做專案時context會逐漸累加，到達一個等級，系統會提醒你，但提醒時通常快爆炸了，context太多除了會影響model速度外，也會影響model的判斷，(請回顧權重的地方)，所以我們可以當context到一定的地步時，摘要並更新記憶，接著丟到下一個session，繼續工作。

回到文章，不過，採用這種純文本、文件系統式的組織方式，有一個極容易被忽略卻直接影響減索成敗的前提：文件之間必須建立起連接與索引。前面介紹的.abstract/.overview解決的是縱向的層次摘要，而這裡強調的是橫向的關聯 -- 如果只是把知識拆成一堆各自獨立的文本文件平舖在目錄裡、彼此之間沒有任何交叉引用，那麼除了全文掃描或是向量檢索外，Agent幾乎無從在相關條目間導航; 知識越多，這堆零散文件反而更難檢索。

正確的做法是把知識庫組織的向wikipedia：每個條目在提及其他條目時都以連結指向它，再輔以入口頁與索引頁，讓Agent能順著連接從一個概念走到相關概念 -- 相當於是用輕量的文件連接，實現GrapgRAG實體關係圖譜的部分導航能力。

這裡還有個實踐中的關鍵差異：不同模型主動建立這類連結的意願與能力並不相同。能力強的模型在寫入新知識時會自發的回指已有條目、順手維護索引; 而不少模型並不會主動這樣做，指是孤立地追加文件。因此在負責寫入知識的提示詞裡必須把要求寫明確-- 每新增一個條目，都要先檢索並連接到相關的已有條目，並更新所在目錄的索引頁，形成雙向可達的引用網路，而不是任由知識退化成互不連接的孤島。

Cursor 震撼發表 Projects 架構！徹底告別「一任務一對話」的片段模式，改由永遠在線的單一持久協調代理（Coordinator Agent）調度數千名雲端子代理。結合預設雲端、跨端共享記憶庫與主動訂閱 PR / Slack 機制，官方實測 PR 合併量暴增 6 倍。
https://www.aiposthub.com/cursor-projects-coordinator-agent-third-era-software-development/