提示词工程(Prompting engineering)
-
目标：写出清晰、明确的指令
-
提示词本质是布置任务的指令，让AI按预期方式回答问题、执行任务...
-
目标：准备好一切AI该知道的信息
-
上下文本质：告诉AI当前的「需要什么」、「能做什么」，就像游戏的任务设定一样，提供所需要的信息、工具和历史记忆，然后交给AI来思考和执行...
-
提示工程：怎么做 -
上下文工程：准备“做成的条件”
-
提示词工程依赖精细指令，不仅难以复用，还容易因措辞差异导致结果波动，对写Prompts的人要求也更高
-
上下文工程让AI具备持续理解和应变能力，不仅能适应新任务，还能保持输出稳定、不易“翻车”
使用Agent时，常常遇到棘手问题：
-
为什么智能体这么不稳定？并归咎于模型本身不够强大。
然而，问题的根源：未能向模型提供恰当上下文。
-
智能体无法可靠地执行任务时，根本原因通常是未能以正确格式向模型传递正确的信息、指令和工具。
随着LLM应用从单一提示词演变为复杂的、动态的智能体系统，“上下文工程”（Context Engineering）正迅速成为AI工程师重要技能。
Cognition 团队核心观点
“再聪明的模型，若不知上下文，也无法做出正确判断。”
智能体系统的失误，本质是 LLM 失误。
从第一性原理分析，LLM 失败主要源于两个方面：
-
底层模型能力不足，无法正确推理或执行。 -
模型缺少正确判断所需的上下文。
随着模型能力的飞速发展，第二点成为更普遍的瓶颈。
上下文供给不足体现在：
-
信息缺失：模型完成任务所依赖的关键信息未被提供。 -
格式混乱：信息虽然存在，但其组织和呈现方式不佳，阻碍了模型的有效理解。
LLM无法读取用户思想，如果不提供完成任务所需的关键信息，不可能知道这些信息的存在。
在很多场景下，LLM需要借助工具来查询更多信息或执行某些动作。为LLM提供正确的工具，与提供正确的信息同等重要。
格式化至关重要：与人类沟通类似，如何向LLM传递信息，其格式会极大地影响结果。
一个简短但描述清晰的错误信息，远比一个庞大而杂乱的JSON数据块更容易让LLM理解和处理。这一点同样适用于工具的设计，工具的输入参数是否清晰、易于理解，直接决定了LLM能否有效使用。
提示词 → 上下文
前段时间, Andrej Karpathy等人提出,应该用Context Engineering替代Prompting Engineering的说法...
大模型应用技术从“提示词艺术”迈向“上下文科学”。
最近爆品，如Cursor，Manus等产品都表明
-
一个卓越的大模型产品，背后必然是精心设计的上下文工程系统。
未来核心竞争力，不再是精妙的提示词，更是高质量、高效率的上下文。
通过精心组织，为模型提供事实依据、注入持久记忆、并扩展其行动能力，有可能释放大模型的潜力，构建出新的有价值AI产品。
上下文工程
-
构建动态系统，以正确格式提供合适的信息和工具，使 LLM 能够合理地完成任务。
上下文工程（Context Engineering）核心定义：
-
构建一个动态系统，以正确格式提供正确的信息和工具，从而使大语言模型（LLM）能够可靠地完成指定任务。
深入理解：
-
系统工程：复杂智能体从多个来源获取上下文，包括开发者预设、用户输入、历史交互、工具调用结果以及外部数据。将这些信息源有机地整合起来，本身就是一个复杂的系统工程。 -
动态变化：上下文组成部分很多是实时生成。最终输入给模型的提示（Prompt）也必须是动态构建的，而非静态的模板。 -
信息精准：智能体系统失败的原因之一是上下文信息缺失。LLM 无法“读心”，必须为其提供完成任务所需的全部信息。所谓“垃圾进，垃圾出”，信息质量直接决定输出质量。 -
工具适用：很多任务无法仅靠初始信息完成。为 LLM 配备合适的工具就变得至关重要，用于信息检索、执行动作或与其他系统交互。提供正确的工具与提供正确的信息同等重要。 -
强调格式规范：与 LLM 的“沟通方式”跟人一样关键。简洁明了的错误信息远胜于一个庞杂 JSON 数据块。工具的参数设计、数据的呈现格式，都会显著影响 LLM 的理解和使用效率。 -
任务可行性：设计系统时，应反复自问：“在当前提供的上下文和工具下，LLM 是否真的有可能完成任务？” 便于归因分析，上下文不足，还是模型本身的执行失误，从而采取不同的优化策略。
提示工程 vs 上下文工程
为什么从“提示工程”（Prompt Engineering）转向“上下文工程”？
LLM应用早期，开发者专注于通过巧妙措辞诱导模型给出更好的答案。
但随着应用变得越来越复杂，共识逐渐形成：
-
向AI提供完整和结构化的上下文，远比任何“魔法般”的措辞都重要。
提示工程是上下文工程的子集。
即使有全部上下文信息，提示词组织、编排方式，仍然至关重要——提示工程范畴。
核心区别：
-
上下文工程：设计架构，动态地收集、筛选和整合来自多源的数据，构建出完整的上下文。 -
提示工程：已有上下文的基础上，设计格式化和指令，以最优方式与LLM沟通。
不同于传统 Prompt Engineering，Context Engineering 更关注系统级的动态上下文构建。
-
强调：在复杂交互和多智能体协作中，如何为每个 Agent 构建精准、独立、可持续的任务背景，是系统能否稳定运行的关键。
上下文系统由多个关键部分组成
上下文工程是一个动态系统
复杂智能体系统从多个来源获取上下文：
-
应用开发者：预设的系统指令和行为准则。 -
用户：当前任务的直接输入和要求。 -
历史交互：先前对话的记忆或摘要。 -
工具调用：通过API或函数调用获取的外部信息。 -
外部数据：从数据库或知识库中检索的文档。
将所有这些信息整合在一起，需要一个复杂的系统。
-
提供正确的信息与工具 -
格式化至关重要 -
自检：反复确认信息是否充分
而且必须动态，因为许多上下文信息是实时变化的。
因此，最终交付给LLM的提示词（Prompt）不是静态模板，而是由动态逻辑实时构建的。
好的上下文工程应该包括：
-
工具使用：当一个智能体访问外部信息时，需要拥有能够访问这些信息的工具。当工具返回信息时，需要以 LLM 最容易理解的方式对其进行格式化。 -
短期记忆：如果对话持续一段时间，可以创建对话摘要，并在未来使用该摘要。 -
长期记忆：如果用户在之前的对话中表达了偏好，需要获取这些信息。 -
提示工程：在提示中清楚地列举智能体应该如何操作的说明。 -
检索：动态地获取信息，并在调用 LLM 之前将其插入到提示中。
正确的信息与工具
进行上下文工程时，应反复确认：
-
“以当前提供的上下文，LLM真的能合理地完成任务吗？”
这个问题能保持清醒，认识到LLM不是万能的，要为创造条件。同时，有助于区分两种主要的失败模式：
-
失败模式一：没有提供足够或正确的信息/工具，导致LLM失败。 -
失败模式二：提供了所有必要的信息和工具，但LLM自身出现了推理错误。
这两种失败模式的修复方案截然不同，准确定位问题是优化的第一步。
参考：
LangChain 官方博客文章《The Rise of "context engineering"》, https://blog.langchain.com/the-rise-of-context-engineering/
译文：https://zhuanlan.zhihu.com/p/1920981931920693117
相关文章
