Rédiger des instructions efficaces pour les agents déclaratifs

Les agents déclaratifs sont des versions personnalisées de Microsoft 365 Copilot qui vous aident à créer des expériences personnalisées en déclarant des instructions, des actions et des connaissances spécifiques. Pour rédiger des instructions efficaces pour votre agent déclaratif, tenez compte des questions suivantes :

• Quel objectif votre agent doit-il atteindre ?
• Quels flux de travail envisagez-vous pour vos utilisateurs finaux ?
  • Y a-t-il une logique métier que vous souhaitez incorporer ?
  • Souhaitez-vous incorporer une expérience utilisateur final ?
• Pour chaque workflow, pouvez-vous fournir des instructions pas à pas pour l’agent ?

Si votre agent déclaratif a également des plugins API en tant qu’actions, le document OpenAPI de votre plugin aide l’agent à comprendre toutes les instructions faisant référence à l’API. Pour plus d’informations, consultez Comment rendre un document OpenAPI efficace dans l’extension de Copilot.

Ces instructions s’adressent aux développeurs et aux créateurs qui utilisent Agent Builder dans Microsoft 365 Copilot ou Microsoft 365 Agents Toolkit pour créer des agents déclaratifs. Pour plus d’informations sur la façon d’écrire des instructions pour les agents Copilot Studio, consultez Configurer des instructions de haute qualité pour l’orchestration générative.

Composants d’instruction

Un ensemble d’instructions bien structuré garantit que l’agent comprend son rôle, les tâches qu’il doit effectuer et comment interagir avec les utilisateurs. Les principaux composants des instructions d’agent déclaratif sont les suivants :

• Objectif
• Directives générales, y compris les directives générales, le ton et les restrictions
• Skills

Le cas échéant, incluez également les éléments suivants dans les instructions :

• Instructions détaillées
• Gestion des erreurs et limitations
• Commentaires et itération
• Exemples d’interaction
• Conditions non standard
• Suivi et clôture

Le diagramme suivant montre les principaux composants des instructions de l’agent déclaratif.

Meilleures pratiques pour les instructions d’agent

Utiliser un langage clair et actionnable

• Concentrez-vous sur ce que Copilot doit faire, et non sur ce qu’il faut éviter.
• Utilisez des verbes précis et spécifiques, tels que « demander », « rechercher », « envoyer », « case activée » ou « utiliser ».
• Complétez avec des exemples pour minimiser l’ambiguïté.
• Définissez les termes non standard ou propres à l’organisation dans les instructions.

Créer des flux de travail pas à pas avec des transitions

Divisez les flux de travail en étapes modulaires, sans ambiguïté et non conflictuelles. Chaque étape doit inclure :

• Objectif : Objectif de l’étape.
• Action : Ce que l’agent doit faire et quels outils utiliser.
• Transition : critères clairs pour passer à l’étape suivante ou terminer le flux de travail.

Utiliser une structure stricte

La structure est l’un des signaux les plus forts utilisés pour interpréter l’intention :

• Utilisez des sections pour regrouper des tâches connexes en catégories logiques, sans impliquer de séquence.
• Utilisez des puces pour les tâches parallèles qui peuvent être effectuées indépendamment. Évitez les numérotations qui pourraient introduire un ordre inattendu.
• Utilisez des étapes pour les actions qui doivent se produire dans une séquence requise et réservez-les uniquement aux vrais flux de travail.

Rendre les tâches atomiques

Décomposez les instructions multiactions en unités clairement séparées. Cette approche réduit l’ambiguïté et empêche le modèle de fusionner ou de réinterpréter les tâches.

• Au lieu de : Extrayez les métriques et résumez les résultats.
• Procédez comme suit :
  1. Extraire les métriques.
  2. Résumez les résultats.

Spécifiez toujours le ton, le niveau de détail et le format de sortie

Si vous ne spécifiez pas le ton et le niveau de détail, le modèle de langage peut déduire ces attributs, ce qui peut entraîner un comportement incohérent d’un modèle à l’autre. Par exemple, spécifiez :

• Ton : professionnel et concis.
• Résultat : Trois puces par section.
• Retourner uniquement le format demandé ; pas d’explications.

Instructions de structure dans Markdown

Pour mettre en évidence et clarifier l’ordre des étapes, utilisez Markdown.

• Utilisez #, ##et ### pour les en-têtes de section.
• S’utilise - pour les listes non triées et 1. pour les listes numérotées. Utilisez des listes non ordonnées, sauf si l’ordre des étapes est important, auquel cas utilisez des listes numérotées.
• Mettez en surbrillance les noms d’outils ou de systèmes (par exemple, Jira, ServiceNow, Teams) à l’aide d’apostrophes inversées (''''').
• Mettre les instructions critiques en gras à l’aide de **.

Des titres clairs et des structures de liste cohérentes aident le modèle à comprendre la hiérarchie prévue. Évitez de mélanger les types de listes de manière à introduire une interprétation involontaire.

Fournissez le vocabulaire du domaine

Définir des termes spécialisés, des formules, des acronymes et un langage spécifique au jeu de données. Cette définition empêche toute inférence incorrecte et garantit une interprétation cohérente.

Référencer explicitement les fonctionnalités, les connaissances et les actions

Indiquez clairement les noms des actions, des capacités ou des sources de connaissances impliquées à chaque étape.

• Actions : par exemple, « Utiliser Jira pour récupérer des tickets ».
• Connaissances sur le connecteur Copilot : Par exemple, « À utiliser ServiceNow KB pour les articles d’aide ».
• Connaissances SharePoint : Par exemple, « Référencer des documents internes SharePoint ou OneDrive ».
• Email messages : par exemple, « Vérifiez les e-mails des utilisateurs pour obtenir des informations pertinentes ».
• Messages Teams : Par exemple, « Rechercher dans l’historique des conversations Teams ».
• Interpréteur de code : Par exemple, « Utiliser l’interpréteur de code pour générer des graphiques à barres ou à secteurs ».
• Connaissances sur les People : par exemple, « Utiliser la connaissance des personnes pour récupérer les e-mails des utilisateurs ».

Réponses de terrain aux sources de connaissances configurées

Les modèles linguistiques disposent de connaissances intégrées à partir de leurs données d’entraînement. Dans de nombreux scénarios d’agent, vous souhaitez que l’agent s’appuie uniquement sur les sources de connaissances que vous configurez, et non sur les connaissances internes du modèle. Cette approche garantit que les réponses sont précises, cohérentes et traçables à vos données organisationnelles.

La méthode recommandée pour empêcher le modèle de s’appuyer sur ses connaissances intégrées est de définir la discourage_model_knowledge propriété true sur l’objet special_instructions de votre manifeste d’agent. Lorsque cette option est activée, l’agent fait de son mieux pour éviter de générer des réponses à partir des connaissances du modèle et s’appuie plutôt sur vos sources de connaissances configurées. Pour plus d’informations, voir Objet Instructions spéciales.

Fournissez des exemples

Les exemples aident l’agent à comprendre les instructions.

• Pour les scénarios simples, vous n’avez pas besoin de donner d’exemples.
• Pour les scénarios complexes, les agents déclaratifs fonctionnent mieux avec des invites à quelques coups. C’est-à-dire donnez plus d’un exemple pour illustrer différents aspects ou cas limites.

Contrôler le raisonnement par la formulation

Votre formulation indique le degré de raisonnement que vous souhaitez que le modèle applique.

Raisonnement profond

Pour augmenter la profondeur :

• Utiliser des verbes de raisonnement explicites (analyser, dériver, évaluer, justifier).
• Ajoutez des indices de méta-raisonnement (réfléchir étape par étape, réfléchir, vérifier la logique).
• Structurer les tâches en plusieurs étapes dépendantes.

Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.

Pour détecter quand le raisonnement profond a été sélectionné :

Before answering, report in one sentence whether you needed deep reasoning or minimal reasoning to solve this. Then provide the final answer only.

Raisonnement modéré (équilibré)

Pour équilibrer le raisonnement :

• Demandez une explication concise mais structurée.
• Fournissez des contraintes claires, mais pas des signaux de méta-raisonnement.

Provide a concise but structured explanation. Include a short summary, 3 key drivers, and a final recommendation. No step-by-step reasoning required.
Task: Explain the tradeoffs between solution X and Y.

Raisonnement rapide et minimal

Pour réduire la profondeur :

• Brièveté du signal. Spécifier une réponse courte et rapide ; Pas de raisonnement/explication.
• Évitez les verbes analytiques et les structures en plusieurs étapes.
• Utilisez une formulation impérative à intention unique et monophasée.

Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.

Éviter les échecs d’invite courants

Soyez conscient des pièges suivants et de leurs solutions pour éviter les échecs courants.

• Utilisation trop hâtive des outils
  • Problème : Le modèle appelle des outils sans les entrées nécessaires.
  • Solution : Ajouter l’instruction « N’appelez l’outil que si les entrées nécessaires sont disponibles ; Sinon, demandez à l’utilisateur. »
• Formulation répétitive
  • Problème : Le modèle réutilise mot pour mot des exemples de formulation.
  • Solution : encouragez les réponses variées et le langage naturel. Envisagez d’ajouter plus d’un exemple au lieu d’un seul (quelques coups de feu). Essayez de supprimer l’exemple pour économiser sur les jetons.
• Explications détaillées
  • Problème : Le modèle explique trop ou fournit une mise en forme excessive.
  • Solution : Pour limiter le niveau de détail ou la mise en forme, ajoutez des contraintes et des exemples concis.

Ajouter une dernière étape d’auto-évaluation

Une étape de case activée renforce l’exhaustivité et permet de s’assurer que l’agent vérifie l’alignement avec vos instructions avant de répondre. Par exemple : Avant de finaliser, confirmez que tous les éléments de la section A apparaissent dans le résumé.

Appliquer un en-tête stabilisateur si nécessaire

Lorsqu’un agent montre des signes de dérive d’inférence ou de réorganisation d’étape, ajoutez un en-tête court qui indique au modèle d’interpréter les instructions littéralement et d’éviter les inférences. Pour plus d’informations, voir Modèle 8 : Appliquer un en-tête d’exécution littérale pour une stabilité immédiate.

Itérer sur vos instructions

L’élaboration d’instructions pour les agents déclaratifs est souvent un processus itératif. Il se compose généralement des étapes suivantes :

1. Créez des instructions et des amorces de conversation pour votre agent en suivant la structure et le format décrits dans cet article.
2. Publiez votre agent. Les pratiques d’IA responsable (RAI) sont intégrées au processus de validation pour garantir que les agents respectent les normes éthiques. Pour plus d’informations, reportez-vous aux rubriques suivantes :
   • Validation RAI
   • Outils et pratiques de la RAI
   • Applications optimisées par l’intelligence artificielle
3. Testez votre agent.
   1. Pour vérifier que l’agent apporte une valeur ajoutée lors de la réponse, comparez les résultats à ceux de Microsoft 365 Copilot.
   2. Vérifiez que les amorces de conversation fonctionnent comme prévu grâce aux instructions pas à pas.
   3. Vérifiez que l’agent agit conformément aux instructions fournies.
   4. Vérifiez que les invites de l’utilisateur en dehors des amorces de conversation sont gérées de manière appropriée.
4. Itérez sur les instructions pour voir si vous pouvez améliorer la sortie.
   • Modifiez les instructions pour modifier le comportement de l’agent.
   • Essayez d’ajouter des connaissances telles que la recherche sur le web, OneDrive/SharePoint ou les connecteurs Microsoft 365 Copilot, si nécessaire à l’aide d’Agents Toolkit ou de Copilot Studio.

Le diagramme suivant illustre le processus itératif de création et d’affinement des instructions d’agent déclaratif.

Exemples d’instructions

L’exemple d’instructions suivant concerne un agent pouvant contribuer à résoudre les problèmes informatiques courants.

# OBJECTIVE
Guide users through issue resolution by gathering information, checking outages, narrowing down solutions, and creating tickets if needed. Ensure the interaction is focused, friendly, and efficient.

# RESPONSE RULES
- Ask one clarifying question at a time, only when needed.
- Present information as concise bullet points or tables.
- Avoid overwhelming users with details or options.
- Always confirm before moving to the next step or ending.
- Use tools only if data is sufficient; otherwise, ask for missing info.

# WORKFLOW

## Step 1: Gather Basic Details
- **Goal:** Identify the user's issue.
- **Action:**
  - Proceed if the description is clear.
  - If unclear, ask a single, focused clarifying question.
    - Example:
      User: "Issue accessing a portal."
      Assistant: "Which portal?"
- **Transition:** Once clear, proceed to Step 2.

## Step 2: Check for Ongoing Outages
- **Goal:** Rule out known outages.
- **Action:**
  - Query `ServiceNow` for current outages.
  - If an outage is found:
    - Share details and ETA.
    - Ask: "Is your issue unrelated? If yes, I can help further."
    - If yes, go to Step 3. If no/no response, end politely.
  - If none, inform the user and go to Step 3.

## Step 3: Narrow Down Resolution
- **Goal:** Find best-fit solutions from the knowledge base.
- **Action:**
  - Search `ServiceNow KB` for related articles.
  - **Iterative narrowing:** Don't list all results. Instead:
    - Ask clarifying questions based on article differences.
    - Eliminate irrelevant options with user responses.
    - Repeat until the best solution is found.
  - Provide step-by-step fix instructions.
  - Confirm: "Did this help? If not, I can go deeper or create a ticket."
    - If more info is provided, repeat this step.
    - If ticket needed, go to Step 4.
    - If resolved/no response, end politely.

## Step 4: Create Support Ticket
- **Goal:** Log unresolved issues.
- **Action:**
  1. Map **category** and **subcategory** from the `sys_choice` SharePoint file.
     - Use only valid pairs. Leave blank if not clear.
  2. Fetch user's UPN (email) with the people capability.
  3. Fill the ticket with:
     - Caller ID (email)
     - Category, Subcategory (if mapped)
     - Description, attempted steps, error codes, metadata
- **Transition:** Confirm ticket creation and next steps.

# OUTPUT FORMATTING RULES
- Use bullets for actions, lists, next steps.
- Use tables for structured data where UI allows.
- Avoid long paragraphs; keep responses skimmable.
- Always confirm before ending or submitting tickets.

# EXAMPLES

## Valid Example
**User:** "I can't connect to VPN."
**Assistant:**
- "Are you seeing a specific error?"
  (User: "DNS server not responding.")
- "Let me check for outages."
  (No outage.)
- "No outages. Searching knowledge base…"
  (Finds articles. Asks: "Are you on office Wi-Fi or home?")
  (User: "Home.")
- "Try resetting your DNS settings. Here's how…"
- "Did this help? If not, I can create a support ticket."

## Invalid Example
- "Here are 15 articles I found…" *(Overwhelms the user)*
- "I'm raising a ticket" *(without confirming details)*

Modèles d’instructions et modèles de conception

Cette section fournit des modèles et des modèles que vous pouvez ajouter à vos instructions d’agent déclaratif. Les exemples affichés ne sont pas prescriptifs. Utilisez-les comme point de départ et adaptez-les aux exigences de votre cas d’utilisation.

Modèle 1 : Convertir des demandes multitâches ambiguës en flux de travail déterministes

En utilisant ce modèle, vous supprimez l’ambiguïté en définissant des étapes atomiques, des formules explicites et la validation requise. Cette approche garantit un comportement stable et reproductible entre les versions du modèle.

## Task: Metrics and ROI (Deterministic)

### Definitions (Do not invent)
- Metrics to compute: [Metric1], [Metric2], [Metric3]
- ROI definition: ROI = (Benefit - Cost) / Cost
- ROI scope: [e.g., 12 months, Product X only, Region Y]
- Source of truth: Use ONLY the provided document(s) for inputs

### Steps (Sequential — do not reorder)
Step 1: Locate inputs for [Metric1-3] in the document. Quote the section/table name where each input came from.
Step 2: Compute [Metric1-3] exactly as defined above. If any input is missing, stop and ask ONE question listing what's missing.
Step 3: Compute ROI using the ROI definition above. Do not substitute other ROI formulas.
Step 4: Output ONLY the table in the format below.

### Output format
Return a single Markdown table with columns: Metric | Value | Source (section/table) | Notes

### Final check (Self-evaluation)
Before finalizing: confirm every metric has (a) a value, (b) a source, and (c) no assumptions. If assumptions exist, stop and ask the user.

Modèle 2 : Structure parallèle ou séquentielle correcte

En utilisant ce modèle, vous vous assurez que le modèle sépare la logique parallèle et séquentielle. Le modèle exécute correctement les flux de travail sans ajouter ou réorganiser d’étapes.

Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.

Section B — Build the Summary
Step 1: Integrate all findings from Section A.
Step 2: Produce the 2 page call prep summary.

Modèle 3 : Règles de décision explicites

À l’aide de ce modèle, vous ajoutez des règles si/alors explicites qui empêchent l’interprétation involontaire du modèle et appliquent des résultats déterministes. Cette approche empêche le modèle de langage d’essayer de résoudre une logique conditionnelle ambiguë par lui-même, ce qui peut entraîner des branches fusionnées (« faire les deux ») ou la sélection d’un chemin conditionnel incorrect.

Read the product report.
Check category performance.
If performance is stable or improving, write the summary section.
If performance declines or anomalies are detected, write the risks/issues section.

Modèle 4 : Contrat de sortie

Les contrats de sortie fournissent la forme, la structure, le ton et le contenu autorisé, garantissant ainsi la cohérence. Sans contraintes de sortie explicites, votre agent peut produire des explications trop longues, des réponses trop laconiques ou passer d’une version à l’autre de manière imprévisible.

Bonne précision :

Produce a 2-page call-prep briefing:
Page 1 → key metrics: revenue, margin, YoY deltas (calculate as needed).
Page 2 → top themes, risks, opportunities, customer signals.
Tone: Professional. Reasoning: none unless calculation required.

Contrat de sortie :

## Output Contract (Mandatory)
Goal: [one sentence]
Format: [bullet list | table | 2 pages | JSON]
Detail level: [short | medium | detailed] — do not exceed [X] bullets per section
Tone: [Professional | Friendly | Efficient]
Include: [A, B, C]
Exclude: No extra recommendations, no extra context, no “helpful tips”
Example shape:
- Section 1: ...
- Section 2: ...

Utilisez ce modèle lorsque votre sortie doit suivre :

• Un format précis (puces, tableau, JSON, résumé multi-pages).
• Un niveau de détail spécifié (court, moyen, détaillé).
• Un modèle de conformité, d’audit ou destiné au client.
• Processus d’entreprise nécessitant une mise en forme cohérente entre les équipes.

Modèle 5 : Nettoyer la structure Markdown

Un Markdown propre et intentionnel garantit que le modèle peut analyser vos instructions de manière fiable. Des listes mal imbriquées, des en-têtes peu clairs ou une mise en forme incohérente provoquent des étapes fusionnées, une hiérarchie involontaire ou des sections réduites.

## Section A — Extract Data
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.

## Section B — Build the Summary (Sequential)
**Step 1:** Integrate findings from Section A.
**Step 2:** Produce the 2 page call prep summary.

Modèle 6 : Porte d’auto-évaluation

En ajoutant une étape de case activée automatique, vous encouragez le modèle à valider l’exhaustivité, à vérifier l’alignement avec les instructions et à corriger les omissions avant de répondre. Cette étape permet dʼaccroître la cohérence et la fiabilité.

## Section A: Extract Data (Non-Sequential)
Perform these tasks when the user requests data extraction from the document:
- Extract pricing changes.
- Extract margin changes.
- Extract sentiment themes.
Use the **Vocabulary Reference** SharePoint document to interpret acronyms, domain specific terms, and company specific vocabulary.

## Section B: Build the Summary (Sequential)
Perform these steps **in order** when the user requests a call prep summary:
Step 1: Integrate all extracted elements from Section A.
Step 2: Produce a clear, well structured 2 page call prep summary.

## Final Check: Self Evaluation
Before finalizing the output, review your response for completeness, ensure that all Section A elements are accurately represented, check for inconsistencies or uncertainty, and revise the answer if needed.

Modèle 7 : Raisonnement en mode automatique de direction

Les signaux de raisonnement explicites vous permettent de contrôler le degré de réflexion auquel le modèle s’applique. Sans ces conseils, votre agent peut sur-expliquer des réponses simples ou sous-expliquer des décisions complexes.

Déclencher un raisonnement profond :

Use deep reasoning. Break the problem into steps, analyze each step, evaluate alternatives, and justify the final decision. Reflect before answering.
Task: Determine the optimal 3-year migration strategy given constraints A, B, and C.

Forcer un raisonnement rapide et minimal :

Short answer only. No reasoning or explanation. Provide the final result only.
Task: Extract the product name and renewal date from this paragraph.

Utilisez ce modèle lorsque votre flux de travail l’exige :

• Raisonnement approfondi (planification, évaluation des alternatives, logique en plusieurs étapes).
• Récupération ou extraction rapide avec un minimum d’explications.
• Basculement entre les résumés de haut niveau et l’analyse plus approfondie.
• Profondeur cohérente entre plusieurs agents ou cas d’utilisation.

Modèle 8 : appliquer un en-tête d’exécution littérale pour une stabilité immédiate

Un en-tête d’exécution littérale permet de stabiliser temporairement un agent existant. Ce modèle est particulièrement utile comme correctif provisoire pendant que vous mettez à jour le jeu d’instructions complet.

Always interpret instructions literally.
Never infer intent or fill in missing steps.
Never add context, recommendations, or assumptions.
Follow step order exactly with no optimization.
Respond concisely and only in the requested format.
Do not call tools unless a step explicitly instructs you to do so.

Utilisez ce modèle lorsque :

• Vous observez une réorganisation, des étapes ajoutées ou un raisonnement excessif dans les réponses de votre agent.
• Vous avez besoin d’une atténuation rapide à court terme avant d’appliquer des améliorations structurelles plus profondes.
• Vous souhaitez diagnostiquer si l’inférence ou l’ambiguïté des instructions est à l’origine du problème.

Modèle 9 : Évaluer les instructions d’agent déclaratif existantes

Utilisez une invite d’évaluation structurée pour auditer rapidement un agent existant, identifier des faiblesses spécifiques et générer des correctifs précis.

You are reviewing Data Access (DA) agent instructions for stability.

INPUT
<instructions>
[PASTE CURRENT INSTRUCTIONS]
</instructions>

TASK
Concise audit. Identify ONLY issues and exact fixes.

CHECKS
- Step order: identify ambiguity, missing steps, or merged steps → propose atomic, numbered steps.
- Tool use: identify auto-calls, retries, or tool switching → add "use only in step X; no auto-retry".
- Grounding: detect inference, blending, or citation gaps → add "cite only retrieved; no inference; no cross-document stitching".
- Missing-data handling: if retrieval is empty or conflicting → add "stop and ask the user".
- Verbosity: identify chatty or explanatory output → replace with "return only the requested data/format".
- Contradictions or duplicates: resolve discrepancies; prefer explicit over implied.
- Vague verbs ("verify", "process", "handle", "clean"): replace with precise, observable actions.
- Safety: prohibit step reordering, optimization, or reinterpretation.

OUTPUT (concise)
- Header patch (3–6 lines)
- Top 5 changes (bullet list: "Issue → Fix")
- Example rewrite (≤10 lines) for the riskiest step

Utilisez ce modèle lorsque :

• Vous auditez un agent existant qui se comporte de manière incohérente.
• Vous n’êtes pas certain des parties fragiles ou ambiguës du jeu d’instructions.
• Vous souhaitez un processus d’évaluation reproductible pour plusieurs agents déclaratifs au sein d’une organisation.
• Vous avez besoin d’un moyen rapide d’identifier les problèmes structurels, stylistiques ou liés à la sécurité.

Contenu connexe

• Exemple de manifeste d’agent déclaratif.
• Utilisez Copilot Studio pour créer des agents.
• Instructions de validation pour les agents.