人工智能
制作的四层背景工程 AI agents：深透视如何在工作代码中应用
当生产AI agents处理数据分析和报告生成等任务时，上下文管理可能成为一个主要的瓶颈。 一个200K的窗口听起来很慷慨，直到一个现实世界的任务在几分钟内烧毁。 数据分析和报告生成使得agent无法中途执行，失去准确性，或者导致成本上升。 一套已公布的指南已经涉及这一问题，但个别技术比应用容易阅读。 应用在一起，它们就产生了可衡量的变化：在引用执行中，这个帖子走过，一个单一的书写和执行工具削减，每个脚本新增到上下文的符号大约减少了95%，按需加载技能使系统迅速缩小了大约97%。
本系列将指导组织为可直接应用的实践。 兹Q 1Z的工程岗哨，加上Strands Agents SDK所构建的特征，凝聚在四层背景工程上：在建筑层面孤立上下文，通过提示控制上下文，将其外部化到文件系统，并以独立的agents和保障措施进行验证。 在此帖子(第2部分)中，您将学习每个层的工作原理以及工作代码中它的样子。 我们将这些技术应用在"深度透视"(Deep Insight)中，一种基于Strands Agents SDK和Amazon Bedrock Agent Core的开源多agent数据分析溶液上，作为整个参考执行。
员额序列
- 第1部分：多agent系统中的5个生产挑战以及如何解决它们。
- 第2部分：制作的四层背景工程AI agents：深透视如何在工作代码中应用。
- 第3部分：实际操作中的哈尼思工程：将深度透视从Dev转移到生产。 (快来了)
第一个帖子定义了生产多agent系统必须解决的五个核心挑战。 它的推出如何用SDK,Amazon Bedrock和Bedrock Agent Core，以及AWS Fargate分别处理不同层次的问题，有代码示例。 这第二个帖子用的是四层背景工程实践，它们都位于该建筑的顶端，显示各执行。 第三个帖子通过在Amazon虚拟私人云(Amazon VPC)上的安全私人网络中部署和操作agents来指导您，覆盖现实世界操作所需的一切。
环境工程是什么？
上下文工程是在大型语言模型(LLM)有限的上下文窗口中优化信息的学科，因此agents表现最好。 Anthropic Claude Sonnet 4.5，可在Amazon Bedrock上找到，提供200K的上下文窗口，但复杂的生产任务很快就超过了它。 例如，“分析销售数据和编制DOCX报告”等似乎直截了当的要求贯穿几个阶段：数据加载和勘探(5分钟)、基于类别的销售分析(3分钟)、生成五张用于时间序列分析的图表(10分钟)、统计验证(3分钟)和最后报告生成(5分钟)。 他们总共消耗了超过150千个纪念品超过15分钟
在单一上下文中处理此类任务会造成问题：窗口溢出任务中段，上下文僵化会降低性能，错误需要重新运行整个管道。 随着环境的增长，对重要信息的关注下降，每盘价格下的融资成本效率低下。
" 随着上下文窗口中的符号数量增加，该模型准确回顾上下文信息的能力下降(康特文腐烂) "。
Anthropic,“AI Agents的有效环境工程”(2025.09)
上下文工程准确地解决了这些问题，它不仅仅是技术的集合。 扩展架构设计、迅速写作、工具执行和校验，此帖子详细介绍了您可以应用的四层方法来有效管理上下文。
如何处理超出上下文窗口的任务
Anthropic发布了几种处理长视距任务的技术。 深透视将这些技术分成四层，每层解决其他技术的局限性。 下表列出四层。
以下各节按各层排列，说明各层规定的内容，前几层为何不足，如何在"深度透视"中实施。
1. 通过多agent架构孤立上下文
给每个专业的agent自己的上下文窗口，只将压缩的结果传递给管弦乐手。 " 深入深入观察 " 以协调员、规划员、计划审查员、监督员和工具Agents(编码员、验证员、报告员、跟踪员、审计员)的等级进行这项工作。
通过单一的agent，所有信息，通过数据探索，分析，图表生成，验证，以及报告，在一个上下文中累积，很容易超过窗口。 给每个agent自己的上下文甚至使使用最多的编码器保持在25K令牌总数以下。 每个agent只收到它需要的东西，并以完成通知和简短摘要向其他人发出信号。
隔离的关键是尽量减少共享信息。 深度透视使用 Python 词典，share state，仅存储四件事：
- 消息：先前的agent最后消息(不是完整的对话历史).
-线索：从每个agent收集的压缩摘要。
- 完整计划：由规划师生成并由Tracker更新的核对表。
-历史：agent名称和消息的简要日志。
线索使用一个固定的CLUES FORMAT：而不是每个agent的完整对话(数万个令牌)，只传递压缩核心结果。
这种模式是Anthropic的 " 我们如何构建我们的多Agent研究系统 " 文章中所建议的模式，其中描述了一个管弦乐-工作模式，其中一名领头的agent代表到专门的子代理人，每个agent只在自己的背景下工作。 您无需自己构建：Strands Agents SDK 中的 agents-as-tool 模式在框架层面提供这种隔离。
2. 通过提示控制上下文流入
第1层单独隔离是不够的：即使有独立的环境，产生长答复的agent也会夸大主管的环境。 第二层通过提示限制每个 agent 的输出。
对于"深度透视"，我们使用提示来限制每个agent返回主管多少信息。 正如深渊透视的提示所示
“以最强的模型和简单的迅速开始。 然后根据实际观察到的故障情况逐步增加具体指示。”
Anthropic,“AI Agents的有效环境工程”(2025.09)
执行细节 2-1：按agent产出符号明确的预算
每个agent的提示指定了最大响应符号计数，防止长期响应污染主管的背景。
Anthropic的“为 Agents 写作有效工具” 文章建议给工具一个 CONCISE 或 DETAILED 响应选项，在 agent 的系统提示中，应用同一个想法。 在Deep Insight中，所有agents共享一个标准化格式：
执行细节 2-2：自足代码哲学。
代码agent的提示中明确指出，“可变性在脚本之间不会持久存在。” 每个脚本必须包括所有必要的导入和直接加载数据。 提示提供了不正确的例子：
这个规则与上下文工程有关的原因是，引用以前脚本中的变量需要agent来"记住"之前的对话，这意味着过去的代码必须保留在上下文中。 自足原则意味着过去的代码可以安全地从上下文中去除。
实施细节 2-3：主管部分完成规则
监督员的提示包括一项规则，即 " 在目前agent部分的所有清单项目标注[x]之前，不要移到下一个agent。 " 我们迅速表达这一规则，因为决定编码员的工作是否完整，要求主管使用跟踪员更新的资料解释计划。 单用代码来表达这个判断是很困难的。
3. " 仅指上下文中的实际数据 "
第1层隔离agents之间的上下文，第2层限制agents内部的输出。 但当编码器agent生成百行Python代码时，该代码本身就进入了上下文。 即使有“简短的答复”即时指示，一些代码也不可能简短写出来。 第3层使用工具设计将重度内容移出上下文，进入文件系统。 如以下实施细节所示，四种技术带来大部分好处。
执行细节 3-1：将代码移出上下文，并带有写和执行工具
编译器读取分析计划，写作Python，并执行以生成可视化。 但当代码变长时，常规方法(分离文件写入和执行工具)新增 100行直接到每个脚本的上下文，积累了1000多行。
定律是将两个步骤折叠成一个单一的工具，因此代码从不作为消息输入上下文。 Deep Insight的代码agent为此使用一个写法和执行工具。
以下是撰写执行工具的部分。 在撰写和执行文件后，它只返回一个摘要：“写出105行，执行成功，完成对五个类别的分析。” 代码保留在文件中，大约三行摘要仍然在上下文中。 基于这个例子，可以节省大约95%的代币。
“服务员侧过滤：在执行层上下文前过滤数据，减少98.7%(150K至2K)”。
- Anthropic,“与MCP一起执行代码”(2025.11)
执行细节 3-2：将通用逻辑重用为编码器agent中的模块
通用模块在分析中重复使用。 与其每次重新生成它们，不如一次将经常使用的功能定义为模块并导入，从而防止象征性的浪费和上下文的重复。
否则，在每次分析中定义像 python type()或 track 计算()这样的函数，在10个分析中产生200至300行重复代码。 深度透视在第一个任务前生成一个名为coder analysis utils.py的模块。 它包括转换numpy类型，跟踪计算元数据，以及保存到JSON的功能。 随后的分析导入它，用两条导入线取代20–30再生成的线条，这可以节省符号，提高一致性和调试。
执行细节3-3：通过结构化说明保存和分享分析结果
我们使用结构化的注意来分享详细的分析结果，而不通过每个agent的背景。 Deep Insight将这些结果存储在一个名为all results.txt的文件中，然后根据需要由agents读取。
例如，在每次分析任务之后，代码agent附加结果为所有 results.txt:
编译器在每次分析后都会在本文件中详细记录结果，而"记者"在撰写最终报告时会阅读。 其他 agents 通过所有 results.txt 以同样方式进行协作。
在不记账的情况下，编码员在每次任务结束后，将详细结果交给主管，并在其背景中积累。 由于注意到这一点，只有大约30个信息，如“类别销售分析完成，找到3个关键见解，将详细结果保存到所有 results.txt”被传递，记者在必要时阅读文件。
模式概括到单个文件之外。 文件系统本身可以作为agent间通信总线，如同在深透视中所做的：
“及时”办法，在运行时动态地将数据输入上下文，而不是预先处理所有相关数据，使上下文保持新鲜、相关并适应任务不断变化的状态。”
Anthropic,“AI Agents的有效环境工程”(2025.09)
执行细节 3-4：装入只需要的知识wi
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
Four layers of context engineering for production AI agents: How Deep Insight applies them in working code
When production AI agents handle tasks such as data analysis and report generation, context management can become a major bottleneck. A 200K-token window sounds generous until a real-world task burns through most of it in minutes. Data analysis and report generation leave the agent failing mid-execution, losing accuracy, or driving up costs. A body of published guidance already addresses this, but the individual techniques are easier to read about than to apply. Applied together, they make a measurable difference: in the reference implementation this post walks through, a single write-and-execute tool cuts the tokens each script adds to context by about 95 percent, and loading skills on demand shrinks the system prompt by about 97 percent.
This series organizes that guidance into practices you can apply directly. Anthropic’s engineering posts, together with features built into the Strands Agents SDK, converge on four layers of context engineering: isolate context at the architecture level, control it through prompts, externalize it to the filesystem, and verify it with independent agents and safeguards. In this post (Part 2), you will learn how each layer works and what it looks like in working code. We applied these techniques in Deep Insight, an open source multi-agent data analysis solution built on the Strands Agents SDK and Amazon Bedrock AgentCore, which serves as the reference implementation throughout.
Post series
- Part 1: 5 production challenges in multi-agent systems and how Deep Insight solved them.
- Part 2: Four layers of context engineering for production AI agents: How Deep Insight applies them in working code.
- Part 3: Harness engineering in practice: moving Deep Insight from dev to production. (Coming soon!)
The first post defined five core challenges that production multi-agent systems must solve. It introduced how Strands Agents SDK, Amazon Bedrock and Bedrock AgentCore, and AWS Fargate each address different layers of the problem, with code examples. This second post takes the four layers of context engineering practice that sit on top of that architecture and shows each one implemented. The third post guides you through deploying and operating agents in a secure private network on Amazon Virtual Private Cloud (Amazon VPC), covering everything needed for real-world operations.
What is context engineering?
Context engineering is the discipline of optimizing the information in a large language model (LLM)’s limited context window so agents perform at their best. Anthropic Claude Sonnet 4.5, available on Amazon Bedrock, offers a 200K context window, but complex production tasks quickly exceed it. For example, a seemingly straightforward request like “Analyze sales data and create a DOCX report” runs through several stages: data loading and exploration (5 min), category-based sales analysis (3 min), generating five charts for time-series analysis (10 min), statistical validation (3 min), and final report generation (5 min). Together they consume over 150K tokens across 15 minutes.
Processing such tasks in a single context causes problems: the window overflows mid-task, stale context degrades performance, and errors require re-running the whole pipeline. As context grows, attention to important information drops, and inefficiency raises cost under per-token pricing.
“As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases (Context rot).”
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
Context engineering solves exactly these problems, and it is not only a collection of techniques. Spanning architecture design, prompt writing, tool implementation, and verification, it’s a layered discipline where each layer compensates for what the previous ones miss. This post details the four-layer approach you can apply to manage context efficiently.
How to handle tasks that exceed the context window
Anthropic has published several techniques for handling long-horizon tasks. Deep Insight groups these techniques into four layers, with each layer addressing the limitations of the others. The following table sets out the four layers.
The sections that follow take each layer in order, stating what the layer prescribes, why the preceding layers alone are insufficient, and how the practice is implemented in Deep Insight.
1. Isolating context through multi-agent architecture
Give each specialized agent its own context window and pass only compressed results to the orchestrator. Deep Insight does this with a hierarchy of Coordinator, Planner, Plan Reviewer, Supervisor, and Tool Agents (Coder, Validator, Reporter, Tracker, Auditor).
With a single agent, all information, from user requests through data exploration, analysis, chart generation, validation, and reporting, accumulates in one context and easily exceeds the window. Giving each agent its own context keeps even the Coder, which uses the most, under 25K tokens total. Each agent receives only what it needs and signals others with a completion notice and brief summary.
The key to isolation is minimizing shared information. Deep Insight uses a Python dictionary, shared_state, that stores only four things:
- messages: The previous agent’s final message (not the full conversation history).
- clues: Compressed summaries collected from each agent.
- full_plan: A checklist generated by Planner and updated by Tracker.
- history: A brief log of agent names and messages.
The clues use a fixed CLUES_FORMAT: instead of each agent’s full conversation (tens of thousands of tokens), only compressed core results are passed.
This pattern is the one recommended in Anthropic’s “How We Built Our Multi-Agent Research System” post, which describes an orchestrator-worker pattern in which a lead agent delegates to specialized subagents, with each agent working only within its own context. You do not need to build it yourself: the agents-as-tools pattern in the Strands Agents SDK provides this isolation at the framework level.
2. Controlling context inflow through prompts
Layer 1 isolation alone is not sufficient: even with independent contexts, an agent that generates long responses inflates the Supervisor’s context. Layer 2 limits each agent’s output through prompts.
For Deep Insight, we use prompts to limit how much information each agent returns to the Supervisor. Three rules do most of the work, as Deep Insight’s prompts show.
“Start with the strongest model and a simple prompt. Then incrementally add specific instructions based on actually observed failure cases.”
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
Implementation detail 2-1: Explicit per-agent output token budgets
Each agent’s prompt specifies a maximum response token count, preventing long responses that pollute the Supervisor’s context.
Anthropic’s ” Writing Effective Tools for Agents” post suggests giving tools a CONCISE or DETAILED response option for context efficiency. Apply the same idea one level up, in each agent’s system prompt. In Deep Insight, all agents share one standardized format:
Implementation detail 2-2: Self-contained code philosophy
The Coder agent’s prompt explicitly states “variables do not persist between scripts.” Every script must include all necessary imports and load data directly. The prompt provides both incorrect and correct examples:
The reason this rule relates to context engineering is that referencing variables from previous scripts requires the agent to “remember” prior conversations, which means past code must remain in context. The self-contained principle means past code can be safely removed from context.
Implementation detail 2-3: Supervisor’s section completion rule
The Supervisor’s prompt includes the rule “Do not move to the next agent until all checklist items in the current agent’s section are marked [x].” We express this rule in the prompt because deciding whether the Coder’s work is complete requires the Supervisor to interpret the plan using information from the Tracker’s updates. This judgment is difficult to express in code alone.
3. “Only pointers in context, actual data in files”
Layer 1 isolates context between agents, and Layer 2 limits output within agents. But when the Coder agent generates 100 lines of Python code, that code itself enters the context. Even with “respond briefly” prompt instructions, some code can’t be written briefly. Layer 3 uses tool design to move heavy content outside the context, into the filesystem. Four techniques carry most of the benefit, as the following implementation details show.
Implementation detail 3-1: Moving code outside context with Write and Execute Tool
The Coder reads the analysis plan, writes Python, and executes it to generate visualizations. But when the code gets long, the conventional approach (separate file-write and execute tools) adds 100 lines directly to context per script, accumulating over 1,000 lines.
The fix is to collapse the two steps into a single tool, so the code never enters context as a message. Deep Insight’s Coder agent uses one write_and_execute_tool for this.
Here’s part of the write_and_execute_tool. After writing and executing the file, it returns only a summary: “Wrote 105 lines, execution successful, completed analysis of five categories.” The code stays in the file and about three lines of summary remain in context. Based on this example, that saves about 95 percent of the tokens.
“Server-side filtering: filtering data at the execution layer before it reaches context, 98.7% token reduction (150K to 2K).”
— Anthropic, “Code Execution with MCP” (2025.11)
Implementation detail 3-2: Reusing common logic as modules in the Coder agent
Common modules get reused across analyses. Rather than regenerating them each time, define frequently-used functions as a module once and import them, which prevents token waste and context duplication.
Without this, defining functions like to_python_type() or track_calculation() in every analysis produces 200–300 lines of duplicate code across 10 analyses. Deep Insight generates a module called coder_analysis_utils.py before the first task. It includes functions for converting numpy types, tracking calculation metadata, and saving to JSON. Subsequent analyses import it, replacing 20–30 regenerated lines with two import lines, which saves tokens and improves consistency and debugging.
Implementation detail 3-3: Saving and sharing analysis results through structured note-taking
We use structured note-taking to share detailed analysis results without passing them through each agent’s context. Deep Insight stores these results in a file called all_results.txt, which is then read by agents as needed.
For example, the Coder agent appends results to all_results.txt after each analysis task:
The Coder records detailed results in this file after each analysis, and the Reporter reads it when writing the final report. Other agents collaborate through all_results.txt the same way.
Without note-taking, the Coder passes detailed results to the Supervisor after every task, accumulating in its context. With note-taking, only an approximately 30-token message like “Category sales analysis complete, 3 key insights found, detailed results saved to all_results.txt” is passed, and the Reporter reads the file when needed.
The pattern generalizes beyond a single file. The filesystem itself can serve as the inter-agent communication bus, as it does in Deep Insight:
“The”just in time” approach, dynamically loading data into context at runtime rather than pre-processing all relevant data up front, keeps context fresh, relevant, and adaptive to the evolving state of the task.”
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
Implementation detail 3-4: Loading only needed knowledge wi
Auto-fetched and translated by AI Atlas. All rights belong to the original author.