ITPub博客

甲骨文（Oracle）的裁员消息再次将这家老牌企业软件巨头推上风口浪尖。从全球范围来看，这并非甲骨文第一次大规模调整人员结构，也很可能不是最后一次。当云计算成为主战场，传统软件 licensing 模式的增长引擎逐渐熄火，甲骨文必须在“守成”与“转型”之间做出更残酷的取舍。本文基于公开信息与行业逻辑，尝试拆解甲骨文裁员背后的深层动因与可能走向。 裁员不是新闻，而是甲骨文转型的“常规动作” 如果仅从单次裁员的视角看甲骨文，很容易将其理解为一家老牌公司在经济周期中的被动收缩。但把时间线拉长，会发现甲骨文的裁员几乎与其云转型战略同步发生，且呈现出明显的“结构性”特征。 第一，裁员往往集中在传统业务线。 甲骨文的核心收入长期依赖数据库许可证、中间件和本地部署（on-premise）企业软件。这些业务的特点是：客户粘性高

当数亿用户习以为常的AI对话窗口突然沉默，我们才意识到，那些看似“无所不能”的大模型，其实建立在极其脆弱的工程地基之上。本文尝试从技术视角，还原一次AI服务中断可能暴露的系统性风险。 没有素材的“事故复盘”：我们到底在讨论什么 需要首先说明的是：依据现有素材判断，目前并没有关于“豆包数据库挂了”这一事件的具体技术细节、官方通报或时间线信息。 因此，本文不会编造具体的故障时间、影响范围、错误代码或恢复时长，而是从AI产品依赖数据库这一技术事实出发，讨论此类事件在工程层面意味着什么。 豆包作为字节跳动旗下的AI对话产品，其背后是一套典型的大模型服务架构：用户输入经过网关分发，由推理集群调用模型生成回复，而数据库在其中承担着远比外界想象更关键的角色。它不只是存储用户聊天记录的“仓库”，更可能涉及会话状态管理、用户身份

在大模型能力快速迭代的当下，模型本身正在逐渐商品化，而数据层却成为企业 AI 落地能否持续产生价值的关键变量。本文尝试从模型与数据层的关系出发，讨论为什么“数据层”正在成为 AI 工程化的真正分水岭。 模型能力趋同之后，差距回到数据层 过去两年，围绕大模型的讨论几乎都集中在模型本身：参数规模、上下文长度、推理能力、多模态支持、推理成本。每一次新模型发布，都会引发一轮关于“能力天花板又被抬高”的讨论。但如果把视角从模型榜单转向真实的企业系统，会发现一个越来越明显的现象：模型能力的差距在缩小，而数据层的差距在放大。 原因并不复杂。头部模型的通用能力正在快速趋同，API 化、开源化、蒸馏化让“拿到一个足够强的模型”变得越来越容易。对于大多数企业而言，真正的难题不是“有没有模型可用”，而是“模型能不能用对企业自己的数据

过去两年，围绕大模型的讨论大多集中在参数规模、榜单排名和单点能力突破上。但当企业真正尝试把 AI 嵌入核心业务时，会发现决定成败的往往不是某一个模型有多强，而是支撑 AI 持续、稳定、可控运行的那套底层能力体系。这套体系，正在被越来越多地称为“AI 能力底座”。 依据现有素材判断，目前关于 AI 能力底座尚无统一、权威的定义。本文尝试从工程与组织视角，梳理这一概念的内涵、构成与建设路径，供技术决策者参考。 什么是 AI 能力底座 如果把 AI 应用比作冰山露出水面的部分，那么 AI 能力底座就是水面之下支撑整座冰山的庞大基座。它不直接面向最终用户，却决定了上层应用能否规模化、可持续地运转。 从工程视角看，AI 能力底座通常包含以下几个层面： 算力与资源调度层。 这是最底层的基础设施，涉及 GPU、NPU 等异构

在过去十年里，Infra（基础设施）几乎是技术行业中最“确定”的领域之一：业务增长带来流量，流量带来机器需求，机器需求带来扩容、调度、监控和容灾。只要系统还能撑住，Infra 的价值就容易被理解为“稳定支撑”。但今天，这种理解正在迅速过时。 当 LLM、实时计算、边缘场景、多云架构和 AI Agent 同时进入生产系统，Infra 面对的问题已经不再是“有没有足够的资源”，而是“能不能把异构资源组织成可持续演进的系统能力”。换句话说，Infra 正在从后台支撑，走向决定业务上限的前台变量。 依据现有素材判断，我们无法依赖具体产品版本、性能数字或厂商案例来展开细节，但可以从行业共识和技术逻辑出发，讨论 Infra 正在发生的结构性变化。 从“资源视角”转向“能力视角” 传统 Infra 的核心命题是资源管理：计算

过去两年，大模型竞赛的焦点集中在参数规模、训练数据与榜单成绩上。但当模型真正进入生产环境，决定用户体验和成本的往往不是模型本身，而是承载它的 runtime——那层介于模型权重与硬件之间的调度、编译与执行系统。同一个模型，在不同 runtime 下可能表现出数倍的吞吐差异和截然不同的首 token 延迟。本文尝试从工程视角拆解模型 runtime 的关键问题，并讨论它正在成为基础设施竞争焦点的原因。 Runtime 到底在解决什么问题 要理解模型 runtime 的价值，先要理解一次推理请求在底层经历了什么。 当用户输入一段 prompt，模型并不是“一次性算完”的。以自回归生成方式为例，模型需要逐 token 输出，每一步都要重新读取庞大的权重、计算注意力、更新 KV Cache。这个过程涉及显存带宽、算子调

过去两年，大模型能力的讨论大多围绕参数规模、推理能力和多模态展开。但当 LLM 真正进入企业流程、个人助理和长期协作场景后，一个更基础的问题开始浮出水面：模型如何“记住”信息？更准确地说，模型如何在多轮交互、跨会话任务和持续变化的业务环境中，形成稳定、可更新、可审计的记忆能力？ 依据现有素材判断，模型记忆正在从单一的“上下文窗口”问题，演变为一个包含存储、检索、压缩、更新和治理的系统工程。它不再只是提示词工程的一部分，而是逐渐成为 AI 应用架构中的独立层。 上下文窗口不是记忆：从“临时可见”到“长期可用” 在大模型应用中，最常被误称为“记忆”的能力，其实是上下文窗口。用户把历史对话、文档片段或业务数据拼接进 prompt，模型在这一次推理中“看见”了这些信息，于是表现得像是记住了。但这种方式有几个天然限制。

云开源工具过去十年的主线是“把能力做出来”，而未来五年的主线，很可能是“把能力变成可信赖的基础设施”。当 Kubernetes、OpenTelemetry、Terraform 这类项目逐渐成为企业技术栈的默认底座，云开源工具的竞争焦点正在从功能覆盖转向稳定性、可治理性与商业可持续性。依据现有素材判断，这一趋势仍将沿着工程化、平台化和生态协同三个方向演进。 从单点工具到平台底座：云开源工具的工程化拐点 云开源工具最早的价值，往往体现在“解决一个具体问题”。例如用容器编排解决部署一致性问题，用声明式配置解决环境漂移问题，用可观测性工具解决链路黑盒问题。但在企业真实生产环境中，单点工具的堆叠很快会带来新的复杂度：工具之间接口不统一、升级节奏不一致、权限模型各自为政、故障排查链路被拉长。 因此，未来云开源工具的第一个明

过去几年，云开发（Cloud Development）从一个偏工具化的概念，逐步演变为应用生产链条中的关键基础设施。它最初解决的是“后端太重、上线太慢、运维太贵”的问题，而今天，它正在逼近一个更根本的命题：当算力、模型、数据和部署能力都被平台化之后，开发者到底还剩下什么不可替代的价值？ 这篇文章尝试给出一个判断：云开发不会停留在“让开发更省事”的层面，它的终局是成为 AI 时代应用生产的新范式。而在这个过程中，行业会经历三次明显的重心迁移。 云开发的第一个阶段：把后端变成“可调用的能力” 云开发最早的吸引力，来自它对传统应用架构的简化。过去做一个完整应用，团队需要自己搭建服务器、配置数据库、处理鉴权、管理文件存储、设计扩容方案，还要为上线后的稳定性负责。对于小团队和个人开发者来说，这套流程的成本高得不成比例。

过去二十年，企业把数据搬进仓库、搬上云，却始终没能解决一个根本矛盾——懂业务的人不懂 SQL，懂 SQL 的人不懂业务。智能问数试图用自然语言抹平这道鸿沟。但它究竟是 BI 的下一站，还是又一个被过度包装的概念？本文尝试给出一个不那么讨巧的判断。 智能问数到底解决了什么问题：不是“查数更快”，而是“提问权下放” 要理解智能问数的价值，先要理解传统 BI 的结构性困境。 在典型的传统数据栈里，一个业务问题要变成一次数据回答，中间要经过一条漫长的链路：业务人员提出需求 → 数据分析师理解需求 → 分析师写 SQL 或拖拽报表 → 数据团队做权限与口径校验 → 结果回传 → 业务人员发现理解有偏差 → 重新沟通。这条链路的瓶颈从来不是算力，也不是存储，而是翻译成本。 智能问数的核心主张，是把这条链路压缩成一句话：用户

过去两年，大模型的能力边界不断外扩，但产业界逐渐意识到一个现实：把全部智能都押注在云端，既不经济，也不实时，更不安全。智能体（Agent）要真正进入生产系统，必须解决“在哪里思考、在哪里行动、在哪里记忆”的问题。云边端协同，正是回答这一问题的架构答案。本文尝试从架构逻辑、落地形态与关键挑战三个层面，梳理智能体与云边端协同的演进脉络。需要说明的是，本文基于公开技术趋势与通用工程实践展开分析，不涉及具体厂商未公开的产品细节；凡涉及判断性内容，均标注为“依据现有素材判断”。 为什么智能体天然需要云边端协同 1.1 单一云端架构的三重瓶颈 大模型驱动的智能体，本质上是一个“感知—规划—行动—反馈”的闭环系统。当这个闭环完全部署在云端时，会暴露三个结构性问题。 第一是时延。 智能体的行动往往发生在物理世界或业务现场：机械

过去两年，关于 AI Agent（智能体）的讨论几乎都集中在模型能力上：上下文窗口有多大、推理链有多长、工具调用有多准。但当我们真正把智能体从 Demo 推向生产环境时，会发现一个尴尬的事实——限制智能体落地的，往往不是模型不够聪明，而是它脚下的基础设施不够“云原生”。 这篇文章想讨论一个被行业叙事长期忽略的角度：云原生开发范式，正在从“支撑微服务的工具集”，演变为“赋能智能体的操作系统”。而谁能率先把这两件事真正缝合起来，谁就可能拿到下一代应用平台的话语权。 智能体不是“更聪明的微服务”，但它需要微服务级别的工程底座 很多团队在构建智能体时，第一反应是把它当成一个“带 LLM 的脚本”来写：一个 Python 文件、几个工具函数、一段 prompt，跑起来就算成功。这种原型开发方式在验证阶段没问题，但一旦进入

过去二十年，数据库的核心叙事是“更快、更稳、更便宜地存取数据”。而当大模型把非结构化数据变成可计算资产，数据库正在被迫回答一个全新的问题——它是否还能只做“管道”，还是必须成为智能系统的“认知基座”？本文尝试从技术演进与产业逻辑两个层面，给出一个判断。 一个被忽视的事实：智能的上限，正在被数据底蕴卡住 过去两年，行业讨论大模型时，注意力几乎都集中在参数规模、训练算力、推理成本上。但真正在一线做企业级 AI 落地的人，会越来越频繁地撞到同一堵墙：模型不是瓶颈，数据底蕴才是。 这里的“数据底蕴”不是指数据量，而是指数据被组织、被理解、被治理、被复用的方式。它包含几个层次： 可发现性：企业是否知道自己有哪些数据、分布在哪里、谁在用； 可理解性：数据是否有语义、有上下文、有血缘，而不是一堆字段名； 可计算性：结构化与非

AIPC 不是一次简单的硬件升级，而是一场关于“个人计算主权”的重新分配。当算力从云端下沉到终端，当模型从通用走向个人化，PC 这个诞生了四十余年的品类，正在经历它自图形界面以来最深刻的一次身份重构。 AIPC 到底是什么：一场被误读的“换机潮” 过去两年，关于 AIPC 的讨论大多停留在两个层面：一是芯片厂商的 NPU 算力数字竞赛，二是 OEM 厂商的“AI 功能清单”营销。但如果只把 AIPC 理解为“带 NPU 的 PC”，那我们就错过了它真正的意义。 依据现有素材判断，AIPC 的核心特征并非某一颗芯片，而是本地算力、本地模型、本地数据三者形成的闭环。这个闭环的价值在于：它让 AI 从“你去找它”变成“它跟着你”。云端大模型再强大，也受制于网络延迟、隐私边界和调用成本；而端侧 AI 的意义，恰恰在于把

导语 过去两年，关于人工智能的讨论几乎被模型参数、算力规模和产品迭代所占据。但当我们把视线从实验室和发布会移开，会发现一个更根本的问题正在浮现：当 AI 从"技术突破"走向"社会基础设施"，决定它能走多远的，不再是某一个模型的性能上限，而是政策框架与标准体系能否为它铺好轨道。 "人工智能+"这个提法，本质上不是技术命题，而是制度命题。它要回答的是：AI 如何真正嵌入千行百业，而不是停留在演示视频里。 从"AI 能做什么"到"AI 被允许做什么" 技术圈习惯用能力边界来定义 AI 的进展：能不能写代码、能不能做科研、能不能通过考试。但产业界真正关心的是另一套边界——合规边界、责任边界、数据边界。 一个模型在基准测试上再强，如果无法明确"出错了谁负责""数据从哪来""结果能不能审计"，它就很难进入金融风控、医疗辅助

“AI原生的数据底座，不是把AI装进数据库，而是让数据库自己长出Agent的能力。”阿里云数据库产品事业部RDS研发总负责人陈宗志(花名：暴跳)在DTCC大会采访时表示。

过去一年，Agent（智能体）从演示视频里的“魔法”迅速变成了工程团队手里的“待办事项”。但真正做过 Agent 开发的人都知道，快速做出一个 Demo 只要一个下午，快速做出一个能上线的 Agent，却可能要一个季度。这篇文章想聊的不是“Agent 有多强”，而是当所有人都在喊“快速开发”时，我们到底在快速开发什么，以及哪些东西根本快不起来。 Agent 开发的“快”，快在了哪里 先说结论：Agent 快速开发这件事，确实在发生，而且速度是真实的。依据现有素材判断，这种“快”主要来自三个层面的成熟。 第一层是模型能力的接口化。 过去要做一个能理解自然语言、能调用工具、能做多步推理的系统，需要自己训练模型、自己搭推理服务。现在这些能力被封装成了 API，开发者只需要写 Prompt、定义工具、编排流程。门槛从“

过去十年，云原生几乎重塑了整个软件基础设施的面貌。Kubernetes 成为事实上的调度底座，容器、服务网格、声明式 API、可观测性体系层层叠加，构成了现代应用的“操作系统”。但如果把镜头从基础设施拉回到开发者身上，会发现一个略显尴尬的事实：基础设施越来越强，开发者的体验却没有同步变好。 在不少团队里，云原生带来的不是“更快交付”，而是更高的认知负担、更长的上手周期和更碎的职责边界。本文尝试从媒体视角，讨论云原生开发正在发生的转向，以及为什么“开发体验”会成为下一阶段的核心竞争力。 云原生的第一阶段：基础设施的胜利 回顾云原生的演进路径，主线非常清晰：把运维问题抽象成平台问题。 容器解决了“环境一致性”； Kubernetes 解决了“编排与调度”； 声明式 API 解决了“状态收敛”； 服务网格解决了“服务

过去十年，我们习惯把注意力放在框架、模型和 API 上，却常常忽略真正让代码“活”起来的那一层——Runtime。当硬件红利放缓、模型规模逼近工程极限，Runtime 正从幕后走向台前，成为决定性能、成本与体验的关键变量。 被低估的 Runtime：软件世界里的“隐形基础设施” 如果让一位开发者列出自己最关注的技术栈，答案大概率是语言、框架、数据库、云平台。

过去二十年，企业信息化的核心命题是“把数据存下来”；未来十年，核心命题正在变成“让系统自己给出判断”。智能分析不是 BI 的简单升级，而是决策链路的重新分配——从人找数据，到数据找人，再到系统替人先想一步。 一个被低估的转折点：分析的主体正在换人 如果回顾企业数据分析的演进，大致可以分成三个阶段。 第一阶段是报表时代。