upload docs

This commit is contained in:
tjb-tech
2025-02-12 14:28:33 +08:00
parent a7436aa818
commit 26a7ffb341
127 changed files with 37054 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.3 MiB

20
docs/.gitignore vendored Normal file
View File

@@ -0,0 +1,20 @@
# Dependencies
/node_modules
# Production
/build
# 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*

48
docs/DOC_STYLE_GUIDE.md Normal file
View File

@@ -0,0 +1,48 @@
# Documentation Style Guide
## General Writing Principles
- **Clarity & Conciseness**: Always prioritize clarity and brevity. Avoid unnecessary jargon or overly complex explanations.
Keep sentences short and to the point.
- **Gradual Complexity**: Start with the simplest, most basic setup, and then gradually introduce more advanced
concepts and configurations.
## Formatting Guidelines
### Headers
Use **Title Case** for the first and second level headers.
Example:
- **Basic Usage**
- **Advanced Configuration Options**
### Lists
When listing items or options, use bullet points to enhance readability.
Example:
- Option A
- Option B
- Option C
### Procedures
For instructions or processes that need to be followed in a specific order, use numbered steps.
Example:
1. Step one: Do this.
2. Step two: Complete this action.
3. Step three: Verify the result.
### Code Blocks
* Use code blocks for multi-line inputs, outputs, commands and code samples.
Example:
```bash
docker run -it \
-e THIS=this \
-e THAT=that
...
```

41
docs/README.md Normal file
View File

@@ -0,0 +1,41 @@
# Website
This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
### Installation
```
$ yarn
```
### Local Development
```
$ yarn 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.
### Build
```
$ yarn build
```
This command generates static content into the `build` directory and can be served using any static contents hosting service.
### Deployment
Using SSH:
```
$ USE_SSH=true yarn deploy
```
Not using SSH:
```
$ GIT_USER=<Your GitHub username> yarn deploy
```
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

3
docs/babel.config.js Normal file
View File

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

View File

@@ -0,0 +1,3 @@
# Python Docs
Docs will appear here after deployment.

View File

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

View File

@@ -0,0 +1,29 @@
---
title: Welcome to MetaChain
sidebar_position: 0
slug: /
---
Welcome to MetaChain! MetaChain is a **Fully-Automated** and highly **Self-Developing** framework that enables users to create and deploy LLM agents through **Natural Language Alone**.
## ✨Key Features
* 🏆 Top Performer on the GAIA Benchmark
<br/>MetaChain has ranked the **#1** spot among open-sourced methods, delivering comparable performance to **OpenAI's Deep Research**.
* 📚 Agentic-RAG with Native Self-Managing Vector Database
<br/>MetaChain equipped with a native self-managing vector database, outperforms industry-leading solutions like **LangChain**.
* ✨ Agent and Workflow Create with Ease
<br/>MetaChain leverages natural language to effortlessly build ready-to-use **tools**, **agents** and **workflows** - no coding required.
* 🌐 Universal LLM Support
<br/>MetaChain seamlessly integrates with **A Wide Range** of LLMs (e.g., OpenAI, Anthropic, Deepseek, vLLM, Grok, Huggingface ...)
* 🔀 Flexible Interaction
<br/>Benefit from support for both **function-calling** and **ReAct** interaction modes.
* 🤖 Dynamic, Extensible, Lightweight
<br/>MetaChain is your **Personal AI Assistant**, designed to be dynamic, extensible, customized, and lightweight.
🚀 Unlock the Future of LLM Agents. Try 🔥MetaChain🔥 Now!

78
docs/docusaurus.config.ts Normal file
View File

@@ -0,0 +1,78 @@
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: "MetaChain",
tagline: "Fully-Automated & Zero-Code LLM Agent Framework",
favicon: "img/metachain_logo.svg",
// Set the production url of your site here
url: "https://metachain-ai.github.io",
baseUrl: "/",
// GitHub pages deployment config.
organizationName: "metachain-ai",
projectName: "metachain-ai.github.io",
trailingSlash: false,
deploymentBranch: "main",
onBrokenLinks: "throw",
onBrokenMarkdownLinks: "warn",
markdown: {
mermaid: true,
},
themes: ['@docusaurus/theme-mermaid'],
presets: [
[
"classic",
{
docs: {
path: "docs",
routeBasePath: "docs",
sidebarPath: "./sidebars.ts",
exclude: [
"**/*.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: "MetaChain",
logo: {
alt: "MetaChain",
src: "img/metachain_logo.svg",
},
items: [
{
type: "docSidebar",
sidebarId: "docsSidebar",
position: "left",
label: "Docs",
},
{
href: "https://github.com/HKUDS/MetaChain",
label: "GitHub",
position: "right",
},
],
},
prism: {
theme: prismThemes.oneLight,
darkTheme: prismThemes.oneDark,
},
} satisfies Preset.ThemeConfig,
};
export default config;

406
docs/i18n/fr/code.json Normal file
View File

@@ -0,0 +1,406 @@
{
"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"
}
}

View File

@@ -0,0 +1,14 @@
{
"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

@@ -0,0 +1,18 @@
{
"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"
}
}

View File

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

View File

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

View File

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

View File

@@ -0,0 +1,25 @@
# 🧠 Agent Principal et Capacités
## CodeActAgent
### Description
Cet agent implémente l'idée de CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action de **code** unifié à la fois pour la _simplicité_ et la _performance_.
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 une commande `bash`, voir le système de plugin 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` effectuant une tâche de science des données (régression linéaire)_.

View File

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

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

View File

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

View File

@@ -0,0 +1,395 @@
# Options de configuration
Ce guide détaille toutes les options de configuration disponibles pour OpenHands, vous aidant à personnaliser son comportement et à l'intégrer avec d'autres services.
:::note
Si vous exécutez en [Mode GUI](https://docs.all-hands.dev/modules/usage/how-to/gui-mode), les paramètres disponibles dans l'interface utilisateur des paramètres auront toujours
la priorité.
:::
---
# Table des matières
1. [Configuration de base](#configuration-de-base)
- [Clés API](#clés-api)
- [Espace de travail](#espace-de-travail)
- [Débogage et journalisation](#débogage-et-journalisation)
- [Gestion des sessions](#gestion-des-sessions)
- [Trajectoires](#trajectoires)
- [Stockage de fichiers](#stockage-de-fichiers)
- [Gestion des tâches](#gestion-des-tâches)
- [Configuration du bac à sable](#configuration-du-bac-à-sable)
- [Divers](#divers)
2. [Configuration LLM](#configuration-llm)
- [Informations d'identification AWS](#informations-didentification-aws)
- [Configuration de l'API](#configuration-de-lapi)
- [Fournisseur LLM personnalisé](#fournisseur-llm-personnalisé)
- [Embeddings](#embeddings)
- [Gestion des messages](#gestion-des-messages)
- [Sélection du modèle](#sélection-du-modèle)
- [Nouvelles tentatives](#nouvelles-tentatives)
- [Options avancées](#options-avancées)
3. [Configuration de l'agent](#configuration-de-lagent)
- [Configuration du micro-agent](#configuration-du-micro-agent)
- [Configuration de la mémoire](#configuration-de-la-mémoire)
- [Configuration LLM](#configuration-llm-2)
- [Configuration de l'espace d'action](#configuration-de-lespace-daction)
- [Utilisation du micro-agent](#utilisation-du-micro-agent)
4. [Configuration du bac à sable](#configuration-du-bac-à-sable-2)
- [Exécution](#exécution)
- [Image de conteneur](#image-de-conteneur)
- [Mise en réseau](#mise-en-réseau)
- [Linting et plugins](#linting-et-plugins)
- [Dépendances et environnement](#dépendances-et-environnement)
- [Évaluation](#évaluation)
5. [Configuration de sécurité](#configuration-de-sécurité)
- [Mode de confirmation](#mode-de-confirmation)
- [Analyseur de sécurité](#analyseur-de-sécurité)
---
## Configuration de base
Les options de configuration de base sont définies dans la section `[core]` du fichier `config.toml`.
**Clés API**
- `e2b_api_key`
- Type : `str`
- Valeur par défaut : `""`
- Description : Clé API pour E2B
- `modal_api_token_id`
- Type : `str`
- Valeur par défaut : `""`
- Description : ID du jeton API pour Modal
- `modal_api_token_secret`
- Type : `str`
- Valeur par défaut : `""`
- Description : Secret du jeton API pour Modal
**Espace de travail**
- `workspace_base`
- Type : `str`
- Valeur par défaut : `"./workspace"`
- Description : Chemin de base pour l'espace de travail
- `cache_dir`
- Type : `str`
- Valeur par défaut : `"/tmp/cache"`
- Description : Chemin du répertoire de cache
**Débogage et journalisation**
- `debug`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Activer le débogage
- `disable_color`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Désactiver la couleur dans la sortie du terminal
**Trajectoires**
- `save_trajectory_path`
- Type : `str`
- Valeur par défaut : `"./trajectories"`
- Description : Chemin pour stocker les trajectoires (peut être un dossier ou un fichier). Si c'est un dossier, les trajectoires seront enregistrées dans un fichier nommé avec l'ID de session et l'extension .json, dans ce dossier.
**Stockage de fichiers**
- `file_store_path`
- Type : `str`
- Valeur par défaut : `"/tmp/file_store"`
- Description : Chemin de stockage des fichiers
- `file_store`
- Type : `str`
- Valeur par défaut : `"memory"`
- Description : Type de stockage de fichiers
- `file_uploads_allowed_extensions`
- Type : `list of str`
- Valeur par défaut : `[".*"]`
- Description : Liste des extensions de fichiers autorisées pour les téléchargements
- `file_uploads_max_file_size_mb`
- Type : `int`
- Valeur par défaut : `0`
- Description : Taille maximale des fichiers pour les téléchargements, en mégaoctets
- `file_uploads_restrict_file_types`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Restreindre les types de fichiers pour les téléchargements de fichiers
- `file_uploads_allowed_extensions`
- Type : `list of str`
- Valeur par défaut : `[".*"]`
- Description : Liste des extensions de fichiers autorisées pour les téléchargements
**Gestion des tâches**
- `max_budget_per_task`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Budget maximal par tâche (0.0 signifie aucune limite)
- `max_iterations`
- Type : `int`
- Valeur par défaut : `100`
- Description : Nombre maximal d'itérations
**Configuration du bac à sable**
- `workspace_mount_path_in_sandbox`
- Type : `str`
- Valeur par défaut : `"/workspace"`
- Description : Chemin de montage de l'espace de travail dans le bac à sable
- `workspace_mount_path`
- Type : `str`
- Valeur par défaut : `""`
- Description : Chemin de montage de l'espace de travail
- `workspace_mount_rewrite`
- Type : `str`
- Valeur par défaut : `""`
- Description : Chemin pour réécrire le chemin de montage de l'espace de travail. Vous pouvez généralement ignorer cela, cela fait référence à des cas spéciaux d'exécution à l'intérieur d'un autre conteneur.
**Divers**
- `run_as_openhands`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Exécuter en tant qu'OpenHands
- `runtime`
- Type : `str`
- Valeur par défaut : `"docker"`
- Description : Environnement d'exécution
- `default_agent`
- Type : `str`
- Valeur par défaut : `"CodeActAgent"`
- Description : Nom de l'agent par défaut
- `jwt_secret`
- Type : `str`
- Valeur par défaut : `uuid.uuid4().hex`
- Description : Secret JWT pour l'authentification. Veuillez le définir sur votre propre valeur.
## 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. Voir [Configurations LLM personnalisées](./llms/custom-llm-configs) pour plus de détails.
:::
**Informations d'identification AWS**
- `aws_access_key_id`
- Type : `str`
- Valeur par défaut : `""`
- Description : ID de clé d'accès AWS
- `aws_region_name`
- Type : `str`
- Valeur par défaut : `""`
- Description : Nom de la région AWS
- `aws_secret_access_key`
- Type : `str`
- Valeur par défaut : `""`
- Description : Clé d'accès secrète AWS
**Configuration de l'API**
- `api_key`
- Type : `str`
- Valeur par défaut : `None`
- Description : Clé API à utiliser
- `base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base de l'API
- `api_version`
- Type : `str`
- Valeur par défaut : `""`
- Description : Version de l'API
- `input_cost_per_token`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Coût par jeton d'entrée
- `output_cost_per_token`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Coût par jeton de sortie
**Fournisseur LLM personnalisé**
- `custom_llm_provider`
- Type : `str`
- Valeur par défaut : `""`
- Description : Fournisseur LLM personnalisé
**Embeddings**
- `embedding_base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base de l'API d'embedding
- `embedding_deployment_name`
- Type : `str`
- Valeur par défaut : `""`
- Description : Nom du déploiement d'embedding
- `embedding_model`
- Type : `str`
- Valeur par défaut : `"local"`
- Description : Modèle d'embedding à utiliser
**Gestion des messages**
- `max_message_chars`
- Type : `int`
- Valeur par défaut : `30000`
- Description : Le nombre maximum approximatif de caractères dans le contenu d'un événement inclus dans l'invite au LLM. Les observations plus grandes sont tronquées.
- `max_input_tokens`
- Type : `int`
- Valeur par défaut : `0`
- Description : Nombre maximal de jetons d'entrée
- `max_output_tokens`
- Type : `int`
- Valeur par défaut : `0`
- Description : Nombre maximal de jetons de sortie
**Sélection du modèle**
- `model`
- Type : `str`
- Valeur par défaut : `"claude-3-5-sonnet-20241022"`
- Description : Modèle à utiliser
**Nouvelles tentatives**
- `num_retries`
- Type : `int`
- Valeur par défaut : `8`
- Description : Nombre de nouvelles tentatives à effectuer
- `retry_max_wait`
- Type : `int`
- Valeur par défaut : `120`
- Description : Temps d'attente maximal (en secondes) entre les tentatives de nouvelle tentative
- `retry_min_wait`
- Type : `int`
- Valeur par défaut : `15`
- Description : Temps d'attente minimal (en secondes) entre les tentatives de nouvelle tentative
- `retry_multiplier`
- Type : `float`
- Valeur par défaut : `2.0`
- Description : Multiplicateur pour le calcul du backoff exponentiel
**Options avancées**
- `drop_params`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Supprimer tous les paramètres non mappés (non pris en charge) sans provoquer d'exception
- `caching_prompt`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Utiliser la fonctionnalité de mise en cache des invites si elle est fournie par le LLM et prise en charge
- `ollama_base_url`
- Type : `str`
- Valeur par défaut : `""`
- Description : URL de base pour l'API OLLAMA
- `temperature`
- Type : `float`
- Valeur par défaut : `0.0`
- Description : Température pour l'API
- `timeout`
- Type : `int`
- Valeur par défaut : `0`
- Description : Délai d'expiration pour l'API
- `top_p`
- Type : `float`
- Valeur par défaut : `1.0`
- Description : Top p pour l'API
- `disable_vision`
- Type : `bool`
- Valeur par défaut : `None`
- Description : Si le modèle est capable de vision, cette option permet de désactiver le traitement des images (utile pour réduire les coûts)
## 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 du micro-agent**
- `micro_agent_name`
- Type : `str`
- Valeur par défaut : `""`
- Description : Nom du micro-agent à utiliser pour cet agent
**Configuration de la mémoire**
- `memory_enabled`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si la mémoire à long terme (embeddings) est activée
- `memory_max_threads`
- Type : `int`
- Valeur par défaut : `3`
- Description : Le nombre maximum de threads indexant en même temps pour les embeddings
**Configuration LLM**
- `llm_config`
- Type : `str`
- Valeur par défaut : `'your-llm-config-group'`
- Description : Le nom de la configuration LLM à utiliser
**Configuration de l'espace d'action**
- `function_calling`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Si l'appel de fonction est activé
- `codeact_enable_browsing`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si le délégué de navigation est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
- `codeact_enable_llm_editor`
- Type : `bool`
- Valeur par défaut : `false`
- Description : Si l'éditeur LLM est activé dans l'espace d'action (fonctionne uniquement avec l'appel de fonction)
**Utilisation du micro-agent**
- `enable_prompt_extensions`
- Type : `bool`
- Valeur par défaut : `true`
- Description : Indique si l'utilisation des micro-agents est activée ou non
- `disabled_microagents`
- Type : `list of str`
- Valeur par défaut : `None`
- Description : Liste des micro-agents à désactiver
### Exécution
- `timeout`
- Type : `int`
- Valeur par défaut : `120`
- Description : Délai d'expiration du bac à sable, en secondes
- `user_id`
- Type : `int`
- Valeur par défaut : `1000`
- Description : ID de l'utilisateur du bac à sable

View File

@@ -0,0 +1,97 @@
# 💿 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 ```sandbox_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
Lorsqu'une image personnalisée est utilisée pour la première fois, elle ne sera pas trouvée et donc elle sera construite (à l'exécution ultérieure, l'image construite sera trouvée et renvoyée).
L'image personnalisée est construite avec [_build_sandbox_image()](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/docker/image_agnostic_util.py#L29), qui crée un fichier docker en utilisant votre image personnalisée comme base et configure ensuite l'environnement pour OpenHands, comme ceci:
```python
dockerfile_content = (
f'FROM {base_image}\n'
'RUN apt update && apt install -y openssh-server wget sudo\n'
'RUN mkdir -p -m0755 /var/run/sshd\n'
'RUN mkdir -p /openhands && mkdir -p /openhands/logs && chmod 777 /openhands/logs\n'
'RUN wget "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"\n'
'RUN bash Miniforge3-$(uname)-$(uname -m).sh -b -p /openhands/miniforge3\n'
'RUN bash -c ". /openhands/miniforge3/etc/profile.d/conda.sh && conda config --set changeps1 False && conda config --append channels conda-forge"\n'
'RUN echo "export PATH=/openhands/miniforge3/bin:$PATH" >> ~/.bashrc\n'
'RUN echo "export PATH=/openhands/miniforge3/bin:$PATH" >> /openhands/bash.bashrc\n'
).strip()
```
> Remarque: Le nom de l'image est modifié via [_get_new_image_name()](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/docker/image_agnostic_util.py#L63) et c'est ce nom modifié qui sera recherché lors des exécutions ultérieures.
## 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 sandbox_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"
sandbox_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

@@ -0,0 +1,41 @@
# ✅ Fournir des commentaires
Lorsque vous utilisez OpenHands, vous rencontrerez des cas où les choses fonctionnent bien, et d'autres où elles ne fonctionnent pas. Nous vous encourageons à fournir des commentaires lorsque vous utilisez OpenHands pour aider à donner des retours à l'équipe de développement, et peut-être plus important encore, créer un corpus ouvert d'exemples d'entraînement d'agents de codage -- Share-OpenHands !
## 📝 Comment fournir des commentaires
Fournir des commentaires est facile ! Lorsque vous utilisez OpenHands, vous pouvez appuyer sur le bouton pouce vers le haut ou pouce vers le bas à tout moment pendant votre interaction. Vous serez invité à fournir votre adresse e-mail (par exemple, afin que nous puissions vous contacter si nous voulons poser des questions de suivi), et vous pouvez choisir si vous souhaitez fournir des commentaires publiquement ou en privé.
<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 publiquement ou en privé.
* Les données **publiques** seront distribuées sous la licence MIT, comme OpenHands lui-même, et pourront être utilisées par la communauté pour entraîner et tester des modèles. Évidemment, les commentaires que vous pouvez rendre publics seront plus précieux pour la communauté dans son ensemble, donc lorsque vous ne traitez pas d'informations sensibles, nous vous encourageons à choisir cette option !
* Les données **privées** ne seront partagées qu'avec l'équipe OpenHands dans le but d'améliorer OpenHands.
### 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 qui ont contribué à des commentaires publics recevront un e-mail décrivant la publication des données et auront la possibilité de se retirer.
2. La ou les personnes en charge de la publication des données effectueront un contrôle de la qualité des données, en supprimant les commentaires de mauvaise qualité, en supprimant les adresses e-mail des soumissionnaires et en essayant de supprimer toute information sensible.
3. Les données seront publiées publiquement sous la licence MIT via des sites couramment utilisés tels que GitHub ou Hugging Face.
### Que faire si je veux que mes données soient supprimées ?
Pour les données sur les serveurs d'All Hands AI, nous sommes heureux de les supprimer sur demande :
**Une pièce de données :** Si vous souhaitez supprimer une pièce de données, nous ajouterons prochainement un mécanisme pour supprimer les pièces de données en utilisant le lien et le mot de passe qui s'affichent sur l'interface lorsque vous soumettez des données.
**Toutes les données :** Si vous souhaitez que toutes vos données soient supprimées, ou si vous n'avez pas l'ID et le mot de passe que vous avez reçus lors de la soumission des données, veuillez contacter `contact@all-hands.dev` à partir de l'adresse e-mail que vous avez enregistrée lorsque vous avez initialement soumis les données.

View File

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

View File

@@ -0,0 +1,112 @@
# 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 OpenHands interactive via la ligne de commande, suivez ces étapes :
1. Assurez-vous d'avoir suivi les [instructions de configuration de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
2. Exécutez la commande suivante :
```bash
poetry run python -m openhands.core.cli
```
Cette commande démarrera une session interactive où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
Vous devrez vous assurer de définir votre modèle, votre clé API et d'autres paramètres via des variables d'environnement
[ou le fichier `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Avec Docker
Pour exécuter OpenHands en mode CLI avec Docker, suivez ces étapes :
1. Définissez `WORKSPACE_BASE` sur le répertoire que vous voulez qu'OpenHands modifie :
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
2. Définissez `LLM_MODEL` sur le modèle que vous voulez utiliser :
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3. Définissez `LLM_API_KEY` sur votre clé API :
```bash
LLM_API_KEY="sk_test_12345"
```
4. Exécutez la commande Docker suivante :
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
--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.23 \
python -m openhands.core.cli
```
Cette commande démarrera une session interactive dans Docker où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
## Exemples de commandes CLI et de sorties attendues
Voici quelques exemples de commandes CLI et leurs sorties attendues :
### Exemple 1 : Tâche simple
```bash
How can I help? >> Écrivez un script Python qui affiche "Hello, World!"
```
Sortie attendue :
```bash
🤖 Bien sûr ! Voici un script Python qui affiche "Hello, World!" :
print("Hello, World!")
```
### Exemple 2 : Commande Bash
```bash
How can I help? >> Créez un répertoire nommé "test_dir"
```
Sortie attendue :
```bash
🤖 Création d'un répertoire nommé "test_dir" :
mkdir test_dir
```
### Exemple 3 : Gestion des erreurs
```bash
How can I help? >> Supprimez un fichier inexistant
```
Sortie attendue :
```bash
🤖 Une erreur s'est produite. Veuillez réessayer.
```

View File

@@ -0,0 +1,61 @@
# Sandbox Personnalisé
Le sandbox est l'endroit où l'agent effectue ses tâches. Au lieu d'exécuter des commandes directement sur votre ordinateur (ce qui pourrait être risqué), l'agent les exécute à l'intérieur d'un conteneur Docker.
Le sandbox OpenHands par défaut (`python-nodejs:python3.12-nodejs22` de [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)) est livré avec certains paquets installés tels que Python et Node.js mais peut nécessiter l'installation d'autres logiciels par défaut.
Vous avez deux options pour la personnalisation :
1. Utiliser une image existante avec les logiciels requis.
2. Créer votre propre image Docker personnalisée.
Si vous choisissez la première option, vous pouvez passer 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é, créez un `Dockerfile` avec le contenu suivant :
```dockerfile
FROM debian:latest
# Installer les paquets requis
RUN apt-get update && apt-get install -y ruby
```
Enregistrez ce fichier dans un dossier. Ensuite, construisez votre image Docker (par exemple, nommée custom-image) en naviguant vers le dossier dans le terminal et en exécutant :
```bash
docker build -t custom-image .
```
Cela produira une nouvelle image appelée `custom-image`, qui sera disponible dans Docker.
> Notez que dans la configuration décrite dans ce document, OpenHands s'exécutera en tant qu'utilisateur "openhands" à l'intérieur du sandbox et donc tous les paquets installés via le docker file devraient être disponibles pour tous les utilisateurs du système, pas seulement root.
## Utilisation du Workflow 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` dans le répertoire OpenHands, définissez `sandbox_base_container_image` sur l'image que vous souhaitez utiliser. Cela peut être une image que vous avez déjà extraite ou une que vous avez construite :
```bash
[core]
...
sandbox_base_container_image="custom-image"
```
### Exécution
Exécutez OpenHands en exécutant ```make run``` dans le répertoire de niveau supérieur.
## Explication Technique
Veuillez vous référer à la [section image docker personnalisée de la documentation d'exécution](https://docs.all-hands.dev/modules/usage/architecture/runtime#advanced-how-openhands-builds-and-maintains-od-runtime-images) pour plus de détails.

View File

@@ -0,0 +1,73 @@
# Débogage
Ce qui suit est destiné à servir d'introduction au débogage d'OpenHands à des fins de développement.
## Serveur / VSCode
Le `launch.json` suivant permettra de déboguer les éléments agent, contrôleur et serveur, mais pas le bac à sable (qui s'exécute dans docker). Il ignorera toutes les modifications à l'intérieur du répertoire `workspace/` :
```
{
"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 plus de paramètres peuvent être spécifiées :
```
...
{
"name": "Debug CodeAct",
"type": "debugpy",
"request": "launch",
"module": "openhands.core.main",
"args": [
"-t",
"Demandez-moi quelle est votre tâche.",
"-d",
"${workspaceFolder}/workspace",
"-c",
"CodeActAgent",
"-l",
"llm.o1",
"-n",
"prompts"
],
"justMyCode": false
}
...
```
Les valeurs dans l'extrait ci-dessus peuvent être mises à jour de telle sorte que :
* *t* : la tâche
* *d* : le répertoire de l'espace de travail openhands
* *c* : l'agent
* *l* : la configuration LLM (prédéfinie dans config.toml)
* *n* : le nom de la session (par exemple, le nom du flux d'événements)

View File

@@ -0,0 +1,280 @@
# Évaluation
Ce guide fournit un aperçu de la façon d'intégrer votre propre benchmark d'évaluation dans le framework OpenHands.
## Configuration de l'environnement et de la configuration LLM
Veuillez suivre les instructions [ici](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) pour configurer votre environnement de développement local.
OpenHands en mode développement utilise `config.toml` pour garder une trace de la plupart des configurations.
Voici un exemple de fichier de configuration que vous pouvez utiliser pour définir et utiliser plusieurs LLMs :
```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 "Écrivez-moi un script bash qui affiche 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
- En utilisant CodeActAgent
- Avec la configuration LLM définie dans la section `llm` de votre fichier `config.toml`
## Comment fonctionne OpenHands
Le point d'entrée principal d'OpenHands se trouve dans `openhands/core/main.py`. Voici un flux simplifié de son fonctionnement :
1. Analyse des arguments de ligne de commande et chargement de la configuration
2. Création d'un environnement d'exécution à l'aide de `create_runtime()`
3. Initialisation de l'agent spécifié
4. Exécution du contrôleur à l'aide de `run_controller()`, qui :
- Attache l'environnement d'exécution à l'agent
- Exécute la tâche de l'agent
- Renvoie un état final une fois terminé
La fonction `run_controller()` est le cœur de l'exécution d'OpenHands. Elle gère l'interaction entre l'agent, l'environnement d'exécution et la tâche, en gérant des choses comme la simulation d'entrée utilisateur et le traitement des événements.
## Le moyen le plus simple de commencer : Explorer les benchmarks existants
Nous vous encourageons à examiner les différents benchmarks d'évaluation disponibles dans le [répertoire `evaluation/benchmarks/`](https://github.com/All-Hands-AI/OpenHands/blob/main/evaluation/benchmarks) de notre dépôt.
Pour intégrer votre propre benchmark, nous vous suggérons de commencer par celui qui ressemble le plus à vos besoins. Cette approche peut considérablement rationaliser votre processus d'intégration, vous permettant de vous appuyer sur les structures existantes et de les adapter à vos exigences spécifiques.
## 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 l'environnement d'exécution 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` en fonction des exigences spécifiques de votre benchmark.
En suivant cette structure, vous pouvez créer un workflow d'évaluation robuste pour votre benchmark dans le framework OpenHands.
## Comprendre la `user_response_fn`
La `user_response_fn` est un composant crucial dans le workflow d'évaluation d'OpenHands. Elle simule l'interaction de l'utilisateur avec l'agent, permettant des réponses automatisées pendant le processus d'évaluation. Cette fonction est particulièrement utile lorsque vous voulez fournir des réponses cohérentes et prédéfinies aux requêtes ou actions de l'agent.
### Workflow et interaction
Le workflow correct pour gérer les actions et la `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 `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
[Émettre une Action]
|
v
[L'Action est-elle exécutable ?]
/ \
Oui Non
| |
v v
[Runtime] [user_response_fn]
| |
v v
[Renvoyer une Observation] [Réponse simulée]
\ /
\ /
v v
[L'agent reçoit le feedback]
|
v
[Continuer ou terminer la tâche]
```
Dans ce workflow :
- Les actions exécutables (comme l'exécution de commandes ou de code) sont gérées directement par le Runtime
- Les actions non exécutables (généralement lorsque l'agent veut communiquer ou demander des clarifications) sont gérées par la `user_response_fn`
- L'agent traite ensuite le feedback, qu'il s'agisse d'une Observation du Runtime ou d'une réponse simulée de la `user_response_fn`
Cette approche permet une gestion automatisée des actions concrètes et des interactions utilisateur simulées, ce qui la rend adaptée aux scénarios d'évaluation où vous voulez tester la capacité de l'agent à accomplir des tâches avec une intervention humaine minimale.
### Exemple d'implémentation
Voici un exemple de `user_response_fn` utilisée dans l'évaluation SWE-Bench :
```python
def codeact_user_response(state: State | None) -> str:
msg = (
'Veuillez continuer à travailler sur la tâche avec l\'approche que vous jugez appropriée.\n'
'Si vous pensez avoir résolu la tâche, veuillez d\'abord envoyer votre réponse à l\'utilisateur via un message, puis <execute_bash> exit </execute_bash>.\n'
'IMPORTANT : VOUS NE DEVEZ JAMAIS DEMANDER DE L\'AIDE HUMAINE.\n'
)
if state and state.history:
# vérifier si l'agent a essayé de parler à l'utilisateur 3 fois, si oui, faire savoir à l'agent qu'il peut abandonner
user_msgs = [
event
for event in state.history
if isinstance(event, MessageAction) and event.source == 'user'
]
if len(user_msgs) >= 2:
# faire savoir à l'agent qu'il peut abandonner quand il a essayé 3 fois
return (
msg
+ 'Si vous voulez abandonner, exécutez : <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, il lui donne la possibilité d'abandonner
En utilisant cette fonction, vous pouvez assurer un comportement cohérent sur plusieurs exécutions d'évaluation et empêcher l'agent de rester bloqué en attendant une entrée humaine.

View File

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

View File

@@ -0,0 +1,127 @@
# Mode Interface Graphique
## Introduction
OpenHands fournit un mode Interface Graphique (GUI) convivial pour interagir avec l'assistant IA. Ce mode offre une façon intuitive de configurer l'environnement, gérer les paramètres et communiquer avec l'IA.
## Installation et Configuration
1. Suivez les instructions du guide [Installation](../installation) pour installer OpenHands.
2. Après avoir exécuté la commande, accédez à OpenHands à l'adresse [http://localhost:3000](http://localhost:3000).
## Interagir avec l'Interface Graphique
### Configuration Initiale
1. Lors du premier lancement, vous verrez une fenêtre modale de paramètres.
2. Sélectionnez un `Fournisseur LLM` et un `Modèle LLM` dans les menus déroulants.
3. Entrez la `Clé API` correspondante pour le fournisseur choisi.
4. Cliquez sur "Enregistrer" pour appliquer les paramètres.
### Configuration du Jeton GitHub
OpenHands exporte automatiquement un `GITHUB_TOKEN` vers l'environnement shell s'il est disponible. Cela peut se produire de deux manières :
1. **Localement (OSS)** : L'utilisateur saisit directement son jeton GitHub
2. **En ligne (SaaS)** : Le jeton est obtenu via l'authentification OAuth GitHub
#### Configuration d'un Jeton GitHub Local
1. **Générer un Personal Access Token (PAT)** :
- Allez dans Paramètres GitHub > Paramètres développeur > Personal Access Tokens > Tokens (classique)
- Cliquez sur "Générer un nouveau jeton (classique)"
- Portées requises :
- `repo` (Contrôle total des dépôts privés)
- `workflow` (Mettre à jour les workflows GitHub Action)
- `read:org` (Lire les données de l'organisation)
2. **Entrer le Jeton dans OpenHands** :
- Cliquez sur le bouton Paramètres (icône d'engrenage) en haut à droite
- Accédez à la section "GitHub"
- Collez votre jeton dans le champ "Jeton GitHub"
- Cliquez sur "Enregistrer" pour appliquer les modifications
#### Politiques de Jetons Organisationnels
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 appliquer des politiques de jetons spécifiques
- Certaines organisations exigent que les jetons soient créés avec SSO activé
- Consultez les [paramètres de politique de jetons](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization) de votre organisation
2. **Vérifier l'Accès à l'Organisation** :
- Allez dans les paramètres de votre jeton sur GitHub
- Recherchez l'organisation sous "Accès à l'organisation"
- Si nécessaire, cliquez sur "Activer SSO" à côté de votre organisation
- Terminez le processus d'autorisation SSO
#### Authentification OAuth (Mode En Ligne)
Lorsque vous utilisez OpenHands en mode en ligne, le flux OAuth GitHub :
1. Demande les autorisations suivantes :
- Accès au dépôt (lecture/écriture)
- Gestion des workflows
- Accès en lecture à l'organisation
2. Étapes d'authentification :
- Cliquez sur "Se connecter avec GitHub" lorsque vous y êtes invité
- Examinez les autorisations demandées
- Autorisez OpenHands à accéder à votre compte GitHub
- Si vous utilisez une organisation, autorisez l'accès à l'organisation si vous y êtes invité
#### Dépannage
Problèmes courants et solutions :
1. **Jeton Non Reconnu** :
- Assurez-vous que le jeton est correctement enregistré dans les paramètres
- Vérifiez que le jeton n'a pas expiré
- Vérifiez que le jeton a les portées requises
- Essayez de régénérer le jeton
2. **Accès à l'Organisation Refusé** :
- Vérifiez si SSO est requis mais non activé
- Vérifiez l'appartenance à l'organisation
- Contactez l'administrateur de l'organisation si les politiques de jetons bloquent l'accès
3. **Vérifier que le Jeton Fonctionne** :
- L'application affichera une coche verte si le jeton est valide
- Essayez d'accéder à un dépôt pour confirmer les autorisations
- Vérifiez la console du navigateur pour tout message d'erreur
- Utilisez le bouton "Tester la connexion" dans les paramètres s'il est disponible
### Paramètres Avancés
1. Basculez sur `Options Avancées` pour accéder aux paramètres supplémentaires.
2. Utilisez la zone de texte `Modèle Personnalisé` pour saisir manuellement un modèle s'il ne figure pas dans la liste.
3. Spécifiez une `URL de Base` si requis par votre fournisseur LLM.
### Interface Principale
L'interface principale se compose de plusieurs composants clés :
1. **Fenêtre de Chat** : La zone centrale où vous pouvez voir l'historique de conversation avec l'assistant IA.
2. **Zone de Saisie** : Située en bas de l'écran, utilisez-la pour taper vos messages ou commandes à l'IA.
3. **Bouton Envoyer** : Cliquez dessus pour envoyer votre message à l'IA.
4. **Bouton Paramètres** : Une icône d'engrenage qui ouvre la fenêtre modale des paramètres, vous permettant d'ajuster votre configuration à tout moment.
5. **Panneau Espace de Travail** : Affiche les fichiers et dossiers de votre espace de travail, vous permettant de naviguer et de visualiser les fichiers, ou les commandes passées de l'agent ou l'historique de navigation web.
### Interagir avec l'IA
1. Tapez votre question, demande ou description de tâche dans la zone de saisie.
2. Cliquez sur le bouton d'envoi ou appuyez sur Entrée pour soumettre votre message.
3. L'IA traitera votre saisie et fournira une réponse dans la fenêtre de chat.
4. Vous pouvez poursuivre la conversation en posant des questions de suivi ou en fournissant des informations supplémentaires.
## Conseils pour une Utilisation Efficace
1. Soyez précis dans vos demandes pour obtenir les réponses les plus précises et utiles, comme décrit dans les [meilleures pratiques d'incitation](../prompting/prompting-best-practices).
2. Utilisez le panneau d'espace de travail pour explorer la structure de votre projet.
3. Utilisez l'un des modèles recommandés, comme décrit dans la section [LLMs](usage/llms/llms.md).
N'oubliez pas que le mode Interface Graphique d'OpenHands est conçu pour rendre votre interaction avec l'assistant IA aussi fluide et intuitive que possible. N'hésitez pas à explorer ses fonctionnalités pour maximiser votre productivité.

View File

@@ -0,0 +1,61 @@
# Mode sans interface
Vous pouvez exécuter OpenHands avec une seule commande, sans démarrer l'application web.
Cela facilite l'écriture de scripts et l'automatisation des tâches avec OpenHands.
Ceci est différent du [Mode CLI](cli-mode), qui est interactif et mieux adapté au développement actif.
## Avec Python
Pour exécuter OpenHands en mode sans interface avec Python,
[suivez les instructions de configuration de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md),
puis exécutez :
```bash
poetry run python -m openhands.core.main -t "write a bash script that prints hi"
```
Vous devrez vous assurer de définir votre modèle, votre clé API et d'autres paramètres via des variables d'environnement
[ou le fichier `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Avec Docker
1. Définissez `WORKSPACE_BASE` sur le répertoire que vous voulez qu'OpenHands modifie :
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
2. Définissez `LLM_MODEL` sur le modèle que vous voulez utiliser :
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3. Définissez `LLM_API_KEY` sur votre clé API :
```bash
LLM_API_KEY="sk_test_12345"
```
4. Exécutez la commande Docker suivante :
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-e LOG_ALL_EVENTS=true \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
--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.23 \
python -m openhands.core.main -t "write a bash script that prints hi" --no-auto-continue
```

View File

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

@@ -0,0 +1,57 @@
# Installation
## Configuration système requise
* Docker version 26.0.0+ ou Docker Desktop 4.31.0+.
* Vous devez utiliser Linux ou Mac OS.
* Si vous êtes sous Windows, vous devez utiliser [WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
## Démarrer l'application
La façon la plus simple d'exécuter OpenHands est avec Docker.
```bash
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik
docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:0.23
```
Vous pouvez également exécuter OpenHands en mode [headless scriptable](https://docs.all-hands.dev/modules/usage/how-to/headless-mode), en tant que [CLI interactive](https://docs.all-hands.dev/modules/usage/how-to/cli-mode), ou en utilisant l'[Action GitHub OpenHands](https://docs.all-hands.dev/modules/usage/how-to/github-action).
## Configuration
Après avoir exécuté la commande ci-dessus, vous trouverez OpenHands en cours d'exécution à l'adresse [http://localhost:3000](http://localhost:3000).
Au lancement d'OpenHands, vous verrez une fenêtre modale de paramètres. Vous **devez** sélectionner un `Fournisseur LLM` et un `Modèle LLM`, et entrer une `Clé API` correspondante.
Ces paramètres peuvent être modifiés à tout moment en sélectionnant le bouton `Paramètres` (icône d'engrenage) dans l'interface utilisateur.
Si le `Modèle LLM` requis n'existe pas dans la liste, vous pouvez activer les `Options avancées` et l'entrer manuellement avec le préfixe correct
dans la zone de texte `Modèle personnalisé`.
Les `Options avancées` vous permettent également de spécifier une `URL de base` si nécessaire.
<div style={{ display: 'flex', justifyContent: 'center', gap: '20px' }}>
<img src="/img/settings-screenshot.png" alt="settings-modal" width="340" />
<img src="/img/settings-advanced.png" alt="settings-modal" width="335" />
</div>
## Versions
La commande ci-dessus récupère la version stable la plus récente d'OpenHands. Vous avez également d'autres options :
- Pour une version spécifique, utilisez `docker.all-hands.dev/all-hands-ai/openhands:$VERSION`, en remplaçant $VERSION par le numéro de version.
- Nous utilisons semver et publions des tags majeurs, mineurs et de patch. Ainsi, `0.9` pointera automatiquement vers la dernière version `0.9.x`, et `0` pointera vers la dernière version `0.x.x`.
- Pour la version de développement la plus à jour, vous pouvez utiliser `docker.all-hands.dev/all-hands-ai/openhands:main`. Cette version est instable et n'est recommandée qu'à des fins de test ou de développement.
Vous pouvez choisir le tag qui convient le mieux à vos besoins en fonction des exigences de stabilité et des fonctionnalités souhaitées.
Pour le workflow de développement, consultez [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Vous rencontrez des problèmes ? Consultez notre [Guide de dépannage](https://docs.all-hands.dev/modules/usage/troubleshooting).

View File

@@ -0,0 +1,109 @@
---
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-2ypg5jweb-d~6hObZDbXi_HEL8PDrbHg">
<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/modules/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

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

View File

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

@@ -0,0 +1,106 @@
# Configurations LLM personnalisées
OpenHands permet de définir plusieurs configurations LLM nommées dans votre fichier `config.toml`. Cette fonctionnalité vous permet d'utiliser différentes configurations LLM pour différents usages, comme utiliser un modèle moins coûteux pour les tâches qui ne nécessitent pas de réponses de haute qualité, ou utiliser différents modèles avec différents paramètres pour des agents spécifiques.
## 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 = "votre-clé-api"
temperature = 0.0
# Configuration LLM personnalisée pour un modèle moins coûteux
[llm.gpt3]
model = "gpt-3.5-turbo"
api_key = "votre-clé-api"
temperature = 0.2
# Une autre configuration personnalisée avec des paramètres différents
[llm.haute-creativite]
model = "gpt-4"
api_key = "votre-clé-api"
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 coûteuse pour cet agent
llm_config = 'gpt3'
[agent.CodeWriterAgent]
# Utiliser la configuration haute créativité pour cet agent
llm_config = 'haute-creativite'
```
### 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 jetons (`max_input_tokens`, `max_output_tokens`)
- Et toutes les autres options de configuration LLM
Pour une liste complète des options disponibles, consultez la section Configuration LLM dans la documentation des [Options de configuration](../configuration-options).
## Cas d'utilisation
Les configurations LLM personnalisées sont particulièrement utiles dans plusieurs scénarios :
- **Optimisation des coûts** : Utiliser des modèles moins coûteux pour les tâches qui ne nécessitent pas de réponses de haute qualité, comme l'exploration de dépôt ou les opérations simples sur les fichiers.
- **Réglage spécifique aux tâches** : Configurer différentes valeurs de température et de top_p pour les tâches qui nécessitent différents niveaux de créativité ou de déterminisme.
- **Différents fournisseurs** : Utiliser différents fournisseurs LLM ou points d'accès API pour différentes tâches.
- **Tests et développement** : Basculer facilement entre différentes configurations de modèles pendant le développement et les tests.
## Exemple : Optimisation des coûts
Un exemple pratique d'utilisation des configurations LLM personnalisées pour optimiser les coûts :
```toml
# Configuration par défaut utilisant GPT-4 pour des réponses de haute qualité
[llm]
model = "gpt-4"
api_key = "votre-clé-api"
temperature = 0.0
# Configuration moins coûteuse pour l'exploration de dépôt
[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ôt utilise un modèle moins coûteux car il s'agit principalement de comprendre et de naviguer dans le code
- La génération de code utilise GPT-4 avec une limite de jetons plus élevée pour générer des blocs de code plus importants
- La configuration par défaut reste disponible pour les autres tâches
:::note
Les configurations LLM personnalisées ne sont disponibles que lors de l'utilisation d'OpenHands en mode développement, via `main.py` ou `cli.py`. Lors de l'exécution via `docker run`, veuillez utiliser les options de configuration standard.
:::

View File

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

View File

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

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

View File

@@ -0,0 +1,22 @@
# 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`
* `Custom Model` au préfixe `litellm_proxy/` + le modèle que vous utiliserez (par exemple, `litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`)
* `Base URL` à l'URL de votre proxy LiteLLM (par exemple, `https://your-litellm-proxy.com`)
* `API Key` à votre clé API du proxy LiteLLM
## Modèles pris en charge
Les modèles pris en charge dépendent de la configuration de votre proxy LiteLLM. OpenHands prend en charge tous les modèles que votre proxy LiteLLM est configuré pour gérer.
Reportez-vous à la configuration de votre proxy LiteLLM pour obtenir la liste des modèles disponibles et leurs noms.

View File

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

View File

@@ -0,0 +1,193 @@
# LLM local avec Ollama
:::warning
Lors de l'utilisation d'un LLM local, OpenHands peut avoir des fonctionnalités limitées.
:::
Assurez-vous que le serveur Ollama est opérationnel.
Pour des instructions détaillées sur le démarrage, référez-vous à [ici](https://github.com/ollama/ollama).
Ce guide suppose que vous avez démarré ollama avec `ollama serve`. Si vous exécutez ollama différemment (par exemple dans docker), les instructions peuvent nécessiter des modifications. Veuillez noter que si vous utilisez WSL, la configuration par défaut d'ollama bloque les requêtes provenant des conteneurs docker. Voir [ici](#configuring-ollama-service-wsl-fr).
## Récupérer les 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`. Les modèles plus gros auront généralement de meilleures performances.
```bash
ollama pull codellama:7b
```
Vous pouvez vérifier quels modèles vous avez téléchargés comme ceci :
```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
```
## Exécuter OpenHands avec Docker
### Démarrer OpenHands
Utilisez les instructions [ici](../getting-started) pour démarrer OpenHands en utilisant Docker.
Mais lorsque vous exécutez `docker run`, vous devrez ajouter quelques arguments supplémentaires :
```bash
docker run # ...
--add-host host.docker.internal:host-gateway \
-e LLM_OLLAMA_BASE_URL="http://host.docker.internal:11434" \
# ...
```
LLM_OLLAMA_BASE_URL est optionnel. Si vous le définissez, il sera utilisé pour afficher
les modèles installés disponibles dans l'interface utilisateur.
### Configurer l'application Web
Lors de l'exécution d'`openhands`, vous devrez définir les éléments suivants dans l'interface utilisateur d'OpenHands via les paramètres :
- le modèle à "ollama/&lt;nom-du-modèle&gt;"
- l'URL de base à `http://host.docker.internal:11434`
- la clé API est optionnelle, vous pouvez utiliser n'importe quelle chaîne, comme `ollama`.
## Exécuter OpenHands en mode développement
### Compiler à partir du code source
Utilisez les instructions dans [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) pour compiler OpenHands.
Assurez-vous que `config.toml` est présent en exécutant `make setup-config` qui en créera un pour vous. Dans `config.toml`, entrez ce qui suit :
```
[core]
workspace_base="./workspace"
[llm]
embedding_model="local"
ollama_base_url="http://localhost:11434"
```
Terminé ! Vous pouvez maintenant démarrer OpenHands avec : `make run`. Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
### Configurer l'application Web
Dans l'interface utilisateur d'OpenHands, cliquez sur la roue des paramètres dans le coin inférieur gauche.
Ensuite, dans le champ `Model`, entrez `ollama/codellama:7b`, ou le nom du modèle que vous avez récupéré précédemment.
S'il n'apparaît pas dans la liste déroulante, activez `Advanced Settings` et tapez-le. Veuillez noter : vous avez besoin du nom du modèle tel qu'il est listé par `ollama list`, avec le préfixe `ollama/`.
Dans le champ API Key, entrez `ollama` ou n'importe quelle valeur, puisque vous n'avez pas besoin d'une clé particulière.
Dans le champ Base URL, entrez `http://localhost:11434`.
Et maintenant vous êtes prêt à démarrer !
## Configurer le service ollama (WSL) {#configuring-ollama-service-wsl-fr}
La configuration par défaut d'ollama dans WSL ne sert que localhost. Cela signifie que vous ne pouvez pas y accéder depuis un conteneur docker. Par ex. cela ne fonctionnera pas avec OpenHands. Testons d'abord qu'ollama fonctionne correctement.
```bash
ollama list # obtenir la liste des modèles installés
curl http://localhost:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
#ex. curl http://localhost:11434/api/generate -d '{"model":"codellama:7b","prompt":"hi"}'
#ex. curl http://localhost:11434/api/generate -d '{"model":"codellama","prompt":"hi"}' #le tag est optionnel s'il n'y en a qu'un
```
Une fois cela fait, testez qu'il autorise les requêtes "extérieures", comme celles provenant d'un conteneur docker.
```bash
docker ps # obtenir la liste des conteneurs docker en cours d'exécution, pour un test plus précis choisissez le conteneur sandbox OpenHands.
docker exec [ID CONTENEUR] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
#ex. docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## Résoudre le problème
Maintenant, faisons en sorte que cela fonctionne. Modifiez /etc/systemd/system/ollama.service avec des privilèges sudo. (Le chemin peut varier selon la distribution Linux)
```bash
sudo vi /etc/systemd/system/ollama.service
```
ou
```bash
sudo nano /etc/systemd/system/ollama.service
```
Dans le bloc [Service], ajoutez ces lignes
```
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"
```
Ensuite, sauvegardez, rechargez la configuration et redémarrez le service.
```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```
Enfin, testez qu'ollama est accessible depuis le conteneur
```bash
ollama list # obtenir la liste des modèles installés
docker ps # obtenir la liste des conteneurs docker en cours d'exécution, pour un test plus précis choisissez le conteneur sandbox OpenHands.
docker exec [ID CONTENEUR] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NOM]","prompt":"hi"}'
```
# LLM local avec LM Studio
Étapes pour configurer LM Studio :
1. Ouvrez LM Studio
2. Allez dans l'onglet Serveur local.
3. Cliquez sur le bouton "Démarrer le serveur".
4. Sélectionnez le modèle que vous souhaitez utiliser dans la liste déroulante.
Définissez les configurations suivantes :
```bash
LLM_MODEL="openai/lmstudio"
LLM_BASE_URL="http://localhost:1234/v1"
CUSTOM_LLM_PROVIDER="openai"
```
### Docker
```bash
docker run # ...
-e LLM_MODEL="openai/lmstudio" \
-e LLM_BASE_URL="http://host.docker.internal:1234/v1" \
-e CUSTOM_LLM_PROVIDER="openai" \
# ...
```
Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
Dans l'environnement de développement, vous pouvez définir les configurations suivantes dans le fichier `config.toml` :
```
[core]
workspace_base="./workspace"
[llm]
model="openai/lmstudio"
base_url="http://localhost:1234/v1"
custom_llm_provider="openai"
```
Terminé ! Vous pouvez maintenant démarrer OpenHands avec : `make run` sans Docker. Vous devriez maintenant pouvoir vous connecter à `http://localhost:3000/`
# Note
Pour WSL, exécutez les commandes suivantes dans cmd pour configurer le mode réseau en miroir :
```
python -c "print('[wsl2]\nnetworkingMode=mirrored',file=open(r'%UserProfile%\.wslconfig','w'))"
wsl --shutdown
```

View File

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

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

View File

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

View File

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

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

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

@@ -0,0 +1,43 @@
# Meilleures pratiques pour les prompts
Lorsque vous travaillez avec le développeur de logiciels OpenHands AI, il est crucial de fournir des prompts clairs et efficaces. Ce guide décrit les meilleures pratiques pour créer des prompts qui produiront les réponses les plus précises et les plus utiles.
## 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 [Démarrer avec OpenHands](../getting-started) pour plus d'exemples de prompts utiles.

View File

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

View File

@@ -0,0 +1,46 @@
# 🚧 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.
:::
### Échec du lancement du client docker
**Description**
Lors de l'exécution d'OpenHands, l'erreur suivante est observée :
```
Launch docker client failed. Please make sure you have installed docker and started docker desktop/daemon.
```
**Résolution**
Essayez ces étapes dans l'ordre :
* Vérifiez que `docker` est en cours d'exécution sur votre système. Vous devriez pouvoir exécuter `docker ps` dans le terminal avec succès.
* Si vous utilisez Docker Desktop, assurez-vous que `Settings > Advanced > Allow the default Docker socket to be used` est activé.
* Selon votre configuration, vous devrez peut-être activer `Settings > Resources > Network > Enable host networking` dans Docker Desktop.
* Réinstallez Docker Desktop.
---
# Spécifique au flux de travail de développement
### Erreur lors de la construction de l'image docker du runtime
**Description**
Les tentatives de démarrage d'une nouvelle session échouent et des erreurs contenant des termes comme les suivants apparaissent dans les logs :
```
debian-security bookworm-security
InRelease At least one invalid signature was encountered.
```
Cela semble se produire lorsque le hash d'une bibliothèque externe existante change et que votre instance docker locale a
mis en cache une version précédente. Pour contourner ce problème, veuillez essayer ce qui suit :
* Arrêtez tous les conteneurs dont le nom a le préfixe `openhands-runtime-` :
`docker ps --filter name=openhands-runtime- --filter status=running -aq | xargs docker stop`
* Supprimez tous les conteneurs dont le nom a le préfixe `openhands-runtime-` :
`docker rmi $(docker images --filter name=openhands-runtime- -q --no-trunc)`
* Arrêtez et supprimez tous les conteneurs / images dont le nom a le préfixe `openhands-runtime-`
* Nettoyez les conteneurs / images : `docker container prune -f && docker image prune -f`

View File

@@ -0,0 +1,72 @@
# ⬆️ 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

@@ -0,0 +1,26 @@
{
"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"
}
}

406
docs/i18n/zh-Hans/code.json Normal file
View File

@@ -0,0 +1,406 @@
{
"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} 上提交一个 bug。如果遇到安装困难或有其他疑问可以访问 {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是您创建的一个具有对OpenHands仓库写权限的GitHub令牌。如果您的写入权限不足请将其更改为",
"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": "{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": "{nPosts} 含有标签「{tagName}」",
"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": "{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": "{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": "{nDocsTagged}「{tagName}」",
"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": "最后{byUser}{atDate}更新",
"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": "请联系原始链接来源网站的所有者,并告知他们链接已损坏。",
"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": "阅读需 {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"
}
}

View File

@@ -0,0 +1,14 @@
{
"title": {
"message": "博客",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "博客",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "最近文章",
"description": "The label for the left sidebar"
}
}

View File

@@ -0,0 +1,18 @@
{
"version.label": {
"message": "Next",
"description": "The label for version current"
},
"sidebar.docsSidebar.category.🤖 LLM 支持": {
"message": "🤖 LLM 支持",
"description": "The label for category 🤖 LLM 支持 in sidebar docsSidebar"
},
"sidebar.docsSidebar.category.🚧 故障排除": {
"message": "🚧 故障排除",
"description": "The label for category 🚧 故障排除 in sidebar docsSidebar"
},
"sidebar.apiSidebar.category.Backend": {
"message": "Backend",
"description": "The label for category Backend in sidebar apiSidebar"
}
}

View File

@@ -0,0 +1,3 @@
# Python 文档
部署后文档将显示在此处。

View File

@@ -0,0 +1,5 @@
{
"items": ["python/python"],
"label": "后端",
"type": "category"
}

View File

@@ -0,0 +1,26 @@
# 关于 OpenHands
## 研究策略
使用 LLM 实现生产级应用的完全复制是一项复杂的工作。我们的策略包括:
1. **核心技术研究:** 专注于基础研究,以理解和改进代码生成和处理的技术方面
2. **专业能力:** 通过数据整理、训练方法等提高核心组件的效率
3. **任务规划:** 开发 bug 检测、代码库管理和优化的能力
4. **评估:** 建立全面的评估指标,以更好地理解和改进我们的模型
## 默认 Agent
我们当前的默认 Agent 是 [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

@@ -0,0 +1,23 @@
# 🧠 主代理和能力
## 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

@@ -0,0 +1,49 @@
---
sidebar_position: 4
---
# 🏛️ 系统架构概览
这是系统架构的高层概览。系统分为两个主要组件:前端和后端。前端负责处理用户交互并显示结果。后端负责处理业务逻辑并执行代理。
![system_architecture.svg](/img/system_architecture.svg)
此概览简化显示了主要组件及其交互。有关后端架构的更详细视图,请参见[后端架构](#backend-architecture-zh-Hans)部分。
# 后端架构 {#backend-architecture-zh-Hans}
_**免责声明**后端架构正在进行中可能会有所变化。下图显示了基于图表页脚中的提交内容的当前后端架构。_
![backend_architecture.svg](/img/backend_architecture.svg)
<details>
<summary>更新此图表</summary>
<div>
后端架构图的生成部分是自动化的。
图表是使用 py2puml 工具从代码中的类型提示生成的。
然后人工审核、调整并导出为 PNG 和 SVG。
## 前提条件
- 能运行 python 环境,其中 openhands 可以执行(根据存储库根目录中的 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

@@ -0,0 +1,54 @@
以下是翻译后的内容:
# 🏛️ 系统架构
<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>
这是系统架构的高层次概述。系统分为两个主要组件:前端和后端。前端负责处理用户交互并显示结果。后端负责处理业务逻辑并执行代理。
# 前端架构 {#frontend-architecture-zh}
![system_architecture.svg](/img/system_architecture.svg)
这个概述经过简化,只显示了主要组件及其交互。有关后端架构的更详细视图,请参阅下面的后端架构部分。
# 后端架构 {#backend-architecture-zh}
_**免责声明**:后端架构正在进行中,可能会发生变化。下图显示了基于图表页脚中显示的提交的后端当前架构。_
![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

@@ -0,0 +1,131 @@
以下是翻译后的内容:
# 📦 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[Action 执行器]
D -->|初始化| E[浏览器]
D -->|初始化| F[Bash Shell]
D -->|初始化| G[插件]
G -->|初始化| L[Jupyter 服务器]
B -->|生成| H[代理]
B -->|生成| I[EventStream]
I <--->|通过 REST API
执行 Action 获取 Observation
| D
H -->|生成 Action| I
I -->|获取 Observation| H
subgraph "Docker 容器"
D
E
F
G
L
end
```
1. 用户输入:用户提供自定义基础 Docker 镜像
2. 镜像构建:OpenHands 基于用户提供的镜像构建新的 Docker 镜像("OH 运行时镜像")。这个新镜像包含 OpenHands 特定的代码,主要是"运行时客户端"
3. 容器启动:当 OpenHands 启动时,它使用 OH 运行时镜像启动一个 Docker 容器
4. Action 执行服务器初始化:Action 执行服务器在容器内初始化一个 `ActionExecutor`,设置必要的组件,如 bash shell,并加载任何指定的插件
5. 通信:OpenHands 后端(`openhands/runtime/impl/eventstream/eventstream_runtime.py`)通过 RESTful API 与 Action 执行服务器通信,发送 Action 并接收 Observation
6. Action 执行:运行时客户端从后端接收 Action,在沙盒环境中执行它们,并将 Observation 发送回去
7. Observation 返回:Action 执行服务器将执行结果作为 Observation 发送回 OpenHands 后端
客户端的作用:
- 它充当 OpenHands 后端和沙盒环境之间的中介
- 它在容器内安全地执行各种类型的 Action(shell 命令、文件操作、Python 代码等)
- 它管理沙盒环境的状态,包括当前工作目录和加载的插件
- 它格式化 Observation 并将其返回给后端,确保处理结果的接口一致
## OpenHands 如何构建和维护 OH 运行时镜像
OpenHands 构建和管理运行时镜像的方法确保了在为生产和开发环境创建和维护 Docker 镜像时的效率、一致性和灵活性。
如果你对更多细节感兴趣,可以查看[相关代码](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py)。
### 镜像标签系统
OpenHands 为其运行时镜像使用三标签系统,以平衡可重现性和灵活性。
标签可以是以下 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`),除了最后一个复制当前源代码的操作。新镜像仅使用**源码**标签。
- **还行的重建**:如果**源码**和**锁定**标签都不存在,将基于**版本**标签镜像构建镜像。
在版本标签镜像中,大多数依赖项应该已经安装,从而节省时间。
- **最慢重建**:如果三个标签都不存在,则基于基础镜像构建全新的镜像
(这是一个较慢的操作)。这个新镜像使用**源码**、**锁定**和**版本**标签。
这种标记方法允许 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

@@ -0,0 +1,384 @@
# 配置选项
本指南详细介绍了 OpenHands 的所有可用配置选项,帮助您自定义其行为并与其他服务集成。
:::note
如果您在 [GUI 模式](https://docs.all-hands.dev/modules/usage/how-to/gui-mode) 下运行,Settings UI 中的可用设置将始终优先。
:::
---
# 目录
1. [核心配置](#核心配置)
- [API Keys](#api-keys)
- [工作区](#工作区)
- [调试和日志记录](#调试和日志记录)
- [会话管理](#会话管理)
- [轨迹](#轨迹)
- [文件存储](#文件存储)
- [任务管理](#任务管理)
- [沙箱配置](#沙箱配置)
- [其他](#其他)
2. [LLM 配置](#llm-配置)
- [AWS 凭证](#aws-凭证)
- [API 配置](#api-配置)
- [自定义 LLM Provider](#自定义-llm-provider)
- [Embeddings](#embeddings)
- [消息处理](#消息处理)
- [模型选择](#模型选择)
- [重试](#重试)
- [高级选项](#高级选项)
3. [Agent 配置](#agent-配置)
- [Microagent 配置](#microagent-配置)
- [内存配置](#内存配置)
- [LLM 配置](#llm-配置-2)
- [ActionSpace 配置](#actionspace-配置)
- [Microagent 使用](#microagent-使用)
4. [沙箱配置](#沙箱配置-2)
- [执行](#执行)
- [容器镜像](#容器镜像)
- [网络](#网络)
- [Linting 和插件](#linting-和插件)
- [依赖和环境](#依赖和环境)
- [评估](#评估)
5. [安全配置](#安全配置)
- [确认模式](#确认模式)
- [安全分析器](#安全分析器)
---
## 核心配置
核心配置选项在 `config.toml` 文件的 `[core]` 部分中定义。
**API Keys**
- `e2b_api_key`
- 类型: `str`
- 默认值: `""`
- 描述: E2B 的 API key
- `modal_api_token_id`
- 类型: `str`
- 默认值: `""`
- 描述: Modal 的 API token ID
- `modal_api_token_secret`
- 类型: `str`
- 默认值: `""`
- 描述: Modal 的 API token secret
**工作区**
- `workspace_base`
- 类型: `str`
- 默认值: `"./workspace"`
- 描述: 工作区的基础路径
- `cache_dir`
- 类型: `str`
- 默认值: `"/tmp/cache"`
- 描述: 缓存目录路径
**调试和日志记录**
- `debug`
- 类型: `bool`
- 默认值: `false`
- 描述: 启用调试
- `disable_color`
- 类型: `bool`
- 默认值: `false`
- 描述: 禁用终端输出中的颜色
**轨迹**
- `save_trajectory_path`
- 类型: `str`
- 默认值: `"./trajectories"`
- 描述: 存储轨迹的路径(可以是文件夹或文件)。如果是文件夹,轨迹将保存在该文件夹中以会话 ID 命名的 .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`
- 描述: 上传文件的最大文件大小,以 MB 为单位
- `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`
- 描述: 最大迭代次数
**沙箱配置**
- `workspace_mount_path_in_sandbox`
- 类型: `str`
- 默认值: `"/workspace"`
- 描述: 在沙箱中挂载工作区的路径
- `workspace_mount_path`
- 类型: `str`
- 默认值: `""`
- 描述: 挂载工作区的路径
- `workspace_mount_rewrite`
- 类型: `str`
- 默认值: `""`
- 描述: 重写工作区挂载路径的路径。通常可以忽略这个,它指的是在另一个容器内运行的特殊情况。
**其他**
- `run_as_openhands`
- 类型: `bool`
- 默认值: `true`
- 描述: 以 OpenHands 身份运行
- `runtime`
- 类型: `str`
- 默认值: `"docker"`
- 描述: 运行时环境
- `default_agent`
- 类型: `str`
- 默认值: `"CodeActAgent"`
- 描述: 默认 agent 的名称
- `jwt_secret`
- 类型: `str`
- 默认值: `uuid.uuid4().hex`
- 描述: 用于身份验证的 JWT 密钥。请将其设置为您自己的值。
## LLM 配置
LLM(大语言模型)配置选项在 `config.toml` 文件的 `[llm]` 部分中定义。
要在 docker 命令中使用这些选项,请传入 `-e LLM_<option>`。例如: `-e LLM_NUM_RETRIES`
**AWS 凭证**
- `aws_access_key_id`
- 类型: `str`
- 默认值: `""`
- 描述: AWS access key ID
- `aws_region_name`
- 类型: `str`
- 默认值: `""`
- 描述: AWS region name
- `aws_secret_access_key`
- 类型: `str`
- 默认值: `""`
- 描述: AWS secret access key
**API 配置**
- `api_key`
- 类型: `str`
- 默认值: `None`
- 描述: 要使用的 API key
- `base_url`
- 类型: `str`
- 默认值: `""`
- 描述: API 基础 URL
- `api_version`
- 类型: `str`
- 默认值: `""`
- 描述: API 版本
- `input_cost_per_token`
- 类型: `float`
- 默认值: `0.0`
- 描述: 每个输入 token 的成本
- `output_cost_per_token`
- 类型: `float`
- 默认值: `0.0`
- 描述: 每个输出 token 的成本
**自定义 LLM Provider**
- `custom_llm_provider`
- 类型: `str`
- 默认值: `""`
- 描述: 自定义 LLM provider
**Embeddings**
- `embedding_base_url`
- 类型: `str`
- 默认值: `""`
- 描述: Embedding API 基础 URL
- `embedding_deployment_name`
- 类型: `str`
- 默认值: `""`
- 描述: Embedding 部署名称
- `embedding_model`
- 类型: `str`
- 默认值: `"local"`
- 描述: 要使用的 Embedding 模型
**消息处理**
- `max_message_chars`
- 类型: `int`
- 默认值: `30000`
- 描述: 包含在提示 LLM 的事件内容中的最大字符数(近似值)。较大的观察结果会被截断。
- `max_input_tokens`
- 类型: `int`
- 默认值: `0`
- 描述: 最大输入 token 数
- `max_output_tokens`
- 类型: `int`
- 默认值: `0`
- 描述: 最大输出 token 数
**模型选择**
- `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 的 temperature
- `timeout`
- 类型: `int`
- 默认值: `0`
- 描述: API 的超时时间
- `top_p`
- 类型: `float`
- 默认值: `1.0`
- 描述: API 的 top p
- `disable_vision`
- 类型: `bool`
- 默认值: `None`
- 描述: 如果模型支持视觉,此选项允许禁用图像处理(对于降低成本很有用)
## Agent 配置
Agent 配置选项在 `config.toml` 文件的 `[agent]``[agent.<agent_name>]` 部分中定义。
**Microagent 配置**
- `micro_agent_name`
- 类型: `str`
- 默认值: `""`
- 描述: 用于此 agent 的 micro agent 名称
**内存配置**
- `memory_enabled`
- 类型: `bool`
- 默认值: `false`
- 描述: 是否启用长期记忆(embeddings)
- `memory_max_threads`
- 类型: `int`
- 默认值: `3`
- 描述: 同时为 embeddings 编制索引的最大线程数
**LLM 配置**
- `llm_config`
- 类型: `str`
- 默认值: `'your-llm-config-group'`
- 描述: 要使用的 LLM 配置的名称
**ActionSpace 配置**
- `function_calling`
- 类型: `bool`
- 默认值: `true`
- 描述: 是否启用函数调用
- `codeact_enable_browsing`
- 类型: `bool`
- 默认值: `false`
- 描述: 是否在 action space 中启用浏览代理(仅适用于函数调用)
- `codeact_enable_llm_editor`
- 类型: `bool`
- 默认值: `false`
- 描述: 是否在 action space 中启用 LLM 编辑器(仅适用于函数调用)
- `codeact_enable_jupyter`
- 类型: `bool`
- 默认值: `false`
- 描述: 是否在 action space 中启用 Jupyter
**Microagent 使用**
- `enable_prompt_extensions`
- 类型: `bool`
- 默认值: `true`
- 描述: 是否使用 microagents
- `disabled_microagents`
- 类型: `list of str`
- 默认值: `None`
- 描述: 要禁用

View File

@@ -0,0 +1,98 @@
# 💿 如何创建自定义 Docker 沙箱
默认的 OpenHands 沙箱包含一个[最小化 ubuntu 配置](https://github.com/All-Hands-AI/OpenHands/blob/main/containers/sandbox/Dockerfile)。您的应用场景可能需要在默认状态下安装额外的软件。本指南将教您如何通过使用自定义 Docker 映像来实现这一目标。
目前提供两种实现方案:
1. 从 Docker Hub 拉取已有镜像。例如,如果您想安装 `nodejs` ,您可以通过使用 `node:20` 镜像来实现。
2. 创建并使用您自定义 Docker 镜像。
若选择第一种方案,您可以直接略过 `Create Your Docker Image` 部分。
为了获得功能更丰富的环境,您可能想要考虑使用预构建的镜像,比如 [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs),这个镜像预装了 Python 和 Node.js同时还包含了许多其他有用的工具和库比如
- Node.js: 22.x
- npm: 10.x
- yarn: stable
- Python: latest
- pip: latest
- pipenv: latest
- poetry: latest
- uv: latest
## 环境设置
确保您能够首先通过 [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) 运行 OpenHands。
## 创建您的 Docker 映像
接下来,您可以开始创建一个自定义的 Docker 映像,该映像必须是基于 Debian 或 Ubuntu 的。例如,如果我们希望 OpenHands 能够访问 `node` 可执行文件,我们可以使用以下 `Dockerfile`:
```bash
# 从最新版 ubuntu 开始
FROM ubuntu:latest
# 运行必要的更新
RUN apt-get update && apt-get install
# 安装 node
RUN apt-get install -y nodejs
```
然后命名并构建您选择的映像例如“custom_image”。为此可以创建一个文件夹并将 `Dockerfile` 放入其中,并在该文件夹内运行以下命令:
```bash
docker build -t custom_image .
```
这将生成一个名为 ```custom_image``` 的新映像,并使其可用于 Docker 服务引擎。
> 注意在本文档描述的配置中OpenHands 将在沙箱内部以“openhands”用户身份运行。因此通过 Dockerfile 安装的所有包应可供系统上的所有用户使用,而不仅仅是 root 用户。
> `Dockerfile`中,使用 `apt-get` 安装的 node 是为所有用户安装的。
## 在 config.toml 文件中指定自定义映像
在 OpenHands 的配置通过顶层的 `config.toml` 文件发生。在 OpenHands 目录下创建一个 ```config.toml``` 文件,并输入以下内容:
```
[core]
workspace_base="./workspace"
run_as_openhands=true
sandbox_base_container_image="custom_image"
```
对于 `sandbox_base_container_image` 的值, 您可以选择以下任意一项:
1. 在上一步中您构建的自定义镜像的名称(例如,`“custom_image”`
2. 从 Docker Hub 拉取的镜像(例如,`“node:20”`,如果你需要一个预装 `Node.js` 的沙箱环境)
## 运行
在顶层目录下通过执行 ```make run``` 运行 OpenHands。
导航至 ```localhost:3001``` 并检查所需依赖是否可用。
在上述示例的情况下,终端中运行 `node -v` 会输出 `v20.15.0`。
恭喜您!
## 技术解释
请参考[运行时文档中自定义 Docker 镜像的章节](https://docs.all-hands.dev/modules/usage/architecture/runtime#advanced-how-openhands-builds-and-maintains-od-runtime-images)获取更详细的解释。
## 故障排除 / 错误
### 错误:```useradd: UID 1000 is not unique```
如果在控制台输出中看到此错误,说明 OpenHands 尝试在沙箱中以 UID 1000 创建 openhands 用户,但该 UID 已经被映像中的其他部分使用(不知何故)。要解决这个问题,请更改 config.toml 文件中的 sandbox_user_id 字段为不同的值:
```
[core]
workspace_base="./workspace"
run_as_openhands=true
sandbox_base_container_image="custom_image"
sandbox_user_id="1001"
```
### 端口使用错误
如果您遇到端口被占用或不可用的错误提示,可以尝试先用`docker ps`命令列出所有运行中的 Docker 容器,然后使用`docker rm`命令删除相关容器,最后再重新执行```make run```命令。

View File

@@ -0,0 +1,39 @@
# ✅ 提供反馈
在使用 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>
## 📜 数据使用和隐私
### 数据共享设置
在提交数据时,您可以选择公开或私下提交。
* **公开**数据将在 MIT 许可下发布,与 OpenHands 本身一样,社区可以使用这些数据来训练和测试模型。显然,您可以公开的反馈对整个社区来说会更有价值,因此当您不处理敏感信息时,我们鼓励您选择这个选项!
* **私有**数据将仅与 OpenHands 团队共享,用于改进 OpenHands。
### 谁收集和存储数据?
数据由 [All Hands AI](https://all-hands.dev) 收集和存储,这是一家由 OpenHands 维护者创立的公司,旨在支持和改进 OpenHands。
### 公开数据将如何发布?
公开数据将在我们达到固定的里程碑时发布,例如 1,000 个公开示例、10,000 个公开示例等。
届时,我们将遵循以下发布流程:
1. 所有提供公开反馈的人都将收到一封电子邮件,描述数据发布情况,并有机会选择退出。
2. 负责数据发布的人员将对数据进行质量控制,删除低质量的反馈,删除提交者的电子邮件地址,并尝试删除任何敏感信息。
3. 数据将通过 github 或 Hugging Face 等常用网站在 MIT 许可下公开发布。
### 如果我想删除我的数据怎么办?
对于 All Hands AI 服务器上的数据,我们很乐意根据要求删除它:
**一条数据:**如果您想删除一条数据,我们将很快添加一种机制,使用您在提交数据时显示在界面上的链接和密码来删除数据。
**所有数据:**如果您想删除所有数据,或者您没有在提交数据时收到的 ID 和密码,请从您最初提交数据时注册的电子邮件地址联系`contact@all-hands.dev`

View File

@@ -0,0 +1,111 @@
# OpenHands 入门指南
您已经[安装了 OpenHands](./installation)并且
[设置了您的 LLM](./installation#setup)。接下来呢?
OpenHands 可以帮助您处理各种工程任务。但这项技术
仍然很新,我们还有很长的路要走,才能拥有无需任何指导就能承担大型、复杂
工程任务的智能体。因此,了解智能体擅长什么,以及
它可能需要什么帮助非常重要。
## Hello World
您可能想尝试的第一件事是一个简单的 "hello world" 示例。
这可能比听起来更复杂!
尝试提示智能体:
> 请编写一个 bash 脚本 hello.sh,打印 "hello world!"
您应该看到,智能体不仅编写了脚本,还设置了正确的
权限并运行脚本以检查输出。
您可以继续提示智能体优化您的代码。这是一个很好的
与智能体合作的方式。从简单开始,然后迭代。
> 请修改 hello.sh,使其接受一个名称作为第一个参数,但默认为 "world"
您还可以使用任何需要的语言,尽管智能体可能需要花一些
时间来设置它的环境!
> 请将 hello.sh 转换为 Ruby 脚本,并运行它
## 从头开始构建
智能体在 "绿地" 任务(不需要
任何关于现有代码库的上下文的任务)方面表现得非常出色,它们可以直接从头开始。
最好从一个简单的任务开始,然后迭代它。最好也要
尽可能具体地说明您想要什么,技术栈应该是什么,等等。
例如,我们可以构建一个 TODO 应用:
> 请在 React 中构建一个基本的 TODO 列表应用。它应该只有前端,所有状态
> 应该保存在 localStorage 中。
一旦骨架搭建好,我们就可以继续迭代应用:
> 请允许为每个任务添加一个可选的截止日期
就像正常开发一样,经常提交和推送代码是很好的做法。
这样,如果智能体偏离轨道,您总是可以恢复到旧的状态。
您可以要求智能体为您提交和推送:
> 请提交更改并将其推送到名为 "feature/due-dates" 的新分支
## 添加新代码
OpenHands 还可以很好地将新代码添加到现有代码库中。
例如,您可以要求 OpenHands 向您的项目添加一个新的 GitHub action
来检查您的代码。OpenHands 可能会查看您的代码库以确定应该使用什么语言,
但随后它可以直接将一个新文件放入 `./github/workflows/lint.yml`
> 请添加一个 GitHub action 来检查此仓库中的代码
某些任务可能需要更多上下文。虽然 OpenHands 可以使用 `ls` 和 `grep`
在您的代码库中搜索,但提前提供上下文可以让它移动得更快、
更准确。而且这会让您花费更少的 token!
> 请修改 ./backend/api/routes.js 以添加一个新路由,返回所有任务的列表
> 请在 ./frontend/components 目录中添加一个新的 React 组件,用于显示 Widget 列表。
> 它应该使用现有的 Widget 组件。
## 重构
OpenHands 在重构现有代码方面表现出色,尤其是在小块中。
您可能不想尝试重新构建整个代码库,但拆分
长文件和函数、重命名变量等往往效果很好。
> 请重命名 ./app.go 中的所有单字母变量
> 请将 widget.php 中的函数 `build_and_deploy_widgets` 拆分为两个函数:`build_widgets` 和 `deploy_widgets`
> 请将 ./api/routes.js 拆分为每个路由的单独文件
## Bug 修复
OpenHands 还可以帮助您跟踪和修复代码中的错误。但是,任何
开发人员都知道,修复错误可能非常棘手,通常 OpenHands 需要更多上下文。
如果您已经诊断出错误,但希望 OpenHands 找出逻辑,这会有所帮助。
> 目前 `/subscribe` 端点中的电子邮件字段拒绝 .io 域名。请修复这个问题。
> ./app.py 中的 `search_widgets` 函数正在执行区分大小写的搜索。请使其不区分大小写。
在使用智能体进行错误修复时,进行测试驱动开发通常很有帮助。
您可以要求智能体编写一个新测试,然后迭代直到修复错误:
> `hello` 函数在空字符串上崩溃。请编写一个测试来重现此错误,然后修复代码以通过测试。
## 更多
OpenHands 能够在几乎任何编码任务上提供帮助。但需要一些练习
才能充分利用它。请记住:
* 保持任务简单
* 尽可能具体
* 提供尽可能多的上下文
* 经常提交和推送
有关如何充分利用 OpenHands 的更多提示,请参阅[提示最佳实践](./prompting/prompting-best-practices)。

View File

@@ -0,0 +1,110 @@
以下是翻译后的内容:
# 命令行模式
OpenHands 可以在交互式命令行模式下运行,允许用户通过命令行启动交互式会话。
这种模式不同于[无头模式](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,请按照以下步骤操作:
1.`WORKSPACE_BASE` 设置为你希望 OpenHands 编辑的目录:
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
2.`LLM_MODEL` 设置为你要使用的模型:
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3.`LLM_API_KEY` 设置为你的 API 密钥:
```bash
LLM_API_KEY="sk_test_12345"
```
4. 运行以下 Docker 命令:
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
--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.23 \
python -m openhands.core.cli
```
该命令将在 Docker 中启动一个交互式会话,你可以在其中输入任务并接收来自 OpenHands 的响应。
## CLI 命令和预期输出示例
以下是一些 CLI 命令及其预期输出的示例:
### 示例 1:简单任务
```bash
How can I help? >> Write a Python script that prints "Hello, World!"
```
预期输出:
```bash
🤖 当然!这是一个打印 "Hello, World!" 的 Python 脚本:
print("Hello, World!")
```
### 示例 2:Bash 命令
```bash
How can I help? >> Create a directory named "test_dir"
```
预期输出:
```bash
🤖 创建一个名为 "test_dir" 的目录:
mkdir test_dir
```
### 示例 3:错误处理
```bash
How can I help? >> Delete a non-existent file
```
预期输出:
```bash
🤖 发生错误。请重试。
```

View File

@@ -0,0 +1,59 @@
# 自定义沙箱
沙箱是代理执行任务的地方。代理不是直接在你的计算机上运行命令(这可能有风险),而是在 Docker 容器内运行。
默认的 OpenHands 沙箱(`python-nodejs:python3.12-nodejs22`,来自 [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs))预装了一些软件包,如 Python 和 Node.js但可能需要默认安装其他软件。
你有两个自定义选项:
1. 使用已有的镜像,其中包含所需的软件。
2. 创建你自己的自定义 Docker 镜像。
如果你选择第一个选项,可以跳过"创建你的 Docker 镜像"部分。
## 创建你的 Docker 镜像
要创建自定义 Docker 镜像,它必须基于 Debian。
例如,如果你想让 OpenHands 安装 `ruby`,创建一个包含以下内容的 `Dockerfile`
```dockerfile
FROM debian:latest
# Install required packages
RUN apt-get update && apt-get install -y ruby
```
将此文件保存在一个文件夹中。然后,通过在终端中导航到该文件夹并运行以下命令来构建你的 Docker 镜像(例如,名为 custom-image
```bash
docker build -t custom-image .
```
这将生成一个名为 `custom-image` 的新镜像,该镜像将在 Docker 中可用。
> 请注意在本文档描述的配置中OpenHands 将以用户 "openhands" 的身份在沙箱内运行,因此通过 docker 文件安装的所有软件包应该对系统上的所有用户可用,而不仅仅是 root。
## 使用开发工作流
### 设置
首先,按照 [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) 中的说明,确保你可以运行 OpenHands。
### 指定基础沙箱镜像
在 OpenHands 目录中的 `config.toml` 文件中,将 `sandbox_base_container_image` 设置为你要使用的镜像。这可以是你已经拉取的镜像或你构建的镜像:
```bash
[core]
...
sandbox_base_container_image="custom-image"
```
### 运行
通过在顶层目录中运行 ```make run``` 来运行 OpenHands。
## 技术解释
请参阅[运行时文档的自定义 docker 镜像部分](https://docs.all-hands.dev/modules/usage/architecture/runtime#advanced-how-openhands-builds-and-maintains-od-runtime-images)以获取更多详细信息。

View File

@@ -0,0 +1,73 @@
以下是翻译后的内容:
# 调试
以下内容旨在作为开发目的下调试 OpenHands 的入门指南。
## 服务器 / VSCode
以下 `launch.json` 将允许调试 agent、controller 和 server 元素,但不包括 sandbox(它运行在 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*: agent
* *l*: LLM 配置 (在 config.toml 中预定义)
* *n*: 会话名称 (例如 eventstream 名称)

View File

@@ -0,0 +1,278 @@
# 评估
本指南概述了如何将您自己的评估基准集成到 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:
# 检查代理是否已尝试与用户对话 3 次,如果是,让代理知道它可以放弃
user_msgs = [
event
for event in state.history
if isinstance(event, MessageAction) and event.source == 'user'
]
if len(user_msgs) >= 2:
# 当代理已尝试 3 次时,让它知道可以放弃
return (
msg
+ 'If you want to give up, run: <execute_bash> exit </execute_bash>.\n'
)
return msg
```
此函数执行以下操作:
1. 提供一条标准消息,鼓励代理继续工作
2. 检查代理尝试与用户通信的次数
3. 如果代理已多次尝试,它会提供放弃的选项
通过使用此函数,您可以确保在多次评估运行中保持一致的行为,并防止代理在等待人工输入时陷入困境。

View File

@@ -0,0 +1,49 @@
# 在 OpenHands 仓库中使用 GitHub Action
本指南解释了如何在 OpenHands 仓库内以及你自己的项目中使用 OpenHands GitHub Action。
## 在 OpenHands 仓库中使用 Action
要在仓库中使用 OpenHands GitHub Action你可以
1. 在仓库中创建一个 issue。
2. 为 issue 添加 `fix-me` 标签,或在 issue 中留下以 `@openhands-agent` 开头的评论。
该 action 将自动触发并尝试解决该 issue。
## 在新仓库中安装 Action
要在你自己的仓库中安装 OpenHands GitHub Action请按照 [OpenHands Resolver 的 README](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/README.md) 进行操作。
## 使用技巧
### 迭代解决
1. 在仓库中创建一个 issue。
2. 为 issue 添加 `fix-me` 标签,或留下以 `@openhands-agent` 开头的评论。
3. 通过检查 pull request 来审查解决 issue 的尝试。
4. 通过一般评论、审查评论或内联线程评论提供反馈。
5. 为 pull request 添加 `fix-me` 标签,或通过以 `@openhands-agent` 开头来解决特定的评论。
### 标签与宏
- 标签(`fix-me`):请求 OpenHands 解决**整个** issue 或 pull request。
- 宏(`@openhands-agent`):请求 OpenHands 仅考虑 issue/pull request 描述和**特定评论**。
## 高级设置
### 添加自定义仓库设置
你可以按照 [resolver 的 README](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` | Variable | 设置与 OpenHands 一起使用的 LLM | `LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"` |
| `OPENHANDS_MAX_ITER` | Variable | 设置代理迭代的最大限制 | `OPENHANDS_MAX_ITER=10` |
| `OPENHANDS_MACRO` | Variable | 自定义用于调用 resolver 的默认宏 | `OPENHANDS_MACRO=@resolveit` |
| `OPENHANDS_BASE_CONTAINER_IMAGE` | Variable | 自定义沙箱 ([了解更多](https://docs.all-hands.dev/modules/usage/how-to/custom-sandbox-guide)) | `OPENHANDS_BASE_CONTAINER_IMAGE="custom_image"` |

View File

@@ -0,0 +1,125 @@
# GUI 模式
## 简介
OpenHands 提供了一个用户友好的图形用户界面GUI模式用于与 AI 助手交互。这种模式提供了一种直观的方式来设置环境、管理设置和与 AI 通信。
## 安装和设置
1. 按照[安装](../installation)指南中的说明安装 OpenHands。
2. 运行命令后,通过 [http://localhost:3000](http://localhost:3000) 访问 OpenHands。
## 与 GUI 交互
### 初始设置
1. 首次启动时,您将看到一个设置模态框。
2. 从下拉菜单中选择 `LLM Provider``LLM Model`
3. 输入所选提供商对应的 `API Key`
4. 点击"保存"应用设置。
### GitHub Token 设置
如果可用OpenHands 会自动将 `GITHUB_TOKEN` 导出到 shell 环境中。这可以通过两种方式实现:
1. **本地OSS**:用户直接输入他们的 GitHub token
2. **在线SaaS**:通过 GitHub OAuth 身份验证获取 token
#### 设置本地 GitHub Token
1. **生成个人访问令牌PAT**
- 转到 GitHub 设置 > 开发者设置 > 个人访问令牌 > 令牌(经典)
- 点击"生成新令牌(经典)"
- 所需范围:
- `repo`(完全控制私有仓库)
- `workflow`(更新 GitHub Action 工作流)
- `read:org`(读取组织数据)
2. **在 OpenHands 中输入令牌**
- 点击右上角的设置按钮(齿轮图标)
- 导航到"GitHub"部分
- 将令牌粘贴到"GitHub Token"字段中
- 点击"保存"应用更改
#### 组织令牌策略
如果您使用组织仓库,可能需要额外的设置:
1. **检查组织要求**
- 组织管理员可能会强制执行特定的令牌策略
- 某些组织要求使用启用 SSO 的令牌
- 查看您组织的[令牌策略设置](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization)
2. **验证组织访问权限**
- 转到 GitHub 上的令牌设置
- 在"组织访问"下查找组织
- 如果需要,点击组织旁边的"启用 SSO"
- 完成 SSO 授权过程
#### OAuth 身份验证(在线模式)
在在线模式下使用 OpenHands 时GitHub OAuth 流程:
1. 请求以下权限:
- 仓库访问(读/写)
- 工作流管理
- 组织读取访问
2. 身份验证步骤:
- 出现提示时,点击"使用 GitHub 登录"
- 查看请求的权限
- 授权 OpenHands 访问您的 GitHub 帐户
- 如果使用组织,在出现提示时授权组织访问
#### 故障排除
常见问题和解决方案:
1. **令牌无法识别**
- 确保令牌已正确保存在设置中
- 检查令牌是否已过期
- 验证令牌是否具有所需的范围
- 尝试重新生成令牌
2. **组织访问被拒绝**
- 检查是否需要但未启用 SSO
- 验证组织成员资格
- 如果令牌策略阻止访问,请联系组织管理员
3. **验证令牌是否有效**
- 如果令牌有效,应用程序将显示绿色复选标记
- 尝试访问仓库以确认权限
- 检查浏览器控制台中是否有任何错误消息
- 如果可用,使用设置中的"测试连接"按钮
### 高级设置
1. 切换`高级选项`以访问其他设置。
2. 如果列表中没有所需的模型,使用`自定义模型`文本框手动输入模型。
3. 如果您的 LLM 提供商需要,请指定`基本 URL`
### 主界面
主界面由几个关键组件组成:
1. **聊天窗口**:中央区域,您可以在其中查看与 AI 助手的对话历史记录。
2. **输入框**:位于屏幕底部,用于输入您要发送给 AI 的消息或命令。
3. **发送按钮**:点击此按钮将消息发送给 AI。
4. **设置按钮**:打开设置模态框的齿轮图标,允许您随时调整配置。
5. **工作区面板**:显示工作区中的文件和文件夹,允许您导航和查看文件,或查看代理的过去命令或网页浏览历史记录。
### 与 AI 交互
1. 在输入框中输入您的问题、请求或任务描述。
2. 点击发送按钮或按 Enter 键提交消息。
3. AI 将处理您的输入并在聊天窗口中提供响应。
4. 您可以通过询问后续问题或提供额外信息来继续对话。
## 有效使用的提示
1. 在请求中要具体,以获得最准确和最有帮助的响应,如[提示最佳实践](../prompting/prompting-best-practices)中所述。
2. 使用工作区面板探索项目结构。
3. 使用[LLMs 部分](usage/llms/llms.md)中描述的推荐模型之一。
请记住OpenHands 的 GUI 模式旨在使您与 AI 助手的交互尽可能流畅和直观。不要犹豫探索其功能以最大限度地提高您的工作效率。

View File

@@ -0,0 +1,62 @@
以下是翻译后的内容:
# 无头模式
你可以使用单个命令运行 OpenHands,而无需启动 Web 应用程序。
这使得使用 OpenHands 编写脚本和自动化任务变得很容易。
这与[CLI 模式](cli-mode)不同,后者是交互式的,更适合主动开发。
## 使用 Python
要在 Python 中以无头模式运行 OpenHands,
[请按照开发设置说明](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md),
然后运行:
```bash
poetry run python -m openhands.core.main -t "write a bash script that prints hi"
```
你需要确保通过环境变量
[或 `config.toml` 文件](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml)
设置你的模型、API 密钥和其他设置。
## 使用 Docker
1.`WORKSPACE_BASE` 设置为你希望 OpenHands 编辑的目录:
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
2.`LLM_MODEL` 设置为你要使用的模型:
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3.`LLM_API_KEY` 设置为你的 API 密钥:
```bash
LLM_API_KEY="sk_test_12345"
```
4. 运行以下 Docker 命令:
```bash
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-e LLM_API_KEY=$LLM_API_KEY \
-e LLM_MODEL=$LLM_MODEL \
-e LOG_ALL_EVENTS=true \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
--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.23 \
python -m openhands.core.main -t "write a bash script that prints hi" --no-auto-continue
```

View File

@@ -0,0 +1,17 @@
以下是翻译后的内容:
# 持久化会话数据
使用标准安装,会话数据存储在内存中。目前,如果 OpenHands 服务重新启动,之前的会话将失效(生成新的密钥),因此无法恢复。
## 如何持久化会话数据
### 开发工作流
`config.toml` 文件中,指定以下内容:
```
[core]
...
file_store="local"
file_store_path="/absolute/path/to/openhands/cache/directory"
jwt_secret="secretpass"
```

View File

@@ -0,0 +1,54 @@
# 安装
## 系统要求
* Docker 版本 26.0.0+ 或 Docker Desktop 4.31.0+。
* 你必须使用 Linux 或 Mac OS。
* 如果你使用的是 Windows你必须使用 [WSL](https://learn.microsoft.com/en-us/windows/wsl/install)。
## 启动应用
在 Docker 中运行 OpenHands 是最简单的方式。
```bash
docker pull docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik
docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:0.23
```
你也可以在可脚本化的[无头模式](https://docs.all-hands.dev/modules/usage/how-to/headless-mode)下运行 OpenHands作为[交互式 CLI](https://docs.all-hands.dev/modules/usage/how-to/cli-mode),或使用 [OpenHands GitHub Action](https://docs.all-hands.dev/modules/usage/how-to/github-action)。
## 设置
运行上述命令后,你可以在 [http://localhost:3000](http://localhost:3000) 找到正在运行的 OpenHands。
启动 OpenHands 后,你会看到一个设置模态框。你**必须**选择一个 `LLM Provider` 和 `LLM Model`,并输入相应的 `API Key`。
这些设置可以随时通过选择 UI 中的 `Settings` 按钮(齿轮图标)进行更改。
如果所需的 `LLM Model` 不在列表中,你可以切换 `Advanced Options`,并在 `Custom Model` 文本框中使用正确的前缀手动输入。
`Advanced Options` 还允许你在需要时指定 `Base URL`。
<div style={{ display: 'flex', justifyContent: 'center', gap: '20px' }}>
<img src="/img/settings-screenshot.png" alt="settings-modal" width="340" />
<img src="/img/settings-advanced.png" alt="settings-modal" width="335" />
</div>
## 版本
上述命令拉取最新的 OpenHands 稳定版本。你还有其他选择:
- 对于特定版本,使用 `docker.all-hands.dev/all-hands-ai/openhands:$VERSION`,将 $VERSION 替换为版本号。
- 我们使用语义化版本,并发布主要版本、次要版本和补丁标签。因此,`0.9` 将自动指向最新的 `0.9.x` 版本,而 `0` 将指向最新的 `0.x.x` 版本。
- 对于最新的开发版本,你可以使用 `docker.all-hands.dev/all-hands-ai/openhands:main`。此版本不稳定,仅建议用于测试或开发目的。
你可以根据稳定性要求和所需功能选择最适合你需求的标签。
有关开发工作流程,请参阅 [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)。
遇到问题了吗?查看我们的[故障排除指南](https://docs.all-hands.dev/modules/usage/troubleshooting)。

View File

@@ -0,0 +1,109 @@
---
sidebar_position: 1
---
# 💻 OpenHands
OpenHands 是一个**自主 AI 软件工程师**,能够执行复杂的工程任务,并在软件开发项目中积极与用户合作。
这个项目是完全开源的,所以你可以随意使用和修改它。
:::tip
在 [GitHub](https://github.com/All-Hands-AI/OpenHands) 上探索 OpenHands 的代码库或加入我们的社区!
<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-2ypg5jweb-d~6hObZDbXi_HEL8PDrbHg">
<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>
:::
## 🛠️ 入门指南
运行 OpenHands 最简单的方法是在 Docker 容器中。它在 Docker 的最新版本 `26.0.0` 上运行效果最佳。
你必须使用 Linux、Mac OS 或 Windows 上的 WSL。
要在 Docker 容器中启动 OpenHands请在终端中运行以下命令
:::warning
运行以下命令时,`./workspace` 中的文件可能会被修改或删除。
:::
```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
```
你会发现 OpenHands 在 [http://localhost:3000](http://localhost:3000) 运行,并可以访问 `./workspace`。要让 OpenHands 操作你的代码,请将代码放在 `./workspace` 中。
OpenHands 只会访问这个工作区文件夹。它在一个安全的 docker 沙盒中运行,不会影响你系统的其他部分。
:::tip
如果你想使用**(不稳定!)**最新版本,可以使用 `ghcr.io/all-hands-ai/openhands:main` 作为镜像(最后一行)。
:::
有关开发工作流程,请参阅 [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)。
遇到问题了吗?查看我们的 [故障排除指南](https://docs.all-hands.dev/modules/usage/troubleshooting)。
:::warning
OpenHands 目前正在开发中,但你已经可以运行 alpha 版本来查看端到端系统的运作情况。
:::
[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

@@ -0,0 +1,43 @@
# Azure
OpenHands 使用 LiteLLM 调用 Azure 的聊天模型。你可以在[这里](https://docs.litellm.ai/docs/providers/azure)找到他们关于使用 Azure 作为提供商的文档。
## Azure OpenAI 配置
运行 OpenHands 时,你需要在 [docker run 命令](/modules/usage/installation#start-the-app)中使用 `-e` 设置以下环境变量:
```
LLM_API_VERSION="<api-version>" # 例如 "2023-05-15"
```
示例:
```bash
docker run -it --pull=always \
-e LLM_API_VERSION="2023-05-15"
...
```
然后在 OpenHands UI 的设置中设置以下内容:
:::note
你需要你的 ChatGPT 部署名称,可以在 Azure 的部署页面找到。下面将其称为 &lt;deployment-name&gt;
:::
* 启用 `Advanced Options`
*`Custom Model` 设置为 azure/&lt;deployment-name&gt;
*`Base URL` 设置为你的 Azure API 基础 URL例如 `https://example-endpoint.openai.azure.com`
*`API Key` 设置为你的 Azure API 密钥
## Embeddings
OpenHands 使用 llama-index 进行 embeddings。你可以在[这里](https://docs.llamaindex.ai/en/stable/api_reference/embeddings/azure_openai/)找到他们关于 Azure 的文档。
### Azure OpenAI 配置
运行 OpenHands 时,在 [docker run 命令](/modules/usage/installation#start-the-app)中使用 `-e` 设置以下环境变量:
```
LLM_EMBEDDING_MODEL="azureopenai"
LLM_EMBEDDING_DEPLOYMENT_NAME="<your-embedding-deployment-name>" # 例如 "TextEmbedding...<etc>"
LLM_API_VERSION="<api-version>" # 例如 "2024-02-15-preview"
```

View File

@@ -0,0 +1,37 @@
# Azure OpenAI 大型语言模型
## 完成
OpenHands 使用 LiteLLM 进行完成调用。你可以在 Azure 的文档中找到他们的文档 [这里](https://docs.litellm.ai/docs/providers/azure)
### Azure openai 配置
在运行 OpenHands Docker 镜像时,你需要使用 `-e` 设置以下环境变量:
```
LLM_BASE_URL="<azure-api-base-url>" # 示例: "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>" # 示例: "2024-02-15-preview"
```
:::note
你可以在 Azure 的部署页面找到你的 ChatGPT 部署名称。它可能与默认或最初设置的聊天模型名称相同(例如 'GPT4-1106-preview'),但不一定相同。运行 OpenHands当你在浏览器中加载它时进入设置并按照上述方式设置模型: "azure/&lt;your-actual-gpt-deployment-name&gt;"。如果列表中没有,请输入你自己的文本并保存。
:::
## 嵌入
OpenHands 使用 llama-index 进行嵌入。你可以在 Azure 的文档中找到他们的文档 [这里](https://docs.llamaindex.ai/en/stable/api_reference/embeddings/azure_openai/)
### Azure openai 配置
Azure OpenAI 嵌入使用的模型是 "text-embedding-ada-002"。
你需要在你的 Azure 账户中为这个模型设置正确的部署名称。
在 Docker 中运行 OpenHands 时,使用 `-e` 设置以下环境变量:
```
LLM_EMBEDDING_MODEL="azureopenai"
LLM_EMBEDDING_DEPLOYMENT_NAME = "<your-embedding-deployment-name>" # 示例: "TextEmbedding...<etc>"
LLM_API_VERSION = "<api-version>" # 示例: "2024-02-15-preview"
```

View File

@@ -0,0 +1,29 @@
# Google Gemini/Vertex
OpenHands 使用 LiteLLM 调用 Google 的聊天模型。你可以在以下文档中找到使用 Google 作为提供商的说明:
- [Gemini - Google AI Studio](https://docs.litellm.ai/docs/providers/gemini)
- [VertexAI - Google Cloud Platform](https://docs.litellm.ai/docs/providers/vertex)
## Gemini - Google AI Studio 配置
运行 OpenHands 时,你需要在设置中设置以下内容:
*`LLM Provider` 设置为 `Gemini`
*`LLM Model` 设置为你将使用的模型。
如果模型不在列表中,请切换 `Advanced Options`,并在 `Custom Model` 中输入(例如 gemini/&lt;model-name&gt;`gemini/gemini-1.5-pro`)。
*`API Key` 设置为你的 Gemini API 密钥
## VertexAI - Google Cloud Platform 配置
要在运行 OpenHands 时通过 Google Cloud Platform 使用 Vertex AI你需要使用 [docker run 命令](/modules/usage/installation#start-the-app) 中的 `-e` 设置以下环境变量:
```
GOOGLE_APPLICATION_CREDENTIALS="<json-dump-of-gcp-service-account-json>"
VERTEXAI_PROJECT="<your-gcp-project-id>"
VERTEXAI_LOCATION="<your-gcp-location>"
```
然后在设置中设置以下内容:
*`LLM Provider` 设置为 `VertexAI`
*`LLM Model` 设置为你将使用的模型。
如果模型不在列表中,请切换 `Advanced Options`,并在 `Custom Model` 中输入(例如 vertex_ai/&lt;model-name&gt;)。

View File

@@ -0,0 +1,28 @@
# Google Gemini/Vertex LLM
## Completion
OpenHands 使用 LiteLLM 进行补全调用。以下资源与使用 OpenHands 和 Google 的 LLM 相关:
- [Gemini - Google AI Studio](https://docs.litellm.ai/docs/providers/gemini)
- [VertexAI - Google Cloud Platform](https://docs.litellm.ai/docs/providers/vertex)
### Gemini - Google AI Studio 配置
在运行 OpenHands Docker 镜像时,通过 Google AI Studio 使用 Gemini你需要使用 `-e` 设置以下环境变量:
```
GEMINI_API_KEY="<your-google-api-key>"
LLM_MODEL="gemini/gemini-1.5-pro"
```
### Vertex AI - Google Cloud Platform 配置
在运行 OpenHands Docker 镜像时,通过 Google Cloud Platform 使用 Vertex AI你需要使用 `-e` 设置以下环境变量:
```
GOOGLE_APPLICATION_CREDENTIALS="<json-dump-of-gcp-service-account-json>"
VERTEXAI_PROJECT="<your-gcp-project-id>"
VERTEXAI_LOCATION="<your-gcp-location>"
LLM_MODEL="vertex_ai/<desired-llm-model>"
```

View File

@@ -0,0 +1,20 @@
# Groq
OpenHands 使用 LiteLLM 在 Groq 上调用聊天模型。你可以在[这里](https://docs.litellm.ai/docs/providers/groq)找到他们关于使用 Groq 作为提供商的文档。
## 配置
在运行 OpenHands 时,你需要在设置中设置以下内容:
* `LLM Provider` 设置为 `Groq`
* `LLM Model` 设置为你将使用的模型。[访问此处查看 Groq 托管的模型列表](https://console.groq.com/docs/models)。如果模型不在列表中,切换 `Advanced Options`,并在 `Custom Model` 中输入它(例如 groq/&lt;model-name&gt;`groq/llama3-70b-8192`)。
* `API key` 设置为你的 Groq API 密钥。要查找或创建你的 Groq API 密钥,[请参见此处](https://console.groq.com/keys)。
## 使用 Groq 作为 OpenAI 兼容端点
Groq 的聊天完成端点[大部分与 OpenAI 兼容](https://console.groq.com/docs/openai)。因此,你可以像访问任何 OpenAI 兼容端点一样访问 Groq 模型。你可以在设置中设置以下内容:
* 启用 `Advanced Options`
* `Custom Model` 设置为前缀 `openai/` + 你将使用的模型(例如 `openai/llama3-70b-8192`
* `Base URL` 设置为 `https://api.groq.com/openai/v1`
* `API Key` 设置为你的 Groq API 密钥

View File

@@ -0,0 +1,22 @@
以下是翻译后的内容:
# LiteLLM 代理
OpenHands 支持使用 [LiteLLM 代理](https://docs.litellm.ai/docs/proxy/quick_start)来访问各种 LLM 提供商。
## 配置
要在 OpenHands 中使用 LiteLLM 代理,你需要:
1. 设置一个 LiteLLM 代理服务器(参见 [LiteLLM 文档](https://docs.litellm.ai/docs/proxy/quick_start))
2. 运行 OpenHands 时,你需要在 OpenHands UI 的设置中设置以下内容:
* 启用`高级选项`
*`自定义模型`设置为前缀 `litellm_proxy/` + 你将使用的模型(例如 `litellm_proxy/anthropic.claude-3-5-sonnet-20241022-v2:0`)
*`Base URL`设置为你的 LiteLLM 代理 URL(例如 `https://your-litellm-proxy.com`)
*`API Key`设置为你的 LiteLLM 代理 API 密钥
## 支持的模型
支持的模型取决于你的 LiteLLM 代理配置。OpenHands 支持你的 LiteLLM 代理配置的任何模型。
有关可用模型及其名称的列表,请参阅你的 LiteLLM 代理配置。

View File

@@ -0,0 +1,82 @@
# 🤖 LLM 后端
OpenHands 可以连接到 LiteLLM 支持的任何 LLM。但是它需要一个强大的模型才能工作。
## 模型推荐
根据我们对编码任务语言模型的评估(使用 SWE-bench 数据集),我们可以为模型选择提供一些建议。一些分析可以在[这篇比较 LLM 的博客文章](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed)和[这篇包含一些最新结果的博客文章](https://www.all-hands.dev/blog/openhands-codeact-21-an-open-state-of-the-art-software-development-agent)中找到。
在选择模型时,要同时考虑输出质量和相关成本。以下是调查结果的总结:
- Claude 3.5 Sonnet 是目前最好的,在 SWE-Bench Verified 上使用 OpenHands 中的默认代理可以达到 53% 的解决率。
- GPT-4o 落后于 Claude而 o1-mini 的表现甚至比 GPT-4o 还要差一些。我们进行了一些分析简单来说o1 有时会"想得太多",在可以直接完成任务的情况下执行额外的环境配置任务。
- 最后,最强大的开放模型是 Llama 3.1 405 B 和 deepseek-v2.5,它们表现得相当不错,甚至超过了一些封闭模型。
请参阅[完整文章](https://www.all-hands.dev/blog/evaluation-of-llms-as-coding-agents-on-swe-bench-at-30x-speed)了解更多详情。
根据这些发现和社区反馈,以下模型已经验证可以与 OpenHands 很好地配合使用:
- claude-3-5-sonnet推荐
- gpt-4 / gpt-4o
- llama-3.1-405b
- deepseek-v2.5
:::warning
OpenHands 将向您配置的 LLM 发出许多提示。这些 LLM 中的大多数都需要付费,因此请务必设置支出限制并监控使用情况。
:::
如果您已经成功地使用特定的未列出的 LLM 运行 OpenHands请将它们添加到已验证列表中。我们也鼓励您提交 PR 分享您的设置过程,以帮助其他使用相同提供商和 LLM 的人!
有关可用提供商和模型的完整列表,请查阅 [litellm 文档](https://docs.litellm.ai/docs/providers)。
:::note
目前大多数本地和开源模型都没有那么强大。使用这些模型时,您可能会看到消息之间的长时间等待、响应不佳或有关 JSON 格式错误的错误。OpenHands 只能和驱动它的模型一样强大。但是,如果您确实找到了可以使用的模型,请将它们添加到上面的已验证列表中。
:::
## LLM 配置
以下内容可以通过设置在 OpenHands UI 中设置:
- `LLM Provider`
- `LLM Model`
- `API Key`
- `Base URL`(通过`Advanced Settings`
有些设置可能对某些 LLM/提供商是必需的,但无法通过 UI 设置。相反,可以通过传递给 [docker run 命令](/modules/usage/installation#start-the-app)的环境变量使用 `-e` 来设置这些变量:
- `LLM_API_VERSION`
- `LLM_EMBEDDING_MODEL`
- `LLM_EMBEDDING_DEPLOYMENT_NAME`
- `LLM_DROP_PARAMS`
- `LLM_DISABLE_VISION`
- `LLM_CACHING_PROMPT`
我们有一些使用特定模型提供商运行 OpenHands 的指南:
- [Azure](llms/azure-llms)
- [Google](llms/google-llms)
- [Groq](llms/groq)
- [LiteLLM Proxy](llms/litellm-proxy)
- [OpenAI](llms/openai-llms)
- [OpenRouter](llms/openrouter)
### API 重试和速率限制
LLM 提供商通常有速率限制,有时非常低,可能需要重试。如果 OpenHands 收到速率限制错误429 错误代码、API 连接错误或其他瞬时错误,它将自动重试请求。
您可以根据使用的提供商的需要自定义这些选项。查看他们的文档,并设置以下环境变量来控制重试次数和重试之间的时间:
- `LLM_NUM_RETRIES`(默认为 8
- `LLM_RETRY_MIN_WAIT`(默认为 15 秒)
- `LLM_RETRY_MAX_WAIT`(默认为 120 秒)
- `LLM_RETRY_MULTIPLIER`(默认为 2
如果您在开发模式下运行 OpenHands也可以在 `config.toml` 文件中设置这些选项:
```toml
[llm]
num_retries = 8
retry_min_wait = 15
retry_max_wait = 120
retry_multiplier = 2
```

View File

@@ -0,0 +1,192 @@
# 使用 Ollama 的本地 LLM
:::warning
使用本地 LLM 时OpenHands 可能会有功能限制。
:::
确保你已经启动并运行了 Ollama 服务器。
有关详细的启动说明,请参考[此处](https://github.com/ollama/ollama)。
本指南假设你已经使用 `ollama serve` 启动了 ollama。如果你以不同的方式运行 ollama例如在 docker 内),则可能需要修改说明。请注意,如果你正在运行 WSL默认的 ollama 配置会阻止来自 docker 容器的请求。请参阅[此处](#configuring-ollama-service-wsl-zh)。
## 拉取模型
Ollama 模型名称可以在[此处](https://ollama.com/library)找到。对于一个小示例,你可以使用
`codellama:7b` 模型。更大的模型通常会有更好的表现。
```bash
ollama pull codellama:7b
```
你可以像这样检查已下载的模型:
```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
```
## 使用 Docker 运行 OpenHands
### 启动 OpenHands
使用[此处](../getting-started)的说明使用 Docker 启动 OpenHands。
但在运行 `docker run` 时,你需要添加一些额外的参数:
```bash
docker run # ...
--add-host host.docker.internal:host-gateway \
-e LLM_OLLAMA_BASE_URL="http://host.docker.internal:11434" \
# ...
```
LLM_OLLAMA_BASE_URL 是可选的。如果设置了它,它将用于在 UI 中显示
可用的已安装模型。
### 配置 Web 应用程序
在运行 `openhands` 时,你需要在 OpenHands UI 的设置中设置以下内容:
- 模型设置为 "ollama/&lt;model-name&gt;"
- 基础 URL 设置为 `http://host.docker.internal:11434`
- API 密钥是可选的,你可以使用任何字符串,例如 `ollama`
## 在开发模式下运行 OpenHands
### 从源代码构建
使用 [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) 中的说明构建 OpenHands。
通过运行 `make setup-config` 确保 `config.toml` 存在,它将为你创建一个。在 `config.toml` 中,输入以下内容:
```
[core]
workspace_base="./workspace"
[llm]
embedding_model="local"
ollama_base_url="http://localhost:11434"
```
完成!现在你可以通过 `make run` 启动 OpenHands。你现在应该能够连接到 `http://localhost:3000/`
### 配置 Web 应用程序
在 OpenHands UI 中,点击左下角的设置齿轮。
然后在 `Model` 输入框中,输入 `ollama/codellama:7b`,或者你之前拉取的模型名称。
如果它没有出现在下拉列表中,启用 `Advanced Settings` 并输入它。请注意:你需要 `ollama list` 列出的模型名称,带有 `ollama/` 前缀。
在 API Key 字段中,输入 `ollama` 或任何值,因为你不需要特定的密钥。
在 Base URL 字段中,输入 `http://localhost:11434`
现在你已经准备好了!
## 配置 ollama 服务WSL {#configuring-ollama-service-wsl-zh}
WSL 中 ollama 的默认配置只服务于 localhost。这意味着你无法从 docker 容器中访问它。例如,它不能与 OpenHands 一起工作。首先让我们测试 ollama 是否正确运行。
```bash
ollama list # 获取已安装模型的列表
curl http://localhost:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例如 curl http://localhost:11434/api/generate -d '{"model":"codellama:7b","prompt":"hi"}'
#例如 curl http://localhost:11434/api/generate -d '{"model":"codellama","prompt":"hi"}' #如果只有一个,标签是可选的
```
完成后,测试它是否允许"外部"请求,例如来自 docker 容器内部的请求。
```bash
docker ps # 获取正在运行的 docker 容器列表,为了最准确的测试,选择 OpenHands 沙盒容器。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例如 docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## 修复它
现在让我们让它工作。使用 sudo 权限编辑 /etc/systemd/system/ollama.service。路径可能因 Linux 发行版而异)
```bash
sudo vi /etc/systemd/system/ollama.service
```
```bash
sudo nano /etc/systemd/system/ollama.service
```
在 [Service] 括号中添加这些行
```
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"
```
然后保存,重新加载配置并重启服务。
```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```
最后测试 ollama 是否可以从容器内访问
```bash
ollama list # 获取已安装模型的列表
docker ps # 获取正在运行的 docker 容器列表,为了最准确的测试,选择 OpenHands 沙盒容器。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
```
# 使用 LM Studio 的本地 LLM
设置 LM Studio 的步骤:
1. 打开 LM Studio
2. 转到 Local Server 选项卡。
3. 点击 "Start Server" 按钮。
4. 从下拉列表中选择要使用的模型。
设置以下配置:
```bash
LLM_MODEL="openai/lmstudio"
LLM_BASE_URL="http://localhost:1234/v1"
CUSTOM_LLM_PROVIDER="openai"
```
### Docker
```bash
docker run # ...
-e LLM_MODEL="openai/lmstudio" \
-e LLM_BASE_URL="http://host.docker.internal:1234/v1" \
-e CUSTOM_LLM_PROVIDER="openai" \
# ...
```
你现在应该能够连接到 `http://localhost:3000/`
在开发环境中,你可以在 `config.toml` 文件中设置以下配置:
```
[core]
workspace_base="./workspace"
[llm]
model="openai/lmstudio"
base_url="http://localhost:1234/v1"
custom_llm_provider="openai"
```
完成!现在你可以通过 `make run` 启动 OpenHands无需 Docker。你现在应该能够连接到 `http://localhost:3000/`
# 注意
对于 WSL在 cmd 中运行以下命令以将网络模式设置为镜像:
```
python -c "print('[wsl2]\nnetworkingMode=mirrored',file=open(r'%UserProfile%\.wslconfig','w'))"
wsl --shutdown
```

View File

@@ -0,0 +1,140 @@
# 使用 Ollama 的本地 LLM
确保您的 Ollama 服务器已启动运行。有关详细的启动说明,请参阅[此处](https://github.com/ollama/ollama)
本指南假定您已通过 `ollama serve` 启动 ollama。如果您以其他方式运行 ollama例如在 docker 内),说明可能需要进行修改。请注意,如果您在运行 WSL默认的 ollama 配置会阻止来自 docker 容器的请求。请参阅[此处](#configuring-ollama-service-zh-Hans)。
## 拉取模型
Ollama 模型名称可以在[这里](https://ollama.com/library)找到。一个小例子,您可以使用
`codellama:7b` 模型。较大的模型通常表现更好。
```bash
ollama pull codellama:7b
```
您可以这样检查已下载的模型:
```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
```
## 启动 OpenHands
### Docker
使用[此处](../intro)的说明通过 Docker 启动 OpenHands。
但是在运行 `docker run` 时,您需要添加一些额外的参数:
```bash
--add-host host.docker.internal:host-gateway \
-e LLM_API_KEY="ollama" \
-e LLM_BASE_URL="http://host.docker.internal:11434" \
```
例如:
```bash
# 您希望 OpenHands 修改的目录。必须是绝对路径!
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
```
现在您应该可以连接到 `http://localhost:3000/`
### 从源代码构建
使用[Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md)中的说明构建 OpenHands。
通过运行 `make setup-config` 确保 `config.toml` 存在,这将为您创建一个。在 `config.toml` 中,输入以下内容:
```
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"
```
如有需要,可以替换您选择的 `LLM_MODEL`
完成!现在您可以通过 `make run` 启动 OpenHands 而无需 Docker。现在您应该可以连接到 `http://localhost:3000/`
## 选择您的模型
在 OpenHands UI 中,点击左下角的设置齿轮。
然后在 `Model` 输入中,输入 `ollama/codellama:7b`,或者您之前拉取的模型名称。
如果它没有出现在下拉列表中,也没关系,只需输入即可。完成后点击保存。
现在您已经准备好了!
## 配置 ollama 服务WSL{#configuring-ollama-service-zh-Hans}
WSL 中 ollama 的默认配置仅为 localhost 提供服务。这意味着您无法从 docker 容器中访问它。比如,它不会与 OpenHands 一起工作。首先让我们测试 ollama 是否正常运行。
```bash
ollama list # 获取已安装模型列表
curl http://localhost:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例如curl http://localhost:11434/api/generate -d '{"model":"codellama:7b","prompt":"hi"}'
#例如curl http://localhost:11434/api/generate -d '{"model":"codellama","prompt":"hi"}' # 如果只有一个模型,标签是可选的
```
完成后,测试它是否允许“外部”请求,比如那些来自 docker 容器内的请求。
```bash
docker ps # 获取正在运行的 docker 容器列表,最准确的测试选择 OpenHands sandbox 容器。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
#例如docker exec cd9cc82f7a11 curl http://host.docker.internal:11434/api/generate -d '{"model":"codellama","prompt":"hi"}'
```
## 修复它
现在让我们使其工作。使用 sudo 权限编辑 /etc/systemd/system/ollama.service。 (路径可能因 linux 版本而异)
```bash
sudo vi /etc/systemd/system/ollama.service
```
或者
```bash
sudo nano /etc/systemd/system/ollama.service
```
在 [Service] 括号内添加以下行
```
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"
```
然后保存,重新加载配置并重新启动服务。
```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama
```
最后测试 ollama 是否可以从容器内访问
```bash
ollama list # 获取已安装模型列表
docker ps # 获取正在运行的 docker 容器列表,最准确的测试选择 OpenHands sandbox 容器。
docker exec [CONTAINER ID] curl http://host.docker.internal:11434/api/generate -d '{"model":"[NAME]","prompt":"hi"}'
```

View File

@@ -0,0 +1,24 @@
# OpenAI
OpenHands 使用 LiteLLM 调用 OpenAI 的聊天模型。你可以在[这里](https://docs.litellm.ai/docs/providers/openai)找到他们关于使用 OpenAI 作为提供商的文档。
## 配置
运行 OpenHands 时,你需要在设置中设置以下内容:
* `LLM Provider` 设置为 `OpenAI`
* `LLM Model` 设置为你将使用的模型。
[访问此处查看 LiteLLM 支持的 OpenAI 模型的完整列表。](https://docs.litellm.ai/docs/providers/openai#openai-chat-completion-models)
如果模型不在列表中,请切换 `Advanced Options`,并在 `Custom Model` 中输入它(例如 openai/&lt;model-name&gt;`openai/gpt-4o`)。
* `API Key` 设置为你的 OpenAI API 密钥。要查找或创建你的 OpenAI 项目 API 密钥,[请参阅此处](https://platform.openai.com/api-keys)。
## 使用 OpenAI 兼容端点
就像 OpenAI 聊天补全一样,我们使用 LiteLLM 进行 OpenAI 兼容端点。你可以在[这里](https://docs.litellm.ai/docs/providers/openai_compatible)找到他们关于此主题的完整文档。
## 使用 OpenAI 代理
如果你使用 OpenAI 代理,你需要在设置中设置以下内容:
* 启用 `Advanced Options`
* `Custom Model` 设置为 openai/&lt;model-name&gt;(例如 `openai/gpt-4o` 或 openai/&lt;proxy-prefix&gt;/&lt;model-name&gt;
* `Base URL` 设置为你的 OpenAI 代理的 URL
* `API Key` 设置为你的 OpenAI API 密钥

View File

@@ -0,0 +1,14 @@
以下是翻译后的内容:
# OpenRouter
OpenHands 使用 LiteLLM 调用 OpenRouter 上的聊天模型。你可以在[这里](https://docs.litellm.ai/docs/providers/openrouter)找到他们关于使用 OpenRouter 作为提供者的文档。
## 配置
运行 OpenHands 时,你需要在设置中设置以下内容:
* `LLM Provider` 设置为 `OpenRouter`
* `LLM Model` 设置为你将使用的模型。
[访问此处查看 OpenRouter 模型的完整列表](https://openrouter.ai/models)。
如果模型不在列表中,请切换 `Advanced Options`,并在 `Custom Model` 中输入(例如 openrouter/&lt;model-name&gt;`openrouter/anthropic/claude-3.5-sonnet`)。
* `API Key` 设置为你的 OpenRouter API 密钥。

View File

@@ -0,0 +1,43 @@
以下是翻译后的内容:
# 提示最佳实践
在使用 OpenHands AI 软件开发者时,提供清晰有效的提示至关重要。本指南概述了创建提示的最佳实践,以产生最准确和最有用的响应。
## 好的提示的特点
好的提示是:
1. **具体的**: 它们准确解释应该添加什么功能或需要修复什么错误。
2. **位置特定的**: 如果已知,它们解释了应该修改代码库中的哪些位置。
3. **适当范围的**: 它们应该是单个功能的大小,通常不超过100行代码。
## 示例
### 好的提示示例
1. "在 `utils/math_operations.py` 中添加一个函数 `calculate_average`,它接受一个数字列表作为输入并返回它们的平均值。"
2. "修复 `frontend/src/components/UserProfile.tsx` 中第42行发生的 TypeError。错误表明我们试图访问 undefined 的属性。"
3. "为注册表单中的电子邮件字段实现输入验证。更新 `frontend/src/components/RegistrationForm.tsx` 以在提交之前检查电子邮件是否为有效格式。"
### 不好的提示示例
1. "让代码更好。"(太模糊,不具体)
2. "重写整个后端以使用不同的框架。"(范围不合适)
3. "用户身份验证中有一个错误。你能找到并修复它吗?"(缺乏具体性和位置信息)
## 有效提示的技巧
1. 尽可能具体地说明期望的结果或要解决的问题。
2. 提供上下文,包括相关的文件路径和行号(如果可用)。
3. 将大型任务分解为更小、更易管理的提示。
4. 包括任何相关的错误消息或日志。
5. 如果从上下文中不明显,请指定编程语言或框架。
请记住,您的提示越精确和信息量大,AI 就越能帮助您开发或修改 OpenHands 软件。
有关更多有用提示的示例,请参阅 [OpenHands 入门](./getting-started)。

View File

@@ -0,0 +1,64 @@
# 自定义代理行为
OpenHands 可以通过提供特定仓库的上下文和指南来进行自定义,以更有效地处理特定仓库。本节将解释如何为你的项目优化 OpenHands。
## 仓库配置
你可以通过在仓库根目录下创建 `.openhands` 目录来自定义 OpenHands 在你的仓库中的行为。至少,它应该包含文件 `.openhands/microagents/repo.md`,其中包括每次代理处理此仓库时都会提供给代理的指令。
我们建议包括以下信息:
1. **仓库概述**:简要描述你的项目的目的和架构
2. **目录结构**:关键目录及其用途
3. **开发指南**:项目特定的编码标准和实践
4. **测试要求**:如何运行测试以及需要哪些类型的测试
5. **设置说明**:构建和运行项目所需的步骤
### 仓库配置示例
`.openhands/microagents/repo.md` 文件示例:
```
Repository: MyProject
Description: A web application for task management
Directory Structure:
- src/: Main application code
- tests/: Test files
- docs/: Documentation
Setup:
- Run `npm install` to install dependencies
- Use `npm run dev` for development
- Run `npm test` for testing
Guidelines:
- Follow ESLint configuration
- Write tests for all new features
- Use TypeScript for new code
```
### 自定义提示
在处理自定义仓库时:
1. **参考项目标准**:提及你的项目中使用的特定编码标准或模式
2. **包括上下文**:参考相关文档或现有实现
3. **指定测试要求**:在提示中包括项目特定的测试要求
自定义提示示例:
```
Add a new task completion feature to src/components/TaskList.tsx following our existing component patterns.
Include unit tests in tests/components/ and update the documentation in docs/features/.
The component should use our shared styling from src/styles/components.
```
### 仓库自定义的最佳实践
1. **保持说明更新**:随着项目的发展,定期更新你的 `.openhands` 目录
2. **要具体**:包括特定于你的项目的具体路径、模式和要求
3. **记录依赖项**:列出开发所需的所有工具和依赖项
4. **包括示例**:提供项目中良好代码模式的示例
5. **指定约定**:记录命名约定、文件组织和代码风格偏好
通过为你的仓库自定义 OpenHands,你将获得更准确、更一致的结果,这些结果符合你的项目标准和要求。
## 其他微代理
你可以在 `.openhands/microagents/` 目录中创建其他指令,如果找到特定关键字,如 `test``frontend``migration`,这些指令将发送给代理。有关更多信息,请参阅 [Microagents](microagents.md)。

View File

@@ -0,0 +1,213 @@
# 微代理
OpenHands 使用专门的微代理来高效处理特定任务和上下文。这些微代理是小型、专注的组件,为特定场景提供专门的行为和知识。
## 概述
微代理在 `openhands/agenthub/codeact_agent/micro/` 目录下的 Markdown 文件中定义。每个微代理都配置有:
- 唯一的名称
- 代理类型(通常是 CodeActAgent
- 触发代理的关键词
- 具体的指令和功能
## 可用的微代理
### GitHub 代理
**文件**`github.md`
**触发词**`github``git`
GitHub 代理专门用于 GitHub API 交互和仓库管理。它:
- 可以访问用于 API 身份验证的 `GITHUB_TOKEN`
- 遵循严格的仓库交互准则
- 处理分支管理和拉取请求
- 使用 GitHub API 而不是网页浏览器交互
主要特点:
- 分支保护(防止直接推送到 main/master
- 自动创建 PR
- Git 配置管理
- 以 API 为先的 GitHub 操作方式
### NPM 代理
**文件**`npm.md`
**触发词**`npm`
专门处理 npm 包管理,特别关注:
- 非交互式 shell 操作
- 使用 Unix 'yes' 命令自动处理确认
- 包安装自动化
### 自定义微代理
你可以通过在微代理目录中添加新的 Markdown 文件来创建自己的微代理。每个文件应遵循以下结构:
```markdown
---
name: agent_name
agent: CodeActAgent
triggers:
- trigger_word1
- trigger_word2
---
微代理的指令和功能...
```
## 最佳实践
使用微代理时:
1. **使用适当的触发词**:确保你的命令包含相关的触发词以激活正确的微代理
2. **遵循代理准则**:每个代理都有特定的指令和限制 - 遵守这些准则以获得最佳结果
3. **API 优先方法**:如果可用,使用 API 端点而不是网页界面
4. **自动化友好**:设计适合非交互式环境的命令
## 集成
微代理自动集成到 OpenHands 的工作流程中。它们:
- 监视传入的命令是否包含触发词
- 在检测到相关触发词时激活
- 应用其专门的知识和能力
- 遵循其特定的准则和限制
## 使用示例
```bash
# GitHub 代理示例
git checkout -b feature-branch
git commit -m "Add new feature"
git push origin feature-branch
# NPM 代理示例
yes | npm install package-name
```
有关特定代理的更多信息,请参阅微代理目录中的各个文档文件。
## 贡献微代理
要为 OpenHands 贡献新的微代理,请遵循以下准则:
### 1. 规划你的微代理
在创建微代理之前,请考虑:
- 它将解决什么具体问题或用例?
- 它应该具有什么独特的能力或知识?
- 什么触发词适合激活它?
- 它应该遵循什么约束或准则?
### 2. 文件结构
`openhands/agenthub/codeact_agent/micro/` 中创建一个新的 Markdown 文件,文件名要有描述性(例如,`docker.md` 用于专注于 Docker 的代理)。
### 3. 必需组件
你的微代理文件必须包括:
1. **Front Matter**:文件开头的 YAML 元数据:
```markdown
---
name: your_agent_name
agent: CodeActAgent
triggers:
- trigger_word1
- trigger_word2
---
```
2. **指令**:明确、具体的代理行为准则:
```markdown
你负责 [特定任务/领域]。
主要职责:
1. [职责 1]
2. [职责 2]
准则:
- [准则 1]
- [准则 2]
使用示例:
[示例 1]
[示例 2]
```
### 4. 微代理开发的最佳实践
1. **明确范围**:让代理专注于特定领域或任务
2. **明确指令**:提供清晰、明确的指引
3. **有用的示例**:包括常见用例的实际示例
4. **安全第一**:包括必要的警告和约束
5. **集成意识**:考虑代理如何与其他组件交互
### 5. 测试你的微代理
在提交之前:
1. 用各种提示测试代理
2. 验证触发词是否正确激活代理
3. 确保指令清晰全面
4. 检查与现有代理的潜在冲突
### 6. 示例实现
这是一个新微代理的模板:
```markdown
---
name: docker
agent: CodeActAgent
triggers:
- docker
- container
---
你负责 Docker 容器管理和 Dockerfile 创建。
主要职责:
1. 创建和修改 Dockerfile
2. 管理容器生命周期
3. 处理 Docker Compose 配置
准则:
- 尽可能使用官方基础镜像
- 包括必要的安全考虑
- 遵循 Docker 最佳实践进行层优化
示例:
1. 创建 Dockerfile
```dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]
```
2. Docker Compose 用法:
```yaml
version: '3'
services:
web:
build: .
ports:
- "3000:3000"
```
记住要:
- 验证 Dockerfile 语法
- 检查安全漏洞
- 优化构建时间和镜像大小
```
### 7. 提交流程
1. 在正确的目录中创建你的微代理文件
2. 全面测试
3. 提交包含以下内容的拉取请求:
- 新的微代理文件
- 更新文档(如果需要)
- 代理的目的和功能说明
请记住,微代理是在特定领域扩展 OpenHands 功能的强大方式。设计良好的代理可以显著提高系统处理专门任务的能力。

View File

@@ -0,0 +1,43 @@
以下是翻译后的内容:
# 提示最佳实践
在使用 OpenHands AI 软件开发者时,提供清晰有效的提示至关重要。本指南概述了创建提示的最佳实践,以产生最准确和最有用的响应。
## 好的提示的特点
好的提示应该:
1. **具体**: 它们准确解释应该添加什么功能或需要修复什么错误。
2. **位置特定**: 如果已知,它们解释了应该修改代码库中的哪些位置。
3. **适当范围**: 它们应该是单个功能的大小,通常不超过100行代码。
## 示例
### 好的提示示例
1. "在 `utils/math_operations.py` 中添加一个函数 `calculate_average`,它接受一个数字列表作为输入并返回它们的平均值。"
2. "修复 `frontend/src/components/UserProfile.tsx` 第42行发生的 TypeError。错误表明我们试图访问 undefined 的属性。"
3. "为注册表单中的电子邮件字段实现输入验证。更新 `frontend/src/components/RegistrationForm.tsx` 以在提交之前检查电子邮件是否为有效格式。"
### 不好的提示示例
1. "让代码变得更好。"(太模糊,不具体)
2. "用不同的框架重写整个后端。"(范围不合适)
3. "用户身份验证中有一个错误。你能找到并修复它吗?"(缺乏具体性和位置信息)
## 有效提示的技巧
1. 尽可能具体地说明所需的结果或要解决的问题。
2. 提供上下文,包括相关的文件路径和行号(如果可用)。
3. 将大型任务分解为更小、更易管理的提示。
4. 包括任何相关的错误消息或日志。
5. 如果从上下文中不明显,请指定编程语言或框架。
请记住,您的提示越精确和信息量大,AI 就越能帮助您开发或修改 OpenHands 软件。
有关更多有用提示的示例,请参阅[OpenHands 入门](../getting-started)。

View File

@@ -0,0 +1,76 @@
# 运行时配置
运行时是 OpenHands 代理可以编辑文件和运行命令的环境。
默认情况下OpenHands 使用基于 Docker 的运行时,在您的本地计算机上运行。这意味着您只需要为使用的 LLM 付费,并且您的代码只会发送到 LLM。
我们还支持"远程"运行时,通常由第三方管理。它们可以使设置更简单、更具可扩展性,特别是当您并行运行多个 OpenHands 对话时(例如进行评估)。
## Docker 运行时
这是启动 OpenHands 时使用的默认运行时。您可能会注意到传递给 `docker run` 的一些标志使这成为可能:
```
docker run # ...
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-v /var/run/docker.sock:/var/run/docker.sock \
# ...
```
来自 nikolaik 的 `SANDBOX_RUNTIME_CONTAINER_IMAGE` 是一个预构建的运行时镜像,其中包含我们的运行时服务器,以及一些用于 Python 和 NodeJS 的基本实用程序。您也可以[构建自己的运行时镜像](how-to/custom-sandbox-guide)。
### 连接到您的文件系统
这里一个有用的功能是能够连接到您的本地文件系统。
要将文件系统挂载到运行时,首先设置 WORKSPACE_BASE
```bash
export WORKSPACE_BASE=/path/to/your/code
# Linux 和 Mac 示例
# export WORKSPACE_BASE=$HOME/OpenHands
# 将 $WORKSPACE_BASE 设置为 /home/<username>/OpenHands
#
# Windows 上的 WSL 示例
# export WORKSPACE_BASE=/mnt/c/dev/OpenHands
# 将 $WORKSPACE_BASE 设置为 C:\dev\OpenHands
```
然后将以下选项添加到 `docker run` 命令中:
```bash
docker run # ...
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
# ...
```
请小心!没有任何措施可以阻止 OpenHands 代理删除或修改挂载到其工作区的任何文件。
此设置可能会导致一些文件权限问题(因此有 `SANDBOX_USER_ID` 变量),但似乎在大多数系统上都能很好地工作。
## All Hands 运行时
All Hands 运行时目前处于测试阶段。您可以通过加入 Slack 上的 #remote-runtime-limited-beta 频道来请求访问权限([请参阅自述文件](https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file#-join-our-community)以获取邀请)。
要使用 All Hands 运行时,请在启动 OpenHands 时设置以下环境变量:
```bash
docker run # ...
-e RUNTIME=remote \
-e SANDBOX_REMOTE_RUNTIME_API_URL="https://runtime.app.all-hands.dev" \
-e SANDBOX_API_KEY="your-all-hands-api-key" \
-e SANDBOX_KEEP_RUNTIME_ALIVE="true" \
# ...
```
## Modal 运行时
我们在 [Modal](https://modal.com/) 的合作伙伴也为 OpenHands 提供了一个运行时。
要使用 Modal 运行时,请创建一个帐户,然后[创建一个 API 密钥](https://modal.com/settings)。
然后,您需要在启动 OpenHands 时设置以下环境变量:
```bash
docker run # ...
-e RUNTIME=modal \
-e MODAL_API_TOKEN_ID="your-id" \
-e MODAL_API_TOKEN_SECRET="your-secret" \
```

View File

@@ -0,0 +1,43 @@
# 🚧 故障排除
:::tip
OpenHands 仅通过 WSL 支持 Windows。请确保在 WSL 终端内运行所有命令。
:::
### 启动 Docker 客户端失败
**描述**
运行 OpenHands 时,出现以下错误:
```
Launch docker client failed. Please make sure you have installed docker and started docker desktop/daemon.
```
**解决方案**
请按顺序尝试以下步骤:
* 确认 `docker` 正在您的系统上运行。您应该能够在终端中成功运行 `docker ps`
* 如果使用 Docker Desktop请确保 `Settings > Advanced > Allow the default Docker socket to be used` 已启用。
* 根据您的配置,您可能需要在 Docker Desktop 中启用 `Settings > Resources > Network > Enable host networking`
* 重新安装 Docker Desktop。
---
# 开发工作流程特定问题
### 构建运行时 Docker 镜像时出错
**描述**
尝试启动新会话失败,并且日志中出现以下术语的错误:
```
debian-security bookworm-security
InRelease At least one invalid signature was encountered.
```
当现有外部库的哈希值发生变化且本地 Docker 实例缓存了先前版本时,似乎会发生这种情况。要解决此问题,请尝试以下操作:
* 停止名称以 `openhands-runtime-` 为前缀的任何容器:
`docker ps --filter name=openhands-runtime- --filter status=running -aq | xargs docker stop`
* 删除名称以 `openhands-runtime-` 为前缀的任何容器:
`docker rmi $(docker images --filter name=openhands-runtime- -q --no-trunc)`
* 停止并删除名称以 `openhands-runtime-` 为前缀的任何容器/镜像
* 清理容器/镜像:`docker container prune -f && docker image prune -f`

View File

@@ -0,0 +1,62 @@
以下是翻译后的内容:
# ⬆️ 升级指南
## 0.8.0 (2024-07-13)
### 配置中的重大变更
在此版本中,我们对后端配置引入了一些重大变更。如果你只通过前端(Web GUI)使用OpenHands,则无需处理任何事情。
以下是配置中重大变更的列表。它们仅适用于通过 `main.py` 使用 OpenHands CLI 的用户。更多详情,请参阅 [#2756](https://github.com/All-Hands-AI/OpenHands/pull/2756)。
#### 从 main.py 中移除 --model-name 选项
请注意,`--model-name``-m` 选项已不再存在。你应该在 `config.toml` 中设置 LLM 配置,或通过环境变量进行设置。
#### LLM 配置组必须是 'llm' 的子组
在 0.8 版本之前,你可以在 `config.toml` 中为 LLM 配置使用任意名称,例如:
```toml
[gpt-4o]
model="gpt-4o"
api_key="<your_api_key>"
```
然后使用 `--llm-config` CLI 参数按名称指定所需的 LLM 配置组。这已不再有效。相反,配置组必须位于 `llm` 组下,例如:
```toml
[llm.gpt-4o]
model="gpt-4o"
api_key="<your_api_key>"
```
如果你有一个名为 `llm` 的配置组,则无需更改它,它将被用作默认的 LLM 配置组。
#### 'agent' 组不再包含 'name' 字段
在 0.8 版本之前,你可能有或没有一个名为 `agent` 的配置组,如下所示:
```toml
[agent]
name="CodeActAgent"
memory_max_threads=2
```
请注意,`name` 字段现已被移除。相反,你应该在 `core` 组下放置 `default_agent` 字段,例如:
```toml
[core]
# 其他配置
default_agent='CodeActAgent'
[agent]
llm_config='llm'
memory_max_threads=2
[agent.CodeActAgent]
llm_config='gpt-4o'
```
请注意,与 `llm` 子组类似,你也可以定义 `agent` 子组。此外,代理可以与特定的 LLM 配置组相关联。更多详情,请参阅 `config.template.toml` 中的示例。

View File

@@ -0,0 +1,26 @@
{
"title": {
"message": "OpenHands",
"description": "The title in the navbar"
},
"logo.alt": {
"message": "OpenHands",
"description": "The alt text of navbar logo"
},
"item.label.Docs": {
"message": "文档",
"description": "Navbar item with label Docs"
},
"item.label.Codebase": {
"message": "代码库",
"description": "Navbar item with label Codebase"
},
"item.label.FAQ": {
"message": "常见问题",
"description": "Navbar item with label FAQ"
},
"item.label.GitHub": {
"message": "GitHub",
"description": "Navbar item with label GitHub"
}
}

18787
docs/package-lock.json generated Normal file

File diff suppressed because it is too large Load Diff

51
docs/package.json Normal file
View File

@@ -0,0 +1,51 @@
{
"name": "docs",
"version": "0.0.0",
"private": true,
"scripts": {
"docusaurus": "docusaurus",
"start": "docusaurus start",
"build": "docusaurus build",
"swizzle": "docusaurus swizzle",
"deploy": "docusaurus deploy",
"clear": "docusaurus clear",
"serve": "docusaurus serve",
"write-translations": "docusaurus write-translations",
"write-heading-ids": "docusaurus write-heading-ids",
"typecheck": "tsc"
},
"dependencies": {
"@docusaurus/core": "^3.7.0",
"@docusaurus/plugin-content-pages": "^3.7.0",
"@docusaurus/preset-classic": "^3.7.0",
"@docusaurus/theme-mermaid": "^3.7.0",
"@mdx-js/react": "^3.1.0",
"clsx": "^2.0.0",
"prism-react-renderer": "^2.4.1",
"react": "^19.0.0",
"react-dom": "^19.0.0",
"react-icons": "^5.4.0",
"react-use": "^17.6.0"
},
"devDependencies": {
"@docusaurus/module-type-aliases": "^3.5.1",
"@docusaurus/tsconfig": "^3.7.0",
"@docusaurus/types": "^3.5.1",
"typescript": "~5.7.3"
},
"browserslist": {
"production": [
">0.5%",
"not dead",
"not op_mini all"
],
"development": [
"last 3 chrome version",
"last 3 firefox version",
"last 5 safari version"
]
},
"engines": {
"node": ">=18.0"
}
}

View File

@@ -0,0 +1,13 @@
export default function tailwindPlugin(context, options) {
return {
name: 'tailwind-plugin',
configurePostCss(postcssOptions) {
postcssOptions.plugins = [
require('postcss-import'),
require('tailwindcss'),
require('autoprefixer'),
];
return postcssOptions;
},
};
}

13
docs/sidebars.ts Normal file
View File

@@ -0,0 +1,13 @@
import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";
const sidebars: SidebarsConfig = {
docsSidebar: [
{
type: 'doc',
label: 'Welcome to MetaChain',
id: 'usage/welcome-to-metachain',
}
],
};
export default sidebars;

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