还记得你的公司把 BI 工具直接连到生产数据库上的时候吗？数据总是错的。没人信任那些仪表板——所以我们构建了数据栈来解决这个问题。
今天的 AI 智能体就相当于直接连到生产数据库的 BI 工具。每个公司现在都有了内部 AI 智能体，接入了原始上下文源：网盘、Notion、邮件。它勉强能用，但你不能完全信任那些答案。
上下文工程是为了以可靠和高效的方式为所有公司知识创建真相来源。而这正是数据团队多年来一直在为数据做的事情。
上下文工程需要数据团队拥有的核心技能：
上下文工程 = 数据治理 + 数据工程 + 数据科学
- 上下文工程需要治理来定义上下文真相来源
- 上下文工程需要工程来摄取和整合它们
- 上下文工程需要科学来衡量和提升 AI 可靠性
1、什么是上下文工程？
上下文工程旨在为 AI 智能体创建最优的上下文。
什么是对智能体来说的最优上下文？
回答率：智能体实际能回答的问题百分比
准确率：答案正确的百分比
成本：智能体产生的 LLM 费用
速度：智能体响应的速度
需要优化的权衡是什么？**上下文太少 → 答案错误或无法回答。**智能体知道的不够。它会幻觉、遗漏细微之处，或者完全放弃回答。
**上下文太多 → 昂贵且混乱。**输入 token 会让 LLM 账用快速飙升（Claude Opus 4.5 中 100 万 token 是 5 美元）。一个上下文密集的调用每次查询很容易发送 5-10 万 token，大约 50 美分。除了成本之外，不相关的上下文会稀释信号——模型会被噪音搞混。
如何进行上下文工程？选择要包含哪些来源，排除哪些来源。
澄清哪个内容是某个主题的真相来源（正确定义、最新来源）。有时你可能会发现自己一开始也不清楚。
创建尚不存在的上下文。
格式化上下文，使模型能够高效解析它：让它更模块化、结构化。
简而言之，上下文工程遵循与数据工程相同的原则：衡量、迭代、优化。跟踪你智能体的表现。识别失败原因。添加缺失的上下文。测试改进。重复。
2、上下文治理
上下文真相来源就是新的数据真相来源。
我们对上下文治理有着与数据治理相同的需求。
我们需要数据治理，因为没有它，"收入"意味着三件不同的事情，取决于你问谁。营销团队算的是总预订额。财务团队算的是净 ARR。产品团队算的是活跃订阅数。没有指标层，没有规范定义——所以每个仪表板讲述不同的故事。
今天，我们需要上下文治理，因为公司知识有完全相同的问题。问"我们的退款政策是什么？"，答案取决于智能体先找到哪个文档——过时的 Notion、最新的 Zendesk 回答，还是法务上季度发在 Slack 里的消息。有时候，没有人真正想过这个问题的正确答案是什么。
很多数据人都经历过可怕的时期，他们到一家公司发现 BI 直接接在生产数据库上。所有数据都在这里，没有两个数字看起来一样，一切都慢且痛苦。今天，我们通过把 AI 接入整个公司知识库做着完全一样的事情。
我们都知道公司知识充满了不准确、过时的内容和矛盾。所以把智能体直接接上这个混乱局面似乎不是最好的做法。
我们需要的是一个上下文层：一个单一的、被治理的、有版本的、公司知识的真相来源。智能体可能面临的每个问题的清晰答案。我们需要基础设施来构建和维护它。
3、上下文工程：上下文栈就是数据栈
为了拥有数据真相来源，我们构建了数据栈。 为了拥有上下文真相来源，我们需要上下文栈。
今天的情况和 10 年前的数据领域一样：我们有来源，有消费工具。但我们没有中间层，没有上下文 ETL 层。
我们需要：
- 摄取工具来自动拉取上下文来源
- 转换工具来挑选上下文真相来源
- 上下文层作为公司知识的真相来源
- 编排以保持上下文的新鲜度
- AI 监控来衡量和跟踪我们的上下文在 AI 智能体中的表现
一些数据团队已经开始内部构建这些组件了。我见过团队编写脚本来从仓库拉取模式元数据和概要统计、从数据目录同步文档、或从 BI 工具中整理经过验证的查询到 markdown 文件中。它有效——但需要大量的脚本和维护。
监控更加落后。大多数分析智能体工具还不支持评估框架，所以没有简单的方法来构建单元测试来验证你的上下文在更改后仍然产生正确的答案。
一旦我们有了治理和栈，我们需要使用我们的数据科学技术来迭代和改进我们的上下文。
4、上下文科学
像调优 ML 模型参数一样调优你的上下文。
在 ML 中，你定义一个成功指标（准确率等），并拥有标注数据的训练测试集。然后你调整参数、特征、训练集。你在每次更改后衡量表现，直到找到最优值。
在上下文工程中，应该是相同的循环。你定义你的成功指标（可靠性、成本等）。你的参数是上下文真相来源、上下文格式化、工具。你可以创建提示词/预期答案的单元测试集。你更改上下文，重新运行测试提示词，衡量影响，保留有效的部分。
但需要攻克的额外问题是如何衡量你的指标→ 成本、速度很容易衡量，但你需要更定制的工具来衡量智能体的可靠性：检查使用的文件来源？精确匹配？LLM 作为评判者？
要做到这一点，你需要为自己构建一个**评估框架**。定义你要跟踪的 KPI——什么是智能体成功，如何衡量它，还有哪些其他参数很重要（成本、速度等）。然后构建单元测试，通过在不同上下文集上的表现来微调你的上下文。
5、如何现在开始转型
如你所见，上下文栈还没有出现。我们仍然缺少工具来公开地整理和改进我们的上下文。
我认为数据团队的第一步应该是在自己的范围内展示他们掌握了上下文工程：你真的能为你分析智能体构建有效的上下文吗？
正如我在之前关于分析智能体基准测试的文章中所探讨的，现成的解决方案不起作用，而且它们是上下文黑盒。如果数据团队投资于他们自己的分析智能体的上下文工程，我相信他们能够证明它比现成的智能体效果更好。
两种设置已经可以用来开始上下文工程了：
文件系统 AI 智能体（Cursor、Claude Code、Cowork、Codex、nao）
这些工具直接从你控制的文件中读取上下文。你可以确切地看到智能体知道什么，通过编辑文件来改变它，并立即衡量影响。此外，你还可以在上面构建评估框架，因为一切都通过代码可访问。内部智能体
如果你构建了自己的智能体，你控制整个上下文管道：你想添加哪些上下文片段，以及你打算如何评估你的智能体。创建一组提示词单元测试，然后开始在不同的上下文场景中运行它们。
原文链接：数据团队的新战场：上下文工程 - 汇智网
