提示词工程为什么正在变成上下文工程
提示词仍然重要，但长任务和 Agent 工作流更依赖上下文组织：指令、资料、记忆、工具、历史摘要、权限边界和验证信号要被放在合适的位置。
很多人第一次认真使用 AI，都会经历一个阶段：不断打磨一句提示词。把角色写清楚，把任务拆细，把格式说死，把语气限定好，再加几个例子。这样做当然有用。OpenAI 和 Anthropic 的官方资料都仍在强调清晰指令、示例、输出格式和迭代测试的重要性。
但当任务从“一问一答”变成“连续做事”，只靠一段提示词就不够了。一个 AI Agent 要读资料、查文件、调用工具、记住目标、处理多轮反馈、避开过期信息、在失败后恢复，还要把最终结果交给人审。这时问题不再只是“我该怎么问”，而是“模型在每一步应该看到什么、记住什么、暂时放下什么、什么时候去取新资料”。
这就是提示词工程正在扩展成上下文工程的原因。提示词仍然重要，但它已经从“全部方法”变成了“上下文系统里的一层”。更常影响长任务质量的，往往是指令、资料、记忆、工具返回、历史摘要、权限边界、验证信号如何被组织起来。
提示词工程没有过时
先把一个误会拿掉：上下文工程不是宣布提示词工程过时。相反，清晰提示词仍是最便宜、最直接、最容易被团队复制的改进方式。
OpenAI API 文档把 prompt engineering 定义为写出有效指令，让模型更稳定地产生符合要求的内容。文档还提醒，模型输出有非确定性，构建复杂应用时要固定生产模型快照，并用测试和评估来观察提示词行为。Anthropic 的 prompt engineering 文档也把提示词设计视为提升 Claude 输出质量的重要方法。
所以，如果你的任务是一次性总结一篇文章、改写一封邮件、生成一个表格、解释一个概念，提示词工程依然很有效。你需要写清任务、提供背景、给出格式、说明边界、提供少量高质量示例。
变化发生在更长、更动态的任务里。比如让 Agent 连续研究一个行业、整理十个网页、查 GitHub issue、改代码、跑测试、再根据失败日志修正。此时模型面对的不是一段静态输入，而是一条不断变化的工作流。提示词能告诉模型“要做什么”，却不能自动管理“每一步该带哪些信息上场”。
上下文工程解决的不是一句话，而是一整个工作台
可以把提示词理解成你对模型说的话，把上下文理解成模型当下能看见的工作台。
这个工作台上可能有八类东西：
第一，系统和开发者指令。它们定义角色、权限、风格、任务边界和不可触碰的规则。
第二，用户当前目标。它告诉模型本轮到底要完成什么，和旧目标相比有没有变化。
第三，任务资料。包括文档、网页、代码片段、表格、图片描述、会议记录、产品说明。
第四，对话历史。它保存用户已经说过的决定、偏好、纠错和补充条件。
第五，工具返回。搜索结果、数据库查询、API 响应、命令输出、测试日志，都属于这一层。
第六，记忆和状态。短期状态用于连续多轮，长期记忆用于跨会话偏好、项目规则和历史决策。
第七，输出格式和评估标准。它们告诉模型怎么交付，以及交付后如何判断是否达标。
第八，安全、权限和审计留痕。它们决定哪些动作需要确认，哪些证据必须保留，哪些信息不能进入公开内容。
提示词工程通常关注第一类和第七类。上下文工程要同时处理这八类，并且不断决定哪些进入模型窗口，哪些留在外部系统，哪些只保留摘要，哪些需要工具按需读取。
为什么长上下文并不自动等于好上下文
很多人会问：既然现在模型上下文窗口越来越长，为什么还要做上下文工程？直接把所有资料塞进去不就行了吗？
问题在于，长窗口只是容量变大，不代表信息自动变清楚。OpenAI Cookbook 关于 Agents SDK session memory 的文章提到，长任务里如果带入太多历史，模型可能被分散注意力、变慢、成本升高，甚至把早期错误继续放大；如果带得太少，又会失去连贯性。文章因此讨论 trimming 和 compression：裁掉不再需要的内容，或把历史压缩成更稳定的摘要。
Anthropic 在 effective context engineering for AI agents 中也强调，Agent 的工具集如果过大、功能重叠或边界模糊，会让模型难以判断何时调用哪个工具；示例也不应无限堆叠，而应挑选多样且有代表性的案例。它还提出 just-in-time context 的思路：不要提前把所有资料塞进上下文，而是让 Agent 保留文件路径、查询、链接等轻量索引，需要时再通过工具读取。
这说明上下文工程不是“把更多东西放进去”，而是“把此刻最有用的东西放进去”。有时你要多给背景，避免模型瞎猜；有时你要少给噪音，避免重要信息被埋掉；有时你要给工具入口，让模型自己去取；有时你要给摘要，让它保持连续性但不背着整段历史前进。
Agent 让上下文工程变成刚需
普通聊天里，模型通常只要回答当前问题。Agent 则要在多步行动中持续更新判断。OpenAI Agents SDK 的官方文档把 Agent 描述为带有指令、工具、handoff、guardrails、结构化输出等运行行为的大语言模型。SDK 还提供 sessions，用来在多轮运行之间维护会话历史。OpenAI 的 context management 文档进一步说明，LLM 能看到的数据来自对话历史；如果要让新数据可见，可以放进 agent instructions、runner input、函数工具，或通过 retrieval/web search 获取。
这几句话背后有个很实际的工程含义：上下文不是一个抽象名词，而是一个运行时设计问题。你要决定：
- 什么信息放在长期指令里，每次都带上；
- 什么信息作为本轮输入，只对这次任务有效；
- 什么信息不提前塞入，而是暴露成工具，让模型按需调用；
- 什么信息放进 session，支撑多轮连续；
- 什么信息只作为应用代码里的依赖，不直接给模型看。
如果这些边界不清，Agent 会很容易出现几类问题：旧目标覆盖新目标，工具返回太长导致重点消失，检索资料互相矛盾却没有标注来源，历史错误被摘要带到下一轮，权限信息混入可公开输出，或者模型在一堆相似工具里来回试错。
所以，上下文工程不是给提示词取一个新名字。它是 Agent 时代的任务环境设计。
一个好上下文通常有四个动作
LangChain 的 context engineering 资料把常见策略归纳为 write、select、compress、isolate。这个分类很适合普通团队理解，但要注意：它是工程归纳，不是所有厂商共同发布的标准。
Write，是把信息写到模型窗口之外。比如任务日志、用户偏好、项目规则、研究证据、测试结果、代码审查结论。写出去的目的不是让模型忘掉，而是让它有地方可查，不必每一轮都背着全部历史。
Select，是在需要时把相关信息选回来。比如本轮只看某个文件的函数定义，就不要加载整个仓库；只用三条来源证据，就不要塞十页搜索结果。选择能力越好，模型越像在整洁桌面上工作。
Compress，是把长历史压缩成短摘要。比如一次研究做了两小时，原始网页、工具日志和中间推理都很长，但下一轮重点看“已确认事实、未确认假设、引用链接、下一步”。压缩的风险是丢掉细节，所以摘要要保留证据路径和未决问题。
Isolate，是把不同任务隔离到不同上下文里。比如一个主控 Agent 负责目标、计划和验收，研究 Agent 只看来源资料，写作 Agent 只看结构和证据，审查 Agent 只看成稿和来源。这样每个模型窗口更专注，最后由主控整合结果。
从提示词清单到上下文清单
过去写提示词清单，常见条目是：角色、任务、格式、例子、约束、语气。现在做上下文清单，需要再加几层。
第一层，目标清单。当前任务是什么？成功标准是什么？哪些旧目标已经失效？用户最新纠正是否高于之前计划？
第二层，资料清单。哪些资料是官方来源？哪些是二手解读？哪些是过期资料？哪些只是类比？来源之间冲突时以谁为准？
第三层，历史清单。哪些历史必须保留？哪些只是聊天噪音？哪些是用户偏好？哪些是已废弃方案？
第四层，工具清单。模型可调用哪些工具？每个工具适合什么任务？输入输出是什么？失败时怎么处理？哪些工具需要人工确认？
第五层，记忆清单。什么写入短期 session？什么写入长期记忆？什么只留在本地任务包？什么不能写入公开文档？
第六层，验证清单。输出后怎么检查？事实如何核验？格式如何验证？图片、链接、代码、数据是否需要单独检查？
这套清单的价值，是让“多给一点上下文”变成可操作的系统。否则团队很容易在两个极端之间摇摆：要么只给一句提示词，指望模型自己补全世界；要么把所有资料塞进去，让模型在杂乱信息里找重点。
上下文工程的常见错误
第一个错误，是把上下文当附件堆。十个网页、二十段聊天、三份文档全塞进去，看似充分，实际会让重要信息失去位置。更好的做法是先标注资料层级：事实、观点、假设、案例、待核验内容分开。
第二个错误，是把长期规则和临时要求混在一起。长期规则应该稳定，比如安全边界、品牌口径、项目目录；临时要求只服务当前任务，比如本篇文章标题、本次输出格式。混在一起会让后续任务继承不该继承的限制。
第三个错误，是让工具返回原样灌进模型。搜索结果、日志、API 响应常常很长，里面有重复、广告、错误和无关字段。工具层应该先做清洗、截断、引用标注，再进入模型窗口。
第四个错误，是把摘要写得太漂亮。摘要如果只剩流畅文字，却丢掉来源链接、重要数字、未决风险，就会让下一轮模型看起来连贯，实际无法核验。好的摘要应该像任务交接单，少一点文采，多一点证据。
第五个错误，是没有隔离高风险上下文。权限、凭据、内部运维口径、未公开数据，不应该因为“给模型更多背景”就混进公开写作或营销内容。上下文工程要考虑可见性，而不是只考虑信息量。
普通使用者可以怎么开始
不写代码的人，也可以用上下文工程思路改进日常 AI 使用。
如果你让 AI 写报告，不要只发一句“帮我写一份行业分析”。可以先给它一个上下文包：目标读者、报告用途、时间范围、必须引用的资料、不能使用的资料、输出结构、事实核验要求、哪些结论只能写成假设。
如果你让 AI 做学习计划，不要每次重新讲背景。可以准备一份短期记忆：当前水平、已学内容、容易卡住的点、可用时间、偏好的练习方式、上次计划执行情况。每轮只更新变化。
如果你让 AI 做资料整理，不要把所有链接一次性丢进去。可以要求它先列来源表，区分官方文档、作者原文、媒体解读和社区讨论，再决定哪些来源进入正式摘要。
如果你让 AI 帮你写长期项目，不要只保存最终稿。要保存目标、版本、决策、证据、待办、未解决问题。下一轮从这些结构化上下文开始，而不是从一长串聊天记录里翻旧账。
这就是上下文工程对普通人的意义：它把“会提问”升级成“会布置工作台”。
对团队来说，上下文工程是一组协作规则
团队里的上下文更复杂，因为信息不只来自一个人。产品经理有需求文档，工程师有代码和日志，运营有用户反馈，法务有红线，管理者有关切，AI 工具有历史输出。谁的上下文进来，谁的上下文被过滤，谁负责验证，都需要规则。
一个可落地的团队做法，是为常见任务建立上下文模板。
研究类任务模板包括：研究问题、时间范围、来源优先级、排除来源、引用格式、事实/观点/假说区分、待复核清单。
写作类任务模板包括：目标读者、发布平台、选题边界、语气、必须保留的证据、不能出现的内部表达、图片需求、审稿节点。
代码类任务模板包括：仓库规则、改动范围、验证命令、测试要求、风险分级、人工确认点、失败恢复路径。
客服类任务模板包括：用户画像、产品版本、已尝试步骤、可承诺内容、不能承诺内容、升级路径、审计留痕。
这些模板不是为了束缚模型，而是为了减少每次从零解释的成本。提示词像一次口头交代，上下文模板像一张标准工单。任务越长、参与者越多，标准工单越有价值。
事实、假设和类比要分清楚
上下文工程这个词正在被很多文章使用，但不同作者的侧重点不完全一样。有些人强调 RAG 和检索，有些人强调 Agent 的工具和记忆，有些人强调长上下文压缩，有些人强调多 Agent 隔离。
本文采用的说法可以这样分层：
事实层：OpenAI、Anthropic、LangChain 等官方或技术资料都在讨论 prompt engineering、context management、sessions、tools、memory、retrieval、compression、isolation 等具体能力或策略。
工程归纳层：把这些能力归纳为“上下文工程”，并用 write、select、compress、isolate 来组织，是社区和框架文档里常见的工程表达。
类比层：把上下文比作“工作台”，把提示词比作“口头交代”，是本文为了帮助理解而使用的类比，不是技术定义。
这样区分很重要。AI 领域新词很多，容易把一个有用方法说成唯一答案。上下文工程不是万能答案，它解决的是“模型每一步看到什么”的问题；模型能力、任务设计、工具质量、数据质量、人类审查仍然会影响结果。
一份上下文工程清单
如果你准备把提示词工程升级为上下文工程，可以先问十个问题：
1. 当前目标和成功标准是否写清楚？ 2. 哪些规则每次都要带上，哪些只对本轮有效？ 3. 哪些资料是事实来源，哪些只是参考观点？ 4. 哪些历史必须保留，哪些应该删除或压缩？ 5. 模型需要哪些工具，工具边界是否清楚？ 6. 工具返回是否需要清洗、截断和来源标注？ 7. 哪些记忆要跨会话保存，哪些只留在本次任务？ 8. 哪些信息不能进入公开输出或普通模型窗口？ 9. 任务变长时，如何做摘要、交接和恢复？ 10. 输出后由谁核验事实、格式、风险和证据链？
结论：从“会问”到“会组织环境”
提示词工程教会我们把需求说清楚，这一步不会消失。上下文工程提醒我们，长任务里的 AI 不是只听一句话，它还在一个信息环境里工作。环境越清楚，模型越容易做对；环境越混乱，提示词写得再漂亮也会被噪音拖住。
未来一段时间，普通用户仍然需要学会写好提示词；团队则更需要学会管理上下文：资料从哪里来，历史怎么保留，工具怎么暴露，记忆怎么写入，摘要怎么压缩，风险怎么隔离，结果怎么验证。
AI 使用能力的分水岭，正在从“谁更会写提示词”，慢慢变成“谁更会组织上下文”。这不是把旧技能推翻，而是把它放进更完整的工作流里。会问问题，能让模型回答得更好；会组织上下文，才有机会让模型连续做事。