必须在主项目composer.json的repositories中配置{"type":"path","url":"../my-package"}，本地包需有合法composer.json且name与require一致，版本用dev-main，路径用相对路径。
Composer 的 path 仓库类型怎么配？
直接在项目 composer.json 里加 path 类型仓库，就能让 Composer 从本地目录加载包——不是 symlink，也不是 git clone，而是原地映射。关键点是：必须把包的 composer.json 放在目标路径下，且该文件里要有合法的 name（格式为 vendor/name），否则 Composer 会报 Package vendor/name is not installed 或直接忽略。
实操步骤：
- 确保独立包根目录下有完整的
composer.json，含"name": "myorg/my-package"、"autoload"等必要字段 - 在主项目的
composer.json的repositories数组里添加：
{
"type": "path",
"url": "../my-package"
}
注意：url 是相对于主项目 composer.json 的路径，支持 ../、./packages/xxx，但不支持绝对路径（Windows 下 C:\xxx 会失败）。
require 时用 dev-main 还是稳定版本号？
用 path 加载时，Composer 默认只识别包 composer.json 中声明的 version 字段（如果写了），但更常见、更可靠的做法是：**不写 version，改用 dev-main 或 dev-develop 作为版本约束**。因为本地开发中分支名比硬编码版本更灵活，且 Composer 能自动匹配到对应分支的 HEAD。
例如主项目 require 段写成：
"myorg/my-package": "dev-main"
而不是：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"myorg/my-package": "1.0.0"
后者只有在包的 composer.json 明确写了 "version": "1.0.0" 才可能生效，且一旦改代码不更新 version，Composer 就不会重装——这反而导致缓存错觉。
为什么 composer install 没拉进 vendor？
最常见原因是包名不一致：主项目 require 的 vendor/name 和 path 包里 composer.json 的 name 字段对不上。Composer 不会报错，只会静默跳过该仓库，回退到 Packagist 查找（结果当然是找不到或装错包）。
排查方法：
- 运行
composer show myorg/my-package，如果提示no matching package found，基本就是 name 不匹配 - 运行
composer config --list | grep repositories确认 path 仓库已加载 - 检查包内
composer.json是否有语法错误（比如末尾多逗号），会导致整个包被忽略
另一个坑：如果主项目已通过 Packagist 安装过同名包，Composer 默认优先走 dist，不会主动切到 path。此时需先 composer remove myorg/my-package，再 composer require myorg/my-package:dev-main 强制触发 path 加载。
path 依赖能自动热更新吗？
不能。Composer 的 path 是单次映射，源码改了，require 的类不会自动重载——和 symlink 行为不同。它只是让 composer install 把那个目录当作“已安装包”处理，autoloader 仍走 PSR-4 规则加载。所以你改了包里的 PHP 文件，只要没改命名空间或文件路径，Web 请求或 CLI 执行时就能立刻生效；但如果你改了 autoload 配置（比如新增了 files 数组），就得手动跑 composer dump-autoload。
顺带提醒：别在生产环境用 path。它绕过了版本锁定（composer.lock 里记录的是路径而非 commit hash），CI 构建时若路径不存在会直接失败。真正要复用的独立包，该发 tag 就发 tag，该推私有 Packagist 就推。
