全球 Lakehouse 架构的部署正在加速普及。然而，一个更深层的范式转变正在悄然发生：企业数据基础设施的服务对象，正在从人向 AI 迁移。
当 AI Agents 开始大规模嵌入企业业务流程，承担分析、决策乃至执行任务时，传统的数据平台架构是否还能胜任？
时至今日，许多企业已经完成了 Lakehouse 的架构升级，却在 AI 规模化落地阶段遭遇了新的瓶颈：数据维度和数据量足够多，但无法支撑 Agent 的高并发探索式查询、无法保障决策数据的准确性、也无法在多 Agent 协作时维持系统的稳定与可治理性。
本文将从工程实践视角，探讨在 AI 时代，大规模 Lakehouse 平台设计面临的困境。
很多人以为，让 AI 表现更好的方法是把提示词写得更精妙。但当你真正开始做企业级 AI Agent，就会发现：问题往往不出在提示词，而出在数据。
一、提示词工程，解决了哪些问题？
过去两年，Prompt Engineering（提示词工程）是 AI 落地最热的词之一。
在 AI 应用的早期阶段，它确实有效------通过精心设计的指令格式、Few-shot 示例、链式推理步骤，能让大模型在同样的任务上输出质量大幅提升。
但当你开始构建企业级 AI Agent 时，一个新的问题出现了：
-
客服 Agent 的回答忽高忽低，有时准确，有时一本正经地编造；
-
销售 Copilot 能讲产品逻辑，却不知道眼前这个客户上周刚投诉过；
-
数据分析 Agent 能写 SQL，却不清楚当前业务口径和真实指标定义。
这些问题，无论你把提示词改多少遍，都很难彻底解决。
因为根本原因不在于模型不会回答，而在于模型没有拿到足够好的上下文。
二、从 Prompt 转向 Context 的新竞争
Context Engineering（上下文工程）是近一年在 AI 工程领域快速兴起的概念。
如果说 Prompt Engineering 是如何问出好问题，那 Context Engineering 解决的是更底层的问题：在模型生成回答之前，如何让它拿到正确、完整、实时的信息环境。
两者的区别，大致可以这样理解：
Prompt Engineering 是在用好现有的模型能力，而 Context Engineering 是在让模型获得它真正需要的信息。
对于企业级 AI Agent，后者往往决定了80% 的实际效果。
三、AI Agent 需要什么样的上下文？
理解了这个转变，下一步自然是：企业在构建 AI Agent 时，应该为它准备什么样的上下文系统？
一个高质量的企业上下文，通常需要满足四个条件：
1. 实时性
Agent 要回答"这个订单现在是什么状态"，靠昨晚同步的快照数据是不够的。上下文必须反映当前业务状态，而不是历史快照。
2. 准确性
脏数据、口径冲突、重复记录，进入上下文后，模型不会自动纠错，只会更自信地输出错误结论。业务事实必须经过治理。
3. 跨源整合
企业的上下文往往分散在数据湖、数仓、OLTP、日志系统、CRM 和第三方工具里。Agent 需要一个能跨越这些孤岛、统一检索的能力层。
4. 低延迟可检索
Agent 是在推理链路中实时调用数据的。如果一次上下文检索需要 10 秒，整个 Agent 的响应体验就会崩塌。毫秒级的查询返回，是工程可用性的基本门槛。
这四点加在一起，本质上描述的是一个问题：企业需要一层专门的数据基础设施，来为 AI Agent 提供持续的、高质量的上下文支撑。
四、上下文从哪里来？
用一个具体的场景来说明。假设你在构建一个企业客服 Agent：
-
用户提问："我的退款申请为什么还没处理？"
-
Agent 判断这个问题需要两类上下文：
• 语义知识：退款政策、处理流程（来自知识库 / 向量检索）
• 业务事实：这个用户的订单状态、退款进度、历史记录（来自实时数据系统）
-
Agent 并发调用：知识库 + 实时数据查询
-
两类上下文合并送入模型，生成回答：
"您的退款申请已于 3 天前提交，目前处于银行处理阶段，预计明天到账。根据我们的政策，大额退款通常需要 3～5 个工作日......
- 本次对话状态保留，支持后续追问。
在这个链路里，向量检索负责解决"说什么语气、引用什么知识"的问题，而实时数据查询负责解决"当前业务事实是什么"的问题。
两者缺一不可。但在很多企业的 AI 架构里，第二层几乎是空白的。
五、StarRocks 在这个架构里扮演什么角色？
如果说知识库解决的是语义背景，那 StarRocks 解决的是实时业务事实，这恰恰是大多数企业 AI Agent 最薄弱的那一环。
具体来说，StarRocks 在上下文工程架构中，承担三个关键角色：
角色一：实时数据访问层
Agent 需要查询"这个用户最近 30 天的行为"或"当前库存水位和历史均值的差距"，这类查询需要在毫秒到秒级内完成。StarRocks 的向量化执行引擎和 MPP 架构，让实时分析查询可以稳定在极低延迟内返回，满足 Agent 在推理链路中同步调用的需求。
角色二：多源上下文聚合层
企业的业务数据从来不在一个地方。StarRocks 支持对数据湖（如 Hive、Iceberg、Delta Lake）、数据仓和外部数据库进行联邦查询，无需将数据全部搬移入仓，Agent 就能通过一个统一的接口获取跨源上下文，这对那些不想做大规模数据整合工程的团队尤其重要。
角色三：结构化业务事实层
很多 Agent 的上下文质量差，不是因为数据不存在，而是因为数据没有被加工成 Agent 可以直接使用的结构化事实。StarRocks 可以承载预先计算好的用户标签、业务指标、聚合维度，让 Agent 每次调用都能拿到有意义的事实，而不是需要再处理的原始流水。
六、从模型竞争，走向上下文竞争
回到最开始的问题：为什么很多企业的 AI Agent 上线后效果不稳定？
模型能力不是瓶颈，今天主流的大模型已经够强大。真正的瓶颈，是这些模型能否在每一次推理时，都获得准确、实时、完整的企业上下文。
这意味着企业 AI 的竞争，正在从谁用了更好的模型，转向谁能更稳定、更高效地组织上下文。
数据基础设施，正在成为 AI 系统的核心竞争力之一。
StarRocks 不只是一个查询引擎，而是企业将实时数据转化为 AI Agent 可用上下文的关键基础设施层。
随着 Agent 需要持续访问最新的业务状态，这一层的价值，才刚刚开始被认识到。