个人知识库

上下文工程

15分钟阅读

上下文工程

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.mdAgent 角色 / 边界 / 工具调度
记忆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-06-17-ai-agent-工程完全指南：芋圆ai 通过半年 100+ 篇笔记研究，给出了上下文工程的生产实践视角——揭示了三个反直觉规律：1) 超长指令反而降低性能：5000 行 agents.md 挤占任务思考空间，所有内容标为”重要”等于都不重要；OpenAI 的正确做法是”给 Agent 一张地图，而不是一本一千页的说明书”（小文件索引 + 结构化子目录 + 按需读取）。2) 隐性知识必须显性化：Slack 讨论、Google Docs、口头经验对 Agent 是黑洞，不在仓库里就不存在。3) 环境可观测性是上下文基础设施：OpenAI Codex 团队接入 Chrome DevTools Protocol 让 Agent 能看到系统状态（浏览器、DOM、日志），单次任务自主工作时长从 < 1 小时提升到 > 6 小时——这是把”环境状态”纳入上下文的基础设施改造。这些实践数据补充了上下文工程”资产打包”和”动态加载”维度的工程经验。

  • 2026-07-05-juejin-context-engineering-harness：GuWenyue 给出了上下文工程的最小代码化示例——把奶茶店新品研发任务拆成 background / constraints / outputRequirements 三个字段，再拼接为系统提示词。它补充了一个非常具体的工程判断：上下文工程不只是“多给资料”，而是把业务背景、硬性约束和输出格式拆成可维护对象；需求变化时只改对应字段，不重写整段提示词。文章还把上下文工程放进 Prompt → Context → Harness 的三阶段演进里：上下文工程解决“模型看见什么”，但生产系统还必须靠 Harness闭环工程 和 Loop Engineering 校验 JSON、成本、合规和工具调用。

  • 2026-07-08-woshipm-ai-coding-web-search-efficiency：hanpangzi 从 Web Search 角度补充了上下文工程的外部事实入口。搜索结束后真正有价值的不是链接，而是竞品差异、用户痛点、价格区间、平台规则、政策限制、数据口径、适用场景、权限边界、风险提醒和验收标准等可复用上下文资产。但这些资产进入上下文前必须先经过 信息源判断：区分原始来源、可验证公开资料和经验/聚合/GEO 内容，避免把错误或营销化资料写进 Agent 的长期执行环境。

  • 2026-07-27-woshipm-anthropic-80-percent-context-engineering：花叔解读 Anthropic 官方文章《The new rules of context engineering for Claude 5 generation models》——这是上下文工程这个概念首次被 Anthropic 官方命名和使用。核心事实：Claude Code 团队将系统提示词删掉 80% 以上，编码评测没有可测量的下降。六条策略对照表是上下文工程的操作手册：给规则→判断框架、给示例→设计接口、全部前置→渐进披露、反复强调→单一位置、CLAUDE.md 存记忆→自动记忆、简单规格→富引用。Anthropic 给出了两个过滤器：① Claude 读文件能不能自己推断出来？② 这是判断框架还是禁令？这为上下文工程的”资产打包”和”动态加载”维度提供了来自模型官方的最权威验证。花叔本人照着做，上下文资产从 23,504→9,259 字符（-60%），发现”一多半是坏的”——矛盾信息、过期版本、未索引的记忆、引用不存在的规则文件。

相关资源

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

相关页面

关系图谱

快速导航

反向链接