Points clés
Les chercheurs ont permis à un assistant de code LLM d'utiliser la documentation et l'API LangChain4j pour concevoir et implémenter de lui-même un système de codage multi-agents.
Cet agent de codage auto-construit a réussi à corriger de véritables bogues, a passé les tests et a exposé son propre flux d'exécution via LangChain4j.
La comparaison de deux modes d'agents a montré que le mode workflow plus strict, en éliminant les frais de coordination induits par le LLM, est 3 fois plus rapide que le mode superviseur.
Grâce à la nouvelle interface MonitoredAgent, il est possible d'obtenir clairement les rapports d'appel et la topologie du système des agents.
Dans l'expérience, la même conception d'agent a échoué sur un modèle ancien et bon marché en tombant dans une boucle d'appels d'outils, tandis que le nouveau modèle a réussi la tâche.
Aperçu de l'expérience
Les chercheurs ont mené une méta-expérience : ils ont confié la documentation LangChain4j à un assistant de code, en lui demandant de construire une "version de lui-même" basée sur cette documentation. Plus précisément, ils souhaitaient concevoir un système multi-agents capable d'écrire, de tester et de déboguer du code comme un ingénieur humain.
Le fait qu'un LLM puisse construire sa propre version à partir de la documentation montre à la fois que l'API LangChain4j est suffisamment claire et facile à utiliser, et que le framework offre une capacité d'orchestration suffisante pour que le système généré puisse effectuer de bout en bout des tâches de débogage réelles.
Ce projet a également permis de tester les nouveaux outils de surveillance de LangChain4j – lorsqu'on laisse une IA en construire une autre, il est essentiel de voir ce qui se passe à l'intérieur. Cet article détaille le processus expérimental et les résultats, et le code du projet est disponible dans ce dépôt.
"Coder dans l'ambiance" un système d'agents
Pour permettre à l'assistant de code de construire un premier agent codeur, les chercheurs ont rédigé l'invite suivante :
Apprenez la documentation et le code source du framework d'agents LangChain4j, et concevez sur cette base un agent codeur qui vous clone.
Après quelques minutes de réflexion, l'assistant a décidé d'utiliser le mode superviseur de LangChain4j et a proposé l'architecture initiale :
public interface SupervisorCoderSystem {
@SupervisorAgent(description = """
一个多智能体编码助手，可以探索代码库、规划实现、编写/编辑代码、运行构建/测试。
它编排专门的子智能体来完成编码请求。
""", subAgents = {
ExplorerAgent.class,
PlannerAgent.class,
ImplementerAgent.class,
ExecutorAgent.class
})
@Override
String code(@K(UserRequest.class) String request,
@K(WorkingDirectory.class) String workingDirectory);
@SupervisorRequest
static String request(@K(UserRequest.class) String userRequest,
@K(WorkingDirectory.class) String workingDirectory) {
return "将'" + workingDirectory + "'作为工作目录，完成以下用户请求：" + userRequest;
}
}L'assistant a également conçu et développé quatre sous-agents, ainsi que leurs messages système et utilisateur : l'agent d'exploration explore le code existant, l'agent de planification élabore un plan d'action, l'agent d'implémentation écrit le code selon le plan, et l'agent d'exécution compile et exécute le code. Chaque sous-agent était équipé d'outils appropriés : navigateur de système de fichiers, éditeur de code, exécuteur de code, etc.
Le résultat de la première itération a été impressionnant. Dans la réalité, les assistants de code "professionnels" suivent généralement un schéma similaire : exécuter les quatre étapes d'exploration, planification, implémentation et exécution, et orchestrer en mode superviseur – ce qui correspond à l'implémentation générée dans l'expérience.
Le fait que l'assistant de code ait pu concevoir et implémenter un tel système montre qu'il a une certaine compréhension de son propre fonctionnement interne et qu'il peut transformer cette compréhension en une conception concrète de système d'agents.
Mettre l'agent codeur au travailPour tester l'agent codeur conçu, les chercheurs lui ont fait écrire du code bogué, puis ont utilisé le système nouvellement créé pour le corriger. L'assistant a généré une classe Calculator contenant quatre méthodes avec des bogues subtils :
public class Calculator {
public int sum(List<Integer> numbers) {
int total = 0;
for (int i = 0; i <= numbers.size(); i++) { // Bug: 应该是 i < numbers.size()
total += numbers.get(i);
}
return total;
}
public double average(List<Integer> numbers) {
if (numbers.isEmpty()) return 0;
return sum(numbers) / numbers.size(); // Bug: 整数除法，应转为double
}
public int max(List<Integer> numbers) {
if (numbers.isEmpty()) throw new IllegalArgumentException("列表不能为空");
int max = 0; // Bug: 如果所有数都是负数，会返回0
for (int n : numbers) {
if (n > max) max = n;
}
return max;
}
public long factorial(int n) {
if (n < 0) throw new IllegalArgumentException("n必须非负");
long result = 1;
for (int i = 1; i < n; i++) { // Bug: 应包含n，即 i <= n
result *= i;
}
return result;
}
}Ensuite, un test a été généré, consistant à cloner le dossier contenant Calculator dans un répertoire temporaire, puis à exécuter l'agent codeur LangChain4j :
@Test
void workflow_should_fix_buggy_calculator() throws Exception {
var coder = CoderAgenticSystem.supervisorCoder(coderModel());
Path source = Path.of("src/test/resources/buggy-project");
Path workDir = Path.of("/tmp/buggy-calculator");
String result = coder.code(
"测试当前失败，因为Calculator.java存在Bug。请修复它。",
workDir.toAbsolutePath().toString());
assertThat(result).isNotBlank();
System.out.println("结果: " + result);
}Lors de l'exécution du code, le modèle gpt-4o d'OpenAI a été utilisé, car c'est le modèle par défaut de LangChain4j et qu'il prend en charge les appels d'outils. Cependant, les résultats n'étaient pas satisfaisants : une erreur est survenue après quelques minutes :
dev.langchain4j.agentic.agent.AgentInvocationException: Failed to invoke agent method: public abstract...Comparaison des modèles : superviseur vs flux de travail
Étant donné que le modèle superviseur nécessite que le LLM prenne des décisions avant et après chaque appel de sous-agent, cela entraîne une surcharge de coordination importante. Les chercheurs se sont donc tournés vers un modèle de flux de travail plus rigoureux (workflow pattern), qui organise les agents dans un ordre fixe et n'appelle le LLM qu'en cas de besoin.
Le modèle de flux de travail est trois fois plus rapide que le modèle superviseur, car il élimine la plupart des changements de contexte entre les LLM. Les données expérimentales montrent que le modèle superviseur nécessite sept appels LLM pour effectuer une correction, tandis que le modèle de flux de travail n'en nécessite que deux.
Impact du choix du modèle
L'expérience a également testé des modèles moins chers (comme gpt-4o-mini), mais ce modèle est tombé dans une boucle d'appels d'outils et n'a pas pu terminer la tâche. En revanche, l'utilisation du modèle plus récent gpt-5-mini a permis de corriger tous les bogues. Cela montre que la qualité du modèle est cruciale pour la fiabilité des systèmes d'agents.
Surveillance des appels d'agents
L'interface MonitoredAgent, récemment introduite par LangChain4j, permet de générer des rapports d'appels d'agents, affichant les entrées, les sorties, les temps d'exécution, etc. Les chercheurs ont utilisé cette interface pour analyser la topologie et le flux de travail du système.
Conclusion
Cette expérience démontre une capacité de méta-programmation intéressante : un LLM peut, en utilisant la documentation d'un framework existant, construire un système d'agents capable de s'auto-réparer. Le modèle de flux de travail est plus efficace que le modèle superviseur, et le choix du modèle détermine directement le succès ou l'échec du système. LangChain4j fournit suffisamment d'API et d'outils de surveillance pour soutenir ce type d'expériences.