从“运行 shell 脚本”这六个字开始讲吧。你用 Automator 整理文件、批量改图片、跑个定时任务，都绕不开这个操作。结果某天打开工作流，Automator 直接弹出一条提示：“操作‘运行shell脚本’未载入，因为它包含无效的签名。”操作栏里那一堆常用组件还在，唯独“运行shell脚本”灰得不能再灰，点上去没反应，工作流也跑不了。我当时第一反应是重启 Automator，没用；重启电脑，还是没用。后来才发现，这个问题不是无解的玄学，而是 macOS 签名机制在工作流文件上的一次“体检未通过”。
这篇文章我会把这个报错的来龙去脉讲透，给你一套从轻到重的排查、修复思路，另外附上我自己的迁移经验和避开同类坑的方法。不管是刚接触 Automator 的新手，还是已经被这个问题折腾半天的老手，照着下面的顺序操作，大概率能救回来。
1. 从一次弹窗说起：这条报错到底意味着什么
1.1 我是在什么场景下撞见它的
第一次遇到这个错误，是在一次系统升级之后。升级完系统，我打开一个平时用了很久的自动化工作流，原本正常工作，那次打开却直接提示“操作‘运行shell脚本’未载入”。更奇怪的是，同一个工作流里的“访达”“拷贝文件”这些操作都好好的，只有 shell 相关的组件报错。
后来我在社群和论坛里发现，遇到这个问题的场景分布很集中：大部分人是在 macOS 大版本更新后踩雷；还有一部分人是从网上下载了别人分享的 .workflow 文件；也有些人只是在“自动操作”应用里新建了一个空工作流，拖一个“运行shell脚本”进去，就立刻报同样的问题。也就是说，这个问题跟系统环境的关系非常大，几乎可以当作“升级后遗症”来对待。
如果你当前也卡在这个状态，先别着急删文件。这个报错在绝大多数情况下不是工作流的功能逻辑坏了，而是文件被系统判定为“签名不可信”。逻辑还在，只是系统不打算执行它。
1.2 报错里的“无效的签名”不是玄学
“无效的签名”在普通用户听来很吓人，好像文件被人动过手脚。其实它是 macOS 每时每刻都在做的事：检查代码签名。
代码签名你可以理解成一份数字“封条”。macOS 在启动或加载一个可执行程序、一个自动化操作时，会先检查这个封条是否完整、是否由可信来源生成。如果封条断了、来源不明，或者文件被改动过导致封条对不上，系统就会拒绝加载。对于“运行shell脚本”这个操作而言，它本身是一个独立的可加载组件，同样要过这道安检。
那为什么其他操作不报错，偏偏 shell 组件报错？这和它在 Automator 里的实现方式有关。“运行shell脚本”操作内部依赖系统自带的命令行解释器，它的加载路径、权限要求都相对固定。一旦系统升级导致它的注册信息、签名缓存发生变化，这个组件最先表现出症状。说白了，它就是 Automator 组件里最敏感的那一个。
提示：看到“无效的签名”时，先默认它是“签名状态和系统记录不一致”，而不是你的脚本内容有恶意代码。你写的 shell 命令再长、再复杂，只要不涉及篡改系统文件，和这个报错没有直接关系。
2. 为什么偏偏是“运行shell脚本”：签名机制拆解
2.1 代码签名与 Automator 工作流的底层关系
Automator 的工作流文件后缀是 .workflow，表面看是一个文件，实际上它是一个文件夹。右键点击工作流文件，选择“显示包内容”，你会看到 Contents 目录，里面主要有 Info.plist 和 document.wflow。“运行shell脚本”操作的内容，其实就嵌套在这个 document.wflow 里面。
但这只是工作流文件的静态结构。Automator 在启动时需要把脚本操作加载进内存，这个过程会调用系统框架去校验组件签名。问题在于，校验的对象不只是工作流文件本身，还包括 Automator 应用、相关系统扩展以及操作对应的命令行辅助工具。任何一个环节的签名信息出现“错位”，系统就会给出“未载入”的结论。
再深挖一层：签名错位是怎么发生的。macOS 大版本升级时，系统会对内置组件做一次重签和缓存重建，这个过程理论上很顺畅，但如果你电脑上有老版本系统时代创建的 Automator 工作流，或者曾经手动修改过 Automator 应用的资源文件，缓存的签名数据就可能新旧混淆。最典型的例子就是同样一个工作流文件，从老系统拷贝到新系统之后，首次打开很容易触发这个报错。
2.2 哪些情况最容易让签名失效
我整理了几类高频触发场景，你对照一下自己属于哪一种：
- 系统跨版本升级后首次打开旧工作流。这个占比最高，尤其是连续跨了两个大版本的系统，签名缓存基本要重建。
- 从网络下载的 .workflow 文件。别人打包分享的工作流，到了你的机器上，原签名链不存在，系统会按未知来源处理。
- 手动编辑过工作流的包内容。比如你为了改参数，直接动过 Info.plist 或 document.wflow，文件的签名指纹马上失效。
- 使用第三方工具批量导入、导出过 Automator 配置，导致文件元数据被重写。
- 磁盘权限异常或文件被移到了没有执行权限的位置，例如放在“下载”目录等受沙盒约束的路径下。
看到这里你会发现，签名失效并不是“你操作错了”这么简单。它更像是 macOS 对文件执行状态的一次系统性审查。理解了这一点，后面的修复逻辑就清楚了：要么让文件恢复一个能被系统信任的签名状态，要么绕开触发签名的加载路径。
注意：下载第三方工作流时，尽量先用文本编辑器打开 document.wflow 查看里面有没有异常命令。这个习惯能在签名问题之外，再帮你筛掉不少不怀好意的脚本。
3. 拿到报错先别慌：三步定位问题范围
3.1 验证工作流的签名状态
在动手修之前，我强烈建议先做一次状态检查。这样可以避免你费了半天劲重装系统，结果发现只是一个文件属性问题。
打开“终端”，进入工作流文件所在目录，执行验证命令。如果你的工作流文件名为“批量压缩.workflow”，命令如下：
codesign --verify --deep --verbose=2 "批量压缩.workflow"终端会给出几种典型输出：
- 没有输出，表示签名没问题，报错来自其他环节。
- 输出“code object is not signed at all”，说明这个文件完全没有签名。
- 输出“invalid signature”，说明有签名但验证失败。
- 输出“code object is not signed”，说明签名确实丢了。
接着再查一下签名详情：
codesign -dv --verbose=4 "批量压缩.workflow"这条命令会显示签名者、签名标识、签名时间等信息。如果签名时间是几年前的，而你的系统已经升过级，那基本可以确定是签名链脱节了。把这两条命令的输出记下来，后面修复时能用来对比效果。
3.2 区分是系统级失效还是单文件失效
验证完签名之后，还需要确认问题只发生在单个工作流，还是整个 Automator 环境都受到影响。最简单的测试方法：在“自动操作”应用里新建一个空白工作流，拖入“运行shell脚本”，随手写一句echo "test"，然后运行。
这里会出现两种结果：
- 如果新建的工作流也报“无效的签名”，说明问题出在 Automator 应用本身或系统组件的加载环节。你需要优先修复系统级签名缓存，而不是去折腾某个 .workflow 文件。
- 如果新建的工作流完全正常，只有旧文件报错，那问题就集中在旧文件的签名状态上。接下来直接采用修复文件签名的方案即可。
这个区分特别重要。我见过有人为了一个旧文件的问题，把整个系统组件都怀疑了一遍，最后白白浪费了时间。定位清楚问题边界，再往下走效率会高很多。
建议：如果新建工作流也报错，可以先重启电脑并更新到最新补丁版本。系统组件的签名缓存经常在补丁中被重建，重启后问题会自动消失。
4. 实操修复方案：从省事到重做，按顺序来
4.1 方案一：复制重建工作流
如果你确认只有单个工作流出错，而新建工作流正常，那最简单的方法就是“重建工作流”。这个方法不涉及任何终端操作，也最容易理解。
具体做法是：在“自动操作”里新建一个同名工作流，然后打开旧工作流文件，如果旧文件还能显示内容，就全选所有操作步骤，复制到新工作流里。如果你连旧文件的内容都看不到，可以先右键点击旧 .workflow 文件，选择“显示包内容”，进入 Contents 目录，用文本编辑器打开 document.wflow，把里面的 XML 内容复制出来，再在新工作流中粘贴或导入。
重建完之后，把新的工作流另存为新文件，并替换掉旧文件。新文件会被系统打上当前环境的正常签名，报错自然消失。
这个方法看着笨，但成功率极高。因为 Automator 在工作流保存时会重新生成全套签名和元数据，相当于给文件换了新的“封条”。我在实际操作中，超过一半的场景靠这个方法一次解决。
4.2 方案二：用 codesign 重签或移除签名
如果重建工作量太大，或者你有很多个工作流要处理，可以试试命令行重签。
先备份原文件，然后执行临时重签：
codesign --force --deep --sign - "你的文件.workflow"这里的-表示使用 ad-hoc 签名，也就是不依赖开发者证书、只做防篡改标记的签名。执行完再用codesign --verify --deep --verbose=2验证，如果显示通过，大多数旧系统遗留文件都能恢复正常加载。
但 ad-hoc 签名不是万能的。某些系统版本会严格要求插件和主应用共享同一签名链，这时 ad-hoc 无法满足，Automator 依然会拒绝加载。
另一个思路是直接移除签名：
codesign --remove-signature "你的文件.workflow"移除签名后，系统会将文件当作“未签名”处理，部分场景下反而能绕过签名校验。不过这个操作会降低文件完整性保障，适用于老旧工作流的临时救急，不适合长期依赖。
注意：重签和移除签名之前，一定先备份。某些系统版本对签名错误特别敏感，操作不当可能导致文件彻底无法打开，只能从备份恢复。
4.3 方案三：清理 Automator 的本地缓存
如果重签没有效果，或者你确认新建工作流也报错，那大概率是 Automator 自身的签名缓存出了问题。这种情况下，清理本地缓存是性价比最高的一步。
先退出“自动操作”应用，然后执行以下命令：
killall Automator rm -rf ~/Library/Caches/com.apple.Automator你也可以顺手清理一下自动化相关的缓存目录：
rm -rf ~/Library/Preferences/com.apple.Automator.plist不过要注意，清理偏好设置会把你已经记住的窗口大小、最近打开文件等设置一起清掉，不算大损失，但没必要每次都用。
清理完成后再打开 Automator，测试新建的“运行shell脚本”操作是否恢复。我在实际处理中，清理 caches 目录能解决一半以上的系统级签名异常。因为系统会把组件加载过程中的签名校验结果缓存起来，一旦缓存数据和真实签名不一致，就会持续误报“无效的签名”。
4.4 方案四：升级系统环境后的系统级修复
如果上述方案都没能解决问题，可能就要考虑系统级修复了。这里要在“终端”里执行两条命令，分别检查和修复系统文件的签名和权限。
diskutil resetUserPermissions / `id -u`这条命令可以重置用户目录下所有文件的权限，消除文件属性对签名校验的干扰。
如果你怀疑系统组件本身的签名数据损坏，可以尝试在恢复模式下运行“系统完整性检查”相关功能。不过需要提醒的是，在恢复模式下操作属于大型修复动作，完成耗时较长，也存在一定风险。建议只在其他方案全部失败后使用。
在正常情况下，我建议优先执行一个更轻量的动作：打开“系统设置”，检查是否有可用的系统更新。很多签名缓存问题会随着系统补丁发布而被官方修复。你只需要更新并重启，很多时候“运行shell脚本”就恢复了。
5. 换条路走：把“运行shell脚本”迁移到其他工具
5.1 Automator 和 AppleScript 怎么分工
如果你连续试过上述方案，还是觉得 Automator 的签名机制像个黑盒子，低效且折腾，那么可以考虑把关键逻辑迁出 Automator，换一种方式实现。
Automator 适合可视化组装流程，但对细粒度的 Shell 命令支持并不友好。相比之下，AppleScript 通过do shell script可以直接执行 shell 命令，而且可以编译为脚本应用，签名逻辑也更简单。
两者分工大概是这样：
- 如果你的需求是“批量操作文件、处理 Finder 项目、和邮件联动”，Automator 更顺手。
- 如果你的需求是“执行自定义命令、处理管道、获取命令输出、做条件分支”，AppleScript 的
do shell script更直接。 - 如果你想把脚本打包成应用，AppleScript 编辑器能直接导出为 .app，还支持简单的权限配置。
5.2 一个可以直接抄的迁移实例
假设你原本用 Automator 在工作流里运行下面的 shell 命令，用来批量压缩某目录下的图片：
cd ~/Pictures/raw && for img in *.png; do sips -s format JPEG "$img" --out "${img%.png}.jpg"; done在 Automator 报错情况下，你可以在“脚本编辑器”里新建一个 AppleScript，写入：
do shell script "cd ~/Pictures/raw && for img in *.png; do sips -s format JPEG \"$img\" --out \"${img%.png}.jpg\"; done"然后点击“运行”测试。如果输出正常，再通过“文件”菜单导出为“应用程序”。以后直接用双击这个 App 来执行压缩任务，不再依赖 Automator 的签名加载流程。
这个迁移看起来简单，但解决的是本质问题：你不再依赖 Automator 组件的动态加载，而是让系统直接运行一个独立的脚本应用。签名校验发生在 App 层面，只要 App 是你本机导出的，系统天然信任。
提示：AppleScript 里执行 shell 命令时，路径中的空格和引号很容易出错。最稳妥的做法是在 shell 代码里先加一层转义，或者用 quoted form 处理变量。
5.3 用“快捷指令”作为轻量替代
如果你的任务没有太多复杂的文件操作，另一个可选项是“快捷指令”。它里面有一个“运行 Shell 脚本”操作，设计上比 Automator 更现代，签名加载机制也更新。
迁移方法同样很简单：新建一个快捷指令，添加“运行 Shell 脚本”步骤，把命令粘贴进去，然后配置输入来源。快捷指令还支持接收来自“共享菜单”“菜单栏”“键盘快捷键”的输入，触发方式比 Automator 更灵活。
我个人的体会是：快捷指令适合“轻、快、场景单一”的自动化任务。例如一键整理截图、一键发送文件到指定文件夹，都很顺手。但如果你依赖文件拖拽的交互方式，或者需要和访达深度联动，Automator 的界面化流程依然有它的优势。
6. 踩坑速查：常见错误与你可能忽略的细节
6.1 常见问题与排查清单
我整理了一份对应表，方便你在不同场景下快速定位问题：
| 错误表现 | 常见原因 | 优先尝试的解法 |
|---|---|---|
| 新建工作流拖入“运行shell脚本”就报错 | Automator 组件缓存损坏 | 清理 com.apple.Automator 缓存后重启 |
| 只有特定旧工作流报错 | 旧文件签名链脱节 | 复制重建工作流 |
| 系统升级后大量工作流集体失效 | 系统签名缓存与旧文件不匹配 | 先做系统更新重启，再逐文件重签 |
| 终端能执行命令，Automator 报错 | Automator 加载路径与终端不同 | 清理缓存并重置文件权限 |
| 从网上下载的工作流报错 | 签名者身份不匹配 | 检查并移除非必要操作后重建 |
6.2 最容易犯的五个错误习惯
第一个错误习惯是看到报错就删除旧工作流，没有先做备份。这个报错几乎不影响文件内容，删了就真的丢失逻辑了。正确的做法是先把 .workflow 文件复制一份到安全目录，再动手修。
第二个错误习惯是直接修改工作流包内容里的 XML，却不知道改完签名立刻失效。如果你需要调整参数，尽量通过 Automator 界面操作，避免用文本编辑器改内部文件。
第三个错误习惯是盲目执行codesign --force --deep --sign。如果不先搞清问题边界，重签可能覆盖掉原本正常的签名状态，反而让问题扩大化。
第四个错误习惯是忽略文件存放位置。放在“下载”“桌面”等带特殊权限约束的位置，有时会触发额外的安全检查。把重建好的工作流移动到“文稿”或其他自定义目录，可以少踩很多坑。
第五个错误习惯是把 Automator 当作唯一方案，没有多准备一条脚本路径。一旦签名系统出问题，整个自动化流程就断了。我更建议把核心命令抽出来单独存成.sh文件，用 Automator 或快捷指令去调用，这样即使 UI 组件崩了，脚本本体还能在终端直接运行。
我个人在实际操作中最常用的组合是：Automator 负责接收文件和交互，真正的逻辑放在独立的.sh脚本里。这样即使 Automator 再报“无效的签名”，我也可以在终端里手动跑脚本，自动化流程不会彻底中断。
如果你决定长期在 macOS 上做自动化，不妨花半小时把目前使用的每个 Automator 工作流都检查一遍，把核心 shell 命令整理到独立脚本文件中，然后在 Automator 里只保留一个“运行shell脚本”调用外部文件的操作。这个习惯能帮你把类似签名问题的冲击降到最低。最后还有个经验之谈：遇到系统升级，不要马上打开所有旧工作流。升级完先重启一次，等系统完成签名缓存的重建，再逐个打开工作流测试。这个操作顺序能避免很多“签名无效”的误报，亲测有效。
