上下文工程：AI Agent 时代的核心竞争力

当我们谈论 AI Agent 的能力上限时，几乎所有注意力都放在了模型本身——参数规模、推理能力、多模态支持。但真正决定 Agent 能否可靠落地的，恰恰是一个很少被摆在台面上讨论的问题：上下文工程（Context Engineering）。

不是模型不够强，而是上下文管理太糙。这篇文章来聊聊这个被忽视却致命的瓶颈。

---

一、上下文是 Agent 的"工作记忆"

人类专家在处理复杂任务时，会在脑海中维持一个"当前状态"——已知什么、目标是什么、卡在哪里。AI Agent 同样依赖这个"状态"来做出合理决策。

这个状态，由三部分构成：

• 系统提示（System Prompt）：Agent 的角色定义和行为边界
• 对话历史（Conversation History）：过去的交互记录，影响 Agent 对当前情境的理解
• 外部上下文（External Context）：从 RAG、工具、数据库、文件等注入的实时信息

当这三者组织得当时，Agent 像一个训练有素的专家。当它们混乱时，Agent 就变成了一个失忆的实习生——每次接手新任务都从零开始，每次都在重复同一个错误。

---

二、上下文工程的三个核心问题

1. 上下文长度：不是越长越好

主流模型的上下文窗口从 128K 一路扩展到 1M，甚至10M。表面上看，"能塞更多"意味着"能记住更多"。但现实恰恰相反。

随着上下文增长，模型attention的computational cost呈二次方增长。更关键的是：信息密度并不均匀。一份500K 的代码库上下文中，真正影响当前决策的信息可能只有 20 行。剩余的 499,980 行都是噪声。

真正的问题不是"能放多少"，而是"怎么放得下真正重要的"。

工程实践：

• 对代码库进行语义切片，而非物理分块（按文件行数切分是最低效的做法）
• 在注入上下文前，用轻量级模型做 relevance scoring，过滤低相关片段
• 维护一个"活跃上下文窗口"，只保留任务当前阶段需要的信息

2. 上下文注入的时序问题

RAG（检索增强生成）是目前最流行的外部知识注入方式。但大多数 RAG 实现有一个致命缺陷：不考虑时序。

假设我们有一个多轮对话的 Agent，用户在第三轮提到了一个变量名 userSessionMap，而这个变量的定义发生在第一轮。标准的向量检索能找回第一轮的内容，但它不知道这应该在第三轮被优先注入。

结果是：Agent 能访问到所有历史信息，却无法判断"这条信息在当前时刻的相关性权重"。

工程实践：

• 在检索阶段附加时间戳和对话轮次权重
• 为每个上下文片段标注"作用域"（scope）：全局有效 / 当前任务有效 / 本轮有效
• 维护一个轻量级的"上下文索引表"，记录每个关键信息点的来源和生命周期

3. 上下文的遗忘与重置