再次强调: 提示工程已死, 上下文工程永生(AI代理系统的“注意力危机”与终极解法)

再次强调

《德说-第420期, 别再死磕提示词了！2026年，Agent 的胜负手不在 Prompt，而在“上下文工程”》

我觉得上一篇没用说太明白, 很多人还是没意识到上下文工程的重要性, 决定再来一篇.

提示工程已死，上下文工程永生：AI代理系统的“注意力危机”与终极解法

当所有人都在疯狂调教提示词时，真正的瓶颈却被忽视了——你的AI正在被淹没在上下文的汪洋中。

2026年，AI代理已从玩具演变为生产力工具，但开发者们正集体陷入一场无声的危机：精心设计的提示词、复杂的工具链、庞大的知识库，换来的却是代理的“精神分裂”——遗忘关键信息、误解用户意图、在无关细节中耗尽算力。问题出在哪？不是模型不够强，而是我们误解了AI的认知方式。今天，我们要揭开这个被99%开发者忽略的真相，并给出一个已经被北大研究验证的终极解决方案。

一、 被误解的“上下文”：AI的注意力不是无限的

你一定遇到过这些场景：代理在长对话中突然忘记你两小时前的指令；检索增强生成（RAG）系统明明召回了相关文档，却答非所问；多轮工具调用后，模型开始胡言乱语。你尝试优化提示词，增加示例，甚至用上最新的思维链，效果却微乎其微。

为什么？因为我们都陷入了“提示工程至上”的迷思。提示工程关注的是“怎么说”，而AI的真正瓶颈在于“能听多少”——这就是上下文工程的战场。

第一性原理： Transformer架构的注意力机制本质是一种稀缺资源。随着输入序列增长，模型会出现 “lost-in-the-middle” 现象（中间部分被遗忘），U型注意力曲线（开头和结尾效果最好），以及注意力稀释（关键信号被噪声淹没）。OpenAI的研究表明，当上下文超过模型窗口的50%时，性能开始明显下降；Anthropic的实验也证实，即使是最先进的模型，在长上下文中也存在高达30%的召回衰减。这并非模型缺陷，而是注意力机制的内在物理规律。

这意味着， 你往上下文里塞的每一个token，都在争夺模型那有限的“注意力预算” 。而大多数开发者的做法，恰恰是像无头苍蝇一样往里面堆砌信息——完整的对话历史、未经筛选的检索文档、冗余的工具定义……结果就是，模型被噪声淹没，关键信号被稀释。

二、 上下文工程：AI代理系统的“操作系统”

正是在这一背景下，Muratcan Koylan 的开源项目 Agent Skills for Context Engineering 应运而生。这个项目被北京大学通用人工智能国家重点实验室在2026年的论文《Meta Context Engineering via Agentic Skill Evolution》中引用，被评价为“静态技能的奠基性工作”，并指出它“架起了手工技能工程与自主自我进化之间的桥梁”。

它不是什么花哨的框架，而是一套关于如何管理模型上下文窗口的系统性方法论。它教你如何像外科医生一样精确地选择哪些信息进入模型、以什么顺序、以什么形式、什么时候该丢弃、什么时候该压缩、什么时候该从外部存储召回。它把上下文管理从“玄学”变成了“工程”。

核心洞察： 上下文工程的本质是在有限的注意力预算内，找到最小的高信号token集，以最大化期望结果的概率。它涵盖系统提示、工具定义、检索文档、消息历史、工具输出等所有进入模型视野的信息。

三、 用户的真实痛点：生产级代理的四大死穴

让我们看看那些试图将AI代理投入生产的团队所面临的典型困境：

1. 成本失控：盲目增加上下文长度直接推高token成本。一个中等复杂度的代理，每天处理数千次对话，token费用可达数百美元，而其中大量是冗余历史。
2. 性能悬崖：长对话中，代理从“智能”退化为“弱智”。客服机器人忘记订单号，编程助手忽略代码库关键文件，研究代理漏掉核心文献。
3. 调试地狱：无法复现失败原因。因为每次模型看到的上下文都不同，问题难以定位，修复全凭运气。
4. 架构混乱：多代理协作时，上下文在代理间随意传递，导致信息污染、重复劳动、决策冲突。

这些痛点不是个例，而是所有依赖长上下文的应用都会遭遇的“系统性疾病”。解决它们，不能靠提示词的局部优化，而需要从架构层面重新思考上下文生命周期。

四、 产品目标：打造平台无关的上下文工程技能

Agent Skills for Context Engineering 的目标是： 为所有AI代理平台（Claude Code、Cursor、自定义框架）提供一套可复用的上下文工程技能。它不是一个库，而是一套教学性质的开源技能集合，每个技能都是一个独立的、结构化的指令模块，代理可以根据当前任务动态加载。

目前项目包含四大类技能：

• 基础技能：理解上下文是什么、为什么会失效（丢失、中毒、分心、冲突）、如何压缩。
• 架构技能：多代理模式、记忆系统（短/长期、图数据库）、工具设计、文件系统上下文、最新的托管代理（带沙箱VM）。
• 运维技能：上下文优化（压缩、掩码、KV缓存）、评估框架（LLM-as-Judge）。
• 认知架构： 最新 的BDI（信念-欲望-意图）心理状态建模，将外部RDF上下文转化为代理的正式心理状态。

每个技能都遵循渐进式披露原则：代理启动时只加载技能名称和描述，只有当任务需要时才加载完整内容。这本身就是上下文工程的一个实践——避免一次性加载过多无关技能占用注意力预算。

五、 实战Demo：在Claude Code中安装并激活上下文工程技能

让我们用一个真实场景演示：假设你正在用Claude Code构建一个多代理写作系统，需要确保代理不会遗忘早期的写作风格指令，同时能有效利用外部知识库。

Step 1：添加插件市场
在Claude Code中运行：

/plugin marketplace add muratcankoylan/Agent-Skills-for-Context-Engineering  

Step 2：安装相关插件

/plugin install context-engineering-fundamentals@context-engineering-marketplace  
/plugin install memory-systems@context-engineering-marketplace  
/plugin install advanced-evaluation@context-engineering-marketplace  

Step 3：触发技能
当你向代理提问：“帮我设计一个记忆系统来追踪用户偏好的写作风格，避免在长对话中遗忘”，代理会自动检测到 memory-systems 技能相关，加载其完整内容，并按照技能指导提供方案。

更妙的是，当你的对话进行到需要评估生成质量时，代理会自动触发 advanced-evaluation 技能，调用LLM-as-Judge技术进行自动评估。

这种动态激活机制，确保代理始终只关注当前最相关的上下文知识，而不被整个技能库拖垮。

六、 权威案例：从个人操作系统到图书生成，验证可复用的成功

该项目不只是纸上谈兵，它附带了多个完整的示例系统，展示了技能的组合应用：

• Digital Brain Skill：一个为创始人和创作者打造的个人操作系统。包含6个模块、4个自动化脚本，实现了三级渐进加载、模块隔离、追加式内存。项目中的 HOW-SKILLS-BUILT-THIS.md 详细追溯了每个架构决策背后的技能原则，证明了这些技能的实用性和可追溯性。
• X-to-Book System：一个多代理系统，自动监控X账号并每日生成合成书籍。它应用了多代理模式、记忆系统、上下文优化等技能，展示了如何将碎片化信息持续转化为结构化知识。
• LLM-as-Judge Skills：一个生产级的TypeScript实现，包含19个通过测试。它实现了直接评分、两两比较（带位置偏差缓解）、评估标准生成等，被用于自动化评估其他代理的输出质量。
• Book SFT Pipeline：用仅2美元成本训练了一个8B模型，使其能够模仿任何作者的写作风格，并在Gertrude Stein案例中以70%的人类评分通过Pangram测试。这得益于项目中的智能分块、提示多样性、Tinker集成等上下文工程技术，证明了风格学习而非内容记忆。

这些案例覆盖了个人效率、社交媒体处理、自动化评估、模型微调等多个领域，说明上下文工程的原则是跨领域通用的，而非个例。

七、 第一性原理再思考：上下文工程的未来会消失吗？

有人可能会问：如果未来模型拥有百万token窗口，或者注意力机制被彻底改造，上下文工程还有必要吗？

让我们用第一性原理推演：

• 前提1：注意力机制是Transformer的内核，而Transformer短期内仍是主流。 只要注意力机制存在，长上下文就会导致注意力稀释。即使窗口扩大到100万token，关键信息依然会被淹没在99万噪声中。所以，上下文工程不会消失，只会从“管理token数量”演变为“管理信息密度”。
• 前提2：经济性永远重要。 即使模型能完美处理长上下文，处理1万token的成本也远高于处理1000token。对于大规模应用，上下文工程是控制成本的核心手段。
• 前提3：人类认知的局限性。 代理系统最终服务于人，人类无法消化过长的输出。上下文工程也包含了对输出的精炼——让代理只返回最关键的结果。

如果这些前提崩塌——比如出现了全新架构，注意力不再是瓶颈，且计算成本为零——那么上下文工程可能会简化。但即便如此，信息筛选和结构化的需求依然存在，因为“无限注意力”不等于“无限智能”。真正的智能在于忽略无关信息，这永远是工程的核心。

八、 观点犀利：告别“提示词迷信”，拥抱“上下文系统思维”

提示工程不是敌人，但它已经被过度神化。许多团队把大量精力花在写“完美提示词”上，却忽视了更根本的上下文管理。这种失衡导致AI应用开发陷入“调参陷阱”——改一个词，效果变好；改另一个，又崩了，毫无可复现性。

上下文工程恰恰提供了系统性的解决框架：它告诉你如何设计代理的记忆结构，如何评估上下文质量，如何诊断注意力失效，如何在不同代理间协调上下文。它不是让你放弃提示工程，而是让你站在更高的维度，把提示词看作整个上下文系统中的一个组件。

一句话总结：提示工程是战术，上下文工程是战略。

九、 行动号召：加入上下文工程的开源革命

Agent Skills for Context Engineering 的出现，标志着AI代理开发从“手工技能时代”迈向“系统化工程时代”。它已被学术界认可，被开发者社区接纳（Star历史稳步增长），并提供了一套完整的、可立即使用的技能库。

无论你是在用Claude Code、Cursor，还是自研框架，都可以从这个项目中汲取养分。浏览它的技能，研究它的案例，甚至贡献你自己的技能。因为上下文工程的未来，不是由少数专家定义，而是由每一个追求高效AI系统的开发者共同塑造。

访问项目地址：https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering

别再只盯着提示词了，让你的AI真正学会“看该看的地方，记该记的东西”。上下文工程，才是生产级AI代理的终极护城河。

数据支撑：北京大学论文引用、Anthropic/OpenAI注意力研究、项目内置案例数据（70%人类评分、$2成本、19测试通过）。本文基于Transformer架构第一性原理，结合多个权威研究及项目官方文档，旨在为AI开发者提供系统性思考框架。

上下文是什么? 如何优化?

上下文是不是每次丢给大模型的所有内容(提示词只是一部分), 你的理解完全正确，而且抓住了当前AI工程化中最容易被忽视的命门。

让我把你的公式写得更清楚：

上下文（Context）= 系统提示 + 本轮用户输入（Prompt） + 历史对话 + RAG检索结果 + 工具定义（MCP/A2A） + 技能描述（Skill Descriptions） + 代理自身状态 + 外部存储片段 + ……

换句话说，你喂给模型的所有东西，都是上下文。而模型那有限的注意力，必须在这堆信息中寻找关键信号。如果你只盯着“提示词怎么写”，却放任上下文里塞满噪声、冗余、过时信息，那就像在垃圾堆里找钻石——提示词写得再好也白搭。

那到底怎么优化上下文？

基于 Agent Skills for Context Engineering 项目中总结的工程原则，我为你拆解成五个实战维度，每个维度都对应 README 中的具体技能，并有真实案例佐证。

维度一：上下文选择与修剪（给模型做“断舍离”）

目标： 让进入上下文窗口的每一个 token 都有明确价值，杜绝“信息脂肪”。

怎么做：

• 去重：如果 RAG 召回了三篇重复度 80% 的文档，只留一篇精华。
• 遗忘：历史对话中，超过 N 轮且与当前任务无关的，直接丢弃或压缩成一句摘要（context-compression 技能）。
• 过滤：利用元数据或关键词，只保留与当前意图强相关的检索片段（而不是整篇文档）。
• 排序：把最重要的信息放在开头或结尾（U 型注意力曲线），中间只放次要内容。

案例：在 digital-brain-skill 示例中，作者实现了 3 级渐进加载（SKILL.md → MODULE.md → 数据文件）。代理启动时只读一级，只有当用户询问具体模块时才加载二级，需要具体数据才加载三级。这比一次性把所有模块塞进上下文，token 消耗减少 70% 以上。

维度二：上下文压缩与结构化（给模型“思维导图”而非“百科全书”）

目标： 用更少的 token 表达同样丰富的信息。

怎么做：

• 摘要化：长对话用 LLM 压缩成关键事实列表（context-compression 技能）。
• 结构化：把自然语言历史转化为 JSON/表格，模型更容易扫描。例如 memory-systems 用 JSONL 格式存储记忆，每行一个事实，附带时间戳和置信度。
• KV 缓存：在推理时复用已计算的键值对，避免重复处理相同前缀（context-optimization 技能中的 KV-cache 策略）。

案例：book-sft-pipeline 示例中，为了训练模型模仿作者风格，他们不是直接把整本书塞给模型，而是用 智能分块+重叠窗口 生成训练样本，并用 15+ 种提示模板防止记忆。最终仅用 $2 成本就让 8B 模型学会了 Gertrude Stein 的风格，人类评分高达 70%。

维度三：上下文动态加载（给模型装“搜索引擎”而非“离线缓存”）

目标： 只在需要时才把特定知识拉进上下文，避免长期驻留无关信息。

怎么做：

• 技能触发：在 Claude Code 中，技能只在相关关键词出现时才加载完整描述（Skill Triggers 机制）。
• RAG 即用即查：不是一次性检索所有相关文档，而是先检索摘要，再根据代理决策决定是否加载全文。
• 文件系统上下文：把部分上下文存成文件，代理通过 read_file 工具按需读取（filesystem-context 技能）。这样主上下文始终保持轻量。

案例：x-to-book-system 监控多个 X 账号，每天生成书籍。它不会把全年的推文一次性加载，而是每天只加载当天的推文，并用记忆系统（memory-systems）存储跨天的重要主题，只在需要总结时才召回。

维度四：上下文质量评估与诊断（给模型装“仪表盘”）

目标： 量化上下文是否有效，找出失效模式（丢失、分心、冲突）。

怎么做：

• LLM-as-Judge：用另一个模型给当前上下文的输出打分，或者直接评估上下文中是否包含了关键信息（advanced-evaluation 技能）。
• 诊断模板：检查是否出现“lost-in-the-middle”（中间部分被遗忘），可以通过设置“探针问题”来测试——例如在对话中间插入一个“记住这个数字：42”，几十轮后问“那个数字是多少”。
• 偏见缓解：在 pairwise 比较时，交换顺序消除位置偏见。

案例：llm-as-judge-skills 是一个完整的 TypeScript 实现，包含直接评分、两两比较、自动生成评估标准等功能。作者用它测试了 19 个场景，确保评估结果稳定可靠。

维度五：认知架构与心理建模（让模型“带着目标看上下文”）

目标： 给代理一个认知框架，让它知道哪些上下文是信念，哪些是当前目标，从而主动筛选信息。

怎么做：

• BDI 模型：把外部上下文（如 RDF 知识图谱）映射为代理的 信念（Beliefs） 、欲望（Desires） 、意图（Intentions） （bdi-mental-states 技能）。代理只关注与当前意图相关的信念，其余信息存入长期记忆。
• 元认知提示：让代理定期反思“我现在需要什么信息来完成意图？当前上下文里有哪些是冗余的？”

案例：README 中提到该技能是“最新”添加的，虽然没给具体案例，但原理清晰——在北大论文《Meta Context Engineering》中，这正是从“静态技能”迈向“动态进化”的关键一步。

一句话总结

优化上下文不是单一技巧，而是贯穿代理系统设计、开发、运行、评估全周期的系统工程。它要求你：

• 设计时：想清楚信息如何分层、如何存储、如何触发。
• 运行时：动态加载、压缩、修剪，保持上下文“苗条而精准”。
• 评估时：量化质量，诊断失效，持续迭代。

当你开始用这些维度审视自己的代理系统，你会发现很多“提示词调不动”的问题，根源都在上下文管理上。正如文章标题所说：提示工程已死，上下文工程永生——不是提示不重要，而是它只是上下文这张大网上的一个节点。真正的高手，在优化整张网。