如果你把提示词改了十次，AI代理还是不断出错，其实问题可能根本不在提示词上。
2025年6月，Andrej Karpathy在X上发了一句话："context engineering is the delicate art and science of filling the context window with just the right information." Shopify CEO Tobi Lutke也立刻表示赞同。"提示词工程"这个词本身就是错的——真正的战场在上下文层面。
大家都这么认为
AI代理给出奇怪答案时，大多数人从这里开始：把系统提示词写得更具体，加few-shot示例，把输出格式规定得更详细。反复这样做，在单次任务上确实管用。
但当代理需要经历多个步骤、使用工具、记住之前的对话、访问企业内部数据——也就是被真正投入生产工作的时候——提示词优化越来越没有意义。无论你的提示词写得多精致，代理不知道的事情它还是不知道。
但数据说的正好相反
Firecrawl分析的研究结果很具体：把提示词分散到多个对话轮次中，相比集中提供，平均性能下降39%。Databricks测试Llama 3.1 405b时发现，上下文窗口超过32,000个token后，准确度明显开始下降。
在上下文窗口中放什么、怎么放，比提示词的表达方式影响大得多。
Elastic的核心区分总结得很到位："提示词工程把上下文窗口当成既定的东西接受。上下文工程则主动设计它。"
Neo4j总结的代理上下文4种失败模式：
| 失败模式 | 描述 | 症状 |
|---|---|---|
| 上下文污染 | 幻觉留在对话历史中被反复引用 | 错误不断累积恶化 |
| 上下文分散 | 过度依赖过去对话 | 忽略训练知识，重复错误答案 |
| 上下文混乱 | 不相关信息影响响应 | 无关内容混入答案 |
| 上下文冲突 | 相互矛盾的信息同时存在于上下文中 | 答案前后不一致 |
这4种问题没有一个能靠更好的提示词来解决。全都是往上下文里放什么、什么时候放、怎么放的问题。
那上下文工程到底是什么？
一句话：不是优化怎么向模型提问，而是设计模型工作的环境本身。
Neo4j的定义范围：检索管道设计、内存策略构建、工具模式与策略定义、任务状态追踪、推理历史管理。直接对比：
| 提示词工程 | 上下文工程 | |
|---|---|---|
| 核心问题 | 怎么表达？ | 模型需要知道什么？ |
| 作用对象 | 单个输入文本 | 完整信息架构 |
| 适合场景 | 单轮对话、简单分类 | 多步代理、长期工作流 |
| 失败时对策 | 修改表达方式 | 重新设计检索、内存、工具结构 |
| 规模 | 个人使用、原型 | 生产级AI系统 |
上下文工程的核心概念是Minimum Viable Context（MVC）——只给模型最少量的高质量信号信息。给太多会分散注意力，给太少会产生幻觉。刚好够用就行。
理想代理调用的5个上下文要素
① 用户目标 ② 最相关的检索结果 ③ 必要的工具定义 ④ 相关策略 ⑤ 压缩的内存摘要——这5个就够了。
GraphRAG：上下文设计的基础
传统RAG通过向量相似度检索文本片段——孤立的块，在需要理解关系的多跳推理上很弱，也会引入大量噪音。
GraphRAG将实体和关系结构化存储。它能回答"A影响B时，C会怎样？"，能在检索时应用访问权限，还能追踪推理路径。将向量搜索与图遍历结合的Agentic GraphRAG，现在是上下文工程的核心架构。
现在就能开始的方法
- 先诊断失败模式
查看代理的错误日志和对话历史，就能看到规律。确定属于4种模式中的哪一种。 - 定义核心知识领域
列出代理必须了解的领域知识。这将成为知识图谱的骨架。 - 检查RAG管道
如果同时提供30个以上的工具，就用RAG过滤减少数量。研究表明减到30个以下可使工具选择精度提升3倍。 - 分离内存层次
将短期（当前会话）、中期（用户历史）、长期（领域知识）分开设计。把所有过去的对话都堆积起来会造成上下文分散。 - 裁剪到最小可行上下文
有意识地减少进入上下文窗口的内容。如果减少后性能提升了，那就是上下文过载。
这不是说提示词工程没用
上下文工程是提示词工程的超集，而不是替代品。对于单轮任务和快速原型制作，提示词优化仍然非常有效。当代理需要处理复杂的多步骤工作时，那才是需要上下文工程的时候。
深入研究
Context Engineering vs. Prompt Engineering (Neo4j) GraphRAG和MVC概念最早系统整理的官方文章 neo4j.com
Context Engineering for AI Agents (Firecrawl) 32K Token限制、4种失败模式、工具优化数据深度分析 firecrawl.dev
Context Engineering vs. Prompt Engineering (Elastic) 主动设计上下文窗口的实用视角 elastic.co
Andrej Karpathy on Context Engineering 引发这次范式转变的原始X帖子 x.com
Why GraphRAG and MCP Are the New Standard GraphRAG成为代理数据架构标准的原因 hyperight.com
