AWS 详解生产级 AI 智能体的四层上下文工程：Deep Insight 的代码实现

当生产级 AI 智能体处理数据分析和报告生成等任务时，上下文管理可能成为主要瓶颈。200K 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 部分：实践中的 Harness 工程：将 Deep Insight 从开发环境推向生产环境。（即将推出！）

第一篇文章定义了生产级多智能体系统必须解决的五个核心挑战。它介绍了 Strands Agents SDK、Amazon Bedrock 和 Bedrock AgentCore，以及 AWS Fargate 如何各自解决不同层面的问题，并附有代码示例。这第二篇文章则介绍位于该架构之上的四层上下文工程实践，并展示每一层的实现方式。第三篇文章将指导你在 Amazon Virtual Private Cloud（Amazon VPC）上的安全私有网络中部署和运行智能体，涵盖真实生产运营所需的一切。

什么是上下文工程？

上下文工程是一门优化大型语言模型（LLM）有限上下文窗口中信息的学科，目的是让智能体发挥最佳表现。可在 Amazon Bedrock 上使用的 Anthropic Claude Sonnet 4.5 提供 200K 上下文窗口，但复杂的生产任务会很快超出这一限制。例如，像“分析销售数据并创建 DOCX 报告”这样看似简单的请求，会经历多个阶段：数据加载与探索（5 分钟）、按类别进行销售分析（3 分钟）、生成五张图表用于时间序列分析（10 分钟）、统计验证（3 分钟）以及最终报告生成（5 分钟）。这些阶段在 15 分钟内合计消耗超过 150K token。

在单一上下文中处理此类任务会引发问题：窗口在任务中途溢出、过时的上下文降低性能，而且出错时需要重新运行整个流程。随着上下文增长，对重要信息的注意力会下降，而低效会在按 token 计费的模式下推高成本。

“随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降（上下文腐化）。”

— Anthropic，“面向 AI 智能体的有效上下文工程”（2025.09）

上下文工程正是为解决这些问题而生，而且它并不只是一组技巧的集合。它横跨架构设计、提示词编写、工具实现与验证，是一门分层学科，每一层都弥补前几层的不足。本文详细介绍了可用于高效管理上下文的四层方法。

如何处理超出上下文窗口的任务

Anthropic 已发布多项用于处理长时程任务的技术。Deep Insight 将这些技术归为四层，每一层都弥补其他层的局限。下表列出了这四层。

以下各节依次介绍每一层，说明该层规定了什么、为何仅靠前几层还不够，以及该实践在 Deep Insight 中是如何实现的。

1. 通过多智能体架构隔离上下文

为每个专用智能体分配各自的上下文窗口，只将压缩后的结果传递给编排器。Deep Insight 通过 Coordinator、Planner、Plan Reviewer、Supervisor 和 Tool Agents（Coder、Validator、Reporter、Tracker、Auditor）的层级结构来实现这一点。

在单智能体模式下，从用户请求到数据探索、分析、图表生成、验证和报告的所有信息都会累积在同一个上下文中，很容易超出窗口。为每个智能体分配各自的上下文后，即使消耗最多的 Coder，其总 token 数也能保持在 25K 以下。每个智能体只接收自己需要的内容，并通过完成通知和简要摘要向其他智能体发出信号。

隔离的关键在于尽量减少共享信息。Deep Insight 使用一个 Python 字典 shared_state，其中只存储四项内容：

• messages：上一个智能体的最终消息（而非完整对话历史）。
• clues：从各智能体收集的压缩摘要。
• full_plan：由 Planner 生成、Tracker 更新的检查清单。
• history：智能体名称与消息的简要日志。

这些线索采用固定的 CLUES_FORMAT：不传递每个智能体的完整对话（数万 token），只传递压缩后的核心结果。

# coder_agent_tool.py -- context passing format
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the next step.*"

# After Coder completes: add only compressed result to clues
clues += CLUES_FORMAT.format("coder", response["text"])

这种模式正是 Anthropic 的“我们如何构建多智能体研究系统”一文中推荐的做法，该文描述了编排器-工作者模式，即由主智能体委派给专用子智能体，每个智能体只在自己的上下文中工作。你无需自行构建：Strands Agents SDK 中的 agents-as-tools 模式在框架层面提供了这种隔离。

2. 通过提示词控制上下文流入

仅靠第 1 层隔离并不足够：即使上下文相互独立，生成冗长响应的 agent 也会撑大 Supervisor 的上下文。第 2 层通过提示词限制每个 agent 的输出。

对于 Deep Insight，我们使用提示词来限制每个 agent 返回给 Supervisor 的信息量。正如 Deep Insight 的提示词所示，三条规则承担了大部分工作。

“从最强的模型和简单的提示词开始。然后根据实际观察到的失败案例，逐步添加具体指令。”

—— Anthropic，《Effective Context Engineering for AI Agents》（2025.09）

实现细节 2-1：为每个 agent 显式设定输出 token 预算

每个 agent 的提示词都规定了最大响应 token 数，防止冗长响应污染 Supervisor 的上下文。

Anthropic 的“Writing Effective Tools for Agents”一文建议为工具提供 CONCISE 或 DETAILED 响应选项，以提升上下文效率。将同样的思路向上应用一层，即写入每个 agent 的系统提示词。在 Deep Insight 中，所有 agent 共享一种标准化格式：

## Status
[SUCCESS | PARTIAL_SUCCESS | ERROR]
## Completed Tasks
- [Task 1 from FULL_PLAN -- use exact wording so Tracker can match]
- [Task 2 -- be specific, not generic]
## Key Insights
- [Key finding 1 with numbers and ratios]
- [Key finding 2 with business implications]
## Generated Files
- ./artifacts/chart.png -- brief description
- ./artifacts/calculation_metadata.json -- N calculations

实现细节 2-2：自包含代码理念

Coder agent 的提示词明确写道“变量不会在脚本之间保留”。每个脚本都必须包含所有必要的导入并直接加载数据。提示词同时给出了错误和正确的示例：

# WRONG -- Attempting to use a variable from Turn 1 in Turn 2
# Turn 1:
df = pd.read_csv('data.csv')
total = df['Amount'].sum()

# Turn 2:
print(f"Total: {total}")  # NameError: name 'total' is not defined

# CORRECT -- Every script is self-contained
import pandas as pd
df = pd.read_csv('./artifacts/cache/df_main.csv')  # Load from cache
total = df['Amount'].sum()
print(f"Total: {total}")

这条规则与上下文工程相关的原因在于：引用之前脚本中的变量要求 agent“记住”先前的对话，这意味着过去的代码必须保留在上下文中。自包含原则意味着过去的代码可以安全地从上下文中移除。

实现细节 2-3：Supervisor 的章节完成规则

Supervisor 的提示词中包含这样一条规则：“在当前 agent 章节的所有检查项都被标记为 [x] 之前，不要进入下一个 agent。”我们在提示词中表达这条规则，是因为判断 Coder 的工作是否完成，需要 Supervisor 利用 Tracker 更新中的信息来解读计划。这种判断很难仅用代码表达。

3. “上下文中只有指针，实际数据放在文件里”

第 1 层隔离了 agent 之间的上下文，第 2 层限制了 agent 内部的输出。但当 Coder agent 生成 100 行 Python 代码时，代码本身会进入上下文。即使有“简短回复”的提示词指令，有些代码也无法写得简短。第 3 层通过工具设计将重内容移出上下文，放入文件系统。如下面的实现细节所示，四项技术带来了大部分收益。

实现细节 3-1：用 Write and Execute Tool 将代码移出上下文

Coder 读取分析计划，编写 Python 并执行以生成可视化。但当代码变长时，常规做法（分开的文件写入工具和执行工具）会让每个脚本的 100 行代码直接进入上下文，累计超过 1,000 行。

解决办法是将两个步骤合并为一个工具，这样代码永远不会作为消息进入上下文。Deep Insight 的 Coder agent 为此使用了一个 write_and_execute_tool。

下面是 write_and_execute_tool 的一部分。在写入并执行文件后，它只返回一段摘要：“写入了 105 行，执行成功，完成了五个类别的分析。”代码留在文件中，上下文中只保留约三行摘要。根据这个例子，这样可以节省约 95% 的 token。

# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
    """Write a Python script and immediately execute it."""
    # Step 1: Write file
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)
    # Step 2: Execute immediately
    result = subprocess.run(
        f"python {file_path}",
        shell=True,
        capture_output=True,
        timeout=timeout
    )
    # Return only summary
    return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
        f"Execution successful\n" \
        f"Output: {result.stdout[:500]}"  # Only first 500 chars

“服务端过滤：在数据到达上下文之前于执行层进行过滤，token 减少 98.7%（从 150K 降至 2K）。”

— Anthropic，“Code Execution with MCP”（2025.11）

实现细节 3-2：在 Coder agent 中将通用逻辑复用为模块

通用模块会在各项分析之间被复用。与其每次都重新生成它们，不如将常用函数一次性定义为模块并导入，这样可以避免 token 浪费和上下文重复。

如果不这样做，在每次分析中都定义 to_python_type() 或 track_calculation() 这类函数，会在 10 次分析中产生 200–300 行重复代码。Deep Insight 会在第一个任务之前生成一个名为 coder_analysis_utils.py 的模块。它包含用于转换 numpy 类型、跟踪计算元数据以及保存为 JSON 的函数。后续分析会导入它，用两行 import 替代 20–30 行重新生成的代码，从而节省 token，并提升一致性和可调试性。

# coder_analysis_utils.py -- common module generated before first task
import numpy as np
import json
from datetime import datetime

_calculations = []

def to_python_type(value):
    """Convert numpy/pandas types to Python native types"""
    if isinstance(value, (np.integer, np.int64)): return int(value)
    elif isinstance(value, (np.floating, np.float64)): return float(value)
    elif isinstance(value, np.ndarray): return value.tolist()
    return value

def track_calculation(calc_id, value, description, formula,
                      source_file, source_columns, importance):
    """Track calculation metadata -- Validator independently verifies later"""
    _calculations.append({
        "id": calc_id, "value": to_python_type(value),
        "description": description, "formula": formula,
        "source_file": source_file, "source_columns": source_columns,
        "importance": importance
    })

def save_calculation_metadata(path="./artifacts/calculation_metadata.json"):
    """Save all tracked calculations to JSON"""
    with open(path, 'w', encoding='utf-8') as f:
        json.dump({"generated_at": datetime.now().isoformat(),
                   "calculations": _calculations}, f, ensure_ascii=False, indent=2)

实现细节 3-3：通过结构化笔记保存和共享分析结果

我们使用结构化笔记来共享详细的分析结果，而无需让这些结果经过每个 agent 的上下文。Deep Insight 将这些结果存储在一个名为 all_results.txt 的文件中，随后由各 agent 按需读取。

例如，Coder agent 在每次分析任务后会将结果追加到 all_results.txt：

with open('./artifacts/all_results.txt', 'a', encoding='utf-8') as f:
    f.write(f"""
## Category Sales Analysis (completed at: 14:32)
- Top revenue category: Fruit (417,166,008 KRW, 45% of total)
- Top 3 categories: Fruit, Vegetables, Meat (78% of total)
- Generated file: ./artifacts/category_sales_chart.png
""")

Coder 在每次分析后会将详细结果记录在该文件中，Reporter 在撰写最终报告时会读取它。其他 agent 也以同样方式通过 all_results.txt 协作。

如果不使用笔记，Coder 会在每次任务后将详细结果传给 Supervisor，并在其上下文中不断累积。使用笔记后，只会传递一条约 30 token 的消息，例如“类别销售分析完成，发现 3 个关键洞察，详细结果已保存到 all_results.txt”，而 Reporter 会在需要时读取该文件。

这种模式可以推广到单个文件之外。文件系统本身就可以充当 agent 间的通信总线，正如 Deep Insight 中所做的那样：

“这种‘即时’方法在运行时将数据动态加载到上下文中，而不是预先处理所有相关数据，从而使上下文保持新鲜、相关，并能适应任务不断演变的状态。”

— Anthropic，“Effective Context Engineering for AI Agents”（2025.09）

实现细节 3-4：使用 Skills 仅加载所需知识

这种方法不是把所有专业知识都塞进系统提示词，而是只在需要时才加载。如果把每一份技能指南（数据结构检查、README 生成、技能创建、系统提示词编写、工具创建）都包含进去，会增加超过 20K token，在每次调用时向 Coder agent 加载不必要的信息，并且添加技能还得重新部署。

Deep Insight 的 Skills 系统在启动时只加载约 500 token 的技能目录，技能列表里只包含名称和简短描述。当用户请求“创建一个 README 文件”时，agent 判断“我需要 readme-generator 技能”并调用 skill_tool(skill_name="readme-generator")。SkillLoader 读取 readme-generator/SKILL.md，返回约 3K token 的详细指南。

# 1. Skill Discovery (at initialization)
from src.utils.skills.skill_utils import initialize_skills
available_skills, skill_prompt = initialize_skills(
    skill_dirs=["./skills"],
    verbose=True
)

# 2. Add to System Prompt (~500-token catalog)
system_prompt = base_prompt + skill_prompt

# 3. Runtime -- Agent loads skill when needed
# Agent decides: "This is README generation, I need the readme-generator skill"
# -> skill_tool(skill_name="readme-generator")
# -> Returns full SKILL.md content (~3K tokens)

每个技能都定义为一个 SKILL.md 文件，由 YAML frontmatter 和详细的 markdown 指南组成。它包含名称、描述、许可证和 allowed-tools 等元数据，以及 Overview、When to Use This Skill、详细说明和 Best Practices。要添加新技能，只需在 skills/ 下创建新目录并编写 SKILL.md 文件，它就会被自动发现。

启动时，agent 加载约 500 token 的技能目录，而不是把超过 20,000 token 浪费在完整指南上（约减少 97%）。需要时，它可以额外加载几千 token 的技能详细说明。

4. 用验证 agent 和防护措施验证质量

即使有了第 1–3 层，仍有一个风险：相互隔离的 agent 看不到彼此的工作，因此如果 Coder 计算错误，Reporter 会把该错误带入报告。第 4 层是最后一道防线。

“提供测试工具，让 agent 能够自行验证功能并修复仅凭代码无法发现的 bug。让模型用描述性的提交信息把进度提交到 git，并在进度文件中编写进度摘要。”

—— Anthropic，“Effective Harnesses for Long-Running Agents”（2025.11）

实现细节 4-1：Tracker、Validator 和 Auditor agent：进度跟踪与质量保证

Tracker 实时更新计划的检查清单。当 Coder 完成数据加载后，Supervisor 调用 Tracker，Tracker 根据“数据加载完成（1,000 行，5 列）”等信息把计划项从 [ ] 更新为 [x]。这帮助用户和系统准确了解进度。

Validator 独立重新执行 Coder 的计算以验证准确性。它读取 calculation_metadata.json，从源数据重新执行每项计算并比较：差异在 0.01 以内则通过，不一致则标记。已验证的计算写入 citations.json，供 Reporter 引用。Reporter 完成后，Auditor 将最终 DOCX 与 citations.json 和 calculation_metadata.json 对照检查，但不修改它们。它把引用缺陷记录到 audit_findings.json，并可要求 Reporter 最多进行两次针对性重试。

实现细节 4-2：按优先级验证计算

验证每一项计算效率低下，因此按重要性限定验证范围。Deep Insight 的 OptimizedValidator 采用以下阈值：

• 超过 50 项计算：激进过滤，验证所有高优先级项，外加仅 10 项中优先级项。
• 超过 20 项计算：适度过滤，验证所有高优先级项，外加 15 项中优先级项。
• 20 项或更少计算：验证大部分，所有高优先级项加所有中优先级项，再加 5 项低优先级项。

它还采用类型安全比较：为避免 numpy 与 Python 的类型问题，所有值都转换为 float()，并检查绝对差是否小于 0.01：

# validator.md -- type-safe numerical comparison
try:
    match = abs(float(expected) - float(actual)) < 0.01
except:
    match = str(expected) == str(actual)

实现细节 4-3：SummarizingConversationManager：最后的安全网

在异常情况下，上下文仍可能溢出，因此要在其他层之下保留一道安全网。Deep Insight 为此使用了 Strands Agents SDK 中的 SummarizingConversationManager。

# strands_sdk_utils.py -- safety net configuration at agent creation
agent = Agent(
    model=llm,
    system_prompt=system_prompts,
    tools=tools,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.5,  # summarize oldest 50% on overflow
        preserve_recent_messages=10,  # always preserve 10 most recent messages
        summarization_system_prompt=apply_prompt_template("summarization", {})
    )
)

发生溢出时，LLM 会将最旧的 50% 消息汇总为一条，同时始终保留最近的 10 条，以维持当前任务的上下文。摘要提示词（summarization.md）要求 clues、plans 和 tracking status 必须逐字保留。

实现细节 4-4：选择性提示缓存以优化成本

上下文工程不仅关乎节省 token，也涵盖成本优化。根据每个 agent 被以相同提示词调用的频率，为每个 agent 启用提示缓存。Deep Insight 的各 agent 设置如下：

启用缓存的 agent 会将缓存点插入系统提示词和工具定义中，在重复调用时可将输入 token 成本降低最多 90%。这是 Strands Agents SDK 原生支持的功能。Plan Reviewer 未出现在表中，因为它是一个人在回路步骤，负责收集用户批准或反馈，而不是调用模型。

结论

本文详细介绍了四层工程方法，可用于高效管理超出上下文窗口的复杂任务的上下文。

• 第 1 层（架构级隔离）：每个 agent 通过多 agent 架构在独立上下文中工作，仅传递压缩后的摘要。
• 第 2 层（基于提示词的控制）：输出 token 预算、标准化响应格式和自包含代码理念主动限制上下文流入。
• 第 3 层（使用文件系统）：write_and_execute_tool 将代码保留在上下文之外，文件系统充当 agent 间通信总线，知识仅在需要时延迟加载。
• 第 4 层（验证与防护）：Validator 的独立计算复核、Auditor 对最终报告的只读引用审计、Tracker 的进度跟踪、SummarizingConversationManager 的溢出防护，以及选择性提示缓存，共同管理质量与成本。

每一层都构成一个防御系统，弥补前几层的遗漏。当架构隔离不足时，提示词限制输出。当提示词不足时，工具将内容保留在外部。而当问题仍然出现时，验证会将其捕获。

这些层次在 Anthropic 的工程博客文章中均有记录，包括“Effective Context Engineering for AI Agents”、“Code Execution with MCP”和“How We Built Our Multi-Agent Research System”。他们推荐的许多内容已经随 Strands Agents SDK 提供，而不是需要你自己构建：SummarizingConversationManager、提示缓存以及 agents-as-tools 模式。

在构建生产级智能体时，仅靠 LLM 的上下文窗口往往不够。应用这些上下文工程技术，可以高效管理上下文，并让智能体扩展到生产工作负载。

本文使用的参考实现 Deep Insight 是开源的。请审阅代码并将其扩展到你的领域。

• GitHub
• Workshop

关于作者

Yoonseo Kim

Yoonseo 是一名解决方案架构师，帮助客户使用 AWS 技术解决业务挑战。她对 AI/ML 有浓厚兴趣，专注于帮助客户设计和优化智能体 AI 工作负载，以及配套的基础设施和评估环境。

Gonsoo Moon

Gonsoo 是 AWS 的 AI/ML 专家解决方案架构师。凭借在多种 AI/ML 用例和生产部署方面的经验，他与客户密切合作，解决他们的 AI/ML 挑战。他还与数据科学家、开发者和分析师分享 AI/ML 知识，致力于为韩国和世界各地带来积极改变。

Jiyun Park

Jiyun 是一名解决方案架构师，帮助软件和互联网行业的客户将工作负载迁移到云端。她与客户合作设计云解决方案，帮助他们实现业务目标。

Chloe Kwak

Chloe 是应用 AI 解决方案组织中 Amazon Connect Decisions 的高级专家解决方案架构师，为 APJ 地区的客户提供支持。她曾在韩国零售团队工作多年，帮助零售和电商客户在 AWS 上实现现代化，并将 AI/ML 投入生产。如今，她帮助客户将智能体 AI 应用于需求和供应计划，从数据准备和预测验证到生产上线全程亲力亲为。

Jesam Kim

Jesam 是一名解决方案架构师，帮助企业客户采用云技术并解决业务挑战。他专注于 AI/ML，包括推荐系统和生成式 AI，帮助客户设计满足其业务需求的架构。

Kyutae Park, Ph.D.

Kyutae 是一名 AI 专家解决方案架构师，帮助各行业客户设计和构建应用 AI 工作负载，在机器学习、MLOps 和智能体 AI 方面拥有丰富经验。他专注于通过智能体 AI 实现智能自动化和运营创新，将自主决策和多智能体协作架构引入真实业务环境。通过这项工作，他帮助客户利用 AWS AI/ML 服务和应用生成式 AI 实现切实的业务成果，并构建可持续的竞争优势。