AI 代理記不住你的專案？OpenContext 想把記憶還給開發者

一個透過 MCP 為 AI 編碼代理加上「專案本地持久記憶」的開源工具，暴露了整個 Agentic AI 工具鏈最薄弱的一層:上下文。記憶放在哪裡，權力就放在哪裡。

深夜的台北，一位在科學園區工作的後端工程師對 AI 編碼代理下了一道指令。代理乾淨俐落地改完程式碼——卻忘了三小時前它自己寫過什麼。這不是笑話，是當前 Agentic AI 工作流程的日常斷點。

2026 年 8 月底，一個名為 OpenContext 的專案登上 Hacker News（來源:https://www.opencntx.dev/），主張透過 MCP（Model Context Protocol）為 AI 編碼代理提供「持久、專案本地」的記憶。同一天前後，另一個名為 Grith 的工具也在 Hacker News 上曝光，主打在 Linux 上以 syscall 層級監督 AI 代理的行為（來源:https://github.com/grith-ai/grith）。兩個專案一柔一硬:一個管記憶，一個管紀律。它們的共同前提是同一個判斷——AI 代理的問題不在聰明不聰明，在於它沒有可靠的工作現場。

記憶為什麼是主戰場

AI 代理每次對話都像失憶的實習生重新報到。模型上下文視窗有限，跨對話、跨 session 的專案知識——架構決策、命名慣例、之前踩過的坑——全都在重置中蒸發。OpenContext 的解法是把記憶「專案本地化」:不放在雲端、不放在模型供應商手裡，而是存在程式碼庫旁邊，透過 MCP 這個開放協定讓任何代理都能讀寫。

這個設計選擇本身就是一個商業宣言。記憶放在哪裡，鎖定效應就在哪裡。若記憶由模型廠商託管，開發者等於把機構知識抵押給單一供應商；放在專案本地，切換模型的成本大幅下降。對台灣大量以接案與代工為結構的軟體生態而言，這個差別很實際:客戶的程式碼與累積的開發脈絡留在自己機器上，而不是某家美國公司的雲端。

職缺數字背後的結構訊號

勞動市場給了這波工具潮一個量級參考。Indeed 上「AI coding agents」相關職缺超過 12,000 筆（來源:https://www.indeed.com/q-ai-coding-agents-jobs.html,摘要顯示 12,043 筆），而更廣義的「AI coding」職缺也持續開出（來源:https://www.indeed.com/q-Ai-Coding-jobs.html）。當企業開始大規模聘人「管理 AI 代理」而非單純寫程式，周邊工具——記憶層、監督層、稽核層——就會從 side project 長成產品線。OpenContext 與 Grith 正是這條新供應鏈的兩個早期節點。

競爭版圖:三條路線

目前的代理記憶與治理賽局，大致三條路:一是模型廠商內建方案（把記憶綁進自家平台，換取便利、付出鎖定）；二是開源本地派（OpenContext 這類，以 MCP 為共同介面，強調主權與可攜）；三是安全監督派（Grith 這類 syscall 層級防護，處理的是「代理亂改檔案、亂連網路」的信任問題）。三條路不互斥——真實的企業環境可能三者都要。

情境與風險

基準情境:MCP 成為業界共通介面，記憶層如同今天的資料庫，成為標準基礎設施，開源方案與商業託管並存。樂觀情境:記憶本地化讓中小團隊也能建立長期累積的 AI 資產，縮小與巨頭的差距。悲觀情境:模型廠商以更深的整合壓過開放協定，開源記憶層淪為小眾，鎖定效應反而加深。

這套分析最大的假設風險在於:上下文視窗與模型原生記憶能力仍以高速演進。若模型本身很快就能跨 session 記住一切，獨立記憶層的存在價值可能被壓縮。屆時 OpenContext 們搶到的，或許只是一段過渡期。但過渡期有多長，沒人敢掛保證——這也正是值得持續盯著 Hacker News 的原因。