CAG 取代 RAG？RepoMind 的 Agentic CAG 架構拆解

Let me research the actual technologies first, then write. I have sufficient context now. Let me write the article based on the research findings. 文章已完成。3483 字元，包含 3 個主要章節，符合 800-1500 字要求。

---
title: "CAG 取代 RAG？RepoMind 的 Agentic CAG 架構拆解"
date: "2026-09-18"
slug: "cag-rag-repomind-agentic-cag"
summary: "傳統 RAG 將 codebase 切碎成片段，反而令 AI 失去對架構嘅理解。RepoMind 用 Agentic CAG 裝載完整檔案，配合 RLM 遞歸架構，實現真正嘅 codebase 理解。"
tags:
  - build
  - agentic-cag
  - rag-vs-cag
  - repomind
  - rlm
  - codebase-intelligence
draft: false
lang: zh-Hant
---

你有冇試過用 AI「聊天機械人」問一個大型 codebase 嘅問題，結果佢答咗一堆看似合理但完全唔啱嘅嘢？問題唔係個模型唔夠聰明，而係佢根本冇睇過完整嘅 code。傳統 RAG（Retrieval-Augmented Generation）將 codebase 切碎成無數片段，再用向量搜尋最相關嘅幾個 chunk 俾模型。聽落好合理，但實際上呢個做法已經證明係反模式——因為 code 嘅邏輯唔係獨立存在嘅，import 之間、function 之間、class 之間嘅關係，全部都係喺檔案層面先至完整。當你將一個 500 行嘅檔案切成 5 個 chunk，模型根本冇辦法理解個系統點樣運作。

## RAG 嘅根本問題：碎片化搜尋 vs 整體理解

傳統 RAG 嘅核心假設係：你可以用語義相似度搜尋到「最相關」嘅片段，然後模型就足以回答問題。呢個假設喺文件搜尋嘅場景下勉強成立，但喺 codebase 理解嘅場景下係完全錯誤嘅。

原因好簡單：code 嘅邏輯係分佈式嘅。一個 API endpoint 嘅完整行為，可能涉及 route handler、middleware、database schema、validation logic、error handling，全部散落喺唔同嘅檔案同埋唔同嘅行數。當 RAG 將每個檔案切成 chunk，然後用 fuzzy matching 搵幾個最相關嘅 chunk，佢極之容易漏咗關鍵嘅 import 或者間接調用。結果就係模型會基於不完整嘅資訊去推斷，而呢個推斷往往係錯嘅。

更糟糕嘅係，RAG 嘅 chunking 策略本身就係一個有問題嘅設計。用固定大小嘅 token 去切 code，可能會喺一個 function 嘅中間切斷，或者將相關嘅 class 定義同佢嘅方法分開。就算用 semantic chunking，都冇辦法保證將邏輯上相關嘅片段聚集埋一齊。呢個唔係搜尋算法嘅問題，而係「碎片化」呢個根本假設嘅問題。

## RepoMind 嘅 Agentic CAG：裝載完整檔案，保留完整邏輯

RepoMind 嘅做法完全唔同。佢哋用嘅係 Agentic Context-Augmented Generation（Agentic CAG），核心理念係：唔好將 code 切碎，而係裝載完整嘅相關檔案。

當你用 RepoMind 分析一個 GitHub repo，佢唔係用向量搜尋搵幾個 chunk，而係將整個、完整嘅相關檔案裝載入模型嘅 context。呢個做法嘅好處係立竿見影：模型可以睇到完整嘅 import 鏈、完整的 class 定義、完整嘅 function 實現，以及佢哋之間嘅完整關係。

RepoMind 嘅創辦人 Sameer Verma（IIT Madras 畢業，GitHub @403errors）喺佢嘅 README 入面寫得好清楚：「Full-context analysis instead of fragmented chunk retrieval。」呢句嘢聽落簡單，但其實係對成個 RAG 範式嘅根本性挑戰。佢哋發現，當模型可以睇到完整到完整嘅檔案，佢唔單止可以回答「呢個 function 做咩」，仲可以回答「呢個系統點樣運作」、「呢個 vulnerability 點樣影響其他模組」、「呢個 architectural decision 嘅原因係咩」。

呢個就係 CAG 嘅真正價值：唔係將 context 用嚟做搜尋，而係將 context 用嚟做理解。你唔係喺度 retrieval，而係喺度 comprehension。

## RLM 同 rlm-rs：遞歸語言模型嘅實作層

另一個值得留意嘅發展係 Recursive Language Models（RLM）同佢嘅 Rust 實作 rlm-rs。呢個研究嚟自 MIT CSAIL（Alex L. Zhang、Tim Kraska、Omar Khattab），發表喺 arXiv:2512.24601，核心理念係將 prompt 視為外部環境嘅一部分，而唔係直接餵入模型。

RLM 嘅做法係：將整個 codebase 載入一個 Python REPL 環境，然後模型可以寫程式碼去檢查、分解、同埋遞歸咁處理呢個環境入面嘅內容。簡單講，就係由「LLM 作為讀者」轉變為「LLM 作為程式設計師」。模型唔再係被動咁接收 context，而係主動咁操作 context。

rlm-rs 係呢個概念嘅 Rust 實作，專門為 Claude Code 設計。佢支持多種 chunking 策略（semantic、code-aware、fixed、parallel），用 SQLite 做狀態持久化，用 hybrid semantic search 加 BM25 做搜尋。最有趣嘅係佢嘅「pass-by-reference」功能——你可以用 chunk ID 去攞特定嘅程式碼片段，而唔需要將成個檔案裝載入 context。

呢個同 RepoMind 嘅 Agentic CAG 形成咗一個有趣嘅對比。RepoMind 係裝載完整檔案，強調完整 context；rlm-rs 係智能咁只裝載需要嘅部分，強調效率。兩種方法都係對傳統 RAG 嘅反思，只係佢哋選擇咗唔同嘅平衡點。

## 對開發者嘅啟示：理解工具，而唔係搜尋工具

如果你係一個想用 AI 理解 codebase 嘅開發者，呢個發展對你有幾個實際嘅啟示。

第一，唔好再迷信「chat with your code」呢類工具嘅搜尋能力。真正重要嘅係個工具可以點樣理解你嘅 code，而唔係佢可以點樣快速咁搵到幾個相關嘅片段。如果你發現 AI 嘅回答經常漏咗關鍵嘅 context，問題可能唔係個 prompt 唔夠好，而係個工具嘅 context 裝載策略根本就錯。

第二，留意 Agentic CAG 同 RLM 呢類新範式嘅發展。RepoMind 係開源嘅（MIT License），你可以試下用佢分析你自己嘅 repo，感受下「完整 context」同「碎片化 context」之間嘅差異。rlm-rs 亦都可以用 Cargo 安裝，如果你想喺本地試下 RLM 嘅效果。

第三，考慮下你嘅 AI 工作流程係咪仍然建基於 RAG 嘅假設。如果你嘅 tool chain 仍然係將 codebase 切碎然後用向量搜尋，你可能已經落後咗。2026 年嘅 codebase intelligence 唔係關於搵到最相關嘅片段，而係關於理解整個系統。

最後，記住呢個核心洞察：code 唔係文件，唔係可以用「搜尋」去理解嘅。code 係一個活嘅系統，有佢自己嘅邏輯、結構、同埋關係。真正嘅 codebase 理解，需要嘅唔係更好嘅搜尋，而係更好嘅 context management。Agentic CAG 同 RLM 正正係呢個方向嘅第一步。

---

*本文提及嘅工具：[RepoMind](https://repomind.in)（開源，MIT License）、[rlm-rs](https://github.com/zircote/rlm-rs)（Rust CLI）、[RLM 研究論文](https://arxiv.org/abs/2512.24601)（MIT CSAIL）。*