ITPub博客

当大模型从“聊天框”走向“执行体”，云计算的重心正在从算力调度转向上下文调度。Agent Native Cloud 不是把 Agent 跑在云上，而是让云本身为 Agent 而设计；而 Context Engine，则是这场重构中最容易被低估、却最可能决定胜负的一层。 从“算力云”到“Agent Native Cloud”：云原生的第二次抽象 过去十年，云原生的核心叙事是“把应用拆小、把调度做活”。Kubernetes 用声明式 API 和控制器模式，把无状态服务的弹性做到了极致。但这套体系有一个隐含前提：请求是短促的、无记忆的、可随意重试的。 Agent 打破了这个前提。 一个正在执行任务的 Agent，可能持续数小时甚至数天，期间不断调用工具、读写文件、等待外部事件、修正自己的计划。它是有状态的、长生命周期

在 AI 大模型训练、自动驾驶仿真、气象预测、基因测序等高性能计算场景中，算力从来不是唯一的瓶颈。当数千张 GPU 同时等待同一份训练数据，当单个检查点文件动辄数十 TB，存储系统往往成为压垮整个集群的那块短板。CPFS（Cloud Parallel File System，云并行文件系统）正是为破解这一困局而生。本文尝试从架构逻辑、性能机理与落地挑战三个维度，拆解这类高性能存储系统的真实价值与边界。 为什么传统存储撑不起高性能计算？ 要理解 CPFS 的意义，必须先理解它要解决的问题。 第一，带宽与 IOPS 的错配。 传统 NAS 存储在设计上优先考虑容量与共享便利性，元数据服务和数据服务往往耦合在同一套节点上。当数百个计算节点并发读取同一数据集时，元数据操作会迅速成为瓶颈，带宽利用率急剧下降。而高性能计算

当行业还在争论大模型参数规模与推理成本时，一个更底层的问题正在浮出水面：Agent 到底在哪里运行？ 如果说 LLM 是 Agent 的大脑，那么 Sandbox（沙箱）就是它的身体、手脚和活动边界。没有可靠的执行环境，再聪明的 Agent 也只能停留在对话框里。本文尝试从基础设施视角，讨论 Agent Sandbox 为何正在从“附属组件”升级为“AI 时代的新操作系统”。 为什么 Agent 需要一个“沙箱”，而不是一个“函数” 传统 API 调用是确定性的：输入 → 处理 → 输出。而 Agent 的行为模式完全不同——它会规划、调用工具、读写文件、执行代码、访问网络，甚至自我修正。这意味着 Agent 天然具备副作用。 一旦具备副作用，安全边界就成了刚需。依据现有素材判断，Agent Sandbox 的

过去两年，大模型应用的重心正在从“对话”转向“行动”。当 LLM 被赋予工具调用、记忆、规划与多步执行能力之后，Agent 不再只是一个问答接口，而更像一个可以自主完成任务的软件实体。它能够读取数据库、调用 API、操作工单系统、发送邮件、执行代码，甚至在多个系统之间串联业务流程。 问题也随之而来：当 Agent 开始“动手”，企业面对的就不再只是模型准确率问题，而是权限、审计、成本、安全、可观测性和生命周期管理问题。 这正是 Agent 构建治理平台出现的背景。依据现有素材判断，AgentCore 所指向的，不是又一个 Agent 开发框架，而是面向 Agent 构建与运行阶段的治理平台。换句话说，它关注的不是“如何让 Agent 更聪明”，而是“如何让 Agent 在企业环境中可被构建、部署、监控、约束和审

过去十年，云计算的竞争主线是“资源”——谁有更多算力、更便宜的存储、更弹性的网络。但当 LLM 驱动的 Agent 开始接管任务编排、工具调用和跨系统操作时，云的核心价值正在从“提供资源”转向“交付结果”。Agentic Cloud，可能正是这场迁移的名字。 从“人操作云”到“Agent 操作云”：一次交互范式的迁移 要理解 Agentic Cloud，先要理解今天我们用云的方式有多“笨”。 无论是 IaaS、PaaS 还是 Serverless，本质都是人把意图翻译成配置：工程师写 Terraform、点控制台、调 API、配 IAM 策略、看监控面板。云提供了极强的能力，但所有编排逻辑仍然由人来完成。云是“被动的”，它响应指令，但不理解目标。 Agentic Cloud 的核心变化在于：云开始理解目标，并自

当模型不再是稀缺资源，Context 成为新的战场。 过去两年，AI 行业的叙事主线几乎都围绕模型展开：参数规模、推理能力、榜单排名、多模态支持。但进入 2025 年之后，一个越来越清晰的趋势是——模型本身正在快速商品化。头部模型之间的能力差距在缩小，开源模型追赶速度加快，API 价格持续下探。当"用哪个模型"不再是一个决定性问题时，真正的差异化就转移到了另一个维度：Context（上下文）。 这不是一个新鲜概念，但它正在从工程细节升级为产品战略的核心。谁掌握了更完整、更精准、更实时的上下文，谁就能让同一个模型输出截然不同的价值。换句话说，模型是引擎，Context 是燃料和路况信息——引擎再好，没有对的输入，也跑不出对的结果。 Context 到底是什么：从 Prompt 到系统级记忆 很多人把 Contex

过去两年，大模型领域的讨论几乎被“参数规模”“榜单分数”“推理成本”这几个关键词垄断。每一次新模型发布，舆论的第一反应往往是跑分对比：MMLU 涨了几个点，代码能力提升了多少，上下文窗口又翻了几倍。但如果真正把一个大模型放进生产系统里跑上几周，你会发现一个被长期低估的事实：决定最终效果的，往往不是模型本身，而是包裹在模型外面的那一层 Harness。 本文尝试从 Model 与 Harness 的关系出发，讨论一个正在发生的转变——模型能力的边际提升正在放缓，而围绕模型的工程编排层，正在成为新的竞争焦点。 重新理解 Harness：它不是“胶水”，而是模型能力的放大器 在传统软件工程语境里，Harness 常被理解为测试脚手架或执行框架。但在 LLM 应用里，Harness 的含义要宽泛得多。它至少包含以下几个

过去一年，Agent（智能体）从演示视频里的“魔法”迅速走向生产环境。但真正做过落地的人都知道，写一个能跑的 Demo 只要一个下午，让它稳定、可控、可观测地跑上三个月，才是真正的难题。本文尝试从开发与运行两个维度，梳理 Agent 工程化正在形成的共识与分歧。 开发范式：从 Prompt 编排到“运行时契约” Agent 开发的第一代实践，几乎等同于 Prompt Engineering。开发者把任务拆成若干步骤，用自然语言描述角色、工具和输出格式，再串成一条链。这种方式在单轮、确定性任务上表现不错，但一旦任务变长、工具变多、环境开始变化，问题就集中爆发：上下文膨胀、工具调用失败、模型“忘记”中间结论、错误在链条上被放大。 于是，行业开始把注意力从“怎么写 Prompt”转向“怎么定义运行时契约”。所谓运行时

当大模型能力逐渐成为基础设施，围绕智能体（Agent）的构建、调试、评测与运营工具，正在成为新一轮技术竞争的焦点。Agent Studio 作为这一趋势的集中载体，正从早期的“提示词调试面板”演化为企业级智能体生产流水线。本文基于公开技术趋势与行业通用实践，梳理 Agent Studio 的发展现状、关键能力与未来走向。 Agent Studio 的定位演进：从单点工具到全生命周期平台 1.1 早期形态：提示词与工作流的试验场 Agent Studio 最初以“提示词工程工具”的面貌出现。开发者可以在可视化界面中编写系统提示词、调整模型参数、接入少量工具（Tool），并实时观察模型输出。这一阶段的核心价值是降低 LLM 应用的试错成本，让非算法背景的工程师也能快速搭建原型。 随着 ReAct、Plan-and-

当大模型从聊天窗口走进业务流程，模型服务面对的核心问题正在改变。过去我们关心的是“一次推理能不能跑通、延迟够不够低”，现在越来越多团队关心的是“一个 Agent 能不能连续工作几小时、几十步不崩、不失控、不烧穿预算”。这不是同一个工程问题。模型服务需要为 Agent 负载重新设计。 Agent 负载改变了模型服务的假设 传统模型服务的隐含假设很清晰：请求是短时的、无状态的、彼此独立的。一次请求进来，模型生成一段文本，请求结束，连接释放。服务端的优化目标也很明确——吞吐、延迟、显存利用率。批处理、KV Cache 复用、连续批处理（continuous batching）这些技术，都是围绕这个假设展开的。 Agent 负载打破了这个假设。 一个 Agent 完成任务，往往不是一次调用，而是一串调用：规划、调用工具

当行业还在为 Token 消耗量、模型参数规模欢呼时，真正决定 AI 商业命运的，已经变成了另一个问题：它到底交付了什么结果？ Token 经济的幻觉：我们曾用“烧得多”证明“用得好” 过去两年，AI 行业形成了一套近乎默认的价值叙事：Token 消耗量等于使用深度，使用深度等于商业价值。 这套逻辑并非毫无道理。在大模型能力快速迭代的阶段，Token 调用量确实是最容易获取、最容易比较、最容易写进融资 PPT 的指标。API 调用次数增长、日均 Token 消耗突破某个量级、推理算力需求翻倍——这些数字构成了一个直观的“AI 繁荣度”仪表盘。云厂商按 Token 计费，模型厂商按 Token 分成，应用层按 Token 估算成本，整条产业链围绕“消耗”建立起了计量体系。 但问题在于，消耗本身不是价值。 一个反复

过去两年，人工智能的叙事主线一直停留在屏幕里：大模型会写代码、会做 PPT、会通过考试。但进入 2025 年，行业讨论的重心正在发生一次明显的迁移——从“模型能说什么”转向“机器能做什么”。具身智能（Embodied AI）由此从学术论文里的概念，变成了产业界争相下注的赛道。 所谓具身智能，通俗地说，就是让 AI 拥有物理身体，能在真实世界里感知、决策并执行动作。人形机器人、四足机器狗、机械臂、自动驾驶车辆，都可以被纳入这个范畴。它的想象空间足够大：工厂里的柔性装配、仓储中的分拣搬运、家庭中的陪护与家务、危险环境下的巡检与救援。也正因如此，资本和巨头在短时间内密集入场。 但如果把镜头拉近，会发现一个略显尴尬的现实：硬件层面的“身体”正在快速成熟，而软件层面的“经验”却严重不足。 电机、减速器、灵巧手、传感器、算

当大模型能力逐渐商品化，AI 竞争的焦点正在从“谁的模型更强”转向“谁能让智能无处不在”。AI 操作系统，这个曾被视作概念炒作的方向，正在成为巨头与创业者共同押注的下一个基础设施战场。 什么是 AI 操作系统：不是“AI 版 Windows”，而是智能的调度中枢 讨论 AI 操作系统，首先要厘清一个常见误解：它并非简单地在传统操作系统上叠加一个聊天入口，也不是把大模型塞进系统设置里。依据现有行业实践判断，AI 操作系统的核心命题是——让智能成为一种可被系统级调用的基础能力，而非某个独立 App 的功能。 从这个角度看，AI 操作系统至少承担三层职责： 资源调度层：统一管理本地与云端的算力资源，包括 CPU、GPU、NPU 以及异构加速单元，决定推理任务在端侧还是云侧执行。 模型编排层：调度不同规模、不同模态的模

9月10日，紫光云正式发布紫鸾AI操作系统。该产品定位为面向智能体的政企级AI操作系统，旨在通过统一管理和调度算力、模型、数据知识及应用能力，为智能体在政企私域环境中的开发、运行和运营提供系统支撑。

过去十年，企业数据基础设施的核心命题是“把数据存好、算准、查快”。数据仓库、数据湖、湖仓一体、指标平台轮番登场，本质上都在解决同一件事：让人类分析师和 BI 工具更高效地消费数据。但当一个又一个 AI Agent（智能体）开始接管查询、分析、决策甚至执行动作时，数据底座的“消费者”变了——从人变成了机器，从“看报表”变成了“做事情”。这不是一次简单的接口升级，而是数据基础设施底层逻辑的重塑。 为什么智能体会“逼”数据底座重构？ 1. 消费主体从人变成 Agent，交互范式彻底改变 传统数据栈的设计假设是：人类提出一个相对明确的问题，系统返回一张表或一张图。而智能体的工作方式是多轮、自主、带工具调用的。它不会只问一次“上季度销售额是多少”，而是会连续发起“查指标定义→拉明细→做归因→生成结论→触发下游动作”这样一

过去两年，大模型的能力跃迁让“AI操作系统”这个曾经偏概念化的词重新回到产业视野。但真正值得关注的变量，不是模型参数又涨了多少，而是 为什么说智能体正在“下沉”为操作系统能力 传统操作系统管理的是 CPU、内存、文件、进程和外部设备，向上提供系统调用，向下屏蔽硬件差异。移动时代，iOS 和 Android 把触屏、传感器、应用商店变成新的系统原语。而到了 AI 时代，智能体正在成为新的“进程”：它有目标、有状态、有工具权限、有生命周期，也需要被调度、隔离、审计和回收。 这个类比并非文字游戏。当用户对系统说“帮我整理上周的会议纪要，发给项目组，并把待办同步到日历”，背后至少涉及： 意图理解与任务拆解 跨应用数据读取权限 工具/API 调用编排 长短期记忆读写 执行结果校验与回滚 这些能力如果每个 App 各自实现

过去两年，企业谈 AI 落地，话题大多集中在模型本身：参数规模、推理能力、上下文长度、榜单排名。但进入 2025 年之后，一个更现实的问题浮出水面：模型能力增长得很快，但支撑它稳定运行的底座，并没有同步升级。 所谓“智能底座”，并不是单一产品，而是由算力基础设施、操作系统与云平台、数据与模型服务、调度与安全体系共同构成的一整套支撑层。它决定了 AI 能不能从演示走向生产，从单点试用走向规模化部署。 依据现有素材判断，当前行业正在经历一轮明显的底座重构：算力从“堆卡”转向“调度”，系统从“兼容 AI”转向“为 AI 原生设计”，模型从“孤立能力”转向“被平台化调用”。这三件事叠加在一起，才是“智能底座升级”的真正含义。 算力底座：从“有多少卡”转向“能不能高效调度” 1.1 堆算力的边际收益正在下降 早期做 AI

过去十年，云市场的核心叙事是“上云”。企业把服务器、数据库、存储、网络从自建机房搬到公有云，云厂商则把 IaaS、PaaS、SaaS 层层堆叠，形成一个巨大的资源货架。谁的产品目录更长、价格更低、区域覆盖更广，谁就能在云市场占据优势。 但进入大模型与智能体时代，这套逻辑正在失效。企业不再只问“你能提供多少算力、多少存储”，而是问“你能不能帮我更快地把 AI 能力嵌入业务”。云市场正在经历一次从“资源交易场”到“能力操作系统”的智能升级。依据现有素材判断，这一趋势已经在多个层面显现，但具体产品版本、市场规模和厂商数据仍需更多公开信息支撑。 云市场的旧范式：资源标准化与价格战 传统云市场的底层假设是：计算、存储、网络、数据库等资源可以被标准化、计量和售卖。用户通过控制台或 API 购买实例，按量付费或包年包月。云厂

过去两年，AI 平台的竞争主线是“有没有”。有没有大模型、有没有 GPU 集群、有没有推理 API、有没有 Agent 框架。而进入 2025 年之后，这条主线正在快速切换为“好不好用”。平台之间的差距，不再是谁先上线了某个功能，而是谁能把模型、算力、数据、工具链和治理能力真正整合成一条稳定、可运营、可规模化的生产线。 需要说明的是，本文依据现有素材判断，不针对某一家具体厂商的产品版本、参数或发布时间做事实性描述，而是从行业整体演进的角度，讨论 AI 平台这一轮“全面升级”的底层逻辑、关键变化与潜在风险。 升级的本质：从模型中心走向“平台工程” 这一轮 AI 平台升级，最容易被误读为“又发了一个更强的模型”。但如果只盯着模型参数和榜单分数，就会错过真正的变化。模型能力仍然重要，但它正在从“稀缺资源”变成“可替换

过去两年，几乎每一家做企业软件的公司都在讲同一个故事：把大模型塞进办公场景。会议纪要自动生成、邮件智能润色、文档一键总结——这些功能从惊艳到平常，只用了不到十八个月。当"AI 能力"不再是差异化卖点，而是产品说明书里的一行小字时，智能办公才真正进入深水区。 本文不打算罗列功能清单，而是想讨论三个正在发生的结构性变化。它们决定了未来三到五年，办公软件会变成什么样，以及企业和个人应该提前做什么准备。 需要说明的是，本文基于公开的行业观察与技术逻辑推演，不引用具体未公开的产品数据；涉及判断的部分，会明确标注为观点。 交互层：从"人找功能"到"意图直达" 传统办公软件的组织逻辑是功能菜单：想加粗就找加粗按钮，想插入表格就找表格入口。这套逻辑统治了桌面软件三十年，因为它假设用户知道自己要什么，也知道工具能做什么。 大模型