docs: migrate all docs from All-Hands-AI/docs to OpenHands repo (#8848)

This commit is contained in:
Xingyao Wang
2025-06-02 17:12:10 -04:00
committed by GitHub
parent d03efa284a
commit 6132968324
342 changed files with 676 additions and 39929 deletions

View File

@@ -1,72 +0,0 @@
# Workflow that builds and deploys the documentation website
name: Deploy Docs to GitHub Pages
# * Always run on "main"
# * Run on PRs that target the "main" branch and have changes in the "docs" folder or this workflow
on:
push:
branches:
- main
pull_request:
paths:
- 'docs/**'
- '.github/workflows/deploy-docs.yml'
branches:
- main
# If triggered by a PR, it will be in the same group. However, each commit on main will be in its own unique group
concurrency:
group: ${{ github.workflow }}-${{ (github.head_ref && github.ref) || github.run_id }}
cancel-in-progress: true
jobs:
# Build the documentation website
build:
if: github.repository == 'All-Hands-AI/OpenHands'
name: Build Docusaurus
runs-on: blacksmith-4vcpu-ubuntu-2204
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: useblacksmith/setup-node@v5
with:
node-version: 18
cache: npm
cache-dependency-path: docs/package-lock.json
- name: Set up Python
uses: useblacksmith/setup-python@v6
with:
python-version: '3.12'
- name: Install dependencies
run: cd docs && npm ci
- name: Build website
run: cd docs && npm run build
- name: Upload Build Artifact
if: github.ref == 'refs/heads/main'
uses: actions/upload-pages-artifact@v3
with:
path: docs/build
# Deploy the documentation website
deploy:
if: github.ref == 'refs/heads/main' && github.repository == 'All-Hands-AI/OpenHands'
name: Deploy to GitHub Pages
runs-on: blacksmith-4vcpu-ubuntu-2204
# This job only runs on "main" so only run one of these jobs at a time
# otherwise it will fail if one is already running
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
needs: build
# Grant GITHUB_TOKEN the permissions required to make a Pages deployment
permissions:
pages: write # to deploy to Pages
id-token: write # to verify the deployment originates from an appropriate source
# Deploy to the github-pages environment
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4

21
docs/.gitignore vendored
View File

@@ -1,21 +0,0 @@
# Dependencies
/node_modules
# Production
/build
/static/swagger-ui
# Generated files
.docusaurus
.cache-loader
# Misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*

View File

@@ -54,9 +54,9 @@ docker run -it \
When adding a note or warning, use the built-in note and warning syntax.
Example:
:::note
<Note>
This section is for advanced users only.
:::
</Note>
### Referring to UI Elements

View File

@@ -1,55 +0,0 @@
# OpenHands Documentation
This website is built using [Docusaurus](https://docusaurus.io/).
When published, the content will be published at https://docs.all-hands.dev/.
### Local Development
```bash
$ cd docs
$ npm install
$ npm run start
```
This command starts a local development server and opens up a browser window.
Most changes are reflected live without having to restart the server.
Alternatively, you can pass a `--locale` argument to render a specific language in dev mode as in:
```
$ npm run start --locale pt-BR # for the Brazilian Portuguese version
$ npm run start --locale fr # for the French version
$ npm run start --locale zh-Hans # for the Chinese Han (simplified variant) version
```
### Build
```
$ npm run build
```
This command generates static content into the `build` directory and can be served using any static contents hosting service.
It compiles all languages.
### Deployment
Open a new pull request and - when it is merged - the [deploy-docs](.github/workflows/deploy-docs.yml) GH action will take care of everything else.
## Automatic Translations
Translations can be automatically updated when the original English content changes, this is done by the script [`translation_updater.py`](./translation_updater.py).
From the root of the repository, you can run the following:
```bash
$ export ANTHROPIC_API_KEY=<your_api_key>
$ poetry run python docs/translation_updater.py
# ...
# Change detected in docs/modules/usage/getting-started.mdx
# translating... docs/modules/usage/getting-started.mdx pt-BR
# translation done
# ...
```
This process uses `claude-sonnet-4-20250514` as base model and each language consumes at least ~30k input tokens and ~35k output tokens.

View File

@@ -1,3 +0,0 @@
module.exports = {
presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
};

197
docs/docs.json Normal file
View File

@@ -0,0 +1,197 @@
{
"$schema": "https://mintlify.com/docs.json",
"theme": "mint",
"name": "All Hands Docs",
"colors": {
"primary": "#99873c",
"light": "#ffe165",
"dark": "#ffe165"
},
"background": {
"color": {
"light": "#f7f3ee",
"dark": "#0B0D0E"
}
},
"appearance": {
"default": "light"
},
"favicon": "/logo-square.png",
"navigation": {
"tabs": [
{
"tab": "Getting started",
"pages": [
"index",
"usage/installation",
"usage/getting-started",
"usage/key-features",
{
"group": "OpenHands Cloud",
"pages": [
"usage/cloud/openhands-cloud",
{
"group": "Installation",
"pages": [
"usage/cloud/github-installation",
"usage/cloud/gitlab-installation"
]
},
"usage/cloud/cloud-ui",
"usage/cloud/cloud-issue-resolver",
"usage/cloud/cloud-api"
]
},
{
"group": "Usage Methods",
"pages": [
"usage/how-to/gui-mode",
"usage/how-to/cli-mode",
"usage/how-to/headless-mode",
"usage/how-to/github-action"
]
}
]
},
{
"tab": "Prompting and Customization",
"pages": [
"usage/prompting/prompting-best-practices",
"usage/prompting/repository",
{
"group": "Microagents",
"pages": [
"usage/prompting/microagents-overview",
"usage/prompting/microagents-repo",
"usage/prompting/microagents-keyword",
"usage/prompting/microagents-org",
"usage/prompting/microagents-public"
]
}
]
},
{
"tab": "Advanced Configuration",
"pages": [
{
"group": "LLM Configuration",
"pages": [
"usage/llms/llms",
{
"group": "Providers",
"pages": [
"usage/llms/azure-llms",
"usage/llms/google-llms",
"usage/llms/groq",
"usage/llms/local-llms",
"usage/llms/litellm-proxy",
"usage/llms/openai-llms",
"usage/llms/openrouter"
]
}
]
},
{
"group": "Runtime Configuration",
"pages": [
"usage/runtimes/overview",
{
"group": "Providers",
"pages": [
"usage/runtimes/docker",
"usage/runtimes/remote",
"usage/runtimes/local",
{
"group": "Third-Party Providers",
"pages": [
"usage/runtimes/modal",
"usage/runtimes/daytona",
"usage/runtimes/runloop",
"usage/runtimes/e2b"
]
}
]
}
]
},
"usage/configuration-options",
"usage/how-to/custom-sandbox-guide",
"usage/mcp"
]
},
{
"tab": "Troubleshooting & Feedback",
"pages": [
"usage/troubleshooting/troubleshooting",
"usage/feedback"
]
},
{
"tab": "For OpenHands Developers",
"pages": [
"usage/how-to/development-overview",
{
"group": "Architecture",
"pages": [
"usage/architecture/backend",
"usage/architecture/runtime"
]
},
"usage/how-to/debugging",
"usage/how-to/evaluation-harness",
"usage/how-to/websocket-connection"
]
},
{
"tab": "API Reference",
"openapi": "/openapi.json"
}
],
"global": {
"anchors": [
{
"anchor": "Company",
"href": "https://www.all-hands.dev/",
"icon": "house"
},
{
"anchor": "Blog",
"href": "https://www.all-hands.dev/blog",
"icon": "newspaper"
},
{
"anchor": "OpenHands Cloud",
"href": "https://app.all-hands.dev",
"icon": "cloud"
}
]
}
},
"logo": {
"light": "/logo/light.svg",
"dark": "/logo/dark.svg"
},
"navbar": {
"links": [
],
"primary": {
"type": "github",
"href": "https://github.com/All-Hands-AI/OpenHands"
}
},
"footer": {
"socials": {
"slack": "https://join.slack.com/t/openhands-ai/shared_invite/zt-34zm4j0gj-Qz5kRHoca8DFCbqXPS~f_A",
"github": "https://github.com/All-Hands-AI/OpenHands",
"discord": "https://discord.gg/ESHStjSjD4"
}
},
"contextual": {
"options": [
"copy",
"view",
"chatgpt",
"claude"
]
}
}

View File

@@ -1,118 +0,0 @@
import type * as Preset from '@docusaurus/preset-classic';
import type { Config } from '@docusaurus/types';
import { themes as prismThemes } from 'prism-react-renderer';
const config: Config = {
title: 'OpenHands',
tagline: 'Code Less, Make More',
favicon: 'img/logo-square.png',
// Set the production url of your site here
url: 'https://docs.all-hands.dev',
baseUrl: '/',
// GitHub pages deployment config.
organizationName: 'All-Hands-AI',
projectName: 'OpenHands',
trailingSlash: false,
onBrokenLinks: 'throw',
onBrokenMarkdownLinks: 'warn',
// Even if you don't use internationalization, you can use this field to set
// useful metadata like html lang. For example, if your site is Chinese, you
// may want to replace "en" with "zh-Hans".
i18n: {
defaultLocale: 'en',
locales: ['en', 'fr', 'zh-Hans', 'ja', 'pt-BR'],
localeConfigs: {
en: {
htmlLang: 'en-GB',
},
},
},
markdown: {
mermaid: true,
},
themes: ['@docusaurus/theme-mermaid'],
plugins: [
[
require.resolve('docusaurus-lunr-search'),
{
languages: ['en', 'zh', 'fr', 'ja', 'pt']
}
]
],
presets: [
[
'classic',
{
docs: {
path: 'modules',
routeBasePath: 'modules',
sidebarPath: './sidebars.ts',
exclude: [
// '**/_*.{js,jsx,ts,tsx,md,mdx}',
// '**/_*/**',
'**/*.test.{js,jsx,ts,tsx}',
'**/__tests__/**',
],
},
blog: {
showReadingTime: true,
},
theme: {
customCss: './src/css/custom.css',
},
} satisfies Preset.Options,
],
],
themeConfig: {
image: 'img/docusaurus.png',
navbar: {
title: 'OpenHands',
logo: {
alt: 'OpenHands',
src: 'img/logo.png',
},
items: [
{
type: 'docSidebar',
sidebarId: 'docsSidebar',
position: 'left',
label: 'User Guides',
},
{
href: 'https://docs.all-hands.dev/swagger-ui/', // FIXME: this should be a relative path, but docusarus steals the click
label: 'API',
position: 'left',
},
{
type: 'localeDropdown',
position: 'left',
},
{
type: 'search',
position: 'left',
},
{
href: 'https://all-hands.dev',
label: 'Company',
position: 'right',
},
{
href: 'https://github.com/All-Hands-AI/OpenHands',
label: 'GitHub',
position: 'right',
},
],
},
prism: {
theme: prismThemes.oneLight,
darkTheme: prismThemes.oneDark,
},
} satisfies Preset.ThemeConfig,
};
export default config;

19
docs/favicon.svg Normal file
View File

@@ -0,0 +1,19 @@
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M9.06145 23.1079C5.26816 22.3769 -3.39077 20.6274 1.4173 5.06384C9.6344 6.09939 16.9728 14.0644 9.06145 23.1079Z" fill="url(#paint0_linear_17557_2021)"/>
<path d="M8.91928 23.0939C5.27642 21.2223 0.78371 4.20891 17.0071 0C20.7569 7.19341 19.6212 16.5452 8.91928 23.0939Z" fill="url(#paint1_linear_17557_2021)"/>
<path d="M8.91388 23.0788C8.73534 19.8817 10.1585 9.08525 23.5699 13.1107C23.1812 20.1229 18.984 26.4182 8.91388 23.0788Z" fill="url(#paint2_linear_17557_2021)"/>
<defs>
<linearGradient id="paint0_linear_17557_2021" x1="3.77557" y1="5.91571" x2="5.23185" y2="21.5589" gradientUnits="userSpaceOnUse">
<stop stop-color="#18E299"/>
<stop offset="1" stop-color="#15803D"/>
</linearGradient>
<linearGradient id="paint1_linear_17557_2021" x1="12.1711" y1="-0.718425" x2="10.1897" y2="22.9832" gradientUnits="userSpaceOnUse">
<stop stop-color="#16A34A"/>
<stop offset="1" stop-color="#4ADE80"/>
</linearGradient>
<linearGradient id="paint2_linear_17557_2021" x1="23.1327" y1="15.353" x2="9.33841" y2="18.5196" gradientUnits="userSpaceOnUse">
<stop stop-color="#4ADE80"/>
<stop offset="1" stop-color="#0D9373"/>
</linearGradient>
</defs>
</svg>

After

Width:  |  Height:  |  Size: 1.2 KiB

View File

@@ -1,102 +0,0 @@
const fs = require('fs');
const path = require('path');
const swaggerUiDist = require('swagger-ui-dist');
/**
* This script manually sets up Swagger UI for the Docusaurus documentation.
*
* Why we need this approach:
* 1. Docusaurus doesn't have a built-in way to integrate Swagger UI
* 2. We need to copy the necessary files from swagger-ui-dist to our static directory
* 3. We need to create a custom index.html file that points to our OpenAPI spec
* 4. This approach allows us to customize the Swagger UI to match our documentation style
*/
// Get the absolute path to the swagger-ui-dist package
const swaggerUiDistPath = swaggerUiDist.getAbsoluteFSPath();
// Create the target directory if it doesn't exist
const targetDir = path.join(__dirname, 'static', 'swagger-ui');
if (!fs.existsSync(targetDir)) {
fs.mkdirSync(targetDir, { recursive: true });
}
// Copy all files from swagger-ui-dist to our target directory
const files = fs.readdirSync(swaggerUiDistPath);
files.forEach(file => {
const sourcePath = path.join(swaggerUiDistPath, file);
const targetPath = path.join(targetDir, file);
// Skip directories and non-essential files
if (fs.statSync(sourcePath).isDirectory() ||
file === 'package.json' ||
file === 'README.md' ||
file.endsWith('.map')) {
return;
}
fs.copyFileSync(sourcePath, targetPath);
});
// Create a custom index.html file that points to our OpenAPI spec
const indexHtml = `
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>OpenHands API Documentation</title>
<link rel="stylesheet" type="text/css" href="./swagger-ui.css" />
<link rel="icon" type="image/png" href="./favicon-32x32.png" sizes="32x32" />
<link rel="icon" type="image/png" href="./favicon-16x16.png" sizes="16x16" />
<style>
html {
box-sizing: border-box;
overflow: -moz-scrollbars-vertical;
overflow-y: scroll;
}
*,
*:before,
*:after {
box-sizing: inherit;
}
body {
margin: 0;
background: #fafafa;
}
</style>
</head>
<body>
<div id="swagger-ui"></div>
<script src="./swagger-ui-bundle.js" charset="UTF-8"> </script>
<script src="./swagger-ui-standalone-preset.js" charset="UTF-8"> </script>
<script>
window.onload = function() {
// Begin Swagger UI call region
const ui = SwaggerUIBundle({
url: "/openapi.json",
dom_id: '#swagger-ui',
deepLinking: true,
presets: [
SwaggerUIBundle.presets.apis,
SwaggerUIStandalonePreset
],
plugins: [
SwaggerUIBundle.plugins.DownloadUrl
],
layout: "StandaloneLayout"
});
// End Swagger UI call region
window.ui = ui;
};
</script>
</body>
</html>
`;
fs.writeFileSync(path.join(targetDir, 'index.html'), indexHtml);
console.log('Swagger UI files generated successfully in static/swagger-ui/');

View File

@@ -1,427 +0,0 @@
{
"footer.title": {
"message": "OpenHands"
},
"footer.docs": {
"message": "Documents"
},
"footer.community": {
"message": "Communauté"
},
"footer.copyright": {
"message": "© {year} OpenHands"
},
"faq.title": {
"message": "Questions Fréquemment Posées",
"description": "FAQ Title"
},
"faq.description": {
"message": "Questions Fréquemment Posées"
},
"faq.section.title.1": {
"message": "Qu'est-ce qu'OpenHands ?",
"description": "First Section Title"
},
"faq.section.highlight": {
"message": "OpenHands",
"description": "Highlight Text"
},
"faq.section.description.1": {
"message": "est un ingénieur logiciel autonome qui peut résoudre des tâches d'ingénierie logicielle et de navigation web à tout moment. Il peut exécuter des requêtes en sciences des données, telles que \"Trouver le nombre de demandes de pull à l'repository OpenHands dans les derniers mois\", et des tâches d'ingénierie logicielle, comme \"Veuillez ajouter des tests à ce fichier et vérifier si tous les tests passent. Si ce n'est pas le cas, réparez le fichier.\"",
"description": "Description for OpenHands"
},
"faq.section.description.2": {
"message": "De plus, OpenHands est une plateforme et communauté pour les développeurs d'agents qui souhaitent tester et évaluer de nouveaux agents.",
"description": "Further Description for OpenHands"
},
"faq.section.title.2": {
"message": "Support",
"description": "Support Section Title"
},
"faq.section.support.answer": {
"message": "Si vous rencontrez un problème que d'autres utilisateurs peuvent également avoir, merci de le signaler sur {githubLink}. Si vous avez des difficultés à l'installation ou des questions générales, rejoignez-vous sur {discordLink} ou {slackLink}.",
"description": "Support Answer"
},
"faq.section.title.3": {
"message": "Comment résoudre un problème sur GitHub avec OpenHands ?",
"description": "GitHub Issue Section Title"
},
"faq.section.github.steps.intro": {
"message": "Pour résoudre un problème sur GitHub en utilisant OpenHands, envoyez une commande à OpenHands demandant qu'il suit des étapes comme les suivantes :",
"description": "GitHub Steps Introduction"
},
"faq.section.github.step1": {
"message": "Lisez l'issue https://github.com/All-Hands-AI/OpenHands/issues/1611",
"description": "GitHub Step 1"
},
"faq.section.github.step2": {
"message": "Cloner le dépôt et vérifier une nouvelle branche",
"description": "GitHub Step 2"
},
"faq.section.github.step3": {
"message": "Sur la base des instructions dans la description de l'issue, modifiez les fichiers pour résoudre le problème",
"description": "GitHub Step 3"
},
"faq.section.github.step4": {
"message": "Pousser le résultat à GitHub en utilisant la variable d'environnement GITHUB_TOKEN",
"description": "GitHub Step 4"
},
"faq.section.github.step5": {
"message": "Dites-moi le lien que je dois utiliser pour envoyer une demande de pull",
"description": "GitHub Step 5"
},
"faq.section.github.steps.preRun": {
"message": "Avant de lancer OpenHands, vous pouvez faire :",
"description": "GitHub Steps Pre-Run"
},
"faq.section.github.steps.tokenInfo": {
"message": "où XXX est un jeton GitHub que vous avez créé et qui a les autorisations pour pousser dans le dépôt OpenHands. Si vous n'avez pas d'autorisations de modification du dépôt OpenHands, vous devrez peut-être changer cela en :",
"description": "GitHub Steps Token Info"
},
"faq.section.github.steps.usernameInfo": {
"message": "où USERNAME est votre nom GitHub.",
"description": "GitHub Steps Username Info"
},
"faq.section.title.4": {
"message": "Comment OpenHands est-il différent de Devin ?",
"description": "Devin Section Title"
},
"faq.section.openhands.linkText": {
"message": "Devin",
"description": "Devin Link Text"
},
"faq.section.openhands.description": {
"message": "est un produit commercial par Cognition Inc., qui a servi d'inspiration initiale pour OpenHands. Les deux visent à bien faire le travail d'ingénierie logicielle, mais vous pouvez télécharger, utiliser et modifier OpenHands, tandis que Devin peut être utilisé uniquement via le site de Cognition. De plus, OpenHands a évolué au-delà de l'inspiration initiale, et est maintenant un écosystème communautaire pour le développement d'agents en général, et nous serions ravis de vous voir rejoindre et",
"description": "Devin Description"
},
"faq.section.openhands.contribute": {
"message": "contribuer",
"description": "Contribute Link"
},
"faq.section.title.5": {
"message": "Comment OpenHands est-il différent de ChatGPT ?",
"description": "ChatGPT Section Title"
},
"faq.section.chatgpt.description": {
"message": "ChatGPT vous pouvez accéder en ligne, il ne se connecte pas aux fichiers locaux et ses capacités d'exécution du code sont limitées. Alors qu'il peut écrire du code, mais c'est difficile à tester ou à exécuter.",
"description": "ChatGPT Description"
},
"homepage.description": {
"message": "Génération d'code AI pour l'ingénierie logicielle.",
"description": "The homepage description"
},
"homepage.getStarted": {
"message": "Commencer"
},
"welcome.message": {
"message": "Bienvenue à OpenHands, un système d'IA autonome ingénieur logiciel capable d'exécuter des tâches d'ingénierie complexes et de collaborer activement avec les utilisateurs sur les projets de développement logiciel."
},
"theme.ErrorPageContent.title": {
"message": "Cette page a planté.",
"description": "The title of the fallback page when the page crashed"
},
"theme.BackToTopButton.buttonAriaLabel": {
"message": "Retourner en haut de la page",
"description": "The ARIA label for the back to top button"
},
"theme.blog.archive.title": {
"message": "Archives",
"description": "The page & hero title of the blog archive page"
},
"theme.blog.archive.description": {
"message": "Archives",
"description": "The page & hero description of the blog archive page"
},
"theme.blog.paginator.navAriaLabel": {
"message": "Pagination des listes d'articles du blog",
"description": "The ARIA label for the blog pagination"
},
"theme.blog.paginator.newerEntries": {
"message": "Nouvelles entrées",
"description": "The label used to navigate to the newer blog posts page (previous page)"
},
"theme.blog.paginator.olderEntries": {
"message": "Anciennes entrées",
"description": "The label used to navigate to the older blog posts page (next page)"
},
"theme.blog.post.paginator.navAriaLabel": {
"message": "Pagination des articles du blog",
"description": "The ARIA label for the blog posts pagination"
},
"theme.blog.post.paginator.newerPost": {
"message": "Article plus récent",
"description": "The blog post button label to navigate to the newer/previous post"
},
"theme.blog.post.paginator.olderPost": {
"message": "Article plus ancien",
"description": "The blog post button label to navigate to the older/next post"
},
"theme.blog.post.plurals": {
"message": "Un article|{count} articles",
"description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.blog.tagTitle": {
"message": "{nPosts} tags avec « {tagName} »",
"description": "The title of the page for a blog tag"
},
"theme.tags.tagsPageLink": {
"message": "Voir tous les tags",
"description": "The label of the link targeting the tag list page"
},
"theme.colorToggle.ariaLabel": {
"message": "Basculer entre le mode sombre et clair (actuellement {mode})",
"description": "The ARIA label for the navbar color mode toggle"
},
"theme.colorToggle.ariaLabel.mode.dark": {
"message": "mode sombre",
"description": "The name for the dark color mode"
},
"theme.colorToggle.ariaLabel.mode.light": {
"message": "mode clair",
"description": "The name for the light color mode"
},
"theme.docs.breadcrumbs.navAriaLabel": {
"message": "Bouton de navigation des liens de la page",
"description": "The ARIA label for the breadcrumbs"
},
"theme.docs.DocCard.categoryDescription.plurals": {
"message": "1 élément|{count} éléments",
"description": "The default description for a category card in the generated index about how many items this category includes"
},
"theme.docs.paginator.navAriaLabel": {
"message": "Pages de documentation",
"description": "The ARIA label for the docs pagination"
},
"theme.docs.paginator.previous": {
"message": "Précédent",
"description": "The label used to navigate to the previous doc"
},
"theme.docs.paginator.next": {
"message": "Suivant",
"description": "The label used to navigate to the next doc"
},
"theme.docs.tagDocListPageTitle.nDocsTagged": {
"message": "Un document tagué|{count} documents tagués",
"description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.tagDocListPageTitle": {
"message": "{nDocsTagged} avec \"{tagName}\"",
"description": "The title of the page for a docs tag"
},
"theme.docs.versionBadge.label": {
"message": "Version: {versionLabel}"
},
"theme.docs.versions.unreleasedVersionLabel": {
"message": "Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.",
"description": "The label used to tell the user that he's browsing an unreleased doc version"
},
"theme.docs.versions.unmaintainedVersionLabel": {
"message": "Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.",
"description": "The label used to tell the user that he's browsing an unmaintained doc version"
},
"theme.docs.versions.latestVersionSuggestionLabel": {
"message": "Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).",
"description": "The label used to tell the user to check the latest version"
},
"theme.docs.versions.latestVersionLinkLabel": {
"message": "dernière version",
"description": "The label used for the latest version suggestion link label"
},
"theme.common.editThisPage": {
"message": "Éditer cette page",
"description": "The link label to edit the current page"
},
"theme.common.headingLinkTitle": {
"message": "Lien direct vers {heading}",
"description": "Title for link to heading"
},
"theme.lastUpdated.atDate": {
"message": " le {date}",
"description": "The words used to describe on which date a page has been last updated"
},
"theme.lastUpdated.byUser": {
"message": " par {user}",
"description": "The words used to describe by who the page has been last updated"
},
"theme.lastUpdated.lastUpdatedAtBy": {
"message": "Dernière mise à jour{atDate}{byUser}",
"description": "The sentence used to display when a page has been last updated, and by who"
},
"theme.navbar.mobileVersionsDropdown.label": {
"message": "Versions",
"description": "The label for the navbar versions dropdown on mobile view"
},
"theme.NotFound.title": {
"message": "Page introuvable",
"description": "The title of the 404 page"
},
"theme.tags.tagsListLabel": {
"message": "Tags :",
"description": "The label alongside a tag list"
},
"theme.admonition.caution": {
"message": "prudence",
"description": "The default label used for the Caution admonition (:::caution)"
},
"theme.admonition.danger": {
"message": "danger",
"description": "The default label used for the Danger admonition (:::danger)"
},
"theme.admonition.info": {
"message": "information",
"description": "The default label used for the Info admonition (:::info)"
},
"theme.admonition.note": {
"message": "remarque",
"description": "The default label used for the Note admonition (:::note)"
},
"theme.admonition.tip": {
"message": "astuce",
"description": "The default label used for the Tip admonition (:::tip)"
},
"theme.admonition.warning": {
"message": "prudence",
"description": "The default label used for the Warning admonition (:::warning)"
},
"theme.AnnouncementBar.closeButtonAriaLabel": {
"message": "Fermer",
"description": "The ARIA label for close button of announcement bar"
},
"theme.blog.sidebar.navAriaLabel": {
"message": "Navigation vers les articles récents du blog",
"description": "The ARIA label for recent posts in the blog sidebar"
},
"theme.CodeBlock.copied": {
"message": "Copié",
"description": "The copied button label on code blocks"
},
"theme.CodeBlock.copyButtonAriaLabel": {
"message": "Copier le code",
"description": "The ARIA label for copy code blocks button"
},
"theme.CodeBlock.copy": {
"message": "Copier",
"description": "The copy button label on code blocks"
},
"theme.CodeBlock.wordWrapToggle": {
"message": "Activer/désactiver le retour à la ligne",
"description": "The title attribute for toggle word wrapping button of code block lines"
},
"theme.DocSidebarItem.expandCategoryAriaLabel": {
"message": "Développer la catégorie '{label}' de la barre latérale",
"description": "The ARIA label to expand the sidebar category"
},
"theme.DocSidebarItem.collapseCategoryAriaLabel": {
"message": "Réduire la catégorie '{label}' de la barre latérale",
"description": "The ARIA label to collapse the sidebar category"
},
"theme.NavBar.navAriaLabel": {
"message": "Main",
"description": "The ARIA label for the main navigation"
},
"theme.navbar.mobileLanguageDropdown.label": {
"message": "Langues",
"description": "The label for the mobile language switcher dropdown"
},
"theme.NotFound.p1": {
"message": "Nous n'avons pas trouvé ce que vous recherchez.",
"description": "The first paragraph of the 404 page"
},
"theme.NotFound.p2": {
"message": "Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.",
"description": "The 2nd paragraph of the 404 page"
},
"theme.TOCCollapsible.toggleButtonLabel": {
"message": "Sur cette page",
"description": "The label used by the button on the collapsible TOC component"
},
"theme.blog.post.readMore": {
"message": "Lire plus",
"description": "The label used in blog post item excerpts to link to full blog posts"
},
"theme.blog.post.readMoreLabel": {
"message": "En savoir plus sur {title}",
"description": "The ARIA label for the link to full blog posts from excerpts"
},
"theme.blog.post.readingTime.plurals": {
"message": "Une minute de lecture|{readingTime} minutes de lecture",
"description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.breadcrumbs.home": {
"message": "Page d'accueil",
"description": "The ARIA label for the home page in the breadcrumbs"
},
"theme.docs.sidebar.collapseButtonTitle": {
"message": "Réduire le menu latéral",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.collapseButtonAriaLabel": {
"message": "Réduire le menu latérale",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.navAriaLabel": {
"message": "Barre de navigation latérale des docs",
"description": "The ARIA label for the sidebar navigation"
},
"theme.docs.sidebar.closeSidebarButtonAriaLabel": {
"message": "Fermer la barre de navigation",
"description": "The ARIA label for close button of mobile sidebar"
},
"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": {
"message": "← Retour au menu principal",
"description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
},
"theme.docs.sidebar.toggleSidebarButtonAriaLabel": {
"message": "Ouvrir/fermer la barre de navigation",
"description": "The ARIA label for hamburger menu button of mobile navigation"
},
"theme.docs.sidebar.expandButtonTitle": {
"message": "Déplier le menu latéral",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.docs.sidebar.expandButtonAriaLabel": {
"message": "Déployer le menu latérale",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.ErrorPageContent.tryAgain": {
"message": "Réessayer",
"description": "The label of the button to try again rendering when the React error boundary captures an error"
},
"theme.common.skipToMainContent": {
"message": "Aller directement au contenu principal",
"description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
},
"theme.tags.tagsPageTitle": {
"message": "Tags",
"description": "The title of the tag list page"
},
"theme.unlistedContent.title": {
"message": "Page non répertoriée",
"description": "The unlisted content banner title"
},
"theme.unlistedContent.message": {
"message": "Cette page n'est pas répertoriée. Les moteurs de recherche ne l'indexeront pas, et seuls les utilisateurs ayant un lien direct peuvent y accéder.",
"description": "The unlisted content banner message"
},
"Use AI to tackle the toil in your backlog. Our agents have all the same tools as a human developer: they can modify code, run commands, browse the web, call APIs, and yes-even copy code snippets from StackOverflow.": {
"message": "Utilisez l'IA pour gérer les tâches répétitives de votre backlog. Nos agents disposent des mêmes outils qu'un développeur humain : ils peuvent modifier du code, exécuter des commandes, naviguer sur le web, appeler des API et même copier des extraits de code depuis StackOverflow."
},
"Get started with OpenHands.": {
"message": "Commencer avec OpenHands"
},
"Most Popular Links": {
"message": "Liens Populaires"
},
"Customizing OpenHands to a repository": {
"message": "Personnaliser OpenHands pour un dépôt"
},
"Integrating OpenHands with Github": {
"message": "Intégrer OpenHands avec Github"
},
"Recommended models to use": {
"message": "Modèles recommandés"
},
"Connecting OpenHands to your filesystem": {
"message": "Connecter OpenHands à votre système de fichiers"
}
}

View File

@@ -1,14 +0,0 @@
{
"title": {
"message": "Blog",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "Blog",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "Articles récents",
"description": "The label for the left sidebar"
}
}

View File

@@ -1,210 +0,0 @@
{
"version.label": {
"message": "Next",
"description": "The label for version current"
},
"sidebar.docsSidebar.category.🤖 Backends LLM": {
"message": "🤖 Backends LLM",
"description": "The label for category 🤖 Backends LLM in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.🚧 Dépannage": {
"message": "🚧 Dépannage",
"description": "The label for category 🚧 Dépannage in sidebar docsSidebar"
},
"sidebar.apiSidebar.category.Backend": {
"message": "Backend",
"description": "The label for category Backend in sidebar apiSidebar"
},
"sidebar.docsSidebar.category.User Guides": {
"message": "Guides d'Utilisateur",
"description": "The label for category User Guides in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Running OpenHands": {
"message": "Exécution d'OpenHands",
"description": "The label for category Running OpenHands in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Prompting": {
"message": "Prompting",
"description": "The label for category Prompting in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Architecture": {
"message": "Architecture",
"description": "The label for category Architecture in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Running OpenHands": {
"message": "Exécution d'OpenHands",
"description": "The label for document Running OpenHands in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Getting Started": {
"message": "Commencer",
"description": "The label for document Getting Started in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Key Features": {
"message": "Fonctionnalités Clés",
"description": "The label for document Key Features in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Customization": {
"message": "Personnalisation",
"description": "The label for category Customization in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Usage Methods": {
"message": "Méthodes d'Utilisation",
"description": "The label for category Usage Methods in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Advanced Configuration": {
"message": "Configuration Avancée",
"description": "The label for category Advanced Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Troubleshooting": {
"message": "Dépannage",
"description": "The label for document Troubleshooting in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Feedback": {
"message": "Retour d'Information",
"description": "The label for document Feedback in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.For OpenHands Developers": {
"message": "Pour les Développeurs OpenHands",
"description": "The label for category For OpenHands Developers in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.About": {
"message": "À Propos",
"description": "The label for document About in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Best Practices": {
"message": "Meilleures Pratiques",
"description": "The label for document Best Practices in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Microagents": {
"message": "Micro-agents",
"description": "The label for category Microagents in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Overview": {
"message": "Aperçu",
"description": "The label for document Overview in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Repository": {
"message": "Dépôt",
"description": "The label for document Repository in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Public": {
"message": "Public",
"description": "The label for document Public in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Repository Customization": {
"message": "Personnalisation du Dépôt",
"description": "The label for document Repository Customization in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.GUI Mode": {
"message": "Mode GUI",
"description": "The label for document GUI Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.CLI Mode": {
"message": "Mode CLI",
"description": "The label for document CLI Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Headless Mode": {
"message": "Mode Sans Interface",
"description": "The label for document Headless Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Github Action": {
"message": "Action GitHub",
"description": "The label for document Github Action in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Cloud": {
"message": "Cloud",
"description": "The label for category Cloud in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Openhands Cloud": {
"message": "OpenHands Cloud",
"description": "The label for document Openhands Cloud in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Cloud GitHub Resolver": {
"message": "Résolveur GitHub Cloud",
"description": "The label for document Cloud GitHub Resolver in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.LLM Configuration": {
"message": "Configuration LLM",
"description": "The label for category LLM Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Providers": {
"message": "Fournisseurs",
"description": "The label for category Providers in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Azure": {
"message": "Azure",
"description": "The label for document Azure in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Google": {
"message": "Google",
"description": "The label for document Google in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Groq": {
"message": "Groq",
"description": "The label for document Groq in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.LiteLLM Proxy": {
"message": "Proxy LiteLLM",
"description": "The label for document LiteLLM Proxy in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.OpenAI": {
"message": "OpenAI",
"description": "The label for document OpenAI in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.OpenRouter": {
"message": "OpenRouter",
"description": "The label for document OpenRouter in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Runtime Configuration": {
"message": "Configuration d'Exécution",
"description": "The label for category Runtime Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Docker Runtime": {
"message": "Environnement Docker",
"description": "The label for document Docker Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Remote Runtime": {
"message": "Environnement Distant",
"description": "The label for document Remote Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Modal Runtime": {
"message": "Environnement Modal",
"description": "The label for document Modal Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Daytona Runtime": {
"message": "Environnement Daytona",
"description": "The label for document Daytona Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Local Runtime": {
"message": "Environnement Local",
"description": "The label for document Local Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Configuration Options": {
"message": "Options de Configuration",
"description": "The label for document Configuration Options in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Custom Sandbox": {
"message": "Bac à Sable Personnalisé",
"description": "The label for document Custom Sandbox in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Development Overview": {
"message": "Aperçu du Développement",
"description": "The label for document Development Overview in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Backend": {
"message": "Backend",
"description": "The label for document Backend in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Runtime": {
"message": "Environnement d'Exécution",
"description": "The label for document Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Debugging": {
"message": "Débogage",
"description": "The label for document Debugging in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Evaluation": {
"message": "Évaluation",
"description": "The label for document Evaluation in sidebar docsSidebar"
}
}

View File

@@ -1,5 +0,0 @@
# Documentation Python
La documentation apparaîtra ici après le déploiement.

View File

@@ -1,5 +0,0 @@
{
"items": ["python/python"],
"label": "Backend",
"type": "categorie"
}

View File

@@ -1,25 +0,0 @@
# À propos d'OpenHands
## Stratégie de recherche
Réaliser une réplication complète d'applications de qualité production avec des LLM est une entreprise complexe. Notre stratégie comprend :
- **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
Notre Agent par défaut est actuellement le [CodeActAgent](agents), qui est capable de générer du code et de gérer des fichiers.
## Construit avec
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 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.

View File

@@ -1,23 +0,0 @@
# 🧠 Agent Principal et Capacités
## CodeActAgent
### Description
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 :
1. **Converser** : Communiquer avec les humains en langage naturel pour demander des clarifications, des confirmations, etc.
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 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)
### Démo
https://github.com/All-Hands-AI/OpenHands/assets/38853559/f592a192-e86c-4f48-ad31-d69282d5f6ac
_Exemple de CodeActAgent avec `gpt-4-turbo-2024-04-09` réalisant une tâche de science des données (régression linéaire)_.

View File

@@ -1,50 +0,0 @@
---
sidebar_position: 4
---
# 🏛️ Aperçu de l'Architecture Système
Voici un aperçu 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 avec l'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.
![system_architecture.svg](/img/system_architecture.svg)
Cet aperçu est simplifié pour montrer les principaux composants et leurs interactions. Pour une vue plus détaillée de l'architecture du backend, consultez la section [Architecture du Backend](#backend-architecture-fr).
# Architecture du Backend {#backend-architecture-fr}
_**Avertissement**: L'architecture du backend est en cours de développement et est sujette à modifications. Le schéma suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du schéma._
![backend_architecture.svg](/img/backend_architecture.svg)
<details>
<summary>Mise à jour de ce Schéma</summary>
<div>
La génération du schéma d'architecture du backend est partiellement automatisée.
Le schéma est généré à partir des annotations de type dans le code en utilisant l'outil py2puml.
Le schéma est ensuite revu manuellement, ajusté et exporté en PNG et SVG.
## Prérequis
- Un environnement Python 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é
## Étapes
1. Générez automatiquement le schéma en exécutant la commande suivante depuis la racine du dépôt :
`py2puml openhands openhands > docs/architecture/backend_architecture.puml`
2. Ouvrez 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. Révisez le PUML généré et apportez toutes les modifications nécessaires au schéma (ajoutez les parties manquantes, corrigez les erreurs, améliorez l'agencement).
_py2puml crée le schéma à partir des annotations de type dans le code, donc les annotations de type manquantes ou incorrectes peuvent entraîner un schéma incomplet ou incorrect._
4. Examinez la différence entre le nouveau schéma et le précédent et vérifiez manuellement si les modifications sont correctes.
_Assurez-vous de ne pas supprimer les parties ajoutées manuellement au schéma par le passé et qui sont toujours pertinentes._
5. Ajoutez le hash du commit qui a été utilisé pour générer le schéma dans le pied de page du schéma.
6. Exporte le schéma sous forme de fichiers PNG et SVG et remplacez les schémas existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par exemple [PlantText](https://www.planttext.com/))
</div>
</details>

View File

@@ -1,54 +0,0 @@
# 🏛️ 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="Diagramme d'Architecture OpenHands 4 juillet 2024" />
<p><em>Diagramme d'Architecture OpenHands (4 juillet 2024)</em></p>
</div>
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 Frontend {#frontend-architecture-en}
![system_architecture.svg](/img/system_architecture.svg)
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 Backend {#backend-architecture-en}
_**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>
<div>
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 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é
## Étapes
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 exemple Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
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. 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 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>

View File

@@ -1,128 +0,0 @@
# 📦 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.
## 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 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 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 ?
Le système Runtime d'OpenHands utilise une architecture client-serveur implémentée avec des conteneurs Docker. Voici un aperçu de son fonctionnement :
```mermaid
graph TD
A[Image Docker personnalisée fournie par l'utilisateur] --> B[Backend OpenHands]
B -->|Construit| C[Image OH Runtime]
C -->|Lance| D[Action Executor]
D -->|Initialise| E[Navigateur]
D -->|Initialise| F[Shell Bash]
D -->|Initialise| G[Plugins]
G -->|Initialise| L[Serveur Jupyter]
B -->|Crée| H[Agent]
B -->|Crée| I[EventStream]
I <--->|Exécute l'action pour
obtenir l'observation
via API REST
| D
H -->|Génère l'action| I
I -->|Obtient l'observation| H
subgraph "Conteneur Docker"
D
E
F
G
L
end
```
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 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 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 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 êtes intéressé par plus de détails.
### Système de marquage d'images
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 :
- **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`)
#### 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 openhands.
#### 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 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.
#### Tag versionné - Le plus générique
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 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 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 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 Runtime
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.
*Plus de détails sur le système de plugins sont encore en construction - les contributions sont les bienvenues !*
Aspects clés du système de plugins :
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)

View File

@@ -1,177 +0,0 @@
# 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['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.

View File

@@ -1,56 +0,0 @@
# Résolveur de Problèmes Cloud
Le Résolveur de Problèmes Cloud automatise les corrections de code et fournit une assistance intelligente pour vos dépôts sur GitHub et GitLab.
## Configuration
Le Résolveur de Problèmes Cloud est disponible automatiquement lorsque vous accordez l'accès au dépôt OpenHands Cloud :
- [Accès au dépôt GitHub](./github-installation#adding-repository-access)
- [Accès au dépôt GitLab](./gitlab-installation#adding-repository-access)
![Ajout d'accès au dépôt à OpenHands](/img/cloud/add-repo.png)
## Utilisation
Après avoir accordé l'accès au dépôt OpenHands Cloud, vous pouvez utiliser le Résolveur de Problèmes Cloud sur les problèmes et les pull/merge requests dans vos dépôts.
### Travailler avec les Problèmes
Sur votre dépôt, étiquetez un problème avec `openhands` ou ajoutez un message commençant par `@openhands`. OpenHands va :
1. Commenter le problème pour vous faire savoir qu'il y travaille
- Vous pouvez cliquer sur le lien pour suivre la progression sur OpenHands Cloud
2. Ouvrir une pull request (GitHub) ou une merge request (GitLab) 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 PR/MR
![Résolveur de problèmes OpenHands en action](/img/cloud/issue-resolver.png)
#### Exemples de Commandes pour les Problèmes
Voici quelques exemples de commandes que vous pouvez utiliser avec le résolveur de problèmes :
```
@openhands lisez la description du problème et corrigez-le
```
### Travailler avec les Pull/Merge Requests
Pour qu'OpenHands travaille sur les pull requests (GitHub) ou les merge requests (GitLab), mentionnez `@openhands` dans les commentaires pour :
- Poser des questions
- Demander des mises à jour
- Obtenir des explications de code
OpenHands va :
1. Commenter pour vous faire savoir qu'il y travaille
2. Effectuer la tâche demandée
#### Exemples de Commandes pour les Pull/Merge Requests
Voici quelques exemples de commandes que vous pouvez utiliser avec les pull/merge requests :
```
@openhands reflétez les commentaires de la revue
```
```
@openhands corrigez les conflits de fusion et assurez-vous que le CI passe
```

View File

@@ -1,29 +0,0 @@
# Interface Cloud
L'interface Cloud fournit une interface web pour interagir avec OpenHands AI. Cette page explique comment accéder et utiliser l'interface Cloud d'OpenHands.
## Accès à l'Interface
L'interface Cloud d'OpenHands est accessible à [app.all-hands.dev](https://app.all-hands.dev). Vous devrez vous connecter avec votre compte GitHub ou GitLab pour accéder à l'interface.
<!-- Image will be added in a future update -->
<!-- ![Interface Cloud OpenHands](/img/docs/openhands-cloud-ui.png) -->
## Fonctionnalités Clés
Pour des informations détaillées sur les fonctionnalités disponibles dans l'interface Cloud d'OpenHands, veuillez consulter la section [Fonctionnalités Clés](../key-features.md) de la documentation.
## Paramètres
La page des paramètres vous permet de :
1. Configurer les préférences de votre compte
2. Gérer l'accès aux dépôts
3. Générer des clés API pour un accès programmatique
4. Personnaliser votre expérience OpenHands
## Prochaines Étapes
- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
- [En savoir plus sur l'API Cloud](./cloud-api.md) pour un accès programmatique
- [Retourner à la Mise en Route](./openhands-cloud.md)

View File

@@ -1,57 +0,0 @@
# Installation GitHub
Ce guide vous accompagne dans le processus d'installation et de configuration d'OpenHands Cloud pour vos dépôts GitHub.
## Prérequis
- Un compte GitHub
- Accès à OpenHands Cloud
## Étapes d'Installation
1. Connectez-vous à [OpenHands Cloud](https://app.all-hands.dev)
2. Si vous n'avez pas encore connecté votre compte GitHub :
- Cliquez sur `Se connecter à GitHub`
- Examinez et acceptez les conditions d'utilisation
- Autorisez l'application OpenHands AI
## Ajout d'Accès au Dépôt
Vous pouvez accorder à OpenHands l'accès à des dépôts spécifiques :
1. Cliquez sur le menu déroulant `Sélectionner un projet GitHub`, puis sélectionnez `Ajouter plus de dépôts...`
2. Sélectionnez votre organisation et choisissez les dépôts spécifiques auxquels vous souhaitez accorder l'accès à OpenHands.
- OpenHands demande des jetons à courte durée de vie (expiration de 8 heures) avec ces permissions :
- Actions : Lecture et écriture
- Administration : Lecture seule
- Statuts de commit : Lecture et écriture
- Contenus : Lecture et écriture
- Problèmes : 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 :
- Permission accordée pour le dépôt
- Permissions GitHub de l'utilisateur (propriétaire/collaborateur)
3. Cliquez sur `Installer & Autoriser`
![Ajout de l'accès au dépôt à OpenHands](/img/cloud/add-repo.png)
## Modification de l'Accès au Dépôt
Vous pouvez modifier l'accès au dépôt à tout moment :
* En utilisant le même workflow `Sélectionner un projet GitHub > Ajouter plus de dépôts`, ou
* En visitant la page Paramètres et en sélectionnant `Configurer les Dépôts GitHub` dans la section `Paramètres GitHub`.
## Utilisation d'OpenHands avec GitHub
Une fois que vous avez accordé l'accès au dépôt, vous pouvez utiliser OpenHands avec vos dépôts GitHub.
Pour plus de détails sur l'utilisation d'OpenHands avec les problèmes et les pull requests GitHub, consultez la documentation du [Résolveur de Problèmes Cloud](./cloud-issue-resolver.md).
## Prochaines Étapes
- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands

View File

@@ -1,50 +0,0 @@
# Installation GitLab
Ce guide vous accompagne dans le processus d'installation et de configuration d'OpenHands Cloud pour vos dépôts GitLab.
## Prérequis
- Un compte GitLab
- Accès à OpenHands Cloud
## Étapes d'Installation
1. Connectez-vous à [OpenHands Cloud](https://app.all-hands.dev)
2. Si vous n'avez pas encore connecté votre compte GitLab :
- Cliquez sur `Se connecter à GitLab`
- Examinez et acceptez les conditions d'utilisation
- Autorisez l'application OpenHands AI
## Ajout d'Accès au Dépôt
Vous pouvez accorder à OpenHands l'accès à des dépôts spécifiques :
1. Cliquez sur le menu déroulant `Sélectionner un projet GitLab`, puis sélectionnez `Ajouter plus de dépôts...`
2. Sélectionnez votre organisation et choisissez les dépôts spécifiques auxquels vous souhaitez accorder l'accès à OpenHands.
- OpenHands demande des permissions avec ces portées :
- api : Accès complet à l'API
- read_user : Lecture des informations utilisateur
- read_repository : Lecture des informations du dépôt
- write_repository : Écriture dans le dépôt
- L'accès au dépôt pour un utilisateur est accordé en fonction de :
- Permission accordée pour le dépôt
- Permissions GitLab de l'utilisateur (propriétaire/mainteneur/développeur)
3. Cliquez sur `Installer & Autoriser`
## Modification de l'Accès au Dépôt
Vous pouvez modifier l'accès au dépôt à tout moment :
* En utilisant le même workflow `Sélectionner un projet GitLab > Ajouter plus de dépôts`, ou
* En visitant la page Paramètres et en sélectionnant `Configurer les Dépôts GitLab` dans la section `Paramètres GitLab`.
## Utilisation d'OpenHands avec GitLab
Une fois que vous avez accordé l'accès au dépôt, vous pouvez utiliser OpenHands avec vos dépôts GitLab.
Pour plus de détails sur l'utilisation d'OpenHands avec les problèmes et les merge requests GitLab, consultez la documentation du [Résolveur de Problèmes Cloud](./cloud-issue-resolver.md).
## Prochaines Étapes
- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
- [Utiliser le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et obtenir de l'aide
- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands

View File

@@ -1,24 +0,0 @@
# OpenHands Cloud
OpenHands Cloud est la version hébergée dans le cloud d'OpenHands par All Hands AI.
## Accès à OpenHands Cloud
Pour commencer avec OpenHands Cloud, visitez [app.all-hands.dev](https://app.all-hands.dev).
Vous serez invité à vous connecter avec votre compte GitHub ou GitLab :
1. Après avoir lu et accepté les conditions d'utilisation, cliquez sur `Se connecter à GitHub` ou `Se connecter à GitLab`.
2. Examinez les permissions demandées par OpenHands et autorisez l'application.
- OpenHands nécessitera certaines permissions de votre compte. Pour en savoir plus sur ces permissions,
vous pouvez cliquer sur le lien `En savoir plus` sur la page d'autorisation.
## Prochaines Étapes
Une fois que vous avez connecté votre compte, vous pouvez :
- [Installer l'Intégration GitHub](./github-installation.md) pour utiliser OpenHands avec vos dépôts GitHub
- [Installer l'Intégration GitLab](./gitlab-installation.md) pour utiliser OpenHands avec vos dépôts GitLab
- [Accéder à l'Interface Cloud](./cloud-ui.md) pour interagir avec l'interface web
- [Utiliser l'API Cloud](./cloud-api.md) pour interagir programmatiquement avec OpenHands
- [Configurer le Résolveur de Problèmes Cloud](./cloud-issue-resolver.md) pour automatiser les corrections de code et fournir une assistance intelligente

View File

@@ -1,395 +0,0 @@
# Options de Configuration
:::note
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
Les options de configuration principales sont définies dans la section `[core]` du fichier `config.toml`.
### Clés API
- `e2b_api_key`
- Type: `str`
- Défaut: `""`
- Description: Clé API pour E2B
- `modal_api_token_id`
- Type: `str`
- Défaut: `""`
- Description: ID de token API pour Modal
- `modal_api_token_secret`
- Type: `str`
- Défaut: `""`
- Description: Secret de token API pour Modal
### 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`
- Défaut: `"/tmp/cache"`
- Description: Chemin du répertoire de cache
### Débogage et Journalisation
- `debug`
- Type: `bool`
- Défaut: `false`
- Description: Activer le débogage
- `disable_color`
- Type: `bool`
- Défaut: `false`
- Description: Désactiver la couleur dans la sortie du terminal
### Trajectoires
- `save_trajectory_path`
- 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.
- `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`
- Défaut: `"/tmp/file_store"`
- Description: Chemin du stockage de fichiers
- `file_store`
- Type: `str`
- Défaut: `"memory"`
- Description: Type de stockage de fichiers
- `file_uploads_allowed_extensions`
- 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`
- Défaut: `0`
- Description: Taille maximale de fichier pour les téléchargements, en mégaoctets
- `file_uploads_restrict_file_types`
- Type: `bool`
- Défaut: `false`
- Description: Restreindre les types de fichiers pour les téléchargements
- `file_uploads_allowed_extensions`
- Type: `liste de str`
- Défaut: `[".*"]`
- Description: Liste des extensions de fichiers autorisées pour les téléchargements
### Gestion des Tâches
- `max_budget_per_task`
- Type: `float`
- Défaut: `0.0`
- Description: Budget maximum par tâche (0.0 signifie pas de limite)
- `max_iterations`
- Type: `int`
- Défaut: `100`
- Description: Nombre maximum d'itérations
### 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_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_path` **(Déprécié)**
- Type: `str`
- Défaut: `""`
- Description: Chemin pour monter l'espace de travail. **Déprécié: Utilisez `SANDBOX_VOLUMES` à la place.**
- `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`
- Défaut: `true`
- Description: Exécuter en tant qu'OpenHands
- `runtime`
- Type: `str`
- Défaut: `"docker"`
- Description: Environnement d'exécution
- `default_agent`
- Type: `str`
- Défaut: `"CodeActAgent"`
- Description: Nom de l'agent par défaut
- `jwt_secret`
- 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`.
:::note
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.
:::
**Identifiants AWS**
- `aws_access_key_id`
- Type: `str`
- Défaut: `""`
- Description: ID de clé d'accès AWS
- `aws_region_name`
- Type: `str`
- Défaut: `""`
- Description: Nom de région AWS
- `aws_secret_access_key`
- Type: `str`
- Défaut: `""`
- Description: Clé d'accès secrète AWS
### Configuration API
- `api_key`
- Type: `str`
- Défaut: `None`
- Description: Clé API à utiliser
- `base_url`
- Type: `str`
- Défaut: `""`
- Description: URL de base de l'API
- `api_version`
- Type: `str`
- Défaut: `""`
- Description: Version de l'API
- `input_cost_per_token`
- Type: `float`
- Défaut: `0.0`
- Description: Coût par token d'entrée
- `output_cost_per_token`
- Type: `float`
- Défaut: `0.0`
- Description: Coût par token de sortie
### Fournisseur LLM personnalisé
- `custom_llm_provider`
- Type: `str`
- Défaut: `""`
- Description: Fournisseur LLM personnalisé
### Gestion des messages
- `max_message_chars`
- 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`
- Défaut: `0`
- Description: Nombre maximum de tokens d'entrée
- `max_output_tokens`
- Type: `int`
- Défaut: `0`
- Description: Nombre maximum de tokens de sortie
### Sélection du modèle
- `model`
- Type: `str`
- Défaut: `"claude-3-5-sonnet-20241022"`
- Description: Modèle à utiliser
### Nouvelles tentatives
- `num_retries`
- Type: `int`
- Défaut: `8`
- Description: Nombre de tentatives à effectuer
- `retry_max_wait`
- Type: `int`
- Défaut: `120`
- Description: Temps d'attente maximum (en secondes) entre les tentatives
- `retry_min_wait`
- Type: `int`
- Défaut: `15`
- Description: Temps d'attente minimum (en secondes) entre les tentatives
- `retry_multiplier`
- Type: `float`
- Défaut: `2.0`
- Description: Multiplicateur pour le calcul de backoff exponentiel
### Options avancées
- `drop_params`
- 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`
- 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`
- Défaut: `""`
- Description: URL de base pour l'API OLLAMA
- `temperature`
- Type: `float`
- Défaut: `0.0`
- Description: Température pour l'API
- `timeout`
- Type: `int`
- Défaut: `0`
- Description: Délai d'attente pour l'API
- `top_p`
- Type: `float`
- Défaut: `1.0`
- Description: Top p pour l'API
- `disable_vision`
- 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
Les options de configuration de l'agent sont définies dans les sections `[agent]` et `[agent.<agent_name>]` du fichier `config.toml`.
### Configuration LLM
- `llm_config`
- Type: `str`
- Défaut: `'your-llm-config-group'`
- Description: Le nom de la configuration LLM à utiliser
### Configuration de l'espace d'action
- `function_calling`
- Type: `bool`
- Défaut: `true`
- Description: Si l'appel de fonction est activé
- `enable_browsing`
- 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`
- Défaut: `false`
- Description: Si l'éditeur LLM est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
- `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`
- Défaut: `true`
- Description: Si les microagents doivent être utilisés
- `disabled_microagents`
- 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`
- Défaut: `120`
- Description: Délai d'attente du sandbox en secondes
- `user_id`
- 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

View File

@@ -1,81 +0,0 @@
# 💿 Comment Créer un Soutien Docker sur Mesure
Le sandbox par défaut OpenHands est équipé d'une configuration ubuntu minimaliste. Votre cas d'utilisation pourrait nécessiter des logiciels installés par défaut. Cet article vous enseignera comment réaliser cela en utilisant une image docker personnalisée.
## Configuration
Assurez-vous de pouvoir utiliser OpenHands en suivant la documentation [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
## Créer Votre Image Docker
Ensuite, vous devez créer votre image docker personnalisée qui doit être basée sur debian/ubuntu. Par exemple, si nous souhaitons que OpenHands ait accès au "node" binaire, nous utiliserions ce Dockerfile:
```bash
# Commencez avec l'image ubuntu la plus récente
FROM ubuntu:latest
# Effectuez les mises à jour nécessaires
RUN apt-get update && apt-get install
# Installez nodejs
RUN apt-get install -y nodejs
```
Ensuite, construisez votre image docker avec le nom de votre choix. Par exemple "image_personnalisée". Pour cela, créez un répertoire et placez le fichier à l'intérieur avec le nom "Dockerfile", puis dans le répertoire exécutez cette commande:
```bash
docker build -t image_personnalisée .
```
Cela produira une nouvelle image appelée ```image_personnalisée``` qui sera disponible dans Docker Engine.
> Remarque: Dans la configuration décrite ici, OpenHands va fonctionner en tant que utilisateur "openhands" à l'intérieur du sandbox et donc tous les packages installés via le Dockerfile seront disponibles pour tous les utilisateurs sur le système, pas seulement root.
>
> L'installation avec apt-get ci-dessus installe nodejs pour tous les utilisateurs.
## Spécifiez votre image personnalisée dans le fichier config.toml
La configuration OpenHands se fait via le fichier de niveau supérieur ```config.toml``` .
Créez un fichier ```config.toml``` dans le répertoire OpenHands et entrez ces contenus:
```toml
[core]
workspace_base="./workspace"
run_as_openhands=true
[sandbox]
base_container_image="image_personnalisée"
```
> Assurez-vous que ```base_container_image``` est défini sur le nom de votre image personnalisée précédente.
## Exécution
Exécutez OpenHands en exécutant ```make run``` dans le répertoire racine.
Naviguez vers ```localhost:3001``` et vérifiez si vos dépendances souhaitées sont disponibles.
Dans le cas de l'exemple ci-dessus, la commande ```node -v``` dans la console produit ```v18.19.1```
Félicitations !
## Explication technique
Veuillez consulter le [chapitre sur les images Docker personnalisées dans la documentation d'exécution](https://docs.all-hands.dev/fr/modules/usage/architecture/runtime) pour obtenir des explications plus détaillées.
## Dépannage / Erreurs
### Erreur: ```useradd: UID 1000 est non unique```
Si vous voyez cette erreur dans la sortie de la console, il s'agit du fait que OpenHands essaie de créer le utilisateur openhands dans le sandbox avec un ID d'utilisateur de 1000, cependant cet ID d'utilisateur est déjà utilisé dans l'image (pour une raison inconnue). Pour résoudre ce problème, changez la valeur du champ user_id dans le fichier config.toml en une valeur différente:
```toml
[core]
workspace_base="./workspace"
run_as_openhands=true
[sandbox]
base_container_image="image_personnalisée"
user_id="1001"
```
### Erreurs de port d'utilisation
Si vous voyez un message d'erreur indiquant que le port est utilisé ou indisponible, essayez de supprimer toutes les containers docker en cours d'exécution (exécutez `docker ps` et `docker rm` des containers concernés) puis ré-exécutez ```make run```

View File

@@ -1,23 +0,0 @@
# 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 ..
```

View File

@@ -1,38 +0,0 @@
# ✅ 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!
## 📝 Comment Fournir des Commentaires
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é
### Paramètres de partage des données
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** 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 ?
Les données sont collectées et stockées par [All Hands AI](https://all-hands.dev), une entreprise fondée par les mainteneurs d'OpenHands pour soutenir et améliorer OpenHands.
### 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 :
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 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 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 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.

View File

@@ -1,99 +0,0 @@
# Premiers pas avec OpenHands
Vous avez [exécuté OpenHands](./installation) et vous avez
[configuré votre LLM](./installation#setup). Et maintenant ?
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
Commencez par un simple exemple "hello world". Cela pourrait être plus délicat qu'il n'y paraît !
Demandez à l'agent :
> Écrivez un script bash hello.sh qui affiche "hello world!"
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, puis itérez.
> Modifiez hello.sh pour qu'il accepte un nom comme premier argument, mais utilise "world" par défaut
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 script Ruby, et exécutez-le
## Construire à partir de zéro
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 :
> Construisez une application TODO frontend uniquement en React. Tout l'état doit être stocké dans localStorage.
Une fois la structure de base en place, continuez à affiner :
> Permettez d'ajouter une date d'échéance optionnelle à chaque tâche.
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 est excellent pour ajouter du nouveau code à une base de code existante.
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`.
> Ajoutez une action GitHub qui vérifie le code dans ce dépôt.
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.
> Modifiez ./backend/api/routes.js pour ajouter une nouvelle route qui renvoie une liste de toutes les tâches.
> 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 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.
> Renommez toutes les variables à une seule lettre dans ./app.go.
> Divisez la fonction `build_and_deploy_widgets` en deux fonctions, `build_widgets` et `deploy_widgets` dans widget.php.
> Décomposez ./api/routes.js en fichiers séparés pour chaque route.
## Corrections de bugs
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.
> 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. Rendez-la insensible à la casse.
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 une chaîne vide. Écrivez un test qui reproduit ce bug, puis corrigez le code pour qu'il passe.
## Plus
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.
Consultez [Meilleures pratiques de prompt](./prompting/prompting-best-practices) pour plus de conseils sur la façon de tirer le meilleur parti d'OpenHands.

View File

@@ -1,55 +0,0 @@
# 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.
Ce mode est différent du [mode headless](headless-mode), qui est non interactif et mieux adapté aux scripts.
## Avec Python
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 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, 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 :
1. Définissez les variables d'environnement suivantes dans votre terminal :
- `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. 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.40-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-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.40 \
python -m openhands.core.cli
```
Cette commande lancera une session interactive dans Docker où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
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é.

View File

@@ -1,95 +0,0 @@
# 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 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 :
- 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 ignorer la section `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é, vous pourriez créer un `Dockerfile` avec le contenu suivant :
```dockerfile
FROM nikolaik/python-nodejs:python3.12-nodejs22
# Install required packages
RUN apt-get update && apt-get install -y ruby
```
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.
## Utilisation de la commande Docker
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
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]
...
[sandbox]
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 lançant ```make run``` dans le répertoire principal.

View File

@@ -1,71 +0,0 @@
# Débogage
Ce qui suit est destiné à servir d'introduction au débogage d'OpenHands à des fins de développement.
## Serveur / VSCode
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/` :
```
{
"version": "0.2.0",
"configurations": [
{
"name": "OpenHands CLI",
"type": "debugpy",
"request": "launch",
"module": "openhands.core.cli",
"justMyCode": false
},
{
"name": "OpenHands WebApp",
"type": "debugpy",
"request": "launch",
"module": "uvicorn",
"args": [
"openhands.server.listen:app",
"--reload",
"--reload-exclude",
"${workspaceFolder}/workspace",
"--port",
"3000"
],
"justMyCode": false
}
]
}
```
Des configurations de débogage plus spécifiques qui incluent davantage de paramètres peuvent être spécifiées :
```
...
{
"name": "Debug CodeAct",
"type": "debugpy",
"request": "launch",
"module": "openhands.core.main",
"args": [
"-t",
"Ask me what your task is.",
"-d",
"${workspaceFolder}/workspace",
"-c",
"CodeActAgent",
"-l",
"llm.o1",
"-n",
"prompts"
],
"justMyCode": false
}
...
```
Les valeurs dans l'extrait ci-dessus peuvent être mises à jour de sorte que :
* *t* : la tâche
* *d* : le répertoire de travail openhands
* *c* : l'agent
* *l* : la configuration LLM (prédéfinie dans config.toml)
* *n* : nom de session (par exemple, nom d'eventstream)

View File

@@ -1,74 +0,0 @@
---
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`

View File

@@ -1,278 +0,0 @@
# É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 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 suivre la plupart des configurations.
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
model = "claude-3-5-sonnet-20241022"
api_key = "sk-XXX"
[llm.eval_gpt4_1106_preview_llm]
model = "gpt-4-1106-preview"
api_key = "XXX"
temperature = 0.0
[llm.eval_some_openai_compatible_model_llm]
model = "openai/MODEL_NAME"
base_url = "https://OPENAI_COMPATIBLE_URL/v1"
api_key = "XXX"
temperature = 0.0
```
## Comment utiliser OpenHands en ligne de commande
OpenHands peut être exécuté depuis la ligne de commande en utilisant le format suivant :
```bash
poetry run python ./openhands/core/main.py \
-i <max_iterations> \
-t "<task_description>" \
-c <agent_class> \
-l <llm_config>
```
Par exemple :
```bash
poetry run python ./openhands/core/main.py \
-i 10 \
-t "Write me a bash script that prints hello world." \
-c CodeActAgent \
-l llm
```
Cette commande exécute OpenHands avec :
- Un maximum de 10 itérations
- La description de tâche spécifiée
- 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. 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, 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.
## 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 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
Pour créer un workflow d'évaluation pour votre benchmark, suivez ces étapes :
1. Importez les utilitaires OpenHands pertinents :
```python
import openhands.agenthub
from evaluation.utils.shared import (
EvalMetadata,
EvalOutput,
make_metadata,
prepare_dataset,
reset_logger_for_multiprocessing,
run_evaluation,
)
from openhands.controller.state.state import State
from openhands.core.config import (
AppConfig,
SandboxConfig,
get_llm_config_arg,
parse_arguments,
)
from openhands.core.logger import openhands_logger as logger
from openhands.core.main import create_runtime, run_controller
from openhands.events.action import CmdRunAction
from openhands.events.observation import CmdOutputObservation, ErrorObservation
from openhands.runtime.runtime import Runtime
```
2. Créez une configuration :
```python
def get_config(instance: pd.Series, metadata: EvalMetadata) -> AppConfig:
config = AppConfig(
default_agent=metadata.agent_class,
runtime='docker',
max_iterations=metadata.max_iterations,
sandbox=SandboxConfig(
base_container_image='your_container_image',
enable_auto_lint=True,
timeout=300,
),
)
config.set_llm_config(metadata.llm_config)
return config
```
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
# Par exemple, définir des variables d'environnement, préparer des fichiers, etc.
pass
```
4. Créez une fonction pour traiter chaque instance :
```python
from openhands.utils.async_utils import call_async_from_sync
def process_instance(instance: pd.Series, metadata: EvalMetadata) -> EvalOutput:
config = get_config(instance, metadata)
runtime = create_runtime(config)
call_async_from_sync(runtime.connect)
initialize_runtime(runtime, instance)
instruction = get_instruction(instance, metadata)
state = run_controller(
config=config,
task_str=instruction,
runtime=runtime,
fake_user_response_fn=your_user_response_function,
)
# Évaluez les actions de l'agent
evaluation_result = await evaluate_agent_actions(runtime, instance)
return EvalOutput(
instance_id=instance.instance_id,
instruction=instruction,
test_result=evaluation_result,
metadata=metadata,
history=compatibility_for_eval_history_pairs(state.history),
metrics=state.metrics.get() if state.metrics else None,
error=state.last_error if state and state.last_error else None,
)
```
5. Exécutez l'évaluation :
```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')
instances = prepare_dataset(your_dataset, output_file, eval_n_limit)
await run_evaluation(
instances,
metadata,
output_file,
num_workers,
process_instance
)
```
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` 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 fonction `user_response_fn`
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 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
3. Si l'Action est exécutable (par exemple, CmdRunAction, IPythonRunCellAction) :
- 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 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
Voici une représentation visuelle plus précise :
```
[Agent]
|
v
[Émet Action]
|
v
[L'Action est-elle exécutable ?]
/ \
Oui Non
| |
v v
[Runtime] [user_response_fn]
| |
v v
[Renvoie Observation] [Réponse simulée]
\ /
\ /
v v
[L'agent reçoit le feedback]
|
v
[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 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 souhaitez tester la capacité de l'agent à accomplir des tâches avec une intervention humaine minimale.
### Exemple d'implémentation
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 = (
'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:
# 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:
# let the agent know that it can give up when it has tried 3 times
return (
msg
+ 'If you want to give up, run: <execute_bash> exit </execute_bash>.\n'
)
return msg
```
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, elle lui fournit une option pour abandonner
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.

View File

@@ -1,51 +0,0 @@
# Utilisation de l'Action GitHub OpenHands
Ce guide explique comment utiliser l'Action GitHub OpenHands dans vos propres projets.
## 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 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 l'issue.
## 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 du Résolveur OpenHands](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md).
## Conseils d'Utilisation
### Résolution itérative
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 **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
### Ajouter des paramètres personnalisés au dépôt
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 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 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/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"` |

View File

@@ -1,142 +0,0 @@
# Mode GUI
OpenHands fournit un mode d'Interface Graphique Utilisateur (GUI) pour interagir avec l'assistant IA.
## Installation et Configuration
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).
## Interagir avec l'interface graphique
### Configuration initiale
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 les modifications` pour appliquer les paramètres.
### 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
OpenHands exporte automatiquement un `GITHUB_TOKEN` vers l'environnement shell s'il est fourni :
<details>
<summary>Configuration d'un jeton GitHub</summary>
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>
<details>
<summary>Politiques de jetons organisationnels</summary>
Si vous travaillez avec des dépôts organisationnels, une configuration supplémentaire peut être nécessaire :
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>
<details>
<summary>Dépannage</summary>
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.
- Essayez de régénérer le jeton.
- **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.
- **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>
#### Configuration du jeton GitLab
OpenHands exporte automatiquement un `GITLAB_TOKEN` vers l'environnement shell s'il est fourni :
<details>
<summary>Configuration d'un jeton GitLab</summary>
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` (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>
<details>
<summary>Dépannage</summary>
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.
- **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>
### Paramètres avancés
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 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 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
- 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 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é.

View File

@@ -1,59 +0,0 @@
# 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.
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 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, 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 Headless avec Docker :
1. Définissez les variables d'environnement suivantes dans votre terminal :
- `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"`).
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.40-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-e LOG_ALL_EVENTS=true \
-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.40 \
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`

View File

@@ -1,18 +0,0 @@
# Persistance des données de session
Avec l'installation standard, les données de session sont stockées en mémoire. Actuellement, si le service OpenHands est redémarré,
les sessions précédentes deviennent invalides (un nouveau secret est généré) et ne sont donc pas récupérables.
## Comment persister les données de session
### Workflow de développement
Dans le fichier `config.toml`, spécifiez ce qui suit :
```
[core]
...
file_store="local"
file_store_path="/absolute/path/to/openhands/cache/directory"
jwt_secret="secretpass"
```

View File

@@ -1,121 +0,0 @@
# Exécution d'OpenHands
## Configuration système requise
- 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 dans Docker.
```bash
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.40-nikolaik
docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.40-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.40
```
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/usage/runtimes/docker#connecting-to-your-filesystem),
exécuter OpenHands en [mode headless](https://docs.all-hands.dev/usage/how-to/headless-mode) scriptable,
interagir avec lui via une [CLI conviviale](https://docs.all-hands.dev/usage/how-to/cli-mode),
ou l'exécuter sur des problèmes étiquetés avec [une action GitHub](https://docs.all-hands.dev/usage/how-to/github-action).
## Configuration
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.
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.
### Obtenir une clé API
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 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.
Pour le flux de travail 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/usage/troubleshooting).

View File

@@ -1,109 +0,0 @@
---
sidebar_position: 1
---
# 💻 OpenHands
OpenHands est un **ingénieur logiciel IA autonome** capable d'exécuter des tâches d'ingénierie complexes et de collaborer activement avec les utilisateurs sur des projets de développement logiciel.
Ce projet est entièrement open-source, vous pouvez donc l'utiliser et le modifier comme bon vous semble.
:::tip
Explorez le code source d'OpenHands sur [GitHub](https://github.com/All-Hands-AI/OpenHands) ou rejoignez l'une de nos communautés !
<a href="https://github.com/All-Hands-AI/OpenHands/graphs/contributors">
<img
src="https://img.shields.io/github/contributors/All-Hands-AI/OpenHands?style=for-the-badge"
alt="Contributors"
/>
</a>
<a href="https://github.com/All-Hands-AI/OpenHands/network/members">
<img
src="https://img.shields.io/github/forks/All-Hands-AI/OpenHands?style=for-the-badge"
alt="Forks"
/>
</a>
<a href="https://github.com/All-Hands-AI/OpenHands/stargazers">
<img
src="https://img.shields.io/github/stars/All-Hands-AI/OpenHands?style=for-the-badge"
alt="Stargazers"
/>
</a>
<a href="https://github.com/All-Hands-AI/OpenHands/issues">
<img
src="https://img.shields.io/github/issues/All-Hands-AI/OpenHands?style=for-the-badge"
alt="Issues"
/>
</a>
<br></br>
<a href="https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE">
<img
src="https://img.shields.io/github/license/All-Hands-AI/OpenHands?style=for-the-badge"
alt="MIT License"
/>
</a>
<br></br>
<a href="https://join.slack.com/t/openhands-ai/shared_invite/zt-34zm4j0gj-Qz5kRHoca8DFCbqXPS~f_A">
<img
src="https://img.shields.io/badge/Slack-Join%20Us-red?logo=slack&logoColor=white&style=for-the-badge"
alt="Join our Slack community"
/>
</a>
<a href="https://discord.gg/ESHStjSjD4">
<img
src="https://img.shields.io/badge/Discord-Join%20Us-purple?logo=discord&logoColor=white&style=for-the-badge"
alt="Join our Discord community"
/>
</a>
:::
## 🛠️ Pour commencer
La manière la plus simple d'exécuter OpenHands est à l'intérieur d'un conteneur Docker. Il fonctionne mieux avec la version la plus récente de Docker, `26.0.0`.
Vous devez utiliser Linux, Mac OS ou WSL sur Windows.
Pour démarrer OpenHands dans un conteneur docker, exécutez les commandes suivantes dans votre terminal :
:::warning
Lorsque vous exécutez la commande suivante, les fichiers dans `./workspace` peuvent être modifiés ou supprimés.
:::
```bash
WORKSPACE_BASE=$(pwd)/workspace
docker run -it \
--pull=always \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app-$(date +%Y%m%d%H%M%S) \
ghcr.io/all-hands-ai/openhands:main
```
Vous trouverez OpenHands fonctionnant à l'adresse [http://localhost:3000](http://localhost:3000) avec accès à `./workspace`. Pour qu'OpenHands fonctionne sur votre code, placez-le dans `./workspace`.
OpenHands n'aura accès qu'à ce dossier de workspace. Le reste de votre système ne sera pas affecté car il s'exécute dans un bac à sable sécurisé de docker.
:::tip
Si vous souhaitez utiliser la version **(instable !)** la plus récente, vous pouvez utiliser `ghcr.io/all-hands-ai/openhands:main` comme image (dernière ligne).
:::
Pour le workflow de développement, consultez [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Avez-vous des problèmes ? Consultez notre [Guide de dépannage](https://docs.all-hands.dev/usage/troubleshooting).
:::warning
OpenHands est actuellement en cours de développement, mais vous pouvez déjà exécuter la version alpha pour voir le système de bout en bout en action.
:::
[contributors-shield]: https://img.shields.io/github/contributors/All-Hands-AI/OpenHands?style=for-the-badge
[contributors-url]: https://github.com/All-Hands-AI/OpenHands/graphs/contributors
[forks-shield]: https://img.shields.io/github/forks/All-Hands-AI/OpenHands?style=for-the-badge
[forks-url]: https://github.com/All-Hands-AI/OpenHands/network/members
[stars-shield]: https://img.shields.io/github/stars/All-Hands-AI/OpenHands?style=for-the-badge
[stars-url]: https://github.com/All-Hands-AI/OpenHands/stargazers
[issues-shield]: https://img.shields.io/github/issues/All-Hands-AI/OpenHands?style=for-the-badge
[issues-url]: https://github.com/All-Hands-AI/OpenHands/issues
[license-shield]: https://img.shields.io/github/license/All-Hands-AI/OpenHands?style=for-the-badge
[license-url]: https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE

View File

@@ -1,29 +0,0 @@
# 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 les fichiers.
- Peut également être utilisé pour télécharger et envoyer 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 les sites web.
- Le navigateur n'est pas interactif.

View File

@@ -1,41 +0,0 @@
# 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
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>" # ex. "2023-05-15"
```
Exemple :
```bash
docker run -it --pull=always \
-e LLM_API_VERSION="2023-05-15"
...
```
Ensuite, dans les paramètres de l'interface OpenHands :
:::note
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.
:::
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
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_API_VERSION="<api-version>" # ex. "2024-02-15-preview"
```

View File

@@ -1,37 +0,0 @@
# Azure OpenAI LLM
## Complétion
OpenHands utilise LiteLLM pour les appels de complétion. Vous pouvez trouver leur documentation sur Azure [ici](https://docs.litellm.ai/docs/providers/azure)
### Configurations openai Azure
Lors de l'exécution de l'image Docker OpenHands, vous devrez définir les variables d'environnement suivantes en utilisant `-e` :
```
LLM_BASE_URL="<azure-api-base-url>" # e.g. "https://openai-gpt-4-test-v-1.openai.azure.com/"
LLM_API_KEY="<azure-api-key>"
LLM_MODEL="azure/<your-gpt-deployment-name>"
LLM_API_VERSION = "<api-version>" # e.g. "2024-02-15-preview"
```
:::note
Vous pouvez trouver le nom de votre déploiement ChatGPT sur la page des déploiements sur Azure. Par défaut ou initialement, il pourrait être le même que le nom du modèle de chat (par exemple 'GPT4-1106-preview'), mais il n'est pas obligé de l'être. Exécutez OpenHands, et une fois chargé dans le navigateur, allez dans Paramètres et définissez le modèle comme suit : "azure/&lt;your-actual-gpt-deployment-name&gt;". Si ce n'est pas dans la liste, entrez votre propre texte et enregistrez-le.
:::
## 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/)
### Configurations openai Azure
Le modèle utilisé pour les embeddings Azure OpenAI est "text-embedding-ada-002".
Vous avez besoin du nom de déploiement correct pour ce modèle dans votre compte Azure.
Lors de l'exécution d'OpenHands dans Docker, définissez les variables d'environnement suivantes en utilisant `-e` :
```
LLM_EMBEDDING_MODEL="azureopenai"
LLM_EMBEDDING_DEPLOYMENT_NAME = "<your-embedding-deployment-name>" # e.g. "TextEmbedding...<etc>"
LLM_API_VERSION = "<api-version>" # e.g. "2024-02-15-preview"
```

View File

@@ -1,136 +0,0 @@
# 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 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
Les configurations LLM nommées sont définies dans le fichier `config.toml` en utilisant des sections qui commencent par `llm.`. Par exemple :
```toml
# Configuration LLM par défaut
[llm]
model = "gpt-4"
api_key = "your-api-key"
temperature = 0.0
# Configuration LLM personnalisée pour un modèle moins cher
[llm.gpt3]
model = "gpt-3.5-turbo"
api_key = "your-api-key"
temperature = 0.2
# Une autre configuration personnalisée avec différents paramètres
[llm.high-creativity]
model = "gpt-4"
api_key = "your-api-key"
temperature = 0.8
top_p = 0.9
```
Chaque configuration nommée hérite de tous les paramètres de la section `[llm]` par défaut et peut remplacer n'importe lequel de ces paramètres. Vous pouvez définir autant de configurations personnalisées que nécessaire.
## Utilisation des configurations personnalisées
### Avec les agents
Vous pouvez spécifier quelle configuration LLM un agent doit utiliser en définissant le paramètre `llm_config` dans la section de configuration de l'agent :
```toml
[agent.RepoExplorerAgent]
# 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 = 'high-creativity'
```
### Options de configuration
Chaque configuration LLM nommée prend en charge toutes les mêmes options que la configuration LLM par défaut. Celles-ci incluent :
- Sélection du modèle (`model`)
- 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 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 [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** : 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 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 = "your-api-key"
temperature = 0.0
# Configuration moins chère pour l'exploration de dépôts
[llm.repo-explorer]
model = "gpt-3.5-turbo"
temperature = 0.2
# Configuration pour la génération de code
[llm.code-gen]
model = "gpt-4"
temperature = 0.0
max_output_tokens = 2000
[agent.RepoExplorerAgent]
llm_config = 'repo-explorer'
[agent.CodeWriterAgent]
llm_config = 'code-gen'
```
Dans cet exemple :
- 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 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.
:::

View File

@@ -1,29 +0,0 @@
# Google Gemini/Vertex
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 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` 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 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](../installation#running-openhands) :
```
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` 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;).

View File

@@ -1,28 +0,0 @@
# Google Gemini/Vertex LLM
## Complétion
OpenHands utilise LiteLLM pour les appels de complétion. Les ressources suivantes sont pertinentes pour utiliser OpenHands avec les LLMs de Google :
- [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
Pour utiliser Gemini via Google AI Studio lors de l'exécution de l'image Docker d'OpenHands, vous devez définir les variables d'environnement suivantes en utilisant `-e` :
```
GEMINI_API_KEY="<votre-cle-api-google>"
LLM_MODEL="gemini/gemini-1.5-pro"
```
### Configurations de Vertex AI - Google Cloud Platform
Pour utiliser Vertex AI via Google Cloud Platform lors de l'exécution de l'image Docker d'OpenHands, vous devez définir les variables d'environnement suivantes en utilisant `-e` :
```
GOOGLE_APPLICATION_CREDENTIALS="<dump-json-du-compte-de-service-gcp-json>"
VERTEXAI_PROJECT="<votre-id-de-projet-gcp>"
VERTEXAI_LOCATION="<votre-localisation-gcp>"
LLM_MODEL="vertex_ai/<modele-llm-desire>"
```

View File

@@ -1,22 +0,0 @@
# 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
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 [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

View File

@@ -1,20 +0,0 @@
# 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.
## Configuration
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`
* 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.
Référez-vous à la configuration de votre proxy LiteLLM pour la liste des modèles disponibles et leurs noms.

View File

@@ -1,92 +0,0 @@
# 🤖 Backends LLM
:::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 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).
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 :
- [anthropic/claude-sonnet-4-20250514](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)
:::warning
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 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 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. 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 :
- `Fournisseur LLM`
- `Modèle LLM`
- `Clé API`
- `URL de base` (via les paramètres `Avancés`)
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`
- `LLM_EMBEDDING_DEPLOYMENT_NAME`
- `LLM_DROP_PARAMS`
- `LLM_DISABLE_VISION`
- `LLM_CACHING_PROMPT`
Nous avons quelques guides pour exécuter OpenHands avec des fournisseurs de modèles spécifiques :
- [Azure](llms/azure-llms)
- [Google](llms/google-llms)
- [Groq](llms/groq)
- [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 taux
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 :
- `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 = 4
retry_min_wait = 5
retry_max_wait = 30
retry_multiplier = 2
```

View File

@@ -1,83 +0,0 @@
# LLM local avec SGLang ou vLLM
:::warning
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.
:::
## Actualités
- 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)).
## Télécharger le modèle depuis Huggingface
Par exemple, pour télécharger [OpenHands LM 32B v0.1](https://huggingface.co/all-hands/openhands-lm-32b-v0.1) :
```bash
huggingface-cli download all-hands/openhands-lm-32b-v0.1 --local-dir all-hands/openhands-lm-32b-v0.1
```
## 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
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
```
### Service avec vLLM
- 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
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
```
## Exécuter et configurer OpenHands
### Exécuter OpenHands
#### Utilisation de Docker
Exécutez OpenHands en utilisant [la commande docker run officielle](../installation#start-the-app).
#### Utilisation du mode développement
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="/path/to/your/workspace"
[llm]
model="openhands-lm-32b-v0.1"
ollama_base_url="http://localhost:8000"
```
Démarrez OpenHands en utilisant `make run`.
### Configurer OpenHands
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`)

View File

@@ -1,141 +0,0 @@
# LLM Local avec Ollama
Assurez-vous que le serveur Ollama est en cours d'exécution.
Pour des instructions détaillées de démarrage, consultez [ici](https://github.com/ollama/ollama)
Ce guide suppose que vous avez démarré ollama avec `ollama serve`. Si vous exécutez ollama différemment (par exemple, à l'intérieur de docker), les instructions pourraient devoir être modifiées. Veuillez noter que si vous utilisez WSL, la configuration par défaut de ollama bloque les requêtes des conteneurs docker. Voir [ici](#configuring-ollama-service-fr).
## Télécharger des modèles
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`. Des modèles plus grands offriront généralement de meilleures performances.
```bash
ollama pull codellama:7b
```
vous pouvez vérifier quels modèles vous avez téléchargés de cette manière :
```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
```
## Démarrer OpenHands
### Docker
Utilisez les instructions [ici](../intro) pour démarrer OpenHands en utilisant Docker.
Mais lors de l'exécution de `docker run`, vous devrez ajouter quelques arguments supplémentaires :
```bash
--add-host host.docker.internal:host-gateway \
-e LLM_API_KEY="ollama" \
-e LLM_BASE_URL="http://host.docker.internal:11434" \
```
Par exemple :
```bash
# Le répertoire que vous souhaitez qu'OpenHands modifie. DOIT être un chemin absolu !
export WORKSPACE_BASE=$(pwd)/workspace
docker run \
-it \
--pull=always \
--add-host host.docker.internal:host-gateway \
-e SANDBOX_USER_ID=$(id -u) \
-e LLM_API_KEY="ollama" \
-e LLM_BASE_URL="http://host.docker.internal:11434" \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 3000:3000 \
ghcr.io/all-hands-ai/openhands:main
```
Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
### Compiler à partir des sources
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` soit présent en exécutant `make setup-config` qui en créera un pour vous. Dans `config.toml`, saisissez les éléments suivants :
```
LLM_MODEL="ollama/codellama:7b"
LLM_API_KEY="ollama"
LLM_EMBEDDING_MODEL="local"
LLM_BASE_URL="http://localhost:11434"
WORKSPACE_BASE="./workspace"
WORKSPACE_DIR="$(pwd)/workspace"
```
Remplacez `LLM_MODEL` par celui de votre choix si nécessaire.
Fini ! Vous pouvez maintenant démarrer OpenHands avec : `make run` sans Docker. Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
## Sélection de votre modèle
Dans l'interface OpenHands, cliquez sur l'icône des paramètres en bas à gauche.
Ensuite, dans l'entrée `Model`, saisissez `ollama/codellama:7b`, ou le nom du modèle que vous avez téléchargé précédemment.
S'il n'apparaît pas dans un menu déroulant, ce n'est pas grave, tapez-le simplement. Cliquez sur Enregistrer lorsque vous avez terminé.
Et maintenant, vous êtes prêt à démarrer !
## Configuration du service ollama (WSL){#configuring-ollama-service-fr}
La configuration par défaut pour ollama sous WSL ne sert que localhost. Cela signifie que vous ne pouvez pas l'atteindre depuis un conteneur docker, par exemple, il ne fonctionnera pas avec OpenHands. Testons d'abord que ollama est en cours d'exécution correctement.
```bash
ollama list # obtenir la liste des modèles installés
curl http://localhost:11434/api/generate -d '{"model":"[NAME]","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 seul
```
Une fois cela fait, testez qu'il accepte les requêtes "externes", comme celles provenant d'un conteneur docker.
```bash
docker ps # obtenir la liste des conteneurs docker en cours d'exécution, pour un test le plus précis choisissez le conteneur de sandbox OpenHands.
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#ex. docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## Correction
Maintenant faisons en sorte que cela fonctionne. Modifiez /etc/systemd/system/ollama.service avec les 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 la section [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 que 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 le plus précis choisissez le conteneur de sandbox OpenHands.
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
```

View File

@@ -1,25 +0,0 @@
# 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` 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 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 points de terminaison compatibles avec OpenAI
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, 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

View File

@@ -1,12 +0,0 @@
# 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` 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.

View File

@@ -1,96 +0,0 @@
# 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

View File

@@ -1,43 +0,0 @@
# 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 utiles.
## 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.
## 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."
### 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)
## 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.
N'oubliez pas, plus votre prompt est précis et informatif, mieux l'IA pourra vous aider à développer ou à modifier le logiciel OpenHands.
Voir [Getting Started with OpenHands](./getting-started) pour plus d'exemples de prompts utiles.

View File

@@ -1,66 +0,0 @@
# Personnalisation du comportement de l'agent
OpenHands peut être personnalisé pour fonctionner plus efficacement avec des dépôts spécifiques en fournissant un contexte et des directives propres à chaque dépôt. Cette section explique comment optimiser OpenHands pour votre projet.
## Configuration du dépôt
Vous pouvez personnaliser le comportement d'OpenHands pour votre dépôt en créant un répertoire `.openhands` à la racine de votre dépôt. Au minimum, il doit contenir le fichier `.openhands/microagents/repo.md`, qui comprend les instructions qui seront données à l'agent chaque fois qu'il travaillera avec ce dépôt.
Nous vous suggérons d'inclure les informations suivantes :
1. **Aperçu du dépôt** : Une brève description de l'objectif et de l'architecture de votre projet
2. **Structure des répertoires** : Les répertoires clés et leurs objectifs
3. **Directives de développement** : Les normes et pratiques de codage spécifiques au projet
4. **Exigences de test** : Comment exécuter les tests et quels types de tests sont requis
5. **Instructions de configuration** : Les étapes nécessaires pour construire et exécuter le projet
### Exemple de configuration de dépôt
Exemple de fichier `.openhands/microagents/repo.md` :
```
Repository: MonProjet
Description: Une application web pour la gestion des tâches
Structure des répertoires :
- src/ : Code principal de l'application
- tests/ : Fichiers de test
- docs/ : Documentation
Configuration :
- Exécutez `npm install` pour installer les dépendances
- Utilisez `npm run dev` pour le développement
- Exécutez `npm test` pour les tests
Directives :
- Suivez la configuration ESLint
- Écrivez des tests pour toutes les nouvelles fonctionnalités
- Utilisez TypeScript pour le nouveau code
```
### Personnalisation des prompts
Lorsque vous travaillez avec un dépôt personnalisé :
1. **Référencez les normes du projet** : Mentionnez les normes ou les modèles de codage spécifiques utilisés dans votre projet
2. **Incluez le contexte** : Faites référence à la documentation pertinente ou aux implémentations existantes
3. **Spécifiez les exigences de test** : Incluez les exigences de test spécifiques au projet dans vos prompts
Exemple de prompt personnalisé :
```
Ajoutez une nouvelle fonctionnalité d'achèvement des tâches à src/components/TaskList.tsx en suivant nos modèles de composants existants.
Incluez des tests unitaires dans tests/components/ et mettez à jour la documentation dans docs/features/.
Le composant doit utiliser notre style partagé de src/styles/components.
```
### Meilleures pratiques pour la personnalisation du dépôt
1. **Gardez les instructions à jour** : Mettez régulièrement à jour votre répertoire `.openhands` au fur et à mesure de l'évolution de votre projet
2. **Soyez spécifique** : Incluez des chemins, des modèles et des exigences spécifiques à votre projet
3. **Documentez les dépendances** : Énumérez tous les outils et dépendances nécessaires au développement
4. **Incluez des exemples** : Fournissez des exemples de bons modèles de code de votre projet
5. **Spécifiez les conventions** : Documentez les conventions de nommage, l'organisation des fichiers et les préférences de style de code
En personnalisant OpenHands pour votre dépôt, vous obtiendrez des résultats plus précis et cohérents qui s'alignent sur les normes et les exigences de votre projet.
## Autres microagents
Vous pouvez créer d'autres instructions dans le répertoire `.openhands/microagents/` qui seront envoyées à l'agent si un mot-clé particulier est trouvé, comme `test`, `frontend` ou `migration`. Voir [Microagents](microagents.md) pour plus d'informations.

View File

@@ -1,36 +0,0 @@
# 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)

View File

@@ -1,40 +0,0 @@
# 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 |

View File

@@ -1,50 +0,0 @@
# 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.

View File

@@ -1,31 +0,0 @@
# 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)

View File

@@ -1,215 +0,0 @@
# Micro-Agents
OpenHands utilise des micro-agents spécialisés pour gérer efficacement des tâches et des contextes spécifiques. Ces micro-agents sont de petits composants ciblés qui fournissent un comportement et des connaissances spécialisés pour des scénarios particuliers.
## Aperçu
Les micro-agents sont définis dans des fichiers markdown sous le répertoire `openhands/agenthub/codeact_agent/micro/`. Chaque micro-agent est configuré avec :
- Un nom unique
- Le type d'agent (généralement CodeActAgent)
- Des mots-clés déclencheurs qui activent l'agent
- Des instructions et des capacités spécifiques
## Micro-Agents Disponibles
### Agent GitHub
**Fichier** : `github.md`
**Déclencheurs** : `github`, `git`
L'agent GitHub se spécialise dans les interactions avec l'API GitHub et la gestion des dépôts. Il :
- A accès à un `GITHUB_TOKEN` pour l'authentification API
- Suit des directives strictes pour les interactions avec les dépôts
- Gère les branches et les pull requests
- Utilise l'API GitHub au lieu des interactions avec le navigateur web
Fonctionnalités clés :
- Protection des branches (empêche les push directs vers main/master)
- Création automatisée de PR
- Gestion de la configuration Git
- Approche API-first pour les opérations GitHub
### Agent NPM
**Fichier** : `npm.md`
**Déclencheurs** : `npm`
Se spécialise dans la gestion des packages npm avec un focus spécifique sur :
- Les opérations shell non interactives
- La gestion automatisée des confirmations en utilisant la commande Unix 'yes'
- L'automatisation de l'installation des packages
### Micro-Agents Personnalisés
Vous pouvez créer vos propres micro-agents en ajoutant de nouveaux fichiers markdown dans le répertoire des micro-agents. Chaque fichier doit suivre cette structure :
```markdown
---
name: nom_de_l_agent
agent: CodeActAgent
triggers:
- mot_declencheur1
- mot_declencheur2
---
Instructions et capacités pour le micro-agent...
```
## Bonnes Pratiques
Lorsque vous travaillez avec des micro-agents :
1. **Utilisez les déclencheurs appropriés** : Assurez-vous que vos commandes incluent les mots-clés déclencheurs pertinents pour activer le bon micro-agent
2. **Suivez les directives de l'agent** : Chaque agent a des instructions et des limitations spécifiques - respectez-les pour des résultats optimaux
3. **Approche API-First** : Lorsque c'est possible, utilisez les endpoints d'API plutôt que les interfaces web
4. **Automatisation conviviale** : Concevez des commandes qui fonctionnent bien dans des environnements non interactifs
## Intégration
Les micro-agents sont automatiquement intégrés dans le workflow d'OpenHands. Ils :
- Surveillent les commandes entrantes pour détecter leurs mots-clés déclencheurs
- S'activent lorsque des déclencheurs pertinents sont détectés
- Appliquent leurs connaissances et capacités spécialisées
- Suivent leurs directives et restrictions spécifiques
## Exemple d'utilisation
```bash
# Exemple d'agent GitHub
git checkout -b feature-branch
git commit -m "Add new feature"
git push origin feature-branch
# Exemple d'agent NPM
yes | npm install package-name
```
Pour plus d'informations sur des agents spécifiques, reportez-vous à leurs fichiers de documentation individuels dans le répertoire des micro-agents.
## Contribuer un Micro-Agent
Pour contribuer un nouveau micro-agent à OpenHands, suivez ces directives :
### 1. Planification de votre Micro-Agent
Avant de créer un micro-agent, considérez :
- Quel problème ou cas d'utilisation spécifique va-t-il adresser ?
- Quelles capacités ou connaissances uniques devrait-il avoir ?
- Quels mots-clés déclencheurs ont du sens pour l'activer ?
- Quelles contraintes ou directives devrait-il suivre ?
### 2. Structure du fichier
Créez un nouveau fichier markdown dans `openhands/agenthub/codeact_agent/micro/` avec un nom descriptif (par ex., `docker.md` pour un agent axé sur Docker).
### 3. Composants requis
Votre fichier de micro-agent doit inclure :
1. **Front Matter** : Métadonnées YAML au début du fichier :
```markdown
---
name: nom_de_votre_agent
agent: CodeActAgent
triggers:
- mot_declencheur1
- mot_declencheur2
---
```
2. **Instructions** : Directives claires et spécifiques pour le comportement de l'agent :
```markdown
Vous êtes responsable de [tâche/domaine spécifique].
Responsabilités clés :
1. [Responsabilité 1]
2. [Responsabilité 2]
Directives :
- [Directive 1]
- [Directive 2]
Exemples d'utilisation :
[Exemple 1]
[Exemple 2]
```
### 4. Bonnes pratiques pour le développement de Micro-Agents
1. **Portée claire** : Gardez l'agent concentré sur un domaine ou une tâche spécifique
2. **Instructions explicites** : Fournissez des directives claires et sans ambiguïté
3. **Exemples utiles** : Incluez des exemples pratiques de cas d'utilisation courants
4. **Sécurité d'abord** : Incluez les avertissements et contraintes nécessaires
5. **Conscience de l'intégration** : Considérez comment l'agent interagit avec les autres composants
### 5. Tester votre Micro-Agent
Avant de soumettre :
1. Testez l'agent avec divers prompts
2. Vérifiez que les mots-clés déclencheurs activent correctement l'agent
3. Assurez-vous que les instructions sont claires et complètes
4. Vérifiez les conflits potentiels avec les agents existants
### 6. Exemple d'implémentation
Voici un modèle pour un nouveau micro-agent :
```markdown
---
name: docker
agent: CodeActAgent
triggers:
- docker
- conteneur
---
Vous êtes responsable de la gestion des conteneurs Docker et de la création de Dockerfiles.
Responsabilités clés :
1. Créer et modifier des Dockerfiles
2. Gérer le cycle de vie des conteneurs
3. Gérer les configurations Docker Compose
Directives :
- Utilisez toujours des images de base officielles lorsque possible
- Incluez les considérations de sécurité nécessaires
- Suivez les bonnes pratiques Docker pour l'optimisation des couches
Exemples :
1. Créer un Dockerfile :
```dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]
```
2. Utilisation de Docker Compose :
```yaml
version: '3'
services:
web:
build: .
ports:
- "3000:3000"
```
N'oubliez pas de :
- Valider la syntaxe du Dockerfile
- Vérifier les vulnérabilités de sécurité
- Optimiser le temps de build et la taille de l'image
```
### 7. Processus de soumission
1. Créez votre fichier de micro-agent dans le bon répertoire
2. Testez minutieusement
3. Soumettez une pull request avec :
- Le nouveau fichier de micro-agent
- La documentation mise à jour si nécessaire
- La description du but et des capacités de l'agent
N'oubliez pas que les micro-agents sont un moyen puissant d'étendre les capacités d'OpenHands dans des domaines spécifiques. Des agents bien conçus peuvent améliorer significativement la capacité du système à gérer des tâches spécialisées.

View File

@@ -1,37 +0,0 @@
# Meilleures pratiques pour les prompts
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 :
- **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
- 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
- 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
- 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.
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.

View File

@@ -1,25 +0,0 @@
# 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.

View File

@@ -1,8 +0,0 @@
---
slug: /usage/runtimes
title: Runtime Configuration
---
import { Redirect } from '@docusaurus/router';
<Redirect to="/modules/usage/runtimes-index" />

View File

@@ -1,32 +0,0 @@
# 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

View File

@@ -1,129 +0,0 @@
# 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 \
```

View File

@@ -1,74 +0,0 @@
# 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.

View File

@@ -1,13 +0,0 @@
# 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" \
```

View File

@@ -1,9 +0,0 @@
# 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 !

View File

@@ -1,68 +0,0 @@
# 🚧 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 apparaît :
```
Launch docker client failed. Please make sure you have installed docker and started docker desktop/daemon.
```
**Résolution**
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.
### Erreur de permission
**Description**
Lors de la première invite, une erreur avec `Permission Denied` ou `PermissionError` est affichée.
**Résolution**
* 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.

View File

@@ -1,72 +0,0 @@
# ⬆️ Guide de mise à niveau
## 0.8.0 (2024-07-13)
### Changements de configuration importants
Dans cette version, nous avons introduit quelques changements importants dans les configurations backend.
Si vous avez uniquement utilisé OpenHands via l'interface frontend (interface web), aucune action n'est nécessaire.
Voici une liste des changements importants dans les configurations. Ils ne s'appliquent qu'aux utilisateurs qui
utilisent OpenHands CLI via `main.py`. Pour plus de détails, voir [#2756](https://github.com/All-Hands-AI/OpenHands/pull/2756).
#### Suppression de l'option --model-name de main.py
Veuillez noter que l'option `--model-name`, ou `-m`, n'existe plus. Vous devez configurer les
configurations LLM dans `config.toml` ou via des variables d'environnement.
#### Les groupes de configuration LLM doivent être des sous-groupes de 'llm'
Avant la version 0.8, vous pouviez utiliser un nom arbitraire pour la configuration LLM dans `config.toml`, par exemple :
```toml
[gpt-4o]
model="gpt-4o"
api_key="<your_api_key>"
```
puis utiliser l'argument CLI `--llm-config` pour spécifier le groupe de configuration LLM souhaité
par nom. Cela ne fonctionne plus. Au lieu de cela, le groupe de configuration doit être sous le groupe `llm`,
par exemple :
```toml
[llm.gpt-4o]
model="gpt-4o"
api_key="<your_api_key>"
```
Si vous avez un groupe de configuration nommé `llm`, il n'est pas nécessaire de le modifier, il sera utilisé
comme groupe de configuration LLM par défaut.
#### Le groupe 'agent' ne contient plus le champ 'name'
Avant la version 0.8, vous pouviez avoir ou non un groupe de configuration nommé `agent` qui
ressemblait à ceci :
```toml
[agent]
name="CodeActAgent"
memory_max_threads=2
```
Notez que le champ `name` est maintenant supprimé. Au lieu de cela, vous devez mettre le champ `default_agent`
sous le groupe `core`, par exemple :
```toml
[core]
# autres configurations
default_agent='CodeActAgent'
[agent]
llm_config='llm'
memory_max_threads=2
[agent.CodeActAgent]
llm_config='gpt-4o'
```
Notez que, comme pour les sous-groupes `llm`, vous pouvez également définir des sous-groupes `agent`.
De plus, un agent peut être associé à un groupe de configuration LLM spécifique. Pour plus
de détails, voir les exemples dans `config.template.toml`.

View File

@@ -1,26 +0,0 @@
{
"title": {
"message": "OpenHands",
"description": "The title in the navbar"
},
"logo.alt": {
"message": "OpenHands",
"description": "The alt text of navbar logo"
},
"item.label.Docs": {
"message": "Docs",
"description": "Navbar item with label Docs"
},
"item.label.Codebase": {
"message": "Codebase",
"description": "Navbar item with label Codebase"
},
"item.label.FAQ": {
"message": "FAQ",
"description": "Navbar item with label FAQ"
},
"item.label.GitHub": {
"message": "GitHub",
"description": "Navbar item with label GitHub"
}
}

View File

@@ -1,427 +0,0 @@
{
"footer.title": {
"message": "OpenHands"
},
"footer.docs": {
"message": "ドキュメント"
},
"footer.community": {
"message": "コミュニティ"
},
"footer.copyright": {
"message": "© {year} OpenHands"
},
"faq.title": {
"message": "よくある質問",
"description": "FAQ Title"
},
"faq.description": {
"message": "よくある質問"
},
"faq.section.title.1": {
"message": "OpenHandsとは何ですか",
"description": "First Section Title"
},
"faq.section.highlight": {
"message": "OpenHands",
"description": "Highlight Text"
},
"faq.section.description.1": {
"message": "はソフトウェアエンジニアリングとウェブナビゲーションのタスクをいつでも解決できる自律型ソフトウェアエンジニアです。「過去数ヶ月間のOpenHandsリポジトリへのプルリクエスト数を調べる」などのデータサイエンスクエリや、「このファイルにテストを追加して、すべてのテストが通るか確認してください。通らない場合は、ファイルを修正してください」などのソフトウェアエンジニアリングタスクを実行できます。",
"description": "Description for OpenHands"
},
"faq.section.description.2": {
"message": "さらに、OpenHandsは新しいエージェントをテストおよび評価したいエージェント開発者向けのプラットフォームとコミュニティでもあります。",
"description": "Further Description for OpenHands"
},
"faq.section.title.2": {
"message": "サポート",
"description": "Support Section Title"
},
"faq.section.support.answer": {
"message": "他のユーザーも同様に発生する可能性のある問題が発生した場合は、{githubLink}で報告してください。インストールに関する問題や一般的な質問がある場合は、{discordLink}または{slackLink}にご参加ください。",
"description": "Support Answer"
},
"faq.section.title.3": {
"message": "OpenHandsでGitHubの問題を解決するには",
"description": "GitHub Issue Section Title"
},
"faq.section.github.steps.intro": {
"message": "OpenHandsを使用してGitHubの問題を解決するには、以下のようなステップを実行するようOpenHandsにコマンドを送信します",
"description": "GitHub Steps Introduction"
},
"faq.section.github.step1": {
"message": "イシュー https://github.com/All-Hands-AI/OpenHands/issues/1611 を読む",
"description": "GitHub Step 1"
},
"faq.section.github.step2": {
"message": "リポジトリをクローンして新しいブランチをチェックアウトする",
"description": "GitHub Step 2"
},
"faq.section.github.step3": {
"message": "イシューの説明に基づいて、問題を解決するためにファイルを修正する",
"description": "GitHub Step 3"
},
"faq.section.github.step4": {
"message": "GITHUB_TOKEN環境変数を使用して結果をGitHubにプッシュする",
"description": "GitHub Step 4"
},
"faq.section.github.step5": {
"message": "プルリクエストを送信するために使用するリンクを教えてください",
"description": "GitHub Step 5"
},
"faq.section.github.steps.preRun": {
"message": "OpenHandsを起動する前に、以下を実行できます",
"description": "GitHub Steps Pre-Run"
},
"faq.section.github.steps.tokenInfo": {
"message": "ここでXXXはあなたが作成したGitHubトークンで、OpenHandsリポジトリにプッシュする権限を持っています。OpenHandsリポジトリの変更権限がない場合は、次のように変更する必要があるかもしれません",
"description": "GitHub Steps Token Info"
},
"faq.section.github.steps.usernameInfo": {
"message": "ここでUSERNAMEはあなたのGitHubユーザー名です。",
"description": "GitHub Steps Username Info"
},
"faq.section.title.4": {
"message": "OpenHandsはDevinとどう違いますか",
"description": "Devin Section Title"
},
"faq.section.openhands.linkText": {
"message": "Devin",
"description": "Devin Link Text"
},
"faq.section.openhands.description": {
"message": "はCognition Inc.の商用製品で、OpenHandsの最初のインスピレーションとなりました。どちらもソフトウェアエンジニアリングの仕事をうまくこなすことを目指していますが、OpenHandsはダウンロード、使用、修正が可能である一方、DevinはCognitionのサイトを通じてのみ使用できます。さらに、OpenHandsは最初のインスピレーションを超えて進化し、現在はエージェント開発全般のためのコミュニティエコシステムとなっており、あなたの参加と",
"description": "Devin Description"
},
"faq.section.openhands.contribute": {
"message": "貢献",
"description": "Contribute Link"
},
"faq.section.title.5": {
"message": "OpenHandsはChatGPTとどう違いますか",
"description": "ChatGPT Section Title"
},
"faq.section.chatgpt.description": {
"message": "ChatGPTはオンラインでアクセスでき、ローカルファイルに接続せず、コード実行能力も限られています。コードを書くことはできますが、テストや実行が難しいです。",
"description": "ChatGPT Description"
},
"homepage.description": {
"message": "ソフトウェアエンジニアリングのためのAIコード生成。",
"description": "The homepage description"
},
"homepage.getStarted": {
"message": "はじめる"
},
"welcome.message": {
"message": "OpenHandsへようこそ。複雑なエンジニアリングタスクを実行し、ソフトウェア開発プロジェクトでユーザーと積極的に協力できる自律型AIソフトウェアエンジニアシステムです。"
},
"theme.ErrorPageContent.title": {
"message": "このページはクラッシュしました。",
"description": "The title of the fallback page when the page crashed"
},
"theme.BackToTopButton.buttonAriaLabel": {
"message": "ページの先頭に戻る",
"description": "The ARIA label for the back to top button"
},
"theme.blog.archive.title": {
"message": "アーカイブ",
"description": "The page & hero title of the blog archive page"
},
"theme.blog.archive.description": {
"message": "アーカイブ",
"description": "The page & hero description of the blog archive page"
},
"theme.blog.paginator.navAriaLabel": {
"message": "ブログ記事リストのページネーション",
"description": "The ARIA label for the blog pagination"
},
"theme.blog.paginator.newerEntries": {
"message": "新しい記事",
"description": "The label used to navigate to the newer blog posts page (previous page)"
},
"theme.blog.paginator.olderEntries": {
"message": "古い記事",
"description": "The label used to navigate to the older blog posts page (next page)"
},
"theme.blog.post.paginator.navAriaLabel": {
"message": "ブログ記事のページネーション",
"description": "The ARIA label for the blog posts pagination"
},
"theme.blog.post.paginator.newerPost": {
"message": "新しい記事",
"description": "The blog post button label to navigate to the newer/previous post"
},
"theme.blog.post.paginator.olderPost": {
"message": "古い記事",
"description": "The blog post button label to navigate to the older/next post"
},
"theme.blog.post.plurals": {
"message": "1記事|{count}記事",
"description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.blog.tagTitle": {
"message": "「{tagName}」のタグが付いた{nPosts}",
"description": "The title of the page for a blog tag"
},
"theme.tags.tagsPageLink": {
"message": "すべてのタグを表示",
"description": "The label of the link targeting the tag list page"
},
"theme.colorToggle.ariaLabel": {
"message": "ダークモードとライトモードを切り替える(現在は{mode}",
"description": "The ARIA label for the navbar color mode toggle"
},
"theme.colorToggle.ariaLabel.mode.dark": {
"message": "ダークモード",
"description": "The name for the dark color mode"
},
"theme.colorToggle.ariaLabel.mode.light": {
"message": "ライトモード",
"description": "The name for the light color mode"
},
"theme.docs.breadcrumbs.navAriaLabel": {
"message": "パンくずリストナビゲーション",
"description": "The ARIA label for the breadcrumbs"
},
"theme.docs.DocCard.categoryDescription.plurals": {
"message": "1項目|{count}項目",
"description": "The default description for a category card in the generated index about how many items this category includes"
},
"theme.docs.paginator.navAriaLabel": {
"message": "ドキュメントページ",
"description": "The ARIA label for the docs pagination"
},
"theme.docs.paginator.previous": {
"message": "前へ",
"description": "The label used to navigate to the previous doc"
},
"theme.docs.paginator.next": {
"message": "次へ",
"description": "The label used to navigate to the next doc"
},
"theme.docs.tagDocListPageTitle.nDocsTagged": {
"message": "1つのドキュメントにタグ付け|{count}のドキュメントにタグ付け",
"description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.tagDocListPageTitle": {
"message": "\"{tagName}\"で{nDocsTagged}",
"description": "The title of the page for a docs tag"
},
"theme.docs.versionBadge.label": {
"message": "バージョン: {versionLabel}"
},
"theme.docs.versions.unreleasedVersionLabel": {
"message": "これは{siteTitle}の次期バージョン{versionLabel}のドキュメントです。",
"description": "The label used to tell the user that he's browsing an unreleased doc version"
},
"theme.docs.versions.unmaintainedVersionLabel": {
"message": "これは{siteTitle} {versionLabel}のドキュメントで、現在はアクティブにメンテナンスされていません。",
"description": "The label used to tell the user that he's browsing an unmaintained doc version"
},
"theme.docs.versions.latestVersionSuggestionLabel": {
"message": "最新のドキュメントについては、{latestVersionLink}{versionLabel})をご覧ください。",
"description": "The label used to tell the user to check the latest version"
},
"theme.docs.versions.latestVersionLinkLabel": {
"message": "最新バージョン",
"description": "The label used for the latest version suggestion link label"
},
"theme.common.editThisPage": {
"message": "このページを編集",
"description": "The link label to edit the current page"
},
"theme.common.headingLinkTitle": {
"message": "{heading}への直接リンク",
"description": "Title for link to heading"
},
"theme.lastUpdated.atDate": {
"message": " {date}に",
"description": "The words used to describe on which date a page has been last updated"
},
"theme.lastUpdated.byUser": {
"message": " {user}によって",
"description": "The words used to describe by who the page has been last updated"
},
"theme.lastUpdated.lastUpdatedAtBy": {
"message": "最終更新{atDate}{byUser}",
"description": "The sentence used to display when a page has been last updated, and by who"
},
"theme.navbar.mobileVersionsDropdown.label": {
"message": "バージョン",
"description": "The label for the navbar versions dropdown on mobile view"
},
"theme.NotFound.title": {
"message": "ページが見つかりません",
"description": "The title of the 404 page"
},
"theme.tags.tagsListLabel": {
"message": "タグ:",
"description": "The label alongside a tag list"
},
"theme.admonition.caution": {
"message": "注意",
"description": "The default label used for the Caution admonition (:::caution)"
},
"theme.admonition.danger": {
"message": "危険",
"description": "The default label used for the Danger admonition (:::danger)"
},
"theme.admonition.info": {
"message": "情報",
"description": "The default label used for the Info admonition (:::info)"
},
"theme.admonition.note": {
"message": "メモ",
"description": "The default label used for the Note admonition (:::note)"
},
"theme.admonition.tip": {
"message": "ヒント",
"description": "The default label used for the Tip admonition (:::tip)"
},
"theme.admonition.warning": {
"message": "警告",
"description": "The default label used for the Warning admonition (:::warning)"
},
"theme.AnnouncementBar.closeButtonAriaLabel": {
"message": "閉じる",
"description": "The ARIA label for close button of announcement bar"
},
"theme.blog.sidebar.navAriaLabel": {
"message": "最近のブログ記事ナビゲーション",
"description": "The ARIA label for recent posts in the blog sidebar"
},
"theme.CodeBlock.copied": {
"message": "コピーしました",
"description": "The copied button label on code blocks"
},
"theme.CodeBlock.copyButtonAriaLabel": {
"message": "コードをコピー",
"description": "The ARIA label for copy code blocks button"
},
"theme.CodeBlock.copy": {
"message": "コピー",
"description": "The copy button label on code blocks"
},
"theme.CodeBlock.wordWrapToggle": {
"message": "折り返し表示の切り替え",
"description": "The title attribute for toggle word wrapping button of code block lines"
},
"theme.DocSidebarItem.expandCategoryAriaLabel": {
"message": "サイドバーカテゴリ「{label}」を展開",
"description": "The ARIA label to expand the sidebar category"
},
"theme.DocSidebarItem.collapseCategoryAriaLabel": {
"message": "サイドバーカテゴリ「{label}」を折りたたむ",
"description": "The ARIA label to collapse the sidebar category"
},
"theme.NavBar.navAriaLabel": {
"message": "メイン",
"description": "The ARIA label for the main navigation"
},
"theme.navbar.mobileLanguageDropdown.label": {
"message": "言語",
"description": "The label for the mobile language switcher dropdown"
},
"theme.NotFound.p1": {
"message": "お探しのものが見つかりませんでした。",
"description": "The first paragraph of the 404 page"
},
"theme.NotFound.p2": {
"message": "元のURLにリンクしたサイトの所有者に連絡して、リンクが切れていることを知らせてください。",
"description": "The 2nd paragraph of the 404 page"
},
"theme.TOCCollapsible.toggleButtonLabel": {
"message": "このページの内容",
"description": "The label used by the button on the collapsible TOC component"
},
"theme.blog.post.readMore": {
"message": "もっと読む",
"description": "The label used in blog post item excerpts to link to full blog posts"
},
"theme.blog.post.readMoreLabel": {
"message": "{title}についてもっと読む",
"description": "The ARIA label for the link to full blog posts from excerpts"
},
"theme.blog.post.readingTime.plurals": {
"message": "1分で読めます|{readingTime}分で読めます",
"description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.breadcrumbs.home": {
"message": "ホームページ",
"description": "The ARIA label for the home page in the breadcrumbs"
},
"theme.docs.sidebar.collapseButtonTitle": {
"message": "サイドバーを折りたたむ",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.collapseButtonAriaLabel": {
"message": "サイドバーを折りたたむ",
"description": "The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.navAriaLabel": {
"message": "ドキュメントサイドバーナビゲーション",
"description": "The ARIA label for the sidebar navigation"
},
"theme.docs.sidebar.closeSidebarButtonAriaLabel": {
"message": "ナビゲーションバーを閉じる",
"description": "The ARIA label for close button of mobile sidebar"
},
"theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": {
"message": "← メインメニューに戻る",
"description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
},
"theme.docs.sidebar.toggleSidebarButtonAriaLabel": {
"message": "ナビゲーションバーの開閉",
"description": "The ARIA label for hamburger menu button of mobile navigation"
},
"theme.docs.sidebar.expandButtonTitle": {
"message": "サイドバーを展開",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.docs.sidebar.expandButtonAriaLabel": {
"message": "サイドバーを展開",
"description": "The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.ErrorPageContent.tryAgain": {
"message": "再試行",
"description": "The label of the button to try again rendering when the React error boundary captures an error"
},
"theme.common.skipToMainContent": {
"message": "メインコンテンツに直接移動",
"description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
},
"theme.tags.tagsPageTitle": {
"message": "タグ",
"description": "The title of the tag list page"
},
"theme.unlistedContent.title": {
"message": "非公開ページ",
"description": "The unlisted content banner title"
},
"theme.unlistedContent.message": {
"message": "このページは非公開です。検索エンジンにインデックスされず、直接リンクを持つユーザーのみがアクセスできます。",
"description": "The unlisted content banner message"
},
"Use AI to tackle the toil in your backlog. Our agents have all the same tools as a human developer: they can modify code, run commands, browse the web, call APIs, and yes-even copy code snippets from StackOverflow.": {
"message": "AIを使用してバックログの作業を効率化しましょう。私たちのエージェントは人間の開発者と同じツールを持っていますコードの修正、コマンドの実行、ウェブの閲覧、APIの呼び出し、そしてStackOverflowからのコードスニペットのコピーさえも可能です。"
},
"Get started with OpenHands.": {
"message": "OpenHandsを始める"
},
"Most Popular Links": {
"message": "人気のリンク"
},
"Customizing OpenHands to a repository": {
"message": "リポジトリ向けにOpenHandsをカスタマイズする"
},
"Integrating OpenHands with Github": {
"message": "OpenHandsをGithubと統合する"
},
"Recommended models to use": {
"message": "推奨モデル"
},
"Connecting OpenHands to your filesystem": {
"message": "OpenHandsをファイルシステムに接続する"
}
}

View File

@@ -1,14 +0,0 @@
{
"title": {
"message": "ブログ",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "OpenHands ブログ",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "最近の投稿",
"description": "The label for the left sidebar"
}
}

View File

@@ -1,210 +0,0 @@
{
"version.label": {
"message": "次のバージョン",
"description": "The label for version current"
},
"sidebar.docsSidebar.category.🤖 Backends LLM": {
"message": "🤖 LLMバックエンド",
"description": "The label for category 🤖 Backends LLM in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.🚧 Dépannage": {
"message": "🚧 トラブルシューティング",
"description": "The label for category 🚧 Dépannage in sidebar docsSidebar"
},
"sidebar.apiSidebar.category.Backend": {
"message": "バックエンド",
"description": "The label for category Backend in sidebar apiSidebar"
},
"sidebar.docsSidebar.category.User Guides": {
"message": "ユーザーガイド",
"description": "The label for category User Guides in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Running OpenHands": {
"message": "OpenHandsの実行",
"description": "The label for category Running OpenHands in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Prompting": {
"message": "プロンプト",
"description": "The label for category Prompting in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Architecture": {
"message": "アーキテクチャ",
"description": "The label for category Architecture in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Running OpenHands": {
"message": "OpenHandsの実行",
"description": "The label for document Running OpenHands in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Getting Started": {
"message": "はじめに",
"description": "The label for document Getting Started in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Key Features": {
"message": "主な機能",
"description": "The label for document Key Features in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Customization": {
"message": "カスタマイズ",
"description": "The label for category Customization in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Usage Methods": {
"message": "使用方法",
"description": "The label for category Usage Methods in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Advanced Configuration": {
"message": "高度な設定",
"description": "The label for category Advanced Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Troubleshooting": {
"message": "トラブルシューティング",
"description": "The label for document Troubleshooting in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Feedback": {
"message": "フィードバック",
"description": "The label for document Feedback in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.For OpenHands Developers": {
"message": "OpenHands開発者向け",
"description": "The label for category For OpenHands Developers in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.About": {
"message": "概要",
"description": "The label for document About in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Best Practices": {
"message": "ベストプラクティス",
"description": "The label for document Best Practices in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Microagents": {
"message": "マイクロエージェント",
"description": "The label for category Microagents in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Overview": {
"message": "概要",
"description": "The label for document Overview in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Repository": {
"message": "リポジトリ",
"description": "The label for document Repository in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Public": {
"message": "パブリック",
"description": "The label for document Public in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Repository Customization": {
"message": "リポジトリのカスタマイズ",
"description": "The label for document Repository Customization in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.GUI Mode": {
"message": "GUIモード",
"description": "The label for document GUI Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.CLI Mode": {
"message": "CLIモード",
"description": "The label for document CLI Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Headless Mode": {
"message": "ヘッドレスモード",
"description": "The label for document Headless Mode in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Github Action": {
"message": "GitHub アクション",
"description": "The label for document Github Action in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Cloud": {
"message": "クラウド",
"description": "The label for category Cloud in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Openhands Cloud": {
"message": "OpenHands クラウド",
"description": "The label for document Openhands Cloud in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Cloud GitHub Resolver": {
"message": "クラウド GitHub リゾルバー",
"description": "The label for document Cloud GitHub Resolver in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.LLM Configuration": {
"message": "LLM 設定",
"description": "The label for category LLM Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Providers": {
"message": "プロバイダー",
"description": "The label for category Providers in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Azure": {
"message": "Azure",
"description": "The label for document Azure in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Google": {
"message": "Google",
"description": "The label for document Google in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Groq": {
"message": "Groq",
"description": "The label for document Groq in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.LiteLLM Proxy": {
"message": "LiteLLM プロキシ",
"description": "The label for document LiteLLM Proxy in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.OpenAI": {
"message": "OpenAI",
"description": "The label for document OpenAI in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.OpenRouter": {
"message": "OpenRouter",
"description": "The label for document OpenRouter in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.Runtime Configuration": {
"message": "ランタイム設定",
"description": "The label for category Runtime Configuration in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Docker Runtime": {
"message": "Docker ランタイム",
"description": "The label for document Docker Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Remote Runtime": {
"message": "リモートランタイム",
"description": "The label for document Remote Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Modal Runtime": {
"message": "Modal ランタイム",
"description": "The label for document Modal Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Daytona Runtime": {
"message": "Daytona ランタイム",
"description": "The label for document Daytona Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Local Runtime": {
"message": "ローカルランタイム",
"description": "The label for document Local Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Configuration Options": {
"message": "設定オプション",
"description": "The label for document Configuration Options in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Custom Sandbox": {
"message": "カスタムサンドボックス",
"description": "The label for document Custom Sandbox in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Development Overview": {
"message": "開発概要",
"description": "The label for document Development Overview in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Backend": {
"message": "バックエンド",
"description": "The label for document Backend in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Runtime": {
"message": "ランタイム",
"description": "The label for document Runtime in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Debugging": {
"message": "デバッグ",
"description": "The label for document Debugging in sidebar docsSidebar"
},
"sidebar.docsSidebar.doc.Evaluation": {
"message": "評価",
"description": "The label for document Evaluation in sidebar docsSidebar"
}
}

View File

@@ -1,88 +0,0 @@
# Python API
OpenHandsは、Pythonコードから直接使用できる豊富なAPIを提供しています。以下は、主要なAPIの概要です。
## OpenHands クライアント
```python
from openhands import OpenHandsClient
# クライアントの初期化
client = OpenHandsClient(
api_key="your-api-key", # OpenAI APIキーなど
model="gpt-4", # 使用するLLMモデル
workspace="/path/to/workspace" # 作業ディレクトリ
)
# タスクの実行
result = client.execute_task("新しいPythonファイルを作成してください")
# 結果の取得
print(result.success) # タスクが成功したかどうか
print(result.output) # タスクの出力
print(result.error) # エラーメッセージ(存在する場合)
```
## サンドボックス設定
```python
from openhands import SandboxConfig
# サンドボックス設定のカスタマイズ
config = SandboxConfig(
allowed_commands=["git", "python"], # 許可するコマンド
timeout=300, # タイムアウト(秒)
max_memory="2g", # メモリ制限
network_access=True # ネットワークアクセスの許可
)
# 設定を使用してクライアントを初期化
client = OpenHandsClient(
api_key="your-api-key",
model="gpt-4",
workspace="/path/to/workspace",
sandbox_config=config
)
```
## イベントハンドリング
```python
from openhands import OpenHandsClient
def on_progress(event):
print(f"進捗: {event.message}")
def on_error(event):
print(f"エラー: {event.error}")
# イベントハンドラーを設定してクライアントを初期化
client = OpenHandsClient(
api_key="your-api-key",
model="gpt-4",
workspace="/path/to/workspace",
on_progress=on_progress,
on_error=on_error
)
```
## 非同期API
```python
import asyncio
from openhands import AsyncOpenHandsClient
async def main():
# 非同期クライアントの初期化
client = AsyncOpenHandsClient(
api_key="your-api-key",
model="gpt-4",
workspace="/path/to/workspace"
)
# タスクの非同期実行
result = await client.execute_task("新しいPythonファイルを作成してください")
print(result.output)
# 非同期メインの実行
asyncio.run(main())

View File

@@ -1,5 +0,0 @@
{
"items": ["python/python"],
"label": "バックエンド",
"type": "categorie"
}

View File

@@ -1,25 +0,0 @@
# OpenHandsについて
## 研究戦略
LLMによる本番グレードのアプリケーションの完全な複製を達成することは複雑な取り組みです。私たちの戦略は以下を含みます
- **コア技術研究:** コード生成と処理の技術的側面を理解し改善するための基礎研究に焦点を当てる。
- **タスク計画:** バグ検出、コードベース管理、最適化のための能力開発。
- **評価:** エージェントをより良く理解し改善するための包括的な評価指標の確立。
## デフォルトエージェント
現在のデフォルトエージェントは[CodeActAgent](agents)で、コードの生成とファイル処理が可能です。
## 使用技術
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の能力を高めるために、最も適切で効率的なツールを採用するよう努めています。
## ライセンス
MIT [ライセンス](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE)の下で配布されています。

View File

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

View File

@@ -1,50 +0,0 @@
---
sidebar_position: 4
---
# 🏛️ システムアーキテクチャの概要
以下は、システムアーキテクチャの高レベルな概要です。システムは主に2つのコンポーネントに分かれています: フロントエンドとバックエンドです。フロントエンドはユーザーとのインタラクションの管理と結果の表示を担当します。バックエンドはビジネスロジックの管理とエージェントの実行を担当します。
![system_architecture.svg](/img/system_architecture.svg)
この概要は、主要なコンポーネントとそれらの相互作用を示すために簡略化されています。バックエンドアーキテクチャのより詳細なビューについては、[バックエンドアーキテクチャ](#backend-architecture-ja)のセクションを参照してください。
# バックエンドアーキテクチャ {#backend-architecture-ja}
_**注意**: バックエンドアーキテクチャは開発中であり、変更される可能性があります。以下の図は、図のフッターに示されているコミットに基づく現在のバックエンドアーキテクチャを示しています。_
![backend_architecture.svg](/img/backend_architecture.svg)
<details>
<summary>この図の更新</summary>
<div>
バックエンドアーキテクチャ図の生成は部分的に自動化されています。
図はpy2pumlツールを使用してコード内の型アテーションから生成されます。
その後、図は手動でレビューされ、調整され、PNGとSVGにエクスポートされます。
## 前提条件
- openhandsが実行可能なPython環境
(リポジトリのルートにあるREADME.mdファイルの指示に従って)
- [py2puml](https://github.com/lucsorel/py2puml)がインストールされていること
## 手順
1. リポジトリのルートから以下のコマンドを実行して、図を自動的に生成します:
`py2puml openhands openhands > docs/architecture/backend_architecture.puml`
2. 生成されたファイルをPlantUMLエディタ(Visual Studio CodeのPlantUML拡張機能や[PlantText](https://www.planttext.com/)など)で開きます。
3. 生成されたPUMLを確認し、図に必要な変更を加えます(欠落している部分を追加し、エラーを修正し、レイアウトを改善します)。
_py2pumlはコード内の型アテーションから図を作成するため、型アテーションが欠落していたり正しくない場合、図が不完全または不正確になる可能性があります。_
4. 新しい図と以前の図の違いを確認し、変更が正しいかどうかを手動で確認します。
_過去に図に手動で追加され、現在も関連性のある部分を削除しないように注意してください。_
5. 図の生成に使用されたコミットのハッシュを図のフッターに追加します。
6. 図をPNGファイルとSVGファイルにエクスポートし、`docs/architecture`ディレクトリ内の既存の図を置き換えます。これは(例えば[PlantText](https://www.planttext.com/)を使用して)行うことができます。
</div>
</details>

View File

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

View File

@@ -1,127 +0,0 @@
# 📦 Docker ランタイム
OpenHands Docker ランタイムは、AIエージェントのアクションを安全かつ柔軟に実行できるようにする中核コンポーネントです。
Dockerを使用してサンドボックス環境を作成し、ホストシステムを危険にさらすことなく任意のコードを安全に実行できます。
## なぜサンドボックス化されたランタイムが必要なのか?
OpenHandsが任意のコードを安全で隔離された環境で実行する必要がある理由はいくつかあります
1. セキュリティ:信頼されていないコードの実行はホストシステムに重大なリスクをもたらす可能性があります。サンドボックス環境は悪意のあるコードがホストシステムのリソースにアクセスしたり変更したりすることを防ぎます
2. 一貫性:サンドボックス環境により、異なるマシンやセットアップ間でのコード実行の一貫性が確保され、「自分のマシンでは動作する」という問題を排除します
3. リソース制御:サンドボックス化によりリソースの割り当てと使用をより適切に制御でき、暴走プロセスがホストシステムに影響を与えることを防ぎます
4. 分離:異なるプロジェクトやユーザーが互いにまたはホストシステムに干渉することなく、隔離された環境で作業できます
5. 再現性:サンドボックス環境は実行環境が一貫していて制御可能なため、バグや問題の再現が容易になります
## ランタイムはどのように機能するか?
OpenHandsランタイムシステムはDockerコンテナで実装されたクライアント-サーバーアーキテクチャを使用しています。以下はその仕組みの概要です:
```mermaid
graph TD
A[ユーザー提供のカスタムDockerイメージ] --> B[OpenHandsバックエンド]
B -->|ビルド| C[OHランタイムイメージ]
C -->|起動| D[アクション実行者]
D -->|初期化| E[ブラウザ]
D -->|初期化| F[Bashシェル]
D -->|初期化| G[プラグイン]
G -->|初期化| L[Jupyterサーバー]
B -->|生成| H[エージェント]
B -->|生成| I[イベントストリーム]
I <--->|REST APIを介して
アクションを実行し
観測を取得
| D
H -->|アクションを生成| I
I -->|観測を取得| H
subgraph "Dockerコンテナ"
D
E
F
G
L
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バックエンドに送り返します
クライアントの役割:
- OpenHandsバックエンドとサンドボックス環境の間の仲介役として機能します
- さまざまなタイプのアクションシェルコマンド、ファイル操作、Pythonコードなどをコンテナ内で安全に実行します
- 現在の作業ディレクトリやロードされたプラグインなど、サンドボックス環境の状態を管理します
- 観測結果をバックエンドにフォーマットして返し、結果処理のための一貫したインターフェースを確保します
## OpenHandsがOHランタイムイメージをビルドし維持する方法
OpenHandsのランタイムイメージの構築と管理へのアプローチは、本番環境と開発環境の両方のDockerイメージを作成・維持する際の効率性、一貫性、柔軟性を確保します。
詳細に興味がある場合は[関連コード](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py)をご確認ください。
### イメージタグシステム
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`
#### ソースタグ - 最も具体的
これはソースディレクトリのディレクトリハッシュのMD5の最初の16桁です。これによりOpenhandsのソースコードのみのハッシュが得られます。
#### ロックタグ
このハッシュは以下のMD5の最初の16桁から構築されます
- イメージが構築されたベースイメージの名前(例:`nikolaik/python-nodejs:python3.12-nodejs22`
- イメージに含まれる`pyproject.toml`の内容
- イメージに含まれる`poetry.lock`の内容
これにより、ソースコードとは独立したOpenhandsの依存関係のハッシュが効果的に得られます。
#### バージョンタグ - 最も一般的
このタグはOpenhandsのバージョンとベースイメージ名タグ標準に合わせて変換の連結です。
#### ビルドプロセス
イメージを生成する際...
- **再ビルドなし**OpenHandsはまず同じ**最も具体的なソースタグ**を持つイメージが存在するかどうかを確認します。そのようなイメージが存在する場合、ビルドは実行されず、既存のイメージが使用されます。
- **最速の再ビルド**OpenHandsは次に**一般的なロックタグ**を持つイメージが存在するかどうかを確認します。そのようなイメージが存在する場合、OpenHandsはそれに基づいて新しいイメージをビルドし、現在のソースコードをコピーする最終操作を除いて、すべてのインストール手順`poetry install``apt-get`など)をバイパスします。新しいイメージには**ソース**タグのみが付けられます。
- **まあまあの再ビルド****ソース**も**ロック**タグも存在しない場合、**バージョン**タグイメージに基づいてイメージがビルドされます。バージョンタグイメージでは、ほとんどの依存関係がすでにインストールされているため、時間を節約できます。
- **最も遅い再ビルド**3つのタグすべてが存在しない場合、ベースイメージに基づいて全く新しいイメージがビルドされますこれはより遅い操作です。この新しいイメージには**ソース**、**ロック**、**バージョン**のすべてのタグが付けられます。
このタグ付けアプローチにより、OpenHandsは開発環境と本番環境の両方を効率的に管理できます。
1. 同一のソースコードとDockerfileは常に同じイメージを生成しますハッシュベースのタグを介して
2. 軽微な変更が発生した場合、システムは互換性のある最新のイメージを活用して迅速にイメージを再構築できます
3. **ロック**タグ(例:`runtime:oh_v0.9.3_1234567890abcdef`は常に特定のベースイメージ、依存関係、OpenHandsバージョンの組み合わせに対する最新のビルドを指します
## ランタイムプラグインシステム
OpenHandsランタイムは、機能を拡張しランタイム環境をカスタマイズできるプラグインシステムをサポートしています。プラグインはランタイムクライアントの起動時に初期化されます。
独自のプラグインを実装したい場合は、[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

View File

@@ -1,177 +0,0 @@
# 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['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レスポンスを返します。

View File

@@ -1,56 +0,0 @@
# クラウド課題リゾルバー
クラウド課題リゾルバーは、GitHubとGitLabのリポジトリに対してコード修正を自動化し、インテリジェントな支援を提供します。
## セットアップ
クラウド課題リゾルバーは、OpenHands Cloudリポジトリアクセスを許可すると自動的に利用可能になります
- [GitHubリポジトリアクセス](./github-installation#adding-repository-access)
- [GitLabリポジトリアクセス](./gitlab-installation#adding-repository-access)
![OpenHandsにリポジトリアクセスを追加する](/img/cloud/add-repo.png)
## 使用方法
OpenHands Cloudリポジトリアクセスを許可した後、リポジトリの課題やプルリクエスト/マージリクエストでクラウド課題リゾルバーを使用できます。
### 課題の操作
リポジトリで、課題に`openhands`というラベルを付けるか、`@openhands`で始まるメッセージを追加します。OpenHandsは以下を行います
1. 課題にコメントして、作業中であることを知らせます
- リンクをクリックすると、OpenHands Cloudで進捗状況を追跡できます
2. 課題が正常に解決されたと判断した場合、プルリクエストGitHubまたはマージリクエストGitLabを開きます
3. 実行されたタスクの概要とPR/MRへのリンクを含むコメントを課題に残します
![OpenHands課題リゾルバーの動作](/img/cloud/issue-resolver.png)
#### 課題用のコマンド例
以下は、課題リゾルバーで使用できるコマンドの例です:
```
@openhands 課題の説明を読んで修正してください
```
### プルリクエスト/マージリクエストの操作
プルリクエストGitHubまたはマージリクエストGitLabでOpenHandsを動作させるには、コメントで`@openhands`を言及して以下を行います:
- 質問する
- 更新をリクエストする
- コードの説明を取得する
OpenHandsは以下を行います
1. 作業中であることを知らせるコメントをします
2. リクエストされたタスクを実行します
#### プルリクエスト/マージリクエスト用のコマンド例
以下は、プルリクエスト/マージリクエストで使用できるコマンドの例です:
```
@openhands レビューコメントを反映してください
```
```
@openhands マージの競合を修正し、CIが通過することを確認してください
```

View File

@@ -1,29 +0,0 @@
# クラウドUI
クラウドUIは、OpenHands AIと対話するためのウェブインターフェースを提供します。このページでは、OpenHands クラウドUIへのアクセス方法と使用方法について説明します。
## UIへのアクセス
OpenHands クラウドUIは[app.all-hands.dev](https://app.all-hands.dev)でアクセスできます。インターフェースにアクセスするには、GitHubまたはGitLabアカウントでサインインする必要があります。
<!-- 画像は将来のアップデートで追加されます -->
<!-- ![OpenHands クラウドUI](/img/docs/openhands-cloud-ui.png) -->
## 主な機能
OpenHands クラウドUIで利用可能な機能の詳細については、ドキュメントの[主な機能](../key-features.md)セクションを参照してください。
## 設定
設定ページでは以下のことができます:
1. アカウント設定の構成
2. リポジトリアクセスの管理
3. プログラムによるアクセスのためのAPIキーの生成
4. OpenHandsエクスペリエンスのカスタマイズ
## 次のステップ
- [クラウド課題リゾルバーを使用する](./cloud-issue-resolver.md)でコード修正を自動化し、支援を受ける
- [クラウドAPIについて学ぶ](./cloud-api.md)でプログラムによるアクセスを行う
- [はじめにに戻る](./openhands-cloud.md)

View File

@@ -1,57 +0,0 @@
# GitHub インストール
このガイドでは、GitHubリポジトリ用にOpenHands Cloudをインストールおよび設定するプロセスについて説明します。
## 前提条件
- GitHubアカウント
- OpenHands Cloudへのアクセス
## インストール手順
1. [OpenHands Cloud](https://app.all-hands.dev)にログインします
2. まだGitHubアカウントを接続していない場合
- `GitHubに接続する`をクリックします
- 利用規約を確認して同意します
- OpenHands AIアプリケーションを承認します
## リポジトリアクセスの追加
特定のリポジトリへのアクセスをOpenHandsに許可できます
1. `GitHubプロジェクトを選択`ドロップダウンをクリックし、`リポジトリを追加...`を選択します
2. 組織を選択し、OpenHandsにアクセスを許可する特定のリポジトリを選択します。
- OpenHandsは以下の権限を持つ短期間のトークン8時間の有効期限をリクエストします
- アクション:読み取りと書き込み
- 管理:読み取り専用
- コミットステータス:読み取りと書き込み
- コンテンツ:読み取りと書き込み
- 課題:読み取りと書き込み
- メタデータ:読み取り専用
- プルリクエスト:読み取りと書き込み
- Webhook読み取りと書き込み
- ワークフロー:読み取りと書き込み
- ユーザーのリポジトリアクセスは以下に基づいて付与されます:
- リポジトリに付与された権限
- ユーザーのGitHub権限所有者/コラボレーター)
3. `インストール&承認`をクリックします
![OpenHandsへのリポジトリアクセスの追加](/img/cloud/add-repo.png)
## リポジトリアクセスの変更
リポジトリアクセスはいつでも変更できます:
* 同じ`GitHubプロジェクトを選択 > リポジトリを追加`ワークフローを使用する、または
* 設定ページにアクセスし、`GitHub設定`セクションで`GitHubリポジトリを設定する`を選択します。
## GitHubでのOpenHandsの使用
リポジトリアクセスを許可すると、GitHubリポジトリでOpenHandsを使用できます。
GitHub課題とプルリクエストでOpenHandsを使用する方法の詳細については、[クラウド課題リゾルバー](./cloud-issue-resolver.md)のドキュメントを参照してください。
## 次のステップ
- [クラウドUIにアクセスする](./cloud-ui.md)でウェブインターフェースと対話する
- [クラウド課題リゾルバーを使用する](./cloud-issue-resolver.md)でコード修正を自動化し、支援を受ける
- [クラウドAPIを使用する](./cloud-api.md)でプログラムによりOpenHandsと対話する

View File

@@ -1,50 +0,0 @@
# GitLab インストール
このガイドでは、GitLabリポジトリ用にOpenHands Cloudをインストールおよび設定するプロセスについて説明します。
## 前提条件
- GitLabアカウント
- OpenHands Cloudへのアクセス
## インストール手順
1. [OpenHands Cloud](https://app.all-hands.dev)にログインします
2. まだGitLabアカウントを接続していない場合
- `GitLabに接続する`をクリックします
- 利用規約を確認して同意します
- OpenHands AIアプリケーションを承認します
## リポジトリアクセスの追加
特定のリポジトリへのアクセスをOpenHandsに許可できます
1. `GitLabプロジェクトを選択`ドロップダウンをクリックし、`リポジトリを追加...`を選択します
2. 組織を選択し、OpenHandsにアクセスを許可する特定のリポジトリを選択します。
- OpenHandsは以下のスコープで権限をリクエストします
- api完全なAPIアクセス
- read_userユーザー情報の読み取り
- read_repositoryリポジトリ情報の読み取り
- write_repositoryリポジトリへの書き込み
- ユーザーのリポジトリアクセスは以下に基づいて付与されます:
- リポジトリに付与された権限
- ユーザーのGitLab権限所有者/メンテナー/開発者)
3. `インストール&承認`をクリックします
## リポジトリアクセスの変更
リポジトリアクセスはいつでも変更できます:
* 同じ`GitLabプロジェクトを選択 > リポジトリを追加`ワークフローを使用する、または
* 設定ページにアクセスし、`GitLab設定`セクションで`GitLabリポジトリを設定する`を選択します。
## GitLabでのOpenHandsの使用
リポジトリアクセスを許可すると、GitLabリポジトリでOpenHandsを使用できます。
GitLab課題とマージリクエストでOpenHandsを使用する方法の詳細については、[クラウド課題リゾルバー](./cloud-issue-resolver.md)のドキュメントを参照してください。
## 次のステップ
- [クラウドUIにアクセスする](./cloud-ui.md)でウェブインターフェースと対話する
- [クラウド課題リゾルバーを使用する](./cloud-issue-resolver.md)でコード修正を自動化し、支援を受ける
- [クラウドAPIを使用する](./cloud-api.md)でプログラムによりOpenHandsと対話する

View File

@@ -1,24 +0,0 @@
# OpenHands クラウド
OpenHands クラウドは、All Hands AIのOpenHandsのホスト型クラウドバージョンです。
## OpenHands クラウドへのアクセス
OpenHands クラウドを始めるには、[app.all-hands.dev](https://app.all-hands.dev)にアクセスしてください。
GitHubまたはGitLabアカウントで接続するよう求められます
1. 利用規約を読んで同意した後、`GitHubに接続する`または`GitLabに接続する`をクリックします。
2. OpenHandsがリクエストする権限を確認し、アプリケーションを承認します。
- OpenHandsはあなたのアカウントから特定の権限を必要とします。これらの権限について詳しく知るには、
承認ページの`詳細を見る`リンクをクリックしてください。
## 次のステップ
アカウントを接続したら、以下のことができます:
- [GitHub統合をインストールする](./github-installation.md)でGitHubリポジトリでOpenHandsを使用する
- [GitLab統合をインストールする](./gitlab-installation.md)でGitLabリポジトリでOpenHandsを使用する
- [クラウドUIにアクセスする](./cloud-ui.md)でウェブインターフェースと対話する
- [クラウドAPIを使用する](./cloud-api.md)でプログラムによりOpenHandsと対話する
- [クラウド課題リゾルバーを設定する](./cloud-issue-resolver.md)でコード修正を自動化し、インテリジェントな支援を提供する

View File

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

View File

@@ -1,81 +0,0 @@
# 💿 カスタム Docker サポートを作成する方法
デフォルトの OpenHands サンドボックスは、最小限の ubuntu 構成で提供されています。ユースケースによっては、デフォルトでインストールされているソフトウェアが必要になる場合があります。この記事では、カスタム docker イメージを使用してこれを実現する方法について説明します。
## セットアップ
[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) のドキュメントに従って、OpenHands を使用できるようにしてください。
## カスタム Docker イメージの作成
次に、debian/ubuntu ベースのカスタム docker イメージを作成する必要があります。たとえば、OpenHands で "node" バイナリにアクセスできるようにしたい場合は、次のような Dockerfile を使用します:
```bash
# 最新の ubuntu イメージから開始
FROM ubuntu:latest
# 必要なアップデートを実行
RUN apt-get update && apt-get install
# nodejs をインストール
RUN apt-get install -y nodejs
```
次に、選択した名前でカスタム docker イメージをビルドします。たとえば、"custom_image" とします。そのためには、ディレクトリを作成し、"Dockerfile" という名前のファイルをその中に配置し、ディレクトリ内でこのコマンドを実行します:
```bash
docker build -t custom_image .
```
これにより、```custom_image``` という名前の新しいイメージが作成され、Docker Engine で利用できるようになります。
> 注: ここで説明する設定では、OpenHands はサンドボックス内で "openhands" ユーザーとして動作するため、Dockerfile 経由でインストールされたパッケージは、root だけでなくシステム上のすべてのユーザーが利用できるようになります。
>
> 上記の apt-get によるインストールでは、すべてのユーザー向けに nodejs がインストールされます。
## config.toml ファイルでカスタムイメージを指定
OpenHands の設定は、トップレベルの ```config.toml``` ファイルを介して行われます。
OpenHands ディレクトリに ```config.toml``` ファイルを作成し、次の内容を入力します:
```toml
[core]
workspace_base="./workspace"
run_as_openhands=true
[sandbox]
base_container_image="custom_image"
```
> ```base_container_image``` が前述のカスタムイメージ名に設定されていることを確認してください。
## 実行
ルートディレクトリで ```make run``` を実行して OpenHands を起動します。
```localhost:3001``` に移動し、目的の依存関係が利用可能かどうかを確認します。
上記の例の場合、コンソールで ```node -v``` コマンドを実行すると ```v18.19.1``` が出力されます。
おめでとうございます!
## 技術的な説明
詳細な説明については、[実行時ドキュメントのカスタムDockerイメージの章](https://docs.all-hands.dev/ja/modules/usage/architecture/runtime)を参照してください。
## トラブルシューティング / エラー
### エラー: ```useradd: UID 1000 は一意ではありません```
このエラーがコンソール出力に表示される場合、OpenHands がサンドボックス内に UID 1000 で openhands ユーザーを作成しようとしていますが、この UID は (何らかの理由で) イメージ内ですでに使用されているためです。この問題を解決するには、config.toml ファイルの user_id フィールドの値を別の値に変更します:
```toml
[core]
workspace_base="./workspace"
run_as_openhands=true
[sandbox]
base_container_image="custom_image"
user_id="1001"
```
### ポート使用エラー
ポートが使用中または利用不可であることを示すエラーメッセージが表示される場合は、実行中のすべての docker コンテナを削除してみてください (`docker ps` を実行し、関連するコンテナに対して `docker rm` を実行します)。その後、```make run``` を再実行します。

View File

@@ -1,21 +0,0 @@
# リポジトリのカスタマイズ
リポジトリのルートレベルに `.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 ..
```

View File

@@ -1,39 +0,0 @@
# ✅ フィードバックの提供
OpenHandsを使用する際、うまく機能する場合と機能しない場合があります。OpenHandsを使用する際にフィードバックを提供することで、開発チームにフィードバックを与え、さらに重要なことに、コーディングエージェントのトレーニング例のオープンコーパスを作成することを奨励します - Share-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>
## 📜 データの使用とプライバシー
### データ共有設定
データを提出する際、公開または非公開で提出することができます。
- **公開**データはOpenHands自体と同様にMITライセンスの下で配布され、コミュニティがモデルのトレーニングとテストに使用できます。明らかに、公開できるフィードバックはコミュニティ全体にとってより価値があるため、機密情報を扱っていない場合は、このオプションを選択することをお勧めします
- **非公開**データはOpenHandsの改善を目的としてOpenHandsチームが利用できるようになります。ただし、他の人と公開して共有できる一意のIDを持つリンクは引き続き作成されます。
### 誰がデータを収集・保存するのか?
データはOpenHandsのメンテナーによって設立された[All Hands AI](https://all-hands.dev)という会社によって収集・保存されます。この会社はOpenHandsをサポートし改善するために設立されました。
### 公開データはどのようにリリースされますか?
公開データは、1,000件の公開例、10,000件の公開例など、固定のマイルストーンに達した時点でリリースされます。
この時点で、以下のリリースプロセスに従います:
1. 公開フィードバックを提供したすべての人にデータリリースについて説明し、オプトアウトの機会を与えるメールが送信されます。
2. データリリースを担当する人物は、低品質のフィードバックの削除、提出者のメールアドレスの削除、機密情報の削除を試みるなど、データの品質管理を行います。
3. データはMITライセンスの下でGitHubやHugging Faceなどの一般的に使用されているサイトを通じて公開されます。
### データの削除を希望する場合はどうすればよいですか?
All Hands AIのサーバー上のデータについては、リクエストに応じて喜んで削除します
**1つのデータ** 1つのデータの削除を希望する場合、近日中にデータを提出した際にインターフェースに表示されるリンクとパスワードを使用してデータを削除するメカニズムを追加する予定です。
**すべてのデータ:** すべてのデータの削除を希望する場合、またはデータ提出時に受け取ったIDとパスワードをお持ちでない場合は、データを最初に提出した際に登録したメールアドレスから`contact@all-hands.dev`にお問い合わせください。

View File

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

View File

@@ -1,54 +0,0 @@
# CLIモード
OpenHandsは対話型CLIモードで実行でき、コマンドラインを通じて対話型セッションを開始することができます。
このモードは[ヘッドレスモード](headless-mode)とは異なり、対話型であり、スクリプト実行よりもユーザー操作に適しています。
## Pythonでの実行
コマンドラインから対話型OpenHandsセッションを開始するには
1. [開発環境セットアップ手順](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)に従っていることを確認してください。
2. 以下のコマンドを実行します:
```bash
poetry run python -m openhands.core.cli
```
このコマンドは対話型セッションを開始し、タスクを入力してOpenHandsからの応答を受け取ることができます。
環境変数または[`config.toml`ファイル](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)を通じて、モデル、APIキー、その他の設定を確実に設定する必要があります。
## Dockerでの実行
DockerでOpenHandsをCLIモードで実行するには
1. ターミナルで以下の環境変数を設定します:
- `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コマンドを実行します
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.40-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e SANDBOX_VOLUMES=$SANDBOX_VOLUMES \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-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.40 \
python -m openhands.core.cli
```
このコマンドはDocker内で対話型セッションを開始し、タスクを入力してOpenHandsからの応答を受け取ることができます。
`-e SANDBOX_USER_ID=$(id -u)`はDockerコマンドに渡され、サンドボックスユーザーがホストユーザーの権限と一致するようにします。これにより、エージェントがマウントされたワークスペースにroot所有のファイルを作成するのを防ぎます。

View File

@@ -1,101 +0,0 @@
# カスタムサンドボックス
:::note
このガイドは、ランタイム用に独自のカスタムDockerイメージを使用したいユーザー向けです。例えば、
特定のツールやプログラミング言語があらかじめインストールされているものなどです。
:::
サンドボックスはエージェントがタスクを実行する場所です。コマンドをあなたのコンピュータで直接実行する
これはリスクがあります代わりに、エージェントはDockerコンテナ内でコマンドを実行します。
デフォルトの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イメージを作成するには、Debianベースである必要があります。
例えば、OpenHandsに`ruby`をインストールしたい場合、以下の内容で`Dockerfile`を作成できます:
```dockerfile
FROM nikolaik/python-nodejs:python3.12-nodejs22
# 必要なパッケージをインストール
RUN apt-get update && apt-get install -y ruby
```
または、Rubyに特化したベースイメージを使用することもできます
```dockerfile
FROM ruby:latest
```
このファイルをフォルダに保存します。次に、ターミナルでそのフォルダに移動し、以下のコマンドを実行してDockerイメージcustom-imageをビルドします
```bash
docker build -t custom-image .
```
これにより、`custom-image`という名前の新しいイメージが作成され、Docker内で利用可能になります。
## Dockerコマンドの使用
[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 \
-e SANDBOX_BASE_CONTAINER_IMAGE=custom-image \
...
```
## 開発ワークフローの使用
### セットアップ
まず、[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の指示に従ってOpenHandsを実行できることを確認してください。
### ベースサンドボックスイメージの指定
OpenHandsディレクトリ内の`config.toml`ファイルで、`base_container_image`を使用したいイメージに設定します。
これは既に取得したイメージか、ビルドしたイメージのいずれかです:
```bash
[core]
...
[sandbox]
base_container_image="custom-image"
```
### 追加の設定オプション
`config.toml`ファイルでは、サンドボックスをカスタマイズするための他のオプションもサポートしています:
```toml
[core]
# ランタイムがビルドされるときに追加の依存関係をインストール
# 有効なシェルコマンドを含めることができます
# これらのコマンドで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」
platform = "linux/amd64"
```
### 実行
トップレベルディレクトリで```make run```を実行してOpenHandsを起動します。

View File

@@ -1,71 +0,0 @@
# デバッグ
以下は開発目的のためのOpenHandsのデバッグに関する入門ガイドです。
## サーバー / VSCode
以下の`launch.json`を使用すると、エージェント、コントローラー、サーバー要素のデバッグが可能になりますが、サンドボックスDockerの中で実行されるはデバッグできません。これは`workspace/`ディレクトリ内の変更を無視します:
```
{
"version": "0.2.0",
"configurations": [
{
"name": "OpenHands CLI",
"type": "debugpy",
"request": "launch",
"module": "openhands.core.cli",
"justMyCode": false
},
{
"name": "OpenHands WebApp",
"type": "debugpy",
"request": "launch",
"module": "uvicorn",
"args": [
"openhands.server.listen:app",
"--reload",
"--reload-exclude",
"${workspaceFolder}/workspace",
"--port",
"3000"
],
"justMyCode": false
}
]
}
```
より多くのパラメータを含む、より具体的なデバッグ設定を指定することもできます:
```
...
{
"name": "Debug CodeAct",
"type": "debugpy",
"request": "launch",
"module": "openhands.core.main",
"args": [
"-t",
"Ask me what your task is.",
"-d",
"${workspaceFolder}/workspace",
"-c",
"CodeActAgent",
"-l",
"llm.o1",
"-n",
"prompts"
],
"justMyCode": false
}
...
```
上記のスニペットの値は以下のように更新できます:
* *t*: タスク
* *d*: openhandsワークスペースディレクトリ
* *c*: エージェント
* *l*: LLM設定config.tomlで事前定義
* *n*: セッション名(例:イベントストリーム名)

View File

@@ -1,74 +0,0 @@
---
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`のスタイルガイドに従っている

View File

@@ -1,278 +0,0 @@
# 評価
このガイドでは、独自の評価ベンチマークをOpenHandsフレームワークに統合する方法の概要を説明します。
## 環境のセットアップとLLM設定
ローカル開発環境のセットアップについては、[こちら](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)の手順に従ってください。
開発モードのOpenHandsでは、ほとんどの設定を追跡するために`config.toml`を使用します。
以下は、複数のLLMを定義して使用するための設定ファイルの例です
```toml
[llm]
# 重要: ここにAPIキーを追加し、評価したいモデルを設定してください
model = "claude-3-5-sonnet-20241022"
api_key = "sk-XXX"
[llm.eval_gpt4_1106_preview_llm]
model = "gpt-4-1106-preview"
api_key = "XXX"
temperature = 0.0
[llm.eval_some_openai_compatible_model_llm]
model = "openai/MODEL_NAME"
base_url = "https://OPENAI_COMPATIBLE_URL/v1"
api_key = "XXX"
temperature = 0.0
```
## コマンドラインでOpenHandsを使用する方法
OpenHandsは以下の形式でコマンドラインから実行できます
```bash
poetry run python ./openhands/core/main.py \
-i <max_iterations> \
-t "<task_description>" \
-c <agent_class> \
-l <llm_config>
```
例えば:
```bash
poetry run python ./openhands/core/main.py \
-i 10 \
-t "Write me a bash script that prints hello world." \
-c CodeActAgent \
-l llm
```
このコマンドは以下の設定でOpenHandsを実行します
- 最大10回の反復
- 指定されたタスク説明
- CodeActAgentを使用
- `config.toml`ファイルの`llm`セクションで定義されたLLM設定を使用
## OpenHandsの仕組み
OpenHandsのメインエントリーポイントは`openhands/core/main.py`にあります。以下は動作の簡略化されたフローです:
1. コマンドライン引数を解析し、設定を読み込む
2. `create_runtime()`を使用してランタイム環境を作成する
3. 指定されたエージェントを初期化する
4. `run_controller()`を使用してコントローラーを実行する:
- ランタイムをエージェントに接続する
- エージェントのタスクを実行する
- 完了時に最終状態を返す
`run_controller()`関数はOpenHandsの実行の中核です。エージェント、ランタイム、タスク間の相互作用を管理し、ユーザー入力シミュレーションやイベント処理などを処理します。
## 最も簡単な始め方:既存のベンチマークを探索する
リポジトリの[`evaluation/benchmarks/`ディレクトリ](https://github.com/All-Hands-AI/OpenHands/blob/main/evaluation/benchmarks)で利用可能な様々な評価ベンチマークを確認することをお勧めします。
独自のベンチマークを統合するには、あなたのニーズに最も近いものから始めることをお勧めします。このアプローチにより、既存の構造を基に構築し、特定の要件に適応させることができるため、統合プロセスが大幅に効率化されます。
## 評価ワークフローの作成方法
ベンチマークの評価ワークフローを作成するには、以下の手順に従ってください:
1. 関連するOpenHandsユーティリティをインポートする
```python
import openhands.agenthub
from evaluation.utils.shared import (
EvalMetadata,
EvalOutput,
make_metadata,
prepare_dataset,
reset_logger_for_multiprocessing,
run_evaluation,
)
from openhands.controller.state.state import State
from openhands.core.config import (
AppConfig,
SandboxConfig,
get_llm_config_arg,
parse_arguments,
)
from openhands.core.logger import openhands_logger as logger
from openhands.core.main import create_runtime, run_controller
from openhands.events.action import CmdRunAction
from openhands.events.observation import CmdOutputObservation, ErrorObservation
from openhands.runtime.runtime import Runtime
```
2. 設定を作成する:
```python
def get_config(instance: pd.Series, metadata: EvalMetadata) -> AppConfig:
config = AppConfig(
default_agent=metadata.agent_class,
runtime='docker',
max_iterations=metadata.max_iterations,
sandbox=SandboxConfig(
base_container_image='your_container_image',
enable_auto_lint=True,
timeout=300,
),
)
config.set_llm_config(metadata.llm_config)
return config
```
3. ランタイムを初期化し、評価環境をセットアップする:
```python
def initialize_runtime(runtime: Runtime, instance: pd.Series):
# ここで評価環境をセットアップする
# 例えば、環境変数の設定、ファイルの準備など
pass
```
4. 各インスタンスを処理する関数を作成する:
```python
from openhands.utils.async_utils import call_async_from_sync
def process_instance(instance: pd.Series, metadata: EvalMetadata) -> EvalOutput:
config = get_config(instance, metadata)
runtime = create_runtime(config)
call_async_from_sync(runtime.connect)
initialize_runtime(runtime, instance)
instruction = get_instruction(instance, metadata)
state = run_controller(
config=config,
task_str=instruction,
runtime=runtime,
fake_user_response_fn=your_user_response_function,
)
# エージェントのアクションを評価する
evaluation_result = await evaluate_agent_actions(runtime, instance)
return EvalOutput(
instance_id=instance.instance_id,
instruction=instruction,
test_result=evaluation_result,
metadata=metadata,
history=compatibility_for_eval_history_pairs(state.history),
metrics=state.metrics.get() if state.metrics else None,
error=state.last_error if state and state.last_error else None,
)
```
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')
instances = prepare_dataset(your_dataset, output_file, eval_n_limit)
await run_evaluation(
instances,
metadata,
output_file,
num_workers,
process_instance
)
```
このワークフローでは、設定をセットアップし、ランタイム環境を初期化し、エージェントを実行してそのアクションを評価することで各インスタンスを処理し、結果を`EvalOutput`オブジェクトに収集します。`run_evaluation`関数は並列化と進捗追跡を処理します。
`get_instruction`、`your_user_response_function`、`evaluate_agent_actions`関数を特定のベンチマーク要件に合わせてカスタマイズすることを忘れないでください。
この構造に従うことで、OpenHandsフレームワーク内でベンチマーク用の堅牢な評価ワークフローを作成できます。
## `user_response_fn`の理解
`user_response_fn`はOpenHandsの評価ワークフローにおける重要なコンポーネントです。エージェントとのユーザー対話をシミュレートし、評価プロセス中に自動応答を可能にします。この関数は、エージェントの問い合わせやアクションに対して一貫した、事前定義された応答を提供したい場合に特に役立ちます。
### ワークフローと相互作用
アクションと`user_response_fn`を処理する正しいワークフローは次のとおりです:
1. エージェントがタスクを受け取り、処理を開始する
2. エージェントがアクションを発行する
3. アクションが実行可能な場合CmdRunAction、IPythonRunCellAction
- ランタイムがアクションを処理する
- ランタイムが観察結果を返す
4. アクションが実行不可能な場合通常はMessageAction
- `user_response_fn`が呼び出される
- シミュレートされたユーザー応答を返す
5. エージェントが観察結果またはシミュレートされた応答を受け取る
6. タスクが完了するか最大反復回数に達するまで、ステップ2〜5を繰り返す
より正確な視覚的表現は次のとおりです:
```
[エージェント]
|
v
[アクション発行]
|
v
[アクションは実行可能か?]
/ \
はい いいえ
| |
v v
[ランタイム] [user_response_fn]
| |
v v
[観察結果を返す] [シミュレートされた応答]
\ /
\ /
v v
[エージェントがフィードバックを受け取る]
|
v
[タスクを継続または完了]
```
このワークフローでは:
- 実行可能なアクション(コマンドの実行やコードの実行など)はランタイムによって直接処理される
- 実行不可能なアクション(通常、エージェントが通信や説明を求める場合)は`user_response_fn`によって処理される
- エージェントは、ランタイムからの観察結果か`user_response_fn`からのシミュレートされた応答かにかかわらず、フィードバックを処理する
このアプローチにより、具体的なアクションとシミュレートされたユーザー対話の両方を自動的に処理できるため、最小限の人間の介入でタスクを完了するエージェントの能力をテストしたい評価シナリオに適しています。
### 実装例
以下はSWE-Bench評価で使用される`user_response_fn`の例です:
```python
def codeact_user_response(state: State | None) -> str:
msg = (
'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:
# 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:
# let the agent know that it can give up when it has tried 3 times
return (
msg
+ 'If you want to give up, run: <execute_bash> exit </execute_bash>.\n'
)
return msg
```
この関数は以下を行います:
1. エージェントに作業を続けるよう促す標準メッセージを提供する
2. エージェントがユーザーとコミュニケーションを取ろうとした回数を確認する
3. エージェントが複数回試みた場合、諦めるオプションを提供する
この関数を使用することで、複数の評価実行にわたって一貫した動作を確保し、エージェントが人間の入力を待って立ち往生することを防ぐことができます。

View File

@@ -1,51 +0,0 @@
# OpenHands GitHub Actionの使用方法
このガイドでは、自分のプロジェクトでOpenHands GitHub Actionを使用する方法について説明します。
## OpenHandsリポジトリでのActionの使用
OpenHands GitHub Actionをリポジトリで使用するには、以下の手順に従います
1. リポジトリでイシューを作成します。
2. イシューに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントをイシューに残します。
アクションは自動的にトリガーされ、イシューの解決を試みます。
## 新しいリポジトリにActionをインストールする
自分のリポジトリにOpenHands GitHub Actionをインストールするには、
[OpenHands Resolverのリードミー](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md)に従ってください。
## 使用上のヒント
### 反復的な解決
1. リポジトリでイシューを作成します。
2. イシューに`fix-me`ラベルを追加するか、`@openhands-agent`で始まるコメントを残します。
3. プルリクエストを確認して、イシュー解決の試みをレビューします。
4. 一般的なコメント、レビューコメント、またはインラインスレッドコメントを通じてフィードバックを行います。
5. プルリクエストに`fix-me`ラベルを追加するか、`@openhands-agent`で始めて特定のコメントに対応します。
### ラベルとマクロの違い
- ラベル(`fix-me`OpenHandsにイシューまたはプルリクエスト**全体**に対応するよう要求します。
- マクロ(`@openhands-agent`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)を自動的にチェックします。
設定できるカスタマイズオプションは以下の通りです:
| **属性名** | **タイプ** | **目的** | **例** |
| -------------------------------- | ---------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| `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/usage/how-to/custom-sandbox-guide) | `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |
| `TARGET_BRANCH` | 変数 | `main`以外のブランチにマージ | `TARGET_BRANCH="dev"` |

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