LangChain @dynamic_prompt pour des instructions de système adaptées aux tâches

Le décorateur @dynamic_prompt de LangChain construit le prompt système à partir du contexte en temps réel plutôt qu’à partir d’une chaîne de caractères fixe intégrée dans la définition de l’agent.

Utilisez-le chaque fois que les instructions doivent varier en fonction de la tâche actuelle, du rôle, du client, de l’étape du flux de travail ou des paramètres de l’application — sans avoir à créer un agent distinct pour chaque variante.

Exemple concret : un assistant RH s’occupe des congés et de la présence, des avantages sociaux ainsi que de l’administration RH. La même instance d’agent modifie ses instructions système en fonction du service pour lequel l’utilisateur a fait appel. Le modèle perçoit toujours une seule conversation ; seul le préambule système invisible change.

Contexte en temps réel vs autorisation

Le contexte de exécution est les données fournies par l’application pour cette invocation — clés de tâche, locale, niveau de plan, flags fonctionnels. @dynamic_prompt lit ce ensemble et renvoie le prompt système pour la prochaine appel au modèle.

Ce n’est pas un mécanisme de contrôle d’accès. Les vérifications de permissions doivent se faire au niveau de l’application ou à l’intérieur des outils. Le décorateur ne fait que définir ce que le modèle doit faire. Mélanger ces deux aspects est une erreur fréquente : un prompt indiquant « vous êtes un administrateur » ne confère pas les API d’administrateur.

Situations pratiques où cela est utile

• Ensembles d’instructions spécifiques à une tâche sur un agent partagé
• Ton, profondeur ou exemples adaptés au rôle
• SaaS multi-locataires avec des textes de politique différents par client
• Étapes de workflow nécessitant des règles différentes au cours d’une session
• Flags fonctionnels qui modifient le comportement du modèle sans redéployer les agents

Localisation des instructions système tout en conservant un seul graphique

Démonstration : Assistant RH avec trois tâches

Tâches affichées dans l’interface utilisateur :

• Congés et présence
• Avantages sociaux des employés
• Administration RH

Rôles : employé ou administrateur. Les congés et les avantages sociaux sont accessibles aux deux ; l’administration n’est réservée qu’aux administrateurs. Cette distinction est importante pour déterminer où placer le contrôle d’accès.

1. Définir l’objet de contexte

UserContext contient des champs que l’application remplit lorsque l’agent est exécuté. task détermine quel bloc d’instructions @dynamic_prompt va retourner. role est vérifié par l’application avant que l’agent ne soit appelé pour des tâches administratives. En excluant le rôle du générateur de prompts, il devient plus facile d’auditer les aspects de sécurité.

2. Construire dynamiquement le prompt

@dynamic_prompt
def hr_dynamic_prompt(request):
    user = request.runtime.context

    if user.task == "leave":
        return """
You are an HR assistant responsible for Leave and Attendance.

Help the user with questions about:
- Leave types
- Leave balances
- Leave application
- Leave carry-forward
- Attendance

Answer only within the Leave and Attendance area.
Keep the response clear and concise.
"""

    elif user.task == "benefits":
        return """
You are an HR assistant responsible for Employee Benefits.

Help the user with questions about:
- Health insurance
- Employee benefits
- Wellness programs
- Company benefit programs

Answer only within the Employee Benefits area.
Keep the response clear and concise.
"""

    elif user.task == "admin":
        return """
You are an HR Administration assistant.

Help the user with administrative HR processes such as:
- Employee onboarding
- Employee offboarding
- HR documentation
- Employee records
- Administrative procedures

Answer only within the HR Administration area.
Keep the response clear and concise.
"""

    return """
You are a general HR assistant.
Answer the user's question clearly and concisely.
"""

Le décorateur marque la fonction comme middleware. LangChain transmet la demande du modèle ; vous récupérez request.runtime.context. Lorsque task vaut "leave", retournez des instructions pour partir ; lorsque c’est "benefits", retournez une copie des informations relatives aux avantages ; lorsque c’est "admin", retournez des directives d’administration. Un seul graphe d’agent, de nombreux prompts système, sans connexion redondante des outils.

3. Connecter le modèle et l’agent une seule fois

Le même modèle de chat et l’agent servent toutes les tâches. Enregistrez hr_dynamic_prompt en tant que middleware afin que LangChain l’appelle juste avant l’étape du modèle. Les outils, la mémoire et les callbacks restent partagés — seul le préambule change.

4. Associer les choix de l’interface utilisateur aux clés des tâches

Un menu simple associe les étiquettes visibles par l’utilisateur à des clés stables :

1 → leave 2 → benefits 3 → admin

Ces clés deviennent le champ task de l’objet contextuel. Les clés stables sont importantes : le texte affiché dans l’interface peut changer sans avoir à réécrire la fonction de prompt.

5. Autoriser en dehors du décorateur

Le contrôle d’accès administratif a lieu avant l’appel à agent.invoke. Si un employé choisit « Administration RH », interrompre immédiatement avec une erreur claire. Les prompts dynamiques modifient les instructions, mais ils ne déterminent pas les droits d’accès. Placer le chemin de refus dans le code de l’application, là où se trouvent déjà les journaux et les métriques.

6. Transmettre le contexte dans l’appel à invoke

context=UserContext(
    user_name="Nachiket",
    role="admin",
    task="leave"
)

Pendant l’étape du modèle, @dynamic_prompt perçoit task="leave" et renvoie le prompt du système de congés. La question de l’utilisateur reste transmise sous forme de message normal d’utilisateur. Le contexte et l’historique des conversations restent clairement séparés.

7. Afficher la réponse

print("\nAssistant:")
print(result["messages"][-1].content)

Le contenu du dernier message de l’agent est ce que vous affichez dans la console ou que vous mettez en évidence dans l’interface utilisateur. À partir de là, vous pouvez ajouter des flux en continu, des citations ou des traces d’appels d’outils sans modifier le middleware dynamic-prompt.

Pourquoi ce modèle est scalable

Vous évitez de cloner des agents pour chaque interface produit. Les instructions restent associées à la fonction middleware, permettant ainsi aux rédacteurs de produits d’éditer le texte en un seul endroit. Les rôles et les permissions restent dans le code de l’application, là où les audits de sécurité sont effectués en premier. Le modèle reçoit toujours une instruction adaptée au flux actuel — sans avoir à coder manuellement trois agents distincts ou trois déploiements séparés.