文｜李嘉星

編輯｜周鑫雨

一句話介紹

context-mode 是一款專為 AI 編程打造的上下文優(yōu)化 MCP（Anthropic 發(fā)布的模型上下文協(xié)議）插件。

它解決了開發(fā)者在長周期開發(fā)中遭遇的“模型失憶”與“Token 過多消耗”的核心痛點。

據(jù)團隊表示，在編程場景下，context-mode 能夠讓 AI 編程的成本降低 98%，同時將大模型的記憶力從30分鐘提升至 3 小時。

團隊背景

context-mode 的背后是一支背景多元的跨國初創(chuàng)團隊。目前團隊的核心成員分布在土耳其、法國等 4 個國家，主要通過 GitHub 異步協(xié)作。

Mert K?seo?lu（核心開發(fā)者、創(chuàng)始人）：曾作為技術(shù)顧問為 OpenAI 等企業(yè)提供技術(shù)服務(wù)，擁有超 10 年全棧工程與系統(tǒng)架構(gòu)經(jīng)驗。創(chuàng)業(yè)前，他曾先后任職于 Countly、Planhat 及 Jotform 等全球知名數(shù)據(jù)與 SaaS 平臺，擔(dān)任高級軟件工程師。

孫逸誠（核心開發(fā)者、多平臺適配負責(zé)人）：團隊里的中國面孔，目前大二在讀。他曾入圍強基計劃（數(shù)學(xué)與物理全省前 18 名），具有 Temporal-RAG（時序數(shù)據(jù)檢索增強）引擎的獨立開發(fā)經(jīng)驗，并獲得知乎全球 A2A（Agent-to-Agent）黑客松銀獎。

產(chǎn)品及業(yè)務(wù)

圖源: context-mode

簡單來說，context-mode 是一款專門為 AI 編程助手“減負”和“整理記憶”的開源 MCP 插件。

該項目發(fā)布后曾登頂 GitHub Hacker News，目前已在 GitHub 獲得超 1.5 萬顆 Star。context-mode 現(xiàn)已吸引逾 24.3 萬名開發(fā)者接入，完成了對 15 個主流平臺的底層適配，并被微軟、谷歌、Meta、字節(jié)跳動及 Cursor 等科技公司的研發(fā)團隊采用。

context-mode 之所以能在極客圈獲得大量的關(guān)注，正是因為其精準切中了一個令人頭疼的行業(yè)焦慮：被昂貴API賬單和大模型失憶逼瘋的開發(fā)者

隨著“龍蝦（OpenClaw，一個開源 Agent 框架）”等全自動AI編程智能體的普及，Vibe Coding 的應(yīng)用門檻進一步降低。

然而，享受到 AI 帶來的效率提升的同時，用戶很快意識到，智力是昂貴的：一方面，Claude、GPT等頂尖模型的 Token 定價并不便宜，包含充足 Token 額度的高級套餐，定價動輒高達 200 美元/月。

另一方面，受制于當(dāng)下的能力，在執(zhí)行具體任務(wù)過程中，模型的反復(fù)試錯、重復(fù)檢索都會造成額外的 Token 浪費。

在實際開發(fā)場景中，大模型往往表現(xiàn)得像一個“沒有常識的數(shù)據(jù)處理機器”。團隊成員孫逸誠分享了一個踩坑經(jīng)歷：

參加 Kaggle 數(shù)據(jù)競賽時，他將一個包含 300 組數(shù)據(jù)的訓(xùn)練任務(wù)交給了 Claude。為了確認任務(wù)進度，Claude 沒有選擇寫一段定時腳本，而是選擇每隔 5 秒鐘向整個項目發(fā)起一次全局檢索。這種極其低效的“死盯”策略，讓一個高配會員賬號的 API 額度在短短半小時內(nèi)消耗了 90%。

與此同時，大模型還存在“失憶”的問題。開發(fā)者發(fā)現(xiàn)，當(dāng)代碼量觸及某些主流 IDE（集成開發(fā)環(huán)境）的隱形上限（如 164K）時，系統(tǒng)會不得不丟棄或壓縮歷史信息，導(dǎo)致模型遺忘關(guān)鍵細節(jié)。這就導(dǎo)致：前一秒還在流暢寫代碼的 AI，下一秒就會把前置的關(guān)鍵架構(gòu)和約束條件忘得一干二凈。

面對大模型嚴重的“幻覺”與“失憶”，context-mode 給出了解法：既然大模型處理海量原始數(shù)據(jù)又貴又笨，那就剝奪它直接閱讀原始數(shù)據(jù)的權(quán)利。

孫逸誠打了一個比方：“傳統(tǒng)的 AI 編程就像看一場馬拉松，大模型會死死盯著每一個選手的每一步，這當(dāng)然會耗盡它的上下文。而 context-mode 做的，是把跑馬拉松的過程扔進一個屏蔽的沙盒（Sandbox）里，大模型只需要看最后的排名結(jié)果?！?/strong>

具體到工作原理，首先，通過引入“虛擬沙盒”與精準檢索，context-mode 能夠有效降低 Token 的消耗。

在傳統(tǒng)的調(diào)用模式中，每一次 MCP 工具的調(diào)用都極其昂貴，龐大的原始數(shù)據(jù)會被直接傾倒進大模型的上下文窗口，導(dǎo)致 Token 消耗量上升。

context-mode 的“虛擬化沙盒”機制，就好比在大模型和操作系統(tǒng)間建立了一道“防火墻”。它會先把所有文件和運行記錄存放在本地，需要用到時再幫大模型把相關(guān)內(nèi)容找出來。

《智能涌現(xiàn)》的測試結(jié)果。

根據(jù)《智能涌現(xiàn)》的測試，接入 context-mode 后，大模型讀取一份 79.3 KB 的文件時，Token 的消耗成本降低了 87.7%。

其次，為了解決大模型的“失憶”痛點，context-mode 通過構(gòu)建“存檔點”，實時監(jiān)控開發(fā)者的每一次文件編輯。

當(dāng)對話太長，它會主動構(gòu)建并向 AI 注入一個通常小于 2KB 的“快照”，相當(dāng)于在代碼編輯過程中建立了一個“存檔點”。官方表示，這種機制能將大模型連續(xù)編程的有效時間從 30 分鐘提升至 3 小時。

最后，context-mode 引入了強制性“用代碼思考（Think in Code）”的范式，從而節(jié)省 Token 消耗。

所謂的 Think in Code，簡單而言，就是不讓模型逐行閱讀、處理文件，而是先讓模型編寫一個“小程序”，讓“小程序”先在本地完成數(shù)據(jù)分析，再將提煉后的結(jié)果反饋給模型。

context-mode 創(chuàng)始人 Mert 告訴《智能涌現(xiàn)》，開發(fā)者陷入了一個誤區(qū)：習(xí)慣將海量數(shù)據(jù)直接丟給大模型進行處理。實際上，面對 50 個文件的數(shù)據(jù)統(tǒng)計任務(wù)，與其讓模型親自逐個閱讀，不如先讓模型寫一段腳本，由腳本完成統(tǒng)計工作，再把結(jié)果返回給模型。

用 Mert 的話說，一個腳本可以替代十幾個昂貴的工具調(diào)用，并節(jié)省百倍的上下文。

根據(jù)《智能涌現(xiàn)》的測試，接入 context-mode 后，模型處理一份文件時，節(jié)省了 99.98% 的 Token 成本。

context-mode 的上手門檻，比 Cursor 等需要重新下載并適應(yīng)環(huán)境的獨立開發(fā)軟件（IDE）更低。作為一個輕量級的 MCP（模型上下文協(xié)議）插件中間件，context-mode 可以直接接入開發(fā)者原有的工作流中。

context-mode 團隊還提供了一系列快捷指令，用來查看各大平臺的 Token 節(jié)省情況。用戶只需要在聊天框中輸入指令，瀏覽器就會彈出一個本地的數(shù)據(jù)統(tǒng)計面板，記錄著當(dāng)周調(diào)用了多少次 API，以及 context-mode 攔截了多少次無效的數(shù)據(jù)讀取。

△快捷指令列表。 圖源: context-mode

近期，context-mode 針對企業(yè)研發(fā)場景，推出了“上下文即服務(wù)”。

在企業(yè)研發(fā)場景中，AI 的 ROI 往往難以衡量。

為此，context-mode 推出了企業(yè)服務(wù)“Insights”。獲得授權(quán)后，安裝在程序員電腦上的插件，可以直接將程序員使用 AI 的過程數(shù)據(jù)（比如調(diào)用了什么工具、報錯了幾次、消耗了多少錢），發(fā)送到Insights 所在服務(wù)器上。

與此同時，Insights 還能針對不同崗位，提供不同的數(shù)據(jù)報告。比如面向安全總監(jiān)，系統(tǒng)會自動生成安全報告；面向財務(wù)團隊，系統(tǒng)可以提供 Tokens 消耗明細。

目前，Insights 仍處于定向內(nèi)測階段。

Founder思考

• 停止將大模型視為“數(shù)據(jù)處理器”，它本質(zhì)上是“代碼生成器”。

現(xiàn)在很多平臺和開發(fā)者陷入了一個誤區(qū)，喜歡把 50 個文件直接讀入上下文，讓大模型去里面“數(shù)”有多少個函數(shù)。

這不僅緩慢，而且極其浪費算力。我們的主張是“用代碼思考（Think in Code）”——LLM 應(yīng)該去編寫一個統(tǒng)計腳本來完成計數(shù)，最后只輸出結(jié)果。

一個腳本可以替代十幾個昂貴的工具調(diào)用，并節(jié)省百倍的上下文。在未來的 AI 編程范式中，這是所有平臺都必須遵循的底層鐵律。

• 無限上下文是一個偽命題，克制才是 AI 工具最難建立的壁壘。

行業(yè)里都在卷大模型的長文本能力（比如 100K 甚至 1M 的上下文），但這其實是個陷阱。把幾十 KB 的報錯日志一股腦傾倒給 AI，只會加速它的“失憶”和幻覺。

真正的解法不是盲目擴容，而是建立起一套極度克制的“狀態(tài)記憶層（沙盒）”。誰能把傳給 AI 的無效噪音壓縮到極致，誰才能真正幫開發(fā)者把連續(xù)編程的時間從 30 分鐘延長到 3 個小時。

• 下一代 AI 編程的瓶頸不在于模型夠不夠聰明，而在于上下文管理框架夠不夠清晰。

現(xiàn)在大家都在抱怨 AI 會在同一個 Bug 上反復(fù)跌倒。這并不是因為模型變笨了，而是它在冗長的對話中迷失了。

只有給 AI 提供像單機游戲一樣的存檔點，強制它按優(yōu)先級讀取記憶，才能為它真正有價值的邏輯推理留出足夠的空間。

• 大廠在卷“全家桶”，而我們在做跨平臺的“萬能插座”。

我們花大量精力去適配 Cursor、Claude、Gemini 等不同的底層邏輯，是因為真實的開發(fā)者生態(tài)永遠是碎片化且快速迭代的。

開發(fā)者不需要另一個被大廠深度綁定的全能 Agent，他們需要的是一個輕量、不吃內(nèi)存、即插即用且能極大降低 API 賬單的中間件。