> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 智能体上下文工程的8种模式
- URL: https://www.hubwiz.com/blog/8-patterns-for-context-engineering-of-agents/
- Published: 2026-05-19T12:24:47.000Z
- Updated: 2026-10-13T16:00:34.000Z
- Description: 不是关于提示优化或提示工程。而是关于信息如何在对话式 AI 系统中流动的基本架构。它正在让公司付出真金白银，同时以难以诊断但容易感受到的方式降低用户体验。
- Author: admin
- Tags: CONTEXT ENGINEERING, #Import 2026-10-14 14:41

我还记得第一次目睹我们的生产环境 AI 智能体出现奇怪故障时的情景。不是技术错误，也不是速率限制。智能体只是忘了！在客户对话进行到一半时，它忘记了客户最初的请求和意图，开始重复自己的话，最终建议了一个客户三分钟前就已经排除的选项。当我们详细分析时，发现问题出在一个混乱的 47,000 token 上下文窗口，它已经成为模型导航的迷宫。

如果你在 2026 年构建基于 AI 的应用，你可能也遇到过这堵墙。关于 AI 开发的讨论往往集中在模型选择、提示工程和 RAG 架构上。但生产系统中有一个沉默的杀手，人们谈论得不够多：上下文工程，或者更准确地说，缺乏上下文工程。

这不是关于提示优化或提示工程。而是关于信息如何在对话式 AI 系统中流动的基本架构。它正在让公司付出真金白银，同时以难以诊断但容易感受到的方式降低用户体验。

## 1、没人预料到的 Token 爆炸

当你构建智能体 AI 应用时：你从简单开始。聊天机器人回答问题。也许它能访问知识库。然后产品要求跨会话记忆。然后你添加工具使用。然后多轮规划。然后错误恢复。然后对话历史。然后是关于用户的丰富上下文。

不知不觉中，每次交互都承载着之前所有内容的重量，加上系统可能需要知道的一切，加上每个工具定义，加上安全指令，加上输出格式规则。你的"简单聊天机器人"现在在用户输入第一个字之前就在处理 15,000 个 token。

数学是残酷的。假设你使用的是 Claude Sonnet 3.5（甚至不是 4.7！）按照当前的 API 定价：

- Input: $3 per million tokens
- Output: $15 per million tokens

一个从 2,000 token 开始、每次交换增长 500 token 的对话不仅仅是线性增加。每条后续消息都继承了整个对话历史。到第十次交换时，你正在处理：

**Message 1:** 2,000 tokens **Message 2:** 2,500 tokens (2,000 + 500) **Message 3:** 3,000 tokens (2,500 + 500) … **Message 10:** 6,500 tokens

这不是总共 5,000 token。那是十次交换中处理的约 45,000 token，因为每次交换都处理之前的一切。成本像滚雪球一样复合增长。

![Token消耗图](https://www.hubwiz.com/blog/content/images/2026/05/1-G3FJh_Pj2K5_ukUKNX50dw-1.png)

Token 消耗呈二次方复合增长，大致为 O(n2)。蓝线显示每次推理的 token 线性增长，但橙线揭示了真正的故事，随着上下文累积，对话中消耗的累计 token 爆炸式增长。

这还是保守估计。真实的生产对话看起来更像这样：

- System prompt with safety rails: 3,000 tokens
- Tool definitions (8–12 tools): 4,000 tokens
- User context and memory: 1,500 tokens
- Conversation history (10 turns): 8,000 tokens\* Current user message: 200 tokens

在模型生成单个输出词之前，你就已经处于 16,700 token。如果对话运行 20 轮？你已经消耗了 400,000 个输入 token。按每百万 $3 计算，每次对话就是 $1.20。扩展到每天 10,000 次对话，你每天就是约 $12,000，仅上下文开销每月就约 $360,000。

![成本图](https://www.hubwiz.com/blog/content/images/2026/05/1-Kim9RiP0qDKKGnWGjcPZ-w.png)

按每天 10,000 次对话，平均 30 轮计算，仅 token 成本就达到 **$13,800/天** 或 **$414,000/月**。

## 2、成本曲线

Token 成本并非保持不变。虽然头条新闻是"AI 正在变得更便宜"，但地面上的现实却讲述了不同的故事。是的，每 token 的推理成本正在下降。但有四个因素正在推高成本：

**1\. 思考模型成为默认选项。**

随着 Claude Opus 4.7 的"xhigh"努力级别、GPT-5.5 的推理模式和 Gemini 3.1 Pro 的深度思考能力，推理模型不仅仅是处理 token，它们用 token 思考。一个输出 500 token 的 Claude Opus 4.7 xhigh 查询可能在内部消耗 25,000–50,000 个思考 token。用户看到的是深思熟虑的回应。你的财务团队看到的是 50–80 倍的 token 乘数。更糟糕的是，Claude Opus 4.7 随 Tokenizer 2.0 一起发布，对于相同的输入文本，它比 Opus 4.6 多产生高达 35% 的 token。头条价格没有变化（每百万 token $5/$25），但你的实际账单一夜之间就上涨了。这就是 AI FinOps 团队所说的"**静默通胀**"，tokenizer 变了，数学变了，但仪表板仍然显示相同的每 token 费率。

![Token消耗对比图](https://www.hubwiz.com/blog/content/images/2026/05/1-iO4n7DVyh0X0rLzVLxRf0Q.png)

2026 年 5 月最新前沿模型的 token 消耗。推理模式比标准推理多消耗 3–4 倍 token。

**2\. 智能体工作流成倍增加上下文。**

当你的 AI 智能体调用三个工具时，每个工具调用都是单独的推理。每次推理都获得完整的上下文。一个具有 10,000 token 上下文的五步智能体任务不是 10,000 token，而是 50,000 token。智能体架构本身成为了 token 放大器。

**多模态上下文是巨大的。** 添加视觉？一张 1024x1024 的图片约 1,500 token。添加文档理解？一个 10 页的 PDF 是 8,000–12,000 token。你的"简单"客户支持机器人，能够读取上传的收据，其 token 预算刚刚翻了 5 倍。

**质量与成本的权衡是真实的。** 更便宜的模型更容易产生幻觉，这意味着需要更多的对话轮次来纠正错误，意味着更多的 token。你在模型上每次请求节省 $0.10，但在延长对话上多花 $0.30。在电子表格中看起来不错的优化在生产中失败了。

## 3、当上下文变成混乱：模型混淆正在规模化

模型退化是使用大于最优的上下文窗口时的另一个主要问题，而且它更阴险，因为更难测量。

技术术语是"迷失在中间"。Anthropic、OpenAI 和 Google 都发表了研究，显示了相同的模式：当上下文窗口变大时，模型对中间部分信息的准确性显著下降。模型擅长使用来自开头（系统提示）和结尾（最近交换）的信息。中间的一切？技术上它在，但模型难以可靠地检索它。

在实践中，这表现为：

**重复循环。** 智能体询问用户六轮前已经提供的信息。你可以在上下文窗口中清楚地看到它。模型看不到。

**工具调用幻觉。** 智能体为 API 调用编造参数，而不是使用对话中明确说明的值。为什么？因为该值埋藏在 15 轮对话的第 8 轮中，而模型的注意力机制正在退化。

**指令漂移。** 你精心设计的系统提示被大量对话历史淹没。模型开始遵循对话中的模式，而不是遵循你的指令。有没有见过 AI 智能体突然改变语气、格式或行为？那就是上下文过载。

**不一致的推理。** 智能体根据信息在上下文中的位置，对相同信息得出不同的结论。token 2,000 处的信息与 token 15,000 处的相同信息被赋予不同的权重。

## 4、如何修复？

以下是一些实用的模式，帮助修复上述问题，让你的智能体和智能体工作流更高效、更具成本效益。

### 模式 1：上下文压缩，让每个 Token 都算数

第一个模式简单得令人惊讶：压缩你不需要以完整密度保留的内容。

大多数对话历史不需要逐字保留。当用户问"天气怎么样？"而 AI 用详细的天气预报回应时，你不需要在接下来的 15 轮中保留那 200 token 的预报。你需要：

- 讨论过天气的事实
- 地点（伦敦）
- 日期（今天）
- 关键要点（下雨，15°C）

那是 20 个 token，不是 200。

**实现方法：**

每次交换后，运行后台压缩过程：

- 获取最后完成的交换（用户消息 + 助手回应）
- 提取事实要点和决策
- 将原始交换存储在外部记忆（数据库、向量存储）中
- 用压缩摘要替换完整交换

**关键注意事项：** 不要在交换完成前压缩。不要压缩最后 2–3 轮。保持最近上下文的完整细节，反正那是模型注意力最强的地方。

### 模式 2：分层上下文，信息分层

并非所有上下文都是平等的。你的系统提示需要高保真度。工具定义需要精确。但第三轮中关于用户偏好电子邮件而非电话的轶事？那可以存在于较低保真度的层中。

将你的上下文想象成金字塔：

**第 1 层：核心系统（始终存在）**

- 系统提示和指令
- 当前用户消息
- 紧接的前一次交换
- 关键用户上下文（身份、权限、安全约束）

**第 2 层：工作记忆（相关时存在）**

- 最近的对话历史（最后 5–7 轮）
- 当前任务的活跃工具
- 临时状态（购物车、进行中的表单）

**第 3 层：背景上下文（动态加载）**

- 较旧的对话历史（已摘要）
- 完整工具目录（仅在需要时加载）
- 扩展用户历史
- 领域知识

本质上，你是在对 token 预算分配做出明确的决策。核心获得 4,000 token。工作层获得 6,000。背景层获得剩余的，而且只有在需要时。

### 模式 3：语义分块，在正确的时间使用正确的工具

这是一个我看到团队经常做错的模式：将每个工具定义加载到每次对话中。

如果你的 AI 智能体可以访问 20 个工具，每个工具定义是 200 token，那就是 4,000 token 的工具定义。存在于每次推理中。即使对话是关于查询账户余额，而那 18 个工具是用于日程安排、数据分析和客户支持升级的。

为什么？因为开发人员害怕模型需要某个工具时它不可用。但这不是智能体系统应该工作的方式。

**实现方法：**

构建一个两阶段工具系统：

**阶段 1：意图分类** 使用一个快速、便宜的模型来分类用户想要的任务类别：

- 信息检索
- 交易执行
- 数据分析
- 日程安排
- 支持升级

**阶段 2：定向工具加载** 仅加载与该类别相关的工具。

Token 节省：每次推理 3,000+。成本节省：约 18%。

不要只在开始时分类。每次工具调用后重新评估。如果智能体使用了交易工具，为下一次推理加载更多交易工具。如果它在提取信息，加载信息工具。让工具集根据智能体实际在做什么动态演变。

### 模式 4：流式状态机，不断演变的上下文

传统聊天机器人将所有内容保留在上下文中。每个对话轮次都留在上下文窗口中，直到出现问题。但人类对话不是这样工作的。我们保持对当前话题的关注，让旧话题淡出。

将对话实现为基于状态改变上下文的状态机：

```
State: Greeting → Load: welcome tools, basic user info
State: Intent Discovery → Load: classification tools, history summary  
State: Task Execution → Load: task-specific tools, relevant data
State: Confirmation → Load: transaction tools, audit log
State: Closing → Load: feedback tools, minimal history

```

对话不会将 15 轮问候交换带入任务执行。它携带一个 50 token 的摘要："用户已问候，认证为 Alice（ID: 12345），想要转账 $500。"

### 模式 5：外部记忆架构，窗口之外的上下文

这里有一个残酷的真相：并非所有东西都需要在上下文窗口中。事实上，大多数东西都不应该在。

你的 AI 智能体不需要将每次历史对话都放在上下文中才能良好运作。它需要：

- 当前对话
- 在明确需要时的相关过去信息
- 按需检索额外上下文的机制

这就是外部记忆模式。将完整的对话历史、用户偏好、过去决策和领域知识存储在上下文窗口之外。使用语义搜索或结构化检索，仅提取当前推理所需的内容。

**架构：**

```
┌─────────────────┐
│  Context Window │
│  (8K tokens)    │
│                 │
│  - System       │
│  - Current turn │
│  - Recent (3)   │
│  - Retrieved    │
└────────┬────────┘
         │
         ↓ Query when needed
┌────────────────────┐
│  External Memory   │
│                    │
│  - Full history    │
│  - User profile    │
│  - Domain knowledge│
│  - Past decisions  │
└────────────────────┘

```

这个模式的妙处在于：即使对于拥有数月对话历史的用户，你的上下文窗口也保持精简（8,000 token）。旧信息存在，但它不会污染每次推理。你只在需要时支付检索费用，而从向量数据库检索比将所有内容包含在每次 LLM 调用中便宜几个数量级。

### 模式 6：渐进式披露，对话的懒加载

在 Web 开发中，我们学会了不要一次性加载所有内容。按需加载。同样的原则适用于 AI 上下文。

以最小上下文开始对话。仅在对话发出信号时才添加更多内容：

**最小启动：**

- System prompt: 2,000 tokens
- User identification: 100 tokens
- Current message: 200 tokens
- Total: 2,300 tokens

**如果对话超过 5 轮：**

- Add compressed history: +500 tokens

**如果用户引用过去的交互：**

- Retrieve and inject relevant past context: +1,000 tokens

**如果任务需要专门的工具：**

- Load tool-specific context: +800 tokens

每次添加都是由对话本身的信号触发的。你不是在猜测可能需要什么。你是在响应模型或用户明确表明他们需要的东西。

模型本身成为需要什么上下文的信号。如果它笨拙或询问信息，那就是你加载更多上下文的信号。如果它处理对话很顺畅，就让上下文保持精简。

### 模式 7：上下文轮换，为长对话提供新鲜窗口

对于真正需要运行 50+ 轮的对话，实现上下文轮换。把它想象成操作系统中的内存分页：你无法将所有内容保留在 RAM 中，所以你要换入换出。

每 10–15 轮，创建一个检查点：

- 将最后 10–15 轮压缩成摘要
- 将摘要写入外部存储
- 从上下文中清除详细历史
- 仅保留压缩摘要

你的上下文窗口重置了，但对话不会失去连贯性，因为你正在保留基本信息。

结果：对话可以无限期运行，而上下文窗口不会爆炸。你通过压缩保持连贯性，而不是通过永远携带一切。

### 模式 8：差异上下文，什么变了？

最复杂的模式：只用变化的内容更新上下文。

轮次之间，你的大部分上下文保持不变。系统提示：相同。工具定义：相同。用户身份：相同。唯一变化的是：

- 新的用户消息
- 新的助手回应
- 可能的一些状态更新

与其每次都发送完整的上下文，不如发送：

- 上下文 ID（当前上下文状态的哈希）
- 差异（自上次调用以来的变化）

后续调用的 token 节省：95%+。但这需要 API 缓存和重用基础上下文，这是 Anthropic 和 OpenAI 目前以预览形式提供的功能。

## 5、AI FinOps 思维：衡量重要的东西

如果你不衡量这些模式的影响，它们都不重要。以下是需要跟踪的内容：

**每次对话指标：**

- Total tokens consumed (input + output)
- Cost per conversation
- Number of turns to task completion
- Context window size over time

**系统级指标：**

- Daily/monthly token burn rate
- Cost per thousand conversations
- Average context size across all conversations
- Token efficiency ratio (useful tokens / total tokens)

**质量指标：**

- Task completion rate
- User satisfaction
- Model confusion events (repetition, inconsistency)
- Tool call accuracy

构建仪表板。设置警报。当平均上下文大小开始攀升时，这是一个领先指标，表明你的上下文工程正在退化。当每次对话的成本增加而没有相应的质量提升时，你的架构出了问题。

做得好的团队将上下文视为预算，而不是无限资源。他们为不同组件分配 token 预算：

- System prompt: 3,000 tokens (max)
- Tools: 2,000 tokens per category
- History: 5,000 tokens (compressed)
- User context: 1,000 tokens
- Current exchange: 3,000 tokens

总预算：14,000 token。所有内容都设计为适合该预算。如果有东西想超过它，其他东西就必须让步。

## 9、前进之路

上下文工程并不性感。它不是头条功能。但它是 AI 应用能够盈利扩展与侵蚀你的利润并随时间退化之间的区别。

我在这里概述的模式不是理论性的。它们来自处理数百万次对话的生产系统的实战检验方法。而且它们是必要的，因为替代方案，即向问题投入更多上下文，是行不通的。随着你扩展，它变得更昂贵、更不可靠。

随着思考模型成为标准，随着智能体工作流变得更复杂，随着多模态输入变得无处不在，上下文工程从"锦上添花"变为"使命攸关"。早期弄清楚这一点的团队将拥有巨大优势：以更低的成本获得更好的模型性能。

从模式 1（压缩）和模式 3（语义工具加载）开始。这些能给你带来最即时的影响。然后叠加外部记忆和分层上下文。将差异上下文留到你大规模运营时使用，它最复杂但提供了最高的上限。

AI 应用的未来不仅仅是更智能的模型。而是围绕这些模型的更智能的架构。而这种架构始于你如何工程化上下文。

---

原文链接：[Patterns for Context Engineering in Agentic Applications](https://medium.com/@shah.ravir/patterns-for-context-engineering-in-agentic-applications-449e4ac3ff7d?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)