Ingénierie du contexte pour les agents AI: vérification de la boucle de contexte Manus

La réponse pratique à Ingénierie du contexte pour les agents AI: Leçons de la construction Manus est de ne pas copier six astuces rapides. Transformez chaque leçon en une invariante que vous pouvez inspecter pendant une course. Un préfixe prompt stable doit avoir une version et un hash. Un outil mentionné dans l'histoire devrait toujours avoir un schéma résolvable. Le matériau compact doit contenir une référence réparable. L'objectif actuel devrait avoir une limite de révision et de fraîcheur. Les actions échouées devraient laisser des preuves éditées. Les actions répétées doivent être comparées à des modifications de sortie. Un rapport terminal devrait toujours nécessiter un reçu de résultat. Ça vous donne un contrat de santé contextuelle. Il peut faire la différence entre une course efficace, une course récupérable, une course faisant des progrès utiles, et une course qui est en fait sûre d'appeler complète. Les hits de cache et les comptes de jetons plus bas aident, mais aucun ne prouve que l'agent a conservé les preuves nécessaires pour terminer correctement. Lisez les leçons de Manus comme des revendications avec des limites L'original poste d'ingénieur à Manus décrit les choix de conception locaux réalisés lors de la construction de son cadre d'agents. Son auteur rapporte un ratio moyen de jetons entrée sortie d'environ 100:1 pour Manus et soutient que le comportement de préfixe cache compte donc beaucoup pour la latence et le coût. L'article recommande: maintenir le préfixe prompt stable et la détermination de la sérialisation déterministe; masquer les actions au lieu de supprimer les définitions d'outils au milieu de l'exécution; Externaliser le contexte de grande taille aux fichiers réparables; réécriture d'une liste de tâches afin que l'objectif soit récemment attiré l'attention; conserver les actions et observations ratées afin que le modèle puisse s'adapter; l'introduction de variations contrôlées pour résister aux comportements répétitifs. Ce sont des hypothèses d'ingénierie utiles, pas des seuils universels. Les caches des fournisseurs diffèrent. Certaines périodes d'exécution peuvent rendre les schèmes d'outils historiques en toute sécurité. Une URL peut être conservée mais devenir plus tard inaccessible. Les traces de la pile brute peuvent contenir des secrets. Répéter l'objectif toutes les huit étapes est une valeur d'essai, pas une loi générale. Les éléments indépendants de preuve s'opposent également au fait de considérer la capacité de contexte annoncée comme une garantie de santé. Anthropic's orientation en matière d'ingénierie contextuelle définit le contexte comme l'état d'inférence complet des instructions du système, des outils, des données externes et de l'historique des messages et recommande de conserver le plus petit ensemble de signaux élevés qui supporte le comportement souhaité. Il décrit également la récupération juste à temps, la divulgation progressive, la compaction, les notes structurées et la séparation multi agents comme des stratégies différentes avec des coûts différents. Les chromas contrôlés Évaluation de la détérioration du contexte ont testé 18 modèles tout en variant la longueur des entrées et en signalant une dégradation non uniforme. Les distracteurs, la distance sémantique et la structure de la paille de foin ont changé les performances. L'implication opérationnelle est modeste mais importante: à l'intérieur de la limite du contexte n'est pas un verdict. Vous avez encore besoin de preuves que le contexte actuel soutient la décision actuelle. Construire un reçu pour six mutations de contexte Capturez les hashes et les compteurs, pas les instructions crues. Un reçu utile peut être joint à chaque point de décision: Les champs répondent à des questions distinctes. Prefix stabilité est une vérification de l'efficacité. Enregistrer la version stable du modèle et un hachage de contenu sur le préfixe cacheable. Éliminer les valeurs volatiles telles qu'un timestamp par demande de ce préfixe lorsque le temps d'exécution le permet. Un changement de hachage n'est pas automatiquement un échec de tâche: si la sortie utile est toujours en mouvement, classez la course comme dégradée et enquêtez sur le churn. Continuité du schéma des outils est un contrôle de l'intégrité des décisions. Garder un registre de schéma versionné ou une traduction explicite des appels historiques à l'outil à leur contrat définissant. Si une action antérieure indique browser fetch mais que le contexte actuel ne définit plus cette action ou une version compatible, le modèle peut être en train de raisonner à partir d'un enregistrement incomplet. Ça devrait bloquer un verdict sain. Context externe restauré est une vérification de récupération. Un chemin de fichier, une clé objet, une requête ou une URL ne sont que des références. Accouplez le avec une digestion de l'intégrité lorsque c'est possible, une dernière vérification de la disponibilité, la portée et l'opération qui le rétablit. La suppression d'un document de la fenêtre en direct tout en conservant une référence vérifiée est une compression réversible. Le laisser tomber sans référence utilisable est une perte de preuves. Objectif de fraîcheur est une vérification de l'attention. Une révision du plan de tâches devrait identifier l'objectif actif, les contraintes acceptées, les étapes clés et la prochaine décision. Mesurez son âge en étapes ou en temps. N'ajoutez pas à l'infini des plans en double; renouvellez un reçu compact lorsque l'œuvre change significativement ou que sa limite de fraîcheur expire. Rétention de défaillance est un contrôle d'apprentissage et d'audit. Comptez les actions ratées et les dossiers de défaillance préservés. Stocker la classe d'erreur, l'outil, l'identité de l'essai, la décision de réessayer et un digest édité non sortie brute arbitraire. Si deux échecs se sont produits mais qu'un seul enregistrement sécurisé reste, une nouvelle tentative ultérieure ne peut être justifiée par des preuves complètes. Repetition versus progression est une vérification de dérive. Une action répétée n'est pas une boucle en soi: la pagination, les sondages et les retries limitées peuvent être légitimes. Combinez une signature d'action avec un compteur de delta de sortie, une fraîcheur objective, un état de dépendance et un budget réessayer. Trois actions répétées avec des artefacts modifiés peuvent fonctionner; trois sans delta d'état méritent un verdict de risque de boucle. Les leçons du préfixe stable et de la variation contrôlée ne sont pas contradictoires. Gardez le préfixe cacheable et les contrats d'outils déterministes. Appliquer la variation nécessaire après ce préfixe dans des exemples, des observations d'action ou une politique de sélection limitée et mesurer si elle modifie les progrès utiles. Appliquer une règle de priorité au lieu de mesurer les signaux Ne coupez pas ces champs en un seul score opaque. Un préfixe stable et bon marché avec un contexte non récupérable n'est pas principalement sain. Utilisez la priorité: 1. unsafe les références historiques à l'outil ne sont pas résolues, les preuves compactées ne peuvent pas être restaurées ou un enregistrement de défaillance a disparu; 2. loop risk l'objectif est obsolète et les actions se répètent sans modification de sortie; 3. unverified l'agent rapporte l'achèvement du terminal sans reçu de résultat valide; 4. healthy chaque invariante contextuelle passe et le résultat spécifique à la tâche est vérifié; 5. dégradé l'intégrité du contexte reste intacte, mais le préfixe churn ou une autre erreur d'efficacité est présent; 6. WORKING les invariants passent, les sorties utiles changent et la course n'est pas terminale. Cette ordonnance rend délibérément les défaillances d'intégrité plus fortes que les gains d'efficacité. L'appareil d'accompagnement modifie une condition à la fois: Résultat attendu: Les huit cas comprennent un résultat vérifié, une progression intermédiaire utile, un décalage préfixe, une dérive des schémas d'outils, une compaction irréversible, des preuves de défaillance effacées, une répétition de buts obsolètes et une finition déclarée sans reçu. Un résultat est intentionnellement inconvénient: le cas cache churn est dégradé , pas dangereux. Son préfixe a changé, mais les schémas, les références, les échecs et les progrès utiles restent intacts. En revanche, irreversible compaction est unsafe même si son préfixe est stable. C'est la différence entre un problème de coûts et un problème de preuves. Vérifiez le reçu sans enregistrer la conversation. Le reçu doit indiquer si des preuves existent sans télécharger les preuves elles mêmes. Pour le préfixe, conservez un identifiant de modèle et digestez le. Pour les outils, conservez la version du schéma, le nom de l'action et le résultat de compatibilité. Pour le contexte externe, conservez une référence de portée, digeste, nombre de bytes, résultat de disponibilité et temps de fraîcheur. Pour les échecs, conservez une classe et un identifiant de tentative modifiés. Pour progresser, conservez des hachages ou des compteurs pour les objets attendus. Gardez les instructions, les réponses, les informations d'identification, les charges utiles des outils bruts et les itinéraires d'hébergement absolus hors de la télémétrie partagée, sauf si un contrat de données explicite et séparé l'exige. Utilisez trois tests avant d'adopter le contrat. Tout d'abord, exécutez un une répétition de mutation unique . Commencez à partir d'un fichier connu et changez un seul champ. Le verdict devrait être échangé pour la raison que vous attendez. Si la suppression d'une référence réparable laisse l'état en bonne santé, la règle est trop faible. Deuxièmement, utilisez un canary redaction . Mettez un secret synthétique dans une charge utile d'échec, traitez le via le constructeur de reçus et affirmez que le secret est absent tant que la classe d'erreur et la décision de réessayer survivent. La conservation des "fausses choses" n'autorise pas la conservation de contenus sensibles. Troisièmement, exécutez un contre exemple de résultat Z . Fournir au classificateur un message d'agent terminal tout en retenant le reçu de livraison réel. Il doit retourner unverified . Ensuite, ajoutez la vérification spécifique à la tâche une digestion de fichier, le test de réussite, la lecture de l'API de destination ou l'approbation humaineet confirmez que seule cette modification permet healthy . La vérification des résultats est nécessairement spécifique au flux de travail. Une tâche de recherche peut nécessiter une couverture de la source citée et un rapport enregistré. Une tâche de déploiement peut nécessiter une réponse de santé en direct et une parité de version. Une tâche de messagerie peut nécessiter la lecture de la boîte aux lettres de destination. Il n'y a pas de preuve en contexte seulement qu'un objectif arbitraire a été atteint. Utiliser le contrat comme limite et non comme prétention de produit Le message Manus est précieux parce qu'il expose de réelles tensions de conception: l'efficacité du cache par rapport au contexte mutable, les fenêtres plus petites par rapport à la perte irréversible, le comportement stable par rapport à la répétition et le nettoyage des erreurs par rapport à l'apprentissage des preuves. L'action opérationnelle consiste à rendre ces tensions inspectibles. Adoptons le contrat quand vous pouvez répondre à ces questions pour une vraie course: Le préfixe cacheable a t il changé, et était ce attendu ? Peut on encore interpréter chaque action d'outil historique ? Est il possible de rétablir et de vérifier l'intégrité de chaque observation omise? L'objectif actuel est il suffisamment frais pour la prochaine décision? Chaque action échouée a t elle laissé des preuves sûres ? Les actions répétées modifient elles l'état de la tâche ? Quel reçu séparé prouve le résultat demandé? Si aucune réponse d'intégrité est inconnue, conservez unknown ou unsafe ; ne fabriquez pas de vert. Si seulement l'efficacité est dégradée alors que les preuves et les progrès restent solides, maintenir le fonctionnement et résoudre le problème des coûts séparément. Sidewisp est actuellement en préversion privée. Son expérience publique est un site Web d'accès anticipé et une démonstration interactive; la collecte des agents de production et la surveillance du contexte ne sont généralement pas expédiées. L'orientation du produit envisagée consiste à transformer des preuves telles que la fraîcheur, la continuité du contexte, les progrès utiles et les résultats vérifiés en une vision claire de la santé tout en maintenant visibles les limites d'incertitude et d'approbation.