上下文工程（Context Engineering）
也叫： 上下文管理
上下文工程是指决定模型在某一步的上下文窗口里究竟放哪些信息——系统指令、可用工具、检索到的文档、历史对话、记忆——并管理这些内容的结构和时效性的一整套实践。
如果只是聊一轮对话，想让模型答得好，很大程度上靠的是『把话说清楚』：提示词写得好，回答自然就好。这就是提示词工程（prompt engineering）关心的事——打磨一句指令的措辞，和 react-prompting 是近亲话题。上下文工程要解决的问题更大，是随着人们开始搭建能连续跑很多步的 Agent 才逐渐冒出来的说法：光写好一句提示词不够，还得决定模型在每一步实际看到的其他所有东西——系统指令、开放了哪些工具、检索回来的是什么文档、多少轮历史对话被保留下来、从记忆里调出了什么、又附带了哪些文件内容。
这个词到 2026 年已经是从业者中相当常见的说法，但它并不是一门有固定方法论、有权威机构定义的成熟学科——不同团队对『提示词』和『上下文』的边界划法也不完全一致。但大家的共识是这个核心转变：提示词是你为某一轮对话专门写的一段文字；上下文则是模型实际看到的完整输入，其中大部分内容是由 Agent 的运行框架（harness）在会话过程中自动拼装、动态更新的，而不是人手动写死的。
这件事对 Agent 场景特别重要，普通一问一答的聊天反而不太需要操心——因为 Agent 的上下文会不断累积。一个已经连续跑了几十轮的编程 Agent，读过文件、跑过命令、收到过各种工具返回结果,这些东西都可能一股脑堆进上下文窗口。运行框架或开发者选择原样保留、做摘要压缩、还是直接丢弃，会直接影响两件事：每一步的成本（上下文越长，消耗的 token 越多）,以及 Agent 实际的行为表现——过时或不相关的上下文会干扰模型判断、甚至让它依据旧信息行动；上下文留得太少,又会让它重复劳动或忘记之前提过的约束条件。
怎么运作
具体到实践中，上下文工程要处理的是几类反复出现的取舍：哪些内容该写进系统提示词，哪些该等用到时再实时取；到底要开放哪些工具（tool-manifest 精简一些，往往比塞满所有工具更容易让模型用好）；检索回来的文档或文件内容要怎么筛选到只剩相关部分，而不是整段塞进去；较早的对话轮次什么时候该做摘要或截断以控制上下文长度；以及跨会话时,agent-memory 里要写入什么、又读回什么。这些都不是一套固定不变的技巧,更像是 coding-agent-harness 或某个具体的 skill 定义必须持续打磨的工程活儿,而且往往随着会话变长,策略也要跟着变。
举个例子
假设一个编程 Agent 正在做一次持续好几个小时的重构，跑到一半。它的上下文窗口里可能包含：最初的任务描述、二十轮之前做出的决策的摘要（而不是完整对话记录）、当前正在改的三个文件的内容、上一次测试运行的输出，以及一份精简的可用工具清单。一个典型的上下文工程决策是：测试跑通之后，把详细的测试输出丢掉，只留一行结论摘要，给下一个要读的文件腾出空间。
和相关概念的区别
上下文工程常被和 agent-memory 搞混，但两者解决的是不同问题。Agent 记忆是存储本身——往往是外部、持久化的（数据库、文件、向量库），保存跨步骤、跨会话的信息。上下文工程则是持续地决定，从记忆以及其他一切来源中，此刻要把哪些内容拉进模型的上下文窗口。记忆负责『信息存在哪里』，上下文工程负责『这一步到底该让模型看到什么』。
常见误解
常见问题
上下文工程和提示词工程有什么区别？
上下文工程是 Anthropic 官方定义的术语吗？
为什么上下文工程对 Agent 比对普通聊天机器人更重要？
最近核实： 2026-08-28