1. 为什么要在 Windows 上折腾 AI Agent 流水线先说一个我踩过的坑。去年冬天我在 Windows 上跑一个自动化的 AI Agent 脚本功能很简单读取本地文档、调用模型接口、把结果写回指定目录。在 macOS 上跑得好好的搬到 Windows 上直接炸了——路径分隔符不对、rm命令不存在、cp报cannot stat、vim打开文件全是乱码。折腾了整整一个下午最后发现问题的根源不是代码逻辑而是 Windows 和 Unix 两套体系在路径、命令、编码上的根本差异。这件事让我意识到一个被很多人忽略的事实AI Agent 的开发本身并不难难的是让它在一个“不友好”的操作系统上稳定跑起来。你去看那些 AI Agent 的教程和开源项目绝大多数默认你用的是 Linux 或 macOS命令行示例清一色是bash风格。而现实是大量开发者手里只有一台 Windows 电脑或者公司配的开发机就是 Windows。所以这个系列我打算把 Windows 上搭 AI Agent 流水线的完整过程拆开讲第一篇专门解决最基础也最烦人的问题路径、删除、命令怎么让它们全都不报错。这不是一篇“Windows 入门教程”而是一个实际跑通过流水线的人把那些文档里不会写的坑一个个填上。这篇文章适合谁看如果你正在 Windows 上尝试搭建 AI Agent或者准备从零开始做一个自动化流程又或者你已经被Git Bash的路径问题、rm命令的报错、vim的乱码折磨过那这篇内容就是写给你的。我会从环境选型讲到具体命令从原理讲到实操尽量让每个步骤都能直接抄作业。2. 环境选型Git Bash、WSL 2 还是原生 CMD2.1 三种方案的真实对比在 Windows 上跑 AI Agent第一件事就是决定用哪个终端环境。这不是一个随便选选的问题因为它直接决定了你后续所有命令的写法、路径的格式、以及遇到报错时的排查方向。我前后用过三种方案各有各的脾气。原生 CMD 和 PowerShell是最“Windows”的选择。优点是系统自带、启动快、和 Windows 生态无缝衔接。缺点是命令体系和 Unix 完全不同——ls变成dirrm变成delcp变成copy路径用反斜杠\。如果你写的 AI Agent 脚本里全是 Unix 命令在 CMD 里跑基本等于重写一遍。而且 PowerShell 虽然强大但它的语法和管道机制跟 bash 差异很大学习成本不低。WSL 2是在 Windows 里跑了一个真正的 Linux 内核。优点是完整的 Linux 体验所有 bash 命令、路径规则、包管理都和 Ubuntu 一模一样AI Agent 项目几乎可以零改动迁移。缺点是资源占用高、文件系统跨边界访问慢、有时候网络配置会出幺蛾子。我实测下来WSL 2 跑轻量级 Agent 没问题但如果你的流水线涉及大量文件读写跨/mnt/c/和 Linux 原生目录之间的操作会明显拖慢速度。Git Bash是我目前最推荐的折中方案。它随 Git for Windows 一起安装提供了一个模拟的 bash 环境支持大部分常用 Unix 命令路径可以用正斜杠/同时又能直接访问 Windows 的文件系统。它不像 WSL 2 那样吃资源又比 CMD 友好得多。对于 AI Agent 流水线这种“需要 Unix 命令但不需要完整 Linux 内核”的场景Git Bash 的性价比最高。方案命令兼容性路径格式资源占用适用场景CMD/PowerShell低反斜杠\极低纯 Windows 原生工具链WSL 2极高正斜杠/高完整 Linux 项目迁移Git Bash高正斜杠/低AI Agent 流水线首选2.2 Git Bash 安装与配置要点Git Bash 的安装本身不复杂去 Git for Windows 官网下载安装包一路下一步就行。但有几个配置项如果你不注意后面会反复踩坑。安装过程中会问你“Adjusting your PATH environment”默认选项是“Git from the command line and also from 3rd-party software”这个保持默认就好。它会把 Git 和 Git Bash 加到系统 PATH 里这样你在任何终端都能调用git命令。另一个关键选项是“Configuring the line ending conversions”。Windows 用CRLF换行Unix 用LF。如果你选错了脚本文件在跨平台传输时会出现诡异的执行错误。我的建议是选“Checkout as-is, commit Unix-style line endings”这样 Git 在提交时自动把换行符转成 Unix 风格检出时保持原样。对于 AI Agent 项目来说这个设置能避免很多“脚本在 Windows 上能跑、在服务器上报错”的问题。安装完成后打开 Git Bash第一件事是确认路径映射。Git Bash 里Windows 的C:\Users\你的用户名会被映射成/c/Users/你的用户名。这个映射规则是理解后续所有路径问题的钥匙。你可以用pwd命令看看当前目录用cd /c/试试能不能进到 C 盘根目录。提示Git Bash 的默认家目录是/c/Users/你的用户名但你可以通过修改~/.bashrc文件来调整。如果你希望每次打开 Git Bash 都自动进入项目目录在.bashrc末尾加一行cd /c/你的项目路径就行。2.3 为什么我不建议一上来就用 WSL 2很多人一听说 WSL 2 是“完整 Linux”就立刻投奔过去了。我一开始也是这么想的直到我发现三个问题。第一WSL 2 的文件系统是独立的。你在 WSL 里创建的 AI Agent 项目文件实际存储在虚拟磁盘里Windows 的资源管理器访问起来要通过\\wsl$\路径速度慢不说有时候还会出现权限问题。第二WSL 2 的网络是 NAT 模式如果你需要 Agent 监听某个端口供外部访问得额外配置端口转发。第三WSL 2 的启动速度虽然比 WSL 1 快但比起 Git Bash 还是慢不少每次打开都要等几秒。Git Bash 的优势在于“轻”。它就是一个终端模拟器加一套 Unix 工具集启动几乎瞬间完成文件直接存在 Windows 磁盘上网络就是 Windows 的网络。对于大多数 AI Agent 流水线来说你需要的只是“能跑 bash 命令”和“路径别报错”Git Bash 完全够用。等你真的遇到 Git Bash 解决不了的问题再上 WSL 2 也不迟。3. 路径问题从报错到根治的完整思路3.1 路径报错的三种典型表现路径问题是 Windows 上跑 AI Agent 最高频的报错来源没有之一。我总结下来它通常以三种形式出现。第一种是“No such file or directory”。你明明看到文件就在那里但命令就是找不到。这通常是因为路径分隔符用错了——在 Git Bash 里用了反斜杠\或者路径里包含了空格但没有加引号。比如cd C:\Users\my project会报错因为 Git Bash 把\当成转义字符而且空格把路径截断了。正确的写法是cd /c/Users/my project。第二种是“Permission denied”。这个在 AI Agent 写文件时特别常见。Windows 的权限体系和 Unix 不一样Git Bash 模拟的权限位有时候和实际文件系统对不上。如果你用chmod x给脚本加执行权限但文件在 NTFS 分区上这个权限可能不会真正生效。解决办法是尽量把项目放在用户目录下避免系统保护目录。第三种是“路径太长”。Windows 默认的路径长度限制是 260 个字符虽然现代 Windows 10 和 11 可以开启长路径支持但很多工具链还没适配。AI Agent 项目如果依赖层级很深比如node_modules里嵌套好几层很容易触发这个限制。我遇到过一次npm install到一半报错排查半天才发现是路径超长。3.2 Git Bash 路径映射规则详解要根治路径问题必须理解 Git Bash 的路径映射逻辑。它本质上是一个“翻译层”把你输入的 Unix 风格路径翻译成 Windows 能理解的路径。核心规则就一条Windows 的盘符X:\映射为/x/。比如C:\Users\test对应/c/Users/testD:\projects\agent对应/d/projects/agent。这个映射是双向的你在 Git Bash 里用/c/开头的路径Git Bash 会自动翻译给 Windows 系统调用。但有几个特殊情况需要注意。第一网络路径\\server\share在 Git Bash 里要写成//server/share。第二UNC 路径和盘符映射路径在 Git Bash 里的行为略有不同前者有时候会出现权限问题。第三如果你在脚本里硬编码了C:\这样的路径在 Git Bash 里执行时可能会被误解建议统一用/c/格式。还有一个隐藏的坑环境变量里的路径。Windows 的PATH环境变量是用分号;分隔的而且路径是反斜杠格式。Git Bash 在启动时会把这些转换成 Unix 风格但如果你在脚本里手动拼接路径比如export PATH$PATH:/c/new/path要注意不要混用两种格式。3.3 实操用pwd、cd、ls定位路径问题当你遇到路径报错时不要慌按下面这个流程一步步排查。第一步用pwd确认当前工作目录。很多时候你以为自己在某个目录实际上不是。比如你双击打开 Git Bash它默认在家目录而不是你上次离开的地方。第二步用ls看看目标文件到底在不在。如果ls能看到文件但你的命令说找不到那问题多半出在路径格式上。如果ls也看不到那就是目录不对。第三步用cd逐级进入目录观察哪一级开始报错。比如cd /c/Users成功cd /c/Users/test失败那说明test目录不存在或者权限有问题。第四步如果路径里有空格或特殊字符用引号包起来。Git Bash 对空格很敏感cd /c/Program Files会报错必须写成cd /c/Program Files。第五步用realpath命令把相对路径转成绝对路径确认最终解析结果。这个命令在排查符号链接和相对路径问题时特别有用。注意Git Bash 里cd命令不显示当前目录如果你习惯用cd后看提示符确认位置可能会不习惯。建议在.bashrc里加一行PS1\w $ 让提示符显示当前路径。3.4 路径问题速查表报错信息可能原因解决方法No such file or directory路径分隔符错误把\改成/No such file or directory路径含空格未加引号用双引号包裹路径Permission denied文件在系统保护目录移到用户目录下Permission denied执行权限未生效用bash script.sh代替./script.sh路径过长超过 260 字符限制开启长路径支持或缩短目录层级找不到命令PATH 未包含该目录检查echo $PATH并手动添加4. 删除操作rm命令在 Windows 上的正确姿势4.1 为什么rm在 Git Bash 里也会出问题rm是 Unix 里最常用的删除命令Git Bash 也提供了它。但你可能遇到这样的情况rm命令执行了没报错但文件还在或者rm -rf删了半天没反应又或者删完之后回收站里找不到文件却真的没了。这些问题的根源在于Git Bash 的rm和 Windows 的文件系统之间有一层“翻译”。Git Bash 的rm实际上调用的是它自带的coreutils里的rm实现这个实现通过 MSYS2 层和 Windows API 交互。大多数时候没问题但在处理只读文件、被占用文件、以及长路径文件时行为会和原生 Linux 有差异。另一个常见问题是rm删除的文件不进回收站。在 Windows 上你用资源管理器删除文件文件会进回收站后悔了还能恢复。但 Git Bash 的rm是直接删除绕过回收站。这意味着一旦删错基本没有挽回余地。我踩过一次坑rm -rf删了一个目录以为里面有备份结果发现备份也在那个目录里。4.2rm、rm -r、rm -rf的区别与风险这三个命令的差异值得单独拿出来讲清楚因为用错了后果很严重。rm file.txt删除单个文件。如果文件不存在会报No such file or directory。如果文件是只读的会提示是否删除需要输入y确认。rm -r dir/递归删除目录及其内容。-r是 recursive 的意思它会进入目录逐个删除里面的文件和子目录。如果目录里有只读文件同样会提示确认。rm -rf dir/强制递归删除不提示任何确认。-f是 force 的意思它会忽略不存在的文件、不提示只读文件、不报任何错误。这个命令在 AI Agent 流水线里很常用比如清理临时目录、重置工作空间。但它也是最危险的因为一旦路径写错比如rm -rf /或者rm -rf ~后果不堪设想。我的建议是在脚本里用rm -rf之前先用echo打印出要删除的路径确认无误后再执行。或者用rm -rf的“安全版”——先cd到目标目录的父目录再用相对路径删除避免绝对路径写错。4.3 安全删除的替代方案如果你对rm心有余悸或者你的 AI Agent 流水线需要“可恢复”的删除操作有几个替代方案可以考虑。用mv代替rm。把要删除的文件移动到一个临时目录比如mv file.txt /tmp/trash/。这样文件还在只是换了个位置后悔了还能移回来。等确认不需要了再统一清理/tmp/trash/。用trash命令。有些 Git Bash 发行版自带trash命令它会把文件移到回收站而不是直接删除。如果你的 Git Bash 没有这个命令可以通过包管理器安装或者写一个简单的脚本模拟。用 Windows 原生的del命令。在 Git Bash 里可以调用cmd //c del file.txt这样删除的文件会进回收站。注意路径要用 Windows 格式而且//c是 Git Bash 里调用 CMD 的写法。用 Python 脚本删除。如果你的 AI Agent 本身就是 Python 写的可以用send2trash库它跨平台支持回收站删除。安装pip install send2trash然后from send2trash import send2trash; send2trash(file.txt)。4.4 删除操作实操记录下面是我在一个 AI Agent 项目里实际用到的清理脚本功能是删除output/目录下超过 7 天的临时文件。#!/bin/bash # cleanup.sh - 清理超过7天的临时文件 TARGET_DIR/c/Users/myuser/agent/output DAYS7 # 先确认目录存在 if [ ! -d $TARGET_DIR ]; then echo 目录不存在: $TARGET_DIR exit 1 fi # 用 find 查找并删除 find $TARGET_DIR -type f -mtime $DAYS -print -delete echo 清理完成这个脚本有几个细节值得说。第一-print -delete会先打印文件名再删除方便你确认删了什么。第二-mtime 7表示修改时间超过 7 天。第三用find而不是rm通配符是因为find对路径的处理更稳健不容易因为空格或特殊字符出错。如果你要删除整个目录我建议用这个模式TARGET/c/Users/myuser/agent/temp if [ -d $TARGET ]; then echo 即将删除: $TARGET rm -rf $TARGET echo 已删除 else echo 目录不存在跳过 fi先判断目录是否存在再打印确认最后删除。这三步看起来啰嗦但能避免 90% 的误删事故。5. 命令兼容性那些在 Git Bash 里“水土不服”的命令5.1cp报cannot stat的排查方法cp: cannot stat 11.txt: no such file or directory这个报错我在热词里看到过自己也遇到过。它的字面意思是“找不到 11.txt 这个文件”但实际情况往往更复杂。最常见的原因是当前目录不对。你以为自己在项目根目录实际上在别的目录。用pwd确认一下用ls看看11.txt在不在。第二个原因是文件名有隐藏字符。比如从网页复制文件名时可能带上了不可见的 Unicode 字符。用ls -la看看文件名的实际字节或者用ls | cat -A显示不可见字符。第三个原因是路径大小写问题。Windows 文件系统不区分大小写但 Git Bash 的某些命令区分。如果文件实际叫11.TXT你写11.txt在某些情况下会找不到。第四个原因是文件在另一个盘符。比如你在/c/下操作但文件在/d/下相对路径自然找不到。排查流程很简单pwd确认位置ls确认文件存在ls -la确认文件名无隐藏字符然后用绝对路径重试。如果绝对路径能成功那就是相对路径的问题。5.2vim在 Git Bash 里的配置与乱码解决vim是 Git Bash 自带的编辑器但默认配置对中文用户不太友好。你可能遇到打开文件全是乱码、方向键变成 ABCD、或者退出时提示q无效。乱码问题的根源是编码不一致。Windows 默认用 GBK 编码而 Git Bash 和大多数 AI Agent 项目用 UTF-8。解决办法是在~/.vimrc里加几行配置set encodingutf-8 set fileencodingutf-8 set termencodingutf-8 set fileencodingsutf-8,gbk,gb2312,gb18030 set nu set ts4 set sw4这几行的作用是内部编码用 UTF-8文件编码用 UTF-8终端编码用 UTF-8打开文件时按 UTF-8、GBK、GB2312、GB18030 的顺序尝试解码。set nu显示行号set ts4和set sw4设置 Tab 为 4 个空格。方向键变 ABCD 的问题是因为vim在兼容模式下把方向键的转义序列当成了普通字符。解决办法是在.vimrc里加set nocompatible或者用vim -N启动。如果你不习惯vimGit Bash 也自带nano操作更简单。或者你可以用 VS Code 的集成终端直接调用 Git Bash编辑文件用 VS Code 的图形界面。5.3 其他常用命令的 Windows 适配除了cp和vim还有几个命令在 Git Bash 里需要特别注意。ln -s创建符号链接。在 Windows 上创建符号链接需要管理员权限而且 NTFS 的符号链接和 Unix 的行为不完全一样。如果你在脚本里用了ln -s建议改成cp或者用 Windows 的mklink命令。chmod修改权限。前面提过Git Bash 的chmod在 NTFS 上可能不生效。如果你需要让脚本可执行用bash script.sh而不是./script.sh。ps和kill进程管理。Git Bash 的ps只显示 Git Bash 内部的进程看不到 Windows 的系统进程。要查看所有进程用tasklist要杀进程用taskkill //PID 进程号 //F。telnet测试端口。Windows 默认没装telnet客户端需要在“启用或关闭 Windows 功能”里手动开启。或者用curl代替curl -v telnet://localhost:8080。type查看命令类型。在 Git Bash 里type命令可以告诉你一个命令是内置的、别名的、还是外部程序。比如type ls会显示ls is aliased to ls --colorauto。5.4 命令兼容性速查表命令Git Bash 表现替代方案cp基本可用注意路径格式用绝对路径或引号包裹vim需配置编码配置.vimrc或用nanoln -s需管理员权限用cp或mklinkchmodNTFS 上可能不生效用bash script.shps只显示 Git Bash 进程用tasklistkill只能杀 Git Bash 进程用taskkill //PID //Ftelnet默认未安装用curl -v telnet://6. 常见问题与排查技巧实录6.1 脚本执行报错的排查思路AI Agent 流水线通常由多个脚本串联而成一个脚本报错整个流水线就断了。我总结了一套排查思路按顺序执行基本能定位到问题。第一步看报错信息的最后一行。Unix 命令的报错通常是“最后一行最重要”前面的输出可能是正常的日志。比如cp: cannot stat 11.txt关键就是cannot stat和文件名。第二步确认脚本的执行环境。你是在 Git Bash 里直接跑还是在 CMD 里调用bash script.sh不同的环境路径解析规则不同。建议统一在 Git Bash 里执行。第三步加-x参数调试。bash -x script.sh会打印每一行执行的命令和参数你能清楚看到是哪一行出了问题以及当时的变量值是什么。第四步检查文件编码和换行符。如果脚本是在 Windows 上编辑的可能带了CRLF换行符导致bash解析出错。用file script.sh查看如果是CRLF用dos2unix script.sh转换。第五步检查依赖命令是否存在。which 命令名可以确认命令是否在 PATH 里。如果不存在需要安装或手动指定路径。6.2 路径含空格和中文的处理路径里有空格是 Windows 用户的“家常便饭”。C:\Program Files、C:\Users\My Name这些路径在 Git Bash 里如果不加引号会被拆成多个参数。处理原则很简单只要路径里有空格或特殊字符就用双引号包起来。比如cd /c/Program Files、cp source file.txt dest file.txt。中文路径的问题更隐蔽。Git Bash 默认用 UTF-8 编码但 Windows 的文件系统 API 可能用 UTF-16。大多数情况下 Git Bash 能正确处理中文路径但如果遇到乱码或找不到文件可以尝试用cd逐级进入或者用ls确认文件名的实际编码。如果中文路径问题频繁出现一个彻底的解决办法是项目路径全部用英文。把项目放在/c/Users/yourname/projects/agent这样的纯英文路径下能避免 99% 的编码问题。6.3 权限问题的典型场景Git Bash 在 Windows 上遇到的权限问题通常有三种场景。第一种是写入系统目录。比如你想把 Agent 的日志写到C:\Windows\System32这需要管理员权限。解决办法是写到用户目录比如~/agent/logs/。第二种是执行脚本。你写了一个run.sh用./run.sh执行报Permission denied。这是因为 NTFS 没有 Unix 的可执行位。解决办法是用bash run.sh或者用chmod x run.sh试试有时候有效。第三种是访问其他用户的文件。如果 Agent 需要读取另一个用户目录下的文件可能会被拒绝。解决办法是把文件复制到当前用户可访问的目录或者调整文件权限。6.4 常见问题速查表问题现象排查步骤解决方案脚本报错但看不出原因用bash -x调试查看具体出错行和变量值文件找不到pwdlsrealpath确认路径和文件名路径含空格报错检查是否加引号用双引号包裹路径中文路径乱码ls查看实际文件名改用英文路径权限拒绝确认文件位置和权限移到用户目录或用bash执行命令不存在which检查安装或指定完整路径换行符导致脚本失败file查看用dos2unix转换6.5 我踩过的三个坑第一个坑是在 CMD 里跑 bash 脚本。我以为装了 Git BashCMD 就能直接跑.sh文件结果报了一堆错。后来才明白.sh文件必须在 bash 环境里执行要么打开 Git Bash要么用bash script.sh。第二个坑是用rm -rf删了不该删的目录。当时我想清理temp/结果路径写成了/c/Users/myuser/agent/temp但实际项目在/d/agent/temp。rm -rf没报错因为/c/Users/myuser/agent/temp不存在-f忽略了错误。等我发现删错的时候已经晚了。从那以后我养成了“先echo再rm”的习惯。第三个坑是vim编辑后文件多了^M。这是因为vim在 Windows 上默认用CRLF保存而 AI Agent 的 Python 脚本对换行符敏感。解决办法是在.vimrc里加set fileformatunix强制用 Unix 换行符保存。7. 把流水线跑通的关键习惯7.1 统一路径风格在 Windows 上搭 AI Agent 流水线最有效的习惯是统一用 Git Bash 的路径风格。所有脚本、配置、命令路径一律用/c/、/d/开头一律用正斜杠/。不要混用C:\和/c/不要一会儿反斜杠一会儿正斜杠。这个习惯的好处是你的脚本在 Git Bash 里能跑在 WSL 2 里也能跑在 Linux 服务器上稍微改改也能跑。如果你混用两种风格脚本就只能在特定环境里跑迁移成本很高。具体做法在项目根目录放一个env.sh定义所有路径变量export PROJECT_ROOT/c/Users/myuser/projects/agent export DATA_DIR$PROJECT_ROOT/data export OUTPUT_DIR$PROJECT_ROOT/output export LOG_DIR$PROJECT_ROOT/logs其他脚本source env.sh后直接用变量不写死路径。这样换电脑或换目录时只改env.sh一个文件就行。7.2 脚本开头加set -eset -e是 bash 的一个选项意思是“遇到错误立即退出”。默认情况下bash 脚本里某一行报错会继续执行下一行这可能导致错误累积最后排查起来很麻烦。在 AI Agent 流水线里我建议每个脚本开头都加#!/bin/bash set -e set -u set -o pipefailset -e遇到错误退出set -u使用未定义变量时报错set -o pipefail管道中任何一个命令失败都算失败。这三行加起来能让脚本的“容错性”变成“快速失败”问题暴露得越早排查成本越低。7.3 日志记录与错误捕获AI Agent 流水线通常跑的时间比较长中间出错时如果没日志根本不知道发生了什么。我的做法是每个关键步骤都写日志错误信息单独捕获。LOG_FILE$LOG_DIR/agent_$(date %Y%m%d_%H%M%S).log exec (tee -a $LOG_FILE) 21 echo 开始执行: $(date) # ... 你的命令 ... echo 执行结束: $(date)exec (tee -a $LOG_FILE) 21这行的作用是把标准输出和标准错误都同时打印到屏幕和写入日志文件。这样你既能实时看到进度又能事后查日志。如果某个命令可能失败但你不希望整个脚本退出可以用|| true或者if判断if ! command_that_might_fail; then echo 警告: 命令失败继续执行 $LOG_FILE fi7.4 一个完整的流水线脚本示例下面是一个简化版的 AI Agent 流水线脚本涵盖了路径处理、删除操作、命令调用、日志记录和错误处理。#!/bin/bash set -euo pipefail # 路径定义 PROJECT_ROOT/c/Users/myuser/projects/agent DATA_DIR$PROJECT_ROOT/data OUTPUT_DIR$PROJECT_ROOT/output TEMP_DIR$PROJECT_ROOT/temp LOG_DIR$PROJECT_ROOT/logs # 创建必要目录 mkdir -p $OUTPUT_DIR $TEMP_DIR $LOG_DIR # 日志配置 LOG_FILE$LOG_DIR/pipeline_$(date %Y%m%d_%H%M%S).log exec (tee -a $LOG_FILE) 21 echo 流水线开始: $(date) # 步骤1: 清理临时目录 echo [步骤1] 清理临时目录 if [ -d $TEMP_DIR ]; then rm -rf $TEMP_DIR mkdir -p $TEMP_DIR echo 临时目录已重置 fi # 步骤2: 检查输入文件 echo [步骤2] 检查输入文件 INPUT_FILE$DATA_DIR/input.txt if [ ! -f $INPUT_FILE ]; then echo 错误: 输入文件不存在: $INPUT_FILE exit 1 fi echo 输入文件确认: $INPUT_FILE # 步骤3: 执行 Agent 处理 echo [步骤3] 执行 Agent 处理 python $PROJECT_ROOT/agent.py \ --input $INPUT_FILE \ --output $OUTPUT_DIR/result.txt \ --temp $TEMP_DIR # 步骤4: 验证输出 echo [步骤4] 验证输出 if [ -f $OUTPUT_DIR/result.txt ]; then echo 输出文件已生成: $OUTPUT_DIR/result.txt wc -l $OUTPUT_DIR/result.txt else echo 错误: 输出文件未生成 exit 1 fi echo 流水线结束: $(date) 这个脚本可以直接改改就用。关键点在于路径全部用变量、删除前先判断、每步都有日志、出错立即退出。7.5 后续可以扩展的方向这篇主要解决了“路径、删除、命令”三个基础问题。但一个完整的 AI Agent 流水线还涉及更多环节比如环境变量管理、依赖安装、定时任务、错误重试、结果通知等。环境变量方面Windows 的set和 Git Bash 的export不一样跨环境传递变量需要额外处理。依赖安装方面Python 的pip、Node 的npm在 Git Bash 里的行为也有差异。定时任务方面Windows 的任务计划程序和 Linux 的cron完全是两套体系。这些内容我会在后续的文章里逐个展开。如果你现在就想动手建议先把这篇里的路径规范和脚本模板用起来把基础打牢。等流水线能稳定跑通单次任务了再考虑加定时、加通知、加监控。我个人在实际操作中的体会是Windows 上跑 AI Agent80% 的报错都来自路径和命令兼容性。把这两个问题解决了剩下的就是纯粹的 Agent 逻辑开发那才是真正有意思的部分。 Windows 上跑 AI Agent 流水线：路径、删除与命令兼容性实战
1. 为什么要在 Windows 上折腾 AI Agent 流水线先说一个我踩过的坑。去年冬天我在 Windows 上跑一个自动化的 AI Agent 脚本功能很简单读取本地文档、调用模型接口、把结果写回指定目录。在 macOS 上跑得好好的搬到 Windows 上直接炸了——路径分隔符不对、rm命令不存在、cp报cannot stat、vim打开文件全是乱码。折腾了整整一个下午最后发现问题的根源不是代码逻辑而是 Windows 和 Unix 两套体系在路径、命令、编码上的根本差异。这件事让我意识到一个被很多人忽略的事实AI Agent 的开发本身并不难难的是让它在一个“不友好”的操作系统上稳定跑起来。你去看那些 AI Agent 的教程和开源项目绝大多数默认你用的是 Linux 或 macOS命令行示例清一色是bash风格。而现实是大量开发者手里只有一台 Windows 电脑或者公司配的开发机就是 Windows。所以这个系列我打算把 Windows 上搭 AI Agent 流水线的完整过程拆开讲第一篇专门解决最基础也最烦人的问题路径、删除、命令怎么让它们全都不报错。这不是一篇“Windows 入门教程”而是一个实际跑通过流水线的人把那些文档里不会写的坑一个个填上。这篇文章适合谁看如果你正在 Windows 上尝试搭建 AI Agent或者准备从零开始做一个自动化流程又或者你已经被Git Bash的路径问题、rm命令的报错、vim的乱码折磨过那这篇内容就是写给你的。我会从环境选型讲到具体命令从原理讲到实操尽量让每个步骤都能直接抄作业。2. 环境选型Git Bash、WSL 2 还是原生 CMD2.1 三种方案的真实对比在 Windows 上跑 AI Agent第一件事就是决定用哪个终端环境。这不是一个随便选选的问题因为它直接决定了你后续所有命令的写法、路径的格式、以及遇到报错时的排查方向。我前后用过三种方案各有各的脾气。原生 CMD 和 PowerShell是最“Windows”的选择。优点是系统自带、启动快、和 Windows 生态无缝衔接。缺点是命令体系和 Unix 完全不同——ls变成dirrm变成delcp变成copy路径用反斜杠\。如果你写的 AI Agent 脚本里全是 Unix 命令在 CMD 里跑基本等于重写一遍。而且 PowerShell 虽然强大但它的语法和管道机制跟 bash 差异很大学习成本不低。WSL 2是在 Windows 里跑了一个真正的 Linux 内核。优点是完整的 Linux 体验所有 bash 命令、路径规则、包管理都和 Ubuntu 一模一样AI Agent 项目几乎可以零改动迁移。缺点是资源占用高、文件系统跨边界访问慢、有时候网络配置会出幺蛾子。我实测下来WSL 2 跑轻量级 Agent 没问题但如果你的流水线涉及大量文件读写跨/mnt/c/和 Linux 原生目录之间的操作会明显拖慢速度。Git Bash是我目前最推荐的折中方案。它随 Git for Windows 一起安装提供了一个模拟的 bash 环境支持大部分常用 Unix 命令路径可以用正斜杠/同时又能直接访问 Windows 的文件系统。它不像 WSL 2 那样吃资源又比 CMD 友好得多。对于 AI Agent 流水线这种“需要 Unix 命令但不需要完整 Linux 内核”的场景Git Bash 的性价比最高。方案命令兼容性路径格式资源占用适用场景CMD/PowerShell低反斜杠\极低纯 Windows 原生工具链WSL 2极高正斜杠/高完整 Linux 项目迁移Git Bash高正斜杠/低AI Agent 流水线首选2.2 Git Bash 安装与配置要点Git Bash 的安装本身不复杂去 Git for Windows 官网下载安装包一路下一步就行。但有几个配置项如果你不注意后面会反复踩坑。安装过程中会问你“Adjusting your PATH environment”默认选项是“Git from the command line and also from 3rd-party software”这个保持默认就好。它会把 Git 和 Git Bash 加到系统 PATH 里这样你在任何终端都能调用git命令。另一个关键选项是“Configuring the line ending conversions”。Windows 用CRLF换行Unix 用LF。如果你选错了脚本文件在跨平台传输时会出现诡异的执行错误。我的建议是选“Checkout as-is, commit Unix-style line endings”这样 Git 在提交时自动把换行符转成 Unix 风格检出时保持原样。对于 AI Agent 项目来说这个设置能避免很多“脚本在 Windows 上能跑、在服务器上报错”的问题。安装完成后打开 Git Bash第一件事是确认路径映射。Git Bash 里Windows 的C:\Users\你的用户名会被映射成/c/Users/你的用户名。这个映射规则是理解后续所有路径问题的钥匙。你可以用pwd命令看看当前目录用cd /c/试试能不能进到 C 盘根目录。提示Git Bash 的默认家目录是/c/Users/你的用户名但你可以通过修改~/.bashrc文件来调整。如果你希望每次打开 Git Bash 都自动进入项目目录在.bashrc末尾加一行cd /c/你的项目路径就行。2.3 为什么我不建议一上来就用 WSL 2很多人一听说 WSL 2 是“完整 Linux”就立刻投奔过去了。我一开始也是这么想的直到我发现三个问题。第一WSL 2 的文件系统是独立的。你在 WSL 里创建的 AI Agent 项目文件实际存储在虚拟磁盘里Windows 的资源管理器访问起来要通过\\wsl$\路径速度慢不说有时候还会出现权限问题。第二WSL 2 的网络是 NAT 模式如果你需要 Agent 监听某个端口供外部访问得额外配置端口转发。第三WSL 2 的启动速度虽然比 WSL 1 快但比起 Git Bash 还是慢不少每次打开都要等几秒。Git Bash 的优势在于“轻”。它就是一个终端模拟器加一套 Unix 工具集启动几乎瞬间完成文件直接存在 Windows 磁盘上网络就是 Windows 的网络。对于大多数 AI Agent 流水线来说你需要的只是“能跑 bash 命令”和“路径别报错”Git Bash 完全够用。等你真的遇到 Git Bash 解决不了的问题再上 WSL 2 也不迟。3. 路径问题从报错到根治的完整思路3.1 路径报错的三种典型表现路径问题是 Windows 上跑 AI Agent 最高频的报错来源没有之一。我总结下来它通常以三种形式出现。第一种是“No such file or directory”。你明明看到文件就在那里但命令就是找不到。这通常是因为路径分隔符用错了——在 Git Bash 里用了反斜杠\或者路径里包含了空格但没有加引号。比如cd C:\Users\my project会报错因为 Git Bash 把\当成转义字符而且空格把路径截断了。正确的写法是cd /c/Users/my project。第二种是“Permission denied”。这个在 AI Agent 写文件时特别常见。Windows 的权限体系和 Unix 不一样Git Bash 模拟的权限位有时候和实际文件系统对不上。如果你用chmod x给脚本加执行权限但文件在 NTFS 分区上这个权限可能不会真正生效。解决办法是尽量把项目放在用户目录下避免系统保护目录。第三种是“路径太长”。Windows 默认的路径长度限制是 260 个字符虽然现代 Windows 10 和 11 可以开启长路径支持但很多工具链还没适配。AI Agent 项目如果依赖层级很深比如node_modules里嵌套好几层很容易触发这个限制。我遇到过一次npm install到一半报错排查半天才发现是路径超长。3.2 Git Bash 路径映射规则详解要根治路径问题必须理解 Git Bash 的路径映射逻辑。它本质上是一个“翻译层”把你输入的 Unix 风格路径翻译成 Windows 能理解的路径。核心规则就一条Windows 的盘符X:\映射为/x/。比如C:\Users\test对应/c/Users/testD:\projects\agent对应/d/projects/agent。这个映射是双向的你在 Git Bash 里用/c/开头的路径Git Bash 会自动翻译给 Windows 系统调用。但有几个特殊情况需要注意。第一网络路径\\server\share在 Git Bash 里要写成//server/share。第二UNC 路径和盘符映射路径在 Git Bash 里的行为略有不同前者有时候会出现权限问题。第三如果你在脚本里硬编码了C:\这样的路径在 Git Bash 里执行时可能会被误解建议统一用/c/格式。还有一个隐藏的坑环境变量里的路径。Windows 的PATH环境变量是用分号;分隔的而且路径是反斜杠格式。Git Bash 在启动时会把这些转换成 Unix 风格但如果你在脚本里手动拼接路径比如export PATH$PATH:/c/new/path要注意不要混用两种格式。3.3 实操用pwd、cd、ls定位路径问题当你遇到路径报错时不要慌按下面这个流程一步步排查。第一步用pwd确认当前工作目录。很多时候你以为自己在某个目录实际上不是。比如你双击打开 Git Bash它默认在家目录而不是你上次离开的地方。第二步用ls看看目标文件到底在不在。如果ls能看到文件但你的命令说找不到那问题多半出在路径格式上。如果ls也看不到那就是目录不对。第三步用cd逐级进入目录观察哪一级开始报错。比如cd /c/Users成功cd /c/Users/test失败那说明test目录不存在或者权限有问题。第四步如果路径里有空格或特殊字符用引号包起来。Git Bash 对空格很敏感cd /c/Program Files会报错必须写成cd /c/Program Files。第五步用realpath命令把相对路径转成绝对路径确认最终解析结果。这个命令在排查符号链接和相对路径问题时特别有用。注意Git Bash 里cd命令不显示当前目录如果你习惯用cd后看提示符确认位置可能会不习惯。建议在.bashrc里加一行PS1\w $ 让提示符显示当前路径。3.4 路径问题速查表报错信息可能原因解决方法No such file or directory路径分隔符错误把\改成/No such file or directory路径含空格未加引号用双引号包裹路径Permission denied文件在系统保护目录移到用户目录下Permission denied执行权限未生效用bash script.sh代替./script.sh路径过长超过 260 字符限制开启长路径支持或缩短目录层级找不到命令PATH 未包含该目录检查echo $PATH并手动添加4. 删除操作rm命令在 Windows 上的正确姿势4.1 为什么rm在 Git Bash 里也会出问题rm是 Unix 里最常用的删除命令Git Bash 也提供了它。但你可能遇到这样的情况rm命令执行了没报错但文件还在或者rm -rf删了半天没反应又或者删完之后回收站里找不到文件却真的没了。这些问题的根源在于Git Bash 的rm和 Windows 的文件系统之间有一层“翻译”。Git Bash 的rm实际上调用的是它自带的coreutils里的rm实现这个实现通过 MSYS2 层和 Windows API 交互。大多数时候没问题但在处理只读文件、被占用文件、以及长路径文件时行为会和原生 Linux 有差异。另一个常见问题是rm删除的文件不进回收站。在 Windows 上你用资源管理器删除文件文件会进回收站后悔了还能恢复。但 Git Bash 的rm是直接删除绕过回收站。这意味着一旦删错基本没有挽回余地。我踩过一次坑rm -rf删了一个目录以为里面有备份结果发现备份也在那个目录里。4.2rm、rm -r、rm -rf的区别与风险这三个命令的差异值得单独拿出来讲清楚因为用错了后果很严重。rm file.txt删除单个文件。如果文件不存在会报No such file or directory。如果文件是只读的会提示是否删除需要输入y确认。rm -r dir/递归删除目录及其内容。-r是 recursive 的意思它会进入目录逐个删除里面的文件和子目录。如果目录里有只读文件同样会提示确认。rm -rf dir/强制递归删除不提示任何确认。-f是 force 的意思它会忽略不存在的文件、不提示只读文件、不报任何错误。这个命令在 AI Agent 流水线里很常用比如清理临时目录、重置工作空间。但它也是最危险的因为一旦路径写错比如rm -rf /或者rm -rf ~后果不堪设想。我的建议是在脚本里用rm -rf之前先用echo打印出要删除的路径确认无误后再执行。或者用rm -rf的“安全版”——先cd到目标目录的父目录再用相对路径删除避免绝对路径写错。4.3 安全删除的替代方案如果你对rm心有余悸或者你的 AI Agent 流水线需要“可恢复”的删除操作有几个替代方案可以考虑。用mv代替rm。把要删除的文件移动到一个临时目录比如mv file.txt /tmp/trash/。这样文件还在只是换了个位置后悔了还能移回来。等确认不需要了再统一清理/tmp/trash/。用trash命令。有些 Git Bash 发行版自带trash命令它会把文件移到回收站而不是直接删除。如果你的 Git Bash 没有这个命令可以通过包管理器安装或者写一个简单的脚本模拟。用 Windows 原生的del命令。在 Git Bash 里可以调用cmd //c del file.txt这样删除的文件会进回收站。注意路径要用 Windows 格式而且//c是 Git Bash 里调用 CMD 的写法。用 Python 脚本删除。如果你的 AI Agent 本身就是 Python 写的可以用send2trash库它跨平台支持回收站删除。安装pip install send2trash然后from send2trash import send2trash; send2trash(file.txt)。4.4 删除操作实操记录下面是我在一个 AI Agent 项目里实际用到的清理脚本功能是删除output/目录下超过 7 天的临时文件。#!/bin/bash # cleanup.sh - 清理超过7天的临时文件 TARGET_DIR/c/Users/myuser/agent/output DAYS7 # 先确认目录存在 if [ ! -d $TARGET_DIR ]; then echo 目录不存在: $TARGET_DIR exit 1 fi # 用 find 查找并删除 find $TARGET_DIR -type f -mtime $DAYS -print -delete echo 清理完成这个脚本有几个细节值得说。第一-print -delete会先打印文件名再删除方便你确认删了什么。第二-mtime 7表示修改时间超过 7 天。第三用find而不是rm通配符是因为find对路径的处理更稳健不容易因为空格或特殊字符出错。如果你要删除整个目录我建议用这个模式TARGET/c/Users/myuser/agent/temp if [ -d $TARGET ]; then echo 即将删除: $TARGET rm -rf $TARGET echo 已删除 else echo 目录不存在跳过 fi先判断目录是否存在再打印确认最后删除。这三步看起来啰嗦但能避免 90% 的误删事故。5. 命令兼容性那些在 Git Bash 里“水土不服”的命令5.1cp报cannot stat的排查方法cp: cannot stat 11.txt: no such file or directory这个报错我在热词里看到过自己也遇到过。它的字面意思是“找不到 11.txt 这个文件”但实际情况往往更复杂。最常见的原因是当前目录不对。你以为自己在项目根目录实际上在别的目录。用pwd确认一下用ls看看11.txt在不在。第二个原因是文件名有隐藏字符。比如从网页复制文件名时可能带上了不可见的 Unicode 字符。用ls -la看看文件名的实际字节或者用ls | cat -A显示不可见字符。第三个原因是路径大小写问题。Windows 文件系统不区分大小写但 Git Bash 的某些命令区分。如果文件实际叫11.TXT你写11.txt在某些情况下会找不到。第四个原因是文件在另一个盘符。比如你在/c/下操作但文件在/d/下相对路径自然找不到。排查流程很简单pwd确认位置ls确认文件存在ls -la确认文件名无隐藏字符然后用绝对路径重试。如果绝对路径能成功那就是相对路径的问题。5.2vim在 Git Bash 里的配置与乱码解决vim是 Git Bash 自带的编辑器但默认配置对中文用户不太友好。你可能遇到打开文件全是乱码、方向键变成 ABCD、或者退出时提示q无效。乱码问题的根源是编码不一致。Windows 默认用 GBK 编码而 Git Bash 和大多数 AI Agent 项目用 UTF-8。解决办法是在~/.vimrc里加几行配置set encodingutf-8 set fileencodingutf-8 set termencodingutf-8 set fileencodingsutf-8,gbk,gb2312,gb18030 set nu set ts4 set sw4这几行的作用是内部编码用 UTF-8文件编码用 UTF-8终端编码用 UTF-8打开文件时按 UTF-8、GBK、GB2312、GB18030 的顺序尝试解码。set nu显示行号set ts4和set sw4设置 Tab 为 4 个空格。方向键变 ABCD 的问题是因为vim在兼容模式下把方向键的转义序列当成了普通字符。解决办法是在.vimrc里加set nocompatible或者用vim -N启动。如果你不习惯vimGit Bash 也自带nano操作更简单。或者你可以用 VS Code 的集成终端直接调用 Git Bash编辑文件用 VS Code 的图形界面。5.3 其他常用命令的 Windows 适配除了cp和vim还有几个命令在 Git Bash 里需要特别注意。ln -s创建符号链接。在 Windows 上创建符号链接需要管理员权限而且 NTFS 的符号链接和 Unix 的行为不完全一样。如果你在脚本里用了ln -s建议改成cp或者用 Windows 的mklink命令。chmod修改权限。前面提过Git Bash 的chmod在 NTFS 上可能不生效。如果你需要让脚本可执行用bash script.sh而不是./script.sh。ps和kill进程管理。Git Bash 的ps只显示 Git Bash 内部的进程看不到 Windows 的系统进程。要查看所有进程用tasklist要杀进程用taskkill //PID 进程号 //F。telnet测试端口。Windows 默认没装telnet客户端需要在“启用或关闭 Windows 功能”里手动开启。或者用curl代替curl -v telnet://localhost:8080。type查看命令类型。在 Git Bash 里type命令可以告诉你一个命令是内置的、别名的、还是外部程序。比如type ls会显示ls is aliased to ls --colorauto。5.4 命令兼容性速查表命令Git Bash 表现替代方案cp基本可用注意路径格式用绝对路径或引号包裹vim需配置编码配置.vimrc或用nanoln -s需管理员权限用cp或mklinkchmodNTFS 上可能不生效用bash script.shps只显示 Git Bash 进程用tasklistkill只能杀 Git Bash 进程用taskkill //PID //Ftelnet默认未安装用curl -v telnet://6. 常见问题与排查技巧实录6.1 脚本执行报错的排查思路AI Agent 流水线通常由多个脚本串联而成一个脚本报错整个流水线就断了。我总结了一套排查思路按顺序执行基本能定位到问题。第一步看报错信息的最后一行。Unix 命令的报错通常是“最后一行最重要”前面的输出可能是正常的日志。比如cp: cannot stat 11.txt关键就是cannot stat和文件名。第二步确认脚本的执行环境。你是在 Git Bash 里直接跑还是在 CMD 里调用bash script.sh不同的环境路径解析规则不同。建议统一在 Git Bash 里执行。第三步加-x参数调试。bash -x script.sh会打印每一行执行的命令和参数你能清楚看到是哪一行出了问题以及当时的变量值是什么。第四步检查文件编码和换行符。如果脚本是在 Windows 上编辑的可能带了CRLF换行符导致bash解析出错。用file script.sh查看如果是CRLF用dos2unix script.sh转换。第五步检查依赖命令是否存在。which 命令名可以确认命令是否在 PATH 里。如果不存在需要安装或手动指定路径。6.2 路径含空格和中文的处理路径里有空格是 Windows 用户的“家常便饭”。C:\Program Files、C:\Users\My Name这些路径在 Git Bash 里如果不加引号会被拆成多个参数。处理原则很简单只要路径里有空格或特殊字符就用双引号包起来。比如cd /c/Program Files、cp source file.txt dest file.txt。中文路径的问题更隐蔽。Git Bash 默认用 UTF-8 编码但 Windows 的文件系统 API 可能用 UTF-16。大多数情况下 Git Bash 能正确处理中文路径但如果遇到乱码或找不到文件可以尝试用cd逐级进入或者用ls确认文件名的实际编码。如果中文路径问题频繁出现一个彻底的解决办法是项目路径全部用英文。把项目放在/c/Users/yourname/projects/agent这样的纯英文路径下能避免 99% 的编码问题。6.3 权限问题的典型场景Git Bash 在 Windows 上遇到的权限问题通常有三种场景。第一种是写入系统目录。比如你想把 Agent 的日志写到C:\Windows\System32这需要管理员权限。解决办法是写到用户目录比如~/agent/logs/。第二种是执行脚本。你写了一个run.sh用./run.sh执行报Permission denied。这是因为 NTFS 没有 Unix 的可执行位。解决办法是用bash run.sh或者用chmod x run.sh试试有时候有效。第三种是访问其他用户的文件。如果 Agent 需要读取另一个用户目录下的文件可能会被拒绝。解决办法是把文件复制到当前用户可访问的目录或者调整文件权限。6.4 常见问题速查表问题现象排查步骤解决方案脚本报错但看不出原因用bash -x调试查看具体出错行和变量值文件找不到pwdlsrealpath确认路径和文件名路径含空格报错检查是否加引号用双引号包裹路径中文路径乱码ls查看实际文件名改用英文路径权限拒绝确认文件位置和权限移到用户目录或用bash执行命令不存在which检查安装或指定完整路径换行符导致脚本失败file查看用dos2unix转换6.5 我踩过的三个坑第一个坑是在 CMD 里跑 bash 脚本。我以为装了 Git BashCMD 就能直接跑.sh文件结果报了一堆错。后来才明白.sh文件必须在 bash 环境里执行要么打开 Git Bash要么用bash script.sh。第二个坑是用rm -rf删了不该删的目录。当时我想清理temp/结果路径写成了/c/Users/myuser/agent/temp但实际项目在/d/agent/temp。rm -rf没报错因为/c/Users/myuser/agent/temp不存在-f忽略了错误。等我发现删错的时候已经晚了。从那以后我养成了“先echo再rm”的习惯。第三个坑是vim编辑后文件多了^M。这是因为vim在 Windows 上默认用CRLF保存而 AI Agent 的 Python 脚本对换行符敏感。解决办法是在.vimrc里加set fileformatunix强制用 Unix 换行符保存。7. 把流水线跑通的关键习惯7.1 统一路径风格在 Windows 上搭 AI Agent 流水线最有效的习惯是统一用 Git Bash 的路径风格。所有脚本、配置、命令路径一律用/c/、/d/开头一律用正斜杠/。不要混用C:\和/c/不要一会儿反斜杠一会儿正斜杠。这个习惯的好处是你的脚本在 Git Bash 里能跑在 WSL 2 里也能跑在 Linux 服务器上稍微改改也能跑。如果你混用两种风格脚本就只能在特定环境里跑迁移成本很高。具体做法在项目根目录放一个env.sh定义所有路径变量export PROJECT_ROOT/c/Users/myuser/projects/agent export DATA_DIR$PROJECT_ROOT/data export OUTPUT_DIR$PROJECT_ROOT/output export LOG_DIR$PROJECT_ROOT/logs其他脚本source env.sh后直接用变量不写死路径。这样换电脑或换目录时只改env.sh一个文件就行。7.2 脚本开头加set -eset -e是 bash 的一个选项意思是“遇到错误立即退出”。默认情况下bash 脚本里某一行报错会继续执行下一行这可能导致错误累积最后排查起来很麻烦。在 AI Agent 流水线里我建议每个脚本开头都加#!/bin/bash set -e set -u set -o pipefailset -e遇到错误退出set -u使用未定义变量时报错set -o pipefail管道中任何一个命令失败都算失败。这三行加起来能让脚本的“容错性”变成“快速失败”问题暴露得越早排查成本越低。7.3 日志记录与错误捕获AI Agent 流水线通常跑的时间比较长中间出错时如果没日志根本不知道发生了什么。我的做法是每个关键步骤都写日志错误信息单独捕获。LOG_FILE$LOG_DIR/agent_$(date %Y%m%d_%H%M%S).log exec (tee -a $LOG_FILE) 21 echo 开始执行: $(date) # ... 你的命令 ... echo 执行结束: $(date)exec (tee -a $LOG_FILE) 21这行的作用是把标准输出和标准错误都同时打印到屏幕和写入日志文件。这样你既能实时看到进度又能事后查日志。如果某个命令可能失败但你不希望整个脚本退出可以用|| true或者if判断if ! command_that_might_fail; then echo 警告: 命令失败继续执行 $LOG_FILE fi7.4 一个完整的流水线脚本示例下面是一个简化版的 AI Agent 流水线脚本涵盖了路径处理、删除操作、命令调用、日志记录和错误处理。#!/bin/bash set -euo pipefail # 路径定义 PROJECT_ROOT/c/Users/myuser/projects/agent DATA_DIR$PROJECT_ROOT/data OUTPUT_DIR$PROJECT_ROOT/output TEMP_DIR$PROJECT_ROOT/temp LOG_DIR$PROJECT_ROOT/logs # 创建必要目录 mkdir -p $OUTPUT_DIR $TEMP_DIR $LOG_DIR # 日志配置 LOG_FILE$LOG_DIR/pipeline_$(date %Y%m%d_%H%M%S).log exec (tee -a $LOG_FILE) 21 echo 流水线开始: $(date) # 步骤1: 清理临时目录 echo [步骤1] 清理临时目录 if [ -d $TEMP_DIR ]; then rm -rf $TEMP_DIR mkdir -p $TEMP_DIR echo 临时目录已重置 fi # 步骤2: 检查输入文件 echo [步骤2] 检查输入文件 INPUT_FILE$DATA_DIR/input.txt if [ ! -f $INPUT_FILE ]; then echo 错误: 输入文件不存在: $INPUT_FILE exit 1 fi echo 输入文件确认: $INPUT_FILE # 步骤3: 执行 Agent 处理 echo [步骤3] 执行 Agent 处理 python $PROJECT_ROOT/agent.py \ --input $INPUT_FILE \ --output $OUTPUT_DIR/result.txt \ --temp $TEMP_DIR # 步骤4: 验证输出 echo [步骤4] 验证输出 if [ -f $OUTPUT_DIR/result.txt ]; then echo 输出文件已生成: $OUTPUT_DIR/result.txt wc -l $OUTPUT_DIR/result.txt else echo 错误: 输出文件未生成 exit 1 fi echo 流水线结束: $(date) 这个脚本可以直接改改就用。关键点在于路径全部用变量、删除前先判断、每步都有日志、出错立即退出。7.5 后续可以扩展的方向这篇主要解决了“路径、删除、命令”三个基础问题。但一个完整的 AI Agent 流水线还涉及更多环节比如环境变量管理、依赖安装、定时任务、错误重试、结果通知等。环境变量方面Windows 的set和 Git Bash 的export不一样跨环境传递变量需要额外处理。依赖安装方面Python 的pip、Node 的npm在 Git Bash 里的行为也有差异。定时任务方面Windows 的任务计划程序和 Linux 的cron完全是两套体系。这些内容我会在后续的文章里逐个展开。如果你现在就想动手建议先把这篇里的路径规范和脚本模板用起来把基础打牢。等流水线能稳定跑通单次任务了再考虑加定时、加通知、加监控。我个人在实际操作中的体会是Windows 上跑 AI Agent80% 的报错都来自路径和命令兼容性。把这两个问题解决了剩下的就是纯粹的 Agent 逻辑开发那才是真正有意思的部分。