DopeAgent
Développement actifUn OS d’agents personnel — un daemon local, de nombreux clients légers.
Un plan de contrôle en Rust s’exécute localement et prend en charge le runtime, les fournisseurs de LLM, les connecteurs de canaux, le stockage et les événements. Les clients restent légers : une interface web React, une TUI Rust plein écran, des connecteurs de messagerie et un SDK TypeScript — tous fondés sur les mêmes contrats JSON Schema.
Vue d’ensemble
Le daemon est le produit. Tout ce qui doit être juste — l’état de session, le routage des fournisseurs, le harness d’outils, le journal d’événements — vit dans un seul workspace Rust derrière une API HTTP locale ; un client n’est jamais qu’une vue sur celui-ci. Le binaire du daemon est `dope-cli`, l’API HTTP est `dope-api`.
Les contrats inter-langages se trouvent dans `schemas/` sous forme de JSON Schema et font autorité pour l’API, les événements et la configuration : le daemon Rust et les clients TypeScript sont générés à partir des mêmes définitions plutôt que synchronisés par convention.
Une hypothèse de travail assumée : l’état d’agent de longue durée doit être observable, rejouable et pouvoir évoluer sans risque. L’ingénierie du contexte, la mémoire, la planification, les passations et les politiques sont repensées plutôt que rafistolées.
Ce qu’il fait
- Plan de contrôle Rust : runtime, fournisseurs de LLM, canaux et connecteurs, stockage, événements, API HTTP et harness dans un seul workspace.
- Trois surfaces au-dessus d’un même daemon : interface web React 19 + Vite, TUI Rust plein écran (`dope-tui`) et connecteurs de messagerie.
- SDK client TypeScript (`@dope/client`) généré à partir des contrats JSON Schema partagés.
- Environnements de test et de production séparés — `~/.dope-test` sur le port 19192 contre `~/.dope` sur 19191, les connecteurs réels étant désactivés par défaut en test.
- L’ancien daemon Go a été entièrement remplacé par le workspace Rust ; la migration est consignée dans `crates/MIGRATION.md`.