AI新技能不是提示工程，而是上下文工程
上下文工程（Context Engineering）是AI世界中一个新兴且备受关注的术语。讨论正在从"提示工程"转向一个更广泛、更强大的概念：上下文工程。Tobi Lutke将其描述为"为任务提供所有上下文，使LLM能够合理解决问题的艺术"，他说得很对。
随着AI代理（Agents）的兴起，我们加载到"有限工作记忆"中的信息变得更加重要。我们发现，决定AI代理成功或失败的主要因素是你提供给它的上下文质量。大多数代理失败不再是模型失败，而是上下文失败。
什么是上下文？
要理解上下文工程，我们必须首先扩展对"上下文"的定义。它不仅仅是你发送给LLM的单个提示。可以将其视为模型在生成响应之前看到的所有内容。
上下文的组成部分
为什么重要：从简单演示到神奇产品
构建真正有效的AI代理的秘诀与你编写的代码复杂性关系不大，而与你提供的上下文质量有着密切关系。
构建代理与你编写的代码或使用的框架关系不大。简单演示和"神奇"代理之间的区别在于你提供的上下文质量。想象一个AI助手被要求根据一封简单的邮件安排会议：
嘿，看看你明天是否有空进行快速同步。
"简单演示"代理
上下文质量差
它只看到用户的请求，别无其他。其代码可能功能完善——它调用LLM并获得响应——但输出无益且机械化：
"感谢您的消息。明天对我来说可行。我可以问一下您想的是什么时间吗？"
"神奇"代理
丰富的上下文
代码的主要工作不是弄清楚如何响应，而是收集LLM完成目标所需的信息。在调用LLM之前，会扩展上下文以包括：
- 你的日历信息（显示你完全被占满）
- 与此人的过往邮件（确定合适的非正式语调）
- 你的联系人列表（识别他们是重要合作伙伴）
- send_invite或send_email的工具
"嘿Jim！明天我这边时间很紧，一整天都是背靠背的会议。周四上午有空，如果可以的话？已发送邀请，告诉我是否可行。"
关键洞察：神奇之处不在于更智能的模型或更巧妙的算法，而在于为正确的任务提供正确的上下文。这就是为什么上下文工程如此重要。代理失败不仅仅是模型失败；它们是上下文失败。
从提示工程到上下文工程
什么是上下文工程？虽然"提示工程"专注于在单个文本字符串中制作完美的指令集，但上下文工程要广泛得多。让我们简单地说：
上下文工程是设计和构建动态系统的学科，这些系统在正确的时间，以正确的格式提供正确的信息和工具，为LLM提供完成任务所需的一切。
上下文工程的特点：
- 系统，而非字符串：上下文不仅仅是静态的提示模板。它是在主要LLM调用之前运行的系统的输出。
- 动态的：根据即时任务即时创建，量身定制。对于一个请求，这可能是日历数据，对于另一个请求，可能是邮件或网络搜索。
- 关于在正确时间提供正确信息和工具：核心工作是确保模型不缺少关键细节（"垃圾进，垃圾出"）。这意味着只在需要和有帮助时提供知识（信息）和能力（工具）。
- 格式很重要：如何呈现信息很重要。简洁的摘要比原始数据转储更好。清晰的工具架构比模糊的指令更好。
结论
构建强大可靠的AI代理越来越少地依赖于寻找神奇的提示或模型更新。而是关于上下文的工程化，在正确的时间，以正确的格式提供正确的信息和工具。这是一个跨职能的挑战，涉及理解你的业务用例、定义你的输出，并构建所有必要的信息，以便LLM能够"完成任务"。
致谢
本概述是在深入手动研究的帮助下创建的，从几个优秀资源中汲取灵感和信息，包括：