MathModelAgent : un agent de modélisation mathématique piloté par SKILLS et livré en application de bureau

Un énoncé de concours transformé en PDF Typst, pas un assistant de rédaction

Le problème visé est précis. Une compétition de modélisation mathématique impose de lire un énoncé, de choisir un modèle, d'écrire du code, de produire des figures et de composer un article au format du concours. La page du projet résume l'ambition en une ligne : passer de trois jours de compétition à une heure, et générer un article complet directement soumettable. Le public visé est donc double. D'abord les participants, qui trouvent une application de bureau pour macOS et Windows dans les Releases, présentée comme n'exigeant ni Python, ni Node.js, ni Redis, et une clé d'API de modèle comme seule configuration. Ensuite les développeurs d'agents, qui disposent d'un dépôt Python dont le README indique que le projet est désormais entièrement piloté par des SKILLS, sans couche Harness propre. Cette décision de conception est le vrai sujet du dépôt : le projet ne réimplémente pas une boucle d'agent, il se branche sur un harnais existant comme Claude Code ou Codex. Le README assume ce choix et le formule pour les développeurs d'agents : construire directement sur un Harness plus des SKILLS plutôt que sur un framework maison.

Une commande, dix-sept gabarits Typst et une base de connaissances intégrée

Le mécanisme est décrit comme une chaîne d'étapes. La commande /1start-mathmodel enchaîne l'analyse du problème, la modélisation, l'écriture du code, le tracé des figures, la mise en page de l'article et la vérification finale. Chaque étape est un Skill indépendant, ce qui permet de n'en exécuter qu'une partie : le README cite l'exemple de ne lancer que l'analyse ou que la rédaction. Deux éléments sont embarqués dans le dépôt. D'abord dix-sept gabarits d'articles Typst, couvrant selon le README des concours chinois et internationaux (国赛, 华数杯, 华为杯, MCM/ICM), avec une correspondance automatique au type d'épreuve. Ensuite une base de connaissances de modélisation : règles de modélisation, arbre de décision de sélection de modèles citant AHP, TOPSIS, ARIMA et GA, et critères d'évaluation MCM/ICM. Le projet présente cette base comme un moyen de réduire les hallucinations de modèle. La vérification finale est annoncée en neuf étapes, dans cet ordre : détection de fuite de texte, contrôle de cohérence numérique, compilation Typst, puis inspection visuelle du PDF. Ce dernier point mérite attention : la compilation est le seul contrôle de sortie qui produise un artefact vérifiable, le PDF. Le reste est une vérification interne au texte.

Interpréteur de code local ou distant, et le cas du notebook réutilisable

L'exécution du code passe par un Code Interpreter, avec deux options. En local, l'interpréteur repose sur Jupyter et le README précise que le code est enregistré au format notebook, donc rééditable après coup. C'est un détail pratique : le notebook reste un artefact que l'utilisateur peut reprendre à la main, contrairement à un script jetable. En distant, deux fournisseurs sont nommés, E2B et Daytona. Le projet annonce également une compatibilité multi-modèles via litellm, avec la possibilité d'affecter un modèle différent à chaque agent, et un workflow qualifié d'agentless, sans dépendance à un framework d'agent, présenté comme un choix de réduction des coûts. La personnalisation passe par l'injection de prompt : le README indique que des exigences peuvent être définies séparément pour chaque sous-tâche. C'est le point d'extension le plus concret du projet pour un utilisateur qui connaît déjà son domaine.

Deux chemins d'installation, et des dépendances qui ne se recouvrent pas

La documentation propose trois méthodes de déploiement, dont deux sont détaillées. Pour l'installation Docker, présentée comme la plus simple et la plus sûre, il suffit de lancer docker-compose up depuis le dossier du projet, puis d'ouvrir http://localhost:5173 pour l'interface et http://localhost:8000 pour l'API. La configuration de la clé d'API se fait dans la barre latérale, sous l'avatar. Pour l'installation locale, le README liste Python, Node.js et Redis comme prérequis, puis détaille les commandes : cd backend, pip install uv, uv sync, puis npm install -g pnpm et pnpm i dans le dossier frontend. Les variables d'environnement à définir sont ENV=DEV et REDIS_URL=redis://localhost:6379/0, avec une syntaxe différente sous PowerShell. Le démarrage enchaîne redis-server, puis uvicorn app.main:app avec les options --host 0.0.0.0, --port 8000, --ws-ping-interval 60, --ws-ping-timeout 120 et --reload. Sous Windows, un fichier win_start.bat est fourni. Un point à relever : les deux chemins ne mènent pas au même produit. L'installation Docker et locale déploie l'interface web et l'API, tandis que l'usage par SKILLS passe par npx skills add jihe520/MathModelAgent --all, puis par un harnais lancé avec claude --dangerously-skip-permissions ou codex --yolo. Ce sont deux modes d'utilisation distincts, et le README ne les réconcilie pas.

La liste des fonctionnalités et la liste des travaux à faire se contredisent

C'est la limite la plus sérieuse, et elle est documentée par le projet lui-même. La section des fonctionnalités annonce quatre mécanismes : la collaboration humain-machine avec pause à des points clés et six actions de décision (confirm, edit, regenerate, ask, skip, abort), la recherche web via l'API Tavily, une base RAG reposant sur ChromaDB et un rerank, et une tolérance aux pannes en quatre couches allant du retry limité au Fallback Hand Off, en passant par un Evaluator Shadow Mode et un Feedback Rerun. La section 后期计划, dans le même README, indique pour chacun de ces points que la logique centrale n'est pas implémentée. Pour la collaboration humain-machine, la note précise que le modèle de données existe mais que l'intégration au workflow est incomplète. Pour la recherche web, la note indique que Tavily a été remplacé par OpenAlex. Pour la base RAG, seuls les éléments de configuration existent. Pour la tolérance aux pannes, la note indique que ni la configuration ni la logique ne sont en place, et qu'il ne reste qu'un mécanisme de retry de base. Un lecteur qui s'appuie sur la première liste pour choisir l'outil se trompe. Le README porte par ailleurs un avertissement explicite : le projet est en phase de démonstration expérimentale, l'auteur indique être occupé et invitent les contributions. À noter aussi que la licence n'est pas renseignée dans les métadonnées du dépôt, ce qui empêche toute conclusion sur les droits d'usage et de redistribution.

Face à un pipeline LaTeX écrit à la main

L'alternative la plus directe n'est pas un autre agent, c'est un pipeline personnel : un script Python pour les calculs, Matplotlib pour les figures, et une chaîne LaTeX pour l'article. La différence d'approche est nette. Un pipeline manuel ne devine rien : chaque figure et chaque tableau est placé par l'auteur, et le résultat est reproductible à l'identique. MathModelAgent fait l'inverse, il génère le choix du modèle, le code, les figures et la mise en page, avec pour contrepartie une variabilité d'un tirage à l'autre et une vérification qui repose sur une compilation Typst. Le choix de Typst plutôt que LaTeX est lui aussi un arbitrage : le README indique que les gabarits sont issus de templates LaTeX convertis, et la compilation Typst sert de point de contrôle dans la vérification en neuf étapes. Un utilisateur dont l'établissement impose un gabarit LaTeX précis devra donc convertir ou renoncer. À l'inverse, pour qui veut un premier jet structuré en une heure, la chaîne Typst est plus courte qu'un pipeline LaTeX monté de zéro.

Coût de maintenance et ce que le dépôt engage

Le rythme de publication est soutenu : la fiche du dépôt indique trois versions récentes en deux jours, v0.0.16 le 7 septembre, puis v0.0.17-beta.1 et v0.0.17 le 8 septembre. Un numéro de version en 0.0.x signale une API et des formats encore mouvants, ce que confirme l'avertissement du README. Concrètement, un utilisateur qui adopte le projet doit s'attendre à ce que les SKILLS et les gabarits Typst changent, et à ce qu'une mise à jour du harnais ou du dépôt casse un enchaînement. Le README précise d'ailleurs que le développement se limitera à la couche SKILLS et que le reste ne sera plus modifié, ce qui donne une indication sur la stabilité attendue de l'interface web et de l'API. Sur la licence, rien ne peut être affirmé : la fiche du dépôt ne renseigne aucune licence, et le README ne mentionne que le caractère open source et gratuit. Avant tout usage en contexte encadré, il faut consulter le fichier de licence dans le dépôt, ou l'absence de ce fichier, et en tirer les conséquences avec un responsable juridique. Le projet distribue par ailleurs des binaires macOS signés et notariés, et un installeur Windows non signé qui déclenche SmartScreen selon le README.

Conclusion éditoriale

MathModelAgent convient aux participants de compétitions de modélisation qui veulent un premier jet complet et compilé, et aux développeurs d'agents qui cherchent un exemple de workflow découpé en SKILLS indépendants. Il ne convient pas à qui a besoin d'un pipeline stable et documenté de bout en bout : la section des fonctionnalités annonce quatre mécanismes dont la section 后期计划 indique explicitement que la logique centrale n'est pas implémentée. Avant d'investir du temps, vérifiez trois points dans le dépôt : le contenu réel de la licence, absente de la fiche du projet, le fichier docker-compose.yml à la racine pour l'installation la plus simple, et le fichier frontend/package.json pour confirmer la dépendance à pnpm.

Sources officielles

1. Issues
2. jihe520/MathModelAgent on GitHub
3. Project website
4. README
5. Releases