Capacités organisationnelles et architecture
D’un espace de travail personnel en IA aux applications d’équipe partagées, en passant par la façon dont les tâches s’exécutent sur votre infrastructure.
Cette page a été traduite automatiquement. Voir la version originale en anglais.
Capacités organisationnelles
LinkSense offre à chaque membre son propre espace de travail IA. Ce qu’une personne construit là-bas peut devenir une capacité que l’organisation partage, gouverne et réutilise entre les équipes.
| Capacités | Ce que l’organisation peut réutiliser |
|---|---|
| Bases de connaissances | Donner à l’IA accès aux documents organisationnels autorisés. L’analyse syntaxique, l’indexation et la récupération intégrées des documents sont disponibles dans Full. |
| Compétences | Transformez une méthode éprouvée de travail en une procédure répétable. |
| Serveurs MCP | Donner aux tâches un accès contrôlé aux systèmes et actions métier. |
| Plugins | Intégrer Skills et MCP pour la distribution révisée. |
Du travail personnel à la réutilisation en équipe
Teams peut développer et tester des compétences et plugins dans un espace de travail personnel, soumettre une version fixe pour examen administrateur, puis la publier pour que d’autres puissent l’installer. Les mises à jour sont explicites. Voir Révision des versions et gouvernance pour le flux de travail d’approbation.
Connectez les ressources organisationnelles
Les propriétaires de la base de connaissances peuvent accorder l’accès à des utilisateurs ou groupes sélectionnés. Les connecteurs donnent accès aux documents et aux e-mails, et le MCP peut intégrer des systèmes tels que l’ERP ou le CRM. Les connexions et leurs identifiants sont gérés séparément : déléguez le travail, pas les identifiants. Vérifiez que le modèle choisi prend en charge les outils et que la connexion fonctionne.
Applications : mettre les capacités à contribution
Une application combine des instructions maintenues et la configuration du modèle avec des connexions Connaissances, Compétences, Plugins et MCP. C’est un point d’entrée réutilisable, pas un agent autonome : un membre autorisé commence et possède sa propre tâche.
Exemple : une demande de financement
Une équipe financière peut combiner sa base de connaissances en politiques, une compétence pour examiner les dépenses et une intégration ERP dans une seule application. Les membres autorisés de l’équipe peuvent commencer à travailler sans recréer cette configuration. Un service en ligne géré peut fournir une utilisation contrôlée des connaissances et du MCP maintenus par le créateur sans donner aux utilisateurs un accès direct à la gestion ni afficher les identifiants sous-jacents dans l’interface habituelle. Un paquet installable, en revanche, crée une copie personnelle qui peut nécessiter sa propre configuration. Voir Accès et utilisation des applications.
Une couche de capacité ouverte
LinkSense connecte les modèles d’IA aux personnes, données et systèmes d’une organisation. Il gère la propriété et les permissions, la revue et la publication, la configuration des identifiants et des modèles, les enregistrements d’utilisation et d’audit, ainsi que l’environnement qui exécute les tâches.
Construit sur le runtime Codex open source
LinkSense exécute le package @openai/codex en amont dans ses Workers gérés et communique avec codex app-server --stdio via JSON-RPC. Il ne forke pas le Codex ni ne remplace sa boucle d’agent. Il ne nécessite pas l’application web Codex ni un runtime hébergé sur LinkSense. L’inférence de modèle est configurée séparément.
| Manches de codex | LinkSense gère |
|---|---|
| Raisonnement et tournants, outils natifs, compétences et plugins, sous-agents et sémantique bac à sable | Espaces de travail, identité et accès aux ressources, publication et gouvernance, configuration du modèle, gestion des travailleurs, persistance, utilisation et opérations |
Le temps d’exécution en amont utilise le Licence Apache-2.0. Codex est une marque déposée d’OpenAI. LinkSense est un projet indépendant et n’est ni affilié ni approuvé par OpenAI.
Open source et auto-hébergé
Faites tourner LinkSense sur vos propres serveurs, cloud privé ou VPC. Vous pouvez inspecter et modifier la source et choisir vos modèles et intégrations. Un déploiement auto-hébergé ne nécessite pas un plan de contrôle cloud opéré par LinkSense ni l’activation d’une licence en ligne.
Avec les points de terminaison des modèles privés, les services locaux Knowledge et MCP locaux, les invites, fichiers, historique des tâches, index, identifiants et enregistrements d’audit peuvent rester sur l’infrastructure que vous contrôlez. Les fournisseurs externes et les intégrations peuvent toujours recevoir des données une fois configurées. L’auto-hébergement ne signifie pas que l’installation est isolée du réseau. Voir Configuration du modèle et les Exceptions de licence et d’attribution du dépôt.
Architecture système
L’espace de travail web soumet des tâches à l’API. L’API gère l’identité, les permissions, l’utilisation et l’état de la tâche. Le Runner gère les Docker Workers qui exécutent les tâches.
| Couche | Composants |
|---|---|
| Espace de travail | React, TypeScript, Vite, TanStack Query |
| Services et stockage | Node.js, Fastify, PostgreSQL, Redis, stockage d’objets compatible S3 |
| Exécution | Docker Workers par utilisateur, Codex app-server |
| Full Connaissance | Analyse analytique de documents, indexation et récupération Elasticsearch |
Modèle ouvrier
LinkSense démarre et réutilise un Docker Worker par utilisateur actif. Les tâches avec un même utilisateur peuvent partager des fichiers HOME, CODEX_HOME et projet. Les travailleurs oisifs sont récupérés ; Les environnements de paquets par utilisateur peuvent persister, et les artefacts générés sont stockés indépendamment dans le stockage d’objets.
Chemin d’exécution des tâches
Pour un démarrage normal en temps réel, l’API perpétue la tâche et la dépêche vers Runner via HTTP. Runner redirige le travail vers le Worker de l’utilisateur, où Codex s’exécute. Les départs en temps réel ne passent normalement pas par BullMQ ; la file d’attente est utilisée pour les automatisations et autres travaux planifiés et en arrière-plan.
Organisation des événements
Runner mappe et expurge les événements d’exécution et les stocke dans une boîte de sortie durable avant de les transmettre à l’API. L’API fait persister les événements et transmet les mises à jour au navigateur via SSE.
Limites d’exécution
Le Worker de l’utilisateur, et non le répertoire des tâches, est la frontière d’isolement. L’exécution normale ne demande pas d’approbation à chaque commande. Une injection de prompt dans une page web, un fichier ou une réponse d’outil non fiable peut conduire à la lecture, à la modification ou à l’envoi des fichiers partagés de cet utilisateur. Le mode Plan utilise un bac à sable en lecture seule avec l’accès réseau désactivé.
Les Task Workers s’exécutent sans privilège, ne montent pas le socket Docker et ne rejoignent pas directement les réseaux de services PostgreSQL ou Redis. Le contrôleur Runner dispose d’un accès au démon Docker et est un composant de gestion fiable. La sortie par internet des travailleurs est autorisée ; L’application n’impose pas par défaut une liste générale d’accès à la sortie ni ne bloque les points de terminaison de métadonnées cloud. Configurez ces contrôles au niveau du déploiement et lisez les Politique de sécurité d’exécution avant d’ouvrir l’accès à plus d’utilisateurs.