转载提示：本文转载自 原文。原作者：Philipp Schmid。原文发布日期：2025-06-30。本文已按站点规范移除推广/导流内容，仅保留核心观点、论证链路与示例。AI 的新技能不是 Prompt Engineering，而是 Context Engineering “Context Engineering” 这个概念正在 AI 领域快速升温。讨论重心正在从“怎么写一条好 prompt”，转向更强也更系统的能力：Context Engineering。正如 Tobi Lutke 所说，它是“为任务提供全部上下文，让 LLM 有现实可行的完成路径”的艺术。 随着 Agent 进入实战，真正决定成败的往往不是模型参数，而是你喂给它的上下文质量。很多 Agent 失败并不是“模型不行”，而是“上下文给错了或给不够”。什么是“上下文”？ 要理解 Context Engineering，首先要扩展对“上下文”的定义。它不只是你发给模型的一段文本，而是模型在生成答案之前能够看到的一切。 ContextInstructions / System Prompt：系统级指令、规则、示例，定义模型在会话中的行为边界。User Prompt：用户当前的具体任务请求。State / History（短期记忆）：当前对话中的历史消息与中间过程。Long-Term Memory（长期记忆）：跨会话沉淀的偏好、项目摘要、事实记忆等。Retrieved Information（RAG）：从文档、数据库、API 检索到的外部知识。Available Tools：模型可调用的工具定义与约束（如 send_email、check_inventory）。Structured Output：输出格式约束，例如 JSON schema。为什么重要：从“廉价 Demo”到“魔法产品” 高质量 Agent 的关键，并不在于你写了多复杂的控制逻辑，而在于你提供了多高质量的上下文。 假设 AI 助手收到邮件：“Hey, just checking if you’re around for a quick sync tomorrow.” Hey, just checking if you’re around for a quick sync tomorrow. 廉价 Demo 型 Agent 上下文贫乏，只看到这句请求，因此回复通常机械、泛化： Thank you for your message. Tomorrow works for me. May I ask what time you had in mind? “魔法感” Agent 的核心工作不是“替模型思考”，而是先把任务相关上下文补齐：日程信息（你明天其实全天排满）。你和对方过往邮件（语气应更自然）。联系人信息（识别其业务重要性）。可执行工具（发邀请、发邮件等）。 然后才让模型生成回复： Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works. 真正的“魔法”不是更聪明的模型，而是在正确时间给出正确上下文。从 Prompt Engineering 到 Context Engineering Prompt Engineering 主要关注“把一句提示词写得更好”，而 Context Engineering 更像一整套系统工程： Context Engineering is the discipline of designing and building dynamic systems that provides the right information and tools, in the right format, at the right time, to give a LLM everything it needs to accomplish a task. 它的核心特征是：系统，而非字符串：上下文由一个“前置系统”动态组装出来，而不是静态模板。动态生成：同一个 Agent 在不同任务下，应注入不同上下文。信息与能力并重：既要提供知识，也要按需暴露工具能力。格式就是性能：结构化、压缩过的信息，通常比原始堆叠更有效。结论 构建可靠 Agent 的竞争点，正在从“找到魔法 prompt”转为“工程化上下文系统”。这要求你同时理解业务目标、输出约束和信息编排方式，把模型真正需要的内容在正确时机交付给它。致谢与参考 本文观点参考并吸收了以下资料：Tobi Lutke tweetKarpathy tweetThe…