Open Interpreter.

Prendre en compte la version que vous installez

Open Interpreter a changé depuis le début du projet Python. La version officielle actuelle est un agent de terminal sur Rust, créé sur la base du Codex et conçu pour choisir différents fournisseurs. L'ancien code Python continue de vivre séparément dans la communauté. Par conséquent, l'ancien guide d'installation ou de démonstration peut décrire un processus de produit différent.

Cette carte porte sur la commande interpreter actuelle et sa documentation. Le rôle propre du projet est de configurer l’accès aux modèles et l’environnement de l’agent, plutôt que de proposer son propre modèle de langage.

Travail à l'intérieur du projet

L'agent démarre dans le dossier du projet, lit les fichiers, propose des modifications et exécute les commandes. Les instructions suivantes sont utilisées : AGENTS.md, skills et MCP. Pour les éditeurs compatibles, ACP est fourni. Les sessions peuvent être poursuivies et le modèle et la méthode de connexion sont sélectionnés dans les paramètres.

Il est préférable de lier la requête d'entrée au résultat observé. Au lieu de « améliorer le projet » général, spécifiez une erreur spécifique, la limite des modifications acceptables et la méthode de vérification. Cela aide à garder le contrôle même avec une tâche de longue haleine dans laquelle un agent doit constamment rechercher le contexte et modifier plusieurs fichiers.

Reproduire d'abord l'erreur

Par exemple, une fonction gère mal une date lors d’un changement de mois. Demandez à l’agent d’en trouver la cause, de fournir une entrée minimale reproduisant l’erreur et de préparer un correctif limité sans modifier l’interface publique. Demandez aussi une courte liste des fichiers modifiés et des vérifications exécutées.

Après le travail, ouvrez le diff. Vérifiez que le correctif concerne le cas indiqué sans modifier les règles voisines. Une commande terminée avec succès ne confirme que cette exécution; les autres comportements peuvent rester non testés. Ce scénario explique comment formuler une tâche et ne prétend pas rendre compte d’un test personnel de l’agent.

Pouvoirs et modèle

Dans la documentation sont séparés sandbox et le mode de coordination. L'un limite les actions techniquement disponibles, l'autre détermine quand l'agent doit demander l'autorisation. Ces paramètres doivent être lus avant de connecter des secrets de travail ou des commandes ayant des conséquences externes.

Vous pouvez utiliser un fournisseur distant ou un modèle local. Le travail local avec les fichiers ne signifie pas en soi le calcul local de la réponse : dans la connexion au cloud, le contexte est transmis au fournisseur. Le comportement des outils dépend également des capacités du modèle choisi.

Budget de démarrage autonome

L'open source est distribué sur Apache-2.0, mais les calculs restent un élément de dépense distinct. Les poids locaux ont besoin de mémoire et d'un équipement approprié; le fournisseur d'API considère l'utilisation selon ses propres règles. Pour la première rencontre, choisissez un petit projet, une charge de travail claire et des résolutions limitées. Cela permet d’évaluer le résultat et les coûts sans modifier de manière complexe l’ensemble de l’environnement de travail.

Pour quelles tâches convient-il

• Modifier la base de code de manière limitée
• Analyser le projet avec le modèle sélectionné
• Automatiser l'étape de travail répétitive via CLI
• Connecter un agent à un éditeur compatible