一句「把这个服务部署到测试环境」丢进 Sealos Desktop 的对话窗口后，Agent 通常先要自己决定两件事：在哪个目录里干活、读哪份部署配置。这两个判断不会自动显示在对话里，所以别急着看它回复的「部署成功」，而要先把它实际站的位置和依据的配置固定下来。可核对的线索一般只有三类：终端里 pwd 的返回、Kubeconfig 指向的集群与命名空间、以及 YAML 里真正被提交的镜像与端口字段。

在 Sealos Desktop 中让 Agent 执行部署前，先用 pwd 与 ls 确认工作区目录，再用 kubectl config current-context 与 view `--minify` 确认集群和命名空间，最后把 YAML 里的 image、containerPort 与 kubectl get 的回显逐项比对。三处对不上时先停下核对，不要用「再执行一次」掩盖配置来源不明的问题。

确认 Agent 实际操作的工作区目录

对话式 Agent 常见的问题是：它在你以为的项目目录之外执行，读到了同名的另一份 YAML。让它在终端里回显当前路径和文件清单，是最省事的排除办法。下面几条命令按顺序执行，适合放在 Agent 刚接收指令、还没动手修改的那一步。

pwd
ls -la
git rev-parse `--show-toplevel` 2>/dev/null || true
find . -maxdepth 2 -type f -mmin -30 | head -n 40

pwd 给出当前目录；git rev-parse 给出仓库根目录，若返回路径与 pwd 不一致，说明 Agent 处在子目录，配置可能来自上层目录；find 按最近修改时间列出文件，用来判断有没有生成计划外的文件。接下来把本次操作涉及的文件范围写清楚，通常包括：待提交的 Deployment YAML、可能被引用的 values 或 env 文件、Kubeconfig 路径，以及 Agent 自己生成的临时脚本。文件范围一旦超出这三四类，就值得回头确认它是不是读错了工作区。

把一句自然语言要求拆成可核对的执行清单

模糊需求最容易掩盖「读了哪份配置」这个问题。可以把一句需求先改写成带有具体对象、环境和版本的句子，例如：「把仓库里的 demo-api 部署到 test 命名空间，副本数为 1，镜像 tag 用 v1.2.0」。然后把这句话拆成动作，每个动作都对应一个可看到的产物。

1. 确认当前上下文与命名空间：产物是 kubectl config current-context 与当前 namespace 的回显。
2. 定位并读取 Deployment YAML：产物是该文件的绝对路径，以及文件内 metadata.namespace 的值。
3. 按需求修改 image 与 replicas：产物是修改前后的 diff，只允许这两个字段变化。
4. 提交并观察滚动状态：产物是 rollout status 的返回与 Pod 列表。
5. 核对端口与访问方式：产物是容器 containerPort 与 Service 里 port、targetPort 的对应关系。

拆到这个粒度后，Agent 每做一步都应能对应到上面某一项产物，读者也能从中看出它到底是在改文件、改集群，还是只改了自己临时拼的命令。

核对部署配置里的镜像与端口字段

下面是一份通用的 Deployment 骨架，字段名按 Kubernetes 常规写法，具体项目可替换名称与镜像地址。它不是唯一写法，只是让核对有落点。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: demo-api
          image: registry.example.com/demo/demo-api:v1.2.0
          ports:
            - containerPort: 8080
          env:
            - name: APP_ENV
              value: test

metadata.namespace 决定部署落到哪个命名空间；spec.replicas 决定副本数；image 的 tag 决定实际拉取的版本；containerPort 只是容器内的端口声明，能不能访问还要看 Service 的 port 与 targetPort 是否指到同一个值。核对时以实际命令输出为准，不要以对话里转述的配置为准；sealos 或 kubectl 的子命令参数，建议先用 `--help` 确认当前版本支持哪些写法，再执行。

kubectl config current-context
kubectl config view `--minify` -o jsonpath='{..namespace}'
kubectl get deploy demo-api -n test -o yaml | grep -E 'image:|containerPort:|replicas:'

在命令回显里比对期望状态与实际状态

判断标准可以很简单：期望值来自你确认过的那份 YAML，实际值来自集群回显，两边逐项对上才算通过。

发现不一致时，按这个顺序排查：先看上下文和命名空间是否被覆盖，再看 Agent 是不是把 YAML 提交到了别的文件或别的目录，然后看镜像 tag 是否被本地缓存或覆盖参数改写，最后看端口与 Service 选择器是否匹配。到这一步仍对不上，建议先停手，把回显原样保存，再决定要不要回滚。

把本次指令与配置差异记进项目笔记

记笔记的目的不是留档好看，而是让下一次同类指令能直接复用，不必再重新猜 Agent 读了哪份配置。可以按下面四段写，放在项目仓库的 docs 或 notes 目录下。

需求原文：把 demo-api 部署到 test 命名空间，1 个副本，镜像 tag v1.2.0
执行动作：读取 deploy/demo-api.yaml；修改 image 与 replicas；kubectl apply
配置改动：仅 image 从 v1.1.0 改为 v1.2.0，replicas 保持 1
验证结果：current-context 为指定集群；namespace 为 test；
          kubectl get deploy 显示 READY 1/1；containerPort 与 Service targetPort 均为 8080
差异说明：Agent 初始读取的是 deploy/old/demo-api.yaml，已改为 deploy/demo-api.yaml

最后一行值得单独写出来：配置来源的偏差是最容易被忽略、也最值得复盘的一项。把「读了哪份文件」写进笔记，下一次再给 Agent 下同类指令时，就可以先让它复述工作区和配置路径，再放行执行。