一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > 产品思考 > 正文内容

回归阿里云九个月：拥抱变化，理解变化，接受变化

anycodes3个月前 (06-03)产品思考2810

![](https://runor.cn/zb_users/upload/2026/06/202606032249561130785.png)

马上又要到 618 了。

我第一次加入阿里云，是 **2020 年 6 月 18 日**。今天是 **2026 年 6 月 3 日**，离又一个 618 已经很近了。

而我第二次回到阿里云，是 **2025 年 9 月 1 日**。

那天是学生开学的日子。某种意义上，对我来说，也像是一次重新开学。

这一次回来，还是阿里云，还是 Serverless 团队，还是以前那一拨人。外人看起来，这好像是一种稳定，像是回到熟悉的地方。但对我自己来说，**二进宫阿里云，其实是一件非常冒险，也非常需要勇气的事情。**

因为我不是没有离开过，也不是没有过另一种生活。

在 AWS 的那段时间，我过着相对平衡的生活，面对企业客户，做架构治理，看行业实践，也用另一种视角重新观察云计算、Serverless 和 AI 的关系。但越是在外面看，越会意识到一个问题：**Serverless 在国内的落地，一直是不温不火的。**

它不是没有价值。相反，我一直认为 Serverless 是非常有价值的架构方向。只是过去几年，它没有真正等到属于自己的大规模场景。

直到 AI 浪潮起来，我开始重新看到一线生机。

**AI 应用天然需要弹性、事件驱动、工具调用、任务编排、沙箱执行、异步处理、成本控制和快速交付。**这些问题和 Serverless 的能力边界高度重合。换句话说，AI 也许不是 Serverless 的一个附属场景，而可能是 Serverless 重新进入主战场的一次机会。

也是在这样的判断下，和老板、老同事沟通之后，我决定回到阿里云。

但回来之前，我其实很清楚，**这不是一次轻松的回归。**

我离开阿里云的原因有很多。一个现实原因，是博士毕业。那几年我一直在工作、产品、开源、写书、论文之间来回切换，博士毕业却始终像一件悬在远处的事情。我对“博士”这件事本身有追求，不只是为了一个学历，而是希望自己真的完成一段相对完整的研究训练。

另一个原因，是那段时间我确实非常疲惫。

很多事情在当时都有预期、有判断，也有明确的上线目标，但真正推进起来并不容易。有些问题表面上看是沟通问题，深一点看，其实是协作机制、资源节奏、产品边界和执行链路没有形成真正的合力。

对我来说，那时其实已经“没电了”。

所以这次回来之后，我给自己的要求很明确：**不能只是再来一次。**我必须比以前做得更好，也必须避免过去的问题再次发生。该坚持的时候，要更坚定一些；该判断的时候，要更清楚一些；该承担的时候，也要更直接一些。

![](https://runor.cn/zb_users/upload/2026/06/202606032258412898391.png)

这种感受，和过去做 Serverless 应用中心、Serverless Devs 的经历有很大关系。

当年做 Serverless 应用中心时，团队里有人说它是“全村的希望”。这句话听起来有点玩笑，但也代表了大家对它的期待。我们希望它能让 Serverless 应用从创建、开发、部署到运维形成一个更标准的流程，也希望它能成为开发者真正进入 Serverless 的入口。

但真正开始做的时候，问题很快就来了。

比如流水线。

我当时的判断是，应用中心里的流水线应该更轻，只做必要的连接和编排，更多能力应该和 GitHub Actions、GitLab CI、云效等已有 CI/CD 工具集成，而不是自己重新做一套完整流水线。因为流水线看起来只是一个功能，背后却是任务编排、状态管理、权限、变量、环境、回滚、审计、插件生态和失败重试。

**这不是一个小功能。**

后来多环境也是类似。我一直认为，多环境对 Serverless 架构当然重要，但它更应该是一套最佳实践，而不一定应该被做成一个很重的产品功能。尤其 Serverless Devs 本身更像是一个偏无状态的工具链，让一个无状态过程去长期管理有状态资源，这件事本身就很别扭。

回过头看，我并不认为 Serverless Devs 是失败的。直到今天，我也不觉得它失败。它进入过 CNCF Sandbox，成为多个云厂商和企业的工具链底座，也支撑了内部大量真实场景。**一个开源项目能被真实业务采用，被不同云厂商集成，被开发者持续使用，这本身就已经说明它完成过自己的历史使命。**

只是它也让我学到一件事：**做产品，不能只看某一个声音，也不能因为某个声音很大，就轻易改变对目标用户和产品本质的判断。**

我们可能服务了一千个、一万个、十万个用户，这些用户都觉得一个能力是 OK 的，是能解决问题的。但只要有一个用户强烈质疑，团队就很容易开始自我怀疑：是不是方向错了？是不是产品有问题？

当然，用户反馈一定要听。但更重要的是，要分清楚：**这是目标用户的普遍问题，还是某个非典型场景下的个体感受？这是产品方向错了，还是提示、链路、体验和文档还不够好？**

这也是我现在做 AgentRun 时不断提醒自己的事情。

AgentRun 是我这次回到阿里云后最重要的一件事。

它从第一天起，就不是在一张白纸上开始的。每一个相关产品都希望 AgentRun 能和自己发生关系，都希望在这个新的 AI Agent 入口里找到自己的位置。站在组织协同的角度，这些诉求都有道理；但站在产品体验的角度，我一开始就有判断：**如果第一版承载太多集成，体验一定会受到影响。**

后来第一版赶在重要发布节点前上线，反馈确实不算理想。

那段时间压力非常大。但我心里也清楚，第一版的问题并不只是某个页面、某个功能、某个交互的问题，而是它一开始就背负了太多目标。于是我和大家说，再给我一点时间，我会重构一个新的版本。

后来我们很快推进了 **AgentRun 2.0**，并在 **12 月 3 日**发布。

那一版上线后，反馈开始发生变化。很多人第一次觉得，这个产品是能看的，是有希望的。更重要的是，哪怕没有大规模市场推广，还是有很多企业客户开始进来调研、试用 AgentRun，也开始认可里面的一些能力。

这对我来说很重要。

因为它说明 AgentRun 不是一个靠概念撑起来的产品。它确实切中了企业在 AI Agent 落地过程中的真实问题：**运行、工具、沙箱、权限、空间、资源隔离、可观测、企业治理。**

它当然还有很多体验问题，但至少在我看来，**它已经具备了一个好产品的雏形。**

最近几个月，围绕 AgentRun，我们也经历过一些方向选择。比如面对 OpenClaw、超级 Agent、托管 Agent Loop、IM、定时触发等公开能力和产品形态时，团队需要不断判断：哪些是短期热点，哪些能沉淀为长期能力；哪些适合快速集成，哪些应该成为自己的核心产品体验。

这类判断并不容易。

我曾经更想推的是超级 Agent，也就是托管 Agent Loop，希望它成为企业 Agent 的超级入口。这个方向如果补上 IM、定时触发等能力，其实可以形成一个更安全、更自主、更可控的 Claw 形态。我当时甚至给它起过一个名字，叫 **FunClaw**。

但产品发展从来不是一个人的线性推演。团队会面对热点，会面对资源约束，会面对不同产品之间的协同，也会面对短期目标和长期能力之间的拉扯。**有些选择最后会被证明值得，有些选择则会提醒我们：内部创业最怕的不是慢，而是在关键窗口期里分散注意力。**

这也是做产品最痛苦的地方。

很多时候，我并不是没有判断。相反，我对自己的产品判断是有信心的。

做 Serverless Devs 时，我判断它应该进入 CNCF Sandbox，也判断它会给阿里云 Serverless 带来生态和心智上的价值。那时候也有人问我：为什么其他云厂商会采纳你做的工具？凭什么？

后来事实证明，他们确实用了。因为它真的解决了问题。

我曾经说，不应该自己做一套重流水线，不应该把多环境做成复杂产品功能。后来很多结果也验证了这些担忧。两年前，我也说过，**世界上从来不需要第二个 Dify。**当一个产品决定自己的目标是对标 Dify 的时候，某种程度上就已经输了。因为用户不需要一个“差不多的替代品”，用户需要的是在特定场景下更好、更准、更不可替代的产品。

还有一个最近的例子，是 AI Coding。

今年 4 月，我曾经判断，很多 AI Coding 工具未来可能不只是“写代码的工具”，而会逐渐变成 AI 应用的重要入口。因为当开发者越来越习惯在 AI Coding 工具里描述需求、生成代码、调试应用、调用工具，下一步很自然就会延伸到应用发布、应用部署、运行管理和线上治理。

也就是说，**AI Coding 工具的上层，很可能会长出一套新的应用发布和部署体系。**

当时很多人并不相信这个判断，觉得 AI Coding 只是辅助编码，离应用运行和部署还很远。但很快，CMA 这样的东西出现了，Qoder 团队也开始做 Cloud 的 Agency。你能明显感受到，AI Coding 正在从“代码生成工具”变成“应用生产入口”，甚至可能进一步影响云上应用的交付方式。

包括我后来推动 FunModel 重构，短期内也带来了用户和业务数据的明显增长。Stable Diffusion 第一波起来时，我们做 AIGCaaS，也确实抓住了场景。

所以我不否认，**我是一个有产品 sense 的人。**

但这份信心并不会让我轻松。恰恰相反，它有时候会让人更痛苦。因为当你提前看到一个方向可能会失败，而团队仍然决定投入时，你会很难受；当你看到一个方向可能会成功，但资源被分散、节奏被打断、组织不再形成合力时，你也会很难受。

**产品经理最难的地方，不是有没有判断，而是你的判断能不能被组织相信，能不能变成团队共同的行动。**

如果判断只停留在一个人的脑子里，它最终只是焦虑。只有当判断被团队理解、被资源支持、被执行兑现，它才会变成产品结果。

![](https://runor.cn/zb_users/upload/2026/06/202606032307138651364.png)

这九个月里，我经历了从兴奋、压力、重构、看到希望，再到重新迷茫的过程。

有时候我也会想，自己的出路到底是什么。是继续留在这里，等待变化，继续推动 AgentRun 往前走；还是去另一个互联网公司，找一个更能集中资源打仗的环境；或者换一条路，去做博士后，去高校或体制内，把这些年在工程、产品、论文、专利、开源和产业实践里的积累，换一种方式继续延展。

说实话，我现在也没有答案。

过去几年，我从阿里到南网，到 AWS，又回到阿里。每一次变化，外人看起来可能都有一个清楚的理由，但只有自己知道，真正身在其中时，很少有什么选择是完全确定的。很多时候，都是在不确定里做判断，在焦虑里做取舍，在看不到结果的时候继续往前走。

所以回头看，我这几年最深的感受可能就是：

**拥抱变化，理解变化，接受变化。**

但接受变化，不代表放弃判断；理解变化，也不代表随波逐流。对我来说，真正难的是：**在变化里保留自己的判断力，在被消耗之后还能重新长出行动力，在一次又一次不确定里，仍然尽量把自己相信的事情做对。**

回归阿里云九个月，我依然相信 Serverless 和 AI 结合的机会，也依然相信 AgentRun 这样的产品有价值。

只是我也比以前更清楚：**一个好产品，不只是被设计出来的，也是被组织、资源、耐心和共同信任一起托举出来的。**

这九个月不是答案。

它更像是一段新的提问。

扫描二维码推送至手机访问。

本文链接：https://runor.cn/?id=51

分享给朋友：

返回列表

上一篇：为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

下一篇：在 AgentRun 上的思考：传统 Infra 必须再做一层

“回归阿里云九个月：拥抱变化，理解变化，接受变化” 的相关文章

刘博说云

大家都在搜：

回归阿里云九个月：拥抱变化，理解变化，接受变化

“回归阿里云九个月：拥抱变化，理解变化，接受变化” 的相关文章

AI Coding 的终点不是写代码，而是应用生产入口

产品对标的陷阱：为何技术优势不等于市场成功

产品的最后一公里：从功能到价值的关键跨越

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

Agent平台：脏活累活，也许才是竞争力的基础

五个人教一个人点鼠标：云服务的荒诞现实

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

回归阿里云九个月：拥抱变化，理解变化，接受变化

“回归阿里云九个月：拥抱变化，理解变化，接受变化” 的相关文章

AI Coding 的终点不是写代码，而是应用生产入口

产品对标的陷阱：为何技术优势不等于市场成功

产品的最后一公里：从功能到价值的关键跨越

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

Agent平台：脏活累活，也许才是竞争力的基础

五个人教一个人点鼠标：云服务的荒诞现实

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论