上下文工程

它是什么

上下文工程是在模型每次推理前，选择、组织并维护合适信息集合的实践。它管理的不只是提示词，还包括消息历史、工具定义与结果、检索资料、任务进度和外部状态。[S1] 提示词工程主要关注指令怎样表达；上下文工程进一步决定当前这一轮究竟让模型看到什么。

为什么需要它

多轮任务会不断产生新信息，但上下文容量和模型注意力都有限。若把所有历史、文件和工具结果原样堆入请求，关键约束可能被冗余内容淹没，成本和时延也会增长。上下文工程的目标不是让输入尽量长，而是让完成当前步骤所需的信息足够、可信且容易找到。

它如何工作

应用先识别当前目标和验收标准，再为指令、证据、历史与输出预留预算；稳定规则放在清楚的位置，外部资料按需检索，过时工具结果被移除或摘要，关键决策则写入可持续状态。任务每推进一步，应用都重新判断哪些内容应保留、更新或退出。Anthropic 将这种过程概括为在推理时持续策展和维护最合适的 Token 集合。[S1][S2]

必须澄清的误会

上下文工程 ≠ 上下文窗口。 上下文窗口是容量上限，上下文工程是在这个上限内决定放什么、按什么顺序放、什么时候丢掉；窗口大不等于上下文好。

上下文工程 ≠ 提示词模板。 模板固定的是「哪段文字反复用」，上下文工程决定的是「这一次该给模型哪些信息」——检索结果和历史塞不进模板。

它不解决资料对不对。 上下文工程的产出是「模型看到了什么」，不是「这些内容是否正确」。把无关甚至过期的资料整理得井井有条，只会让错误答案更顺畅。

真实例子

一个售后助手处理退款争议时，不需要加载全部客服知识库。它可以保留退换规则与用户身份状态，按订单号检索本次订单，只带入最近相关对话和刚返回的物流结果，并把已经完成的排查步骤压缩成简短记录。进入退款工具前，再补入权限要求和金额限制。每一步看到的上下文都围绕当前决策变化。

什么时候适合与不适合

上下文工程适合多轮代理、长文分析、工具密集任务和需要动态证据的应用。一次性、输入很短的任务可能不值得建立复杂管线。它也不能弥补错误来源：筛选得再精细，虚假资料仍是虚假资料。上下文编辑还可能删除后续需要的细节，因此必须保留可追溯原始状态并测试召回失败。[S2]

亲自试一下

选择一个真实工作流，把一次请求中的内容分成“稳定指令、当前任务、必要证据、历史状态、工具定义、工具结果”六类，并记录各自 Token。为每类写出保留、按需加载、摘要和删除条件。用三个固定任务验证精简前后结果；只有关键事实与成功率不下降，精简规则才可采用。

接下来学什么

先学习上下文窗口理解容量边界，再用检索上下文决定外部证据如何进入请求；任务持续变长时，继续学习上下文压缩处理历史增长。

来源与修订

上下文工程的整体定义、迭代策展和高信号原则参考 Anthropic 工程文章 [S1]；选择性清除、摘要替换与客户端保留完整历史的实现边界参考上下文编辑文档 [S2]。具体 API 参数和推荐策略会随版本变化，正文不固化配置字段。