上下文工程：AI 的新系统设计范式

一场显而易见的架构变革正在发生

过去几年，大多数人把 AI 当作一个 API。

您发出一个提示，得到一个响应；若想更“高级”一点，再加上重试和少量日志，然后就称其为系统。做演示时这很有效，也让这一波应用得以迅速落地。但一旦您要构建一个需要长期运行的东西，这个模式就不再奏效。

生产级 AI 系统更像是进程，而不是 API。

一旦引入“延续性”，一切都变了。您不再处理单次请求-响应，而是在处理相互依赖的一系列交互。您需要记忆与状态，并且必须决定当下什么重要、五分钟前什么重要、明天什么仍应重要。

跨过这条线后，您会意识到，这不是什么“规模化的提示工程”。

这就是系统设计。

您真正构建的不是更好的提示，而是一个决定上下文如何被筛选并随时间演化的系统。这就是新兴的学科：上下文工程。

上下文不是提示

在调试器中打开任何一个生产级代理，看看某一轮实际发送给模型的是什么。几乎从来不只是用户消息。一个典型的请求大致如下：

用户消息是负载中最小的一部分。其他每个区块都是经过筛选后注入提示的。这些区块是您设计的管道的产物，即便您没意识到自己在设计一个管道。

这个管道才是真正的产品。模型是运行时。上下文工程就是管道的设计。

一旦接受了这一区分，架构就会截然不同。

记忆不是单一事物

“加记忆”是新的“加缓存”。听起来像一个特性，但其实是多个系统的合称。如果不做区分，您最终会得到一个用来回答所有问题却都答不好的大杂烩存储：该忘的地方不忘、该记的地方又过度执着。

第一刀切分来自认知科学，也正在成为从业者的共识： 短期记忆（STM） 与 长期记忆（LTM）。短期记忆就是当下上下文窗口内的内容，即模型此轮可见的工作集。

长期记忆是任何能跨越单次调用而存续的东西：事实、工件、计划、先前决策、工具输出和规则。短期记忆是预算问题；长期记忆是系统问题。

下面这五种都是长期记忆，按用途及存储方式来组织。它们与经典的语义记忆、情景记忆、程序性记忆的分类相对应，类似 CoALA 等受认知科学启发的框架。我将其中两类再细分，因为在生产中它们需要不同的治理方式。

策略记忆

规范性规则与约束。通常是全局或租户级范围。需版本化并严格管控。这是系统被允许去做的事：合规规则、品牌护栏、安全边界。它很少、且经过慎重才会变更。这属于认知科学意义上的程序性记忆，即跨会话塑造行为的规则与流程。在以文件系统为先的代理中，与 CLAUDE.md 或 AGENTS.md 这类文件同一类别。

偏好记忆

稳定的个性化参数。通常为用户范围。这个用户希望得到 JSON 响应，那个用户偏好项目符号列表，这个租户的日期格式为 DD/MM/YYYY。偏好记忆让系统无需每次重述就能表现得更贴合个人。与下文的事实记忆一起，构成语义层：对世界及其中事物的持久、可查询断言。

事实记忆

可供代理复用的持久断言，必须包含出处。“客户的生产数据库在 us-east-1”是一个事实，“他们的财年从四月开始”也是。事实是复利优势所在，也是最难设计的问题所在，因为每写下一条事实，都是对未来的下注。我把事实与偏好分开，因为尽管在认知层面都属语义记忆，但它们的写入路径、衰减曲线、治理要求都不同。

情景记忆

对已完成工作的结构化摘要。比如“案件已解决”或“迁移完成”。由系统从轨迹中提炼出的可复用工件。情景记忆让系统能够识别我们以前做过这件事并取回先前解法的轮廓。

轨迹记忆

原始的、仅追加的执行事件。这是您的“飞行记录仪”。体量大，主要用于检索与回放；当您想了解一个用户是什么样时，这里并不是正确的去处，只能看到他们做了什么。二者区别很重要，因为大多数团队将其混为一谈，最后靠在执行日志上做语义搜索来推断偏好。

在更粗的分类中，情景与轨迹记忆都归入情景范畴，包括会话转录、工具输出、运行历史。我之所以拆分，是因为在生产中，原始流与提炼摘要在访问模式、保留策略、成本曲线上迥然不同。将其视为同一物，团队就会为“在日志上 grep”付出向量数据库的价格。

工作记忆未出现在此列表中，因为它不属于长期记忆。它就是上下文窗口本身，是模型当前轮次实际可见的工作集。工作记忆真实且重要，大量最困难的应用机器学习工作如今都在这里：提示压缩、KV 缓存复用、滑动窗口注意力、哪些 token 有资格占用预算等算计。

但它按定义是瞬时的。将其与上述持久存储混为一谈，会导致将草稿本与权威记录放在同一数据库的架构。这不应发生。工作记忆应在每一轮由长期记忆组装而成，并在未被明确“晋升”时丢弃。晋升这一步是两层相遇之处，也是大多数有趣设计工作的发生地。

当有人说“我们的代理有记忆”时，问问他们指的是这五种中的哪一种。如果回答是“我们把一切都丢进向量库”，那您就找到了该代理在某些地方健忘、在另一些地方执念的原因。

循环，以及其中会出问题的地方

每个生产级 AI 系统最终都会收敛为同一种形态：一个循环。

这种形态并不具争议。大多数关于代理循环的描述都可归纳为五步：组装上下文、调用模型、采取行动、观察结果、更新记忆，然后重复。我对阶段的命名略有不同，因为我想将“组装上下文”的两半（吸收 vs. 选择）分开，并认为晋升应有独立名称，而不是被折叠进“更新记忆”。

但底层解剖是一致的。无论您从代理运行时、数据库，还是提示切入，都会看到同样的五个拐点。

ReAct 在 2022 年普及了推理与行动交替的模式；生产级代理系统此后将其扩展为上面的更广义循环。图示有助于理解，但要知道每个阶段的失败模式，才能明白工程时间该花在哪里。

Injest

Ingest 失败的原因是接受了过多。Ingest 是组装上下文的前半：从环境中吸收原始输入。把每个事件都当作潜在上下文，会制造出需要在检索阶段“返工”的噪声。此处的修为体现在边界：您在拒绝吸收什么？

Retrieve

Retrieve 的失败是悄无声息的。Retrieve 是上下文组装的后半：从长期记忆中选择当下相关的子集。它返回错片段时不会抛异常，只会让模型听起来有点“不对劲”。这是循环中最被低估的阶段，也是与系统感知质量最强相关的那一环。

纯语义搜索只是初稿。对大多数生产系统而言，基线是元数据过滤 + 词法/语义混合检索并重排序；在此之上，当任务具备组合性时，查询分解、图遍历与多跳检索会有帮助，但必须受限于延迟与评估预算。

推断与行动

推断与行动 在上下文驱动错误行为时失败。这一阶段将调用模型与采取行动合并在一起，因为规划与调用工具都源自组装好的上下文让模型决定要做什么。这里会遭遇长上下文的失败模式：夹在中间、近因偏见、上下文腐坏。

直觉会以为更多上下文应当单调提升响应质量：给模型更多信息，理应更好。现实中，更多 token 往往让模型更差。上下文预算如今是一门真功夫，“把我们有的一切都给模型”的本能，通常是错误答案。

评估

评估 是大多数系统压根没有的阶段。它通过观察行动的结果，将反馈引入系统。您需要知道响应是否有帮助、工作流是否成功、用户是否不得不纠正它。

即便没有显式捕获反馈，信号也客观存在。实践中效果不错的几种：下一条消息时间（很快的跟进通常意味着答案没打中）、您输出与用户实际发送或保存版本之间的编辑距离（小改动是噪声，大改动是纠正）、在工具结果出来后N 秒内的放弃（用户看了您产出的东西就走了）。

这些都不要求用户评分。它们只要求您为已经发生的行为埋点。此类隐式信号无处不在，但技术栈里没有组件在聆听。缺了这一步，循环就闭合不了：系统会运行，却永远不从自身产出中学习。

晋升

晋升是最容易做错的阶段。晋升是更新记忆中的一半，负责写回长期存储。大多数团队错误地过度写回，把一切都倒回去，进而污染了存储本身。您需要一份真正成文的策略，回答六个问题：

• 写回什么？
• 粒度如何？
• 写入哪种记忆类型？
• 具有什么样的出处信息？
• 采用怎样的衰减策略？
• 由谁授权？

这是最难做对、也是最关键的一步。

管道会终止。循环会复利。差别就在“晋升”。

您大概率已经在投产的反模式

如果您构建代理超过几个月，几乎肯定已经踩过其中好几个坑。我们团队早期的实验也被它们逐一“教育”，所以我很清楚它们从内部看是什么样子。

• 每一轮都倾倒完整对话记录：这是保存状态的懒办法。成本高得离谱，很快就遭遇上下文腐坏，并以用户抱怨为标志地、渐进式地劣化响应质量。规模化时，后台运行的压缩型总结器不是可选项；提示缓存应仅用于稳定前缀（系统提示、工具定义、静态策略块），而易变的检索负载应放在缓存段之后。
• 检索策略的上下文过载：检索侧的等价问题，是把检索当成“百宝箱”，拉取 top-20 片段并指望模型自己筛。它会把它们“平均化”，这比只选 5 个好片段更糟。
• 把草稿本当记忆：即工具调用结果、中间推理、生成的资产都会泄入长期存储，因为从未有人明确丢弃它们。您的“记忆”多半是尾气。
• 所有记忆共用一个存储：当系统用一个向量索引容纳一切：轨迹、事实、偏好、策略、情景摘要都在一处，检索无法区分，模型也不行。
• 永不遗忘的记忆：相反的失败是记忆从不遗忘：无 TTL、无衰减、无淘汰。仅几个月后，这会从资产变为负债。您能为系统添加的最佳行为之一，是激进的遗忘策略。
• 基于用户点赞来晋升：这是陷阱，因为最强的反馈信号也是最稀缺、最偏颇的。只在显式正向信号上晋升的系统，会学会为按钮点击而优化，而非为真实质量优化。
• 无回放能力：没有回放能力，调试就成了猜谜。您无法重现昨天的会话，因为记忆存储已经前进了。这类 Bug 会毁掉事后复盘。

为何这是系统设计，而不是“感觉工程”

值得称为“系统设计”的部分，并非心智模型本身，而是取舍权衡。每一个取舍都有一个“更容易上线但更难以为继”的错误答案。

Token 经济学正在驱动请求架构

提示缓存命中成本仅为未命中的一小部分：在 Anthropic 的 API 和 OpenAI 的新模型上常为标准输入价的 10%，在 Google 的 Gemini 上为 25%。这种定价重塑了请求中“把什么放在哪”的理性选择；对缓存友好的前缀、稳定的工具模式、固定的系统指令已不再是表面文章。

这将输入 token 的节省上限推至 4 倍到 10 倍之间（取决于服务商），且在代理式工作负载中还会叠加结构性复利（同一前缀每一步都会重发）。缓存策略得当，同一任务下，良好架构的代理成本可比糟糕架构者低数倍。这是 AI 工程里最接近“缓存行”的问题，但多数团队却把它当成 CSS 决策在处理。

检索是个架构问题

生产一线采用混合（词法 + 语义）、重排序、并进行查询重写。上限是代理式检索：模型在循环内自行发起并迭代搜索。两者之间的距离巨大，基准看不见，每次用户交互都看得见。如果您的检索只是一次 top-k 调用，那它就是让您的代理显得“笨”的原因。

上下文作用域是安全边界

多租户隔离、子代理沙箱、跨会话泄漏。这些不是事后的加固工作。如果子代理默认可见父代理的工作集，隐患已在，只是看是您先发现，还是对手先发现。

评估比以往任何系统都更难

有状态、随机性、路径依赖的系统无法做单元测试。您需要基于轨迹的评估、黄金检索集、针对版本化记忆快照的离线回放，以及同样版本化的“LLM 评审”。多数团队对此一无所有，几乎是盲飞。他们是在被用户告知后才发现上一次部署让质量回退了。

治理不是可选项，而且技术难度超出预期

一旦“了解用户的那个东西”是由上百次交互提炼出的事实，GDPR 下的“被遗忘权”就不再简单。从一个已将其吸收进事实记忆的系统里删除用户数据，意味着什么？欧盟 AI 法案又叠加了一层，其大部分义务（包括数据治理、人类监管、高风险系统的透明度要求）将于 2026 年 8 月生效。

到 2026 年下半年向欧洲交付 AI 产品的团队，需要回答一些业界尚未集体解决的问题：如何可证地移除用户对某一派生事实的贡献、如何审计一次记忆晋升的谱系、如何证明记忆存储的作用域与您所宣称的一致。

目前谁的答案都不够好。但系统必须可用，监管也不会等待行业自己摸索。

这就是为什么上下文工程关乎系统设计，而不是提示工程。多数有趣的工作发生在系统与系统的衔接处，即上下文从一个阶段传递到另一个阶段。几乎没发生在提示本身。而且上述几乎每个取舍都有一个看似便宜、却会在最糟糕时刻滚成技术债的“捷径”。

记忆层正在收敛到哪里

一旦您接受记忆是五种、且有多种访问模式，下一个显而易见的问题是：它们都该放在哪里？

“混合检索”，即词法 + 语义在同一系统中，如今基本已是解决问题。Elasticsearch、OpenSearch、LanceDB、Pinecone、Weaviate、以及 Postgres 的向量扩展都支持某种形式；它们之间的生产级差距没有厂商营销说得那么大。如果整个记忆层只是“嵌入 + 全文检索”，架构问题就很无聊了。

事实并非如此，因为记忆不只是检索。再看看这五种，注意每一种对其存储的真实需求。

您最终得到的“意外架构”会沿着最痛的轴线把它们分开。关系型数据放在 Postgres 或同类托管服务。混合检索放在 Elasticsearch、OpenSearch，或 Pinecone、Weaviate、LanceDB 这样的专用向量库。

轨迹被放进 S3 或时序数据库。它们各自都在其擅长的工作上表现强劲，许多生产栈也用得很好。问题不在某个单独组件，而在于每条有意义的检索路径都会跨系统“联合”：例如“找到与此查询相关的事实，并按该租户适用的策略过滤，作用域限定在此代理可见的用户”。这个联合跨越了三道边界：信任、事务、延迟。每当上下文跨过这些边界之一，您就重拾了原本想要避免的一致性问题。

这正是架构图景发生变化的地方。混合检索与关系型数据共处于同一存储中，才是区分能力，这与“仅有混合检索”是不同的问题。混合检索作为一个特性，正日益随处可得。

较少见的是在单一事务与安全边界下，共置关系型、文档型与向量数据，使策略、偏好、事实与情景记忆能够在 ACID 保证下共同查询，而非跨系统对账。

Oracle AI Database 是这种融合式多模型方法的一个例子：关系表、JSON 文档与向量嵌入都在一个引擎中，共用一条 SQL 语句、在同一事务里被查询。认真对待“五类型分类法”并开始画出策略、偏好、事实之间的关联后，问题就从“哪种检索引擎最好”转向“治理检索的关系型数据该住在哪里”。

实践中的样子，是一条 SQL 将关系型的策略数据、JSON 编码的偏好、以及事实记忆上的向量相似度联结起来。原本跨三个系统的查询被折叠为一条语句：

-- Find facts relevant to this question, scoped to the policies
-- and preferences that apply to this user, in a single query.
SELECT f.fact_text, f.provenance, f.created_at
FROM   fact_memory f
JOIN   user_preferences p
       ON p.user_id = :current_user
JOIN   tenant_policies t
       ON t.tenant_id = p.tenant_id
      AND t.is_active = 'Y'
WHERE  f.tenant_id = p.tenant_id
  AND  JSON_VALUE(p.prefs, '$.allow_personalization') = 'true'
  AND  f.access_level <= t.max_access_level
ORDER BY VECTOR_DISTANCE(
           f.embedding,
           VECTOR_EMBEDDING(MINILM USING :query AS DATA),
           COSINE
         )
FETCH FIRST 5 ROWS ONLY;

这一条语句同时在做四件事：强制执行租户策略、遵循用户偏好、按事实施加访问控制、并按语义相似度排序。在联邦式架构中，这意味着跨三个不同存储的四次往返，并且一致性模型要由您自己负责。

而在这里，它是一份查询计划、一个事务边界、一个审计位置。自 1970 年代以来让数据库成为共享状态“记录系统”的那些 ACID 保证，如今同样适用于包含行与向量的记忆。

该模式的可运行示例（包括具备混合搜索的代理式 RAG，以及关于上下文工程记忆架构的笔记本）可在Oracle 的 GitHub AI Developer Hub中找到。

少数场景您仍会需要专用存储。高体量的轨迹记忆在耐久性与成本特征上不同于您的业务数据库。大型资产（文档、图像、模型工件）的对象存储应放在为此而建的地方。对于需要该类别特有功能的强化文档工作流，专用文档数据库或许仍然合适。

重点不在于统一平台能消灭所有其他存储，而在于它消除了最昂贵的联合：关系数据（规定代理被允许做什么）与向量数据（影响代理实际做什么）之间的那一个。当二者共置，架构问题就从“如何保持这些存储同步”转向“如何设计好的记忆策略”，而后者才是关键所在。

对未来的七个预测

上述部分描述了我们的现状。以下是关于前路的押注，故意带有观点色彩。不同意就尽管不同意。

1. 模型不会成为记忆本身

诱人的说法是：模型提供商把记忆吸收入模型本体。长上下文窗口拉长、缓存更聪明、外部记忆层不再需要。这不会发生。上下文窗口会继续增长，但仍需在每一轮进行“预喂”。模型在每个会话中仍保持无状态，外部记忆层仍是记录系统。变的是外部记忆会更聪明（今天是向量库与混合平台，未来是我们尚未构建的东西），而上下文工程会成为一门手艺：决定模型在何时、为何看到什么。如果某前沿提供商交付了足以在生产中替代外部记忆系统的原语，这一预测就错了——我不押它会发生。

2. 成熟 AI 产品的记忆基础设施开销将超过推理

推理成本大约每 18 个月下降一个数量级。存储、检索、嵌入生成、重排序、以及按请求组装上下文则不会。它们随用户量、会话深度、交互历史而线性增长，这些都在上涨。云账单的主科目将从 GPU token 转向向量与混合检索基础设施。这会重塑自建 vs 采购的决策。记忆基础设施不像模型层那样易于商品化。长期赢家将是那些从第一天起就将记忆基础设施视为一等公民投资的团队。

3. 经典 RAG 将成为“遗留架构”

“嵌入文档、按用户查询 top-k、塞进提示”会成为 AI 架构的 COBOL。它好用、无处不在，但回望会令人尴尬。替代者已现：代理式检索，模型自行规划搜索、发起多步查询、阅读中间结果、决定下一步取什么。它更像研究过程，而不是数据库查找。今天仍在构建静态 RAG 流水线的团队，正走在迁移路上——不管知不知道。

4. 记忆将成为对抗面

记忆攻击的复利效应与提示注入不同。能写入长期记忆存储的对手，不论直接还是通过您未视为特权的输入通道，都能塑造该系统对所有后续用户的行为。外泄同理：由于作用域模型马虎，让一个会话的上下文泄漏到另一个。首个严重的现实世界“记忆投毒”事件就要发生。随后业界将围绕出处、背书、逐事实访问控制匆忙补课。

5. 上下文隐私边界将成为合规要求

从“上下文作用域是安全边界”的下一个逻辑台阶，是记忆分段的密码学隔离，让代理仅能基于“需知”原则披露上下文。一旦存在不同信任级别的子代理，或法规要求可证明地限定敏感事实的作用域，这就变得重要。预期第一份引用“代理记忆作用域隔离不足”的受监管行业审计结论将成为导火索，随后合规框架会跟进。已将密码学作用域纳入路线图的团队，将赢得依赖它的招标；没有者将被迫在期限压力下“补课”。

6. 多代理一致性将成为被命名且可预期的能力

今天，客服代理与计费代理触达同一客户账号，可能给出自相矛盾的答复，因为它们各自取了不同的记忆切片，且没有任何对账。目前这还可容忍，因为大多数生产部署是单代理。随着多代理系统规模化进入生产，用户会开始捕捉这些矛盾，“上下文一致性”将成为一个被命名的能力，平台将以此竞争。它会先出现在厂商对比矩阵里，再进入企业采购清单。早解的人将获差异化优势；忽视者将背负支持单，解释为何自家两个代理对同一客户说法不一。

7. “人均有用上下文”将成为可基准的指标

基准将从模型迁移到完整系统，头条指标会类似“每用户、每交互携带的有用上下文量”。这是真正能预测用户留存、以及“产品是否了解您”与“产品每周二就重置”的差距的数字。先在投资人演示中出现，再见于学术论文。一个相关指标是“每个有用上下文 token 的成本”，将成为值得回答的单位经济学问题。

周一就能做什么

如果您刚入门且需要一个起点：别再把记忆当作一件事。挑一个您能访问的生产代理，给它的各个存储按记忆类型打标签，留意某个存储被“一库三用”的频率。

如果您已经在构建代理：为循环埋点。尤其是检索与晋升之间的信号。我见过很多团队能告诉您某一轮系统检索了什么；能告诉您模型实际用了哪些被检索记忆的少之又少；几乎没有人能说清某次记忆为何被晋升。

知道哪些记忆被使用，才能在下一次晋升中强化它们——这正是记忆系统从“只写日志”变为“真正学习”的方式。

这个反馈回路是复利优势所在，也是接下来这门学科里最有意思工作的发生地。

所有团队几乎在同一时间拿到同样的前沿模型。没人能复制的，是您围绕它们所构建的记忆层：它由您的用户、您的抉择、以及您对“值得记住什么”的判断所塑造。

模型是共享的。记忆系统是您的。