Agentic AI基础设施实践经验系列（九）：Context Engineering 上下文工程

在本文中，我们将介绍上下文工程在Agent应用的场景与实践，结合AWS Bedrock AgentCore, Strands Agents等能力，构建起具有从上下文检索与生成，上下文处理到上下文管理的完整框架，帮助企业实现兼具成本，性能与扩展性的新一代智能体。

1. 上下文与上下文工程的基本概念

随着大语言模型技术的快速发展，AI正从简单的文本生成工具演进为具备自主决策和行动能力的智能体（Agent）。现代Agentic AI不仅能理解和生成文本，还具备任务分解、工具调用、多步推理等复杂能力，能够主动规划并执行复杂任务。

这一演进带来了上下文复杂度的指数级增长。传统对话系统只需维护简单的对话历史，而 Agent 系统需要管理工具定义、执行历史、推理链、多 Agent 协作等大量上下文信息。一个复杂任务可能产生数百条上下文记录，直接导致成本激增、性能下降和可扩展性受限等问题。正是在这样的背景下，上下文工程（Context Engineering）作为专门解决 Agentic AI 时代上下文管理挑战的技术方法论应运而生。

1.1 上下文的作用与范式转变

基于大语言模型的聊天应用中的上下文

在传统的基于大语言模型的聊天应用中，模型本身实际上是无状态的。这里所说的”状态”特指对话历史、系统设定等上下文信息。大模型并不会主动保存这些状态数据，而是完全依赖应用层来维护。从模型的视角来看，这些由应用传递进来的历史信息就构成了它的上下文（Context）。

这类对话应用在上下文管理上呈现出一个简单而清晰的模式：大模型作为纯粹的推理引擎，不记住任何历史信息；应用层负责维护完整的对话历史；每次向模型发起请求时，都需要携带完整的上下文。如图一所示，多轮对话的上下文在聊天应用中通常以会话级别的数据结构进行存储，每条消息都包含角色标识和内容，形成一个有序的消息队列。

图1：聊天应用中的上下文

Agentic AI应用的上下文范式

当应用场景从简单的对话系统演进到 Agentic AI 时，上下文管理的复杂度发生了质的变化。Agentic AI 具备任务分解、多步骤执行、自主思考和工具调用等高级能力，这些能力的实现都依赖于更加丰富和复杂的上下文结构。

单Agent场景

在单 Agent 架构中，除了继承原有对话系统的基础上下文，还新增了多个关键模块。首先是工具定义被集成到 Context 中，Agent 需要知道自己可以调用哪些工具以及如何调用。其次，每一次工具调用的完整历史都需要被记录下来，包括请求参数和返回结果。此外，系统还需要支持多步骤的推理链存储，以及复杂任务的分解执行过程。

让我们用一个具体例子来理解这种上下文增长的量级。假设一个任务被 Agent 分解成了 10 个子任务，每个子任务需要调用两次工具才能完成。那么这个大任务总共会产生 41 条新增的上下文记录：1 条初始的任务分解思考，加上 10 个子任务各自产生的 4 条记录（1 次工具调用请求 + 1 次工具调用返回，重复两次）。这种指数级的增长对上下文管理提出了全新的挑战。

多Agent场景

在多 Agent 系统中，问题变得更加复杂。每个 Agent 都需要持有上述单 Agent 所拥有的完整上下文模块，而多个 Agent 之间还需要进行协作和信息共享。这导致整个系统的上下文总量呈现倍增关系。如图二所示，多 Agent 场景下的上下文规模出现了显著的膨胀，每个 Agent 不仅要维护自己的工作上下文，还可能需要了解其他 Agent 的执行状态和结果。

图2：多Agent场景下的上下文

1.2 上下文管理面临的挑战

随着 Agentic AI 应用的复杂度提升，上下文管理面临着一系列严峻的挑战。最直接的问题是模型上下文窗口的物理限制。即使是支持超长上下文的模型，在处理诸如 500 页 PDF 文档这样的大规模内容时，也无法将全部信息一次性加载到上下文中。代码助手和文档助手这类 Agent 如果不加以控制，很容易就会突破模型的上下文容量上限。

更长的上下文还带来了成本压力。大模型的定价通常与处理的 token 数量成正比，过长的上下文会大幅增加每次调用的成本。在高频交互的场景下，这种成本累积会变得不可忽视。

从用户体验角度看，还存在个性化偏好保存的需求。当用户多次访问应用时，如何保存和利用用户的历史偏好，在降低上下文冗余的同时提供个性化服务，这需要更智能的上下文管理策略。

最后，也是最容易被忽视的一点，是性能和准确率的隐性下降。多步工具调用和多轮对话导致的过长上下文不仅会降低模型响应速度，还可能引发”Lost in the Middle”问题——模型在过长的上下文中迷失方向，无法准确捕捉关键信息，从而影响推理准确性。

1.3 上下文相关问题的归纳与分析

上述一系列上下文相关的问题和挑战促使业界开始思考 Agent 应用应该如何才能更好地管理上下文。一个理想的场景是在每一次执行完成、需要新增上下文时，都能针对当前任务对现有上下文进行优化。这种优化可能是保存 metadata 信息，并将实际的完整内容外置到外部存储中；也可能是采用某种上下文压缩技术。这些针对上下文的处理使得每一步使用的上下文都是综合考虑成本、效率、准确性之后的最优选择。

如图3所示，从动态视角展示了在 Agent 平均多达 50 步的执行过程中，系统如何不断动态地优化上下文，以便每一步都可以输出最佳结果。上下文优化器（Context Optimizer）当前主要以工程化实现为主，未来演进方向可能是模型驱动的优化器，该优化器根据当前用户输入、任务目标和模型状态决定是否进行压缩、采用何种压缩策略、丢弃哪些内容、存储为记忆，以及何时进行记忆回填等操作。

图3：上下文优化器

1.4 上下文工程的定义

近年来，随着 Agentic AI 应用的快速发展，业界逐渐形成了对上下文工程的系统性认识。上下文工程被定义为一种通过动态管理输入到大模型（LLM）上下文窗口的信息，优化其推理和决策能力的技术框架。其核心目标是解决传统提示工程的局限性，特别是 AI 智能体的上下文缺失或信息不当问题，在实现精准填充上下文窗口的同时达到降本增效的目的。

上下文工程与传统的 Prompt Engineering 有着本质区别。传统提示工程通过静态字符串输入，无法处理动态多源信息，如实时数据、历史状态、工具接口等。它侧重于如何组装和表述上下文，强调单次输出的结果，在长文本场景下往往表现不佳。

相比之下，上下文工程将上下文视为动态结构化组件的集合，通过显式记忆管理和模块化组合，强调在动态数据输入环境下构建健壮的系统，而不仅仅是优化静态提示。它关注的是整个信息流的生命周期管理——从信息获取、过滤、存储、检索到最终的上下文组装，形成一个完整的工程体系。

根据《上下文工程综述》的研究，图4展示了智能体架构的演进路径，从基础 RAG 系统到复杂的多智能体架构和工具集成推理系统，上下文工程的理念贯穿始终，逐渐成为支撑这些先进应用的核心方法论。

图 4：从基础RAG系统到复杂的多智能体架构和工具集成推理系统的演进过程

1.5 上下文工程的必要性

上下文工程强调对模型信息环境的整体构建——既要包含任务必需的全部关键信息，又需避免冗余内容导致的注意力分散与成本增加。

从信息构建的维度来看，上下文工程突破了传统提示词工程因注意力机制不足而产生幻觉的限制。通过增强的 RAG 检索系统，能够显著提升文本导航的准确率，增强 Agent 对于复杂推理的能力。结构化的上下文管理使得模型能够更好地理解任务需求，保持推理链的连贯性，从而提供更加准确和可靠的输出。

从成本控制的维度来看，上下文压缩技术能够显著减少 token 消耗，高效处理长文本，大幅度降低当前多智能体应用产生的计算开销问题。在云端部署大模型应用时，这种成本优化直接影响到服务的经济可行性和商业竞争力。

综合来看，上下文工程不仅是技术优化的手段，更是构建可持续、可扩展 AI 应用的基础方法论。它为 Agentic AI 应用在性能、成本和准确性之间找到最佳平衡点提供了系统化的解决方案。

2. 上下文工程构成

2.1. 内容构成

上下文工程由输入、记忆和输出三大部分组成。输入包括系统指令、外部知识检索、工具定义、全局状态和用户输入，为模型提供任务背景和所需信息。记忆部分分为长期记忆和短期记忆，用于存储和召回历史信息。输出则包括工具执行的结果和模型生成的结构化内容。这些组件共同协作，构建一个丰富的上下文环境，以支持LLM完成复杂任务。

图 5 上下文工程内容构成

2.2. 核心组件

上下文工程是一种系统化构建、处理并动态管理上下文信息，以驱动大型语言模型实现精准推理与决策的先进架构。其核心组件包括上下文检索与生成，上下文处理与上下文管理三个部分，其工作流是一个动态迭代的闭环过程。

图6 上下文工程核心组件概览

首先，系统接收用户输入、系统指令与知识库信息作为原始素材，通过上下文检索与生成动态获取并组装多源信息，构建出任务相关的增强上下文（由RAG系统实现），并在此过程中初始化与更新记忆系统（含全局状态、短期与长期记忆）。

进而，通过上下文处理获取相关上下文信息，对增强后的长序列上下文进行结构化整合与深度推理，在此过程中，记忆系统与工具集成模块协同工作，通过调用外部工具与迭代优化，生成结构化输出并持续反哺记忆与工具模块。

最终，上下文管理作为中枢，在多智能体系统的协调下，对全流程中的信息（包括原始输入、记忆与工具）进行高效的组织、压缩与调度，以优化资源利用并确保响应质量。整个架构并非单向线性，而是通过多轮次的迭代与优化，实现上下文生命周期的系统化与动态化管理，从而为复杂Agent提供可靠、高效且可进化的核心支撑。

2.2.1 上下文检索与生成

这一模块对应 RAG 系统的核心功能，通过提示词工程、外部知识检索和动态上下文组装获取适当的的上下文信息，主要解决了信息源适配的问题，在这一阶段，关键任务是如何从多源信息中筛选出与当前问题相关的内容，确保AI有正确的材料来完成任务。

首先基于CLEAR原则（简练性、逻辑性、明确性、适应性、反思性）构建结构化指令框架，明确输出目标与推理路径。

当任务涉及超出模型参数化知识的领域（如实时数据或专业信息）时，系统激活外部知识检索组件。

外部知识检索通过检索增强生成（RAG）架构动态连接知识图谱、数据库等外部信源，其中Self-RAG机制智能决策检索时机，知识图谱系统则保障信息权威性与关联性。

这个过程对检索到的信息进行多维度的优化：通过优先级排序提取核心数据，利用自然语言表述将结构化数据转化为 LLM 可解析的格式，通过多 Agent 协作和压缩技术在保障回复质量的前提下控制上下文长度。在这个过程中，可以通过 LangChain 等工具链实现自动化数据清洗与格式转换，确保信息适配模型处理要求。

三组件形成闭环优化系统：提示工程定义的检索过程引导了知识获取的范围，外部检索结果的质量反馈至提示模块进行指令校准，而组装输出的上下文有效性则通过自迭代优化进行多轮修订。当LLM输出未达预期时，系统回溯到问题环节，若因信息缺失则强化检索策略，若因表述模糊则优化提示设计，若因整合混乱则重组上下文结构。这种协同机制在保障信息时效性与准确性的同时，显著降低幻觉风险。

2.2.2 上下文处理

这一模块对应记忆系统（Memory Systems）和工具集成推理（Tool-Integrated Reasoning）的功能，通过长序列优化、自优化机制、多模态融合、结构化集成四大技术方向，解决LLM处理海量信息的核心挑战。核心任务是将原始上下文转化为高效、鲁棒以及任务适配的语义表示，具体实现路径如下：

长序列优化首先解决基础计算瓶颈：状态空间模型（SSM）维持线性计算复杂度，位置插值技术，如LongRoPE将上下文窗口扩展至2048K token，StreamingLLM 通过关键token保留机制支持无限长流处理，为后续处理环节提供可计算的压缩序列。

自优化组件随即对序列进行语义精炼：Self-Refine框架使模型兼具生成与校验功能，实现闭环修正，长思维链（LongCoT）扩展推理深度，动态长短推理（Auto Long-Short）按问题复杂度自适应调整步长，输出优化后的内容。

多模态融合接收精炼文本并扩展信息维度：视觉提示生成器（VPG）将图像映射至文本空间，跨模态注意力机制建立图文细粒度关联，链接上下文学习（LCL）通过显式因果链演示抑制模态偏差，形成统一的多模态表示。

结构化集成最终注入逻辑验证框架，输出可验证的上下文。综上所述，对上下文的处理本质上是计算载体（长序列）、质量引擎（自优化）、信息扩展（多模态）、逻辑验证（结构化）的功能闭环。

2.2.3 上下文管理

这一模块对应多智能体系统（Multi-Agent Systems），旨在优化大语言模型中信息的组织、存储与利用，以应对有限上下文窗口的约束，构建高效的内存架构，并通过压缩技术提升信息密度，实现上下文高效管理。

这一组件需要解决三个核心挑战：首先是严格的记忆容量约束，传统Transformer架构在处理长文本时会产生平方级增长的计算开销；其次是显著的信息提取偏差，模型对文本中段内容的理解能力明显弱于首尾部分；最后是固有的无状态特性，模型默认不会保留跨对话的历史信息。

为了应对这些挑战，研究者开发了多层次的解决方案。在存储架构方面，借鉴计算机操作系统的虚拟内存概念，采用分层记忆设计将关键信息保留在快速访问区域，同时支持外部存储扩展。基于艾宾浩斯遗忘曲线的动态记忆机制能够智能调整信息留存强度，高频使用的内容获得更强记忆权重。

同时，先进的压缩算法可将长文本提炼为原大小四分之一的精华内容，通过双层存储结构同时保存全局概览和细节数据。分布式计算框架的引入使得处理百万级 token 的超长内容成为可能。典型的应用案例包括

2.3. 系统实现

2.3.1 检索增强生成（RAG）

典型的检索增强生成框架包括模块化 RAG、智能体 RAG 和图增强 RAG，主要应用于动态检索策略、低延迟优化、增量索引等场景中，用于集成内部和外部的上下文系统。

图7 检索增强生成框架:包括模块化RAG、主体RAG系统和图增强RAG方法用于集成外部上下文的RAG系统架构概览

模块化 RAG 通常采用分层架构设计，将整个检索增强生成流程分解为多个专业模块。典型代表包括 FlashRAG 和 ComposeRAG 等框架，它们通常构建三层结构：顶层负责协调完整的 RAG 流程，中层管理各个功能子模块，底层则包含具体的操作单元。这种设计的核心优势在于能够动态重组工作流程，通过智能路由模块和灵活的调度机制，根据不同的查询需求自动选择最合适的处理路径。

智能体 RAG 将自主 AI 智能体整合到检索增强生成流程中，实现了基于持续推理的动态操作。这种设计充分利用反思、规划、工具使用和多智能体协作等机制，通过多模态感知、工具使用和外部记忆集成，基于 LLM 的自主智能体扩展了传统语言模型的能力边界。以 Self-RAG 为代表的自优化框架能够根据任务复杂度自动调整检索深度和范围，而 PlanRAG 等系统则进一步具备任务分解和规划能力，使得检索过程更加智能化和针对性。

图增强 RAG 将关注点从简单的文档导向转向复杂的结构化知识表示。通过引入图结构来提升检索质量，这类智能体擅长处理需要多步推理的复杂查询。GraphRAG 和 HippoRAG 等框架利用知识图谱的结构化特性，能够沿着实体关系路径进行多跳检索，挖掘深层次的关联信息。更先进的 GNN-RAG 还集成了图神经网络技术，通过分析图中节点间的复杂关系模式，显著提升了实体关系捕获的准确性和完整性。

2.3.2 记忆系统（Memory Systems）

记忆系统通过实现持续性的信息存储、检索和利用机制，使大语言模型能够突破无状态交互的限制，将模型从单纯模式匹配的处理器转变为具备学习能力、适应性和长期上下文理解能力的智能体。记忆系统主要由三大核心模块构成：记忆架构、记忆增强型智能体以及评估与优化机制。

在记忆架构方面，系统采用分层设计来模拟人类记忆过程。短期记忆通过上下文窗口实现，作为工作记忆维持对近期处理内容的快速访问。长期记忆则依托外部存储系统，突破模型固有上下文窗口的限制。现代记忆系统实现了多种存储形式：参数化记忆（模型权重中编码的知识）、临时激活记忆（会话期间的运行时状态）以及通过检索增强生成访问的明文记忆。代表性框架包括 Mem0、Letta，以及 Amazon Bedrock Agent Core Memory。

记忆增强型智能体通过整合短期与长期记忆系统，充分适应上下文环境。典型架构如 MemOS 将记忆分为参数记忆、激活记忆和明文记忆三类，而 SCM 框架则通过记忆流和记忆控制器来管理信息更新与利用。

当前主要瓶颈包括缺乏标准化评估基准、难以区分记忆机制与推理能力的界限，以及实验室环境与真实场景的差距。未来发展方向聚焦于混合记忆框架的探索，结合参数化记忆的精确性与非参数化记忆的高效性。创新路径包括基于认知科学的记忆巩固机制、低秩适应等参数高效更新技术，以及支持多智能体协作的共享记忆系统。

图8 记忆系统框架:长文本模型中用于超长上下文处理的记忆架构、增强记忆的智能体和评估挑战概览

2.3.3 工具集成推理（Tool-Integrated Reasoning）

工具集成推理系统让语言模型从单纯的文本生成升级为能够主动使用外部工具解决问题的智能体。这一技术突破主要包含三个关键部分：首先是基础工具调用能力，让模型学会使用计算器、搜索引擎等常见工具；其次是任务分解与执行能力，将复杂问题拆解为适合工具处理的子任务；最后是实时交互能力，根据工具返回结果动态调整解决方案。

当前主流实现方式有两种：一种是模型微调方法，通过大量工具使用示例训练模型，效果稳定但成本较高；另一种是提示工程方法，通过精心设计的指令引导模型使用工具，成本低但稳定性稍差。无论哪种方法，系统工作时都会经历” 分析问题-选择工具-执行操作-整合结果 “的标准流程。

未来发展方向包括让模型自主探索工具的创新用法，支持多个智能体协同使用工具完成任务，以及将工具使用经验形成长期记忆等。这些进步将进一步提升语言模型解决实际问题的能力，拓展其应用场景边界。

图9 工具增强系统框架:通过函数调用机制、工具集成推理和环境交互能力,从文本生成器演化为能与现实互动的系统

2.3.4 多智能体系统（Multi-Agent Systems）

多智能体系统（MAS）正在重塑人工智能解决问题的基本范式。通过协调多个自主智能体的工作，突破了单一智能体的能力边界，在复杂任务处理上展现出独特优势。从技术架构来看，现代MAS主要依赖三大核心组件：标准化的通信协议确保不同架构智能体间的无缝对接，智能化的编排机制实现任务的动态分配与调度，以及精细化的协同策略保障系统运行的稳定性。

在通信协议层面，系统采用 MCP（模型上下文协议）、A2A（智能体间通信）和 ANP（网络互操作）等标准化方案，为异构智能体提供互联基础。协调机制则通过先验协调与后验协调相结合的方式实现任务优化。其中先验协调进行预执行分析，后验协调则对并行响应进行评估。同时借助 SagaLLM 等框架的事务完整性保障，通过补偿机制和独立验证确保系统可靠性。这些技术已在医疗分诊代理、网络管理中的上下文感知协调等场景中得到成功验证，展现出多智能体协同的实践价值。

图10 多智能体系统框架: Multi-Agent系统的通信协议、编排机制和协调策略

3. 上下文工程系统实践

上下文工程的实际落地需要完整的技术栈支撑，AWS在这一领域提供了从底层模型能力到上层应用部署的三个关键层级的工具链体系。

基础模型层：AWS通过Amazon Bedrock提供上下文工程的核心能力基础。Bedrock不仅提供Claude、Llama等主流大语言模型的推理能力，更重要的是通过Converse API的标准化接口、Prompt Cache的上下文缓存优化、以及原生的工具调用机制，为上层应用提供了高效的上下文处理基础设施。这一层解决的是”如何高效地与模型交互”的问题。

Agent框架层：AWS生态中的Strands Agents等轻量级框架专注于上下文的智能管理和应用。这些框架通过对话管理、记忆系统、工具集成等模块，将AWS Bedrock的原始模型能力封装为易于使用的Agent开发组件。这一层解决的是”如何构建智能的上下文管理机制”的问题，让开发者能够快速构建具备记忆、推理和工具使用能力的Agent应用。

Agent运行环境层：AWS通过Amazon Bedrock AgentCore提供企业级的部署和运营保障。AgentCore套件包含Memory（记忆管理）、Gateway（工具网关）、Runtime（运行时）、Identity（身份认证）、Observability（可观测性）等完整服务，确保Agent应用能够在AWS云环境中稳定、安全、可扩展地运行。这一层解决的是”如何将Agent应用安全可靠地部署到生产环境”的问题。

这三个层级相互依托，构成了AWS在上下文工程领域的完整技术能力，为开发者提供了从概念验证到生产部署的全链路AWS原生解决方案。

一个典型的上下文智能体解决方案示意图如下，基础模型层通过AWS Bedrock提供的模型（如Claude系列模型）实现核心的推理和连续对话能力，Agent框架层以Strands Agents为核心，集成Prompt Cache、Tools和多轮对话管理机制，负责处理用户query并维护对话连贯性，Agent运行环境层则由Bedrock Agentcore Runtime提供统一的运行环境，负责生命周期管理、组件协调和上下文优化策略的执行，同时结合Bedrock Agentcore Gateway管理协调多种工具增加系统的完整性。这三层通过紧密配合，实现了从用户输入到系统响应的完整上下文处理流程，确保了对话系统的连续性和智能性。

图11 基于Agentcore的上下文工程实践Agent架构

3.1 基础模型-Bedrock

Amazon Bedrock是AWS提供的完全托管服务，让开发者能够通过API访问来自Amazon和领先AI公司的基础模型（Foundation Models）。Bedrock不仅提供了Claude、Llama等主流大语言模型的访问能力，更重要的是围绕这些模型构建了完整的企业级AI应用开发生态。

在上下文工程领域，Bedrock 提供了多项关键能力：通过 Converse API 实现标准化的上下文结构管理，通过 Prompt Cache 优化重复上下文的处理成本，以及通过 AgentCore 套件提供企业级的 Agent 开发和部署平台。这些能力使得开发者能够构建具备长期记忆、工具集成和多智能体协作的复杂 AI 应用，同时享受 AWS 云服务的安全性、可扩展性和可靠性保障。

3.1.1 模型的context

对于LLM模型，输入结构遵循特定的组织方式，确保上下文信息能够被正确理解和处理。每次与模型的交互都是一个精心构建的上下文传递过程，因为模型本身是无状态的，不会记住任何历史信息。

根据 Amazon Bedrock 的 Converse API 规范，输入结构按特定顺序组织。工具配置（Tool Configuration）首先定义可用工具的 JSON Schema，包含工具名称、描述和输入参数规范，让模型知道可以调用哪些外部功能。系统提示（System Prompt）定义模型的角色、行为准则和基本指令，为整个对话设定基调和约束条件。消息历史（Messages）按时间顺序包含之前的用户输入和助手响应，维护对话的连续性和上下文一致性。当前用户消息（Current User Message）包含用户的具体请求或问题，是触发模型生成响应的直接指令。

以下是基于Amazon Bedrock的Converse API 工具调用示例：

// 工具配置
{
    "toolConfig": {
        "tools": [
            {
                "toolSpec": {
                    "name": "top_song",
                    "description": "Get the most popular song played on a radio station.",
                    "inputSchema": {
                        "json": {
                            "type": "object",
                            "properties": {
                                "sign": {
                                    "type": "string",
                                    "description": "The call sign for the radio station"
                                }
                            },
                            "required": ["sign"]
                        }
                    }
                }
            }
        ]
    },
    
    // 系统提示
    "system": [
        {
            "text": "You are a helpful assistant that can look up information about radio stations."
        }
    ],
    
    // 消息历史和当前用户输入
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "text": "What is the most popular song on WZPZ?"
                }
            ]
        }
    ]
}

这种结构化设计带来了显著优势。工具配置和系统提示在多次交互中保持稳定，可以被有效缓存，大幅降低计算成本和响应延迟。同时，这种组织方式确保了模型能够理解可用工具、明确角色定位、维持对话连续性，并基于用户输入响应当前请求。这种架构将上下文工程从简单信息拼接提升为认知架构构建，形成完整高效的信息处理系统。

Claude模型的工具使用系统提示构建

以Claude模型工具调用为例，当调用 API并传入tools参数时，系统会自动构建一个特殊的系统提示。这个构建过程展示了实际LLM如何处理工具定义和上下文组织：

In this environment you have access to a set of tools you can use to answer the user's question.

{{ FORMATTING INSTRUCTIONS }}
String and scalar parameters should be specified as is, while lists and objects should use JSON format. 
Note that spaces for string values are not stripped. The output is not expected to be valid XML and is parsed with regular expressions.

Here are the functions available in JSONSchema format:
{{ TOOL DEFINITIONS IN JSON SCHEMA }}

{{ USER SYSTEM PROMPT }}

{{ TOOL CONFIGURATION }}

这个模板清晰地展示了 Claude 如何将不同的上下文组件按特定顺序组合。系统首先声明工具环境的可用性，然后提供格式化指令确保工具调用的正确性，接着插入具体的工具定义（JSON Schema 格式），再整合用户自定义的系统提示，最后添加工具配置信息。这种自动化的提示构建机制确保了工具使用的一致性和可靠性，同时为开发者提供了灵活的定制空间。

3.1.2 Prompt Cache

Amazon Bedrock中的Prompt Cache是关键的上下文优化技术，通过缓存重复使用的提示内容显著降低推理延迟和成本。这对 Agent 应用尤为重要，因为 Agent 通常需要处理大量重复的系统提示、工具定义和历史对话。

工作原理与收益

Prompt Cache 通过创建缓存检查点（Cache Checkpoints）标记需要缓存的连续提示片段。当模型遇到已缓存内容时，直接从缓存读取而非重新计算。这带来三方面收益：缓存 token 收费比标准输入 token 低 90%，在 Agent 任务中输入输出比例高达 100:1 的场景下成本节省尤为突出；避免重复计算大幅提升响应速度；共享计算优化整体系统性能。

在实际应用中，以 Claude Code 等代码助手为例，稳定的 Agent 工作流中缓存命中率可达 90% 以上，整体推理成本可降低 80%。系统提示、工具定义和项目上下文等高度重复的内容特别适合缓存，使大规模 Agent 部署在经济上变得可行。

Agent 应用最佳实践

适合缓存的内容包括：系统提示（Agent 角色定义和行为准则）、工具定义（在多轮对话中基本不变）、对话历史摘要（长期对话的压缩信息）以及检索到的知识上下文（来自 RAG 系统的背景信息）。

缓存策略建议

建议采用滑动窗口缓存策略：将系统提示和工具定义设为永久缓存点，对话历史每隔 N 轮或新增 X 个 token 时滑动缓存点，确保缓存内容稳定以避免频繁失效。通过合理使用 Prompt Cache，Agent 应用可在保持高性能的同时显著降低运营成本。

以下是使用 Converse API 实现 Prompt Cache 的完整示例：

import boto3

bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock_runtime.converse(
    modelId='anthropic.claude-3-7-sonnet-20250219-v1:0',
    
    # 系统提示 - 设置缓存检查点
    system=[
        {
            "text": "你是一个专业的代码助手，擅长分析代码、提供优化建议和解决编程问题。请始终保持准确性和实用性。"
        },
        {
            "cachePoint": {"type": "default"}
        }
    ],
    
    # 工具配置 - 设置缓存检查点
    toolConfig={
        "tools": [
            {
                "toolSpec": {
                    "name": "code_analyzer",
                    "description": "分析代码质量和性能",
                    "inputSchema": {
                        "json": {
                            "type": "object",
                            "properties": {
                                "code": {"type": "string"},
                                "language": {"type": "string"}
                            },
                            "required": ["code", "language"]
                        }
                    }
                }
            },
            {
                "toolSpec": {
                    "name": "performance_optimizer",
                    "description": "提供代码性能优化建议",
                    "inputSchema": {
                        "json": {
                            "type": "object",
                            "properties": {
                                "code": {"type": "string"},
                                "optimization_type": {"type": "string"}
                            },
                            "required": ["code"]
                        }
                    }
                }
            }
        ],
        "cachePoint": {"type": "default"}
    },
    
    # 消息历史 - 包含缓存的上下文和当前请求
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": "项目上下文：这是一个Python Web应用，使用Flask框架，包含用户认证、数据处理和API接口模块。主要技术栈包括SQLAlchemy ORM、Redis缓存、Celery异步任务处理。项目结构如下：\n- app/\n  - models/\n  - views/\n  - utils/\n- tests/\n- requirements.txt"
                },
                {
                    "cachePoint": {"type": "default"}
                }
            ]
        },
        {
            "role": "assistant",
            "content": [
                {
                    "text": "我了解了您的Python Flask项目结构和技术栈。可以帮您分析代码质量、性能优化和最佳实践建议。"
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "text": "请分析这段代码的性能问题：\n```python\ndef process_data(data_list):\n    result = []\n    for item in data_list:\n        if item > 0:\n            result.append(item * 2)\n    return result\n```"
                }
            ]
        }
    ]
)

# 检查缓存使用情况
usage = response['usage']
print(f"缓存读取tokens: {usage.get('cacheReadInputTokens', 0)}")
print(f"缓存写入tokens: {usage.get('cacheWriteInputTokens', 0)}")
print(f"标准输入tokens: {usage.get('inputTokens', 0)}")

3.2 Agent框架——Strands Agents

Strands Agents是一个轻量级、代码优先的 Agent 构建框架，专为简化 Agent 开发而设计。它提供了生产就绪的解决方案，支持多种模型提供商和部署目标，默认集成 Amazon Bedrock 和 Claude 模型。框架的核心优势在于其简洁性——开发者只需几行代码就能创建功能完整的 Agent，同时保持了高度的可定制性和扩展性。Strands Agents 支持对话式和非对话式 Agent、流式和非流式响应，并内置了完整的可观测性、追踪和安全功能，使其成为企业级 Agent 应用的理想选择。观测性、追踪和安全功能，使其成为企业级Agent应用的理想选择。

3.2.1 Strands Agents对话管理

在 Agent 应用中，对话管理直接影响性能、成本和用户体验。随着交互进行，上下文信息不断累积，若不加管理会导致窗口溢出、响应延迟和成本上升。Strands Agents 提供三种对话管理模式，适应不同场景需求。

Strands Agents对话管理器提供三种对话管理模式，体现不同的设计理念和适用场景。

NullConversationManager 代表”完全保留”策略，适用于短期交互、调试环境或需要完整上下文分析的场景，特别是研究环境、问题诊断或有合规性要求的场景。

SlidingWindowConversationManager 体现”时间优先”理念，基于最近对话通常比历史对话更相关的假设，保持固定数量的最近对话轮次。

from strands import Agent
from strands.agent.conversation_manager import SlidingWindowConversationManager

# 为客服Agent配置滑动窗口管理
conversation_manager = SlidingWindowConversationManager(
    window_size=20,  # 保持最近20轮对话
    should_truncate_results=True  # 自动截断过长的工具结果
)

agent = Agent(conversation_manager=conversation_manager)

这种策略确保上下文大小可控，提供稳定的性能和成本，适合客服机器人、问答系统等任务导向的 Agent。

SummarizingConversationManager 代表”智能压缩”理念，通过总结保留历史信息精华而非简单丢弃，适合需要长期上下文理解的复杂应用，如代码助手或项目管理 Agent。

from strands import Agent
from strands.agent.conversation_manager import SummarizingConversationManager

# 为代码助手配置智能总结管理
conversation_manager = SummarizingConversationManager(
    summary_ratio=0.3,  # 总结30%的历史消息
    preserve_recent_messages=10,  # 保持最近10轮完整对话
)

agent = Agent(conversation_manager=conversation_manager)

当用户询问”之前讨论的性能优化方案是什么？”时，总结管理器能从压缩的历史摘要中提取相关信息，而非简单回答”不记得了”，特别适合代码助手或项目管理 Agent。

3.2.2 Strands Agents记忆管理

除了对话管理，Strands Agents记忆模块通过集成Mem0.ai提供了强大的持久化记忆能力，这是上下文工程在长期记忆维度的重要体现。与对话管理主要处理短期上下文不同，记忆管理解决的是跨会话的长期信息保持问题，让Agent能够真正”记住”用户的偏好、历史交互和重要信息。

Strands Agents 通过 hooks 机制提供了灵活的记忆管理能力，这是上下文工程在长期记忆维度的重要体现。与对话管理主要处理短期上下文不同，记忆管理解决的是跨会话的长期信息保持问题，让 Agent 能够真正”记住”用户的偏好、历史交互和重要信息。

Strands Agents 的 hooks 机制允许在 Agent 执行生命周期的特定节点注入自定义逻辑。对于记忆管理，核心是两个关键事件：MessageAddedEvent（消息添加时）和 AfterInvocationEvent（调用完成后）。通过监听这些事件，可以实现记忆的自动检索和存储，无需在业务代码中显式调用记忆管理 API。

from strands.hooks import HookProvider, HookRegistry, MessageAddedEvent, AfterInvocationEvent

class MemoryHookProvider(HookProvider):
    """通过 hooks 自动管理记忆的提供者"""
    
    def __init__(self, memory_client, memory_id: str):
        self.memory_client = memory_client
        self.memory_id = memory_id
    
    def retrieve_memories(self, event: MessageAddedEvent):
        """在用户消息添加时自动检索相关记忆"""
        messages = event.agent.messages
        if messages[-1]["role"] == "user":
            user_message = messages[-1]["content"][0].get("text", "")
            actor_id = event.agent.state.get("actor_id")
            
            # 基于语义相似性检索记忆
            memories = self.memory_client.retrieve_memories(
                memory_id=self.memory_id,
                namespace=f"/users/{actor_id}",
                query=user_message
            )
            
            # 将检索到的记忆注入到用户消息中作为上下文
            if memories:
                context = "\n".join([m['content']['text'] for m in memories])
                messages[-1]["content"][0]["text"] += f"\n\n相关历史: {context}"
    
    def save_memories(self, event: AfterInvocationEvent):
        """在 Agent 回复后自动保存对话"""
        messages = event.agent.messages
        if len(messages) >= 2:
            user_msg = messages[-2]["content"][0]["text"]
            assistant_msg = messages[-1]["content"][0]["text"]
            
            # 保存对话到记忆系统
            self.memory_client.create_event(
                memory_id=self.memory_id,
                actor_id=event.agent.state.get("actor_id"),
                session_id=event.agent.state.get("session_id"),
                messages=[(user_msg, "USER"), (assistant_msg, "ASSISTANT")]
            )
    
    def register_hooks(self, registry: HookRegistry):
        """注册记忆管理 hooks"""
        registry.add_callback(MessageAddedEvent, self.retrieve_memories)
        registry.add_callback(AfterInvocationEvent, self.save_memories)

# 创建带记忆管理的 Agent
memory_hooks = MemoryHookProvider(memory_client, memory_id)
agent = Agent(
    hooks=[memory_hooks],
    system_prompt="你是一个个性化助手",
    state={"actor_id": "user123", "session_id": "session456"}
)

这种 hooks 驱动的记忆管理体现了上下文工程的分层处理思想：检索阶段通过语义搜索快速定位相关记忆，注入阶段将记忆作为上下文补充到用户消息中，存储阶段自动保存新的对话内容。整个过程对业务代码透明，开发者只需关注 Agent 的核心逻辑。

在实际应用中，当用户说”记住我喜欢靠窗的座位”时，系统通过 save_memories hook 自动存储这个偏好。几天后用户询问”帮我预订机票”时，retrieve_memories hook 会自动检索到座位偏好信息并注入到上下文中，Agent 能够主动提醒用户选择靠窗座位。这种自动化的个性化服务正是现代 AI 助手的核心竞争力。

Strands Agents 的记忆管理可以与 Amazon Bedrock AgentCore Memory 无缝集成，后者提供了企业级的记忆存储、语义检索和多租户隔离能力。通过 hooks 机制，开发者能够将 AgentCore Memory 的强大功能以声明式的方式集成到 Agent 中，无需修改核心业务逻辑，实现真正的关注点分离。

3.3 Agent运行环境

Amazon Bedrock AgentCore是AWS推出的企业级Agent开发和部署平台，专为构建安全、可扩展的Agentic AI而设计。它提供了一套完整的模块化服务，包括Runtime（运行时）、Identity（身份管理）、Memory（记忆管理）、Code Interpreter（代码解释器）、Browser（浏览器工具）、Gateway（工具网关）和Observability（可观测性）等组件。AgentCore的核心优势在于其与开源框架的兼容性和企业级的安全性，开发者可以使用任何框架和模型，同时享受AWS提供的基础设施、安全性和可靠性保障。

3.3.1 AgentCore Memory记忆管理

Amazon Bedrock AgentCore Memory 是 AWS 原生的企业级记忆管理服务，通过双层记忆架构（短期与长期）解决了 Agent 应用中的关键上下文工程挑战：如何让 Agent 在保持高效性能的同时具备真正的”记忆”能力。作为完全托管的 SaaS 服务，AgentCore Memory 天然支持多租户架构和严格数据隔离，更适合企业级部署和严格合规场景，同时可与 LangGraph、CrewAI 等主流开源框架无缝集成。相比之下，Strands Agents 集成的第三方记忆服务（如 Mem0.ai）更适合快速原型开发和灵活定制场景。

AgentCore Memory 采用双层架构处理不同时间尺度的上下文需求。短期记忆存储对话交互以维护当前会话上下文。例如编程助手 Agent 在调试过程中会记录变量检查、语法修正等交互事件，使对话能连续进行而无需重复信息。短期记忆为长期记忆提供输入，支持多步骤任务完成和会话内知识积累。

长期记忆存储提取的洞察信息，包含三个关键组件。用户偏好记忆让 Agent 记住开发者的编码风格（如 snake_case 命名、pandas 数据分析偏好），在后续会话中自动遵循这些偏好。语义事实记忆积累领域知识（如”Pandas 是用于数据分析的 Python 库”），支持基于知识的智能推荐。摘要记忆生成会话概要（如”创建数据清理函数，修复语法错误，测试回归模型”），既跟踪工作进展又优化上下文窗口使用。

import boto3
from bedrock_agentcore.memory import MemoryClient

# 初始化AgentCore Memory客户端
memory_client = MemoryClient(region_name="us-west-2")

# 创建记忆实例
memory = memory_client.create_memory_and_wait(
    name="CodingAssistantMemory",
    strategies=[
        {
            "userPreferenceMemoryStrategy": {
                "name": "UserPreferences",
                "namespaces": ["/users/{actorId}"]
            }
        },
        {
            "semanticMemoryStrategy": {
                "name": "SemanticFacts",
                "namespaces": ["/knowledge/programming"]
            }
        }
    ]
)

# 存储用户偏好
memory_client.put_memory_item(
    memoryId=memory["id"],
    actorId="user123",
    sessionId="session456",
    namespace="/users/user123",
    content="用户偏好使用TypeScript进行前端开发，喜欢函数式编程风格"
)

# 检索相关记忆
relevant_memories = memory_client.get_memory_items(
    memoryId=memory["id"],
    actorId="user123",
    query="前端开发偏好",
    maxResults=5
)

3.3.2 AgentCore Gateway工具管理

Amazon Bedrock AgentCore Gateway是专为 Agent 应用设计的工具管理服务，解决了复杂场景下的核心挑战：当需要集成数十甚至数百个工具和 API 时，传统静态工具定义方式不仅管理复杂，还会导致上下文窗口浪费和工具选择困难。
Gateway 将现有 API、Lambda 函数和服务自动转换为 Agent 兼容的 MCP 协议格式，消除数周的自定义开发工作。其核心创新在于基于任务上下文的工具语义搜索机制：通过语义搜索动态检索最相关的工具定义，而非将所有工具加载到上下文中。处理”分析数据文件并生成可视化报告”的请求时，系统会自动识别并按依赖关系组合文件读取、数据处理和图表生成工具。

这种动态加载机制带来显著的上下文工程优势：Agent 根据需要加载工具定义，大幅减少上下文 token 使用；语义匹配提升工具选择精度，避免在大量工具中盲目选择。Gateway 还提供完整的企业级治理能力，包括版本管理、基于 IAM 的访问控制、使用监控和合规审计，通过多层缓存策略（工具定义、搜索结果、调用结果）优化性能，特别适合相似工具组合的反复使用场景。

import boto3
from bedrock_agentcore.gateway import GatewayClient

# 初始化Gateway客户端
gateway_client = GatewayClient(region_name="us-west-2")

# 创建工具网关
gateway = gateway_client.create_gateway(
    name="DataAnalysisGateway",
    description="数据分析和处理工具集合"
)

# 注册工具到网关
gateway_client.register_tool(
    gatewayId=gateway["id"],
    toolDefinition={
        "name": "pandas_analyzer",
        "description": "使用pandas进行数据分析和统计计算",
        "inputSchema": {
            "type": "object",
            "properties": {
                "data_source": {"type": "string"},
                "analysis_type": {"type": "string"}
            }
        },
        "tags": ["data", "analysis", "pandas", "statistics"]
    }
)

# 基于任务进行工具搜索
relevant_tools = gateway_client.search_tools(
    gatewayId=gateway["id"],
    query="需要分析CSV文件中的销售数据趋势",
    maxResults=3
)

4. 结语

亚马逊云科技通过完整的服务生态，将上下文工程的理论框架成功转化为可落地的智能体构建实践。其核心组件包括实现工具无缝集成的模型上下文协议（MCP）、提供业界领先记忆能力的AgentCore Memory，以及支持快速构建智能体应用的Strands Agents共同构成了一个覆盖工具集成、记忆管理和多智能体协作的完整技术栈。这些服务不仅精准对应了上下文工程的核心要素，更通过Amazon Bedrock AgentCore这一生产级平台，为企业提供了从开发到大规模部署的全链路支持，有效解决了智能体应用中上下文连贯性、系统可靠性和规模化运营的关键挑战。

上下文工程技术生态的独特价值在于它形成了一个理论与实践紧密结合的闭环。开发者能够通过Kiro开发环境以自然语言驱动智能体开发，利用开源的Multi-Agent Orchestrator框架灵活编排多智能体工作流，最终通过Bedrock AgentCore的安全隔离环境将智能体应用部署到生产环境。AWS不仅提供了构建智能体所需的技术组件，更重要的是打造了一个能够动态注入上下文、支持智能任务分解、并具备企业级管控能力的完整生态，为客户构建下一代上下文感知型智能体应用奠定了坚实基础。

关于Agentic AI基础设施的更多实践经验参考，欢迎点击：

Agentic AI基础设施实践经验系列（一）：Agent应用开发与落地实践思考

Agentic AI基础设施实践经验系列（二）：专用沙盒环境的必要性与实践方案

Agentic AI基础设施实践经验系列（三）：Agent记忆模块的最佳实践

Agentic AI基础设施实践经验系列（四）：MCP服务器从本地到云端的部署演进

Agentic AI基础设施实践经验系列（五）：Agent应用系统中的身份认证与授权管理

Agentic AI基础设施实践经验系列（六）：Agent质量评估

Agentic AI基础设施实践经验系列（七）：可观测性在Agent应用的挑战与实践

Agentic AI基础设施实践经验系列（八）：Agent应用的隐私和安全

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。