Ce qu'un agent est réellement

Vous avez effectué des appels API, mais un seul appel ne retourne qu'une réponse. Si vous voulez automatiser un flux de travail, Claude doit agir, examiner le résultat, décider de la suite et continuer. Ce modèle est ce que les gens entendent quand ils parlent de flux de travail agentiques.

Un agent est une version autonome de Claude, exécutant les deux côtés de la boucle de messagerie sans humain au milieu. Un agent reçoit une tâche, choisit un outil et exécute du code en boucle jusqu'à ce que Claude décide que la tâche est terminée.

La façon la plus simple d'implémenter une boucle d'agent ressemble à ceci :

Envoyer un message à Claude avec les outils disponibles.
Claude répond soit avec une réponse finale, soit avec une demande d'utilisation d'un outil que vous avez défini.
Votre code exécute cet outil.
Vous renvoyez le résultat à Claude.
Répétez jusqu'à ce que la raison d'arrêt soit end_turn.

Pensez-y comme une conversation où les tours alternent : l'utilisateur lance les choses, l'agent appelle un outil, l'outil retourne un résultat, et l'agent continue jusqu'à ce qu'il ait une réponse.

Un exemple minimal fonctionnel

Pour voir cette boucle s'exécuter de bout en bout sans traîner une base de données ou une interface utilisateur, nous allons configurer un faux outil appelé get_weather et demander à Claude quoi porter à Austin aujourd'hui. Claude n'a aucun moyen de connaître la météo par lui-même, donc il doit appeler l'outil, lire le résultat, puis vous donner une réponse.

Voici le script complet :

import anthropic

client = anthropic. Anthropic()

tools = [ { "name": "get_weather", "description": "Get the current weather for a city. ", "input_schema": { "type": "object", "properties": { "city": { "type": "string", "description": "The city to get weather for", } }, "required": ["city"], }, } ]

def run_tool(name, tool_input): if name == "get_weather": return f"Weather in {tool_input['city']}: 95F, sunny" raise ValueError(f"Unknown tool: {name}")

messages = [ {"role": "user", "content": "What should I wear in Austin today? "} ]

while True: response = client. messages. create( model="claude-sonnet-4-6", max_tokens=1024, tools=tools, messages=messages, )

if response. stop_reason == "end_turn":

for block in response. content: if block. type == "text": print(block. text) break

if response. stop_reason == "tool_use":

tool_results = [] for block in response. content: if block. type == "tool_use": result = run_tool(block. name, block. input) tool_results. append( { "type": "tool_result", "tool_use_id": block. id, "content": result, } )

messages. append({"role": "assistant", "content": response. content}) messages. append({"role": "user", "content": tool_results})

Trois éléments à remarquer :

Le tableau tools indique à Claude ce qui est disponible : un nom, une description et un schéma JSON pour les entrées.
run_tool est juste une recherche codée en dur. Dans une vraie application, cela accèderait à votre base de données, une API, etc.
La boucle est la boucle d'agent. Chaque itération envoie les messages à Claude et bascule sur la raison d'arrêt de la réponse. Sur end_turn, Claude a terminé — imprimez le texte final et arrêtez. Sur tool_use, trouvez les blocs d'utilisation d'outil, exécutez chacun, poussez la réponse de l'assistant et vos résultats d'outil dans messages, et bouclez à nouveau pour que Claude puisse répondre.

L'exécuter

Quand vous exécutez le script, vous verrez deux tours :

Tour un : la raison d'arrêt est tool_use. Claude demande get_weather pour Austin, et votre code retourne la température et les conditions.
Tour deux : la raison d'arrêt est end_turn, et Claude vous dit de porter quelque chose de léger et respirant.

Terminal output of the agent loop: turn 1 stops with tool_use and calls get_weather for Austin, then turn 2 stops with end_turn and Claude prints its final clothing recommendations

Deux appels API, une exécution d'outil, une réponse finale. C'est toute la boucle. Tout ce que vous construisez avec l'API Claude va être similaire à ceci.

La même boucle en production

Dans un environnement réel, cette même boucle alimente quelque chose comme un point de terminaison d'examen automatique : un agent de conformité qui lit un rapport structurel, recherche les codes du bâtiment pertinents via un outil, et écrit les conclusions de risque dans la base de données un par un au fur et à mesure qu'il travaille.

A compliance review dashboard listing uploaded structural reports, each with a Run auto-review button that kicks off the agent

La forme de la boucle est identique à celle que vous venez d'exécuter. Les différences sont :

De vrais outils au lieu d'une recherche météo fictive.
Les résultats sont diffusés vers l'interface utilisateur sous forme d'événements envoyés par le serveur.
Les conclusions sont persistées dans une table de conclusions de risque.

The review trace of a running compliance agent: dozens of tool calls searching the building-code library and looking up specific code sections as the loop iterates

Récapitulatif

Un agent est Claude dans une boucle : observer, décider, agir, répéter.
La boucle est simple : envoyer des messages avec des outils, exécuter tout outil que Claude demande, renvoyer le résultat, et arrêter quand la raison d'arrêt est end_turn.
Vous possédez la boucle et les outils. Claude possède le raisonnement.
La même forme de boucle s'adapte d'une démo météo fictive à un agent de conformité en production — seuls les outils et la plomberie changent.
Quand vous ne voulez pas posséder la boucle, les agents gérés exécutent cette boucle exacte pour vous sur l'infrastructure d'Anthropic.