← 返回概念解读

Concept Fable精修版

上下文工程

Context Engineering · System design

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

给裁判递材料的书记官

王城每月审案,裁判坐在高台上,书记官负责把卷宗递上去。早年案件简单,一张状纸、两份证词,裁判看完便能判。

后来商路繁杂,案卷堆成小山。有的争执牵涉旧契,有的要看港口规矩,有的还夹着十年前的判例。书记官起初把所有纸都搬上案头,觉得越全越稳。

裁判很快被淹没。关键证词埋在税单下面,最新口供和过期契约混在一起,判决变慢,还常被无关细节带偏。

书记官第一次修补,是把卷宗剪短。案头清爽了,却漏掉一张边角批注,正是判定货权的关键。被告当场翻出原件,堂上陷入尴尬。

老书记没有继续在“多”和“少”之间摇摆。他先问裁判下一步要判断什么,再按问题摆材料:事实放前面,依据紧随其后,旧例只保留相似处,冲突证词并排呈现。

他还给每份材料贴上来处、时间和可信度。裁判不必猜哪张纸更近,也不必在一堆杂物里找线索。若案情转向,书记官会重新组织,而不是原封不动再搬一摞。

王城审案终于快了起来。大家明白,递材料不是堆纸,也不是删纸,而是围绕眼前判断,把相关、顺序、来源和边界安排到位。

新书记入门时,老书记不让他先练搬卷宗,而是让他练提问:裁判此刻要判断身份、责任、金额,还是时效?问题不同,材料的排列就不同。真正的本事藏在选择和组织里,让有限案头承载足够判断,而不是让纸堆替人思考。 后来裁判也更信任书记官,因为他递来的不是一堆热心材料,而是一份能支撑当前裁断的案头环境。材料进来、排好、删去、标明来源,都是为了让判断在有限注意力里成立。 后来许多复杂案子能判清,不是因为纸少了,而是因为案头终于围着问题展开。 这句话后来被写进新人的手册里,提醒大家先看现场代价,再谈省力。 也正因为这层提醒,后来再遇到相似难题时,众人不会急着套旧办法。

揭示

这个故事讲的是:上下文工程

Context Engineering 是为模型选择、组织、压缩、更新和隔离上下文的工程实践。它比传统 Prompt Engineering 更宽:不仅写指令,还处理记忆、检索、工具结果、任务状态、权限边界、来源可信度和 token 约束。企业 Agent 的可靠性很大程度取决于上下文工程,因为模型只能基于进入当前请求的信息行动。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 裁判:大语言模型或 Agent 决策核心
  • 书记官:上下文工程层
  • 所有纸张抱上案桌:无选择地填充上下文
  • 分层卷宗:系统指令、任务状态、证据和记忆的结构化组织
  • 来源可信度:上下文的元数据和信任边界
  • 检查检索、摘要、旧记忆:上下文质量诊断
  • 最后洞察:Context Engineering 是决定模型能看见什么、如何理解什么的工程

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

prompt engineeringmemoryretrievalcontext windowscratchpadsystem prompt

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。