什么是 云存储？

云存储技能旨在桥接各种存储提供商，提供统一的方法来管理 AWS S3、Google Cloud Storage、Azure 以及 Dropbox 或 OneDrive 等消费级服务中的资产。通过利用 Openclaw Skills，开发人员可以自动化复杂的文件生命周期，同时避免常见的陷阱，如隐藏的出站流量费用、速率限制和身份验证过期。该技能确保每项操作不仅得到执行，还通过校验和及大小比较进行验证，以确保完整的数据完整性。

下载入口:https://github.com/openclaw/skills/tree/main/skills/ivangdavila/cloud-storage

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

云存储 应用场景

• 在 Azure Blob 和 AWS S3 等不同云生态系统之间同步数据集。
• 自动化从本地环境到 Google Drive 或 iCloud 的备份。
• 在计算和监控出站成本的同时进行大规模迁移。
• 实施需要断点续传逻辑的可靠文件管理工作流。

1. 通过选择提供商并通过 auth.md 配置验证凭据来初始化会话。
2. 进行操作前评估，以估计与 API 调用和出站流量相关的传输时间和成本。
3. 使用针对 ID、路径或键的特定提供商逻辑执行文件传输或管理任务。
4. 监控速率限制并实施检查点以处理潜在的网络或 API 故障。
5. 在执行任何破坏性操作之前，使用校验和验证操作的成功并核实备份状态。

云存储 配置指南

将此集成到您的 Openclaw Skills 工作流中需要设置提供商凭据。请参阅每个提供商的特定文档。

# 配置云访问环境
export CLOUD_STORAGE_PROVIDER="s3"
# 确保您的本地环境具有必要的身份验证令牌
# 对于 Google Drive/GCP，使用服务帐户 JSON 或 gcloud CLI

云存储 数据架构与分类体系

该技能通过一组结构化的参考文件管理元数据和操作参数。这允许 Openclaw Skills 保持状态和成本感知。

name: Cloud Storage
slug: cloud-storage
version: 1.0.1
description: Manage files across cloud providers with authentication, cost awareness, and multi-provider operations.
changelog: Added When to Use section for consistency
metadata: {"clawdbot":{"emoji":"??","requires":{"bins":[]},"os":["linux","darwin","win32"]}}

When to Use

User needs to upload, download, sync, or manage files across cloud storage providers. Agent handles multi-provider operations with cost awareness.

Quick Reference

Scope

This skill covers operational cloud storage tasks across providers:

• S3, GCS, Azure Blob, Backblaze B2, Cloudflare R2
• Google Drive, Dropbox, OneDrive, iCloud

For storage architecture decisions, see storage skill. For S3-specific deep patterns, see s3 skill.

Critical Rules

1. Verify operations completed — API 200 ≠ success; check file exists with correct size/checksum
2. Calculate ALL costs before large transfers — egress fees often exceed storage costs; check costs.md
3. Never delete without backup verification — confirm backup exists AND is restorable before removing source
4. Handle partial failures — long operations fail mid-way; implement checkpoints and resume logic
5. Rate limits vary wildly — Google 750GB/day upload, Dropbox batch limits, S3 3500 PUT/s per prefix

Authentication Traps

• OAuth tokens expire — refresh before long operations, not during
• Service account ≠ user account — different quotas, permissions, audit trails
• Wrong region/endpoint — S3 bucket in eu-west-1 won't work with s3.amazonaws.com
• MFA required — some operations need session tokens, plan for interactive auth

Multi-Provider Gotchas

Before Any Bulk Operation

• Estimated time calculated (size ÷ bandwidth)
• Rate limits checked for both source AND destination
• Cost estimate including egress + API calls
• Checkpoint/resume strategy for failures
• Verification method defined (checksum, count, spot-check)