AI Shell 实战：用自然语言把云资源操作跑通（含权限模型与踩坑）

从去年开始，很多云厂商都在把「自然语言运维」做成一个可交互的终端产品。华为云的 AI Shell 就是这类形态：一个浏览器里拉起来的云端作业环境，预装 CLI 和一批资源管理技能，用对话的方式下发任务。这篇文章基于实际使用，讲清楚它的会话是怎么建立的、工具调用为什么要二次确认、以及容器层面容易踩的几个坑。

一、它是怎么跑起来的

点开 AI Shell 入口后，首先弹的是一个凭据同步确认框：是否把当前账号的临时访问凭据（AK/SK）同步进 AI Shell 环境。这个设计的目的很直接——省掉手工配置 AK/SK 的步骤，让终端一启动就具备调用云 API 的能力。凭据只存在沙箱容器里，可以用 hwcloud logout 清除。

确认之后，后端会分配一台容器，前端通过 WebSocket 连上容器内的 tty，浏览器里看到的就是一个真实的 Linux 终端。所以你在里面敲 ls、cat、curl，和在本地机器上没有区别，只是环境是临时的。

二、会话模型与上下文

进入 hwcloud chat 后，界面大致分三块：顶部是 Session ID 和当前上下文 token 数，中间是对话历史，底部是输入框和当前使用的模型（我这边是 glm-5.2，provider 标的是 huawei-inner-provider）。

每个会话有独立的 Session ID，上下文按 token 累计。实测一轮简单的工具调用任务下来，上下文从 0 涨到一万出头，这里面既有系统提示词和技能描述，也有工具返回结果。所以不要在一轮会话里堆太多无关任务，长会话的上下文成本会明显上升，也会让模型更容易抓错重点。

三、工具调用为什么要二次确认

这是我觉得设计上比较克制的部分。AI Shell 不是把命令直接扔进 shell 执行，而是先声明一个工具调用意图，再由用户确认。以「创建一个文件并读出来」为例，流程是：

1. 模型输出计划，声明要调用 write_file(path=/root/xxx.txt)
2. 2. 界面弹出 Permission Request，列出 Write file 和路径，给出 Allow once / Allow always / Reject once / Reject always 四个选项
3. 3. 用户确认后才真正写入，结果回填到上下文
4. 4. 接着声明 bash_exec(command=cat ...)，再次确认，才执行

这个机制的意义在于：模型可以规划，但动作边界由人控制。对生产环境来说这是必须的——一个没有确认环节的 Agent 直接对着云账号执行命令，风险不可控。Allow always 适合在一次性沙箱里做连续操作，Reject always 则可以在发现模型理解偏差时立刻止损。

四、几个实际的坑

1）容器实例的环境差异。AI Shell 的容器是临时分配的，不同实例的状态可能不一致。我遇到过某次启动后 hwcloud chat 直接报「预置模型配置失败，可能原因：当前机器上没有密码保管箱（无法保存 apiKey）」的情况，重试两次仍然失败。换成新拉起的容器后一次就成功了。遇到这类报错，优先怀疑实例环境，而不是自己的操作步骤。

2）会话生命周期。Beta 期间容器断开连接满一小时就会被销毁，再次进入会重新分配一台全新的容器。这意味着里面的临时文件不会保留。需要保留的产物要及时导出，或者改用持久化版本。

3）不要在容器里存长期凭据。临时 AK/SK 只适合沙箱内的短期操作，用完可以用 hwcloud logout 清理，避免容器被复用或残留时泄露。

五、一份可以直接用的提示词模板

写提示词时，把「目标、边界、验收标准」三件事说清楚，比堆形容词有效：

目标：在华北-北京四创建一台按需计费的 ECS，规格 s6.small.1，系统盘 40G 高 IO，镜像用 Huawei Cloud EulerOS 2.0。

边界：不要动现有的 VPC 和安全组，新机器挂到已有的 default 安全组；带宽只开 1M。

验收：创建完成后列出实例 ID、私网 IP、计费方式，并确认状态为 running。

这种写法下，模型一般会先给出资源清单让你确认，再逐步执行，中间每一步都能看到它打算做什么。

六、小结

AI Shell 的价值不在于「用嘴代替手敲命令」，而在于把 Agent 的规划能力和云 API 的执行能力放在一个有确认环节的沙箱里。真正需要适应的是工作方式的改变：从写命令变成写约束条件，从盯执行变成审计划。对日常的查询类、轻量部署类任务，它的效率提升是实实在在的；对涉及生产资源的操作，建议保持 Allow once 的习惯，把确认权留在自己手里。