上下文工程：企业 AI 为什么不能只靠提示词

上下文工程设计的是 AI 系统被允许知道、看到、记住、检索和执行的一切::而不只是提示词怎么写。Google Cloud 对它的定义是：设计 AI 运行于其中的结构化数据环境::数据管道、记忆、检索和工具连接，而不是手工调优的文本。Anthropic 的工程团队从 agent 侧得出同样的结论：agent 系统里脆弱的部分几乎从来不是模型，而是你喂给它的上下文。

如果你的 AI 在 demo 里一切正常、一碰真实的企业数据、权限和流程就崩，缺的那层几乎从来不是模型，是上下文架构。

什么是上下文工程？

最短有用的定义是一个减法：

提示词工程
= 你对模型说了什么

上下文工程
= 系统允许模型知道、看到、
  记住、检索、执行什么

提示词活在单次请求里。上下文活在整个系统里：模型看到的是哪份价格表、谁的权限生效、对话之前发生过什么、它可以查哪个 ERP、答案是否必须给出处。

demo 里，提示词和数据都由你控制。生产环境里，数据归业务管::它每小时都在变、它自己跟自己打架、不同的人被允许看到不同的部分。提示词解决不了模型根本没被允许看见的问题。

上下文工程 vs 提示词工程

	提示词工程	上下文工程
范围	单次请求	整个 AI 环境
知识	提示词里塞得下的	检索回来的企业数据，受治理
记忆	通常是临时的	被设计和控制
权限	几乎不涉及	核心架构
工具	可选	显式治理
更新	手工改提示词	从实时系统动态更新
生产可用性	有限	高

这不是说提示词工程没用。而是说它只是一层::最容易被抄走的一层，最不构成壁垒的一层。竞争对手一个下午就能复刻你的提示词。他们没法那么快复刻你的检索、你的权限模型、你治理过的知识库。

企业 AI 上下文的七层

KifferLiu 做部署时，会把上下文当作七层来审计。我们称之为 Enterprise Context Stack::这是我们用于真实部署的工作模型，不是行业标准。把它当清单用，别当圣经。

1. 指令           系统规则、语气、转人工策略
2. 身份           谁在问、角色、部门、语言
3. 业务知识       产品、价格、政策、手册
4. 检索           正确的知识如何被找到
5. 记忆           系统跨会话记住什么
6. 工具与实时数据 ERP、CRM、计算器、实时查询
7. 权限与出处     谁可以看什么、答案出自哪份来源

1. 指令。 系统 prompt：助手如何表现、必须拒绝什么、什么时候升级给人。必要，但永远不充分。

2. 身份。 同一个问题，对销售、工程师和客户有不同的正确答案。上下文工程把身份变成显式输入，而不是靠猜。

3. 业务知识。 产品规格、价格表、技术手册、政策::清洗、去重、版本化。脏活大部分发生在这层，我们把它单独当成一门学科：知识治理。

4. 检索。 哪些片段被拉进模型、从哪里、按什么排序。RAG 活在这里。

5. 记忆。 会话之间延续什么：偏好、未关工单、历史报价。企业通常要的是可控可查的记忆，不是无限记忆。

6. 工具与实时数据。 计算器、ERP 查询、CRM 写入。任何数字类问题，一次工具调用都好过检索文本。

7. 权限与出处。 谁可以看哪个答案，每个论断可追溯到一份带日期的来源。这是 demo 跳过、审计要求的层::也是带引用的 AI 回答之所以可能的那层。

我们看到的大多数失败试点，投入几乎全在第 1 层和第 4 层，然后在生产环境里撞上其余五层。

为什么提示词很好，企业 AI 还是失败

三个场景，全部来自制造企业部署中的真实模式：

过期价格表。 提示词写得非常好。检索层自信地捞出法务八个月前就叫停的 2023 版出口价格表。模型流利地答错，而且因为它很自信，没人复查::直到某个客户复查了。

两个员工，同一个问题。 销售问某个返单的毛利；实习生问同一个问题。没有身份和权限层，两人拿到同一个答案::包括实习生永远不该看到的成本拆解。系统没有幻觉，它只是对错误的受众准确。

ERP 动了。 库存、交期、汇率天天在变。任何写死在提示词或静态索引里的东西，上线第二天就开始偏离事实。只有实时工具访问加上被维护的知识层能保持现行。

这三条没有一条是提示词能修的。它们是架构问题，只服从架构。

RAG 与上下文工程

RAG 是这个栈里的一层，而人们很容易把它当成全部。不是：

好的检索
≠
好的企业上下文

检索决定你能不能找到对的那份文档。上下文工程决定这份文档是否现行、这个用户是否可以看它、更新的答案是否其实在 ERP 里、回答是否展示来源。一个指向未治理知识的检索系统，是在用机器速度自动化你们公司的不一致。这就是为什么我们把知识治理当作前提，而不是事后清理。

AI Agent 与上下文工程

当系统开始执行动作::写 CRM、生成报价、触发流程::第 2、6、7 层就不再是便利功能，而是安全架构。一个 prompt 打磨得很亮、上下文不受管理的 agent，可以检索到过期价格、套用到错误的客户分层、然后把它发出去。失败已经从答案层转移到业务层。

控制侧::身份、权限、审批环、审计、急停::我们单独写在《AI Agent 治理》里；检索策略侧见《Agentic RAG vs 传统 RAG》。

一个实用的上下文工程架构

对一家中型制造企业，我们最终搭出来的架构通常长这样：

用户
 ↓
身份（谁在问、角色、语言）
 ↓
意图（他到底在问什么）
 ↓
上下文编排器
 ↙        ↓        ↘
知识库         CRM   ERP / 实时系统
（受治理）
 ↓
权限校验（这个用户可以看吗？）
 ↓
大模型（指令 + 组装好的上下文）
 ↓
回答 / 动作
 ↓
引用 + 审计日志

中间那个编排器才是产品本身。它针对每个问题决定模型需要什么：一次检索、一次工具调用、两者都要、还是转人工。它上下两端的一切，决定了答案能不能活下来。

五个能熬过好提示词的上下文错误

失败复盘里反复出现的模式：

1. 知识写死在提示词里。 价格、政策、规格粘贴进系统 prompt，然后无声地腐烂。没人会重读一个”还能用”的提示词，所以答案漂移时它最后一个被检查。实时值属于工具；受治理的文档属于检索。
2. 检索不感知权限。 索引什么都吞；模型愉快地把内部成本拆解答给任何问的人。权限必须由编排器在查询时强制执行::事后补救不叫执行。
3. 记忆是功能，不是策略。 “助手记得你”很迷人，直到它记住了 A 客户的保密报价，然后在 B 客户的会话里复述出来。企业记忆需要范围、保留和删除规则，且必须提前定。
4. 工具没有白名单。 给模型一个通用数据库连接，它一定会找到有创意的用法。工具应该窄、具名、参数受校验::一个工具一个能力，带限额。
5. 没有反馈闭环。 上线只是知识漂移的第一天。没有”系统没答好的问题”的日志流，上下文层会安静地腐朽，直到用户安静地弃用。

注意规律：每一条都是系统设计错误。提示词磨得再亮也碰不到它们。

你需要上下文工程吗？

一张不留情面的清单，勾得越多，更好的提示词对你越没用：

• AI 的 demo 效果很好，但对企业真实数据回答出错
• 不同用户对同一个问题应该得到不同答案
• 知识存在多个版本，没人确定哪份现行
• 正确回答需要 ERP、CRM 或其他实时系统的数字或状态
• 回答必须引用可核验的来源
• 系统要过审计，或处在监管行业
• 你在规划会执行动作的 agent，而不只是产出文本

勾了四条以上，瓶颈就是上下文架构。一两条，一套治理良好的 RAG 可能就够了。

你的模型可能不是问题所在。

如果你的 AI 在 demo 里正常、一碰真实的企业数据、权限和流程就崩，缺少的通常是上下文架构。我们的企业上下文工程服务会梳理并构建知识、检索、权限、实时数据和部署。如果你正在比较产品，可以阅读企业上下文工程平台购买、集成与定制指南。