我在阿里云的这五年

2021年夏天，我加入阿里云弹性计算，在计算巢团队做研发。五年时间只做一件事，但这件事一直在生长——让软件部署从一门手艺变成一种基础设施。

我们做的事情说简单也简单，说复杂也复杂：给ISV（独立软件开发商）构建自动化部署的能力——一键部署云资源加上ISV的软件。用户不需要懂Kubernetes、不需要学资源编排模板、不需要自己配网络，点几下就能把一套企业应用跑在自己的云上。五年里这个能力不断完善，从最初只能支持几款简单应用，到如今覆盖阿里云上95%产品的一键部署，支持镜像、脚本、容器等多种软件交付方式，也长出了变配升级等软件全生命周期管理和按量付费、包年包月、试用等完整的售卖能力。

一、服务发布智能化：让ISV不写模板

计算巢的核心资产是ROS模板（一种云资源编排描述），ISV用它来描述"我的应用需要哪些云资源、怎么组装"。问题是——大多数ISV写不好这份模板。复杂架构几天才能写完，早期全靠我们的员工代写，人肉撑规模显然走不远。

模板写不好是门槛问题，更底层的一个问题是：软件到底怎么部署到云服务器上去。不同企业差异极大——有的用脚本安装，有的打包成ECS自定义镜像，有的直接扔容器。光把这些交付方式都支持下来就已经够复杂，再加上云是多地域的，问题会更棘手。ISV要手动把镜像复制到所有地域（20+个），然后在模板里维护地域映射表，费时又容易出错；文件分发要么依赖ISV自己的OSS产生费用，要么走公网下载，一旦ECS没开公网就挂了，如何可以通过内网快速拉取；容器镜像因服务商托管仓库不同，经常因为权限问题拉不下来。

为了解决这些问题，我们设计了部署物的体系：镜像部署物、文件部署物、容器部署物。核心思路是把"存在哪、权限谁管、怎么分发、怎么引用"四件事从ISV手里收走，由计算巢负责。ISV只需要上传一次资产，平台负责全地域分发和权限管控。在模板里写一个标志位，执行时自动替换成当前地域对应的实际ID或URL。

而对于模板本身，我们花了很多力气去降低撰写门槛。最开始我们观察到一个事实：大部分ISV的部署架构无非是基于ECS或ACK，在此基础上换几个部署物、新增几个云资源（比如挂一块NAS、加一个SLB）。真正从零设计全新架构的只是少数。

既然主流模式集中，那就不需要每个ISV都从头写模板。我们基于服务商最常用的架构组合，整理出一批规范化基础模板——涵盖ECS单机、ECS集群、ACK单可用区、ACK多可用区等典型场景，预置好网络拓扑和安全组规则，搭配部署物引用。ISV要做的只是把自己的镜像或文件上传，选一个基础模板，替换掉部署物参数，就能发布服务。大部分情况下，模板撰写量为零。

但对于稍复杂的场景——比如ISV的应用依赖了RDS、Redis、OSS、SLB等多种资源，且资源间的关联关系不是标准模式——基础模板套不进去。这时我们做了"资源反推"：ISV先在阿里云上手动把这套资源部署好，系统扫描已有资源实例，反向生成一份完整的ROS模板，再把可变的参数（实例规格、地域、密码等）提取为parameters暴露出来。ISV拿到的模板已经是可直接复用的，不需要理解模板语法。

最复杂的场景——架构本身需要从零设计、涉及多种云产品组合、关系复杂——老实说，前两条链路都不够用，很长一段时间里只能靠我们的员工手把手帮客户做完。2025年，随着大模型能力成熟，这个问题终于有了转机。我们引入了AI生成：先把计算巢的模板规范和最佳实践沉淀成标准skill，让模型直接产出符合规范的模板初稿；ISV只需要用对话描述"我需要哪些资源、输入参数是什么、要输出什么"，AI生成ROS模板后会自动调用校验接口做合规检查，最后人工确认再发布。随着模型能力和我们prompt调优的持续进步，AI产出的模板越来越接近可以直接用的程度。

与此同时，为了让习惯用代码管理的软件开发者也能快速上云，我们做了另一条路：给定一个GitHub仓库，通过AI分析项目结构，一键生成对应的计算巢服务，省掉开发者从零理解云编排的成本。

这套体系上线后，服务创建时间最快从一周压到一天，上百家对接客户用上了这套流程。

二、软件管理：部署完成只是开始

服务能一键部署了，但这只是软件生命周期的一半。真正难的往往在后面：用户业务量涨了，三台ECS不够用要加到五台，怎么办？服务商修复了一个Bug或上线了新功能，存量客户的服务实例怎么平滑升级到新版本？还有日常的运维、监控、日志排查——这些如果没有一套统一的管理面，ISV还得自己搭工具，体验就断了。

这块内容其实很多，这里主要说两个部分。

第一块是资源变配。服务实例创建完成后，随着业务变化，原来的资源规格或套餐可能就不够用了。计算巢的变配能力让用户可以直接在实例上调整云资源配置——扩容ECS、加大磁盘、调整带宽等，改完之后费用也会联动重算：按量付费的资源展示新的价格，周期付费的资源展示差价。前提是服务商在创建服务时预先定义了哪些参数可以变、有哪些档位，用户端才能自助操作，不用提工单等人工介入。

第二块是软件升级。服务商发布新版本后，用老版本创建的存量实例怎么跟上？这里我们复用了ROS模板做版本驱动：每个服务版本对应一份模板，升级时系统会对比新旧两版模板的差异，据此对资源栈做"保持不变、更新、删除、新建"四种操作，一次动作同时完成云资源和软件应用的升级。服务商不需要理解底层资源拓扑的变化，只要定义好两个版本即可。同时支持单个升级和批量升级，还提供了回滚——升级出问题可以退回上一个版本，给用户一个安全垫。

计算巢还支持很多管理功能，本处仅抛砖引玉，这些功能打通后，计算巢才算真正覆盖了一个软件从上架、部署到长期运营的完整闭环，而不只是"帮你装一下"。

三、售卖：最后一公里从0到有

一个应用可以部署、可以运维了，那最后的问题就是商业化——也就是，怎么收钱。部署做得再好，ISV收不到钱，就不会持续把产品放在你的平台上。

这里要先厘清一件事，计算巢本身不收费，而我们也不负责云资源的收费。云资源该收多少、怎么收，是各个云产品自己管的。我们要解决的是另一半——软件本身怎么定价、怎么卖。而"卖"这件事，我们是和阿里云云市场合作来做的：服务商在计算巢发布服务之后，可以把它作为一个商品上架到云市场，打通计算巢服务与云市场的交易链路。我做的事，就是让软件这一层的计收能力尽可能顺。

计费方式最终支持了四类：按次售卖（永久买断，属于预付费）、按周期售卖（包年、包月这种买固定时长并按周期续费，也是预付费）、按量售卖（后付费，先下单、按实际使用量付费），以及免费试用。软件的定价不是拍一个数就完事——同一个软件往往分基础版、高级版等不同商品规格，还可能挂额外计费项，比如按服务器数量收费。用户从基础版升到高级版、或者加几台服务器，价格都会变，这套规格与计费项的组合要在创建服务时就定义清楚。

最难的是按量付费，因为它绕不开"计量"。云市场原本的按量能力比较基础，只支持服务商自己主动推送计量数据，而且需要走公网调用API——服务商得自己采集用量、记录云市场实例ID和计量项、管理密钥，稍有环境限制就推不上去。我们在云市场的基础上扩展了自动计量：服务商只要在计算巢里配置好上报源、绑定计量项，计算巢就会帮忙自动采集并把数据推送到云市场。上报源支持三种——时间（直接用使用时长作为计量值）、Prometheus（从监控指标里采集CPU、内存、网络流量等）、账单（直接拉服务实例的账单）。这样一来，服务商不用记实例ID、不用管密钥、也不依赖公网，离线环境里内部通道照样能推。

试用是另一条链路。云市场本来就支持软件免费试用，计算巢则支持云资源免费试用，两边集成之后，用户在云市场下单一个免费试用商品，计算巢会自动创建出对应的试用服务实例，软件和资源都能限时免费体验完整功能。此外我们还做了付费周期的绑定：用户在云市场买的是软件时长，而底下云资源有自己独立的付费周期，两者本来容易对不齐。我们让用户只需要选软件购买时长，云资源的付费周期会自动同步成一致，省掉了"软件到期了但资源还在跑"这种尴尬。

这套体系跑起来之后，计算巢才真正闭环——ISV可以像上架App Store一样，把自己的云应用挂上去、定价、卖出去、把钱收回来。

四、Agent部署

2024年大模型落地进入深水区，行业共识是：Agent不能永远困在网页对话框里。企业需要私有Agent，但私有Agent的"私有"不只是"模型私有"——工具执行也要私有。让Agent操作文件、执行代码、访问内网，意味着必须有隔离环境。如果Agent要调用的工具和数据都在用户自己的VPC里，那Agent本身也必须部署在用户可控的基础设施上。

好在私有部署Agent这件事，和应用私有部署没有本质区别——Agent照样跑在ECS、函数计算或ACS上，计算巢这几年攒下的私有化部署能力可以顺理成章地延伸过来。真正的难点在于，Agent不是一个装完就结束的应用，而是一个需要不断"接东西"的载体：要挂记忆、知识库、会话历史，要接MCP和各种Skill，还要能在用户已经在用的IM里被随手唤起——钉钉、飞书、企业微信，每个频道的消息协议和回调方式都不一样。怎么把这么多能力和渠道标准化地组装进一次部署里，让不懂代码的用户也能几分钟搭出一个可用的私有Agent，这才是从零要啃的硬骨头。

我做了三件事来解决这个问题。第一，把部署目标从"一台ECS"扩展到ECS、ACS、函数计算三种形态，按Agent的实际负载选择运行时——轻量对话型Agent跑在函数计算上按请求付费，重负载工具型Agent用常驻的ACS容器，需要持久化数据或复杂环境的走ECS。第二，实现"零代码构建"路径——用户不需要写任何代码，只需要在平台上勾选工具、绑定IM频道（钉钉、飞书、企微），五分钟获得一个可用的私有Agent。第三，把Sandbox、记忆、知识库、skill、MCP做成一个可被Agent调用的Tool，用户按需创建、使用。

除此之外，我们还支持了Agent在线试用、WebUI交互、在线代码查看与修改、以及A2A协议对接等一系列能力，内容较多就不一一展开了。

写在最后

回头看这五年，我始终没换过团队，一直待在计算巢，围绕"让软件在云上被更好地部署、运维和售卖"这一件事做深做透。基础设施的工作大多是幕后的——它的价值恰恰在于，别人用你的东西时完全感知不到你的存在。但也正因为一直在同一口井里往下挖，坚持才有了复利。如果你也在做一个不起眼却有用的底层系统，希望这篇碎碎念能让你相信：坚持本身，就是一种回报。