Agentic Infra 之后，我更相信 Agent 竞争会落到运行时#

今天看到华为云发布 Agentic Infra 和 AgentSphere，我第一反应不是“又一家云厂商开始讲 agent”，而是：agent 这条线终于被推到了基础设施层。

过去一年，大家讨论 AI 热点时很容易盯着模型榜单：谁的推理更强，谁的上下文更长，谁的编码分数更高。但越做真实产品，我越觉得模型只是起点。真正把 agent 从 demo 推到生产环境的，是它周围那一整套运行时：token 供给、任务隔离、状态恢复、权限边界、观测、审计，以及人类能不能在关键节点重新拿回控制权。

华为云这次的说法里有几个点值得放在一起看。它把 Agentic Infra 描述成一个新范式，里面包括 token factory、continuous learning、统一调度通用计算和 AI 计算、secure autonomy。AgentSphere 则被定位成安全自治的 agent runtime，并强调轻量 sandbox、快速启动和大规模实例创建。旁边还有 AgentArts 这种企业级 agent 平台，覆盖长任务、安全、行业知识和端到端可观测性。

这组词在营销稿里看起来很满，但我更关心它背后的工程方向：agent 的单位不再只是一次 chat completion，而是一个可以被调度、隔离、复盘、持续改进的执行体。

我理解的变化：从模型调用到运行时对象#

如果把传统 LLM 应用拆开看，开发者最熟悉的是三层：

prompt 和工具调用。
RAG 或业务上下文。
一个把请求发给模型的服务端。

这个结构能撑起聊天、摘要、检索增强问答，也能撑起不少 Copilot 式功能。但它天然不擅长长任务。长任务会立刻暴露几个问题：

agent 需要中间状态，不能只靠一条 request/response。
agent 会调用真实工具，权限和审计不能靠约定。
agent 可能并发执行，隔离和资源配额不能靠应用代码临时补。
agent 会失败、重试、漂移，观测不能停在 token 日志。

所以我看到 AgentSphere 这种“agent runtime environment”的表述时，觉得它比单个模型发布更有趋势意义。它说明云厂商开始把 agent 当成一种需要原生承载的工作负载，而不是把 agent 当成普通 Web API 背后的某段业务逻辑。

这和 Microsoft 最近讲的“AI alone won't change your business. The system running it will.”是同一个方向。Microsoft 从 GitHub、Foundry、Agent 365、Microsoft 365 这条线讲企业 agent 系统；Cisco 从 Cloud Control 讲人和 agent 共用同一运营上下文；华为云今天则从 token factory、sandbox runtime、行业 foundry 和混合云白皮书切入。视角不同，但结论很接近：agent 真正进入生产，不是靠一个更聪明的模型，而是靠一个能运行它、约束它、观察它、让它持续变好的系统。

为什么我更在意 sandbox#

我最近对 agent 产品的判断越来越简单：没有隔离，就没有自治。

一个只能读文档、生成文本的 assistant，对 sandbox 的要求没那么高。可一旦 agent 开始改代码、跑命令、连数据库、申请云资源、触发部署，它就不再是“内容生成器”，而是“半自动执行者”。这时候安全问题不是抽象伦理，而是非常具体的工程问题：

它能不能越权读到不该读的数据？
它生成的脚本能不能影响同一机器上的其他任务？
它失败时能不能冻结现场，而不是把状态冲掉？
它的每一步动作能不能被回放和解释？
它拿到的 token、密钥、临时凭证有没有生命周期？

华为云这次强调 ultra-lightweight sandbox、secure autonomous runtime、intent protection，我不会把这些词直接等同于真实能力，但我认同方向。agent runtime 最终应该像容器、函数计算、CI runner、浏览器沙箱这些东西一样，成为开发者默认依赖的底座。

也就是说，未来的 agent 平台竞争，很可能不是“谁先做出一个更会聊天的入口”，而是“谁能给开发者一个足够便宜、足够快、足够可审计的执行环境”。

Token factory 是另一个信号#

另一个让我在意的词是 token factory。

过去我们谈 inference，多半是在讲模型吞吐、延迟、批处理、KV cache、量化、路由。token factory 这个说法更偏产品化：它不是单纯把 token 生成得更快，而是把 token 当成企业 agent 系统的基础产能。

这件事对开发者很现实。agent 和普通聊天最大的区别，是它会把一次用户意图展开成很多中间调用：规划、检索、工具选择、代码生成、验证、总结、回滚建议。用户看到的可能只是一条回复，底下烧掉的是一串 token 预算和执行预算。

如果 token 供给不稳定，agent 就会在体验上变得忽快忽慢；如果 token 成本不可控，企业就会把 autonomy 阉割成按钮式自动化；如果 token 调度和普通云工作负载割裂，agent 就很难真正进入业务系统。

所以统一调度通用计算和 AI 计算这件事，我觉得比发布一个新的 agent builder 更重要。builder 决定开发体验，调度决定它能不能规模化活下来。

我会怎么调整自己的技术判断#

这条新闻对我的直接影响，是我会更少把 agent 项目理解成“模型 API 的上层封装”，更多把它当成一种新的 runtime 产品。

如果我要评估一个 agent 平台，我会看这些问题：

它有没有稳定的任务生命周期，而不是只暴露 chat session。
它的工具调用是不是有权限模型、审计日志和回放能力。
它的执行环境是不是隔离的，能不能为每个任务生成干净上下文。
它有没有面向长任务的状态、检查点、取消、恢复和超时语义。
它的观测是不是能解释“agent 为什么做了这一步”，而不是只给 token 数。
它能不能在模型、工具、数据、部署环境之间做成本和风险调度。

这些能力听起来不如模型发布刺激，但它们更像真正的护城河。模型能力会继续涨，但企业和开发者最终买单的是“能不能把这东西放心放进工作流里”。

结尾#

我不确定 Agentic Infra 这个名字会不会成为长期术语，但我认为它指向的方向是对的：AI 时代的新基础设施，不只是训练更大的模型，也不是把所有应用都接上 chatbot，而是为能行动的智能体提供一套生产级运行环境。

今天这类发布越来越多，说明行业叙事正在从“模型像人一样聪明”转向“系统能不能承载一群会行动的模型”。这对开发者反而更重要。因为模型竞赛多数时候我们只能旁观，但 runtime、sandbox、observability、tool protocol、eval、deployment pipeline，这些是我们每天都要设计和承担后果的部分。

我现在更愿意把 agent 看成一种新型进程：它消耗 token，携带意图，调用工具，产生副作用，需要隔离，也需要被调度。谁能把这个“进程模型”做得足够可靠，谁才更有机会把 agent 从演示带进生产。

参考来源：