Chaque système d'agent est confronté au même compromis inconfortable. Vous voulez une base de connaissances approfondie et bien organisée qui survive aux revues de code et à l'historique git. Mais vous avez également besoin que l'environnement d'exécution soit rapide et reste concentré. Ces deux besoins s'opposent. Plus vous conservez d'instructions, plus il devient tentant de toutes les déverser dans le prompt en espérant que tout se passe bien. Cet espoir coûte cher.
Dans l'écosystème Agent Project Context, cette tension se répartit nettement sur deux couches. APC gère la durabilité. APX gère la rapidité. Comprendre comment ils interagissent — et pourquoi APX refuse de précharger chaque définition de compétence — en révèle plus sur l'ingénierie de prompt que la plupart des guides d'optimisation ne vous le diront.
L'archive et le moteur
Le rôle d'APC est la permanence. Il stocke des fichiers de compétences réutilisables sous .apc/skills/ en tant que documents Markdown bruts. Comme ces fichiers résident à l'intérieur de votre dépôt, ils suivent le contrôle de version. Vous pouvez ouvrir une pull request qui modifie une procédure de déploiement. Vous pouvez comparer (diff) un retour en arrière d'une politique de sécurité datant d'il y a six semaines. Vous pouvez auditer exactement ce que l'agent était censé savoir et à quel moment. Cette capacité de révision est cruciale lorsqu'un mauvais déploiement est mis en ligne ou qu'un auditeur de conformité commence à poser des questions.
APX, en revanche, vit l'instant présent. Il gère la conversation réelle entre vous et le modèle. Son objectif n'est pas d'archiver la connaissance, mais de l'utiliser avec précision. Lorsque APX traite les compétences comme un bagage permanent, l'ensemble du système ralentit. La fenêtre de contexte se remplit. Les coûts en tokens augmentent. Pire encore, l'attention du modèle se disperse sur des instructions qui n'ont aucun rapport avec la requête actuelle.
C'est pourquoi le contenu des compétences est chargé à la demande.
Le véritable coût d'un prompt surchargé
La plupart des équipes comprennent que les tokens coûtent de l'argent. Peu d'équipes réalisent que les tokens non pertinents coûtent en précision.
Lorsque APX injecte chaque compétence disponible dans chaque tour d'interaction, le prompt devient bruyant. Le modèle reçoit simultanément le runbook de déploiement, le guide de sécurité, la référence de style d'API, la liste de contrôle de tests et la FAQ d'onboarding. Même avec une grande fenêtre de contexte, la qualité du raisonnement se dégrade lorsque le modèle doit d'abord trier le bruit pour trouver le signal. Il pourrait s'accrocher à une exigence de sécurité destinée aux déploiements de production tout en répondant à une question sur la configuration des tests locaux. Il pourrait halluciner des étapes d'une liste de contrôle de version dans une simple correction de bug. Chaque paragraphe supplémentaire de texte non lié est une distraction potentielle.
La logique est simple. La plupart des interactions n'ont pas besoin de la plupart des compétences. Si vous demandez une correction rapide pour un journal d'erreurs, vous n'avez pas besoin du texte intégral d'un runbook de déploiement ou d'un guide de durcissement de la sécurité. Vous avez besoin que le modèle voie l'erreur, comprenne les conventions de votre projet et modifie le bon fichier. Charger des contenus de compétences non pertinents n'aide pas le modèle à accomplir cela. Cela le force à filtrer des données inutiles avant même de commencer à travailler sur votre problème réel.
Comment fonctionne le chargement à la demande
Le mécanisme est simple mais délibéré. APC continue de détenir la source de vérité. Vos définitions de compétences restent là où elles doivent être : dans .apc/skills/<name>.md.
APX ne duplique pas ces fichiers dans la mémoire active. Au lieu de cela, il compile un registre compact des noms de compétences. Le modèle voit cette liste et comprend qu'un catalogue existe. S'il a besoin de parcourir ou de confirmer les capacités disponibles, il peut invoquer un appel list_skills. Cela lui donne de la visibilité sans le volume.
Lorsque la tâche nécessite réellement la syntaxe exacte, les étapes détaillées ou les contraintes spécifiques encodées dans un fichier de compétence, le modèle appelle load_skill. À ce moment-là, et seulement à ce moment-là, APX récupère le corps Markdown complet depuis APC et l'injecte dans le contexte. L'instruction arrive « à chaud », utilisée une seule fois pour l'usage prévu, et le système évite de la transporter comme un poids mort.
Pensez à la différence entre importer une bibliothèque et coller chaque définition de fonction dans votre fichier principal. Une approche permet de garder votre base de code navigable. L'autre crée un désordre qui ne compile que par accident.
Qui l'emporte lorsque les compétences entrent en collision
APX impose également un ordre de priorité clair lorsqu'il charge des compétences. Tous les environnements ne sont pas identiques, et les conseils génériques ne devraient jamais primer sur les connaissances locales.
Les compétences de projet sont la priorité absolue. Ces fichiers se trouvent dans votre dépôt actuel sous .apc/skills/. Ils capturent les conventions spécifiques de votre équipe, vos wrappers personnalisés, vos normes de nommage héritées et votre chaîne d'outils particulière. Si votre projet définit sa propre méthode de gestion des migrations de base de données, c'est cette définition qui l'emporte.
Les compétences globales arrivent ensuite. Elles couvrent les modèles à l'échelle de l'organisation qui s'appliquent lorsque le projet lui-même ne spécifie rien. Elles agissent comme une bibliothèque standard.
Les compétences d'exécution intégrées se situent au bas de la hiérarchie en tant que solution de repli. Elles gèrent les capacités génériques que chaque agent devrait comprendre, mais qu'aucun projet spécifique n'a pris la peine de redéfinir.
Cette approche par couches signifie que votre dépôt garde le contrôle sur son propre comportement. Une compétence globale ou intégrée ne peut pas détourner accidentellement un flux de travail que votre équipe a intentionnellement personnalisé.
Ce que cela donne en pratique
Imaginez une tâche de maintenance typique. Un collaborateur colle un journal d'erreurs dans le chat. La trace d'appels pointe vers une seule référence nulle dans un module utilitaire. La correction ne nécessite probablement que deux lignes de code défensif.
Dans un système sans chargement à la demande, APX saturerait le contexte avec toutes les compétences qu'il connaît. Le modèle doit alors examiner quarante pages de texte avant de toucher à ces deux lignes. Il voit la liste de contrôle de version et se demande s'il doit incrémenter une version. Il voit le guide de sécurité et envisage une validation des entrées sur une fonction qui nécessite juste une vérification de nullité. Il voit le guide de déploiement et commence à réfléchir aux environnements de pré-production. Le modèle s'égare. La réponse prend plus de temps. Le compteur de tokens s'emballe.
Grâce à la conception à la demande d'APX, le modèle ne voit que les noms. Il sait que [release-checklist], [security-guide], [deployment-runbook] et [error-handling] existent. Il ignore les trois premiers. Il pourrait charger [error-handling] si les conventions de votre projet en matière de sécurité des valeurs nulles sont spécifiques. Il corrige le bug. Les compétences non liées n'ont jamais pénétré la fenêtre de contexte. Le modèle est resté concentré parce que le prompt est resté propre.
La même logique s'applique lorsque la tâche est réellement complexe. Si vous demandez plus tard à l'agent de préparer un déploiement en production, il pourra charger le guide de déploiement, consulter le guide de sécurité et suivre la liste de contrôle de version exactement au moment où ces étapes deviennent pertinentes. La connaissance était toujours là. Elle attendait simplement le bon moment.
La discipline du prompt comme architecture
La séparation entre APC et APX n'est pas qu'un simple détail d'implémentation. C'est une philosophie de discipline du prompt. APC préserve la connaissance pour toujours, la rendant révisable, versionnée et sûre. APX décide quelle part de cette connaissance mérite une place dans le contexte actif à l'instant présent.
Un catalogue de compétences riche est un atout. Un prompt surchargé est un fardeau. L'objectif est de garder votre contexte portable sans le rendre constamment actif. Votre dépôt devrait contenir toutes les instructions que votre équipe a jamais écrites, mais l'agent ne devrait lire que celles qui aident à la tâche immédiate.
Si votre système force le modèle à transporter le contenu de chaque compétence à chaque itération, vous ne construisez pas un assistant intelligent. Vous construisez un bibliothécaire qui traîne l'intégralité des archives à chaque question posée au bureau de référence. Stockez tout. Chargez ce qui compte. C'est ainsi que vous gardez les agents rapides, le contexte propre et le raisonnement aiguisé.