composer 不通过 composer.json 精确指定自身版本，而是约束依赖包版本；写 "monolog/monolog": "2.9.0" 默认等价于 "^2.9.0"，需用 "=2.9.0" 或依赖 composer.lock 才能锁定版本。
Composer 不能通过 composer.json “精确指定自身版本”，你真正要控制的是项目依赖包的版本——而所谓“精确版本”，本质是用 ^、~、= 或无修饰符来约束解析行为，不是“锁死”或“强制安装某个 Composer 可执行文件版本”。
为什么 composer install 装出来的包版本和 composer.json 写的不一致？
这是最常被误解的点：你写 "monolog/monolog": "2.9.0"，但 composer install 却装了 2.9.1，说明你没关掉默认的稳定性校验或没理解版本运算符优先级。
-
"monolog/monolog": "2.9.0"等价于"monolog/monolog": "^2.9.0"（Composer 默认启用^行为） - 想真正锁定到
2.9.0，必须显式写成"monolog/monolog": "=2.9.0"或"monolog/monolog": "2.9.0 as 2.9.0" - 更可靠的方式是配合
composer.lock：只要它存在且未被删，composer install就严格按 lock 文件还原，哪怕composer.json里写的是^2.9 - 如果
composer.lock不存在或被改过，Composer 会重新解析composer.json并生成新 lock，此时才看版本写法是否够精确
^ 和 ~ 的实际行为差异在哪？
它们不是“大概范围”，而是有明确定义的语义规则，直接影响你能否升级到某个补丁/小版本。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
^2.9.0允许升级到2.9.9、2.10.0，但不允许3.0.0（即“兼容性保证”：只要主版本不变，次版本可升） -
~2.9.0等价于>=2.9.0 ，只允许 <code>2.9.x，不进2.10—— 更保守，适合对次版本敏感的场景 -
^0.9.0是例外：因为0.x被视为不稳定版，^0.9.0实际等价于>=0.9.0 ，行为同 <code>~0.9.0 - 想彻底禁用自动升级？直接写死带等号：
"foo/bar": "=1.2.3"，Composer 不会尝试解析任何范围
如何让 CI/CD 或多人协作中真正“固定”依赖？
靠 composer.json 写法远远不够，关键在流程和文件协同。
-
composer.lock必须提交进 Git —— 它是唯一能跨环境还原一致依赖的依据 - 禁止在 CI 中运行
composer update，只允许composer install --no-interaction --no-scripts - 如果团队用了不同 Composer 版本（如 2.2 vs 2.5），lock 文件格式可能不兼容（v2.2 生成的 lock 在 v2.5 下可能被重写），建议统一开发机和 CI 的 Composer 版本：
composer self-update 2.5.8 - 检查 lock 是否过期：运行
composer show --outdated（仅对比 lock 与远程最新可用版本，不修改任何文件）
真正难的不是写对一个版本号，而是理解 composer.lock 才是事实来源、composer.json 只是声明意图；以及明白 ^ 的语义会随主版本号变化而切换行为。很多人卡在“明明写了 2.9.0 却装了 2.10.0”，其实只是忘了删 lock 文件后又跑了一次 install。
