Agentic AI Infrastructure Practice Series 9: Context Engineering¶

Ch04.403 Agentic AI Infrastructure Practice Series 9: Context Engineering¶

📊 Level ⭐⭐ | 5.9KB | entities/agentic-ai-infrastructure-practice-series-nine-context-engineering.md

Agentic AI Infrastructure Practice Series 9: Context Engineering¶

→ 原文存档

摘要¶

这是 AWS 官方博客"Agentic AI 基础设施实践经验系列"的第九篇，系统性地分析了 Agentic AI 时代上下文管理的范式转变。文章从传统聊天应用的简单上下文模型出发，论证了 Agent 系统中上下文复杂度的指数级增长，并结合 AWS Bedrock AgentCore 和 Strands Agents 展示了从上下文检索、处理到管理的完整框架。核心观点：Context Engineering 不是 RAG 的升级版，而是 Agentic AI 时代独立的技术方法论，需要从架构层面系统性解决上下文窗口限制、成本压力、性能衰减和个性化偏好四大挑战。

核心要点¶

1. 从聊天到 Agent：上下文的质变¶

传统聊天应用的上下文模型极其简单：模型本身无状态，应用层维护对话历史，每次请求携带完整上下文。这是一个"消息队列"模式。

Agent 系统的上下文发生了结构性变化，新增了多个关键模块： - 工具定义（Agent 需要知道自己能调用什么） - 工具调用历史（每次请求参数和返回结果） - 多步推理链 - 任务分解执行过程 - 多 Agent 协作状态

2. 上下文增长的量级¶

文章用一个具体例子说明了增长的量级：一个任务被分解成 10 个子任务，每个子任务需要调用 2 次工具。总上下文增长：

1（任务分解思考）+ 10 × 4（2次调用 × 2条记录）= 41 条新增上下文记录

多 Agent 场景下，每个 Agent 持有完整上下文还要协作共享，总量呈倍增关系。

3. 四大核心挑战¶

4. 性能衰减的隐性陷阱¶

这是文章最具洞察力的观点：当上下文 token 数增长时，成本线性增加，但性能（准确率）可能隐性下降。这不是一个可以用"加大模型"或"扩展窗口"解决的问题——它是一个结构性矛盾，需要在架构层面做优化。

深度分析¶

上下文工程 ≠ RAG 的升级¶

很多人会把 Context Engineering 理解为"更好的 RAG"，这是一个根本性的误解。RAG 解决的是"从外部文档中检索相关信息"的问题，它管理的是静态知识。Context Engineering 解决的是"在 Agent 执行过程中管理动态上下文"的问题，它管理的是运行时状态。

两者的区别：

AWS 的解决方案框架¶

文章结合 Bedrock AgentCore 和 Strands Agents 展示了三层框架：

1. 上下文检索与生成：从外部知识源获取相关信息，类似 RAG 但更动态
2. 上下文处理：对原始上下文进行压缩、摘要、优先级排序
3. 上下文管理：生命周期管理，包括缓存策略、淘汰策略、多 Agent 共享机制

这个框架的核心设计理念是：不是让上下文变得更多，而是让上下文变得更"对"。

对 Agent 架构的启示¶

1. 上下文设计应该像数据库 schema 设计一样被认真对待——它是 Agent 系统的核心数据结构
2. 监控上下文长度与性能的关系——建立成本/效果的最佳区间，而非盲目扩展
3. 多 Agent 系统中的上下文边界设计——过度共享导致耦合，过度隔离导致协作失效
4. 优先处理高频场景的上下文优化——而非追求通用解决方案

实践启示¶

• Agent 开发中，上下文管理是核心工程挑战，需要像对待数据库 schema 一样对待上下文设计
• 建立上下文监控指标：token 数、成本、延迟、准确率，找到最优区间
• 多 Agent 系统中，明确每个 Agent 的上下文边界——什么该共享、什么该隔离
• 上下文压缩和摘要不是可选优化，而是 Agent 系统的必要基础设施
• 缓存策略对成本影响巨大——高频重复调用场景应优先实现上下文缓存
• 个性化上下文需要独立管理——不要把它混入任务上下文

相关实体¶

• Context Engineering
• AI Coding 入门指南
• Harness Engineering
• MOC