个人知识库

上下文工程

13分钟阅读

上下文工程

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 内。这揭示了上下文工程的一个新维度：不只是”管理喂给模型的上下文”，更是”设计上下文的隔离边界”——知道什么信息不应该出现在当前上下文中，和知道什么信息应该出现一样重要

相关资源

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

相关页面

关系图谱

快速导航

反向链接