让 AI Agent 安全地操作华为云：KooCLI + MCP 实战指南

摘要：AI Agent 能写代码已经不稀奇，能安全地"动手改云"才是真本事。本文用华为云 KooCLI（hcloud）与官方 MCP 工具，搭出一条"只读优先、写操作逐条审批、购买先过成本门"的可落地路径，让 Agent 既能干活，又不至于把生产环境干翻。

一、起点：Agent 想"动手"，我们却不敢放手

AI Agent 已经能读代码、查文档、写配置。但当它要真正操作云资源时，大多数团队会本能地踩下刹车。原因很现实：

• 幻觉命令：模型凭"训练记忆"编造 API 名和参数，把一次"清理测试环境"变成一个不存在的危险操作。
• 误操作不可逆：删库、删桶、放开安全组，一次失误可能就是一次线上事故。
• 凭证外泄：把长期 AK/SK 直接塞进 Prompt、代码或日志里。
• 无法审计：谁、在什么时间、动了哪个资源，事后说不清楚。

核心矛盾在于：我们想要 Agent 的效率，但承受不起它"自由发挥"的代价。

本文给出的一条路径是：用 KooCLI（hcloud） 作为执行层，用官方 MCP 工具作为编排与安全层，把风险挡在操作真正发生之前。

二、第一原则：先"查"，再"做"

华为云有 200+ 服务，命令、配额、区域上线状态变化都非常快。所以第一条铁律是：

绝不依赖模型的训练数据来执行云操作。

正确姿势是让 Agent 先发现、后执行。比如要"列出 ECS 云服务器"，应该先看清有哪些真实存在的操作：

hcloud ECS --help
hcloud ECS ListServersDetails

而不是让模型凭印象写一个 hcloud ECS ListServers——一个"看起来很像、但根本不存在"的操作名。

"先 --help、再执行"这个习惯，是一切可靠性的根基。

三、环境准备：三步让 KooCLI 跑起来

1）安装与校验

hcloud version

2）配置凭证

hcloud configure init
# 按提示输入 AK/SK 与区域，例如华北-北京四 cn-north-4

这里有一条重要的安全建议：给 Agent 使用的 AK/SK，应绑定一个"最小权限"的 IAM 子用户，绝不要用主账号密钥。

3）确认身份与账号类型

在 MCP 化的工作流里，可以先用账号类型检查能力确认当前凭证是主账号还是 IAM 子用户——这直接决定了"允许它执行写操作"的风险等级。

四、核心设计：三段式安全模型

把 Agent 的能力切成三层，权限逐层放大：

铁律：L3 的每一条命令，都必须先把"精确的命令原文"展示给用户并获得批准，才允许执行。

这不是可选项，而是安全底线。工具负责"安全地执行"，是否执行则由人来决定——执行与决策必须分离。

五、实战 A：只读侦察，先把家底摸清

面对一个模糊需求，比如"看看我在华北的资源情况"，Agent 应该先把意图收敛到具体区域，再查询：

# 1. 先发现可用区域（MCP 工具即可完成）
# 2. 只读查询华北-北京四的 ECS 实例
hcloud ECS ListServersDetails --cli-region=cn-north-4

如果问题是"某个服务在目标区域到底上不上线"，应先做区域可用性确认，再决定动不动手。不要在不可用的区域上浪费时间和额度，也不要盲目扫描所有区域——目标区域明确时，就只看目标区域。

六、实战 B：接上 MCP，让工具自己"带规则"

华为云把上面这套能力封装成了一组 MCP 工具，Agent 可以直接调用。常用的几类：

• 发现与学习：搜索文档、加载技能，先搞清楚该用哪个服务、哪条命令
• 只读执行：受安全策略约束的只读命令执行，输出自动脱敏
• 计划与预检：命令分类规划、命令风险检查、部署计划检查
• 审批执行：仅在"精确命令已被人工批准"后执行写操作
• 凭证与账号：检查认证状态、判断账号类型

这套设计的精髓是：Agent 拿到的不只是"一个能跑命令的手"，而是"一只带着规则与刹车的手"。

七、实战 C：写操作的成本闸门与有序销毁

一旦涉及购买资源（ECS + EIP + 磁盘 + 安全组……），问题就不只是"删不删得掉"，还有"花不花得起"。这时应当切换到 IaC（资源编排） 路径，它会强制加上几个阶段：

1. 成本门：先给出架构方案与费用估算，用户确认后再购买。
2. 批量审批：成套资源一次性审核，而不是一条条零散点。
3. 状态跟踪 + 有序销毁：销毁按依赖顺序执行，避免"删了 VPC 却留下孤立 EIP"这类烂摊子。

如果只是想要一个临时的 Web 预览环境（hello world / 原型 / Demo），更轻的选择是 Sandbox（临时开发环境）：临时运行时 + 即时可访问的公网 URL，零计费资源，用完即弃，不进入生产账单。

一个值得强调的官方要求：当需求是"部署一个 Web 应用"却没有指定目标时，不应默认选择某个单一服务，而应先把选项摆出来——临时沙箱（推荐）/ 静态网站托管 / 云服务器 / 容器——让用户显式选择。把选择权交还给用户，本身就是一种安全设计。

八、凭证与审计的最佳实践

• 最小权限：为 Agent 单独创建 IAM 子用户，只授予完成当前任务所需的策略。
• 短凭证优先：能用临时 AK/SK 就别用长期密钥，能过期就别常驻。
• 不进 Prompt：AK/SK 永远不要写进对话、代码或日志，只放在凭证库或环境变量中。
• 可审计：开启云审计服务，让每一次写操作都有迹可循。
• 输出脱敏：检查工具返回时，凭证相关字段应被自动遮蔽。

安全不是"给不给权限"的二选一，而是怎么给、给多少、以及怎么收回的工程问题。

九、串起来：一次合格的 Agent 会话长什么样

用户：帮我在北京四看看有没有闲置的 ECS，如果多的话给我一份清理建议（先别动手）
Agent（L1）：hcloud ECS ListServersDetails --cli-region=cn-north-4  → 列出实例
Agent（L2）：对候选实例生成"待删除清单"，逐条做命令风险检查
Agent：    把精确的删除命令原文 + 影响面呈现给用户
用户：确认删除第 3 台
Agent（L3）：执行且仅执行已被批准的那一条命令
Agent：     复查资源列表确认结果，并保留云审计留痕

注意这条链路：模型从不"自由地"修改云资源，它只是把人的决策安全地翻译成命令。

十、结语：把"翻车概率"压到最低

让 Agent 操作云，本质不是"要不要给它权限"，而是"如何建立一套让人放心的协作机制"。把下面这份 Checklist 贴进你的团队规范：

• [ ] 不靠模型记忆，先 --help 再执行
• [ ] 只读与写操作分层，写操作逐条审批
• [ ] 涉及购买先过成本门，销毁严格按序
• [ ] 临时环境优先用沙箱，生产再上云服务器 / 容器
• [ ] 最小权限 + 短凭证 + 云审计

做到这些，你就能在享受 Agent 效率的同时，把"翻车"的概率压到最低。

如果你也在为"让 Agent 安全落地"做探索，欢迎在评论区交流你的实践与踩坑经验。