GUI Agent不擅长确定性安装任务

在一台全新的 Windows 机器上，我做了一个显而易见的极客实验：用 AI Agent 来完成系统配置。

刚开始它看起来挺聪明的，也就持续了两分钟。

然后我就看着 OpenClaw 在安装程序的复选框上卡住、在模态窗口前暂停，简直就是数字版的"走进房间忘了要干什么"。

就在它还在和一个安装程序搏斗的时候，我切换了策略：

用 Ninite 处理常见的应用合集

用 WinGet 处理那些我希望保留并能反复运行的应用安装

用 PowerShell 处理那些无聊的系统级操作

用 GPT-5 或 Claude 做规划，而不是让它去点点点

这套组合在 AI Agent 恢复过来之前就完成了 18 个应用的安装。

看完 r/openclaw 这个帖子之后，我认为真正的教训比 Windows 配置本身更广泛：

GUI 驱动的 Agent 对于确定性工作来说是错误的抽象层。

如果任务是"搞清楚这台机器需要什么"，用模型。如果任务是"把这 18 个东西装好然后别搞幺蛾子"，用脚本。

错误：让 Agent 去扮演鼠标

我信奉反脆弱自动化。

OpenClaw、GPT-5 和 Claude 在问题模糊的时候很有用：

"给这台机器配置好 Python、Docker、VS Code、Node 和本地 Ollama 栈"

"比较各个包管理器，选出最干净的安装路径"

"起草一个安装脚本，并解释哪些地方可能会出错"

但在问题完全确定性的情况下，它们就没那么有用了：

取消勾选绑定的工具栏

选择默认安装路径

第二类场景正是 WinGet、Ninite 和 PowerShell 通过"无聊"获胜的地方。

这和你在 n8n、Make、Zapier 或自定义 Agent 工作流中看到的模式是一样的：

让 GPT-5 或 Claude 去解读混乱的输入

让确定性步骤去执行计划

除非需要判断，否则不要让模型介入

这种架构更快、更容易调试，而且通常更便宜。

在全新 Windows 配置上真正有效的方法

以下是我会再次使用的分工方案。

为什么 Reddit 一直推荐 Ninite

因为对于全新 Windows 安装后的第一个小时，Ninite 的效率仍然高得离谱。

如果你想要这样的合集：

Ninite 很难被击败。

你选好应用，下载一个安装程序，运行一次，然后就可以走了。

不用在厂商网站上搜索。不用在广告复选框里考古。不用十步安装仪式。

这就是 Reddit 一直提它的原因。它用极少的繁琐解决了显而易见的问题。

WinGet 何时比 Ninite 更好

一旦你关心可重复性，WinGet 就赢了。

重建开发机器

配置多台笔记本

记录入职流程

标准化团队环境

在 Git 里版本化管理安装脚本

几个有用的命令：

winget search vscode
winget install --id Microsoft.VisualStudioCode -e
winget install --id Docker.DockerDesktop -e
winget install --id Git.Git -e
winget install --id Python.Python.3.12 -e

导出已安装的应用：

winget export -o apps.json

之后在新机器上导入：

winget import -i apps.json

这是一个比指望 Agent 能熬过每种安装程序 UI 变化好得多的基础。

一个比完全 Agent 控制更实用的配置流程

这是我想推荐给大多数开发者的 workflow。

1) 用 GPT-5 或 Claude 来生成计划

我正在为一台全新的 Windows 11 机器配置后端开发环境。
我需要 Python、Node.js、Docker Desktop、VS Code、Git、Postman、WSL 和 Ollama。
给我：
1. 推荐的安装顺序
2. 可以用 WinGet 的包 ID
3. 用于配置的 PowerShell 命令
4. 任何依赖或坑点

这就是模型的强项。它们可以：

把模糊的需求变成具体的清单

捕捉缺失的依赖

建议包名

当某一步失败时重写计划

2) 用 Ninite 处理显而易见的桌面应用合集

快速获取常见应用。

用它来处理那些不需要纠结的东西。

3) 用 WinGet 处理任何你想保留的应用

$packages = @(
  "Microsoft.VisualStudioCode",
  "Git.Git",
  "Python.Python.3.12",
  "OpenJS.NodeJS.LTS",
  "Docker.DockerDesktop",
  "Postman.Postman"
)

foreach ($pkg in $packages) {
  winget install --id $pkg -e --accept-package-agreements --accept-source-agreements
}

4) 用 PowerShell 做系统配置

wsl --install
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
mkdir $HOME\dev -ErrorAction SilentlyContinue
git config --global init.defaultBranch main
git config --global pull.rebase false

5) 只在收尾或边缘场景使用 GUI Agent

如果某个奇怪的安装程序既没有包也没有静默安装选项，那就算了。

那就是 OpenClaw 风格的控制可以帮忙的地方。

但那应该是例外，而不是架构。

示例：模型做规划，脚本做执行

这是可以超越 PC 配置扩展的模式。

你可以让 GPT-5 或 Claude 来起草这样的脚本：

$apps = @(
  "Microsoft.VisualStudioCode",
  "Git.Git",
  "Python.Python.3.12",
  "OpenJS.NodeJS.LTS",
  "Docker.DockerDesktop"
)

foreach ($app in $apps) {
  Write-Host "Installing $app"
  winget install --id $app -e --silent --accept-package-agreements --accept-source-agreements
}

Write-Host "Done"

这比让 AI 真的去看屏幕、猜测"下一步"按钮挪到哪了要好得多。

同样的教训也适用于 Agent 工作流

这不只是 Windows 帖子。

这是你在任何严肃自动化中都会做的同样设计决策：

在 n8n 里，不要用模型去模拟普通 HTTP 节点能做的事。

在 Make 里，如果结构已经确定，不要在确定性的字段映射上烧 token。

在 Zapier 里，不要让模型去即兴发挥那些可以直接表达的 API 调用。

在自定义 Agent 框架里，不要让模型去掌控那些应该是脚本的执行路径。

重写失败的步骤

用确定性工具处理：

基础设施变更

这种分工才是让 Agent 有用而不是昂贵的表演。

一旦工作流变得重复，成本就更重要了

这正是 PC 配置实验连接到生产自动化的地方。

一旦你开始在大循环中使用 GPT-5 或 Claude：

多步骤 Agent 工作流

按 token 计费就会很快变得烦人。

不是因为模型不好。而是重复操作会以一种难以预测的方式叠加成本。

这就是为什么固定费率的计算对于构建 Agent 和自动化的开发者来说很有吸引力。

如果你的工作流架构是"模型思考，脚本执行"，你仍然希望模型随时可用，处理那些需要判断的部分。你只是不想让每次重试和规划都像一次计费事件。

这就是 Standard Compute 的吸引力：

OpenAI 兼容 API

兼容现有 SDK 和 HTTP 客户端

适用于 n8n、Make、Zapier、OpenClaw 和自定义 Agent 工作流

当你的自动化整天运行时不会有按 token 计费的焦虑

对于重度 Agent 的系统来说，这种定价模式比假装每个工作流都可以归结为一个廉价的 completion 要合理得多。

我实际试过之后的看法

Reddit 对 Ninite 的推荐是对的。

但只是针对问题的第一层。

我先用了蠢办法做这件事之后的结论：

Ninite 最适合全新 PC 上的快速应用合集。

WinGet 最适合可重复的、面向开发者的配置。

PowerShell 最适合系统配置和自动化粘合剂。

GPT-5 或 Claude 最适合做规划和修复工作流。

像 OpenClaw 这样的 GUI Agent 只适合那些没有确定性路径的边缘场景。

有效的模式不是"让 Agent 做所有事"。

让模型决定应该发生什么

让脚本和包管理器去做工作

只有当环境变得奇怪时才把 Agent 叫回来

这最终成了一个愚蠢的全新 PC 实验中有用的教训。

当我不再让 AI Agent 去假装是一只鼠标的时候，它才开始变得有用。

如果你在构建配置流程、入职脚本或 Agent 自动化，这个区分比 demo 本身要重要得多。