表里都有 user_id，为什么两次查询算出的活跃用户仍不一样？企业问数最难的部分常常发生在 SQL 生成之前：应该用哪张表、哪个时间字段、哪套过滤条件，以及哪份定义仍然有效。
OpenAI 在 2026 年 1 月公开的内部实践，把问题中心放在上下文工程。文章给出的当时规模快照是超过 3,500 名内部用户、600PB 数据和约 70,000 个数据集。规模数字很醒目，但更值得借鉴的是系统如何缩小候选上下文。
六类上下文不是同一种知识
| 来源 | 提供什么 | 典型风险 |
|---|---|---|
| 表使用信息 | Schema、血缘、历史查询 | 热门查询未必正确 |
| 人工注释 | 业务含义、已知问题、Owner 经验 | 可能过期或只适用于局部 |
| 管道代码 | 派生逻辑、过滤条件、新鲜度线索 | 实现复杂，需结合运行状态 |
| 机构知识 | 文档、讨论、决策背景 | 权威性和时效差异大 |
| 运行时反馈 | 查询结果、错误和数据分布 | 只能说明本次执行状态 |
| 记忆与纠正 | 已验证修正和失败经验 | 必须限制适用域与版本 |
这些材料不能简单拼进一个超长提示词。系统需要先检索候选资产，再按权限、时间、粒度和问题相关性收窄，并保留为什么选择这份上下文的证据。
查询生成只是中段
一个更完整的链路是：理解意图 → 检索元数据与机构知识 → 选择候选表和可信查询 → 生成与执行 → 根据错误和结果修正 → 独立验证 → 记录可复用纠正。
其中，执行反馈很关键。空结果可能意味着过滤错误，也可能是真实业务现象；SQL 成功只能证明语法和运行环境接受了它，不能证明业务语义正确。
记忆必须有适用边界
“上次把 created_at 换成 activated_at 就对了”不是全局规则。可靠记忆至少要绑定数据域、指标、表版本、时间范围和验证证据。否则一次有效纠正会成为下一次错误来源。
对企业团队的启示
不要先追求覆盖所有数据。先选一个定义相对稳定、Owner 明确、错误代价可控的业务域，建设可检索的资产说明、可信查询、运行时权限和回归任务集。每次纠正都进入审阅流程，而不是直接写入永久记忆。
这套内部实践不是可直接采购的产品规格。它真正说明的是：当数据规模扩大后，Data Agent 的瓶颈会从“能不能生成 SQL”转向“能不能找到、约束并验证正确的上下文”。
评测也要围绕上下文错误设计
只用“最终答案是否正确”做评测，很难定位系统该怎么改。更有用的任务集会单独标注：是否选中了正确资产，是否命中了有效指标版本，是否使用了合法 Join，遇到过期注释时有没有降权，查询结果与可信基线差异来自哪里。这样才能判断失败发生在检索、语义、执行还是解释阶段。
生产监控也应保留上下文包的版本和检索轨迹。当某张表下线、管道逻辑变化或 Owner 更新定义时，可以回放受影响的历史任务，而不是等用户再次发现同一类错误。上下文工程最终是一套持续维护机制，不是上线前做一次元数据清理。