企业官网建设流程全解析

agentic-awesome-skills 的 ai-ml 工作流：从 LLM 应用到 RAG、Agent 与 MLOps 的生产级 AI 研发编排指南

【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,115+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/gh_mirrors/an/agentic-awesome-skills

导读

本篇文章以 plugins/agentic-awesome-skills-claude/skills/ai-ml/SKILL.md 中的ai-ml工作流编排文档为核心，系统讲解如何在 agentic-awesome-skills 仓库中按七个阶段完成 AI/ML 项目的端到端落地：LLM 应用设计、LLM 集成、RAG 实现、AI Agent 开发、ML 流水线、AI 可观测性与 AI 安全。读完本文，你将掌握如何通过@技能名的 copy-paste 提示词逐阶段调度仓库内 30+ 个专项技能，并理解每个阶段背后的源码级实现依据，形成一套可直接复用的生产级 AI 研发方法论。

ai-ml在仓库数据层被注册为workflow-bundle类目（见 data/catalog.json 与 data/skills_index.json），其triggers覆盖ai、ml、machine、learning、llm、application、rag、agent、architecture、pipelines等关键词，风险评级为safe，来源为personal，添加日期为 2026-02-27。也就是说，当任务描述命中这些触发词时，Agent 即可自动唤起该工作流并逐阶段调度子技能。

一、工作流定位与适用场景

1.1 什么是 workflow bundle

ai-ml不是单一技能，而是一个编排层文档：它不亲自实现算法细节，而是把仓库中分散的专项技能按研发顺序组织成一条可执行的流水线。原文在 plugins/agentic-awesome-skills-claude/skills/ai-ml/SKILL.md 中将其定位为 "Comprehensive AI/ML workflow for building LLM applications, implementing RAG systems, creating AI agents, and developing machine learning pipelines"，并明确指出该 bundle 的职责是 "orchestrates skills for production AI development"。

仓库中存在与之并列的同类工作流，例如 data/workflows.json 中注册的ship-saas-mvp（SaaS MVP 交付工作流），可见 workflow-bundle 是仓库的一等公民结构：一份编排文档 + 一组被调度的技能，共同构成可复用的交付路径。

1.2 何时启用 ai-ml 工作流

根据原文档，以下六类任务应当启用本工作流：

• 构建 LLM 驱动的应用（Building LLM-powered applications）
• 实现 RAG（Retrieval-Augmented Generation）系统
• 创建 AI Agent
• 开发 ML 流水线
• 为应用添加 AI 功能
• 搭建 AI 可观测性

从数据层看，这些场景与 data/catalog.json 中ai-ml条目的triggers字段高度一致——catalog 将该条目的触发词明确收录为ai、ml、machine、learning、llm、application、rag、agent、architecture、pipelines，这意味着在支持目录检索的 Agent 环境中，上述关键词的出现会自动把任务路由到ai-ml工作流。

二、工作流全景：七个阶段的编排总览

原文档将整个 AI/ML 研发流程划分为七个阶段，每个阶段都包含三个要素：待调度的技能清单（Skills to Invoke）、要执行的动作（Actions）、可直接复制粘贴给 Agent 的提示词（Copy-Paste Prompts）。整体链路如下：

下文将逐一展开每个阶段，并给出调度技能的仓库源码依据。

三、Phase 1：AI 应用设计——先定架构，再写代码

3.1 本阶段调度的技能

• ai-product：AI 产品开发
• ai-engineer：AI 工程
• ai-agents-architect：Agent 架构
• llm-app-patterns：LLM 应用模式

其中ai-product的实现文档位于 skills/ai-product/SKILL.md，它的定位句是 "Every product will be AI-powered"，强调把 LLM 集成模式、RAG 架构、可扩展的提示词工程、用户信任的 AI UX 以及成本优化统一纳入产品设计。该技能要求在执行前先阅读其 详细指南，把其中的安全性、前置条件与验证要求视为强制项。

3.2 本阶段要完成的动作

1. 定义 AI 用例（Define AI use cases）
2. 选择合适的模型（Choose appropriate models）
3. 设计系统架构（Design system architecture）
4. 规划数据流（Plan data flows）
5. 定义成功指标（Define success metrics）

3.3 Copy-Paste 提示词

原文档提供了两条可直接复用的提示词：

Use @ai-product to design AI-powered features

Use @ai-agents-architect to design multi-agent system

设计要点：本阶段的成功标准是"可度量的用例 + 确定的模型选型 + 有依据的架构"。成功指标的定义尤其重要，它决定了后续 Phase 6 可观测性阶段要采集哪些指标。建议在此阶段同步产出架构决策记录（ADR），作为后续各阶段的验收基线。

四、Phase 2：LLM 集成——打通模型调用通道

4.1 本阶段调度的技能

• llm-application-dev-ai-assistant：AI 助手开发
• llm-application-dev-langchain-agent：LangChain Agent
• llm-application-dev-prompt-optimize：提示词工程
• gemini-api-dev：Gemini API

以llm-application-dev-ai-assistant为例，其实现文档见 skills/llm-application-dev-ai-assistant/SKILL.md。该技能专注于自然语言理解、上下文管理与系统集成的生产级 AI 助手开发，并指向resources/implementation-playbook.md获取详细模式与示例。gemini-api-dev则覆盖 Gemini 这一具体模型供应商的接入细节。

4.2 本阶段要完成的动作

1. 选择 LLM 提供商（Select LLM provider）
2. 配置 API 访问（Set up API access）
3. 实现提示词模板（Implement prompt templates）
4. 配置模型参数（Configure model parameters）
5. 添加流式支持（Add streaming support）
6. 实现错误处理（Implement error handling）

4.3 Copy-Paste 提示词

Use @llm-application-dev-ai-assistant to build conversational AI

Use @llm-application-dev-langchain-agent to create LangChain agents

Use @llm-application-dev-prompt-optimize to optimize prompts

集成要点：本阶段的技术重心是"可观测的通道化"——模型参数（temperature、top_p、max_tokens 等）、流式输出与错误处理应当被封装为统一接口，而不是散落在业务代码中。这与 Phase 6 的追踪（tracing）目标直接衔接：只有在调用点统一收敛后，Langfuse 等工具才能完整捕获每一次 LLM 调用的输入、输出与延迟。

五、Phase 3：RAG 实现——检索质量决定生成质量

5.1 本阶段调度的技能

• rag-engineer：RAG 工程
• rag-implementation：RAG 实现
• embedding-strategies：Embedding 选型
• vector-database-engineer：向量数据库
• similarity-search-patterns：相似度检索
• hybrid-search-implementation：混合检索

5.2 核心技能源码解析：rag-engineer

skills/rag-engineer/SKILL.md 是 RAG 阶段的核心技能，风险评级为critical。它的核心立场是 "retrieval quality determines generation quality - garbage in, garbage out"，并给出五条工程原则：

• 检索质量 > 生成质量：先修检索（Retrieval quality > Generation quality - fix retrieval first）
• 分块大小取决于内容类型与查询模式（Chunk size depends on content type and query patterns）
• Embedding 并非万能，存在盲区（Embeddings are not magic - they have blind spots）
• 始终将检索与生成分开评估（Always evaluate retrieval separately from generation）
• 大多数场景下混合检索优于纯语义检索（Hybrid search beats pure semantic in most cases）

该技能文档还完整给出了六种核心模式与对应适用场景：

5.3 向量数据库技能源码解析

skills/vector-database-engineer/SKILL.md 覆盖 Pinecone、Weaviate、Qdrant、Milvus、pgvector 五类向量数据库，风险评级同为critical。其工作流与最佳实践要点包括：

1. 分析数据特征与查询模式
2. 选择合适的 Embedding 模型
3. 设计分块与预处理流水线
4. 选择向量数据库与索引类型（HNSW、IVF、PQ）
5. 配置元数据 Schema 用于过滤
6. 按需实现混合检索
7. 优化延迟/召回权衡
8. 建立监控与重建索引策略

实践建议（Best Practices）包括：Embedding 维度按用例选择 384–1536、带重叠的分块、用元数据过滤缩小搜索空间、监控 Embedding 漂移、规划索引重建、缓存高频查询、测试召回与延迟的权衡。

5.4 本阶段要完成的动作

1. 设计数据流水线（Design data pipeline）
2. 选择 Embedding 模型（Choose embedding model）
3. 搭建向量数据库（Set up vector database）
4. 实现分块策略（Implement chunking strategy）
5. 配置检索（Configure retrieval）
6. 添加重排序（Add reranking）
7. 实现缓存（Implement caching）

5.5 Copy-Paste 提示词

Use @rag-engineer to design RAG pipeline

Use @vector-database-engineer to set up vector search

Use @embedding-strategies to select optimal embeddings

5.6 高频坑位清单（Sharp Edges）

rag-engineer文档针对生产中常见失败模式给出了具体的规避指引，值得在实现前通读：

• 固定大小分块破坏句子与上下文（HIGH）：固定 token 切分会在句中、段中、语义中断开，导致 embedding 表征不完整。应使用语义分块，尊重句子/段落边界，保留文档结构作为元数据，并加重叠。
• 纯语义检索不做元数据预过滤（MEDIUM）：语义相似 ≠ 相关。应实现混合过滤：先按日期/来源/类目预过滤，再向量检索。
• 不同内容类型共用同一 Embedding 模型（MEDIUM）：文本 Embedding 模型处理代码、领域内容效果差。应按内容类型评估（如代码用 CodeBERT），必要时拆分索引。
• 直接使用第一段检索结果（MEDIUM）：向量检索优化的是召回而非精度。应扩大候选集（如 top 20–50），用 cross-encoder 重排后再取 top-K（如 top 5）。
• 把最大量上下文塞进提示词（MEDIUM）：更多上下文不等于更好。应设最小相似度阈值、限制为真正相关的块、按相关性排序。
• 不单独评估检索质量（HIGH）：端到端评估无法定位是检索失败还是生成失败。应建立带相关标注的检索测试集，用 MRR、NDCG、Recall@K 度量。
• 源文档变更后不刷新 Embedding（MEDIUM）：应跟踪文档版本/哈希，变更时重新嵌入，处理删除文档，必要时为 Embedding 设置 TTL。
• 所有查询类型用同一检索策略（MEDIUM）：关键词型查询与语义型查询应分别处理，用 BM25 + 向量 + RRF 混合方案。

六、Phase 4：AI Agent 开发——从单 Agent 到多智能体系统

6.1 本阶段调度的技能

• autonomous-agents：自主 Agent 模式
• autonomous-agent-patterns：Agent 模式
• crewai：CrewAI 框架
• langgraph：LangGraph
• multi-agent-patterns：多智能体系统
• computer-use-agents：计算机操作 Agent

6.2 核心技能源码解析：langgraph

skills/langgraph/SKILL.md 将 LangGraph 定位为构建有状态、多参与者AI 应用的生产级框架，风险评级critical。其核心能力覆盖：图拓扑设计、状态 Schema 模式、条件分支、持久化策略（checkpointers）、人在环上（human-in-the-loop）、工具集成、错误处理与恢复。该技能的前置条件明确列出 Python 3.9+、langgraph 包、LLM API 访问（OpenAI、Anthropic 等）以及图论基础概念，并要求执行前阅读其 详细指南。

技能文档强调的工程理念是 "graphs make the flow visible and debuggable"——用显式图结构让流程可见、可调试，同时强调在状态设计、持久化、循环防止（防止无限循环）上的严谨性。

6.3 本阶段要完成的动作

1. 设计 Agent 架构（Design agent architecture）
2. 定义 Agent 角色（Define agent roles）
3. 实现工具集成（Implement tool integration）
4. 搭建记忆系统（Set up memory systems）
5. 配置编排（Configure orchestration）
6. 加入人在环上（Add human-in-the-loop）

6.4 Copy-Paste 提示词

Use @crewai to build role-based multi-agent system

Use @langgraph to create stateful AI workflows

Use @autonomous-agents to design autonomous agent

设计要点：Agent 阶段的关键权衡是"自主性 vs 可控性"。自主 Agent 模式（autonomous-agents）追求端到端任务闭环，而 human-in-the-loop 为高风险动作保留人工确认点；LangGraph 的状态管理与持久化（checkpointer）正是支撑这种可控性的基础设施。建议先明确每个 Agent 的角色边界、工具白名单与失败回退策略，再进入实现。

七、Phase 5：ML 流水线开发——训练、注册、部署全链路

7.1 本阶段调度的技能

• ml-engineer：ML 工程
• mlops-engineer：MLOps
• machine-learning-ops-ml-pipeline：ML 流水线
• ml-pipeline-workflow：ML 工作流
• data-engineer：数据工程

7.2 核心技能源码解析：ml-engineer

skills/ml-engineer/SKILL.md 的风险评级为critical，面向生产级 ML 系统。其能力面覆盖：

• 框架栈：PyTorch 2.x（torch.compile、FSDP、分布式训练）、TensorFlow 2.x/Keras（tf.function、混合精度、TF Serving）、JAX/Flax、Scikit-learn/XGBoost/LightGBM/CatBoost、ONNX、Hugging Face Transformers、Ray。
• 模型服务与部署：TensorFlow Serving、TorchServe、MLflow、BentoML、Kubernetes/Helm、云 ML 服务（AWS SageMaker、Azure ML、GCP Vertex AI）、FastAPI/gRPC 推理微服务、TFLite/PyTorch Mobile/ONNX Runtime 边缘部署。
• 模型优化：量化、剪枝、蒸馏。
• 评估与测试：离线评估（交叉验证、时间验证）、在线评估（A/B 测试、champion-challenger）、公平性测试、鲁棒性测试、SHAP/LIME 可解释性。
• 行为准则：优先生产可靠性而非模型复杂度；从第一天就建立监控与可观测性；关注端到端系统性能而非仅模型精度；所有 ML 产物可复现、可版本化。

7.3 核心技能源码解析：mlops-engineer

skills/mlops-engineer/SKILL.md 的风险评级同为critical，覆盖 MLOps 全生命周期：

• 流水线编排：Kubeflow Pipelines、Apache Airflow、Prefect、Dagster、Argo Workflows。
• 实验追踪与模型管理：MLflow、Weights & Biases、Neptune、ClearML、DVC、Git LFS。
• 模型注册与版本化：MLflow Model Registry、AWS/ Azure ML Model Registry、模型血缘追踪与审批流程。
• 云平台栈：分别给出 AWS（SageMaker Pipelines、Batch Transform、S3、CloudWatch/X-Ray）、Azure（Azure ML、AKS、Application Insights）、GCP（Vertex AI、GKE、Cloud Build/Pub/Sub）三套完整栈。
• 监控与合规：数据漂移与性能退化检测、Prometheus/Grafana、GDPR/HIPAA/SOC 2、模型加密与访问控制。
• CI/CD 与 GitOps：自动重训触发、金丝雀/蓝绿部署、回滚与灾备策略。

7.4 本阶段要完成的动作

1. 设计 ML 流水线（Design ML pipeline）
2. 搭建数据处理（Set up data processing）
3. 实现模型训练（Implement model training）
4. 配置评估（Configure evaluation）
5. 搭建模型注册（Set up model registry）
6. 部署模型（Deploy models）

7.5 Copy-Paste 提示词

Use @ml-engineer to build machine learning pipeline

Use @mlops-engineer to set up MLOps infrastructure

工程要点：ML 阶段与 AI Agent 阶段的分界在于"确定性"：ML 流水线强调数据版本化、实验可复现、模型注册与审批门禁；建议引入 champion-challenger 机制，在自动重训与人工审批之间建立平衡，避免模型漂移引发线上事故。

八、Phase 6：AI 可观测性——上线后的命脉

8.1 本阶段调度的技能

• langfuse：Langfuse 可观测性
• manifest：Manifest 遥测
• evaluation：AI 评估
• llm-evaluation：LLM 评估

8.2 核心技能源码解析：langfuse

skills/langfuse/SKILL.md 是该阶段最具代表性的技能，风险评级critical。它由 AAS maintainers 于 2026-09-05 修订，强调"不要仅仅因为存在 LLM 就盲目引入可观测性服务，而应从需要数据支撑的事故或产品决策出发"。其最小可运行示例（最小 Python 观测）如下：

from langfuse import get_client client = get_client() with client.start_as_current_observation(as_type="span", name="synthetic-health-check") as span: span.update(output={"status": "ok"}) client.flush()

该技能文档还给出了完整的接入过程：检查依赖锁与既有埋点（不要混用旧版langfuse.trace()、langfuse.decorators或langfuse.callback与新 SDK）、选择单一集成层（直接 SDK span / 框架回调 / OpenTelemetry 埋点）、把端点与凭据放在源码之外、先用合成数据验证导出权限、执行一次成功与一次失败请求核对 span 树、短生命周期进程必须显式 flush。

隐私与脱敏方面，文档明确"truncation 不等于 redaction（不要将截断视为脱敏）"，建议优先省略原始提示词、用户消息与工具载荷，并在配置的 SDK 版本下使用mask_otel_spans等导出期转换机制。评估部分则强调：评估器错误与低分必须区分对待；LLM 作为评判者（judge）的输出必须通过有界 Schema 与有限范围校验，严禁对任意模型文本直接float()后当作"实测质量"。

8.3 本阶段要完成的动作

1. 搭建追踪（Set up tracing）
2. 配置日志（Configure logging）
3. 实现评估（Implement evaluation）
4. 监控性能（Monitor performance）
5. 追踪成本（Track costs）
6. 配置告警（Set up alerts）

8.4 Copy-Paste 提示词

Use @langfuse to set up LLM observability

Use @evaluation to create evaluation framework

实施要点：可观测性必须覆盖三层——调用链追踪（span 树）、质量评估（离线数据集 + 在线指标）、成本与延迟监控。Phase 2 中统一收敛的 LLM 调用点是本阶段生效的前提；评估数据集（evaluation datasets）应独立于生产流量维护，作为回归测试的输入。

九、Phase 7：AI 安全——最后一道防线

9.1 本阶段调度的技能

• prompt-engineering：提示词安全
• security-scanning-security-sast：安全扫描

9.2 本阶段要完成的动作

1. 实现输入校验（Implement input validation）
2. 添加输出过滤（Add output filtering）
3. 配置限流（Configure rate limiting）
4. 设置访问控制（Set up access controls）
5. 监控滥用（Monitor for abuse）
6. 实现审计日志（Implement audit logging）

安全要点：AI 应用的安全面比传统应用更宽——除了注入攻击，还包括提示注入（prompt injection）、越狱、数据泄露与滥用。建议安全阶段与 Phase 6 联动：告警指标同时服务性能与安全两类目标，审计日志与追踪 span 共享同一个时间基线，便于事后复盘。

十、贯穿全流程的检查清单与质量门禁

原文档在七个阶段之后，给出了一套可勾选的交付检查清单（AI Development Checklist）与最终质量门禁（Quality Gates），建议在每个阶段收尾时逐项核对：

10.1 LLM 集成检查清单

• API 密钥已安全保存（API keys secured）
• 限流已配置（Rate limiting configured）
• 错误处理已实现（Error handling implemented）
• 流式输出已启用（Streaming enabled）
• Token 用量已追踪（Token usage tracked）

10.2 RAG 系统检查清单

• 数据流水线可用（Data pipeline working）
• Embedding 已生成（Embeddings generated）
• 向量检索已优化（Vector search optimized）
• 检索准确率已测试（Retrieval accuracy tested）
• 缓存已实现（Caching implemented）

10.3 AI Agent 检查清单

• Agent 角色已定义（Agent roles defined）
• 工具已集成（Tools integrated）
• 记忆系统可用（Memory working）
• 编排已测试（Orchestration tested）
• 错误处理健壮（Error handling robust）

10.4 可观测性检查清单

• 追踪已启用（Tracing enabled）
• 指标已采集（Metrics collected）
• 评估在运行（Evaluation running）
• 告警已配置（Alerts configured）
• 仪表盘已创建（Dashboards created）

10.5 最终质量门禁（Quality Gates）

• 所有 AI 功能已测试（All AI features tested）
• 性能基准达标（Performance benchmarks met）
• 安全措施就位（Security measures in place）
• 可观测性已配置（Observability configured）
• 文档完整（Documentation complete）

十一、关联工作流与使用边界

11.1 可组合的关联工作流

原文档列出了与本工作流衔接的四个相邻 bundle，用于覆盖 AI 研发之外的周边环节：

• development：应用开发
• database：数据管理
• cloud-devops：基础设施
• testing-qa：AI 测试

这种"工作流间协作"的设计与仓库整体的 bundle 体系一致——在 plugins/agentic-awesome-skills-claude/skills 目录下可以看到大量同类 workflow 目录，每个目录以 SKILL.md 作为编排入口。

11.2 使用边界与限制（Limitations）

原文档明确给出三条使用边界，必须遵守：

• 仅在任务与该文档描述的范围明确匹配时使用本技能（Use this skill only when the task clearly matches the scope described above）
• 输出不能替代针对具体环境的验证、测试或专家评审（Do not treat the output as a substitute for environment-specific validation, testing, or expert review）
• 当必需输入、权限、安全边界或成功标准缺失时，停下来向用户澄清（Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing）

这三条边界与仓库内各专项技能（如 skills/rag-engineer/SKILL.md、skills/ml-engineer/SKILL.md）文末的 Limitations 完全一致，是 AAS 仓库统一的技能行为规范，其精神是：技能输出是"带依据的建议"，而非"免检的结论"。

十二、仓库内的延伸阅读与验证路径

如果你希望进一步验证ai-ml工作流在仓库数据层的注册情况，以及各阶段技能的真实存在性，可以查看以下路径：

• 工作流本体：plugins/agentic-awesome-skills-claude/skills/ai-ml/SKILL.md（本文核心文档）
• 目录注册信息：data/catalog.json 与 data/skills_index.json 中的ai-ml条目（category 为workflow-bundle，risk 为safe）
• 内容索引：data/aas-v1/skill-content-index.v1.json 与 data/aas-v1/skill-content.v1.ndjson 中收录了ai-ml的内容条目
• 各阶段核心技能实现：skills/rag-engineer/SKILL.md、skills/vector-database-engineer/SKILL.md、skills/langgraph/SKILL.md、skills/ml-engineer/SKILL.md、skills/mlops-engineer/SKILL.md、skills/langfuse/SKILL.md、skills/llm-application-dev-ai-assistant/SKILL.md
• 深读指南（执行前必读）：skills/ai-product/references/detailed-guide.md、skills/langgraph/references/detailed-guide.md
• 相邻工作流数据：data/workflows.json（可对照ship-saas-mvp等其他 workflow 的注册结构）

结语

ai-ml是 agentic-awesome-skills 仓库中覆盖面最广的 workflow-bundle 之一：从产品设计到模型接入，从 RAG 检索到多智能体编排，从 ML 训练流水线到可观测性与安全，七个阶段环环相扣，且每个阶段都有仓库内真实存在的专项技能作为执行单元。实践它的正确姿势是：把它当作编排地图，按阶段依次以@技能名唤起专项技能，在每个阶段收尾时对照检查清单与质量门禁验收，遇到不确定的输入、权限与边界立即向用户澄清——这既是本工作流的设计意图，也是 AAS 全仓库统一的技能使用规范。

【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,115+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/gh_mirrors/an/agentic-awesome-skills