Context Engineering：AI Agent 时代最重要的工程能力

当别人还在争论该用哪个大模型的时候，真正的工程师已经开始优化"给模型的输入"了。

---

2025 年底，一个叫 Context Engineering 的概念悄悄爬上了 AI 工程师的嘴边。它没有 RAG 那样有明确的论文背书，也没有 Agent 那样有资本的热捧，但它正在成为决定 AI 应用质量天花板的关键因素。

从"调模型"到"调输入"

过去两年，大多数 AI 应用团队的时间都花在了两件事上：选模型 和 调 Prompt。

选模型是采购决策——哪个模型强、哪个便宜、哪个延迟低。这很重要，但它是外部依赖，你无法完全控制。调 Prompt 是对已有模型的微调——加几句指令、加几个示例、换个说法。这是有效的，但很快会遇到瓶颈：Prompt 再怎么写，模型也无法凭空知道它没有的信息。

真正的转折点发生在团队意识到：AI 应用的质量，90% 取决于你把什么信息送进模型的上下文窗口。

这个认知的背后，是一个简单但深刻的逻辑：大模型的能力由两部分构成：模型本身的推理能力 + 上下文中包含的信息质量。 模型能力在 API 调用那一刻已经固定，但上下文是你可以无限优化的工程变量。

这就是 Context Engineering 的本质：系统性地设计、管理和优化输入给大模型的上下文，让模型在每个任务中都能获得恰到好处的信息支撑。

为什么这件事在 2025-2026 年突然变重要了

Context Engineering 不是新概念，但它在当下这个节点爆发，有三个驱动因素。

第一，上下文窗口已经大到可以塞进整套系统架构。 2024 年初，上下文窗口还是 128K token 的天下。到了 2025 年底，1M token 的上下文已经是主流模型标配。这意味着你可以在一次请求中塞入：项目代码库结构、相关源码、测试用例、Issue 记录、团队 Coding 规范——这在以前是不可想象的。

第二，Agent 架构让上下文成为"系统血液"。 在纯问答场景，上下文只需要覆盖用户当前的问题。但在 Agent 架构中，模型需要在多轮交互中维护状态、记忆、工具调用历史、中间推理结果。上下文从"一次性输入"变成了"持续流通的系统状态"。它的质量直接决定了 Agent 会不会迷路、会不会遗忘关键信息、会不会在错误的方向上越走越远。

第三，RAG 的局限已经充分暴露。 RAG（检索增强生成）是 Context Engineering 最经典的应用，但它的简单形态——"检索 Top-K 文档，拼进 Prompt"——在复杂场景中频繁失效。向量检索的语义匹配精度有限，知识库构建质量参差不齐，Top-K 排序无法捕捉任务真正需要的信息优先级。这些问题迫使工程师回过头来，从更底层重新思考"如何组织上下文"。

Context Engineering 的核心维度

如果说 Context Engineering 是一套方法论，它大概可以拆成四个核心维度。

1. 内容选择：给模型喂什么

不是所有相关信息都有价值。噪音信息不仅浪费 token 预算，还会干扰模型的注意力机制，导致输出质量下降。

内容选择的核心问题是：对于当前任务，哪些信息是必要的、哪些是冗余的、哪些可能是有害的？

实践中常见的策略包括：

• ：不只是语义相似度，还要考虑时序相关性、任务相关性、结构相关性。比如一个 Bug 修复任务，最近三天内的 Issue 评论比三个月前的设计文档重要得多。