AI Shell 进入日常运维前：会话持久化、协议适配和可审计边界

从一次命令到一段任务

Shell 原本是无状态的：用户输入命令，系统返回结果。AI Shell 改变了交互方式，用户会连续描述目标、补充限制、让助手解释错误，再执行下一步。这种体验更接近“任务会话”，而不是单条命令。

近期社区里关于 AI Shell 会话持久化、开发者空间以及 ACP/MCP 支持的讨论，说明开发者关注点正在从“能否回答”转向“能否接入工作流”。如果会话不能恢复，长任务中断后就要重新描述上下文；如果协议不能适配外部工具，就难以把 AI Shell 放进更大的研发自动化链路；如果审计边界不清楚，团队也很难放心用于运维场景。

会话持久化应保存什么

会话持久化不是简单保存聊天记录。对开发和运维任务来说，至少要保存六类信息。

第一类是用户目标，例如“排查测试环境订单服务 502”或“生成灰度发布检查清单”。目标需要有创建时间、发起人和所属项目。

第二类是环境快照，包括当前工作目录、Git 分支、云区域、目标集群、命名空间、凭据来源和工具版本。

第三类是上下文资料，包括用户上传的日志片段、检索到的文档、命令输出摘要和错误栈。

第四类是计划与决策，例如 AI 建议的排查步骤、用户批准或拒绝的操作、跳过某一步的原因。

第五类是执行记录，包括命令、参数、开始时间、结束时间、退出码和输出摘要。

第六类是敏感信息处理结果，例如哪些字段被脱敏，哪些凭据只以引用形式参与执行。

一个最小会话模型可以这样设计：

{
  "session_id": "sess-20260801-001",
  "project": "order-platform",
  "owner": "devops-user",
  "goal": "diagnose 502 in test namespace",
  "environment": {
    "region": "cn-north-4",
    "cluster": "cce-test",
    "namespace": "order-test",
    "git_branch": "release-2026-08-01"
  },
  "decisions": [
    {
      "step": "check rollout status",
      "approved_by": "devops-user",
      "risk": "read-only"
    }
  ],
  "commands": [
    {
      "cmd": "kubectl get pods -n order-test",
      "exit_code": 0,
      "output_ref": "logs/cmd-001.txt"
    }
  ]
}

注意 output_ref 指向日志文件，而不是把完整输出塞进会话 JSON。这样可以控制体积，也便于对日志做脱敏和访问控制。

持久化的边界

会话持久化有三条边界。

第一，不能保存明文凭据。Access Key、Token、Cookie、数据库密码都应在写入前脱敏。会话里只保存“使用了哪个凭据引用”，不保存凭据本身。

第二，不能把所有终端输出永久保存。日志可能包含个人信息、客户标识或内部地址。建议按数据等级设置保留期，普通排障会话保留 7 到 30 天，事故会话按审计要求单独归档。

第三，恢复会话不等于自动继续执行。用户重新打开会话后，系统可以恢复上下文和计划，但涉及变更的命令必须重新确认，尤其是删除、重启、扩容、权限修改等操作。

ACP/MCP 适配层怎么设计

无论使用 ACP、MCP 还是其他工具协议，核心问题都是把 AI Shell 能力包装成清晰的工具接口。一个好接口要明确输入、输出、权限和副作用。

可以先把能力拆成三组。

只读上下文工具：读取当前项目、读取 Git 状态、查询云资源、查询日志、查询流水线状态。

分析工具：总结错误日志、生成排查计划、比较配置差异、解释 Terraform plan。

受控执行工具：运行只读命令、触发非生产流水线、生成变更单。生产变更应要求人工审批。

工具描述不要写得过于宽泛。比如“执行任意命令”是危险接口，“在指定命名空间执行只读 kubectl get/describe/logs”才是可治理接口。

tools:
  - name: k8s_readonly_query
    description: Run approved read-only Kubernetes diagnostics
    inputs:
      namespace: string
      command: enum:get_pods,get_events,describe_deploy,tail_logs
      target: string
    side_effect: none
    approval_required: false

  - name: trigger_test_pipeline
    description: Trigger a non-production pipeline with fixed parameters
    inputs:
      pipeline_id: string
      branch: string
    side_effect: creates_build
    approval_required: true

如果未来产品原生支持某个协议，团队可以把这层适配器替换为官方入口；在此之前，也可以用网关或本地服务承接协议请求，再调用 AI Shell 或相关自动化能力。关键是接口定义要稳定，不能把供应方差异直接暴露给业务流程。

权限模型：先分风险，再谈智能

AI Shell 最怕的是“会说就会做”。进入团队日常运维前，需要按风险分级。

零级是解释型能力，只能解释命令、日志和错误，不访问实时环境。

一级是只读能力，可以查询资源、日志、监控和流水线，但不能修改状态。

二级是低风险变更，可以触发测试环境构建、创建临时诊断任务、生成配置补丁，但需要用户确认。

三级是生产变更，包括重启服务、修改路由、扩缩容、删除资源、变更权限。三级操作不建议由 AI Shell 直接执行，应生成变更单、检查清单和回滚方案，由现有发布或运维系统执行。

这种分级听起来保守，但能避免把自然语言误解直接转化成生产事故。

一个排障会话示例

假设用户在开发者空间中排查测试环境接口 502，可以把任务分成可审计步骤。

第一步，记录目标和环境。

goal: diagnose 502 for order-api in test
scope: namespace order-test, read-only diagnostics
approval: user confirmed read-only commands

第二步，只运行只读命令。

kubectl get deploy order-api -n order-test
kubectl get pods -n order-test -l app=order-api
kubectl get events -n order-test --sort-by=.lastTimestamp
kubectl logs deploy/order-api -n order-test --tail=200

第三步，AI Shell 总结证据，而不是直接下结论。比如“最近 10 分钟内 order-api 有 3 次 Readiness probe failed，日志出现 upstream timeout，未发现镜像拉取失败”。如果证据不足，应建议继续查询网关或依赖服务，而不是猜测数据库故障。

第四步，生成候选修复和验证命令。涉及修改探针、调整超时或回滚镜像时，输出补丁和风险说明，等待用户走发布流程。

常见坑位

第一个坑是把会话持久化做成全文搜索。聊天全文有用，但运维审计更关心目标、环境、决策、命令、输出摘要和审批。

第二个坑是忽略脱敏。命令输出中的 Token、内网域名、客户编号可能被模型或日志系统长期保存，必须在持久化前处理。

第三个坑是工具能力过大。一个“run_shell”接口会让所有权限边界失效，应拆成小工具并声明副作用。

第四个坑是恢复会话后自动执行。恢复上下文可以自动，恢复执行必须重新确认。

第五个坑是没有失败分类。超时、权限不足、命令不存在、资源不存在、模型拒答应该被分开记录，方便后续优化。

验证清单

团队可以用下面的问题判断 AI Shell 是否适合进入日常流程。

1. 断开后能否恢复目标、环境、计划和已执行证据。
2. 会话中是否没有明文凭据。
3. 工具接口是否声明了副作用和审批要求。
4. 只读操作和生产变更是否有明确分界。
5. 用户能否导出排障报告或变更证据。
6. 失败时是否保留足够信息供人工接手。

输出报告要面向交接

AI Shell 如果只在当前窗口里给出结论，价值会随着会话关闭而衰减。更实用的做法是让每个重要会话都能导出一份轻量报告，方便值班交接、故障复盘或变更评审。

报告不必很长，但应包含任务目标、环境范围、关键证据、已执行命令、未确认假设、建议动作和风险提示。尤其要区分“已经观察到的事实”和“基于事实推断的可能原因”。例如“Pod 最近 5 分钟重启 3 次”是事实，“可能由探针超时导致”是推断。把这两类内容混在一起，会让接手的人难以判断下一步该验证什么。

对跨班次排障来说，报告还应记录哪些操作没有执行以及原因。比如“未执行重启，因为当前没有变更窗口”“未查询生产数据库，因为会话权限为只读”。这些负面信息常常比成功命令更有价值。

总结

AI Shell 的长期价值不在于替用户记住几条命令，而在于把自然语言、工具调用和云环境证据连接起来。会话持久化让长任务可恢复，协议适配让能力可集成，权限分级和审计记录让团队敢于把它放进真实研发流程。先把这些边界做清楚，再扩大使用场景，才是从尝鲜走向工程化的路径。