核心問題：一次交齊材料，不等於一次讀完材料

需求應從「網關支援複雜附件」，調整為「前置側接收大量材料，並組織可追溯、能持續交付的研究流程」。你可以一次把所有材料交給系統，但不應要求它們同時進入同一次模型呼叫。三遍閱讀可以是分析方法，卻不能取代有限上下文下的調度機制。13

哪種做法最接近這個目標？

研究方向：遞迴式語言模型

遞迴式語言模型（Recursive Language Models，RLM）會把大型輸入留在模型視窗之外，讓模型按需要檢查、拆分內容，再遞迴呼叫模型分析片段，而不是把整份材料直接塞進上下文。論文的 2026 年 5 月 11 日修訂版指出，這種方法可處理超過模型上下文視窗限制一個數量級以上的輸入。3

這與「把材料一次交齊，再深入研究」的需求相當接近，但不代表輸入量可以無限增加，也不保證結果必然可靠。論文同時指出，子呼叫可能帶來成本膨脹，護欄與執行流程也仍有複雜度。3

工程主線：按需載入，並留下可延續的工作紀錄

較務實的做法，是把按需載入、獨立子任務上下文、外部證據紀錄和分階段交付組合起來。Anthropic 的上下文工程資料建議，與其預先載入所有原文，不如採用輕量來源引用、動態載入、結構化筆記，以及讓子代理使用隔離上下文。12 長時間運作的代理系統也強調，要把任務拆成可處理的部分，並留下清楚的成果，讓下一個工作階段可以接手。7

Anthropic 於 2026 年 11 月 6 日發布的《The components of agent memory》，討論如何從工作紀錄形成新的筆記與表示。4 這是跨工作階段記憶的方向，並不會消除單次模型呼叫的上下文限制。

AWS 於 2026 年 5 月 21 日分享了以 AgentCore Code Interpreter 和 Strands 實作 RLM 的方案。6 這可作為編排機制的參考，但不能據此推論目前的 Cline 或現有 MCP 已具備相同能力。

建議先做出可控的前置研究編排，再把 RLM 式的遞迴閱讀作為後續能力；不宜一開始就引入任意程式碼執行或不設上限的子呼叫。

近期紀錄不代表所有問題都是上下文耗盡

本次檢視了五個近期 Roo 分析工作階段。找到的 Cline 儲存目錄只有設定，並未取得所指近期 Plan 工作階段的原始紀錄。因此，Cline 視窗崩潰的具體根因目前是：證據不足。

目前定位到兩類阻塞：

• **前置 MCP 解構工作階段：**紀錄中明確出現「專案不在伺服器授權集合」及上游串流提早中止，最後停在選擇取證方式。API 歷史字串約 2.1 萬字元，不能單憑這個數字判定上下文已耗盡。見工作階段紀錄。
• **流程圖比較工作階段：**紀錄中出現資源配置不可用的 503 錯誤及上游串流提早中止，最後也未能定位圖片內容。歷史字串約 36.7 萬字元，其中約 35.4 萬字元來自兩個圖片區塊；不能把編碼後的字元數當成文字 Token 數。見工作階段紀錄及內容類型紀錄。

另有工作階段留下了完成結果，因此不能概括為所有研究都無限延伸。輸入交付、權限拒絕、傳輸失敗與研究不收斂，應分別處理；上下文蒸餾無法修復前三類問題。

前置側如何承接「一次丟進全部材料」

建議設計成以下流程，而不是先把所有內容壓成一份固定長度的摘要：

1. **接收完整材料包。**保留腦力激盪原文，區分使用者目標、硬性限制、待釐清問題與參考材料。本機檔案、論文連結、網誌和程式碼儲存庫都應登記來源身分、版本、取得狀態與授權。無法取得的來源要明確列出，不要假裝已讀。
2. **建立可回讀的來源庫。**PDF 轉換、網頁正文擷取和程式碼結構分析是輸入處理方式；完整原文應留在前置側，並保留頁碼、區塊、符號或程式行等定位資訊。AST（抽象語法樹）骨架不等於讀懂原始碼，Markdown 轉換也不等於讀懂論文。
3. 安排三遍閱讀。
   • **第一遍：**掃描材料目錄和具代表性的內容，整理需求重述、證據地圖、候選方向與閱讀優先順序。
   • **第二遍：**依照決策問題分派有範圍限制的閱讀任務，要求回報主張、原文依據、限制、反證及尚未閱讀的範圍。跨資料關係仍須納入檢查，避免只靠相關性檢索而遺漏。
   • **第三遍：**針對會影響選擇的關鍵假設深入推演、補讀和反向檢查，推進 DR／DM 與使用者需求的收斂；不必機械式地把每份資料全部重讀三次。
4. **由主控維持動態工作集。**每一輪只帶入當前決策需要的證據、不可遺失的限制和未完成事項；需要細節時再回讀原文。前一版 RFC 提到的 20K–40K，應視為待驗證的工作集預算，而不是任何複雜任務都能一次壓縮到這個規模的保證。
5. **設定交付與停止門檻。**第一遍閱讀後就交付初步判斷。達到閱讀輪次、時間、費用或上下文預算時，應回報目前結論、衝突、未知事項與待補證據，而不是不斷搜尋直到崩潰。若重複閱讀已不再改變決策，就應停止；遇到權限拒絕、確定性錯誤或來源缺失，則應明確標示阻塞，不要無限重試。

以上是建議的工程契約，不是現有宿主已實現的能力。尤其需要驗證首次輸入如何接手，以及逐輪工具結果的預算如何管理；只註冊一個 MCP 工具，並不會自動攔截過大的首輪輸入。

ADR 與實作計畫應如何調整

• 目前 ADR：保留已接受的歷史基準與已定案的實體事實，另行記錄需求變更。明確界定網關不負責文件研究控制面；前置側的目標改為「針對大量混合來源進行漸進閱讀、證據整合與需求收斂」，而解析引擎只是可替換的介接器。
• 目前計畫：保留原有本機端已完成的範圍，另設獨立的增量驗證關卡，優先驗證完整輸入登記、有限工作集、三遍閱讀產物、跨工作階段恢復與異常狀況下的交付。不要先把大量時間花在競逐解析引擎，卻沒有可用的研究閉環。
• **驗收重點：**已讀範圍與來源可追溯；關鍵限制不遺失；工具結果不會無限膨脹；跨工作階段能恢復；權限拒絕、503、串流中斷與預算耗盡都有明確的階段性交付；最終結論能對照需求、證據與反證。

這次完成的是唯讀檢視，沒有修改 ADR、計畫或 RFC，也沒有執行測試或提交變更。核心調整是：讓使用者一次提交完整材料，再分階段深入理解；擴大可取用的證據範圍，而不是試圖無限擴大單一聊天視窗。

核心問題：一次交齊材料，不等於一次讀完材料

需求應從「網關支援複雜附件」，調整為「前置側接收大量材料，並組織可追溯、能持續交付的研究流程」。你可以一次把所有材料交給系統，但不應要求它們同時進入同一次模型呼叫。三遍閱讀可以是分析方法，卻不能取代有限上下文下的調度機制。13

哪種做法最接近這個目標？

研究方向：遞迴式語言模型

遞迴式語言模型（Recursive Language Models，RLM）會把大型輸入留在模型視窗之外，讓模型按需要檢查、拆分內容，再遞迴呼叫模型分析片段，而不是把整份材料直接塞進上下文。論文的 2026 年 5 月 11 日修訂版指出，這種方法可處理超過模型上下文視窗限制一個數量級以上的輸入。3

這與「把材料一次交齊，再深入研究」的需求相當接近，但不代表輸入量可以無限增加，也不保證結果必然可靠。論文同時指出，子呼叫可能帶來成本膨脹，護欄與執行流程也仍有複雜度。3

工程主線：按需載入，並留下可延續的工作紀錄

較務實的做法，是把按需載入、獨立子任務上下文、外部證據紀錄和分階段交付組合起來。Anthropic 的上下文工程資料建議，與其預先載入所有原文，不如採用輕量來源引用、動態載入、結構化筆記，以及讓子代理使用隔離上下文。12 長時間運作的代理系統也強調，要把任務拆成可處理的部分，並留下清楚的成果，讓下一個工作階段可以接手。7

Anthropic 於 2026 年 11 月 6 日發布的《The components of agent memory》，討論如何從工作紀錄形成新的筆記與表示。4 這是跨工作階段記憶的方向，並不會消除單次模型呼叫的上下文限制。

AWS 於 2026 年 5 月 21 日分享了以 AgentCore Code Interpreter 和 Strands 實作 RLM 的方案。6 這可作為編排機制的參考，但不能據此推論目前的 Cline 或現有 MCP 已具備相同能力。

建議先做出可控的前置研究編排，再把 RLM 式的遞迴閱讀作為後續能力；不宜一開始就引入任意程式碼執行或不設上限的子呼叫。

近期紀錄不代表所有問題都是上下文耗盡

本次檢視了五個近期 Roo 分析工作階段。找到的 Cline 儲存目錄只有設定，並未取得所指近期 Plan 工作階段的原始紀錄。因此，Cline 視窗崩潰的具體根因目前是：證據不足。

目前定位到兩類阻塞：

• **前置 MCP 解構工作階段：**紀錄中明確出現「專案不在伺服器授權集合」及上游串流提早中止，最後停在選擇取證方式。API 歷史字串約 2.1 萬字元，不能單憑這個數字判定上下文已耗盡。見工作階段紀錄。
• **流程圖比較工作階段：**紀錄中出現資源配置不可用的 503 錯誤及上游串流提早中止，最後也未能定位圖片內容。歷史字串約 36.7 萬字元，其中約 35.4 萬字元來自兩個圖片區塊；不能把編碼後的字元數當成文字 Token 數。見工作階段紀錄及內容類型紀錄。

另有工作階段留下了完成結果，因此不能概括為所有研究都無限延伸。輸入交付、權限拒絕、傳輸失敗與研究不收斂，應分別處理；上下文蒸餾無法修復前三類問題。

前置側如何承接「一次丟進全部材料」

建議設計成以下流程，而不是先把所有內容壓成一份固定長度的摘要：

1. **接收完整材料包。**保留腦力激盪原文，區分使用者目標、硬性限制、待釐清問題與參考材料。本機檔案、論文連結、網誌和程式碼儲存庫都應登記來源身分、版本、取得狀態與授權。無法取得的來源要明確列出，不要假裝已讀。
2. **建立可回讀的來源庫。**PDF 轉換、網頁正文擷取和程式碼結構分析是輸入處理方式；完整原文應留在前置側，並保留頁碼、區塊、符號或程式行等定位資訊。AST（抽象語法樹）骨架不等於讀懂原始碼，Markdown 轉換也不等於讀懂論文。
3. 安排三遍閱讀。
   • **第一遍：**掃描材料目錄和具代表性的內容，整理需求重述、證據地圖、候選方向與閱讀優先順序。
   • **第二遍：**依照決策問題分派有範圍限制的閱讀任務，要求回報主張、原文依據、限制、反證及尚未閱讀的範圍。跨資料關係仍須納入檢查，避免只靠相關性檢索而遺漏。
   • **第三遍：**針對會影響選擇的關鍵假設深入推演、補讀和反向檢查，推進 DR／DM 與使用者需求的收斂；不必機械式地把每份資料全部重讀三次。
4. **由主控維持動態工作集。**每一輪只帶入當前決策需要的證據、不可遺失的限制和未完成事項；需要細節時再回讀原文。前一版 RFC 提到的 20K–40K，應視為待驗證的工作集預算，而不是任何複雜任務都能一次壓縮到這個規模的保證。
5. **設定交付與停止門檻。**第一遍閱讀後就交付初步判斷。達到閱讀輪次、時間、費用或上下文預算時，應回報目前結論、衝突、未知事項與待補證據，而不是不斷搜尋直到崩潰。若重複閱讀已不再改變決策，就應停止；遇到權限拒絕、確定性錯誤或來源缺失，則應明確標示阻塞，不要無限重試。

以上是建議的工程契約，不是現有宿主已實現的能力。尤其需要驗證首次輸入如何接手，以及逐輪工具結果的預算如何管理；只註冊一個 MCP 工具，並不會自動攔截過大的首輪輸入。

ADR 與實作計畫應如何調整

• 目前 ADR：保留已接受的歷史基準與已定案的實體事實，另行記錄需求變更。明確界定網關不負責文件研究控制面；前置側的目標改為「針對大量混合來源進行漸進閱讀、證據整合與需求收斂」，而解析引擎只是可替換的介接器。
• 目前計畫：保留原有本機端已完成的範圍，另設獨立的增量驗證關卡，優先驗證完整輸入登記、有限工作集、三遍閱讀產物、跨工作階段恢復與異常狀況下的交付。不要先把大量時間花在競逐解析引擎，卻沒有可用的研究閉環。
• **驗收重點：**已讀範圍與來源可追溯；關鍵限制不遺失；工具結果不會無限膨脹；跨工作階段能恢復；權限拒絕、503、串流中斷與預算耗盡都有明確的階段性交付；最終結論能對照需求、證據與反證。

這次完成的是唯讀檢視，沒有修改 ADR、計畫或 RFC，也沒有執行測試或提交變更。核心調整是：讓使用者一次提交完整材料，再分階段深入理解；擴大可取用的證據範圍，而不是試圖無限擴大單一聊天視窗。