2026年真正的AI开发者都在做 Context Engineering，而不是Prompt Engineering

顺便提一下：北京大学通用人工智能国家重点实验室2026年1月发表了一篇论文——《Meta Context Engineering via Agentic Skill Evolution》——直接引用了 Agent-Skills-for-Context-Engineering 仓库，称其为"静态技能架构的奠基性工作"。一个好的 Context Engineering 系统，应该能判断每段历史对当前任

技术小黑屋_

271人浏览 · 2026-03-16 09:03:34

技术小黑屋_ · 2026-03-16 09:03:34 发布

2026年Q1，GitHub Trending 上同时爆出几个仓库。

obra/superpowers，累计超6.3万颗星，描述是"一个可组合的 Agentic Skills 框架"。Agent-Skills-for-Context-Engineering，1.1万星，昨晚刚推了新代码。字节跳动的 deer-flow 2.1万星，HuggingFace 的 smolagents 2.5万星。

四个仓库，四个不同团队，同一天热度爆发。

我翻了它们的 README，发现一个有意思的共同点——

它们全都在刻意回避"prompt"这个词。

取而代之的是：Skills、Context、Memory、Agent Architecture。

这不是巧合，是一个行业信号：Prompt Engineering 的时代，正在悄悄结束。

中文圈目前几乎没有一篇深度文章在讨论这个转变。48小时的信息差窗口，现在就是最好的时机。

什么是 Context Engineering？

很多人第一次听到这个词会以为：哦，就是写更好的提示词嘛。换个名字而已。

不对。差远了。

Andrej Karpathy——特斯拉自动驾驶前负责人，那个说出"最火的编程语言是英语"的男人——给出了目前最精准的定义：

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

——Andrej Karpathy

翻译过来：Context Engineering，是把恰好合适的信息填入上下文窗口的艺术与科学。

注意，他说的是"整个上下文窗口"，不是"一条提示词"。

我来用一个类比说清楚这两者的区别：

Prompt Engineering 做的事： 怎么写这道菜的配方，让厨师看得懂。

Context Engineering 做的事： 管理整个厨房——食材库存是什么、厨师的技术背景是什么、今晚已经做了哪些菜、下一道菜需要哪个锅、过敏信息提前标注好没有。

上下文窗口里有什么？来拆开看：

•

系统提示（System Prompt）：厨师的基础训练和操作规范。静态系统提示就像把规范刻在石头上，好的 Context Engineering 要让它动起来——根据用户角色、任务类型实时调整。
•

工具定义（Tool Definitions）：厨房里有哪些设备。工具定义也占 token，写得太模糊，Agent 会乱调用；写得太多，会分散注意力。
•

外部记忆（Memory）：之前做过哪些菜、这个客人上次反映太咸。这是很多系统最薄弱的地方——要么完全没有记忆，要么把所有历史无脑堆进去。
•

对话历史（Message History）：今晚这桌客人已经点了什么、讨论了什么。长了要裁剪，短了会失忆，裁剪规则就是 Context Engineering 的核心技术之一。
•

用户状态（User Context）：这个用户是新手还是专家？现在在哪个任务阶段？情绪怎样？这些信息，模型自己猜不到，必须你注入进去。

把这五样东西全部管好，就是 Context Engineering。

而且有个残酷的数据：90% 以上的 Agent 失败，不是模型不够聪明，是上下文给错了。 coleam00 的 context-engineering-intro 仓库里明确写着："Most agent failures aren't model failures — they're context failures."

为什么是现在？

这个概念不是2026年才冒出来的。那为什么现在集中爆发？

因为三个关键条件同时成熟了。

条件一：上下文窗口大了一个数量级。

2023年，主流模型的上下文窗口是4K、8K token。现在 Claude 3.7、Gemini 2.0 Flash 都支持100K到200K甚至更多。

窗口小的时候，问题是"怎么把最重要的信息塞进去"——这是 Prompt Engineering 要解决的事。窗口大了，问题变成"这么大的空间，怎么合理分配、怎么防止模型在中间迷失"——这就进入 Context Engineering 的领域了。

有个研究发现叫 "Lost in the Middle"：当上下文很长的时候，模型对中间部分的注意力会显著下降，呈 U 型曲线。开头和结尾记得住，中间的内容容易被遗忘。这意味着，信息放在上下文里的顺序和位置，直接影响效果。这是 Prompt Engineering 从来没有系统研究过的维度。

条件二：Agent 从演示变成了实际工作系统。

2024年大家都在 demo Agent。2025年、2026年，Agent 开始真正跑在生产环境里，处理真实任务——调试代码、管理邮件、执行研究工作流、协调多个子 Agent。

一条精心设计的 prompt 可以让单次问答很好用。但一个要自主运行几十步、几百步的 Agent 系统，需要的是一套上下文管理机制：每一步生成的结果怎么传递给下一步？历史里哪些还相关、哪些该丢弃？工具调用的结果怎么摘要后注入？

这些问题，靠"写好提示词"根本无法解决。

条件三：MCP 协议让工具上下文成了可编程资源。

Anthropic 推出的 Model Context Protocol 已经成为主流标准，几乎所有主流 AI 工具都在接入。

MCP 的核心设计思想不只是"让 AI 调用工具"，而是让工具定义、工具结果、外部数据都成为可以动态注入和管理的上下文资源。这是一个协议级别的范式转变——你现在可以精确控制 Agent 在每个步骤能"看到"什么。

Karpathy 说"最火的编程语言是英语"。这句话本来是说，自然语言指令正在替代传统代码。但现在我要加一句延伸：英语也不够了，你需要的是"上下文架构"。

顺便提一下：北京大学通用人工智能国家重点实验室2026年1月发表了一篇论文——《Meta Context Engineering via Agentic Skill Evolution》——直接引用了 Agent-Skills-for-Context-Engineering 仓库，称其为"静态技能架构的奠基性工作"。学术界已经开始系统研究，开发者圈子还没反应过来。

3种实战模式，直接拿去用

理论说完了，来点能直接上手的东西。Context Engineering 落地有三种主要模式。

Skills 模式：知识预加载

Skills 模式的核心思想：把专业知识打包成可复用的"技能文件"，Agent 按需加载，而不是每次在 prompt 里重写一遍。

obra/superpowers 是这套玩法的最佳案例。它的设计哲学是：让 Agent 在开始任何任务之前，先自动加载对应领域的"技能上下文"。

在 Claude Code 里安装：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

装好之后，当你开始一个新功能，Agent 会自动加载 spec-drafting 技能（先讨论需求再写代码）、TDD 技能（测试先行）、subagent-coordination 技能（把复杂任务拆给子 Agent）。你什么都不用说，它就知道该怎么干。

这不是魔法，是上下文预装载（Context Preloading）。

你自己也可以做同样的事：把项目的架构规范、代码风格约定、不能踩的坑，写进 .claude/skills/ 目录里的 markdown 文件。Agent 每次启动自动加载，而不是靠你每次手动提醒它"这个项目用 TypeScript 严格模式，不能用 any"。

结果：obra/superpowers 的用户反馈，Agent 可以连续自主工作几个小时不跑偏。靠的不是更聪明的模型，靠的是更好的上下文管理。

Memory 模式：长短期分层存储

内存模式解决的问题是：Agent 既不能失忆，也不能记忆过载。

字节跳动 deer-flow 的实现思路是分层记忆架构：

# deer-flow 分层记忆示意
context = {
"short_term": {
"current_task": "实现用户登录模块",
"recent_decisions": ["用 JWT", "有效期24小时", "Redis 存储 token"],
"working_notes": "..."# 最近5步操作记录，滚动更新
    },
"long_term": {
"user_preferences": {"language": "Python", "style": "简洁少注释"},
"project_conventions": "详见 CLAUDE.md",
"past_solutions": {
"payment": "用了 stripe-python v7",
"auth": "统一用 bcrypt 哈希"
        }
    }
}

短期记忆：当前任务的上下文，滚动更新，只保留最近几步最相关的内容。

长期记忆：用户偏好、项目约定、历史方案，持久化存储，每次任务开始时注入。

关键原则：对话历史不是无限追加的。 要定期做摘要，把"这10步对话的要点是什么"压缩后替换原始历史。这样 Agent 既能记住重要决策，又不会被无关信息淹没。

Tool-Context 模式：MCP 按需注入

第三种模式是用 MCP 实现工具的动态注入和精准控制：

{
"context_strategy":{
"task_start":{
"inject":["project_structure","recent_git_changes","active_branch"],
"prune":["stale_tool_results","old_error_messages"]
},
"tool_call_done":{
"summarize":true,
"keep_raw":false
}
},
"tools":[
{
"name":"search_codebase",
"description":"搜索当前项目代码库中的函数和类定义",
"when_to_invoke":"用户询问具体实现细节时，不要主动调用"
}
]
}

两个核心操作：注入（inject） 和 裁剪（prune）。

每次任务开始，注入最新的项目结构、最近的代码变更——这些是 Agent 做决策必须知道的背景。同时，把过期的工具调用结果、已经处理的错误信息裁剪掉——这些是噪声，留着只会分散注意力。

工具调用完成后，对结果做摘要再注入，而不是把原始输出全塞进去。一个 shell 命令可能返回500行日志，但 Agent 需要的可能只是"命令成功执行，生成了3个文件"这10个字。

Context Engineering vs Prompt Engineering：一张表说清楚

维度	Prompt Engineering	Context Engineering
核心问题	怎么写这句话让 AI 听懂	怎么管理 AI 能看到的一切信息
适用场景	单次问答、简单指令	Agent、多步骤自主工作流
技能载体	一条自然语言指令	系统提示+工具定义+记忆+历史
主要失败原因	措辞不够精确	信息缺失/噪声过多/顺序错误
优化方式	反复改写提示词	设计信息架构和流动规则
生活类比	写一道菜的配方	管理整个厨房
技术门槛	写作能力+领域知识	系统设计+信息工程思维
可复用性	低（强场景依赖）	高（Skills 可跨项目复用）
规模化	难（每个场景单独调整）	可（统一框架管理所有场景）

结论： Prompt Engineering 没死，它是 Context Engineering 的一个子集——就像会写函数不等于会做系统设计。但如果2026年你的 AI 开发技能还停留在"反复调整提示词"这个层面，你在做的是手工艺，不是工程。

开发者怎么转型：5个自检问题

从现在开始，每次搭 AI 工具或者 Agent 系统时，先问自己这5个问题。答案会告诉你，你的系统处于什么水平。

① 系统提示是动态生成的吗，还是写死的一段话？

静态系统提示是起点，不是终点。一个成熟的 Agent 系统，系统提示应该根据用户角色（管理员/普通用户/访客）、任务类型（代码/写作/分析）、当前状态（初始化/进行中/错误处理）动态生成。

最小可行步骤：把你的项目规范、代码约定、禁忌事项写进 CLAUDE.md 或者 Skills 文件，让 Agent 每次自动加载，而不是靠你手动复制粘贴。

② 你的工具定义，有没有说清楚"在什么情况下调用"？

很多人的工具描述写的是"这个工具能做什么"，但 Agent 真正需要知道的是"在什么情况下应该调用这个工具，什么情况下不该调用"。

如果描述模糊，Agent 遇到稍微相关的场景就会乱调。而且每个工具定义都要占 token，工具越多、描述越长，能用于真正任务的上下文空间就越少。保持工具列表精简，每个工具职责单一。

③ 你的 Agent 有没有分层记忆机制？

没有记忆的 Agent，每次对话都从零开始，用户得反复解释背景，这是体验最差的设计。

但把所有对话历史无限追加进去更糟——随着任务推进，无关信息越堆越多，模型的注意力被分散，性能持续下降。

至少要做两件事：一，定期对历史对话做摘要；二，把用户偏好、项目设定这些长期信息独立存储，不要混在对话历史里。

④ 你有没有按相关性裁剪历史，而不是按时间顺序保留？

最近的不等于最重要的。当前任务是"优化数据库查询"，三步前讨论的支付模块逻辑就是噪声，应该被裁剪掉或者摘要。

一个好的 Context Engineering 系统，应该能判断每段历史对当前任务的相关度，优先保留高相关的，摘要或丢弃低相关的。这是 Agent 系统从"能用"到"好用"的关键跨越。

⑤ 用户状态有没有注入上下文？

AI 模型猜不到用户是谁、在哪个任务阶段、有什么背景。这些信息必须你主动注入。

新手用户需要更多解释，专家用户需要更简洁的回答；刚开始一个新功能和正在调试一个 bug，需要 Agent 有完全不同的行为模式。这些差异，模型自己感知不到，除非你把用户状态编码进系统提示或者每轮的上下文里。

做个快速自测：5个问题里，超过3个答案是"没有"或者"不确定"？那你的 Agent 系统正在用一台跑车的引擎，配了一个自行车的变速箱。

从"手艺"到"工程"，这是必然

说实话，Context Engineering 不是什么革命性的新发明。

它是 AI 工程从**"手艺"走向"工程"**的必然过程。

类比一下软件工程的发展：早期程序员写代码全靠个人风格和天才直觉，不用版本控制、不写测试、不做代码审查。然后 Git 出现了，CI/CD 出现了，代码规范出现了。不用 Git 的程序员，在2016年已经被团队淘汰了。

AI 开发正在经历同样的过程。

靠反复试提示词、靠感觉调 Agent 行为的阶段，就是 AI 工程的"早期程序员时代"。而 Skills 框架、Memory 分层、Context 裁剪规则、系统提示的动态生成……这些是 AI 工程的"版本控制时代"正在到来的标志。

那几个同时爆火的仓库不是在跟风造词。它们是一群工程师，在各自独立地解决同一个问题：怎么把 AI 开发从手工艺变成可维护、可扩展、可复用的工程系统。

术语已经在收敛了。工具已经在成熟了。论文已经在定义框架了。

2026年，不会 Context Engineering 的 AI 开发者，就像2016年不会 Git 的程序员。

时间窗口就这48小时。你先看到了。

文中数据来源：GitHub API（2026-02-27，数据为实时抓取）、北京大学通用AI实验室论文《Meta Context Engineering via Agentic Skill Evolution》（arxiv，2026-01）、Andrej Karpathy 原话引用自 davidkimai/Context-Engineering 仓库文档。

推荐仓库：