Organisation des comptes rendus de réunion
Étapes d'exécution
Vérifier si l'entrée contient un contenu de réunion identifiable. Distinguer les opinions de discussion, les conclusions finales et les questions en suspens. Extraire les éléments d'action, les responsables et les dates limites. Marquer les informations non vérifiables comme « en attente de confirmation ». Sortir selon le modèle spécifié et recroiser avec l'enregistrement original.
Où `name` et `description` sont des champs obligatoires dans la spécification. `name` donne un nom au Skill actuel, et `description` fournit une description de tâche pour le Skill actuel. Alors, comment un Skill entre-t-il et complète-t-il une tâche ?
Après l'installation d'un Skill, le système ne transmet pas tous les fichiers au grand modèle en une fois. Le processus d'exécution courant se déroule en trois étapes :
1. Le système fournit d'abord les noms et descriptions des Skills installés. Le grand modèle détermine quelles capacités peuvent être pertinentes en fonction de la tâche de l'utilisateur.
2. Une fois un Skill sélectionné, le système charge son `SKILL.md`, et le grand modèle vérifie l'entrée et exécute les étapes principales en conséquence.
3. Ce n'est que lors de l'exécution d'étapes spécifiques qu'il lit les documents de référence, applique les modèles ou exécute les scripts selon les instructions.
Par exemple, lorsqu'un utilisateur demande d'organiser une transcription de réunion en compte rendu, le grand modèle ou l'outil Agent associera la capacité de compte rendu de réunion parmi plusieurs Skills, puis lira ses règles complètes. Si la tâche nécessite également la génération d'un tableau d'éléments d'action Excel, il peut également sélectionner le Skill de traitement de tableaux. Le grand modèle est responsable de formuler des jugements basés sur la tâche actuelle, le Skill fournit des méthodes stables, et la plateforme ou le framework Agent gère le chargement des fichiers et l'invocation des outils.
Par rapport aux Skills maintenus, comment se distinguent-ils des Prompts, des flux de travail et du MCP ? Organisons cela.
<a id="c28-s2"></a>
## <strong>Différence entre Skills et Prompts</strong>
Un Prompt est l'entrée que vous donnez au grand modèle ou à l'Agent dans la tâche actuelle, incluant typiquement les objectifs, les matériaux, les contraintes et les exigences de sortie. Il répond à ce qu'il faut faire cette fois. Par exemple :
```bash
Veuillez organiser cette transcription de réunion en compte rendu, en listant les conclusions et les éléments d'action.
Ce Prompt explique l'objectif de cette fois, mais ne spécifie pas complètement ce qui constitue une conclusion finale, quoi faire lorsqu'un responsable est manquant, si les informations non présentes dans le texte original doivent être complétées, ou quelle structure utiliser pour la sortie. Les Skills sauvegardent ces règles relativement stables à l'avance. La prochaine fois que vous traiterez une transcription de réunion, vous n'aurez qu'à fournir les matériaux actuels et les exigences spécifiques sans recopier l'ensemble des méthodes. Comparaison des Prompts et des Skills selon les perspectives de fonction, support, méthode de chargement et gestion de version :
Se connecter pour rejoindre la discussion
Dimension | Prompt | Skill |
Fonction principale | Décrire la tâche actuelle | Définir comment un type de tâche est généralement accompli |
Cycle d'utilisation | Utilisé la plupart du temps uniquement pour la demande actuelle | Peut être appelé plusieurs fois et maintenu en continu |
Support | Texte, fichiers et contexte dans la conversation | Répertoire contenant |
Contenu | Objectifs, matériaux, contraintes et exigences de sortie | Conditions de déclenchement, étapes, outils, modèles, exceptions et critères d'acceptation |
Méthode de chargement | Entre généralement directement dans le contexte actuel | Peut être chargé couche par couche selon les besoins de la tâche |
Gestion de version | Facilement dispersé dans l'historique des conversations | Peut être inclus dans Git avec des enregistrements de modifications |
Bien sûr, Prompts et Skills ne sont pas mutuellement exclusifs. Les Prompts disent au grand modèle ou à l'Agent quels matériaux traiter cette fois et quelles exigences temporaires existent, tandis que les Skills fournissent les méthodes établies pour ce type de tâche. Le même Skill, face à des entrées différentes, a toujours besoin de Prompts pour expliquer l'objectif actuel. Pas chaque Prompt mérite d'être transformé en Skill.
Un flux de travail est un ensemble d'arrangements opérationnels pour organiser plusieurs nœuds de tâches, typiquement spécifiant l'ordre séquentiel, les branches conditionnelles, le passage des données et la gestion des échecs. Il répond à comment plusieurs étapes se connectent.
Par exemple, un flux de travail de rapport hebdomadaire pourrait être :
Lire les données brutes → Nettoyer les champs → Générer les graphiques → Rédiger l'analyse → Exporter le rapport hebdomadaire
Un Skill se concentre sur comment une unité de capacité doit être accomplie. Chacune des étapes ci-dessus peut être fournie par un Skill, ou accomplies par des scripts, des opérations manuelles ou d'autres outils. La différence entre les deux ne réside pas dans lequel est fixe et lequel est flexible, mais dans des objets de focus différents :
Un Skill peut contenir des étapes fixes ainsi que des jugements conditionnels. Un flux de travail peut également appeler un Agent à un certain nœud, laissant l'Agent décider de l'étape suivante en fonction de la situation réelle.
MCP est le protocole de contexte de modèle, utilisé pour fournir des outils externes, des ressources et des modèles de prompts aux Agents de manière unifiée. Il répond à comment les Agents se connectent et appellent des capacités externes. Through MCP, les Agents peuvent se connecter à des bases de données, des bases de connaissances, des systèmes de gestion de projets, des services cartographiques ou d'autres systèmes métier. Mais une connexion réussie signifie seulement que l'Agent peut utiliser une capacité, pas qu'il sait déjà comment accomplir une tâche métier.
Un Skill peut guider un Agent pour appeler des outils MCP, ou ne pas utiliser MCP du tout. Un service MCP peut également être utilisé par plusieurs Skills. Lors de l'envoi de messages, de la modification d'enregistrements, de la suppression de données, de la génération de coûts ou de la publication publique, les Skills doivent spécifier clairement les points de confirmation.
Concept | Question principale | Contenu typique |
Prompt | Quoi faire cette fois | Objectif actuel, matériaux et exigences temporaires |
Skill | Comment ce type de tâche est généralement fait | Méthodes, règles, ressources, outils et critères d'acceptation |
Flux de travail | Comment plusieurs étapes se connectent | Nœuds, ordre, branches et passage des résultats |
MCP | Comment un Agent se connecte aux capacités externes | Outils, ressources, paramètres et interfaces d'invocation |
Un Skill complet doit avoir à la fois du contenu décrivant la méthode de tâche et des fichiers portant ce contenu. Pour la tâche elle-même, les conditions de déclenchement, l'entrée, les étapes d'exécution, les outils et ressources, la sortie et la gestion des exceptions doivent être clairement écrites. Pour l'organisation des fichiers, au minimum un fichier d'entrée SKILL.md est nécessaire, et les Skills plus complexes peuvent inclure des documents de référence, des modèles, des scripts et des cas de test.
En présence de plusieurs Skills simultanément, le grand modèle compare généralement d'abord le nom et la description de chaque Skill, puis sélectionne le plus petit ensemble le plus pertinent pour l'intention actuelle.
Les conditions de déclenchement permettent au Skill d'aider le grand modèle à trouver la capacité nécessaire actuelle parmi de nombreux Skills, principalement reflétées dans le name et description au début de SKILL.md.
La vérification de l'entrée fait référence à ce que l'Agent ou le grand modèle doit savoir lorsqu'il commence à exécuter un Skill : ce qui est nécessaire, quels matériaux sont requis, lesquels sont optionnels, et comment gérer les informations clés manquantes.
Ce n'est qu'après le passage de la vérification d'entrée que l'Agent commence formellement à traiter la tâche. Les étapes d'exécution doivent décrire clairement la séquence complète de la lecture des matériaux à la livraison des résultats.
Les étapes d'exécution expliquent quoi faire, tandis que les outils et ressources expliquent ce qui est spécifiquement utilisé pour l'accomplir.
Après avoir terminé le traitement, l'Agent doit savoir comment livrer.
La gestion des exceptions traverse l'entrée, l'exécution, l'invocation d'outils et la vérification de sortie — ce n'est pas quelque chose ajouté à la fin.
Le cœur de la conception d'un Skill n'est pas de créer d'abord des répertoires ou d'écrire un long Prompt, mais d'organiser l'expérience de travail humaine en méthodes que l'Agent peut exécuter et vérifier.
Ci-dessous, nous implémentons cette capacité dans un Notebook ModelScope, en utilisant les réunions de bureau de remboursement de frais de déplacement et de réception de clients comme exemples.
Cette expérimentation utilise Qwen3-4B pour le raisonnement. Commencez par exécuter le code suivant pour vérifier les versions actuelles de Python et des packages de dépendances.
Les sections précédentes ont expliqué la composition d'un Skill. Ici, nous écrivons directement les règles de compte rendu de réunion dans des fichiers.
Après la préparation des fichiers, utilisez le SkillLoader de ms-agent pour charger le répertoire local.
Cette expérimentation utilise le Qwen/Qwen3-4B de la communauté ModelScope, déployé comme interface compatible OpenAI via ms-swift.
Ci-dessous, nous utilisons un enregistrement de réunion administrative pour l'appel.
Après l'appel, vérifiez si l'entrée et la spécification de sortie ont été lues.
Après un appel, vérifiez la fiabilité du Skill avec différents matériaux.
Les cas doivent enregistrer à la fois l'entrée et le comportement attendu.
Utilisez check_output() pour vérifier les résultats retournés par le modèle.
run_suite() exécute les cas séquentiellement.
Conservez la version 1.0.0, créez la version candidate 1.0.1 dans un nouveau répertoire.
Chaque version doit sauvegarder les fichiers complets et les enregistrements de test.
Toutes les données expérimentales et le code de ce chapitre sont disponibles à :
https://modelscope.cn/gallery/liucong/0e182f07-3330-40cc-ba59-173b7cc609b7