Introductie

Agentische systemen veranderen hoe software wordt gebouwd en onderhouden. In plaats van alleen te vertrouwen op ontwikkelaars om code te schrijven en bij te werken, gebruiken teams systemen die doelen kunnen interpreteren, oplossingen kunnen voorstellen en actie kunnen ondernemen binnen opslagplaatsen. In GitHub kan een agent een vertakking maken, bestanden wijzigen, een pull-aanvraag openen en vervolgens herhalen op basis van feedback van tests, beveiligingsscans en codebeoordelingen.

De mogelijkheid alleen maakt echter geen agent betrouwbaar. Zonder een goed gedefinieerde architectuur kunnen agents te vroeg handelen, onduidelijke wijzigingen veroorzaken of zonder voldoende validatie werken. In productieomgevingen creëren deze fouten echte risico's voor codekwaliteit, beveiliging en operationele stabiliteit.

Het ontwerpen van een agentsysteem in GitHub gaat niet over het geven van meer vrijheid aan de agent. Het gaat om het definiëren van hoe werkstromen door het systeem stromen met behulp van afdwingbare GitHub functies zoals pull-aanvragen, werkstromen en opslagplaatsregels. Een goed ontworpen architectuur zorgt ervoor dat elke agentactie een zichtbare record verlaat, wordt gevalideerd door objectieve signalen en alleen wordt geaccepteerd wanneer deze voldoet aan beleidsvereisten.

Glossary

Belangrijke termen en definities

In deze module wordt een kleine set terugkerende termen gebruikt. De onderstaande definities verduidelijken hoe ze in de inhoud worden gebruikt.

• Plannen (artefact) Een gestructureerde beschrijving van de beoogde wijzigingen, meestal opgenomen in een beschrijving van een pull-aanvraag. Het bevat een overzicht van het doel, het bereik, de stappen, de risico's en de validatiecriteria voor het werk.

• Planning (agentmogelijkheid) Het proces waarmee een agent een plan genereert of verfijnt op basis van een taak, probleem of gebruikersinvoer. Dit kan gebeuren in verschillende toegangspunten, zoals een probleem met GitHub of de interface agents.