[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-trained-agentic-context-management":3,"topics-all":38,"news-related-88d15f9c-5548-4dae-bde5-75e79c3d0a28":57},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":24,"news_slug":31,"published_at":32,"created_at":33,"modified_at":34,"is_published":35,"publish_type":36,"image_url":14,"view_count":37},"88d15f9c-5548-4dae-bde5-75e79c3d0a28","8K 上下文顶 1M:把长文档问题训练成 agent 接力,而不是堆窗口","Bryce Sandlund 把 Qwen3.6-35B-A3B 微调成「会拆长文」的代理,用最简 read_chunk+spawn_subagent 工具集。8K 上下文下,OOLONG-synth 文档超 40K 与 1M 上下文 GPT-5.4 打平,RULER 上 10K-320K 文档 ≥85%。代码开源。","模型窗口短,长文档就砸\"问题\"。这两年长上下文赛道的默认解法是「把窗口撑到 1M、10M,甚至 100M」。但 Bryce Sandlund 在 arXiv:2610.02404 里给了一条反方向的路线:别再堆上下文,让模型自己学着拆。\n\n## 把长上下文问题转成 agent 接力\n\n作者把工具集砍到只有两个:`read_chunk(start, end)` 读原文任意区间;`spawn_subagent(subtask)` 拉一个独立上下文的子代理去解子任务。父代理拿到的是被刷成 OOLONG 风格的长文档,但每个代理自己的上下文硬性上限是 8K。父代理需要自己判断:该读哪段、该派谁去、什么时候把子结果汇总。\n\n这不是手写 prompt 工程。Sandlund 的实验显示,基模直接扔进这套 harness 后表现很差:base Qwen3.6-35B-A3B、GPT-5.4、Kimi K2.6 都会把原问题原封不动扔给子代理,根本不读文档;Opus 4.6 倒是开始拆任务,但会一口气递归到 300 美元的 API 额度烧光。模型对「在拆程序、解法、本地决策」没有先验。预训练是纯语言续写,agent 后训练也没教分解策略。Recursive Language Models 那类工具能跑,因为模型有强代码先验;但这条最简 harness 上,分解能力得现教。\n\n## 用 oracle SFT 教三种分解套路\n\n训练方法刻意选了 SFT 而不是 RL。作者给出的理由是:L 级别的强化学习探索能力,在「弱分解先验」面前根本逃不出去——同时也不清楚该给子代理什么 reward,如果用 GRPO 也不知道哪个 group 比较子代理的轨迹。\n\n他用更强的模型(Opus 4.8 \u002F 5 \u002F 5.5、Fable 5 \u002F 5.1)造了一条合成数据,教三种分解套路:\n\n- **tree reduce** 应对顺序无关的聚合任务(类比早期 GPT-3 摘要论文的思路);\n- **sequential fold** 应对顺序依赖的任务(类似 Memagent 那种\"滚动节点\"策略);\n- **agentic delegation** 在边界条件上由模型自己决定是直接读、派子代理还是汇总结果。\n\n关键设计是「不把分解结构焊死在 harness 里」——harness 只提供两个工具,具体怎么拆让模型自己学。最终微调的是 Qwen3.6-35B-A3B,合成的 oracle 数据来自 Claude\u002FGemini 系的更强智能体。代码已开源。\n\n## 8K 上下文追平 1M token 的 GPT-5.4\n\n结果分两部分。\n\n在 OOLONG-synth 上,文档长度超过 40K 时,8K-context 的小模型跟 GPT-5.4(medium reasoning,1M token 上下文上限)打平。换句话说,在某个长度区间之后,「窗口更大」不再带来长能力,反而「会拆文档」才是关键能力。\n\n在 RULER 上,文档从 10K 到 320K,该模型在每代理 8K 的硬限制下全程保持 ≥85% 准确率——基模原版在长文档上明显衰减。\n\n作者特别强调一点:训练数据故意排除了评测分布,目的是证明「在分布外的真实长文档上,sft 出的 agent 分解策略依然泛化」,而不是「专门刷榜」。\n\n## 工业界为什么没这么做\n\nMemGPT(2023)、RAPTOR(2024)、Chain-of-Agents(2024)、Recursive Language Models(2025)这一类工作,本质都是「工程化 harness」:人写好流程,把长文档切成可被分治的块。Memagent(2026)是同方向的训练工作,但「执行结构被焊在 harness 里」,只在自训练分布上验证。\n\nSandlund 的差异化是:harness 极简(只有两个工具),不写流程;分解能力完全交给 SFT 学出来的策略。同时,论文还做了个 ablations——RL 跑不出这种能力,弱探索是瓶颈。唯一的现有可参照训练方向是 Kimi K2.5 的\"agent swarm\",但它只训练父代理如何调子代理,不训子代理轨迹本身。\n\n## 长文能力可以被训练成策略,不一定是窗口\n\n这条路线最有意思的暗示是:不是所有长文档问题都需要原生 1M 上下文。如果代理本身学会怎么分解、何时组织,8K 窗口也能拖 320K 文档。\n\n代价是:SFT 数据质量是天花板——oracle 拆得对不对决定策略能不能泛化;训练数据生成成本不便宜(用 Opus 5、Fable 5.1 等更贵的模型造 oracle 轨迹)。论文也坦承,「opaque orchestration」被训练出来的策略,出了训练分布不一定稳。\n\n但对那些不推 1M 窗口、又嫌 MemGPT 类工程化太重的团队,这条线值得跟进:用 oracle SFT 把「上下文管理」当成可训练的策略,而不是每次都去堆原生窗口或外挂 harness。下一步要看 RL 阶段能不能接上去——这是作者留作 future work 的方向。","https:\u002F\u002Farxiv.org\u002Fabs\u002F2610.02404","7437aeb9-930c-4866-a2e9-48003c1a792b",[11,15,18,21],{"id":12,"name":13,"slug":13,"description":14,"color":14},"6ad31a14-c0da-42df-81fd-564281f768db","agentic-ai",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"0ef8513a-0a26-42f0-b6f9-5b6dadded45c","efficiency",{"id":19,"name":20,"slug":20,"description":14,"color":14},"01598627-1ea6-4b27-a5d8-874971571a71","llm",{"id":22,"name":23,"slug":23,"description":14,"color":14},"b9bd9039-fcdb-41a8-b85b-fc1587def2b9","open-source",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"e2e3de32-0b92-492c-a9c9-cd88e7d5684d","en","8K beats 1M: long-doc handling trained as agent relay","Bryce Sandlund fine-tunes Qwen3.6-35B-A3B into a long-document decomposing agent using a minimal read_chunk+spawn_subagent toolset. With an 8K per-agent cap, the model ties GPT-5.4 (1M context) on OOLONG-synth once documents exceed 40K, and holds ≥85% on RULER from 10K to 320K. Code is open-sourced.","When context windows run short, long documents break. The default fix in the long-context race over the past two years has been \"stretch the window to 1M, 10M, even 100M.\" Bryce Sandlund's arXiv:2610.02404 takes the opposite direction: stop stacking context, and let the model learn to decompose.\n\n## Long context, recast as an agent relay\n\nThe author shrinks the toolkit to two primitives: `read_chunk(start, end)` reads any slice of the source, and `spawn_subagent(subtask)` launches a child whose context is independent. The parent gets an OOLONG-style long document, but every agent in the chain is capped at 8K context. The parent must decide what to read, what to delegate, and when to fold sub-results back together.\n\nThis is not prompt engineering. Sandlund's ablations show that base models thrown into the harness perform poorly: base Qwen3.6-35B-A3B, GPT-5.4, and Kimi K2.6 simply forward the original question to subagents without ever reading the document. Opus 4.6 starts to decompose tasks, but burns through $300 of API credits building massive sub-agent trees. Models have no prior for \"when to delegate versus read.\" Pre-training is pure next-token continuation, and agentic post-training does not teach decomposition either. Recursive Language Models-style tools work only because models carry a strong coding prior; on this minimal harness, decomposition has to be taught.\n\n## Teaching three decomposition patterns with oracle SFT\n\nTraining deliberately picks SFT over RL. The author's reason: the exploration in L-level reinforcement learning cannot escape a weak decomposition prior, and it is unclear what reward to assign sub-agents. GRPO has no obvious group to compare sub-agent trajectories against.\n\nStronger models (Opus 4.8 \u002F 5 \u002F 5.5 and Fable 5 \u002F 5.1) generate a synthetic dataset that teaches three decomposition patterns:\n\n- **tree reduce** for order-independent aggregation tasks (echoing the GPT-3 summarization recipe);\n- **sequential fold** for order-dependent tasks (the \"rolling node\" strategy used by Memagent);\n- **agentic delegation** at boundary conditions, where the model decides whether to read directly, spawn a sub-agent, or fold results.\n\nThe key design choice is that decomposition structure is not welded into the harness. The harness only exposes the two tools; how to decompose is left for the model to learn. The fine-tuned backbone is Qwen3.6-35B-A3B, and the oracle data comes from stronger Claude\u002FGemini-family agents. Code is open-sourced.\n\n## 8K context ties 1M-token GPT-5.4\n\nResults come in two parts.\n\nOn OOLONG-synth, once documents exceed 40K tokens, the 8K-context small model ties GPT-5.4 (medium reasoning, 1M-token context limit). Past a certain length, bigger windows stop buying more long-context capability, while document decomposition starts mattering.\n\nOn RULER, across documents from 10K to 320K tokens, the model holds ≥85% accuracy under the per-agent 8K cap. The base model degrades visibly at the long end.\n\nThe author emphasizes one point: the training distribution was deliberately kept disjoint from the evaluation distribution. The goal is to show that an SFT'd agent decomposition strategy generalizes to out-of-distribution documents, not to memorize benchmarks.\n\n## Why industry has not done this yet\n\nMemGPT (2023), RAPTOR (2024), Chain-of-Agents (2024), and Recursive Language Models (2025) are all \"engineered harnesses\": humans write the workflow that chops long documents into piecemeal chunks. Memagent (2026) trains decomposition too, yet the strategy stays welded into the harness and only the training distribution is verified.\n\nSandlund's differentiator: the harness is minimal (two tools), the workflow is not written, and decomposition is fully owned by an SFT-learned policy. The paper also runs ablations showing RL cannot pull it off because exploration is the bottleneck. The only comparable training direction is Kimi K2.5's \"agent swarm,\" but that only trains the parent agent's call policy, not sub-agent trajectories themselves.\n\n## Long-context ability is a learnable strategy, not necessarily a bigger window\n\nThe most interesting implication: not every long-document problem needs a native 1M context. If the agent learns how to decompose and orchestrate, an 8K window can still carry a 320K document.\n\nThe cost: SFT data quality is the ceiling. Whether the oracle decomposes correctly determines whether the strategy generalizes. Training data generation is also expensive (oracles come from Opus 5, Fable 5.1 and similar top-tier models). The paper also admits that \"opaque orchestration\" trained into the weights may not stay stable outside the training distribution.\n\nStill, for teams that do not ship a 1M window and find MemGPT-style engineering too heavy, this line is worth following: treat context management as a learnable strategy via oracle SFT, instead of always reaching for a bigger native window or an external harness. The next step, which the author flags as future work, is whether an RL stage can plug in on top.","trained-agentic-context-management","2026-10-01T11:32:00Z","2026-10-06T01:12:22.357416Z","2026-10-06T01:12:22.357429Z",true,"agent",330,[39,48],{"slug":40,"tag_slug":40,"title_zh":41,"title_en":42,"intro_zh":43,"intro_en":44,"id":45,"is_active":35,"created_at":46,"modified_at":47},"ai-for-science","AI for Science 2026：从 UniPert 到 GPT-Rosalind 的硬核进化","AI for Science 2026: from UniPert to GPT-Rosalind","生命科学、化学材料、物理世界模型——AI 正在从\"语言工具\"变成\"实验伙伴\"。本专题收录 AI 在三大科学方向的关键节点：UniPert 统一基因与化学扰动空间、GPT-Rosalind 端到端生命科学推理、达摩院 AI 智能体 28 小时找到 4 种超导新材料、Anthropic Claude Science 把工作台做成标准品。","From language tool to lab partner — AI is reshaping life sciences, chemistry\u002Fmaterials, and physical world models. This topic covers the key milestones: UniPert unifying genetic-chemical perturbation spaces, GPT-Rosalind's end-to-end life-sciences reasoning, DAMO's AI agent discovering 4 superconducting materials in 28 hours, and Anthropic's Claude Science workbench going mainstream.","988a4300-5fab-41c4-b5d8-63711a2dc757","2026-09-10T01:34:15.296649Z","2026-09-10T01:34:15.296663Z",{"slug":49,"tag_slug":49,"title_zh":50,"title_en":51,"intro_zh":52,"intro_en":53,"id":54,"is_active":35,"created_at":55,"modified_at":56},"h3-series","MiniMax H3 系列：从开源权重到 35 倍吞吐","MiniMax H3 Series: from open weights to 35x throughput","MiniMax H3 自 2026 年 8 月开源以来节奏密集：官方把生成、参考与编辑收回一个模型；ComfyUI 当天压进 RTX 3060；摩尔线程 3 小时完成国产 GPU 适配；fal 后训练版把吞吐拉到 35 倍；FastH3 蒸馏再砍推理成本。本专题持续追踪 H3 的发布—开源—蒸馏—部署全链路。","Since MiniMax open-sourced H3 in August 2026 the pace has been relentless: one unified omni-modal model, same-day ComfyUI support down to an RTX 3060, a 3-hour Day-0 port to Moore Threads GPUs, fal's post-trained H3 Max at 35x throughput, and FastH3 distillation cutting inference cost further. This topic tracks the full H3 chain — release, open weights, distillation, deployment.","83ef0daa-3c31-4cb3-86ed-e5ee58654d5f","2026-09-08T07:33:19.942193Z","2026-09-08T07:33:19.942209Z",{"items":58},[59,64,69,74,79,84],{"id":60,"title":61,"news_slug":62,"published_at":63},"5878a668-282c-4b88-b2b8-7eef40b7938c","LFM2.5-2.6B：2.5GB 内存跑本机 Agent 220 tok\u002Fs","lfm2-5-2-6b-on-device-agent","2026-08-11T00:00:00+00:00",{"id":65,"title":66,"news_slug":67,"published_at":68},"15987a0e-bc06-4f21-9608-264da02d0e6c","AutoMem 让 32B 开源模型在长程任务上追平 Claude Opus 4.5","automem-stanford-32b-long-horizon","2026-07-23T12:10:00+00:00",{"id":70,"title":71,"news_slug":72,"published_at":73},"5edbfca7-7c1a-4df3-8577-a0195408b827","RSI-Anything:世界模型陪跑,自我改进有了回滚键","rsi-anything-world-model-recursive-self-improvement","2026-10-12T21:20:00+00:00",{"id":75,"title":76,"news_slug":77,"published_at":78},"a820bb5a-ac48-4aab-8d8b-34da340900c1","REMORY 让 LLM 用 5% 上下文继续跑 Agent","remory-agent-memory","2026-10-11T09:00:00+00:00",{"id":80,"title":81,"news_slug":82,"published_at":83},"95e663a4-2cdf-454c-9787-b154fbd41909","TokenRouter:token 级路由提速 64 倍","tokenrouter-token-level-llm-routing","2026-10-09T21:11:28+00:00",{"id":85,"title":86,"news_slug":87,"published_at":88},"e40de2f9-9ee4-47f3-b1f1-7bf93a4870a9","一个动词翻转工具调用决策,LLM 内部向量现形","llm-tool-call-decision-vector","2026-10-09T13:10:00+00:00"]