Installation

Crew est distribué sous forme de paquet Python qui regroupe le tableau de bord React. Il existe quatre façons de l'installer; choisissez celle qui convient le mieux à votre façon de l'exécuter. Toutes les versions sont construites avec de simples pip + npm/Vite + pytest. Aucun outillage propriétaire.

Crew fait fonctionner un LLM par l'intermédiaire de kiro-cli via le Agent Client Protocol. C'est le seul fournisseur (agent.provider = acp). Le tableau de bord guide la configuration et la connexion de Kiro CLI avant l'ouverture du clavardage. kirocrew doctor indique si le binaire est trouvé et si la connexion est établie.

Si le Gateway détecte une Kiro CLI sans la commande acp requise, la configuration s'arrête à Mise à jour de Kiro CLI requise. Sélectionnez Mettre à jour Kiro CLI pour exécuter kiro-cli update sur l'hôte Gateway, puis relancez la vérification.

La mémoire sémantique ne nécessite aucune configuration. Les intégrations s'exécutent dans le même processus et le Gateway télécharge son modèle d'intégration (~610 Mo) en arrière-plan au premier démarrage, le vérifie et le stocke sous ~/.kiro/crew/models. Jusqu'à ce que le modèle soit en place, la recherche en mémoire se replie sur la correspondance par mots-clés et adopte automatiquement les intégrations sans redémarrage. Définissez KIROCREW_EMBED_MODEL_URL pour pointer vers un miroir pour les installations en réseau isolé.

Crew prend en charge Windows nativement. Le programme d'installation signé est le chemin le plus simple; un dépôt source peut utiliser CPython 3.12, un environnement virtuel et pip install -e . tzdata.

py -3.12 -m venv .venv
.venv\Scripts\activate
pip install -e . tzdata
python -m kiro_crew gateway

Le démarrage à froid du Gateway Windows est nettement plus rapide dans la version 0.7. Computer Use fonctionne via UI Automation, et les pods isolés s'exécutent par l'intermédiaire du Planificateur de tâches lorsque l'utilisateur actuel peut créer une tâche planifiée. Consultez la référence de la CLI pour les commandes de pod; pod api est la seule commande de pod indisponible sous Windows, car son canal de requêtes privé dépend d'un socket de domaine Unix. Utilisez pod token et l'URL affichée avec votre propre client HTTP à la place.

Le programme d'installation signé se met à jour sur place et relance la nouvelle version. Le terminal Web interactif et le PTY de connexion utilisent leur implémentation propre à la plateforme ou signalent clairement un état non pris en charge plutôt que d'échouer silencieusement.

Les installations de bureau et gérées affichent les mises à jour dans Settings → About, la boîte de dialogue de mise à jour et Nouveautés. Lorsque l'approbation de l'hôte est requise, chaque surface affiche la même commande et le temps restant dans la fenêtre d'approbation.

Le Gateway vérifie les mises à jour du source au démarrage et toutes les douze heures. L'application automatique met d'abord en pause l'admission de nouveaux tours, puis attend que les tours actifs, les exécutions planifiées, les sous-agents, les étapes du Task Runner et les flux de travail deviennent inactifs. Elle ne s'applique qu'après que ce travail s'est stabilisé; une charge de travail active reporte la mise à jour plutôt que de l'annuler.

Avant de déplacer le dépôt, Crew vérifie que la révision cible prend en charge l'interpréteur Python dans l'environnement virtuel actuel. Une incompatibilité est refusée avec l'environnement et le chemin de l'interpréteur nommés — un Python en dessous du plancher 3.12 est rejeté catégoriquement. Un dépôt sale ou divergé est également refusé plutôt que réinitialisé.

Exécutez une mise à jour manuellement si nécessaire :

kirocrew update

Pour les installations par wheel et cli.sh, le programme de mise à jour installe dans une arborescence fraîche dont la signature est vérifiée et y bascule de façon atomique. Les images Docker restent immuables; extrayez une balise plus récente et recréez le conteneur comme décrit dans Exécution 24 h/24, 7 j/7.

Lorsque Crew modifie une valeur par défaut entre deux versions, votre configuration enregistrée peut encore conserver l'ancienne valeur par défaut. Exécutez kirocrew config defaults pour répertorier les valeurs enregistrées qui utilisent toujours des valeurs par défaut remplacées. Utilisez --adopt pour adopter les valeurs par défaut actuelles ou --keep pour enregistrer les valeurs stockées comme intentionnelles.

Cela s'applique après une mise à niveau, particulièrement si le modèle vocal stt_model ou les paramètres de bac à sable ont été définis par une version antérieure.

Pour les installations par wheel en une seule ligne, à partir des sources et Docker, configurez et vérifiez après l'installation :

kirocrew setup            # interactive wizard: data dir, agent, credentials
kirocrew doctor           # verify everything is wired up
kirocrew gateway          # start the server → http://localhost:5476

kirocrew doctor indique l'état du binaire kiro-cli, son authentification, Ollama/intégrations, les jetons Slack, la validité de la configuration et les serveurs MCP.

Tout l'état persistant se trouve sous ~/.kiro/crew/ (à remplacer par KIROCREW_HOME) :

~/.kiro/crew/
├── config.json          # user configuration
├── .env                 # Slack tokens, owner ID, other credentials
├── workspace/
│   ├── memory/          # preferences.md, projects.md, history/
│   ├── lessons.jsonl    # learned corrections
│   └── knowledge/       # ingested documents (FTS5 + vectors)
├── conversations/       # JSONL session logs
├── crons.json           # scheduled jobs
├── audit.log            # bash command audit trail
└── agents/              # generated kiro-cli agent configs

KIROCREW_HOME et KIROCREW_PORT sont tous deux validés à l'entrée de la CLI, et non stockés comme clés de configuration. Passez --port sur la CLI pour remplacer la variable d'environnement à chaque invocation.

Installez avec pip install "kirocrew[<extra>]" :

Piper TTS est le fournisseur de synthèse vocale par défaut et s'exécute localement — aucune installation supplémentaire n'est nécessaire.