从 0.1 到 0.22：gws（Google Workspace CLI）版本演进全解析

从 0.1 到 0.22：gws（Google Workspace CLI）版本演进全解析

【免费下载链接】cliGoogle Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills.项目地址: https://gitcode.com/gh_mirrors/cli413/cli

gws（npm 包名@googleworkspace/cli）是一款面向人类与 AI Agent 的 Google Workspace 统一命令行工具，运行时从 Google Discovery Service 动态构建命令面，覆盖 Drive、Gmail、Calendar、Sheets、Docs、Chat 等全部 Workspace API，并内置 100+ 个 Agent Skills。本文以仓库根目录 CHANGELOG.md 为骨架，逐版本梳理0.1.1至0.22.5的功能里程碑、安全加固、架构变迁与安装分发演化，并结合crates/、npm/、scripts/下的源码与配置给出实现级证据，帮助你快速定位自己关心的能力是在哪个版本引入的、以及它背后的底层原理。

注意：本工具并非 Google 官方支持的产品（见 README.md），项目处于积极开发阶段，向 v1.0 演进的过程中可能存在破坏性变更（breaking changes）。

一、版本节奏与发布基建的演进

1.1 从 0.1.x 到 0.22.5 的发布体系变化

CHANGELOG 采用 changesets 管理，0.1.x时代主要解决"包能发出去、CI 能跑起来"的问题：0.1.1引入Swatinem/rust-cache、sccache加速 CI 构建并复用冒烟测试产物；0.1.2修复发布流水线同步Cargo.toml版本与创建 git tag；0.1.3修正 npm 包名以@googleworkspace/cli发布；0.1.4修复 OAuth 登录"no refresh token"问题——解密 token 缓存后再解析、并兼容EncryptedTokenStorage的 HashMap 格式。

分发体系的两次重大转折发生在中后期：

• 0.22.4：彻底移除 cargo-dist，改用自定义 GitHub Actions 发布流水线 + 矩阵交叉编译，npm 安装器改为零依赖实现（原生fetch()，要求 Node 18+），同时移除了axios、rimraf、detect-libc、console.table、axios-proxy-builder等依赖，npm 包体积与攻击面同步下降。
• 0.22.5：把安装文档的优先级调整为"优先从 GitHub Releases 下载预编译二进制"，npm 仅作为自动化下载二进制的便捷途径；npm 包的postinstall脚本增加SHA256 校验和验证（158f93a），并对cross-rs进行版本锁定（b422e5d），避免未固定 git HEAD 的构建。

1.2 零依赖 npm 安装器的实现细节

npm/install.js 是整个分发链路的核心，其工作流可以拆成五步：

1. 读取 npm/package.json 中的version，拼出 GitHub Releases 下载地址；
2. 通过原生fetch()下载对应平台的目标归档（.tar.gz或.zip）；
3. 再下载同名的.sha256文件，用 Node 内置crypto计算本地文件哈希并比对，不一致则报错退出（"The downloaded binary may have been tampered with"）；
4. 用tar/unzip（Windows 走 PowerShellExpand-Archive）解压到bin/目录，Unix 平台chmod 755；
5. 在bin/.version写入当前版本号，供下次安装判断是否需要升级（见 npm/install.js）。

npm/run.js 则解决了pnpm等包管理器跳过postinstall导致gws binary not found的问题（对应 CHANGELOG 0.22.5 的6ccbb42）：当bin/下找不到二进制时，自动以node install.js补装，再转发参数到真实二进制（见 npm/run.js）。package.json中"bin": { "gws": "run.js" }与"postinstall": "node install.js"构成完整闭环。

supportedPlatforms字段（npm/package.json）覆盖 7 个目标平台：aarch64-apple-darwin、x86_64-apple-darwin、aarch64-unknown-linux-gnu、aarch64-unknown-linux-musl、x86_64-unknown-linux-gnu、x86_64-unknown-linux-musl、x86_64-pc-windows-msvc。其中 ARM64 支持在 0.4.0 加入，musl 静态二进制目标在 0.6.3 加入，0.21.2 起两个 crate 同时发布到 crates.io。

二、架构演进：从单二进制到 Cargo Workspace 双 crate

2.1 0.21.0：提取google-workspace库 crate

0.21.0（029e5de）是本项目架构上的分水岭：原先的单二进制被拆分为 Cargo workspace 的两个成员（见根 Cargo.toml）：

• crates/google-workspace—— 库 crate，暴露可编程的 Rust API；
• crates/google-workspace-cli——gws二进制 crate，透明地 re-export 库类型，行为零变化。

库 crate 提供五个核心模块（对应 CHANGELOG 0.21.0 的模块清单，实际位于 crates/google-workspace/src）：

这一拆分的价值在于：第三方 Rust 项目可以直接把google-workspace作为依赖，复用 Discovery 抓取、错误处理、校验和重试客户端，而不必 fork CLI。

2.2 两阶段解析架构

README 描述gws采用两阶段解析（two-phase parsing）：先读argv[1]识别服务名（如drive），抓取该服务的 Discovery Document（缓存 24 小时），再根据文档中的 resources 与 methods 动态构建clap::Command树，重新解析剩余参数，最后认证、构造 HTTP 请求并执行。这解释了为什么gws不需要维护静态命令列表——Google 新增端点后gws会自动感知。Discovery 文档缓存在0.3.2起做了更智能的截断（按句边界/词边界截断并剥离 markdown 链接，回收字符预算）；0.3.5修复了flatPath占位符与参数名不匹配时 URL 构建失败的问题。

2.3 版本同步脚本

0.21.1 修复了version-sync.sh的目标路径：workspace 重构后根Cargo.toml不再有[package]段，脚本改为更新crates/google-workspace-cli/Cargo.toml，并与package.json的版本保持一致（见 scripts/version-sync.sh）。

三、认证体系：六次迭代背后的取舍

认证是gws演进最密集的领域，从 CHANGELOG 可以看到一条清晰的"功能加法 → 减法 → 安全加固"曲线。

3.1 多账户支持的引入与移除

• 0.4.0引入多账户支持：--account EMAIL全局 flag、GOOGLE_WORKSPACE_CLI_ACCOUNT环境变量、gws auth list、gws auth default、gws auth logout --account EMAIL、OAuth URL 中的login_hint自动预选账户；凭证存储格式从单一credentials.enc改为按账户分文件（credentials.<b64-email>.enc）+accounts.json注册表，因此升级后必须重新gws auth login。
• 0.7.0却移除了多账户、域级委派（domain-wide delegation）与身份模拟（impersonation）支持：删除gws auth list、gws auth default、--accountflag、GOOGLE_WORKSPACE_CLI_ACCOUNT与GOOGLE_WORKSPACE_CLI_IMPERSONATED_USER环境变量。这是面向 v1.0 的主动收敛——把复杂度留给单账户 + 多种凭证来源的组合。

3.2 凭证来源优先级与 ADC 支持

0.6.0 引入Application Default Credentials（ADC）作为第四/第五凭证来源，最终查找顺序为：

1. GOOGLE_WORKSPACE_CLI_TOKEN（原始 access token，最高优先级）
2. GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE
3. 加密凭证~/.config/gws/credentials.enc（gws auth login写入）
4. 明文凭证~/.config/gws/credentials.json
5. ADC：GOOGLE_APPLICATION_CREDENTIALS环境变量（文件缺失则硬错误），随后是~/.config/gcloud/application_default_credentials.json（缺失则静默跳过）

这意味着gcloud auth application-default login --client-id-file=client_secret.json成为完全受支持的认证路径，且同时支持authorized_user与service_account两种 ADC 格式。0.6.2 修复了accounts.json缺失导致认证失败的三个连锁 bug（resolve_account误判 legacy 凭证、main.rs吞掉认证错误、auth login未包含openid/emailscope 导致无法识别用户）。

3.3 加密存储与 OS 钥匙串策略

凭证在磁盘上是 AES-256-GCM 加密存储的（见 crates/google-workspace-cli/src/token_storage.rs 中EncryptedTokenStorage的注释与实现），密钥的存放策略经历了三个阶段：

• 0.2.1：稳定加密密钥回退——OS keyring 返回NoEntry时，优先复用已存在的.encryption_key文件，新密钥则持久化到文件作为稳定回退，并修复OnceLock竞态。
• 0.9.1：keyring 可用时不再持久化.encryption_key文件；已有文件密钥迁移进 keyring 并删除文件。
• 0.10.0：新增GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND环境变量（keyring或file），显式选择后端，修复 Docker/无 keyring 环境下密钥丢失的问题——.encryption_key永不删除并始终作为回退持久化。
• 0.22.3：macOS / Windows 上严格使用原生 OS keychain（macOS Keychain Access、Windows Credential Manager），不再写入回退的.encryption_key文本文件；若 keychain 登录成功后仍发现旧.encryption_key，会自动删除。Linux 则继续默认使用文件回退，保证无桌面 DBUS 服务的 headless CI、Docker、SSH 环境最大兼容。

token_storage.rs中的load_from_disk对解密失败、非法 UTF-8、JSON 解析错误都会向 stderr 打印具体警告并提示重新认证（0.6.3 的9a780d7修复），而不是静默吞掉错误；save_to_disk失败也会传播错误并设置目录权限（0.6.3 的132c3b1改为eprintln!警告）。

3.4 范围（Scope）选择策略

• 0.2.2 收窄默认 OAuth scope 以避免未验证应用的403 restricted_client。
• 0.4.3 将需要 Workspace 域管理员权限的 scope（apps.*、cloud-identity.*、ediscovery、directory.readonly、groups）移出 "Recommended" 预设——个人@gmail.com账户使用这些 scope 会返回400 invalid_scope；管理员仍可通过 "Full Access" 模板或逐个勾选获取。
• 0.5.0 为gws auth login增加-s/--services过滤（如-s drive,gmail,sheets），并扩展 Workspace 管理员 scope 黑名单（chat.admin.*、classroom.*）。
• 0.10.0 当-s指定静态 scope 列表之外的服务时，会动态从 Discovery 文档抓取 scope并去重。
• 0.6.3 修复 scope 选择改用方法的第一个（最宽泛）scope，避免gmail.metadata限制q参数。

3.5 认证命令的重构与可用性

0.19.0 将gws auth全部子命令改用 clap 结构化解析，引入ScopeMode枚举，--help完整可用；d341de2让gws auth setup在启动设置向导前先处理--help/-h，防止用户只想看帮助时误创建项目。0.4.1 的项目选择器新增"手动输入 project ID"选项，绕开大账户下gcloud projects list的 10 秒超时（0.4.0 还修复了 stdout 管道未及时排空导致的死锁）。0.3.4 改为逐个、并行启用 API 并透出gcloud错误，而不是整批失败。

四、结构化错误与退出码：可脚本化的失败处理

4.1 退出码语义（0.12.0）

0.12.0 为gws引入类型化退出码，脚本无需解析错误输出即可按失败类型分支：

这一语义直接对应 crates/google-workspace/src/error.rs 中GwsError的五个EXIT_CODE_*常量与exit_code()映射，且单元测试test_exit_codes_are_distinct保证五个码互不冲突（见 error.rs）。典型用法：

gws drive files list --params '{"fileId": "bad"}' echo $? # 1 — API 错误 gws unknown-service files list echo $? # 3 — 校验错误（未知服务）

4.2 accessNotConfigured 的引导式报错

0.2.2（de2787e）起，当 API 返回403 accessNotConfigured时，gws会从错误体提取 GCP Console 启用 URL：JSON 输出保持向后兼容（仅当可解析时附加enable_url字段），同时向 stderr 打印带💡图标的人类可读指引（"Enable it at: …"）。GwsError::Api变体的enable_url: Option<String>与to_json()序列化逻辑见 error.rs，配套测试覆盖了带/不带 URL 两种场景（error.rs）。README 的 Troubleshooting 章节给出了完整的 JSON 与 stderr 输出示例（见 README.md）。

4.3 输出卫生与终端安全

0.17.0 的6f92e5b是一揽子 stderr/stdout 卫生改造：诊断信息统一走 stderr（保证 stdout 对管道始终是合法 JSON）、错误标签带颜色（尊重NO_COLOR）、日历/聊天/文档/Drive/Script/Sheets 的认证失败传播为GwsError::Auth而非静默未认证继续。0.18.0 的2e909ae把终端净化、着色、输出助手收敛进output.rs，并升级sanitize_for_terminal剥离危险 Unicode 字符（bidi 覆盖符、零宽空格、方向隔离符）以及此前watch.rs中绕过NO_COLOR与 TTY 检测的裸 ANSI 转义码。

五、Gmail 助手命令：从零到九大能力的演进

gws gmail是功能最密集的服务，CHANGELOG 记录了+send、+reply、+reply-all、+forward、+triage、+watch、+read七个助手命令（helper，以+前缀与 Discovery 生成的方法区分，不会冲突）的完整进化史。

5.1 时间线速览

5.2 源码级实现：+send

以 crates/google-workspace-cli/src/helpers/gmail/send.rs 为例，handle_send的核心链路是：parse_send_args解析参数 →resolve_mail_method根据--draft选择 send/draft 方法及其 Discovery scope → 取 token →create_send_raw_message用mail_builder::MessageBuilder构造 MIME →dispatch_raw_email分发。关键点：

• parse_send_args要求--to至少一个收件人，否则返回GwsError::Validation("--to must specify at least one recipient")（send.rs）；
• 测试用例覆盖了--from传空值退化为None、CRLF 注入（--from中带\r\nBcc: ...不会生成额外头）、multipart/mixed附件、多收件人、--cc/--bcc头不泄漏等场景（send.rs），这些是面向 LLM Agent 调用场景的关键防护。

0.18.0还让 From 头自动填充 send-as 设置中的显示名，并给裸--from邮箱补充配置的显示名；0.20.1增加了 RFC 2822 显示名引号的回归测试。非 ASCII 显示名的乱码问题在 0.16.0 通过encode_address_header()解决——只对显示名做 RFC 2047 Base64 编码、不动邮箱地址本体。

5.3 长期运行助手与信号处理

+watch（Gmail）与+subscribe（Workspace Events）是流式长期任务：0.13.2 在每个 Pub/Sub 与 Gmail 请求前刷新 OAuth access token，并校验--subscription资源名、去重PUBSUB_API_BASE常量；0.18.1 为两个拉取循环增加SIGTERM 处理（在 Ctrl+C 之外），使它们能在 Kubernetes、Docker、systemd 下优雅退出。events +subscribe的配置默认值见 crates/google-workspace-cli/src/helpers/events/subscribe.rs：max_messages默认 10、poll_interval默认 2 秒，project回退到GOOGLE_WORKSPACE_PROJECT_ID，--output-dir与--subscription分别经过validate_safe_output_dir与validate_resource_name防路径穿越。0.19.0 为+renew/+subscribe增加--dry-run，只打印将要执行的动作、不发起 API 调用，方便 Agent 模拟学习。+triage的 403 修复（0.10.0）说明了一个反直觉的坑：gmail.metadatascope 不支持q参数，因此改用gmail.readonly。

六、上传、分页与时区：通用能力的深化

6.1 多部分上传与类型推断（0.14.0）

--upload-content-typeflag 的引入解决了一个真实痛点：Drive 上传中元数据mimeType是"目标类型"（文件要变成什么），而媒体Content-Type是"源类型"（字节是什么）。此前两者被强行绑定，导致"上传 Markdown、由 Drive 转成 Google Docs"这类导入转换无法实现。新行为：缺省时先按文件扩展名推断媒体类型，失败才回退到元数据mimeType。因此导入转换开箱即用：

# 扩展名推断 text/markdown → 转换自动生效 gws drive files create \ --json '{"name":"My Doc","mimeType":"application/vnd.google-apps.document"}' \ --upload notes.md # 需要覆盖时显式指定 gws drive files create \ --json '{"name":"My Doc","mimeType":"application/vnd.google-apps.document"}' \ --upload notes.md \ --upload-content-type text/markdown

同版本（945ac91）还把大文件上传改为通过ReaderStream分块流式读取，内存占用从 O(文件大小) 降到 O(64 KB)，避免大文件 OOM。

6.2 分页控制

分页参数（README 与 CHANGELOG 0.2.2 共同确认）：

0.2.2 修复了--page-all搭配--format csv/--format table时每页重复输出表头的问题（表头只在第一页输出），YAML 格式分页则补充文档分隔符---；0.11.1 修复了数组套数组响应（如 Sheets values API）的 CSV 输出。

6.3 账户时区与日历助手（0.16.0）

0.16.0 起，+agenda、+standup-report、+weekly-digest、+meeting-prep等时间感知助手使用Google 账户时区而非机器本地时区计算日界，时区从 Calendar Settings API 抓取并缓存 24 小时；+agenda可用--timezone显式覆盖（--tz亦可用）。0.13.3 曾修复+agenda日界用 UTC 而非本地时区的问题。日历助手+insert的参数定义见 crates/google-workspace-cli/src/helpers/calendar.rs：--calendar默认primary、--summary与--start（ISO 8601）必填；0.17.0 为+insert加入 Google Meet 视频会议支持。

七、安全加固史：一条贯穿始终的主线

CHANGELOG 中有大量安全相关条目，可归纳为四个维度：

7.1 输入校验与路径安全

• 0.2.0：新增 validate.rs 的validate_safe_output_dir、validate_msg_format、validate_safe_dir_path；对gmail +watch/events +subscribe的--output-dir、--msg-format（白名单 full/metadata/minimal/raw）、script +push的--dir做路径穿越校验；URL 查询参数改用 reqwest.query()构建器；encode_path_segment、validate_resource_name共享安全助手。
• 0.3.5：URL 模板{var}按路径段编码、{+var}保留斜杠且逐段编码，参数/模板不匹配时快速失败（修复 Sheetsrange中 Unicode 与保留字符）。
• 0.4.0：拒绝 ASCII 控制字符 DEL（0x7F）——此前reject_control_chars只拦 0x00–0x1F。
• 0.13.3：chat +send校验 space name 防路径穿越。
• 0.17.0：校验范围扩展到危险 Unicode（零宽字符、bidi 覆盖符、Unicode 行/段分隔符）。

7.2 原子写入与 TOCTOU（0.17.0）

811fe7b修复了原子文件写入中的 TOCTOU/符号链接竞态：随机化临时文件名防可预测性、O_EXCL防止跟随已存在的符号链接、Unix 下文件从创建起即0600权限、删除冗余的写后二次权限调用以关闭竞态窗口。0.2.2 的0603bce就已引入原子凭证写入防崩溃/Ctrl-C 损坏。

7.3 供应链安全（0.22.5 集中爆发）

• 5d24ac2：新增 cargo-audit CI workflow 自动扫描依赖漏洞；
• ecdf2e：新增 cargo-deny 配置（license/advisory/source 审计，即仓库根目录的 deny.toml）；
• b307856：内部 AI skills 注册表（personas 与 recipes）从 YAML 迁移到 TOML（对应 crates/google-workspace-cli/registry/personas.toml 与 recipes.toml），从而移除无人维护的serde_yaml依赖；
• 158f93a：npm postinstall 校验二进制 SHA256；
• b422e5d：发布流水线锁定cross-rsv0.2.5。

7.4 传输与 TLS

0.9.0（789e7f1）从 reqwest 内置 Mozilla 根证书切换到系统原生证书库，使企业自建 CA 证书可被信任。HTTP 客户端在 crates/google-workspace/src/client.rs 中的实现要点：x-goog-api-client头格式为gl-rust/<name>-<version>（0.3.0 修复）；10 秒连接超时（0.20.1 新增，防止初始连接挂死）；重试逻辑send_with_retry最多 3 次，尊重Retry-After头、缺省指数退避 1s/2s/4s，且延迟上限 60 秒（0.17.0 的b241a5b修复，防止恶意/错误配置的服务器无限挂起进程），详见 client.rs 与 client.rs。

八、可观测性：零开销的 opt-in 日志（0.15.0）

0.15.0 引入基于tracing的结构化 HTTP 请求日志，两个新环境变量：

• GOOGLE_WORKSPACE_CLI_LOG：stderr 日志过滤（如gws=debug）；
• GOOGLE_WORKSPACE_CLI_LOG_FILE：JSON 日志文件目录，按天轮转。

默认完全静默、零开销；只记录不含 PII 的元数据：API method ID、HTTP 方法、状态码、延迟、content-type。这与 0.6.3 的322529d（在 release 构建中启用GOOGLE_WORKSPACE_CLI_CONFIG_DIR）一起构成完整的配置/可观测性环境变量矩阵，完整清单见 README.md 的 Environment Variables 章节。

九、Agent 生态：Skills、personas 与 recipes

9.1 演进时间线

• 0.2.0：新增gws workflow子命令（5 个内置助手：+standup-report、+meeting-prep、+email-to-task、+weekly-digest、+file-announce）；10 个 Agent personas（exec-assistant、project-manager、sales-ops 等）；docs/skills.md skills 索引；50 个面向 Gmail/Drive/Docs/Calendar/Sheets 的多步 recipes；lefthook pre-commit 串行执行 fmt 与 clippy（见 lefthook.yml）。
• 0.3.1：每小时 cron 自动同步 skills 到上游 Google Discovery API 变更（通过 PR）；新增 OpenClaw skills 发布 workflow。
• 0.19.0：生成 SKILL.md 的 frontmatter 从 flow 序列改为 block 序列——bins: ["gws"]→bins:\n - gws。flow 序列虽合法，但被 Agent Skills 参考实现agentskills validate依赖的strictyaml拒绝，导致全部 93 个生成 skills 校验失败（修复 #521）。

9.2 当前技能矩阵

README 声明仓库随附 100+ 个SKILL.md：每个受支持 API 一个，外加高级工作流助手与 50 个精选 recipes（完整索引见 docs/skills.md，实际技能文件位于 skills 目录，按gws-*、persona-*、recipe-*三类组织）。gws-shared技能内置 install 块，OpenClaw 在gws不在 PATH 时会自动通过 npm 安装。README 提供的安装方式（npx skills add）与 OpenClaw 符号链接方案（ln -s $(pwd)/skills/gws-* ~/.openclaw/skills/）可让 Agent 一键获得全部能力。

9.3 已退役的 MCP 能力（历史记录）

gws mcp曾在 0.3.0 引入（stdio 上的 Model Context Protocol 服务器，将 Workspace API 暴露为结构化工具给 Claude Desktop、Gemini CLI、VS Code 等任意 MCP 客户端），0.5.0 增加--tool-mode compact|full（compact 模式每服务一个工具 +gws_discover元工具，上下文窗口从 200–400 个工具降到约 26 个），0.6.3 修复 MCP 工具 schema 仅在有请求体/支持媒体上传/有 pageToken 时条件性包含body/upload/page_all属性。但0.8.0 已移除mcp命令——当前版本以 Agent Skills 作为主要的 Agent 集成方式。若你在旧文档中看到gws mcp，请注意它已不存在于 0.8.0 及之后的版本。

十、安装与运行（当前仓库为准）

以当前仓库（0.22.5）为准，推荐方式与前提：

1. 预编译二进制（首选）：从 GitHub Releases 下载对应 OS/架构的归档，解压后把gws放入$PATH；
2. npm（便捷自动化）：npm install -g @googleworkspace/cli（Node.js 18+），postinstall自动下载并对 SHA256 校验；二进制缺失时run.js会自动补装；
3. 源码构建：cargo build（开发构建）、cargo clippy -- -D warnings（lint）、cargo test（单元测试）、scripts/coverage.sh（HTML 覆盖率报告到target/llvm-cov/html/）；workspace 内亦可cargo build -p google-workspace-cli；
4. Nix：仓库提供 flake.nix。

快速上手（README Quick Start）：

gws auth setup # 引导式配置 Google Cloud 项目 gws auth login # OAuth 登录 gws drive files list --params '{"pageSize": 5}' gws schema drive.files.list # 内省任意方法的请求/响应 schema gws drive files list --params '{"pageSize": 100}' --page-all | jq -r '.files[].name' # NDJSON 流式分页

十一、版本速览总表

结语：给不同读者的版本选型建议

• 想用最新能力（--draft、严格 keychain、供应链审计）：升级到 0.22.5；
• 想用 Rust 库 API：至少 0.21.0（google-workspace库 crate）；
• 在 Docker/K8s 跑流式任务：0.18.1+（SIGTERM 优雅退出）、0.13.2+（token 自动刷新）；
• 在无 keyring 环境跑认证：0.10.0+ 用GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file，或 0.6.0+ 用 ADC；
• 写脚本做自动化：0.12.0+ 的退出码体系是必备基础。

CHANGELOG 本身即是一份浓缩的产品路线图：从"能跑"到"能安全地跑"再到"能让 Agent 安全地跑"，gws的每一次 minor/patch 更新都在这三个维度上前进。本文所引源码路径均可直接在仓库对应位置查看，结合 README.md 与 docs/skills.md 可进一步深入每一项能力的完整用法。

【免费下载链接】cliGoogle Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills.项目地址: https://gitcode.com/gh_mirrors/cli413/cli