Contenu multicanal avec modération
À partir d'un brief produit, générer avec Google ADK quatre déclinaisons (LinkedIn, Instagram, newsletter, WhatsApp) par quatre sous-agents en parallèle, filtrées par des callbacks qui masquent les données personnelles et bloquent les promesses interdites.
Une équipe marketing écrit un brief produit (le document qui résume le produit, la cible, le prix et le ton), puis le décline pour chaque canal : un post LinkedIn, une légende Instagram, un bloc de newsletter, un message WhatsApp. C'est répétitif, et chaque canal a ses codes et sa longueur maximale.
Dans ce lab, vous confiez ce travail à quatre sous-agents ADK qui écrivent en parallèle, et vous placez autour d'eux une modération automatique : avant l'appel au modèle, les données personnelles du brief sont masquées et un brief non conforme est refusé ; après l'appel, tout texte qui contient une promesse interdite ou une donnée personnelle est bloqué.
Ce que vous construisez
flowchart LR
B["Brief produit"] --> P["ParallelAgent declinaisons"]
P --> L["linkedin"]
P --> I["instagram"]
P --> N["newsletter"]
P --> W["whatsapp"]
subgraph CB["Callbacks de chaque sous-agent"]
direction TB
BM["before_model : masquer les données personnelles, refuser un brief non conforme"]
AM["after_model : bloquer promesses interdites et données personnelles"]
end
L & I & N & W -.-> CB
L & I & N & W --> S["État : texte_linkedin, texte_instagram, ..."]
S --> R["Rapport : textes, longueurs, journal de modération"]
moderation.py: les règles en Python pur (expressions régulières), testables sans modèle ;agent.py: 4 sous-agents générés depuis un dictionnaireCANAUX, unParallelAgent, deux callbacks et un rapport ;test_multicanal.py: 15 tests sans clé, avec un faux modèle qui prouve que le modèle ne voit jamais l'e-mail du brief ;- trois essais réels : un brief propre, un brief piège, un brief ambigu.
Pour qui ?
- Développeurs Python qui ont déjà écrit un agent ADK simple, et veulent passer au multi-agents et aux callbacks.
- Équipes marketing ou conformité curieuses de voir où placer des règles automatiques, et ce qu'elles ne savent pas faire.
Prérequis
- Python 3.10 ou plus récent,
pip install -r files/requirements.txt(google-adk 2.10.0). - Une clé d'API Gemini dans
GOOGLE_API_KEY, avecGOOGLE_GENAI_USE_VERTEXAI=FALSE. Les tests tournent sans clé.
Programme
| Module | Leçon | Ce que vous faites |
|---|---|---|
| 1. Cas d'usage et architecture | Un brief, quatre canaux, des règles | Comprendre ParallelAgent, output_key et le cycle de vie des callbacks |
| 2. Construire pas à pas | Un sous-agent par canal | Générer 4 agents depuis un dictionnaire, les lancer en parallèle |
| Les callbacks de modération | before_model qui masque et refuse, after_model qui bloque | |
| 3. Tester, évaluer, exploiter | Tester sans clé avec un faux modèle | Prouver le masquage et le blocage sans appel réseau |
| Essais réels et limites de la modération | Trois briefs réels, ce que les règles laissent passer, la relecture humaine |
En local ou sur Google Cloud ?
Tout tourne en local avec une clé d'API Gemini. Pour mettre l'agent à disposition d'une équipe, les mêmes fichiers se déploient sur Cloud Run ou Vertex AI Agent Engine (voir les labs Avec Google Cloud) ; les callbacks voyagent avec l'agent, sans changement.
Le code
Tout est dans files/ : agent.py, moderation.py, brief_produit.md, brief_piege.md et test_multicanal.py.
الموارد
- example.env.example1 KB
- pyagent.py6 KBعرض
- mdbrief_ambigu.md1 KBعرض
- mdbrief_piege.md1 KBعرض
- mdbrief_produit.md1 KBعرض
- pymoderation.py2 KBعرض
- txtrequirements.txt1 KBعرض
- pytest_multicanal.py4 KBعرض
المراجع
- ADK : agents parallèles (ParallelAgent)google.github.io
- ADK : callbacksgoogle.github.io — before_model, after_model et les autres points d'accroche
- ADK : types de callbacksgoogle.github.io
- ADK : modèles de conception et bonnes pratiques des callbacksgoogle.github.io
- ADK : sécurité et garde-fousgoogle.github.io
- API Gemini : paramètres de sécuritéai.google.dev
- Règlement général sur la protection des données (RGPD)eur-lex.europa.eu