为什么 200K 窗口还是不够
2026 年 11 月 4 日，AWS 机器学习博客发布 Deep Insight 系列第二篇《Four layers of context engineering for production AI agents: How Deep Insight applies them in working code》。Deep Insight 是一个开源的多智能体数据分析方案，构建在 Strands Agents SDK 与 Amazon Bedrock AgentCore 之上，在该系列中充当参考实现。文章讨论的起点不是模型能力，而是一个很具体的工程现象：窗口够大，任务仍然跑不完。
官方举的例子是「分析销售数据并生成一份 DOCX 报告」。这个请求被拆成五段：数据与探索约 5 分钟、按品类做销售分析约 3 分钟、生成五张时序图表约 10 分钟、统计校验约 3 分钟、最终报告生成约 5 分钟；合计消耗超过 150,000 token，对照的是 Claude Sonnet 4.5 在 Amazon Bedrock 上的 200K token 窗口。文章列出三类失效：窗口中途溢出、陈旧上下文拉低输出质量、一处错误需要整条流水线重跑；并引述 Anthropic 关于 Context rot 的判断，即上下文内 token 增多时，模型准确召回其中信息的能力会下降。
| 阶段 | 官方给出的耗时 | 动作 | 对上下文的影响 |
|---|---|---|---|
| 数据与探索 | 约 5 分钟 | 载入并理解数据 | 原始数据结构进入上下文 |
| 按品类分析 | 约 3 分钟 | 分类聚合 | 中间结果累积 |
| 生成五张图表 | 约 10 分钟 | 时序可视化 | 脚本与输出同时膨胀 |
| 统计校验 | 约 3 分钟 | 验证计算 | 校验记录叠加 |
| 报告生成 | 约 5 分钟 | 产出 DOCX | 需要回看前面所有结论 |
上面五段耗时相加为 26 分钟，而同篇文字把整个过程描述为「约 15 分钟、超过 150K token」。公开材料没有说明是部分阶段并行、还是两段计时范围不同，因此这两个数不宜互相代替。本文并列保留，不据此推算吞吐量。
把 150,000 放进 200,000 的窗口，占用约 75%。四层工程并不是把窗口做大，而是把这个占用比例往下压；但官方没有公布四层叠加之后、端到端跑完一份报告实际用了多少 token，这一点决定了后续所有百分比的可比范围。
四层全景：三层压输入，一层查输出
AWS 把 Anthropic 的上下文工程建议与 Strands Agents SDK 的内建能力整理成四层：在架构层隔离上下文、在提示层控制流入、把重内容外置到文件系统、用独立智能体与防护机制做验证。四层不是四个并列开关，而是递进补偿：上一层漏掉的，由下一层兜住。
| 层 | 作用对象 | 主要手段 | 官方读数 | 公开材料未给 |
|---|---|---|---|---|
| 架构层 | 各角色自己的上下文 | 专职智能体隔离，只回传压缩摘要 | Coder 控制在 25K token 以内 | 多角色并行时的全局峰值 |
| 提示层 | 单次输出与常驻指令 | 输出预算、脚本自包含、技能按需加载 | 系统提示约缩 97% | 不同技能库规模下的泛化比例 |
| 文件层 | 脚本与大体量结果 | 写入并执行工具只回短摘要 | 每脚本约省 95% token | 整条任务的端到端 token 总量 |
| 验证层 | 写进交付物的数字 | Validator 重算、Auditor 对照引文 | 差异阈值 0.01、最多两次重试 | 开启前后的错误率对照 |
把四层都当成同一个「省 token」指标会误读。架构、提示、文件三层减少的是进入上下文的 token；验证层并不改变进入量，它改变的是写进报告的数字是否经过独立重算。因此把 95% 与 97% 相加得到 192% 没有物理意义，两者分别作用于脚本回传与技能常驻指令，分母并不同。
这个区分也解释了为什么该系列第三篇被安排为 harness engineering 与 VPC 私有网络部署：前四层解决的是单任务内的信息组织，跨任务的环境、权限与运维属于另一层问题（AWS 把第三篇标注为即将发布）。
架构层：按角色隔离上下文
Deep Insight 把一份报告的生产拆给多个专职智能体。公开材料与转述中出现的角色包括 Coordinator、Planner、Plan Reviewer、Supervisor、Tool Agents、Coder、Validator、Reporter、Auditor 与 Tracker。每个角色持有自己的上下文，向协作链路只回传压缩摘要；共享状态里保留的是压缩线索、计划清单、简短历史与上一个智能体的最终消息，而不是各角色的完整轨迹。
| 角色 | 职责 | 调用特征 | prompt caching |
|---|---|---|---|
| Coordinator | 接收请求、启动流程 | 一次性 | 关闭 |
| Planner / Plan Reviewer | 拆解与复核计划 | 一次性或低频 | 关闭 |
| Supervisor | 协调各专职智能体 | 重复调用 | 开启 |
| Coder | 编写并执行分析脚本 | 上下文负担较重 | 开启 |
| Validator | 重算 Coder 的结果 | 命中率低 | 关闭 |
| Reporter / Auditor | 成文与交付件核对 | 重复调用 | 开启 |
| Tracker | 状态跟踪 | 命中率低 | 关闭 |
官方称这套隔离让上下文负担较重的 Coder 总量保持在 25,000 token 以内。把 25,000 放进 200,000 的窗口是 12.5%，但这是单个角色的上限，不是全局占用；多个角色并行、叠加共享状态时总量如何变化，公开材料没有给出峰值读数。
值得注意的是，角色隔离同时是验证层的前提：Validator 之所以能「独立」重算，正是因为它没有继承 Coder 的完整推理轨迹，只拿到需要核对的计算与结果。若为了省事让两者共享同一份上下文，重算就会退化成复读。
提示层：把输出预算写成硬约束
提示层做的不是把提示词写得更好，而是给每个角色的输出设定可检查的额度。公开材料给出的预算为：Coder 每次 1,000 至 1,500 token，Validator 800 token，Reporter 1,000 token。脚本被要求自包含，旧代码可以从上下文中丢弃；可复用的专业指引不再整段常驻，而是作为 skills 按需加载。
| 预算项 | 数值 | 作用 | 口径边界 |
|---|---|---|---|
| Coder 单次输出 | 1,000 至 1,500 token | 限制脚本解释文字进入上下文 | 单次输出，非单角色总量 |
| Validator 单次输出 | 800 token | 只回报差异与判定 | 单次输出 |
| Reporter 单次输出 | 1,000 token | 控制成文阶段的回传量 | 单次输出 |
| 技能目录常驻 | 约 500 token | 替代常驻完整指南 | 启动时加载 |
| 按需加载的 SKILL.md | 约 3K token | 用到时再取 | 单项指南示例值 |
| 原常驻技能正文 | 超过 20,000 token | 对照基线 | 该参考实现中的示例规模 |
500 对 20,000 约为 2.5%，与官方「系统提示约缩 97%」方向一致。但 20,000 是该参考实现里技能正文的示例规模：技能库更大的项目会放大缩减幅度，技能库很小的项目则几乎无感。这个百分比描述的是那一段常驻指令，不是整份系统提示词，更不是整条任务的成本。
输出预算与角色隔离是一组配套设计：没有隔离，预算会被其他角色的历史挤占；没有预算，隔离出来的上下文仍会被本角色自己的长输出填满。
文件层：写入并执行工具只回摘要
文件层的做法是把「生成代码」与「阅读代码」都搬出消息流。Deep Insight 用一个 write-and-execute 工具完成三件事：保存脚本、执行脚本、只返回一段短摘要与输出的前 500 个字符。详细结果落到文件（公开材料提到 all_results.txt）供 Reporter 按需读取；常用分析函数预置在 coder_analysis_utils.py 里，避免每轮重新生成；专业指引放进 skills 目录，由目录与 SKILL.md 自动发现。
| 环节 | 传统做法回传 | 文件外置后回传 | 官方示例量级 |
|---|---|---|---|
| 脚本本体 | 整段代码进入上下文 | 保存为文件，只回摘要 | 约 100 行对约 3 行 |
| 执行输出 | 完整输出进入上下文 | 只回前 500 字符 | 约 20,000 token 对约 500 token |
| 详细结果 | 随消息传递 | 写入 all_results.txt 供读取 | 未披露文件大小 |
| 复用函数 | 每轮重写 | 预置 coder_analysis_utils.py | 未披露复用率 |
官方据此给出「每个脚本加入上下文的 token 约减少 95%」。这个数字的定语很关键：它是单个脚本的一次回传，不是整条任务的总账。一份报告会经历多轮脚本、多次工具调用与跨角色摘要，局域减幅能否等比例传导到端到端账单，公开材料没有给出实测。
验证层：独立智能体重算与抽样
验证层由三道动作组成。Validator 重跑 Coder 的计算，差异达到 0.01 即标记；Auditor 把完成的 DOCX 与已核验的引文逐项对照，最多可要求 Reporter 重试两次；汇总式 conversation manager 作为兜底，在上下文接近阈值时压缩历史。这套设计把「报告里的数字」与「生成数字的那次推理」分开核验。
| 组件 | 触发条件 | 阈值或上限 | 公开材料未给 |
|---|---|---|---|
| Validator | Coder 产出计算结果后重算 | 差异达到 0.01 即标记 | 该阈值下的漏检率 |
| Validator 抽样 | 计算项超过 50 项时 | 高重要度全检，中重要度抽 10 项 | 低重要度的抽样比例 |
| Auditor | DOCX 成稿后对照已核验引文 | 最多要求两次 Reporter 重试 | 两次仍不通过时的处置 |
| conversation manager | 上下文接近阈值 | 压缩会话历史 | 压缩触发的具体阈值 |
「计算项超过 50 项时，高重要度全检、中重要度抽 10 项」实际上把复核覆盖率写成了一个随任务规模变化的参数：计算项越多，中低重要度被抽到的比例越低。这是精度与成本之间的显式取舍，也意味着长任务上的验证强度并非恒定。官方没有给出该规则下的错误检出率或漏检率对照，团队复现时应把它当作可调项而非默认值。
把这一层与前三层并排看，会发现它并没有减少任何 token 进入；相反，Validator 的重算与 Auditor 的对照都会新增调用。四层合起来是「用一部分新增的验证开销，换取前面三层省下的窗口空间与结论可信度」，而不是纯粹的压缩方案。
成本层：缓存只对重复调用的角色开
缓存策略按角色区分：Supervisor、Coder、Reporter、Auditor 开启 prompt caching；一次性的 Coordinator 与 Planner、命中率较低的 Validator 与 Tracker 不开启。官方说明是缓存只在相同提示被反复调用时才有收益，并给出「重复调用时缓存输入 token 最多可省 90%」这一数值。
| 分组 | 角色 | 是否缓存 | 判断依据 |
|---|---|---|---|
| 重复调用组 | Supervisor、Coder、Reporter、Auditor | 开启 | 同一提示在多轮中反复出现 |
| 一次性组 | Coordinator、Planner | 关闭 | 调用次数少，缓存命中不足 |
| 低命中组 | Validator、Tracker | 关闭 | 输入随任务变化，复用率低 |
95% 来自单个脚本的回传量，97% 来自技能常驻指令的体积，90% 来自定价说明中缓存输入 token 的折扣上限。三者既不是同一条任务链上的连续环节，也不共享分母，不能连乘或相加得出「总体节省」。更关键的是，这篇官方文章没有给出每份报告的美元成本、开启与关闭 Validator/Auditor 的错误率对照，以及端到端延迟；它介绍的是自家 SDK 与托管服务的参考实现，宜当作可复现清单，不宜当作节省证明。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是 Part 3 的 harness engineering 与 VPC 部署细节、四层叠加后的端到端成本与第三方复现结果。
同周三路线：别把三张账单加在一起
同一周还出现了两条相近但落点不同的路线。其一是火山引擎 OpenViking：用 viking:// 形式的可导航文件系统替代不透明的向量存储，把上下文组织成 L0 摘要、L1 概览、L2 细节三层，让智能体先用摘要判断相关性再决定是否加载全文；项目文档自报在 LoCoMo 长对话记忆基准上，把三家框架的记忆准确率从 24% 至 57% 提升到 80% 至 83%，输入 token 降 34.3% 至 91.0%，查询延迟降 58.45% 至 66.10%，tau2-bench 上零售与航空场景分别提升 6.87 与 11.87 个百分点，采用 AGPLv3 并提供自托管。其二是 TinyContext（11 月 2 日）：用单个本地 SQLite 文件 agent-memory.db 承载记忆，提供 save_memories、recall_memories、list_memories、get_memory、update_memory、delete_memory 六个 MCP 工具，把 profile 事实与 episodic 结论分开存储，附约 60 行 Python 示例与 800 token 召回上限。
本站此前解构过另外两条：AWS Infinity（R-TECH-49）用无栈协程让智能体在工具调用等待期间挂起、只保留会话历史；Redis Iris（R-TECH-58）把上下文引擎做成运行时能力，与记忆、路由、网关并列。把五者放在一起，能看出它们作用在同一条长任务账单的不同段落。
| 路线 | 作用的账单段 | 主要手段 | 公开读数 | 口径边界 |
|---|---|---|---|---|
| Deep Insight | 进入窗口的 token | 角色隔离、输出预算、文件外置、独立复核 | 每脚本约省 95%、技能指令约缩 97% | 厂商自报的单步示例 |
| OpenViking | 跨会话检索与存储 | 可导航文件系统、L0/L1/L2 分层加载 | 准确率 24% 至 57% 提到 80% 至 83% | 项目自报，未见第三方复现 |
| TinyContext | 跨会话记忆的部署成本 | 本地 SQLite 单文件、六个 MCP 工具 | 约 60 行 Python、800 token 召回上限 | 轻量方案，未给长任务基准 |
| AWS Infinity | 等待时占着的进程 | 无栈协程、挂起后只留会话历史 | 官方定位为早期研究版本 | 与上下文窗口无关 |
| Redis Iris | 运行时上下文调度 | 上下文网关、路由、记忆并列为运行时能力 | 部分能力为公开预览 | 产品成熟度分层 |
先定位瓶颈在哪一段，再选路线。失败表现为窗口中途溢出，优先看文件外置与输出预算；表现为换一个会话就失忆，优先看记忆层；表现为大量智能体在等待工具调用时空转，优先看运行时挂起与快照恢复。三条路线没有共同分母，任何把百分比相加、或据此排出优劣名次的做法都缺少依据。
可证伪边界与未披露项
把这篇材料当作工程清单时，有几处应当保留怀疑：
- 缺端到端账本：没有每份报告的美元成本、四层叠加后的总 token 数与端到端延迟，局域减幅无法换算成整体收益。
- 缺对照实验：没有给出开启与关闭 Validator、Auditor 时的错误率差异，验证层的收益目前只有机制描述。
- 示例不是基准：95% 与 97% 来自作者给出的 worked example，不是跨任务、跨模型的统计结果。
- 计时口径不一致：五段耗时相加 26 分钟，与文中约 15 分钟的总时长表述并列存在，公开材料未解释差异。
- 同周两条路线均为项目自报：OpenViking 的准确率、token 与延迟区间，以及 TinyContext 的接入成本，目前均未见第三方复现。
- 厂商立场：原文用于介绍 Strands Agents SDK 与 Amazon Bedrock AgentCore 的组合，架构可迁移，读数不宜外推到其它栈。
一条可证伪的检验路径是：冻结智能体设计，只把上下文窗口换成更大的规格，若同样能避免中途溢出并达到同等级减幅，则「四层优于更大窗口」这一主张就不成立。这个提法来自第三方对原文的方法学评述，本文照录并标注出处。
可迁移的部分其实不依赖 AWS：把生成的代码与大体量结果放进文件、给每个角色设定输出额度、按需加载专业指引、对报告里将要引用的每个数字安排一次独立重算。这四条在多数智能体框架里都能先做小规模 A/B，再决定是否引入完整的验证智能体。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是 Part 3 关于 harness engineering 与 Amazon VPC 部署的具体方案，以及四层的第三方复现数据。