技术 · 熟练
它不会用你的软件，因为没有按钮可按
agent 缺的不是智能，是那双手
让 AI 操作一个只有图形界面的软件，常见的失败不是「它不懂」，而是「它没法按」—— 屏幕上只有像素，它不知道哪个是按钮、点了会发生什么、做完没有。这一页讲的是把老软件「翻译」成 agent 能用的形态：给它套一层命令行外壳。做法是四步：先判这个软件能不能被脚本化（有没有批处理 / 有没有可调用的入口）→ 一次只包一个核心动作 → 每个动作必须有退出码与可回读的状态 → 最后才扩到全功能。判据只有一句：做完之后，agent 能不能自己回答「成了没有」。
方法 · 一图看懂
1
先判能不能被脚本化 — 有没有批处理、宏、插件接口、可调用的可执行文件；三样都没有就先别包
2
一次只包一个动作 — 先包「打开→做那件事→保存」这一条，别一上来铺满菜单
3
每个动作给退出码 — 0 成功 / 非 0 带原因，让它能分支；没有退出码的封装等于没封装
4
状态做成可回读 — 做完能查（文件在不在、大小对不对、日志最后一行是什么），而不是靠猜
5
最后才扩全功能 — 等第一条动作稳定跑通十次，再按同样形状复制到下一条
原理 · 为什么有效
命令行之所以比图形界面更适合 agent，不是因为它「更老」，而是因为它把三件事写进了协议：参数（我要做什么，写在同一行里）· 退出码（成没成，一个整数）· 标准输出（做成了什么，一段可解析的文本）。图形界面这三样都没有 —— 它只有坐标和像素，而坐标会随窗口大小、主题、语言、分辨率变化。
所以「套壳」这件事的价值不在自动化本身，而在把一个不可判定的界面，变成可判定的接口。一旦有了退出码和可回读的状态，agent 就能自己闭环：失败重试、成功继续、异常停下 —— 这三件事才是「能干活」和「看起来在干活」的分界。
这也是为什么一次只包一个动作：动作越小，失败越容易被定位；一上来包整个软件，坏了你不知道坏在哪一步。
适用场景
适用：手里有必须继续用的老软件（行业工具、单机版财务 / 设计 / 排版软件、只有 Windows 客户端的专用系统），且想让它进入自动化流程。
⛔ 不适用：软件本身有官方 API 或成熟 CLI —— 那就直接用，包一层只是多一个会坏的中间层。
⛔ 不适用：动作涉及不可逆操作（删除、批量覆盖、对外发送）而你又没法加确认闸 —— 先解决确认机制，再谈自动化。
⚠️ 前提：愿意接受「先只自动化一条动作」，而不是一次做完所有功能。
自测 · 5 问
我要自动化的那个软件，有没有批处理 / 宏 / 插件接口 / 可以直接调用的可执行文件？我说得出是哪一种吗？
我打算包的第一个动作，能不能用一句话说清「输入是什么、输出是什么」？
这个动作做完之后，agent 怎么知道成了没有 —— 有退出码吗，还是要靠看屏幕？
如果它失败了，日志里能不能看出失败在第几步？还是只有一句「出错了」？
这条动作里有不可逆的部分吗（删除 / 覆盖 / 对外发送）？确认闸放在哪？
怎么上手 · 验证步骤
第一轮只包一条动作，挑那种「每天都做、每次三十秒、但一天要做二十次」的 —— 回报最快，也最容易验证。
按四步走：① 找到这个软件可以被脚本触发的入口（命令行参数 / 批处理文件 / 宏 / 插件）② 写一个最小封装：接一个输入文件路径，跑完吐一个退出码 ③ 加一条「自检」：跑完检查产物文件存不存在、大小是否大于 0 ④ 让它连续跑十次，十次都成功才算这条动作立住。
十次里有一次失败，就先别加第二条动作 —— 那条不稳定会污染后面所有判断。
自检动作：把封装交给一个「完全不知道这个软件怎么用」的人（或另一个 agent），只给它一句用法说明，看它能不能跑通。它跑不通，说明你的封装还在依赖「屏幕上的知识」；它跑通了但说不清成功与否，说明退出码没做对。两个都过，这条动作才算真的可被 agent 使用。