2 篇博文 含有标签「数据基础设施」

亚马逊云科技中国峰会，2026 年 6 月 23–24 日，上海。

2026 年 6 月，我在亚马逊云科技（AWS）上海峰会上做了一场分享，大概是全场"最不性感"的一场。一上来我先澄清了一句：我们的 Nova，不是 Amazon 那个 Nova。我幻灯片上的 Nova，是我在 HP 带队做的一个内部平台；全场其他人挂在嘴边的 Nova，才是亚马逊的前沿大模型。台下笑了。一个撞名的小玩笑，却也恰好划出了这篇文章要讲的那条线——接下来的时间里，我讲的是任何主论坛都懒得碰的东西：我们怎么把一套报表系统，从 Power BI 搬到了 Amazon Athena 加 Apache Iceberg 上。那是个三十分钟、300 级的进阶专题，排在六楼，离楼下的人群远远的。

会场楼层导览：专题演讲（包括我那场）在六楼，主论坛在五楼，展厅在楼下。

而一楼的展厅，卖的全是"性感"的另一面。宇树（Unitree）的人形机器人（humanoid robot）在灯光下伸手抓取；一只标价 ¥9,999 的灵巧手（dexterous hand），冲着镜头比了个耶；一块屏幕上，一群编程智能体（coding agent）全程没人插手，自己把软件交付了，另一块屏幕上，AI 把一段足球比赛录像拆成了战术和球员指标。聚光灯下，智能正学着感知、学着创造、学着在物理世界里行动。

楼下一楼的展厅：人潮都在这儿。

这个反差，就是这篇文章的论点。过去两百年，产出是跟着人头走的——想多干，就得多招人。AI 正在掐断这条线：产出开始靠基础设施（模型、算力、数据）撑着，而不再死死绑在人力上。这就是智力的工业化。和第一次工业革命一样，最后赢的不会是手握最炫机器的人，而是给这些机器铺好地基的人。我那场"无聊"的迁移就是个缩影：让报表变好用的，不是换了个更聪明的模型，而是把脚下的地基换了——刷新从 4–6 小时压到 1 小时；而原本只能盯着看的报表，如今成了谁都能用大白话直接发问的数据。

所以这篇文章，会从地基往上写。先看展厅里被围观的三道前沿——会感知、会创造、会行动的机器；再看撑着这三样的那一层，也就是我专程跑去上海讲的那件事：决定它们到底能长多高的数据底座（data foundation）。

想象一个再熟悉不过的场景：周一上午，你又坐在会议室里复盘，为什么公司的 LLM 应用始终冲不出展示环境。团队已经搭了一个看起来很“聪明”的、由 GPT-4o 驱动的智能代理：能理解复杂客户咨询、通过函数调用串起内部系统，甚至还能看似自主地编排多步骤流程。那时领导层一度热情高涨，预算批得很快，Roadmap 也写得漂亮。可六个月过去，项目仍困在资深从业者口中的 demo hell（“演示炼狱”）——永远在演示，始终不上真正可承压的生产。

如果你瞬间代入，这不是偶然共鸣——而是当今企业的常态。如果这个场景听起来很熟悉，你并不孤单。无论组织是使用托管API（如GPT-4o、Claude Sonnet 4和Gemini 2.5 Pro）构建，还是部署自托管模型（如DeepSeek-R1、QwQ、Gemma 3和Phi 4），绝大多数都难以超越实验性试点项目。正如我在AI生产力研究分析中探讨的，AI的生产力效益高度依赖于具体情境，结构化方法显著优于临时性使用。瓶颈不在于你的LLM集成的复杂性、托管与自托管模型的选择，或者你的AI开发团队的才能。而在于更根本的东西：LLM应用底层的数据基础。

真正卡住企业级 LLM 应用的，不是“模型选哪个”，而是：能不能在对的时间，把对的数据，以可追溯、可度量、可治理的方式送到模型面前。 你的“智能”代理，其上限只等于你数据基础设施的下限。

如果你尝试把一个惊艳的演示推向生产，结果被碎片化系统、不一致 API、缺失血缘、检索漂移、缓存陈旧这些细碎又顽固的阻力磨掉耐心——这篇文章就是写给你的。我们的基本立场很直接：企业级 LLM 应用的成功，不取决于提示技巧或代理框架炫不炫，而取决于是否有一套为“程序化智能消费”而设计的数据底座。

接下来我们会按层拆开：数据可访问性如何悄悄钳制模型表现；哪些数据与上下文管理模式让工具调用真正可靠；面向 LLM 特有风险的治理如何设计；以及如何把这些理念落成可以扩展、可演进的生产体系。

答案从来不是“多写几个高阶提示”或者“再换个更大模型”——而是重建数据基础。下面先从问题底层结构讲起。