AWS 四层上下文工程 智能体 token 降 95%

时间：2026年11月4日，AWS 机器学习博客发布技术文章 Four layers of context engineering for production AI agents，讲清楚了开源项目 Deep Insight 如何把四层上下文工程落到可运行的代码上。 地点：美国华盛顿州西雅图 AWS；开源项目 Deep Insight，代码托管在 AWS 官方示例仓库 aws-samples/sample-deep-insight。 人物：文章作者 Yoonseo Kim；开源项目 Deep Insight 的开发团队；文中方法来源为 Anthropic 的工程博客与 Strands Agents SDK 的内置能力。 事件详情：AWS 把散落在 Anthropic 工程博客和 SDK 文档里的上下文管理技巧，收敛成四层，并逐层给出 Deep Insight 中的实现方式。第一层是架构隔离，每个智能体运行在自己的隔离执行环境里，只在自己的上下文内工作，避免一个任务的上下文污染另一个任务；Deep Insight 直接使用 Strands Agents SDK 原生的 agents-as-tools 模式，不需要自己实现调度。第二层是提示词约束，在提示词里写入输出控制规则，限制模型能摄取和返回的信息量，例如要求 Coder 写的脚本自包含、变量不跨脚本继承，Supervisor 必须等当前清单全部标记完成才能进入下一个智能体。第三层是工具层外置，把脚本、数据文件和生成的图表写进文件系统，智能体上下文里只保留路径指针；Deep Insight 把写文件与执行两步合并成一个 write_and_execute_tool，工具执行完只回传几行摘要，代码本身从不进入上下文，这一项把每个脚本带进上下文的 token 数量减少约 95%；按需加载技能时，智能体启动只加载约 500 token 的技能目录，而不是超过两万 token 的完整指南，系统提示词因此缩减约 97%。第四层是验证，由独立的验证智能体复核结果并加上防护措施，因为前三层之后各智能体互相看不到彼此的工作，Coder 一旦算错，Reporter 就会把错误带进报告；这里用 Strands Agents SDK 的 SummarizingConversationManager 作为防溢出的最后一道安全网，并按智能体分别开启提示词缓存，重复调用时输入 token 成本最多下降 90%，计划的复核环节则是收集用户确认的人工步骤，不调用模型。 背景：上下文工程指的是在模型有限的上下文窗口里优化信息投放，让智能体保持在最佳状态。文章指出，在 Amazon Bedrock 上可用的 Anthropic Claude Sonnet 4.5 提供 20 万 token 的上下文窗口，但一个看似简单的分析销售数据并生成 DOCX 报告的任务，几分钟内就会烧掉窗口的大部分。多智能体系统里每个智能体都用自己的上下文工作，单体式的大提示词很快触顶，随着上下文变长，模型的召回能力会下降。所谓上下文腐化，指的正是这种被反复提到的现象。Deep Insight 是构建在 Strands Agents SDK 和 Amazon Bedrock AgentCore 之上的开源多智能体数据分析方案，代码在 AWS 官方的 aws-samples 仓库里对所有人开放。 影响：这篇文章给的是可以直接照搬的工程动作，而不是概念。四层里最有价值的是第三层，把重内容挪出上下文比缩短提示词收益大得多，一次工具设计改动就能砍掉九成以上的上下文 token；技能按需加载同样值得抄，目录化的做法比把完整指南全塞进系统提示词省得多。提示词缓存那一段则把上下文工程的收益从省 token 延伸到了降成本，重复调用场景下的输入成本最多降九成。验证层补上了前三层留下的漏洞，隔离之后的智能体互相看不见对方的产出，必须有人复核，代价是多了执行路径和延迟。部署上，参考实现把每个智能体放进独立容器执行，隔离了故障范围，也把存储权限与生命周期策略变成新的运维项。整体来看，这是一篇给已经在做多智能体的团队准备的文章，尤其是那些提示词越写越长、上下文快撑爆的流水线。 总结：AWS 把上下文管理从零散技巧收敛成了一套四层框架，并配上了能直接跑的开源代码。四层里最见效的是工具层外置，一个 write_and_execute_tool 就把每个脚本的上下文开销压掉约 95%。架构隔离解决的是相互污染，提示词约束解决的是输出失控，验证层则负责兜住隔离之后没人看见彼此工作的风险。四个数字可以当验收标准看：脚本 token 降约 95%，系统提示词降约 97%，重复调用的输入成本最多降 90%，而 20 万 token 的窗口在真实分析任务面前依然几分钟就会被烧穿。对做智能体应用的团队来说，这套做法的可复制性远高于概念价值。 常见问题： 问：上下文工程和提示词工程有什么区别？ 答：提示词工程关注怎么写好一条提示词，上下文工程关注在模型有限的上下文窗口里怎么投放信息，包括架构隔离、提示词约束、工具外置和独立验证四层。 问：上下文工程是谁提出的？ 答：这篇 AWS 文章把 Anthropic 工程博客的做法与 Strands Agents SDK 的内置能力收敛成四层，没有提出新概念，参考实现是开源项目 Deep Insight。 参考来源： AWS 机器学习博客：Four layers of context engineering for production AI agents https://aws.amazon.com/blogs/machine-learning/four-layers-of-context-engineering-for-production-ai-agents-how-deep-insight-applies-them-in-working-code/ AWS 官方示例代码仓库 aws-samples：Deep Insight https://github.com/aws-samples/sample-deep-insight AI导航：Four layers of context engineering for production AI agents 全文 https://ai-tokens.cn/news/news-d2290c5d3e5ab011.html Today for AI：Deep Insight Open-Sources Four-Layer Context Engineering for Agents https://todayforai.com/en/items/art-764f89f3-e40 CloudNinjas：Implementing Four-Layer Context Engineering for Production AI Agents https://cloudninjas.ca/ai/implementing-four-layer-context-engineering-for-production-ai-agents-with-deep-insight/ The Wire：AWS Machine Learning 栏目 Four layers of context engineering https://thewire.ink/sources/aws-ml