上下文工程:AI Agent 时代的核心竞争力
Site Owner
Published on 2026-05-31
上下文工程:AI Agent 时代的核心竞争力 当我们谈论 AI Agent 的能力上限时,几乎所有注意力都放在了模型本身——参数规模、推理能力、多模态支持。但真正决定 Agent 能否可靠落地的,恰恰是一个很少被摆在台面上讨论的问题:上下文工程(Context Engineering)。 不是模型不够强,而是上下文管理太糙。这篇文章来聊聊这个被忽视却致命的瓶颈。 --- 一、上下文是 Agen...
上下文工程: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):全局有效 / 当前任务有效 / 本轮有效
- 维护一个轻量级的"上下文索引表",记录每个关键信息点的来源和生命周期