db:backup命令不存在是因为backup manager未正确加载：服务提供者未注册、配置未发布、或自动发现被禁用，导致命令类未被识别。
Backup Manager 不是 Laravel 原生组件，直接 composer require backup-manager/laravel 后不配置、不发布、不检查依赖，db:backup 命令大概率根本不会出现在 php artisan list 里——这不是命令写错了，是它压根没被加载。
为什么 db:backup 命令不存在？
常见错误现象：运行 php artisan db:backup 报错 Command "db:backup" is not defined。这不是 Laravel 版本问题，而是服务提供者未注册或配置未发布导致的加载失败。
- Laravel 5.5+ 默认启用自动发现，但前提是
composer.json中没有"dont-discover": ["*"]或类似禁用项 - 即使自动发现生效，也必须执行
php artisan vendor:publish --provider="BackupManager\Laravel\Laravel55ServiceProvider"，否则config/backup-manager.php不会出现，命令类无法读取配置 - 手动注册时，
config/app.php的providers数组末尾漏了逗号，会导致 PHP 解析失败，整个服务提供者列表失效（错误静默，无提示） - Lumen 用户需额外在
bootstrap/app.php中调用$app->configure('backup-manager')，否则配置不加载
db:backup 执行报 DatabaseDumpFailed 怎么办？
这个错误几乎总是 mysqldump 或 pg_dump 命令不可用导致的，和云存储配置无关。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确认服务器上已安装对应 CLI 工具：
which mysqldump或which pg_dump，返回空则需安装 MySQL/PostgreSQL 客户端包 - Laravel 运行用户（如
www-data或nginx）必须有权限执行该命令，不能仅靠 root 能跑就认为 OK - 数据库连接配置中若含特殊字符（如密码里的
@、/），未 URL 编码会导致mysqldump参数解析失败；建议改用DB_HOST+DB_PORT+DB_USERNAME等独立环境变量方式传参 - 使用
--database=mysql时，确保config/database.php中存在名为mysql的连接键，且其driver值为mysql（不是mysqli或其他别名）
定时备份调度失败的三个隐藏条件
在 app/Console/Kernel.php 里写好 $schedule->command(...)->daily()，不代表它真会跑——Laravel 调度器本身需要外部 Cron 触发。
- 服务器必须配置系统级 Cron：每分钟执行一次
php /path/to/artisan schedule:run - Artisan 命令字符串中含空格或特殊符号（如
--timestamp="Y_m_d_H_i_s"）时，必须用单引号包裹整个字符串，否则 shell 解析出错，实际执行的是截断后的命令 - 目标存储（如 S3、Dropbox）的凭据必须通过 Laravel 配置或环境变量注入，不能硬编码在调度闭包里；否则线上环境因
.env未加载而认证失败 - 本地开发环境默认不启用队列或文件锁，多个
schedule:run并发时可能重复执行；生产环境建议配合withoutOverlapping()
压缩与存储路径中的易忽略细节
--compression=gzip 看似简单，但影响恢复兼容性和磁盘占用，不是开就完事。
- gzip 压缩后文件扩展名应为
.sql.gz，但 Backup Manager 默认只加.gz；若后续用脚本批量解压，需统一处理逻辑 -
--destinationPath结尾带斜杠（如/backups/）和不带（如/backups）在部分存储驱动（如 SFTP）中行为不同：前者可能创建空目录，后者才真正写入文件 - S3 目标路径中若含
$environment变量，必须用双引号包裹整个命令字符串，且确保该变量在 Artisan 命令执行时能被正确解析（推荐改用config('app.env')在命令类内部获取） - Dropbox 驱动要求 API token 具备
files.content.write权限，仅account_info.read会导致静默上传失败
最麻烦的从来不是“怎么配”，而是“配完之后谁在真正执行”。命令是否加载、dump 工具是否存在、Cron 是否触发、凭据是否生效——这四层缺一不可，漏掉任何一层，备份就只是日志里一行成功的假象。
