提示词工程(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自身出现了推理错误。
这两种失败模式的修复方案截然不同，准确定位问题是优化的第一步。
