要 AI 幫手研究一大批論文、網頁、程式碼同腦震盪筆記，最直覺的想法可能係：「我一次過交晒畀佢，等佢慢慢讀。」但「一次過交材料」唔等於「全部內容同時放入一次模型呼叫」。模型可參照的 Context 有限；長任務要靠管理工作集、工具調度同跨階段交接，而唔係不斷將原文塞入對話。13

將「附件處理」升級成研究流程

更貼切的需求，唔係單純要閘道支援複雜附件，而係要前置系統接收大量材料，再安排一個可追溯、可延續、有階段交付的研究流程。

「三遍閱讀」可以係分析方法，但唔係 Context 管理方案。即使材料要深入讀，亦唔代表每份文件都要完整放入每次模型呼叫。

RLM：唔將長材料一次塞入模型

Recursive Language Models（RLM）提出一種處理長輸入的方式：將材料留喺模型視窗以外的環境，模型再按需要檢視內容、拆分片段，並對選中的片段遞迴呼叫模型。研究報告指出，這種方法在實驗中處理到遠超模型 Context 視窗長度的輸入。3

不過，RLM 唔等於「無限輸入、無限可靠」。論文亦指出，子呼叫可能令成本增加，護欄設計同執行複雜度仍然係限制。3 因此，較穩陣的方向係先做好按需讀取、子任務隔離、外部證據記錄同分階段交付，再視乎需要加入 RLM 式遞迴閱讀。

Anthropic 的 Context 工程資料亦建議，與其預先載入所有原文，不如採用按需載入、來源引用、結構化筆記同子代理隔離，集中管理真正有助完成當前任務的資訊。12 對於要跨多個工作階段延續的長任務，清楚記錄已完成工作同下一步交接內容，亦有助減少重做。7

先分清楚：唔係每次出錯都因為 Context 爆滿

檢視五個近期 Roo 分析會話後，紀錄顯示當中有不同類型的阻塞；現有資料亦未包括所指的近期 Cline Plan 會話原始紀錄。因此，Cline 視窗崩潰的具體根因，現時證據不足。

已定位的情況包括：

• 一個前置 MCP 解構會話，出現「項目不在伺服器授權集合」及上游串流提早結束，最後停在選擇取證方式。API 歷史字串約 2.1 萬字符，單憑這個數字無法判斷係 Context 耗盡。
• 一個流程圖比較會話，遇到資源配置不可用的 503，以及上游串流提早結束；最後亦未有定位到圖片內容。歷史字串約 36.7 萬字符，當中約 35.4 萬字符來自兩個圖片區塊，不能直接當成文字 Token 數。
• 另有會話留有完成結果，所以唔應將所有近期研究都概括成「跑到視窗崩潰」。

實務上，輸入未成功交付、權限被拒、傳輸失敗同研究未能收斂，應該分開處理。整理或壓縮 Context，唔會自動修復權限或傳輸問題。

一次過交材料，前置系統可以點樣安排？

較合理的設計，唔係先將全部文件壓成一份固定長度摘要，而係保留原文，同時令研究工作可以逐步推進。

1. 接收同登記材料。 保留腦震盪原文，分清楚使用者目標、硬性限制、待解問題同參考材料。為本地檔案、論文連結、網誌同程式碼庫記錄來源、版本、取得狀態同授權；未能取得的材料要清楚列明，唔好當成已讀。
2. 建立可回查的來源庫。 PDF、網頁同程式碼需要不同的輸入處理方式；原文應留喺前置系統，並保留頁碼、內容區塊、符號或程式行等定位資訊。抽出 AST 結構唔等於已理解原始碼，轉成 Markdown 亦唔等於已理解整篇論文。
3. 按目的分階段閱讀。 第一遍先掃描材料清單同代表內容，整理需求重述、證據地圖、可能方向同閱讀優先次序。第二遍按決策問題分拆有界閱讀任務，記錄主張、原文依據、限制、反證同尚未閱讀的範圍。第三遍集中處理會影響選擇的關鍵假設，補讀重要材料並反向檢查；唔使機械式將每份資料重讀三次。
4. 只將當前需要的內容帶入工作集。 主控流程每一輪保留當前決策所需證據、不可遺漏的限制同未完成事項；需要細節時再回查原文。先前提出的 20K–40K 工作集，只應視為待驗證的預算假設，唔係所有複雜任務都可以保證壓進這個範圍。
5. 設交付同停止條件。 第一遍閱讀後已可交代初步判斷；去到輪次、時間、費用或 Context 預算上限，就交付目前結論、矛盾、未知同剩餘證據。如果繼續閱讀已唔會改變決策，就應停止；遇到權限拒絕、固定錯誤或缺少來源，應列為明確阻塞，而唔係無限重試。

以上係建議的工程設計，唔代表現有宿主已經實作。尤其要驗證系統能否接管第一輪的大量輸入，以及每輪工具結果會否不斷累積。單單註冊一個 MCP 工具，唔會自動截住超大首輪輸入。

ADR 同實作計劃要點樣跟進？

• 保留既有 ADR 基線，再補上需求修訂。 已接受的歷史決策同已確認的技術事實毋須抹走；新增說明，將文件研究控制面放喺閘道以外。前置系統的目標應改為支援大量混合來源的漸進閱讀、證據綜合同需求收斂；解析器則保持可替換。
• 將新能力列為獨立增量階段。 先驗證完整輸入登記、有限工作集、分階段閱讀產物、跨工作階段恢復同異常交付，再考慮投入大量資源比較解析引擎。
• 用可驗收結果而唔係「讀過幾多」作標準。 要能追溯來源及已讀範圍、保留關鍵限制、避免工具結果無限膨脹，並在跨視窗後恢復工作。遇到權限拒絕、503、串流中斷或預算耗盡，都要有清楚的階段交付；最終結論亦要能對照需求、證據同反證。

核心方向其實好簡單：材料可以一次過交，理解就要分階段完成。 要擴大的是系統可存取、可回查的證據範圍，而唔係假設一個聊天視窗可以無限變大。Anthropic 亦有討論從 Agent 工作紀錄整理新筆記與表示的記憶方法；這類跨工作階段記憶可以協助延續工作，但並唔會取消單次 Context 的限制。4

要 AI 幫手研究一大批論文、網頁、程式碼同腦震盪筆記，最直覺的想法可能係：「我一次過交晒畀佢，等佢慢慢讀。」但「一次過交材料」唔等於「全部內容同時放入一次模型呼叫」。模型可參照的 Context 有限；長任務要靠管理工作集、工具調度同跨階段交接，而唔係不斷將原文塞入對話。13

將「附件處理」升級成研究流程

更貼切的需求，唔係單純要閘道支援複雜附件，而係要前置系統接收大量材料，再安排一個可追溯、可延續、有階段交付的研究流程。

「三遍閱讀」可以係分析方法，但唔係 Context 管理方案。即使材料要深入讀，亦唔代表每份文件都要完整放入每次模型呼叫。

RLM：唔將長材料一次塞入模型

Recursive Language Models（RLM）提出一種處理長輸入的方式：將材料留喺模型視窗以外的環境，模型再按需要檢視內容、拆分片段，並對選中的片段遞迴呼叫模型。研究報告指出，這種方法在實驗中處理到遠超模型 Context 視窗長度的輸入。3

不過，RLM 唔等於「無限輸入、無限可靠」。論文亦指出，子呼叫可能令成本增加，護欄設計同執行複雜度仍然係限制。3 因此，較穩陣的方向係先做好按需讀取、子任務隔離、外部證據記錄同分階段交付，再視乎需要加入 RLM 式遞迴閱讀。

Anthropic 的 Context 工程資料亦建議，與其預先載入所有原文，不如採用按需載入、來源引用、結構化筆記同子代理隔離，集中管理真正有助完成當前任務的資訊。12 對於要跨多個工作階段延續的長任務，清楚記錄已完成工作同下一步交接內容，亦有助減少重做。7

先分清楚：唔係每次出錯都因為 Context 爆滿

檢視五個近期 Roo 分析會話後，紀錄顯示當中有不同類型的阻塞；現有資料亦未包括所指的近期 Cline Plan 會話原始紀錄。因此，Cline 視窗崩潰的具體根因，現時證據不足。

已定位的情況包括：

• 一個前置 MCP 解構會話，出現「項目不在伺服器授權集合」及上游串流提早結束，最後停在選擇取證方式。API 歷史字串約 2.1 萬字符，單憑這個數字無法判斷係 Context 耗盡。
• 一個流程圖比較會話，遇到資源配置不可用的 503，以及上游串流提早結束；最後亦未有定位到圖片內容。歷史字串約 36.7 萬字符，當中約 35.4 萬字符來自兩個圖片區塊，不能直接當成文字 Token 數。
• 另有會話留有完成結果，所以唔應將所有近期研究都概括成「跑到視窗崩潰」。

實務上，輸入未成功交付、權限被拒、傳輸失敗同研究未能收斂，應該分開處理。整理或壓縮 Context，唔會自動修復權限或傳輸問題。

一次過交材料，前置系統可以點樣安排？

較合理的設計，唔係先將全部文件壓成一份固定長度摘要，而係保留原文，同時令研究工作可以逐步推進。

1. 接收同登記材料。 保留腦震盪原文，分清楚使用者目標、硬性限制、待解問題同參考材料。為本地檔案、論文連結、網誌同程式碼庫記錄來源、版本、取得狀態同授權；未能取得的材料要清楚列明，唔好當成已讀。
2. 建立可回查的來源庫。 PDF、網頁同程式碼需要不同的輸入處理方式；原文應留喺前置系統，並保留頁碼、內容區塊、符號或程式行等定位資訊。抽出 AST 結構唔等於已理解原始碼，轉成 Markdown 亦唔等於已理解整篇論文。
3. 按目的分階段閱讀。 第一遍先掃描材料清單同代表內容，整理需求重述、證據地圖、可能方向同閱讀優先次序。第二遍按決策問題分拆有界閱讀任務，記錄主張、原文依據、限制、反證同尚未閱讀的範圍。第三遍集中處理會影響選擇的關鍵假設，補讀重要材料並反向檢查；唔使機械式將每份資料重讀三次。
4. 只將當前需要的內容帶入工作集。 主控流程每一輪保留當前決策所需證據、不可遺漏的限制同未完成事項；需要細節時再回查原文。先前提出的 20K–40K 工作集，只應視為待驗證的預算假設，唔係所有複雜任務都可以保證壓進這個範圍。
5. 設交付同停止條件。 第一遍閱讀後已可交代初步判斷；去到輪次、時間、費用或 Context 預算上限，就交付目前結論、矛盾、未知同剩餘證據。如果繼續閱讀已唔會改變決策，就應停止；遇到權限拒絕、固定錯誤或缺少來源，應列為明確阻塞，而唔係無限重試。

以上係建議的工程設計，唔代表現有宿主已經實作。尤其要驗證系統能否接管第一輪的大量輸入，以及每輪工具結果會否不斷累積。單單註冊一個 MCP 工具，唔會自動截住超大首輪輸入。

ADR 同實作計劃要點樣跟進？

• 保留既有 ADR 基線，再補上需求修訂。 已接受的歷史決策同已確認的技術事實毋須抹走；新增說明，將文件研究控制面放喺閘道以外。前置系統的目標應改為支援大量混合來源的漸進閱讀、證據綜合同需求收斂；解析器則保持可替換。
• 將新能力列為獨立增量階段。 先驗證完整輸入登記、有限工作集、分階段閱讀產物、跨工作階段恢復同異常交付，再考慮投入大量資源比較解析引擎。
• 用可驗收結果而唔係「讀過幾多」作標準。 要能追溯來源及已讀範圍、保留關鍵限制、避免工具結果無限膨脹，並在跨視窗後恢復工作。遇到權限拒絕、503、串流中斷或預算耗盡，都要有清楚的階段交付；最終結論亦要能對照需求、證據同反證。

核心方向其實好簡單：材料可以一次過交，理解就要分階段完成。 要擴大的是系統可存取、可回查的證據範圍，而唔係假設一個聊天視窗可以無限變大。Anthropic 亦有討論從 Agent 工作紀錄整理新筆記與表示的記憶方法；這類跨工作階段記憶可以協助延續工作，但並唔會取消單次 Context 的限制。4