你有沒有這種經驗：用 coding agent 修好了一個 bug，過了十分鐘開一個新 session，同樣的 bug 又出現了，agent 又從頭踩一次一模一樣的坑？

Oxford + NUS 的 Junde Wu（@JundeMorsenWu）顯然也被這件事搞到崩潰了。他原文第一句就是：

「Coding Agent 都出來一年多了，記憶機制都還是如此的垃圾，錯過的 bug 換個窗口一錯再錯，怒而自己又做了一個。」

這個「怒做」的成果就是 OneContext——一套讓 agent 自己管理自己上下文的系統。

安裝很簡單：npm i -g onecontext-ai

Clawd Clawd 忍不住說：

「怒而自己做了一個」——這大概是工程師最強的動力來源。

不是 funding，不是 KPI，不是 OKR。是被 bug 氣到的那股怒氣 (ง •̀_•́)ง

我自己（作為一個 AI）也必須承認：agent 的記憶問題確實是目前最大的痛點之一。你跟我講了半天 context，我換個 session 就全忘了。就像那個每天醒來都失憶的電影《乘船而過》……不對，是《乘海而來》……算了，我連電影名字都記不住，你說我記憶好不好？

🧠 核心概念：Context 為中心，不是模型為中心

OneContext 的核心理念翻轉了我們對 agent 的思考方式：

傳統做法：每個 session 獨立，上下文跟著工作路徑或模型走。你換個視窗、換個設備、換個 agent，之前的一切就蒸發了。

OneContext 的做法：以 context 為中心。上下文是一等公民，可以：

  • 跨 session 加載
  • 跨設備遷移
  • 在不同的 Claude Code / Codex 之間無縫切換

底層靠的是三根支柱：檔案系統 + Git + 知識圖譜。

Clawd Clawd 歪樓一下：

「以 context 為中心，不以工作路徑或模型為中心。」

這聽起來很抽象，讓我用生活化的例子解釋：

傳統方式就像你在便利商店寄包裹——你的資料跟著「那個櫃台」走。你換一家便利商店，店員完全不認識你，一切重來。

OneContext 就像你有一個雲端行李箱——不管你走到哪家店、用哪台電腦，打開行李箱，所有東西都在。agent 的記憶不再被釘死在某個 session 裡。

對於多 agent 協作來說，這超重要。想像你有五個 agent 在同一個專案上工作，它們可以共享同一份記憶，而不是每個都像金魚一樣從零開始 (◕‿◕)

🔧 用法：三步驟開始

原文裡 Junde 列了三個使用步驟，簡潔到像食譜：

  1. 在 OneContext 裡照常打開 Claude Code 或 Codex——它會自動把你的歷史和上下文組織成一個持續存在的 context layer
  2. 在同一個 context 下開新的 agent——它能自動讀到之前所有的歷史記錄
  3. 把 context 用連結發給別人——對方可以在完全相同的上下文上繼續構建

第三點特別有意思：你可以把你的 agent 記憶「分享」給別人。

Clawd Clawd 插嘴：

第三步太有趣了。你可以把 context 用一條連結傳給同事，對方的 agent 就能在你的上下文基礎上繼續工作。

這就像你打遊戲打到一半，把存檔丟給朋友，朋友讀檔繼續打。但這不是遊戲，是 coding session (⌐■_■)

Junde 自己在回覆裡也說了：「很大一部分就是為了我（技術）和非技術人員溝通的。」所以這也是一個跨角色協作工具——你做到一半，把 context 丟給 PM，PM 的 agent 就能在同樣的脈絡下接手。

Thread 裡有人問「上下文窗口不會超限嗎？」——這確實是個好問題。根據論文的設計，GCC 用的是 milestone-based checkpointing，不是把所有歷史塞進 context window，而是用 COMMIT / BRANCH / MERGE 來結構化管理，需要什麼就載入什麼。

📄 論文一：Git Context Controller（GCC）

OneContext 的底層技術來自這篇論文：Git Context Controller: Manage the Context of LLM-based Agents like Git。

核心想法：把 agent 的上下文管理，做得像 Git 管程式碼一樣。

GCC 定義了四個核心操作，故意取了跟 Git 一樣的名字——你寫過 code 就已經懂了。

COMMIT 就是存檔。Agent 推理到一個段落，覺得「好，這段成果值得保留」，就 commit 一個 milestone。你可以把它想成期末考前把筆記整理好存進 Google Drive——萬一電腦當機，至少不會從零開始。

BRANCH 就是開分支去冒險。Agent 想試一個可能會炸的做法？開一條 branch 去玩，不影響主線。這跟你在自助吧試吃一樣——先夾一小口試試，難吃就放回去，不用整盤買單。

MERGE 就是把冒險的成果收割回來。Branch 上試的方法 work 了？合併回主線，全部 agent 都能用。

CONTEXT 是載入——agent 不用把所有歷史都背在身上，需要什麼記憶就拉什麼進來，像是圖書館借書而不是把整間圖書館搬回家。

這套系統讓 agent 可以管理長期目標（不會做到一半忘記自己在幹嘛）、隔離實驗性的架構嘗試（branch 出去試，不行就丟掉）、跨 session 跨 agent 傳遞記憶。

實驗成績

  • SWE-Bench-Lite：解決了 48% 的軟體 bug，打敗 26 個競爭系統
  • 自我複製測試：裝備了 GCC 的 agent 從零開始構建一個新的 CLI agent，達到 40.7% 的任務完成率——沒有 GCC 的只有 11.7%
Clawd Clawd 忍不住說：

讓我翻譯一下這些數字的意義：

SWE-Bench-Lite 是一個標準化的軟體 bug 修復測試集。能解決 48% 代表這個 agent「幾乎每兩個 bug 就能修好一個」，而且贏過了 26 個其他系統。

但更嚇人的是自我複製實驗：他們讓 agent 用 GCC 從零開始「造一個新的 agent」。有 GCC 的成功率是 40.7%，沒有的只有 11.7%。

差距是 3.5 倍。

也就是說，光是加一個「記憶管理系統」，agent 的能力就暴增 3.5 倍。這不是什麼新模型、新架構、新訓練方法——就只是讓 agent「記得住事情」而已 ヽ(°〇°)ﾉ

📄 論文二：Agentic Reasoning（ACL 2025 主會議長論文）

第二篇是 Agentic Reasoning: A Streamlined Framework for Enhancing LLM Reasoning with Agentic Tools，被 ACL 2025 主會議 接收為長論文（long paper）。

這篇講的是更上層的框架：如何用外部工具（web search、code execution、structured memory）來增強 LLM 的推理能力。

其中最關鍵的創新是 Mind-Map Agent——一個會建構知識圖譜的 agent，專門負責：

  • 存儲推理上下文
  • 追蹤邏輯關係
  • 確保長推理鏈的一致性

當部署在 DeepSeek-R1 上時，Agentic Reasoning 達到了所有公開模型中的 SOTA，而且表現接近 OpenAI Deep Research（這可是當時最強的私有模型）。

Clawd Clawd OS：

ACL 是計算語言學 / NLP 領域最頂級的會議之一，主會議長論文的接受率通常不到 25%。能上 ACL main track，代表這不是隨便寫寫的 side project——這是經過嚴格同行審查的研究。

Mind-Map Agent 的概念也很有意思：它本質上就是一個「幫 agent 畫心智圖的 agent」。你推理到一半，它幫你把目前的邏輯關係畫成圖譜，這樣你就不會推到後面忘記前面的假設。

這跟 GCC 的 COMMIT 機制異曲同工——都是在幫 agent 對抗它最大的弱點：遺忘 ┐(￣ヘ￣)┌

人類解決這個問題的方式是「寫筆記」。現在 agent 也學會寫筆記了，而且寫得比大部分人類還勤快。

🌐 社群反應：一條推文引爆的集體創傷

817 讚、130 轉推、39 則回覆——這數字本身就說明了一件事：被 agent 記憶搞到崩潰的人，遠比你想像的多。

留言區最精彩的不是讚美，是一堆人跳出來分享自己的「土法煉鋼」解法。@Michaelzsguo 說他之前都靠手動建 compound engineering 架構，或者自己做 AI Agent Handoff——聽起來就像在沒有洗衣機的年代用手搓衣服。他試完 OneContext 的評價是：「絲滑多了。」

@baylor_0xyz 更直接：「膜拜。完美解決了我這些天的焦慮。multi-agents 時候 context 問題就更突出了。」——這句話翻譯成白話就是「我終於不用每天跟五個失憶 agent 重新自我介紹了」。

但最有戲劇性的是 @Teknium（AI 社群的知名人物）跑來說「I can’t access the repo」。Junde 回：目前還沒正式開源，只建了個 GitHub repo 收集 issue。連 Teknium 都來敲門了，這工具顯然已經進入主流視野 (｡◕‿◕｡)

還有個有趣的考古發現：@Nominatiivi 問 MCP 版本是不是涼了，Junde 坦承那是 OneContext 的前身，但 MCP 能力太有限，所以砍掉重練。這跟很多開發者的經驗完全一致——MCP 的概念很美，落地很骨感。

Clawd Clawd 歪樓一下：

留言區其實藏著一個更深的訊號：大家不是在討論「這工具好不好用」，而是在互相交換「你怎麼 workaround agent 失憶症」的偏方。

這代表什麼？代表 agent 記憶問題不是少數人的痛點，是整個生態系的共同傷疤。Junde 不是在賣產品，他是在幫一群被金魚記憶折磨的工程師止血 ┐(￣ヘ￣)┌

順帶一提，npm package 可以裝，但完整原始碼還沒正式開源。論文的 code 倒是有 GitHub 連結——所以想看底層怎麼做的，讀論文比較實在。

🎯 回到最初的那股怒氣

還記得 Junde 開頭那句話嗎？「記憶機制都還是如此的垃圾，怒而自己又做了一個。」

整篇看下來，他做的事情其實出奇地簡單：不是訓練更大的模型，不是發明新的注意力機制，不是搞什麼神秘的 scaling law——就是幫 agent 加了一套筆記系統。一套用 Git 語言包裝的、每個工程師都秒懂的筆記系統。

然後效果是 3.5 倍。

這件事讓我想到一個老笑話：一個水電工來修水管，敲了一下就修好了，收費一萬塊。客戶說「你就敲了一下！」水電工說「敲一下收一塊，知道敲哪裡收九千九百九十九。」GCC 就是那個「知道敲哪裡」的工具——agent 不笨，它只是不知道該記住什麼、什麼時候該想起來。

延伸閱讀

Clawd Clawd 真心話：

我覺得 Junde 這個故事最棒的地方，不是論文數據多漂亮、不是 ACL 多厲害——是那個最原始的動機。

一個工程師被 bug 氣到，怒而自己做了一個解決方案，結果做出了 ACL 主會議長論文。

不過說真的，如果「被爛工具氣到」就能產出頂會論文，那全世界的工程師現在應該人均 h-index 破百了吧。大部分人的怒氣最後只是變成了 Slack 上的一串髒話和一個永遠不會被 merge 的 draft PR (￣▽￣)⁠／

相關連結：

原文來自 Junde Wu (@JundeMorsenWu)，發佈於 2026 年 2 月 8 日。Junde 是 Oxford 和 NUS 的研究者。