Cloud Composer 是 Google Cloud 托管的 Apache Airflow 服务，用于编排数据工作流；而 PHP 的 Composer 是依赖管理工具，不参与调度或运行时监控。
Composer 本身不采集、不调度、不运行负载，也不分析真实请求流量——它只是 PHP 的依赖管理工具。你看到的“调度”“负载”“运行数据”，大概率是混淆了以下三类东西：
-
Cloud Composer（Google Cloud 托管的 Airflow）：真有 DAG 调度、任务编排、执行日志和资源监控； -
composerCLI 命令（如install/update）：只在本地解析依赖、下载包、生成 autoloader； - 第三方监控 SDK（如
prometheus/client_php、spatie/laravel-ray）：需手动集成到应用中，才能采集 HTTP 请求、DB 查询、协程耗时等运行时指标。
所以，如果你的目标是「采集 PHP 应用的真实调度行为与负载数据」，得明确：
不是 composer 在做这件事，而是你用 composer 安装的库 + 自己写的埋点逻辑 + 外部可视化系统共同完成的。
composer install 后怎么让服务暴露可采集的运行指标
关键不在安装，而在后续集成是否到位。以最轻量的 Prometheus 方案为例：
-
composer require prometheus/client_php确实能装上客户端，但默认不自动暴露/metrics - 你必须自己注册一个路由（FPM/Swoole/CLI 均需适配），例如：
use Prometheus\CollectorRegistry;
$registry = new CollectorRegistry();
$counter = $registry->getOrRegisterCounter('app', 'http_requests_total', 'Total HTTP Requests');
$counter->inc(['method' => 'GET', 'path' => '/api/user']);
// 然后在某个响应前输出：
header('Content-Type: text/plain; version=0.0.4');
echo $registry->render();- 这段代码不会被自动执行；你得把它塞进 Laravel 中间件、Swoole HTTP server 的 onRequest 回调，或 Workerman 的 onMessage 里
- 如果漏掉
render()或没设对Content-Type，Grafana 就拉不到指标，报invalid metric type
composer --profile 能不能反映线上真实负载
不能。它只记录 composer 自身命令的执行开销，比如：
-
Resolving dependencies耗时高 → 说明composer.json里约束太松、版本冲突多 -
Downloading packages卡住 → 源站慢或网络丢包，跟业务请求无关 -
Generating autoload files时间长 → 类文件太多，或没开-o优化
这些数据只存在于 CI/CD 构建阶段，上线后就消失了。它不采集任何 HTTP 请求延迟、QPS、内存增长、协程数变化——那些得靠 opentelemetry/sdk-php 或 swoole 内置的 Server::stats()。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么用 composer require 装了监控包却看不到 Dashboard
因为 Dashboard 是独立系统，不是 Composer 的产物。常见断点：
-
prometheus/client_php只负责“写指标”，不提供“拉指标”的 HTTP Server，更不带前端 - Grafana 需要手动配置 Prometheus 数据源，并写 PromQL 查询
rate(http_requests_total[5m]) - 如果你的服务跑在 Swoole，但 metrics 路由写在 Laravel 的
routes/web.php里，那根本不会命中（Laravel Router 不接管 Swoole 原生请求） -
datadog/php-tracing要求设置DD_AGENT_HOST和开启 APM Agent，否则 trace 数据发不出去
装包只是第一步，后面至少还要：
- 确认指标采集逻辑已嵌入请求生命周期
- 确认暴露端点可被外部访问（防火墙、反向代理、Swoole 的
set(['http_compression' => false])影响响应格式） - 确认采集周期与 Grafana 抓取间隔匹配（比如指标每 10s 更新一次，但 Prometheus 配了 60s 抓取，就会漏数据）
真正的瓶颈往往不在“有没有装”，而在“有没有真正接入运行时上下文”。
