一名云计算从业者的思考

大家都在搜：

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

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

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

anycodes10个月前 (07-20)产品思考4580

## AgentCore的发布：一次产品哲学的宣示

AWS的Amazon Bedrock AgentCore带来了 AI Agent Infra 的一波小热潮，这个专门为AI Agent设计的基础设施平台包含了Runtime、Memory、Identity、Gateway等7个核心服务。表面上看，这只是AWS产品线的又一次扩充，但深层次看，这其实是一次重要的产品哲学宣示。

![](https://www.runor.cn/zb_users/upload/2025/07/202507201912262107274.png)

AgentCore的发布传递了一个明确信号：AWS认为AI Agent需要专门的基础设施，Lambda无法胜任这个角色。这个判断背后隐含着一个更深层的问题：当新的技术需求出现时，我们应该改造现有工具，还是创造新的专用工具？

有趣的是，在AgentCore发布的同一时期，阿里云选择了完全不同的路径。他们没有直接推出新的AI专用 FaaS计算服务，而是对函数计算FC进行了大幅升级[：运行时间从分钟级别扩展到24小时，增加了Session亲和性，支持了多种AI场景的沙箱模式](https://mp.weixin.qq.com/s/f7dcspyXfpeCL2B2NX-Kng "：运行时间从分钟级别扩展到24小时，增加了Session亲和性，支持了多种AI场景的沙箱模式")。

这两种不同的选择，引出了关于技术边界的根本性思考。

## Serverless的技术边界：人为限制还是技术必然？

AgentCore的诞生暴露了一个长期被忽视的问题：Serverless架构中的许多"限制"实际上是人为设定的产品策略，而非技术边界。

Lambda的15分钟执行限制看似是技术约束，但从技术角度来说，容器技术、资源调度、状态管理这些底层能力在云计算发展的十多年中已经相当成熟。这个限制更像是AWS为了保持服务简单性、可预测性而做出的产品决策。

当AI应用的市场价值足够大时，这些人为设定的边界就成为了需要重新审视的对象。AWS选择保持Lambda的边界不变，为AI创造专门的AgentCore；阿里云则选择直接突破FC的限制，让平台进化适应新需求。

这种差异反映了技术发展的一个重要规律：技术的边界往往不是由技术本身决定的，而是由商业价值和产品策略决定的。当足够大的市场机会出现时，看似不可能突破的技术限制往往都能被解决。

## AWS的边界坚持：专业工具的纯粹性

AWS面对AI时代的挑战时，选择了一条看似"保守"但实际上很有策略性的路径：保持Lambda的专业边界，专门为AI场景创造AgentCore。

> 额外对比一下 AgentCore Runtime 和 Lambda 的区别。

> 功能对比

> | 特性         | AgentCore Runtime        | AWS Lambda         |
| ------------ | ------------------------ | ------------------ |
| **设计目标** | 专为 AI Agent 设计       | 通用无服务器计算   |
| **运行时长** | 支持长达 8 小时          | 最长 15 分钟       |
| **会话管理** | 内置会话隔离和上下文管理 | 需要自行实现       |
| **AI 集成**  | 原生支持 AI 框架和模型   | 需要自定义集成     |
| **身份管理** | 内置 AI Agent 身份控制   | 使用 IAM 角色      |
| **状态管理** | 内置内存和状态管理       | 无状态，需外部存储 |

> 思路对比

> | 设计考量     | Lambda             | AgentCore Runtime    |
| ------------ | ------------------ | -------------------- |
| **核心理念** | 事件驱动，快速执行 | 智能体驱动，持续学习 |
| **执行模式** | 函数调用           | 会话管理             |
| **状态处理** | 外部化             | 内置化               |
| **优化目标** | 吞吐量和成本       | 用户体验和智能性     |

这个选择体现了AWS对产品设计的深刻理解。Lambda自2014年推出以来，一直专注于事件驱动的短任务处理，在API处理、文件转换、数据ETL等场景中表现卓越。AWS认为，与其为了适应AI场景而妥协这些既有优势，不如为新场景创造专门优化的工具。

AgentCore Runtime的设计完全围绕AI工作负载的特点展开。它支持8小时的长时间运行，提供完整的会话隔离，内置了专门为AI设计的Memory、Identity、Gateway等服务。更重要的是，它针对LangGraph、CrewAI等AI框架进行了深度优化，支持检查点恢复机制，甚至可以直接从AWS Marketplace部署预构建的AI Agent。

这种专业化路径的逻辑是清晰的：让专业的工具做专业的事。Lambda继续在短任务处理领域保持性能优势，AgentCore则专注于AI场景的最优体验。每个产品都能在自己的领域做到极致，避免了通用产品的性能妥协。

但专业化也意味着更高的复杂度。用户需要学习和管理更多的产品，需要理解每个工具的适用边界，需要在多个产品间进行选择和集成。这对技术团队的能力提出了更高要求。

## 阿里云的边界突破：让平台适应需求

阿里云选择了一条更加"激进"的路径：直接突破FC的技术限制，通过平台进化来适应AI时代的需求。

| 对比维度       | 阿里云 FC                   | AWS AgentCore Runtime                 |
| -------------- | --------------------------- | ------------------------------------- |
| **运行时长**   | 24小时                      | 8小时                                 |
| **会话管理**   | Session亲和性（Header方式） | 原生会话隔离                          |
| **状态持久化** | NAS/OSS/PolarFS外部存储     | 内置Memory服务                        |
| **冷启动优化** | 预留实例+快照启动           | AI框架专用优化+检查点恢复             |
| **并发模式**   | 实例级多并发（可配置1-N）   | 会话级隔离并发                        |
| **框架支持**   | 支持任意语言/框架           | 专为AI框架优化（LangGraph、CrewAI等） |
| **工具集成**   | 需要手动集成                | 内置Gateway+AWS Marketplace           |
| **身份管理**   | 外部IAM集成                 | 内置Identity服务                      |
| **可观测性**   | CloudWatch集成              | 内置Observability+OpenTelemetry       |

最直观的变化是运行时间限制的突破。FC支持长达24小时的运行时间，这不仅解决了AI Agent长时间运行的需求，甚至超过了专门为AI设计的AgentCore的8小时限制。这个数字本身就说明了一个问题：所谓的技术限制往往是可以被突破的。

但改变远不止时间限制。为了支持AI场景，FC进行了全方位的架构升级：通过Session亲和性机制解决有状态应用的需求，通过动态依赖安装支持AI应用的不确定性，通过四种不同的沙箱模式适配从代码执行到浏览器自动化的各种AI场景。

这种进化体现了阿里云对技术限制的根本观点：技术的边界是可以被突破的，关键在于是否有足够的动力和资源去突破。当AI应用的市场价值变得足够大时，投入资源去解决技术挑战就成为了理性选择。

阿里云的工程团队没有被现有架构束缚，而是正面应对技术挑战。他们重新设计了资源调度系统以支持长时间运行，重新架构了网络层以支持会话亲和，重新优化了安全机制以支持多种沙箱模式。这种工程能力的展现，本身就证明了许多所谓的"技术限制"实际上是选择问题。

## 两种哲学的深层对比

这两种不同的选择，反映的不仅是技术路径的差异，更是产品哲学和文化背景的根本不同。

| 对比维度 | AWS专业化路径 | 阿里云进化路径 |
|---------|--------------|--------------|
| 运行时长 | Lambda 15分钟 + AgentCore 8小时 | FC 24小时 |
| 产品数量 | 多个专用产品 | 一个通用平台 |
| 学习成本 | 每个场景学习新产品 | 一个产品适应多场景 |
| 技术优化 | 针对特定场景深度优化 | 通用优化兼顾多场景 |
| 创新方式 | 创造新工具解决新问题 | 增强现有工具适应新需求 |
| 集成复杂度 | 多产品间集成 | 平台内统一集成 |

AWS的专业化路径体现了硅谷的工匠精神。这种文化相信"术业有专攻"，认为专业工具应该专注于特定领域，追求在该领域的极致表现。在这种理念下，技术限制不是缺陷而是特色，是为了保持产品纯粹性而做出的理性选择。

阿里云的进化路径体现了中国的工程师思维。这种文化更加实用主义，认为技术应该服务于业务需求，当需求发生变化时技术就应该适应变化。在这种理念下，技术限制是需要被突破的障碍，工程师的价值就在于解决这些技术挑战。

## 技术革新的真正驱动力：市场价值决定技术边界

AgentCore的发布和FC的升级，共同揭示了技术发展的一个重要规律：技术的边界往往不是由技术本身决定的，而是由商业价值决定的。

回顾Serverless的发展历程，我们可以清楚地看到这一点。早期的FaaS服务执行时间只有几分钟，内存限制在几百MB，并发数也很有限。但随着市场需求的增长和应用场景的扩展，这些"技术限制"不断被突破。

AI应用的兴起为这种技术革新提供了强大的驱动力。企业愿意为AI能力付出更高成本，AI应用的商业价值也远超传统应用。在这种情况下，云厂商有足够的动机去突破原有的技术限制或创造新的解决方案。

从用户的角度看，无论是15分钟的执行时间限制还是无状态的架构约束，都增加了应用开发的复杂度。但从服务商的角度看，这些限制往往有其合理性：简化系统设计、提高性能稳定性、降低运维复杂度，更重要的是帮助定义产品边界。

当AI应用带来足够大的市场价值时，这种平衡被打破了。AWS选择通过产品分化来应对变化，阿里云则选择通过技术革新来突破限制。两种选择都是理性的，但反映了不同的技术文化和商业策略。

## 未来展望：FaaS的持续演进

AgentCore的发布标志着Serverless计算进入了一个新的发展阶段。传统的"一刀切"式的技术限制正在被更加灵活和多样化的解决方案取代。

这种变化的意义超越了技术本身。它告诉我们，在评估技术方案时，不应该被现有的限制所束缚，而要看到技术发展的潜力和可能性。今天看似不可逾越的技术边界，可能就是明天突破的起点。

对于开发者来说，这意味着更多的选择和可能性。无论是选择AWS的专业化工具组合，还是选择阿里云的平台化解决方案，关键在于理解自己的需求和团队特点，选择最适合的路径。

更重要的是，这种竞争和创新推动着整个Serverless技术的持续发展。无论是专业化创新还是平台化升级，都在拓展着FaaS技术的边界，为用户创造更多价值。

在AI重新定义软件架构的今天，AgentCore的发布不仅是一个产品的推出，更是一次关于技术边界和产品哲学的深刻思考。它提醒我们，技术的发展从来不是线性的，而是在不同理念的碰撞中螺旋上升的。

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

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

标签: 云计算 Serverless AI Agent 技术创新产品哲学

分享给朋友：

返回列表

上一篇：开源：秀肌肉的舞台，众目睽睽的考场

下一篇：AI浪潮下的产品经理困境：当技术加速度遇上决策复杂度

刘博说云

大家都在搜：

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

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

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

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

开源：秀肌肉的舞台，众目睽睽的考场

"用户第一"的悖论：从三朵云看产品设计的中庸之道

回归产品思维：一位前产品经理的八点反思

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

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

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

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

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

开源：秀肌肉的舞台，众目睽睽的考场

"用户第一"的悖论：从三朵云看产品设计的中庸之道

回归产品思维：一位前产品经理的八点反思

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论