生产 AI 代理的上下文工程

当生产 AI 代理处理数据分析、报告生成等任务时，上下文管理可能成为主要瓶颈。 20 万个 token 的窗口听起来很慷慨，但现实中的任务几分钟内就会将其消耗殆尽。 数据分析和报告生成会导致代理在执行中途失败，降低准确性或增加成本。 虽然已有已发布的指导方针，但单独的技术比应用它们更容易阅读。 当它们一起应用时，它们会产生可衡量的差异：在本帖中逐步介绍的参考实现中，单个写和执行工具将每个脚本添加到上下文的 token 数减少了约 95%，按需加载技能将系统提示减少了约 97%。

本系列将指导方针组织为可以直接应用的做法。 Anthropic 的工程帖子与 Strands Agents SDK 中构建的功能相结合，形成了上下文工程的四个层次：在架构级别隔离上下文，通过提示控制它，将其外部化到文件系统，并使用独立的代理和防护措施进行验证。 在本帖（第 2 部分）中，您将学习每一层是如何工作的，以及它在工作代码中是什么样子。

我们将这些技术应用于 Deep Insight，这是一个基于 Strands Agents SDK 和 Amazon Bedrock AgentCore 的开源多代理数据分析解决方案，它作为整个过程中的参考实现。 第 1 部分：多代理系统中的 5 个生产挑战以及 Deep Insight 如何解决它们。 第 2 部分：生产 AI 代理的四个层次上下文工程：Deep Insight 如何在工作代码中应用它们。 第 3 部分：实践中的工程：将 Deep Insight 从开发迁移到生产。 （即将推出！

）第一帖定义了生产多代理系统必须解决的五个核心挑战。 它介绍了 Strands Agents SDK、Amazon Bedrock 和 Bedrock AgentCore 如何分别解决不同层次的问题，并提供了代码示例。 第二帖介绍了构建在架构之上的四个层次上下文工程实践，并展示了每个实践的具体实现。 第三帖将指导您在 Amazon 虚拟私有云（Amazon VPC）上的安全私有网络上部署和操作代理，涵盖了一切实际操作所需的内容。

什么是上下文工程？上下文工程是优化大型语言模型（LLM）有限上下文窗口中信息的学科，以便代理能够发挥最佳性能。Anthropic Claude Sonnet 4.5 在 Amazon Bedrock 上提供 200K 的上下文窗口，但复杂的生产任务很快就会超过它。例如，一个看似简单的请求，如“分析销售数据并创建 DOCX 报告”，会经历几个阶段：数据加载和探索（5 分钟）、基于类别的销售分析（3 分钟）、为时间序列分析生成五个图表（10 分钟）、统计验证（3 分钟）和最终报告生成（5 分钟）。总共它们在 15 分钟内消耗了超过 150K 个 token。在单个上下文中处理这些任务会导致问题：任务中途窗口溢出，过时的上下文降低性能，错误需要重新运行整个管道。随着上下文的增长，对重要信息的关注下降，并且在每 token 定价下，低效率会提高成本。

“随着上下文窗口中 token 数量的增加，模型准确回忆该上下文中信息的能力会下降（上下文腐烂）。”—— Anthropic，《有效 AI 代理上下文工程》（2025 年 9 月）

上下文工程解决了这些问题，它不仅仅是一系列技术。跨越架构设计、提示编写、工具实现和验证，它是一个分层的学科，每一层都弥补了前一层所遗漏的内容。本帖详细介绍了您可以应用的四层方法，以有效管理上下文。