Linchpin

Qu'est-ce que Linchpin ?

Linchpin est un runtime auto-hébergeable pour agents IA qui supporte l'exécution avec de nombreux fournisseurs de modèles et modèles locaux. Il est conçu pour router les requêtes vers différents LLM, exécuter chaque session d'agent dans un environnement isolé, et fournir un ensemble contrôlé d'outils intégrés et externes.

Son objectif principal est de réduire le verrouillage sur les modèles/fournisseurs tout en offrant aux agents un contexte d'exécution sandboxé et un accès géré aux outils, identifiants et flux d'événements.

Fonctionnalités clés

• Tout modèle, un adaptateur : Linchpin peut router vers environ 200 modèles cloud (dont Claude, GPT, Gemini, Llama, DeepSeek, Mistral et Qwen) via OpenRouter, et utiliser Ollama pour exécuter des modèles locaux ; vous pouvez changer de fournisseur par agent.
• Sessions sandboxées avec conteneurs Docker par session : Chaque session s'exécute dans son propre conteneur Docker avec Python, Node, git et ripgrep préinstallés pour un environnement d'outils cohérent.
• Réseautage configurable par environnement : Le réseautage peut être défini sur none pour des restrictions strictes ou open egress pour des configurations moins restrictives.
• Huit outils conteneurs intégrés : Les agents peuvent utiliser des outils comme bash, read, write, edit, glob, grep, web_fetch et web_search, avec exécution contrainte dans le conteneur.
• Intégration d'outils MCP et HTTP : Linchpin peut brancher des serveurs Model Context Protocol (MCP) via stdio, ou se connecter à n'importe quel point de terminaison HTTP ; le connecteur gère le cycle de vie du processus et l'injection d'identifiants.
• Coffres d'identifiants chiffrés : Les identifiants sont stockés avec le chiffrement Fernet ; les agents référencent les secrets par nom dans leurs configs, et les secrets sont déchiffrés au démarrage de la session sans écriture sur disque en clair.
• Flux d'événements append-only par session : Linchpin enregistre un journal d'événements append-only par session et supporte la pagination par curseur ; les clients peuvent s'abonner via SSE pour rejouer les événements passés un curseur et streamer les mises à jour en direct.

Comment utiliser Linchpin

1. Choisissez votre chemin de modèle : Configurez un agent pour utiliser un modèle cloud via OpenRouter (pour sélection de fournisseur) et/ou un modèle local via Ollama.
2. Exécutez les sessions d'agent en sandbox : Lancez les sessions en sachant que chacune utilise son propre conteneur Docker avec les outils runtime préinstallés ; définissez le réseautage selon vos besoins (none vs open egress).
3. Sélectionnez les outils pour l'agent : Utilisez les outils intégrés de Linchpin (bash, opérations fichiers, recherche/récupération) et ajoutez optionnellement des serveurs MCP (via stdio) ou connectez-vous à des points de terminaison HTTP comme outils externes.
4. Fournissez les identifiants de manière sécurisée : Stockez les identifiants dans le coffre chiffré Fernet de Linchpin et référencez les secrets par nom dans les configs d'agent.
5. Streamez les événements vers votre UI ou service : Abonnez-vous via SSE et utilisez la pagination par curseur pour rejouer les événements antérieurs et continuer à recevoir les mises à jour.

Cas d'usage

• Déploiement d'agents multi-fournisseurs : Vous voulez exécuter le même workflow d'agent sur différents LLM (par exemple, Claude pour une tâche et GPT pour une autre) tout en gardant le reste de votre configuration d'outils et sandbox cohérent.
• Exécutions d'agents avec modèles locaux : Vous avez des modèles téléchargés localement et préférez les exécuter via Ollama, en utilisant les mêmes outils conteneurisés et isolation de session indépendamment de l'emplacement du modèle.
• Workflows de code et fichiers sandboxés : Un agent qui doit éditer et rechercher des fichiers de projet ou exécuter des commandes shell peut le faire dans son propre conteneur Docker, avec réseautage restreint si nécessaire.
• Outils via serveurs MCP : Vous avez des serveurs MCP existants qui exposent des capacités aux agents ; Linchpin peut s'y connecter via stdio et gérer le cycle de vie du connecteur et l'injection d'identifiants.
• Flux d'événements UI en direct : Vous construisez une interface qui a besoin d'historique et de mises à jour en direct ; vous pouvez rejouer les entrées du journal d'événements à partir d'un curseur puis continuer à streamer les événements en temps réel via SSE.

FAQ

• Linchpin nécessite-t-il un fournisseur de modèles spécifique ? Non. Linchpin passe par OpenRouter pour de nombreux modèles cloud et peut aussi exécuter des modèles locaux via Ollama, avec sélection du fournisseur configurable par agent.

• Comment les sessions d’agents sont-elles isolées ? Chaque session s’exécute dans son propre conteneur Docker avec des outils tels que Python et Node préinstallés. Le réseau peut être restreint (aucun) ou autorisé (sortie ouverte) selon l’environnement.

• Quels outils les agents peuvent-ils utiliser ? Linchpin inclut huit outils intégrés (bash, read, write, edit, glob, grep, web_fetch, web_search) et peut intégrer des outils externes via serveurs MCP (stdio) ou endpoints HTTP.

• Comment Linchpin gère-t-il les identifiants ? Les identifiants sont stockés dans un coffre chiffré Fernet et référencés par nom dans les configs d’agents. Ils sont déchiffrés au démarrage de la session et ne sont pas écrits sur disque en clair.

• Puis-je diffuser l’activité des agents vers un frontend ? Oui. Linchpin maintient un journal d’événements append-only par session et prend en charge les abonnements SSE qui rejouent les événements passés un curseur puis diffusent les nouveaux événements en direct.

Alternatives

• Runtimes d’agents auto-hébergés avec sandboxing : Des plateformes alternatives qui exécutent les agents dans des conteneurs isolés peuvent aussi fournir une exécution contrôlée des outils ; la différence réside souvent dans l’intégration des modèles et outils (routage fournisseur, support MCP/HTTP et modèle de streaming d’événements).
• Frameworks d’agents locaux uniquement : Des frameworks axés sur les modèles locaux (p. ex. ceux construits autour d’inférence locale) peuvent éviter le routage vers fournisseurs externes, mais offrent des niveaux différents de commutation de fournisseur et de gestion d’outils/identifiants.
• Connecteurs d’outils axés sur MCP : Si votre besoin principal est la connectivité MCP, vous pourriez trouver des alternatives qui mettent l’accent sur l’intégration d’outils MCP ; comparé à Linchpin, il faudrait évaluer leur gestion de l’isolation des sessions, du stockage des identifiants et du streaming.
• Implémentations personnalisées SSE/journal d’événements : Certaines équipes construisent leur propre journalisation d’événements et streaming SSE autour d’un système d’agents ; le compromis est un effort d’ingénierie plus important pour reproduire la relecture basée sur curseur, les journaux de sessions append-only et un comportement cohérent des outils d’agents.