1. 从能跑到敢放手本地 AI 执行脚本的真实鸿沟很多人第一次看到本地大模型调用 shell 脚本、自动执行命令的时候兴奋点都集中在哇它真的能跑起来。我也不例外。早几个月我拿一台闲置的迷你主机搭了套本地推理环境接上命令行工具让它自己读需求、写脚本、执行、看输出、再修正。第一次跑通一个批量重命名并归档文件的任务时我盯着终端里滚动的日志确实有种这玩意儿要成精了的错觉。但兴奋劲过去之后我试着把一件真实的工作交给它——不是玩具任务而是那种我平时自己要做半小时、涉及多步骤、有中间判断、可能出错要回滚的活。结果呢它在前三步表现得很聪明第四步开始自作主张第五步把一个不该动的目录给改了第六步报错之后陷入了无限重试。我坐在旁边全程盯着手一直悬在键盘上准备随时 CtrlC。那一刻我意识到一个很尴尬的事实它能写脚本、能跑命令但它离无人值守还差着十万八千里。这个差距不是模型智商的问题。现在本地能跑的模型写个 for 循环、拼个 git 命令、解析一下 JSON 输出基本都没问题。真正的鸿沟在于无人值守意味着你要把判断权和执行权同时交出去而这两件事在真实环境里充满了模糊地带。模型不知道哪个目录是绝对不能碰的不知道某个命令返回非零退出码到底算失败还是算正常不知道一个操作跑多久算超时、超时之后该重试还是该放弃更不知道当它自己拿不准的时候应该停下来问人还是硬着头皮往下走。我后来把这段时间踩过的坑做了个复盘发现卡点其实高度集中在五个地方。这五个卡点不是理论推演出来的是我一次次放手—翻车—收手—再放手循环里实打实撞出来的。下面我把每一个都拆开讲包括它为什么会成为卡点、我当时是怎么误判的、以及后来用什么办法绕过去或者至少缓解掉。如果你也在折腾本地 AI 自动化执行这条线这些内容应该能帮你少走不少弯路。需要先说明一点我这里说的无人值守指的是你启动一个任务之后可以去干别的事中途不需要盯着出问题了它能自己处理或者至少安全地停下来而不是把系统跑崩、把数据搞乱。这个标准其实挺高的比能自动跑完一个 happy path要高得多。2. 卡点一权限边界模糊AI 分不清能碰和不能碰2.1 为什么模型天生缺乏禁区意识这是我认为最致命、也最容易被低估的一个卡点。你给一个本地 AI 配上执行命令的能力它看待文件系统的视角是平的——在它眼里/home/user/project/和/etc/和~/.ssh/没有本质区别都是路径字符串。它不会因为某个目录叫system32就本能地绕开也不会因为某个文件是配置文件就格外小心。这跟人类操作员的直觉完全不一样。我们自己敲命令的时候手在rm -rf后面会本能地停顿一下脑子里过一遍这个路径对不对。这种停顿来自多年的肌肉记忆和恐惧记忆。模型没有这种记忆它只有概率——而概率在涉及破坏性操作时恰恰是最不可靠的东西。我踩过的第一个大坑就是权限。当时我让 AI 帮我清理一个测试项目里的临时文件需求描述里写了清理构建产物。它写出来的脚本逻辑上没错但它把匹配范围放得太宽find的路径写成了项目根目录的上一级。幸好我那次是盯着跑的在它执行前扫了一眼命令及时拦下来了。如果当时是无人值守状态上一级目录里我另一个项目的源码可能就没了。2.2 用白名单 沙箱把边界焊死后来我总结出来的做法是永远不要指望模型自己判断边界边界必须由外层框架强制施加。具体分两层。第一层是路径白名单。我在调度层维护一个允许操作的根目录列表AI 生成的任何涉及文件读写的命令在执行前都要过一遍路径校验。校验逻辑很简单把命令里出现的所有绝对路径提取出来逐个判断是否落在白名单目录内只要有一个越界直接拒绝执行并把原因返回给模型。这一步用正则加路径规范化就能做不需要多复杂。第二层是执行沙箱。对于确实需要一定自由度的任务我会把它放进一个受限环境里跑比如用容器或者受限用户身份。这样即使模型写出了越界命令实际影响范围也被物理隔离了。沙箱里可以给它一个看起来像完整文件系统的视图但真实主机上的敏感目录根本不在它的可见范围内。提示路径校验一定要做规范化处理。../这种相对路径、软链接、大小写差异都是绕过朴素字符串匹配的常见方式。我一开始只做了字符串前缀匹配结果被一个foo/../../etc给绕过去了后来老老实实用了路径解析库。2.3 破坏性命令的二次确认机制除了路径还有一类命令本身就需要额外警惕比如删除、覆盖、格式化、批量修改权限。我的做法是维护一个高危命令模式清单命中清单的命令不直接执行而是走一个二次确认流程。这个确认流程在无人值守场景下怎么设计总不能弹个框等人点。我的方案是分级低危操作直接放行中危操作记录详细日志后放行但保留完整回滚信息高危操作直接阻断把任务挂起标记为需要人工介入然后通过通知渠道告诉我。这样既保证了无人值守的连续性又不会让高危操作在没人看着的时候悄悄执行。这里有个经验回滚信息的记录要在执行前做不是执行后。我吃过亏有一次让 AI 批量修改文件它改到一半报错了我想回滚结果发现它没记录原始内容只能从备份里翻。后来我强制要求任何写操作执行前先把目标文件的原始状态快照下来存到一个独立的、AI 无权访问的目录里。这样即使 AI 把现场搞乱了我还能还原。3. 卡点二错误语义缺失退出码不等于成功/失败3.1 模型对非零退出码的粗暴理解第二个卡点特别隐蔽因为它平时不发作一发作就让你怀疑人生。问题出在退出码上。在命令行世界里退出码 0 通常代表成功非 0 代表某种失败。模型学到这个规律之后就会简单粗暴地认为退出码非 0 出错了 需要重试或者修正。但真实世界的命令根本不是这么回事。grep没匹配到内容返回 1这算失败吗在很多场景下这是完全正常的结果。diff发现文件有差异返回 1这是它的正常工作方式。有些命令返回 2 表示用法错误返回 1 表示业务层面的没找到返回 0 才是真的成功。还有的命令退出码含义完全自定义你不看文档根本猜不到。我遇到过一次典型翻车让 AI 跑一个检查任务它调用了一个工具命令那个命令在检查通过时返回 0检查发现问题时返回 1。AI 看到返回 1判定为执行失败于是开始重试。重试还是返回 1它继续重试陷入了死循环。实际上那个返回 1 恰恰是它应该报告的结果。它把业务结果和执行状态混为一谈了。3.2 给每个命令建立语义档案解决这个问题的核心思路是不要让模型自己去猜退出码的含义而是提前给每个会用到的命令建立语义档案。我在调度层维护了一张表记录每个命令的退出码含义、正常输出模式、异常输出模式。命令退出码 0退出码 1退出码 2特殊说明grep匹配到内容未匹配到用法错误1 是正常业务结果diff无差异有差异错误1 是正常业务结果test条件为真条件为假参数错误1 是正常业务结果curl请求完成协议错误用法错误需结合 HTTP 状态码判断自定义脚本成功业务失败参数错误需看脚本文档有了这张表AI 在判断执行结果时就有据可依而不是靠通用直觉。对于表里没有的命令我会让它先跑一次--help或者看文档把退出码含义搞清楚再纳入档案。3.3 区分执行失败和业务否定更深一层的问题是即使退出码含义搞清楚了还要区分执行失败和业务否定这两种情况因为它们对应的处理策略完全不同。执行失败比如命令不存在、权限不足、网络超时通常意味着环境有问题重试可能有用或者需要换个方式执行。业务否定比如检查未通过、条件不满足意味着任务正常推进到了某个判断点结果是否这时候应该按业务逻辑走下一步而不是重试。我在调度逻辑里把这两类明确分开执行失败走重试/降级/上报流程业务否定走正常的分支流程。这个区分看起来简单但如果不显式做模型很容易把两者混在一起导致该停的时候在重试该重试的时候却停了。注意有些命令的退出码在不同版本之间会变。我遇到过升级工具之后退出码含义变了导致原本正常的判断逻辑失效。所以语义档案要跟版本绑定升级依赖之后记得回归验证。4. 卡点三状态丢失多步任务跑到一半失忆4.1 无状态执行的天然缺陷第三个卡点跟任务的长度有关。短任务比如把这个目录下的图片批量转格式AI 一口气跑完没问题。但真实工作往往是多步的、有依赖的、需要记住中间结果的。这时候问题就来了模型每次调用之间是相对独立的它不像人一样有持续的工作记忆。我做过一个稍微复杂点的任务从一堆日志里提取错误信息归类然后针对每类错误生成修复建议最后把建议写成报告。这个任务涉及读取、解析、分类、生成、汇总五个阶段。AI 在前两个阶段表现很好到第三个阶段开始忘事——它忘了前面提取出来的错误信息具体长什么样开始凭印象编。到第四个阶段它生成的修复建议跟实际错误对不上号。最后报告是写出来了但内容基本不可信。这个问题的本质是多步任务需要显式的状态管理而模型自己不会主动做这件事。它倾向于把每一步都当成独立任务来处理前面步骤的细节在上下文里逐渐被稀释、被覆盖。4.2 用外部状态文件做任务记忆我的解决方案是把状态从模型脑子里挪出来放到外部文件里。每完成一步就把这一步的输入、输出、关键决策写进一个结构化的状态文件。下一步开始前先把状态文件读进来作为上下文的一部分。这个状态文件我一般用 JSON 或者 YAML结构大概是这样任务 ID、当前阶段、已完成步骤列表、每步的输入输出摘要、待处理项、已知问题。关键是摘要要足够精炼但信息完整不能把原始数据全塞进去上下文放不下也不能太简略丢了关键信息。实际操作中我会让 AI 在每步结束时自己生成这个状态更新但生成之后我会做一次校验——检查必填字段在不在、格式对不对、关键信息有没有丢。校验通过才写入不通过就打回让它重写。这一步看起来繁琐但能极大降低跑着跑着失忆的概率。4.3 断点续跑让任务可以从任意一步恢复状态外置还有一个额外好处断点续跑。任务跑到一半因为各种原因中断了超时、报错、我手动停了下次可以从上次的状态继续而不是从头再来。我实现的方式是给每个步骤打上已完成标记续跑时从第一个未完成的步骤开始。这里要注意的是幂等性——同一个步骤重复执行不能产生副作用。比如追加一行到文件这种操作就不幂等重复跑会多出一行。对于不幂等的步骤我会在状态里记录它是否已经执行过续跑时跳过。有一次我因为没处理好幂等性续跑之后同一个文件被追加了两次内容导致后续解析全乱了。从那以后我定了个规矩任何有副作用的步骤执行前先检查状态标记执行后立即更新标记中间不留空窗。这个规矩救了我好几次。5. 卡点四超时与重试策略模型自己拿捏不准5.1 无限重试最容易被忽视的失控第四个卡点是我觉得最阴险的因为它不会立刻暴露而是慢慢把资源耗光。模型在面对失败时的默认行为是重试这本身没错但它对重试多少次间隔多久什么条件下该放弃完全没有概念。我遇到过一次某个网络请求因为目标服务临时不可用一直失败AI 就一直在重试间隔还特别短几乎是不停地打。跑了十几分钟把本地资源占满了日志刷了几万行任务本身一点进展没有。等我发现的时候它还在那儿锲而不舍地重试。这种勤奋在无人值守场景下是灾难。5.2 分级重试不同错误不同对待后来我设计了一套分级重试策略核心思想是根据错误类型决定重试行为而不是一刀切。错误类型重试策略间隔上限放弃后动作瞬时错误超时、连接重置指数退避重试1s, 2s, 4s, 8s5 次上报并挂起资源错误磁盘满、内存不足不重试--立即上报逻辑错误参数错、路径不存在不重试--返回给模型修正业务否定检查未通过不重试--走正常分支未知错误有限重试固定 5s3 次上报并挂起指数退避是关键。瞬时错误往往是因为对端短暂抖动短间隔重试大概率还是失败反而加重对端负担。指数退避给它恢复时间成功率明显更高。5.3 超时设置给每个操作一个死线除了重试次数超时时间也得显式设置。模型执行命令时默认会一直等直到命令自己结束。但有些命令可能永远不结束比如等待输入的交互式命令有些命令可能跑得比预期慢很多。没有超时任务就可能永远卡在那里。我给每类操作都设了超时文件操作 30 秒网络请求 60 秒脚本执行 5 分钟长任务单独配置。超时之后不是简单杀掉而是先尝试优雅终止发信号让它自己清理等几秒还没退再强制杀掉。杀掉之后记录现场作为失败处理。提示超时时间不要设得太紧。我一开始为了快速失败把超时设得很短结果一些正常但稍慢的操作被误杀反而增加了失败率。后来我改成先宽松观察一段时间根据实际耗时分布再收紧效果好很多。6. 卡点五异常兜底缺失出错之后没人收场6.1 报错即停止不等于安全最后一个卡点也是最容易被能跑通的假象掩盖的异常兜底。很多人觉得只要让 AI 在出错时停下来就行了停下来就安全了。但实际情况是停下来只是第一步停下来之后现场是什么状态、有没有留下烂摊子、下次能不能恢复这些才是关键。我遇到过 AI 执行到一半报错停止结果留下了一堆半成品文件、一个被锁住的资源、一个处于中间状态的数据库。这些残留物如果不清理下次任务跑起来会撞上它们产生更奇怪的问题。更糟的是有些残留物会伪装成正常状态让后续判断出错。6.2 每个任务都要有清理钩子我的做法是给每个任务定义清理钩子cleanup hook。不管任务是正常结束、异常结束还是被强制终止清理钩子都会被执行。它负责释放资源、删除临时文件、解锁、把状态标记为已终止。清理钩子的设计要点是它自己必须足够健壮不能因为清理过程出错而影响主流程。我一般把清理逻辑写得非常保守只做确定安全的操作遇到不确定的情况就跳过并记录绝不冒险。清理钩子本身出错的话记录日志但不抛出避免掩盖原始错误。6.3 失败也要有可读的失败还有一个细节失败信息要让人能看懂。模型报错的时候经常抛出一大堆堆栈或者原始错误码人看了半天不知道发生了什么。我会在兜底层做一次错误翻译把技术错误转换成哪个步骤失败了、可能的原因是什么、建议怎么处理这样的自然语言描述。这个翻译不需要多精确但要有用。比如命令返回 127翻译成命令未找到可能是依赖没装或者路径不对连接超时翻译成目标服务无响应可能是服务没启动或者网络不通。有了这个我收到告警的时候能快速判断要不要介入而不是对着一堆天书发呆。6.4 兜底不是终点是下一次的起点最后我想强调一个心态上的转变。异常兜底不是为了让任务永远不失败那不可能。它是为了让失败变得可控、可恢复、可学习。每次失败之后我会把失败原因、处理过程、改进措施记录下来定期回顾。很多卡点就是这样一个个被磨掉的。我现在的本地 AI 执行环境离真正的无人值守还有距离但至少做到了跑的时候我敢去泡杯咖啡出问题的时候它不会把系统搞崩失败之后我能快速定位和恢复。这个状态对我来说已经很有用了。如果你也在往这个方向走建议不要追求一步到位先把这五个卡点一个个处理掉每处理一个你能放手的时间就长一点。7. 把五个卡点串起来我的调度层长什么样讲了五个卡点可能有点散。我把它们串一下说说我现在的调度层大概是怎么组织的这样你能看到这些卡点是怎么被系统性地处理的。整个调度层分四块。第一块是准入控制负责路径白名单校验、高危命令拦截、权限检查对应卡点一。第二块是执行引擎负责命令语义档案查询、退出码解释、超时控制、分级重试对应卡点二和卡点四。第三块是状态管理负责任务状态外置、断点续跑、幂等性保证对应卡点三。第四块是兜底与清理负责异常捕获、清理钩子、错误翻译、告警上报对应卡点五。这四块之间通过一个统一的任务上下文传递信息。任务上下文里包含任务 ID、当前阶段、状态文件路径、允许的路径范围、超时配置、重试配置等。每一块在执行时都从上下文里读配置执行完把结果写回上下文。这样整个流程是连贯的不会出现这块不知道那块在干什么的情况。这套东西搭起来花了我不少时间但搭好之后我跑任务的信心完全不一样了。以前是试试看盯着点现在是交给它有事它会叫我。这个转变本身就是从能跑到敢放手的关键。如果你刚开始搞这块我的建议是不要一上来就追求大而全。先把路径白名单和超时这两个最基础的做上这两个能挡掉大部分灾难性事故。然后再逐步加状态管理和重试策略。兜底和清理可以最后做但一定要做不能省。8. 几个我反复踩、反复改的细节最后分享几个具体的、容易忽略的细节都是我自己反复踩过才记住的。第一个是日志的粒度。日志太粗出问题查不到细节日志太细刷屏刷到没法看。我的经验是按阶段分日志级别正常流程记 INFO关键决策记 WARN异常记 ERROR调试细节记 DEBUG 且默认关闭。这样平时看 INFO 和 WARN 就够了出问题再开 DEBUG。第二个是环境变量的污染。AI 执行命令时的环境变量可能跟你在终端里手动执行时不一样导致同样的命令行为不同。我后来强制在调度层显式设置关键环境变量不依赖继承避免这种在我机器上好好的问题。第三个是并发任务的资源竞争。如果你同时跑多个 AI 任务它们可能抢同一个文件、同一个端口、同一个锁。我现在的做法是给每个任务分配独立的临时目录和资源命名空间需要共享的资源走显式加锁。这个不做的话偶发的诡异错误能查到你怀疑人生。第四个是模型输出的不确定性。同一个任务模型两次生成的脚本可能不一样。这在调试时特别坑你以为改好了其实只是这次运气好。我的应对是关键步骤的脚本生成之后先做静态检查语法、危险模式再在沙箱里试跑通过了才正式执行。多这一道稳定性提升很明显。这些细节单看都不大但叠在一起就是能跑和敢放手之间的差距。无人值守不是一个开关是一堆细节堆出来的状态。每解决一个卡点你就离它近一步。
本地AI执行脚本无人值守的五大卡点与工程化解决方案
1. 从能跑到敢放手本地 AI 执行脚本的真实鸿沟很多人第一次看到本地大模型调用 shell 脚本、自动执行命令的时候兴奋点都集中在哇它真的能跑起来。我也不例外。早几个月我拿一台闲置的迷你主机搭了套本地推理环境接上命令行工具让它自己读需求、写脚本、执行、看输出、再修正。第一次跑通一个批量重命名并归档文件的任务时我盯着终端里滚动的日志确实有种这玩意儿要成精了的错觉。但兴奋劲过去之后我试着把一件真实的工作交给它——不是玩具任务而是那种我平时自己要做半小时、涉及多步骤、有中间判断、可能出错要回滚的活。结果呢它在前三步表现得很聪明第四步开始自作主张第五步把一个不该动的目录给改了第六步报错之后陷入了无限重试。我坐在旁边全程盯着手一直悬在键盘上准备随时 CtrlC。那一刻我意识到一个很尴尬的事实它能写脚本、能跑命令但它离无人值守还差着十万八千里。这个差距不是模型智商的问题。现在本地能跑的模型写个 for 循环、拼个 git 命令、解析一下 JSON 输出基本都没问题。真正的鸿沟在于无人值守意味着你要把判断权和执行权同时交出去而这两件事在真实环境里充满了模糊地带。模型不知道哪个目录是绝对不能碰的不知道某个命令返回非零退出码到底算失败还是算正常不知道一个操作跑多久算超时、超时之后该重试还是该放弃更不知道当它自己拿不准的时候应该停下来问人还是硬着头皮往下走。我后来把这段时间踩过的坑做了个复盘发现卡点其实高度集中在五个地方。这五个卡点不是理论推演出来的是我一次次放手—翻车—收手—再放手循环里实打实撞出来的。下面我把每一个都拆开讲包括它为什么会成为卡点、我当时是怎么误判的、以及后来用什么办法绕过去或者至少缓解掉。如果你也在折腾本地 AI 自动化执行这条线这些内容应该能帮你少走不少弯路。需要先说明一点我这里说的无人值守指的是你启动一个任务之后可以去干别的事中途不需要盯着出问题了它能自己处理或者至少安全地停下来而不是把系统跑崩、把数据搞乱。这个标准其实挺高的比能自动跑完一个 happy path要高得多。2. 卡点一权限边界模糊AI 分不清能碰和不能碰2.1 为什么模型天生缺乏禁区意识这是我认为最致命、也最容易被低估的一个卡点。你给一个本地 AI 配上执行命令的能力它看待文件系统的视角是平的——在它眼里/home/user/project/和/etc/和~/.ssh/没有本质区别都是路径字符串。它不会因为某个目录叫system32就本能地绕开也不会因为某个文件是配置文件就格外小心。这跟人类操作员的直觉完全不一样。我们自己敲命令的时候手在rm -rf后面会本能地停顿一下脑子里过一遍这个路径对不对。这种停顿来自多年的肌肉记忆和恐惧记忆。模型没有这种记忆它只有概率——而概率在涉及破坏性操作时恰恰是最不可靠的东西。我踩过的第一个大坑就是权限。当时我让 AI 帮我清理一个测试项目里的临时文件需求描述里写了清理构建产物。它写出来的脚本逻辑上没错但它把匹配范围放得太宽find的路径写成了项目根目录的上一级。幸好我那次是盯着跑的在它执行前扫了一眼命令及时拦下来了。如果当时是无人值守状态上一级目录里我另一个项目的源码可能就没了。2.2 用白名单 沙箱把边界焊死后来我总结出来的做法是永远不要指望模型自己判断边界边界必须由外层框架强制施加。具体分两层。第一层是路径白名单。我在调度层维护一个允许操作的根目录列表AI 生成的任何涉及文件读写的命令在执行前都要过一遍路径校验。校验逻辑很简单把命令里出现的所有绝对路径提取出来逐个判断是否落在白名单目录内只要有一个越界直接拒绝执行并把原因返回给模型。这一步用正则加路径规范化就能做不需要多复杂。第二层是执行沙箱。对于确实需要一定自由度的任务我会把它放进一个受限环境里跑比如用容器或者受限用户身份。这样即使模型写出了越界命令实际影响范围也被物理隔离了。沙箱里可以给它一个看起来像完整文件系统的视图但真实主机上的敏感目录根本不在它的可见范围内。提示路径校验一定要做规范化处理。../这种相对路径、软链接、大小写差异都是绕过朴素字符串匹配的常见方式。我一开始只做了字符串前缀匹配结果被一个foo/../../etc给绕过去了后来老老实实用了路径解析库。2.3 破坏性命令的二次确认机制除了路径还有一类命令本身就需要额外警惕比如删除、覆盖、格式化、批量修改权限。我的做法是维护一个高危命令模式清单命中清单的命令不直接执行而是走一个二次确认流程。这个确认流程在无人值守场景下怎么设计总不能弹个框等人点。我的方案是分级低危操作直接放行中危操作记录详细日志后放行但保留完整回滚信息高危操作直接阻断把任务挂起标记为需要人工介入然后通过通知渠道告诉我。这样既保证了无人值守的连续性又不会让高危操作在没人看着的时候悄悄执行。这里有个经验回滚信息的记录要在执行前做不是执行后。我吃过亏有一次让 AI 批量修改文件它改到一半报错了我想回滚结果发现它没记录原始内容只能从备份里翻。后来我强制要求任何写操作执行前先把目标文件的原始状态快照下来存到一个独立的、AI 无权访问的目录里。这样即使 AI 把现场搞乱了我还能还原。3. 卡点二错误语义缺失退出码不等于成功/失败3.1 模型对非零退出码的粗暴理解第二个卡点特别隐蔽因为它平时不发作一发作就让你怀疑人生。问题出在退出码上。在命令行世界里退出码 0 通常代表成功非 0 代表某种失败。模型学到这个规律之后就会简单粗暴地认为退出码非 0 出错了 需要重试或者修正。但真实世界的命令根本不是这么回事。grep没匹配到内容返回 1这算失败吗在很多场景下这是完全正常的结果。diff发现文件有差异返回 1这是它的正常工作方式。有些命令返回 2 表示用法错误返回 1 表示业务层面的没找到返回 0 才是真的成功。还有的命令退出码含义完全自定义你不看文档根本猜不到。我遇到过一次典型翻车让 AI 跑一个检查任务它调用了一个工具命令那个命令在检查通过时返回 0检查发现问题时返回 1。AI 看到返回 1判定为执行失败于是开始重试。重试还是返回 1它继续重试陷入了死循环。实际上那个返回 1 恰恰是它应该报告的结果。它把业务结果和执行状态混为一谈了。3.2 给每个命令建立语义档案解决这个问题的核心思路是不要让模型自己去猜退出码的含义而是提前给每个会用到的命令建立语义档案。我在调度层维护了一张表记录每个命令的退出码含义、正常输出模式、异常输出模式。命令退出码 0退出码 1退出码 2特殊说明grep匹配到内容未匹配到用法错误1 是正常业务结果diff无差异有差异错误1 是正常业务结果test条件为真条件为假参数错误1 是正常业务结果curl请求完成协议错误用法错误需结合 HTTP 状态码判断自定义脚本成功业务失败参数错误需看脚本文档有了这张表AI 在判断执行结果时就有据可依而不是靠通用直觉。对于表里没有的命令我会让它先跑一次--help或者看文档把退出码含义搞清楚再纳入档案。3.3 区分执行失败和业务否定更深一层的问题是即使退出码含义搞清楚了还要区分执行失败和业务否定这两种情况因为它们对应的处理策略完全不同。执行失败比如命令不存在、权限不足、网络超时通常意味着环境有问题重试可能有用或者需要换个方式执行。业务否定比如检查未通过、条件不满足意味着任务正常推进到了某个判断点结果是否这时候应该按业务逻辑走下一步而不是重试。我在调度逻辑里把这两类明确分开执行失败走重试/降级/上报流程业务否定走正常的分支流程。这个区分看起来简单但如果不显式做模型很容易把两者混在一起导致该停的时候在重试该重试的时候却停了。注意有些命令的退出码在不同版本之间会变。我遇到过升级工具之后退出码含义变了导致原本正常的判断逻辑失效。所以语义档案要跟版本绑定升级依赖之后记得回归验证。4. 卡点三状态丢失多步任务跑到一半失忆4.1 无状态执行的天然缺陷第三个卡点跟任务的长度有关。短任务比如把这个目录下的图片批量转格式AI 一口气跑完没问题。但真实工作往往是多步的、有依赖的、需要记住中间结果的。这时候问题就来了模型每次调用之间是相对独立的它不像人一样有持续的工作记忆。我做过一个稍微复杂点的任务从一堆日志里提取错误信息归类然后针对每类错误生成修复建议最后把建议写成报告。这个任务涉及读取、解析、分类、生成、汇总五个阶段。AI 在前两个阶段表现很好到第三个阶段开始忘事——它忘了前面提取出来的错误信息具体长什么样开始凭印象编。到第四个阶段它生成的修复建议跟实际错误对不上号。最后报告是写出来了但内容基本不可信。这个问题的本质是多步任务需要显式的状态管理而模型自己不会主动做这件事。它倾向于把每一步都当成独立任务来处理前面步骤的细节在上下文里逐渐被稀释、被覆盖。4.2 用外部状态文件做任务记忆我的解决方案是把状态从模型脑子里挪出来放到外部文件里。每完成一步就把这一步的输入、输出、关键决策写进一个结构化的状态文件。下一步开始前先把状态文件读进来作为上下文的一部分。这个状态文件我一般用 JSON 或者 YAML结构大概是这样任务 ID、当前阶段、已完成步骤列表、每步的输入输出摘要、待处理项、已知问题。关键是摘要要足够精炼但信息完整不能把原始数据全塞进去上下文放不下也不能太简略丢了关键信息。实际操作中我会让 AI 在每步结束时自己生成这个状态更新但生成之后我会做一次校验——检查必填字段在不在、格式对不对、关键信息有没有丢。校验通过才写入不通过就打回让它重写。这一步看起来繁琐但能极大降低跑着跑着失忆的概率。4.3 断点续跑让任务可以从任意一步恢复状态外置还有一个额外好处断点续跑。任务跑到一半因为各种原因中断了超时、报错、我手动停了下次可以从上次的状态继续而不是从头再来。我实现的方式是给每个步骤打上已完成标记续跑时从第一个未完成的步骤开始。这里要注意的是幂等性——同一个步骤重复执行不能产生副作用。比如追加一行到文件这种操作就不幂等重复跑会多出一行。对于不幂等的步骤我会在状态里记录它是否已经执行过续跑时跳过。有一次我因为没处理好幂等性续跑之后同一个文件被追加了两次内容导致后续解析全乱了。从那以后我定了个规矩任何有副作用的步骤执行前先检查状态标记执行后立即更新标记中间不留空窗。这个规矩救了我好几次。5. 卡点四超时与重试策略模型自己拿捏不准5.1 无限重试最容易被忽视的失控第四个卡点是我觉得最阴险的因为它不会立刻暴露而是慢慢把资源耗光。模型在面对失败时的默认行为是重试这本身没错但它对重试多少次间隔多久什么条件下该放弃完全没有概念。我遇到过一次某个网络请求因为目标服务临时不可用一直失败AI 就一直在重试间隔还特别短几乎是不停地打。跑了十几分钟把本地资源占满了日志刷了几万行任务本身一点进展没有。等我发现的时候它还在那儿锲而不舍地重试。这种勤奋在无人值守场景下是灾难。5.2 分级重试不同错误不同对待后来我设计了一套分级重试策略核心思想是根据错误类型决定重试行为而不是一刀切。错误类型重试策略间隔上限放弃后动作瞬时错误超时、连接重置指数退避重试1s, 2s, 4s, 8s5 次上报并挂起资源错误磁盘满、内存不足不重试--立即上报逻辑错误参数错、路径不存在不重试--返回给模型修正业务否定检查未通过不重试--走正常分支未知错误有限重试固定 5s3 次上报并挂起指数退避是关键。瞬时错误往往是因为对端短暂抖动短间隔重试大概率还是失败反而加重对端负担。指数退避给它恢复时间成功率明显更高。5.3 超时设置给每个操作一个死线除了重试次数超时时间也得显式设置。模型执行命令时默认会一直等直到命令自己结束。但有些命令可能永远不结束比如等待输入的交互式命令有些命令可能跑得比预期慢很多。没有超时任务就可能永远卡在那里。我给每类操作都设了超时文件操作 30 秒网络请求 60 秒脚本执行 5 分钟长任务单独配置。超时之后不是简单杀掉而是先尝试优雅终止发信号让它自己清理等几秒还没退再强制杀掉。杀掉之后记录现场作为失败处理。提示超时时间不要设得太紧。我一开始为了快速失败把超时设得很短结果一些正常但稍慢的操作被误杀反而增加了失败率。后来我改成先宽松观察一段时间根据实际耗时分布再收紧效果好很多。6. 卡点五异常兜底缺失出错之后没人收场6.1 报错即停止不等于安全最后一个卡点也是最容易被能跑通的假象掩盖的异常兜底。很多人觉得只要让 AI 在出错时停下来就行了停下来就安全了。但实际情况是停下来只是第一步停下来之后现场是什么状态、有没有留下烂摊子、下次能不能恢复这些才是关键。我遇到过 AI 执行到一半报错停止结果留下了一堆半成品文件、一个被锁住的资源、一个处于中间状态的数据库。这些残留物如果不清理下次任务跑起来会撞上它们产生更奇怪的问题。更糟的是有些残留物会伪装成正常状态让后续判断出错。6.2 每个任务都要有清理钩子我的做法是给每个任务定义清理钩子cleanup hook。不管任务是正常结束、异常结束还是被强制终止清理钩子都会被执行。它负责释放资源、删除临时文件、解锁、把状态标记为已终止。清理钩子的设计要点是它自己必须足够健壮不能因为清理过程出错而影响主流程。我一般把清理逻辑写得非常保守只做确定安全的操作遇到不确定的情况就跳过并记录绝不冒险。清理钩子本身出错的话记录日志但不抛出避免掩盖原始错误。6.3 失败也要有可读的失败还有一个细节失败信息要让人能看懂。模型报错的时候经常抛出一大堆堆栈或者原始错误码人看了半天不知道发生了什么。我会在兜底层做一次错误翻译把技术错误转换成哪个步骤失败了、可能的原因是什么、建议怎么处理这样的自然语言描述。这个翻译不需要多精确但要有用。比如命令返回 127翻译成命令未找到可能是依赖没装或者路径不对连接超时翻译成目标服务无响应可能是服务没启动或者网络不通。有了这个我收到告警的时候能快速判断要不要介入而不是对着一堆天书发呆。6.4 兜底不是终点是下一次的起点最后我想强调一个心态上的转变。异常兜底不是为了让任务永远不失败那不可能。它是为了让失败变得可控、可恢复、可学习。每次失败之后我会把失败原因、处理过程、改进措施记录下来定期回顾。很多卡点就是这样一个个被磨掉的。我现在的本地 AI 执行环境离真正的无人值守还有距离但至少做到了跑的时候我敢去泡杯咖啡出问题的时候它不会把系统搞崩失败之后我能快速定位和恢复。这个状态对我来说已经很有用了。如果你也在往这个方向走建议不要追求一步到位先把这五个卡点一个个处理掉每处理一个你能放手的时间就长一点。7. 把五个卡点串起来我的调度层长什么样讲了五个卡点可能有点散。我把它们串一下说说我现在的调度层大概是怎么组织的这样你能看到这些卡点是怎么被系统性地处理的。整个调度层分四块。第一块是准入控制负责路径白名单校验、高危命令拦截、权限检查对应卡点一。第二块是执行引擎负责命令语义档案查询、退出码解释、超时控制、分级重试对应卡点二和卡点四。第三块是状态管理负责任务状态外置、断点续跑、幂等性保证对应卡点三。第四块是兜底与清理负责异常捕获、清理钩子、错误翻译、告警上报对应卡点五。这四块之间通过一个统一的任务上下文传递信息。任务上下文里包含任务 ID、当前阶段、状态文件路径、允许的路径范围、超时配置、重试配置等。每一块在执行时都从上下文里读配置执行完把结果写回上下文。这样整个流程是连贯的不会出现这块不知道那块在干什么的情况。这套东西搭起来花了我不少时间但搭好之后我跑任务的信心完全不一样了。以前是试试看盯着点现在是交给它有事它会叫我。这个转变本身就是从能跑到敢放手的关键。如果你刚开始搞这块我的建议是不要一上来就追求大而全。先把路径白名单和超时这两个最基础的做上这两个能挡掉大部分灾难性事故。然后再逐步加状态管理和重试策略。兜底和清理可以最后做但一定要做不能省。8. 几个我反复踩、反复改的细节最后分享几个具体的、容易忽略的细节都是我自己反复踩过才记住的。第一个是日志的粒度。日志太粗出问题查不到细节日志太细刷屏刷到没法看。我的经验是按阶段分日志级别正常流程记 INFO关键决策记 WARN异常记 ERROR调试细节记 DEBUG 且默认关闭。这样平时看 INFO 和 WARN 就够了出问题再开 DEBUG。第二个是环境变量的污染。AI 执行命令时的环境变量可能跟你在终端里手动执行时不一样导致同样的命令行为不同。我后来强制在调度层显式设置关键环境变量不依赖继承避免这种在我机器上好好的问题。第三个是并发任务的资源竞争。如果你同时跑多个 AI 任务它们可能抢同一个文件、同一个端口、同一个锁。我现在的做法是给每个任务分配独立的临时目录和资源命名空间需要共享的资源走显式加锁。这个不做的话偶发的诡异错误能查到你怀疑人生。第四个是模型输出的不确定性。同一个任务模型两次生成的脚本可能不一样。这在调试时特别坑你以为改好了其实只是这次运气好。我的应对是关键步骤的脚本生成之后先做静态检查语法、危险模式再在沙箱里试跑通过了才正式执行。多这一道稳定性提升很明显。这些细节单看都不大但叠在一起就是能跑和敢放手之间的差距。无人值守不是一个开关是一堆细节堆出来的状态。每解决一个卡点你就离它近一步。
