Amazon Bedrock AgentCore 突破上下文窗口限制：用递归语言模型处理超长文档

一句话看懂

AWS 发布基于 Bedrock AgentCore 的递归语言模型方案，通过代码解释器作为持久工作记忆，实现无上限上下文窗口处理超长文档。

详细发生了什么

当文档长度达到数百万字符时，即使最大的上下文窗口也会失效——模型要么拒绝输入，要么因“lost in the middle”问题产生不完整答案。AWS 在最新博客中介绍了如何利用 Amazon Bedrock AgentCore Code Interpreter 和 Strands Agents SDK 实现递归语言模型（RLM），从根本上解耦文档大小与模型上下文窗口的限制。

RLM 由 Zhang 等人在 arXiv:2512.24601 中提出，核心思路是将输入视为外部环境，模型通过编程方式与之交互。根 LLM 仅接收查询和环境描述，然后编写代码来搜索、切片和迭代分析文档。当需要语义理解时，它会调用子 LLM（sub-LLM）处理特定段落，结果以 Python 变量形式保存在工作记忆中，不占用根 LLM 的上下文窗口。

架构包含三个组件：根 LLM 代理（基于 Strands Agents SDK）、运行在 PUBLIC 网络模式下的 Bedrock AgentCore Code Interpreter 会话（文档预加载为 Python 变量），以及注入沙箱的 llm_query() 函数，用于直接调用 Bedrock 进行子 LLM 分析。

在 Financial Multi-Document QA 子集（LongBench v2）上的评测显示，RLM 在 200K token 基础模型和 1M token 长上下文模型之间取得了平衡：成功率达到 100%（基础模型仅 33%），准确率 73%（长上下文模型 67%）。

中文圈视角

对中文用户而言，这个方案最直接的价值在于处理超长中文文档——比如合同审核、年报分析、学术文献综述等。国内类似场景通常依赖分段摘要或 RAG，但 RLM 的递归结构能更精细地保持上下文连贯性。

不过，该方案完全依赖 AWS 生态：需要 AWS 账号、Bedrock 模型访问权限，且 Code Interpreter 的 PUBLIC 网络模式可能涉及数据出境问题。对于国内用户，如果数据合规要求严格，可以考虑阿里云的通义千问长上下文模型（最大 10M token）或百度文心的分段处理方案，但缺乏类似的递归编程框架。

一个值得关注的盲点是：RLM 的递归调用成本——每次子 LLM 调用都产生独立 API 费用，对于百万字符文档，总成本可能远超直接使用长上下文模型。AWS 未在博客中提供成本对比，用户需根据实际文档长度和查询复杂度评估。

几条值得记住的细节

• RLM 通过 Code Interpreter 的持久会话状态实现工作记忆，变量在多次代码执行间保留。
• llm_query() 函数在沙箱内直接调用 Bedrock，子 LLM 结果不回流到根 LLM 上下文窗口。
• 评测使用 Financial Multi-Document QA 子集，文档长度约 2M 字符，RLM 成功率达 100%。
• 需要 IAM 权限：bedrock:InvokeModel、bedrock-agentcore:StartCodeInterpreterSession 等。
• 根 LLM 使用 Claude Sonnet 4.5，子 LLM 可指定任意 Bedrock 模型。

一句话总结

如果你经常处理超长文档且需要精细分析，RLM 方案值得尝试，但需权衡 AWS 依赖、数据合规和递归调用成本。