5 concepts clés de l'IA

Avant de commencer à utiliser EasyClaw, prenez 5 minutes pour apprendre ces concepts — ils vous aideront à vraiment comprendre comment fonctionne l'IA, plutôt que de saisir des instructions à l'aveugle.
Vous n'avez pas besoin d'être ingénieur, mais vous devez savoir : pourquoi l'IA peut faire les choses, comment la rendre plus précise et quand elle peut échouer.

1. Agent (Agent intelligent)

Ensuite, clarifions son mode de fonctionnement. Vous pouvez imaginer le processus de travail de l'Agent comme une boucle exécutée de manière répétée : Comprendre la tâche → Élaborer un plan → Appeler des outils → Exécuter l'action → Vérifier le résultat → Ajuster → Rapporter.

1) Comprendre la tâche :
L'Agent déterminera d'abord quel problème vous essayez de résoudre, à quoi ressemble le succès, et s'il existe des contraintes (par exemple, format, ton, délai, ce qu'il ne doit pas faire). Si les informations sont insuffisantes, il peut d'abord vous poser des questions, ou faire les hypothèses nécessaires en les expliquant.

2) Élaborer un plan (décomposer les étapes) :
Les grandes tâches doivent souvent être décomposées en étapes plus petites. Par exemple, « organiser la boîte de réception » pourrait être décomposé en : Analyser les e-mails → Identifier les types (notifications/factures/clients/divers) → Évaluer la priorité → Archiver → Rédiger des brouillons de réponse (si nécessaire) → Résumer la liste. Cette étape détermine « que faire en premier, que faire ensuite ».

3) Appeler des outils/capacités :
C'est aussi la clé qui permet à l'Agent de « faire avancer les choses ». Sans outils, il ne peut en rester qu'au niveau du conseil textuel ; avec des outils, il peut effectivement exécuter des actions, telles que : lire des fichiers, rechercher des informations, envoyer des messages, accéder à des systèmes d'entreprise, générer des documents, etc. Vous verrez l'Agent « se connecter au monde extérieur », et pas seulement générer une phrase.

4) Exécuter et enregistrer :
Aux étapes appropriées, l'Agent déclenchera réellement des opérations (par exemple, appeler une API de service, terminer une tâche de traitement de données, générer du contenu utilisable). En même temps, il enregistre « quelle étape j'ai terminée », ce qui facilite la poursuite ou le retour en arrière pour corrections.

5) Vérification et correction d'erreur :
L'Agent ne vise pas seulement à « sembler terminé » ; il vérifie également si le résultat répond aux exigences. Par exemple : la sortie manque-t-elle des champs clés, enfreint-elle vos exigences de format, y a-t-il des erreurs ou incertitudes évidentes ? S'il n'est pas satisfait, il replanifiera l'étape suivante et continuera d'itérer.

6) Rapporter les résultats et les prochaines étapes :
Enfin, l'Agent résumera le contenu qu'il a terminé, les constatations importantes, et les éléments nécessitant votre confirmation. Vous pouvez voir clairement : ce qu'il a fait, ce qui est terminé, ce qui est encore en cours.

2. Compétence (Capacité/Aptitude)

Dans la boucle de l'Agent, l'étape « appeler des outils/capacités » apparaît fréquemment, et ce qui est appelé est généralement une compétence. Vous pouvez y penser comme : L'Agent est comme un cerveau, la compétence est comme les mains, les pieds et une boîte à outils.

Pour approfondir, expliquons en détail « comment la compétence fonctionne dans la boucle de l'Agent » :

1) L'Agent détermine quelle compétence est nécessaire
Lorsque la tâche entre dans la phase d'exécution, l'Agent analyse les capacités nécessaires pour l'étape en cours. Par exemple, « trouver l'historique des communications d'un client » nécessite une compétence de type « récupérer/lire » ; « rédiger un e-mail de suivi » nécessite une compétence de type « générer du texte/utiliser un modèle » ; « synchroniser la tâche avec le système de tâches » nécessite une compétence de type « écrire/mettre à jour ».

2) L'Agent remplit les paramètres dans la compétence (Entrée)
Les compétences nécessitent généralement un format d'entrée spécifique, comme : mots-clés, plage de temps, identifiant client, public cible, style de sortie, etc. L'Agent extrait le contexte et l'organise dans les paramètres requis par la compétence.
Cette étape détermine si l'exécution est précise : si l'entrée est erronée, la sortie sera probablement incorrecte.

3) La compétence s'exécute et retourne le résultat (Sortie)
Après exécution, la compétence retourne des résultats structurés ou semi-structurés, tels que : listes d'éléments récupérés, résultats de calcul, texte de document généré, codes de statut de retour d'API, etc. Ces résultats peuvent être lus par l'Agent pour la prise de décision ultérieure.

4) L'Agent valide la sortie et passe à l'étape suivante (boucle fermée)
L'achèvement de la compétence n'est pas le point final ; l'Agent vérifie également : si le résultat respecte les contraintes, s'il manque des informations, si une deuxième génération ou correction est nécessaire. S'il n'est pas satisfait, il pourrait appeler une autre compétence (ex. « recherche complémentaire », « réécrire le contenu », « formater la sortie ») et itérer à nouveau. C'est la « boucle fermée coopérative » de la compétence et de l'Agent.

Exemple : Vous demandez à l'Agent de « rédiger un e-mail de suivi aux prospects et de créer un élément de tâche. »
Ceci enchaîne généralement plusieurs compétences, formant une chaîne d'actions complète :

1) Compétence de récupération des informations client : entrée ID/nom du client, sortie nom, entreprise, points clés de la dernière communication ;
2) Compétence d'extraction/résumé d'information : entrée enregistrements de communication, sortie points de douleur clés et éléments réalisés ;
3) Compétence de génération d'e-mail : entrée ton (professionnel/amical), modèle (suivi/clôture), points clés, sortie corps de l'e-mail ;
4) Compétence de génération de tâche : entrée contenu de l'e-mail et suggestions d'action, sortie éléments de tâche (responsable, échéance, étapes) ;
5) Compétence d'écriture dans l'agenda/système de tâches : entrée données structurées de tâche, sortie statut de création réussi ou lien.

Vous remarquerez : l'Agent semble « comprendre le travail de vente », mais derrière cela, des modules de compétence assemblent des capacités réelles en un flux de travail. L'Agent est responsable d'utiliser ces capacités dans le bon ordre.

Continuez à utiliser la « boucle de fonctionnement » de l'Agent pour comprendre la compétence : l'Agent est responsable de la réflexion et de la planification, la compétence est responsable de l'exécution des étapes concrètes. Lorsque l'Agent découvre qu'une tâche nécessite une certaine capacité, il sélectionnera la compétence appropriée, y mettra les paramètres nécessaires, attendra qu'elle retourne les résultats, puis ramènera les résultats dans la boucle pour validation, complément ou planification de l'étape suivante.

Exemple : Vous demandez à l'Agent de « rédiger un e-mail de suivi client pour moi et de générer une tâche. »
Il pourrait appeler différentes compétences :
1) Récupérer les informations client (obtenir le nom, les points de la dernière communication) ;
2) Générer un brouillon d'e-mail (sortie selon le ton/longueur/modèle) ;
3) Générer une liste de tâches (décomposer les prochaines étapes en éléments).
Lorsque ces compétences sont assemblées, elles forment un comportement d'Agent qui « semble très compétent. »

3. Prompt (Instruction/Consigne)

Vous remarquerez que le Prompt et les deux concepts précédents (Agent / Compétence) sont les deux faces de la même logique de fonctionnement : l'Agent a besoin du Prompt pour décider comment procéder, la compétence a besoin du Prompt pour décider quoi remplir et comment vérifier.

La « boucle de travail de l'Agent » peut être comprise comme :
Comprendre la tâche → Élaborer un plan → Décider d'appeler une compétence → La compétence s'exécute → Vérifier le résultat → Ajuster → Rapporter.
Et le rôle du Prompt est de donner des règles à chaque étape, l'empêchant de dévier, de deviner à l'aveugle ou de former une boucle fermée.

1) Le Prompt définit d'abord « l'objectif et les critères de succès » (Pourquoi le faire)
Cette étape détermine les « règles de notation » de l'Agent. Le Prompt doit lui dire : quel est exactement le problème que vous résolvez, et quel résultat compte comme une réalisation.
Par exemple : non pas « aide-moi à rédiger un e-mail », mais « l'e-mail doit inclure quels paragraphes, quel ton, quelle plage de longueur et se terminer par un élément de tâche. »

Sans critères de succès dans le Prompt, l'Agent ne peut produire qu'une sortie qui « semble à peu près correcte », rendant la qualité difficile à vérifier.

2) Le Prompt fournit des « conditions de déclenchement et des contraintes » (Quand faire quoi)
Un Prompt qui peut produire des résultats clarifie généralement : quand appeler une compétence, quand poser des questions.
Par exemple : s'il manque le nom du client ou la date, il doit d'abord demander plutôt que de mettre par défaut « un nom/une date quelconque. »

Cela équivaut à réduire l'incertitude : plus les contraintes sont claires, plus l'Agent est stable.

3) Le Prompt décrit « quelles compétences sont nécessaires et les contrats d'entrée/sortie pour chacune » (Quels outils utiliser)
Le Prompt doit clarifier :
Quelle compétence appeler, quels champs d'entrée elle nécessite, d'où viennent les champs d'entrée, quelles sont les exigences de format ;
et en même temps clarifier : dans quelle structure la sortie de la compétence doit être retournée (ex. champs JSON, listes, tableaux, structure de paragraphe fixe, etc.).

Cette étape est la clé pour que le Prompt soit vraiment « conçu » : transformer « comment faire la prochaine étape » en « invocation de capacité appelable. »

4) Le Prompt exige « vérification et gestion des échecs » (Comment juger si c'est bien fait)
Générer des résultats seuls ne suffit pas ; le Prompt doit spécifier des règles de vérification et des stratégies d'échec. Les approches courantes incluent :
- L'appel de compétence échoue/retourne un résultat vide : diagnostiquer d'abord la cause (erreur de paramètre/permission/réseau/données manquantes) puis réessayer ou dégrader ;
- Sortie manquant des champs clés : doit être complétée ou demander à l'utilisateur, aucune supposition autorisée ;
- Format non conforme : déclencher « compétence de format/compétence de réorganisation/régénérer. »

Cela empêche l'Agent de rester bloqué dans une boucle de « production répétée sans convergence. »

5) Le Prompt définit le « format de sortie final » (Qui utilisera la sortie)
Enfin, le Prompt doit spécifier comment les résultats sont présentés : quels champs doivent être retournés, quels sont les noms de champ, si des résultats structurés sont nécessaires, si des informations traçables sont nécessaires (ex. « si la compétence a été appelée, quelle compétence a été appelée, quelles étaient les entrées/sorties clés »).

4. Mémoire (Mémoire à long terme) / MEMORY.md

Par exemple, vous dites à l'Agent : « Je préfère les réponses concises en français, utilise Python pour le code ».
Si cette préférence est écrite dans la Mémoire dans un format approprié, alors lorsque l'Agent traitera des types de tâches similaires plus tard, il suivra ces règles par défaut ; vous n'avez pas besoin de les répéter sans cesse, et vous êtes beaucoup moins susceptible de rencontrer des problèmes de « style de réponse incohérent à chaque fois ».

Pour garantir que la Mémoire soit vraiment « utilisable », elle doit répondre aux normes des trois concepts précédents : déclenchement stable, entrée claire, sortie vérifiable. En d'autres termes, le contenu écrit dans la Mémoire doit clairement guider la manière dont l'Agent doit procéder ensuite, et non être une expression émotionnelle vague.

Il est recommandé d'écrire la Mémoire dans ce style de « liste de contrôle de règles » :

• Préférences de style d'écriture : ex. « français concis », « conclusions en premier », « pas plus de 3 phrases par paragraphe »
• Exigences de format : ex. « Python pour le code », « sortie de tableau inclut les champs A/B/C », « format de date AAAA-MM-JJ »
• SOP de décision : ex. « demander si l'information est insuffisante, ne pas deviner ; fournir des alternatives avec des étiquettes de risque »
• Contexte à long terme : ex. « mon équipe est en livraison B2B », « les outils courants sont XX (le cas échéant) »

Points clés sur la Mémoire :

1) La Mémoire stocke la configuration à long terme (Pourquoi elle existe)
La principale différence entre la Mémoire et le Prompt est : le Prompt gère cette tâche spécifique, tandis que la Mémoire gère « toutes les tâches futures ». En stockant les préférences et les SOP dans la Mémoire, l'Agent peut appliquer ces règles de manière cohérente sans que vous ayez besoin de les répéter.

Par exemple, si vous écrivez « la langue de sortie par défaut est le français » dans la Mémoire, alors dans toutes les tâches futures, l'Agent priorisera automatiquement une réponse en français.

2) Quand l'Agent utilise-t-il la Mémoire ? (Mécanisme de chargement)
Typiquement, la Mémoire est chargée en premier lorsque l'Agent démarre une nouvelle session ou conversation. L'Agent lit MEMORY.md, extrait les règles/préférences, puis les traite comme faisant partie du contexte système pour cette exécution — similaire à l'ajout d'instructions système supplémentaires.

Ceci est différent du Prompt en cours de conversation : la Mémoire ne change pas pendant la conversation, c'est la « ligne de base stable » pour toutes les exécutions suivantes.

3) Ce qui NE doit PAS aller dans la Mémoire (Définition des limites)
La Mémoire doit contenir : habitudes de travail stables, préférences de format, SOP à long terme, contraintes récurrentes.
La Mémoire NE doit PAS contenir : tâches ponctuelles, données temporaires, informations spécifiques à une session, secrets personnels.

Mélanger ces éléments rend la Mémoire encombrée et l'Agent perd la capacité de distinguer entre « ce qui est permanent » et « ce qui est temporaire ».

4) Comment structurer la Mémoire pour une efficacité maximale
Une bonne Mémoire doit être organisée par catégorie :

• Style de communication : « Toujours répondre en français concis », « structure d'abord, puis détails », etc.
• Valeurs techniques par défaut : « utiliser Python comme langage principal », « utiliser JSON pour les données structurées », etc.
• Règles de décision : « en cas d'incertitude, demander plutôt que deviner », « toujours fournir une évaluation des risques », etc.
• Contexte et arrière-plan : « travailler dans le SaaS B2B », « taille de l'équipe : 5 », etc.
• Informations sur les outils et l'intégration : « le CRM typique est Salesforce », « le système de journalisation est Datadog », etc.

Ainsi, lorsque l'Agent lit la Mémoire, il peut rapidement trouver les règles pertinentes pour le contexte actuel.

5) Maintenance de la Mémoire (La garder fraîche)
La Mémoire n'est pas « écrire une fois, utiliser pour toujours ». À mesure que votre style de travail évolue ou que les règles changent, vous devez périodiquement revoir et mettre à jour la Mémoire pour la garder alignée avec la pratique actuelle.

Une bonne pratique : revoir la Mémoire trimestriellement, supprimer les éléments obsolètes, ajouter les nouveaux modèles établis. Cela garde la Mémoire légère et efficace.

My Work Preferences & SOPs

 Communication Style
  Language: French (concise, conclusion-first)
  Format: bullet points when listing, structured sections for complex info
  Tone: professional but approachable

Technical Defaults
  Primary Language: Python
  Data Format: JSON
  Date Format: YYYY-MM-DD
  Time Zone: UTC+1

Decision Rules
  When information is insufficient: ask clarifying questions, do not assume
  Provide alternatives with risk/benefit analysis
  Include traceable reasoning in complex decisions

Context
  Team: B2B SaaS, 5 people
  Main CRM: Salesforce
  Primary Tools: Python, PostgreSQL, Slack

Process SOPs
  Code review always required before deployment
  Documentation must update when API changes
  Daily standup at 10:00 AM UTC+1
      

5. Âme (Valeurs fondamentales et comportement) / SOUL.md

Si la Mémoire est « ce qui a été retenu », alors l'Âme est « quel genre d'IA devenir. » Par exemple : ne répondre qu'aux questions liées au produit ; les opérations financières nécessitent une double confirmation ; ne jamais demander de mots de passe ou d'identifiants sensibles ; pour les questions juridiques/médicales, doit fournir des clauses de non-responsabilité et orienter vers des canaux professionnels, etc.

Il est recommandé d'écrire l'Âme comme une « liste de contrôle de règles exécutables », couvrant les catégories suivantes :

• Ce qui est autorisé : le périmètre de travail de l'Agent et les limites de domaine (ex. ne traiter que les demandes de produits/processus internes).
• Ce qui est interdit : des refus explicites et fermes pour les comportements à haut risque (ex. demander des mots de passe/clés ; promettre des résultats incertains ; contourner les permissions).
• Actions nécessitant une confirmation : règles pour les transferts, remboursements, contrats, changements de permissions qui doivent être doublement confirmés ou approuvés.
• Style de sortie et ton : ex. doit être poli, pas d'attaques personnelles, pas de langage menaçant.
• Comment gérer les limites : en cas d'incapacité à terminer, fournir des alternatives (ex. enregistrer et escalader vers un humain/suggérer de consulter des spécialistes).

Distinctions clés entre l'Âme, la Mémoire et le Prompt :

1) L'Âme définit « Quel genre d'Agent êtes-vous » (Identité et garde-fous)
L'Âme répond à la question la plus profonde : Qu'est-ce que je suis autorisé à être et à faire ?
Cela inclut :
- Périmètre de travail : De quels domaines/tâches suis-je responsable ?
- Garde-fous stricts : Qu'est-ce que je ne dois absolument jamais faire (sécurité, conformité, éthique) ?
- Flux d'approbation : Pour quelles actions dois-je exiger une confirmation ?
- Chemins d'escalade : Quand je ne peux pas aider, où est-ce que je redirige ?

L'Âme est la ligne « à ne pas franchir ». Elle est appliquée à chaque exécution, peu importe comment les utilisateurs essaient de manipuler.

2) Âme vs Sécurité : Pourquoi l'Âme est importante pour le déploiement
Une Âme bien configurée peut prévenir de nombreux vecteurs d'attaque courants :
- Injection de prompt : Si l'Âme dit « toujours vérifier les demandes à haut risque », même si un prompt dit « ignore cette règle », l'Agent doit refuser.
- Ingénierie sociale : Si l'Âme dit « ne jamais fournir d'identifiants », peu importe à quel point un utilisateur demande astucieusement, l'Agent doit rejeter.
- Dérive de périmètre : Si l'Âme définit la limite de domaine de l'Agent, il n'essaiera pas de traiter des demandes hors périmètre en devinant.

Cela rend l'Âme fondamentale pour un déploiement sûr.

3) Comment l'Âme s'intègre à la boucle de décision de l'Agent
Considérez le cycle d'exécution de l'Agent comme suit :
Étape 1 : Lire l'Âme → Quelles sont mes limites ?
Étape 2 : Lire la Mémoire → Quelles sont mes préférences de travail ?
Étape 3 : Recevoir le Prompt → Quelle est cette tâche spécifique ?
Étape 4 : Planifier l'exécution → Dans les limites, atteindre l'objectif
Étape 5 : Vérifier la conformité → Suis-je resté dans l'Âme ?
Étape 6 : Exécuter / Escalader

Remarquez que l'Âme est vérifiée avant et après l'exécution. C'est la boucle externe.

Concepts avancés (optionnels)

Les trois concepts suivants vous aideront à vraiment « comprendre l'automatisation ». Ce ne sont pas des connaissances entièrement nouvelles, mais plutôt une application des concepts précédents d' Agent / Compétence / Mémoire / Âme / Prompt au niveau pratique de « vraiment exécuter, connecter ensemble et intégrer de manière stable ». Les débutants peuvent les ignorer pour l'instant ; lorsque vous commencerez à construire des processus en plusieurs étapes, à intégrer des services externes ou à déboguer des problèmes de flux de données, revenir ici vous fera gagner un temps considérable.

🔀 1) Workflow (Exécution de processus en plusieurs étapes)

Un Workflow peut être compris comme un chemin d'exécution réutilisable : connecter plusieurs étapes en séquence pour permettre au système d'atteindre un objectif de manière systématique. Si l'Agent est « un collègue qui peut penser et exécuter », alors le Workflow est « la file de tâches et la méthode de connexion que nous mettons en place pour ce collègue ». Il résout le problème : quand une tâche ne peut pas être accomplie en une seule phrase, comment exécuter de manière fiable plusieurs étapes en chaîne connectée ?

Un Workflow typique contient généralement ces éléments (vous pouvez utiliser ce cadre pour comprendre les capacités multi-étapes d'EasyClaw) :

• Liste d'étapes : Que faire à l'étape 1, à l'étape 2, etc. Chaque étape doit avoir des limites et des responsabilités claires.
• Entrée et sortie : Chaque étape doit produire des résultats structurés que l'étape suivante peut utiliser, pas seulement des « descriptions textuelles ».
• Conditions et branchements : Par exemple, « si un champ critique est manquant, d'abord demander ou récupérer plus de données », sinon passer à l'étape suivante.
• Validation et gestion des erreurs : Par exemple, « si l'analyse échoue, réessayer ou basculer vers une approche alternative ».
• Résumé de sortie : Livrer le résultat final dans un format utilisable (liste de contrôle, rapport, liste de tâches, contenu de notification, etc.).

Comment le Workflow s'aligne-t-il avec les concepts précédents ? Une phrase les relie :
L'Agent gère la prise de décision et la planification, la Compétence gère l'exécution concrète, la Mémoire/l'Âme gèrent les règles et limites à long terme, le Prompt lui dit « comment le faire », et le Workflow relie ces étapes en séquence comme une chaîne.

Exemple : vous devez « escalader une réclamation utilisateur en ticket et notifier la personne responsable. » Un Workflow raisonnable pourrait ressembler à ceci :

1. Collecter l'entrée : Recueillir le contenu de la réclamation, les infos utilisateur, la chronologie depuis le formulaire/message.
2. Extraction d'information : Utiliser l'Agent pour structurer les points clés de la réclamation (ex. type de problème, portée de l'impact, horodatages critiques).
3. Jugement selon les règles : Basé sur l'Âme/les règles, déterminer si haute priorité, nécessite une escalade ou nécessite plus d'informations d'abord.
4. Appeler la compétence de création de ticket : Remplir les champs structurés dans l'API du système de tickets, générer un numéro de ticket.
5. Appeler la compétence de notification : Envoyer le numéro de ticket et le résumé clé à la personne responsable (Feishu/e-mail/IM).
6. Validation du résultat : Confirmer que la création du ticket a retourné un statut de succès, que la notification a été envoyée.
7. Retour synthétique : Sortie à l'utilisateur ou à l'administrateur « Ticket créé + lien/numéro + prochaines étapes. »

Vous remarquerez : le Workflow ne résout pas « comment écrire une explication », mais plutôt « comment enchaîner de manière fiable plusieurs appels d'outils et étapes de validation. » Lorsque vous commencez à traiter des processus complexes (surtout inter-systèmes : IM + tickets + base de données), le Workflow devient votre capacité la plus utile.

📦 2) JSON (Format d'échange de données)

JSON est le format standard pour transmettre des données entre l'Agent et les outils/API externes. Dans l'automatisation multi-étapes, le rôle de JSON est critique : il fait de « l'étape suivante peut-elle obtenir les bonnes données ? » une question vérifiable, et non « pouvons-nous comprendre intuitivement une phrase en langage naturel ? »

Vous pouvez penser à JSON comme : un « conteneur de données structuré » à l'intérieur du système. Au lieu de phrases libres, il contient des champs et des types explicites, tels que : titre du ticket, ID utilisateur, priorité, échéance, contenu de la notification, etc.

Dans le flux de travail d'EasyClaw, JSON apparaît généralement dans ces endroits :

• Entrée et sortie de Compétence : Les compétences nécessitent souvent des champs spécifiques comme entrée, renvoyant des résultats structurés pour la prise de décision de l'Agent.
• Paramètres d'appel d'API : Par exemple, lors de l'appel de l'API Feishu, les paramètres doivent être organisés en JSON.
• Transfert de données entre les étapes : La sortie JSON d'une étape est lue par l'étape suivante.

Pourquoi de nombreux problèmes qui ressemblent à « l'Agent ne peut pas faire cela » proviennent-ils en réalité de JSON ? Les cas courants incluent :

• Incompatibilité de nom de champ : L'entrée attendue est user_id, mais l'entrée réelle est userId.
• Champs manquants : Un champ requis est manquant, l'API renvoie une erreur.
• Incompatibilité de type : La date devrait être une chaîne mais a été passée comme nombre, ou devrait être un tableau mais a été passée comme texte.
• Erreur de format JSON : Guillemets manquants, crochets manquants, virgules finales, l'analyse échoue.

Par conséquent, le meilleur ordre de dépannage pour les problèmes d'intégration est généralement :
Vérifier JSON d'abord, puis le Prompt, puis la logique de raisonnement de l'Agent.
Parce que JSON est la base de « si cela va fonctionner. »

🔑 3) Clé API (Identifiant d'accès)

Une Clé API est l'identifiant d'authentification lors de l'accès aux modèles d'IA ou aux services tiers. Sans la bonne Clé API, le système ne peut généralement pas appeler le modèle ou le service correspondant ; même si l'Agent raisonne parfaitement, l'exécution reste impossible.

Dans les scénarios EasyClaw, vous devez distinguer deux cas :

• Utiliser les capacités/crédits officiels par défaut : Les débutants n'ont généralement pas besoin de leur propre clé, car la plateforme a déjà configuré l'accès pour vous.
• Intégrer des modèles personnalisés/services personnalisés : Vous devez remplir la Clé API à l'endroit approprié et diriger l'Agent/la Compétence vers ce modèle.

La Clé API ne concerne pas seulement « pouvoir ou ne pas pouvoir utiliser », mais affecte également « quelles capacités, quel coût et quelle stabilité » :

• Sélection du modèle : Différentes clés/modèles peuvent fournir une qualité de raisonnement, une vitesse et des performances de format de sortie différentes.
• Contrôle des coûts : Certaines plateformes facturent à l'utilisation ; le compte/quota de la clé affecte le budget disponible.
• Limites de permission : Certaines clés de service peuvent n'autoriser que des appels d'API limités, provoquant l'échec d'une exécution de compétence spécifique.

Dépannage courant pour « l'appel de compétence a échoué » :
Confirmer si la Clé est correctement remplie, si la Clé est expirée/quota insuffisant, si cette Clé a les permissions d'appel.
Si l'API renvoie une erreur d'authentification (401/403), suspecter d'abord la configuration de la Clé API.

Quand devez-vous sérieusement étudier ces concepts ? (Référence rapide)

• Vous construisez une automatisation multi-étapes : Le Workflow détermine si la chaîne peut fonctionner de manière stable.
• Vous intégrez Feishu/systèmes d'entreprise/API externes : JSON détermine si les données sont transférées correctement et peuvent être analysées.
• Vous intégrez votre propre modèle ou service personnalisé : La Clé API détermine si vous pouvez appeler la capacité correspondante.
• Vous débuggez « peut expliquer mais ne peut pas exécuter » ou « l'exécution échoue sans indice » : Habituellement, dépanner l'enchaînement du Workflow, la structure JSON, les permissions de la Clé API dans cet ordre est le plus rapide.