我最近注意到 OpenAI 在 2026 年初发的一份介绍内部数据 Agent（Data Agent）的报告 《Inside our in-house data agent》，里面的工程细节挺有意思。据 VentureBeat，这个 agent 的初版由两名工程师在三个月内搭成，后来已有数千名员工使用。若采用 OpenAI 2026 年 1 月官方披露的统一口径，其数据平台服务 3,500 多名内部用户，覆盖 70,000 个 datasets 和 600 PB 以上数据。
很长一段时间里，大家做 Agent 遇到海量数据和复杂业务时，第一反应往往是去做复杂的实时检索。从向量数据库检索、Graph RAG 到各种在线分发机制，行业里好像默认觉得在线把匹配做复杂，才是解决上下文问题的终极办法。但 OpenAI 这份报告和后续透露出的细节，其实给出了一个挺不一样的视角。
支撑这么大数仓分析的系统，OpenAI 并没有把主要复杂度堆在在线控制流上。根据 OpenAI 官方博客 和 ByteByteGo 访谈 的披露，在线 agent loop 相当简洁：OpenAI 2026 年 1 月披露的版本由 GPT-5.2 驱动，后来的 ByteByteGo 报道称在线主模型已升级到 GPT-5.5；每个请求仍进入同一个主模型，约 13 个精选工具按次暴露，没有独立 router，也尚未 fine-tune。这里的“单模型”只指在线 agent loop，离线 enrichment 和检索仍使用 Codex 与 Embeddings API。
OpenAI 的核心工程师 Emma Tang 在接受 VentureBeat 采访 时提到：“我们用的都是外部完全可用的同款 API，没用微调模型，完全依赖 GPT-5.2，所以你完全可以搭出这样的系统。”在全行业都在研究实时 RAG 搜索的时候，这种把复杂度前移到离线生产的做法，反而在复杂场景下跑出了相当不错的稳定性。
刚看到 OpenAI 披露的内部架构时，最吸引我注意的就是它在线部分的简洁。在常见的工程设想里，一个要同时服务几千名顶级科学家和工程师的数据 Agent，后台怎么也得堆上一堆模型微调策略、多层路由以及复杂的工具链。
但真实的数据和技术细节却展示了很鲜明的反差：在线任务就靠一个主模型在跑，每次调用只暴露约 13 个工具。这种架构的干炼，打破了大家对大厂必须有神级在线算法的迷思。它真正反直觉的地方在于：OpenAI 并不是用离线目录取代 RAG——官方明确写了查询时仍通过 RAG 拉取最相关的 embedded context。本文所谓 Yahoo 模式，是我对离线编撰环节的比喻；真正的变化是把 RAG 的检索对象从原始元数据和日志，换成预先加工的高密度 context。
仔细拆解这个案例会发现，大家很容易踩进一个误区，以为越厉害的 Agent 就越需要复杂的在线控制流。但在实际工程里，在线部分太复杂往往是系统不稳定的根源。当所有的精力都放在怎么在用户提问的那几秒钟里完成高效检索和多步推理时，本质上是在用在线计算的不确定性，去硬扛数据本身的语义模糊。
为什么处理企业级复杂数据时，传统的在线 RAG 搜索很容易遇到瓶颈？这背后的根源，其实是 Google 模式和 Yahoo 模式对信息是怎么存在的这个前提假设完全不同。这里的 Google / Yahoo 都是我的比喻框架，不是 OpenAI 的术语。
Google 模式（实时 RAG 搜索）在公开互联网上之所以大获成功，是因为互联网有着极端丰富的信息供给。公网上几乎什么都有，不管你问什么，大概率早就有现成的网页或文档把答案写好了。所以 Google 模式的基本假设是：信息本身就已经在那里了，我们只需要在用户提问时把它检索出来。
但企业内部的数据和知识系统，恰恰彻底打破了这个前提。
在实际的数仓治理里，表名往往充满了像 t_usr_evt_v2
这样高度抽象的代号，字段的具体含义也和业务上下文绑定得非常深。数据表真正的业务语义——比如主键粒度、指标判定边界、下游依赖链条——往往没有被完整、及时地写入
schema 或现成文档，而是隐式藏在 Airflow 或 Spark 的 ETL
管道代码里，甚至只保存在老员工的脑子里。OpenAI 自己的 Lesson #3
说得很直白：schema 和 query history 描述的是表的形状和用法，true meaning
在产生它的代码里。
在信息没有被充分文字化、结构化的企业内部，如果盲目用 Google 模式在提问时去搞实时向量搜索，搜出来的多半是字面相似但逻辑完全对不上的垃圾片段。原因很简单：你很难检索出一个还没有被写出来的语义。
而 Yahoo 模式的核心，从来就不是死板的分类，而是一个人工主编与整理的过程。在早期的互联网，Yahoo 依靠主编人员手动去筛选、撰写和组织网站分类目录。在 OpenAI 的案例里，大语言模型真正替代的并不是检索的动作，而是接管了主编与整理人的角色——然后，在线端仍然用 RAG 去检索这些已经被编好的材料。
OpenAI 并没有靠人工去死板地维护这份目录，而是让大模型（Codex）担任离线主编，针对热门或重要表自动去读其生产 pipeline 代码，结合专家标注和历史使用信号，在提问发生之前，就把原本杂乱无章的数仓代码编译成按表组织的结构化描述，以及可单独检索的机构知识和 memory。
这种离线提炼直接决定了前台调用的极简。正因为离线阶段已经把原始代码、Schema 和历史使用信号提炼成按表组织的结构化描述，在线推理时，模型只需检索与当前问题相关的片段，而不必扫描原始元数据和日志——这就顺理成章地引出了上下文工程里的另一个核心原则：少即是多。
Emma Tang 在 VentureBeat 访谈 里专门提到，很多团队做 Agent 时，习惯把搜到的所有资料一股脑塞进上下文窗口，寄希望于大模型自己能在海量信息里看出端倪，但 evals 发现效果刚好相反：给模型更少但更准确、经过策展的 context，结果反而更好。
甚至连工具的收敛也是同一个逻辑：正因为离线卡片把语义交代得更干净，前台模型不再那么容易犯迷糊，ByteByteGo 报道团队最初接入约 40 个工具，后来移除重叠能力，并把每次调用可见的工具控制在约 13 个。
为了支撑这套离线主编机制，OpenAI 在后台把上下文的收集与整理分成了六个层级，也就是他们报告里提到的六层上下文架构。
如果光看这六层架构本身，很容易把它读成一份枯燥的说明书：第一层是什么、第二层是什么……但作为工程实践者，架构图表面的分层并不重要，真正有启发的是：他们当年到底遇到了什么数据死穴，才倒逼出这六种设计？
下面是我对官方六层的重组，不是 OpenAI 自己的四痛点框架。把这六层拆开，本质上是在用离线基础设施去解决企业数据分析里的四个核心痛点：
光看数据库表名和字段类型，你往往不知道 t_usr_evt_v2
到底是一天更新一次还是一小时更新一次，更不知道主键和 Join
关系是什么。这些逻辑大量藏在 Airflow/Spark
的管道代码和资深工程师的经验里。 为了解决这个语义黑盒，他们才设计了
Codex 代码解析（Layer 3） 与 专家标注（Layer
2）：让 Codex 每日异步任务针对热门或重要表读取其生产 pipeline
代码，从代码里反推主键、粒度和替代表；同时让数据专家补充隐性的业务意图。因为代码才是业务语义真正的载体之一。
企业数仓里充斥着大量的临时测试表和一次性实验 SQL。如果把所有历史查询都当成范例喂给模型，模型就会学到一堆错误写法。 为了解决垃圾数据噪点，他们设计了 表使用率与血缘（Layer 1）：汇总 Schema、血缘和历史查询，并按使用量与可信度给历史查询排序——高使用量 dashboard 背后的查询优先，一次性探索查询降权。公开材料没有说 one-off 查询会全部删除，也不应把它们与 eval 中的 golden SQL 混为一谈。
数据分析师提问“这个月 DAU 是多少”时，DAU 的定义往往在 Notion 或 Slack 讨论里，而不是在数据库里。同时，不同员工能看的数据权限完全不同。 为了解决指标一致性与数据安全，他们设计了 机构知识与权限隔离（Layer 4）：打通 Notion、Docs 和 Slack 的指标定义。内部文档在 retrieval 时做权限检查；warehouse 查询则继承用户已有的表权限，agent 不会因为代写 SQL 获得额外授权。
如果用户纠正了一次“EMEA 市场要剔除测试账号”，AI 下次还犯，用户就会失去信任；但如果完全依赖离线目录，遇到 Schema 刚改过的情况，AI 就可能用旧 Schema 写出报错 SQL。 为了解决重复犯错与静态延迟，他们设计了 记忆回路（Layer 5） 与 运行时 Live 校验（Layer 6）：记忆层负责把用户的纠错变成可复用资产；而 Layer 6 允许 agent 在离线 context 缺失或过时时按需 live query warehouse，并调用 Airflow、Spark 等平台系统补充 runtime context。公开材料没有披露固定的执行前 information_schema 校验、在线校验比例或六层统一刷新周期。
看懂了这四个痛点，就会明白 Emma Tang 在访谈里说的“真正的工程工作在基础设施层，不在模型层”是什么意思。后续版本使用 GPT-5.5 作为在线主模型，团队把可靠性主要归因于 context infrastructure；但未公开准确率或 ablation 数据。正是因为后台基础设施把这四个痛点在前置阶段消化掉了，在线端才能只用约 13 个工具和单模型跑得更轻。
但天下没有完美的架构。离线主编模式虽然在语义提炼上优势明显，但它天生带有一个避不开的短板：时效性延迟。企业数仓的 Schema 几乎每天都在变，离线批处理任务肯定存在更新滞后。如果完全依赖静态的离线目录，模型难免会用过时的表结构写出错误的 SQL。
为了解决离线目录的陈旧性问题，OpenAI 引入了 Layer 6（Runtime Context）来做双相补偿。在运行时，当离线 context 缺失或过时时，模型可以 live query warehouse 校验实际 Schema，并对接 Airflow 和 Spark 动态获取最新的执行状态。Layer 6 并不是对离线架构的否定，而是在保持离线目录高密度优势的同时，专门用来修补最后那点状态延迟。另外，agent 生成 SQL 后去 live 执行拿结果，本来就是正常分析流程，不是偶发兜底。
同样，我们也能很客观地看到这套系统在实践里的边界。Emma Tang 在 VentureBeat 访谈 里坦言，模型过度自信是一个需要注意的问题，模型有时会在上下文不够时表现出盲目的确定性。在 InfoQ 演讲 里披露的真实案例也显示，这个 Agent 曾把 ChatGPT 的活跃用户数误算成了 500 万（对照约 8 亿），甚至还把视频生成模型 Sora 误判成了游戏《王国之心》里的角色。
另外，长期积累的记忆机制也存在概念漂移的风险，旧的偏好可能会过度拟合并干扰新的业务逻辑；InfoQ Q&A 中 Bonnie Xu 也承认 bad memory 会造成真实失败，当前主要靠 auditing 和 pruning。甚至官方 demo 截图对比了无 memory 时仍运行 22m41s 与有 memory 时 1m22s 完成——这属于厂商 demo，没有生产 telemetry 或独立复现。理清这些边界，能帮我们更客观地评估离线编撰架构的适用场景。
复盘 OpenAI Data Agent 的架构演进，给 Agent 开发者带来的最直接启发是：别再在在线 Prompt 和复杂的实时分发机制上做无谓的内耗了，把精力转向建设离线数据供应链。
对大多数资源有限的团队来说，完全复制一套六层 Context 机制既没有必要也不现实。我们可以从最小闭环切入，分三步建立自己的离线整理管线：
首先，清洗历史日志。别把所有历史对话或 SQL 记录直接往向量库里扔，而是根据使用频率和验证状态做筛选，让高频、高信任度的查询优先进入检索材料。
其次，引入 AI 离线提炼。部署轻量级的定时任务，利用大语言模型（比如 Codex 或通用模型）定期扫描数据管道代码和 SQL 脚本，提取表粒度、主键约束和业务含义，自动生成结构化的离线描述。
最后，建立纠错记忆回路。把用户在日常协作里提出的修正意见抓取下来，写入轻量化的记忆文件，在下一次离线更新时合并进目录上下文——但要有 auditing 和 pruning，否则 bad memory 会把错误永久放大。
好的上下文工程，精髓不在于运行时检索到了多么海量的数据，而在于离线阶段利用大模型充当主编，把可检索材料整理得有多准确。当数据供应链能在后台消化掉绝大部分复杂性时，在线端的 Agent 自然可以用很简洁的架构，跑出相当稳定高效的结果。