200K 的上下文窗口，听起来足够奢侈。但一个真实的“分析销售数据并生成 DOCX 报告”任务，能在 15 分钟内烧掉 15 万 token，把窗口逼到溢出边缘。
这不是假设。AWS 在官方博客里给了一个账本：同一个任务要跑过数据加载与探索、分类销售分析、生成 5 张时间序列图、统计验证、最终报告生成五个阶段，累计消耗超过 15 万 token。而 Anthropic 在 2025 年 9 月的工程文章里早就下了结论：“随着上下文窗口中 token 数量增加，模型从该上下文中准确回忆信息的能力会下降”，他们给这个现象起了个名字：Context rot，上下文腐烂。
窗口越大，记忆越差。这正是生产级 AI 代理最尴尬的悖论。
于是问题变了：不是怎么把更多东西塞进窗口，而是怎么让代理在窗口之外也能干活。AWS 的答案是一套四层上下文工程体系，而且不是纸上谈兵——它被实现在一个名叫 Deep Insight 的开源多代理数据分析方案里，用 Strands Agents SDK 和 Amazon Bedrock AgentCore 搭起来，作为参考实现贯穿全文。效果是量化的：一个 write-and-execute 工具把每个脚本加入上下文的 token 砍掉约 95%，按需加载 skills 再把过滤后的上下文砍掉约 97%。
为什么“大窗口”救不了生产代理
把任务交给单个代理，是最直觉的做法，也是最容易崩的做法。
从用户请求、数据探索、分析、画图、验证到报告生成，所有信息在一个上下文里层层累积，很快突破窗口上限。一旦溢出，代理要么执行到一半失败，要么准确性下降，要么只能把整条流水线重跑一遍——在按 token 计价的时代，每一次重跑都是真金白银。
更隐蔽的问题是注意力稀释。上下文越长，模型对关键信息的注意力越弱。Anthropic 的原话是，token 越多，准确回忆能力越差。这意味着即使窗口没满，性能也在悄悄下滑：5 万 token 时可能还正常，10 万、15 万 token 时模型已经开始“记不住”了。
所以上下文工程不是技巧合集，而是一门横跨架构设计、提示词编写、工具实现、验证机制的分层学科。每一层都在补前一层的漏洞。AWS 把这四层排成一张表：第一层是架构，用多代理架构隔离上下文，每个代理在独立上下文中运行，局限是仅靠隔离还不够；第二层是提示词，用输出控制和行为规则限制上下文流入，局限是仅靠提示词还不够；第三层是工具，把重型内容外置到文件系统，局限是问题仍会出现；第四层是验证代理与防护机制，独立核查错误、防止溢出，作为最后一道防线。
四层串联成一个防御系统：隔离不够，提示词来限流；提示词不够，工具把内容搬出去；还出问题，验证层兜底。
第一层：把上下文切成小块，每个代理只拿自己那份
第一层的核心动作是隔离。给每个专业化代理分配独立的上下文窗口，只把压缩后的结果传给协调者。
Deep Insight 搭了一套代理层级：Coordinator、Planner、Plan Reviewer、Supervisor，再加上一组工具代理——Coder、Validator、Reporter、Tracker、Auditor。每个代理只接收自己需要的信息，完成任务后发一个完成通知和简短摘要，而不是把整段历史丢给下一个代理。
关键在“最小化共享”。Deep Insight 用一个 Python 字典 shared_state 只存四样东西：上一个代理的最终消息、计划清单状态等极轻量的元数据，重的东西一律不进共享状态。
效果立竿见影。即使是用 token 最多的 Coder 代理，总上下文也被压在 25K 以下，只有 200K 窗口的八分之一。单个代理的上下文不再随任务时长线性膨胀，而是被锁在一个可控区间里。
但这层有天然边界：隔离能防止单个代理撑爆窗口，却管不住代理自己往上下文里塞废话。一个不受约束的 Coder 完全可以在自己的 200K 里写满冗余输出，再把冗长摘要传给下游。所以需要第二层。
第二层：用提示词给输出装上流量计
第二层从源头限流：输出 token 预算、标准化响应格式、自包含代码理念。
输出 token 预算是给代理的输出设上限，逼它说重点；标准化响应格式让每个代理的输出结构一致，下游解析时不用反复猜；自包含代码理念则要求代码片段本身完整可读，减少来回追问带来的上下文往返。
这三招的共同点是主动限制上下文流入，而不是等溢出后再补救。它们把“省 token”从一种事后优化，变成提示词里的硬性行为规则。
第二层的局限同样明显：提示词是软约束，模型状态波动、任务复杂度上升时，预算可能被突破，格式可能走样。当提示词 alone 不够用时，第三层接手。
第三层：把重型内容扔到文件系统里
第三层是上下文工程里最容易被低估、也最有效的一层：文件即上下文。
Deep Insight 的做法很彻底。它实现了一个 write_and_execute_tool：代码不放进上下文，而是写进文件再执行。仅这一项，就把每个脚本加入上下文的 token 减少了约 95%。
更进一步，文件系统被当成代理间的通信总线。所有重内容都在文件里流转，上下文里只传文件名和摘要：all_results.txt 由 Coder 写入分析结果累积日志，Reporter 读取生成报告；calculation_metadata.json 由 Coder 记录每次数值计算的来源、公式和值，交给 Validator 复核；citations.json 由 Validator 写入验证通过的引用数据，Reporter 插入报告；audit_findings.json 由 Auditor 写入最终报告里的引用缺陷，驱动 Reporter 针对性重试；coder_analysis_utils.py 由 Coder 写一次共享工具函数，所有脚本反复导入，不用重复生成。
再加上按需懒加载 knowledge——知识只在需要时才被拉进上下文——Deep Insight 把按需加载 skills 后的过滤上下文再砍掉约 97%。
这层的精妙之处在于，它把“上下文管理”变成了“文件系统管理”。文件可以无限增长，上下文窗口不行。代理之间靠文件对话，上下文里只保留最轻的指针。
但文件也会写错，计算也会算错。代码外置解决了 token 问题，没解决正确性问题。所以需要第四层。
第四层：让另一个代理当审计员
第四层是独立验证与防护机制，也是最后一道防线。
Deep Insight 在这里摆了三道岗。Validator 对 Coder 的数值计算做独立复核——不是读一遍代码，而是自己重新算一遍，比对 calculation_metadata.json 里的来源、公式和值。Auditor 对最终报告做只读引用审计，找出引用缺陷写进 audit_findings.json，逼 Reporter 针对性重试，而不是全盘重写。Tracker 全程跟踪进度，用共享状态里的 full_plan 清单实时更新完成状态，让 Supervisor 随时知道任务走到哪一步。
防护机制还有两层。SummarizingConversationManager 负责溢出预防，当对话历史接近窗口上限时自动摘要压缩，而不是等报错。选择性 prompt caching 则在保证命中的前提下复用缓存，既管质量也管成本。
这一层要解决的不是“能不能跑完”，而是“跑得对不对、贵不贵”。前三层保证代理不崩，第四层保证代理不瞎。
四层合起来的真正含义
把四层放在一起看，才能看出 AWS 这套框架的野心。
它不是在教开发者怎么省 token，而是在重新定义生产级代理的构建方式。过去两年，行业的主流叙事是“窗口越大越好”——从 32K 到 128K 到 200K，厂商在窗口大小上内卷，开发者误以为窗口能解决一切。AWS 用 Deep Insight 的参考实现说：窗口只是原材料，上下文工程才是手艺。
这套框架的理论底座来自 Anthropic 的三篇工程文章：《Effective Context Engineering for AI Agents》《Code Execution with MCP》《How We Built Our Multi-Agent Research System》。但 AWS 没有停留在转载最佳实践，而是把它们编译进了 Strands Agents SDK——SummarizingConversationManager、prompt caching、agents-as-tools 模式，这些能力已经是 SDK 的内置功能，开发者不用自己造轮子。
这也是 Deep Insight 作为参考实现的价值：它把抽象原则变成了可审查、可复现、可扩展的代码。项目开源在 GitHub（aws-samples/sample-deep-insight），配套还有完整的 Workshop。开发者可以把它当成模板，往自己的领域里延伸。
生产代理的下一战
上下文工程只是开始。这个系列还有第三部分，讲怎么把 Deep Insight 从开发环境搬到生产环境：在 Amazon VPC 的私有网络里部署和运营代理，覆盖真实运维需要的一切。那才是生产化的深水区——安全、网络、权限、可观测性，每一样都比上下文更难缠。
但四层框架已经给出了一个可迁移的判断：生产级代理的竞争，不会停留在模型智商，而会落到工程纪律。谁能把上下文切得够细、把内容外置得够彻底、把验证做得够独立，谁才能在长任务、高成本、高准确要求的场景里活下来。
200K 窗口不是解药，四层防御才是。当你的代理开始处理 15 分钟、15 万 token 的真实任务时，这句话会变成真金白银的账单。
快报