在 LLM 發展的上半場，我們執着於不斷拉長 Context Window，從 8K 到 128K 甚至百萬級別。但在下半場，資深開發者們逐漸意識到：盲目拉長上下文是在用昂貴的算力掩蓋邏輯管理的無能為例。 這一章我們圍繞Coding這個核心視角來尋找一些新的上下文管理的思路：以 Coding 為核心，將 Context 視為“內存（RAM）”，將 Runtime 視為“狀態（State）”，構建一套屬於智能體的“操作系統”。
最近，ByteDance 的 Context-Folding、MIT 的 RLM、以及熱門項目 Ralph 的出現，共同指向了一個極其明確的趨勢：未來的智能體不再是“文本生成器”，而是Stateful Runtime Operator。
這一章我們不精讀論文，而是圍繞coding的上下文管理，分別看下以下論文中相關的點。
內存摺疊：上下文的“分級治理”與垃圾回收
- Scaling Long-Horizon LLM Agent via Context-Folding
在長程任務（如 Deep Research 或全庫代碼修改）中，Agent 會產生海量的中間工具調用日誌。傳統的做法是全量堆疊，但這會導致上下文迅速“通脹”。
- 核心工程實現：Branch & Return
字節的方案非常 Native 地借鑑了 Git 分支管理的概念：
- Branch(description, prompt)：創建一個子分支，開啓子任務，此時所有的中間邏輯（搜索結果、讀取的長文件）僅在子分支內流轉。
- Return(message)：子任務結束，物理刪除子分支內所有過程 Token，僅將精煉後的執行結果 merge 回主分支。
這裏字節是使用了GRPO來通過訓練優化模型調用Branch和Return工具的準確程度，不過這個摺疊的思路其實是可以通過工具描述結合Git的相關操作來實現。
近期Claude 2.1的最新迭代中，SKILLS已經支持了fork功能，讓SKILLS在隔離的上下文中運行，不會污染外層會話。所以在當前這個階段，大家的想法都趨於一致性~
RLM：把上下文當作“外部存儲”的漸進式加載
- RECURSIVE LANGUAGE MODELS
RLM 的思路與數據預處理中的“漸進式加載”如出一轍：當內存（Context Window）裝不下超大文件（Long Prompt）時，不要強行負載，而是通過編程手段分片處理。
- 核心範式：上下文即變量
RLM 將提示詞加載為 Python REPL 環境中的全局變量 ctx。模型不再是“閲讀”指令，而是通過以下操作“操控”指令：
- Probe：通過 print(ctx[:500]) 觀察指令局部。
- Split & Loop：根據關鍵詞分割指令，並進行循環遞歸。
- Regex：利用正則精準定位關鍵信息。
- llm_query：這是論文中很有意思的一個點（哈哈雖然我對效果存疑）——在代碼環境中反向暴露大模型能力，實現“模型嵌套代碼，代碼調用模型”。
這裏對比Context-Folding在每個branch開始還需要主Branch向子branch發送全部信息，而RLM只需要通過全局的變量持久化，就可以實現主要信息的直接傳遞，無需大量顯式的信息傳遞。
這裏就有兩個點感覺有試驗下的價值
- 通過持久化變量傳遞信息：不過需要注意的是通過print打印變量的關鍵信息，因為coding是不隨多輪對話傳遞的，因此需要在觀測中暴露必要信息，這一點其實是不穩定的根源
- 在code環境中引入模型操作: 使用例如RLM定義的llm_query這個函數，在代碼工具中反向暴露大模型操作，從而把簡單的代碼工具，進一步拓展成擁有模型能力的獨立子智能體
使用GPT5的完整指令如下，僅參考思路，個人更傾向從工具角度去做結合（還是要順着模型native能力的發展方向去做）~
CaveAgent：雙流架構下的“狀態化”運行時
- CaveAgent: Transforming LLMs into Stateful Runtime Operators
CaveAgent 進一步強化了“變量即記憶”的思路。它提出 LLM 應該在兩個流中切換：
1. Dual-stream Architecture
- Semantic Stream（語義流）：輕量級推理上下文，僅記錄“想了什麼”。
- Runtime Stream（運行時流）：持久化的 Python 環境，記錄“存了什麼”。模型直接操作外部變量的“句柄（Handle）”而不是內容。
2. 深度思考：變量 vs. 文件
Manus之前在上下文管理中推崇以文件作為持久化介質，但變量存儲在某些場景下更有優勢：
- 更細粒度的觀測：利用 df.describe() 或 obj.dict 可以生成比文件讀取更精煉、結構化的信息觀測（State Observation），這比 RAG 檢索文件片段更精準。
- 運行時一致性：變量支持條件篩選、動態更新（例如 Plan 結構體），每完成一步，將 is_finish 置為 True，實現原生的狀態跟蹤。
可以當前看變量最大的問題在於觀測信息的局部化，和文件所見即所得存在差異，如何更全面完整精簡的描述變量是一個值得思考的問題。
Ralph
- https://ghuntley.com/ralph/
Ralph 項目最近在社區極火，它的名字“Repeatedly running agent in a loop”揭示了它的本質：通過“上下文徹底重置”來保證長程任務不崩潰。
整個智能體的執行鏈路，在指令裏面有比較清晰的描述
## Your Task
1. Read the PRD at `prd.json` (in the same directory as this file)
2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
3. Check you're on the correct branch from PRD `branchName`. If not, check it out or create from main.
4. Pick the **highest priority** user story where `passes: false`
5. Implement that single user story
6. Run quality checks (e.g., typecheck, lint, test - use whatever your project requires)
7. Update AGENTS.md files if you discover reusable patterns (see below)
8. If checks pass, commit ALL changes with message: `feat: [Story ID] - [Story Title]`
9. Update the PRD to set `passes: true` for the completed story
10. Append your progress to `progress.txt`
1. 以代碼執行為核心的plan & Execute
- Plan環節
這一步其實和大家常用的Plan類似，Ralph選擇JSON文件進行步驟管理。Anthropic也採用了相似的思路，認為JSON比Markdown模型進行亂改的概率更小。Raphal把生成Plan的過程拆分成了兩個步驟，分別用SKILLS來實現
- 生成markdown格式的PRD文檔：根據用户需求，可以適當追問明確細節，然後生成對應格式的PRD文件。兩個核心要求
- 單個step要足夠原子化（保證上文長度可以足夠完成任務），但實際上這只是美好的願望，依舊需要後處理壓縮邏輯來100%保證
- 具體可衡量的驗收標準：通過lint、test、browser verify進行明確驗收反饋
- Execute環節
執行步驟，會循環以上PRD.json的所有步驟，按順序進行執行，每個Step執行是Bash裏面全新的一次智能體循環，所以擁有全新的上下文，但是引入了經驗壓縮步驟
- progress.txt：基於前面執行步驟的重要觀測，核心包括已完成功能、文件修改、以及後面執行任務可以借鑑的經驗
- Agents.md: 把整個項目可複用的編碼經驗，在每次執行完成以後，更新到Agents.md。其實在前面的progerss.txt已經有一輪經驗反思和壓縮。所以其實這裏是兩種不同等級的經驗提取，不過感覺指令裏面區分的並不算很清晰。可以進一步分成Project Specific和Engineer Specific可能會更加清晰。
一個多步循環的Demo如下圖所示
五、 總結與突破：邁向 VM-Agent 架構
簡單總結下，Agent的上下文應該是基於狀態機和代碼運行時的上下文治理協議：
- 解耦“想”與“記”：窗口只留當前任務；Runtime存儲活躍變量；文件系統存儲長效經驗。
- 符號化操作：強制要求模型通過 search()、split()、filter() 來感知長上下文，嚴禁直接讀取超長文本。
- 遞歸函數化：將複雜的子任務封裝成 Python 函數，內部調用 llm_query，實現真正的模塊化推理。
在追求無限長的context的同時，追求無限精簡的有效狀態
