用四层上下文设计构建生产级智能体

AWS ML Blog 以开源多智能体数据分析方案 Deep Insight 为例，介绍如何用四层上下文设计组织生产级智能体。它基于 Strands Agents SDK 和 Amazon Bedrock AgentCore，讨论的重点是：分析数据、执行代码、生成报告时，怎样控制进入模型的信息，避免任务越跑，上下文越臃肿。

目前能确认什么

上下文工程管理的是大语言模型每次执行任务时能看到的信息。窗口容量有限，把历史对话、脚本和工具结果持续塞进去，可能挤占后续步骤的空间，也会增加模型处理的信息量。

文章将实践分成四层：

• 架构层：给不同智能体独立的上下文，只向协调者传递压缩结果。
• 提示词层：控制提示词内容，按需加载 skills。
• 文件与工具层：将信息外置到文件系统，并通过工具控制交互。
• 验证层：引入独立智能体与防护机制检查结果。

节选给出了架构层的具体做法：共享状态只保存上一智能体的最终消息、压缩摘要、任务清单和简短日志，不传完整对话。

作者还报告，在参考实现中，写入并执行脚本的单一工具让每个脚本新增的上下文 token 减少约 95%，按需加载 skills 让系统提示词缩小约 97%。这两个比例衡量的是特定上下文开销，不能直接当成整体成本或准确率的改善幅度。

我的判断

对正在做数据分析 Agent 的程序员，最有参考价值的是交接协议：下一个智能体究竟需要哪些结果，哪些内容应该留在文件里。拆出多个 Agent 后，如果仍然转发完整历史，上下文隔离就很难发挥作用。

压缩也有代价。摘要若漏掉数据口径、异常记录或执行失败信息，后续报告可能沿着错误继续生成。因此，验证机制需要检查哪些证据、能否追溯原始产物，比多设一个 Validator 角色更关键。

目前节选尚未展示文件工具和验证层的完整实现，也没有交代上述降幅的测试范围。能确认的是一套组织方法；它在不同任务上的收益，还缺少足够信息判断。