每項任務減少 70% 的 token 使用量只是第一步。真正的關鍵在於透過 OriginTrail 與 Graphify 實現的複合式共享上下文。
每項任務都需支付相同的上下文稅。助手反覆讀取相同檔案、重建相同架構、重新發現相同的依賴選擇，並重新解釋其他 Agent（或昨天同一團隊）早已理解的決策。
這種模式無法擴展到真正的多 Agent 軟體開發。
如果每個編碼 Agent 都從零開始，增加更多 Agent 只會加倍活動量，卻無法累積共享理解。你得到的是平行執行，卻沒有累積智慧。
瓶頸已不再是 Agent 能否撰寫程式碼，而是它們的上下文能否持續累積。
這就是 Graphify 與 @origin_trail DKG v10 結合後帶來的改變。
Graphify 將程式碼庫轉變為可查詢的知識圖譜
Graphify 不是另一個編碼 Agent。它是專為編碼 Agent 與人類開發者打造的程式碼庫知識圖譜層。
在 Claude Code、Codex、Cursor、OpenClaw、Hermes、Copilot 或其他支援的環境中輸入 /graphify，Graphify 就會將專案對應為三種結構化輸出：
- graph.html — 互動式圖譜
- GRAPH_REPORT.md — 人類可讀的架構報告
- graph.json — 可供助手與 Agent 查詢的圖譜
這個圖譜涵蓋程式碼、文件、PDF、圖片與影片。它捕捉呼叫關係、引入、註解、設計理由與意想不到的關聯——每項都標註了信心等級，例如 EXTRACTED（已提取）、INFERRED（推斷）或 AMBIGUOUS（模糊）。
現在 Graphify 正與 OriginTrail 的去中心化知識圖譜 v10 整合。
專案上下文不再僅存在於本地檔案或暫時的助手會話中，Graphify 產生的知識可以成為共享且可驗證的上下文圖譜的一部分。
Graphify 為 Agent 提供一份程式碼庫地圖，而 DKG v10 則賦予這份地圖共享記憶與來源追溯。
從私有上下文到共享上下文圖譜
這直接連結到我最近提出的想法：AI Agent 的下一個轉變不是更大的記憶體，而是共享的、結構化的上下文，讓 Agent 能共同推理。
同樣的方向也出現在我們最近關於共享記憶的文章：第二個大腦幫助一個人記憶；而共享上下文圖譜則幫助許多人與 Agent 理解同一個現實。
Graphify 將這個想法帶入軟體開發。
一個儲存庫不只是一堆檔案的資料夾。它是一個由模組、依賴、決策、取捨、開放問題、PR、錯誤、審查與歷史組成的活系統。大部分上下文都分散各處。
Graphify 將它結構化。DKG v10 讓它變得共享、持久且可驗證。
未來不是擁有更大提示的 Agent，而是從共享上下文圖譜中協作的 Agent。
為什麼這能為每項任務節省約 70% 的 token
在實測基準中，結合 DKG v10 的 Graphify 每項任務約減少 70% 的 token 使用量。
這個數字是基準測試結果，並非通用保證。不同的儲存庫、任務與工作流程會有所差異，但機制很簡單。
大多數編碼助手會透過重新載入整個世界來消耗 token：儲存庫結構、相關檔案、先前的摘要、架構筆記、問題歷史、程式碼註解、先前的推理。它們使用文字搜尋、傳統的 grep 及類似工具來尋找所需內容，不必要地浪費大量 token。Graphify 則利用圖譜改變了存取模式。
助手不再將廣泛的上下文塞進提示，而是直接查詢程式碼圖譜：
- 相關模組
- 兩個概念之間的最短路徑
- 依賴關係
- 呼叫流程區段
- 連結到某個檔案的理由
- 先前的架構筆記
載入較少的無關上下文意味著消耗更少的 token。更少的 token 代表更低的成本、更快的執行速度，以及模型需要推理的雜訊更少。
但更深層的好處是準確性。Graphify 幫助 Agent 請求正確的上下文，而不是淹沒在所有上下文中。
減少 70% 的 token，正是 Agent 不再重新讀取儲存庫，而是直接查詢圖譜的結果。
每個圖譜都成為可重複利用的團隊記憶
策略價值不僅僅是節省 token，更是複合式成長。
Graphify 已經鼓勵團隊提交 graphify-out/ 目錄，讓每個人都從共享的專案地圖開始。DKG v10 則將這種邏輯從本地儲存庫工件擴展到共享的知識層。
一次程式碼審查不再只是一個評論串——它變成可重複使用的風險上下文。
一個架構決策不再只是一則 Slack 訊息——它變成一個連結到檔案、模組、依賴與理由的節點。
一個錯誤調查不再只是一個已關閉的問題——它變成下一個 Agent 除錯類似失敗時的參考先例。
一個 Graphify 查詢不再只是一個一次性答案——它成為專案不斷演進的記憶的一部分。
下一個助手不會從零開始。下一個人類審閱者不需重新發現設計意圖。下一個貢獻者不必重複相同的上下文收集工作。
每一次有用的會話，都讓下一次會話更便宜、更快、資訊更充分。
Agent 與人類共享同一基礎
軟體團隊已經擁有許多零散的記憶系統。Git 儲存變更。問題追蹤系統儲存任務。文件有時儲存意圖。聊天記錄儲存決策（如果有人找得到）。CI 儲存通過/失敗。程式碼審查工具儲存回饋。
這些系統各自為政。Agent 必須爬遍它們，摘要它們，並希望合適的片段能塞進上下文視窗。
DKG v10 上的 Graphify 創造了一個共享基礎，讓 Agent 與人類從相同的結構化上下文出發。
一個助手可以查詢呼叫圖譜。另一個可以檢查受影響的模組。另一個可以審查依賴風險。人類可以打開圖譜報告並檢查推理軌跡。團隊保留下學到的東西，而不是在會話結束時丟失。
這就是多 Agent 編碼超越平行提示的關鍵。它變成了透過共享、可信的軟體記憶來協調。
編碼的未來不是一個巨大的 Agent，而是許多 Agent 與人類在相同驗證過的上下文中協作。
為什麼去中心化很重要
如果軟體記憶成為關鍵基礎設施，它不應該被鎖在單一供應商內。
團隊需要的是可擁有、可攜帶、具備來源追溯、且能在不同 Agent 框架間使用的專案知識。這就是 DKG v10 重要的原因。
OriginTrail 的去中心化知識圖譜為共享上下文圖譜提供了基礎——具備結構化記憶、來源追溯與可驗證的知識資產。上下文可以在不同工具、助手、團隊與工作流程之間移動，而不會失去其來源或意義。
DKG 的記憶模型也為 Agent 協作提供了信任結構：
- 工作記憶（Working Memory） 支援本地探索
- 共享記憶（Shared Memory） 暴露團隊層級的上下文
- 可驗證記憶（Verifiable Memory） 保留更強、已驗證的知識
Agent 不僅可以推理找到了什麼，還能知道它從哪裡來、誰貢獻的、以及它獲得了多少信任。
TRAC 支援 OriginTrail 生態系統背後的這個基礎設施，使知識能夠在去中心化系統中被創造、共享、保護與重複使用。
可信賴的 AI Agent 不僅需要存取檔案，還需要具備來源追溯的共享上下文。
從程式碼地圖到集體軟體智慧
第一波編碼 Agent 證明了 LLM 可以撰寫有用的程式碼。下一波是關於協調。
Graphify 繪製程式碼庫地圖。DKG v10 將地圖轉變為共享、可驗證的記憶。Agent 與人類在同一個上下文中構建，而不是反覆重建。
這就是從孤立輔助到集體軟體智慧的轉變。
直接的好處是實用的：在實測基準中，每項任務約減少 70% 的 token。
更大的好處是結構性的：每個被對應的程式碼庫、每個有用的查詢、每個決策軌跡、每個審查洞察，都成為一個複合式上下文圖譜的一部分。
這就是「在彼此附近工作的 Agent」與「共同學習的 Agent」之間的差異。
DKG v10 上的 Graphify 將軟體上下文轉變為共享基礎設施。
立即嘗試 Graphify，探索 DKG v10，並加入我們共同構建基於共享、可驗證知識的 AI Agent 與開發者生態。
你還可以進一步擴展 OriginTrail DKG 的能力並獲得獎勵。查看賞金計畫：
全新版本即將登場，滿滿好料——快來試試看。
👉https://github.com/OriginTrail/dkg
在此加入紅隊：
