在AI领域，"上下文工程"（Context Engineering）正逐渐取代"提示工程"（Prompt Engineering），成为更广泛且强大的概念。Tobi Lutke将其定义为"为任务提供所有上下文，使其能够被大语言模型（LLM）合理解决的艺术"。随着智能代理（Agents）的兴起，如何将信息加载到"有限的工作记忆"中变得尤为重要。代理的成功与否主要取决于提供的上下文质量，大多数失败源于上下文问题而非模型本身。上下文不仅包括用户提示，还涵盖系统指令、对话历史等所有模型生成响应前看到的信息。

主要内容总结：

1. 背景工程（Context Engineering）的兴起
在人工智能领域，随着“提示工程”（Prompt Engineering）的逐渐演变，一个新的概念——“背景工程”正在受到关注。Tobi Lutke将其定义为“为任务提供所有背景信息，使其能够被大型语言模型（LLM）合理解决的艺术”。背景工程的核心在于，决定AI代理（Agent）成功与否的关键因素是所提供的背景质量，而非模型本身的性能。

2. 背景的定义
背景不仅仅是发送给LLM的单一提示，而是模型在生成响应之前所看到的所有信息，包括：
- 指令/系统提示：定义模型行为的初始指令，可能包含示例和规则。
- 用户提示：用户提出的即时任务或问题。
- 状态/历史（短期记忆）：当前对话的上下文，包括用户和模型的交互历史。
- 长期记忆：从过去的对话中积累的持久知识库，如用户偏好、项目总结等。
- 检索信息（RAG）：从外部文档、数据库或API中获取的最新相关知识。
- 可用工具：模型可以调用的功能或内置工具的定义。
- 结构化输出：模型响应格式的定义，例如JSON对象。

3. 背景工程的重要性
构建高效AI代理的关键不在于代码的复杂性，而在于提供的背景质量。一个“廉价演示”与“神奇代理”之间的区别在于背景的丰富程度。例如，一个简单的会议安排任务，如果代理能够访问日历信息、历史邮件和联系人列表，并调用相关工具，生成的响应将更加智能和实用。

4. 从提示工程到背景工程
提示工程专注于在单一文本字符串中设计完美的指令，而背景工程则更为广泛。背景工程是设计和构建动态系统的学科，旨在以正确的格式、在正确的时间提供正确的信息和工具，使LLM能够完成任务。其特点包括：
- 系统而非字符串：背景是系统运行后的输出，而非静态提示模板。
- 动态性：根据即时任务实时创建，可能包括日历数据、邮件或网络搜索。
- 提供正确的信息和工具：确保模型不缺少关键细节，仅在需要时提供知识和能力。
- 格式的重要性：信息呈现方式至关重要，简洁的摘要优于原始数据转储。

5. 结论
构建强大且可靠的AI代理越来越依赖于背景工程，而非寻找神奇的提示或模型更新。背景工程是一个跨学科的挑战，涉及理解业务用例、定义输出，并构建所有必要信息，使LLM能够完成任务。

6. 致谢
本文通过深入研究和手动整理，参考了多个优秀资源，形成了这一概述。

关键点：
- 背景工程是AI领域的新兴概念，强调为任务提供全面的背景信息。
- 背景包括指令、用户提示、历史、长期记忆、检索信息、可用工具和结构化输出。
- 背景质量决定AI代理的成功与否，而非模型本身的性能。
- 背景工程是动态系统设计，旨在以正确的格式和时间提供信息和工具。
- 构建高效AI代理的核心在于背景工程，而非代码复杂性或模型更新。

主要观点总结：

1. 上下文工程的重要性：

   • 支持观点：构建强大的AI代理不再依赖于寻找“魔法提示”或模型更新，而是依赖于上下文工程，即在正确的时间以正确的格式提供正确的信息和工具。
     • 引用："Building powerful and reliable AI Agents is becoming less about finding a magic prompt or model updates. It is about the engineering of context..." (评论1)
     • 引用："Context engineering is critical for agents, but I wonder if it’s also useful for shaping personality and improving overall relatability?" (评论19)
   • 反对观点：上下文工程可能只是“提示工程”的另一种形式，本质上仍然是“试错”过程，且“正确”的定义模糊。
     • 引用："If the definition of "right" information is "information which results in a sufficiently accurate answer from a language model" then I fail to see how you are doing anything fundamentally differently than prompt engineering." (评论6)
     • 引用："Finding a magic prompt was never “prompt engineering” it was always “context engineering”..." (评论20)

2. 上下文工程的挑战与局限性：

   • 挑战：长上下文可能导致“上下文腐烂”，需要技术如上下文隔离、修剪和总结来解决。
     • 引用："How Long Contexts Fail - talks about the various ways in which longer contexts can start causing problems (also known as "context rot")" (评论2)
     • 引用："Without proper context, you can’t tell if the output is correct." (评论16)
   • 局限性：上下文工程可能过于复杂，且未来可能被自动化或淘汰。
     • 引用："Cool, but wait another year or two and context engineering will be obsolete as well." (评论22)
     • 引用："There is no need to develop this ‘skill’. This can all be automated as a preprocessing step before the main request runs." (评论17)

3. AI项目的评估与工具使用：

   • 评估的重要性：AI项目需要评估，否则只是“猜测”而非迭代改进。
     • 引用："Evals are more important for AI projects than test suites are for traditional engineering ones." (评论3)
     • 引用："Without that raw context, it’s impossible to audit what really shaped the answer." (评论30)
   • 工具与流程：开发者可以通过上下文管理系统和工具（如Aider、Continue.dev）提升AI辅助开发效率。
     • 引用："I’m trying to figure out how to build a "Context Management System"..." (评论29)
     • 引用："I love that I can just brain dump into speech to text, and llms don’t really care that much about grammar and syntax." (评论29)

4. 对AI技术的怀疑与批评：

   • 怀疑：AI技术尚未达到“自明”的实用性，且过度依赖上下文工程可能是一种倒退。
     • 引用："The utility of a calculator is self-evident. The utility of an LLM requires 30k words of explanation and nuanced caveats." (评论13)
     • 引用："It’s insulting to call begging an LLM "engineering"." (评论15)
   • 批评：AI生成的代码质量不稳定，且可能加剧代码复杂性。
     • 引用："I almost always rewrite AI written functions in my code a few weeks later." (评论12)
     • 引用："Code quality can only drop as the project grows." (评论28)

总结：

上下文工程被认为是提升AI代理性能的关键，但其定义和实施仍存在争议。支持者认为它是解决复杂问题的必要手段，而批评者则认为它可能只是“提示工程”的另一种形式，且未来可能被自动化取代。同时，AI项目的评估和工具使用也被认为是确保成功的重要因素。尽管AI技术在某些领域表现出色，但其实用性和代码生成质量仍受到质疑。