生产代理靠四层上下文管理，而不是更大的窗口

Lede

2026 年 11 月 4 日，Amazon Web Services 发布 Deep Insight 系列第 2 篇，用可运行代码说明生产级 AI 代理的四层上下文工程。200K token 窗口看似宽裕，一个“分析销售并写 DOCX”任务仍可在多阶段里烧掉超过 150K。文中可辩护的主张是操作方法。生产代理的失败，多半是上下文窗口管理失败；带可测 token 减量的四层栈（隔离、提示约束、外置、校验）优于只买更大窗口。 若代理设计冻结时，仅靠更大窗口就能打出文中约 95%、约 97% 的减幅并避免任务中途溢出，该主张即失败。

发了什么

Deep Insight 是基于 Strands Agents SDK 与 Amazon Bedrock AgentCore 的开源多代理数据分析方案。文章把 Anthropic 已公开做法与 Strands 能力收成四层。

第 1 层隔离上下文。Coordinator、Planner、Plan Reviewer、Supervisor 与工具代理（Coder、Validator、Reporter、Tracker、Auditor）各自保有窗口。代理只传压缩“线索”和简短完成通知，而不是全文对话。共享状态只有四项：上一代理最终消息、压缩线索、Planner/Tracker 清单、简短名字与消息历史。AWS 称在此层级下，最重的 Coder 总上下文也可压在约 25K token 以内。

第 2 层用提示约束流入。各代理有明确输出 token 预算（Coder 约 1,000–1,500，因为代码落盘）。提示要求脚本自包含，这样不必把旧变量留在上下文。Supervisor 须勾完当前清单项才能进入下一步。

第 3 层外置重内容。单一的写入并执行工具把脚本写入磁盘并运行，只回短摘要（行数、是否成功、截断后的标准输出），约 100 行代码不必进入消息流；相对回传全文，AWS 估计每脚本约少 95% token。常用函数收成可导入模块。结果写入 all_results.txt、calculation_metadata.json 等文件，供后续代理按需读取。Skills 在系统提示里只放约 500 token 的目录，调用时再加载约 3K 指南，而不是每轮塞入超过 20K 的技能正文；AWS 把这部分提示体积缩减约计为 97%。

第 4 层是校验代理与防护：Validator、Auditor 从文件独立核对计算与引用，给溢出和静默数值错误加第二道防线。

证据与缺口

硬数字来自 Deep Insight 参考实现，以及文中引用的 Anthropic 论述（窗口变长时的 context rot；另一篇 MCP 代码执行笔记中 150K→2K 一类服务端过滤说法）。代码开源，原则上可复现，但仍是厂商托管的工作实例，不是多现场随机对照。95% 与 97% 是对所示脚本与技能集的约数。Coder 低于约 25K 是 AWS 对该层级的陈述，不是对一切负载的保证。第 2 层预算可被不守规矩的模型忽略。文件外置把风险转到磁盘完整性、路径混乱，以及经检索文件注入提示。

钢人反驳。 更大窗口与更强长上下文模型会减轻一部分溢出。把已知技巧收成四层并开源，相对 Anthropic 原文可能增量有限。在冗长分析代理上看起来很大的省 token，在短对话代理上会变小。校验代理要额外调用，还可能互相打架。

这些保留成立。它们并不抹掉方法骨架：把上下文当稀缺资源，用架构、提示、工具与校验去管，并在固定任务上公布前后 token。这直接打中“等更大窗口、却仍把整段脚本和技能手册塞进每一轮”的习惯。

谁买单，看什么

做多步分析或报告代理的团队，应在批准换模型前先按阶段统计 token。平台组应优先写入并执行与按需 Skills，而不是常驻巨型系统提示。采购方应要“有无外置”的每任务 token 表，而不是只听“支持 200K 上下文”。

接下来看：第三方能否在公开任务上复现约 95%/97% 减幅；系列第 3 篇的 harness/VPC 指引是否改写成本曲线；文件总线是否会像编排-工人博文一样成为标配。

收束

AWS 可用的句子不是 Deep Insight 发明了上下文工程，而是：代理可靠性会在团队按四层计量并削减上下文、并把更大窗口当作最后杠杆时复利。 六个月后，要么更多团队用开源 harness 公布分阶段 token 表，要么行业继续买更长上下文，去盖住同一种任务中途溢出。