github/OpenHands
1
0
Fork 0
mirror of https://github.com/OpenHands/OpenHands.git synced 2025-12-25 21:36:52 +08:00
Code Issues Packages Projects Releases Wiki Activity

Simplify workspace mounting with SANDBOX_VOLUMES (#8242)

Browse Source
This commit is contained in:
Xingyao Wang 2025-05-07 12:15:52 +08:00 committed by GitHub
parent e8bd59ec22
commit 2f4b70159e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
189 changed files with 7417 additions and 4807 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/about.md
View File

@ -1,15 +1,12 @@
# À propos d'OpenHands
## Stratégie de recherche
La réplication complète d'applications de niveau production avec des LLM est une entreprise complexe. Notre stratégie implique :
Réaliser une réplication complète d'applications de qualité production avec des LLM est une entreprise complexe. Notre stratégie comprend :
1. **Recherche technique fondamentale :** Se concentrer sur la recherche fondamentale pour comprendre et améliorer les aspects techniques de la génération et de la gestion du code
2. **Capacités spécialisées :** Améliorer l'efficacité des composants de base grâce à la curation des données, aux méthodes d'entraînement, et plus encore
3. **Planification des tâches :** Développer des capacités pour la détection des bugs, la gestion des bases de code et l'optimisation
4. **Évaluation :** Établir des métriques d'évaluation complètes pour mieux comprendre et améliorer nos modèles
- **Recherche technique fondamentale :** Concentration sur la recherche fondamentale pour comprendre et améliorer les aspects techniques de la génération et de la gestion du code.
- **Planification des tâches :** Développement de capacités pour la détection de bugs, la gestion de base de code et l'optimisation.
- **Évaluation :** Établissement de métriques d'évaluation complètes pour mieux comprendre et améliorer nos agents.
## Agent par défaut
@ -17,12 +14,12 @@ Notre Agent par défaut est actuellement le [CodeActAgent](agents), qui est capa
## Construit avec
OpenHands est construit en utilisant une combinaison de frameworks et de bibliothèques puissants, fournissant une base solide pour son développement. Voici les principales technologies utilisées dans le projet :
OpenHands est construit en utilisant une combinaison de frameworks et bibliothèques puissants, fournissant une base solide pour son développement. Voici les technologies clés utilisées dans le projet :
![FastAPI](https://img.shields.io/badge/FastAPI-black?style=for-the-badge) ![uvicorn](https://img.shields.io/badge/uvicorn-black?style=for-the-badge) ![LiteLLM](https://img.shields.io/badge/LiteLLM-black?style=for-the-badge) ![Docker](https://img.shields.io/badge/Docker-black?style=for-the-badge) ![Ruff](https://img.shields.io/badge/Ruff-black?style=for-the-badge) ![MyPy](https://img.shields.io/badge/MyPy-black?style=for-the-badge) ![LlamaIndex](https://img.shields.io/badge/LlamaIndex-black?style=for-the-badge) ![React](https://img.shields.io/badge/React-black?style=for-the-badge)
Veuillez noter que la sélection de ces technologies est en cours et que des technologies supplémentaires peuvent être ajoutées ou des technologies existantes peuvent être supprimées à mesure que le projet évolue. Nous nous efforçons d'adopter les outils les plus appropriés et les plus efficaces pour améliorer les capacités d'OpenHands.
Veuillez noter que la sélection de ces technologies est en cours, et des technologies supplémentaires peuvent être ajoutées ou des existantes peuvent être supprimées à mesure que le projet évolue. Nous nous efforçons d'adopter les outils les plus appropriés et efficaces pour améliorer les capacités d'OpenHands.
## Licence
Distribué sous la [Licence](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT.
Distribué sous la [Licence](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT.

8
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/agents.md
View File

@ -1,12 +1,10 @@
# 🧠 Agent Principal et Capacités
## CodeActAgent
### Description
Cet agent implémente l'idée de CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action de **code** unifié à la fois pour la _simplicité_ et la _performance_.
Cet agent implémente l'idée CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action **code** unifié pour la _simplicité_ et la _performance_.
L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut :
@ -14,7 +12,7 @@ L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut :
2. **CodeAct** : Choisir d'effectuer la tâche en exécutant du code
- Exécuter n'importe quelle commande Linux `bash` valide
- Exécuter n'importe quel code `Python` valide avec [un interpréteur Python interactif](https://ipython.org/). Ceci est simulé via une commande `bash`, voir le système de plugin ci-dessous pour plus de détails.
- Exécuter n'importe quel code `Python` valide avec [un interpréteur Python interactif](https://ipython.org/). Ceci est simulé via la commande `bash`, voir le système de plugins ci-dessous pour plus de détails.
![image](https://github.com/All-Hands-AI/OpenHands/assets/38853559/92b622e3-72ad-4a61-8f41-8c040b6d5fb3)
@ -22,4 +20,4 @@ L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut :
https://github.com/All-Hands-AI/OpenHands/assets/38853559/f592a192-e86c-4f48-ad31-d69282d5f6ac
_Exemple de CodeActAgent avec `gpt-4-turbo-2024-04-09` effectuant une tâche de science des données (régression linéaire)_.
_Exemple de CodeActAgent avec `gpt-4-turbo-2024-04-09` réalisant une tâche de science des données (régression linéaire)_.

40
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx
View File

@ -1,35 +1,35 @@
# 🏛️ Architecture du Système
<div style={{ textAlign: 'center' }}>
<img src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38" alt="OpenHands System Architecture Diagram Jul 4 2024" />
<p><em>Diagramme de l'Architecture du Système OpenHands (4 juillet 2024)</em></p>
<img src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38" alt="Diagramme d'Architecture OpenHands 4 juillet 2024" />
<p><em>Diagramme d'Architecture OpenHands (4 juillet 2024)</em></p>
</div>
Ceci est une vue d'ensemble de haut niveau de l'architecture du système. Le système est divisé en deux composants principaux : le frontend et le backend. Le frontend est responsable de la gestion des interactions utilisateur et de l'affichage des résultats. Le backend est responsable de la gestion de la logique métier et de l'exécution des agents.
Voici une vue d'ensemble de l'architecture du système. Le système est divisé en deux composants principaux : le frontend et le backend. Le frontend est responsable de la gestion des interactions utilisateur et de l'affichage des résultats. Le backend est responsable de la gestion de la logique métier et de l'exécution des agents.
# Architecture du Frontend {#frontend-architecture-fr}
# Architecture Frontend {#frontend-architecture-en}
![system_architecture.svg](/img/system_architecture.svg)
Cette vue d'ensemble est simplifiée pour montrer les principaux composants et leurs interactions. Pour une vue plus détaillée de l'architecture du backend, voir la section Architecture du Backend ci-dessous.
Cette vue d'ensemble est simplifiée pour montrer les composants principaux et leurs interactions. Pour une vue plus détaillée de l'architecture backend, consultez la section Architecture Backend ci-dessous.
# Architecture du Backend {#backend-architecture-fr}
# Architecture Backend {#backend-architecture-en}
_**Avertissement** : L'architecture du backend est en cours de développement et est sujette à changement. Le diagramme suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du diagramme._
_**Avertissement** : L'architecture backend est en cours de développement et peut être modifiée. Le diagramme suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du diagramme._
![backend_architecture.svg](/img/backend_architecture.svg)
<details>
<summary>Mise à jour de ce Diagramme</summary>
<summary>Mise à jour de ce diagramme</summary>
<div>
La génération du diagramme d'architecture du backend est partiellement automatisée.
Le diagramme est généré à partir des indications de type dans le code en utilisant l'outil py2puml. Le diagramme est ensuite manuellement revu, ajusté et exporté en PNG et SVG.
La génération du diagramme d'architecture backend est partiellement automatisée.
Le diagramme est généré à partir des annotations de type dans le code en utilisant l'outil
py2puml. Le diagramme est ensuite manuellement révisé, ajusté et exporté en PNG
et SVG.
## Prérequis
- Environnement python fonctionnel dans lequel openhands est exécutable
- Environnement Python opérationnel dans lequel openhands est exécutable
(selon les instructions du fichier README.md à la racine du dépôt)
- [py2puml](https://github.com/lucsorel/py2puml) installé
@ -38,17 +38,17 @@ _**Avertissement** : L'architecture du backend est en cours de développement et
1. Générer automatiquement le diagramme en exécutant la commande suivante depuis la racine du dépôt :
`py2puml openhands openhands > docs/architecture/backend_architecture.puml`
2. Ouvrir le fichier généré dans un éditeur PlantUML, par ex. Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
2. Ouvrir le fichier généré dans un éditeur PlantUML, par exemple Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
3. Revoir le PUML généré et effectuer tous les ajustements nécessaires au diagramme (ajouter les parties manquantes, corriger les erreurs, améliorer le positionnement).
_py2puml crée le diagramme en se basant sur les indications de type dans le code, donc des indications manquantes ou incorrectes peuvent entraîner un diagramme incomplet ou incorrect._
3. Examiner le PUML généré et faire tous les ajustements nécessaires au diagramme (ajouter les parties manquantes, corriger les erreurs, améliorer le positionnement).
_py2puml crée le diagramme basé sur les annotations de type dans le code, donc des annotations manquantes ou incorrectes peuvent entraîner un diagramme incomplet ou incorrect._
4. Revoir la différence entre le nouveau diagramme et le précédent et vérifier manuellement si les changements sont corrects.
_S'assurer de ne pas supprimer des parties qui ont été ajoutées manuellement au diagramme par le passé et qui sont toujours pertinentes._
4. Examiner la différence entre le nouveau diagramme et le précédent et vérifier manuellement si les changements sont corrects.
_Assurez-vous de ne pas supprimer des parties qui ont été ajoutées manuellement au diagramme dans le passé et qui sont toujours pertinentes._
5. Ajouter le hash du commit qui a été utilisé pour générer le diagramme dans le pied de page du diagramme.
6. Exporter le diagramme sous forme de fichiers PNG et SVG et remplacer les diagrammes existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par ex. [PlantText](https://www.planttext.com/))
6. Exporter le diagramme en fichiers PNG et SVG et remplacer les diagrammes existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par exemple [PlantText](https://www.planttext.com/))
</div>
</details>
</details>

114
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md
View File

@ -1,19 +1,17 @@
# 📦 Docker Runtime
Le Docker Runtime d'OpenHands est le composant central qui permet l'exécution sécurisée et flexible des actions d'un agent IA.
Il crée un environnement isolé (sandbox) en utilisant Docker, où du code arbitraire peut être exécuté en toute sécurité sans risquer de compromettre le système hôte.
# 📦 Runtime Docker
Le Runtime Docker d'OpenHands est le composant principal qui permet l'exécution sécurisée et flexible des actions des agents d'IA.
Il crée un environnement en bac à sable (sandbox) en utilisant Docker, où du code arbitraire peut être exécuté en toute sécurité sans risquer le système hôte.
## Pourquoi avons-nous besoin d'un runtime en bac à sable ?
## Pourquoi avons-nous besoin d'un environnement d'exécution isolé ?
OpenHands doit exécuter du code arbitraire dans un environnement sécurisé et isolé pour plusieurs raisons :
1. Sécurité : L'exécution de code non fiable peut poser des risques importants pour le système hôte. Un environnement en bac à sable empêche le code malveillant d'accéder ou de modifier les ressources du système hôte
2. Cohérence : Un environnement en bac à sable garantit que l'exécution du code est cohérente sur différentes machines et configurations, éliminant les problèmes du type "ça fonctionne sur ma machine"
3. Contrôle des ressources : Le bac à sable permet un meilleur contrôle de l'allocation et de l'utilisation des ressources, empêchant les processus incontrôlés d'affecter le système hôte
1. Sécurité : L'exécution de code non fiable peut présenter des risques importants pour le système hôte. Un environnement isolé empêche le code malveillant d'accéder ou de modifier les ressources du système hôte
2. Cohérence : Un environnement isolé garantit que l'exécution du code est cohérente sur différentes machines et configurations, éliminant les problèmes du type "ça marche sur ma machine"
3. Contrôle des ressources : L'isolation permet un meilleur contrôle de l'allocation et de l'utilisation des ressources, empêchant les processus incontrôlés d'affecter le système hôte
4. Isolation : Différents projets ou utilisateurs peuvent travailler dans des environnements isolés sans interférer les uns avec les autres ou avec le système hôte
5. Reproductibilité : Les environnements en bac à sable facilitent la reproduction des bugs et des problèmes, car l'environnement d'exécution est cohérent et contrôlable
5. Reproductibilité : Les environnements isolés facilitent la reproduction des bugs et des problèmes, car l'environnement d'exécution est cohérent et contrôlable
## Comment fonctionne le Runtime ?
@ -23,17 +21,17 @@ Le système Runtime d'OpenHands utilise une architecture client-serveur impléme
graph TD
A[Image Docker personnalisée fournie par l'utilisateur] --> B[Backend OpenHands]
B -->|Construit| C[Image OH Runtime]
C -->|Lance| D[Exécuteur d'actions]
C -->|Lance| D[Action Executor]
D -->|Initialise| E[Navigateur]
D -->|Initialise| F[Shell Bash]
D -->|Initialise| G[Plugins]
G -->|Initialise| L[Serveur Jupyter]
B -->|Génère| H[Agent]
B -->|Génère| I[EventStream]
B -->|Crée| H[Agent]
B -->|Crée| I[EventStream]
I <--->|Exécute l'action pour
obtenir l'observation
via l'API REST
via API REST
| D
H -->|Génère l'action| I
@ -50,80 +48,72 @@ graph TD
1. Entrée utilisateur : L'utilisateur fournit une image Docker de base personnalisée
2. Construction de l'image : OpenHands construit une nouvelle image Docker (l'"image OH runtime") basée sur l'image fournie par l'utilisateur. Cette nouvelle image inclut le code spécifique à OpenHands, principalement le "client runtime"
3. Lancement du conteneur : Lorsqu'OpenHands démarre, il lance un conteneur Docker en utilisant l'image OH runtime
4. Initialisation du serveur d'exécution des actions : Le serveur d'exécution des actions initialise un `ActionExecutor` à l'intérieur du conteneur, mettant en place les composants nécessaires comme un shell bash et chargeant les plugins spécifiés
5. Communication : Le backend OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) communique avec le serveur d'exécution des actions via une API RESTful, envoyant des actions et recevant des observations
6. Exécution des actions : Le client runtime reçoit les actions du backend, les exécute dans l'environnement en bac à sable et renvoie les observations
7. Retour des observations : Le serveur d'exécution des actions renvoie les résultats d'exécution au backend OpenHands sous forme d'observations
3. Lancement du conteneur : Lorsqu'OpenHands démarre, il lance un conteneur Docker utilisant l'image OH runtime
4. Initialisation du serveur d'exécution d'actions : Le serveur d'exécution d'actions initialise un `ActionExecutor` à l'intérieur du conteneur, configurant les composants nécessaires comme un shell bash et chargeant les plugins spécifiés
5. Communication : Le backend OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) communique avec le serveur d'exécution d'actions via une API RESTful, envoyant des actions et recevant des observations
6. Exécution d'actions : Le client runtime reçoit les actions du backend, les exécute dans l'environnement isolé, et renvoie des observations
7. Retour d'observation : Le serveur d'exécution d'actions renvoie les résultats d'exécution au backend OpenHands sous forme d'observations
Le rôle du client :
- Il agit comme un intermédiaire entre le backend OpenHands et l'environnement en bac à sable
- Il exécute différents types d'actions (commandes shell, opérations sur les fichiers, code Python, etc.) en toute sécurité dans le conteneur
- Il gère l'état de l'environnement en bac à sable, y compris le répertoire de travail courant et les plugins chargés
- Il formate et renvoie les observations au backend, assurant une interface cohérente pour le traitement des résultats
- Il agit comme intermédiaire entre le backend OpenHands et l'environnement isolé
- Il exécute divers types d'actions (commandes shell, opérations sur fichiers, code Python, etc.) en toute sécurité dans le conteneur
- Il gère l'état de l'environnement isolé, y compris le répertoire de travail actuel et les plugins chargés
- Il formate et renvoie les observations au backend, assurant une interface cohérente pour le traitement des résultats
## Comment OpenHands construit et maintient les images OH Runtime
L'approche d'OpenHands pour la construction et la gestion des images runtime assure l'efficacité, la cohérence et la flexibilité dans la création et la maintenance des images Docker pour les environnements de production et de développement.
L'approche d'OpenHands pour construire et gérer les images runtime assure efficacité, cohérence et flexibilité dans la création et la maintenance des images Docker pour les environnements de production et de développement.
Consultez le [code pertinent](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py) si vous souhaitez plus de détails.
Consultez le [code pertinent](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py) si vous êtes intéressé par plus de détails.
### Système de balises d'images
### Système de marquage d'images
OpenHands utilise un système à trois balises pour ses images runtime afin d'équilibrer la reproductibilité et la flexibilité.
Les balises peuvent être dans l'un des 2 formats suivants :
OpenHands utilise un système à trois tags pour ses images runtime afin d'équilibrer reproductibilité et flexibilité.
Les tags peuvent être dans l'un des 2 formats suivants :
- **Balise versionnée** : `oh_v{openhands_version}_{base_image}` (ex : `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
- **Balise de verrouillage** : `oh_v{openhands_version}_{16_digit_lock_hash}` (ex : `oh_v0.9.9_1234567890abcdef`)
- **Balise source** : `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
(ex : `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
- **Tag versionné** : `oh_v{openhands_version}_{base_image}` (ex. : `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
- **Tag de verrouillage** : `oh_v{openhands_version}_{16_digit_lock_hash}` (ex. : `oh_v0.9.9_1234567890abcdef`)
- **Tag source** : `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
(ex. : `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
#### Balise source - La plus spécifique
#### Tag source - Le plus spécifique
Il s'agit des 16 premiers chiffres du MD5 du hash du répertoire pour le répertoire source. Cela donne un hash
uniquement pour la source d'openhands
uniquement pour la source openhands.
#### Balise de verrouillage
#### Tag de verrouillage
Ce hash est construit à partir des 16 premiers chiffres du MD5 de :
- Le nom de l'image de base sur laquelle l'image a été construite (ex : `nikolaik/python-nodejs:python3.12-nodejs22`)
- Le nom de l'image de base sur laquelle l'image a été construite (ex. : `nikolaik/python-nodejs:python3.12-nodejs22`)
- Le contenu du `pyproject.toml` inclus dans l'image.
- Le contenu du `poetry.lock` inclus dans l'image.
Cela donne effectivement un hash pour les dépendances d'Openhands indépendamment du code source.
#### Balise versionnée - La plus générique
#### Tag versionné - Le plus générique
Cette balise est une concaténation de la version d'openhands et du nom de l'image de base (transformé pour s'adapter au standard des balises).
Ce tag est une concaténation de la version openhands et du nom de l'image de base (transformé pour s'adapter au standard des tags).
#### Processus de construction
Lors de la génération d'une image...
- **Pas de reconstruction** : OpenHands vérifie d'abord si une image avec la même **balise source la plus spécifique** existe. S'il existe une telle image,
aucune construction n'est effectuée - l'image existante est utilisée.
- **Reconstruction la plus rapide** : OpenHands vérifie ensuite si une image avec la **balise de verrouillage générique** existe. S'il existe une telle image,
OpenHands construit une nouvelle image basée sur celle-ci, en contournant toutes les étapes d'installation (comme `poetry install` et
`apt-get`) sauf une opération finale pour copier le code source actuel. La nouvelle image est balisée avec une
balise **source** uniquement.
- **Reconstruction correcte** : Si ni une balise **source** ni une balise **de verrouillage** n'existe, une image sera construite sur la base de l'image avec la balise **versionnée**.
Dans l'image avec la balise versionnée, la plupart des dépendances devraient déjà être installées, ce qui permet de gagner du temps.
- **Reconstruction la plus lente** : Si les trois balises n'existent pas, une toute nouvelle image est construite à partir de
l'image de base (ce qui est une opération plus lente). Cette nouvelle image est balisée avec toutes les balises **source**, **de verrouillage** et **versionnée**.
- **Pas de reconstruction** : OpenHands vérifie d'abord si une image avec le même **tag source le plus spécifique** existe. S'il existe une telle image, aucune construction n'est effectuée - l'image existante est utilisée.
- **Reconstruction la plus rapide** : OpenHands vérifie ensuite si une image avec le **tag de verrouillage générique** existe. S'il existe une telle image, OpenHands construit une nouvelle image basée sur celle-ci, contournant toutes les étapes d'installation (comme `poetry install` et `apt-get`) sauf une opération finale pour copier le code source actuel. La nouvelle image est marquée uniquement avec un tag **source**.
- **Reconstruction acceptable** : Si ni un tag **source** ni un tag **verrouillage** n'existe, une image sera construite basée sur l'image avec le tag **versionné**. Dans l'image avec tag versionné, la plupart des dépendances devraient déjà être installées, ce qui permet de gagner du temps.
- **Reconstruction la plus lente** : Si aucun des trois tags n'existe, une toute nouvelle image est construite basée sur l'image de base (ce qui est une opération plus lente). Cette nouvelle image est marquée avec tous les tags **source**, **verrouillage** et **versionné**.
Cette approche de balisage permet à OpenHands de gérer efficacement les environnements de développement et de production.
Cette approche de marquage permet à OpenHands de gérer efficacement les environnements de développement et de production.
1. Un code source et un Dockerfile identiques produisent toujours la même image (via des balises basées sur des hashs)
2. Le système peut reconstruire rapidement les images lorsque des changements mineurs se produisent (en s'appuyant sur des images compatibles récentes)
3. La balise **de verrouillage** (ex : `runtime:oh_v0.9.3_1234567890abcdef`) pointe toujours vers la dernière version pour une combinaison particulière d'image de base, de dépendances et de version d'OpenHands
1. Un code source et un Dockerfile identiques produisent toujours la même image (via des tags basés sur des hashs)
2. Le système peut rapidement reconstruire des images lorsque des changements mineurs se produisent (en exploitant des images compatibles récentes)
3. Le tag **verrouillage** (ex., `runtime:oh_v0.9.3_1234567890abcdef`) pointe toujours vers la dernière construction pour une combinaison particulière d'image de base, de dépendances et de version OpenHands
## Système de plugins du Runtime
## Système de plugins Runtime
Le Runtime d'OpenHands prend en charge un système de plugins qui permet d'étendre les fonctionnalités et de personnaliser l'environnement d'exécution. Les plugins sont initialisés lorsque le client runtime démarre.
Le Runtime OpenHands prend en charge un système de plugins qui permet d'étendre les fonctionnalités et de personnaliser l'environnement d'exécution. Les plugins sont initialisés au démarrage du client runtime.
Consultez [un exemple de plugin Jupyter ici](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55) si vous souhaitez implémenter votre propre plugin.
@ -131,8 +121,8 @@ Consultez [un exemple de plugin Jupyter ici](https://github.com/All-Hands-AI/Ope
Aspects clés du système de plugins :
1. Définition des plugins : Les plugins sont définis comme des classes Python qui héritent d'une classe de base `Plugin`
2. Enregistrement des plugins : Les plugins disponibles sont enregistrés dans un dictionnaire `ALL_PLUGINS`
3. Spécification des plugins : Les plugins sont associés à `Agent.sandbox_plugins: list[PluginRequirement]`. Les utilisateurs peuvent spécifier quels plugins charger lors de l'initialisation du runtime
4. Initialisation : Les plugins sont initialisés de manière asynchrone lorsque le client runtime démarre
5. Utilisation : Le client runtime peut utiliser les plugins initialisés pour étendre ses capacités (par exemple, le JupyterPlugin pour exécuter des cellules IPython)
1. Définition du plugin : Les plugins sont définis comme des classes Python qui héritent d'une classe de base `Plugin`
2. Enregistrement du plugin : Les plugins disponibles sont enregistrés dans un dictionnaire `ALL_PLUGINS`
3. Spécification du plugin : Les plugins sont associés à `Agent.sandbox_plugins: list[PluginRequirement]`. Les utilisateurs peuvent spécifier quels plugins charger lors de l'initialisation du runtime
4. Initialisation : Les plugins sont initialisés de manière asynchrone au démarrage du client runtime
5. Utilisation : Le client runtime peut utiliser les plugins initialisés pour étendre ses capacités (par exemple, le JupyterPlugin pour exécuter des cellules IPython)

177
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md Normal file
View File

@ -0,0 +1,177 @@
# API Cloud OpenHands
OpenHands Cloud fournit une API REST qui vous permet d'interagir programmatiquement avec le service. Cela est utile si vous souhaitez facilement lancer vos propres tâches depuis vos programmes de manière flexible.
Ce guide explique comment obtenir une clé API et utiliser l'API pour démarrer des conversations.
Pour des informations plus détaillées sur l'API, consultez la [Référence API OpenHands](https://docs.all-hands.dev/swagger-ui/).
## Obtention d'une clé API
Pour utiliser l'API OpenHands Cloud, vous devrez générer une clé API :
1. Connectez-vous à votre compte [OpenHands Cloud](https://app.all-hands.dev)
2. Accédez à la [page Paramètres](https://app.all-hands.dev/settings)
3. Localisez la section "Clés API"
4. Cliquez sur "Générer une nouvelle clé"
5. Donnez à votre clé un nom descriptif (par exemple, "Développement", "Production")
6. Copiez la clé API générée et conservez-la en lieu sûr - elle ne sera affichée qu'une seule fois
![Génération de clé API](/img/docs/api-key-generation.png)
## Utilisation de l'API
### Démarrer une nouvelle conversation
Pour démarrer une nouvelle conversation avec OpenHands effectuant une tâche, vous devrez faire une requête POST vers le point de terminaison de conversation.
#### Paramètres de la requête
| Paramètre | Type | Obligatoire | Description |
|-----------|------|-------------|-------------|
| `initial_user_msg` | chaîne | Oui | Le message initial pour démarrer la conversation |
| `repository` | chaîne | Non | Nom du dépôt Git pour fournir du contexte au format `propriétaire/repo`. Vous devez avoir accès au dépôt. |
#### Exemples
<details>
<summary>cURL</summary>
```bash
curl -X POST "https://app.all-hands.dev/api/conversations" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}'
```
</details>
<details>
<summary>Python (avec requests)</summary>
```python
import requests
api_key = "YOUR_API_KEY"
url = "https://app.all-hands.dev/api/conversations"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
data = {
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}
response = requests.post(url, headers=headers, json=data)
conversation = response.json()
print(f"Conversation Link: https://app.all-hands.dev/conversations/{conversation['id']}")
print(f"Status: {conversation['status']}")
```
</details>
<details>
<summary>TypeScript/JavaScript (avec fetch)</summary>
```typescript
const apiKey = "YOUR_API_KEY";
const url = "https://app.all-hands.dev/api/conversations";
const headers = {
"Authorization": `Bearer ${apiKey}`,
"Content-Type": "application/json"
};
const data = {
initial_user_msg: "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
repository: "yourusername/your-repo"
};
async function startConversation() {
try {
const response = await fetch(url, {
method: "POST",
headers: headers,
body: JSON.stringify(data)
});
const conversation = await response.json();
console.log(`Conversation Link: https://app.all-hands.dev/conversations/${conversation.id}`);
console.log(`Status: ${conversation.status}`);
return conversation;
} catch (error) {
console.error("Error starting conversation:", error);
}
}
startConversation();
```
</details>
#### Réponse
L'API renverra un objet JSON avec les détails de la conversation créée :
```json
{
"status": "ok",
"conversation_id": "abc1234",
}
```
Vous pouvez également recevoir une `AuthenticationError` si :
1. Vous avez fourni une clé API invalide
2. Vous avez fourni un nom de dépôt incorrect
3. Vous n'avez pas accès au dépôt
### Récupération du statut d'une conversation
Vous pouvez vérifier le statut d'une conversation en faisant une requête GET vers le point de terminaison de conversation.
#### Point de terminaison
```
GET https://app.all-hands.dev/api/conversations/{conversation_id}
```
#### Exemple
<details>
<summary>cURL</summary>
```bash
curl -X GET "https://app.all-hands.dev/api/conversations/{conversation_id}" \
-H "Authorization: Bearer YOUR_API_KEY"
```
</details>
#### Réponse
La réponse est formatée comme suit :
```json
{
"conversation_id":"abc1234",
"title":"Update README.md",
"created_at":"2025-04-29T15:13:51.370706Z",
"last_updated_at":"2025-04-29T15:13:57.199210Z",
"status":"RUNNING",
"selected_repository":"yourusername/your-repo",
"trigger":"gui"
}
```
## Limites de taux
L'API a une limite de 10 conversations simultanées par compte. Si vous avez besoin d'une limite plus élevée pour votre cas d'utilisation, veuillez nous contacter à [contact@all-hands.dev](mailto:contact@all-hands.dev).
Si vous dépassez cette limite, l'API renverra une réponse 429 Too Many Requests.

33
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md Normal file
View File

@ -0,0 +1,33 @@
# Résolveur GitHub Cloud
Le Résolveur GitHub automatise les corrections de code et fournit une assistance intelligente pour vos dépôts.
## Configuration
Le Résolveur GitHub Cloud est disponible automatiquement lorsque vous
[accordez l'accès au dépôt OpenHands Cloud](./openhands-cloud#adding-repository-access).
## Utilisation
Après avoir accordé l'accès au dépôt OpenHands Cloud, vous pouvez utiliser le Résolveur GitHub Cloud sur les problèmes et les pull requests
du dépôt.
### Problèmes (Issues)
Sur votre dépôt, étiquetez un problème avec `openhands`. OpenHands va :
1. Commenter le problème pour vous informer qu'il y travaille.
- Vous pouvez cliquer sur le lien pour suivre la progression sur OpenHands Cloud.
2. Ouvrir une pull request s'il détermine que le problème a été résolu avec succès.
3. Commenter le problème avec un résumé des tâches effectuées et un lien vers la pull request.
### Pull Requests
Pour qu'OpenHands travaille sur des pull requests, utilisez `@openhands` dans les commentaires de premier niveau ou en ligne pour :
- Poser des questions
- Demander des mises à jour
- Obtenir des explications de code
OpenHands va :
1. Commenter la PR pour vous informer qu'il y travaille.
2. Effectuer la tâche.

65
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx Normal file
View File

@ -0,0 +1,65 @@
# OpenHands Cloud
OpenHands Cloud est la version hébergée dans le cloud d'OpenHands par All Hands AI.
## Accéder à OpenHands Cloud
OpenHands Cloud est accessible à l'adresse https://app.all-hands.dev/.
Vous pouvez également interagir avec OpenHands Cloud par programmation en utilisant l'[API](./cloud-api).
## Premiers pas
Après avoir visité OpenHands Cloud, il vous sera demandé de vous connecter avec votre compte GitHub ou GitLab :
1. Après avoir lu et accepté les conditions d'utilisation, cliquez sur `Log in with GitHub` ou `Log in with GitLab`.
2. Examinez les autorisations demandées par OpenHands, puis cliquez sur `Authorize OpenHands AI`.
- OpenHands nécessitera certaines autorisations de votre compte GitHub ou GitLab. Pour en savoir plus sur ces autorisations :
- GitHub : Vous pouvez cliquer sur le lien `Learn more` sur la page d'autorisation GitHub.
- GitLab : Vous pouvez développer chaque demande d'autorisation sur la page d'autorisation GitLab.
## Accès aux dépôts
### GitHub
#### Ajouter l'accès aux dépôts
Vous pouvez accorder à OpenHands un accès à des dépôts spécifiques :
1. Cliquez sur `Add GitHub repos` sur la page d'accueil.
2. Sélectionnez l'organisation, puis choisissez les dépôts spécifiques auxquels vous souhaitez donner accès à OpenHands.
<details>
<summary>Détails des autorisations pour l'accès aux dépôts</summary>
Openhands demande des jetons à courte durée de vie (expiration de 8 heures) avec ces autorisations :
- Actions : Lecture et écriture
- Administration : Lecture seule
- Statuts de commit : Lecture et écriture
- Contenus : Lecture et écriture
- Issues : Lecture et écriture
- Métadonnées : Lecture seule
- Pull requests : Lecture et écriture
- Webhooks : Lecture et écriture
- Workflows : Lecture et écriture
L'accès au dépôt pour un utilisateur est accordé en fonction de :
- L'autorisation accordée pour le dépôt.
- Les autorisations GitHub de l'utilisateur (propriétaire/collaborateur).
</details>
3. Cliquez sur `Install & Authorize`.
#### Modifier l'accès aux dépôts
Vous pouvez modifier l'accès aux dépôts GitHub à tout moment en :
* Utilisant le même processus `Add GitHub repos`, ou
* Visitant la page Paramètres et en sélectionnant `Configure GitHub Repositories` dans la section `Git Settings`.
### GitLab
Lorsque vous utilisez votre compte GitLab, OpenHands aura automatiquement accès à vos dépôts.
## Persistance des conversations
- Liste des conversations – Affiche uniquement les 10 conversations les plus récentes initiées au cours des 10 derniers jours.
- Espaces de travail – Les espaces de travail de conversation sont conservés pendant 14 jours.
- Environnements d'exécution – Les environnements d'exécution restent actifs ("chauds") pendant 30 minutes. Après cette période, la reprise d'une conversation peut prendre 1 à 2 minutes.

536
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/configuration-options.md
View File

@ -1,387 +1,395 @@
# Options de configuration
Ce guide détaille toutes les options de configuration disponibles pour OpenHands, vous aidant à personnaliser son comportement et à l'intégrer avec d'autres services.
# Options de Configuration
:::note
Si vous exécutez en [Mode GUI](https://docs.all-hands.dev/modules/usage/how-to/gui-mode), les paramètres disponibles dans l'interface utilisateur des paramètres auront toujours
la priorité.
Cette page présente toutes les options de configuration disponibles pour OpenHands, vous permettant de personnaliser son comportement et
de l'intégrer avec d'autres services. En Mode GUI, tous les paramètres appliqués via l'interface Paramètres auront la priorité.
:::
---
## Configuration Principale
# Table des matières
Les options de configuration principales sont définies dans la section `[core]` du fichier `config.toml`.
1. [Configuration de base](#core-configuration)
- [Clés API](#api-keys)
- [Espace de travail](#workspace)
- [Débogage et journalisation](#debugging-and-logging)
- [Trajectoires](#trajectories)
- [Stockage de fichiers](#file-store)
- [Gestion des tâches](#task-management)
- [Configuration du bac à sable](#sandbox-configuration)
- [Divers](#miscellaneous)
2. [Configuration LLM](#llm-configuration)
- [Informations d'identification AWS](#aws-credentials)
- [Configuration de l'API](#api-configuration)
- [Fournisseur LLM personnalisé](#custom-llm-provider)
- [Embeddings](#embeddings)
- [Gestion des messages](#message-handling)
- [Sélection du modèle](#model-selection)
- [Nouvelles tentatives](#retrying)
- [Options avancées](#advanced-options)
3. [Configuration de l'agent](#agent-configuration)
- [Configuration de la mémoire](#memory-configuration)
- [Configuration LLM](#llm-configuration-1)
- [Configuration de l'espace d'action](#actionspace-configuration)
- [Utilisation du micro-agent](#microagent-usage)
4. [Configuration du bac à sable](#sandbox-configuration-1)
- [Exécution](#execution)
- [Image de conteneur](#container-image)
- [Mise en réseau](#networking)
- [Linting et plugins](#linting-and-plugins)
- [Dépendances et environnement](#dependencies-and-environment)
- [Évaluation](#evaluation)
5. [Configuration de sécurité](#security-configuration)
- [Mode de confirmation](#confirmation-mode)
- [Analyseur de sécurité](#security-analyzer)
---
## Configuration de base
Les options de configuration de base sont définies dans la section `[core]` du fichier `config.toml`.
**Clés API**
### Clés API
- `e2b_api_key`
- Type : `str`
- Valeur par défaut : `""`
- Description : Clé API pour E2B
- Type: `str`
- Défaut: `""`
- Description: Clé API pour E2B
- `modal_api_token_id`
- Type : `str`
- Valeur par défaut : `""`
- Description : ID du jeton API pour Modal
- Type: `str`
- Défaut: `""`
- Description: ID de token API pour Modal
- `modal_api_token_secret`
- Type : `str`
- Valeur par défaut : `""`
- Description : Secret du jeton API pour Modal
- Type: `str`
- Défaut: `""`
- Description: Secret de token API pour Modal
**Espace de travail**
- `workspace_base`
- Type : `str`
- Valeur par défaut : `"./workspace"`
- Description : Chemin de base pour l'espace de travail
### Espace de travail
- `workspace_base` **(Déprécié)**
- Type: `str`
- Défaut: `"./workspace"`
- Description: Chemin de base pour l'espace de travail. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
- `cache_dir`
- Type : `str`
- Valeur par défaut : `"/tmp/cache"`
- Description : Chemin du répertoire de cache
- Type: `str`
- Défaut: `"/tmp/cache"`
- Description: Chemin du répertoire de cache
**Débogage et journalisation**
### Débogage et Journalisation
- `debug`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Activer le débogage
- Type: `bool`
- Défaut: `false`
- Description: Activer le débogage
- `disable_color`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Désactiver la couleur dans la sortie du terminal
- Type: `bool`
- Défaut: `false`
- Description: Désactiver la couleur dans la sortie du terminal
**Trajectoires**
### Trajectoires
- `save_trajectory_path`
- Type : `str`
- Valeur par défaut : `"./trajectories"`
- Description : Chemin pour stocker les trajectoires (peut être un dossier ou un fichier). Si c'est un dossier, les trajectoires seront enregistrées dans un fichier nommé avec l'ID de session et l'extension .json, dans ce dossier.
- Type: `str`
- Défaut: `"./trajectories"`
- Description: Chemin pour stocker les trajectoires (peut être un dossier ou un fichier). Si c'est un dossier, les trajectoires seront sauvegardées dans un fichier nommé avec l'ID de session et l'extension .json, dans ce dossier.
**Stockage de fichiers**
- `replay_trajectory_path`
- Type: `str`
- Défaut: `""`
- Description: Chemin pour charger une trajectoire et la rejouer. Si fourni, doit être un chemin vers le fichier de trajectoire au format JSON. Les actions dans le fichier de trajectoire seront rejouées d'abord avant que toute instruction utilisateur ne soit exécutée.
### Stockage de Fichiers
- `file_store_path`
- Type : `str`
- Valeur par défaut : `"/tmp/file_store"`
- Description : Chemin de stockage des fichiers
- Type: `str`
- Défaut: `"/tmp/file_store"`
- Description: Chemin du stockage de fichiers
- `file_store`
- Type : `str`
- Valeur par défaut : `"memory"`
- Description : Type de stockage de fichiers
- Type: `str`
- Défaut: `"memory"`
- Description: Type de stockage de fichiers
- `file_uploads_allowed_extensions`
- Type : `list of str`
- Valeur par défaut : `[".*"]`
- Description : Liste des extensions de fichiers autorisées pour les téléchargements
- Type: `liste de str`
- Défaut: `[".*"]`
- Description: Liste des extensions de fichiers autorisées pour les téléchargements
- `file_uploads_max_file_size_mb`
- Type : `int`
- Valeur par défaut : `0`
- Description : Taille maximale des fichiers pour les téléchargements, en mégaoctets
- Type: `int`
- Défaut: `0`
- Description: Taille maximale de fichier pour les téléchargements, en mégaoctets
- `file_uploads_restrict_file_types`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Restreindre les types de fichiers pour les téléchargements de fichiers
- Type: `bool`
- Défaut: `false`
- Description: Restreindre les types de fichiers pour les téléchargements
- `file_uploads_allowed_extensions`
- Type : `list of str`
- Valeur par défaut : `[".*"]`
- Description : Liste des extensions de fichiers autorisées pour les téléchargements
- Type: `liste de str`
- Défaut: `[".*"]`
- Description: Liste des extensions de fichiers autorisées pour les téléchargements
**Gestion des tâches**
### Gestion des Tâches
- `max_budget_per_task`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Budget maximal par tâche (0.0 signifie aucune limite)
- Type: `float`
- Défaut: `0.0`
- Description: Budget maximum par tâche (0.0 signifie pas de limite)
- `max_iterations`
- Type : `int`
- Valeur par défaut : `100`
- Description : Nombre maximal d'itérations
- Type: `int`
- Défaut: `100`
- Description: Nombre maximum d'itérations
**Configuration du bac à sable**
- `workspace_mount_path_in_sandbox`
- Type : `str`
- Valeur par défaut : `"/workspace"`
- Description : Chemin de montage de l'espace de travail dans le bac à sable
### Configuration du Sandbox
- `volumes`
- Type: `str`
- Défaut: `None`
- Description: Montages de volumes au format 'chemin_hôte:chemin_conteneur[:mode]', par ex. '/my/host/dir:/workspace:rw'. Plusieurs montages peuvent être spécifiés en utilisant des virgules, par ex. '/path1:/workspace/path1,/path2:/workspace/path2:ro'
- `workspace_mount_path`
- Type : `str`
- Valeur par défaut : `""`
- Description : Chemin de montage de l'espace de travail
- `workspace_mount_path_in_sandbox` **(Déprécié)**
- Type: `str`
- Défaut: `"/workspace"`
- Description: Chemin pour monter l'espace de travail dans le sandbox. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
- `workspace_mount_rewrite`
- Type : `str`
- Valeur par défaut : `""`
- Description : Chemin pour réécrire le chemin de montage de l'espace de travail. Vous pouvez généralement ignorer cela, cela fait référence à des cas spéciaux d'exécution à l'intérieur d'un autre conteneur.
- `workspace_mount_path` **(Déprécié)**
- Type: `str`
- Défaut: `""`
- Description: Chemin pour monter l'espace de travail. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
**Divers**
- `workspace_mount_rewrite` **(Déprécié)**
- Type: `str`
- Défaut: `""`
- Description: Chemin pour réécrire le chemin de montage de l'espace de travail. Vous pouvez généralement ignorer cela, cela fait référence à des cas spéciaux d'exécution à l'intérieur d'un autre conteneur. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
### Divers
- `run_as_openhands`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Exécuter en tant qu'OpenHands
- Type: `bool`
- Défaut: `true`
- Description: Exécuter en tant qu'OpenHands
- `runtime`
- Type : `str`
- Valeur par défaut : `"docker"`
- Description : Environnement d'exécution
- Type: `str`
- Défaut: `"docker"`
- Description: Environnement d'exécution
- `default_agent`
- Type : `str`
- Valeur par défaut : `"CodeActAgent"`
- Description : Nom de l'agent par défaut
- Type: `str`
- Défaut: `"CodeActAgent"`
- Description: Nom de l'agent par défaut
- `jwt_secret`
- Type : `str`
- Valeur par défaut : `uuid.uuid4().hex`
- Description : Secret JWT pour l'authentification. Veuillez le définir sur votre propre valeur.
- Type: `str`
- Défaut: `uuid.uuid4().hex`
- Description: Secret JWT pour l'authentification. Veuillez le définir avec votre propre valeur.
## Configuration LLM
Les options de configuration LLM (Large Language Model) sont définies dans la section `[llm]` du fichier `config.toml`.
Pour les utiliser avec la commande docker, passez `-e LLM_<option>`. Exemple : `-e LLM_NUM_RETRIES`.
Pour les utiliser avec la commande docker, passez `-e LLM_<option>`. Exemple: `-e LLM_NUM_RETRIES`.
:::note
Pour les configurations de développement, vous pouvez également définir des configurations LLM personnalisées. Voir [Configurations LLM personnalisées](./llms/custom-llm-configs) pour plus de détails.
Pour les configurations de développement, vous pouvez également définir des configurations LLM personnalisées nommées. Voir [Configurations LLM personnalisées](./llms/custom-llm-configs) pour plus de détails.
:::
**Informations d'identification AWS**
**Identifiants AWS**
- `aws_access_key_id`
- Type : `str`
- Valeur par défaut : `""`
- Description : ID de clé d'accès AWS
- Type: `str`
- Défaut: `""`
- Description: ID de clé d'accès AWS
- `aws_region_name`
- Type : `str`
- Valeur par défaut : `""`
- Description : Nom de la région AWS
- Type: `str`
- Défaut: `""`
- Description: Nom de région AWS
- `aws_secret_access_key`
- Type : `str`
- Valeur par défaut : `""`
- Description : Clé d'accès secrète AWS
- Type: `str`
- Défaut: `""`
- Description: Clé d'accès secrète AWS
**Configuration de l'API**
### Configuration API
- `api_key`
- Type : `str`
- Valeur par défaut : `None`
- Description : Clé API à utiliser
- Type: `str`
- Défaut: `None`
- Description: Clé API à utiliser
- `base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base de l'API
- Type: `str`
- Défaut: `""`
- Description: URL de base de l'API
- `api_version`
- Type : `str`
- Valeur par défaut : `""`
- Description : Version de l'API
- Type: `str`
- Défaut: `""`
- Description: Version de l'API
- `input_cost_per_token`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Coût par jeton d'entrée
- Type: `float`
- Défaut: `0.0`
- Description: Coût par token d'entrée
- `output_cost_per_token`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Coût par jeton de sortie
- Type: `float`
- Défaut: `0.0`
- Description: Coût par token de sortie
**Fournisseur LLM personnalisé**
### Fournisseur LLM personnalisé
- `custom_llm_provider`
- Type : `str`
- Valeur par défaut : `""`
- Description : Fournisseur LLM personnalisé
- Type: `str`
- Défaut: `""`
- Description: Fournisseur LLM personnalisé
**Embeddings**
- `embedding_base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base de l'API d'embedding
- `embedding_deployment_name`
- Type : `str`
- Valeur par défaut : `""`
- Description : Nom du déploiement d'embedding
- `embedding_model`
- Type : `str`
- Valeur par défaut : `"local"`
- Description : Modèle d'embedding à utiliser
**Gestion des messages**
### Gestion des messages
- `max_message_chars`
- Type : `int`
- Valeur par défaut : `30000`
- Description : Le nombre maximum approximatif de caractères dans le contenu d'un événement inclus dans l'invite au LLM. Les observations plus grandes sont tronquées.
- Type: `int`
- Défaut: `30000`
- Description: Le nombre approximatif maximum de caractères dans le contenu d'un événement inclus dans le prompt au LLM. Les observations plus grandes sont tronquées.
- `max_input_tokens`
- Type : `int`
- Valeur par défaut : `0`
- Description : Nombre maximal de jetons d'entrée
- Type: `int`
- Défaut: `0`
- Description: Nombre maximum de tokens d'entrée
- `max_output_tokens`
- Type : `int`
- Valeur par défaut : `0`
- Description : Nombre maximal de jetons de sortie
- Type: `int`
- Défaut: `0`
- Description: Nombre maximum de tokens de sortie
**Sélection du modèle**
### Sélection du modèle
- `model`
- Type : `str`
- Valeur par défaut : `"claude-3-5-sonnet-20241022"`
- Description : Modèle à utiliser
- Type: `str`
- Défaut: `"claude-3-5-sonnet-20241022"`
- Description: Modèle à utiliser
**Nouvelles tentatives**
### Nouvelles tentatives
- `num_retries`
- Type : `int`
- Valeur par défaut : `8`
- Description : Nombre de nouvelles tentatives à effectuer
- Type: `int`
- Défaut: `8`
- Description: Nombre de tentatives à effectuer
- `retry_max_wait`
- Type : `int`
- Valeur par défaut : `120`
- Description : Temps d'attente maximal (en secondes) entre les tentatives de nouvelle tentative
- Type: `int`
- Défaut: `120`
- Description: Temps d'attente maximum (en secondes) entre les tentatives
- `retry_min_wait`
- Type : `int`
- Valeur par défaut : `15`
- Description : Temps d'attente minimal (en secondes) entre les tentatives de nouvelle tentative
- Type: `int`
- Défaut: `15`
- Description: Temps d'attente minimum (en secondes) entre les tentatives
- `retry_multiplier`
- Type : `float`
- Valeur par défaut : `2.0`
- Description : Multiplicateur pour le calcul du backoff exponentiel
- Type: `float`
- Défaut: `2.0`
- Description: Multiplicateur pour le calcul de backoff exponentiel
**Options avancées**
### Options avancées
- `drop_params`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Supprimer tous les paramètres non mappés (non pris en charge) sans provoquer d'exception
- Type: `bool`
- Défaut: `false`
- Description: Ignorer les paramètres non mappés (non pris en charge) sans provoquer d'exception
- `caching_prompt`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Utiliser la fonctionnalité de mise en cache des invites si elle est fournie par le LLM et prise en charge
- Type: `bool`
- Défaut: `true`
- Description: Utiliser la fonctionnalité de mise en cache des prompts si fournie par le LLM et prise en charge
- `ollama_base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base pour l'API OLLAMA
- Type: `str`
- Défaut: `""`
- Description: URL de base pour l'API OLLAMA
- `temperature`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Température pour l'API
- Type: `float`
- Défaut: `0.0`
- Description: Température pour l'API
- `timeout`
- Type : `int`
- Valeur par défaut : `0`
- Description : Délai d'expiration pour l'API
- Type: `int`
- Défaut: `0`
- Description: Délai d'attente pour l'API
- `top_p`
- Type : `float`
- Valeur par défaut : `1.0`
- Description : Top p pour l'API
- Type: `float`
- Défaut: `1.0`
- Description: Top p pour l'API
- `disable_vision`
- Type : `bool`
- Valeur par défaut : `None`
- Description : Si le modèle est capable de vision, cette option permet de désactiver le traitement des images (utile pour réduire les coûts)
- Type: `bool`
- Défaut: `None`
- Description: Si le modèle est capable de vision, cette option permet de désactiver le traitement d'images (utile pour réduire les coûts)
## Configuration de l'agent
## Configuration de l'Agent
Les options de configuration de l'agent sont définies dans les sections `[agent]` et `[agent.<agent_name>]` du fichier `config.toml`.
**Configuration de la mémoire**
- `memory_enabled`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si la mémoire à long terme (embeddings) est activée
- `memory_max_threads`
- Type : `int`
- Valeur par défaut : `3`
- Description : Le nombre maximum de threads indexant en même temps pour les embeddings
**Configuration LLM**
### Configuration LLM
- `llm_config`
- Type : `str`
- Valeur par défaut : `'your-llm-config-group'`
- Description : Le nom de la configuration LLM à utiliser
- Type: `str`
- Défaut: `'your-llm-config-group'`
- Description: Le nom de la configuration LLM à utiliser
**Configuration de l'espace d'action**
### Configuration de l'espace d'action
- `function_calling`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Si l'appel de fonction est activé
- Type: `bool`
- Défaut: `true`
- Description: Si l'appel de fonction est activé
- `enable_browsing`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si le délégué de navigation est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
- Type: `bool`
- Défaut: `false`
- Description: Si le délégué de navigation est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
- `enable_llm_editor`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si l'éditeur LLM est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
- Type: `bool`
- Défaut: `false`
- Description: Si l'éditeur LLM est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
**Utilisation du micro-agent**
- `enable_jupyter`
- Type: `bool`
- Défaut: `false`
- Description: Si Jupyter est activé dans l'espace d'action
- `enable_history_truncation`
- Type: `bool`
- Défaut: `true`
- Description: Si l'historique doit être tronqué pour continuer la session lorsqu'on atteint la limite de longueur de contexte du LLM
### Utilisation des microagents
- `enable_prompt_extensions`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Indique si l'utilisation des micro-agents est activée ou non
- Type: `bool`
- Défaut: `true`
- Description: Si les microagents doivent être utilisés
- `disabled_microagents`
- Type : `list of str`
- Valeur par défaut : `None`
- Description : Liste des micro-agents à désactiver
- Type: `liste de str`
- Défaut: `None`
- Description: Une liste de microagents à désactiver
## Configuration du Sandbox
Les options de configuration du sandbox sont définies dans la section `[sandbox]` du fichier `config.toml`.
Pour les utiliser avec la commande docker, passez `-e SANDBOX_<option>`. Exemple: `-e SANDBOX_TIMEOUT`.
### Exécution
- `timeout`
- Type : `int`
- Valeur par défaut : `120`
- Description : Délai d'expiration du bac à sable, en secondes
- Type: `int`
- Défaut: `120`
- Description: Délai d'attente du sandbox en secondes
- `user_id`
- Type : `int`
- Valeur par défaut : `1000`
- Description : ID de l'utilisateur du bac à sable
- Type: `int`
- Défaut: `1000`
- Description: ID utilisateur du sandbox
### Image du conteneur
- `base_container_image`
- Type: `str`
- Défaut: `"nikolaik/python-nodejs:python3.12-nodejs22"`
- Description: Image de conteneur à utiliser pour le sandbox
### Réseau
- `use_host_network`
- Type: `bool`
- Défaut: `false`
- Description: Utiliser le réseau de l'hôte
- `runtime_binding_address`
- Type: `str`
- Défaut: `0.0.0.0`
- Description: L'adresse de liaison pour les ports d'exécution. Elle spécifie quelle interface réseau sur la machine hôte Docker doit lier les ports d'exécution.
### Linting et Plugins
- `enable_auto_lint`
- Type: `bool`
- Défaut: `false`
- Description: Activer le linting automatique après l'édition
- `initialize_plugins`
- Type: `bool`
- Défaut: `true`
- Description: Si les plugins doivent être initialisés
### Dépendances et Environnement
- `runtime_extra_deps`
- Type: `str`
- Défaut: `""`
- Description: Dépendances supplémentaires à installer dans l'image d'exécution
- `runtime_startup_env_vars`
- Type: `dict`
- Défaut: `{}`
- Description: Variables d'environnement à définir au lancement de l'exécution
### Évaluation
- `browsergym_eval_env`
- Type: `str`
- Défaut: `""`
- Description: Environnement BrowserGym à utiliser pour l'évaluation
## Configuration de Sécurité
Les options de configuration de sécurité sont définies dans la section `[security]` du fichier `config.toml`.
Pour les utiliser avec la commande docker, passez `-e SECURITY

23
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/customization/repository.md Normal file
View File

@ -0,0 +1,23 @@
# Personnalisation du dépôt
Vous pouvez personnaliser la façon dont OpenHands interagit avec votre dépôt en créant un
répertoire `.openhands` à la racine.
## Microagents
Les microagents vous permettent d'étendre les prompts d'OpenHands avec des informations spécifiques à votre projet et de définir comment OpenHands
doit fonctionner. Consultez [Vue d'ensemble des microagents](../prompting/microagents-overview) pour plus d'informations.
## Script de configuration
Vous pouvez ajouter un fichier `.openhands/setup.sh`, qui s'exécutera chaque fois qu'OpenHands commence à travailler avec votre dépôt.
C'est un emplacement idéal pour installer des dépendances, définir des variables d'environnement et effectuer d'autres tâches de configuration.
Par exemple :
```bash
#!/bin/bash
export MY_ENV_VAR="my value"
sudo apt-get update
sudo apt-get install -y lsof
cd frontend && npm install ; cd ..
```

31
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/feedback.md
View File

@ -1,23 +1,21 @@
# ✅ Fournir des Commentaires
Lorsque vous utilisez OpenHands, vous rencontrerez des cas où les choses fonctionnent bien, et d'autres où ce n'est pas le cas. Nous vous encourageons à fournir des commentaires lorsque vous utilisez OpenHands pour aider à donner un retour à l'équipe de développement et, peut-être plus important encore, créer un corpus ouvert d'exemples d'entraînement pour les agents de codage -- Share-OpenHands!
# ✅ Fournir des commentaires
## 📝 Comment Fournir des Commentaires
Lorsque vous utilisez OpenHands, vous rencontrerez des cas où les choses fonctionnent bien, et d'autres où elles ne fonctionnent pas. Nous vous encourageons à fournir des commentaires lorsque vous utilisez OpenHands pour aider à donner des retours à l'équipe de développement, et peut-être plus important encore, créer un corpus ouvert d'exemples d'entraînement d'agents de codage -- Share-OpenHands !
## 📝 Comment fournir des commentaires
Fournir des commentaires est facile ! Lorsque vous utilisez OpenHands, vous pouvez appuyer sur le bouton pouce vers le haut ou pouce vers le bas à tout moment pendant votre interaction. Vous serez invité à fournir votre adresse e-mail (par exemple, afin que nous puissions vous contacter si nous voulons poser des questions de suivi), et vous pouvez choisir si vous souhaitez fournir des commentaires publiquement ou en privé.
Fournir des commentaires est facile ! Lorsque vous utilisez OpenHands, vous pouvez appuyer sur le bouton pouce levé ou pouce baissé à tout moment pendant votre interaction. Il vous sera demandé de fournir votre adresse e-mail (par exemple, pour que nous puissions vous contacter si nous souhaitons poser des questions complémentaires), et vous pouvez choisir si vous souhaitez fournir des commentaires publiquement ou en privé.
<iframe width="560" height="315" src="https://www.youtube.com/embed/5rFx-StMVV0?si=svo7xzp6LhGK_GXr" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
## 📜 Utilisation des données et confidentialité
## 📜 Utilisation des Données et Confidentialité
### Paramètres de partage des données
Lorsque vous soumettez des données, vous pouvez les soumettre publiquement ou en privé.
Lorsque vous soumettez des données, vous pouvez les soumettre soit publiquement, soit en privé.
* Les données **publiques** seront distribuées sous la licence MIT, comme OpenHands lui-même, et pourront être utilisées par la communauté pour entraîner et tester des modèles. Évidemment, les commentaires que vous pouvez rendre publics seront plus précieux pour la communauté dans son ensemble, donc lorsque vous ne traitez pas d'informations sensibles, nous vous encourageons à choisir cette option !
* Les données **privées** ne seront partagées qu'avec l'équipe OpenHands dans le but d'améliorer OpenHands.
- Les données **publiques** seront distribuées sous la licence MIT, comme OpenHands lui-même, et pourront être utilisées par la communauté pour entraîner et tester des modèles. Évidemment, les commentaires que vous pouvez rendre publics seront plus précieux pour la communauté dans son ensemble, donc lorsque vous ne traitez pas d'informations sensibles, nous vous encourageons à choisir cette option !
- Les données **privées** seront mises à la disposition de l'équipe OpenHands dans le but d'améliorer OpenHands. Cependant, un lien avec un identifiant unique sera toujours créé que vous pourrez partager publiquement avec d'autres.
### Qui collecte et stocke les données ?
@ -25,17 +23,16 @@ Les données sont collectées et stockées par [All Hands AI](https://all-hands.
### Comment les données publiques seront-elles publiées ?
Les données publiques seront publiées lorsque nous atteindrons des jalons fixes, tels que 1 000 exemples publics, 10 000 exemples publics, etc.
À ce moment-là, nous suivrons le processus de publication suivant :
Les données publiques seront publiées lorsque nous atteindrons des jalons fixes, tels que 1 000 exemples publics, 10 000 exemples publics, etc. À ce moment-là, nous suivrons le processus de publication suivant :
1. Toutes les personnes qui ont contribué à des commentaires publics recevront un e-mail décrivant la publication des données et auront la possibilité de se retirer.
2. La ou les personnes en charge de la publication des données effectueront un contrôle de la qualité des données, en supprimant les commentaires de mauvaise qualité, en supprimant les adresses e-mail des soumissionnaires et en essayant de supprimer toute information sensible.
1. Toutes les personnes ayant contribué avec des commentaires publics recevront un e-mail décrivant la publication des données et auront la possibilité de se désinscrire.
2. La ou les personnes responsables de la publication des données effectueront un contrôle de qualité des données, supprimant les commentaires de faible qualité, supprimant les adresses e-mail des soumissionnaires et tentant de supprimer toute information sensible.
3. Les données seront publiées publiquement sous la licence MIT via des sites couramment utilisés tels que GitHub ou Hugging Face.
### Que faire si je veux que mes données soient supprimées ?
### Que faire si je souhaite que mes données soient supprimées ?
Pour les données sur les serveurs d'All Hands AI, nous sommes heureux de les supprimer sur demande :
**Une pièce de données :** Si vous souhaitez supprimer une pièce de données, nous ajouterons prochainement un mécanisme pour supprimer les pièces de données en utilisant le lien et le mot de passe qui s'affichent sur l'interface lorsque vous soumettez des données.
**Une Seule Donnée :** Si vous souhaitez qu'une donnée soit supprimée, nous ajouterons prochainement un mécanisme pour supprimer des éléments de données en utilisant le lien et le mot de passe qui s'affichent sur l'interface lorsque vous soumettez des données.
**Toutes les données :** Si vous souhaitez que toutes vos données soient supprimées, ou si vous n'avez pas l'ID et le mot de passe que vous avez reçus lors de la soumission des données, veuillez contacter `contact@all-hands.dev` à partir de l'adresse e-mail que vous avez enregistrée lorsque vous avez initialement soumis les données.
**Toutes les Données :** Si vous souhaitez que toutes vos données soient supprimées, ou si vous ne disposez pas de l'identifiant et du mot de passe que vous avez reçus lors de la soumission des données, veuillez contacter `contact@all-hands.dev` depuis l'adresse e-mail que vous avez enregistrée lors de la soumission initiale des données.

114
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/getting-started.mdx
View File

@ -1,113 +1,99 @@
# Premiers pas avec OpenHands
# Démarrer avec OpenHands
Vous avez donc [installé OpenHands](./installation) et avez
Vous avez [exécuté OpenHands](./installation) et vous avez
[configuré votre LLM](./installation#setup). Et maintenant ?
OpenHands peut vous aider à aborder une grande variété de tâches d'ingénierie. Mais la technologie
est encore nouvelle, et nous sommes loin d'avoir des agents capables de prendre en charge des tâches
d'ingénierie vastes et compliquées sans aucune aide. Il est donc important de se faire une idée de ce que l'agent
fait bien, et où il pourrait avoir besoin d'un coup de main.
OpenHands peut vous aider pour diverses tâches d'ingénierie. Cependant, la technologie est encore nouvelle, et nous sommes loin d'avoir
des agents capables de gérer des tâches complexes de manière autonome. Il est important de comprendre ce que l'agent fait bien et où il
a besoin de soutien.
## Hello World
La première chose que vous voudrez peut-être essayer est un simple exemple "hello world".
Cela peut être plus compliqué qu'il n'y paraît !
Commencez par un simple exemple "hello world". Cela pourrait être plus délicat qu'il n'y paraît !
Essayez de demander à l'agent :
> Veuillez écrire un script bash hello.sh qui affiche "hello world!"
Demandez à l'agent :
> Écrivez un script bash hello.sh qui affiche "hello world!"
Vous devriez constater que l'agent non seulement écrit le script, mais définit également les
permissions correctes et exécute le script pour vérifier la sortie.
L'agent écrira le script, définira les permissions correctes et l'exécutera pour vérifier la sortie.
Vous pouvez continuer à demander à l'agent d'affiner votre code. C'est une excellente façon de
travailler avec les agents. Commencez simplement, et itérez.
travailler avec les agents. Commencez simplement, puis itérez.
> Veuillez modifier hello.sh pour qu'il accepte un nom comme premier argument, mais par défaut "world"
> Modifiez hello.sh pour qu'il accepte un nom comme premier argument, mais utilise "world" par défaut
Vous pouvez également travailler dans n'importe quel langage dont vous avez besoin, bien que l'agent puisse avoir besoin de passer du
temps à configurer son environnement !
Vous pouvez également utiliser n'importe quel langage dont vous avez besoin. L'agent peut avoir besoin de temps pour configurer l'environnement.
> Veuillez convertir hello.sh en un script Ruby, et l'exécuter
> Veuillez convertir hello.sh en script Ruby, et exécutez-le
## Construire à partir de zéro
Les agents se débrouillent exceptionnellement bien pour les tâches "greenfield" (tâches où ils n'ont pas besoin
de contexte sur une base de code existante) et ils peuvent simplement commencer à partir de zéro.
Il est préférable de commencer par une tâche simple, puis d'itérer. Il est également préférable d'être
aussi précis que possible sur ce que vous voulez, sur la pile technologique à utiliser, etc.
Les agents excellent dans les tâches "greenfield", où ils n'ont pas besoin de contexte sur le code existant et
peuvent partir de zéro.
Commencez par une tâche simple et itérez à partir de là. Soyez précis sur ce que vous voulez et la pile technologique.
Par exemple, nous pourrions construire une application TODO :
> Veuillez créer une application basique de liste de tâches en React. Elle devrait être uniquement frontend, et tout l'état
> devrait être conservé dans localStorage.
> Construisez une application TODO frontend uniquement en React. Tout l'état doit être stocké dans localStorage.
Nous pouvons continuer à itérer sur l'application une fois le squelette en place :
Une fois la structure de base en place, continuez à affiner :
> Veuillez permettre d'ajouter une date d'échéance optionnelle à chaque tâche
> Permettez d'ajouter une date d'échéance optionnelle à chaque tâche.
Tout comme avec le développement normal, il est bon de commiter et de pousser votre code fréquemment.
De cette façon, vous pouvez toujours revenir à un ancien état si l'agent dévie.
Vous pouvez demander à l'agent de commiter et de pousser pour vous :
> Veuillez commiter les changements et les pousser sur une nouvelle branche appelée "feature/due-dates"
Comme pour le développement normal, committez et poussez votre code souvent.
De cette façon, vous pouvez toujours revenir à un état antérieur si l'agent s'égare.
Vous pouvez demander à l'agent de committer et pousser pour vous :
> Committez les changements et poussez-les vers une nouvelle branche appelée "feature/due-dates"
## Ajouter du nouveau code
OpenHands peut également faire un excellent travail en ajoutant du nouveau code à une base de code existante.
OpenHands est excellent pour ajouter du nouveau code à une base de code existante.
Par exemple, vous pouvez demander à OpenHands d'ajouter une nouvelle action GitHub à votre projet
qui analyse votre code. OpenHands peut jeter un coup d'œil à votre base de code pour voir quel langage
il doit utiliser, mais ensuite il peut simplement déposer un nouveau fichier dans `./github/workflows/lint.yml`
Par exemple, vous pouvez demander à OpenHands d'ajouter une action GitHub qui vérifie votre code. Il pourrait vérifier votre base de code pour
déterminer le langage, puis créer un nouveau fichier dans `./github/workflows/lint.yml`.
> Veuillez ajouter une action GitHub qui analyse le code dans ce dépôt
> Ajoutez une action GitHub qui vérifie le code dans ce dépôt.
Certaines tâches peuvent nécessiter un peu plus de contexte. Bien qu'OpenHands puisse utiliser `ls` et `grep`
pour rechercher dans votre base de code, fournir le contexte à l'avance lui permet d'aller plus vite,
et plus précisément. Et cela vous coûtera moins de tokens !
Certaines tâches nécessitent plus de contexte. Bien qu'OpenHands puisse utiliser des commandes comme ls et grep pour rechercher, fournir du contexte dès le départ
accélère les choses et réduit l'utilisation de tokens.
> Veuillez modifier ./backend/api/routes.js pour ajouter une nouvelle route qui renvoie une liste de toutes les tâches
> Modifiez ./backend/api/routes.js pour ajouter une nouvelle route qui renvoie une liste de toutes les tâches.
> Veuillez ajouter un nouveau composant React qui affiche une liste de Widgets dans le répertoire ./frontend/components.
> Ajoutez un nouveau composant React au répertoire ./frontend/components pour afficher une liste de Widgets.
> Il devrait utiliser le composant Widget existant.
## Refactoring
OpenHands est excellent pour refactoriser du code existant, surtout par petits morceaux.
Vous ne voulez probablement pas essayer de réarchitecturer toute votre base de code, mais diviser
les longs fichiers et fonctions, renommer les variables, etc. ont tendance à très bien fonctionner.
OpenHands est très efficace pour refactoriser du code en petits morceaux. Plutôt que de réarchitecturer l'ensemble de la base de code,
il est plus efficace de décomposer les fichiers et fonctions longs ou de renommer des variables.
> Veuillez renommer toutes les variables à une lettre dans ./app.go
> Renommez toutes les variables à une seule lettre dans ./app.go.
> Veuillez diviser la fonction `build_and_deploy_widgets` en deux fonctions, `build_widgets` et `deploy_widgets` dans widget.php
> Divisez la fonction `build_and_deploy_widgets` en deux fonctions, `build_widgets` et `deploy_widgets` dans widget.php.
> Veuillez diviser ./api/routes.js en fichiers séparés pour chaque route
> Décomposez ./api/routes.js en fichiers séparés pour chaque route.
## Corrections de bugs
OpenHands peut également vous aider à traquer et corriger des bugs dans votre code. Mais, comme tout
développeur le sait, la correction de bugs peut être extrêmement délicate, et souvent OpenHands aura besoin de plus de contexte.
Cela aide si vous avez diagnostiqué le bug, mais que vous voulez qu'OpenHands comprenne la logique.
OpenHands peut aider à traquer et corriger des bugs, mais la correction de bugs peut être délicate et nécessite souvent plus de contexte.
C'est utile si vous avez déjà diagnostiqué le problème et avez juste besoin qu'OpenHands gère la logique.
> Actuellement, le champ email dans le point de terminaison `/subscribe` rejette les domaines .io. Veuillez corriger cela.
> Le champ email dans le point de terminaison `/subscribe` rejette les domaines .io. Corrigez cela.
> La fonction `search_widgets` dans ./app.py effectue une recherche sensible à la casse. Veuillez la rendre insensible à la casse.
> La fonction `search_widgets` dans ./app.py effectue une recherche sensible à la casse. Rendez-la insensible à la casse.
Il est souvent utile de faire du développement piloté par les tests lors de la correction de bugs avec un agent.
Vous pouvez demander à l'agent d'écrire un nouveau test, puis d'itérer jusqu'à ce qu'il corrige le bug :
Pour la correction de bugs, le développement piloté par les tests peut être vraiment utile. Vous pouvez demander à l'agent d'écrire un nouveau test et d'itérer
jusqu'à ce que le bug soit corrigé :
> La fonction `hello` plante sur la chaîne vide. Veuillez écrire un test qui reproduit ce bug, puis corrigez le code pour qu'il passe.
> La fonction `hello` plante sur une chaîne vide. Écrivez un test qui reproduit ce bug, puis corrigez le code pour qu'il passe.
## Plus
OpenHands est capable d'aider sur à peu près n'importe quelle tâche de codage. Mais il faut de la pratique
pour en tirer le meilleur parti. N'oubliez pas de :
* Garder vos tâches petites
* Être aussi précis que possible
* Fournir autant de contexte que possible
* Commiter et pousser fréquemment
OpenHands peut vous aider pour presque n'importe quelle tâche de codage, mais il faut un peu de pratique pour obtenir les meilleurs résultats.
Gardez ces conseils à l'esprit :
* Gardez vos tâches petites.
* Soyez précis.
* Fournissez beaucoup de contexte.
* Committez et poussez fréquemment.
Voir [Bonnes pratiques de prompting](./prompting/prompting-best-practices) pour plus de conseils sur la façon de tirer le meilleur parti d'OpenHands.
Consultez [Meilleures pratiques de prompt](./prompting/prompting-best-practices) pour plus de conseils sur la façon de tirer le meilleur parti d'OpenHands.

89
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/cli-mode.md
View File

@ -1,5 +1,3 @@
# Mode CLI
OpenHands peut être exécuté en mode CLI interactif, ce qui permet aux utilisateurs de démarrer une session interactive via la ligne de commande.
@ -8,105 +6,50 @@ Ce mode est différent du [mode headless](headless-mode), qui est non interactif
## Avec Python
Pour démarrer une session OpenHands interactive via la ligne de commande, suivez ces étapes :
1. Assurez-vous d'avoir suivi les [instructions de configuration de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Pour démarrer une session interactive OpenHands via la ligne de commande :
1. Assurez-vous d'avoir suivi les [instructions de configuration pour le développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
2. Exécutez la commande suivante :
```bash
poetry run python -m openhands.core.cli
```
Cette commande démarrera une session interactive où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
Cette commande lancera une session interactive où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
Vous devrez vous assurer de définir votre modèle, votre clé API et d'autres paramètres via des variables d'environnement
Vous devrez vous assurer de définir votre modèle, clé API et autres paramètres via des variables d'environnement
[ou le fichier `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Avec Docker
Pour exécuter OpenHands en mode CLI avec Docker, suivez ces étapes :
Pour exécuter OpenHands en mode CLI avec Docker :
1. Définissez `WORKSPACE_BASE` sur le répertoire que vous voulez qu'OpenHands modifie :
1. Définissez les variables d'environnement suivantes dans votre terminal :
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
- `SANDBOX_VOLUMES` pour spécifier le répertoire auquel vous souhaitez qu'OpenHands accède (Ex : `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw`).
- L'agent travaille dans `/workspace` par défaut, donc montez votre répertoire de projet à cet emplacement si vous souhaitez que l'agent modifie des fichiers.
- Pour les données en lecture seule, utilisez un chemin de montage différent (Ex : `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw,/path/to/large/dataset:/data:ro`).
- `LLM_MODEL` pour le modèle à utiliser (Ex : `export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`).
- `LLM_API_KEY` pour la clé API (Ex : `export LLM_API_KEY="sk_test_12345"`).
2. Définissez `LLM_MODEL` sur le modèle que vous voulez utiliser :
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3. Définissez `LLM_API_KEY` sur votre clé API :
```bash
LLM_API_KEY="sk_test_12345"
```
4. Exécutez la commande Docker suivante :
2. Exécutez la commande Docker suivante :
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
--name openhands-app-$(date +%Y%m%d%H%M%S) \
docker.all-hands.dev/all-hands-ai/openhands:0.36 \
python -m openhands.core.cli
```
Cette commande démarrera une session interactive dans Docker où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
Cette commande lancera une session interactive dans Docker où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
## Exemples de commandes CLI et de sorties attendues
Voici quelques exemples de commandes CLI et leurs sorties attendues :
### Exemple 1 : Tâche simple
```bash
How can I help? >> Écrivez un script Python qui affiche "Hello, World!"
```
Sortie attendue :
```bash
🤖 Bien sûr ! Voici un script Python qui affiche "Hello, World!" :
❯ print("Hello, World!")
```
### Exemple 2 : Commande Bash
```bash
How can I help? >> Créez un répertoire nommé "test_dir"
```
Sortie attendue :
```bash
🤖 Création d'un répertoire nommé "test_dir" :
❯ mkdir test_dir
```
### Exemple 3 : Gestion des erreurs
```bash
How can I help? >> Supprimez un fichier inexistant
```
Sortie attendue :
```bash
🤖 Une erreur s'est produite. Veuillez réessayer.
```
Le paramètre `-e SANDBOX_USER_ID=$(id -u)` est transmis à la commande Docker pour s'assurer que l'utilisateur du sandbox correspond aux permissions de l'utilisateur hôte. Cela empêche l'agent de créer des fichiers appartenant à root dans l'espace de travail monté.

73
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/custom-sandbox-guide.md
View File

@ -1,50 +1,65 @@
# Sandbox personnalisé
# Sandbox Personnalisé
:::note
Ce guide est destiné aux utilisateurs qui souhaitent utiliser leur propre image Docker personnalisée pour l'environnement d'exécution. Par exemple, avec certains outils ou langages de programmation préinstallés.
:::
Le sandbox est l'endroit où l'agent effectue ses tâches. Au lieu d'exécuter des commandes directement sur votre ordinateur (ce qui pourrait être risqué), l'agent les exécute à l'intérieur d'un conteneur Docker.
Le sandbox OpenHands par défaut (`python-nodejs:python3.12-nodejs22` de [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)) est livré avec certains paquets installés tels que Python et Node.js mais peut nécessiter l'installation d'autres logiciels par défaut.
Le sandbox OpenHands par défaut (`python-nodejs:python3.12-nodejs22` de [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)) est livré avec certains packages installés comme python et Node.js, mais peut nécessiter d'autres logiciels installés par défaut.
Vous avez deux options pour la personnalisation :
1. Utiliser une image existante avec les logiciels requis.
2. Créer votre propre image Docker personnalisée.
- Utiliser une image existante avec les logiciels requis.
- Créer votre propre image Docker personnalisée.
Si vous choisissez la première option, vous pouvez passer la section `Créer Votre Image Docker`.
Si vous choisissez la première option, vous pouvez ignorer la section `Créer votre image Docker`.
## Créer Votre Image Docker
## Créer votre image Docker
Pour créer une image Docker personnalisée, elle doit être basée sur Debian.
Par exemple, si vous voulez qu'OpenHands ait `ruby` installé, créez un `Dockerfile` avec le contenu suivant :
Par exemple, si vous voulez qu'OpenHands ait `ruby` installé, vous pourriez créer un `Dockerfile` avec le contenu suivant :
```dockerfile
FROM debian:latest
FROM nikolaik/python-nodejs:python3.12-nodejs22
# Installer les paquets requis
# Install required packages
RUN apt-get update && apt-get install -y ruby
```
Enregistrez ce fichier dans un dossier. Ensuite, construisez votre image Docker (par exemple, nommée custom-image) en naviguant vers le dossier dans le terminal et en exécutant :
Ou vous pourriez utiliser une image de base spécifique à Ruby :
```dockerfile
FROM ruby:latest
```
Enregistrez ce fichier dans un dossier. Ensuite, construisez votre image Docker (par exemple, nommée custom-image) en naviguant vers le dossier dans le terminal et en exécutant :
```bash
docker build -t custom-image .
```
Cela produira une nouvelle image appelée `custom-image`, qui sera disponible dans Docker.
> Notez que dans la configuration décrite dans ce document, OpenHands s'exécutera en tant qu'utilisateur "openhands" à l'intérieur du sandbox et donc tous les paquets installés via le docker file devraient être disponibles pour tous les utilisateurs du système, pas seulement root.
## Utilisation de la commande Docker
## Utilisation du Workflow de Développement
Lorsque vous exécutez OpenHands en utilisant [la commande docker](/modules/usage/installation#start-the-app), remplacez `-e SANDBOX_RUNTIME_CONTAINER_IMAGE=...` par `-e SANDBOX_BASE_CONTAINER_IMAGE=<nom de l'image personnalisée>` :
```commandline
docker run -it --rm --pull=always \
-e SANDBOX_BASE_CONTAINER_IMAGE=custom-image \
...
```
## Utilisation du flux de travail de développement
### Configuration
Tout d'abord, assurez-vous de pouvoir exécuter OpenHands en suivant les instructions dans [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
### Spécifier l'Image de Base du Sandbox
### Spécifier l'image de base du Sandbox
Dans le fichier `config.toml` dans le répertoire OpenHands, définissez `base_container_image` sur l'image que vous souhaitez utiliser. Cela peut être une image que vous avez déjà extraite ou une que vous avez construite :
Dans le fichier `config.toml` du répertoire OpenHands, définissez `base_container_image` sur l'image que vous souhaitez utiliser. Il peut s'agir d'une image que vous avez déjà téléchargée ou que vous avez construite :
```bash
[core]
@ -53,10 +68,28 @@ Dans le fichier `config.toml` dans le répertoire OpenHands, définissez `base_c
base_container_image="custom-image"
```
### Options de configuration supplémentaires
Le fichier `config.toml` prend en charge plusieurs autres options pour personnaliser votre sandbox :
```toml
[core]
# Install additional dependencies when the runtime is built
# Can contain any valid shell commands
# If you need the path to the Python interpreter in any of these commands, you can use the $OH_INTERPRETER_PATH variable
runtime_extra_deps = """
pip install numpy pandas
apt-get update && apt-get install -y ffmpeg
"""
# Set environment variables for the runtime
# Useful for configuration that needs to be available at runtime
runtime_startup_env_vars = { DATABASE_URL = "postgresql://user:pass@localhost/db" }
# Specify platform for multi-architecture builds (e.g., "linux/amd64" or "linux/arm64")
platform = "linux/amd64"
```
### Exécution
Exécutez OpenHands en exécutant ```make run``` dans le répertoire de niveau supérieur.
## Explication Technique
Veuillez vous référer à la [section image docker personnalisée de la documentation d'exécution](https://docs.all-hands.dev/modules/usage/architecture/runtime#advanced-how-openhands-builds-and-maintains-od-runtime-images) pour plus de détails.
Exécutez OpenHands en lançant ```make run``` dans le répertoire principal.

14
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/debugging.md
View File

@ -1,12 +1,10 @@
# Débogage
Ce qui suit est destiné à servir d'introduction au débogage d'OpenHands à des fins de développement.
## Serveur / VSCode
Le `launch.json` suivant permettra de déboguer les éléments agent, contrôleur et serveur, mais pas le bac à sable (qui s'exécute dans docker). Il ignorera toutes les modifications à l'intérieur du répertoire `workspace/` :
Le fichier `launch.json` suivant permettra de déboguer les éléments de l'agent, du contrôleur et du serveur, mais pas le bac à sable (qui s'exécute dans Docker). Il ignorera tous les changements dans le répertoire `workspace/` :
```
{
@ -38,7 +36,7 @@ Le `launch.json` suivant permettra de déboguer les éléments agent, contrôleu
}
```
Des configurations de débogage plus spécifiques qui incluent plus de paramètres peuvent être spécifiées :
Des configurations de débogage plus spécifiques qui incluent davantage de paramètres peuvent être spécifiées :
```
...
@ -49,7 +47,7 @@ Des configurations de débogage plus spécifiques qui incluent plus de paramètr
"module": "openhands.core.main",
"args": [
"-t",
"Demandez-moi quelle est votre tâche.",
"Ask me what your task is.",
"-d",
"${workspaceFolder}/workspace",
"-c",
@ -64,10 +62,10 @@ Des configurations de débogage plus spécifiques qui incluent plus de paramètr
...
```
Les valeurs dans l'extrait ci-dessus peuvent être mises à jour de telle sorte que :
Les valeurs dans l'extrait ci-dessus peuvent être mises à jour de sorte que :
* *t* : la tâche
* *d* : le répertoire de l'espace de travail openhands
* *d* : le répertoire de travail openhands
* *c* : l'agent
* *l* : la configuration LLM (prédéfinie dans config.toml)
* *n* : le nom de la session (par exemple, le nom du flux d'événements)
* *n* : nom de session (par exemple, nom d'eventstream)

74
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/development-overview.md Normal file
View File

@ -0,0 +1,74 @@
---
sidebar_position: 9
---
# Aperçu du développement
Ce guide fournit un aperçu des principales ressources de documentation disponibles dans le dépôt OpenHands. Que vous souhaitiez contribuer, comprendre l'architecture ou travailler sur des composants spécifiques, ces ressources vous aideront à naviguer efficacement dans le code.
## Documentation principale
### Fondamentaux du projet
- **Aperçu principal du projet** (`/README.md`)
Le point d'entrée principal pour comprendre OpenHands, y compris les fonctionnalités et les instructions de configuration de base.
- **Guide de développement** (`/Development.md`)
Guide complet pour les développeurs travaillant sur OpenHands, incluant la configuration, les exigences et les flux de travail de développement.
- **Directives de contribution** (`/CONTRIBUTING.md`)
Informations essentielles pour les contributeurs, couvrant le style de code, le processus de PR et les flux de travail de contribution.
### Documentation des composants
#### Frontend
- **Application Frontend** (`/frontend/README.md`)
Guide complet pour configurer et développer l'application frontend basée sur React.
#### Backend
- **Implémentation Backend** (`/openhands/README.md`)
Documentation détaillée de l'implémentation et de l'architecture du backend Python.
- **Documentation du serveur** (`/openhands/server/README.md`)
Détails d'implémentation du serveur, documentation API et architecture des services.
- **Environnement d'exécution** (`/openhands/runtime/README.md`)
Documentation couvrant l'environnement d'exécution, le modèle d'exécution et les configurations d'exécution.
#### Infrastructure
- **Documentation des conteneurs** (`/containers/README.md`)
Informations complètes sur les conteneurs Docker, les stratégies de déploiement et la gestion des conteneurs.
### Tests et évaluation
- **Guide des tests unitaires** (`/tests/unit/README.md`)
Instructions pour écrire, exécuter et maintenir les tests unitaires.
- **Cadre d'évaluation** (`/evaluation/README.md`)
Documentation du cadre d'évaluation, des benchmarks et des tests de performance.
### Fonctionnalités avancées
- **Architecture des microagents** (`/microagents/README.md`)
Informations détaillées sur l'architecture des microagents, leur implémentation et leur utilisation.
### Normes de documentation
- **Guide de style de documentation** (`/docs/DOC_STYLE_GUIDE.md`)
Normes et directives pour la rédaction et la maintenance de la documentation du projet.
## Débuter avec le développement
Si vous débutez dans le développement avec OpenHands, nous vous recommandons de suivre cette séquence :
1. Commencez par le `README.md` principal pour comprendre l'objectif et les fonctionnalités du projet
2. Consultez les directives de `CONTRIBUTING.md` si vous prévoyez de contribuer
3. Suivez les instructions de configuration dans `Development.md`
4. Plongez dans la documentation spécifique des composants selon votre domaine d'intérêt :
- Les développeurs frontend devraient se concentrer sur `/frontend/README.md`
- Les développeurs backend devraient commencer par `/openhands/README.md`
- Le travail d'infrastructure devrait commencer par `/containers/README.md`
## Mises à jour de la documentation
Lorsque vous apportez des modifications au code, veuillez vous assurer que :
1. La documentation pertinente est mise à jour pour refléter vos changements
2. Les nouvelles fonctionnalités sont documentées dans les fichiers README appropriés
3. Tout changement d'API est reflété dans la documentation du serveur
4. La documentation suit le guide de style dans `/docs/DOC_STYLE_GUIDE.md`

72
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/evaluation-harness.md
View File

@ -1,19 +1,17 @@
# Évaluation
Ce guide fournit un aperçu de la façon d'intégrer votre propre benchmark d'évaluation dans le framework OpenHands.
## Configuration de l'environnement et de la configuration LLM
## Configuration de l'environnement et configuration du LLM
Veuillez suivre les instructions [ici](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) pour configurer votre environnement de développement local.
OpenHands en mode développement utilise `config.toml` pour garder une trace de la plupart des configurations.
OpenHands en mode développement utilise `config.toml` pour suivre la plupart des configurations.
Voici un exemple de fichier de configuration que vous pouvez utiliser pour définir et utiliser plusieurs LLMs :
Voici un exemple de fichier de configuration que vous pouvez utiliser pour définir et utiliser plusieurs LLM :
```toml
[llm]
# IMPORTANT : ajoutez votre clé API ici et définissez le modèle que vous souhaitez évaluer
# IMPORTANT: ajoutez votre clé API ici et définissez le modèle que vous souhaitez évaluer
model = "claude-3-5-sonnet-20241022"
api_key = "sk-XXX"
@ -47,7 +45,7 @@ Par exemple :
```bash
poetry run python ./openhands/core/main.py \
-i 10 \
-t "Écrivez-moi un script bash qui affiche hello world." \
-t "Write me a bash script that prints hello world." \
-c CodeActAgent \
-l llm
```
@ -55,29 +53,29 @@ poetry run python ./openhands/core/main.py \
Cette commande exécute OpenHands avec :
- Un maximum de 10 itérations
- La description de tâche spécifiée
- En utilisant CodeActAgent
- Utilisant le CodeActAgent
- Avec la configuration LLM définie dans la section `llm` de votre fichier `config.toml`
## Comment fonctionne OpenHands
Le point d'entrée principal d'OpenHands se trouve dans `openhands/core/main.py`. Voici un flux simplifié de son fonctionnement :
1. Analyse des arguments de ligne de commande et chargement de la configuration
2. Création d'un environnement d'exécution à l'aide de `create_runtime()`
3. Initialisation de l'agent spécifié
4. Exécution du contrôleur à l'aide de `run_controller()`, qui :
- Attache l'environnement d'exécution à l'agent
1. Analyser les arguments de ligne de commande et charger la configuration
2. Créer un environnement d'exécution en utilisant `create_runtime()`
3. Initialiser l'agent spécifié
4. Exécuter le contrôleur en utilisant `run_controller()`, qui :
- Attache le runtime à l'agent
- Exécute la tâche de l'agent
- Renvoie un état final une fois terminé
La fonction `run_controller()` est le cœur de l'exécution d'OpenHands. Elle gère l'interaction entre l'agent, l'environnement d'exécution et la tâche, en gérant des choses comme la simulation d'entrée utilisateur et le traitement des événements.
La fonction `run_controller()` est le cœur de l'exécution d'OpenHands. Elle gère l'interaction entre l'agent, le runtime et la tâche, en gérant des éléments comme la simulation d'entrée utilisateur et le traitement des événements.
## Le moyen le plus simple de commencer : Explorer les benchmarks existants
## Façon la plus simple de commencer : Explorer les benchmarks existants
Nous vous encourageons à examiner les différents benchmarks d'évaluation disponibles dans le [répertoire `evaluation/benchmarks/`](https://github.com/All-Hands-AI/OpenHands/blob/main/evaluation/benchmarks) de notre dépôt.
Pour intégrer votre propre benchmark, nous vous suggérons de commencer par celui qui ressemble le plus à vos besoins. Cette approche peut considérablement rationaliser votre processus d'intégration, vous permettant de vous appuyer sur les structures existantes et de les adapter à vos exigences spécifiques.
Pour intégrer votre propre benchmark, nous vous suggérons de commencer par celui qui ressemble le plus à vos besoins. Cette approche peut considérablement simplifier votre processus d'intégration, vous permettant de vous appuyer sur des structures existantes et de les adapter à vos exigences spécifiques.
## Comment créer un workflow d'évaluation
@ -126,7 +124,7 @@ Pour créer un workflow d'évaluation pour votre benchmark, suivez ces étapes :
return config
```
3. Initialisez l'environnement d'exécution et configurez l'environnement d'évaluation :
3. Initialisez le runtime et configurez l'environnement d'évaluation :
```python
def initialize_runtime(runtime: Runtime, instance: pd.Series):
# Configurez votre environnement d'évaluation ici
@ -183,19 +181,19 @@ Pour créer un workflow d'évaluation pour votre benchmark, suivez ces étapes :
Ce workflow configure la configuration, initialise l'environnement d'exécution, traite chaque instance en exécutant l'agent et en évaluant ses actions, puis collecte les résultats dans un objet `EvalOutput`. La fonction `run_evaluation` gère la parallélisation et le suivi de la progression.
N'oubliez pas de personnaliser les fonctions `get_instruction`, `your_user_response_function` et `evaluate_agent_actions` en fonction des exigences spécifiques de votre benchmark.
N'oubliez pas de personnaliser les fonctions `get_instruction`, `your_user_response_function` et `evaluate_agent_actions` selon les exigences spécifiques de votre benchmark.
En suivant cette structure, vous pouvez créer un workflow d'évaluation robuste pour votre benchmark dans le framework OpenHands.
## Comprendre la `user_response_fn`
## Comprendre la fonction `user_response_fn`
La `user_response_fn` est un composant crucial dans le workflow d'évaluation d'OpenHands. Elle simule l'interaction de l'utilisateur avec l'agent, permettant des réponses automatisées pendant le processus d'évaluation. Cette fonction est particulièrement utile lorsque vous voulez fournir des réponses cohérentes et prédéfinies aux requêtes ou actions de l'agent.
La fonction `user_response_fn` est un composant crucial dans le workflow d'évaluation d'OpenHands. Elle simule l'interaction utilisateur avec l'agent, permettant des réponses automatisées pendant le processus d'évaluation. Cette fonction est particulièrement utile lorsque vous souhaitez fournir des réponses cohérentes et prédéfinies aux requêtes ou actions de l'agent.
### Workflow et interaction
Le workflow correct pour gérer les actions et la `user_response_fn` est le suivant :
Le workflow correct pour gérer les actions et la fonction `user_response_fn` est le suivant :
1. L'agent reçoit une tâche et commence à la traiter
2. L'agent émet une Action
@ -203,7 +201,7 @@ Le workflow correct pour gérer les actions et la `user_response_fn` est le suiv
- Le Runtime traite l'Action
- Le Runtime renvoie une Observation
4. Si l'Action n'est pas exécutable (généralement une MessageAction) :
- La `user_response_fn` est appelée
- La fonction `user_response_fn` est appelée
- Elle renvoie une réponse utilisateur simulée
5. L'agent reçoit soit l'Observation, soit la réponse simulée
6. Les étapes 2 à 5 se répètent jusqu'à ce que la tâche soit terminée ou que le nombre maximum d'itérations soit atteint
@ -214,7 +212,7 @@ Voici une représentation visuelle plus précise :
[Agent]
|
v
[Émettre une Action]
[Émet Action]
|
v
[L'Action est-elle exécutable ?]
@ -225,48 +223,48 @@ Voici une représentation visuelle plus précise :
[Runtime] [user_response_fn]
| |
v v
[Renvoyer une Observation] [Réponse simulée]
[Renvoie Observation] [Réponse simulée]
\ /
\ /
v v
[L'agent reçoit le feedback]
|
v
[Continuer ou terminer la tâche]
[Continue ou termine la tâche]
```
Dans ce workflow :
- Les actions exécutables (comme l'exécution de commandes ou de code) sont gérées directement par le Runtime
- Les actions non exécutables (généralement lorsque l'agent veut communiquer ou demander des clarifications) sont gérées par la `user_response_fn`
- L'agent traite ensuite le feedback, qu'il s'agisse d'une Observation du Runtime ou d'une réponse simulée de la `user_response_fn`
- Les actions non exécutables (généralement lorsque l'agent veut communiquer ou demander des clarifications) sont gérées par la fonction `user_response_fn`
- L'agent traite ensuite le feedback, qu'il s'agisse d'une Observation du Runtime ou d'une réponse simulée de la fonction `user_response_fn`
Cette approche permet une gestion automatisée des actions concrètes et des interactions utilisateur simulées, ce qui la rend adaptée aux scénarios d'évaluation où vous voulez tester la capacité de l'agent à accomplir des tâches avec une intervention humaine minimale.
Cette approche permet une gestion automatisée des actions concrètes et des interactions utilisateur simulées, ce qui la rend adaptée aux scénarios d'évaluation où vous souhaitez tester la capacité de l'agent à accomplir des tâches avec une intervention humaine minimale.
### Exemple d'implémentation
Voici un exemple de `user_response_fn` utilisée dans l'évaluation SWE-Bench :
Voici un exemple de fonction `user_response_fn` utilisée dans l'évaluation SWE-Bench :
```python
def codeact_user_response(state: State | None) -> str:
msg = (
'Veuillez continuer à travailler sur la tâche avec l\'approche que vous jugez appropriée.\n'
'Si vous pensez avoir résolu la tâche, veuillez d\'abord envoyer votre réponse à l\'utilisateur via un message, puis <execute_bash> exit </execute_bash>.\n'
'IMPORTANT : VOUS NE DEVEZ JAMAIS DEMANDER DE L\'AIDE HUMAINE.\n'
'Please continue working on the task on whatever approach you think is suitable.\n'
'If you think you have solved the task, please first send your answer to user through message and then <execute_bash> exit </execute_bash>.\n'
'IMPORTANT: YOU SHOULD NEVER ASK FOR HUMAN HELP.\n'
)
if state and state.history:
# vérifier si l'agent a essayé de parler à l'utilisateur 3 fois, si oui, faire savoir à l'agent qu'il peut abandonner
# check if the agent has tried to talk to the user 3 times, if so, let the agent know it can give up
user_msgs = [
event
for event in state.history
if isinstance(event, MessageAction) and event.source == 'user'
]
if len(user_msgs) >= 2:
# faire savoir à l'agent qu'il peut abandonner quand il a essayé 3 fois
# let the agent know that it can give up when it has tried 3 times
return (
msg
+ 'Si vous voulez abandonner, exécutez : <execute_bash> exit </execute_bash>.\n'
+ 'If you want to give up, run: <execute_bash> exit </execute_bash>.\n'
)
return msg
```
@ -275,6 +273,6 @@ Cette fonction fait ce qui suit :
1. Fournit un message standard encourageant l'agent à continuer à travailler
2. Vérifie combien de fois l'agent a tenté de communiquer avec l'utilisateur
3. Si l'agent a fait plusieurs tentatives, il lui donne la possibilité d'abandonner
3. Si l'agent a fait plusieurs tentatives, elle lui fournit une option pour abandonner
En utilisant cette fonction, vous pouvez assurer un comportement cohérent sur plusieurs exécutions d'évaluation et empêcher l'agent de rester bloqué en attendant une entrée humaine.
En utilisant cette fonction, vous pouvez assurer un comportement cohérent à travers plusieurs séries d'évaluations et empêcher l'agent de rester bloqué en attendant une entrée humaine.

54
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/github-action.md
View File

@ -1,51 +1,51 @@
# Utilisation de l'Action GitHub OpenHands
Ce guide explique comment utiliser l'Action GitHub OpenHands, à la fois dans le dépôt OpenHands et dans vos propres projets.
Ce guide explique comment utiliser l'Action GitHub OpenHands dans vos propres projets.
## Utilisation de l'Action dans le dépôt OpenHands
## Utilisation de l'Action dans le Dépôt OpenHands
Pour utiliser l'Action GitHub OpenHands dans un dépôt, vous pouvez :
1. Créer un ticket dans le dépôt.
2. Ajouter l'étiquette `fix-me` au ticket ou laisser un commentaire sur le ticket commençant par `@openhands-agent`.
1. Créer une issue dans le dépôt.
2. Ajouter l'étiquette `fix-me` à l'issue ou laisser un commentaire sur l'issue commençant par `@openhands-agent`.
L'action se déclenchera automatiquement et tentera de résoudre le ticket.
L'action se déclenchera automatiquement et tentera de résoudre l'issue.
## Installation de l'Action dans un nouveau dépôt
## Installation de l'Action dans un Nouveau Dépôt
Pour installer l'Action GitHub OpenHands dans votre propre dépôt, suivez le [README pour le Resolver OpenHands](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md).
Pour installer l'Action GitHub OpenHands dans votre propre dépôt, suivez
le [README du Résolveur OpenHands](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md).
## Conseils d'utilisation
## Conseils d'Utilisation
### Résolution itérative
1. Créez un ticket dans le dépôt.
2. Ajoutez l'étiquette `fix-me` au ticket, ou laissez un commentaire commençant par `@openhands-agent`
3. Examinez la tentative de résolution du ticket en vérifiant la pull request
4. Faites un suivi avec des commentaires via des commentaires généraux, des commentaires de revue ou des commentaires de fil en ligne
5. Ajoutez l'étiquette `fix-me` à la pull request, ou adressez un commentaire spécifique en commençant par `@openhands-agent`
1. Créez une issue dans le dépôt.
2. Ajoutez l'étiquette `fix-me` à l'issue, ou laissez un commentaire commençant par `@openhands-agent`.
3. Examinez la tentative de résolution de l'issue en vérifiant la pull request.
4. Donnez votre feedback via des commentaires généraux, des commentaires de révision ou des commentaires en ligne.
5. Ajoutez l'étiquette `fix-me` à la pull request, ou répondez à un commentaire spécifique en commençant par `@openhands-agent`.
### Étiquette versus Macro
- Étiquette (`fix-me`) : Demande à OpenHands de traiter le ticket ou la pull request dans son **intégralité**.
- Macro (`@openhands-agent`) : Demande à OpenHands de ne considérer que la description du ticket/de la pull request et **le commentaire spécifique**.
- Étiquette (`fix-me`) : Demande à OpenHands de traiter **l'ensemble** de l'issue ou de la pull request.
- Macro (`@openhands-agent`) : Demande à OpenHands de considérer uniquement la description de l'issue/pull request et **le commentaire spécifique**.
## Paramètres avancés
## Paramètres Avancés
### Ajouter des paramètres de dépôt personnalisés
### Ajouter des paramètres personnalisés au dépôt
Vous pouvez fournir des instructions personnalisées pour OpenHands en suivant le [README pour le resolver](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md#providing-custom-instructions).
Vous pouvez fournir des instructions personnalisées pour OpenHands en suivant le [README du résolveur](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md#providing-custom-instructions).
### Configurations personnalisées
Le resolver Github vérifiera automatiquement les [secrets de dépôt](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions?tool=webui#creating-secrets-for-a-repository) ou les [variables de dépôt](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#creating-configuration-variables-for-a-repository) valides pour personnaliser son comportement.
Le résolveur GitHub vérifiera automatiquement les [secrets du dépôt](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions?tool=webui#creating-secrets-for-a-repository) valides ou les [variables du dépôt](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#creating-configuration-variables-for-a-repository) pour personnaliser son comportement.
Les options de personnalisation que vous pouvez définir sont :
| **Nom de l'attribut** | **Type** | **Objectif** | **Exemple** |
|----------------------------------| -------- |-------------------------------------------------------------------------------------------------------------|------------------------------------------------------|
| `LLM_MODEL` | Variable | Définir le LLM à utiliser avec OpenHands | `LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"` |
| `OPENHANDS_MAX_ITER` | Variable | Définir la limite maximale pour les itérations de l'agent | `OPENHANDS_MAX_ITER=10` |
| `OPENHANDS_MACRO` | Variable | Personnaliser la macro par défaut pour invoquer le resolver | `OPENHANDS_MACRO=@resolveit` |
| `OPENHANDS_BASE_CONTAINER_IMAGE` | Variable | Sandbox personnalisé ([en savoir plus](https://docs.all-hands.dev/modules/usage/how-to/custom-sandbox-guide))| `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |
| **Nom de l'attribut** | **Type** | **Objectif** | **Exemple** |
| -------------------------------- | -------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| `LLM_MODEL` | Variable | Définir le LLM à utiliser avec OpenHands | `LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"` |
| `OPENHANDS_MAX_ITER` | Variable | Définir la limite maximale d'itérations de l'agent | `OPENHANDS_MAX_ITER=10` |
| `OPENHANDS_MACRO` | Variable | Personnaliser la macro par défaut pour invoquer le résolveur | `OPENHANDS_MACRO=@resolveit` |
| `OPENHANDS_BASE_CONTAINER_IMAGE` | Variable | Sandbox personnalisé ([en savoir plus](https://docs.all-hands.dev/modules/usage/how-to/custom-sandbox-guide)) | `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |
| `TARGET_BRANCH` | Variable | Fusionner vers une branche autre que `main` | `TARGET_BRANCH="dev"` |

226
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/gui-mode.md
View File

@ -1,168 +1,142 @@
# Mode GUI
# Mode Interface Graphique
## Introduction
OpenHands fournit un mode Interface Graphique (GUI) convivial pour interagir avec l'assistant IA. Ce mode offre une façon intuitive de configurer l'environnement, gérer les paramètres et communiquer avec l'IA.
OpenHands fournit un mode d'Interface Graphique Utilisateur (GUI) pour interagir avec l'assistant IA.
## Installation et Configuration
1. Suivez les instructions du guide [Installation](../installation) pour installer OpenHands.
1. Suivez les instructions d'installation pour installer OpenHands.
2. Après avoir exécuté la commande, accédez à OpenHands à [http://localhost:3000](http://localhost:3000).
2. Après avoir exécuté la commande, accédez à OpenHands à l'adresse [http://localhost:3000](http://localhost:3000).
## Interagir avec l'interface graphique
## Interagir avec l'Interface Graphique
### Configuration initiale
### Configuration Initiale
1. Lors du premier lancement, vous verrez une fenêtre modale de paramètres.
2. Sélectionnez un `Fournisseur LLM` et un `Modèle LLM` dans les menus déroulants.
1. Lors du premier lancement, vous verrez une fenêtre de paramètres.
2. Sélectionnez un `Fournisseur LLM` et un `Modèle LLM` dans les menus déroulants. Si le modèle requis n'existe pas dans la liste,
sélectionnez `voir les paramètres avancés`. Ensuite, activez les options `Avancées` et saisissez-le avec le préfixe correct dans la
zone de texte `Modèle personnalisé`.
3. Entrez la `Clé API` correspondante pour le fournisseur choisi.
4. Cliquez sur "Enregistrer" pour appliquer les paramètres.
4. Cliquez sur `Enregistrer les modifications` pour appliquer les paramètres.
### Jetons de Contrôle de Version
### Jetons de contrôle de version
OpenHands prend en charge plusieurs fournisseurs de contrôle de version. Vous pouvez configurer des jetons pour plusieurs fournisseurs simultanément.
#### Configuration du Jeton GitHub
#### Configuration du jeton GitHub
OpenHands exporte automatiquement un `GITHUB_TOKEN` vers l'environnement shell s'il est disponible. Cela peut se produire de deux manières :
OpenHands exporte automatiquement un `GITHUB_TOKEN` vers l'environnement shell s'il est fourni :
1. **Localement (OSS)** : L'utilisateur saisit directement son jeton GitHub
2. **En ligne (SaaS)** : Le jeton est obtenu via l'authentification OAuth GitHub
<details>
<summary>Configuration d'un jeton GitHub</summary>
##### Configuration d'un Jeton GitHub Local
1. **Générer un jeton d'accès personnel (PAT)** :
- Sur GitHub, allez dans Paramètres > Paramètres développeur > Jetons d'accès personnels > Jetons (classique).
- **Nouveau jeton (classique)**
- Portées requises :
- `repo` (Contrôle complet des dépôts privés)
- **Jetons à portée précise**
- Tous les dépôts (Vous pouvez sélectionner des dépôts spécifiques, mais cela affectera les résultats de recherche)
- Autorisations minimales (Sélectionnez `Meta Data = Lecture seule` pour la recherche, `Pull Requests = Lecture et écriture` et `Content = Lecture et écriture` pour la création de branches)
2. **Entrer le jeton dans OpenHands** :
- Cliquez sur le bouton Paramètres (icône d'engrenage).
- Collez votre jeton dans le champ `Jeton GitHub`.
- Cliquez sur `Enregistrer` pour appliquer les modifications.
</details>
1. **Générer un Personal Access Token (PAT)** :
- Allez dans Paramètres GitHub > Paramètres développeur > Personal Access Tokens > Tokens (classique)
- Cliquez sur "Générer un nouveau jeton (classique)"
- Portées requises :
- `repo` (Contrôle total des dépôts privés)
- `workflow` (Mettre à jour les workflows GitHub Action)
- `read:org` (Lire les données de l'organisation)
<details>
<summary>Politiques de jetons organisationnels</summary>
2. **Entrer le Jeton dans OpenHands** :
- Cliquez sur le bouton Paramètres (icône d'engrenage) en haut à droite
- Accédez à la section "Git Provider Settings"
- Collez votre jeton dans le champ "Jeton GitHub"
- Cliquez sur "Enregistrer" pour appliquer les modifications
Si vous travaillez avec des dépôts organisationnels, une configuration supplémentaire peut être nécessaire :
##### Politiques de Jetons Organisationnels
1. **Vérifier les exigences de l'organisation** :
- Les administrateurs de l'organisation peuvent imposer des politiques de jetons spécifiques.
- Certaines organisations exigent que les jetons soient créés avec SSO activé.
- Consultez les [paramètres de politique de jetons](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization) de votre organisation.
2. **Vérifier l'accès à l'organisation** :
- Accédez à vos paramètres de jeton sur GitHub.
- Recherchez l'organisation sous `Accès à l'organisation`.
- Si nécessaire, cliquez sur `Activer SSO` à côté de votre organisation.
- Complétez le processus d'autorisation SSO.
</details>
Si vous travaillez avec des dépôts organisationnels, une configuration supplémentaire peut être nécessaire :
<details>
<summary>Dépannage</summary>
1. **Vérifier les Exigences de l'Organisation** :
- Les administrateurs de l'organisation peuvent appliquer des politiques de jetons spécifiques
- Certaines organisations exigent que les jetons soient créés avec SSO activé
- Consultez les [paramètres de politique de jetons](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization) de votre organisation
Problèmes courants et solutions :
2. **Vérifier l'Accès à l'Organisation** :
- Allez dans les paramètres de votre jeton sur GitHub
- Recherchez l'organisation sous "Accès à l'organisation"
- Si nécessaire, cliquez sur "Activer SSO" à côté de votre organisation
- Terminez le processus d'autorisation SSO
- **Jeton non reconnu** :
- Assurez-vous que le jeton est correctement enregistré dans les paramètres.
- Vérifiez que le jeton n'a pas expiré.
- Vérifiez que le jeton dispose des portées requises.
- Essayez de régénérer le jeton.
##### Authentification OAuth (Mode En Ligne)
- **Accès à l'organisation refusé** :
- Vérifiez si SSO est requis mais non activé.
- Vérifiez l'appartenance à l'organisation.
- Contactez l'administrateur de l'organisation si les politiques de jetons bloquent l'accès.
Lorsque vous utilisez OpenHands en mode en ligne, le flux OAuth GitHub :
- **Vérification du fonctionnement du jeton** :
- L'application affichera une coche verte si le jeton est valide.
- Essayez d'accéder à un dépôt pour confirmer les autorisations.
- Vérifiez la console du navigateur pour tout message d'erreur.
</details>
1. Demande les autorisations suivantes :
- Accès au dépôt (lecture/écriture)
- Gestion des workflows
- Accès en lecture à l'organisation
#### Configuration du jeton GitLab
2. Étapes d'authentification :
- Cliquez sur "Se connecter avec GitHub" lorsque vous y êtes invité
- Examinez les autorisations demandées
- Autorisez OpenHands à accéder à votre compte GitHub
- Si vous utilisez une organisation, autorisez l'accès à l'organisation si vous y êtes invité
OpenHands exporte automatiquement un `GITLAB_TOKEN` vers l'environnement shell s'il est fourni :
##### Dépannage
<details>
<summary>Configuration d'un jeton GitLab</summary>
Problèmes courants et solutions :
1. **Jeton Non Reconnu** :
- Assurez-vous que le jeton est correctement enregistré dans les paramètres
- Vérifiez que le jeton n'a pas expiré
- Vérifiez que le jeton a les portées requises
- Essayez de régénérer le jeton
2. **Accès à l'Organisation Refusé** :
- Vérifiez si SSO est requis mais non activé
- Vérifiez l'appartenance à l'organisation
- Contactez l'administrateur de l'organisation si les politiques de jetons bloquent l'accès
3. **Vérifier que le Jeton Fonctionne** :
- L'application affichera une coche verte si le jeton est valide
- Essayez d'accéder à un dépôt pour confirmer les autorisations
- Vérifiez la console du navigateur pour tout message d'erreur
- Utilisez le bouton "Tester la connexion" dans les paramètres s'il est disponible
#### Configuration du Jeton GitLab
OpenHands exporte automatiquement un `GITLAB_TOKEN` vers l'environnement shell, uniquement pour les installations locales, s'il est disponible.
##### Configuration d'un Jeton GitLab
1. **Générer un Personal Access Token (PAT)** :
- Sur GitLab, allez dans Paramètres utilisateur > Jetons d'accès
1. **Générer un jeton d'accès personnel (PAT)** :
- Sur GitLab, allez dans Paramètres utilisateur > Jetons d'accès.
- Créez un nouveau jeton avec les portées suivantes :
- `api` (Accès API)
- `read_user` (Lecture des informations utilisateur)
- `read_repository` (Lecture du dépôt)
- `write_repository` (Écriture du dépôt)
- Définissez une date d'expiration ou laissez vide pour un jeton sans expiration
- `read_user` (Lire les informations utilisateur)
- `read_repository` (Lire le dépôt)
- `write_repository` (Écrire dans le dépôt)
- Définissez une date d'expiration ou laissez-la vide pour un jeton sans expiration.
2. **Entrer le jeton dans OpenHands** :
- Cliquez sur le bouton Paramètres (icône d'engrenage).
- Collez votre jeton dans le champ `Jeton GitLab`.
- Entrez l'URL de votre instance GitLab si vous utilisez GitLab auto-hébergé.
- Cliquez sur `Enregistrer` pour appliquer les modifications.
</details>
2. **Entrer le Jeton dans OpenHands** :
- Cliquez sur le bouton Paramètres (icône d'engrenage)
- Accédez à la section `Git Provider Settings`
- Collez votre jeton dans le champ `Jeton GitLab`
- Si vous utilisez GitLab auto-hébergé, entrez l'URL de votre instance GitLab
- Cliquez sur `Enregistrer les modifications` pour appliquer les changements
<details>
<summary>Dépannage</summary>
##### Dépannage
Problèmes courants et solutions :
Problèmes courants et solutions :
- **Jeton non reconnu** :
- Assurez-vous que le jeton est correctement enregistré dans les paramètres.
- Vérifiez que le jeton n'a pas expiré.
- Vérifiez que le jeton dispose des portées requises.
- Pour les instances auto-hébergées, vérifiez l'URL correcte de l'instance.
1. **Jeton Non Reconnu** :
- Assurez-vous que le jeton est correctement enregistré dans les paramètres
- Vérifiez que le jeton n'a pas expiré
- Vérifiez que le jeton a les portées requises
- Pour les instances auto-hébergées, vérifiez l'URL correcte de l'instance
- **Accès refusé** :
- Vérifiez les autorisations d'accès au projet.
- Vérifiez si le jeton dispose des portées nécessaires.
- Pour les dépôts de groupe/organisation, assurez-vous d'avoir un accès approprié.
</details>
2. **Accès Refusé** :
- Vérifiez les permissions d'accès au projet
- Vérifiez si le jeton possède les portées nécessaires
- Pour les dépôts de groupe/organisation, assurez-vous d'avoir les accès appropriés
### Paramètres avancés
### Paramètres Avancés
1. Basculez sur `Options Avancées` pour accéder aux paramètres supplémentaires.
2. Utilisez la zone de texte `Modèle Personnalisé` pour saisir manuellement un modèle s'il ne figure pas dans la liste.
3. Spécifiez une `URL de Base` si requis par votre fournisseur LLM.
### Interface Principale
L'interface principale se compose de plusieurs composants clés :
1. **Fenêtre de Chat** : La zone centrale où vous pouvez voir l'historique de conversation avec l'assistant IA.
2. **Zone de Saisie** : Située en bas de l'écran, utilisez-la pour taper vos messages ou commandes à l'IA.
3. **Bouton Envoyer** : Cliquez dessus pour envoyer votre message à l'IA.
4. **Bouton Paramètres** : Une icône d'engrenage qui ouvre la fenêtre modale des paramètres, vous permettant d'ajuster votre configuration à tout moment.
5. **Panneau Espace de Travail** : Affiche les fichiers et dossiers de votre espace de travail, vous permettant de naviguer et de visualiser les fichiers, ou les commandes passées de l'agent ou l'historique de navigation web.
1. Dans la page Paramètres, activez les options `Avancées` pour accéder aux paramètres supplémentaires.
2. Utilisez la zone de texte `Modèle personnalisé` pour saisir manuellement un modèle s'il n'est pas dans la liste.
3. Spécifiez une `URL de base` si requis par votre fournisseur LLM.
### Interagir avec l'IA
1. Tapez votre question, demande ou description de tâche dans la zone de saisie.
1. Tapez votre requête dans la zone de saisie.
2. Cliquez sur le bouton d'envoi ou appuyez sur Entrée pour soumettre votre message.
3. L'IA traitera votre saisie et fournira une réponse dans la fenêtre de chat.
4. Vous pouvez poursuivre la conversation en posant des questions de suivi ou en fournissant des informations supplémentaires.
3. L'IA traitera votre saisie et fournira une réponse dans la fenêtre de discussion.
4. Vous pouvez poursuivre la conversation en posant des questions complémentaires ou en fournissant des informations supplémentaires.
## Conseils pour une Utilisation Efficace
## Conseils pour une utilisation efficace
1. Soyez précis dans vos demandes pour obtenir les réponses les plus précises et utiles, comme décrit dans les [meilleures pratiques d'incitation](../prompting/prompting-best-practices).
2. Utilisez le panneau d'espace de travail pour explorer la structure de votre projet.
3. Utilisez l'un des modèles recommandés, comme décrit dans la section [LLMs](usage/llms/llms.md).
- Soyez précis dans vos demandes pour obtenir les réponses les plus précises et utiles, comme décrit dans les [meilleures pratiques de prompt](../prompting/prompting-best-practices).
- Utilisez l'un des modèles recommandés, comme décrit dans la [section LLMs](usage/llms/llms.md).
N'oubliez pas que le mode Interface Graphique d'OpenHands est conçu pour rendre votre interaction avec l'assistant IA aussi fluide et intuitive que possible. N'hésitez pas à explorer ses fonctionnalités pour maximiser votre productivité.
N'oubliez pas que le mode GUI d'OpenHands est conçu pour rendre votre interaction avec l'assistant IA aussi fluide et intuitive
que possible. N'hésitez pas à explorer ses fonctionnalités pour maximiser votre productivité.

56
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/how-to/headless-mode.md
View File

@ -1,61 +1,59 @@
# Mode sans interface
# Mode Headless
Vous pouvez exécuter OpenHands avec une seule commande, sans démarrer l'application web.
Cela facilite l'écriture de scripts et l'automatisation des tâches avec OpenHands.
Ceci est différent du [Mode CLI](cli-mode), qui est interactif et mieux adapté au développement actif.
C'est différent du [Mode CLI](cli-mode), qui est interactif et plus adapté au développement actif.
## Avec Python
Pour exécuter OpenHands en mode sans interface avec Python,
[suivez les instructions de configuration de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md),
puis exécutez :
Pour exécuter OpenHands en mode headless avec Python :
1. Assurez-vous d'avoir suivi les [instructions de configuration pour le développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
2. Exécutez la commande suivante :
```bash
poetry run python -m openhands.core.main -t "write a bash script that prints hi"
```
Vous devrez vous assurer de définir votre modèle, votre clé API et d'autres paramètres via des variables d'environnement
Vous devrez vous assurer de définir votre modèle, clé API et autres paramètres via des variables d'environnement
[ou le fichier `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Avec Docker
1. Définissez `WORKSPACE_BASE` sur le répertoire que vous voulez qu'OpenHands modifie :
Pour exécuter OpenHands en mode Headless avec Docker :
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
1. Définissez les variables d'environnement suivantes dans votre terminal :
2. Définissez `LLM_MODEL` sur le modèle que vous voulez utiliser :
- `SANDBOX_VOLUMES` pour spécifier le répertoire auquel OpenHands doit accéder (Ex : `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw`).
- L'agent travaille dans `/workspace` par défaut, donc montez votre répertoire de projet à cet emplacement si vous souhaitez que l'agent modifie des fichiers.
- Pour les données en lecture seule, utilisez un chemin de montage différent (Ex : `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw,/path/to/large/dataset:/data:ro`).
- `LLM_MODEL` pour le modèle à utiliser (Ex : `export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`).
- `LLM_API_KEY` pour la clé API (Ex : `export LLM_API_KEY="sk_test_12345"`).
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3. Définissez `LLM_API_KEY` sur votre clé API :
```bash
LLM_API_KEY="sk_test_12345"
```
4. Exécutez la commande Docker suivante :
2. Exécutez la commande Docker suivante :
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-e LOG_ALL_EVENTS=true \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
--name openhands-app-$(date +%Y%m%d%H%M%S) \
docker.all-hands.dev/all-hands-ai/openhands:0.36 \
python -m openhands.core.main -t "write a bash script that prints hi" --no-auto-continue
python -m openhands.core.main -t "write a bash script that prints hi"
```
Le paramètre `-e SANDBOX_USER_ID=$(id -u)` est transmis à la commande Docker pour s'assurer que l'utilisateur du sandbox correspond aux permissions de l'utilisateur hôte. Cela empêche l'agent de créer des fichiers appartenant à root dans l'espace de travail monté.
## Configurations avancées du mode Headless
Pour voir toutes les options de configuration disponibles pour le mode headless, exécutez la commande Python avec l'option `--help`.
### Journaux supplémentaires
Pour que le mode headless enregistre toutes les actions de l'agent, exécutez dans le terminal : `export LOG_ALL_EVENTS=true`

114
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/installation.mdx
View File

@ -1,16 +1,61 @@
# Exécution d'OpenHands
## Configuration système requise
* Docker version 26.0.0+ ou Docker Desktop 4.31.0+.
* Vous devez utiliser Linux ou Mac OS.
* Si vous êtes sous Windows, vous devez utiliser [WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
- MacOS avec [support Docker Desktop](https://docs.docker.com/desktop/setup/install/mac-install/#system-requirements)
- Linux
- Windows avec [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) et [support Docker Desktop](https://docs.docker.com/desktop/setup/install/windows-install/#system-requirements)
Un système avec un processeur moderne et un minimum de **4 Go de RAM** est recommandé pour exécuter OpenHands.
## Prérequis
<details>
<summary>MacOS</summary>
**Docker Desktop**
1. [Installer Docker Desktop sur Mac](https://docs.docker.com/desktop/setup/install/mac-install).
2. Ouvrez Docker Desktop, allez dans `Settings > Advanced` et assurez-vous que `Allow the default Docker socket to be used` est activé.
</details>
<details>
<summary>Linux</summary>
:::note
Testé avec Ubuntu 22.04.
:::
**Docker Desktop**
1. [Installer Docker Desktop sur Linux](https://docs.docker.com/desktop/setup/install/linux/).
</details>
<details>
<summary>Windows</summary>
**WSL**
1. [Installer WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
2. Exécutez `wsl --version` dans powershell et confirmez `Default Version: 2`.
**Docker Desktop**
1. [Installer Docker Desktop sur Windows](https://docs.docker.com/desktop/setup/install/windows-install).
2. Ouvrez Docker Desktop, allez dans `Settings` et confirmez les points suivants :
- General: `Use the WSL 2 based engine` est activé.
- Resources > WSL Integration: `Enable integration with my default WSL distro` est activé.
:::note
La commande docker ci-dessous pour démarrer l'application doit être exécutée dans le terminal WSL.
:::
</details>
## Démarrer l'application
La façon la plus simple d'exécuter OpenHands est avec Docker.
La façon la plus simple d'exécuter OpenHands est dans Docker.
```bash
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik
@ -19,39 +64,58 @@ docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:0.36
```
Vous pouvez également exécuter OpenHands en mode [headless scriptable](https://docs.all-hands.dev/modules/usage/how-to/headless-mode), en tant que [CLI interactive](https://docs.all-hands.dev/modules/usage/how-to/cli-mode), ou en utilisant l'[Action GitHub OpenHands](https://docs.all-hands.dev/modules/usage/how-to/github-action).
Vous trouverez OpenHands en cours d'exécution à l'adresse http://localhost:3000 !
Vous pouvez également [connecter OpenHands à votre système de fichiers local](https://docs.all-hands.dev/modules/usage/runtimes/docker#connecting-to-your-filesystem),
exécuter OpenHands en [mode headless](https://docs.all-hands.dev/modules/usage/how-to/headless-mode) scriptable,
interagir avec lui via une [CLI conviviale](https://docs.all-hands.dev/modules/usage/how-to/cli-mode),
ou l'exécuter sur des problèmes étiquetés avec [une action GitHub](https://docs.all-hands.dev/modules/usage/how-to/github-action).
## Configuration
Après avoir exécuté la commande ci-dessus, vous trouverez OpenHands en cours d'exécution à l'adresse [http://localhost:3000](http://localhost:3000).
Après avoir lancé OpenHands, vous **devez** sélectionner un `LLM Provider` et un `LLM Model` et saisir une `API Key` correspondante.
Cela peut être fait lors de la fenêtre contextuelle des paramètres initiaux ou en sélectionnant le bouton `Settings`
(icône d'engrenage) dans l'interface utilisateur.
Au lancement d'OpenHands, vous verrez une fenêtre modale de paramètres. Vous **devez** sélectionner un `Fournisseur LLM` et un `Modèle LLM`, et entrer une `Clé API` correspondante.
Ces paramètres peuvent être modifiés à tout moment en sélectionnant le bouton `Paramètres` (icône d'engrenage) dans l'interface utilisateur.
Si le modèle requis n'existe pas dans la liste, vous pouvez activer les options `Advanced` et le saisir manuellement avec le préfixe correct
dans la zone de texte `Custom Model`.
Les options `Advanced` vous permettent également de spécifier une `Base URL` si nécessaire.
Si le `Modèle LLM` requis n'existe pas dans la liste, vous pouvez activer les `Options avancées` et l'entrer manuellement avec le préfixe correct
dans la zone de texte `Modèle personnalisé`.
Les `Options avancées` vous permettent également de spécifier une `URL de base` si nécessaire.
### Obtenir une clé API
<div style={{ display: 'flex', justifyContent: 'center', gap: '20px' }}>
<img src="/img/settings-screenshot.png" alt="settings-modal" width="340" />
<img src="/img/settings-advanced.png" alt="settings-modal" width="335" />
</div>
OpenHands nécessite une clé API pour accéder à la plupart des modèles de langage. Voici comment obtenir une clé API auprès des fournisseurs recommandés :
#### Anthropic (Claude)
1. [Créez un compte Anthropic](https://console.anthropic.com/).
2. [Générez une clé API](https://console.anthropic.com/settings/keys).
3. [Configurez la facturation](https://console.anthropic.com/settings/billing).
Envisagez de définir des limites d'utilisation pour contrôler les coûts.
#### OpenAI
1. [Créez un compte OpenAI](https://platform.openai.com/).
2. [Générez une clé API](https://platform.openai.com/api-keys).
3. [Configurez la facturation](https://platform.openai.com/account/billing/overview).
Vous êtes maintenant prêt à [commencer avec OpenHands](./getting-started).
## Versions
La commande ci-dessus récupère la version stable la plus récente d'OpenHands. Vous avez également d'autres options :
- Pour une version spécifique, utilisez `docker.all-hands.dev/all-hands-ai/openhands:$VERSION`, en remplaçant $VERSION par le numéro de version.
- Nous utilisons semver et publions des tags majeurs, mineurs et de patch. Ainsi, `0.9` pointera automatiquement vers la dernière version `0.9.x`, et `0` pointera vers la dernière version `0.x.x`.
- Pour la version de développement la plus à jour, vous pouvez utiliser `docker.all-hands.dev/all-hands-ai/openhands:main`. Cette version est instable et n'est recommandée qu'à des fins de test ou de développement.
La [commande docker ci-dessus](./installation#start-the-app) extrait la version stable la plus récente d'OpenHands. Vous avez également d'autres options :
- Pour une version spécifique, remplacez $VERSION dans `openhands:$VERSION` et `runtime:$VERSION` par le numéro de version.
Nous utilisons SemVer, donc `0.9` pointera automatiquement vers la dernière version `0.9.x`, et `0` pointera vers la dernière version `0.x.x`.
- Pour la version de développement la plus à jour, remplacez $VERSION dans `openhands:$VERSION` et `runtime:$VERSION` par `main`.
Cette version est instable et est recommandée uniquement à des fins de test ou de développement.
Vous pouvez choisir le tag qui convient le mieux à vos besoins en fonction des exigences de stabilité et des fonctionnalités souhaitées.
Pour le flux de travail de développement, consultez [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Pour le workflow de développement, consultez [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Vous rencontrez des problèmes ? Consultez notre [Guide de dépannage](https://docs.all-hands.dev/modules/usage/troubleshooting).
Vous rencontrez des problèmes ? Consultez notre [Guide de dépannage](https://docs.all-hands.dev/modules/usage/troubleshooting).

29
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/key-features.md Normal file
View File

@ -0,0 +1,29 @@
# Aperçu des fonctionnalités d'OpenHands
![aperçu](/img/oh-features.png)
### Panneau de discussion
- Affiche la conversation entre l'utilisateur et OpenHands.
- OpenHands explique ses actions dans ce panneau.
### Modifications
- Montre les modifications de fichiers effectuées par OpenHands.
### VS Code
- VS Code intégré pour parcourir et modifier des fichiers.
- Peut également être utilisé pour télécharger et importer des fichiers.
### Terminal
- Un espace permettant à OpenHands et aux utilisateurs d'exécuter des commandes terminal.
### Jupyter
- Affiche toutes les commandes Python exécutées par OpenHands.
- Particulièrement utile lors de l'utilisation d'OpenHands pour des tâches de visualisation de données.
### Application
- Affiche le serveur web lorsqu'OpenHands exécute une application.
- Les utilisateurs peuvent interagir avec l'application en cours d'exécution.
### Navigateur
- Utilisé par OpenHands pour naviguer sur des sites web.
- Le navigateur n'est pas interactif.

37
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/azure-llms.md
View File

@ -1,16 +1,14 @@
# Azure
OpenHands utilise LiteLLM pour faire des appels aux modèles de chat d'Azure. Vous pouvez trouver leur documentation sur l'utilisation d'Azure comme fournisseur [ici](https://docs.litellm.ai/docs/providers/azure).
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat d'Azure. Vous pouvez trouver leur documentation sur l'utilisation d'Azure comme fournisseur [ici](https://docs.litellm.ai/docs/providers/azure).
## Configuration d'Azure OpenAI
Lorsque vous exécutez OpenHands, vous devrez définir la variable d'environnement suivante en utilisant `-e` dans la
[commande docker run](/modules/usage/installation#start-the-app) :
Lors de l'exécution d'OpenHands, vous devrez définir la variable d'environnement suivante en utilisant `-e` dans la
[commande docker run](../installation#running-openhands) :
```
LLM_API_VERSION="<api-version>" # par exemple "2023-05-15"
LLM_API_VERSION="<api-version>" # ex. "2023-05-15"
```
Exemple :
@ -20,29 +18,24 @@ docker run -it --pull=always \
...
```
Ensuite, définissez les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
Ensuite, dans les paramètres de l'interface OpenHands :
:::note
Vous aurez besoin du nom de votre déploiement ChatGPT qui peut être trouvé sur la page des déploiements dans Azure. Il est référencé comme
Vous aurez besoin du nom de déploiement ChatGPT qui peut être trouvé sur la page des déploiements dans Azure. Il est référencé comme
&lt;deployment-name&gt; ci-dessous.
:::
* Activez `Advanced Options`
* `Custom Model` à azure/&lt;deployment-name&gt;
* `Base URL` à votre URL de base de l'API Azure (par exemple `https://example-endpoint.openai.azure.com`)
* `API Key` à votre clé API Azure
## Embeddings
OpenHands utilise llama-index pour les embeddings. Vous pouvez trouver leur documentation sur Azure [ici](https://docs.llamaindex.ai/en/stable/api_reference/embeddings/azure_openai/).
1. Activez les options `Advanced`.
2. Définissez les éléments suivants :
- `Custom Model` à azure/&lt;deployment-name&gt;
- `Base URL` à votre URL de base de l'API Azure (ex. `https://example-endpoint.openai.azure.com`)
- `API Key` à votre clé API Azure
### Configuration d'Azure OpenAI
Lorsque vous exécutez OpenHands, définissez les variables d'environnement suivantes en utilisant `-e` dans la
[commande docker run](/modules/usage/installation#start-the-app) :
Lors de l'exécution d'OpenHands, définissez la variable d'environnement suivante en utilisant `-e` dans la
[commande docker run](../installation#running-openhands) :
```
LLM_EMBEDDING_MODEL="azureopenai"
LLM_EMBEDDING_DEPLOYMENT_NAME="<your-embedding-deployment-name>" # par exemple "TextEmbedding...<etc>"
LLM_API_VERSION="<api-version>" # par exemple "2024-02-15-preview"
```
LLM_API_VERSION="<api-version>" # ex. "2024-02-15-preview"
```

76
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/custom-llm-configs.md
View File

@ -1,6 +1,6 @@
# Configurations LLM personnalisées
OpenHands permet de définir plusieurs configurations LLM nommées dans votre fichier `config.toml`. Cette fonctionnalité vous permet d'utiliser différentes configurations LLM pour différents usages, comme utiliser un modèle moins coûteux pour les tâches qui ne nécessitent pas de réponses de haute qualité, ou utiliser différents modèles avec différents paramètres pour des agents spécifiques.
OpenHands permet de définir plusieurs configurations LLM nommées dans votre fichier `config.toml`. Cette fonctionnalité vous permet d'utiliser différentes configurations LLM pour différents usages, comme utiliser un modèle moins coûteux pour des tâches qui ne nécessitent pas de réponses de haute qualité, ou utiliser différents modèles avec différents paramètres pour des agents spécifiques.
## Comment ça fonctionne
@ -10,19 +10,19 @@ Les configurations LLM nommées sont définies dans le fichier `config.toml` en
# Configuration LLM par défaut
[llm]
model = "gpt-4"
api_key = "votre-clé-api"
api_key = "your-api-key"
temperature = 0.0
# Configuration LLM personnalisée pour un modèle moins coûteux
# Configuration LLM personnalisée pour un modèle moins cher
[llm.gpt3]
model = "gpt-3.5-turbo"
api_key = "votre-clé-api"
api_key = "your-api-key"
temperature = 0.2
# Une autre configuration personnalisée avec des paramètres différents
[llm.haute-creativite]
# Une autre configuration personnalisée avec différents paramètres
[llm.high-creativity]
model = "gpt-4"
api_key = "votre-clé-api"
api_key = "your-api-key"
temperature = 0.8
top_p = 0.9
```
@ -37,12 +37,12 @@ Vous pouvez spécifier quelle configuration LLM un agent doit utiliser en défin
```toml
[agent.RepoExplorerAgent]
# Utiliser la configuration GPT-3 moins coûteuse pour cet agent
# Utiliser la configuration GPT-3 moins chère pour cet agent
llm_config = 'gpt3'
[agent.CodeWriterAgent]
# Utiliser la configuration haute créativité pour cet agent
llm_config = 'haute-creativite'
llm_config = 'high-creativity'
```
### Options de configuration
@ -53,32 +53,32 @@ Chaque configuration LLM nommée prend en charge toutes les mêmes options que l
- Configuration de l'API (`api_key`, `base_url`, etc.)
- Paramètres du modèle (`temperature`, `top_p`, etc.)
- Paramètres de nouvelle tentative (`num_retries`, `retry_multiplier`, etc.)
- Limites de jetons (`max_input_tokens`, `max_output_tokens`)
- Limites de tokens (`max_input_tokens`, `max_output_tokens`)
- Et toutes les autres options de configuration LLM
Pour une liste complète des options disponibles, consultez la section Configuration LLM dans la documentation des [Options de configuration](../configuration-options).
Pour une liste complète des options disponibles, consultez la section Configuration LLM dans la documentation [Options de configuration](../configuration-options).
## Cas d'utilisation
Les configurations LLM personnalisées sont particulièrement utiles dans plusieurs scénarios :
- **Optimisation des coûts** : Utiliser des modèles moins coûteux pour les tâches qui ne nécessitent pas de réponses de haute qualité, comme l'exploration de dépôt ou les opérations simples sur les fichiers.
- **Réglage spécifique aux tâches** : Configurer différentes valeurs de température et de top_p pour les tâches qui nécessitent différents niveaux de créativité ou de déterminisme.
- **Différents fournisseurs** : Utiliser différents fournisseurs LLM ou points d'accès API pour différentes tâches.
- **Tests et développement** : Basculer facilement entre différentes configurations de modèles pendant le développement et les tests.
- **Optimisation des coûts** : Utilisez des modèles moins chers pour des tâches qui ne nécessitent pas de réponses de haute qualité, comme l'exploration de dépôts ou les opérations simples sur les fichiers.
- **Réglage spécifique aux tâches** : Configurez différentes valeurs de température et de top_p pour des tâches qui nécessitent différents niveaux de créativité ou de déterminisme.
- **Différents fournisseurs** : Utilisez différents fournisseurs LLM ou points d'accès API pour différentes tâches.
- **Tests et développement** : Passez facilement d'une configuration de modèle à une autre pendant le développement et les tests.
## Exemple : Optimisation des coûts
Un exemple pratique d'utilisation des configurations LLM personnalisées pour optimiser les coûts :
Un exemple pratique d'utilisation de configurations LLM personnalisées pour optimiser les coûts :
```toml
# Configuration par défaut utilisant GPT-4 pour des réponses de haute qualité
[llm]
model = "gpt-4"
api_key = "votre-clé-api"
api_key = "your-api-key"
temperature = 0.0
# Configuration moins coûteuse pour l'exploration de dépôt
# Configuration moins chère pour l'exploration de dépôts
[llm.repo-explorer]
model = "gpt-3.5-turbo"
temperature = 0.2
@ -97,10 +97,40 @@ llm_config = 'code-gen'
```
Dans cet exemple :
- L'exploration de dépôt utilise un modèle moins coûteux car il s'agit principalement de comprendre et de naviguer dans le code
- La génération de code utilise GPT-4 avec une limite de jetons plus élevée pour générer des blocs de code plus importants
- La configuration par défaut reste disponible pour les autres tâches
- L'exploration de dépôts utilise un modèle moins cher puisqu'il s'agit principalement de comprendre et de naviguer dans le code
- La génération de code utilise GPT-4 avec une limite de tokens plus élevée pour générer des blocs de code plus grands
- La configuration par défaut reste disponible pour d'autres tâches
# Configurations personnalisées avec des noms réservés
OpenHands peut utiliser des configurations LLM personnalisées nommées avec des noms réservés, pour des cas d'utilisation spécifiques. Si vous spécifiez le modèle et d'autres paramètres sous les noms réservés, OpenHands les chargera et les utilisera pour un objectif spécifique. À ce jour, une telle configuration est implémentée : l'éditeur de brouillon.
## Configuration de l'éditeur de brouillon
La configuration `draft_editor` est un groupe de paramètres que vous pouvez fournir pour spécifier le modèle à utiliser pour l'ébauche préliminaire des modifications de code, pour toutes les tâches qui impliquent l'édition et le raffinement du code. Vous devez la fournir sous la section `[llm.draft_editor]`.
Par exemple, vous pouvez définir dans `config.toml` un éditeur de brouillon comme ceci :
```toml
[llm.draft_editor]
model = "gpt-4"
temperature = 0.2
top_p = 0.95
presence_penalty = 0.0
frequency_penalty = 0.0
```
Cette configuration :
- Utilise GPT-4 pour des modifications et suggestions de haute qualité
- Définit une température basse (0,2) pour maintenir la cohérence tout en permettant une certaine flexibilité
- Utilise une valeur top_p élevée (0,95) pour considérer un large éventail d'options de tokens
- Désactive les pénalités de présence et de fréquence pour maintenir l'accent sur les modifications spécifiques nécessaires
Utilisez cette configuration lorsque vous souhaitez qu'un LLM ébauche des modifications avant de les effectuer. En général, cela peut être utile pour :
- Examiner et suggérer des améliorations de code
- Affiner le contenu existant tout en conservant son sens fondamental
- Apporter des modifications précises et ciblées au code ou au texte
:::note
Les configurations LLM personnalisées ne sont disponibles que lors de l'utilisation d'OpenHands en mode développement, via `main.py` ou `cli.py`. Lors de l'exécution via `docker run`, veuillez utiliser les options de configuration standard.
:::
Les configurations LLM personnalisées ne sont disponibles que lorsque vous utilisez OpenHands en mode développement, via `main.py` ou `cli.py`. Lors de l'exécution via `docker run`, veuillez utiliser les options de configuration standard.
:::

34
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/google-llms.md
View File

@ -1,31 +1,29 @@
# Google Gemini/Vertex
OpenHands utilise LiteLLM pour faire des appels aux modèles de chat de Google. Vous pouvez trouver leur documentation sur l'utilisation de Google comme fournisseur :
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat de Google. Vous pouvez consulter leur documentation sur l'utilisation de Google comme fournisseur :
- [Gemini - Google AI Studio](https://docs.litellm.ai/docs/providers/gemini)
- [VertexAI - Google Cloud Platform](https://docs.litellm.ai/docs/providers/vertex)
## Configurations de Gemini - Google AI Studio
## Configurations Gemini - Google AI Studio
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* `LLM Provider` à `Gemini`
* `LLM Model` au modèle que vous utiliserez.
Si le modèle ne figure pas dans la liste, activez `Advanced Options` et entrez-le dans `Custom Model` (par exemple, gemini/&lt;model-name&gt; comme `gemini/gemini-1.5-pro`).
* `API Key` à votre clé API Gemini
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
- `LLM Provider` sur `Gemini`
- `LLM Model` sur le modèle que vous utiliserez.
Si le modèle n'est pas dans la liste, activez les options `Advanced`, et saisissez-le dans `Custom Model` (par exemple gemini/&lt;nom-du-modèle&gt; comme `gemini/gemini-2.0-flash`).
- `API Key` avec votre clé API Gemini
## Configurations de VertexAI - Google Cloud Platform
## Configurations VertexAI - Google Cloud Platform
Pour utiliser Vertex AI via Google Cloud Platform lors de l'exécution d'OpenHands, vous devrez définir les variables d'environnement suivantes en utilisant `-e` dans la [commande docker run](/modules/usage/installation#start-the-app) :
Pour utiliser Vertex AI via Google Cloud Platform lors de l'exécution d'OpenHands, vous devrez définir les variables d'environnement suivantes en utilisant `-e` dans la [commande docker run](../installation#running-openhands) :
```
GOOGLE_APPLICATION_CREDENTIALS="<json-dump-of-gcp-service-account-json>"
VERTEXAI_PROJECT="<your-gcp-project-id>"
VERTEXAI_LOCATION="<your-gcp-location>"
GOOGLE_APPLICATION_CREDENTIALS="<json-dump-du-compte-de-service-gcp-json>"
VERTEXAI_PROJECT="<votre-id-de-projet-gcp>"
VERTEXAI_LOCATION="<votre-emplacement-gcp>"
```
Ensuite, définissez les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* `LLM Provider` à `VertexAI`
* `LLM Model` au modèle que vous utiliserez.
Si le modèle ne figure pas dans la liste, activez `Advanced Options` et entrez-le dans `Custom Model` (par exemple, vertex_ai/&lt;model-name&gt;).
Ensuite, définissez les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
- `LLM Provider` sur `VertexAI`
- `LLM Model` sur le modèle que vous utiliserez.
Si le modèle n'est pas dans la liste, activez les options `Advanced`, et saisissez-le dans `Custom Model` (par exemple vertex_ai/&lt;nom-du-modèle&gt;).

28
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/groq.md
View File

@ -1,22 +1,22 @@
# Groq
OpenHands utilise LiteLLM pour faire des appels aux modèles de chat sur Groq. Vous pouvez trouver leur documentation sur l'utilisation de Groq comme fournisseur [ici](https://docs.litellm.ai/docs/providers/groq).
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat sur Groq. Vous pouvez trouver leur documentation sur l'utilisation de Groq comme fournisseur [ici](https://docs.litellm.ai/docs/providers/groq).
## Configuration
Lorsque vous exécutez OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* `LLM Provider` à `Groq`
* `LLM Model` au modèle que vous utiliserez. [Visitez ici pour voir la liste des modèles hébergés par Groq](https://console.groq.com/docs/models). Si le modèle n'est pas dans la liste, activez les `Advanced Options` et entrez-le dans `Custom Model` (par exemple, groq/&lt;model-name&gt; comme `groq/llama3-70b-8192`).
* `API key` à votre clé API Groq. Pour trouver ou créer votre clé API Groq, [voir ici](https://console.groq.com/keys).
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
- `LLM Provider` sur `Groq`
- `LLM Model` sur le modèle que vous utiliserez. [Visitez ce lien pour voir la liste des
modèles hébergés par Groq](https://console.groq.com/docs/models). Si le modèle n'est pas dans la liste, activez
les options `Advanced`, et saisissez-le dans `Custom Model` (par exemple groq/&lt;nom-du-modèle&gt; comme `groq/llama3-70b-8192`).
- `API key` avec votre clé API Groq. Pour trouver ou créer votre clé API Groq, [voir ici](https://console.groq.com/keys).
## Utilisation de Groq comme point de terminaison compatible OpenAI
Le point de terminaison Groq pour la complétion de chat est [principalement compatible OpenAI](https://console.groq.com/docs/openai). Par conséquent, vous pouvez accéder aux modèles Groq comme vous le feriez pour n'importe quel point de terminaison compatible OpenAI. Vous pouvez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* Activer les `Advanced Options`
* `Custom Model` au préfixe `openai/` + le modèle que vous utiliserez (par exemple, `openai/llama3-70b-8192`)
* `Base URL` à `https://api.groq.com/openai/v1`
* `API Key` à votre clé API Groq
Le point de terminaison Groq pour la complétion de chat est [majoritairement compatible avec OpenAI](https://console.groq.com/docs/openai). Par conséquent, vous pouvez accéder aux modèles Groq comme vous
accéderiez à n'importe quel point de terminaison compatible OpenAI. Dans l'interface utilisateur d'OpenHands via les Paramètres :
1. Activez les options `Advanced`
2. Définissez les éléments suivants :
- `Custom Model` avec le préfixe `openai/` + le modèle que vous utiliserez (par exemple `openai/llama3-70b-8192`)
- `Base URL` sur `https://api.groq.com/openai/v1`
- `API Key` avec votre clé API Groq

14
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/litellm-proxy.md
View File

@ -1,5 +1,3 @@
# Proxy LiteLLM
OpenHands prend en charge l'utilisation du [proxy LiteLLM](https://docs.litellm.ai/docs/proxy/quick_start) pour accéder à divers fournisseurs de LLM.
@ -9,14 +7,14 @@ OpenHands prend en charge l'utilisation du [proxy LiteLLM](https://docs.litellm.
Pour utiliser le proxy LiteLLM avec OpenHands, vous devez :
1. Configurer un serveur proxy LiteLLM (voir la [documentation LiteLLM](https://docs.litellm.ai/docs/proxy/quick_start))
2. Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* Activer les `Options avancées`
* `Custom Model` au préfixe `litellm_proxy/` + le modèle que vous utiliserez (par exemple, `litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`)
* `Base URL` à l'URL de votre proxy LiteLLM (par exemple, `https://your-litellm-proxy.com`)
* `API Key` à votre clé API du proxy LiteLLM
2. Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
* Activer les options `Avancées`
* Définir `Modèle personnalisé` avec le préfixe `litellm_proxy/` + le modèle que vous utiliserez (par exemple `litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`)
* Définir `URL de base` avec l'URL de votre proxy LiteLLM (par exemple `https://your-litellm-proxy.com`)
* Définir `Clé API` avec votre clé API du proxy LiteLLM
## Modèles pris en charge
Les modèles pris en charge dépendent de la configuration de votre proxy LiteLLM. OpenHands prend en charge tous les modèles que votre proxy LiteLLM est configuré pour gérer.
Reportez-vous à la configuration de votre proxy LiteLLM pour obtenir la liste des modèles disponibles et leurs noms.
Référez-vous à la configuration de votre proxy LiteLLM pour la liste des modèles disponibles et leurs noms.

76
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/llms.md
View File

@ -1,50 +1,55 @@
# 🤖 Backends LLM
OpenHands peut se connecter à n'importe quel LLM supporté par LiteLLM. Cependant, il nécessite un modèle puissant pour fonctionner.
:::note
Cette section est destinée aux utilisateurs qui souhaitent connecter OpenHands à différents LLMs.
:::
OpenHands peut se connecter à n'importe quel LLM pris en charge par LiteLLM. Cependant, il nécessite un modèle puissant pour fonctionner.
## Recommandations de modèles
Sur la base de nos évaluations des modèles de langage pour les tâches de codage (en utilisant le jeu de données SWE-bench), nous pouvons fournir quelques recommandations pour la sélection des modèles. Certaines analyses peuvent être trouvées dans [cet article de blog comparant les LLM](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed) et [cet article de blog avec des résultats plus récents](https://www.all-hands.dev/blog/openhands-codeact-21-an-open-state-of-the-art-software-development-agent).
Sur la base de nos évaluations des modèles de langage pour les tâches de programmation (utilisant le jeu de données SWE-bench), nous pouvons fournir quelques
recommandations pour la sélection de modèles. Nos derniers résultats d'évaluation peuvent être consultés dans [ce tableur](https://docs.google.com/spreadsheets/d/1wOUdFCMyY6Nt0AIqF705KN4JKOWgeI4wUGUP60krXXs/edit?gid=0).
Lors du choix d'un modèle, considérez à la fois la qualité des sorties et les coûts associés. Voici un résumé des résultats :
Sur la base de ces résultats et des retours de la communauté, les modèles suivants ont été vérifiés comme fonctionnant raisonnablement bien avec OpenHands :
- Claude 3.5 Sonnet est le meilleur de loin, atteignant un taux de résolution de 53% sur SWE-Bench Verified avec l'agent par défaut dans OpenHands.
- GPT-4o est à la traîne, et o1-mini a en fait obtenu des performances légèrement inférieures à celles de GPT-4o. Nous avons analysé les résultats un peu, et brièvement, il semblait que o1 "réfléchissait trop" parfois, effectuant des tâches de configuration d'environnement supplémentaires alors qu'il aurait pu simplement aller de l'avant et terminer la tâche.
- Enfin, les modèles ouverts les plus puissants étaient Llama 3.1 405 B et deepseek-v2.5, et ils ont obtenu des performances raisonnables, surpassant même certains des modèles fermés.
- [anthropic/claude-3-7-sonnet-20250219](https://www.anthropic.com/api) (recommandé)
- [gemini/gemini-2.5-pro](https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/)
- [deepseek/deepseek-chat](https://api-docs.deepseek.com/)
- [openai/o3-mini](https://openai.com/index/openai-o3-mini/)
- [openai/o3](https://openai.com/index/introducing-o3-and-o4-mini/)
- [openai/o4-mini](https://openai.com/index/introducing-o3-and-o4-mini/)
- [all-hands/openhands-lm-32b-v0.1](https://www.all-hands.dev/blog/introducing-openhands-lm-32b----a-strong-open-coding-agent-model) -- disponible via [OpenRouter](https://openrouter.ai/all-hands/openhands-lm-32b-v0.1)
Veuillez vous référer à [l'article complet](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed) pour plus de détails.
Sur la base de ces résultats et des commentaires de la communauté, il a été vérifié que les modèles suivants fonctionnent raisonnablement bien avec OpenHands :
- claude-3-5-sonnet (recommandé)
- gpt-4 / gpt-4o
- llama-3.1-405b
- deepseek-v2.5
:::warning
OpenHands enverra de nombreuses invites au LLM que vous configurez. La plupart de ces LLM sont payants, alors assurez-vous de définir des limites de dépenses et de surveiller l'utilisation.
OpenHands enverra de nombreuses requêtes au LLM que vous configurez. La plupart de ces LLMs ont un coût, alors assurez-vous de définir des limites de dépenses et de surveiller l'utilisation.
:::
Si vous avez réussi à exécuter OpenHands avec des LLM spécifiques qui ne figurent pas dans la liste, veuillez les ajouter à la liste vérifiée. Nous vous encourageons également à ouvrir une PR pour partager votre processus de configuration afin d'aider les autres utilisant le même fournisseur et LLM !
Si vous avez réussi à exécuter OpenHands avec des LLMs spécifiques qui ne figurent pas dans la liste, veuillez les ajouter à la liste vérifiée. Nous
vous encourageons également à ouvrir une PR pour partager votre processus de configuration afin d'aider d'autres utilisateurs du même fournisseur et LLM !
Pour une liste complète des fournisseurs et des modèles disponibles, veuillez consulter la [documentation litellm](https://docs.litellm.ai/docs/providers).
Pour une liste complète des fournisseurs et modèles disponibles, veuillez consulter la
[documentation litellm](https://docs.litellm.ai/docs/providers).
:::note
La plupart des modèles locaux et open source actuels ne sont pas aussi puissants. Lors de l'utilisation de tels modèles, vous pouvez constater de longs temps d'attente entre les messages, des réponses médiocres ou des erreurs concernant du JSON mal formé. OpenHands ne peut être aussi puissant que les modèles qui le pilotent. Cependant, si vous en trouvez qui fonctionnent, veuillez les ajouter à la liste vérifiée ci-dessus.
La plupart des modèles locaux et open source actuels ne sont pas aussi puissants. Lorsque vous utilisez de tels modèles, vous pourriez constater de longs
temps d'attente entre les messages, des réponses médiocres ou des erreurs concernant un JSON mal formé. OpenHands ne peut être que aussi puissant que les
modèles qui l'alimentent. Cependant, si vous en trouvez qui fonctionnent, veuillez les ajouter à la liste vérifiée ci-dessus.
:::
## Configuration LLM
Les éléments suivants peuvent être définis dans l'interface utilisateur d'OpenHands via les paramètres :
Les éléments suivants peuvent être définis dans l'interface utilisateur d'OpenHands via les Paramètres :
- `Fournisseur LLM`
- `Modèle LLM`
- `Clé API`
- `URL de base` (via `Paramètres avancés`)
- `URL de base` (via les paramètres `Avancés`)
Il existe certains paramètres qui peuvent être nécessaires pour certains LLM/fournisseurs et qui ne peuvent pas être définis via l'interface utilisateur. Au lieu de cela, ils peuvent être définis via des variables d'environnement passées à la [commande docker run](/modules/usage/installation#start-the-app) en utilisant `-e` :
Il existe certains paramètres qui peuvent être nécessaires pour certains LLMs/fournisseurs qui ne peuvent pas être définis via l'interface utilisateur. Au lieu de cela, ils
peuvent être définis via des variables d'environnement transmises à la commande docker run lors du démarrage de l'application
en utilisant `-e` :
- `LLM_API_VERSION`
- `LLM_EMBEDDING_MODEL`
@ -58,27 +63,30 @@ Nous avons quelques guides pour exécuter OpenHands avec des fournisseurs de mod
- [Azure](llms/azure-llms)
- [Google](llms/google-llms)
- [Groq](llms/groq)
- [LiteLLM Proxy](llms/litellm-proxy)
- [LLMs locaux avec SGLang ou vLLM](llms/../local-llms.md)
- [Proxy LiteLLM](llms/litellm-proxy)
- [OpenAI](llms/openai-llms)
- [OpenRouter](llms/openrouter)
### Nouvelles tentatives d'API et limites de débit
### Nouvelles tentatives d'API et limites de taux
Les fournisseurs de LLM ont généralement des limites de débit, parfois très basses, et peuvent nécessiter de nouvelles tentatives. OpenHands réessaiera automatiquement les requêtes s'il reçoit une erreur de limite de débit (code d'erreur 429), une erreur de connexion API ou d'autres erreurs transitoires.
Les fournisseurs de LLM ont généralement des limites de taux, parfois très basses, et peuvent nécessiter des nouvelles tentatives. OpenHands réessaiera automatiquement
les requêtes s'il reçoit une erreur de limite de taux (code d'erreur 429).
Vous pouvez personnaliser ces options selon vos besoins pour le fournisseur que vous utilisez. Consultez leur documentation et définissez les variables d'environnement suivantes pour contrôler le nombre de nouvelles tentatives et le temps entre les tentatives :
Vous pouvez personnaliser ces options selon vos besoins pour le fournisseur que vous utilisez. Consultez leur documentation et définissez les
variables d'environnement suivantes pour contrôler le nombre de nouvelles tentatives et le temps entre les tentatives :
- `LLM_NUM_RETRIES` (Par défaut 8)
- `LLM_RETRY_MIN_WAIT` (Par défaut 15 secondes)
- `LLM_RETRY_MAX_WAIT` (Par défaut 120 secondes)
- `LLM_NUM_RETRIES` (Par défaut 4 fois)
- `LLM_RETRY_MIN_WAIT` (Par défaut 5 secondes)
- `LLM_RETRY_MAX_WAIT` (Par défaut 30 secondes)
- `LLM_RETRY_MULTIPLIER` (Par défaut 2)
Si vous exécutez OpenHands en mode développement, vous pouvez également définir ces options dans le fichier `config.toml` :
```toml
[llm]
num_retries = 8
retry_min_wait = 15
retry_max_wait = 120
num_retries = 4
retry_min_wait = 5
retry_max_wait = 30
retry_multiplier = 2
```
```

208
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/local-llms.md
View File

@ -1,193 +1,83 @@
# LLM local avec Ollama
# LLM local avec SGLang ou vLLM
:::warning
Lors de l'utilisation d'un LLM local, OpenHands peut avoir des fonctionnalités limitées.
Lorsque vous utilisez un LLM local, OpenHands peut avoir des fonctionnalités limitées.
Il est fortement recommandé d'utiliser des GPU pour servir les modèles locaux afin d'obtenir une expérience optimale.
:::
Assurez-vous que le serveur Ollama est opérationnel.
Pour des instructions détaillées sur le démarrage, référez-vous à [ici](https://github.com/ollama/ollama).
## Actualités
Ce guide suppose que vous avez démarré ollama avec `ollama serve`. Si vous exécutez ollama différemment (par exemple dans docker), les instructions peuvent nécessiter des modifications. Veuillez noter que si vous utilisez WSL, la configuration par défaut d'ollama bloque les requêtes provenant des conteneurs docker. Voir [ici](#configuring-ollama-service-wsl-fr).
- 2025/03/31 : Nous avons publié un modèle ouvert OpenHands LM v0.1 32B qui atteint 37,1% sur SWE-Bench Verified
([blog](https://www.all-hands.dev/blog/introducing-openhands-lm-32b----a-strong-open-coding-agent-model), [modèle](https://huggingface.co/all-hands/openhands-lm-32b-v0.1)).
## Récupérer les modèles
## Télécharger le modèle depuis Huggingface
Les noms des modèles Ollama peuvent être trouvés [ici](https://ollama.com/library). Pour un petit exemple, vous pouvez utiliser le modèle `codellama:7b`. Les modèles plus gros auront généralement de meilleures performances.
Par exemple, pour télécharger [OpenHands LM 32B v0.1](https://huggingface.co/all-hands/openhands-lm-32b-v0.1) :
```bash
ollama pull codellama:7b
huggingface-cli download all-hands/openhands-lm-32b-v0.1 --local-dir all-hands/openhands-lm-32b-v0.1
```
Vous pouvez vérifier quels modèles vous avez téléchargés comme ceci :
## Créer un point de terminaison compatible OpenAI avec un framework de service de modèle
### Service avec SGLang
- Installez SGLang en suivant [la documentation officielle](https://docs.sglang.ai/start/install.html).
- Exemple de commande de lancement pour OpenHands LM 32B (avec au moins 2 GPU) :
```bash
~$ ollama list
NAME ID SIZE MODIFIED
codellama:7b 8fdf8f752f6e 3.8 GB 6 weeks ago
mistral:7b-instruct-v0.2-q4_K_M eb14864c7427 4.4 GB 2 weeks ago
starcoder2:latest f67ae0f64584 1.7 GB 19 hours ago
SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 python3 -m sglang.launch_server \
--model all-hands/openhands-lm-32b-v0.1 \
--served-model-name openhands-lm-32b-v0.1 \
--port 8000 \
--tp 2 --dp 1 \
--host 0.0.0.0 \
--api-key mykey --context-length 131072
```
## Exécuter OpenHands avec Docker
### Service avec vLLM
### Démarrer OpenHands
Utilisez les instructions [ici](../getting-started) pour démarrer OpenHands en utilisant Docker.
Mais lorsque vous exécutez `docker run`, vous devrez ajouter quelques arguments supplémentaires :
- Installez vLLM en suivant [la documentation officielle](https://docs.vllm.ai/en/latest/getting_started/installation.html).
- Exemple de commande de lancement pour OpenHands LM 32B (avec au moins 2 GPU) :
```bash
docker run # ...
--add-host host.docker.internal:host-gateway \
-e LLM_OLLAMA_BASE_URL="http://host.docker.internal:11434" \
# ...
vllm serve all-hands/openhands-lm-32b-v0.1 \
--host 0.0.0.0 --port 8000 \
--api-key mykey \
--tensor-parallel-size 2 \
--served-model-name openhands-lm-32b-v0.1
--enable-prefix-caching
```
LLM_OLLAMA_BASE_URL est optionnel. Si vous le définissez, il sera utilisé pour afficher
les modèles installés disponibles dans l'interface utilisateur.
## Exécuter et configurer OpenHands
### Exécuter OpenHands
### Configurer l'application Web
#### Utilisation de Docker
Lors de l'exécution d'`openhands`, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
- le modèle à "ollama/&lt;nom-du-modèle&gt;"
- l'URL de base à `http://host.docker.internal:11434`
- la clé API est optionnelle, vous pouvez utiliser n'importe quelle chaîne, comme `ollama`.
Exécutez OpenHands en utilisant [la commande docker run officielle](../installation#start-the-app).
#### Utilisation du mode développement
## Exécuter OpenHands en mode développement
### Compiler à partir du code source
Utilisez les instructions dans [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) pour compiler OpenHands.
Assurez-vous que `config.toml` est présent en exécutant `make setup-config` qui en créera un pour vous. Dans `config.toml`, entrez ce qui suit :
Utilisez les instructions dans [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) pour construire OpenHands.
Assurez-vous que `config.toml` existe en exécutant `make setup-config` qui en créera un pour vous. Dans le fichier `config.toml`, saisissez ce qui suit :
```
[core]
workspace_base="./workspace"
workspace_base="/path/to/your/workspace"
[llm]
embedding_model="local"
ollama_base_url="http://localhost:11434"
model="openhands-lm-32b-v0.1"
ollama_base_url="http://localhost:8000"
```
Terminé ! Vous pouvez maintenant démarrer OpenHands avec : `make run`. Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
Démarrez OpenHands en utilisant `make run`.
### Configurer l'application Web
### Configurer OpenHands
Dans l'interface utilisateur d'OpenHands, cliquez sur la roue des paramètres dans le coin inférieur gauche.
Ensuite, dans le champ `Model`, entrez `ollama/codellama:7b`, ou le nom du modèle que vous avez récupéré précédemment.
S'il n'apparaît pas dans la liste déroulante, activez `Advanced Settings` et tapez-le. Veuillez noter : vous avez besoin du nom du modèle tel qu'il est listé par `ollama list`, avec le préfixe `ollama/`.
Dans le champ API Key, entrez `ollama` ou n'importe quelle valeur, puisque vous n'avez pas besoin d'une clé particulière.
Dans le champ Base URL, entrez `http://localhost:11434`.
Et maintenant vous êtes prêt à démarrer !
## Configurer le service ollama (WSL) {#configuring-ollama-service-wsl-fr}
La configuration par défaut d'ollama dans WSL ne sert que localhost. Cela signifie que vous ne pouvez pas y accéder depuis un conteneur docker. Par ex. cela ne fonctionnera pas avec OpenHands. Testons d'abord qu'ollama fonctionne correctement.
```bash
ollama list # obtenir la liste des modèles installés
curl http://localhost:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
#ex. curl http://localhost:11434/api/generate -d '{"model":"codellama:7b","prompt":"hi"}'
#ex. curl http://localhost:11434/api/generate -d '{"model":"codellama","prompt":"hi"}' #le tag est optionnel s'il n'y en a qu'un
```
Une fois cela fait, testez qu'il autorise les requêtes "extérieures", comme celles provenant d'un conteneur docker.
```bash
docker ps # obtenir la liste des conteneurs docker en cours d'exécution, pour un test plus précis choisissez le conteneur sandbox OpenHands.
docker exec [ID CONTENEUR] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
#ex. docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## Résoudre le problème
Maintenant, faisons en sorte que cela fonctionne. Modifiez /etc/systemd/system/ollama.service avec des privilèges sudo. (Le chemin peut varier selon la distribution Linux)
```bash
sudo vi /etc/systemd/system/ollama.service
```
ou
```bash
sudo nano /etc/systemd/system/ollama.service
```
Dans le bloc [Service], ajoutez ces lignes
```
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"
```
Ensuite, sauvegardez, rechargez la configuration et redémarrez le service.
```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```
Enfin, testez qu'ollama est accessible depuis le conteneur
```bash
ollama list # obtenir la liste des modèles installés
docker ps # obtenir la liste des conteneurs docker en cours d'exécution, pour un test plus précis choisissez le conteneur sandbox OpenHands.
docker exec [ID CONTENEUR] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
```
# LLM local avec LM Studio
Étapes pour configurer LM Studio :
1. Ouvrez LM Studio
2. Allez dans l'onglet Serveur local.
3. Cliquez sur le bouton "Démarrer le serveur".
4. Sélectionnez le modèle que vous souhaitez utiliser dans la liste déroulante.
Définissez les configurations suivantes :
```bash
LLM_MODEL="openai/lmstudio"
LLM_BASE_URL="http://localhost:1234/v1"
CUSTOM_LLM_PROVIDER="openai"
```
### Docker
```bash
docker run # ...
-e LLM_MODEL="openai/lmstudio" \
-e LLM_BASE_URL="http://host.docker.internal:1234/v1" \
-e CUSTOM_LLM_PROVIDER="openai" \
# ...
```
Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
Dans l'environnement de développement, vous pouvez définir les configurations suivantes dans le fichier `config.toml` :
```
[core]
workspace_base="./workspace"
[llm]
model="openai/lmstudio"
base_url="http://localhost:1234/v1"
custom_llm_provider="openai"
```
Terminé ! Vous pouvez maintenant démarrer OpenHands avec : `make run` sans Docker. Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
# Note
Pour WSL, exécutez les commandes suivantes dans cmd pour configurer le mode réseau en miroir :
```
python -c "print('[wsl2]\nnetworkingMode=mirrored',file=open(r'%UserProfile%\.wslconfig','w'))"
wsl --shutdown
```
Une fois qu'OpenHands est en cours d'exécution, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
1. Activez les options `Avancées`.
2. Définissez les éléments suivants :
- `Modèle personnalisé` sur `openai/<served-model-name>` (par exemple `openai/openhands-lm-32b-v0.1`)
- `URL de base` sur `http://host.docker.internal:8000`
- `Clé API` sur la même chaîne que celle que vous avez définie lors du service du modèle (par exemple `mykey`)

29
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/openai-llms.md
View File

@ -1,26 +1,25 @@
# OpenAI
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat d'OpenAI. Vous pouvez trouver leur documentation sur l'utilisation d'OpenAI en tant que fournisseur [ici](https://docs.litellm.ai/docs/providers/openai).
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat d'OpenAI. Vous pouvez trouver leur documentation sur l'utilisation d'OpenAI comme fournisseur [ici](https://docs.litellm.ai/docs/providers/openai).
## Configuration
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* `LLM Provider` à `OpenAI`
* `LLM Model` au modèle que vous utiliserez.
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
* `LLM Provider` sur `OpenAI`
* `LLM Model` sur le modèle que vous utiliserez.
[Visitez ce lien pour voir une liste complète des modèles OpenAI pris en charge par LiteLLM.](https://docs.litellm.ai/docs/providers/openai#openai-chat-completion-models)
Si le modèle ne figure pas dans la liste, activez les `Advanced Options` et entrez-le dans `Custom Model` (par exemple, openai/&lt;model-name&gt; comme `openai/gpt-4o`).
* `API Key` à votre clé API OpenAI. Pour trouver ou créer votre clé API de projet OpenAI, [voir ici](https://platform.openai.com/api-keys).
Si le modèle ne figure pas dans la liste, activez les options `Advanced`, et saisissez-le dans `Custom Model` (par exemple openai/&lt;nom-du-modèle&gt; comme `openai/gpt-4o`).
* `API Key` avec votre clé API OpenAI. Pour trouver ou créer votre clé API de projet OpenAI, [voir ici](https://platform.openai.com/api-keys).
## Utilisation des endpoints compatibles OpenAI
## Utilisation des points de terminaison compatibles avec OpenAI
Tout comme pour les chat completions OpenAI, nous utilisons LiteLLM pour les endpoints compatibles OpenAI. Vous pouvez trouver leur documentation complète sur ce sujet [ici](https://docs.litellm.ai/docs/providers/openai_compatible).
Tout comme pour les compléments de chat OpenAI, nous utilisons LiteLLM pour les points de terminaison compatibles avec OpenAI. Vous pouvez trouver leur documentation complète sur ce sujet [ici](https://docs.litellm.ai/docs/providers/openai_compatible).
## Utilisation d'un proxy OpenAI
Si vous utilisez un proxy OpenAI, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* Activer les `Advanced Options`
* `Custom Model` à openai/&lt;model-name&gt; (par exemple, `openai/gpt-4o` ou openai/&lt;proxy-prefix&gt;/&lt;model-name&gt;)
* `Base URL` à l'URL de votre proxy OpenAI
* `API Key` à votre clé API OpenAI
Si vous utilisez un proxy OpenAI, dans l'interface utilisateur d'OpenHands via les Paramètres :
1. Activez les options `Advanced`
2. Définissez les éléments suivants :
- `Custom Model` sur openai/&lt;nom-du-modèle&gt; (par exemple `openai/gpt-4o` ou openai/&lt;préfixe-proxy&gt;/&lt;nom-du-modèle&gt;)
- `Base URL` sur l'URL de votre proxy OpenAI
- `API Key` sur votre clé API OpenAI

16
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/llms/openrouter.md
View File

@ -1,14 +1,12 @@
# OpenRouter
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat sur OpenRouter. Vous pouvez trouver leur documentation sur l'utilisation d'OpenRouter en tant que fournisseur [ici](https://docs.litellm.ai/docs/providers/openrouter).
OpenHands utilise LiteLLM pour effectuer des appels aux modèles de chat sur OpenRouter. Vous pouvez trouver leur documentation sur l'utilisation d'OpenRouter comme fournisseur [ici](https://docs.litellm.ai/docs/providers/openrouter).
## Configuration
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
* `LLM Provider` à `OpenRouter`
* `LLM Model` au modèle que vous utiliserez.
[Visitez ici pour voir une liste complète des modèles OpenRouter](https://openrouter.ai/models).
Si le modèle ne figure pas dans la liste, activez `Advanced Options`, et entrez-le dans `Custom Model` (par exemple openrouter/&lt;model-name&gt; comme `openrouter/anthropic/claude-3.5-sonnet`).
* `API Key` à votre clé API OpenRouter.
Lors de l'exécution d'OpenHands, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les Paramètres :
* `LLM Provider` sur `OpenRouter`
* `LLM Model` sur le modèle que vous utiliserez.
[Visitez ce lien pour voir une liste complète des modèles OpenRouter](https://openrouter.ai/models).
Si le modèle ne figure pas dans la liste, activez les options `Advanced`, et saisissez-le dans `Custom Model` (par exemple openrouter/&lt;nom-du-modèle&gt; comme `openrouter/anthropic/claude-3.5-sonnet`).
* `API Key` avec votre clé API OpenRouter.

96
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/mcp.md Normal file
View File

@ -0,0 +1,96 @@
# Protocole de Contexte de Modèle (MCP)
:::note
Cette page explique comment configurer et utiliser le Protocole de Contexte de Modèle (MCP) dans OpenHands, vous permettant d'étendre les capacités de l'agent avec des outils personnalisés.
:::
## Aperçu
Le Protocole de Contexte de Modèle (MCP) est un mécanisme qui permet à OpenHands de communiquer avec des serveurs d'outils externes. Ces serveurs peuvent fournir des fonctionnalités supplémentaires à l'agent, comme le traitement spécialisé de données, l'accès à des API externes, ou des outils personnalisés. MCP est basé sur le standard ouvert défini sur [modelcontextprotocol.io](https://modelcontextprotocol.io).
## Configuration
La configuration MCP est définie dans la section `[mcp]` de votre fichier `config.toml`.
### Exemple de configuration
```toml
[mcp]
# Serveurs SSE - Serveurs externes qui communiquent via Server-Sent Events
sse_servers = [
# Serveur SSE basique avec juste une URL
"http://example.com:8080/mcp",
# Serveur SSE avec authentification par clé API
{url="https://secure-example.com/mcp", api_key="your-api-key"}
]
# Serveurs Stdio - Processus locaux qui communiquent via entrée/sortie standard
stdio_servers = [
# Serveur stdio basique
{name="fetch", command="uvx", args=["mcp-server-fetch"]},
# Serveur stdio avec variables d'environnement
{
name="data-processor",
command="python",
args=["-m", "my_mcp_server"],
env={
"DEBUG": "true",
"PORT": "8080"
}
}
]
```
## Options de configuration
### Serveurs SSE
Les serveurs SSE sont configurés en utilisant soit une URL sous forme de chaîne, soit un objet avec les propriétés suivantes :
- `url` (obligatoire)
- Type: `str`
- Description: L'URL du serveur SSE
- `api_key` (optionnel)
- Type: `str`
- Par défaut: `None`
- Description: Clé API pour l'authentification avec le serveur SSE
### Serveurs Stdio
Les serveurs Stdio sont configurés en utilisant un objet avec les propriétés suivantes :
- `name` (obligatoire)
- Type: `str`
- Description: Un nom unique pour le serveur
- `command` (obligatoire)
- Type: `str`
- Description: La commande pour exécuter le serveur
- `args` (optionnel)
- Type: `list of str`
- Par défaut: `[]`
- Description: Arguments de ligne de commande à passer au serveur
- `env` (optionnel)
- Type: `dict of str to str`
- Par défaut: `{}`
- Description: Variables d'environnement à définir pour le processus du serveur
## Comment fonctionne MCP
Lorsque OpenHands démarre, il :
1. Lit la configuration MCP depuis `config.toml`
2. Se connecte à tous les serveurs SSE configurés
3. Démarre tous les serveurs stdio configurés
4. Enregistre les outils fournis par ces serveurs auprès de l'agent
L'agent peut alors utiliser ces outils comme n'importe quel outil intégré. Lorsque l'agent appelle un outil MCP :
1. OpenHands achemine l'appel vers le serveur MCP approprié
2. Le serveur traite la demande et renvoie une réponse
3. OpenHands convertit la réponse en une observation et la présente à l'agent

36
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/prompting/microagents-keyword.md Normal file
View File

@ -0,0 +1,36 @@
# Microagents déclenchés par mots-clés
## Objectif
Les microagents déclenchés par mots-clés fournissent à OpenHands des instructions spécifiques qui sont activées lorsque certains mots-clés apparaissent dans la requête. Cela est utile pour adapter le comportement en fonction d'outils, langages ou frameworks particuliers.
## Utilisation
Ces microagents ne sont chargés que lorsqu'une requête inclut l'un des mots déclencheurs.
## Syntaxe du frontmatter
Le frontmatter est requis pour les microagents déclenchés par mots-clés. Il doit être placé en haut du fichier, au-dessus des directives.
Encadrez le frontmatter par des triples tirets (---) et incluez les champs suivants :
| Champ | Description | Obligatoire | Valeur par défaut |
|------------|----------------------------------------------------|-------------|-------------------|
| `triggers` | Une liste de mots-clés qui activent le microagent. | Oui | Aucune |
| `agent` | L'agent auquel ce microagent s'applique. | Non | 'CodeActAgent' |
## Exemple
Exemple de fichier de microagent déclenché par mot-clé situé à `.openhands/microagents/yummy.md` :
```
---
triggers:
- yummyhappy
- happyyummy
---
L'utilisateur a dit le mot magique. Répondez avec "C'était délicieux !"
```
[Voir des exemples de microagents déclenchés par mots-clés dans le dépôt officiel OpenHands](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)

40
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/prompting/microagents-overview.md Normal file
View File

@ -0,0 +1,40 @@
# Aperçu des Microagents
Les microagents sont des prompts spécialisés qui améliorent OpenHands avec des connaissances spécifiques à un domaine.
Ils fournissent des conseils d'experts, automatisent les tâches courantes et assurent des pratiques cohérentes dans les projets.
## Types de Microagents
Actuellement, OpenHands prend en charge les types de microagents suivants :
- [Microagents Généraux de Dépôt](./microagents-repo) : Directives générales pour OpenHands concernant le dépôt.
- [Microagents Déclenchés par Mots-clés](./microagents-keyword) : Directives activées par des mots-clés spécifiques dans les prompts.
Pour personnaliser le comportement d'OpenHands, créez un répertoire .openhands/microagents/ à la racine de votre dépôt et
ajoutez des fichiers `<microagent_name>.md` à l'intérieur.
:::note
Les microagents chargés occupent de l'espace dans la fenêtre de contexte.
Ces microagents, ainsi que les messages des utilisateurs, informent OpenHands sur la tâche et l'environnement.
:::
Exemple de structure de dépôt :
```
some-repository/
└── .openhands/
└── microagents/
└── repo.md # Directives générales du dépôt
└── trigger_this.md # Microagent déclenché par des mots-clés spécifiques
└── trigger_that.md # Microagent déclenché par des mots-clés spécifiques
```
## Exigences de Frontmatter pour les Microagents
Chaque fichier de microagent peut inclure un frontmatter qui fournit des informations supplémentaires. Dans certains cas, ce frontmatter
est requis :
| Type de Microagent | Requis |
|----------------------------------------|---------|
| `Microagents Généraux de Dépôt` | Non |
| `Microagents Déclenchés par Mots-clés` | Oui |

50
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/prompting/microagents-public.md Normal file
View File

@ -0,0 +1,50 @@
# Microagents globaux
## Aperçu
Les microagents globaux sont des [microagents déclenchés par mot-clé](./microagents-keyword) qui s'appliquent à tous les utilisateurs d'OpenHands. Une liste des microagents globaux actuels peut être trouvée [dans le dépôt OpenHands](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents).
## Contribuer un microagent global
Vous pouvez créer des microagents globaux et les partager avec la communauté en ouvrant une pull request sur le dépôt officiel.
Consultez le fichier [CONTRIBUTING.md](https://github.com/All-Hands-AI/OpenHands/blob/main/CONTRIBUTING.md) pour des instructions spécifiques sur la façon de contribuer à OpenHands.
### Bonnes pratiques pour les microagents globaux
- **Portée claire** : Gardez le microagent concentré sur un domaine ou une tâche spécifique.
- **Instructions explicites** : Fournissez des directives claires et sans ambiguïté.
- **Exemples utiles** : Incluez des exemples pratiques de cas d'utilisation courants.
- **Sécurité d'abord** : Incluez les avertissements et contraintes nécessaires.
- **Conscience d'intégration** : Tenez compte de la façon dont le microagent interagit avec d'autres composants.
### Étapes pour contribuer un microagent global
#### 1. Planifier le microagent global
Avant de créer un microagent global, considérez :
- Quel problème spécifique ou cas d'utilisation va-t-il traiter ?
- Quelles capacités ou connaissances uniques devrait-il avoir ?
- Quels mots déclencheurs ont du sens pour l'activer ?
- Quelles contraintes ou directives devrait-il suivre ?
#### 2. Créer le fichier
Créez un nouveau fichier Markdown avec un nom descriptif dans le répertoire approprié :
[`microagents/`](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)
#### 3. Tester le microagent global
- Testez l'agent avec diverses requêtes.
- Vérifiez que les mots déclencheurs activent correctement l'agent.
- Assurez-vous que les instructions sont claires et complètes.
- Vérifiez les conflits potentiels et les chevauchements avec les agents existants.
#### 4. Processus de soumission
Soumettez une pull request avec :
- Le nouveau fichier de microagent.
- Documentation mise à jour si nécessaire.
- Description de l'objectif et des capacités de l'agent.

31
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/prompting/microagents-repo.md Normal file
View File

@ -0,0 +1,31 @@
# Microagents Généraux de Dépôt
## Objectif
Directives générales pour qu'OpenHands travaille plus efficacement avec le dépôt.
## Utilisation
Ces microagents sont toujours chargés dans le contexte.
## Syntaxe du Frontmatter
Le frontmatter pour ce type de microagent est facultatif.
Le frontmatter doit être encadré par des triples tirets (---) et peut inclure les champs suivants :
| Champ | Description | Obligatoire | Valeur par défaut |
|------------|-----------------------------------------|-------------|-------------------|
| `agent` | L'agent auquel ce microagent s'applique | Non | 'CodeActAgent' |
## Exemple
Exemple de fichier microagent général de dépôt situé à `.openhands/microagents/repo.md` :
```
Ce projet est une application TODO qui permet aux utilisateurs de suivre des éléments TODO.
Pour la configurer, vous pouvez exécuter `npm run build`.
Assurez-vous toujours que les tests sont réussis avant de valider les modifications. Vous pouvez exécuter les tests en lançant `npm run test`.
```
[Voir plus d'exemples de microagents généraux de dépôt ici.](https://github.com/All-Hands-AI/OpenHands/tree/main/.openhands/microagents)

40
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/prompting/prompting-best-practices.md
View File

@ -1,43 +1,37 @@
# Meilleures pratiques pour les prompts
Lorsque vous travaillez avec le développeur de logiciels OpenHands AI, il est crucial de fournir des prompts clairs et efficaces. Ce guide décrit les meilleures pratiques pour créer des prompts qui produiront les réponses les plus précises et les plus utiles.
Lorsque vous travaillez avec le développeur IA OpenHands, fournir des prompts clairs et efficaces est essentiel pour obtenir des réponses précises et utiles. Ce guide présente les meilleures pratiques pour élaborer des prompts efficaces.
## Caractéristiques des bons prompts
Les bons prompts sont :
1. **Concrets** : Ils expliquent exactement quelle fonctionnalité doit être ajoutée ou quelle erreur doit être corrigée.
2. **Spécifiques à l'emplacement** : Si connu, ils expliquent les emplacements dans la base de code qui doivent être modifiés.
3. **Correctement dimensionnés** : Ils doivent avoir la taille d'une seule fonctionnalité, ne dépassant généralement pas 100 lignes de code.
- **Concrets** : Décrivez clairement quelle fonctionnalité doit être ajoutée ou quelle erreur doit être corrigée.
- **Spécifiques à l'emplacement** : Précisez les emplacements dans la base de code qui doivent être modifiés, si connus.
- **Correctement délimités** : Concentrez-vous sur une seule fonctionnalité, ne dépassant généralement pas 100 lignes de code.
## Exemples
### Exemples de bons prompts
1. "Ajoutez une fonction `calculate_average` dans `utils/math_operations.py` qui prend une liste de nombres en entrée et renvoie leur moyenne."
2. "Corrigez le TypeError dans `frontend/src/components/UserProfile.tsx` se produisant à la ligne 42. L'erreur suggère que nous essayons d'accéder à une propriété de undefined."
3. "Implémentez la validation des entrées pour le champ email dans le formulaire d'inscription. Mettez à jour `frontend/src/components/RegistrationForm.tsx` pour vérifier si l'email est dans un format valide avant la soumission."
- Ajouter une fonction `calculate_average` dans `utils/math_operations.py` qui prend une liste de nombres en entrée et renvoie leur moyenne.
- Corriger le TypeError dans `frontend/src/components/UserProfile.tsx` qui se produit à la ligne 42. L'erreur suggère que nous essayons d'accéder à une propriété de undefined.
- Implémenter la validation des entrées pour le champ email dans le formulaire d'inscription. Mettre à jour `frontend/src/components/RegistrationForm.tsx` pour vérifier si l'email est dans un format valide avant la soumission.
### Exemples de mauvais prompts
1. "Améliorez le code." (Trop vague, pas concret)
2. "Réécrivez tout le backend pour utiliser un framework différent." (Pas correctement dimensionné)
3. "Il y a un bug quelque part dans l'authentification des utilisateurs. Pouvez-vous le trouver et le corriger ?" (Manque de spécificité et d'informations de localisation)
- Améliorer le code. (Trop vague, pas concret)
- Réécrire tout le backend pour utiliser un framework différent. (Portée inappropriée)
- Il y a un bug quelque part dans l'authentification utilisateur. Pouvez-vous le trouver et le corriger ? (Manque de spécificité et d'informations sur l'emplacement)
## Conseils pour des prompts efficaces
1. Soyez aussi précis que possible sur le résultat souhaité ou le problème à résoudre.
2. Fournissez du contexte, y compris les chemins de fichiers et les numéros de ligne pertinents si disponibles.
3. Décomposez les grandes tâches en prompts plus petits et gérables.
4. Incluez tous les messages d'erreur ou logs pertinents.
5. Spécifiez le langage de programmation ou le framework s'il n'est pas évident d'après le contexte.
- Soyez aussi précis que possible sur le résultat souhaité ou le problème à résoudre.
- Fournissez du contexte, y compris les chemins de fichiers pertinents et les numéros de ligne si disponibles.
- Décomposez les tâches importantes en prompts plus petits et gérables.
- Incluez les messages d'erreur ou les journaux pertinents.
- Précisez le langage de programmation ou le framework, si ce n'est pas évident.
N'oubliez pas, plus votre prompt est précis et informatif, mieux l'IA pourra vous aider à développer ou à modifier le logiciel OpenHands.
Plus votre prompt est précis et informatif, mieux OpenHands pourra vous aider.
Voir [Démarrer avec OpenHands](../getting-started) pour plus d'exemples de prompts utiles.
Voir [Démarrer avec OpenHands](../getting-started) pour plus d'exemples de prompts utiles.

25
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes-index.md Normal file
View File

@ -0,0 +1,25 @@
# Configuration d'exécution
:::note
Cette section est destinée aux utilisateurs qui souhaitent utiliser un environnement d'exécution autre que Docker pour OpenHands.
:::
Un environnement d'exécution est un environnement où l'agent OpenHands peut modifier des fichiers et exécuter des commandes.
Par défaut, OpenHands utilise un [environnement d'exécution basé sur Docker](./runtimes/docker), fonctionnant sur votre ordinateur local.
Cela signifie que vous ne payez que pour le LLM que vous utilisez, et votre code n'est jamais envoyé qu'au LLM.
Nous prenons également en charge d'autres environnements d'exécution, qui sont généralement gérés par des tiers.
De plus, nous fournissons un [Environnement d'exécution local](./runtimes/local) qui s'exécute directement sur votre machine sans Docker,
ce qui peut être utile dans des environnements contrôlés comme les pipelines CI.
## Environnements d'exécution disponibles
OpenHands prend en charge plusieurs environnements d'exécution différents :
- [Environnement Docker](./runtimes/docker.md) - L'environnement d'exécution par défaut qui utilise des conteneurs Docker pour l'isolation (recommandé pour la plupart des utilisateurs).
- [Environnement distant OpenHands](./runtimes/remote.md) - Environnement d'exécution basé sur le cloud pour l'exécution parallèle (bêta).
- [Environnement Modal](./runtimes/modal.md) - Environnement d'exécution fourni par nos partenaires chez Modal.
- [Environnement Daytona](./runtimes/daytona.md) - Environnement d'exécution fourni par Daytona.
- [Environnement local](./runtimes/local.md) - Exécution directe sur votre machine locale sans Docker.

82
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes.md
View File

@ -1,78 +1,8 @@
---
slug: /usage/runtimes
title: Runtime Configuration
---
import { Redirect } from '@docusaurus/router';
# Configuration d'exécution
Un Runtime est un environnement où l'agent OpenHands peut modifier des fichiers et exécuter des commandes.
Par défaut, OpenHands utilise un runtime basé sur Docker, s'exécutant sur votre ordinateur local. Cela signifie que vous n'avez à payer que pour le LLM que vous utilisez, et votre code n'est envoyé qu'au LLM.
Nous prenons également en charge les runtimes "distants", qui sont généralement gérés par des tiers. Ils peuvent simplifier la configuration et la rendre plus évolutive, en particulier si vous exécutez de nombreuses conversations OpenHands en parallèle (par exemple pour faire de l'évaluation).
## Runtime Docker
C'est le Runtime par défaut qui est utilisé lorsque vous démarrez OpenHands. Vous remarquerez peut-être que certains flags sont passés à `docker run` pour rendre cela possible :
```
docker run # ...
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-v /var/run/docker.sock:/var/run/docker.sock \
# ...
```
Le `SANDBOX_RUNTIME_CONTAINER_IMAGE` de nikolaik est une image de runtime pré-construite qui contient notre serveur Runtime, ainsi que quelques utilitaires de base pour Python et NodeJS. Vous pouvez également [construire votre propre image de runtime](how-to/custom-sandbox-guide).
### Connexion à votre système de fichiers
Une fonctionnalité utile ici est la possibilité de se connecter à votre système de fichiers local.
Pour monter votre système de fichiers dans le runtime, définissez d'abord WORKSPACE_BASE :
```bash
export WORKSPACE_BASE=/chemin/vers/votre/code
# Exemple Linux et Mac
# export WORKSPACE_BASE=$HOME/OpenHands
# Définira $WORKSPACE_BASE sur /home/<username>/OpenHands
#
# Exemple WSL sur Windows
# export WORKSPACE_BASE=/mnt/c/dev/OpenHands
# Définira $WORKSPACE_BASE sur C:\dev\OpenHands
```
puis ajoutez les options suivantes à la commande `docker run` :
```bash
docker run # ...
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
# ...
```
Attention ! Rien n'empêche l'agent OpenHands de supprimer ou de modifier les fichiers montés dans son espace de travail.
Cette configuration peut causer des problèmes de permissions de fichiers (d'où la variable `SANDBOX_USER_ID`) mais semble bien fonctionner sur la plupart des systèmes.
## Runtime All Hands
Le Runtime All Hands est actuellement en version bêta. Vous pouvez demander l'accès en rejoignant le canal #remote-runtime-limited-beta sur Slack ([voir le README](https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file#-join-our-community) pour une invitation).
Pour utiliser le Runtime All Hands, définissez les variables d'environnement suivantes lors du démarrage d'OpenHands :
```bash
docker run # ...
-e RUNTIME=remote \
-e SANDBOX_REMOTE_RUNTIME_API_URL="https://runtime.app.all-hands.dev" \
-e SANDBOX_API_KEY="votre-clé-api-all-hands" \
-e SANDBOX_KEEP_RUNTIME_ALIVE="true" \
# ...
```
## Runtime Modal
Nos partenaires de [Modal](https://modal.com/) ont également fourni un runtime pour OpenHands.
Pour utiliser le Runtime Modal, créez un compte, puis [créez une clé API.](https://modal.com/settings)
Vous devrez ensuite définir les variables d'environnement suivantes lors du démarrage d'OpenHands :
```bash
docker run # ...
-e RUNTIME=modal \
-e MODAL_API_TOKEN_ID="votre-id" \
-e MODAL_API_TOKEN_SECRET="votre-secret" \
```
<Redirect to="/modules/usage/runtimes-index" />

32
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes/daytona.md Normal file
View File

@ -0,0 +1,32 @@
# Runtime Daytona
Vous pouvez utiliser [Daytona](https://www.daytona.io/) comme fournisseur de runtime :
## Étape 1 : Récupérer votre clé API Daytona
1. Visitez le [Tableau de bord Daytona](https://app.daytona.io/dashboard/keys).
2. Cliquez sur **"Create Key"**.
3. Entrez un nom pour votre clé et confirmez la création.
4. Une fois la clé générée, copiez-la.
## Étape 2 : Définir votre clé API comme variable d'environnement
Exécutez la commande suivante dans votre terminal, en remplaçant `<your-api-key>` par la clé que vous avez copiée :
```bash
export DAYTONA_API_KEY="<your-api-key>"
```
Cette étape garantit qu'OpenHands peut s'authentifier auprès de la plateforme Daytona lors de son exécution.
## Étape 3 : Exécuter OpenHands localement avec Docker
Pour démarrer la dernière version d'OpenHands sur votre machine, exécutez la commande suivante dans votre terminal :
```bash
bash -i <(curl -sL https://get.daytona.io/openhands)
```
### Ce que fait cette commande :
- Télécharge le script de la dernière version d'OpenHands.
- Exécute le script dans une session Bash interactive.
- Extrait et exécute automatiquement le conteneur OpenHands à l'aide de Docker.
Une fois exécuté, OpenHands devrait fonctionner localement et être prêt à l'emploi.
Pour plus de détails et une initialisation manuelle, consultez le [README.md](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/impl/daytona/README.md) complet

129
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes/docker.md Normal file
View File

@ -0,0 +1,129 @@
# Docker Runtime
C'est le Runtime par défaut qui est utilisé lorsque vous démarrez OpenHands.
## Image
Le `SANDBOX_RUNTIME_CONTAINER_IMAGE` de nikolaik est une image runtime pré-construite
qui contient notre serveur Runtime, ainsi que quelques utilitaires de base pour Python et NodeJS.
Vous pouvez également [construire votre propre image runtime](../how-to/custom-sandbox-guide).
## Connexion à votre système de fichiers
Une fonctionnalité utile est la possibilité de se connecter à votre système de fichiers local. Pour monter votre système de fichiers dans le runtime :
### Utilisation de SANDBOX_VOLUMES
La façon la plus simple de monter votre système de fichiers local est d'utiliser la variable d'environnement `SANDBOX_VOLUMES` :
```bash
docker run # ...
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=/path/to/your/code:/workspace:rw \
# ...
```
Le format de `SANDBOX_VOLUMES` est : `chemin_hôte:chemin_conteneur[:mode]`
- `chemin_hôte` : Le chemin sur votre machine hôte que vous souhaitez monter
- `chemin_conteneur` : Le chemin à l'intérieur du conteneur où le chemin de l'hôte sera monté
- Utilisez `/workspace` pour les fichiers que vous voulez que l'agent modifie. L'agent travaille dans `/workspace` par défaut.
- Utilisez un chemin différent (par exemple, `/data`) pour les documents de référence en lecture seule ou les grands ensembles de données
- `mode` : Mode de montage optionnel, soit `rw` (lecture-écriture, par défaut) soit `ro` (lecture seule)
Vous pouvez également spécifier plusieurs montages en les séparant par des virgules (`,`) :
```bash
export SANDBOX_VOLUMES=/path1:/workspace/path1,/path2:/workspace/path2:ro
```
Exemples :
```bash
# Exemple Linux et Mac - Espace de travail modifiable
export SANDBOX_VOLUMES=$HOME/OpenHands:/workspace:rw
# Exemple WSL sur Windows - Espace de travail modifiable
export SANDBOX_VOLUMES=/mnt/c/dev/OpenHands:/workspace:rw
# Exemple de code de référence en lecture seule
export SANDBOX_VOLUMES=/path/to/reference/code:/data:ro
# Exemple de montages multiples - Espace de travail modifiable avec données de référence en lecture seule
export SANDBOX_VOLUMES=$HOME/projects:/workspace:rw,/path/to/large/dataset:/data:ro
```
> **Remarque :** Lors de l'utilisation de plusieurs montages, le premier montage est considéré comme l'espace de travail principal et sera utilisé pour la compatibilité avec les outils qui s'attendent à un espace de travail unique.
> **Important :** L'agent travaillera dans `/workspace` par défaut. Si vous voulez que l'agent modifie des fichiers dans votre répertoire local, vous devriez monter ce répertoire sur `/workspace`. Si vous avez des données en lecture seule que vous voulez que l'agent accède mais ne modifie pas, montez-les sur un chemin différent (comme `/data`) et demandez explicitement à l'agent de regarder à cet endroit.
### Utilisation des variables WORKSPACE_* (Déprécié)
> **Remarque :** Cette méthode est dépréciée et sera supprimée dans une version future. Veuillez utiliser `SANDBOX_VOLUMES` à la place.
1. Définissez `WORKSPACE_BASE` :
```bash
export WORKSPACE_BASE=/path/to/your/code
```
2. Ajoutez les options suivantes à la commande `docker run` :
```bash
docker run # ...
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
# ...
```
Soyez prudent ! Rien n'empêche l'agent OpenHands de supprimer ou de modifier
les fichiers qui sont montés dans son espace de travail.
Le `-e SANDBOX_USER_ID=$(id -u)` est passé à la commande Docker pour s'assurer que l'utilisateur du sandbox correspond aux
permissions de l'utilisateur hôte. Cela empêche l'agent de créer des fichiers appartenant à root dans l'espace de travail monté.
## Installation Docker renforcée
Lors du déploiement d'OpenHands dans des environnements où la sécurité est une priorité, vous devriez envisager d'implémenter une
configuration Docker renforcée. Cette section fournit des recommandations pour sécuriser votre déploiement Docker OpenHands au-delà de la configuration par défaut.
### Considérations de sécurité
La configuration Docker par défaut dans le README est conçue pour faciliter l'utilisation sur une machine de développement locale. Si vous
l'exécutez sur un réseau public (par exemple, le WiFi d'un aéroport), vous devriez mettre en œuvre des mesures de sécurité supplémentaires.
### Sécurité de liaison réseau
Par défaut, OpenHands se lie à toutes les interfaces réseau (`0.0.0.0`), ce qui peut exposer votre instance à tous les réseaux auxquels
l'hôte est connecté. Pour une configuration plus sécurisée :
1. **Restreindre la liaison réseau** : Utilisez la configuration `runtime_binding_address` pour restreindre les interfaces réseau sur lesquelles OpenHands écoute :
```bash
docker run # ...
-e SANDBOX_RUNTIME_BINDING_ADDRESS=127.0.0.1 \
# ...
```
Cette configuration garantit qu'OpenHands n'écoute que sur l'interface de bouclage (`127.0.0.1`), le rendant accessible uniquement depuis la machine locale.
2. **Liaison de port sécurisée** : Modifiez l'option `-p` pour ne se lier qu'à localhost au lieu de toutes les interfaces :
```bash
docker run # ... \
-p 127.0.0.1:3000:3000 \
```
Cela garantit que l'interface web OpenHands n'est accessible que depuis la machine locale, et non depuis d'autres machines du réseau.
### Isolation réseau
Utilisez les fonctionnalités réseau de Docker pour isoler OpenHands :
```bash
# Créer un réseau isolé
docker network create openhands-network
# Exécuter OpenHands dans le réseau isolé
docker run # ... \
--network openhands-network \
```

74
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes/local.md Normal file
View File

@ -0,0 +1,74 @@
# Runtime Local
Le Runtime Local permet à l'agent OpenHands d'exécuter des actions directement sur votre machine locale sans utiliser Docker.
Ce runtime est principalement destiné aux environnements contrôlés comme les pipelines CI ou les scénarios de test où Docker n'est pas disponible.
:::caution
**Avertissement de sécurité** : Le Runtime Local s'exécute sans aucune isolation sandbox. L'agent peut directement accéder et modifier
des fichiers sur votre machine. N'utilisez ce runtime que dans des environnements contrôlés ou lorsque vous comprenez pleinement les implications de sécurité.
:::
## Prérequis
Avant d'utiliser le Runtime Local, assurez-vous que :
1. Vous pouvez exécuter OpenHands en utilisant le [workflow de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
2. tmux est disponible sur votre système.
## Configuration
Pour utiliser le Runtime Local, en plus des configurations requises comme le fournisseur LLM, le modèle et la clé API, vous devrez définir
les options suivantes via des variables d'environnement ou le [fichier config.toml](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml) lors du démarrage d'OpenHands :
Via des variables d'environnement :
```bash
# Requis
export RUNTIME=local
# Optionnel mais recommandé
# L'agent travaille dans /workspace par défaut, donc montez votre répertoire de projet à cet endroit
export SANDBOX_VOLUMES=/chemin/vers/votre/espace_de_travail:/workspace:rw
# Pour des données en lecture seule, utilisez un chemin de montage différent
# export SANDBOX_VOLUMES=/chemin/vers/votre/espace_de_travail:/workspace:rw,/chemin/vers/grand/dataset:/data:ro
```
Via `config.toml` :
```toml
[core]
runtime = "local"
[sandbox]
# L'agent travaille dans /workspace par défaut, donc montez votre répertoire de projet à cet endroit
volumes = "/chemin/vers/votre/espace_de_travail:/workspace:rw"
# Pour des données en lecture seule, utilisez un chemin de montage différent
# volumes = "/chemin/vers/votre/espace_de_travail:/workspace:rw,/chemin/vers/grand/dataset:/data:ro"
```
Si `SANDBOX_VOLUMES` n'est pas défini, le runtime créera un répertoire temporaire pour que l'agent y travaille.
## Exemple d'utilisation
Voici un exemple de démarrage d'OpenHands avec le Runtime Local en Mode Headless :
```bash
# Définir le type de runtime sur local
export RUNTIME=local
# Définir un répertoire de travail (l'agent travaille dans /workspace par défaut)
export SANDBOX_VOLUMES=/chemin/vers/votre/projet:/workspace:rw
# Pour des données en lecture seule que vous ne voulez pas que l'agent modifie, utilisez un chemin différent
# export SANDBOX_VOLUMES=/chemin/vers/votre/projet:/workspace:rw,/chemin/vers/données/référence:/data:ro
# Démarrer OpenHands
poetry run python -m openhands.core.main -t "écrire un script bash qui affiche bonjour"
```
## Cas d'utilisation
Le Runtime Local est particulièrement utile pour :
- Les pipelines CI/CD où Docker n'est pas disponible.
- Les tests et le développement d'OpenHands lui-même.
- Les environnements où l'utilisation de conteneurs est restreinte.

13
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes/modal.md Normal file
View File

@ -0,0 +1,13 @@
# Runtime Modal
Nos partenaires chez [Modal](https://modal.com/) ont fourni un runtime pour OpenHands.
Pour utiliser le Runtime Modal, créez un compte, puis [créez une clé API.](https://modal.com/settings)
Vous devrez ensuite définir les variables d'environnement suivantes lors du démarrage d'OpenHands :
```bash
docker run # ...
-e RUNTIME=modal \
-e MODAL_API_TOKEN_ID="your-id" \
-e MODAL_API_TOKEN_SECRET="modal-api-key" \
```

9
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/runtimes/remote.md Normal file
View File

@ -0,0 +1,9 @@
# OpenHands Remote Runtime
:::note
Ce runtime est spécifiquement conçu uniquement pour des fins d'évaluation d'agents via le
[harnais d'évaluation OpenHands](https://github.com/All-Hands-AI/OpenHands/tree/main/evaluation). Il ne doit pas être utilisé pour lancer des applications OpenHands en production.
:::
OpenHands Remote Runtime est actuellement en version bêta (lisez [ici](https://runtime.all-hands.dev/) pour plus de détails), il vous permet de lancer des runtimes
en parallèle dans le cloud. Remplissez [ce formulaire](https://docs.google.com/forms/d/e/1FAIpQLSckVz_JFwg2_mOxNZjCtr7aoBFI2Mwdan3f75J_TrdMS1JV2g/viewform) pour postuler si vous souhaitez l'essayer !

68
docs/i18n/fr/docusaurus-plugin-content-docs/current/usage/troubleshooting/troubleshooting.md
View File

@ -1,46 +1,68 @@
# 🚧 Dépannage
:::tip
OpenHands ne prend en charge Windows que via WSL. Veuillez vous assurer d'exécuter toutes les commandes dans votre terminal WSL.
:::
### Impossible d'accéder à l'onglet VS Code via une IP locale
**Description**
Lors de l'accès à OpenHands via une URL non-localhost (comme une adresse IP LAN), l'onglet VS Code affiche une erreur "Forbidden", alors que les autres parties de l'interface fonctionnent correctement.
**Résolution**
Cela se produit car VS Code s'exécute sur un port élevé aléatoire qui peut ne pas être exposé ou accessible depuis d'autres machines. Pour résoudre ce problème :
1. Définissez un port spécifique pour VS Code en utilisant la variable d'environnement `SANDBOX_VSCODE_PORT` :
```bash
docker run -it --rm \
-e SANDBOX_VSCODE_PORT=41234 \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:latest \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
-p 3000:3000 \
-p 41234:41234 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:latest
```
2. Assurez-vous d'exposer le même port avec `-p 41234:41234` dans votre commande Docker.
3. Alternativement, vous pouvez définir cela dans votre fichier `config.toml` :
```toml
[sandbox]
vscode_port = 41234
```
### Échec du lancement du client docker
**Description**
Lors de l'exécution d'OpenHands, l'erreur suivante est observée :
Lors de l'exécution d'OpenHands, l'erreur suivante apparaît :
```
Launch docker client failed. Please make sure you have installed docker and started docker desktop/daemon.
```
**Résolution**
Essayez ces étapes dans l'ordre :
* Vérifiez que `docker` est en cours d'exécution sur votre système. Vous devriez pouvoir exécuter `docker ps` dans le terminal avec succès.
* Si vous utilisez Docker Desktop, assurez-vous que `Settings > Advanced > Allow the default Docker socket to be used` est activé.
* Selon votre configuration, vous devrez peut-être activer `Settings > Resources > Network > Enable host networking` dans Docker Desktop.
Essayez ces solutions dans l'ordre :
* Confirmez que `docker` est en cours d'exécution sur votre système. Vous devriez pouvoir exécuter `docker ps` dans le terminal avec succès.
* Si vous utilisez Docker Desktop, assurez-vous que `Paramètres > Avancé > Autoriser l'utilisation du socket Docker par défaut` est activé.
* Selon votre configuration, vous pourriez avoir besoin d'activer `Paramètres > Ressources > Réseau > Activer le réseau hôte` dans Docker Desktop.
* Réinstallez Docker Desktop.
---
# Spécifique au flux de travail de développement
### Erreur lors de la construction de l'image docker du runtime
### Erreur de permission
**Description**
Les tentatives de démarrage d'une nouvelle session échouent et des erreurs contenant des termes comme les suivants apparaissent dans les logs :
```
debian-security bookworm-security
InRelease At least one invalid signature was encountered.
```
Lors de la première invite, une erreur avec `Permission Denied` ou `PermissionError` est affichée.
Cela semble se produire lorsque le hash d'une bibliothèque externe existante change et que votre instance docker locale a
mis en cache une version précédente. Pour contourner ce problème, veuillez essayer ce qui suit :
**Résolution**
* Arrêtez tous les conteneurs dont le nom a le préfixe `openhands-runtime-` :
`docker ps --filter name=openhands-runtime- --filter status=running -aq | xargs docker stop`
* Supprimez tous les conteneurs dont le nom a le préfixe `openhands-runtime-` :
`docker rmi $(docker images --filter name=openhands-runtime- -q --no-trunc)`
* Arrêtez et supprimez tous les conteneurs / images dont le nom a le préfixe `openhands-runtime-`
* Nettoyez les conteneurs / images : `docker container prune -f && docker image prune -f`
* Vérifiez si le répertoire `~/.openhands-state` appartient à `root`. Si c'est le cas, vous pouvez :
* Changer le propriétaire du répertoire : `sudo chown <utilisateur>:<utilisateur> ~/.openhands-state`.
* ou mettre à jour les permissions du répertoire : `sudo chmod 777 ~/.openhands-state`
* ou le supprimer si vous n'avez pas besoin des données précédentes. OpenHands le recréera. Vous devrez ressaisir les paramètres LLM.
* Si vous montez un répertoire local, assurez-vous que votre `WORKSPACE_BASE` dispose des permissions nécessaires pour l'utilisateur exécutant OpenHands.

22
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/about.md
View File

@ -1,27 +1,25 @@
# OpenHands について
# OpenHandsについて
## 研究戦略
LLM を使用して本番レベルのアプリケーションを完全に複製することは複雑な endeavor です。私たちの戦略は以下の通りです:
LLMによる本番グレードのアプリケーションの完全な複製を達成することは複雑な取り組みです。私たちの戦略は以下を含みます：
- **コア技術研究:** コード生成と処理の技術的側面を理解し改善するための基礎研究に注力します。
- **タスク計画:** バグ検出、コードベース管理、最適化の機能を開発します。
- **評価:** 私たちのエージェントをより良く理解し改善するための包括的な評価指標を確立します。
- **コア技術研究：** コード生成と処理の技術的側面を理解し改善するための基礎研究に焦点を当てる。
- **タスク計画：** バグ検出、コードベース管理、最適化のための能力開発。
- **評価：** エージェントをより良く理解し改善するための包括的な評価指標の確立。
## デフォルトエージェント
現在のデフォルトエージェントは、コードの生成とファイル処理が可能な [CodeActAgent](agents) です。
現在のデフォルトエージェントは[CodeActAgent](agents)で、コードの生成とファイル処理が可能です。
## 構築技術
## 使用技術
OpenHands は、強力なフレームワークとライブラリを組み合わせて構築されており、開発のための堅牢な基盤を提供しています。
プロジェクトで使用されている主要な技術は以下の通りです:
OpenHandsは強力なフレームワークとライブラリの組み合わせを使用して構築されており、その開発のための堅牢な基盤を提供しています。以下はプロジェクトで使用されている主要な技術です：
![FastAPI](https://img.shields.io/badge/FastAPI-black?style=for-the-badge) ![uvicorn](https://img.shields.io/badge/uvicorn-black?style=for-the-badge) ![LiteLLM](https://img.shields.io/badge/LiteLLM-black?style=for-the-badge) ![Docker](https://img.shields.io/badge/Docker-black?style=for-the-badge) ![Ruff](https://img.shields.io/badge/Ruff-black?style=for-the-badge) ![MyPy](https://img.shields.io/badge/MyPy-black?style=for-the-badge) ![LlamaIndex](https://img.shields.io/badge/LlamaIndex-black?style=for-the-badge) ![React](https://img.shields.io/badge/React-black?style=for-the-badge)
これらの技術の選択は進行中であり、プロジェクトの進化に伴って新しい技術が追加されたり、既存の技術が削除されたりする可能性があることに注意してください。
私たちは OpenHands の機能を強化するために、最も適切で効率的なツールを採用するよう努めています。
これらの技術の選択は進行中であり、プロジェクトの進化に伴い、追加の技術が加えられたり、既存のものが削除されたりする可能性があることにご注意ください。私たちはOpenHandsの能力を高めるために、最も適切で効率的なツールを採用するよう努めています。
## ライセンス
MIT [ライセンス](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) の下で配布されています。
MIT [ライセンス](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE)の下で配布されています。

12
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/agents.md
View File

@ -4,15 +4,15 @@
### 説明
このエージェントは、CodeActのアイデア ([論文](https://arxiv.org/abs/2402.01030), [ツイート](https://twitter.com/xingyaow_/status/1754556835703751087)) を実装しており、LLMエージェントの**行動**を、_シンプルさ_と_パフォーマンス_の両方のために、統一された**コード**行動空間に統合します。
このエージェントはCodeActのアイデア（[論文](https://arxiv.org/abs/2402.01030)、[ツイート](https://twitter.com/xingyaow_/status/1754556835703751087)）を実装しており、LLMエージェントの**アクション**を統一された**コード**アクション空間に統合することで、_シンプルさ_と_パフォーマンス_の両方を実現します。
概念的なアイデアは以下の図に示されています。各ターンで、エージェントは以下のことができます。
概念的なアイデアは以下のように示されています。各ターンで、エージェントは以下のことができます：
1. **会話**: 明確化、確認などのために、自然言語で人間とコミュニケーションをとる。
1. **会話**: 人間と自然言語でコミュニケーションを取り、明確化や確認などを求める
2. **CodeAct**: コードを実行してタスクを実行することを選択する
- 任意の有効なLinux `bash`コマンドを実行する
- [対話型Pythonインタープリター](https://ipython.org/)で任意の有効な`Python`コードを実行する。これは`bash`コマンドを通してシミュレートされます。詳細はプラグインシステムを参照してください。
- 有効なLinux `bash` コマンドを実行する
- [インタラクティブなPythonインタプリタ](https://ipython.org/)で有効な`Python`コードを実行する。これは`bash`コマンドを通じてシミュレートされます。詳細については以下のプラグインシステムを参照してください。
![image](https://github.com/All-Hands-AI/OpenHands/assets/38853559/92b622e3-72ad-4a61-8f41-8c040b6d5fb3)
@ -20,4 +20,4 @@
https://github.com/All-Hands-AI/OpenHands/assets/38853559/f592a192-e86c-4f48-ad31-d69282d5f6ac
_データサイエンスタスク（線形回帰）を実行する`gpt-4-turbo-2024-04-09`を使用したCodeActAgentの例_。
_`gpt-4-turbo-2024-04-09`を使用したCodeActAgentがデータサイエンスタスク（線形回帰）を実行する例_。

39
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx
View File

@ -2,52 +2,51 @@
<div style={{ textAlign: 'center' }}>
<img src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38" alt="OpenHands System Architecture Diagram Jul 4 2024" />
<p><em>OpenHands システムアーキテクチャ図 (2024年7月4日)</em></p>
<p><em>OpenHandsシステムアーキテクチャ図（2024年7月4日）</em></p>
</div>
これはシステムアーキテクチャの高レベルな概要です。システムはフロントエンドとバックエンドの2つの主要コンポーネントに分かれています。フロントエンドはユーザーインタラクションを処理し、結果を表示する役割を担います。バックエンドはビジネスロジックを処理し、エージェントを実行する役割を担います。
これはシステムアーキテクチャの高レベル概要です。システムはフロントエンドとバックエンドの2つの主要コンポーネントに分かれています。フロントエンドはユーザーインタラクションの処理と結果の表示を担当します。バックエンドはビジネスロジックの処理とエージェントの実行を担当します。
# フロントエンドアーキテクチャ {#frontend-architecture-ja}
# フロントエンドアーキテクチャ {#frontend-architecture-en}
![system_architecture.svg](/img/system_architecture.svg)
この概要は、主要なコンポーネントとそれらの相互作用を示すために簡略化されています。バックエンドアーキテクチャのより詳細なビューについては、以下のバックエンドアーキテクチャのセクションを参照してください。
この概要は主要コンポーネントとその相互作用を示すために簡略化されています。バックエンドアーキテクチャのより詳細な表示については、以下のバックエンドアーキテクチャセクションを参照してください。
# バックエンドアーキテクチャ {#backend-architecture-ja}
# バックエンドアーキテクチャ {#backend-architecture-en}
_**免責事項**: バックエンドアーキテクチャは現在進行中の作業であり、変更される可能性があります。以下の図は、図のフッターに示されているコミットに基づくバックエンドの現在のアーキテクチャを示しています。_
_**免責事項**: バックエンドアーキテクチャは進行中の作業であり、変更される可能性があります。以下の図は、図のフッターに表示されているコミットに基づく現在のバックエンドアーキテクチャを示しています。_
![backend_architecture.svg](/img/backend_architecture.svg)
<details>
<summary>この図の更新</summary>
<summary>この図の更新について</summary>
<div>
バックエンドアーキテクチャ図の生成は部分的に自動化されています。
この図は、py2pumlツールを使用してコード内の型ヒントから生成されます。
その後、図は手動でレビュー、調整され、PNGとSVGにエクスポートされます。
この図はpy2pumlツールを使用してコード内の型ヒントから生成されます。その後、図は手動でレビュー、調整され、PNGおよびSVGにエクスポートされます。
## 前提条件
- openhandsが実行可能なPython環境
(リポジトリのルートにあるREADME.mdファイルの指示に従って)
- openhandsが実行可能なPython環境が稼働していること
（リポジトリのルートにあるREADME.mdファイルの指示に従って）
- [py2puml](https://github.com/lucsorel/py2puml)がインストールされていること
## 手順
1. リポジトリのルートから以下のコマンドを実行して、図を自動生成します:
1. リポジトリのルートから次のコマンドを実行して図を自動生成します：
`py2puml openhands openhands > docs/architecture/backend_architecture.puml`
2. 生成されたファイルをPlantUMLエディタで開きます。例えば、PlantUML拡張機能を使用したVisual Studio Codeや[PlantText](https://www.planttext.com/)など。
2. 生成されたファイルをPlantUMLエディタで開きます。例えば、PlantUML拡張機能を持つVisual Studio Codeや[PlantText](https://www.planttext.com/)などです。
3. 生成されたPUMLをレビューし、図に必要な調整を行います(欠落部分の追加、ミスの修正、位置の改善など)。
_py2pumlは、コード内の型ヒントに基づいて図を作成するため、型ヒントが欠落していたり正しくない場合、図が不完全または不正確になることがあります。_
3. 生成されたPUMLをレビューし、図に必要な調整をすべて行います（不足している部分の追加、ミスの修正、配置の改善）。
_py2pumlはコード内の型ヒントに基づいて図を作成するため、型ヒントが不足または不正確な場合、不完全または不正確な図が生成される可能性があります。_
4. 新旧の図の差分をレビューし、変更が正しいかどうかを手動で確認します。
_過去に図に手動で追加され、現在も関連性のある部分を削除しないように注意してください。_
4. 新しい図と以前の図の差分をレビューし、変更が正しいかどうかを手動で確認します。
_過去に図に手動で追加され、まだ関連性のある部分を削除しないように注意してください。_
5. 図のフッターに、図の生成に使用されたコミットのコミットハッシュを追加します。
5. 図を生成するために使用されたコミットのコミットハッシュを図のフッターに追加します。
6. 図をPNGとSVGファイルとしてエクスポートし、`docs/architecture`ディレクトリ内の既存の図を置き換えます。これは(例えば[PlantText](https://www.planttext.com/))で行うことができます。
6. 図をPNGおよびSVGファイルとしてエクスポートし、`docs/architecture`ディレクトリ内の既存の図を置き換えます。これは（例えば[PlantText](https://www.planttext.com/)で）行うことができます。
</div>
</details>
</details>

124
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md
View File

@ -1,43 +1,41 @@
以下に翻訳結果を示します。
# 📦 Docker ランタイム
# 📦 Dockerランタイム
OpenHands Docker ランタイムは、AIエージェントのアクションを安全かつ柔軟に実行できるようにする中核コンポーネントです。
Dockerを使用してサンドボックス環境を作成し、ホストシステムを危険にさらすことなく任意のコードを安全に実行できます。
OpenHands Dockerランタイムは、AIエージェントのアクションを安全かつ柔軟に実行できるようにするコアコンポーネントです。
Dockerを使用してサンドボックス化された環境を作成し、ホストシステムを危険にさらすことなく任意のコードを安全に実行できます。
## なぜサンドボックス化されたランタイムが必要なのか？
## サンドボックス化されたランタイムが必要な理由
OpenHandsが任意のコードを安全で隔離された環境で実行する必要がある理由はいくつかあります：
OpenHandsでは、いくつかの理由から、信頼できないコードを安全で隔離された環境で実行する必要があります。
1. セキュリティ：信頼されていないコードの実行はホストシステムに重大なリスクをもたらす可能性があります。サンドボックス環境は悪意のあるコードがホストシステムのリソースにアクセスしたり変更したりすることを防ぎます
2. 一貫性：サンドボックス環境により、異なるマシンやセットアップ間でのコード実行の一貫性が確保され、「自分のマシンでは動作する」という問題を排除します
3. リソース制御：サンドボックス化によりリソースの割り当てと使用をより適切に制御でき、暴走プロセスがホストシステムに影響を与えることを防ぎます
4. 分離：異なるプロジェクトやユーザーが互いにまたはホストシステムに干渉することなく、隔離された環境で作業できます
5. 再現性：サンドボックス環境は実行環境が一貫していて制御可能なため、バグや問題の再現が容易になります
1. セキュリティ: 信頼できないコードを実行すると、ホストシステムに重大なリスクを及ぼす可能性があります。サンドボックス化された環境では、悪意のあるコードがホストシステムのリソースにアクセスしたり、変更したりすることを防ぐことができます。
2. 一貫性: サンドボックス化された環境では、異なるマシンやセットアップ間でコードの実行が一貫していることが保証され、「自分のマシンでは動作する」という問題が解消されます。
3. リソース制御: サンドボックス化により、リソースの割り当てと使用をより適切に制御でき、暴走プロセスがホストシステムに影響を与えることを防ぐことができます。
4. 分離: 異なるプロジェクトやユーザーは、ホストシステムや他のプロジェクトに干渉することなく、分離された環境で作業できます。
5. 再現性: サンドボックス化された環境では、実行環境が一貫しており制御可能であるため、バグや問題を再現しやすくなります。
## ランタイムはどのように機能するか？
## ランタイムの仕組み
OpenHandsランタイムシステムは、Dockerコンテナを使用してクライアント-サーバーアーキテクチャを実装しています。以下は、その仕組みの概要です。
OpenHandsランタイムシステムはDockerコンテナで実装されたクライアント-サーバーアーキテクチャを使用しています。以下はその仕組みの概要です：
```mermaid
graph TD
A[ユーザー提供のカスタムDockerイメージ] --> B[OpenHandsバックエンド]
B -->|ビルド| C[OHランタイムイメージ]
C -->|起動| D[アクション実行サーバー]
C -->|起動| D[アクション実行者]
D -->|初期化| E[ブラウザ]
D -->|初期化| F[Bashシェル]
D -->|初期化| G[プラグイン]
G -->|初期化| L[Jupyterサーバー]
B -->|生成| H[エージェント]
B -->|生成| I[EventStream]
B -->|生成| I[イベントストリーム]
I <--->|REST APIを介して
アクションを実行し
観測結果を取得
観測を取得
| D
H -->|アクション生成| I
I -->|観測結果取得| H
H -->|アクションを生成| I
I -->|観測を取得| H
subgraph "Dockerコンテナ"
D
@ -48,82 +46,82 @@ graph TD
end
```
1. ユーザー入力: ユーザーがカスタムベースDockerイメージを提供します。
2. イメージのビルド: OpenHandsは、ユーザー提供のイメージをベースに新しいDockerイメージ（「OHランタイムイメージ」）をビルドします。この新しいイメージには、主に「ランタイムクライアント」であるOpenHands固有のコードが含まれます。
3. コンテナの起動: OpenHandsが起動すると、OHランタイムイメージを使用してDockerコンテナが起動します。
4. アクション実行サーバーの初期化: アクション実行サーバーは、コンテナ内で`ActionExecutor`を初期化し、Bashシェルなどの必要なコンポーネントをセットアップし、指定されたプラグインをロードします。
5. 通信: OpenHandsバックエンド（`openhands/runtime/impl/eventstream/eventstream_runtime.py`）は、RESTful APIを介してアクション実行サーバーと通信し、アクションを送信し、観測結果を受信します。
6. アクションの実行: ランタイムクライアントはバックエンドからアクションを受信し、サンドボックス化された環境内でそれらを実行し、観測結果を送り返します。
7. 観測結果の返却: アクション実行サーバーは、実行結果を観測結果としてOpenHandsバックエンドに送り返します。
1. ユーザー入力：ユーザーがカスタムベースDockerイメージを提供します
2. イメージビルド：OpenHandsはユーザー提供のイメージに基づいて新しいDockerイメージ（「OHランタイムイメージ」）をビルドします。この新しいイメージにはOpenHands固有のコード、主に「ランタイムクライアント」が含まれます
3. コンテナ起動：OpenHandsが起動すると、OHランタイムイメージを使用してDockerコンテナを起動します
4. アクション実行サーバーの初期化：アクション実行サーバーはコンテナ内で`ActionExecutor`を初期化し、Bashシェルなどの必要なコンポーネントをセットアップし、指定されたプラグインをロードします
5. 通信：OpenHandsバックエンド（`openhands/runtime/impl/eventstream/eventstream_runtime.py`）はRESTful APIを介してアクション実行サーバーと通信し、アクションを送信して観測を受け取ります
6. アクション実行：ランタイムクライアントはバックエンドからアクションを受け取り、サンドボックス環境で実行し、観測結果を送り返します
7. 観測結果の返送：アクション実行サーバーは実行結果を観測としてOpenHandsバックエンドに送り返します
クライアントの役割:
クライアントの役割：
- OpenHandsバックエンドとサンドボックス化された環境の間の仲介役を果たします。
- コンテナ内で様々なタイプのアクション（シェルコマンド、ファイル操作、Pythonコードなど）を安全に実行します。
- 現在の作業ディレクトリやロードされたプラグインなど、サンドボックス化された環境の状態を管理します。
- 観測結果をフォーマットしてバックエンドに返し、結果を処理するための一貫したインターフェースを確保します。
- OpenHandsバックエンドとサンドボックス環境の間の仲介役として機能します
- さまざまなタイプのアクション（シェルコマンド、ファイル操作、Pythonコードなど）をコンテナ内で安全に実行します
- 現在の作業ディレクトリやロードされたプラグインなど、サンドボックス環境の状態を管理します
- 観測結果をバックエンドにフォーマットして返し、結果処理のための一貫したインターフェースを確保します
## OpenHandsがOHランタイムイメージをビルドおよび管理する方法
## OpenHandsがOHランタイムイメージをビルドし維持する方法
OpenHandsのランタイムイメージのビルドと管理に対するアプローチは、本番環境と開発環境の両方でDockerイメージを効率的、一貫性のある、柔軟な方法で作成および維持することを保証します。
OpenHandsのランタイムイメージの構築と管理へのアプローチは、本番環境と開発環境の両方のDockerイメージを作成・維持する際の効率性、一貫性、柔軟性を確保します。
詳細に興味がある場合は、[関連コード](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py)をチェックしてください。
詳細に興味がある場合は[関連コード](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py)をご確認ください。
### イメージタグ付けシステム
### イメージタグシステム
OpenHandsは、再現性と柔軟性のバランスを取るために、ランタイムイメージに3つのタグシステムを使用しています。
タグは以下の2つの形式のいずれかになります。
OpenHandsはランタイムイメージに3つのタグシステムを使用して、再現性と柔軟性のバランスを取っています。
タグは以下の2つの形式のいずれかになります：
- **バージョン付きタグ**: `oh_v{openhands_version}_{base_image}` (例: `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
- **ロックタグ**: `oh_v{openhands_version}_{16_digit_lock_hash}` (例: `oh_v0.9.9_1234567890abcdef`)
- **ソースタグ**: `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
(例: `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
- **バージョンタグ**：`oh_v{openhands_version}_{base_image}`（例：`oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`）
- **ロックタグ**：`oh_v{openhands_version}_{16_digit_lock_hash}`（例：`oh_v0.9.9_1234567890abcdef`）
- **ソースタグ**：`oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
（例：`oh_v0.9.9_1234567890abcdef_1234567890abcdef`）
#### ソースタグ - 最も具体的
これは、ソースディレクトリのディレクトリハッシュのMD5の最初の16桁です。これにより、openhandsソースのみのハッシュが得られます。
これはソースディレクトリのディレクトリハッシュのMD5の最初の16桁です。これによりOpenhandsのソースコードのみのハッシュが得られます。
#### ロックタグ
このハッシュは、以下のMD5の最初の16桁から構築されます。
このハッシュは以下のMD5の最初の16桁から構築されます：
- イメージがビルドされたベースイメージの名前（例: `nikolaik/python-nodejs:python3.12-nodejs22`）
- イメージが構築されたベースイメージの名前（例：`nikolaik/python-nodejs:python3.12-nodejs22`）
- イメージに含まれる`pyproject.toml`の内容
- イメージに含まれる`poetry.lock`の内容
これにより、ソースコードとは無関係に、Openhandsの依存関係のハッシュが効果的に得られます。
これにより、ソースコードとは独立したOpenhandsの依存関係のハッシュが効果的に得られます。
#### バージョン付きタグ - 最も一般的
#### バージョンタグ - 最も一般的
このタグは、openhandsのバージョンとベースイメージ名（タグ標準に適合するように変換されたもの）を連結したものです。
このタグはOpenhandsのバージョンとベースイメージ名（タグ標準に合わせて変換）の連結です。
#### ビルドプロセス
イメージを生成する際...
- **再ビルドなし**: OpenHandsは最初に、同じ**最も具体的なソースタグ**を持つイメージが存在するかどうかをチェックします。そのようなイメージが存在する場合、ビルドは実行されず、既存のイメージが使用されます。
- **最速の再ビルド**: 次に、OpenHandsは**一般的なロックタグ**を持つイメージが存在するかどうかをチェックします。そのようなイメージが存在する場合、OpenHandsはそれに基づいて新しいイメージをビルドし、現在のソースコードをコピーする最終操作を除くすべてのインストール手順（`poetry install`や`apt-get`など）をバイパスします。新しいイメージには**ソース**タグのみが付けられます。
- **まあまあの再ビルド**: **ソース**タグも**ロック**タグも存在しない場合、**バージョン付き**タグイメージに基づいてイメージがビルドされます。バージョン付きタグイメージでは、ほとんどの依存関係がすでにインストールされているため、時間を節約できます。
- **最も遅い再ビルド**: 3つのタグのすべてが存在しない場合、ベースイメージに基づいて新しいイメージがビルドされます（これは遅い操作です）。この新しいイメージには、**ソース**、**ロック**、**バージョン付き**の各タグが付けられます。
- **再ビルドなし**：OpenHandsはまず同じ**最も具体的なソースタグ**を持つイメージが存在するかどうかを確認します。そのようなイメージが存在する場合、ビルドは実行されず、既存のイメージが使用されます。
- **最速の再ビルド**：OpenHandsは次に**一般的なロックタグ**を持つイメージが存在するかどうかを確認します。そのようなイメージが存在する場合、OpenHandsはそれに基づいて新しいイメージをビルドし、現在のソースコードをコピーする最終操作を除いて、すべてのインストール手順（`poetry install`や`apt-get`など）をバイパスします。新しいイメージには**ソース**タグのみが付けられます。
- **まあまあの再ビルド**：**ソース**も**ロック**タグも存在しない場合、**バージョン**タグイメージに基づいてイメージがビルドされます。バージョンタグイメージでは、ほとんどの依存関係がすでにインストールされているため、時間を節約できます。
- **最も遅い再ビルド**：3つのタグすべてが存在しない場合、ベースイメージに基づいて全く新しいイメージがビルドされます（これはより遅い操作です）。この新しいイメージには**ソース**、**ロック**、**バージョン**のすべてのタグが付けられます。
このタグ付けアプローチにより、OpenHandsは開発環境と本番環境の両方を効率的に管理できます。
1. 同一のソースコードとDockerfileは、常に同じイメージを生成します（ハッシュベースのタグを介して）。
2. 小さな変更が発生した場合、システムはイメージを迅速に再ビルドできます（最近の互換性のあるイメージを活用することで）。
3. **ロック**タグ（例: `runtime:oh_v0.9.3_1234567890abcdef`）は、特定のベースイメージ、依存関係、およびOpenHandsバージョンの組み合わせに対する最新のビルドを常に指します。
1. 同一のソースコードとDockerfileは常に同じイメージを生成します（ハッシュベースのタグを介して）
2. 軽微な変更が発生した場合、システムは互換性のある最新のイメージを活用して迅速にイメージを再構築できます
3. **ロック**タグ（例：`runtime:oh_v0.9.3_1234567890abcdef`）は常に特定のベースイメージ、依存関係、OpenHandsバージョンの組み合わせに対する最新のビルドを指します
## ランタイムプラグインシステム
OpenHandsランタイムは、機能を拡張し、ランタイム環境をカスタマイズできるプラグインシステムをサポートしています。プラグインは、ランタイムクライアントの起動時に初期化されます。
OpenHandsランタイムは、機能を拡張しランタイム環境をカスタマイズできるプラグインシステムをサポートしています。プラグインはランタイムクライアントの起動時に初期化されます。
独自のプラグインを実装したい場合は、[Jupyterプラグインの例](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55)をチェックしてください。
独自のプラグインを実装したい場合は、[Jupyterプラグインの例はこちら](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55)をご確認ください。
*プラグインシステムの詳細はまだ作成中です - 貢献を歓迎します！*
*プラグインシステムに関する詳細はまだ構築中です - 貢献を歓迎します！*
プラグインシステムの主な側面:
プラグインシステムの主な側面：
1. プラグインの定義: プラグインは、基本の`Plugin`クラスを継承するPythonクラスとして定義されます。
2. プラグインの登録: 利用可能なプラグインは、`ALL_PLUGINS`辞書に登録されます。
3. プラグインの指定: プラグインは、`Agent.sandbox_plugins: list[PluginRequirement]`に関連付けられます。ユーザーは、ランタイムを初期化するときにロードするプラグインを指定できます。
4. 初期化: プラグインは、ランタイムクライアントの起動時に非同期で初期化されます。
5. 使用: ランタイムクライアントは、初期化されたプラグインを使用して機能を拡張できます（例: IPythonセルを実行するためのJupyterPlugin）。
1. プラグイン定義：プラグインは基本の`Plugin`クラスを継承するPythonクラスとして定義されます
2. プラグイン登録：利用可能なプラグインは`ALL_PLUGINS`辞書に登録されます
3. プラグイン指定：プラグインは`Agent.sandbox_plugins: list[PluginRequirement]`に関連付けられます。ユーザーはランタイムの初期化時にロードするプラグインを指定できます
4. 初期化：プラグインはランタイムクライアントの起動時に非同期で初期化されます
5. 使用法：ランタイムクライアントは初期化されたプラグインを使用して機能を拡張できます（例：IPythonセルを実行するためのJupyterPlugin）

177
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md Normal file
View File

@ -0,0 +1,177 @@
# OpenHands Cloud API
OpenHands Cloudは、サービスをプログラムで操作できるREST APIを提供しています。これは、自分のプログラムから柔軟な方法で簡単にジョブを開始したい場合に便利です。
このガイドでは、APIキーの取得方法と、APIを使用して会話を開始する方法について説明します。
APIの詳細については、[OpenHands APIリファレンス](https://docs.all-hands.dev/swagger-ui/)を参照してください。
## APIキーの取得
OpenHands Cloud APIを使用するには、APIキーを生成する必要があります：
1. [OpenHands Cloud](https://app.all-hands.dev)アカウントにログインします
2. [設定ページ](https://app.all-hands.dev/settings)に移動します
3. 「APIキー」セクションを見つけます
4. 「新しいキーを生成」をクリックします
5. キーに分かりやすい名前を付けます（例：「開発用」、「本番用」）
6. 生成されたAPIキーをコピーして安全に保管します - 表示されるのは一度だけです
![APIキー生成](/img/docs/api-key-generation.png)
## APIの使用方法
### 新しい会話の開始
OpenHandsでタスクを実行する新しい会話を開始するには、会話エンドポイントにPOSTリクエストを送信する必要があります。
#### リクエストパラメータ
| パラメータ | 型 | 必須 | 説明 |
|-----------|------|----------|-------------|
| `initial_user_msg` | string | はい | 会話を開始する最初のメッセージ |
| `repository` | string | いいえ | コンテキストを提供するGitリポジトリ名（`owner/repo`形式）。リポジトリへのアクセス権が必要です。 |
#### 例
<details>
<summary>cURL</summary>
```bash
curl -X POST "https://app.all-hands.dev/api/conversations" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}'
```
</details>
<details>
<summary>Python (requestsを使用)</summary>
```python
import requests
api_key = "YOUR_API_KEY"
url = "https://app.all-hands.dev/api/conversations"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
data = {
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}
response = requests.post(url, headers=headers, json=data)
conversation = response.json()
print(f"Conversation Link: https://app.all-hands.dev/conversations/{conversation['id']}")
print(f"Status: {conversation['status']}")
```
</details>
<details>
<summary>TypeScript/JavaScript (fetchを使用)</summary>
```typescript
const apiKey = "YOUR_API_KEY";
const url = "https://app.all-hands.dev/api/conversations";
const headers = {
"Authorization": `Bearer ${apiKey}`,
"Content-Type": "application/json"
};
const data = {
initial_user_msg: "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
repository: "yourusername/your-repo"
};
async function startConversation() {
try {
const response = await fetch(url, {
method: "POST",
headers: headers,
body: JSON.stringify(data)
});
const conversation = await response.json();
console.log(`Conversation Link: https://app.all-hands.dev/conversations/${conversation.id}`);
console.log(`Status: ${conversation.status}`);
return conversation;
} catch (error) {
console.error("Error starting conversation:", error);
}
}
startConversation();
```
</details>
#### レスポンス
APIは作成された会話の詳細を含むJSONオブジェクトを返します：
```json
{
"status": "ok",
"conversation_id": "abc1234",
}
```
以下の場合は`AuthenticationError`を受け取ることがあります：
1. 無効なAPIキーを提供した場合
2. 間違ったリポジトリ名を提供した場合
3. リポジトリへのアクセス権がない場合
### 会話ステータスの取得
会話エンドポイントにGETリクエストを送信することで、会話のステータスを確認できます。
#### エンドポイント
```
GET https://app.all-hands.dev/api/conversations/{conversation_id}
```
#### 例
<details>
<summary>cURL</summary>
```bash
curl -X GET "https://app.all-hands.dev/api/conversations/{conversation_id}" \
-H "Authorization: Bearer YOUR_API_KEY"
```
</details>
#### レスポンス
レスポンスは以下の形式でフォーマットされます：
```json
{
"conversation_id":"abc1234",
"title":"Update README.md",
"created_at":"2025-04-29T15:13:51.370706Z",
"last_updated_at":"2025-04-29T15:13:57.199210Z",
"status":"RUNNING",
"selected_repository":"yourusername/your-repo",
"trigger":"gui"
}
```
## レート制限
APIはアカウントごとに10の同時会話の制限があります。ユースケースに応じてより高い制限が必要な場合は、[contact@all-hands.dev](mailto:contact@all-hands.dev)までお問い合わせください。
この制限を超えると、APIは429 Too Many Requestsレスポンスを返します。

31
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md Normal file
View File

@ -0,0 +1,31 @@
# Cloud GitHub Resolver
GitHub Resolverはコードの修正を自動化し、リポジトリに対してインテリジェントな支援を提供します。
## セットアップ
Cloud GitHub Resolverは、[OpenHands Cloudにリポジトリアクセス権を付与する](./openhands-cloud#adding-repository-access)と自動的に利用可能になります。
## 使用方法
OpenHands Cloudにリポジトリアクセス権を付与した後、リポジトリの課題（Issue）とプルリクエストでCloud GitHub Resolverを使用できます。
### 課題（Issues）
リポジトリで課題に`openhands`ラベルを付けると、OpenHandsは以下の操作を行います：
1. 課題にコメントして、作業中であることを通知します。
- OpenHands Cloudで進捗状況を追跡するためのリンクをクリックできます。
2. 課題が正常に解決されたと判断した場合、プルリクエストを開きます。
3. 実行されたタスクの概要とプルリクエストへのリンクを含むコメントを課題に投稿します。
### プルリクエスト
プルリクエストでOpenHandsを利用するには、トップレベルまたはインラインコメントで`@openhands`を使用して：
- 質問する
- 更新をリクエストする
- コードの説明を取得する
OpenHandsは以下の操作を行います：
1. PRにコメントして、作業中であることを通知します。
2. タスクを実行します。

65
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx Normal file
View File

@ -0,0 +1,65 @@
# OpenHands Cloud
OpenHands CloudはAll Hands AIによるOpenHandsのクラウドホスト版です。
## OpenHands Cloudへのアクセス
OpenHands Cloudは https://app.all-hands.dev/ でアクセスできます。
[API](./cloud-api)を使用してプログラム的にOpenHands Cloudと対話することもできます。
## はじめに
OpenHands Cloudにアクセスすると、GitHubまたはGitLabアカウントとの接続を求められます：
1. 利用規約を読んで同意した後、`Log in with GitHub`または`Log in with GitLab`をクリックします。
2. OpenHandsが要求する権限を確認し、`Authorize OpenHands AI`をクリックします。
- OpenHandsはGitHubまたはGitLabアカウントからいくつかの権限を必要とします。これらの権限について詳しく知るには：
- GitHub：GitHub認証ページの`Learn more`リンクをクリックできます。
- GitLab：GitLab認証ページで各権限リクエストを展開できます。
## リポジトリアクセス
### GitHub
#### リポジトリアクセスの追加
OpenHandsに特定のリポジトリへのアクセス権を付与できます：
1. ホームページで`Add GitHub repos`をクリックします。
2. 組織を選択し、OpenHandsにアクセス権を付与する特定のリポジトリを選択します。
<details>
<summary>リポジトリアクセスの権限詳細</summary>
Openhandsは短期間のトークン（8時間で期限切れ）を以下の権限で要求します：
- Actions：読み取りと書き込み
- Administration：読み取り専用
- Commit statuses：読み取りと書き込み
- Contents：読み取りと書き込み
- Issues：読み取りと書き込み
- Metadata：読み取り専用
- Pull requests：読み取りと書き込み
- Webhooks：読み取りと書き込み
- Workflows：読み取りと書き込み
ユーザーのリポジトリアクセスは以下に基づいて付与されます：
- リポジトリに対して付与された権限
- ユーザーのGitHub権限（オーナー/コラボレーター）
</details>
3. `Install & Authorize`をクリックします。
#### リポジトリアクセスの変更
GitHubリポジトリアクセスはいつでも以下の方法で変更できます：
* 同じ`Add GitHub repos`ワークフローを使用する、または
* 設定ページにアクセスし、`Git Settings`セクションの下にある`Configure GitHub Repositories`を選択する。
### GitLab
GitLabアカウントを使用する場合、OpenHandsは自動的にあなたのリポジトリにアクセスできるようになります。
## 会話の保持
- 会話リスト – 過去10日間に開始された最新10件の会話のみが表示されます。
- ワークスペース – 会話ワークスペースは14日間保持されます。
- ランタイム – ランタイムは30分間アクティブ（「ウォーム」）な状態を維持します。この期間後、会話を再開するには1〜2分かかる場合があります。

311
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/configuration-options.md
View File

@ -1,381 +1,342 @@
# 設定オプション
このガイドでは、OpenHandsで利用可能なすべての設定オプションを詳しく説明し、その動作をカスタマイズし、他のサービスと統合するのに役立ちます。
:::note
[GUIモード](https://docs.all-hands.dev/modules/usage/how-to/gui-mode)で実行している場合、設定UIで利用可能な設定が常に優先されます。
このページでは、OpenHandsで利用可能なすべての設定オプションを説明しています。これにより、動作をカスタマイズし、他のサービスと統合することができます。GUIモードでは、設定UI経由で適用された設定が優先されます。
:::
---
## コア設定
# 目次
コア設定オプションは、`config.toml`ファイルの`[core]`セクションで定義されています。
1. [基本設定](#core-configuration)
- [APIキー](#api-keys)
- [ワークスペース](#workspace)
- [デバッグとロギング](#debugging-and-logging)
- [トラジェクトリ](#trajectories)
- [ファイルストア](#file-store)
- [タスク管理](#task-management)
- [サンドボックス設定](#sandbox-configuration)
- [その他](#miscellaneous)
2. [LLM設定](#llm-configuration)
- [AWS認証情報](#aws-credentials)
- [API設定](#api-configuration)
- [カスタムLLMプロバイダー](#custom-llm-provider)
- [埋め込み](#embeddings)
- [メッセージ処理](#message-handling)
- [モデル選択](#model-selection)
- [リトライ](#retrying)
- [詳細オプション](#advanced-options)
3. [エージェント設定](#agent-configuration)
- [メモリ設定](#memory-configuration)
- [LLM設定](#llm-configuration-1)
- [アクションスペース設定](#actionspace-configuration)
- [マイクロエージェントの使用](#microagent-usage)
4. [サンドボックス設定](#sandbox-configuration-1)
- [実行](#execution)
- [コンテナイメージ](#container-image)
- [ネットワーキング](#networking)
- [リンティングとプラグイン](#linting-and-plugins)
- [依存関係と環境](#dependencies-and-environment)
- [評価](#evaluation)
5. [セキュリティ設定](#security-configuration)
- [確認モード](#confirmation-mode)
- [セキュリティアナライザー](#security-analyzer)
---
## 基本設定
基本設定オプションは`config.toml`ファイルの`[core]`セクションで定義されます。
**APIキー**
### APIキー
- `e2b_api_key`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: E2BのAPIキー
- `modal_api_token_id`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: ModalのAPIトークンID
- `modal_api_token_secret`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: ModalのAPIトークンシークレット
**ワークスペース**
- `workspace_base`
### ワークスペース
- `workspace_base` **(非推奨)**
- 型: `str`
- デフォルト値: `"./workspace"`
- 説明: ワークスペースのベースパス
- デフォルト: `"./workspace"`
- 説明: ワークスペースのベースパス。**非推奨: 代わりに`SANDBOX_VOLUMES`を使用してください。**
- `cache_dir`
- 型: `str`
- デフォルト値: `"/tmp/cache"`
- デフォルト: `"/tmp/cache"`
- 説明: キャッシュディレクトリのパス
**デバッグとロギング**
### デバッグとロギング
- `debug`
- 型: `bool`
- デフォルト値: `false`
- デフォルト: `false`
- 説明: デバッグを有効にする
- `disable_color`
- 型: `bool`
- デフォルト値: `false`
- 説明: ターミナル出力のカラー表示を無効にする
- デフォルト: `false`
- 説明: ターミナル出力の色を無効にする
**トラジェクトリ**
### トラジェクトリ
- `save_trajectory_path`
- 型: `str`
- デフォルト値: `"./trajectories"`
- 説明: トラジェクトリを保存するパス（フォルダまたはファイル）。フォルダの場合、トラジェクトリはセッションIDと.json拡張子を持つファイルとしてそのフォルダに保存されます。
- デフォルト: `"./trajectories"`
- 説明: トラジェクトリを保存するパス（フォルダまたはファイル）。フォルダの場合、トラジェクトリはセッションID名と.json拡張子を持つファイルにそのフォルダ内に保存されます。
**ファイルストア**
- `replay_trajectory_path`
- 型: `str`
- デフォルト: `""`
- 説明: トラジェクトリをロードして再生するためのパス。指定する場合は、JSON形式のトラジェクトリファイルへのパスである必要があります。トラジェクトリファイル内のアクションは、ユーザー指示が実行される前に最初に再生されます。
### ファイルストア
- `file_store_path`
- 型: `str`
- デフォルト値: `"/tmp/file_store"`
- デフォルト: `"/tmp/file_store"`
- 説明: ファイルストアのパス
- `file_store`
- 型: `str`
- デフォルト値: `"memory"`
- デフォルト: `"memory"`
- 説明: ファイルストアのタイプ
- `file_uploads_allowed_extensions`
- 型: `list of str`
- デフォルト値: `[".*"]`
- 説明: アップロードを許可するファイル拡張子のリスト
- デフォルト: `[".*"]`
- 説明: アップロード可能なファイル拡張子のリスト
- `file_uploads_max_file_size_mb`
- 型: `int`
- デフォルト値: `0`
- 説明: アップロードの最大ファイルサイズ（メガバイト）
- デフォルト: `0`
- 説明: アップロードの最大ファイルサイズ（メガバイト単位）
- `file_uploads_restrict_file_types`
- 型: `bool`
- デフォルト値: `false`
- デフォルト: `false`
- 説明: ファイルアップロードのファイルタイプを制限する
**タスク管理**
- `file_uploads_allowed_extensions`
- 型: `list of str`
- デフォルト: `[".*"]`
- 説明: アップロード可能なファイル拡張子のリスト
### タスク管理
- `max_budget_per_task`
- 型: `float`
- デフォルト値: `0.0`
- 説明: タスクごとの最大予算（0.0は制限なし）
- デフォルト: `0.0`
- 説明: タスクごとの最大予算（0.0は制限なしを意味します）
- `max_iterations`
- 型: `int`
- デフォルト値: `100`
- 説明: 最大イテレーション数
- デフォルト: `100`
- 説明: 最大反復回数
**サンドボックス設定**
- `workspace_mount_path_in_sandbox`
### サンドボックス設定
- `volumes`
- 型: `str`
- デフォルト値: `"/workspace"`
- 説明: サンドボックス内のワークスペースマウントパス
- デフォルト: `None`
- 説明: 'host_path:container_path[:mode]'形式のボリュームマウント。例：'/my/host/dir:/workspace:rw'。複数のマウントはカンマで区切って指定できます。例：'/path1:/workspace/path1,/path2:/workspace/path2:ro'
- `workspace_mount_path`
- `workspace_mount_path_in_sandbox` **(非推奨)**
- 型: `str`
- デフォルト値: `""`
- 説明: ワークスペースマウントパス
- デフォルト: `"/workspace"`
- 説明: サンドボックス内にワークスペースをマウントするパス。**非推奨: 代わりに`SANDBOX_VOLUMES`を使用してください。**
- `workspace_mount_rewrite`
- `workspace_mount_path` **(非推奨)**
- 型: `str`
- デフォルト値: `""`
- 説明: ワークスペースマウントパスを書き換えるパス。通常は無視できます。別のコンテナ内での実行の特殊なケースを参照します。
- デフォルト: `""`
- 説明: ワークスペースをマウントするパス。**非推奨: 代わりに`SANDBOX_VOLUMES`を使用してください。**
**その他**
- `workspace_mount_rewrite` **(非推奨)**
- 型: `str`
- デフォルト: `""`
- 説明: ワークスペースマウントパスを書き換えるパス。通常は無視できます。別のコンテナ内で実行する特殊なケースを指します。**非推奨: 代わりに`SANDBOX_VOLUMES`を使用してください。**
### その他
- `run_as_openhands`
- 型: `bool`
- デフォルト値: `true`
- デフォルト: `true`
- 説明: OpenHandsとして実行する
- `runtime`
- 型: `str`
- デフォルト値: `"docker"`
- 説明: 実行環境
- デフォルト: `"docker"`
- 説明: ランタイム環境
- `default_agent`
- 型: `str`
- デフォルト値: `"CodeActAgent"`
- 説明: デフォルトのエージェント名
- デフォルト: `"CodeActAgent"`
- 説明: デフォルトエージェントの名前
- `jwt_secret`
- 型: `str`
- デフォルト値: `uuid.uuid4().hex`
- デフォルト: `uuid.uuid4().hex`
- 説明: 認証用のJWTシークレット。独自の値に設定してください。
## LLM設定
LLM（大規模言語モデル）設定オプションは`config.toml`ファイルの`[llm]`セクションで定義されます。
LLM（大規模言語モデル）設定オプションは、`config.toml`ファイルの`[llm]`セクションで定義されています。
dockerコマンドで使用する場合は、`-e LLM_<option>`として渡します。例：`-e LLM_NUM_RETRIES`
これらをdockerコマンドで使用するには、`-e LLM_<option>`を渡します。例：`-e LLM_NUM_RETRIES`。
:::note
開発設定では、カスタムLLM設定も定義できます。詳細は[カスタムLLM設定](./llms/custom-llm-configs)を参照してください。
開発セットアップでは、カスタム名前付きLLM設定を定義することもできます。詳細は[カスタムLLM設定](./llms/custom-llm-configs)を参照してください。
:::
**AWS認証情報**
- `aws_access_key_id`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: AWSアクセスキーID
- `aws_region_name`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: AWSリージョン名
- `aws_secret_access_key`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: AWSシークレットアクセスキー
**API設定**
### API設定
- `api_key`
- 型: `str`
- デフォルト値: `None`
- デフォルト: `None`
- 説明: 使用するAPIキー
- `base_url`
- 型: `str`
- デフォルト値: `""`
- 説明: APIのベースURL
- デフォルト: `""`
- 説明: APIベースURL
- `api_version`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: APIバージョン
- `input_cost_per_token`
- 型: `float`
- デフォルト値: `0.0`
- デフォルト: `0.0`
- 説明: 入力トークンあたりのコスト
- `output_cost_per_token`
- 型: `float`
- デフォルト値: `0.0`
- デフォルト: `0.0`
- 説明: 出力トークンあたりのコスト
**カスタムLLMプロバイダー**
### カスタムLLMプロバイダー
- `custom_llm_provider`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: カスタムLLMプロバイダー
**埋め込み**
- `embedding_base_url`
- 型: `str`
- デフォルト値: `""`
- 説明: 埋め込みAPIのベースURL
- `embedding_deployment_name`
- 型: `str`
- デフォルト値: `""`
- 説明: 埋め込みデプロイメント名
- `embedding_model`
- 型: `str`
- デフォルト値: `"local"`
- 説明: 使用する埋め込みモデル
**メッセージ処理**
### メッセージ処理
- `max_message_chars`
- 型: `int`
- デフォルト値: `30000`
- 説明: LLMプロンプトに含まれるイベントコンテンツの最大文字数（概算）。より大きな観察は切り捨てられます。
- デフォルト: `30000`
- 説明: LLMへのプロンプトに含まれるイベントのコンテンツの最大文字数（概算）。より大きな観測は切り捨てられます。
- `max_input_tokens`
- 型: `int`
- デフォルト値: `0`
- デフォルト: `0`
- 説明: 最大入力トークン数
- `max_output_tokens`
- 型: `int`
- デフォルト値: `0`
- デフォルト: `0`
- 説明: 最大出力トークン数
**モデル選択**
### モデル選択
- `model`
- 型: `str`
- デフォルト値: `"claude-3-5-sonnet-20241022"`
- デフォルト: `"claude-3-5-sonnet-20241022"`
- 説明: 使用するモデル
**リトライ**
### リトライ
- `num_retries`
- 型: `int`
- デフォルト値: `8`
- 説明: リトライ回数
- デフォルト: `8`
- 説明: 試行するリトライ回数
- `retry_max_wait`
- 型: `int`
- デフォルト値: `120`
- 説明: リトライ間の最大待機時間（秒）
- デフォルト: `120`
- 説明: リトライ試行間の最大待機時間（秒）
- `retry_min_wait`
- 型: `int`
- デフォルト値: `15`
- 説明: リトライ間の最小待機時間（秒）
- デフォルト: `15`
- 説明: リトライ試行間の最小待機時間（秒）
- `retry_multiplier`
- 型: `float`
- デフォルト値: `2.0`
- デフォルト: `2.0`
- 説明: 指数バックオフ計算の乗数
**詳細オプション**
### 高度なオプション
- `drop_params`
- 型: `bool`
- デフォルト値: `false`
- デフォルト: `false`
- 説明: マッピングされていない（サポートされていない）パラメータを例外を発生させずに削除する
- `caching_prompt`
- 型: `bool`
- デフォルト値: `true`
- デフォルト: `true`
- 説明: LLMによって提供され、サポートされている場合、プロンプトキャッシュ機能を使用する
- `ollama_base_url`
- 型: `str`
- デフォルト値: `""`
- デフォルト: `""`
- 説明: OLLAMA APIのベースURL
- `temperature`
- 型: `float`
- デフォルト値: `0.0`
- 説明: APIの温度パラメータ
- デフォルト: `0.0`
- 説明: APIの温度
- `timeout`
- 型: `int`
- デフォルト値: `0`
- デフォルト: `0`
- 説明: APIのタイムアウト
- `top_p`
- 型: `float`
- デフォルト値: `1.0`
- 説明: APIのtop_pパラメータ
- デフォルト: `1.0`
- 説明: APIのtop p
- `disable_vision`
- 型: `bool`
- デフォルト値: `None`
- 説明: モデルがビジョン機能を持つ場合、この設定で画像処理を無効にできます（コスト削減に有用）
- デフォルト: `None`
- 説明: モデルがビジョン対応の場合、このオプションで画像処理を無効にできます（コスト削減に役立ちます）
## エージェント設定
エージェント設定オプションは`config.toml`ファイルの`[agent]`および`[agent.<agent_name>]`セクションで定義されます。
エージェント設定オプションは、`config.toml`ファイルの`[agent]`および`[agent.<agent_name>]`セクションで定義されています。
**メモリ設定**
- `memory_enabled`
- 型: `bool`
- デフォルト値: `false`
- 説明: 長期メモリ（埋め込み）が有効かどうか
- `memory_max_threads`
- 型: `int`
- デフォルト値: `3`
- 説明: 埋め込みのために同時にインデックスを作成する最大スレッド数
**LLM設定**
### LLM設定
- `llm_config`
- 型: `str`
- デフォルト値: `'your-llm-config-group'`
- デフォルト: `'your-llm-config-group'`
- 説明: 使用するLLM設定の名前
**アクションスペース設定**
### ActionSpace設定
- `function_calling`
- 型: `bool`
- デフォルト値: `true`
- デフォルト: `true`
- 説明: 関数呼び出しが有効かどうか
- `enable_browsing`
- 型: `bool`
- デフォルト値: `false`
- 説明: アクションスペースでブラウジングデリゲートが有効かどうか（関数呼び出しでのみ機能）
- デフォルト: `false`
- 説明: アクションスペースでブラウジングデリゲートが有効かどうか（関数呼び出しでのみ機能します）
- `enable_llm_editor`
- 型: `bool`
- デフォルト値: `false`
- 説明: アクションスペースでLLMエディタが有効かどうか（関数呼び出しでのみ機能）
- デフォルト: `false`
- 説明: アクションスペースでLLMエディタが有効かどうか（関数呼び出しでのみ機能します）
**マイクロエージェントの使用**
- `enable_jupyter`
- 型: `bool`
- デフォルト: `false`
- 説明: アクションスペースでJupyterが有効かどうか
- `enable_history_truncation`
- 型: `bool`
- デフォルト: `true`
- 説明: LLMコンテキスト長の制限に達したときにセッションを続行するために履歴を切り詰めるかどうか
### マイクロエージェントの使用
- `enable_prompt_extensions`
- 型: `bool`
- デフォルト値: `true`
- 説明: マイクロエージェントの使用が有効かどうか
- デフォルト: `true`
- 説明: マイクロエージェントを使用するかどうか
- `disabled_microagents`
- 型: `list of str`
- デフォルト値: `None`
- デフォルト: `None`
- 説明: 無効にするマイクロエージェントのリスト
## サンドボックス設定
サンドボックス設定オプションは、`config.toml`ファイルの`[sandbox]`セクションで定義されています。
これらをdockerコマンドで使用するには、`-e SANDBOX_<option>`を渡します。例：`-e SANDBOX_TIMEOUT`。
### 実行
- `timeout`
- 型: `int`
- デフォルト値: `120`
- デフォルト: `120`
- 説明: サンドボックスのタイムアウト（秒）
- `user_id`
- 型: `int`
- デフォルト値: `1000`
- 説明: サンドボックスのユーザーID
- デフォルト: `1000`

21
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/customization/repository.md Normal file
View File

@ -0,0 +1,21 @@
# リポジトリのカスタマイズ
リポジトリのルートレベルに `.openhands` ディレクトリを作成することで、OpenHandsがあなたのリポジトリとどのように連携するかをカスタマイズできます。
## マイクロエージェント
マイクロエージェントを使用すると、OpenHandsのプロンプトをプロジェクト固有の情報で拡張し、OpenHandsがどのように機能するかを定義できます。詳細については[マイクロエージェントの概要](../prompting/microagents-overview)をご覧ください。
## セットアップスクリプト
`.openhands/setup.sh` ファイルを追加すると、OpenHandsがあなたのリポジトリで作業を開始するたびに実行されます。
これは依存関係のインストール、環境変数の設定、その他のセットアップタスクを実行するための理想的な場所です。
例えば：
```bash
#!/bin/bash
export MY_ENV_VAR="my value"
sudo apt-get update
sudo apt-get install -y lsof
cd frontend && npm install ; cd ..
```

35
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/feedback.md
View File

@ -1,10 +1,10 @@
# ✅ フィードバックの提供
OpenHandsを使用する際、うまくいく場合もあれば、そうでない場合もあります。開発チームにフィードバックを提供し、おそらくより重要なことですが、コーディングエージェントのトレーニング例のオープンなコーパスを作成するために、OpenHandsを使用する際にフィードバックを提供することをお勧めします -- Share-OpenHands!
OpenHandsを使用する際、うまく機能する場合と機能しない場合があります。OpenHandsを使用する際にフィードバックを提供することで、開発チームにフィードバックを与え、さらに重要なことに、コーディングエージェントのトレーニング例のオープンコーパスを作成することを奨励します - Share-OpenHands！
## 📝 フィードバックの提供方法
フィードバックの提供は簡単です! OpenHandsを使用している際、インタラクションの任意のポイントで親指を上または下に向けるボタンを押すことができます。メールアドレスの入力を求められます (例: フォローアップの質問をしたい場合に連絡できるように)。また、フィードバックを公開するか非公開にするかを選択できます。
フィードバックの提供は簡単です！OpenHandsを使用している際、対話中のどの時点でも親指を上げるボタンまたは親指を下げるボタンを押すことができます。メールアドレスの入力を求められます（例：追加の質問がある場合に連絡できるように）、そしてフィードバックを公開するか非公開にするかを選択できます。
<iframe width="560" height="315" src="https://www.youtube.com/embed/5rFx-StMVV0?si=svo7xzp6LhGK_GXr" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
@ -12,29 +12,28 @@ OpenHandsを使用する際、うまくいく場合もあれば、そうでな
### データ共有設定
データを送信する際、公開または非公開で送信できます。
データを提出する際、公開または非公開で提出することができます。
- **公開**データは、OpenHands自体と同様にMITライセンスの下で配布され、コミュニティがモデルのトレーニングとテストに使用できます。明らかに、公開できるフィードバックは、コミュニティ全体にとってより価値があるでしょう。機密情報を扱っていない場合は、このオプションを選択することをお勧めします!
- **非公開**データは、OpenHandsの改善を目的としてOpenHandsチームが利用できるようになります。ただし、一意のIDを持つリンクが作成され、他の人と公開で共有できます。
- **公開**データはOpenHands自体と同様にMITライセンスの下で配布され、コミュニティがモデルのトレーニングとテストに使用できます。明らかに、公開できるフィードバックはコミュニティ全体にとってより価値があるため、機密情報を扱っていない場合は、このオプションを選択することをお勧めします！
- **非公開**データはOpenHandsの改善を目的としてOpenHandsチームが利用できるようになります。ただし、他の人と公開して共有できる一意のIDを持つリンクは引き続き作成されます。
### データの収集と保存は誰が行うのか?
### 誰がデータを収集・保存するのか？
データは、OpenHandsのメンテナーによって設立されたOpenHandsのサポートと改善を目的とする企業である[All Hands AI](https://all-hands.dev)によって収集および保存されます。
データはOpenHandsのメンテナーによって設立された[All Hands AI](https://all-hands.dev)という会社によって収集・保存されます。この会社はOpenHandsをサポートし改善するために設立されました。
### 公開データはどのようにリリースされるのか?
### 公開データはどのようにリリースされますか？
公開データは、1,000件の公開例、10,000件の公開例などの固定されたマイルストーンに達した時点でリリースされます。
その際、以下のリリースプロセスに従います:
公開データは、1,000件の公開例、10,000件の公開例など、固定のマイルストーンに達した時点でリリースされます。
この時点で、以下のリリースプロセスに従います：
1. 公開フィードバックを提供したすべての人に、データのリリースについて説明し、オプトアウトする機会を与えるメールが送信されます。
2. データリリースを担当する人は、データの品質管理を行い、低品質のフィードバックを削除し、
提出者のメールアドレスを削除し、機密情報を削除するよう試みます。
3. データは、GitHubやHugging Faceなどの一般的に使用されているサイトを通じて、MITライセンスの下で公開されます。
1. 公開フィードバックを提供したすべての人にデータリリースについて説明し、オプトアウトの機会を与えるメールが送信されます。
2. データリリースを担当する人物は、低品質のフィードバックの削除、提出者のメールアドレスの削除、機密情報の削除を試みるなど、データの品質管理を行います。
3. データはMITライセンスの下でGitHubやHugging Faceなどの一般的に使用されているサイトを通じて公開されます。
### データを削除したい場合はどうすればよいですか?
### データの削除を希望する場合はどうすればよいですか？
All Hands AIのサーバー上のデータについては、リクエストに応じて削除いたします:
All Hands AIのサーバー上のデータについては、リクエストに応じて喜んで削除します：
**1つのデータ:** 1つのデータを削除したい場合、データ送信時にインターフェイスに表示されるリンクとパスワードを使用してデータを削除するメカニズムを近日中に追加する予定です。
**1つのデータ：** 1つのデータの削除を希望する場合、近日中にデータを提出した際にインターフェースに表示されるリンクとパスワードを使用してデータを削除するメカニズムを追加する予定です。
**すべてのデータ:** すべてのデータを削除したい場合、またはデータ送信時に受け取ったIDとパスワードがない場合は、元のデータ送信時に登録したメールアドレスから`contact@all-hands.dev`までご連絡ください。
**すべてのデータ：** すべてのデータの削除を希望する場合、またはデータ提出時に受け取ったIDとパスワードをお持ちでない場合は、データを最初に提出した際に登録したメールアドレスから`contact@all-hands.dev`にお問い合わせください。

105
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/getting-started.mdx
View File

@ -1,108 +1,93 @@
# OpenHandsを始める
[OpenHandsをインストール](./installation)し、[LLMを設定](./installation#setup)しました。次は何をしましょうか？
[OpenHandsを実行](./installation)して、
[LLMをセットアップ](./installation#setup)しました。次は何をしますか？
OpenHandsは、さまざまなエンジニアリングタスクを支援できます。しかし、この技術はまだ新しく、
エージェントが支援なしで広範で複雑なエンジニアリングタスクを処理できるようになるまでには時間がかかります。
そのため、エージェントが得意とすることと、支援が必要な部分を理解することが重要です。
OpenHandsはさまざまなエンジニアリングタスクを支援できます。しかし、この技術はまだ新しく、複雑なタスクを独立して処理できるエージェントの実現にはまだ遠い道のりがあります。エージェントが得意とすることと、サポートが必要な部分を理解することが重要です。
## Hello World
最初に試してみたいのは、シンプルな「hello world」の例かもしれません。
これは見た目以上に複雑になる可能性があります！
まずは簡単な「hello world」の例から始めましょう。思ったより難しいかもしれません！
エージェントに以下のように依頼してみてください：
> "hello world!"と表示するbashスクリプトhello.shを作成してください
エージェントに次のようにプロンプトしてみましょう：
> 「hello world!」と表示するbashスクリプトhello.shを書いてください
エージェントがスクリプトを作成するだけでなく、適切な権限を設定し、
スクリプトを実行して出力を確認することに気付くでしょう。
エージェントはスクリプトを作成し、適切な権限を設定し、実行して出力を確認します。
エージェントにコードの改良を続けて依頼することもできます。これはエージェントと
作業する優れた方法です。シンプルに始めて、反復的に改良していきます。
コードを改良するためにエージェントにさらにプロンプトを続けることができます。これはエージェントと作業する素晴らしい方法です。シンプルに始めて、反復していきましょう。
> hello.shを修正して、最初の引数として名前を受け取るようにしてください。デフォルトは"world"にしてください
> hello.shを修正して、最初の引数として名前を受け取るようにしてください。ただし、デフォルトは「world」にしてください
また、エージェントが環境のセットアップに時間を要する可能性はありますが、
必要な任意の言語で作業することができます！
また、必要な言語を使用することもできます。エージェントは環境のセットアップに時間がかかる場合があります。
> hello.shをRubyスクリプトに変換して実行してください
> hello.shをRubyスクリプトに変換して、実行してください
## ゼロからの構築
エージェントは、「グリーンフィールド」タスク（既存のコードベースに関する文脈を必要としないタスク）で
特に優れた性能を発揮し、ゼロから始めることができます。
エージェントは「グリーンフィールド」タスク、つまり既存のコードについてのコンテキストが不要で、
ゼロから始められるタスクに優れています。
シンプルなタスクから始めて、そこから反復していきましょう。欲しいものと技術スタックについて具体的に指示しましょう。
シンプルなタスクから始めて、反復的に改良していくのがベストです。また、
要望する内容、使用する技術スタックなどについて、できるだけ具体的に指定することをお勧めします。
例えば、TODOアプリを構築するとします：
例えば、TODOアプリケーションを構築できます：
> フロントエンドのみのTODOアプリをReactで構築してください。すべての状態はlocalStorageに保存してください。
> フロントエンドのみのReactベースの基本的なTODOリストアプリケーションを作成してください。
> すべての状態はlocalStorageに保存してください。
基本的な構造ができたら、さらに改良を続けます：
基本的な構造ができたら、アプリケーションの改良を続けることができます：
> 各タスクにオプションの期限を追加できるようにしてください。
> 各タスクにオプションの期限を追加できるようにしてください
通常の開発と同様に、頻繁にコミットとプッシュを行うことをお勧めします。
これにより、エージェントが予期せぬ方向に進んだ場合でも、以前の状態に戻ることができます。
通常の開発と同様に、コードを頻繁にコミットしてプッシュしましょう。
これにより、エージェントが道を外れた場合でも、常に古い状態に戻すことができます。
エージェントにコミットとプッシュを依頼することもできます：
> 変更をコミットして、"feature/due-dates"という新しいブランチにプッシュしてください
> 変更をコミットして、「feature/due-dates」という新しいブランチにプッシュしてください
## 新しいコードの追加
OpenHandsは、既存のコードベースに新しいコードを追加する作業も優れています。
OpenHandsは既存のコードベースに新しいコードを追加するのに優れています。
例えば、OpenHandsにコードを分析するGitHubアクションをプロジェクトに追加するよう依頼できます。
OpenHandsはコードベースを確認して使用すべき言語を判断し、新しいファイルを
`./github/workflows/lint.yml`に作成できます。
例えば、コードをリントするGitHub actionを追加するようOpenHandsに依頼できます。言語を判断するためにコードベースをチェックし、`./github/workflows/lint.yml`に新しいファイルを作成するかもしれません。
> このリポジトリのコードを分析するGitHubアクションを追加してください
> このリポジトリのコードをリントするGitHub actionを追加してください。
一部のタスクではより多くの文脈が必要かもしれません。OpenHandsは`ls`や`grep`を使用して
コードベースを検索できますが、事前に文脈を提供することで、より速く、より正確に作業を
進めることができます。また、トークンの消費も少なくなります！
一部のタスクにはより多くのコンテキストが必要です。OpenHandsはlsやgrepなどのコマンドを使用して検索できますが、前もってコンテキストを提供することで作業が速くなり、トークンの使用量が減ります。
> ./backend/api/routes.jsを修正して、すべてのタスクのリストを返す新しいルートを追加してください
> ./backend/api/routes.jsを修正して、すべてのタスクのリストを返す新しいルートを追加してください。
> ./frontend/componentsディレクトリにWidgetのリストを表示する新しいReactコンポーネントを追加してください。
> ./frontend/componentsディレクトリに、Widgetのリストを表示する新しいReactコンポーネントを追加してください。
> 既存のWidgetコンポーネントを使用する必要があります。
## リファクタリング
OpenHandsは、特に小規模な既存コードのリファクタリングに優れています。
コードベース全体のアーキテクチャを変更しようとするのは避けた方がよいですが、
長いファイルや関数の分割、変数名の変更などは非常にうまく機能する傾向があります。
OpenHandsは小さな単位でのコードリファクタリングに優れています。コードベース全体を再設計するよりも、
長いファイルや関数を分割したり、変数名を変更したりする方が効果的です。
> ./app.goの1文字の変数名をすべて変更してください
> ./app.goの一文字変数をすべて改名してください。
> widget.phpの`build_and_deploy_widgets`関数を`build_widgets`と`deploy_widgets`の2つの関数に分割してください
> widget.phpの`build_and_deploy_widgets`関数を`build_widgets`と`deploy_widgets`の2つの関数に分割してください。
> ./api/routes.jsを各ルートごとの別々のファイルに分割してください
> ./api/routes.jsを各ルートごとに別々のファイルに分割してください。
## バグ修正
OpenHandsは、コードのバグの追跡と修正も支援できます。しかし、すべての
開発者が知っているように、バグ修正は非常に繊細な作業になる可能性があり、多くの場合OpenHandsはより多くの文脈を
必要とします。バグを診断済みで、OpenHandsにロジックを理解してもらいたい場合に特に役立ちます。
OpenHandsはバグの追跡と修正を支援できますが、バグ修正は難しく、多くの場合より多くのコンテキストが必要です。
すでに問題を診断していて、OpenHandsにロジックを処理してもらうだけの場合は役立ちます。
> 現在、`/subscribe`エンドポイントのemailフィールドが.ioドメインを拒否しています。これを修正してください。
> `/subscribe`エンドポイントのメールフィールドが.ioドメインを拒否しています。これを修正してください。
> ./app.pyの`search_widgets`関数が大文字小文字を区別して検索を行っています。大文字小文字を区別しないように修正してください。
> ./app.pyの`search_widgets`関数が大文字と小文字を区別する検索を行っています。大文字と小文字を区別しないようにしてください。
エージェントとバグを修正する際は、テスト駆動開発を行うと便利なことが多いです。
エージェントに新しいテストを書かせ、バグが修正されるまで反復することができます：
バグ修正には、テスト駆動開発が非常に役立ちます。エージェントに新しいテストを書いてもらい、バグが修正されるまで反復することができます：
> `hello`関数が空文字列でクラッシュします。このバグを再現するテストを書いて、コードを修正してテストが通るようにしてください。
> `hello`関数が空の文字列でクラッシュします。このバグを再現するテストを書いて、コードを修正してテストに合格するようにしてください。
## その他
OpenHandsは、ほぼすべてのコーディングタスクを支援できます。しかし、最大限に
活用するには練習が必要です。以下の点を忘れないでください：
* タスクを小さく保つ
* できるだけ具体的に指定する
* できるだけ多くの文脈を提供する
* 頻繁にコミットとプッシュを行う
OpenHandsはほぼすべてのコーディングタスクを支援できますが、最良の結果を得るには練習が必要です。
以下のヒントを心に留めておきましょう：
* タスクを小さく保つ。
* 具体的に指示する。
* 十分なコンテキストを提供する。
* 頻繁にコミットしてプッシュする。
OpenHandsを最大限に活用する方法についての詳細なアドバイスは、[プロンプトのベストプラクティス](./prompting/prompting-best-practices)をご覧ください。
OpenHandsを最大限に活用する方法についての詳細は、[プロンプトのベストプラクティス](./prompting/prompting-best-practices)をご覧ください。

83
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/cli-mode.md
View File

@ -1,45 +1,46 @@
# CLI モード
# CLIモード
OpenHands は対話型の CLI モードで実行できます。これにより、ユーザーはコマンドラインから対話型セッションを開始できます。
OpenHandsは対話型CLIモードで実行でき、コマンドラインを通じて対話型セッションを開始することができます。
このモードは、非対話型でスクリプティングに適した [ヘッドレスモード](headless-mode) とは異なります。
このモードは[ヘッドレスモード](headless-mode)とは異なり、対話型であり、スクリプト実行よりもユーザー操作に適しています。
## Python を使用する場合
## Pythonでの実行
コマンドラインから対話型の OpenHands セッションを開始するには:
コマンドラインから対話型OpenHandsセッションを開始するには：
1. [開発セットアップの手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) に従っていることを確認してください。
2. 以下のコマンドを実行します:
1. [開発環境セットアップ手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)に従っていることを確認してください。
2. 以下のコマンドを実行します：
```bash
poetry run python -m openhands.core.cli
```
このコマンドを実行すると、タスクを入力して OpenHands からレスポンスを受け取ることができる対話型セッションが開始されます。
このコマンドは対話型セッションを開始し、タスクを入力してOpenHandsからの応答を受け取ることができます。
環境変数 [または `config.toml` ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml) を使用して、モデル、API キー、その他の設定を確実に設定する必要があります。
環境変数または[`config.toml`ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を通じて、モデル、APIキー、その他の設定を確実に設定する必要があります。
## Docker を使用する場合
## Dockerでの実行
Docker で OpenHands を CLI モードで実行するには:
DockerでOpenHandsをCLIモードで実行するには：
1. ターミナルで以下の環境変数を設定します:
1. ターミナルで以下の環境変数を設定します：
- `WORKSPACE_BASE` を OpenHands に編集させたいディレクトリに設定 (例: `export WORKSPACE_BASE=$(pwd)/workspace`)。
- `LLM_MODEL` を使用するモデルに設定 (例: `export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`)。
- `LLM_API_KEY` を API キーに設定 (例: `export LLM_API_KEY="sk_test_12345"`)。
- `SANDBOX_VOLUMES`でOpenHandsがアクセスするディレクトリを指定します（例：`export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw`）。
- エージェントはデフォルトで`/workspace`で動作するため、エージェントにファイルを変更させたい場合はプロジェクトディレクトリをそこにマウントします。
- 読み取り専用データの場合は、異なるマウントパスを使用します（例：`export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw,/path/to/large/dataset:/data:ro`）。
- `LLM_MODEL`に使用するモデルを設定します（例：`export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`）。
- `LLM_API_KEY`にAPIキーを設定します（例：`export LLM_API_KEY="sk_test_12345"`）。
2. 以下の Docker コマンドを実行します:
2. 以下のDockerコマンドを実行します：
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
@ -48,48 +49,6 @@ docker run -it \
python -m openhands.core.cli
```
このコマンドを実行すると、Docker 内で対話型セッションが開始され、タスクを入力して OpenHands からレスポンスを受け取ることができます。
このコマンドはDocker内で対話型セッションを開始し、タスクを入力してOpenHandsからの応答を受け取ることができます。
## CLI コマンドと期待される出力の例
CLI コマンドとその期待される出力の例を以下に示します:
### 例1: シンプルなタスク
```bash
>> "Hello, World!" と出力する Python スクリプトを書いてください
```
期待される出力:
```bash
🤖 はい! "Hello, World!" と出力する Python スクリプトは以下のようになります:
❯ print("Hello, World!")
```
### 例2: Bash コマンド
```bash
>> "test_dir" という名前のディレクトリを作成してください
```
期待される出力:
```bash
🤖 "test_dir" という名前のディレクトリを作成します:
❯ mkdir test_dir
```
### 例3: エラー処理
```bash
>> 存在しないファイルを削除してください
```
期待される出力:
```bash
🤖 エラーが発生しました。もう一度お試しください。
```
`-e SANDBOX_USER_ID=$(id -u)`はDockerコマンドに渡され、サンドボックスユーザーがホストユーザーの権限と一致するようにします。これにより、エージェントがマウントされたワークスペースにroot所有のファイルを作成するのを防ぎます。

53
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/custom-sandbox-guide.md
View File

@ -1,21 +1,29 @@
# カスタムサンドボックス
サンドボックスは、エージェントがタスクを実行する場所です。コンピュータ上で直接コマンドを実行する（これはリスクがある可能性があります）代わりに、エージェントはDockerコンテナ内でそれらを実行します。
:::note
このガイドは、ランタイム用に独自のカスタムDockerイメージを使用したいユーザー向けです。例えば、
特定のツールやプログラミング言語があらかじめインストールされているものなどです。
:::
デフォルトのOpenHandsサンドボックス（[nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)の`python-nodejs:python3.12-nodejs22`）にはPythonやNode.jsなどのパッケージがインストールされていますが、デフォルトでインストールする必要のある他のソフトウェアがある場合があります。
サンドボックスはエージェントがタスクを実行する場所です。コマンドをあなたのコンピュータで直接実行する
（これはリスクがあります）代わりに、エージェントはDockerコンテナ内でコマンドを実行します。
カスタマイズには2つのオプションがあります:
デフォルトのOpenHandsサンドボックス（[nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)から
`python-nodejs:python3.12-nodejs22`）にはpythonやNode.jsなどのパッケージがインストールされていますが、
他のソフトウェアをデフォルトでインストールする必要がある場合があります。
- 必要なソフトウェアがインストールされている既存のイメージを使用する。
カスタマイズには2つの選択肢があります：
- 必要なソフトウェアがインストールされた既存のイメージを使用する。
- 独自のカスタムDockerイメージを作成する。
最初のオプションを選択した場合は、`Dockerイメージの作成`セクションをスキップできます。
最初の選択肢を選ぶ場合は、「Dockerイメージの作成」セクションをスキップできます。
## Dockerイメージの作成
カスタムDockerイメージを作成するには、Debianベースである必要があります。
たとえば、OpenHandsに`ruby`をインストールしたい場合は、次の内容で`Dockerfile`を作成できます:
例えば、OpenHandsに`ruby`をインストールしたい場合、以下の内容で`Dockerfile`を作成できます：
```dockerfile
FROM nikolaik/python-nodejs:python3.12-nodejs22
@ -24,23 +32,23 @@ FROM nikolaik/python-nodejs:python3.12-nodejs22
RUN apt-get update && apt-get install -y ruby
```
または、Ruby固有のベースイメージを使用することもできます:
または、Rubyに特化したベースイメージを使用することもできます：
```dockerfile
FROM ruby:latest
```
このファイルをフォルダに保存します。次に、ターミナルでフォルダに移動し、次のコマンドを実行して、Dockerイメージ（たとえば、custom-imageという名前）をビルドします:
このファイルをフォルダに保存します。次に、ターミナルでそのフォルダに移動し、以下のコマンドを実行してDockerイメージ（例：custom-image）をビルドします：
```bash
docker build -t custom-image .
```
これにより、`custom-image`という新しいイメージが作成され、Dockerで利用できるようになります。
これにより、`custom-image`という名前の新しいイメージが作成され、Docker内で利用可能になります。
## Dockerコマンドの使用
[dockerコマンド](/modules/usage/installation#start-the-app)を使用してOpenHandsを実行する場合は、`-e SANDBOX_RUNTIME_CONTAINER_IMAGE=...`を`-e SANDBOX_BASE_CONTAINER_IMAGE=<カスタムイメージ名>`に置き換えます:
[dockerコマンド](/modules/usage/installation#start-the-app)を使用してOpenHandsを実行する場合、
`-e SANDBOX_RUNTIME_CONTAINER_IMAGE=...`を`-e SANDBOX_BASE_CONTAINER_IMAGE=<カスタムイメージ名>`に置き換えます：
```commandline
docker run -it --rm --pull=always \
@ -52,11 +60,12 @@ docker run -it --rm --pull=always \
### セットアップ
まず、[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の手順に従って、OpenHandsを実行できることを確認してください。
まず、[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の指示に従ってOpenHandsを実行できることを確認してください。
### ベースサンドボックスイメージの指定
OpenHandsディレクトリ内の`config.toml`ファイルで、`base_container_image`を使用するイメージに設定します。これは、すでにプルしたイメージまたは構築したイメージにすることができます:
OpenHandsディレクトリ内の`config.toml`ファイルで、`base_container_image`を使用したいイメージに設定します。
これは既に取得したイメージか、ビルドしたイメージのいずれかです：
```bash
[core]
@ -65,28 +74,28 @@ OpenHandsディレクトリ内の`config.toml`ファイルで、`base_container_
base_container_image="custom-image"
```
### その他の設定オプション
### 追加の設定オプション
`config.toml`ファイルは、サンドボックスをカスタマイズするためのいくつかの他のオプションをサポートしています:
`config.toml`ファイルでは、サンドボックスをカスタマイズするための他のオプションもサポートしています：
```toml
[core]
# ランタイムのビルド時に追加の依存関係をインストールする
# 有効なシェルコマンドを含めることができる
# これらのコマンドのいずれかでPythonインタープリターへのパスが必要な場合は、$OH_INTERPRETER_PATH変数を使用できる
# ランタイムがビルドされるときに追加の依存関係をインストール
# 有効なシェルコマンドを含めることができます
# これらのコマンドでPythonインタプリタのパスが必要な場合は、$OH_INTERPRETER_PATH変数を使用できます
runtime_extra_deps = """
pip install numpy pandas
apt-get update && apt-get install -y ffmpeg
"""
# ランタイムの環境変数を設定する
# ランタイムで使用可能である必要がある設定に役立つ
# ランタイム用の環境変数を設定
# ランタイム時に利用可能にする必要がある設定に役立ちます
runtime_startup_env_vars = { DATABASE_URL = "postgresql://user:pass@localhost/db" }
# マルチアーキテクチャビルドのプラットフォームを指定する（例: "linux/amd64"または"linux/arm64"）
# マルチアーキテクチャビルド用のプラットフォームを指定（例：「linux/amd64」または「linux/arm64」）
platform = "linux/amd64"
```
### 実行
トップレベルのディレクトリで```make run```を実行して、OpenHandsを実行します。
トップレベルディレクトリで```make run```を実行してOpenHandsを起動します。

12
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/debugging.md
View File

@ -1,8 +1,10 @@
以下は、OpenHandsのデバッグに関する入門書です。開発目的で使用してください。
# デバッグ
以下は開発目的のためのOpenHandsのデバッグに関する入門ガイドです。
## サーバー / VSCode
以下の`launch.json`は、エージェント、コントローラー、サーバー要素のデバッグを可能にしますが、サンドボックス（Dockerの中で動作する）はデバッグできません。`workspace/`ディレクトリ内の変更は無視されます。
以下の`launch.json`を使用すると、エージェント、コントローラー、サーバー要素のデバッグが可能になりますが、サンドボックス（Dockerの中で実行される）はデバッグできません。これは`workspace/`ディレクトリ内の変更を無視します：
```
{
@ -34,7 +36,7 @@
}
```
より具体的なデバッグ設定では、より多くのパラメータを指定できます。
より多くのパラメータを含む、より具体的なデバッグ設定を指定することもできます：
```
...
@ -60,10 +62,10 @@
...
```
上記のスニペットの値は、以下のように更新できます。
上記のスニペットの値は以下のように更新できます：
* *t*: タスク
* *d*: openhandsワークスペースディレクトリ
* *c*: エージェント
* *l*: LLM設定（config.tomlで事前定義）
* *n*: セッション名（例：eventstream名）
* *n*: セッション名（例：イベントストリーム名）

74
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/development-overview.md Normal file
View File

@ -0,0 +1,74 @@
---
sidebar_position: 9
---
# 開発概要
このガイドでは、OpenHandsリポジトリで利用可能な主要なドキュメントリソースの概要を提供します。貢献したい、アーキテクチャを理解したい、または特定のコンポーネントに取り組みたいと考えている場合でも、これらのリソースはコードベースを効果的に操作するのに役立ちます。
## コアドキュメント
### プロジェクトの基本
- **メインプロジェクト概要** (`/README.md`)
OpenHandsを理解するための主要なエントリーポイントで、機能と基本的なセットアップ手順が含まれています。
- **開発ガイド** (`/Development.md`)
OpenHandsに取り組む開発者向けの包括的なガイドで、セットアップ、要件、開発ワークフローが含まれています。
- **貢献ガイドライン** (`/CONTRIBUTING.md`)
貢献者向けの重要な情報で、コードスタイル、PRプロセス、貢献ワークフローをカバーしています。
### コンポーネントドキュメント
#### フロントエンド
- **フロントエンドアプリケーション** (`/frontend/README.md`)
Reactベースのフロントエンドアプリケーションのセットアップと開発のための完全なガイド。
#### バックエンド
- **バックエンド実装** (`/openhands/README.md`)
Pythonバックエンドの実装とアーキテクチャに関する詳細なドキュメント。
- **サーバードキュメント** (`/openhands/server/README.md`)
サーバー実装の詳細、APIドキュメント、サービスアーキテクチャ。
- **ランタイム環境** (`/openhands/runtime/README.md`)
ランタイム環境、実行モデル、ランタイム構成をカバーするドキュメント。
#### インフラストラクチャ
- **コンテナドキュメント** (`/containers/README.md`)
Dockerコンテナ、デプロイメント戦略、コンテナ管理に関する包括的な情報。
### テストと評価
- **ユニットテストガイド** (`/tests/unit/README.md`)
ユニットテストの作成、実行、保守に関する指示。
- **評価フレームワーク** (`/evaluation/README.md`)
評価フレームワーク、ベンチマーク、パフォーマンステストに関するドキュメント。
### 高度な機能
- **マイクロエージェントアーキテクチャ** (`/microagents/README.md`)
マイクロエージェントアーキテクチャ、実装、使用法に関する詳細情報。
### ドキュメント標準
- **ドキュメントスタイルガイド** (`/docs/DOC_STYLE_GUIDE.md`)
プロジェクトドキュメントの作成と保守のための標準とガイドライン。
## 開発を始める
OpenHandsでの開発が初めての場合は、次の順序に従うことをお勧めします：
1. プロジェクトの目的と機能を理解するために、メインの`README.md`から始める
2. 貢献する予定がある場合は、`CONTRIBUTING.md`のガイドラインを確認する
3. `Development.md`のセットアップ手順に従う
4. 興味のある分野に基づいて特定のコンポーネントドキュメントに深く入り込む：
- フロントエンド開発者は`/frontend/README.md`に焦点を当てるべき
- バックエンド開発者は`/openhands/README.md`から始めるべき
- インフラストラクチャ作業は`/containers/README.md`から始めるべき
## ドキュメントの更新
コードベースに変更を加える際は、以下を確認してください：
1. 関連するドキュメントが変更を反映するように更新されている
2. 新機能が適切なREADMEファイルに文書化されている
3. APIの変更がサーバードキュメントに反映されている
4. ドキュメントが`/docs/DOC_STYLE_GUIDE.md`のスタイルガイドに従っている

113
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/evaluation-harness.md
View File

@ -2,16 +2,16 @@
このガイドでは、独自の評価ベンチマークをOpenHandsフレームワークに統合する方法の概要を説明します。
## 環境のセットアップとLLMの設定
## 環境のセットアップとLLM設定
ローカル開発環境のセットアップ方法については、[こちら](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の手順に従ってください。
開発モードのOpenHandsは、ほとんどの設定を追跡するために`config.toml`を使用します。
ローカル開発環境のセットアップについては、[こちら](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の手順に従ってください。
開発モードのOpenHandsでは、ほとんどの設定を追跡するために`config.toml`を使用します。
複数のLLMを定義して使用するために使用できる設定ファイルの例を以下に示します。
以下は、複数のLLMを定義して使用するための設定ファイルの例です：
```toml
[llm]
# 重要: ここにAPIキーを追加し、モデルを評価したいものに設定してください
# 重要: ここにAPIキーを追加し、評価したいモデルを設定してください
model = "claude-3-5-sonnet-20241022"
api_key = "sk-XXX"
@ -30,7 +30,7 @@ temperature = 0.0
## コマンドラインでOpenHandsを使用する方法
OpenHandsは、以下の形式でコマンドラインから実行できます。
OpenHandsは以下の形式でコマンドラインから実行できます：
```bash
poetry run python ./openhands/core/main.py \
@ -40,7 +40,7 @@ poetry run python ./openhands/core/main.py \
-l <llm_config>
```
例:
例えば：
```bash
poetry run python ./openhands/core/main.py \
@ -50,38 +50,39 @@ poetry run python ./openhands/core/main.py \
-l llm
```
このコマンドは、以下の設定でOpenHandsを実行します:
このコマンドは以下の設定でOpenHandsを実行します：
- 最大10回の反復
- 指定されたタスクの説明
- 指定されたタスク説明
- CodeActAgentを使用
- `config.toml`ファイルの`llm`セクションで定義されたLLM設定
- `config.toml`ファイルの`llm`セクションで定義されたLLM設定を使用
## OpenHandsの動作原理
## OpenHandsの仕組み
OpenHandsのメインエントリーポイントは`openhands/core/main.py`にあります。簡略化された動作の流れは次のとおりです。
OpenHandsのメインエントリーポイントは`openhands/core/main.py`にあります。以下は動作の簡略化されたフローです：
1. コマンドライン引数を解析し、設定を読み込む
2. `create_runtime()`を使用して実行時環境を作成する
2. `create_runtime()`を使用してランタイム環境を作成する
3. 指定されたエージェントを初期化する
4. `run_controller()`を使用してコントローラーを実行する
- 実行時環境をエージェントにアタッチする
4. `run_controller()`を使用してコントローラーを実行する：
- ランタイムをエージェントに接続する
- エージェントのタスクを実行する
- 完了時に最終状態を返す
`run_controller()`関数は、OpenHandsの実行の中核です。エージェント、実行時環境、およびタスク間の相互作用を管理し、ユーザー入力シミュレーションやイベント処理などを処理します。
`run_controller()`関数はOpenHandsの実行の中核です。エージェント、ランタイム、タスク間の相互作用を管理し、ユーザー入力シミュレーションやイベント処理などを処理します。
## 最も簡単な開始方法: 既存のベンチマークの探索
## 最も簡単な始め方：既存のベンチマークを探索する
リポジトリの[`evaluation/benchmarks/`ディレクトリ](https://github.com/All-Hands-AI/OpenHands/blob/main/evaluation/benchmarks)にある様々な評価ベンチマークを確認することをお勧めします。
リポジトリの[`evaluation/benchmarks/`ディレクトリ](https://github.com/All-Hands-AI/OpenHands/blob/main/evaluation/benchmarks)で利用可能な様々な評価ベンチマークを確認することをお勧めします。
独自のベンチマークを統合するには、ニーズに最も近いものから始めることをお勧めします。このアプローチは、既存の構造を基にして特定の要件に適応させることで、統合プロセスを大幅に合理化できます。
独自のベンチマークを統合するには、あなたのニーズに最も近いものから始めることをお勧めします。このアプローチにより、既存の構造を基に構築し、特定の要件に適応させることができるため、統合プロセスが大幅に効率化されます。
## 評価ワークフローの作成方法
ベンチマークの評価ワークフローを作成するには、次の手順に従います。
1. 関連するOpenHandsユーティリティをインポートします:
ベンチマークの評価ワークフローを作成するには、以下の手順に従ってください：
1. 関連するOpenHandsユーティリティをインポートする：
```python
import openhands.agenthub
from evaluation.utils.shared import (
@ -106,7 +107,7 @@ OpenHandsのメインエントリーポイントは`openhands/core/main.py`に
from openhands.runtime.runtime import Runtime
```
2. 設定を作成します:
2. 設定を作成する：
```python
def get_config(instance: pd.Series, metadata: EvalMetadata) -> AppConfig:
config = AppConfig(
@ -123,15 +124,15 @@ OpenHandsのメインエントリーポイントは`openhands/core/main.py`に
return config
```
3. 実行時環境を初期化し、評価環境をセットアップします:
3. ランタイムを初期化し、評価環境をセットアップする：
```python
def initialize_runtime(runtime: Runtime, instance: pd.Series):
# ここで評価環境をセットアップします
# ここで評価環境をセットアップする
# 例えば、環境変数の設定、ファイルの準備など
pass
```
4. 各インスタンスを処理する関数を作成します:
4. 各インスタンスを処理する関数を作成する：
```python
from openhands.utils.async_utils import call_async_from_sync
def process_instance(instance: pd.Series, metadata: EvalMetadata) -> EvalOutput:
@ -163,7 +164,7 @@ OpenHandsのメインエントリーポイントは`openhands/core/main.py`に
)
```
5. 評価を実行します:
5. 評価を実行する：
```python
metadata = make_metadata(llm_config, dataset_name, agent_class, max_iterations, eval_note, eval_output_dir)
output_file = os.path.join(metadata.eval_output_dir, 'output.jsonl')
@ -178,71 +179,71 @@ OpenHandsのメインエントリーポイントは`openhands/core/main.py`に
)
```
このワークフローでは、設定をセットアップし、実行時環境を初期化し、エージェントを実行して各インスタンスのアクションを評価し、結果を`EvalOutput`オブジェクトに収集します。`run_evaluation`関数は、並列化と進捗状況の追跡を処理します。
このワークフローでは、設定をセットアップし、ランタイム環境を初期化し、エージェントを実行してそのアクションを評価することで各インスタンスを処理し、結果を`EvalOutput`オブジェクトに収集します。`run_evaluation`関数は並列化と進捗追跡を処理します。
`get_instruction`、`your_user_response_function`、および`evaluate_agent_actions`関数は、特定のベンチマークの要件に応じてカスタマイズすることを忘れないでください。
`get_instruction`、`your_user_response_function`、`evaluate_agent_actions`関数を特定のベンチマーク要件に合わせてカスタマイズすることを忘れないでください。
この構造に従うことで、OpenHandsフレームワーク内で独自のベンチマークの堅牢な評価ワークフローを作成できます。
この構造に従うことで、OpenHandsフレームワーク内でベンチマーク用の堅牢な評価ワークフローを作成できます。
## `user_response_fn`の理解
`user_response_fn`は、OpenHandsの評価ワークフローにおいて重要な役割を果たします。これは、評価プロセス中にエージェントとのユーザー対話をシミュレートし、自動化された応答を可能にします。この関数は、エージェントのクエリやアクションに対して一貫性のある事前定義された応答を提供したい場合に特に役立ちます。
`user_response_fn`はOpenHandsの評価ワークフローにおける重要なコンポーネントです。エージェントとのユーザー対話をシミュレートし、評価プロセス中に自動応答を可能にします。この関数は、エージェントの問い合わせやアクションに対して一貫した、事前定義された応答を提供したい場合に特に役立ちます。
### ワークフローと相互作用
アクションと`user_response_fn`を処理するための正しいワークフローは次のとおりです。
アクションと`user_response_fn`を処理する正しいワークフローは次のとおりです：
1. エージェントがタスクを受け取り、処理を開始する
2. エージェントがアクションを発行する
3. アクションが実行可能な場合(CmdRunAction、IPythonRunCellActionなど):
- 実行時環境がアクションを処理する
- 実行時環境が観測結果を返す
4. アクションが実行不可能な場合(通常はMessageAction):
3. アクションが実行可能な場合（例：CmdRunAction、IPythonRunCellAction）：
- ランタイムがアクションを処理する
- ランタイムが観察結果を返す
4. アクションが実行不可能な場合（通常はMessageAction）：
- `user_response_fn`が呼び出される
- シミュレートされたユーザー応答を返す
5. エージェントは、観測結果またはシミュレートされた応答のいずれかを受け取る
6. ステップ2〜5が、タスクが完了するか最大反復回数に達するまで繰り返される
5. エージェントが観察結果またはシミュレートされた応答を受け取る
6. タスクが完了するか最大反復回数に達するまで、ステップ2〜5を繰り返す
より正確な視覚的表現は次のとおりです。
より正確な視覚的表現は次のとおりです：
```
[Agent]
[エージェント]
|
v
[Emit Action]
[アクション発行]
|
v
[Is Action Executable?]
[アクションは実行可能か？]
/ \
Yes No
はい いいえ
| |
v v
[Runtime] [user_response_fn]
[ランタイム] [user_response_fn]
| |
v v
[Return Observation] [Simulated Response]
[観察結果を返す] [シミュレートされた応答]
\ /
\ /
v v
[Agent receives feedback]
[エージェントがフィードバックを受け取る]
|
v
[Continue or Complete Task]
[タスクを継続または完了]
```
このワークフローでは:
このワークフローでは：
- 実行可能なアクション(コマンドの実行やコードの実行など)は、実行時環境によって直接処理される
- 実行不可能なアクション(通常、エージェントがコミュニケーションを取ったり、明確化を求めたりする場合)は、`user_response_fn`によって処理される
- エージェントは、実行時環境からの観測結果または`user_response_fn`からのシミュレートされた応答のいずれかのフィードバックを処理する
- 実行可能なアクション（コマンドの実行やコードの実行など）はランタイムによって直接処理される
- 実行不可能なアクション（通常、エージェントが通信や説明を求める場合）は`user_response_fn`によって処理される
- エージェントは、ランタイムからの観察結果か`user_response_fn`からのシミュレートされた応答かにかかわらず、フィードバックを処理する
このアプローチにより、具体的なアクションとシミュレートされたユーザー対話の両方を自動的に処理できるため、人的介入を最小限に抑えてエージェントのタスク完了能力をテストしたい評価シナリオに適しています。
このアプローチにより、具体的なアクションとシミュレートされたユーザー対話の両方を自動的に処理できるため、最小限の人間の介入でタスクを完了するエージェントの能力をテストしたい評価シナリオに適しています。
### 実装例
SWE-Benchの評価で使用される`user_response_fn`の例を以下に示します。
以下はSWE-Bench評価で使用される`user_response_fn`の例です：
```python
def codeact_user_response(state: State | None) -> str:
@ -268,10 +269,10 @@ def codeact_user_response(state: State | None) -> str:
return msg
```
この関数は次のことを行います。
この関数は以下を行います：
1. エージェントに作業を続けるよう促す標準メッセージを提供する
2. エージェントがユーザーとのコミュニケーションを試みた回数をチェックする
3. エージェントが複数回試行した場合、諦めるオプションを提供する
2. エージェントがユーザーとコミュニケーションを取ろうとした回数を確認する
3. エージェントが複数回試みた場合、諦めるオプションを提供する
この関数を使用することで、複数の評価実行全体で一貫した動作を確保し、エージェントが人間の入力を待って停止するのを防ぐことができます。
この関数を使用することで、複数の評価実行にわたって一貫した動作を確保し、エージェントが人間の入力を待って立ち往生することを防ぐことができます。

55
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/github-action.md
View File

@ -1,50 +1,51 @@
# OpenHands GitHub Actionの使用方法
このガイドでは、OpenHands自体のリポジトリ内および独自のプロジェクトの両方で、OpenHands GitHub Actionを使用する方法について説明します。
このガイドでは、自分のプロジェクトでOpenHands GitHub Actionを使用する方法について説明します。
## OpenHands リポジトリ内でのActionの使用
## OpenHandsリポジトリでのActionの使用
リポジトリ内でOpenHands GitHub Actionを使用するには、以下の手順を実行します。
OpenHands GitHub Actionをリポジトリで使用するには、以下の手順に従います：
1. リポジトリ内にissueを作成します。
2. issueに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントをissueに残します。
1. リポジトリでイシューを作成します。
2. イシューに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントをイシューに残します。
アクションは自動的にトリガーされ、issueの解決を試みます。
アクションは自動的にトリガーされ、イシューの解決を試みます。
## 新しいリポジトリへのActionのインストール
## 新しいリポジトリにActionをインストールする
独自のリポジトリにOpenHands GitHub Actionをインストールするには、[OpenHands Resolverの README](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md)に従ってください。
自分のリポジトリにOpenHands GitHub Actionをインストールするには、
[OpenHands Resolverのリードミー](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md)に従ってください。
## 使用のヒント
## 使用上のヒント
### 反復的な解決
1. リポジトリ内にissueを作成します。
2. issueに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントを残します。
3. プルリクエストを確認して、issueを解決する試みをレビューします。
4. 一般的なコメント、レビューコメント、またはインラインスレッドコメントを通じてフィードバックをフォローアップします。
5. プルリクエストに`fix-me`ラベルを追加するか、`@openhands-agent`で始まる特定のコメントに対処します。
1. リポジトリでイシューを作成します。
2. イシューに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントを残します。
3. プルリクエストを確認して、イシュー解決の試みをレビューします。
4. 一般的なコメント、レビューコメント、またはインラインスレッドコメントを通じてフィードバックを行います。
5. プルリクエストに`fix-me`ラベルを追加するか、`@openhands-agent`で始めて特定のコメントに対応します。
### ラベルとマクロ
### ラベルとマクロの違い
- ラベル（`fix-me`）：OpenHandsに**全体の** issueまたはプルリクエストへの対処を要求します。
- マクロ（`@openhands-agent`）：OpenHandsにissue/プルリクエストの説明と**特定のコメント**のみを考慮するように要求します。
- ラベル（`fix-me`）：OpenHandsにイシューまたはプルリクエスト**全体**に対応するよう要求します。
- マクロ（`@openhands-agent`）：OpenHandsにイシュー/プルリクエストの説明と**特定のコメント**のみを考慮するよう要求します。
## 高度な設定
### カスタムリポジトリ設定の追加
[resolverのREADME](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md#providing-custom-instructions)に従って、OpenHandsにカスタムの指示を提供できます。
[リゾルバーのリードミー](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md#providing-custom-instructions)に従って、OpenHandsにカスタム指示を提供できます。
### カスタム構成
GitHub resolverは、自動的に有効な[リポジトリシークレット](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions?tool=webui#creating-secrets-for-a-repository)または[リポジトリ変数](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#creating-configuration-variables-for-a-repository)をチェックして、その動作をカスタマイズします。
設定可能なカスタマイズオプションは次のとおりです。
GitHub resolverは、動作をカスタマイズするために有効な[リポジトリシークレット](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions?tool=webui#creating-secrets-for-a-repository)または[リポジトリ変数](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#creating-configuration-variables-for-a-repository)を自動的にチェックします。
設定できるカスタマイズオプションは以下の通りです：
| **属性名** | **タイプ** | **目的** | **例** |
| -------------------------------- | -------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| `LLM_MODEL` | Variable | OpenHandsで使用するLLMを設定 | `LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"` |
| `OPENHANDS_MAX_ITER` | Variable | エージェントの反復の最大制限を設定 | `OPENHANDS_MAX_ITER=10` |
| `OPENHANDS_MACRO` | Variable | リゾルバを呼び出すためのデフォルトマクロをカスタマイズ | `OPENHANDS_MACRO=@resolveit` |
| `OPENHANDS_BASE_CONTAINER_IMAGE` | Variable | カスタムSandbox（[詳細](https://docs.all-hands.dev/modules/usage/how-to/custom-sandbox-guide)） | `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |
| `TARGET_BRANCH` | Variable | `main`以外のブランチにマージ | `TARGET_BRANCH="dev"` |
| **属性名** | **タイプ** | **目的** | **例** |
| -------------------------------- | ---------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| `LLM_MODEL` | 変数 | OpenHandsで使用するLLMを設定 | `LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"` |
| `OPENHANDS_MAX_ITER` | 変数 | エージェントの反復回数の最大制限を設定 | `OPENHANDS_MAX_ITER=10` |
| `OPENHANDS_MACRO` | 変数 | リゾルバーを呼び出すためのデフォルトマクロをカスタマイズ | `OPENHANDS_MACRO=@resolveit` |
| `OPENHANDS_BASE_CONTAINER_IMAGE` | 変数 | カスタムサンドボックス（[詳細](https://docs.all-hands.dev/modules/usage/how-to/custom-sandbox-guide)） | `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |
| `TARGET_BRANCH` | 変数 | `main`以外のブランチにマージ | `TARGET_BRANCH="dev"` |

149
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/gui-mode.md
View File

@ -1,20 +1,22 @@
# GUIモード
OpenHandsは、AI アシスタントとやり取りするためのグラフィカルユーザーインターフェース（GUI）モードを提供しています。
OpenHandsは、AIアシスタントとの対話のためのグラフィカルユーザーインターフェース（GUI）モードを提供しています。
## インストールとセットアップ
1. インストール手順に従って、OpenHandsをインストールします。
1. インストール手順に従ってOpenHandsをインストールします。
2. コマンドを実行した後、[http://localhost:3000](http://localhost:3000)でOpenHandsにアクセスします。
## GUIでのやり取り
## GUIでの対話
### 初期設定
1. 初回起動時に、設定ページが表示されます。
2. ドロップダウンメニューから`LLM Provider`と`LLM Model`を選択します。必要なモデルがリストにない場合は、`Advanced`オプションを切り替えて、正しいプレフィックスを付けて`Custom Model`テキストボックスに入力します。
3. 選択したプロバイダーに対応する`API Key`を入力します。
4. `Save Changes`をクリックして設定を適用します。
1. 初回起動時に設定ポップアップが表示されます。
2. ドロップダウンメニューから`LLMプロバイダー`と`LLMモデル`を選択します。必要なモデルがリストに存在しない場合は、
`詳細設定を表示`を選択してください。次に`詳細設定`をトグルして、
`カスタムモデル`テキストボックスに正しいプレフィックスを付けて入力します。
3. 選択したプロバイダーに対応する`APIキー`を入力します。
4. `変更を保存`をクリックして設定を適用します。
### バージョン管理トークン
@ -22,139 +24,118 @@ OpenHandsは複数のバージョン管理プロバイダーをサポートし
#### GitHubトークンの設定
OpenHandsは、利用可能な場合、自動的に`GITHUB_TOKEN`をシェル環境にエクスポートします。これは2つの方法で行われます。
OpenHandsは提供された場合、自動的に`GITHUB_TOKEN`をシェル環境にエクスポートします：
**ローカルインストール**: ユーザーが直接GitHubトークンを入力します。
<details>
<summary>GitHubトークンの設定</summary>
<summary>GitHubトークンの設定方法</summary>
1. **Personal Access Token（PAT）の生成**:
- GitHubで、Settings > Developer Settings > Personal Access Tokens > Tokens (classic)に移動します。
- **New token (classic)**
- 必要なスコープ:
1. **個人アクセストークン（PAT）の生成**：
- GitHubで、設定 > 開発者設定 > 個人アクセストークン > トークン（クラシック）に移動します。
- **新しいトークン（クラシック）**
- 必要なスコープ：
- `repo`（プライベートリポジトリの完全な制御）
- **Fine-Grained Tokens**
- All Repositories（特定のリポジトリを選択できますが、これはリポジトリ検索の結果に影響します）
- Minimal Permissions（検索用に**Meta Data = Read-only**を選択し、ブランチ作成用に**Pull Requests = Read and Write**、**Content = Read and Write**を選択します）
2. **OpenHandsにトークンを入力**:
- **細かい権限を持つトークン**
- すべてのリポジトリ（特定のリポジトリを選択することもできますが、リポジトリ検索の結果に影響します）
- 最小限の権限（検索用に`メタデータ = 読み取り専用`、ブランチ作成用に`プルリクエスト = 読み取りと書き込み`および`コンテンツ = 読み取りと書き込み`を選択）
2. **OpenHandsにトークンを入力**：
- 設定ボタン（歯車アイコン）をクリックします。
- `Git Provider Settings`セクションに移動します。
- `GitHub Token`フィールドにトークンを貼り付けます。
- `Save Changes`をクリックして変更を適用します。
- `GitHubトークン`フィールドにトークンを貼り付けます。
- `保存`をクリックして変更を適用します。
</details>
<details>
<summary>組織のトークンポリシー</summary>
組織のリポジトリを使用する場合は、追加の設定が必要になる場合があります。
組織のリポジトリを扱う場合、追加の設定が必要な場合があります：
1. **組織の要件を確認**:
- 組織の管理者は、特定のトークンポリシーを適用することがあります。
- 一部の組織では、SSOを有効にしてトークンを作成する必要があります。
1. **組織の要件を確認**：
- 組織の管理者は特定のトークンポリシーを強制する場合があります。
- 一部の組織では、SSOが有効になっているトークンの作成が必要です。
- 組織の[トークンポリシー設定](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization)を確認してください。
2. **組織へのアクセスを確認**:
2. **組織へのアクセスを確認**：
- GitHubのトークン設定に移動します。
- `Organization access`の下で組織を探します。
- 必要に応じて、組織の横にある`Enable SSO`をクリックします。
- SSOの認証プロセスを完了します。
- `組織アクセス`の下で組織を探します。
- 必要に応じて、組織の横にある`SSOを有効にする`をクリックします。
- SSO認証プロセスを完了します。
</details>
<details>
<summary>トラブルシューティング</summary>
一般的な問題と解決策:
一般的な問題と解決策：
- **トークンが認識されない**:
- **トークンが認識されない**：
- トークンが設定に正しく保存されていることを確認します。
- トークンの有効期限が切れていないことを確認します。
- トークンが期限切れになっていないか確認します。
- トークンに必要なスコープがあることを確認します。
- トークンを再生成してみてください。
- **組織へのアクセスが拒否された**:
- SSOが必要だが有効になっていないかどうかを確認します。
- **組織アクセスが拒否された**：
- SSOが必要だが有効になっていないか確認します。
- 組織のメンバーシップを確認します。
- トークンポリシーがアクセスをブロックしている場合は、組織の管理者に連絡してください。
- **トークンが機能することを確認**:
- トークンが有効な場合、アプリにグリーンのチェックマークが表示されます。
- リポジトリにアクセスして、権限を確認してみてください。
- **トークンが機能するか確認**：
- トークンが有効な場合、アプリは緑色のチェックマークを表示します。
- リポジトリにアクセスして権限を確認してみてください。
- ブラウザのコンソールでエラーメッセージを確認してください。
</details>
**OpenHands Cloud**: トークンはGitHub OAuth認証を通じて取得されます。
<details>
<summary>OAuth認証</summary>
OpenHands Cloudを使用する場合、GitHub OAuthフローは以下の権限を要求します:
- リポジトリアクセス（読み取り/書き込み）
- ワークフロー管理
- 組織の読み取りアクセス
OpenHandsを認証するには:
- プロンプトが表示されたら、`Sign in with GitHub`をクリックします。
- 要求された権限を確認します。
- OpenHandsがGitHubアカウントにアクセスすることを承認します。
- 組織を使用している場合は、プロンプトが表示されたら組織へのアクセスを承認します。
</details>
#### GitLabトークンの設定
OpenHandsは、利用可能な場合、ローカルインストールのみ、自動的に`GITLAB_TOKEN`をシェル環境にエクスポートします。
OpenHandsは提供された場合、自動的に`GITLAB_TOKEN`をシェル環境にエクスポートします：
<details>
<summary>GitLabトークンの設定</summary>
<summary>GitLabトークンの設定方法</summary>
1. **Personal Access Token（PAT）の生成**:
- GitLabで、User Settings > Access Tokensに移動します。
- 以下のスコープを持つ新しいトークンを作成します:
1. **個人アクセストークン（PAT）の生成**：
- GitLabで、ユーザー設定 > アクセストークンに移動します。
- 以下のスコープを持つ新しいトークンを作成します：
- `api`（APIアクセス）
- `read_user`（ユーザー情報の読み取り）
- `read_repository`（リポジトリ読み取り）
- `write_repository`（リポジトリ書き込み）
- 有効期限を設定するか、無期限トークンの場合は空白のままにします。
2. **OpenHandsにトークンを入力**:
- `read_repository`（リポジトリの読み取り）
- `write_repository`（リポジトリの書き込み）
- 有効期限を設定するか、期限なしトークンの場合は空白のままにします。
2. **OpenHandsにトークンを入力**：
- 設定ボタン（歯車アイコン）をクリックします。
- `Git Provider Settings`セクションに移動します。
- `GitLab Token`フィールドにトークンを貼り付けます。
- `GitLabトークン`フィールドにトークンを貼り付けます。
- セルフホスト型GitLabを使用している場合は、GitLabインスタンスのURLを入力します。
- `Save Changes`をクリックして変更を適用します。
- `保存`をクリックして変更を適用します。
</details>
<details>
<summary>トラブルシューティング</summary>
一般的な問題と解決策:
一般的な問題と解決策：
- **トークンが認識されない**:
- **トークンが認識されない**：
- トークンが設定に正しく保存されていることを確認します。
- トークンの有効期限が切れていないことを確認します。
- トークンが期限切れになっていないか確認します。
- トークンに必要なスコープがあることを確認します。
- セルフホスト型インスタンスの場合は、正しいインスタンスURLを確認します。
- セルフホスト型インスタンスの場合、正しいインスタンスURLを確認します。
- **アクセスが拒否された**:
- **アクセスが拒否された**：
- プロジェクトのアクセス権限を確認します。
- トークンに必要なスコープがあるかどうかを確認します。
- グループ/組織のリポジトリの場合は、適切なアクセス権があることを確認します。
- トークンに必要なスコープがあるか確認します。
- グループ/組織のリポジトリの場合、適切なアクセス権があることを確認します。
</details>
### 高度な設定
### 詳細設定
1. 設定ページ内で、`Advanced`オプションを切り替えて追加の設定にアクセスします。
2. `Custom Model`テキストボックスを使用して、リストにないモデルを手動で入力します。
3. LLMプロバイダーで必要な場合は、`Base URL`を指定します。
1. 設定ページ内で、`詳細設定`をトグルして追加設定にアクセスします。
2. リストにないモデルを手動で入力するには、`カスタムモデル`テキストボックスを使用します。
3. LLMプロバイダーが必要とする場合は、`ベースURL`を指定します。
### AIとのやり取り
### AIとの対話
1. 入力ボックスにプロンプトを入力します。
2. 送信ボタンをクリックするか、Enterキーを押してメッセージを送信します。
3. AIは入力を処理し、チャットウィンドウに応答を提供します。
4. フォローアップの質問をしたり、追加情報を提供したりして、会話を続けることができます。
3. AIはあなたの入力を処理し、チャットウィンドウに応答を提供します。
4. フォローアップの質問や追加情報を提供することで会話を続けることができます。
## 効果的な使用のためのヒント
- [プロンプトのベストプラクティス](../prompting/prompting-best-practices)で説明されているように、要求を具体的にすることで、最も正確で役立つ応答を得ることができます。
- ワークスペースパネルを使用して、プロジェクト構造を探索します。
- [LLMsセクション](usage/llms/llms.md)で説明されているように、推奨モデルの1つを使用します。
- [プロンプティングのベストプラクティス](../prompting/prompting-best-practices)で説明されているように、最も正確で役立つ回答を得るために、リクエストを具体的にしてください。
- [LLMセクション](usage/llms/llms.md)で説明されているように、推奨モデルのいずれかを使用してください。
OpenHandsのGUIモードは、AIアシスタントとのやり取りをできるだけスムーズで直感的にすることを目的としています。生産性を最大限に高めるために、ぜひその機能を探ってみてください。
OpenHandsのGUIモードは、AIアシスタントとの対話をできるだけスムーズで直感的にするように設計されています。生産性を最大化するために、その機能を遠慮なく探索してください。

43
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/how-to/headless-mode.md
View File

@ -1,43 +1,44 @@
# ヘッドレスモード
OpenHandsは、Webアプリケーションを起動せずに、単一のコマンドで実行できます。
これにより、OpenHandsを使用してスクリプトを作成したり、タスクを自動化したりするのが簡単になります。
OpenHandsは、Webアプリケーションを起動せずに単一のコマンドで実行できます。
これにより、スクリプトを作成してOpenHandsでタスクを自動化することが容易になります。
これは、インタラクティブで、アクティブな開発に適した[CLIモード](cli-mode)とは異なります。
これは対話型で、アクティブな開発に適している[CLIモード](cli-mode)とは異なります。
## Pythonを使用する場合
## Pythonでの実行
PythonでOpenHandsをヘッドレスモードで実行するには:
1. [開発セットアップの手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)に従っていることを確認してください。
2. 以下のコマンドを実行します:
PythonでヘッドレスモードでOpenHandsを実行するには：
1. [開発セットアップ手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)に従っていることを確認してください。
2. 次のコマンドを実行します：
```bash
poetry run python -m openhands.core.main -t "write a bash script that prints hi"
```
モデル、APIキー、その他の設定は、環境変数[または`config.toml`ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を介して設定する必要があります。
環境変数または[`config.toml`ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を通じて、モデル、APIキー、その他の設定を必ず設定してください。
## Dockerを使用する場合
## Dockerでの実行
DockerでOpenHandsをヘッドレスモードで実行するには:
DockerでヘッドレスモードでOpenHandsを実行するには：
1. ターミナルで以下の環境変数を設定します:
1. ターミナルで次の環境変数を設定します：
- `WORKSPACE_BASE`をOpenHandsが編集するディレクトリに設定 (例: `export WORKSPACE_BASE=$(pwd)/workspace`)。
- `LLM_MODEL`を使用するモデルに設定 (例: `export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`)。
- `LLM_API_KEY`をAPIキーに設定 (例: `export LLM_API_KEY="sk_test_12345"`)。
- `SANDBOX_VOLUMES`でOpenHandsがアクセスするディレクトリを指定します（例：`export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw`）。
- エージェントはデフォルトで`/workspace`で作業するため、エージェントにファイルを変更させたい場合はプロジェクトディレクトリをそこにマウントします。
- 読み取り専用データの場合は、異なるマウントパスを使用します（例：`export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw,/path/to/large/dataset:/data:ro`）。
- `LLM_MODEL`に使用するモデルを設定します（例：`export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`）。
- `LLM_API_KEY`にAPIキーを設定します（例：`export LLM_API_KEY="sk_test_12345"`）。
2. 以下のDockerコマンドを実行します:
2. 次のDockerコマンドを実行します：
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-e LOG_ALL_EVENTS=true \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
@ -46,10 +47,12 @@ docker run -it \
python -m openhands.core.main -t "write a bash script that prints hi"
```
`-e SANDBOX_USER_ID=$(id -u)`はDockerコマンドに渡され、サンドボックスユーザーがホストユーザーの権限と一致するようにします。これにより、エージェントがマウントされたワークスペースにroot所有のファイルを作成するのを防ぎます。
## 高度なヘッドレス設定
ヘッドレスモードで利用可能なすべての設定オプションを表示するには、`--help`フラグを付けてPythonコマンドを実行します。
ヘッドレスモードで利用可能なすべての設定オプションを表示するには、Pythonコマンドに`--help`フラグを付けて実行します。
### 追加のログ
### 追加ログ
ヘッドレスモードでエージェントのすべてのアクションをログに記録するには、ターミナルで`export LOG_ALL_EVENTS=true`を実行します。
ヘッドレスモードですべてのエージェントアクションをログに記録するには、ターミナルで次のコマンドを実行します：`export LOG_ALL_EVENTS=true`

119
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/installation.mdx
View File

@ -2,54 +2,119 @@
## システム要件
* Docker バージョン26.0.0+またはDocker Desktop 4.31.0+
* LinuxまたはMac OSを使用する必要があります
* Windowsを使用している場合は、[WSL](https://learn.microsoft.com/en-us/windows/wsl/install)を使用する必要があります
- [Docker Desktopをサポート](https://docs.docker.com/desktop/setup/install/mac-install/#system-requirements)するMacOS
- Linux
- [WSL](https://learn.microsoft.com/en-us/windows/wsl/install)と[Docker Desktopをサポート](https://docs.docker.com/desktop/setup/install/windows-install/#system-requirements)するWindows
## アプリケーションの起動
OpenHandsを実行するには、最新のプロセッサと最低**4GB RAM**を搭載したシステムが推奨されます。
OpenHandsを実行する最も簡単な方法は、Dockerを使用することです。
## 前提条件
<details>
<summary>MacOS</summary>
**Docker Desktop**
1. [MacにDocker Desktopをインストール](https://docs.docker.com/desktop/setup/install/mac-install)します。
2. Docker Desktopを開き、`設定 > 詳細設定`に移動して、`デフォルトのDockerソケットの使用を許可する`が有効になっていることを確認します。
</details>
<details>
<summary>Linux</summary>
:::note
Ubuntu 22.04でテスト済み。
:::
**Docker Desktop**
1. [LinuxにDocker Desktopをインストール](https://docs.docker.com/desktop/setup/install/linux/)します。
</details>
<details>
<summary>Windows</summary>
**WSL**
1. [WSLをインストール](https://learn.microsoft.com/en-us/windows/wsl/install)します。
2. PowerShellで`wsl --version`を実行し、`Default Version: 2`であることを確認します。
**Docker Desktop**
1. [WindowsにDocker Desktopをインストール](https://docs.docker.com/desktop/setup/install/windows-install)します。
2. Docker Desktopを開き、`設定`で以下を確認します：
- 一般：`WSL 2ベースのエンジンを使用する`が有効になっている。
- リソース > WSL統合：`デフォルトのWSLディストリビューションとの統合を有効にする`が有効になっている。
:::note
アプリを起動するための以下のdockerコマンドは、WSLターミナル内で実行する必要があります。
:::
</details>
## アプリの起動
OpenHandsを実行する最も簡単な方法はDockerを使用することです。
```bash
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.29-nikolaik
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik
docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.29-nikolaik \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:0.29
docker.all-hands.dev/all-hands-ai/openhands:0.36
```
また、[ヘッドレススクリプトモード](https://docs.all-hands.dev/modules/usage/how-to/headless-mode)、[対話型CLI](https://docs.all-hands.dev/modules/usage/how-to/cli-mode)、または[OpenHands GitHub Action](https://docs.all-hands.dev/modules/usage/how-to/github-action)としても実行できます。
OpenHandsは http://localhost:3000 で実行されています！
## 設定
また、[OpenHandsをローカルファイルシステムに接続](https://docs.all-hands.dev/modules/usage/runtimes/docker#connecting-to-your-filesystem)したり、
OpenHandsを[ヘッドレスモード](https://docs.all-hands.dev/modules/usage/how-to/headless-mode)でスクリプト実行したり、
[使いやすいCLI](https://docs.all-hands.dev/modules/usage/how-to/cli-mode)を介して操作したり、
[GitHubアクション](https://docs.all-hands.dev/modules/usage/how-to/github-action)でタグ付けされた課題に対して実行したりすることもできます。
上記のコマンドを実行すると、OpenHandsは[http://localhost:3000](http://localhost:3000)で動作します。
## セットアップ
OpenHandsを起動すると、設定モーダルウィンドウが表示されます。`LLMプロバイダー`と`LLMモデル`を選択し、対応する`APIキー`を入力する**必要があります**。
これらの設定は、UIの`設定`ボタン（歯車アイコン）を選択することでいつでも変更できます。
OpenHandsを起動した後、`LLMプロバイダー`と`LLMモデル`を選択し、対応する`APIキー`を入力する**必要があります**。
これは、初期設定ポップアップ時に行うか、UIの`設定`ボタン（歯車アイコン）を選択して行うことができます。
必要な`LLMモデル`がリストに存在しない場合は、`詳細オプション`を有効にして、
`カスタムモデル`テキストボックスに適切なプレフィックスを付けて手動で入力できます。
`詳細オプション`では、必要に応じて`ベースURL`も指定できます。
必要なモデルがリストに存在しない場合は、`詳細設定`をトグルして、正しいプレフィックスを付けて
`カスタムモデル`テキストボックスに手動で入力することができます。
`詳細設定`では、必要に応じて`ベースURL`を指定することもできます。
<div style={{ display: 'flex', justifyContent: 'center', gap: '20px' }}>
<img src="/img/settings-screenshot.png" alt="settings-modal" width="340" />
<img src="/img/settings-advanced.png" alt="settings-modal" width="335" />
</div>
### APIキーの取得
OpenHandsはほとんどの言語モデルにアクセスするためにAPIキーが必要です。推奨プロバイダーからAPIキーを取得する方法は次のとおりです：
#### Anthropic (Claude)
1. [Anthropicアカウントを作成](https://console.anthropic.com/)します。
2. [APIキーを生成](https://console.anthropic.com/settings/keys)します。
3. [課金を設定](https://console.anthropic.com/settings/billing)します。
コストを管理するために使用制限を設定することを検討してください。
#### OpenAI
1. [OpenAIアカウントを作成](https://platform.openai.com/)します。
2. [APIキーを生成](https://platform.openai.com/api-keys)します。
3. [課金を設定](https://platform.openai.com/account/billing/overview)します。
これで[OpenHandsを使い始める](./getting-started)準備ができました。
## バージョン
上記のコマンドは、OpenHandsの最新の安定版を取得します。他のオプションもあります：
- 特定のバージョンを使用する場合は、`docker.all-hands.dev/all-hands-ai/openhands:$VERSION`を使用し、$VERSIONをバージョン番号に置き換えてください。
- semverを使用しており、メジャー、マイナー、パッチバージョンのタグを公開しています。したがって、`0.9`は最新の`0.9.x`バージョンを、`0`は最新の`0.x.x`バージョンを指します。
- 最新の開発バージョンを使用する場合は、`docker.all-hands.dev/all-hands-ai/openhands:main`を使用できます。このバージョンは不安定で、テストまたは開発目的でのみ推奨されます。
安定性要件と必要な機能に応じて、最適なタグを選択できます。
[上記のdockerコマンド](./installation#start-the-app)は、OpenHandsの最新の安定版リリースを取得します。他のオプションもあります：
- 特定のリリースの場合、`openhands:$VERSION`と`runtime:$VERSION`の$VERSIONをバージョン番号に置き換えます。
SemVerを使用しているため、`0.9`は自動的に最新の`0.9.x`リリースを指し、`0`は最新の`0.x.x`リリースを指します。
- 最新の開発バージョンの場合、`openhands:$VERSION`と`runtime:$VERSION`の$VERSIONを`main`に置き換えます。
このバージョンは不安定であり、テストまたは開発目的でのみ推奨されます。
開発ワークフローについては、[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)を参照してください。
問題がありますか？[トラブルシューティングガイド](https://docs.all-hands.dev/modules/usage/troubleshooting)をご確認ください。
問題がありますか？[トラブルシューティングガイド](https://docs.all-hands.dev/modules/usage/troubleshooting)をご確認ください。

85
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/key-features.md
View File

@ -1,72 +1,29 @@
# 主な機能
# OpenHands 機能概要
![overview](https://www.all-hands.dev/assets/product/product-slide-1.webp)
![概要](/img/oh-features.png)
## 1. ワークスペース
### チャットパネル
- ユーザーとOpenHandsの会話を表示します。
- OpenHandsはこのパネルで自身の行動を説明します。
ワークスペース機能は、以下の主要な機能を備えた包括的な開発環境を提供します：
### 変更点
- OpenHandsによって実行されたファイルの変更を表示します。
* ファイルエクスプローラー：プロジェクトのファイルとディレクトリの閲覧、表示、管理
* プロジェクト管理：異なるプロジェクトのインポート、作成、ナビゲーション
* 統合開発ツール：様々な開発ワークフローとのシームレスな統合
* ファイル操作：
* ファイル内容の表示
* 新規ファイルとフォルダの作成
* ファイルのアップロードとダウンロード
* 基本的なファイル操作
### VS Code
- ファイルの閲覧や修正のための組み込みVS Code。
- ファイルのアップロードやダウンロードにも使用できます。
## 2. Jupyterノートブック
### ターミナル
- OpenHandsとユーザーがターミナルコマンドを実行するためのスペース。
Jupyterノートブック機能は、インタラクティブなコーディングとデータ分析環境を提供します：
### Jupyter
- OpenHandsによって実行されたすべてのPythonコマンドを表示します。
- OpenHandsを使用してデータ可視化タスクを実行する際に特に便利です。
* インタラクティブなコードセル：セルベースのインターフェースでPythonコードを実行
* 入出力の追跡：コード入力とその出力の履歴を保持
* 永続的なセッション：セル間でコード実行コンテキストを保持
* 様々なPython操作とデータ分析タスクをサポート
* リアルタイムのコード実行と結果の可視化
### アプリ
- OpenHandsがアプリケーションを実行する際にウェブサーバーを表示します。
- ユーザーは実行中のアプリケーションと対話できます。
## 3. ブラウザ（ベータ）
ブラウザ機能は、Web操作機能を提供します：
* Webページナビゲーション：アプリケーション内でウェブサイトを開いて閲覧
* スクリーンショット取得：Webページのスクリーンショットを自動生成
* インタラクション機能：
* 要素のクリック
* フォームの入力
* ページのスクロール
* Web内容のナビゲーション
* 15種類のブラウザ操作機能をサポート
## 4. ターミナル
ターミナル機能は、アプリケーション内でコマンドラインインターフェースを提供します：
* シェルコマンドの実行：bashとシステムコマンドを実行
* コマンド履歴：過去のコマンドを追跡して呼び出し
* 環境との対話：システムのコマンドラインと直接対話
* 様々なプログラミングとシステム管理タスクをサポート
## 5. チャット / AI会話
チャットインターフェースは、AIを活用した会話体験を提供します：
* インタラクティブなAIアシスタント：自然言語での会話に参加
* コンテキストを理解した応答：開発関連の質問を理解して応答
* アクション提案：タスクに対する実行可能な推奨事項を提供
* 会話管理：異なる会話スレッドの作成、削除、管理
## 6. アプリケーション（ベータ）
メインアプリケーションインターフェースは、これらすべての機能を統合します：
* 統合ワークスペース：ワークスペース、ブラウザ、ターミナル、AIチャットのシームレスな統合
* カスタマイズ可能なレイアウト：異なる機能パネルの配置をカスタマイズ
* 状態管理：異なる機能間でコンテキストと状態を維持
* セキュリティとプライバシー制御：アプリケーションの設定と権限を管理
### 追加情報
* アプリケーションは現在ベータ版で、継続的な改善と機能追加が行われています
* 様々な開発ワークフローとAIアシストコーディングをサポート
* 統合ツールとAIアシスタンスを通じて開発者の生産性を向上するように設計
### ブラウザ
- OpenHandsがウェブサイトを閲覧するために使用します。
- このブラウザは非対話型です。

28
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/azure-llms.md
View File

@ -1,38 +1,38 @@
# Azure
OpenHands は LiteLLM を使用して Azure のチャットモデルを呼び出します。Azure をプロバイダとして使用する方法については、[こちら](https://docs.litellm.ai/docs/providers/azure)のドキュメントをご覧ください。
OpenHandsはLiteLLMを使用してAzureのチャットモデルを呼び出します。Azureをプロバイダーとして使用する方法に関するドキュメントは[こちら](https://docs.litellm.ai/docs/providers/azure)で確認できます。
## Azure OpenAI 設定
## Azure OpenAI設定
OpenHands を実行する際には、以下の環境変数を [docker run コマンド](../installation#running-openhands) で `-e` を使用して設定する必要があります。
OpenHandsを実行する際、[docker runコマンド](../installation#running-openhands)で`-e`を使用して以下の環境変数を設定する必要があります：
```
LLM_API_VERSION="<api-version>" # 例: "2023-05-15"
```
例:
例：
```bash
docker run -it --pull=always \
-e LLM_API_VERSION="2023-05-15"
...
```
その後、OpenHands UI の設定で以下を行います。
その後、OpenHands UIの設定で：
:::note
Azure の deployments ページで ChatGPT のデプロイメント名を確認する必要があります。以下では &lt;deployment-name&gt; と表記しています。
Azureのデプロイメントページで確認できるChatGPTデプロイメント名が必要です。これは以下の&lt;deployment-name&gt;として参照されます。
:::
1. `Advanced` オプションを有効にします。
2. 以下を設定します:
- `Custom Model` を azure/&lt;deployment-name&gt; に設定
- `Base URL` を Azure API の Base URL に設定 (例: `https://example-endpoint.openai.azure.com`)
- `API Key` を Azure API キーに設定
1. `Advanced`オプションを有効にします。
2. 以下を設定します：
- `Custom Model`を azure/&lt;deployment-name&gt; に設定
- `Base URL`を Azure API ベースURL（例：`https://example-endpoint.openai.azure.com`）に設定
- `API Key`を Azure APIキーに設定
### Azure OpenAI 設定
### Azure OpenAI設定
OpenHands を実行する際には、以下の環境変数を [docker run コマンド](../installation#running-openhands) で `-e` を使用して設定します。
OpenHandsを実行する際、[docker runコマンド](../installation#running-openhands)で`-e`を使用して以下の環境変数を設定します：
```
LLM_API_VERSION="<api-version>" # 例: "2024-02-15-preview"
```
```

86
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/custom-llm-configs.md
View File

@ -1,35 +1,35 @@
# カスタムLLM設定
OpenHandsでは、`config.toml`ファイルで複数の名前付きLLM設定を定義できます。この機能により、高品質な応答が不要なタスクには低コストのモデルを使用したり、特定のエージェントに対して異なるパラメータを持つ異なるモデルを使用したりするなど、異なる用途に応じて異なるLLM設定を使用できます。
OpenHandsでは、`config.toml`ファイルに複数の名前付きLLM設定を定義することができます。この機能により、異なる目的に応じて異なるLLM設定を使用することができます。例えば、高品質な応答を必要としないタスクには安価なモデルを使用したり、特定のエージェントに対して異なるパラメータを持つ異なるモデルを使用したりすることができます。
## 仕組み
名前付きLLM設定は、`config.toml`ファイルで`llm.`で始まるセクションを使用して定義されます。例：
名前付きLLM設定は、`config.toml`ファイルで`llm.`で始まるセクションを使用して定義されます。例えば：
```toml
# デフォルトのLLM設定
# デフォルトLLM設定
[llm]
model = "gpt-4"
api_key = "あなたのAPIキー"
api_key = "your-api-key"
temperature = 0.0
# 低コストモデル用のカスタムLLM設定
# 安価なモデル用のカスタムLLM設定
[llm.gpt3]
model = "gpt-3.5-turbo"
api_key = "あなたのAPIキー"
api_key = "your-api-key"
temperature = 0.2
# 異なるパラメータを持つ別のカスタム設定
[llm.high-creativity]
model = "gpt-4"
api_key = "あなたのAPIキー"
api_key = "your-api-key"
temperature = 0.8
top_p = 0.9
```
各名前付き設定は、デフォルトの`[llm]`セクションからすべてのパラメータを継承し、これらのパラメータを上書きできます。必要な数のカスタム設定を定義できます。
各名前付き設定は、デフォルトの`[llm]`セクションからすべての設定を継承し、それらの設定を上書きすることができます。必要な数だけカスタム設定を定義できます。
## カスタム設定の使用
## カスタム設定の使用方法
### エージェントでの使用
@ -37,48 +37,48 @@ top_p = 0.9
```toml
[agent.RepoExplorerAgent]
# このエージェントには低コストのGPT-3設定を使用
# このエージェントには安価なGPT-3設定を使用
llm_config = 'gpt3'
[agent.CodeWriterAgent]
# このエージェントには高創造性の設定を使用
# このエージェントには高創造性設定を使用
llm_config = 'high-creativity'
```
### 設定オプション
各名前付きLLM設定は、デフォルトのLLM設定と同じすべてのオプションをサポートしています。これらには以下が含まれます：
各名前付きLLM設定は、デフォルトのLLM設定と同じオプションをすべてサポートしています。これらには以下が含まれます：
- モデルの選択（`model`）
- モデル選択（`model`）
- API設定（`api_key`、`base_url`など）
- モデルパラメータ（`temperature`、`top_p`など）
- リトライパラメータ（`num_retries`、`retry_multiplier`など）
- リトライ設定（`num_retries`、`retry_multiplier`など）
- トークン制限（`max_input_tokens`、`max_output_tokens`）
- その他すべてのLLM設定オプション
利用可能なオプションの完全なリストについては、[設定オプション](../configuration-options)のドキュメントのLLM設定セクションを参照してください。
利用可能なオプションの完全なリストについては、[設定オプション](../configuration-options)ドキュメントのLLM設定セクションを参照してください。
## ユースケース
カスタムLLM設定は、以下のようなシナリオで特に有用です：
カスタムLLM設定は、特に以下のシナリオで役立ちます：
- **コスト最適化**：リポジトリの探索やシンプルなファイル操作など、高品質な応答が不要なタスクには低コストのモデルを使用
- **タスク固有の調整**：異なるレベルの創造性や決定論的な応答が必要なタスクに対して、異なるtemperatureやtop_p値を設定
- **異なるプロバイダー**：異なるタスクに対して異なるLLMプロバイダーやAPIエンドポイントを使用
- **テストと開発**：開発とテスト中に異なるモデル設定を簡単に切り替え
- **コスト最適化**：リポジトリの探索や単純なファイル操作など、高品質な応答を必要としないタスクには安価なモデルを使用します。
- **タスク固有の調整**：異なるレベルの創造性や決定論を必要とするタスクに対して、異なる温度やtop_p値を設定します。
- **異なるプロバイダー**：異なるタスクに対して異なるLLMプロバイダーやAPIエンドポイントを使用します。
- **テストと開発**：開発とテスト中に異なるモデル設定を簡単に切り替えることができます。
## 例：コスト最適化
コスト最適化のためのカスタムLLM設定の実践的な例：
カスタムLLM設定を使用してコストを最適化する実用的な例：
```toml
# 高品質な応答用のGPT-4を使用するデフォルト設定
# 高品質な応答のためのGPT-4を使用するデフォルト設定
[llm]
model = "gpt-4"
api_key = "あなたのAPIキー"
api_key = "your-api-key"
temperature = 0.0
# リポジトリ探索用の低コスト設定
# リポジトリ探索用の安価な設定
[llm.repo-explorer]
model = "gpt-3.5-turbo"
temperature = 0.2
@ -97,10 +97,40 @@ llm_config = 'code-gen'
```
この例では：
- リポジトリ探索は主にコードの理解とナビゲーションなので、低コストモデルを使用
- コード生成は、より大きなコードブロックを生成するためにGPT-4とより高いトークン制限を使用
- デフォルト設定は他のタスクで引き続き利用可能
- リポジトリ探索は主にコードの理解とナビゲーションを含むため、安価なモデルを使用します
- コード生成は、より大きなコードブロックを生成するためにGPT-4とより高いトークン制限を使用します
- デフォルト設定は他のタスクで引き続き利用可能です
# 予約名を持つカスタム設定
OpenHandsは、特定のユースケースのために予約名を持つカスタムLLM設定を使用することができます。予約名の下でモデルやその他の設定を指定すると、OpenHandsはそれらを特定の目的のために読み込んで使用します。現在、そのような設定の一つが実装されています：ドラフトエディター。
## ドラフトエディター設定
`draft_editor`設定は、コードの編集や改良を含むタスクのために、コード編集の予備的な草案作成に使用するモデルを指定するための設定グループです。これを`[llm.draft_editor]`セクションの下に提供する必要があります。
例えば、`config.toml`で次のようなドラフトエディターを定義できます：
```toml
[llm.draft_editor]
model = "gpt-4"
temperature = 0.2
top_p = 0.95
presence_penalty = 0.0
frequency_penalty = 0.0
```
この設定：
- 高品質な編集と提案のためにGPT-4を使用します
- 一貫性を維持しながらも柔軟性を許容するために低い温度（0.2）を設定します
- 幅広いトークンオプションを考慮するために高いtop_p値（0.95）を使用します
- 必要な特定の編集に焦点を当てるためにpresenceとfrequencyのペナルティを無効にします
この設定は、編集を行う前にLLMに編集の草案を作成させたい場合に使用します。一般的に、以下の場合に役立ちます：
- コードの改善を確認して提案する
- コアの意味を維持しながら既存のコンテンツを改良する
- コードやテキストに正確で焦点を絞った変更を加える
:::note
カスタムLLM設定は、`main.py`または`cli.py`を介して開発モードでOpenHandsを使用する場合にのみ利用可能です。`docker run`を介して実行する場合は、標準の設定オプションを使用してください。
:::
:::

34
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/google-llms.md
View File

@ -1,31 +1,29 @@
以下は、指定されたコンテンツの日本語訳です。
# Google Gemini/Vertex
OpenHandsはLiteLLMを使用して、Googleのチャットモデルを呼び出します。Googleをプロバイダとして使用する方法については、以下のドキュメントを参照してください。
OpenHandsはLiteLLMを使用してGoogleのチャットモデルを呼び出します。Googleをプロバイダーとして使用する方法については、以下のドキュメントを参照してください：
- [Gemini - Google AI Studio](https://docs.litellm.ai/docs/providers/gemini)
- [VertexAI - Google Cloud Platform](https://docs.litellm.ai/docs/providers/vertex)
## Gemini - Google AI Studio の設定
## Gemini - Google AI Studioの設定
OpenHandsを実行する際、設定画面で以下を設定する必要があります。
- `LLM Provider` を `Gemini` に設定
- `LLM Model` を使用するモデルに設定
モデルがリストにない場合は、`Advanced` オプションを切り替えて、`Custom Model` に入力します（例: `gemini/gemini-2.0-flash` のように gemini/&lt;model-name&gt;）。
- `API Key` を Gemini API キーに設定
OpenHandsを実行する際、設定画面で以下を設定する必要があります：
- `LLM Provider`を`Gemini`に設定
- `LLM Model`を使用するモデルに設定
モデルがリストにない場合は、`Advanced`オプションを切り替えて、`Custom Model`に入力してください（例：gemini/&lt;model-name&gt;、`gemini/gemini-2.0-flash`など）。
- `API Key`にGemini APIキーを設定
## VertexAI - Google Cloud Platform の設定
## VertexAI - Google Cloud Platformの設定
Google Cloud Platform 経由で Vertex AI を使用して OpenHands を実行するには、[docker run コマンド](../installation#running-openhands)で `-e` を使用して以下の環境変数を設定する必要があります。
Google Cloud PlatformのVertex AIを使用してOpenHandsを実行する場合、[docker runコマンド](../installation#running-openhands)で`-e`を使用して以下の環境変数を設定する必要があります：
```
GOOGLE_APPLICATION_CREDENTIALS="<json-dump-of-gcp-service-account-json>"
VERTEXAI_PROJECT="<your-gcp-project-id>"
VERTEXAI_LOCATION="<your-gcp-location>"
GOOGLE_APPLICATION_CREDENTIALS="<gcp-サービスアカウントjsonのjsonダンプ>"
VERTEXAI_PROJECT="<あなたのgcpプロジェクトid>"
VERTEXAI_LOCATION="<あなたのgcpロケーション>"
```
その後、設定画面で以下を設定します。
- `LLM Provider` を `VertexAI` に設定
- `LLM Model` を使用するモデルに設定
モデルがリストにない場合は、`Advanced` オプションを切り替えて、`Custom Model` に入力します（例: vertex_ai/&lt;model-name&gt;）。
その後、OpenHandsのUI設定で以下を設定します：
- `LLM Provider`を`VertexAI`に設定
- `LLM Model`を使用するモデルに設定
モデルがリストにない場合は、`Advanced`オプションを切り替えて、`Custom Model`に入力してください（例：vertex_ai/&lt;model-name&gt;）。

25
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/groq.md
View File

@ -1,20 +1,19 @@
# Groq
OpenHandsは、GroqのチャットモデルへのAPIコールにLiteLLMを使用します。Groqをプロバイダーとして使用する方法については、[こちら](https://docs.litellm.ai/docs/providers/groq)のドキュメントを参照してください。
OpenHandsはLiteLLMを使用してGroqのチャットモデルを呼び出します。Groqをプロバイダーとして使用する方法に関するドキュメントは[こちら](https://docs.litellm.ai/docs/providers/groq)で確認できます。
## 設定
OpenHandsを実行する際、OpenHandsのUIで設定メニューから以下の項目を設定する必要があります：
OpenHandsを実行する際、設定画面で以下の項目を設定する必要があります：
- `LLM Provider`を`Groq`に設定
- `LLM Model`を使用するモデルに設定。[Groqがホストしているモデルのリストはこちらで確認できます](https://console.groq.com/docs/models)。モデルがリストにない場合は、`Advanced`オプションを有効にして、`Custom Model`に入力してください（例：groq/&lt;model-name&gt;のように`groq/llama3-70b-8192`）。
- `API key`にGroq APIキーを設定。Groq APIキーの確認または作成については、[こちらを参照してください](https://console.groq.com/keys)。
* `LLMプロバイダー`を`Groq`に設定
* `LLMモデル`を使用するモデルに設定。[Groqがホストするモデルのリストはこちら](https://console.groq.com/docs/models)を参照してください。モデルがリストにない場合は、`詳細設定`を有効にし、`カスタムモデル`に入力してください（例：groq/&lt;model-name&gt;として`groq/llama3-70b-8192`）。
* `APIキー`をGroq APIキーに設定。Groq APIキーの確認または作成については、[こちら](https://console.groq.com/keys)を参照してください。
## GroqをOpenAI互換エンドポイントとして使用する
## OpenAI互換エンドポイントとしてのGroqの使用
Groqのチャット補完エンドポイントは[主にOpenAI互換](https://console.groq.com/docs/openai)です。そのため、他のOpenAI互換エンドポイントと同様の方法でGroqのモデルにアクセスできます。OpenHandsのUIで設定メニューから以下の項目を設定します：
* `詳細設定`を有効にする
* `カスタムモデル`にプレフィックス`openai/`と使用するモデルを設定（例：`openai/llama3-70b-8192`）
* `ベースURL`を`https://api.groq.com/openai/v1`に設定
* `APIキー`をGroq APIキーに設定
Groqのチャット完了エンドポイントは[ほぼOpenAI互換](https://console.groq.com/docs/openai)です。そのため、OpenAI互換エンドポイントと同様にGroqモデルにアクセスできます。OpenHandsのUI設定画面で：
1. `Advanced`オプションを有効にする
2. 以下を設定する：
- `Custom Model`に接頭辞`openai/`と使用するモデル名を組み合わせて設定（例：`openai/llama3-70b-8192`）
- `Base URL`を`https://api.groq.com/openai/v1`に設定
- `API Key`にGroq APIキーを設定

18
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/litellm-proxy.md
View File

@ -1,20 +1,20 @@
# LiteLLM プロキシ
OpenHandsは、様々なLLMプロバイダーにアクセスするために[LiteLLMプロキシ](https://docs.litellm.ai/docs/proxy/quick_start)の使用をサポートしています。
OpenHandsは[LiteLLMプロキシ](https://docs.litellm.ai/docs/proxy/quick_start)を使用して、様々なLLMプロバイダーにアクセスすることをサポートしています。
## 設定
OpenHandsでLiteLLMプロキシを使用するには、以下の手順が必要です：
1. LiteLLMプロキシサーバーを設定する（[LiteLLMのドキュメント](https://docs.litellm.ai/docs/proxy/quick_start)を参照）
2. OpenHandsを実行する際、OpenHandsのUIで設定メニューから以下の項目を設定する必要があります：
* `詳細設定`を有効にする
* `カスタムモデル`にプレフィックス`litellm_proxy/`と使用するモデルを設定（例：`litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`）
* `ベースURL`をLiteLLMプロキシのURL（例：`https://your-litellm-proxy.com`）に設定
* `APIキー`をLiteLLMプロキシのAPIキーに設定
1. LiteLLMプロキシサーバーをセットアップする（[LiteLLMドキュメント](https://docs.litellm.ai/docs/proxy/quick_start)を参照）
2. OpenHandsを実行する際、設定画面から以下の項目を設定する必要があります：
* `Advanced`（詳細設定）オプションを有効にする
* `Custom Model`（カスタムモデル）に接頭辞 `litellm_proxy/` + 使用するモデル名を設定する（例：`litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`）
* `Base URL`（ベースURL）にLiteLLMプロキシのURLを設定する（例：`https://your-litellm-proxy.com`）
* `API Key`（APIキー）にLiteLLMプロキシのAPIキーを設定する
## サポートされているモデル
サポートされているモデルは、LiteLLMプロキシの設定に依存します。OpenHandsは、LiteLLMプロキシが処理するように設定されているすべてのモデルをサポートします。
サポートされているモデルはLiteLLMプロキシの設定によって異なります。OpenHandsはLiteLLMプロキシが対応するように設定されているあらゆるモデルをサポートします。
利用可能なモデルとその名前のリストについては、LiteLLMプロキシの設定を参照してください。
利用可能なモデルとその名前のリストについては、LiteLLMプロキシの設定を参照してください。

88
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/llms.md
View File

@ -1,48 +1,55 @@
# 🤖 LLMバックエンド
OpenHandsは、LiteLLMがサポートするすべてのLLMに接続できます。ただし、機能するには強力なモデルが必要です。
## モデルの推奨事項
コーディングタスクに対する言語モデルの評価（SWE-benchデータセットを使用）に基づいて、モデル選択に関するいくつかの推奨事項を提供できます。分析の一部は、[LLMを比較したこのブログ記事](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed)と[より最近の結果を含むこのブログ記事](https://www.all-hands.dev/blog/openhands-codeact-21-an-open-state-of-the-art-software-development-agent)で確認できます。
モデルを選択する際は、出力の品質とコストの両方を考慮してください。結果の要約は以下の通りです：
- Claude 3.5 Sonnetが圧倒的に優れており、OpenHandsのデフォルトエージェントでSWE-Bench Verifiedの53%の解決率を達成しています。
- GPT-4oは遅れを取っており、o1-miniは実際にGPT-4oよりもわずかに低いパフォーマンスを示しました。結果を少し分析したところ、o1は時々「考えすぎ」て、タスクを完了できるのに追加の環境設定タスクを実行していたようです。
- 最後に、最も強力なオープンモデルはLlama 3.1 405 BとDeepseek-v2.5で、合理的なパフォーマンスを示し、一部のクローズドモデルを上回りました。
詳細については、[完全な記事](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed)を参照してください。
これらの結果とコミュニティからのフィードバックに基づいて、以下のモデルがOpenHandsで合理的に機能することが確認されています：
- claude-3-5-sonnet（推奨）
- gpt-4 / gpt-4o
- llama-3.1-405b
- deepseek-v2.5
:::warning
OpenHandsは、設定したLLMに多くのプロンプトを送信します。これらのLLMのほとんどは有料なので、支出制限を設定し、使用状況を監視してください。
:::note
このセクションは、OpenHandsを異なるLLMに接続したいユーザー向けです。
:::
リストにない特定のLLMでOpenHandsの実行に成功した場合は、検証済みリストに追加してください。また、同じプロバイダーとLLMを使用する他のユーザーを支援するため、設定プロセスを共有するPRを開くことをお勧めします！
OpenHandsはLiteLLMでサポートされているあらゆるLLMに接続できます。ただし、動作するには強力なモデルが必要です。
利用可能なプロバイダーとモデルの完全なリストについては、[litellmのドキュメント](https://docs.litellm.ai/docs/providers)を参照してください。
## モデルの推奨
コーディングタスク向けの言語モデル評価（SWE-benchデータセットを使用）に基づいて、モデル選択についていくつかの
推奨事項を提供できます。最新のベンチマーク結果は[このスプレッドシート](https://docs.google.com/spreadsheets/d/1wOUdFCMyY6Nt0AIqF705KN4JKOWgeI4wUGUP60krXXs/edit?gid=0)で確認できます。
これらの調査結果とコミュニティからのフィードバックに基づき、以下のモデルはOpenHandsでうまく動作することが確認されています：
- [anthropic/claude-3-7-sonnet-20250219](https://www.anthropic.com/api) (推奨)
- [gemini/gemini-2.5-pro](https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/)
- [deepseek/deepseek-chat](https://api-docs.deepseek.com/)
- [openai/o3-mini](https://openai.com/index/openai-o3-mini/)
- [openai/o3](https://openai.com/index/introducing-o3-and-o4-mini/)
- [openai/o4-mini](https://openai.com/index/introducing-o3-and-o4-mini/)
- [all-hands/openhands-lm-32b-v0.1](https://www.all-hands.dev/blog/introducing-openhands-lm-32b----a-strong-open-coding-agent-model) -- [OpenRouter](https://openrouter.ai/all-hands/openhands-lm-32b-v0.1)を通じて利用可能
:::warning
OpenHandsは設定したLLMに多くのプロンプトを送信します。これらのLLMのほとんどは有料なので、支出制限を設定し、
使用状況を監視してください。
:::
リストにないLLMでOpenHandsを正常に実行できた場合は、検証済みリストに追加してください。
また、同じプロバイダーとLLMを使用している他のユーザーを支援するために、セットアッププロセスを共有するPRを開くことをお勧めします！
利用可能なプロバイダーとモデルの完全なリストについては、
[litellmのドキュメント](https://docs.litellm.ai/docs/providers)を参照してください。
:::note
現在のほとんどのローカルおよびオープンソースモデルは、それほど強力ではありません。このようなモデルを使用する場合、メッセージ間の長い待機時間、品質の低い応答、または不正なJSONに関するエラーが発生する可能性があります。OpenHandsは、それを駆動するモデルと同じくらい強力にしかなりません。ただし、機能するモデルを見つけた場合は、上記の検証済みリストに追加してください。
現在のほとんどのローカルおよびオープンソースモデルはそれほど強力ではありません。そのようなモデルを使用すると、
メッセージ間の長い待ち時間、質の低い応答、または不正なJSON形式に関するエラーが発生する可能性があります。OpenHandsは
それを駆動するモデルと同じくらい強力にしかなりません。ただし、うまく動作するモデルを見つけた場合は、上記の検証済みリストに追加してください。
:::
## LLM設定
以下の項目は、OpenHandsのUIで設定メニューから設定できます：
以下の設定は、OpenHandsのUI内の設定から行うことができます：
- `LLMプロバイダー`
- `LLMモデル`
- `APIキー`
- `ベースURL`（`詳細設定`から）
一部のLLM/プロバイダーで必要となる可能性があるが、UIでは設定できないパラメータがあります。これらは代わりに、[docker runコマンド](/modules/usage/installation#start-the-app)に`-e`を使用して環境変数として渡すことができます：
一部のLLM/プロバイダーでは、UI経由で設定できない設定が必要な場合があります。これらは
アプリを起動する際にdocker runコマンドに`-e`を使って環境変数として渡すことができます：
- `LLM_API_VERSION`
- `LLM_EMBEDDING_MODEL`
@ -56,27 +63,30 @@ OpenHandsは、設定したLLMに多くのプロンプトを送信します。
- [Azure](llms/azure-llms)
- [Google](llms/google-llms)
- [Groq](llms/groq)
- [SGLangまたはvLLMを使用したローカルLLM](llms/../local-llms.md)
- [LiteLLM Proxy](llms/litellm-proxy)
- [OpenAI](llms/openai-llms)
- [OpenRouter](llms/openrouter)
### APIリトライとレート制限
LLMプロバイダーは通常、レート制限を持っており、時には非常に低い制限で、リトライが必要になる場合があります。OpenHandsは、レート制限エラー（エラーコード429）、API接続エラー、またはその他の一時的なエラーを受信した場合、自動的にリクエストを再試行します。
LLMプロバイダーには通常レート制限があり、場合によっては非常に低く設定されていて、リトライが必要になることがあります。OpenHandsは
レート制限エラー（429エラーコード）を受け取った場合、自動的にリクエストを再試行します。
使用しているプロバイダーのニーズに応じて、これらのオプションをカスタマイズできます。プロバイダーのドキュメントを確認し、以下の環境変数を設定してリトライ回数とリトライ間の待機時間を制御してください：
使用しているプロバイダーに合わせてこれらのオプションをカスタマイズできます。プロバイダーのドキュメントを確認し、
リトライ回数とリトライ間の時間を制御するために以下の環境変数を設定してください：
- `LLM_NUM_RETRIES`（デフォルト8）
- `LLM_RETRY_MIN_WAIT`（デフォルト15秒）
- `LLM_RETRY_MAX_WAIT`（デフォルト120秒）
- `LLM_RETRY_MULTIPLIER`（デフォルト2）
- `LLM_NUM_RETRIES`（デフォルトは4回）
- `LLM_RETRY_MIN_WAIT`（デフォルトは5秒）
- `LLM_RETRY_MAX_WAIT`（デフォルトは30秒）
- `LLM_RETRY_MULTIPLIER`（デフォルトは2）
OpenHandsを開発モードで実行している場合、これらのオプションを`config.toml`ファイルで設定することもできます：
開発モードでOpenHandsを実行している場合は、`config.toml`ファイルでこれらのオプションを設定することもできます：
```toml
[llm]
num_retries = 8
retry_min_wait = 15
retry_max_wait = 120
num_retries = 4
retry_min_wait = 5
retry_max_wait = 30
retry_multiplier = 2
```
```

203
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/local-llms.md
View File

@ -1,190 +1,83 @@
# ローカルLLMとOllama
# ローカルLLM（SGLangまたはvLLM）の使用
:::warning
ローカルLLMを使用する場合、OpenHandsの機能が制限される可能性があります。
最適な体験を得るためには、GPUを使用してローカルモデルを提供することを強く推奨します。
:::
Ollamaサーバーが起動し、実行中であることを確認してください。
詳細な起動手順については、[こちら](https://github.com/ollama/ollama)を参照してください。
## ニュース
このガイドでは、`ollama serve`でollamaを起動したことを前提としています。ollamaを別の方法で実行している場合（例：dockerの中で）、手順を変更する必要があるかもしれません。WSLを実行している場合、デフォルトのollama設定ではdockerコンテナからのリクエストがブロックされることに注意してください。[こちら](#configuring-ollama-service-wsl-ja)を参照してください。
- 2025/03/31: SWE-Bench Verifiedで37.1%を達成するオープンモデルOpenHands LM v0.1 32Bをリリースしました
（[ブログ](https://www.all-hands.dev/blog/introducing-openhands-lm-32b----a-strong-open-coding-agent-model)、[モデル](https://huggingface.co/all-hands/openhands-lm-32b-v0.1)）。
## モデルのプル
## Huggingfaceからモデルをダウンロード
Ollamaモデル名は[こちら](https://ollama.com/library)で確認できます。小さな例として、`codellama:7b`モデルを使用できます。一般的に、より大きなモデルの方が性能が良くなります。
例えば、[OpenHands LM 32B v0.1](https://huggingface.co/all-hands/openhands-lm-32b-v0.1)をダウンロードするには：
```bash
ollama pull codellama:7b
huggingface-cli download all-hands/openhands-lm-32b-v0.1 --local-dir all-hands/openhands-lm-32b-v0.1
```
ダウンロードしたモデルは以下のように確認できます：
## モデル提供フレームワークでOpenAI互換エンドポイントを作成
### SGLangでの提供
- [公式ドキュメント](https://docs.sglang.ai/start/install.html)に従ってSGLangをインストールします。
- OpenHands LM 32B用の起動コマンド例（少なくとも2つのGPUが必要）：
```bash
~$ ollama list
NAME ID SIZE MODIFIED
codellama:7b 8fdf8f752f6e 3.8 GB 6 weeks ago
mistral:7b-instruct-v0.2-q4_K_M eb14864c7427 4.4 GB 2 weeks ago
starcoder2:latest f67ae0f64584 1.7 GB 19 hours ago
SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 python3 -m sglang.launch_server \
--model all-hands/openhands-lm-32b-v0.1 \
--served-model-name openhands-lm-32b-v0.1 \
--port 8000 \
--tp 2 --dp 1 \
--host 0.0.0.0 \
--api-key mykey --context-length 131072
```
## DockerでOpenHandsを実行
### vLLMでの提供
### OpenHandsの起動
[こちら](../getting-started)の手順を使用して、DockerでOpenHandsを起動します。
ただし、`docker run`を実行する際に、いくつかの引数を追加する必要があります：
- [公式ドキュメント](https://docs.vllm.ai/en/latest/getting_started/installation.html)に従ってvLLMをインストールします。
- OpenHands LM 32B用の起動コマンド例（少なくとも2つのGPUが必要）：
```bash
docker run # ...
--add-host host.docker.internal:host-gateway \
-e LLM_OLLAMA_BASE_URL="http://host.docker.internal:11434" \
# ...
vllm serve all-hands/openhands-lm-32b-v0.1 \
--host 0.0.0.0 --port 8000 \
--api-key mykey \
--tensor-parallel-size 2 \
--served-model-name openhands-lm-32b-v0.1
--enable-prefix-caching
```
LLM_OLLAMA_BASE_URLはオプションです。設定すると、UIでインストール済みの利用可能なモデルを表示するために使用されます。
## OpenHandsの実行と設定
### OpenHandsの実行
### Webアプリケーションの設定
#### Dockerを使用
`openhands`を実行する際、OpenHands UIの設定で以下を設定する必要があります：
- モデルを"ollama/&lt;model-name&gt;"に
- ベースURLを`http://host.docker.internal:11434`に
- APIキーはオプションで、`ollama`などの任意の文字列を使用できます。
[公式のdocker実行コマンド](../installation#start-the-app)を使用してOpenHandsを実行します。
#### 開発モードを使用
## 開発モードでOpenHandsを実行
### ソースからビルド
[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の手順を使用して、OpenHandsをビルドします。
`make setup-config`を実行して`config.toml`が存在することを確認してください。これにより、設定ファイルが作成されます。`config.toml`に以下を入力します：
[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の指示に従ってOpenHandsをビルドします。
`make setup-config`を実行して`config.toml`が存在することを確認します。これにより設定ファイルが作成されます。`config.toml`に以下を入力します：
```
[core]
workspace_base="./workspace"
workspace_base="/path/to/your/workspace"
[llm]
embedding_model="local"
ollama_base_url="http://localhost:11434"
model="openhands-lm-32b-v0.1"
ollama_base_url="http://localhost:8000"
```
これで完了です！`make run`でOpenHandsを起動できるようになりました。`http://localhost:3000/`に接続できるはずです。
`make run`を使用してOpenHandsを起動します。
### Webアプリケーションの設定
### OpenHandsの設定
OpenHands UIで、左下の設定ホイールをクリックします。
次に、`Model`入力に`ollama/codellama:7b`、または先ほどプルしたモデルの名前を入力します。
ドロップダウンに表示されない場合は、`Advanced Settings`を有効にして入力してください。注意：`ollama list`で表示されるモデル名に、接頭辞`ollama/`を付ける必要があります。
APIキーフィールドには、特定のキーが不要なので、`ollama`または任意の値を入力します。
ベースURLフィールドには、`http://localhost:11434`を入力します。
これで準備完了です！
## ollamaサービスの設定（WSL） {#configuring-ollama-service-wsl-ja}
WSLのollamaのデフォルト設定では、localhostのみにサービスを提供します。つまり、dockerコンテナからアクセスできません。例えば、OpenHandsでは動作しません。まず、ollamaが正しく実行されていることをテストしましょう。
```bash
ollama list # インストール済みモデルのリストを取得
curl http://localhost:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例 curl http://localhost:11434/api/generate -d '{"model":"codellama:7b","prompt":"hi"}'
#例 curl http://localhost:11434/api/generate -d '{"model":"codellama","prompt":"hi"}' #タグは1つしかない場合はオプション
```
完了したら、dockerコンテナ内からの「外部」リクエストを許可するかテストします。
```bash
docker ps # 実行中のdockerコンテナのリストを取得。最も正確なテストのためにOpenHandsサンドボックスコンテナを選択。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例 docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## 修正方法
それでは、動作するようにしましょう。sudo権限で/etc/systemd/system/ollama.serviceを編集します。（パスはLinuxの種類によって異なる場合があります）
```bash
sudo vi /etc/systemd/system/ollama.service
```
または
```bash
sudo nano /etc/systemd/system/ollama.service
```
[Service]ブラケットにこれらの行を追加します
```
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"
```
そして保存し、設定をリロードしてサービスを再起動します。
```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```
最後に、コンテナ内からollamaにアクセスできることをテストします
```bash
ollama list # インストール済みモデルのリストを取得
docker ps # 実行中のdockerコンテナのリストを取得。最も正確なテストのためにOpenHandsサンドボックスコンテナを選択。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
```
# ローカルLLMとLM Studio
LM Studioのセットアップ手順：
1. LM Studioを開きます
2. ローカルサーバータブに移動します。
3. 「サーバーを起動」ボタンをクリックします。
4. ドロップダウンから使用するモデルを選択します。
以下の設定を行います：
```bash
LLM_MODEL="openai/lmstudio"
LLM_BASE_URL="http://localhost:1234/v1"
CUSTOM_LLM_PROVIDER="openai"
```
### Docker
```bash
docker run # ...
-e LLM_MODEL="openai/lmstudio" \
-e LLM_BASE_URL="http://host.docker.internal:1234/v1" \
-e CUSTOM_LLM_PROVIDER="openai" \
# ...
```
これで、`http://localhost:3000/`に接続できるはずです。
開発環境では、`config.toml`ファイルに以下の設定を行うことができます：
```
[core]
workspace_base="./workspace"
[llm]
model="openai/lmstudio"
base_url="http://localhost:1234/v1"
custom_llm_provider="openai"
```
完了です！これで、Dockerなしで`make run`を実行してOpenHandsを起動できます。`http://localhost:3000/`に接続できるはずです。
# 注意
WSLの場合、cmdで以下のコマンドを実行して、ネットワークモードをミラーに設定します：
```
python -c "print('[wsl2]\nnetworkingMode=mirrored',file=open(r'%UserProfile%\.wslconfig','w'))"
wsl --shutdown
```
OpenHandsが実行されたら、設定を通じてOpenHands UIで以下を設定する必要があります：
1. `Advanced`オプションを有効にします。
2. 以下を設定します：
- `Custom Model`を`openai/<served-model-name>`（例：`openai/openhands-lm-32b-v0.1`）に設定
- `Base URL`を`http://host.docker.internal:8000`に設定
- `API key`をモデル提供時に設定したのと同じ文字列（例：`mykey`）に設定

29
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/openai-llms.md
View File

@ -1,26 +1,25 @@
# OpenAI
OpenHandsは、OpenAIのチャットモデルへのAPIコールにLiteLLMを使用します。OpenAIをプロバイダーとして使用する方法については、[こちら](https://docs.litellm.ai/docs/providers/openai)のドキュメントを参照してください。
OpenHandsはLiteLLMを使用してOpenAIのチャットモデルを呼び出します。OpenAIをプロバイダーとして使用する方法に関するドキュメントは[こちら](https://docs.litellm.ai/docs/providers/openai)で確認できます。
## 設定
OpenHandsを実行する際、OpenHandsのUIで設定メニューから以下の項目を設定する必要があります：
* `LLMプロバイダー`を`OpenAI`に設定
* `LLMモデル`を使用するモデルに設定。
[LiteLLMがサポートするOpenAIモデルの完全なリストはこちら](https://docs.litellm.ai/docs/providers/openai#openai-chat-completion-models)を参照してください。
モデルがリストにない場合は、`詳細設定`を有効にし、`カスタムモデル`に入力してください（例：openai/&lt;model-name&gt;として`openai/gpt-4o`）。
* `APIキー`をOpenAI APIキーに設定。OpenAIプロジェクトのAPIキーの確認または作成については、[こちら](https://platform.openai.com/api-keys)を参照してください。
OpenHandsを実行する際、設定画面で以下の項目を設定する必要があります：
* `LLM Provider`を`OpenAI`に設定
* `LLM Model`を使用するモデルに設定
[LiteLLMがサポートするOpenAIモデルの完全なリストはこちらをご覧ください。](https://docs.litellm.ai/docs/providers/openai#openai-chat-completion-models)
モデルがリストにない場合は、`Advanced`オプションを切り替えて、`Custom Model`に入力してください（例：openai/&lt;model-name&gt;、`openai/gpt-4o`など）。
* `API Key`にOpenAI APIキーを設定。OpenAI Project APIキーの確認または作成については、[こちら](https://platform.openai.com/api-keys)をご覧ください。
## OpenAI互換エンドポイントの使用
OpenAIのチャット補完と同様に、OpenAI互換エンドポイントにもLiteLLMを使用します。この件に関する完全なドキュメントは[こちら](https://docs.litellm.ai/docs/providers/openai_compatible)を参照してください。
OpenAIチャット補完と同様に、OpenAI互換エンドポイントにもLiteLLMを使用します。この話題に関する完全なドキュメントは[こちら](https://docs.litellm.ai/docs/providers/openai_compatible)で確認できます。
## OpenAIプロキシの使用
OpenAIプロキシを使用する場合、OpenHandsのUIで設定メニューから以下の項目を設定する必要があります：
* `詳細設定`を有効にする
* `カスタムモデル`をopenai/&lt;model-name&gt;に設定（例：`openai/gpt-4o`またはopenai/&lt;proxy-prefix&gt;/&lt;model-name&gt;）
* `ベースURL`をOpenAIプロキシのURLに設定
* `APIキー`をOpenAI APIキーに設定
OpenAIプロキシを使用している場合、OpenHandsのUI設定で：
1. `Advanced`オプションを有効にする
2. 以下を設定する：
- `Custom Model`をopenai/&lt;model-name&gt;に設定（例：`openai/gpt-4o`またはopenai/&lt;proxy-prefix&gt;/&lt;model-name&gt;）
- `Base URL`をOpenAIプロキシのURLに設定
- `API Key`をOpenAI APIキーに設定

15
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/llms/openrouter.md
View File

@ -1,13 +1,12 @@
# OpenRouter
OpenHandsは、OpenRouterのチャットモデルへのAPIコールにLiteLLMを使用します。OpenRouterをプロバイダーとして使用する方法については、[こちら](https://docs.litellm.ai/docs/providers/openrouter)のドキュメントを参照してください。
OpenHandsはLiteLLMを使用してOpenRouter上のチャットモデルを呼び出します。OpenRouterをプロバイダーとして使用する方法に関するドキュメントは[こちら](https://docs.litellm.ai/docs/providers/openrouter)で確認できます。
## 設定
OpenHandsを実行する際、OpenHandsのUIで設定メニューから以下の項目を設定する必要があります：
* `LLMプロバイダー`を`OpenRouter`に設定
* `LLMモデル`を使用するモデルに設定。
[OpenRouterのモデルの完全なリストはこちら](https://openrouter.ai/models)を参照してください。
モデルがリストにない場合は、`詳細設定`を有効にし、`カスタムモデル`に入力してください（例：openrouter/&lt;model-name&gt;として`openrouter/anthropic/claude-3.5-sonnet`）。
* `APIキー`をOpenRouter APIキーに設定。
OpenHandsを実行する際、設定画面から以下の項目を設定する必要があります：
* `LLM Provider`を`OpenRouter`に設定
* `LLM Model`を使用するモデルに設定
[OpenRouterモデルの完全なリストはこちらで確認できます](https://openrouter.ai/models)。
モデルがリストにない場合は、`Advanced`オプションを切り替えて、`Custom Model`に入力してください（例：openrouter/&lt;model-name&gt; のように `openrouter/anthropic/claude-3.5-sonnet`）。
* `API Key`にOpenRouterのAPIキーを設定

96
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/mcp.md Normal file
View File

@ -0,0 +1,96 @@
# モデルコンテキストプロトコル（MCP）
:::note
このページでは、OpenHandsでモデルコンテキストプロトコル（MCP）を設定して使用する方法を説明します。これにより、エージェントの機能をカスタムツールで拡張できます。
:::
## 概要
モデルコンテキストプロトコル（MCP）は、OpenHandsが外部ツールサーバーと通信するためのメカニズムです。これらのサーバーは、特殊なデータ処理、外部APIアクセス、またはカスタムツールなど、エージェントに追加機能を提供できます。MCPは[modelcontextprotocol.io](https://modelcontextprotocol.io)で定義されているオープンスタンダードに基づいています。
## 設定
MCP設定は`config.toml`ファイルの`[mcp]`セクションで定義されます。
### 設定例
```toml
[mcp]
# SSEサーバー - Server-Sent Eventsを介して通信する外部サーバー
sse_servers = [
# 基本的なSSEサーバー（URLのみ）
"http://example.com:8080/mcp",
# APIキー認証を使用するSSEサーバー
{url="https://secure-example.com/mcp", api_key="your-api-key"}
]
# Stdioサーバー - 標準入出力を介して通信するローカルプロセス
stdio_servers = [
# 基本的なstdioサーバー
{name="fetch", command="uvx", args=["mcp-server-fetch"]},
# 環境変数を持つstdioサーバー
{
name="data-processor",
command="python",
args=["-m", "my_mcp_server"],
env={
"DEBUG": "true",
"PORT": "8080"
}
}
]
```
## 設定オプション
### SSEサーバー
SSEサーバーは、文字列URLまたは以下のプロパティを持つオブジェクトを使用して設定されます：
- `url`（必須）
- 型: `str`
- 説明: SSEサーバーのURL
- `api_key`（オプション）
- 型: `str`
- デフォルト: `None`
- 説明: SSEサーバーとの認証用APIキー
### Stdioサーバー
Stdioサーバーは、以下のプロパティを持つオブジェクトを使用して設定されます：
- `name`（必須）
- 型: `str`
- 説明: サーバーの一意の名前
- `command`（必須）
- 型: `str`
- 説明: サーバーを実行するコマンド
- `args`（オプション）
- 型: `list of str`
- デフォルト: `[]`
- 説明: サーバーに渡すコマンドライン引数
- `env`（オプション）
- 型: `dict of str to str`
- デフォルト: `{}`
- 説明: サーバープロセスに設定する環境変数
## MCPの仕組み
OpenHandsが起動すると、次のことが行われます：
1. `config.toml`からMCP設定を読み込む
2. 設定されたSSEサーバーに接続する
3. 設定されたstdioサーバーを起動する
4. これらのサーバーが提供するツールをエージェントに登録する
エージェントは、これらのツールを組み込みツールと同じように使用できます。エージェントがMCPツールを呼び出すと：
1. OpenHandsは呼び出しを適切なMCPサーバーにルーティングする
2. サーバーはリクエストを処理し、レスポンスを返す
3. OpenHandsはレスポンスを観察結果に変換し、エージェントに提示する

36
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/prompting/microagents-keyword.md Normal file
View File

@ -0,0 +1,36 @@
# キーワードトリガー型マイクロエージェント
## 目的
キーワードトリガー型マイクロエージェントは、プロンプト内に特定のキーワードが現れたときに有効化される特定の指示をOpenHandsに提供します。これは特定のツール、言語、またはフレームワークに基づいて動作をカスタマイズするのに役立ちます。
## 使用方法
これらのマイクロエージェントは、プロンプトにトリガーワードの1つが含まれている場合にのみ読み込まれます。
## フロントマターの構文
フロントマターはキーワードトリガー型マイクロエージェントには必須です。ファイルの先頭、ガイドラインの上に配置する必要があります。
フロントマターを三重のダッシュ(---)で囲み、以下のフィールドを含めます：
| フィールド | 説明 | 必須 | デフォルト |
|------------|------------------------------------------------|----------|------------------|
| `triggers` | マイクロエージェントを有効化するキーワードのリスト | はい | なし |
| `agent` | このマイクロエージェントが適用されるエージェント | いいえ | 'CodeActAgent' |
## 例
`.openhands/microagents/yummy.md`に配置されたキーワードトリガー型マイクロエージェントファイルの例：
```
---
triggers:
- yummyhappy
- happyyummy
---
ユーザーが魔法の言葉を言いました。「それはおいしかった！」と応答してください。
```
[公式OpenHandsリポジトリでキーワードによってトリガーされるマイクロエージェントの例を見る](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)

52
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/prompting/microagents-overview.md
View File

@ -1,33 +1,39 @@
# Microagentsの概要
# マイクロエージェント概要
Microagentsは、ドメイン固有の知識、リポジトリ固有のコンテキスト、タスク固有のワークフローでOpenHandsを強化する特殊なプロンプトです。専門家のガイダンスを提供し、一般的なタスクを自動化し、プロジェクト全体で一貫したプラクティスを確保するのに役立ちます。
マイクロエージェントは、OpenHandsにドメイン固有の知識を強化する特殊なプロンプトです。
専門的なガイダンスを提供し、一般的なタスクを自動化し、プロジェクト全体で一貫した実践を確保します。
## Microagentの種類
## マイクロエージェントの種類
現在、OpenHandsは以下の種類のmicroagentsをサポートしています:
現在、OpenHandsは以下の種類のマイクロエージェントをサポートしています：
* [リポジトリMicroagents](./microagents-repo): OpenHands用のリポジトリ固有のコンテキストとガイドライン。
* [パブリックMicroagents](./microagents-public): すべてのOpenHandsユーザーのためにキーワードによってトリガーされる一般的なガイドライン。
- [一般リポジトリマイクロエージェント](./microagents-repo)：リポジトリに関するOpenHandsの一般的なガイドライン。
- [キーワードトリガーマイクロエージェント](./microagents-keyword)：プロンプト内の特定のキーワードによって起動されるガイドライン。
OpenHandsがリポジトリで動作する際:
OpenHandsの動作をカスタマイズするには、リポジトリのルートに`.openhands/microagents/`ディレクトリを作成し、
その中に`<microagent_name>.md`ファイルを追加します。
1. リポジトリに`.openhands/microagents/`が存在する場合、そこからリポジトリ固有の指示を読み込みます。
2. 会話のキーワードによってトリガーされる一般的なガイドラインを読み込みます。
現在の[パブリックMicroagents](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)を参照してください。
:::note
ロードされたマイクロエージェントはコンテキストウィンドウ内のスペースを占めます。
これらのマイクロエージェントは、ユーザーメッセージと共に、タスクと環境についてOpenHandsに情報を提供します。
:::
## Microagentのフォーマット
リポジトリ構造の例：
すべてのmicroagentsは、YAMLのfrontmatterを持つmarkdownファイルを使用します。これには、OpenHandsがタスクを達成するための特別な指示が含まれています:
```
---
name: <Microagentの名前>
type: <Microagentのタイプ>
version: <Microagentのバージョン>
agent: <エージェントのタイプ (通常はCodeActAgent)>
triggers:
- <オプション: microagentをトリガーするキーワード。トリガーを削除すると、常に含まれるようになります>
---
<OpenHandsが従うべき特別なガイドライン、指示、プロンプトを含むMarkdown。
ベストプラクティスに関する各microagentの具体的なドキュメントを確認してください。>
some-repository/
└── .openhands/
└── microagents/
└── repo.md # 一般的なリポジトリガイドライン
└── trigger_this.md # 特定のキーワードでトリガーされるマイクロエージェント
└── trigger_that.md # 特定のキーワードでトリガーされるマイクロエージェント
```
## マイクロエージェントのフロントマター要件
各マイクロエージェントファイルには、追加情報を提供するフロントマターが含まれる場合があります。場合によっては、このフロントマターが必要です：
| マイクロエージェントの種類 | 必須 |
|--------------------------|------|
| `一般リポジトリマイクロエージェント` | いいえ |
| `キーワードトリガーマイクロエージェント` | はい |

103
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/prompting/microagents-public.md
View File

@ -1,91 +1,50 @@
# パブリックマイクロエージェント
# グローバルマイクロエージェント
## 概要
パブリックマイクロエージェントは、OpenHandsのすべてのユーザーが利用できる一般的なガイドラインを提供します。これらは、特定のキーワードによってトリガーされ、特定のドメインやタスクに関する専門知識を提供します。
グローバルマイクロエージェントは、すべてのOpenHandsユーザーに適用される[キーワード起動型マイクロエージェント](./microagents-keyword)です。現在のグローバルマイクロエージェントのリストは[OpenHandsリポジトリ](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)で確認できます。
## 現在のパブリックマイクロエージェント
## グローバルマイクロエージェントの貢献
### GitHubエージェント
公式リポジトリにプルリクエストを開くことで、グローバルマイクロエージェントを作成してコミュニティと共有することができます。
GitHubエージェントは、GitHubリポジトリとの対話を支援します。主な機能：
OpenHandsへの貢献方法の具体的な手順については、[CONTRIBUTING.md](https://github.com/All-Hands-AI/OpenHands/blob/main/CONTRIBUTING.md)を参照してください。
* リポジトリのクローン
* ブランチの作成と切り替え
* コミットとプッシュ
* プルリクエストの作成
### グローバルマイクロエージェントのベストプラクティス
### NPMエージェント
- **明確な範囲**: マイクロエージェントを特定のドメインやタスクに焦点を当てる。
- **明示的な指示**: 明確で曖昧さのないガイドラインを提供する。
- **有用な例**: 一般的なユースケースの実用的な例を含める。
- **安全性優先**: 必要な警告と制約を含める。
- **統合の認識**: マイクロエージェントが他のコンポーネントとどのように相互作用するかを考慮する。
NPMエージェントは、Node.jsプロジェクトの管理を支援します：
### グローバルマイクロエージェントを貢献するステップ
* パッケージのインストールと更新
* 依存関係の管理
* スクリプトの実行
* バージョン管理
#### 1. グローバルマイクロエージェントの計画
## パブリックマイクロエージェントの貢献
グローバルマイクロエージェントを作成する前に、以下を考慮してください：
### パブリックマイクロエージェントのベストプラクティス
- どのような特定の問題やユースケースに対応するか？
- どのようなユニークな能力や知識を持つべきか？
- どのようなトリガーワードが活性化に適しているか？
- どのような制約やガイドラインに従うべきか？
1. **明確なトリガー**：エージェントをトリガーするキーワードを明確に定義します
2. **集中的な範囲**：1つのドメインまたはタスクに焦点を当てます
3. **明確なガイドライン**：エージェントの責任と制限を明確に説明します
4. **実用的な例**：一般的なユースケースの例を含めます
#### 2. ファイルの作成
### パブリックマイクロエージェントを貢献するステップ
適切なディレクトリに説明的な名前を持つ新しいMarkdownファイルを作成します：
[`microagents/`](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)
1. [マイクロエージェントのフォーマット](./microagents-overview#microagent-format)を確認します
2. 新しいマイクロエージェントファイルを作成します
3. ガイドラインとベストプラクティスに従っていることを確認します
4. プルリクエストを作成します
#### 3. グローバルマイクロエージェントのテスト
### パブリックマイクロエージェントの実装例
- さまざまなプロンプトでエージェントをテストする。
- トリガーワードが正しくエージェントを活性化することを確認する。
- 指示が明確で包括的であることを確認する。
- 既存のエージェントとの潜在的な競合や重複をチェックする。
```
---
name: Dockerエージェント
type: public
version: 1.0
agent: CodeActAgent
triggers:
- docker
- container
---
#### 4. 提出プロセス
あなたはDockerコンテナの管理とDockerfileの作成を担当します。
以下を含むプルリクエストを提出します：
主な責任：
1. Dockerfileの作成と修正
2. コンテナのライフサイクル管理
3. Docker Compose設定の処理
ガイドライン：
- 可能な限り公式ベースイメージを使用
- 必要なセキュリティ考慮事項を含める
- レイヤー最適化のためのDockerベストプラクティスに従う
例：
1. Dockerfileの作成：
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]
2. Docker Composeの使用：
version: '3'
services:
web:
build: .
ports:
- "3000:3000"
忘れないこと：
- Dockerfileの構文を検証
- セキュリティ脆弱性をチェック
- ビルド時間とイメージサイズを最適化
```
より多くの例については、[現在のパブリックマイクロエージェント](https://github.com/All-Hands-AI/OpenHands/tree/main/microagents)をご覧ください。
- 新しいマイクロエージェントファイル。
- 必要に応じて更新されたドキュメント。
- エージェントの目的と機能の説明。

72
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/prompting/microagents-repo.md
View File

@ -1,67 +1,31 @@
# リポジトリマイクロエージェント
# 一般リポジトリマイクロエージェント
## 概要
## 目的
OpenHandsは、リポジトリ固有のコンテキストとガイドラインを提供することで、特定のリポジトリでより効果的に動作するようにカスタマイズできます。このセクションでは、OpenHandsをプロジェクトに最適化する方法を説明します。
リポジトリをより効果的に扱うためのOpenHandsの一般的なガイドライン。
## リポジトリマイクロエージェントの作成
## 使用方法
リポジトリのルートに`.openhands/microagents/`ディレクトリを作成することで、リポジトリに対するOpenHandsの動作をカスタマイズできます。
最低限、このリポジトリで作業する際にエージェントに与えられる指示を含む
`.openhands/microagents/repo.md`ファイルが必要です。
これらのマイクロエージェントは常にコンテキストの一部として読み込まれます。
### リポジトリマイクロエージェントのベストプラクティス
## フロントマター構文
* **指示を最新に保つ**：プロジェクトの進化に合わせて`.openhands/microagents/`ディレクトリを定期的に更新します。
* **具体的に**：プロジェクト固有のパス、パターン、要件を含めます。
* **依存関係を文書化**：開発に必要なすべてのツールと依存関係をリストアップします。
* **例を含める**：プロジェクトの良いコードパターンの例を提供します。
* **規約を指定**：命名規則、ファイル構成、コードスタイルの設定を文書化します。
このタイプのマイクロエージェントのフロントマターはオプションです。
### リポジトリマイクロエージェントを作成するステップ
フロントマターは三重のダッシュ(---)で囲み、以下のフィールドを含めることができます：
#### 1. リポジトリマイクロエージェントの計画
| フィールド | 説明 | 必須 | デフォルト値 |
|-----------|-----------------------------------------|----------|----------------|
| `agent` | このマイクロエージェントが適用されるエージェント | いいえ | 'CodeActAgent' |
リポジトリ固有のマイクロエージェントを作成する際は、以下の情報を含めることを推奨します：
* **リポジトリの概要**：プロジェクトの目的とアーキテクチャの簡単な説明。
* **ディレクトリ構造**：主要なディレクトリとその目的。
* **開発ガイドライン**：プロジェクト固有のコーディング標準とプラクティス。
* **テスト要件**：テストの実行方法と必要なテストの種類。
* **セットアップ手順**：プロジェクトのビルドと実行に必要な手順。
#### 2. ファイルの作成
リポジトリの`.openhands/microagents/`ディレクトリにファイルを作成します（例：`.openhands/microagents/repo.md`）
[必要なフォーマット](./microagents-overview#microagent-format)に従って必要なフロントマターと、リポジトリに必要な特殊なガイドラインでファイルを更新します。
### リポジトリマイクロエージェントの例
## 例
`.openhands/microagents/repo.md`に配置された一般リポジトリマイクロエージェントファイルの例：
```
---
name: repo
type: repo
agent: CodeActAgent
---
このプロジェクトはユーザーがTODOアイテムを追跡できるTODOアプリケーションです。
リポジトリ：MyProject
説明：タスク管理のためのWebアプリケーション
ディレクトリ構造：
- src/：メインアプリケーションコード
- tests/：テストファイル
- docs/：ドキュメント
セットアップ：
- `npm install`で依存関係をインストール
- 開発には`npm run dev`を使用
- テストには`npm test`を実行
ガイドライン：
- ESLint設定に従う
- すべての新機能にテストを書く
- 新しいコードにはTypeScriptを使用
src/componentsに新しいコンポーネントを追加する場合は、必ずtests/components/に適切なユニットテストを追加してください。
セットアップするには、`npm run build`を実行できます。
変更をコミットする前に、常にテストが合格していることを確認してください。`npm run test`を実行してテストを実行できます。
```
[一般リポジトリマイクロエージェントの詳細な例はこちらをご覧ください。](https://github.com/All-Hands-AI/OpenHands/tree/main/.openhands/microagents)

36
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/prompting/prompting-best-practices.md
View File

@ -1,37 +1,37 @@
# プロンプトのベストプラクティス
OpenHands AIソフトウェア開発者と連携する際、明確で効果的なプロンプトを提供することが重要です。このガイドでは、最も正確で有用な応答を引き出すためのプロンプト作成のベストプラクティスについて説明します。
OpenHands AIソフトウェア開発者と連携する際、明確で効果的なプロンプトを提供することが、正確で有用な回答を得るための鍵となります。このガイドでは、効果的なプロンプトを作成するためのベストプラクティスを概説します。
## 良いプロンプトの特徴
良いプロンプトは以下のような特徴があります：
良いプロンプトは以下の特徴を持ちます：
- **具体的**：どのような機能を追加すべきか、またはどのようなエラーを修正する必要があるかを正確に説明します。
- **場所を特定**：可能であれば、コードベース内のどの場所を修正すべきかを説明します。
- **適切な範囲**：1つの機能の大きさであるべきで、通常は100行のコードを超えないようにします。
- **具体的**：追加すべき機能や修正すべきエラーを明確に説明する。
- **場所を特定**：可能であれば、修正すべきコードベース内の場所を指定する。
- **適切な範囲**：単一の機能に焦点を当て、通常は100行以内のコードに収める。
## 例
### 良いプロンプトの例
- "`utils/math_operations.py`に、数値のリストを入力として受け取り、その平均を返す関数`calculate_average`を追加してください。"
- "`frontend/src/components/UserProfile.tsx`の42行目で発生しているTypeErrorを修正してください。このエラーは、undefinedのプロパティにアクセスしようとしていることを示唆しています。"
- "登録フォームのメールフィールドに入力検証を実装してください。`frontend/src/components/RegistrationForm.tsx`を更新し、送信前にメールが有効な形式であるかどうかを確認するようにしてください。"
- `utils/math_operations.py`に、数値のリストを入力として受け取り、その平均を返す`calculate_average`関数を追加してください。
- `frontend/src/components/UserProfile.tsx`の42行目で発生しているTypeErrorを修正してください。エラーは、undefinedのプロパティにアクセスしようとしていることを示唆しています。
- 登録フォームのメールフィールドに入力検証を実装してください。`frontend/src/components/RegistrationForm.tsx`を更新して、送信前にメールが有効な形式かどうかを確認するようにしてください。
### 悪いプロンプトの例
- "コードをもっと良くしてください。"（曖昧すぎる、具体性に欠ける）
- "バックエンド全体を別のフレームワークを使用するように書き換えてください。"（適切な範囲ではない）
- "ユーザー認証のどこかにバグがあります。見つけて修正できますか？"（具体性とロケーション情報に欠ける）
- コードを改善してください。（あまりにも曖昧で、具体性がない）
- バックエンド全体を別のフレームワークを使用して書き直してください。（範囲が適切でない）
- ユーザー認証のどこかにバグがあります。見つけて修正できますか？（具体性と場所の情報が不足）
## 効果的なプロンプトのためのヒント
- 望ましい結果や解決すべき問題について、できるだけ具体的に説明してください。
- 関連するファイルパスや行番号など、コンテキストを提供してください。
- 大きなタスクは、より小さく管理しやすいプロンプトに分割してください。
- 関連するエラーメッセージやログを含めてください。
- コンテキストから明らかでない場合は、プログラミング言語やフレームワークを指定してください。
- 望ましい結果や解決すべき問題について、できるだけ具体的に説明する。
- 関連するファイルパスや行番号など、可能であればコンテキストを提供する。
- 大きなタスクを小さく管理しやすいプロンプトに分割する。
- 関連するエラーメッセージやログを含める。
- プログラミング言語やフレームワークが明らかでない場合は、それを指定する。
プロンプトが正確で情報量が多いほど、AIはOpenHandsソフトウェアの開発や修正においてより良いサポートができることを覚えておいてください。
プロンプトが正確で情報量が多いほど、OpenHandsはより良くサポートできます。
役立つプロンプトの他の例については、[OpenHands入門](../getting-started)を参照してください。
役立つプロンプトの例については、[OpenHandsの使い方](../getting-started)をご覧ください。

29
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes-index.md
View File

@ -1,22 +1,25 @@
# ランタイム設定
ランタイムとは、OpenHands エージェントがファイルを編集したりコマンドを実行したりできる環境のことです。
:::note
このセクションは、OpenHandsでDockerとは異なるランタイムを使用したいユーザー向けです。
:::
デフォルトでは、OpenHands はローカルコンピュータ上で動作する Docker ベースのランタイムを使用します。
つまり、使用している LLM の料金のみを支払えばよく、コードが LLM に送信されるだけです。
ランタイムとは、OpenHandsエージェントがファイルを編集しコマンドを実行できる環境のことです。
また、通常はサードパーティが管理する「リモート」ランタイムもサポートしています。
特に多数の OpenHands 会話を並行して実行する場合（例えば評価を行う場合など）、セットアップがより簡単でスケーラブルになります。
デフォルトでは、OpenHandsはローカルコンピュータ上で動作する[Dockerベースのランタイム](./runtimes/docker)を使用します。
これにより、使用するLLMの費用のみを支払えば良く、コードはLLMにのみ送信されます。
さらに、Docker を使用せずに直接マシン上で実行される「ローカル」ランタイムも提供しており、
CI パイプラインのような制御された環境で役立ちます。
また、通常はサードパーティによって管理される他のランタイムもサポートしています。
さらに、Dockerを使わずにマシン上で直接実行する[ローカルランタイム](./runtimes/local)も提供しており、
CIパイプラインのような制御された環境で役立ちます。
## 利用可能なランタイム
OpenHands は以下のようなさまざまなランタイム環境をサポートしています。
OpenHandsはいくつかの異なるランタイム環境をサポートしています：
- [Docker ランタイム](./runtimes/docker.md) - 分離のために Docker コンテナを使用するデフォルトのランタイム（ほとんどのユーザーにお勧め）
- [OpenHands リモートランタイム](./runtimes/remote.md) - 並列実行用のクラウドベースのランタイム（ベータ版）
- [Modal ランタイム](./runtimes/modal.md) - パートナーである Modal 社が提供するランタイム
- [Daytona ランタイム](./runtimes/daytona.md) - Daytona 社が提供するランタイム
- [ローカルランタイム](./runtimes/local.md) - Docker を使用せずにローカルマシン上で直接実行
- [Dockerランタイム](./runtimes/docker.md) - 分離のためにDockerコンテナを使用するデフォルトのランタイム（ほとんどのユーザーに推奨）。
- [OpenHandsリモートランタイム](./runtimes/remote.md) - 並列実行のためのクラウドベースのランタイム（ベータ版）。
- [Modalランタイム](./runtimes/modal.md) - パートナーであるModalが提供するランタイム。
- [Daytonaランタイム](./runtimes/daytona.md) - Daytonaが提供するランタイム。
- [ローカルランタイム](./runtimes/local.md) - Dockerを使わずにローカルマシン上で直接実行。

4
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes.md
View File

@ -3,8 +3,6 @@ slug: /usage/runtimes
title: Runtime Configuration
---
Here is the translation in Japanese, preserving the code block and not translating the code:
import { Redirect } from '@docusaurus/router';
<Redirect to="/modules/usage/runtimes-index" />
<Redirect to="/modules/usage/runtimes-index" />

18
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes/daytona.md
View File

@ -9,24 +9,24 @@
4. キーが生成されたら、それをコピーします。
## ステップ 2: API キーを環境変数として設定する
ターミナルで以下のコマンドを実行し、`<your-api-key>` をコピーした実際のキーに置き換えます：
ターミナルで以下のコマンドを実行し、`<your-api-key>` をコピーした実際のキーに置き換えてください：
```bash
export DAYTONA_API_KEY="<your-api-key>"
```
このステップにより、OpenHands が実行されるときに Daytona プラットフォームで認証できるようになります。
このステップにより、OpenHandsが実行時にDaytonaプラットフォームで認証できるようになります。
## ステップ 3: Docker を使用してローカルで OpenHands を実行する
マシン上で最新バージョンの OpenHands を起動するには、ターミナルで次のコマンドを実行します：
## ステップ 3: Dockerを使用してOpenHandsをローカルで実行する
マシン上で最新バージョンのOpenHandsを起動するには、ターミナルで次のコマンドを実行します：
```bash
bash -i <(curl -sL https://get.daytona.io/openhands)
```
### このコマンドの動作：
- 最新の OpenHands リリーススクリプトをダウンロードします。
- インタラクティブな Bash セッションでスクリプトを実行します。
- Docker を使用して OpenHands コンテナを自動的にプルして実行します。
- 最新のOpenHandsリリーススクリプトをダウンロードします。
- インタラクティブなBashセッションでスクリプトを実行します。
- Dockerを使用してOpenHandsコンテナを自動的に取得して実行します。
実行すると、OpenHands がローカルで実行され、使用準備が整います。
実行すると、OpenHandsがローカルで実行され、使用準備が整います。
詳細と手動初期化については、[README.md](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/impl/daytona/README.md) 全体を参照してください。
詳細と手動初期化については、完全な[README.md](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/impl/daytona/README.md)をご覧ください。

105
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes/docker.md
View File

@ -1,56 +1,96 @@
# Docker ランタイム
# Dockerランタイム
これは、OpenHands を起動するときに使用されるデフォルトのランタイムです。
これは、OpenHandsを起動する際にデフォルトで使用されるランタイムです。
## イメージ
nikolaik の `SANDBOX_RUNTIME_CONTAINER_IMAGE` は、ランタイムサーバーと Python および NodeJS の基本的なユーティリティを含む事前ビルドされたランタイムイメージです。
nikolaikからの`SANDBOX_RUNTIME_CONTAINER_IMAGE`は、ランタイムサーバーと、PythonとNodeJSの基本的なユーティリティを含む事前ビルドされたランタイムイメージです。
[独自のランタイムイメージを構築する](../how-to/custom-sandbox-guide)こともできます。
## ファイルシステムへの接続
ここでの便利な機能の1つは、ローカルファイルシステムに接続する機能です。ファイルシステムをランタイムにマウントするには：
1. `WORKSPACE_BASE` を設定します：
便利な機能の一つは、ローカルファイルシステムに接続する機能です。ランタイムにファイルシステムをマウントするには：
### SANDBOX_VOLUMESの使用
ローカルファイルシステムをマウントする最も簡単な方法は、`SANDBOX_VOLUMES`環境変数を使用することです：
```bash
docker run # ...
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=/path/to/your/code:/workspace:rw \
# ...
```
`SANDBOX_VOLUMES`のフォーマットは：`host_path:container_path[:mode]`
- `host_path`：マウントしたいホストマシン上のパス
- `container_path`：ホストパスがマウントされるコンテナ内のパス
- エージェントに変更させたいファイルには`/workspace`を使用します。エージェントはデフォルトで`/workspace`で作業します。
- 読み取り専用の参照資料や大きなデータセットには、別のパス（例：`/data`）を使用します。
- `mode`：オプションのマウントモード、`rw`（読み書き、デフォルト）または`ro`（読み取り専用）
カンマ（`,`）で区切ることで、複数のマウントを指定することもできます：
```bash
export SANDBOX_VOLUMES=/path1:/workspace/path1,/path2:/workspace/path2:ro
```
例：
```bash
# LinuxとMacの例 - 書き込み可能なワークスペース
export SANDBOX_VOLUMES=$HOME/OpenHands:/workspace:rw
# Windows上のWSLの例 - 書き込み可能なワークスペース
export SANDBOX_VOLUMES=/mnt/c/dev/OpenHands:/workspace:rw
# 読み取り専用の参照コードの例
export SANDBOX_VOLUMES=/path/to/reference/code:/data:ro
# 複数マウントの例 - 書き込み可能なワークスペースと読み取り専用の参照データ
export SANDBOX_VOLUMES=$HOME/projects:/workspace:rw,/path/to/large/dataset:/data:ro
```
> **注意：** 複数のマウントを使用する場合、最初のマウントが主要なワークスペースと見なされ、単一のワークスペースを想定するツールとの後方互換性のために使用されます。
> **重要：** エージェントはデフォルトで`/workspace`で作業します。エージェントにローカルディレクトリ内のファイルを変更させたい場合は、そのディレクトリを`/workspace`にマウントする必要があります。エージェントにアクセスさせたいが変更させたくない読み取り専用データがある場合は、別のパス（`/data`など）にマウントし、エージェントにそこを見るよう明示的に指示してください。
### WORKSPACE_*変数の使用（非推奨）
> **注意：** この方法は非推奨であり、将来のバージョンで削除される予定です。代わりに`SANDBOX_VOLUMES`を使用してください。
1. `WORKSPACE_BASE`を設定します：
```bash
export WORKSPACE_BASE=/path/to/your/code
# Linux と Mac の例
# export WORKSPACE_BASE=$HOME/OpenHands
# $WORKSPACE_BASE を /home/<username>/OpenHands に設定します
#
# Windows の WSL の例
# export WORKSPACE_BASE=/mnt/c/dev/OpenHands
# $WORKSPACE_BASE を C:\dev\OpenHands に設定します
```
2. 以下のオプションを `docker run` コマンドに追加します：
2. `docker run`コマンドに以下のオプションを追加します：
```bash
docker run # ...
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
# ...
```
注意してください！OpenHands エージェントがワークスペースにマウントされたファイルを削除または変更することを妨げるものはありません。
注意してください！OpenHandsエージェントがワークスペースにマウントされたファイルを削除または変更することを防ぐものは何もありません。
このセットアップはファイルのアクセス権に関する問題を引き起こす可能性がありますが（そのため `SANDBOX_USER_ID` 変数があります）、ほとんどのシステムでうまく機能します。
`-e SANDBOX_USER_ID=$(id -u)`はDockerコマンドに渡され、サンドボックスユーザーがホストユーザーの権限と一致するようにします。これにより、エージェントがマウントされたワークスペースにroot所有のファイルを作成することを防ぎます。
## 強化された Docker インストール
## 強化されたDockerインストール
セキュリティが優先される環境に OpenHands をデプロイする場合は、強化された Docker 構成の実装を検討する必要があります。このセクションでは、デフォルト構成を超えて OpenHands Docker デプロイメントを保護するための推奨事項を提供します。
セキュリティが優先される環境でOpenHandsをデプロイする場合、強化されたDockerの設定を検討すべきです。このセクションでは、デフォルト設定を超えてOpenHandsのDockerデプロイメントを保護するための推奨事項を提供します。
### セキュリティに関する考慮事項
### セキュリティの考慮事項
README のデフォルトの Docker 構成は、ローカル開発マシンでの使いやすさを考慮して設計されています。公共ネットワーク（例：空港の WiFi）で実行している場合は、追加のセキュリティ対策を実装する必要があります。
READMEのデフォルトのDocker設定は、ローカル開発マシンでの使いやすさを考慮して設計されています。公共ネットワーク（例：空港のWiFi）で実行している場合は、追加のセキュリティ対策を実施する必要があります。
### ネットワークバインディングのセキュリティ
デフォルトでは、OpenHands はすべてのネットワークインターフェース（`0.0.0.0`）にバインドされ、ホストが接続しているすべてのネットワークにインスタンスが公開される可能性があります。より安全なセットアップのために：
デフォルトでは、OpenHandsはすべてのネットワークインターフェース（`0.0.0.0`）にバインドし、ホストが接続しているすべてのネットワークにインスタンスを公開する可能性があります。より安全な設定のために：
1. **ネットワークバインディングの制限**：
`runtime_binding_address` 構成を使用して、OpenHands がリッスンするネットワークインターフェースを制限します：
1. **ネットワークバインディングの制限**：`runtime_binding_address`設定を使用して、OpenHandsがリッスンするネットワークインターフェースを制限します：
```bash
docker run # ...
@ -58,29 +98,26 @@ README のデフォルトの Docker 構成は、ローカル開発マシンで
# ...
```
この構成により、OpenHands はループバックインターフェース（`127.0.0.1`）でのみリッスンし、ローカルマシンからのみアクセス可能になります。
この設定により、OpenHandsはループバックインターフェース（`127.0.0.1`）のみでリッスンし、ローカルマシンからのみアクセス可能になります。
2. **ポートバインディングの保護**：
`-p` フラグを変更して、すべてのインターフェースではなくローカルホストにのみバインドします：
2. **ポートバインディングの保護**：`-p`フラグを変更して、すべてのインターフェースではなくlocalhostにのみバインドします：
```bash
docker run # ... \
-p 127.0.0.1:3000:3000 \
```
これにより、OpenHands ウェブインターフェースはローカルマシンからのみアクセス可能になり、ネットワーク上の他のマシンからはアクセスできなくなります。
これにより、OpenHandsのWebインターフェースはローカルマシンからのみアクセス可能になり、ネットワーク上の他のマシンからはアクセスできなくなります。
### ネットワーク分離
Docker のネットワーク機能を使用して OpenHands を分離します：
Dockerのネットワーク機能を使用してOpenHandsを分離します：
```bash
# 分離されたネットワークを作成
docker network create openhands-network
# 分離されたネットワークで OpenHands を実行
# 分離されたネットワークでOpenHandsを実行
docker run # ... \
--network openhands-network \
docker.all-hands.dev/all-hands-ai/openhands:0.36
```
```

50
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes/local.md
View File

@ -1,62 +1,72 @@
# ローカルランタイム
ローカルランタイムを使用すると、OpenHands エージェントは Docker を使用せずに直接ローカルマシン上でアクションを実行できます。このランタイムは主に、Docker が利用できない CI パイプラインやテストシナリオなどの制御された環境向けです。
ローカルランタイムを使用すると、OpenHandsエージェントはDockerを使用せずに直接ローカルマシン上でアクションを実行できます。
このランタイムは主に、Dockerが利用できないCI（継続的インテグレーション）パイプラインやテストシナリオなどの制御された環境向けに設計されています。
:::caution
**セキュリティ警告**: ローカルランタイムはサンドボックス分離なしで実行されます。エージェントはマシン上のファイルに直接アクセスして変更できます。制御された環境でのみ、またはセキュリティへの影響を十分に理解している場合にのみ、このランタイムを使用してください。
**セキュリティ警告**: ローカルランタイムはサンドボックス分離なしで実行されます。エージェントはマシン上のファイルに直接アクセスして変更することができます。このランタイムは、制御された環境または安全性の影響を十分に理解している場合にのみ使用してください。
:::
## 前提条件
ローカルランタイムを使用する前に、以下を確認してください：
1. [開発セットアップ手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)に従っていること。
2. tmux がシステムで利用可能であること。
1. [開発ワークフロー](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)を使用してOpenHandsを実行できること。
2. システム上でtmuxが利用可能であること。
## 設定
ローカルランタイムを使用するには、モデル、API キーなどの必要な設定に加えて、OpenHands を起動するときに環境変数または[config.toml ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を介して以下のオプションを設定する必要があります：
ローカルランタイムを使用するには、LLMプロバイダー、モデル、APIキーなどの必要な設定に加えて、OpenHandsを起動する際に環境変数または[config.tomlファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を通じて以下のオプションを設定する必要があります：
- 環境変数を介して：
環境変数を使用する場合：
```bash
# 必須
export RUNTIME=local
# オプションですが推奨
export WORKSPACE_BASE=/path/to/your/workspace
# エージェントはデフォルトで/workspaceで作業するため、プロジェクトディレクトリをそこにマウントします
export SANDBOX_VOLUMES=/path/to/your/workspace:/workspace:rw
# 読み取り専用データの場合は、異なるマウントパスを使用します
# export SANDBOX_VOLUMES=/path/to/your/workspace:/workspace:rw,/path/to/large/dataset:/data:ro
```
- `config.toml` を介して：
`config.toml`を使用する場合：
```toml
[core]
runtime = "local"
workspace_base = "/path/to/your/workspace"
[sandbox]
# エージェントはデフォルトで/workspaceで作業するため、プロジェクトディレクトリをそこにマウントします
volumes = "/path/to/your/workspace:/workspace:rw"
# 読み取り専用データの場合は、異なるマウントパスを使用します
# volumes = "/path/to/your/workspace:/workspace:rw,/path/to/large/dataset:/data:ro"
```
`WORKSPACE_BASE` が設定されていない場合、ランタイムはエージェントが作業するための一時ディレクトリを作成します。
`SANDBOX_VOLUMES`が設定されていない場合、ランタイムはエージェントが作業するための一時ディレクトリを作成します。
## 使用例
以下は、ヘッドレスモードでローカルランタイムを使用して OpenHands を起動する例です：
以下は、ヘッドレスモードでローカルランタイムを使用してOpenHandsを起動する例です：
```bash
# ランタイムタイプをローカルに設定
# ランタイムタイプをlocalに設定
export RUNTIME=local
# オプションでワークスペースディレクトリを設定
export WORKSPACE_BASE=/path/to/your/project
# ワークスペースディレクトリを設定（エージェントはデフォルトで/workspaceで作業します）
export SANDBOX_VOLUMES=/path/to/your/project:/workspace:rw
# エージェントに変更させたくない読み取り専用データの場合は、異なるパスを使用します
# export SANDBOX_VOLUMES=/path/to/your/project:/workspace:rw,/path/to/reference/data:/data:ro
# OpenHands を起動
poetry run python -m openhands.core.main -t "hi と出力する bash スクリプトを書いてください"
# OpenHandsを起動
poetry run python -m openhands.core.main -t "write a bash script that prints hi"
```
## ユースケース
ローカルランタイムは特に以下の場合に役立ちます：
- Docker が利用できない CI/CD パイプライン。
- OpenHands 自体のテストと開発。
- コンテナの使用が制限されている環境。
- ファイルシステムへの直接アクセスが必要なシナリオ。
- Dockerが利用できないCI/CDパイプライン。
- OpenHands自体のテストと開発。
- コンテナの使用が制限されている環境。

10
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes/modal.md
View File

@ -1,13 +1,13 @@
# Modal ランタイム
[Modal](https://modal.com/) のパートナーが OpenHands 用のランタイムを提供しています。
[Modal](https://modal.com/)のパートナーがOpenHands用のランタイムを提供しています。
Modal ランタイムを使用するには、アカウントを作成し、[API キーを作成](https://modal.com/settings)してください。
Modal ランタイムを使用するには、アカウントを作成し、[APIキーを作成してください。](https://modal.com/settings)
その後、OpenHands を起動するときに以下の環境変数を設定する必要があります：
その後、OpenHandsを起動する際に以下の環境変数を設定する必要があります：
```bash
docker run # ...
-e RUNTIME=modal \
-e MODAL_API_TOKEN_ID="your-id" \
-e MODAL_API_TOKEN_SECRET="your-secret" \
```
-e MODAL_API_TOKEN_SECRET="modal-api-key" \
```

7
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/runtimes/remote.md
View File

@ -1,6 +1,7 @@
# OpenHands リモートランタイム
OpenHands リモートランタイムは現在ベータ版です（詳細は[こちら](https://runtime.all-hands.dev/)を参照）。クラウド内で並列にランタイムを起動することができます。
試してみたい場合は、[このフォーム](https://docs.google.com/forms/d/e/1FAIpQLSckVz_JFwg2_mOxNZjCtr7aoBFI2Mwdan3f75J_TrdMS1JV2g/viewform)に記入して申し込んでください！
:::note
このランタイムは、[OpenHands 評価ハーネス](https://github.com/All-Hands-AI/OpenHands/tree/main/evaluation)を通じたエージェント評価目的のみのために特別に設計されています。OpenHands アプリケーションの本番環境での起動には使用しないでください。
:::
注意：このランタイムは、[OpenHands 評価ハーネス](https://github.com/All-Hands-AI/OpenHands/tree/main/evaluation)を通じてのエージェント評価目的のみのために特別に設計されています。本番環境の OpenHands アプリケーションの起動には使用しないでください。
OpenHands リモートランタイムは現在ベータ版です（詳細は[こちら](https://runtime.all-hands.dev/)を参照）。これにより、クラウド上で並行してランタイムを起動することができます。試してみたい場合は、[このフォーム](https://docs.google.com/forms/d/e/1FAIpQLSckVz_JFwg2_mOxNZjCtr7aoBFI2Mwdan3f75J_TrdMS1JV2g/viewform)に記入して申し込んでください！

69
docs/i18n/ja/docusaurus-plugin-content-docs/current/usage/troubleshooting/troubleshooting.md
View File

@ -1,43 +1,68 @@
# 🚧 トラブルシューティング
:::tip
OpenHandsはWSL経由でのみWindowsをサポートしています。必ずWSLターミナル内でコマンドを実行してください。
OpenHandsはWindowsではWSL経由でのみサポートされています。すべてのコマンドはWSLターミナル内で実行してください。
:::
### ローカルIPを介してVS Codeタブにアクセスできない
**説明**
OpenHandsをlocalhostではないURL（LANのIPアドレスなど）を通じてアクセスすると、VS Codeタブに「Forbidden」エラーが表示されますが、UIの他の部分は正常に動作します。
**解決策**
これは、VS Codeがランダムな高ポートで実行され、他のマシンからアクセスできないか公開されていない可能性があるために発生します。修正するには：
1. `SANDBOX_VSCODE_PORT`環境変数を使用して、VS Code用の特定のポートを設定します：
```bash
docker run -it --rm \
-e SANDBOX_VSCODE_PORT=41234 \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:latest \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
-p 3000:3000 \
-p 41234:41234 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:latest
```
2. Dockerコマンドで同じポートを`-p 41234:41234`で公開していることを確認してください。
3. または、`config.toml`ファイルで設定することもできます：
```toml
[sandbox]
vscode_port = 41234
```
### Dockerクライアントの起動に失敗
**説明**
OpenHandsを実行する際に、以下のようなエラーが表示される:
OpenHandsを実行すると、次のエラーが表示されます：
```
Launch docker client failed. Please make sure you have installed docker and started docker desktop/daemon.
```
**解決策**
以下の順番で試してみてください:
* システム上で`docker`が実行されていることを確認します。ターミナルで`docker ps`が正常に実行できるはずです。
* Docker Desktopを使用している場合は、`Settings > Advanced > Allow the default Docker socket to be used`が有効になっていることを確認してください。
* 設定によっては、Docker Desktopで`Settings > Resources > Network > Enable host networking`を有効にする必要があるかもしれません。
* Docker Desktopを再インストールしてみてください。
---
以下を順番に試してください：
* システム上で`docker`が実行されていることを確認します。ターミナルで`docker ps`を正常に実行できるはずです。
* Docker Desktopを使用している場合は、`設定 > 詳細 > デフォルトのDockerソケットの使用を許可する`が有効になっていることを確認してください。
* 構成によっては、Docker Desktopの`設定 > リソース > ネットワーク > ホストネットワーキングを有効にする`を有効にする必要がある場合があります。
* Docker Desktopを再インストールしてください。
# 開発ワークフロー固有の問題
### runtimeのDockerイメージのビルドエラー
### 権限エラー
**説明**
新しいセッションの開始に失敗し、ログに以下のようなエラーが表示される:
```
debian-security bookworm-security
InRelease At least one invalid signature was encountered.
```
最初のプロンプトで、`Permission Denied`または`PermissionError`というエラーが表示されます。
これは、既存の外部ライブラリのハッシュが変更され、ローカルのDockerインスタンスが以前のバージョンをキャッシュしている場合に発生するようです。これを回避するには、以下を試してみてください:
**解決策**
* 名前が`openhands-runtime-`で始まるコンテナを停止します:
`docker ps --filter name=openhands-runtime- --filter status=running -aq | xargs docker stop`
* 名前が`openhands-runtime-`で始まるコンテナを削除します:
`docker rmi $(docker images --filter name=openhands-runtime- -q --no-trunc)`
* 名前が`openhands-runtime-`で始まるコンテナ/イメージを停止して削除します
* コンテナ/イメージをプルーンします: `docker container prune -f && docker image prune -f`
* `~/.openhands-state`が`root`によって所有されているかどうかを確認してください。もしそうなら：
* ディレクトリの所有権を変更します：`sudo chown <user>:<user> ~/.openhands-state`
* またはディレクトリの権限を更新します：`sudo chmod 777 ~/.openhands-state`
* または以前のデータが必要ない場合は削除します。OpenHandsは再作成します。LLM設定を再入力する必要があります。
* ローカルディレクトリをマウントしている場合は、`WORKSPACE_BASE`にOpenHandsを実行しているユーザーに必要な権限があることを確認してください。

14
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/about.md
View File

@ -2,24 +2,24 @@
## Estratégia de Pesquisa
Alcançar a replicação completa de aplicações de nível de produção com LLMs é um esforço complexo. Nossa estratégia envolve:
Alcançar a replicação completa de aplicações de nível de produção com LLMs é um empreendimento complexo. Nossa estratégia envolve:
- **Pesquisa Técnica Central:** Foco em pesquisa fundamental para entender e aprimorar os aspectos técnicos da geração e manipulação de código.
- **Planejamento de Tarefas:** Desenvolvimento de capacidades para detecção de bugs, gerenciamento de codebase e otimização.
- **Pesquisa Técnica Fundamental:** Foco em pesquisa fundamental para entender e melhorar os aspectos técnicos de geração e manipulação de código.
- **Planejamento de Tarefas:** Desenvolvimento de capacidades para detecção de bugs, gerenciamento de base de código e otimização.
- **Avaliação:** Estabelecimento de métricas de avaliação abrangentes para melhor entender e aprimorar nossos agentes.
## Agente Padrão
Nosso Agente padrão atualmente é o [CodeActAgent](agents), que é capaz de gerar código e lidar com arquivos.
Nosso Agente padrão é atualmente o [CodeActAgent](agents), que é capaz de gerar código e manipular arquivos.
## Construído Com
O OpenHands é construído usando uma combinação de poderosos frameworks e bibliotecas, fornecendo uma base robusta para seu desenvolvimento. Aqui estão as principais tecnologias usadas no projeto:
O OpenHands é construído usando uma combinação de frameworks e bibliotecas poderosas, fornecendo uma base robusta para seu desenvolvimento. Aqui estão as principais tecnologias utilizadas no projeto:
![FastAPI](https://img.shields.io/badge/FastAPI-black?style=for-the-badge) ![uvicorn](https://img.shields.io/badge/uvicorn-black?style=for-the-badge) ![LiteLLM](https://img.shields.io/badge/LiteLLM-black?style=for-the-badge) ![Docker](https://img.shields.io/badge/Docker-black?style=for-the-badge) ![Ruff](https://img.shields.io/badge/Ruff-black?style=for-the-badge) ![MyPy](https://img.shields.io/badge/MyPy-black?style=for-the-badge) ![LlamaIndex](https://img.shields.io/badge/LlamaIndex-black?style=for-the-badge) ![React](https://img.shields.io/badge/React-black?style=for-the-badge)
Por favor, note que a seleção dessas tecnologias está em andamento, e tecnologias adicionais podem ser adicionadas ou as existentes podem ser removidas à medida que o projeto evolui. Nós nos esforçamos para adotar as ferramentas mais adequadas e eficientes para aprimorar as capacidades do OpenHands.
Por favor, note que a seleção dessas tecnologias está em andamento, e tecnologias adicionais podem ser adicionadas ou as existentes podem ser removidas conforme o projeto evolui. Nós nos esforçamos para adotar as ferramentas mais adequadas e eficientes para aprimorar as capacidades do OpenHands.
## Licença
Distribuído sob a [Licença](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT.
Distribuído sob a [Licença](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) MIT.

11
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/agents.md
View File

@ -4,14 +4,15 @@
### Descrição
Este agente implementa a ideia do CodeAct ([artigo](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) que consolida as **ações** dos agentes LLM em um espaço de ação de **código** unificado para _simplicidade_ e _desempenho_.
Este agente implementa a ideia CodeAct ([artigo](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) que consolida as **aç**ões dos agentes LLM em um
espaço de ação de **código** unificado para obter tanto _simplicidade_ quanto _desempenho_.
A ideia conceitual é ilustrada abaixo. A cada turno, o agente pode:
1. **Conversar**: Comunicar-se com humanos em linguagem natural para pedir esclarecimentos, confirmações, etc.
2. **CodeAct**: Optar por executar a tarefa executando código
1. **Conversar**: Comunicar-se com humanos em linguagem natural para pedir esclarecimentos, confirmação, etc.
2. **CodeAct**: Escolher realizar a tarefa executando código
- Executar qualquer comando Linux `bash` válido
- Executar qualquer comando `bash` válido do Linux
- Executar qualquer código `Python` válido com [um interpretador Python interativo](https://ipython.org/). Isso é simulado através do comando `bash`, veja o sistema de plugins abaixo para mais detalhes.
![image](https://github.com/All-Hands-AI/OpenHands/assets/38853559/92b622e3-72ad-4a61-8f41-8c040b6d5fb3)
@ -20,4 +21,4 @@ A ideia conceitual é ilustrada abaixo. A cada turno, o agente pode:
https://github.com/All-Hands-AI/OpenHands/assets/38853559/f592a192-e86c-4f48-ad31-d69282d5f6ac
_Exemplo do CodeActAgent com `gpt-4-turbo-2024-04-09` realizando uma tarefa de ciência de dados (regressão linear)_.
_Exemplo do CodeActAgent com `gpt-4-turbo-2024-04-09` realizando uma tarefa de ciência de dados (regressão linear)_.

30
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/architecture/backend.mdx
View File

@ -1,16 +1,11 @@
# 🏛️ Arquitetura do Sistema
<div style={{ textAlign: 'center' }}>
<img
src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38"
alt="Diagrama da Arquitetura do Sistema OpenHands 4 de julho de 2024"
/>
<p>
<em>Diagrama da Arquitetura do Sistema OpenHands (4 de julho de 2024)</em>
</p>
<img src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38" alt="Diagrama de Arquitetura do OpenHands 4 de julho de 2024" />
<p><em>Diagrama de Arquitetura do OpenHands (4 de julho de 2024)</em></p>
</div>
Esta é uma visão geral de alto nível da arquitetura do sistema. O sistema é dividido em dois componentes principais: o frontend e o backend. O frontend é responsável por lidar com as interações do usuário e exibir os resultados. O backend é responsável por lidar com a lógica de negócios e executar os agentes.
Esta é uma visão geral de alto nível da arquitetura do sistema. O sistema está dividido em dois componentes principais: o frontend e o backend. O frontend é responsável por lidar com as interações do usuário e exibir os resultados. O backend é responsável por gerenciar a lógica de negócios e executar os agentes.
# Arquitetura do Frontend {#frontend-architecture-en}
@ -27,32 +22,33 @@ _**Aviso**: A arquitetura do backend é um trabalho em andamento e está sujeita
<details>
<summary>Atualizando este Diagrama</summary>
<div>
A geração do diagrama da arquitetura do backend é parcialmente automatizada.
O diagrama é gerado a partir das type hints no código usando a ferramenta py2puml.
O diagrama é então revisado manualmente, ajustado e exportado para PNG e SVG.
A geração do diagrama de arquitetura do backend é parcialmente automatizada.
O diagrama é gerado a partir das dicas de tipo no código usando a
ferramenta py2puml. O diagrama é então revisado manualmente, ajustado e exportado para PNG
e SVG.
## Pré-requisitos
- Ambiente python em execução no qual o openhands é executável
- Ambiente Python em execução no qual o openhands é executável
(de acordo com as instruções no arquivo README.md na raiz do repositório)
- [py2puml](https://github.com/lucsorel/py2puml) instalado
## Passos
1. Gere automaticamente o diagrama executando o seguinte comando na raiz do repositório:
1. Gere automaticamente o diagrama executando o seguinte comando a partir da raiz do repositório:
`py2puml openhands openhands > docs/architecture/backend_architecture.puml`
2. Abra o arquivo gerado em um editor PlantUML, por exemplo, Visual Studio Code com a extensão PlantUML ou [PlantText](https://www.planttext.com/)
3. Revise o PUML gerado e faça todos os ajustes necessários no diagrama (adicione partes ausentes, corrija erros, melhore o posicionamento).
_py2puml cria o diagrama com base nas type hints no código, portanto, type hints ausentes ou incorretas podem resultar em um diagrama incompleto ou incorreto._
3. Revise o PUML gerado e faça todos os ajustes necessários ao diagrama (adicione partes ausentes, corrija erros, melhore o posicionamento).
_py2puml cria o diagrama com base nas dicas de tipo no código, portanto, dicas de tipo ausentes ou incorretas podem resultar em um diagrama incompleto ou incorreto._
4. Revise a diferença entre o novo diagrama e o anterior e verifique manualmente se as alterações estão corretas.
_Certifique-se de não remover partes que foram adicionadas manualmente ao diagrama no passado e ainda são relevantes._
5. Adicione o hash do commit que foi usado para gerar o diagrama no rodapé do diagrama.
5. Adicione o hash do commit que foi usado para gerar o diagrama ao rodapé do diagrama.
6. Exporte o diagrama como arquivos PNG e SVG e substitua os diagramas existentes no diretório `docs/architecture`. Isso pode ser feito com (por exemplo, [PlantText](https://www.planttext.com/))
</div>
</details>
</details>

104
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/architecture/runtime.md
View File

@ -1,34 +1,34 @@
# 📦 Docker Runtime
O OpenHands Docker Runtime é o componente principal que permite a execução segura e flexível das ações do agente de IA.
Ele cria um ambiente isolado usando o Docker, onde código arbitrário pode ser executado com segurança sem arriscar o sistema host.
O Docker Runtime do OpenHands é o componente central que permite a execução segura e flexível das ações do agente de IA.
Ele cria um ambiente isolado (sandbox) usando Docker, onde código arbitrário pode ser executado com segurança sem colocar em risco o sistema host.
## Por que precisamos de um runtime isolado?
## Por que precisamos de um runtime em sandbox?
O OpenHands precisa executar código arbitrário em um ambiente seguro e isolado por várias razões:
1. Segurança: Executar código não confiável pode representar riscos significativos para o sistema host. Um ambiente isolado impede que código malicioso acesse ou modifique os recursos do sistema host
2. Consistência: Um ambiente isolado garante que a execução do código seja consistente em diferentes máquinas e configurações, eliminando problemas do tipo "funciona na minha máquina"
3. Controle de Recursos: O isolamento permite um melhor controle sobre a alocação e uso de recursos, evitando que processos descontrolados afetem o sistema host
1. Segurança: A execução de código não confiável pode representar riscos significativos para o sistema host. Um ambiente em sandbox impede que código malicioso acesse ou modifique os recursos do sistema host
2. Consistência: Um ambiente em sandbox garante que a execução do código seja consistente em diferentes máquinas e configurações, eliminando problemas do tipo "funciona na minha máquina"
3. Controle de Recursos: O sandbox permite um melhor controle sobre a alocação e uso de recursos, evitando que processos descontrolados afetem o sistema host
4. Isolamento: Diferentes projetos ou usuários podem trabalhar em ambientes isolados sem interferir uns com os outros ou com o sistema host
5. Reprodutibilidade: Ambientes isolados facilitam a reprodução de bugs e problemas, já que o ambiente de execução é consistente e controlável
5. Reprodutibilidade: Ambientes em sandbox facilitam a reprodução de bugs e problemas, já que o ambiente de execução é consistente e controlável
## Como o Runtime funciona?
## Como funciona o Runtime?
O sistema OpenHands Runtime usa uma arquitetura cliente-servidor implementada com contêineres Docker. Aqui está uma visão geral de como ele funciona:
O sistema Runtime do OpenHands usa uma arquitetura cliente-servidor implementada com contêineres Docker. Veja uma visão geral de como funciona:
```mermaid
graph TD
A[Imagem Docker Personalizada Fornecida pelo Usuário] --> B[Backend do OpenHands]
B -->|Constrói| C[Imagem do OH Runtime]
C -->|Inicia| D[Executor de Ação]
A[Imagem Docker Personalizada do Usuário] --> B[Backend OpenHands]
B -->|Constrói| C[Imagem OH Runtime]
C -->|Lança| D[Executor de Ações]
D -->|Inicializa| E[Navegador]
D -->|Inicializa| F[Shell Bash]
D -->|Inicializa| G[Plugins]
G -->|Inicializa| L[Servidor Jupyter]
B -->|Gera| H[Agente]
B -->|Gera| I[EventStream]
B -->|Cria| H[Agente]
B -->|Cria| I[EventStream]
I <--->|Executa Ação para
Obter Observação
via API REST
@ -47,40 +47,40 @@ graph TD
```
1. Entrada do Usuário: O usuário fornece uma imagem Docker base personalizada
2. Construção da Imagem: O OpenHands constrói uma nova imagem Docker (a "imagem do OH runtime") com base na imagem fornecida pelo usuário. Essa nova imagem inclui código específico do OpenHands, principalmente o "cliente de runtime"
3. Inicialização do Contêiner: Quando o OpenHands inicia, ele lança um contêiner Docker usando a imagem do OH runtime
4. Inicialização do Servidor de Execução de Ação: O servidor de execução de ação inicializa um `ActionExecutor` dentro do contêiner, configurando os componentes necessários, como um shell bash e carregando quaisquer plugins especificados
5. Comunicação: O backend do OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) se comunica com o servidor de execução de ação por meio de uma API RESTful, enviando ações e recebendo observações
6. Execução da Ação: O cliente de runtime recebe ações do backend, as executa no ambiente isolado e envia de volta as observações
7. Retorno da Observação: O servidor de execução de ação envia os resultados da execução de volta para o backend do OpenHands como observações
2. Construção da Imagem: O OpenHands constrói uma nova imagem Docker (a "imagem OH runtime") baseada na imagem fornecida pelo usuário. Esta nova imagem inclui código específico do OpenHands, principalmente o "cliente runtime"
3. Lançamento do Contêiner: Quando o OpenHands inicia, ele lança um contêiner Docker usando a imagem OH runtime
4. Inicialização do Servidor de Execução de Ações: O servidor de execução de ações inicializa um `ActionExecutor` dentro do contêiner, configurando componentes necessários como um shell bash e carregando quaisquer plugins especificados
5. Comunicação: O backend do OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) se comunica com o servidor de execução de ações através de API RESTful, enviando ações e recebendo observações
6. Execução de Ações: O cliente runtime recebe ações do backend, executa-as no ambiente sandbox e envia de volta as observações
7. Retorno de Observação: O servidor de execução de ações envia os resultados da execução de volta ao backend do OpenHands como observações
O papel do cliente:
- Ele atua como um intermediário entre o backend do OpenHands e o ambiente isolado
- Ele executa vários tipos de ações (comandos shell, operações de arquivo, código Python, etc.) com segurança dentro do contêiner
- Ele gerencia o estado do ambiente isolado, incluindo o diretório de trabalho atual e os plugins carregados
- Ele formata e retorna observações para o backend, garantindo uma interface consistente para processar os resultados
- Atua como intermediário entre o backend do OpenHands e o ambiente sandbox
- Executa vários tipos de ações (comandos shell, operações de arquivo, código Python, etc.) com segurança dentro do contêiner
- Gerencia o estado do ambiente sandbox, incluindo o diretório de trabalho atual e plugins carregados
- Formata e retorna observações para o backend, garantindo uma interface consistente para processamento de resultados
## Como o OpenHands constrói e mantém imagens do OH Runtime
## Como o OpenHands constrói e mantém imagens OH Runtime
A abordagem do OpenHands para construir e gerenciar imagens de runtime garante eficiência, consistência e flexibilidade na criação e manutenção de imagens Docker para ambientes de produção e desenvolvimento.
A abordagem do OpenHands para construir e gerenciar imagens runtime garante eficiência, consistência e flexibilidade na criação e manutenção de imagens Docker para ambientes de produção e desenvolvimento.
Confira o [código relevante](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py) se você estiver interessado em mais detalhes.
### Sistema de Tags de Imagem
### Sistema de Marcação de Imagens
O OpenHands usa um sistema de três tags para suas imagens de runtime para equilibrar reprodutibilidade com flexibilidade.
O OpenHands usa um sistema de três tags para suas imagens runtime para equilibrar reprodutibilidade com flexibilidade.
As tags podem estar em um dos 2 formatos:
- **Tag Versionada**: `oh_v{openhands_version}_{base_image}` (ex.: `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
- **Tag de Bloqueio**: `oh_v{openhands_version}_{16_digit_lock_hash}` (ex.: `oh_v0.9.9_1234567890abcdef`)
- **Tag de Origem**: `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
- **Tag de Fonte**: `oh_v{openhands_version}_{16_digit_lock_hash}_{16_digit_source_hash}`
(ex.: `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
#### Tag de Origem - Mais Específica
#### Tag de Fonte - Mais Específica
Estes são os primeiros 16 dígitos do MD5 do hash do diretório para o diretório de origem. Isso fornece um hash
apenas para o código-fonte do openhands
Esta é os primeiros 16 dígitos do MD5 do hash do diretório para o diretório fonte. Isso fornece um hash
apenas para o código fonte do openhands
#### Tag de Bloqueio
@ -90,7 +90,7 @@ Este hash é construído a partir dos primeiros 16 dígitos do MD5 de:
- O conteúdo do `pyproject.toml` incluído na imagem.
- O conteúdo do `poetry.lock` incluído na imagem.
Isso efetivamente fornece um hash para as dependências do Openhands independente do código-fonte.
Isso efetivamente fornece um hash para as dependências do Openhands independente do código fonte.
#### Tag Versionada - Mais Genérica
@ -100,35 +100,35 @@ Esta tag é uma concatenação da versão do openhands e do nome da imagem base
Ao gerar uma imagem...
- **Sem reconstrução**: O OpenHands primeiro verifica se existe uma imagem com a mesma **tag de origem mais específica**. Se houver tal imagem,
- **Sem reconstrução**: O OpenHands primeiro verifica se existe uma imagem com a mesma **tag de fonte mais específica**. Se existir tal imagem,
nenhuma construção é realizada - a imagem existente é usada.
- **Reconstrução mais rápida**: O OpenHands verifica em seguida se existe uma imagem com a **tag de bloqueio genérica**. Se houver tal imagem,
o OpenHands constrói uma nova imagem com base nela, ignorando todas as etapas de instalação (como `poetry install` e
`apt-get`), exceto uma operação final para copiar o código-fonte atual. A nova imagem é marcada apenas com uma
tag de **origem**.
- **Reconstrução razoável**: Se não existir uma tag de **origem** nem de **bloqueio**, uma imagem será construída com base na imagem com tag **versionada**.
Na imagem com tag versionada, a maioria das dependências já deve estar instalada, economizando tempo.
- **Reconstrução mais lenta**: Se todas as três tags não existirem, uma nova imagem é construída com base na imagem
base (o que é uma operação mais lenta). Esta nova imagem é marcada com todas as tags de **origem**, **bloqueio** e **versionada**.
- **Reconstrução mais rápida**: O OpenHands verifica em seguida se existe uma imagem com a **tag de bloqueio genérica**. Se existir tal imagem,
o OpenHands constrói uma nova imagem baseada nela, ignorando todas as etapas de instalação (como `poetry install` e
`apt-get`) exceto uma operação final para copiar o código fonte atual. A nova imagem é marcada apenas com uma
tag de **fonte**.
- **Reconstrução razoável**: Se nem uma tag de **fonte** nem de **bloqueio** existir, uma imagem será construída com base na imagem de tag **versionada**.
Na imagem de tag versionada, a maioria das dependências já deve estar instalada, economizando tempo.
- **Reconstrução mais lenta**: Se todas as três tags não existirem, uma imagem totalmente nova é construída com base na imagem
base (o que é uma operação mais lenta). Esta nova imagem é marcada com todas as tags de **fonte**, **bloqueio** e **versionada**.
Essa abordagem de tags permite que o OpenHands gerencie com eficiência ambientes de desenvolvimento e produção.
Esta abordagem de marcação permite que o OpenHands gerencie eficientemente ambientes de desenvolvimento e produção.
1. Código-fonte e Dockerfile idênticos sempre produzem a mesma imagem (via tags baseadas em hash)
2. O sistema pode reconstruir rapidamente imagens quando ocorrem pequenas alterações (aproveitando imagens compatíveis recentes)
3. A tag de **bloqueio** (ex.: `runtime:oh_v0.9.3_1234567890abcdef`) sempre aponta para a construção mais recente para uma combinação específica de imagem base, dependência e versão do OpenHands
1. Código fonte idêntico e Dockerfile sempre produzem a mesma imagem (via tags baseadas em hash)
2. O sistema pode reconstruir rapidamente imagens quando ocorrem mudanças menores (aproveitando imagens compatíveis recentes)
3. A tag de **bloqueio** (ex., `runtime:oh_v0.9.3_1234567890abcdef`) sempre aponta para a construção mais recente para uma combinação específica de imagem base, dependência e versão do OpenHands
## Sistema de Plugins do Runtime
O OpenHands Runtime suporta um sistema de plugins que permite estender a funcionalidade e personalizar o ambiente de runtime. Os plugins são inicializados quando o cliente de runtime é iniciado.
O Runtime do OpenHands suporta um sistema de plugins que permite estender a funcionalidade e personalizar o ambiente de runtime. Os plugins são inicializados quando o cliente runtime é iniciado.
Confira [um exemplo do plugin Jupyter aqui](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55) se você quiser implementar seu próprio plugin.
Confira [um exemplo de plugin Jupyter aqui](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55) se você quiser implementar seu próprio plugin.
_Mais detalhes sobre o sistema de Plugins ainda estão em construção - contribuições são bem-vindas!_
*Mais detalhes sobre o sistema de Plugins ainda estão em construção - contribuições são bem-vindas!*
Aspectos-chave do sistema de plugins:
1. Definição de Plugin: Os plugins são definidos como classes Python que herdam de uma classe base `Plugin`
2. Registro de Plugin: Os plugins disponíveis são registrados em um dicionário `ALL_PLUGINS`
3. Especificação de Plugin: Os plugins são associados a `Agent.sandbox_plugins: list[PluginRequirement]`. Os usuários podem especificar quais plugins carregar ao inicializar o runtime
4. Inicialização: Os plugins são inicializados de forma assíncrona quando o cliente de runtime é iniciado
5. Uso: O cliente de runtime pode usar plugins inicializados para estender suas capacidades (por exemplo, o JupyterPlugin para executar células IPython)
3. Especificação de Plugin: Os plugins são associados com `Agent.sandbox_plugins: list[PluginRequirement]`. Os usuários podem especificar quais plugins carregar ao inicializar o runtime
4. Inicialização: Os plugins são inicializados de forma assíncrona quando o cliente runtime inicia
5. Uso: O cliente runtime pode usar plugins inicializados para estender suas capacidades (ex., o JupyterPlugin para executar células IPython)

177
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/cloud/cloud-api.md Normal file
View File

@ -0,0 +1,177 @@
# API da OpenHands Cloud
A OpenHands Cloud fornece uma API REST que permite interagir programaticamente com o serviço. Isso é útil se você deseja iniciar facilmente seus próprios trabalhos a partir de seus programas de maneira flexível.
Este guia explica como obter uma chave de API e usar a API para iniciar conversas.
Para informações mais detalhadas sobre a API, consulte a [Referência da API OpenHands](https://docs.all-hands.dev/swagger-ui/).
## Obtendo uma Chave de API
Para usar a API da OpenHands Cloud, você precisará gerar uma chave de API:
1. Faça login na sua conta [OpenHands Cloud](https://app.all-hands.dev)
2. Navegue até a [página de Configurações](https://app.all-hands.dev/settings)
3. Localize a seção "API Keys"
4. Clique em "Generate New Key"
5. Dê à sua chave um nome descritivo (ex: "Desenvolvimento", "Produção")
6. Copie a chave de API gerada e armazene-a com segurança - ela será mostrada apenas uma vez
![Geração de Chave de API](/img/docs/api-key-generation.png)
## Uso da API
### Iniciando uma Nova Conversa
Para iniciar uma nova conversa com a OpenHands realizando uma tarefa, você precisará fazer uma requisição POST para o endpoint de conversas.
#### Parâmetros da Requisição
| Parâmetro | Tipo | Obrigatório | Descrição |
|-----------|------|-------------|-----------|
| `initial_user_msg` | string | Sim | A mensagem inicial para começar a conversa |
| `repository` | string | Não | Nome do repositório Git para fornecer contexto no formato `proprietário/repo`. Você deve ter acesso ao repositório. |
#### Exemplos
<details>
<summary>cURL</summary>
```bash
curl -X POST "https://app.all-hands.dev/api/conversations" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}'
```
</details>
<details>
<summary>Python (com requests)</summary>
```python
import requests
api_key = "YOUR_API_KEY"
url = "https://app.all-hands.dev/api/conversations"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
data = {
"initial_user_msg": "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
"repository": "yourusername/your-repo"
}
response = requests.post(url, headers=headers, json=data)
conversation = response.json()
print(f"Conversation Link: https://app.all-hands.dev/conversations/{conversation['id']}")
print(f"Status: {conversation['status']}")
```
</details>
<details>
<summary>TypeScript/JavaScript (com fetch)</summary>
```typescript
const apiKey = "YOUR_API_KEY";
const url = "https://app.all-hands.dev/api/conversations";
const headers = {
"Authorization": `Bearer ${apiKey}`,
"Content-Type": "application/json"
};
const data = {
initial_user_msg: "Check whether there is any incorrect information in the README.md file and send a PR to fix it if so.",
repository: "yourusername/your-repo"
};
async function startConversation() {
try {
const response = await fetch(url, {
method: "POST",
headers: headers,
body: JSON.stringify(data)
});
const conversation = await response.json();
console.log(`Conversation Link: https://app.all-hands.dev/conversations/${conversation.id}`);
console.log(`Status: ${conversation.status}`);
return conversation;
} catch (error) {
console.error("Error starting conversation:", error);
}
}
startConversation();
```
</details>
#### Resposta
A API retornará um objeto JSON com detalhes sobre a conversa criada:
```json
{
"status": "ok",
"conversation_id": "abc1234",
}
```
Você também pode receber um `AuthenticationError` se:
1. Você forneceu uma chave de API inválida
2. Você forneceu o nome do repositório errado
3. Você não tem acesso ao repositório
### Recuperando o Status da Conversa
Você pode verificar o status de uma conversa fazendo uma requisição GET para o endpoint de conversas.
#### Endpoint
```
GET https://app.all-hands.dev/api/conversations/{conversation_id}
```
#### Exemplo
<details>
<summary>cURL</summary>
```bash
curl -X GET "https://app.all-hands.dev/api/conversations/{conversation_id}" \
-H "Authorization: Bearer YOUR_API_KEY"
```
</details>
#### Resposta
A resposta é formatada da seguinte forma:
```json
{
"conversation_id":"abc1234",
"title":"Update README.md",
"created_at":"2025-04-29T15:13:51.370706Z",
"last_updated_at":"2025-04-29T15:13:57.199210Z",
"status":"RUNNING",
"selected_repository":"yourusername/your-repo",
"trigger":"gui"
}
```
## Limites de Taxa
A API tem um limite de 10 conversas simultâneas por conta. Se você precisar de um limite maior para seu caso de uso, entre em contato conosco em [contact@all-hands.dev](mailto:contact@all-hands.dev).
Se você exceder esse limite, a API retornará uma resposta 429 Too Many Requests.

32
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/cloud/cloud-github-resolver.md
View File

@ -1,33 +1,33 @@
Here is the translation to Brazilian Portuguese:
# Resolvedor GitHub na Nuvem
# GitHub Cloud Resolver
O GitHub Cloud Resolver automatiza correções de código e fornece assistência inteligente para seus repositórios.
O Resolvedor GitHub automatiza correções de código e fornece assistência inteligente para seus repositórios.
## Configuração
O Resolvedor do GitHub na Nuvem está disponível automaticamente quando você
[concede acesso ao repositório do OpenHands Cloud](./openhands-cloud#adding-repository-access).
O Resolvedor GitHub na Nuvem está disponível automaticamente quando você
[concede acesso de repositório ao OpenHands Cloud](./openhands-cloud#adding-repository-access).
## Uso
Após conceder acesso ao repositório do OpenHands Cloud, você pode usar o Resolvedor do GitHub na Nuvem nos problemas e pull requests
Após conceder acesso de repositório ao OpenHands Cloud, você pode usar o Resolvedor GitHub na Nuvem nos problemas e pull requests
do repositório.
### Issues
### Problemas (Issues)
No seu repositório, rotule um issue com `openhands`. O OpenHands irá:
No seu repositório, rotule um problema com `openhands`. O OpenHands irá:
1. Comentar no problema para informar que está trabalhando nele.
- Você pode clicar no link para acompanhar o progresso no OpenHands Cloud.
2. Abrir um pull request se determinar que o problema foi resolvido com sucesso.
3. Comentar no problema com um resumo das tarefas realizadas e um link para o pull request.
1. Comentar no issue para informar que está trabalhando nele.
- Você pode clicar no link para acompanhar o progresso no OpenHands Cloud.
2. Abrir um pull request se determinar que o issue foi resolvido com sucesso.
3. Comentar no issue com um resumo das tarefas realizadas e um link para o pull request.
### Pull Requests
Para fazer o OpenHands trabalhar em pull requests, use `@openhands` em comentários de nível superior ou inline para: - Fazer perguntas - Solicitar atualizações - Obter explicações de código
Para fazer o OpenHands trabalhar em pull requests, use `@openhands` em comentários de nível superior ou em linha para:
- Fazer perguntas
- Solicitar atualizações
- Obter explicações de código
O OpenHands irá:
1. Comentar no PR para informar que está trabalhando nele.
2. Realizar a tarefa.
2. Realizar a tarefa.

65
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/cloud/openhands-cloud.mdx Normal file
View File

@ -0,0 +1,65 @@
# Openhands Cloud
OpenHands Cloud é a versão hospedada na nuvem do OpenHands pela All Hands AI.
## Acessando o OpenHands Cloud
O OpenHands Cloud pode ser acessado em https://app.all-hands.dev/.
Você também pode interagir com o OpenHands Cloud programaticamente usando a [API](./cloud-api).
## Primeiros Passos
Ao visitar o OpenHands Cloud, você será solicitado a conectar-se com sua conta GitHub ou GitLab:
1. Após ler e aceitar os termos de serviço, clique em `Log in with GitHub` ou `Log in with GitLab`.
2. Revise as permissões solicitadas pelo OpenHands e então clique em `Authorize OpenHands AI`.
- O OpenHands precisará de algumas permissões da sua conta GitHub ou GitLab. Para ler mais sobre essas permissões:
- GitHub: Você pode clicar no link `Learn more` na página de autorização do GitHub.
- GitLab: Você pode expandir cada solicitação de permissão na página de autorização do GitLab.
## Acesso ao Repositório
### GitHub
#### Adicionando Acesso ao Repositório
Você pode conceder ao OpenHands acesso específico ao repositório:
1. Clique em `Add GitHub repos` na página inicial.
2. Selecione a organização e, em seguida, escolha os repositórios específicos para conceder acesso ao OpenHands.
<details>
<summary>Detalhes de Permissão para Acesso ao Repositório</summary>
O Openhands solicita tokens de curta duração (expiração de 8 horas) com estas permissões:
- Actions: Leitura e escrita
- Administration: Somente leitura
- Commit statuses: Leitura e escrita
- Contents: Leitura e escrita
- Issues: Leitura e escrita
- Metadata: Somente leitura
- Pull requests: Leitura e escrita
- Webhooks: Leitura e escrita
- Workflows: Leitura e escrita
O acesso ao repositório para um usuário é concedido com base em:
- Permissão concedida para o repositório.
- Permissões do GitHub do usuário (proprietário/colaborador).
</details>
3. Clique em `Install & Authorize`.
#### Modificando o Acesso ao Repositório
Você pode modificar o acesso ao repositório do GitHub a qualquer momento:
* Usando o mesmo fluxo de trabalho `Add GitHub repos`, ou
* Visitando a página de Configurações e selecionando `Configure GitHub Repositories` na seção `Git Settings`.
### GitLab
Ao usar sua conta GitLab, o OpenHands terá automaticamente acesso aos seus repositórios.
## Persistência de Conversas
- Lista de Conversas – Exibe apenas as 10 conversas mais recentes iniciadas nos últimos 10 dias.
- Workspaces – Os workspaces de conversas são mantidos por 14 dias.
- Runtimes – Os runtimes permanecem ativos ("aquecidos") por 30 minutos. Após esse período, retomar uma conversa pode levar de 1 a 2 minutos.

124
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/configuration-options.md
View File

@ -1,14 +1,13 @@
# Opções de Configuração
Este guia detalha todas as opções de configuração disponíveis para o OpenHands, ajudando você a personalizar seu comportamento e integrá-lo com outros serviços.
:::note
Se você estiver executando no [Modo GUI](https://docs.all-hands.dev/modules/usage/how-to/gui-mode), as configurações disponíveis na UI de Configurações sempre terão precedência.
Esta página descreve todas as opções de configuração disponíveis para o OpenHands, permitindo que você personalize seu comportamento e
o integre com outros serviços. No Modo GUI, quaisquer configurações aplicadas através da interface de Configurações terão precedência.
:::
## Configuração Principal
As opções de configuração principais são definidas na seção `[core]` do arquivo `config.toml`.
As opções de configuração principal são definidas na seção `[core]` do arquivo `config.toml`.
### Chaves de API
- `e2b_api_key`
@ -26,38 +25,38 @@ As opções de configuração principais são definidas na seção `[core]` do a
- Padrão: `""`
- Descrição: Segredo do token de API para Modal
### Workspace
- `workspace_base`
### Espaço de Trabalho
- `workspace_base` **(Obsoleto)**
- Tipo: `str`
- Padrão: `"./workspace"`
- Descrição: Caminho base para o workspace
- Descrição: Caminho base para o espaço de trabalho. **Obsoleto: Use `SANDBOX_VOLUMES` em vez disso.**
- `cache_dir`
- Tipo: `str`
- Padrão: `"/tmp/cache"`
- Descrição: Caminho do diretório de cache
### Depuração e Log
### Depuração e Registro
- `debug`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Habilitar depuração
- Descrição: Ativar depuração
- `disable_color`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Desabilitar cor na saída do terminal
- Descrição: Desativar cores na saída do terminal
### Trajetórias
- `save_trajectory_path`
- Tipo: `str`
- Padrão: `"./trajectories"`
- Descrição: Caminho para armazenar trajetórias (pode ser uma pasta ou um arquivo). Se for uma pasta, as trajetórias serão salvas em um arquivo nomeado com o nome do id da sessão e extensão .json, nessa pasta.
- Descrição: Caminho para armazenar trajetórias (pode ser uma pasta ou um arquivo). Se for uma pasta, as trajetórias serão salvas em um arquivo nomeado com o ID da sessão e extensão .json, nessa pasta.
- `replay_trajectory_path`
- Tipo: `str`
- Padrão: `""`
- Descrição: Caminho para carregar uma trajetória e reproduzir. Se fornecido, deve ser um caminho para o arquivo de trajetória no formato JSON. As ações no arquivo de trajetória seriam reproduzidas primeiro antes de qualquer instrução do usuário ser executada.
- Descrição: Caminho para carregar uma trajetória e reproduzir. Se fornecido, deve ser um caminho para o arquivo de trajetória em formato JSON. As ações no arquivo de trajetória serão reproduzidas primeiro antes que qualquer instrução do usuário seja executada.
### Armazenamento de Arquivos
- `file_store_path`
@ -71,7 +70,7 @@ As opções de configuração principais são definidas na seção `[core]` do a
- Descrição: Tipo de armazenamento de arquivos
- `file_uploads_allowed_extensions`
- Tipo: `list of str`
- Tipo: `lista de str`
- Padrão: `[".*"]`
- Descrição: Lista de extensões de arquivo permitidas para uploads
@ -86,7 +85,7 @@ As opções de configuração principais são definidas na seção `[core]` do a
- Descrição: Restringir tipos de arquivo para uploads de arquivos
- `file_uploads_allowed_extensions`
- Tipo: `list of str`
- Tipo: `lista de str`
- Padrão: `[".*"]`
- Descrição: Lista de extensões de arquivo permitidas para uploads
@ -101,21 +100,26 @@ As opções de configuração principais são definidas na seção `[core]` do a
- Padrão: `100`
- Descrição: Número máximo de iterações
### Configuração do Sandbox
- `workspace_mount_path_in_sandbox`
### Configuração da Sandbox
- `volumes`
- Tipo: `str`
- Padrão: `None`
- Descrição: Montagens de volume no formato 'caminho_host:caminho_container[:modo]', ex. '/meu/dir/host:/workspace:rw'. Múltiplas montagens podem ser especificadas usando vírgulas, ex. '/caminho1:/workspace/caminho1,/caminho2:/workspace/caminho2:ro'
- `workspace_mount_path_in_sandbox` **(Obsoleto)**
- Tipo: `str`
- Padrão: `"/workspace"`
- Descrição: Caminho para montar o workspace no sandbox
- Descrição: Caminho para montar o espaço de trabalho na sandbox. **Obsoleto: Use `SANDBOX_VOLUMES` em vez disso.**
- `workspace_mount_path`
- `workspace_mount_path` **(Obsoleto)**
- Tipo: `str`
- Padrão: `""`
- Descrição: Caminho para montar o workspace
- Descrição: Caminho para montar o espaço de trabalho. **Obsoleto: Use `SANDBOX_VOLUMES` em vez disso.**
- `workspace_mount_rewrite`
- `workspace_mount_rewrite` **(Obsoleto)**
- Tipo: `str`
- Padrão: `""`
- Descrição: Caminho para reescrever o caminho de montagem do workspace. Você geralmente pode ignorar isso, refere-se a casos especiais de execução dentro de outro contêiner.
- Descrição: Caminho para reescrever o caminho de montagem do espaço de trabalho. Você geralmente pode ignorar isso, refere-se a casos especiais de execução dentro de outro contêiner. **Obsoleto: Use `SANDBOX_VOLUMES` em vez disso.**
### Diversos
- `run_as_openhands`
@ -142,10 +146,10 @@ As opções de configuração principais são definidas na seção `[core]` do a
As opções de configuração do LLM (Large Language Model) são definidas na seção `[llm]` do arquivo `config.toml`.
Para usá-las com o comando docker, passe `-e LLM_<opção>`. Exemplo: `-e LLM_NUM_RETRIES`.
Para usar estas com o comando docker, passe `-e LLM_<opção>`. Exemplo: `-e LLM_NUM_RETRIES`.
:::note
Para configurações de desenvolvimento, você também pode definir configurações de LLM personalizadas nomeadas. Veja [Configurações Personalizadas de LLM](./llms/custom-llm-configs) para detalhes.
Para configurações de desenvolvimento, você também pode definir configurações de LLM personalizadas com nomes. Veja [Configurações Personalizadas de LLM](./llms/custom-llm-configs) para detalhes.
:::
**Credenciais AWS**
@ -162,7 +166,7 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- `aws_secret_access_key`
- Tipo: `str`
- Padrão: `""`
- Descrição: Chave secreta de acesso AWS
- Descrição: Chave de acesso secreta AWS
### Configuração da API
- `api_key`
@ -190,14 +194,13 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- Padrão: `0.0`
- Descrição: Custo por token de saída
### Provedor LLM Personalizado
### Provedor de LLM Personalizado
- `custom_llm_provider`
- Tipo: `str`
- Padrão: `""`
- Descrição: Provedor LLM personalizado
- Descrição: Provedor de LLM personalizado
### Tratamento de Mensagens
### Manipulação de Mensagens
- `max_message_chars`
- Tipo: `int`
- Padrão: `30000`
@ -219,7 +222,7 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- Padrão: `"claude-3-5-sonnet-20241022"`
- Descrição: Modelo a ser usado
### Tentativas
### Repetição de Tentativas
- `num_retries`
- Tipo: `int`
- Padrão: `8`
@ -238,7 +241,7 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- `retry_multiplier`
- Tipo: `float`
- Padrão: `2.0`
- Descrição: Multiplicador para cálculo de backoff exponencial
- Descrição: Multiplicador para cálculo de recuo exponencial
### Opções Avançadas
- `drop_params`
@ -264,7 +267,7 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- `timeout`
- Tipo: `int`
- Padrão: `0`
- Descrição: Timeout para a API
- Descrição: Tempo limite para a API
- `top_p`
- Tipo: `float`
@ -274,19 +277,19 @@ Para configurações de desenvolvimento, você também pode definir configuraç
- `disable_vision`
- Tipo: `bool`
- Padrão: `None`
- Descrição: Se o modelo é capaz de visão, esta opção permite desabilitar o processamento de imagem (útil para redução de custo)
- Descrição: Se o modelo for capaz de visão, esta opção permite desativar o processamento de imagens (útil para redução de custos)
## Configuração do Agente
As opções de configuração do agente são definidas nas seções `[agent]` e `[agent.<agent_name>]` do arquivo `config.toml`.
As opções de configuração do agente são definidas nas seções `[agent]` e `[agent.<nome_do_agente>]` do arquivo `config.toml`.
### Configuração do LLM
- `llm_config`
- Tipo: `str`
- Padrão: `'your-llm-config-group'`
- Descrição: O nome da configuração LLM a ser usada
- Descrição: O nome da configuração de LLM a ser usada
### Configuração do Espaço de Ação
### Configuração do Espaço de Ações
- `function_calling`
- Tipo: `bool`
- Padrão: `true`
@ -295,22 +298,22 @@ As opções de configuração do agente são definidas nas seções `[agent]` e
- `enable_browsing`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Se o delegado de navegação está habilitado no espaço de ação (funciona apenas com chamada de função)
- Descrição: Se o delegado de navegação está habilitado no espaço de ações (funciona apenas com chamada de função)
- `enable_llm_editor`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Se o editor LLM está habilitado no espaço de ação (funciona apenas com chamada de função)
- Descrição: Se o editor LLM está habilitado no espaço de ações (funciona apenas com chamada de função)
- `enable_jupyter`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Se o Jupyter está habilitado no espaço de ação
- Descrição: Se o Jupyter está habilitado no espaço de ações
- `enable_history_truncation`
- Tipo: `bool`
- Padrão: `true`
- Descrição: Se o histórico deve ser truncado para continuar a sessão ao atingir o limite de comprimento de contexto do LLM
- Descrição: Se o histórico deve ser truncado para continuar a sessão quando atingir o limite de comprimento de contexto do LLM
### Uso de Microagentes
- `enable_prompt_extensions`
@ -319,49 +322,49 @@ As opções de configuração do agente são definidas nas seções `[agent]` e
- Descrição: Se deve usar microagentes
- `disabled_microagents`
- Tipo: `list of str`
- Tipo: `lista de str`
- Padrão: `None`
- Descrição: Uma lista de microagentes a serem desabilitados
- Descrição: Uma lista de microagentes para desativar
## Configuração do Sandbox
## Configuração da Sandbox
As opções de configuração do sandbox são definidas na seção `[sandbox]` do arquivo `config.toml`.
As opções de configuração da sandbox são definidas na seção `[sandbox]` do arquivo `config.toml`.
Para usá-las com o comando docker, passe `-e SANDBOX_<opção>`. Exemplo: `-e SANDBOX_TIMEOUT`.
Para usar estas com o comando docker, passe `-e SANDBOX_<opção>`. Exemplo: `-e SANDBOX_TIMEOUT`.
### Execução
- `timeout`
- Tipo: `int`
- Padrão: `120`
- Descrição: Timeout do sandbox em segundos
- Descrição: Tempo limite da sandbox em segundos
- `user_id`
- Tipo: `int`
- Padrão: `1000`
- Descrição: ID do usuário do sandbox
- Descrição: ID de usuário da sandbox
### Imagem do Contêiner
- `base_container_image`
- Tipo: `str`
- Padrão: `"nikolaik/python-nodejs:python3.12-nodejs22"`
- Descrição: Imagem do contêiner a ser usada para o sandbox
- Descrição: Imagem do contêiner a ser usada para a sandbox
### Rede
- `use_host_network`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Usar a rede do host
- Descrição: Usar rede do host
- `runtime_binding_address`
- Tipo: `str`
- Padrão: `0.0.0.0`
- Descrição: O endereço de ligação para as portas de tempo de execução. Especifica em qual interface de rede na máquina host o Docker deve ligar as portas de tempo de execução.
- Descrição: O endereço de vinculação para as portas de runtime. Especifica qual interface de rede na máquina host o Docker deve vincular as portas de runtime.
### Linting e Plugins
- `enable_auto_lint`
- Tipo: `bool`
- Padrão: `false`
- Descrição: Habilitar linting automático após a edição
- Descrição: Habilitar linting automático após edição
- `initialize_plugins`
- Tipo: `bool`
@ -372,25 +375,8 @@ Para usá-las com o comando docker, passe `-e SANDBOX_<opção>`. Exemplo: `-e S
- `runtime_extra_deps`
- Tipo: `str`
- Padrão: `""`
- Descrição: Dependências extras a serem instaladas na imagem de tempo de execução
- Descrição: Dependências extras para instalar na imagem de runtime
- `runtime_startup_env_vars`
- Tipo: `dict`
- Padrão: `{}`
- Descrição: Variáveis de ambiente a serem definidas no lançamento do tempo de execução
### Avaliação
- `browsergym_eval_env`
- Tipo: `str`
- Padrão: `""`
- Descrição: Ambiente BrowserGym a ser usado para avaliação
## Configuração de Segurança
As opções de configuração de segurança são definidas na seção `[security]` do arquivo `config.toml`.
Para usá-las com o comando docker, passe `-e SECURITY_<opção>`. Exemplo: `-e SECURITY_CONFIRMATION_MODE`.
### Modo de Confirmação
- `confirmation_mode`
- Tipo
- Padr

23
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/customization/repository.md Normal file
View File

@ -0,0 +1,23 @@
# Personalização do Repositório
Você pode personalizar como o OpenHands interage com seu repositório criando um
diretório `.openhands` no nível raiz.
## Microagentes
Os microagentes permitem que você estenda os prompts do OpenHands com informações específicas do seu projeto e defina como o OpenHands
deve funcionar. Veja [Visão Geral dos Microagentes](../prompting/microagents-overview) para mais informações.
## Script de Configuração
Você pode adicionar um arquivo `.openhands/setup.sh`, que será executado toda vez que o OpenHands começar a trabalhar com seu repositório.
Este é um local ideal para instalar dependências, definir variáveis de ambiente e realizar outras tarefas de configuração.
Por exemplo:
```bash
#!/bin/bash
export MY_ENV_VAR="my value"
sudo apt-get update
sudo apt-get install -y lsof
cd frontend && npm install ; cd ..
```

38
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/feedback.md
View File

@ -1,10 +1,14 @@
# ✅ Fornecendo Feedback
Ao usar o OpenHands, você encontrará casos em que as coisas funcionam bem e outros em que não funcionam. Nós encorajamos você a fornecer feedback quando usar o OpenHands para ajudar a dar feedback para a equipe de desenvolvimento e, talvez mais importante, criar um corpus aberto de exemplos de treinamento de agentes de codificação -- Share-OpenHands!
Ao usar o OpenHands, você encontrará casos em que as coisas funcionam bem e outros em que não funcionam. Incentivamos você a
fornecer feedback quando usar o OpenHands para ajudar a dar retorno à equipe de desenvolvimento e, talvez mais importante,
criar um corpus aberto de exemplos de treinamento para agentes de codificação -- Share-OpenHands!
## 📝 Como Fornecer Feedback
Fornecer feedback é fácil! Quando você estiver usando o OpenHands, você pode pressionar o botão de polegar para cima ou polegar para baixo a qualquer momento durante sua interação. Você será solicitado a fornecer seu endereço de e-mail (por exemplo, para que possamos entrar em contato com você se quisermos fazer alguma pergunta de acompanhamento), e você pode escolher se deseja fornecer feedback publicamente ou privadamente.
Fornecer feedback é fácil! Quando estiver usando o OpenHands, você pode pressionar o botão de polegar para cima ou polegar para baixo a qualquer momento
durante sua interação. Você será solicitado a fornecer seu endereço de e-mail
(por exemplo, para que possamos contatá-lo se quisermos fazer perguntas de acompanhamento), e você pode escolher se deseja fornecer feedback publicamente ou de forma privada.
<iframe width="560" height="315" src="https://www.youtube.com/embed/5rFx-StMVV0?si=svo7xzp6LhGK_GXr" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
@ -12,27 +16,35 @@ Fornecer feedback é fácil! Quando você estiver usando o OpenHands, você pode
### Configurações de compartilhamento de dados
Quando você envia dados, você pode enviá-los publicamente ou privadamente.
Ao enviar dados, você pode enviá-los publicamente ou de forma privada.
- Dados **públicos** serão distribuídos sob a Licença MIT, como o próprio OpenHands, e podem ser usados pela comunidade para treinar e testar modelos. Obviamente, o feedback que você pode tornar público será mais valioso para a comunidade como um todo, então quando você não estiver lidando com informações confidenciais, nós encorajamos você a escolher esta opção!
- Dados **privados** serão disponibilizados para a equipe do OpenHands com o propósito de melhorar o OpenHands. No entanto, um link com um ID único ainda será criado para que você possa compartilhar publicamente com outras pessoas.
- Os dados **públicos** serão distribuídos sob a Licença MIT, como o próprio OpenHands, e podem ser usados pela comunidade para
treinar e testar modelos. Obviamente, o feedback que você pode tornar público será mais valioso para a comunidade como um todo,
então quando você não estiver lidando com informações sensíveis, incentivamos você a escolher esta opção!
- Os dados **privados** serão disponibilizados para a equipe do OpenHands com o propósito de melhorar o OpenHands.
No entanto, ainda será criado um link com um ID único que você pode compartilhar publicamente com outras pessoas.
### Quem coleta e armazena os dados?
Os dados são coletados e armazenados pela [All Hands AI](https://all-hands.dev), uma empresa fundada pelos mantenedores do OpenHands para apoiar e melhorar o OpenHands.
### Como os dados públicos serão divulgados?
### Como os dados públicos serão lançados?
Os dados públicos serão divulgados quando atingirmos marcos fixos, como 1.000 exemplos públicos, 10.000 exemplos públicos, etc. Neste momento, seguiremos o seguinte processo de divulgação:
Os dados públicos serão lançados quando atingirmos marcos fixos, como 1.000 exemplos públicos, 10.000 exemplos públicos, etc.
Nesse momento, seguiremos o seguinte processo de lançamento:
1. Todas as pessoas que contribuíram com feedback público receberão um e-mail descrevendo a divulgação dos dados e terão a oportunidade de optar por não participar.
2. A pessoa ou pessoas responsáveis pela divulgação dos dados realizarão o controle de qualidade dos dados, removendo feedback de baixa qualidade, removendo endereços de e-mail dos remetentes e tentando remover quaisquer informações confidenciais.
3. Os dados serão divulgados publicamente sob a licença MIT por meio de sites comumente usados, como GitHub ou Hugging Face.
1. Todas as pessoas que contribuíram com feedback público receberão um e-mail descrevendo o lançamento dos dados e terão a oportunidade de optar por não participar.
2. A pessoa ou pessoas responsáveis pelo lançamento dos dados realizarão o controle de qualidade dos dados, removendo feedback de baixa qualidade,
removendo endereços de e-mail dos remetentes e tentando remover qualquer informação sensível.
3. Os dados serão lançados publicamente sob a licença MIT através de sites comumente usados como GitHub ou Hugging Face.
### E se eu quiser que meus dados sejam excluídos?
Para dados nos servidores da All Hands AI, teremos prazer em excluí-los mediante solicitação:
Para dados nos servidores da All Hands AI, estamos felizes em excluí-los mediante solicitação:
**Uma Parte dos Dados:** Se você deseja que uma parte dos dados seja excluída, em breve adicionaremos um mecanismo para excluir partes dos dados usando o link e a senha exibidos na interface quando você envia os dados.
**Um Único Dado:** Se você quiser que um único dado seja excluído, em breve adicionaremos um mecanismo para excluir partes de
dados usando o link e a senha que são exibidos na interface quando você envia dados.
**Todos os Dados:** Se você deseja que todas as partes de seus dados sejam excluídas, ou se você não possui o ID e a senha que recebeu ao enviar os dados, entre em contato com `contact@all-hands.dev` a partir do endereço de e-mail que você registrou quando enviou os dados originalmente.
**Todos os Dados:** Se você deseja que todos os seus dados sejam excluídos, ou não possui o ID e a senha que
recebeu ao enviar os dados, entre em contato com `contact@all-hands.dev` a partir do endereço de e-mail que você registrou
quando originalmente enviou os dados.

114
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/getting-started.mdx
View File

@ -1,111 +1,99 @@
# Começando com o OpenHands
# Começando com OpenHands
Então você [executou o OpenHands](./installation) e
Então você já [executou o OpenHands](./installation) e
[configurou seu LLM](./installation#setup). E agora?
O OpenHands pode ajudá-lo a lidar com uma ampla variedade de tarefas de engenharia. Mas a tecnologia
ainda é nova, e estamos longe de ter agentes que possam assumir tarefas de engenharia grandes e complicadas
sem qualquer orientação. Portanto, é importante ter uma noção do que o agente
faz bem e onde ele pode precisar de alguma ajuda.
O OpenHands pode ajudar com uma variedade de tarefas de engenharia. No entanto, a tecnologia ainda é nova, e estamos longe de ter
agentes que possam lidar com tarefas complexas de forma independente. É importante entender o que o agente faz bem e onde ele
precisa de suporte.
## Olá Mundo
## Hello World
A primeira coisa que você pode querer tentar é um exemplo simples de "olá mundo".
Isso pode ser mais complicado do que parece!
Comece com um exemplo simples de "hello world". Pode ser mais complicado do que parece!
Tente solicitar ao agente:
> Por favor, escreva um script bash hello.sh que imprima "hello world!"
Solicite ao agente com:
> Escreva um script bash hello.sh que imprima "hello world!"
Você deve ver que o agente não apenas escreve o script, mas também define as permissões
corretas e executa o script para verificar a saída.
O agente escreverá o script, definirá as permissões corretas e o executará para verificar a saída.
Você pode continuar solicitando ao agente para refinar seu código. Esta é uma ótima maneira de
trabalhar com agentes. Comece de forma simples e itere.
trabalhar com agentes. Comece de forma simples e vá iterando.
> Por favor, modifique hello.sh para que ele aceite um nome como o primeiro argumento, mas use "world" como padrão
> Modifique hello.sh para que aceite um nome como primeiro argumento, mas use "world" como padrão
Você também pode trabalhar em qualquer linguagem que precisar, embora o agente possa precisar de algum
tempo para configurar seu ambiente!
Você também pode usar qualquer linguagem que precisar. O agente pode precisar de tempo para configurar o ambiente.
> Por favor, converta hello.sh para um script Ruby e execute-o
## Construindo do Zero
Os agentes se saem excepcionalmente bem em tarefas "greenfield" (tarefas em que eles não precisam
de nenhum contexto sobre uma base de código existente) e podem simplesmente começar do zero.
Os agentes se destacam em tarefas "greenfield", onde não precisam de contexto sobre código existente e
podem começar do zero.
Comece com uma tarefa simples e itere a partir daí. Seja específico sobre o que você quer e a stack tecnológica.
É melhor começar com uma tarefa simples e, em seguida, iterar sobre ela. Também é melhor ser
o mais específico possível sobre o que você deseja, qual deve ser a pilha de tecnologia, etc.
Por exemplo, podemos construir um aplicativo de tarefas:
Por exemplo, podemos construir um aplicativo de lista de tarefas:
> Construa um aplicativo de tarefas apenas com frontend em React. Todo o estado deve ser armazenado no localStorage.
> Por favor, construa um aplicativo básico de lista de tarefas em React. Ele deve ser apenas frontend e todo o estado
> deve ser mantido no localStorage.
Uma vez que a estrutura básica esteja pronta, continue refinando:
Podemos continuar iterando no aplicativo assim que o esqueleto estiver lá:
> Permita adicionar uma data de vencimento opcional a cada tarefa.
> Por favor, permita adicionar uma data de vencimento opcional para cada tarefa.
Assim como no desenvolvimento normal, é bom fazer commit e push do seu código com frequência.
Dessa forma, você sempre pode reverter para um estado antigo se o agente sair do caminho.
Assim como no desenvolvimento normal, faça commit e push do seu código com frequência.
Dessa forma, você sempre pode reverter para um estado anterior se o agente se desviar.
Você pode pedir ao agente para fazer commit e push para você:
> Por favor, faça commit das alterações e envie-as para uma nova branch chamada "feature/due-dates"
> Faça commit das alterações e envie-as para uma nova branch chamada "feature/due-dates"
## Adicionando Novo Código
O OpenHands também pode fazer um ótimo trabalho adicionando novo código a uma base de código existente.
O OpenHands é ótimo para adicionar novo código a uma base de código existente.
Por exemplo, você pode pedir ao OpenHands para adicionar uma nova ação do GitHub ao seu projeto
que faça lint do seu código. O OpenHands pode dar uma olhada na sua base de código para ver qual linguagem
ele deve usar e, em seguida, soltar um novo arquivo em `./github/workflows/lint.yml`.
Por exemplo, você pode pedir ao OpenHands para adicionar uma ação do GitHub que faça lint do seu código. Ele pode verificar sua base de código para
determinar a linguagem e, em seguida, criar um novo arquivo em `./github/workflows/lint.yml`.
> Por favor, adicione uma ação do GitHub que faça lint do código neste repositório.
> Adicione uma ação do GitHub que faça lint do código neste repositório.
Algumas tarefas podem exigir um pouco mais de contexto. Embora o OpenHands possa usar `ls` e `grep`
para pesquisar em sua base de código, fornecer contexto antecipadamente permite que ele se mova mais rápido
e com mais precisão. E isso custará menos tokens para você!
Algumas tarefas precisam de mais contexto. Embora o OpenHands possa usar comandos como ls e grep para pesquisar, fornecer contexto antecipadamente
acelera as coisas e reduz o uso de tokens.
> Por favor, modifique ./backend/api/routes.js para adicionar uma nova rota que retorne uma lista de todas as tarefas.
> Modifique ./backend/api/routes.js para adicionar uma nova rota que retorne uma lista de todas as tarefas.
> Por favor, adicione um novo componente React que exiba uma lista de Widgets no diretório ./frontend/components.
> Adicione um novo componente React ao diretório ./frontend/components para exibir uma lista de Widgets.
> Ele deve usar o componente Widget existente.
## Refatoração
O OpenHands é ótimo em refatorar código existente, especialmente em pequenos pedaços.
Você provavelmente não vai querer tentar rearquitetar toda a sua base de código, mas dividir
arquivos e funções longas, renomear variáveis, etc. tendem a funcionar muito bem.
O OpenHands é ótimo para refatorar código em pequenos pedaços. Em vez de reconfigurar toda a base de código,
é mais eficaz dividir arquivos e funções longas ou renomear variáveis.
> Por favor, renomeie todas as variáveis de uma letra em ./app.go.
> Renomeie todas as variáveis de letra única em ./app.go.
> Por favor, divida a função `build_and_deploy_widgets` em duas funções, `build_widgets` e `deploy_widgets` em widget.php.
> Divida a função `build_and_deploy_widgets` em duas funções, `build_widgets` e `deploy_widgets` em widget.php.
> Por favor, divida ./api/routes.js em arquivos separados para cada rota.
> Divida ./api/routes.js em arquivos separados para cada rota.
## Correções de Bugs
## Correção de Bugs
O OpenHands também pode ajudá-lo a rastrear e corrigir bugs em seu código. Mas como qualquer
desenvolvedor sabe, a correção de bugs pode ser extremamente complicada e, muitas vezes, o OpenHands precisará de mais contexto.
Ajuda se você diagnosticou o bug, mas quer que o OpenHands descubra a lógica.
O OpenHands pode ajudar a rastrear e corrigir bugs, mas a correção de bugs pode ser complicada e geralmente requer mais contexto.
É útil se você já diagnosticou o problema e só precisa que o OpenHands lide com a lógica.
> Atualmente, o campo de e-mail no endpoint `/subscribe` está rejeitando domínios .io. Por favor, corrija isso.
> O campo de email no endpoint `/subscribe` está rejeitando domínios .io. Corrija isso.
> A função `search_widgets` em ./app.py está fazendo uma pesquisa sensível a maiúsculas e minúsculas. Por favor, torne-a insensível a maiúsculas e minúsculas.
> A função `search_widgets` em ./app.py está fazendo uma busca sensível a maiúsculas e minúsculas. Torne-a insensível a maiúsculas e minúsculas.
Muitas vezes, ajuda fazer o desenvolvimento orientado a testes ao corrigir bugs com um agente.
Você pode pedir ao agente para escrever um novo teste e, em seguida, iterar até que ele corrija o bug:
Para correção de bugs, o desenvolvimento orientado a testes pode ser muito útil. Você pode pedir ao agente para escrever um novo teste e iterar
até que o bug seja corrigido:
> A função `hello` trava na string vazia. Por favor, escreva um teste que reproduza esse bug e, em seguida, corrija o código para que ele passe.
> A função `hello` falha com uma string vazia. Escreva um teste que reproduza esse bug e, em seguida, corrija o código para que ele passe.
## Mais
O OpenHands é capaz de ajudar em praticamente qualquer tarefa de codificação, mas é necessária alguma prática
para tirar o máximo proveito dele. Lembre-se de:
* Manter suas tarefas pequenas.
* Ser o mais específico possível.
* Fornecer o máximo de contexto possível.
* Fazer commit e push com frequência.
O OpenHands pode ajudar com quase qualquer tarefa de codificação, mas é preciso alguma prática para obter os melhores resultados.
Tenha em mente estas dicas:
* Mantenha suas tarefas pequenas.
* Seja específico.
* Forneça bastante contexto.
* Faça commit e push com frequência.
Veja [Melhores Práticas de Prompt](./prompting/prompting-best-practices) para mais dicas sobre como obter o máximo do OpenHands.
Veja [Melhores Práticas de Prompt](./prompting/prompting-best-practices) para mais dicas sobre como obter o máximo do OpenHands.

64
docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/usage/how-to/cli-mode.md
View File

@ -2,7 +2,7 @@
O OpenHands pode ser executado em um modo CLI interativo, que permite aos usuários iniciar uma sessão interativa via linha de comando.
Esse modo é diferente do [modo headless](headless-mode), que é não interativo e melhor para scripting.
Este modo é diferente do [modo headless](headless-mode), que é não interativo e melhor para scripts.
## Com Python
@ -15,18 +15,20 @@ Para iniciar uma sessão interativa do OpenHands via linha de comando:
poetry run python -m openhands.core.cli
```
Esse comando iniciará uma sessão interativa onde você pode inserir tarefas e receber respostas do OpenHands.
Este comando iniciará uma sessão interativa onde você pode inserir tarefas e receber respostas do OpenHands.
Você precisará definir seu modelo, chave de API e outras configurações via variáveis de ambiente
[ou o arquivo `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
Você precisará definir seu modelo, chave de API e outras configurações através de variáveis de ambiente
[ou do arquivo `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Com Docker
Para executar o OpenHands no modo CLI com Docker:
1. Defina as seguintes variáveis de ambiente no seu terminal:
1. Defina as seguintes variáveis de ambiente em seu terminal:
- `WORKSPACE_BASE` para o diretório que você deseja que o OpenHands edite (Ex: `export WORKSPACE_BASE=$(pwd)/workspace`).
- `SANDBOX_VOLUMES` para especificar o diretório que você quer que o OpenHands acesse (Ex: `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw`).
- O agente trabalha em `/workspace` por padrão, então monte seu diretório de projeto lá se quiser que o agente modifique arquivos.
- Para dados somente leitura, use um caminho de montagem diferente (Ex: `export SANDBOX_VOLUMES=$(pwd)/workspace:/workspace:rw,/path/to/large/dataset:/data:ro`).
- `LLM_MODEL` para o modelo a ser usado (Ex: `export LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"`).
- `LLM_API_KEY` para a chave de API (Ex: `export LLM_API_KEY="sk_test_12345"`).
@ -37,10 +39,9 @@ docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.36-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
@ -49,48 +50,7 @@ docker run -it \
python -m openhands.core.cli
```
Esse comando iniciará uma sessão interativa no Docker onde você pode inserir tarefas e receber respostas do OpenHands.
Este comando iniciará uma sessão interativa no Docker onde você pode inserir tarefas e receber respostas do OpenHands.
## Exemplos de Comandos CLI e Saídas Esperadas
Aqui estão alguns exemplos de comandos CLI e suas saídas esperadas:
### Exemplo 1: Tarefa Simples
```bash
>> Escreva um script Python que imprima "Hello, World!"
```
Saída Esperada:
```bash
🤖 Claro! Aqui está um script Python que imprime "Hello, World!":
❯ print("Hello, World!")
```
### Exemplo 2: Comando Bash
```bash
>> Crie um diretório chamado "test_dir"
```
Saída Esperada:
```bash
🤖 Criando um diretório chamado "test_dir":
❯ mkdir test_dir
```
### Exemplo 3: Tratamento de Erro
```bash
>> Exclua um arquivo inexistente
```
Saída Esperada:
```bash
🤖 Ocorreu um erro. Por favor, tente novamente.
```
O `-e SANDBOX_USER_ID=$(id -u)` é passado para o comando Docker para garantir que o usuário da sandbox corresponda às
permissões do usuário do host. Isso impede que o agente crie arquivos pertencentes ao root no workspace montado.

Some files were not shown because too many files have changed in this diff Show More