Je pars du principe que vous savez déjà faire dire à un LLM des choses intelligentes sur une action. N'importe quel type peut le faire. Ce n'est pas le boulot.
Le boulot, c'est le harnais, la couche autour du modèle qui décide si votre analyste est un bureau de confiance ou un générateur de nombres aléatoires avec une bonne grammaire. Le modèle est la pièce la plus interchangeable de tout l'ensemble.

Trois parties :
- Comment le faire fonctionner correctement
- Comment l'éduquer en machine financière (le vrai avantage)
- Les dépôts et services qui l'étendent.
Lisez la partie du milieu deux fois.
Pas un conseil financier. Faites vos propres recherches. Mon propre projet - @coldvisionXYZ
PARTIE 1 : FAITES-LE FONCTIONNER, ET COMPRENEZ CE QUE VOUS FAITES FONCTIONNER
Une ligne. Elle provisionne python, node, git, tout, dans ~/.hermes/ :
1curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
Linux, macOS, WSL2, Android via Termux (auto-détecté), Windows natif (bêta précoce, pas besoin de WSL). Python 3.11+. Ensuite hermes setup pour l'assistant, ou hermes model / hermes tools / hermes gateway setup pièce par pièce. Exécutez-le avec hermes (CLI classique) ou hermes --tui (recommandé).
L'abstraction du fournisseur est le superpouvoir discret
Le même runtime pilote les API chat-completions, Anthropic Messages, Codex Responses, un chemin de serveur d'applications Codex hors processus, et Bedrock.
Les formats d'appels d'outils et les particularités des fournisseurs sont normalisés par des adaptateurs de transport, de sorte qu'au niveau de la boucle, la surface du modèle semble identique, quel que soit ce qui se cache derrière.
Cela signifie que le basculement entre fournisseurs est réel, et que l'échange de modèles est véritablement sans code.
Conséquence pratique pour votre portefeuille : vous n'exécutez pas un seul modèle.
Sous auxiliary dans config.yaml, chaque tâche secondaire, exécution du curateur, vision, embeddings, génération de titres, recherche de session, le résumé de compression, peut épingler son propre fournisseur, modèle, base_url et effort de raisonnement.
Ainsi, votre modèle de raisonnement coûteux ne brûle jamais de jetons à résumer de vieux chats ou à nommer une session.
Il y a aussi smart_model_routing pour envoyer les tours difficiles au modèle fort et tout le reste à un modèle bon marché.
La configuration la plus économique et sensée : Nous Portal (un abonnement, 300+ modèles + la Tool Gateway pour le web/navigateur/image/TTS) comme fournisseur principal, un modèle bon marché épinglé pour tout le travail auxiliaire, Ollama/vLLM local comme solution de repli gratuite. Si vous optez pour le local, Ollama utilise par défaut un contexte de 4k et tronque silencieusement, définissez num_ctx à 64k+ ou l'agent deviendra stupide et vous blâmerez le modèle.
La chose que vous devez comprendre avant de toucher à la configuration : le prompt est en forme de cache
C'est l'invariant sur lequel tout le système est construit, et si vous ne le comprenez pas, vous allez silencieusement multiplier votre facture par 10.
Hermes compose le prompt système en trois niveaux :
- stable
- contexte
- volatil

Le niveau stable porte l'identité (SOUL.md), les instructions d'outils pour les outils activés uniquement, l'index des compétences, les indices d'environnement. Le contexte est dérivé du répertoire de travail actuel. Le niveau volatil change tour par tour. La hiérarchisation est explicite dans le code pour une seule raison : la validité du cache de préfixe du prompt. Les fournisseurs mettent en cache le préfixe de votre prompt et facturent les jetons en cache à une fraction. Chaque fois que le niveau stable change, vous cassez ce cache et payez le plein tarif sur tout.
Donc Hermes traite la modification du contexte comme presque sacrée. D'après les propres règles d'ingénierie de l'agent : la seule fois où il modifie délibérément le contexte, c'est lors de la compression. Les commandes slash qui modifient l'état du prompt système (installation d'une compétence, activation/désactivation d'un outil) utilisent par défaut une invalidation différée : la modification prend effet à la prochaine session, avec un drapeau --now lorsque vous en avez vraiment besoin en direct. /skills install --now est le modèle canonique "J'accepte la rupture de cache".
Pourquoi cela vous concerne en tant qu'analyste : chaque compétence que vous activez et chaque outil que vous allumez vit dans ce niveau stable et coûte des jetons de préfixe à chaque appel. Un agent gonflé avec 60 outils activés paie pour les 60 descriptions à chaque tour pour toujours. Des ensembles d'outils légers et des compétences à la demande ne sont pas une question de propreté, c'est le modèle de coût.
La compression est une lignée, pas une troncature
Lorsque le contexte se remplit, les agents naïfs suppriment les anciens tours et souffrent d'amnésie.
Hermes exécute deux couches de compression indépendantes :
- un filet de sécurité "hygiène de session" de la passerelle qui se déclenche autour de 85 % du contexte sur une estimation approximative avant même que l'agent ne s'exécute
- la vraie, le ContextCompressor dans la boucle qui se déclenche autour de 50 % en utilisant des comptes de jetons précis rapportés par l'API.
Il résume les tours intermédiaires en un nouveau message plutôt que de les supprimer, et les sessions suivent la lignée parent-enfant pour chaque division de compression. Le résumé fait partie de la transcription ; l'original est conservé dans la lignée

La perte est acceptable, la conservation sans perte ferait exploser la mémoire.
Les sessions sont une infrastructure, pas seulement des transcriptions.
Elles portent des balises de source et des métadonnées de routage, et il y a un outil session_search accessible au modèle ainsi qu'un index SQLite FTS5 sur chaque tour passé. Votre agent peut se rappeler "qu'est-ce que j'ai conclu à propos de COIN il y a trois semaines" en cours de raisonnement, non pas parce que vous l'avez fourré dans le contexte, mais parce qu'il peut interroger sa propre histoire à la demande.
Où il s'exécute
Six terminaux dorsaux :
- local
- Docker
- SSH
- Singularity
- Modal
- Daytona
Modal et Daytona sont sans serveur, l'environnement hiberne lorsqu'il est inactif et se réveille à la demande, ne coûtant presque rien entre les exécutions.
Un VPS à 5 $ ou une boîte sans serveur en hibernation est le véritable "5 $". Connectez la passerelle et le même agent fonctionne sur plus de 20 plateformes (Telegram, Discord, Slack, Signal, …) sur un routage de session unifié, de sorte que vous lui parlez depuis votre téléphone pendant qu'il travaille sur la boîte cloud.
Les sessions survivent aux redémarrages via SQLite en mode WAL avec une couche de réessai personnalisée pour les conflits d'écriture multi-processus, de sorte que les tâches cron et le travail de passerelle ne se corrompent pas mutuellement.
PARTIE 2 - ÉDUQUEZ-LE EN MACHINE FINANCIÈRE
Un agent brut est un stagiaire brillant sans formation dans le domaine et sans discipline de jugement. Vous l'éduquez littéralement à travers quatre canaux : l'identité, les playbooks, la mémoire et les normes. Ensuite, il s'auto-éduque, et votre vrai travail devient la curation.
2a. L'identité - SOUL.md est l'emplacement n°1
SOUL.md est littéralement la première chose dans le prompt système, avant les outils, avant les compétences, avant tout. C'est la couche de la personnalité et des valeurs.
Pour un analyste financier, c'est là que vous définissez le tempérament épistémique, pas des fioritures de personnalité.
Des choses comme : "Vous êtes un analyste acheteur sceptique. Vous vous méfiez des chiffres ronds et des récits. Vous ne déclarez jamais un chiffre que vous n'avez pas extrait d'un outil de cette session.
Vous préférez dire 'données insuffisantes' plutôt que de deviner. Vous traitez vos propres conclusions antérieures comme des a priori à mettre à jour"
Cela se trouve dans le niveau stable du cache et colore chaque tour gratuitement. La plupart des gens laissent SOUL.md par défaut. Pour un analyste, ce sont vos 1 500 caractères les plus efficaces.
2b. Les playbooks - les compétences, et pourquoi la description est la véritable ingénierie
Une compétence est un SKILL.md, nom + description + procédure, stocké dans ~/.hermes/skills/.
Seules les descriptions courtes se trouvent dans l'index des compétences toujours chargé.
La procédure complète se charge à la demande lorsqu'une tâche correspond. Ainsi, votre bibliothèque de compétences peut être immense sans gonfler le préfixe.
Ce qui signifie que la description est l'endroit où la compétence réussit ou échoue.
C'est un routeur. Si la description est vague, l'agent ne charge jamais la compétence quand il le devrait, ou la charge quand il ne le devrait pas. Écrivez les descriptions comme des conditions de déclenchement, pas des résumés.
"Utiliser quand l'utilisateur nomme une action cotée aux États-Unis et veut une lecture fondamentale" bat "analyse les actions."
Une compétence d'analyste réelle, notez les normes de la partie 2d intégrées directement dans la procédure :
1---2name: zoom-equity3description: Utiliser quand l'utilisateur nomme un ticker coté aux États-Unis et veut une lecture fondamentale + de prix avec des indicateurs de risque.4---56# Zoom sur une action781. Résoudre le ticker -> CIK via la carte company_tickers de la SEC. NE JAMAIS deviner un ticker.92. Récupérer les derniers 10-K/10-Q (revenus, dette, FCF) via EDGAR. Enregistrer le numéro d'accession.103. NE JAMAIS calculer les ratios vous-même. Appeler l'outil de calcul pour le P/E, les marges, l'annuel.114. Recouper les revenus sur deux sources. S'ils ne sont pas d'accord, SIGNALER l'écart, ne pas en choisir un.125. Résultat : thèse (2 lignes), 3 catalyseurs, 3 risques, lecture de la valorisation, confiance de 0 à 1,13 et "quel point de données inverserait cela". Si les données sont maigres, renvoyer "passer".
Les compétences prennent en charge l'activation/désactivation par plateforme, l'activation conditionnelle basée sur la disponibilité des outils et la validation des prérequis, de sorte qu'une compétence peut déclarer "disponible uniquement si l'outil EDGAR est présent".
Le format est le standard ouvert agentskills.io, donc ce que vous écrivez est portable vers d'autres agents compatibles.
2c. La boucle d'auto-amélioration, et la maintenance
L'agent écrit ses propres compétences.
Après avoir résolu quelque chose par essais et erreurs (généralement une tâche avec plusieurs appels d'outils), il enregistre l'approche fonctionnelle sous forme de SKILL.md dans agent_created/.
L'outil de gestion des compétences a six actions et celle à connaître est patch : une correction ciblée, préférée aux réécritures complètes car elle est efficace en termes de jetons.
L'agent affine littéralement ses propres playbooks en place pendant l'utilisation.
Sans maintenance, les compétences auto-générées métastasent.
Vous vous retrouvez avec des dizaines de playbooks étroits et qui se chevauchent, brûlant des jetons de préfixe et polluant le routeur.

Le Curateur s'en charge, et ses mécanismes méritent d'être connus. Ce n'est pas un démon cron, il s'exécute sur une vérification d'inactivité : environ quand 7 jours se sont écoulés depuis sa dernière exécution et que l'agent est inactif depuis 2 heures ou plus, un fork en arrière-plan démarre avec son propre cache de prompt, ne touchant jamais la conversation active, et exécute une boucle de révision LLM qui archive automatiquement les compétences obsolètes (dans .archive/, restaurables, rien n'est jamais perdu).
La configuration se trouve sous curator dans config.yaml : interval_hours, min_idle_hours, stale_after_days, archive_after_days.
Traitez les compétences auto-générées comme des brouillons de stagiaire. hermes curator review pour les examiner, épinglez celles qui sont vraiment bonnes pour qu'elles survivent, laissez le reste être archivé. Curation de cette boucle est l'éducation.
Un agent non curaté empire avec le temps, ne s'améliore pas.
2d. Les normes - la discipline, classée par combien elle vous fait économiser
Ce sont les règles que vous intégrez dans SOUL.md et chaque SKILL.md. Par ordre d'impact.
1. Interdire l'arithmétique. Les LLM prédisent des jetons. C'est la source numéro un de chiffres erronés avec confiance. L'implémentation propre utilise execute_code (couvert dans 2e) de sorte qu'un script déterministe fasse le calcul et que le modèle ne décide que des entrées et interprète les sorties.
Un DCF que le modèle a "estimé" est une fiction ; un qu'un script a calculé et que le modèle a testé sous contrainte est un produit.
2. Reçus pour chaque chiffre. Chaque nombre revient avec sa source et sa date associée, jamais nu. Le moteur de rendu supprime tout ce qui n'a pas de reçu.
Le gain est adversarial : lorsque deux sources ne sont pas d'accord, le désaccord est le signal.
3. Ponctuel uniquement. Le biais de regard en arrière est le tueur silencieux de chaque backtest et de chaque capture d'écran "il l'a prédit". Les API servent par défaut des données retraitées et actuelles.
Étiquetez les faits avec des dates de référence et verrouillez l'agent sur ce qui était connaissable à la date de décision.
4. Adversarial par construction. Un sous-agent construit le scénario haussier, un second reçoit l'ordre de le tuer, un troisième réconcilie avec une confiance déclarée. La valeur réside entièrement dans le fait que les objectifs sont véritablement opposés, pas dans le nombre d'agents.
Les modèles neutres comptent ici car ils défendront le scénario baissier avec vigueur au lieu de le diluer dans du flou.
5. Autorisation de s'abstenir. Imposez "quel point de données inverserait cela" à chaque appel.
Si ce sont des données que l'agent n'a pas, la réponse est pas de position.
2e. La manœuvre avancée : l'appel d'outils programmatique réduit les pipelines à un coût de contexte nul
C'est la fonctionnalité qui, une fois comprise, change la façon dont vous construisez chaque flux de travail d'analyste.
Normalement, un pipeline en plusieurs étapes brûle un tour LLM par étape : "je vais chercher… maintenant je vais lire… maintenant je vais résumer… maintenant je vais écrire."
Chaque étape mécanique coûte des jetons d'inférence et pollue le contexte avec des déchets intermédiaires.
execute_code tue cela
L'agent écrit un script Python qui appelle les propres outils d'Hermes via un RPC sur socket de domaine Unix. Le script s'exécute dans un processus enfant ; les appels d'outils voyagent sur le socket de retour vers le parent et sont dispatchés via le même gestionnaire que les appels d'outils normaux.
De manière cruciale : seule la sortie print() du script revient au modèle. Les résultats intermédiaires des outils n'entrent jamais dans la fenêtre de contexte.
1# l'agent écrit ceci UNE FOIS ; le modèle n'est impliqué qu'au point de décision2from hermes_tools import edgar_fetch, market_price, calc34tickers = ["TSLA", "NVDA", "COIN"]5rows = []6for t in tickers:7 f = edgar_fetch(t, form="10-Q") # appel d'outil via RPC8 px = market_price(t) # appel d'outil via RPC9 pe = calc("pe", price=px["last"], eps=f["eps"]) # calcul déterministe, pas le LLM10 rows.append({"ticker": t, "pe": pe, "src": f["accession"], "as_of": f["period_end"]})1112print(rows) # SEULEMENT cela entre dans la fenêtre de contexte
Pour un analyste financier, c'est énorme.
Un balayage matinal sur 20 tickers avec trois appels d'outils chacun représente 60 appels d'outils qui, faits de manière conventionnelle, feraient exploser votre contexte et votre budget de jetons.
En tant que script, c'est un seul tour, un seul tableau propre imprimé, les calculs faits de manière déterministe en ligne. Vous pliez des pipelines entiers en une seule inférence et le modèle ne pense qu'aux points qui nécessitent réellement un jugement. Construisez vos flux de travail d'analyste récurrents sous forme de scripts execute_code encapsulés dans des compétences. (Linux/macOS uniquement, cela nécessite des sockets de domaine Unix.)
2f. La mémoire - faits vs. modèle utilisateur
La mémoire d'Hermes est composée de trois mécanismes orthogonaux (le cadre "3 couches" est une simplification pédagogique, dans le code ils sont indépendants) :
- MEMORY.md - faits durables. Limite d'environ 2 200 caractères.
- USER.md - le modèle de vous. Limite d'environ 1 375 caractères.
- SessionDB - SQLite, WAL, FTS5 sur chaque tour passé, interrogé via session_search.
Un MemoryStore lit MEMORY.md et USER.md une fois au début de la session et les intègre comme un seul bloc immuable dans le prompt système.
L'agent peut écrire dans ces fichiers en milieu de session et les écritures atteignent le disque, mais la copie dans le prompt ne change pas avant la session suivante, car la modifier briserait le cache de préfixe (même invariant qu'ailleurs).
Plus 8 fournisseurs externes optionnels (la modélisation utilisateur dialectique d'Honcho, Mem0, Hindsight, Supermemory…), sélection unique, hermes memory setup.
Les limites de caractères sont une fonctionnalité. Elles vous obligent à garder USER.md comme une infrastructure à fort signal, pas comme un dépotoir.
Pour un analyste, USER.md est votre mandat : tolérance au risque, horizon, les mesures sur lesquelles vous agissez réellement, format de sortie.
MEMORY.md est pour les faits durables que l'agent a mérités ("Les revenus de COIN sont plus proprement liés au 10-K qu'à FMP").
SessionDB comme votre tableau de bord : stockez chaque appel, notez-le par rapport aux résultats, et l'agent met à jour les a priori pendant que vous apprenez son calibrage, où il est précis et où il est chroniquement trop haussier. Cette carte de calibrage est un alpha qu'aucune construction de détail ne prend la peine de collecter.
2g. Quand les prompts ne suffisent pas : GAPA, puis RL
Avant d'envisager le fine-tuning : Hermes dispose de GAPA, une optimisation systématique des prompts pour votre SOUL.md, les instructions de compétence et les prompts système, au lieu de réglages manuels par essais et erreurs.
Essayez-le lorsque les performances stagnent.
Au-delà, Hermes fait de la génération de trajectoires par lots et exporte des traces au format ShareGPT pour le SFT, et il existe un chemin RL (Atropos) pour effectuer un fine-tuning réel du comportement d'appel d'outils sur vos propres trajectoires. C'est le vrai plafond de "l'éduquer", ça se termine par l'entraînement d'un modèle sur la façon dont votre analyste travaille.
PARTIE 3 - ÉTENDEZ-LE : DÉPÔTS, MCP, SERVICES
MCP : séparer l'enregistrement de l'exposition
Ajoutez des serveurs via la CLI ou config.yaml ; l'agent liste leurs outils au démarrage et les enregistre aux côtés des outils intégrés. Discipline clé, en miroir de la logique de cache ci-dessus : utilisez une liste blanche avec tools.include pour n'exposer que ce dont vous avez besoin, car chaque outil exposé coûte des jetons de préfixe et élargit votre surface d'attaque.
1hermes mcp add github --command npx --args "-y,@modelcontextprotocol/server-github"2hermes mcp configure github # basculer chaque outil individuellement
1mcp_servers:2 filesystem:3 command: npx4 args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/you/research"]5 tools: { include: [read_file, list_directory] } # lecture seule, pas d'écriture
/reload-mcp pour appliquer.
Composio MCP est le code de triche : un serveur, des centaines de connexions SaaS ; les gens construisent des agents financiers sur Hermes qui récupèrent des données de marché et écrivent des rapports dans Google Docs entièrement via cela. Et hermes mcp serve fait fonctionner Hermes en tant que serveur MCP, exposant son historique de session pour que Claude Desktop ou Cursor puissent interroger ce que votre analyste a trouvé ; l'agent devient une base de connaissances que vos autres outils lisent.
Les robinets de données (classés : colonne vertébrale vs garniture)
Colonne vertébrale crypto :
DefiLlama
(gratuit, pas de clé, pas de limite de débit réelle, TVL/frais/rendements/prix, la moitié des tableaux de bord payants sont des re-skins)
+ Helius
(roi de Solana, l'analyse de transactions améliorée transforme la soupe d'octets en swaps lisibles).
Garniture :
Birdeye (OHLCV+websocket), Jupiter (routage/devis), Dune+Flipside (SQL on-chain), Bitquery (GraphQL multichain), Nansen/Arkham (étiquettes, payant).
Colonne vertébrale TradFi :
FRED
(Fed de Saint-Louis, macro gratuite au plus fort signal, les données que les desks regardent réellement)
+ edgartools
(MIT, pas de clé, états financiers typés extraits des 10-K avec numéros d'accession).
Garniture :
Finnhub (meilleur niveau gratuit), FMP (ratios pré-calculés), Polygon/Tiingo (historique propre), yfinance (ruban adhésif, casse silencieusement), GDELT (événements d'actualité mondiaux).
Piège : les niveaux gratuits sont serrés (Alpha Vantage ~2 douzaines d'appels/jour). Vous penserez que votre code est cassé. Mettez tout en cache, et utilisez des pools d'identifiants (config.yaml) pour tourner sur plusieurs clés automatiquement et survivre aux limites de débit.
Dépôts qui valent votre temps
- NousResearch/hermes-agent
Lisez les docs du guide développeur : architecture, boucle d'agent, compression et mise en cache du contexte. Les miroirs DeepWiki et mudrii/hermes-agent-docs sont bons pour les détails internes.

- 0xNyk/awesome-hermes-agent
Compétences, outils, serveurs MCP, intégrations sélectionnés. Commencez ici. Hubs de compétences : le Hub officiel (680+ compétences, 18 catégories), skills.sh, ClawHub.

- OpenBB-finance/OpenBB
Bloomberg open source qui expédie des serveurs MCP, donc il se branche directement dans Hermes et donne à l'agent une vaste surface de données de marché + analyses via une seule interface. Le seul ajout au plus fort effet de levier.

- polakowo/vectorbt
Backtesting aussi rapide que Numba, des milliers de variations en secondes. Enveloppez-le dans une compétence pour que l'agent teste chaque hypothèse avant que vous ne lui fassiez confiance.

- TauricResearch/TradingAgents (+ auronsun/TradingAgents-crypto)
Simulation de société de trading multi-agents. Lisez-le pour la structure, puis construisez la version plus légère avec sous-agent haussier/baissier que vous comprenez. microsoft/qlib et nautechsystems/nautilus_trader pour des stratégies systématiques réelles. wilsonfreitas/awesome-quant comme carte de la bibliothèque.






