ITPub博客

过去两年，几乎每一场技术发布会、每一篇行业分析、每一次投资人对谈，都绕不开同一个问题：AI 会不会把 SaaS 干掉？ 这个问题的流行，本身就很值得玩味。它把两种不同性质的东西——一种是以模型能力为核心的技术范式，一种是以流程、数据和协作关系为核心的商业交付方式——放在了同一个“替代”框架里。于是讨论很容易滑向两个极端：要么认为 SaaS 已死，要么认为 AI 只是 SaaS 的一个新功能模块。 我的判断是：AI 不会替代 SaaS，但会重写 SaaS 的价值分配方式。 真正被替代的，不是 SaaS 这种形态，而是那些只靠“界面 + 表单 + 流程审批”收订阅费、却没有沉淀不可替代数据资产和协作网络的产品。换句话说，AI 不是 SaaS 的掘墓人，而是 SaaS 的筛子。 把 AI 和 SaaS 放在“替代”框

当大模型参数规模从百亿走向万亿，智能算力不再只是“更快的芯片”问题，而是一场从单点硬件到系统工程的全面重构。智算中心密集落地、GPU 一卡难求、CUDA 生态壁垒高筑、推理成本成为商业化生死线——我们正在经历的，不只是算力扩容，而是一次产业底层逻辑的切换。本文尝试从算力供给、系统效率与商业闭环三个层面，拆解智算产业的真实处境与下一步走向。 算力供给：从“买得到”到“用得起”的鸿沟 过去两年，智算产业最直观的关键词是“缺”。缺 GPU、缺高端显存、缺先进封装产能、缺稳定电力。大模型训练对算力的需求呈指数级上升，而硬件供应链的扩产周期以年计，供需错配成为常态。 但进入 2024 年之后，一个更微妙的变化正在发生：算力不是单纯不够，而是结构性错配。 一方面，头部厂商和大型云服务商仍在争抢高端训练卡，用于千亿、万亿参数

当行业还在争论 Agent 该用哪种框架、接哪个模型时，一个更底层的问题正在浮出水面——Agent 运行在哪里？它执行代码、调用工具、访问文件、连接网络，几乎拥有一个“数字员工”的全部权限。一旦失控，代价可能远超一次模型幻觉。硬件级虚拟化隔离，正在从“云基础设施的旧话题”变成“Agent 安全的新答案”。 Agent 越像人，越需要一个“隔离舱” 过去两年，Agent 的能力边界被迅速拉宽。从最初的对话补全，到能自主规划任务、调用 API、读写文件、执行 Shell 命令、操作浏览器，甚至编排多个子 Agent 协同完成复杂工作流。它不再是一个“回答问题”的模型，而是一个“动手做事”的执行体。 这带来一个根本性的变化：Agent 的风险模型，已经从“说错话”升级为“做错事”。 模型幻觉的代价，通常是一次错误的回

当大模型从“对话”走向“行动”，Agent 正在成为软件的新形态。但一个被反复讨论的问题是：Agent 到底应该跑在哪里？容器、虚拟机，还是无服务器？本文尝试从工程约束出发，讨论 Serverless 为何可能成为 Agent 运行时的默认选项，以及这条路仍然存在的代价。 Agent 的运行时困境：它不像 Web 服务，也不像批处理 要讨论 Agent 该跑在哪里，先要理解 Agent 和传统软件在运行时特征上的差异。 一个典型的 Web API 是短生命周期、无状态、请求-响应式的。一个典型的批处理任务是长周期、有状态、可预测的。而 Agent 恰好卡在两者之间，并且同时具备了几种互相矛盾的属性： 第一，生命周期高度不确定。 一次 Agent 调用可能只触发一次工具查询就结束，也可能因为多轮推理、工具调用、结

过去十年，Runtime 一度被视为“沉默的底层”——它稳定、可靠，却很少成为技术叙事的中心。但随着云原生、AI 推理、边缘计算和异构硬件的同时爆发，Runtime 正在从幕后走向台前。它不再只是语言执行的容器，而正在成为软件性能、可移植性与安全边界的关键变量。本文尝试从技术演进与产业格局两个维度，讨论 Runtime 为何重新变得重要，以及它可能把软件产业带向何处。 Runtime 为什么重新成为焦点？ 在传统认知中，Runtime 是“语言的一部分”。Java 有 JVM，JavaScript 有 V8，Python 有 CPython，.NET 有 CLR。开发者写代码，Runtime 负责执行，二者相安无事。Runtime 的竞争，往往被简化为“性能 benchmark”或“生态成熟度”的比较。 但今天

过去两年，围绕 LLM 的讨论从“模型能力”迅速转向“应用落地”。但真正把智能体（Agent）推向生产环境的团队都会遇到同一个尴尬：单个 Agent 的 Demo 惊艳，一旦要部署几十个、上百个、上千个实例，工程复杂度会呈指数级上升。AgentCore 这类面向智能体运行时的基础设施出现，正是为了回答一个问题——当智能体不再是玩具，而是需要被调度、被观测、被治理的生产负载时，我们该用什么来承载它？ 依据现有素材判断，AgentCore 的定位指向智能体的规模化部署与运行时管理。本文不虚构具体版本号、性能数字或客户案例，而是从工程与产业视角，讨论它为何重要、规模化部署卡在哪里、以及它可能带来的结构性变化。 为什么“规模化部署”成了智能体的分水岭 1.1 单 Agent 与多 Agent 是两种问题 一个 Agen

过去两年，大模型在运维领域的落地经历了一条典型的“期望膨胀—现实回落—价值重估”曲线。最初，行业热衷于把 LLM 接进 IM 群聊，做一个能回答“这台机器为什么报警”的问答机器人；很快人们发现，问答本身并不解决运维的核心痛点——真正稀缺的不是解释，而是处置。2024 年以来，随着 Agent（智能体）范式的成熟，运维自动化的重心正在从“辅助人判断”转向“代替人执行”，一个以 Agent 为调度中枢的智能运维新架构开始浮现。 需要说明的是，本文基于公开的行业趋势与工程实践逻辑展开分析，不涉及具体厂商未公开的产品细节；凡涉及尚未形成共识的判断，文中会明确标注“依据现有素材判断”。 为什么是 Agent，而不是又一个“运维 Copilot” 要理解 Agent 智能运维的价值，先要理解传统运维自动化的天花板在哪里。

在软件工程过去二十年的叙事里，开发者最熟悉的敌人往往不是业务逻辑的复杂度，而是环境。一个项目从代码仓库到真正跑起来，中间横亘着依赖版本、系统库、编译工具链、运行时配置、网络代理、GPU 驱动、CUDA 版本、容器镜像、集群权限等一长串“非功能性障碍”。行业里有一个略带自嘲的说法：这不是编程，这是“环境工程”。 “环境即开即用”正在成为新的交付标准。它不是一个单点工具，而是一种从开发、测试到生产全链路的产品哲学：让环境像自来水一样，拧开就有，按需计量，用完即走。本文尝试从问题根源、技术路径与产业影响三个层面，讨论这场正在发生的交付革命。 配置地狱的代价：为什么“能跑”比“写对”更难 1.1 环境问题的本质是“状态漂移” 软件的可复现性，长期被低估。同一份代码，在 A 的笔记本上编译通过，在 B 的机器上失败，在

在云原生与 DevOps 的叙事里，“分支”一直是个轻量词。代码分支几乎零成本，想开就开，想删就删。但当同样的动作落到数据库上，事情就变得沉重起来——复制数据、等待同步、协调环境、担心污染生产。于是，一个被反复提及却始终难以兑现的承诺浮出水面：数据库分支，能不能也做到秒级？ 这个问题的答案，正在重新定义现代研发基础设施的边界。 为什么“秒级创建分支”是一个值得认真对待的命题 要理解秒级分支的价值，先要理解它试图解决的是什么。 在传统研发流程中，代码分支早已是肌肉记忆。开发者创建一个 feature branch，提交、评审、合并，整个过程以秒计。但支撑这个分支运行的数据环境，却往往以小时甚至天计。测试库需要从生产快照恢复，恢复过程可能耗时数小时；多个团队共用一套测试数据，彼此干扰；敏感数据在复制过程中被反复搬运

近年来，Agent（智能体）成为大模型落地最热的方向之一。但真正做过 Agent 产品的人都会遇到同一个尴尬：模型很聪明，记性却很差。一次对话结束，它就把你忘得干干净净；换个会话窗口，昨天聊过的偏好、约束、历史决策全部归零。 于是，"Agent 记忆"从一个工程细节，迅速上升为决定产品形态的核心命题。它不只是"把历史对话塞进 prompt"这么简单，而是关乎 Agent 能否从一次性工具，进化为可持续协作的数字主体。 依据现有素材判断，本文不引用具体产品版本或跑分数据，只从工程与产品逻辑出发，讨论 Agent 记忆的三条可能路径，以及它们各自将把行业带向何方。 记忆不是存储问题，而是"什么值得被记住"的问题 很多人对 Agent 记忆的第一反应是：加个数据库不就行了？把对话历史存下来，需要的时候检索出来拼进上下

过去十年，企业谈数字化转型，谈的是“上云”；未来十年，企业谈数字化深耕，谈的将是“数据底座”。当大模型与AI应用从演示走向生产，数据底座不再是后台的“仓库管理员”，而是决定企业智能化上限的“中央厨房”。本文尝试从技术演进与产业实践的交叉视角，给出三个判断。 重新定义数据底座：它不是数据库，而是“数据操作系统” 很长一段时间里，行业对“数据底座”的理解是模糊的。有人把它等同于数据仓库，有人把它看作数据中台换了个说法，还有人把它简化为“一堆数据库的集合”。这些理解在各自的历史阶段都有合理性，但放在今天，已经明显不够用了。 依据现有素材判断，我们倾向于给出这样一个定义：数据底座是企业范围内、支撑所有数据消费场景的底层能力集合，它至少包含四个层次——存储与计算引擎、数据治理与语义层、数据开发与调度体系、以及面向AI的数

过去二十年，数据库的核心命题是“如何高效地存储和查询数据”。无论是关系型数据库的行列之争，还是 NoSQL 对海量非结构化数据的妥协，抑或是 NewSQL 对分布式事务的探索，本质上都围绕着一个前提：人是数据的最终消费者。人类通过 SQL、API、可视化面板去读取数据、理解数据、做出决策。 但 AI Agent 的崛起正在打破这个前提。当 LLM 驱动的智能体开始自主规划任务、调用工具、读写记忆、协作分工时，数据库面对的不再只是“人”，而是一群会思考、会遗忘、会犯错、会并发的“数字员工”。这意味着，数据库需要被重新定义。 本文尝试从三个维度展开：从存储引擎到认知基础设施、从查询语言到意图协议、从一致性模型到记忆治理。这不是对现有数据库的否定，而是对下一代数据底座的一次前瞻性推演。 从存储引擎到认知基础设施：数据

过去十年，技术栈的演进主线是"云原生"——容器、微服务、Kubernetes 重新定义了软件的交付方式。而今天，一条新的主线正在浮现：AI 原生。它不是给现有系统加一个模型 API，而是从数据层、计算层到应用层，整条链路都在为模型重新排列优先级。这场变革的深度，可能被低估了。 从"云原生"到"AI原生"：一次底层假设的切换 云原生的核心假设是：基础设施是弹性的、可编排的，应用应当被拆成细粒度的服务，通过标准接口组合。这套逻辑统治了从 2014 年到今天的整个后端世界，Kubernetes 成为事实上的操作系统，微服务成为默认架构。 AI 原生提出的假设则不同。它的核心不是"服务如何编排"，而是"模型如何成为系统的一等公民"。这意味着几件事同时发生变化： 第一，计算资源的重心从 CPU 转向加速器。 云原生时代，

Anthropic 于 2026 年 10 月 8 日更新了 Claude 的使用政策。依据现有素材判断，这次更新的具体条款细节尚未完全公开，但“使用政策更新”这一动作本身，已经足以成为观察 AI 行业治理逻辑的一个切口。当模型能力越来越强，真正决定它能否被信任的，往往不是参数规模，而是那条看不见的边界画在哪里。 政策更新不是“合规补丁”，而是产品的一部分 过去几年，AI 公司发布使用政策，常常被外界当成一份法务部门准备好的“免责声明”。用户点开、滑到底、点同意，然后忘掉。但如果今天还把 Claude 的使用政策更新理解为一次例行公事，那就低估了这件事的分量。 Anthropic 选择在 2026 年 10 月 8 日更新 Claude 的使用政策，时间点本身就值得注意。依据现有素材判断，我们无法确认这次更新是

过去两年，大模型厂商的发布会关键词是“更强”——更强的推理、更长的上下文、更低的幻觉率。但进入 2024 年之后，一个微妙的变化正在发生：OpenAI 和 Anthropic 在对外沟通中越来越频繁地提到另一个词——合规。 从内容审核 API、企业级数据隔离，到模型行为规范、审计日志、区域化部署，两家公司不约而同地把“安全与合规”从后台的成本中心，推到了前台的产品卖点。这不是一次简单的功能更新，而是一场关于大模型商业化路径的深层博弈。 依据现有素材判断，本文不引用具体版本号、定价或未公开的基准数据，仅从公开的产品方向与行业逻辑出发，讨论这场合规竞赛意味着什么。 合规不再是“刹车”，而是“入场券” 1.1 从被动应对到主动产品化 早期的大模型厂商对合规的态度，更接近“被动防守”：监管问什么，就补什么；客户投诉什么

当整个行业还在争论 AI 生成内容该不该打标、怎么打标时，OpenAI 选择了一条更务实的路径——不追求技术上的“绝对不可移除”，而是把水印做成一种生态习惯。这看起来是妥协，实际上是一次相当聪明的落子。 水印这件事，难的不是技术，是“谁来认” AI 内容标识并不是新话题。从 C2PA 内容凭证标准到各家厂商的元数据方案，过去两年里，围绕“如何证明一段内容是不是 AI 生成的”已经出现了大量尝试。但真正落地时，行业很快撞上一堵墙：水印的价值不取决于生成方，而取决于验证方。 一段带水印的图片，如果社交平台在上传时自动剥离了元数据，如果截图工具不保留任何凭证，如果下游模型在二次编辑时把标识抹掉——那么再精巧的水印方案，也只是一串没人读得懂的字节。技术圈过去习惯用“鲁棒性”来衡量水印强度，但现实中的鲁棒性考验，往往不是

企业该如何部署自己的数据底座，让Context真正与业务结合，实现跨资产的流转链路?微软给出的答案是 Fabric——一个从数据分析平台进化而来的企业级AI运营底座!

过去两年，大模型能力的跃迁让“智能体”（Agent）从实验室概念迅速走向产业视野。但一个被反复讨论却尚未形成共识的问题是：智能体究竟运行在哪里？它需要怎样的底层支撑？当行业目光聚焦于模型参数、推理能力和应用场景时，一个更基础的趋势正在发生——云基础设施正在从“向下提供资源”转向“向上构建智能体平台”。这不是一次简单的产品迭代，而是云计算价值重心的结构性迁移。 从“资源底座”到“能力底座”：云的角色正在被重写 传统云计算的叙事逻辑是清晰的：以虚拟化技术为核心，把计算、存储、网络等资源池化，再以弹性、按需的方式交付给上层应用。IaaS、PaaS、SaaS 三层分工明确，云厂商的核心竞争力体现在规模、稳定性和成本效率上。 但智能体的出现打破了这套分工。一个可运行的智能体，至少需要四类能力同时在线：模型推理、工具调用、

过去两年，智能体（Agent）从演示视频走进了生产系统。但一个被频繁混淆的问题是：个人智能体和企业智能体，看起来都是“LLM + 工具调用 + 记忆”，它们真的是同一种东西吗？ 依据现有素材判断，二者在底层模型能力上确实同源，但在技术形态上正在分化为两个截然不同的物种。把它们当成同一类产品来设计、选型和部署，是当前企业智能化项目踩坑的主要来源之一。 个人智能体：以“体验闭环”为中心的单体形态 个人智能体的技术目标非常明确：让一个用户在尽可能少的操作下完成一件事。它的技术形态通常呈现以下特征： 单用户上下文：记忆、偏好、历史会话围绕一个人构建，上下文边界清晰，不需要考虑跨用户隔离。 工具集轻量且通用：搜索、日历、邮件、本地文件、浏览器操作等，工具数量有限，调用链路短。 部署形态简单：多数以 App、浏览器插件或桌

过去两年，围绕大模型的应用创新几乎都指向同一个方向：让模型不只是回答问题，而是能“做事”。于是，智能体（Agent）成为行业热词。从自动订票、写代码、做研究，到操作浏览器、调用企业系统，智能体被寄予厚望，被视为大模型从“对话能力”走向“生产力工具”的关键一跃。 但现实并不总是理想。大量智能体产品仍停留在演示阶段，真正能在复杂、长链路、高风险任务中稳定交付的案例并不多。问题并不只是模型不够强，也不只是工具不够多，而是智能体正在用旧架构应对新任务。换句话说，智能体要真正走向规模化落地，需要的不是再多一个插件、再多一轮提示词优化，而是一次“新的智能体架构变化”。 旧架构的瓶颈：把智能体当成“会调工具的模型”已经不够了 当前主流智能体架构，大致可以概括为“大模型 + 提示词 + 工具调用 + 记忆”的组合。它的基本逻辑