Ontwikkelaarstools van derden stellen codeeragents in staat om verder te kijken dan de DOM, netwerkverzoeken en consolelogs. Door aangepaste tools rechtstreeks vanuit uw website of framework beschikbaar te stellen, kunt u uw agent laten interageren met anders ontoegankelijke applicatiestatus en -gegevens.
Deze tools worden gemaakt met JavaScript en worden automatisch door Chrome DevTools voor agents gedetecteerd wanneer uw pagina wordt geladen.
Inzicht in tools van externe ontwikkelaars
In de context van codeeragenten zijn tools kant-en-klare functies waarmee agenten specifieke acties kunnen uitvoeren. Specifiek voor DevTools voor agenten kunnen dergelijke tools hun interne runtime-status rechtstreeks aan codeeragenten blootstellen, waardoor de kloof tussen de gegenereerde output en de interne logica wordt overbrugd.
Houd bij het gebruik van tools van derden rekening met het volgende:
- Runtime-detectie. Tools worden automatisch gedetecteerd wanneer uw applicatie reageert op de
devtoolstooldiscoverygebeurtenis die door Chrome DevTools wordt uitgezonden voor agents op het globalewindowobject. - Contextbereik. Tools worden alleen uitgevoerd binnen de context van de pagina waarop ze zijn gedefinieerd. Ze blijven niet behouden tussen verschillende paginabronnen en bij het opnieuw laden van pagina's.
- Specificiteit van de tools . Tools zijn slechts een extra manier voor uw agent om een taak uit te voeren. De agent geeft mogelijk de voorkeur aan ingebouwde tools of aan de basisfunctionaliteiten van het model om aan een verzoek te voldoen. Zorg er daarom voor dat de namen en beschrijvingen van de tools zo duidelijk mogelijk zijn.
Voorwaarden
Voordat u tools van derden implementeert, moet u ervoor zorgen dat u aan de volgende vereisten voldoet:
- Chrome DevTools voor agents. Gebruik versie 0.25.0 of later.
- JavaScript is ingeschakeld. JavaScript is ingeschakeld en wordt uitgevoerd.
Implementeer een tool
Om een tool te implementeren, luister je naar een specifieke ontdekkingsgebeurtenis en reageer je met je tooldefinities. De volgende code is een voorbeeld van een reactie met tooldefinities:
window.addEventListener(
'devtoolstooldiscovery',
(event: DevtoolsToolDiscoveryEvent) => {
event.respondWith({
name: 'Page-specific DevTools',
description: 'Provide runtime info directly from the JavaScript in the page.',
tools: [
{
name: 'add',
description: 'Calculates the sum of two numbers.',
inputSchema: {
type: 'object',
properties: {
a: {type: 'number'},
b: {type: 'number'},
},
required: ['a', 'b'],
},
execute: async (input: {a: number; b: number}) => {
return input.a + input.b;
},
},
],
});
},
);
Om tools in uw applicatie te registreren:
Definieer uw gereedschapsgroep. Maak een
ToolGroupaan die een naam, een beschrijving en een array met individuele gereedschapsdefinities bevat.export interface ToolDefinition { name: string; description: string; inputSchema: JSONSchema7; execute: (args: Record<string, unknown>) => unknown; } export interface ToolGroup { name: string; description: string; tools: ToolDefinition[]; }Luister naar de ontdekkingsgebeurtenis. Chrome DevTools voor agents verzendt een aangepaste
devtoolstooldiscoverygebeurtenis op het globalewindowobject na elke navigatie en telkens wanneer een bijgewerkte lijst met beschikbare tools nodig is.Registreer uw tools. Roep de
respondWith()-methode van de gebeurtenis aan om uw toolgroep aan de agent door te geven.
Essentiële onderdelen voor individuele gereedschappen
Elke tooldefinitie die u implementeert, moet de volgende drie onderdelen bevatten:
- Naam en beschrijving. Deze bevatten de instructies die de agent gebruikt om te bepalen wanneer en hoe uw tool moet worden aangeroepen.
- Invoerschema. Een JSON-schema dat de structuur en typen argumenten definieert die de tool verwacht.
- Uitvoeringsfunctie. De daadwerkelijke JavaScript-code die op de pagina wordt uitgevoerd wanneer de agent de tool aanroept.
Het volgende voorbeeld laat deze drie componenten zien in één enkele tooldefinitie:
{
name: 'add',
description: 'Calculates the sum of two numbers.',
inputSchema: {
type: 'object',
properties: {
a: {type: 'number'},
b: {type: 'number'},
},
required: ['a', 'b'],
},
execute: async (input) => {
return input.a + input.b;
},
}
Gebruiksscenario's voor ontwikkelaarstools van derden
Geef je agent de opdracht om de diepere applicatielogica te inspecteren in plaats van alleen de oppervlakkige UI-elementen. Gebruik deze aangepaste tools om het debuggen van stateful of framework-intensieve applicaties te stroomlijnen.
Tips voor het vinden van de juiste tools
Schrijf beschrijvende namen en omschrijvingen voor de gereedschappen . Agenten gebruiken deze omschrijvingen als context om te bepalen welk gereedschap ze moeten gebruiken; duidelijke taal helpt de agent om zelfstandig te bepalen wanneer een gereedschap geschikt is voor een taak.
Foutopsporing van toepassingsspecifieke runtime-statistieken
Problemen zoals ongemerkte cachemissers of overbodige API-aanroepen zijn vaak onzichtbaar bij standaardinspecties. Door interne statistieken beschikbaar te stellen, kan uw agent verklaren waarom bepaald gedrag zich voordoet.
Stel dat je een functie hebt die interne statistieken weergeeft; dan moet je eerst een tool zoals deze maken:
window.addEventListener('devtoolstooldiscovery', (event) => {
event.respondWith({
name: 'My app',
description: 'Tools to debug my app',
tools: [
{
name: 'getCacheStatistics',
description: 'Exposes runtime cache hits and misses for the frontend API service.',
inputSchema: {},
execute: async () => {
// Assuming window.__apiCacheService exists in your app
return window.__apiCacheService.getStats();
}
}
]
});
});
Als de beschrijving van uw tool duidelijk is, kan uw agent de tool mogelijk autonoom gebruiken wanneer dat nodig is. U kunt uw agent bijvoorbeeld als volgt een taak laten uitvoeren met behulp van de tool:
When I reassign a lead to a new sales rep, the dashboard takes a second to
update. Please verify if the frontend is correctly updating the local cache,
or if it is doing a full cache miss and refetching the entire pipeline from the
database.
Voorbeeld van agentuitvoering: Uw agent detecteert de getCacheStatistics tool die door uw applicatie beschikbaar wordt gesteld. De agent roept de tool aan, analyseert de geretourneerde hit-to-miss-ratio en identificeert dat de frontend onnodig de hele pipeline opnieuw ophaalt in plaats van de lokale cache bij te werken.
Controleren van feature flags
Definieer aangepaste datapunten om de huidige omgevingsvariabelen of actieve feature flags voor een specifieke gebruikerssessie weer te geven. Dit helpt u bij het debuggen waarom bepaalde functies wel of niet zichtbaar zijn voor specifieke gebruikers. Als een gebruiker een bug meldt, kan de agent controleren of deze gebruiker deel uitmaakt van een experimentgroep die mogelijk het probleem veroorzaakt.
Maak bijvoorbeeld een tool zoals deze om de interne status van de feature flag terug te geven:
// Implementation for a website creator to expose feature flags
window.addEventListener('devtoolstooldiscovery', (event) => {
event.respondWith({
name: 'Application Configuration Tools',
description: 'Tools for inspecting runtime environment and feature toggles',
tools: [
{
name: 'getFeatureFlags',
description: 'Returns a list of all active feature flags and their current values for the session.',
inputSchema: {
type: 'object',
properties: {} // No input parameters required for this tool
},
execute: async () => {
// This should return your internal feature flag state
// Example: return window.AppConfig.getFlags();
return {
"new-ui-enabled": true,
"beta-search-v2": false,
"experiment-group": 'control',
"log-level": 'debug'
};
}
}
]
});
});
Als de beschrijving van uw tool duidelijk is, kan uw agent de tool mogelijk autonoom gebruiken wanneer dat nodig is. U kunt uw agent bijvoorbeeld als volgt een taak laten uitvoeren met behulp van de tool:
Check the active feature flags and tell me if the new-ui-enabled flag is set to
true for this session.
Voorbeeld van agentuitvoering : Uw agent roept de tool getFeatureFlags aan, bevestigt dat de vlag new-ui-enabled actief is en gaat vervolgens verder met het debuggen van de componenten die aan de nieuwe interface zijn gekoppeld.
De globale applicatiestatus controleren
Geef de runtime-statusstructuur van uw applicatie weer, zodat uw agent de interne logica kan begrijpen zonder de volledige DOM op te halen.
Je zou een tool zoals deze kunnen maken om specifieke paden in je statusstructuur op te vragen, bijvoorbeeld zoals in het volgende voorbeeld:
// Library-agnostic implementation for inspecting global application state
window.addEventListener('devtoolstooldiscovery', (event) => {
event.respondWith({
name: "Global State Inspector",
description: 'Tools to inspect the runtime state tree of the application',
tools: [
{
name: 'getGlobalState',
description: "Returns the current application state. Use the 'path' parameter to drill down into specific sections (for example, 'auth.user' or 'cart.items'). ",
inputSchema: {
type: 'object',
properties: {
path: {
type: 'string',
description: 'Optional dot-notation path to a specific property in the state tree.'
}
}
},
execute: async (input) => {
// Library-agnostic access:
// Website creators can point this to whatever global store they use.
const state = window.__APP_STATE__ ||
(window.store && typeof window.store.getState === 'function' ? window.store.getState() : null);
if (!state) {
return { error: 'Application state is not accessible via window.__APP_STATE__ or window.store.' };
}
if (!input.path) {
return state;
}
// Helper to resolve a dot-notated path against the state object
return input.path.split('.').reduce((acc, part) => {
return acc && acc[part] !== undefined ? acc[part] : undefined;
}, state);
}
}
]
});
});
Als de beschrijving van uw tool duidelijk is, kan uw agent de tool mogelijk autonoom gebruiken wanneer dat nodig is. U kunt uw agent bijvoorbeeld als volgt een taak laten uitvoeren met behulp van de tool:
The number of items in my cart is not updating. Inspect the global state at the
path cart.items and list the current items and their quantities, see if they are
the same.
Voorbeeld van agentuitvoering : Uw agent roept getGlobalState aan met de parameter path . Deze haalt de lijst met items uit het winkelmandje op en identificeert een discrepantie tussen de interne status en de items die op de pagina worden weergegeven.
Enkele belangrijke opmerkingen met betrekking tot dit toolvoorbeeld:
- Ontkoppelde logica : De AI-agent vraagt om de "status". Jij, als ontwikkelaar, bepaalt hoe je dat verzoek koppelt aan je daadwerkelijke datastructuur in de
execute. - Gerichte foutopsporing : Door de
pathtoe te voegen, kan de agent voorkomen dat de volledige statusboom (die enorm groot kan zijn) wordt opgehaald en zich alleen richten op het relevante gedeelte, waardoor tokens worden bespaard en de prestaties worden verbeterd. - Gestandaardiseerde interface : Zelfs als u overstapt op een andere bibliotheek voor statusbeheer, heeft uw AI-debuggingagent geen nieuwe instructies of tools nodig zolang u deze ene
executebijwerkt.
Inspecteer de database-inhoud
Controleer of uw backendgegevens overeenkomen met de status van de gebruikersinterface door rechtstreeks databasegegevens op te vragen via een alleen-lezen debug-eindpunt.
Stel een veilig debug-eindpunt beschikbaar en maak een tool zoals deze om backend-gegevens te verifiëren:
// Framework-agnostic implementation for inspecting database content
window.addEventListener('devtoolstooldiscovery', (event) => {
event.respondWith({
name: 'Database Inspection Tools',
description: 'Tools to query backend database records using existing browser session',
tools: [
{
name: 'queryDatabaseTable',
description: 'Retrieves a limited set of records from a specific table. Useful for verifying that backend data matches the UI state.',
inputSchema: {
type: 'object',
properties: {
tableName: {
type: 'string',
description: 'The name of the database table to inspect.'
},
limit: {
type: 'number',
default: 5,
description: 'Maximum number of rows to return.'
}
},
required: ['tableName']
},
execute: async (input) => {
// This calls a generic debug endpoint you've set up on your server.
// It's framework-agnostic because it just expects a JSON response.
try {
const response = await fetch(`/api/debug/db-inspect?table=${input.tableName}&limit=${input.limit}`);
if (!response.ok) {
return { error: `Backend returned ${response.status}: ${response.statusText}` };
}
return await response.json();
} catch (error) {
return { error: `Failed to connect to debug endpoint: ${error.message}` };
}
}
}
]
});
});
Als de beschrijving van uw tool duidelijk is, kan uw agent de tool mogelijk autonoom gebruiken wanneer dat nodig is. U kunt uw agent bijvoorbeeld als volgt een taak laten uitvoeren met behulp van de tool:
The total price on the checkout page seems wrong. Query the orders table for my
last order to verify the subtotal and tax values and see what may be causing the
problem, if any.
Voorbeeld van agentuitvoering : Uw agent roept queryDatabaseTable aan voor de tabel orders. Deze haalt het JSON-record op, identificeert een fout in de belastingberekening van de backend en stelt een oplossing voor de serverlogica voor.
Enkele belangrijke opmerkingen met betrekking tot dit toolvoorbeeld:
- Beveiliging en authenticatie : U hoeft geen databasegegevens aan de AI-agent door te geven. De
fetchaanroep gebruikt de huidige inlogsessie van de browser om het verzoek op uw backend te autoriseren. - Actiegericht debuggen : Als een AI-agent een UI-bug detecteert, kan deze direct
queryDatabaseTableaanroepen om te controleren of de fout zich in de brongegevens of de frontend-berekening bevindt. - Minimale configuratie : Je hoeft slechts één "veilig" (alleen-lezen) debug-eindpunt op je server beschikbaar te stellen dat een tabelnaam accepteert en JSON retourneert. Het framework dat je gebruikt om dat eindpunt te bouwen, maakt niet uit.