上下文工程

AI Agent 时代浮出水面的新工程方向——管理 Agent 协作中”喂给模型的上下文”这一可迁移资产,覆盖 Skill / Memory / MCP / 上下文重组等所有围绕上下文展开的能力

简介

上下文工程(Context Engineering)是 AI Agent 协作时代浮出水面的新工程方向。它不是单一技术,而是一系列围绕”如何管理喂给模型的上下文”的工程实践集合。在 LLM Agent 形态下,模型本身的能力差异在快速收敛,真正决定 Agent 输出质量的不再是模型本身,而是上下文层的工程能力——你给模型看了什么、按什么顺序看、有没有冗余、有没有腐烂、能不能复用。

这个概念被多个独立观察者同时识别出来,但视角不同:

三个视角合起来定义了上下文工程的边界:它是围绕”上下文”这一核心资产展开的工程实践集合,覆盖资产管理、动态加载、腐烂修复等所有维度。

关键信息

核心特性

定义

上下文工程是 AI Agent 时代浮出水面的工程方向,目标是系统化管理 Agent 协作中”喂给模型的上下文”这一可迁移资产。它不是单一技术,而是一系列工程实践的集合——覆盖资产打包、动态加载、腐烂修复、跨 Agent 复用等所有围绕上下文展开的能力。

核心命题:模型在收敛,上下文在分化

当主流模型能力快速逼近时,相同的需求给不同人用同一个模型,输出质量可能差 10 倍——差距不在模型,而在他们给模型看了什么、按什么顺序看、有没有冗余、能不能复用。这就是上下文工程要回答的核心问题。

上下文工程的四个维度

维度解决什么代表实践
资产打包如何把人的隐性经验编译成模型能用的上下文Skill(SOP 形态)、Memory(偏好沉淀)
动态加载在什么时机给模型什么粒度的上下文渐进式披露(name+description → SKILL.md → references)
腐烂修复长链路任务里上下文超窗后怎么重组GET SHIT DONE 这类工具
跨 Agent 复用同一份上下文资产怎么在多个 Agent 间复用中央 Skill 文件夹 + 软链接、Skills 跨平台协议

与传统 Prompt Engineering 的区别

项目Prompt Engineering上下文工程
时间尺度单次对话长期可复用
单位一段 prompt 文本一套上下文资产(Skill+Memory+MCP)
关注点怎么说让模型听懂怎么管让模型持续高效
失败模式措辞不准导致模型误解上下文腐烂导致模型”变笨”

上下文工程是 Prompt Engineering 的下一阶段——前者是”怎么说一次”的艺术,后者是”怎么长期维护一套上下文资产”的工程。

上下文腐烂(Context Rot)

上下文工程要解决的最典型问题之一。Sunday 在描述 GSD 时给出的清晰定义:

为什么 Claude Code 一开始还挺聪明,写着写着就开始变笨了?其实出现这个问题的原因大多数情况下是因为大模型的上下文超了,导致模型不知道你前面做了什么。

上下文腐烂的形成机制:

  1. 任务链路推进,工具调用 / 文件内容 / 历史对话不断累积到上下文窗口
  2. 窗口逼近上限时,重要信息被淹没在噪音里
  3. 模型表现下降,看起来像”变笨”

上下文工程的腐烂修复维度就是要处理这一现象——典型工具是 GET SHIT DONE

上下文资产作为可迁移核心

深思圈在 2026-05-13-ai-agent-productivity-20x 里给出了一个非常重要的判断——Agent harness 的核心可迁移资产是上下文层面的:

资产类型文件形态作用
Agent 配置agents.md / CLAUDE.mdAgent 角色 / 边界 / 项目规范 / Never 规则
记忆memory.md用户偏好 / 长期信息
SkillSKILL.md + scripts/references/assets程序性知识包
MCPMCP server 配置外部工具 / 数据接入

换平台只需要带走这四类资产,模型本体可以替换。这也是为什么 Anthropic 在 Claude Code 上推 plugins / agents / hooks / MCP servers / LSP servers 这一整套扩展点——它在打造的不是模型,是上下文资产的生态。

与同类概念的区别

  • 与 RAG 的区别:RAG 是”检索 + 拼接相关内容到 prompt”的具体技术;上下文工程是更上层的工程方向,RAG 是它的实现手段之一
  • 与 Prompt Engineering 的区别:见上面表格
  • 与 Memory 的区别:Memory 是上下文工程的一个组成部分(持久化的用户偏好层)

不同素材中的观点

  • 2026-05-27-juejin-claude-code-5-tools:程序员 Sunday 在介绍 GSD 时第一次明确提出”上下文工程”作为 Claude Code 生态里非常重要的一层。他给出的定义性表述是:“GSD 这种项目,代表的是 Claude Code 生态里非常重要的一层:上下文工程”。这是这个概念作为独立工程方向第一次被命名——之前散落在 Prompt Engineering / RAG / Memory 等不同标签下,Sunday 把它们汇聚到一个统一名字下。

  • 2026-05-13-ai-agent-productivity-20x:深思圈给出了上下文工程的资产视角——Agent harness 的核心可迁移资产是 agents.md / memory.md / Skill / MCP。这四类资产构成了一个 Agent 的可携带核心,换平台只需要带走这些。这与 Sunday 的”上下文工程是一层”的判断完全对齐——深思圈给出的”四类资产”就是上下文工程要管理的具体对象。

  • 2026-05-27-woshipm-yunshu-skill-practical-guide:云舒给出了上下文工程的作业视角——Agent 调用 Skill 是分多层级渐进式加载(name+description 触发 → SKILL.md 主流程 → references/scripts/assets 按需)。这本质是上下文的动态供给——按 Agent 当前任务需要,把上下文资产分阶段喂入模型,而不是一次性塞满窗口。这是上下文工程”动态加载”维度的核心机制。

  • 2026-05-28-agents-md-coding-standard:莪_幻尘给出了上下文工程的规范视角——AGENTS.md 规范文件 是上下文四大资产(agents.md / memory.md / Skill / MCP)中成本最低但收益最高的一个。5 分钟写一份 60-100 行的项目规范文件,AI 代码规范遵循率从 60% 飙升到 95%+。核心机制是”Never 规则持续演进”——每次 AI 犯错就加一条禁令,本质上是把人类的隐性经验编译成模型可消费的声明性上下文。在 Claude Code 生态中叫 CLAUDE.md,与 DESIGN.md、AGENTS.local.md 组成三文件体系,分别对应项目规范、视觉规范和个人偏好三个上下文层次

  • 2026-05-28-woshipm-llm-wiki-qmd-architecture:秋孝隱给出了上下文工程在知识管理场景的完整实践方案——CLAUDE.md 在 LLM Wiki 系统中不再是代码规范文件,而是知识库维护的行为规范手册,定义六个维度(角色定义+知识库定位+新会话启动+Ingest 流程+Query 流程+页面格式)。配合 qmd 检索引擎的 CLI 封装,LLM 不直接操作底层命令,而是通过语义化动作(wiki search / find-related / search-chunks)消费上下文——这是上下文工程”动态加载”维度在知识管理场景的特化:长文档不读全文,按主题用 search-chunks 检索相关段落,处理完一个主题就落盘(WIP 续传),避免上下文窗口爆炸

  • 2026-05-31-blocktempo-7-agents-software-factory:@sairahul1 给出了上下文工程的隔离视角——上下文漂移 是上下文工程要防御的主要威胁,而 7 Agent 软件工厂 通过 Agent 职责隔离实现了上下文的天然防控。核心洞察:当所有角色塌缩在一个 AI 对话中时,错误假设会被模型持续叠加并无声扩散;把对话拆成 7 个独立 Agent 后,每个 Agent 只装自己需要的上下文,漂移被天然限制在单个 Agent 内。这揭示了上下文工程的一个新维度:不只是”管理喂给模型的上下文”,更是”设计上下文的隔离边界”——知道什么信息不应该出现在当前上下文中,和知道什么信息应该出现一样重要

  • 2026-06-10-agent-engineering-guide:一位独立研究者给出了上下文工程的环境治理视角——他给内部项目搭了 Coding Agent,Demo 阶段惊艳,上线两周后 Agent 开始犯蠢。根本原因是 Agent 自己写出来的代码慢慢污染了自己的环境——它复制了一处不符合规范的实现,然后在后续任务里又复制了三处,架构漂移的速度比修补速度还快。这揭示了上下文工程的另一个维度:上下文不只是”喂给模型的信息”,还包括 Agent 运行的整个环境状态。OpenAI Codex 团队的应对是接入 Chrome DevTools Protocol,让 Agent 能感知系统状态(截图、DOM、日志),单次任务自主工作超过 6 小时。更深层的洞察是”知识放错了地方”——把所有规则塞进一个超长 agents.md 会适得其反,上下文有限,塞了 5000 行规则留给任务的思考空间就被挤掉了。正确做法是”给 Agent 一张地图,而不是一本一千页的说明书”——小的 agents.md 当目录,详细知识拆到结构化子目录按需读取。这与 2026-05-28-agents-md-coding-standard 的 AGENTS.md 实践完全对齐

相关资源

  • 上下文工程相关工具:GET SHIT DONE(腐烂修复)、Skill(资产打包)、MCP 模型上下文协议(外部接入)
  • 上下文工程的载体:Claude Code 是上下文工程实践最完整的平台(推出 Skills/agents/hooks/MCP/LSP 全套扩展点)

相关页面