Clanker CLI：给 AI 编程工具装上云端副驾驶

Clanker Logo 图1：Clanker 项目 Logo

场景切入：当凌晨3点的告警碰上云上迷宫

凌晨3点，你的手机震了——AWS Lambda 函数报错了。你揉着眼睛 SSH 登录控制台，开始在 EC2 安全组、RDS 存储卷和 CloudWatch 日志之间来回切换，试图从碎片化的数据里拼凑出问题的全貌。这种场景，对每一个负责生产环境的开发者来说都不陌生。

Clanker 正是为解决这个问题而生的：它是一个用 Go 语言编写的开源 CLI Agent，本质上是一个云端副驾驶——你用自然语言告诉它想做什么，它帮你理解、执行和验证多云环境（AWS/GCP/Azure/Cloudflare）下的运维操作，无需记忆每一个云厂商的 CLI 语法。

项目背景：从命令行工具到 AI DevOps IDE 的演进

Clanker 由独立开发者 bgdnvk 创建并维护，背后公司是 Clanker Cloud，官网 clankercloud.ai 提供配套的桌面应用。项目的核心定位是首个面向 AI Agent 和人类的 AI DevOps IDE。

这个定位的内涵在于：Clanker 不仅服务人类运维工程师，也能被其他 AI Agent 调用。它通过 MCP（Model Context Protocol） 协议暴露自己的工具集，任何兼容 MCP 的 Agent 都能直接调用 Clanker 的能力，相当于把整个多云运维知识库插拔式地接入其他 AI 系统。

截至分析时，该项目在 GitHub 上拥有 368 颗 Stars，属于垂直领域工具中的活跃项目，且增长趋势明显（月趋势分 77.86）。技术栈为 Go 语言，遵循 MIT 许可证。

核心功能：三个工作模式覆盖运维全链路

模式一：自然语言问答（clanker ask）

这是 Clanker 最核心的交互方式。你可以用自然语言询问任何云资源的状态：

# 查询特定 Lambda 函数状态
clanker ask "what is the status of my chat service lambda?"

# 跨云厂商追问
clanker ask --profile dev "what is the last error from my big-api-service lambda?"

# 切换 AI 模型
clanker ask --ai-profile openai "What are the latest logs for our dev Lambda functions?"

背后的实现是一个三阶段 LLM Pipeline：

LLM 分析问题，确定需要调用哪些云厂商 CLI 工具
并行执行选中的工具调用（AWS CLI、GCP SDK 等）
汇总结果，结合上下文生成 Markdown 格式回答

支持多家 AI 提供商：OpenAI GPT-5、Google Gemini 2.5 Flash、Cohere Command A，用户可通过配置文件自由切换。

模式二：基础设施编排（clanker ask --maker）

这是 Clanker 最具生产力的模式。它不仅能回答问题，还能生成并执行基础设施变更计划：

# 生成计划（预览，不执行）
clanker ask --aws --maker "create a small ec2 instance and a postgres rds" | cat

# 人工审核后应用
clanker ask --aws --maker --apply < plan.json | cat

# 危险操作需要显式授权
clanker ask --aws --maker --destroyer "delete the clanka-postgres rds instance" | cat

Maker 模式的核心设计理念是安全优先：

对幂等的已存在错误视为成功（避免重复创建时卡壳）
对异步 AWS 操作（CloudFormation）等待最终状态再返回
检测到常见配置错误（CIDR/子网/模板不匹配）时自动重写并重试
内置重试和胶水逻辑耗尽后，升级到 AI 补充前置命令，再指数退避重试

模式三：Kubernetes 全栈管理

Clanker 提供了完整的 Kubernetes 生命周期管理，覆盖从集群创建到应用部署的每个环节：

# 创建 EKS 集群
clanker k8s create eks my-cluster --nodes 2 --node-type t3.small

# 部署应用
clanker k8s deploy nginx --name my-nginx --port 80 --replicas 3

# Pod 日志实时流
clanker k8s logs my-pod -f --tail 100

# 节点指标排序
clanker k8s stats nodes --sort-by cpu

# 自然语言集群查询
clanker k8s ask "which pods are consuming most memory in production?"

值得注意的是，Clanker 的 K8s 支持不依赖 Helm 或 OpenTelemetry，它会检测环境里实际安装了哪些工具（kubectl、helm、metrics-server），然后启用对应的功能。这种自适应设计让它对各种 K8s 发行版都很友好。

SRE Bot：自动化的基础设施看护者

Clanker 还提供了 SRE Bot 能力，可以作为常驻进程监控基础设施健康状态：

# 先探查环境
clanker sre discover --format json

# 规划 Docker 安装
clanker sre plan --sre

# 安装并启动
clanker sre install --sre --target docker --apply

SRE Bot 会自动检测 Docker、Kubernetes、Terraform、CI/CD 流水线、OTel Collector 等组件，仅启用已检测到的监控项，并向 Clanker Cloud 的 Cerebro 平台上报心跳和发现事件。安装目标支持 Docker、systemd、launchd、Kubernetes、Cloud VM 五种形态。

MCP 协议：让 Clanker 成为 AI Agent 的云能力插件

这是 Clanker 最有战略价值的特性。它不只是一个孤立的 CLI 工具，而是通过 MCP 协议暴露了约 25 个工具，可以被任何 MCP 客户端调用：

工具类别	工具数量	代表工具
通用命令执行	3	clanker_version, clanker_run_command, clanker_route_question
K8s 只读操作	6	clanker_k8s_list_clusters, clanker_k8s_get_resources, clanker_k8s_ask_cluster
K8s 写操作	9	clanker_k8s_scale, clanker_k8s_restart, clanker_k8s_apply, clanker_k8s_helm_install
K8s 运维	7	clanker_k8s_node_cordon/drain/uncordon

换句话说，如果你正在开发一个 AI Coding Agent，需要让 Agent 操作 Kubernetes 或查询 AWS 资源，不需要自己集成所有云厂商 SDK——只需让 Agent 调用 Clanker 的 MCP 工具即可。这极大降低了 AI Agent 的云能力接入门槛。

代码架构：Go + 模块化插件体系

项目采用 Go 1.25 开发，代码组织遵循清晰的模块化结构：

cmd/          # 命令入口，每个 .go 文件对应一个子命令
internal/     # 内部实现包
  agent/      # Agent 协调逻辑
  ai/         # AI 模型调用抽象层
  aws/        # AWS 服务封装
  azure/      # Azure 服务封装
  gcp/        # GCP 服务封装
  cloudflare/ # Cloudflare 服务封装
  kubernetes/ # K8s 操作封装
  deploy/     # 部署逻辑
  hermes/     # Hermes 集成
internal/backend/     # 桌面应用后端
internal/clankercloud/ # Clanker Cloud 平台集成

依赖项涵盖所有主流云厂商 SDK：AWS SDK v2、Google Cloud SDK、Azure SDK、Cloudflare Workers SDK，以及数据库连接（Cloud SQL）、容器服务（GKE/EKS）等。这种全面覆盖在同类工具中相当罕见。

代码质量方面：项目包含大量 _test.go 文件（如 ask_test.go、config_test.go、cost_savings_print_test.go），测试覆盖较完善；README 文档详尽，示例丰富。

部署体验：无门槛安装，但需准备云账号

Clanker 的安装体验非常友好，两种方式：

Homebrew（macOS/Linux）：brew install clanker，最简单
源码编译：make install，自动拉取依赖并编译安装

安装后通过 clanker config init 引导式创建配置文件 ~/.clanker.yaml，指定默认云厂商和 AI 模型。

不过，Clanker 本身不需要 GPU，对本地硬件要求极低（512MB RAM 即可），但需要配置目标云厂商的 CLI 工具和凭证——AWS CLI、GCP SDK、Azure CLI、Kubectl 等。首次运行 clanker onboarding scan 可以自动探测缺失的依赖和凭证，指导用户一步步配置。

部署难度评定为简单（2/5），因为安装链路清晰、无复杂依赖。但实际会用需要用户对云资源管理有基础认知——它降低的是命令行记忆成本，不是云知识门槛。

局限与争议

无 Web UI：纯命令行工具，对不习惯 CLI 的用户有上手门槛。配套的 Clanker Cloud 桌面应用是付费产品。
Maker 模式的信任问题：让 AI 自动执行云资源变更存在风险，虽然有幂等设计和安全检查，但生产环境使用仍需人工复核。
多云支持的深度不一：AWS 支持最完善（测试最多），GCP/Azure 次之，Tencent Cloud 等其他厂商覆盖较浅。
MCP 工具数量受限：当前 MCP 仅暴露约 25 个工具，而 CLI 本身支持上百个操作，Agent 通过 MCP 接入时能力受限。

行业意义：DevOps Agent 赛道的细分深耕

Clanker 代表的趋势是垂直领域 AI Agent 的工具化。在 AI Coding 工具（如 Cursor、Copilot）已经能写代码的背景下，如何让 AI 真正上手干活——部署、监控、排障——成为下一个价值高地。

Clanker 的做法是：不做一个大而全的平台，而是做好一个云端工具桥——一头接入所有主流云厂商 SDK，一头通过自然语言界面和 MCP 协议向外暴露。这种定位让它既能服务人类工程师，也能被其他 AI Agent 调用，生态兼容性极强。

随着 AI Agent 在软件开发和运维领域的渗透，类似 Clanker 这样的领域工具桥接层会越来越重要。它的增长曲线（月趋势分 77.86）和活跃的社区维护（368 Stars，20 个 Topics 覆盖主要云和 AI 领域），证明了市场对这类工具的明确需求。

Clanker CLI：给 AI 编程工具装上云端副驾驶

Clanker Logo 图1：Clanker 项目 Logo

场景切入：当凌晨3点的告警碰上云上迷宫

项目背景：从命令行工具到 AI DevOps IDE 的演进

核心功能：三个工作模式覆盖运维全链路

模式一：自然语言问答（clanker ask）

这是 Clanker 最核心的交互方式。你可以用自然语言询问任何云资源的状态：

# 查询特定 Lambda 函数状态
clanker ask "what is the status of my chat service lambda?"

# 跨云厂商追问
clanker ask --profile dev "what is the last error from my big-api-service lambda?"

# 切换 AI 模型
clanker ask --ai-profile openai "What are the latest logs for our dev Lambda functions?"

背后的实现是一个三阶段 LLM Pipeline：

LLM 分析问题，确定需要调用哪些云厂商 CLI 工具
并行执行选中的工具调用（AWS CLI、GCP SDK 等）
汇总结果，结合上下文生成 Markdown 格式回答

支持多家 AI 提供商：OpenAI GPT-5、Google Gemini 2.5 Flash、Cohere Command A，用户可通过配置文件自由切换。

模式二：基础设施编排（clanker ask --maker）

这是 Clanker 最具生产力的模式。它不仅能回答问题，还能生成并执行基础设施变更计划：

# 生成计划（预览，不执行）
clanker ask --aws --maker "create a small ec2 instance and a postgres rds" | cat

# 人工审核后应用
clanker ask --aws --maker --apply < plan.json | cat

# 危险操作需要显式授权
clanker ask --aws --maker --destroyer "delete the clanka-postgres rds instance" | cat

Maker 模式的核心设计理念是安全优先：

对幂等的已存在错误视为成功（避免重复创建时卡壳）
对异步 AWS 操作（CloudFormation）等待最终状态再返回
检测到常见配置错误（CIDR/子网/模板不匹配）时自动重写并重试
内置重试和胶水逻辑耗尽后，升级到 AI 补充前置命令，再指数退避重试

模式三：Kubernetes 全栈管理

Clanker 提供了完整的 Kubernetes 生命周期管理，覆盖从集群创建到应用部署的每个环节：

# 创建 EKS 集群
clanker k8s create eks my-cluster --nodes 2 --node-type t3.small

# 部署应用
clanker k8s deploy nginx --name my-nginx --port 80 --replicas 3

# Pod 日志实时流
clanker k8s logs my-pod -f --tail 100

# 节点指标排序
clanker k8s stats nodes --sort-by cpu

# 自然语言集群查询
clanker k8s ask "which pods are consuming most memory in production?"

SRE Bot：自动化的基础设施看护者

Clanker 还提供了 SRE Bot 能力，可以作为常驻进程监控基础设施健康状态：

# 先探查环境
clanker sre discover --format json

# 规划 Docker 安装
clanker sre plan --sre

# 安装并启动
clanker sre install --sre --target docker --apply

MCP 协议：让 Clanker 成为 AI Agent 的云能力插件

这是 Clanker 最有战略价值的特性。它不只是一个孤立的 CLI 工具，而是通过 MCP 协议暴露了约 25 个工具，可以被任何 MCP 客户端调用：

工具类别	工具数量	代表工具
通用命令执行	3	clanker_version, clanker_run_command, clanker_route_question
K8s 只读操作	6	clanker_k8s_list_clusters, clanker_k8s_get_resources, clanker_k8s_ask_cluster
K8s 写操作	9	clanker_k8s_scale, clanker_k8s_restart, clanker_k8s_apply, clanker_k8s_helm_install
K8s 运维	7	clanker_k8s_node_cordon/drain/uncordon

代码架构：Go + 模块化插件体系

项目采用 Go 1.25 开发，代码组织遵循清晰的模块化结构：

cmd/          # 命令入口，每个 .go 文件对应一个子命令
internal/     # 内部实现包
  agent/      # Agent 协调逻辑
  ai/         # AI 模型调用抽象层
  aws/        # AWS 服务封装
  azure/      # Azure 服务封装
  gcp/        # GCP 服务封装
  cloudflare/ # Cloudflare 服务封装
  kubernetes/ # K8s 操作封装
  deploy/     # 部署逻辑
  hermes/     # Hermes 集成
internal/backend/     # 桌面应用后端
internal/clankercloud/ # Clanker Cloud 平台集成

代码质量方面：项目包含大量 _test.go 文件（如 ask_test.go、config_test.go、cost_savings_print_test.go），测试覆盖较完善；README 文档详尽，示例丰富。

部署体验：无门槛安装，但需准备云账号

Clanker 的安装体验非常友好，两种方式：

Homebrew（macOS/Linux）：brew install clanker，最简单
源码编译：make install，自动拉取依赖并编译安装

安装后通过 clanker config init 引导式创建配置文件 ~/.clanker.yaml，指定默认云厂商和 AI 模型。

局限与争议

无 Web UI：纯命令行工具，对不习惯 CLI 的用户有上手门槛。配套的 Clanker Cloud 桌面应用是付费产品。
Maker 模式的信任问题：让 AI 自动执行云资源变更存在风险，虽然有幂等设计和安全检查，但生产环境使用仍需人工复核。
多云支持的深度不一：AWS 支持最完善（测试最多），GCP/Azure 次之，Tencent Cloud 等其他厂商覆盖较浅。
MCP 工具数量受限：当前 MCP 仅暴露约 25 个工具，而 CLI 本身支持上百个操作，Agent 通过 MCP 接入时能力受限。