多代理 MLOps 机器学习管道

要解决什么问题

把模型从「笔记本里能跑」推到「线上可监控、可回滚、可复训」，往往要同时碰数据版本、特征存储、训练实验、Serving 与漂移告警——角色多、交接点多，单轮对话很容易漏掉质量门禁或生产细节。本技能面向 完整 ML 管道 的设计与实现，用户通过 $ARGUMENTS 描述目标与约束，由编排流程按阶段产出可落地的方案与实现要点。

技能如何工作

核心理念是 基于阶段的协调：数据工程师 → 数据科学家 → ML 工程师 → Python 生产化 → MLOps / K8s → 可观测性，每步明确交付物并引用上一阶段输出。

• 阶段 1：数据源审计与摄入（Pydantic / Great Expectations、DVC / lakeFS）、质量框架与分层存储；特征工程与实验设计（Feast/Tecton、指标与 A/B 假设）。
• 阶段 2：模块化训练（Optuna / Ray Tune、分布式训练）、MLflow / W&B 实验跟踪与模型注册晋级；代码重构、性能优化与单元/集成/模型质量测试。
• 阶段 3：REST/gRPC 服务（FastAPI、KServe / Seldon）、蓝绿/金丝雀/影子发布、CI/CD 与 Terraform / Helm；Kubeflow 调度、HPA/KEDA、特征与模型存储策略。
• 阶段 4：准确率与延迟监控、KS/PSI 等 漂移检测、Prometheus/Grafana/Jaeger、自动重训触发与成本归因。

可通过配置项切换 experimenttracking、featurestore、serving_platform、orchestration 等栈；更细的示例见 resources/implementation-playbook.md。

适用边界

任务与多代理 MLOps 管道编排无关时不必启用。它给出最佳实践、步骤与验证思路，不会替代你在目标云账号、合规与真实数据上的最终决策；成功标准里对生产数据质量改善等指标需结合业务自行验收。