Tutorial API Grok 4.7: Construiește un evaluator AI pentru proiecte de circuite

O schemă electrică este o diagramă care arată cum se conectează componentele electronice. Revizuirea ei înseamnă verificarea dacă piesele și valorile lor respectă cerințele de proiectare. Poate sursa de alimentare să furnizeze suficient curent? Poate procesorul să citească întregul semnal al senzorului? Răspunsurile vin din schemă, din fișele tehnice ale componentelor și din câteva calcule.

Am vrut să văd dacă Grok 4.7 ar putea face întreaga revizuire. Ghidul Grok 4.7 spune că modelul a fost antrenat pentru sarcini mai lungi și pentru a-și verifica munca mai atent. Un circuit ne oferă și numere pe care le poate verifica Python obișnuit, așa că nu avem nevoie de un alt model AI care să judece rezultatul.

Pentru experiment, am construit EnviroNode Rev A, o mică placă cu senzori alimentată prin USB, și am introdus trei defecte în design. Grok nu este informat câte defecte există. Trebuie să le găsească, să susțină fiecare constatare cu documentație a componentelor, să propună corecții și să trimită valorile corectate la verificări în Python.

Nu ai nevoie de formare în inginerie electrică ca să urmărești. Explic fiecare regulă de circuit când apare prima dată. Vei învăța cum să:

• Trimiți o imagine a schemei către Grok 4.7 prin Responses API

• Atașezi fișe tehnice cu Files API și lași Grok să le caute

• Verifici calculele cu execuție de cod și limitele cu căutare web

• Îi dai lui Grok o funcție locală verify_design() care decide dacă trece sau nu

• Păstrezi o conversație lungă, plină de documente, în limita de context a modelului

• Primești un format de revizuire consecvent, apoi compari nivelurile de raționare

Aceeași placă rămâne în discuție de la prima revizuire a imaginii până la verificarea finală în Python.

Pe scurt

Grok 4.7 a identificat fiecare defect introdus odată ce a avut fișele tehnice, iar designul corectat a trecut verificările în Python. Asta spune ceva despre aceste trei defecte, nu despre revizuirea de circuite în general.

• Fără documente, Grok a refuzat să ghicească: imaginea singură a dat un defect confirmat, iar limitele regulatorului și ale convertorului analog-digital (ADC) au intrat la „necesită dovezi”.
• Fișele tehnice au transformat suspiciunea în dovezi: fiecare constatare a citat o valoare din document, fără să marcheze greșit vreo piesă corectă.
• Rundele cu multe fișiere pot epuiza contextul pe termen lung: după căutări repetate în PDF-uri, o continuare a depășit fereastra de 500K; bucla corectată compactează înainte de următoarea tură.
• Low a trecut verificatorul dar a expus un unghi mort: valorile filtrului au respectat verificările scrise, lăsând netestate sarcina capacitivă și comportamentul la stabilizare.

Aceasta este o singură placă, nu un test comparativ. O placă cu o duzină de fișe tehnice va crea un context mai mare și poate produce rezultate diferite.

Ce este API-ul Grok 4.7?

API-ul Grok 4.7 oferă aplicațiilor Python input de text și imagini, output de text și o fereastră de context de 500.000 de tokeni prin ID-ul modelului grok-4.7. Ghidul oficial listează nivelurile de raționare low, medium, high (implicit) și xhigh; raționarea nu poate fi dezactivată. API-ul suportă și apelare de funcții, outputuri structurate, căutare web, căutare pe X și execuție de cod.

Prezentarea Grok 4.7 acoperă lansarea și benchmark-urile. SpaceXAI etichetează Chat Completions ca fiind învechit, așa că fiecare exemplu de aici folosește Responses API.

Cât costă Grok 4.7?

Sub 200.000 de tokeni în prompt, Grok 4.7 costă 2 $ pe milion de tokeni de input, 0,50 $ pe milion de tokeni de input cache-uiți și 6 $ pe milion de tokeni de output. Odată ce un prompt ajunge la 200.000 de tokeni, fiecare token din acea cerere este taxat cu 4 $, 1 $ și 12 $.

Instrumentele server-side au taxe separate: pagina de prețuri taxează 5 $ per 1.000 de apeluri de căutare web sau execuție de cod. Căutările în documentele atașate costă un cent fiecare, iar documentele stocate au și un cost zilnic per GiB. Folosește un prompt_cache_key stabil pentru cereri înrudite, dar bugetează pentru input necache-uit.

Citește costul facturat din usage.cost_in_usd_ticks. Documentația de urmărire a costurilor spune că include caching-ul și taxele pentru instrumente. Împarte valoarea la 10^10 pentru dolari.

De ce să testezi Grok 4.7 pe proiectare de circuite?

Proiectarea de circuite testează citirea documentelor, calculele, utilizarea instrumentelor și verificarea într-o singură sarcină. SpaceXAI raportează 64,0% pentru Grok 4.7 pe EEBench. Metodologia EEBench folosește simulări și verificări ale listei de materiale (BOM) în locul unui judecător LLM, iar EnviroNode urmează aceeași regulă.

Ce vom construi: revizuirea circuitului EnviroNode Rev A

EnviroNode Rev A este un nod de senzori alimentat prin USB. Poți descărca proiectul complet de pe GitHub.

Schema conține fiecare valoare de componentă de care Grok are nevoie pentru revizuire. Fiecare cerință are un ID precum PWR-002 sau BW-001, astfel încât fiecare constatare poate indica înapoi către o regulă.

Schema EnviroNode Rev A cu valori. Imagine de autor.

Înainte ca Grok să revizuiască placa, expune fiecare regulă pe care o va folosi verificatorul. Funcția returnează cinci verificări trece-sau-nu bazate pe aceste opt cerințe:

• PWR-001: Intrarea USB rămâne între 4,75 V și 5,25 V
• PWR-002: Regulatorul acoperă vârful de sarcină
• PWR-003: Sarcinile non-MCU folosesc un buget de 10 mA
• SIG-001: Scala maximă a senzorului este 1,0 V
• ADC-001: Intrarea ADC rămâne la sau sub 2.250 mV
• ADC-002: Intrarea ADC ajunge la cel puțin 1.500 mV
• BW-001: Semnalele până la 100 Hz pierd mai puțin de 1 dB
• BW-002: Frecvența de tăiere a filtrului rămâne la sau sub 500 Hz

Modelul primește același set de cerințe. Nicio limită a verificatorului nu apare doar după ce Grok propune o remediere.

Care sunt cele trei defecte introduse?

Trei defecte pot fi verificate cu numere. Numărul lor nu este menționat în prompt.

• Regulator prea mic (PWR-002): TI TLV700 este evaluat la 200 mA, în timp ce fișa tehnică ESP32-C3 listează un vârf de transmisie Wi-Fi de 335 mA, iar lista de verificare a schemei de la Espressif cere cel puțin 500 mA.

• ADC peste domeniu (ADC-001): un câștig de 3 pune 3,0 V la ADC, dar domeniul efectiv din fișa tehnică se oprește la 2.500 mV, iar cerința permite 90% din asta.

• Filtru prea lent (BW-001): 10 kΩ și 1 μF dau o frecvență de tăiere de 15,9 Hz, în timp ce semnalele până la 100 Hz pot pierde cel mult 1 dB.

Defectul ADC ține de domeniul de măsurare, nu de avarierea pinului. Alegerile corecte, cum ar fi rezistorul LED și întârzierea CHIP_EN, fac ca pozitivele false să fie măsurabile.

Cum funcționează bucla de revizuire?

Revizuirea are nevoie de o delimitare clară: Grok propune schimbări, iar Python decide dacă trece sau nu. Diagrama arată unde intră documentele și instrumentele în acea buclă.

Bucla de revizuire separă propunerea de verificare. Imagine de autor.

Definește succesul înainte de primul apel API. Numără un defect doar când Grok îl leagă de o cerință și de dovezi suport. Numără o remediere doar când verify_design() returnează all_pass = true.

Cum configurezi API-ul Grok 4.7 în Python

Ai nevoie de o cheie de API xAI cu credite preplătite, Python 3.10 sau mai nou și SDK-ul OpenAI pentru Python configurat pe URL-ul de bază al xAI. Creează cheia în xAI Console, apoi instalează pachetele folosite mai jos.

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install openai python-dotenv pydantic httpx streamlit
pip install matplotlib schemdraw pytest  # Optional diagrams and verifier tests

Exemplele de API folosesc primul grup de pachete; al doilea susține diagramele și testele din depozit. Le-am testat cu Python 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 și httpx 0.28.1. Salvează cheia ca variabilă de mediu XAI_API_KEY și încarc-o cu python-dotenv în loc să o pui în codul sursă; ghidul nostru despre medii virtuale explică setarea dacă e nouă pentru tine.

Fă primul apel la API-ul Grok 4.7

Dacă cheia ta deja funcționează cu Responses API, sari la Pasul 1. Altfel, această cerere verifică cheia, URL-ul de bază și ID-ul modelului dintr-o lovitură.

import os
import httpx
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["XAI_API_KEY"], base_url="https://api.x.ai/v1",
                timeout=httpx.Timeout(3600.0))

response = client.responses.create(
    model="grok-4.7",
    reasoning={"effort": "low"},
    input="In one sentence, what does a low-dropout regulator do?",
)
print(response.output_text)

Un răspuns într-o propoziție înseamnă că setup-ul funcționează. Timeout-ul mare contează mai târziu, deoarece cererile care folosesc raționare și instrumente pot dura câteva minute.

Pasul 1: Poate Grok 4.7 să revizuiască un circuit dintr-o imagine?

Da, Grok 4.7 poate revizui o schemă doar dintr-o imagine, atâta timp cât promptul spune clar că nu urmează instrumente. Baza trimite PNG-ul ca un URL de date base64 împreună cu textul cerințelor.

image = {
    "type": "input_image",
    "image_url": f"data:image/png;base64,{SCHEMATIC_B64}",
    "detail": "high",
}
response = client.responses.create(
    model="grok-4.7",
    input=[{"role": "user", "content": [
        image,
        {"type": "input_text", "text": REVIEW_PROMPT},
    ]}],
)

Promptul cere trei secțiuni: confirmate, necesită mai multe dovezi și verificate și acceptabile. Nu menționează un număr de defecte sau o piesă suspectă.

Ce a găsit revizuirea doar din imagine?

Spune-i modelului explicit când nu sunt disponibile instrumente sau fișe tehnice. Altfel, poate încheia răspunsul după ce spune că va căuta o specificație la care nu are acces.

După cum s-a menționat la Pe scurt, Grok a confirmat defectul filtrului cu o frecvență de tăiere de 15,9 Hz și 16,1 dB pierdere la 100 Hz. A pus regulatorul și ADC-ul la „necesită mai multe dovezi” în loc să ghicească limitele lor.

Pasul 2: Cum adaugi fișe tehnice cu Files API

Documentele atașate transformă o îngrijorare vagă într-o afirmație susținută de numere. Încarcă fiecare document o singură dată și fă referire la el prin file_id.

with open(DATASHEET_PATH, "rb") as datasheet:
    uploaded = client.files.create(
        file=datasheet,
        purpose="assistants",
        expires_after={"anchor": "created_at", "seconds": 7 * 24 * 3600},
    )
content = [image, *[{"type": "input_file", "file_id": fid} for fid in file_ids],
           {"type": "input_text", "text": EVIDENCE_PROMPT}]

Pentru că acest tutorial setează expires_after la șapte zile, ID-urile cache-uite sunt valide doar în acea fereastră. Fără expires_after, xAI păstrează fișierele încărcate până când le ștergi.

În răspunsurile SDK-ului OpenAI capturate aici, căutarea în atașamente a apărut ca elemente custom_tool_call numite pdf_search și pdf_browse, în timp ce utilizarea le-a numărat la document_search_calls. Asta e un comportament observat, nu contractul general al tipurilor de instrumente, așa că bucla verifică și contorul de utilizare documentat.

Cum schimbă fișele tehnice revizuirea?

Documentele au rezolvat cele două întrebări deschise din Pasul 1 și au susținut constatările privind alimentarea, ADC-ul și filtrul. Constatările pentru regulator au citat ratingul de 200 mA al TLV700, vârful de 335 mA al ESP32-C3 la transmisie și recomandarea de 500 mA pentru alimentare.

Pentru filtru, Grok a dedus ce valori ale condensatorului ar satisface ambele reguli de lățime de bandă cu R5 neschimbat: aproximativ 32 până la 81 nF. Fiecare capcană a ajuns la „verificate și acceptabile”, cu motiv.

Pasul 3: Cum verifici calculele cu execuția de cod Grok 4.7

Execuția de cod este sandbox-ul Python pe server al xAI, adăugat la tools ca {"type": "code_interpreter"} când folosești clientul OpenAI. Promptul adaugă o regulă: fiecare afirmație cu numere trebuie calculată înainte să conteze ca fiind confirmată.

Ghidul pentru execuția de cod menționat mai devreme spune că sandbox-ul nu are acces la rețea și nu păstrează stare între cereri. Pentru câteva numere din fișe tehnice, e în regulă.

Ce calcule ar trebui să verifice Grok?

Cere-i lui Grok să verifice bugetul de putere, domeniul ADC și lățimea de bandă a filtrului într-un singur script. Dacă nu te pasionează circuitele, sari peste outputul de mai jos; concluzia urmează după el.

f=  100.0 Hz  |H|=0.157177  attenuation=16.0722 dB
fc required for <= 1 dB at 100 Hz: fc >= 196.5227 Hz
V_adc_fs = 3.0000 V
90% limit = 2.2500 V
required rating = max(headroom, mcu min) = 500.00 mA

Minimul de 196,5 Hz pentru frecvența de tăiere este numărul de care depinde remedierea filtrului, iar codul îl calculează în loc să-l lase la aritmetica modelului. Chiar și colțul de toleranță cu cea mai mică atenuare pierde peste 15 dB la 100 Hz, deci verdictul rămâne.

Pasul 4: Poate Grok 4.7 să caute pe web prin API?

Da. Căutarea web verifică dacă documentele atașate sunt încă actuale, deoarece producătorii revizuiesc fișele tehnice după limita de antrenare a unui model. Restrânge-o la domenii oficiale ca dovezile să rămână de la prima sursă.

tools = [
    {"type": "code_interpreter"},
    {"type": "web_search", "filters": {"allowed_domains": ["ti.com", "espressif.com"]}},
]

Ghidul de căutare web menționat mai devreme permite până la cinci allowed_domains, inclusiv subdomenii precum docs.espressif.com. Aș păstra acest pas chiar și când fișele atașate sunt actuale, pentru că poate prinde o revizie publicată după încărcarea ta.

Ce dovedesc citările?

Grok ar trebui să citeze pagina de produs TI actuală, documentația ESP32-C3, lista hardware și orice erată relevantă. Tratează acele citări ca dovezi ale sursei, nu ca dovadă că concluzia inginerească este corectă.

Filtrele de domeniu pot totuși returna o pagină irelevantă. Verifică ca fiecare citare să susțină componenta exactă și limita folosită în calcul.

Grok caută în fișiere, calculează, verifică sursele. Imagine de autor.

Pasul 5: Cum adaugi un verificator cu apelarea de funcții Grok 4.7

verify_design() este o funcție Python simplă care rulează pe mașina ta și este singurul judecător dacă o revizie trece. Grok propune valori de proiect prin apelare de funcții, iar funcția le verifică față de limite fixe.

VERIFY_DESIGN_TOOL = {
    "type": "function",
    "name": "verify_design",
    "description": "Deterministically check an EnviroNode revision against EN-REQ-001...",
    "parameters": {
        "type": "object",
        "properties": {
            "revision": {"type": "string"},
            "regulator_part": {"type": "string"},
            "gain_rf_ohm": {"type": "number"},
            "gain_rg_ohm": {"type": "number"},
            "filter_r_ohm": {"type": "number"},
            "filter_c_nf": {"type": "number"},
        },
        "required": ["revision", "regulator_part", "gain_rf_ohm",
                     "gain_rg_ohm", "filter_r_ohm", "filter_c_nf"],
    },
}

Capacitatea de putere trebuie să îndeplinească max((335 + 10) mA × 1.25, 500 mA). Pentru ADC, 1.0 V × (1 + Rf/Rg) trebuie să rămână între 1.500 și 2.250 mV. Verificările filtrului măsoară pierderea la 100 Hz și limitează frecvența de tăiere la 500 Hz; fiecare verificare returnează o valoare, o limită și trece sau nu.

Schema instrumentului îi spune lui Grok doar ce valori să trimită. Logica de bază trece-sau-nu e Python obișnuit:

import math

part = PARTS.get(regulator_part.strip().upper())
required_ma = max((335 + 10) * 1.25, 500)
power_ok = (
    part is not None
    and float(part["rated_iout_ma"]) >= required_ma
    and float(part["vin_max_v"]) >= 5.25
    and float(part["vout_v"]) == 3.3
)

gain = 1 + gain_rf_ohm / gain_rg_ohm
adc_mv = gain * 1000

fc = 1 / (2 * math.pi * filter_r_ohm * filter_c_nf * 1e-9)
loss_db = 10 * math.log10(1 + (100 / fc) ** 2)

checks = {
    "PWR-002": power_ok,
    "ADC-001": adc_mv <= 2250,
    "ADC-002": adc_mv >= 1500,
    "BW-001": loss_db <= 1.0,
    "BW-002": fc <= 500,
}
return {"all_pass": all(checks.values()), "checks": checks}

Funcția completă respinge și valori invalide și returnează măsurători cu fiecare rezultat. Testeaz-o cu un design cunoscut bun, unul cunoscut slab, o componentă necunoscută și un caz-limită.

De ce ar trebui ca nota să fie dată de cod, nu de model?

Păstrează ratingurile componentelor în afara controlului modelului. Nu aș lăsa modelul să furnizeze propriul rating de curent. Grok trimite un cod de piesă, iar funcția caută ratingul în catalogul aplicației.

Un agent nu ar trebui să propună o soluție și să decidă dacă e corectă atunci când codul poate verifica răspunsul. Înlocuiește verify_design() cu o suită de teste sau o verificare de schemă când sarcina se schimbă. Scrierea verificatorului cere muncă în plus, dar rezultatul trece-sau-nu nu depinde de opinia modelului.

Pasul 6: Cum reproiectezi și verifici circuitul

Dă-i lui Grok un singur obiectiv: să remedieze fiecare încălcare confirmată cu cel mai mic set rezonabil de schimbări, și să nu declare designul finalizat până când verificarea definită mai devreme nu trece. Furnizează dovezile și instrumentele din pașii 3 până la 5, apoi stabilește o limită de cereri.

Aici contează avertismentul de context din Pe scurt. Rezolvă-l înainte să adaugi mai multe ture.

De ce au buclele cu multe fișiere nevoie de compactarea contextului?

O cerere continuată include rezultatele instrumentelor anterioare, iar căutările în documente pot întoarce mult text. În prototipul eșuat, următoarea continuare a ajuns la 1.116.321 de tokeni și a depășit fereastra de 500.000 de tokeni a Grok 4.7.

Compactarea contextului nu poate salva o cerere care deja este peste limită. Bucla corectată compactează fiecare rundă de căutare în documente reușită înainte de a trimite următoarea cerere.

details = (response.usage.model_extra or {}).get(
    "server_side_tool_usage_details", {}
)
observed_attachment_call = any(
    item.type == "custom_tool_call"
    and item.name in {"pdf_search", "pdf_browse"}
    for item in response.output
)
used_documents = (
    details.get("document_search_calls", 0) > 0
    or observed_attachment_call
)

if used_documents:
    compacted = client.responses.compact(
        model="grok-4.7", input=history + list(response.output) + follow_up)
    history = list(compacted.output)  # pass the compaction item back unchanged
    # Compaction drops tool output, so restate the verifier's verdict ourselves.
    history.append({"role": "user", "content":
                    "verify_design results, exactly as returned: " + json.dumps(results)})
else:
    history = history + list(response.output) + follow_up
response = client.responses.create(model="grok-4.7", input=history, tools=TOOLS,
                                   store=False, prompt_cache_key=cache_key)

Păstrează acel ultim append. Compactarea elimină outputul voluminos al instrumentelor, așa că reformularea rezultatului verificatorului ajută răspunsul următor să evite verificări inventate sau confuze. Compactarea după fiecare rundă cu multe documente este o cadență conservatoare; un sistem mai mare poate folosi un prag de tokeni de input în schimb.

A trecut Rev B verificarea?

Da. Grok a schimbat o piesă în fiecare subsistem care eșua: alimentare, câștig ADC și lățime de bandă a filtrului. Diagrama arată valorile exacte pentru Rev A și Rev B.

Trei schimbări de componente corectează Rev A. Imagine de autor.

Valorile revizuite merg apoi la verify_design(). Aceasta returnează un rezultat pentru fiecare cerință.

Designul revizuit trece toate verificările. Imagine de autor.

Un rezultat eșuat se întoarce ca function_call_output, astfel încât Grok poate revizui designul până când verificările trec sau se atinge limita de cereri.

Pasul 7: Cum returnezi o revizuire structurată a circuitului

Outputurile structurate returnează un obiect care se potrivește unei scheme în loc de proză pe care ar trebui să o parsezi. Apelează client.responses.parse() cu un model Pydantic în aceeași conversație, cu apelurile de instrumente oprite.

class Finding(BaseModel):
    violated_requirement: str
    severity: Literal["blocker", "major", "minor"]
    evidence: list[str]
    recommended_change: str
    verifier_result: Literal["pass", "fail", "not_verified"]

parsed = client.responses.parse(
    model="grok-4.7", input=history + [REPORT_REQUEST],
    text_format=DesignReview, tools=TOOLS, tool_choice="none", store=False,
)

O schemă validă nu dovedește că conținutul e corect, așa că include rezultatele verificatorului și spune-i lui Grok să bazeze verifier_result pe ele. JSON-ul poate apoi alimenta un tracker de issue-uri sau o coadă de aprobare umană.

Ce a raportat revizuirea structurată?

Raportul structurat ar trebui să marcheze fiecare defect inițial ca rezolvat, să citeze valoarea măsurată returnată de verificator și să păstreze îngrijorările netestate sub open_risks. Pentru acest design, acele îngrijorări includ un regulator care stă exact la pragul de 500 mA și un condensator ADC diferit de recomandarea Espressif.

Îmbunătățește efortul de raționare Grok 4.7 revizuirea circuitului?

Efortul mai mare nu a îmbunătățit scorul verificatorului, dar a schimbat calitatea remedierii filtrului. Fiecare nivel a primit aceeași schemă, același prompt, aceleași instrumente și aceeași limită de cereri.

low a reduct rezistorul și a păstrat condensatorul de 1 μF, lăsând sarcina capacitivă și comportamentul la stabilizare în afara verificatorului. Ghidul pentru sarcină capacitivă de la Microchip spune că un rezistor în serie poate îmbunătăți stabilitatea, deci acest rezultat nu dovedește că remedierea este instabilă; cere testare de răspuns în frecvență, răspuns la treaptă sau pe banc. high a schimbat în schimb condensatorul, în timp ce xhigh a ales aceleași valori finale ca high după un apel suplimentar la verificator.

Când merită raționarea xhigh?

Pentru această singură comparație, high a oferit un echilibru mai bun. A evitat îngrijorarea privind sarcina nemodelată fără apelul suplimentar la verificator făcut de xhigh. O execuție per nivel nu poate stabili un clasament general.

A reparat Grok 4.7 circuitul?

Răspunsul la întrebarea de deschidere este da, în limitele verificatorului cu cinci verificări. Tabelul condensează constatările anterioare într-o singură privire.

• Imagine și cerințe
  • Adaugă: Inspecție vizuală
  • Rezultat: Confirmă ce poate dovedi doar schema
• Fișe tehnice
  • Adaugă: Limite ale producătorului
  • Rezultat: Transformă două întrebări deschise în constatări
• Execuție de cod
  • Adaugă: Calcule verificate
  • Rezultat: Măsoară problemele de putere și filtrare
• Căutare web
  • Adaugă: Surse oficiale actuale
  • Rezultat: Verifică dacă dovezile atașate sunt actuale
• Verificator local
  • Adaugă: Trecere sau eșec din Python
  • Rezultat: Acceptă doar o revizie care trece fiecare regulă

Grok a remediat cerințele codificate. Nu a dovedit că placa revizuită era electric completă sau gata de producție.

Documentele decid dacă o îngrijorare are dovezi. Python decide dacă o revizie trece. Proza fluentă nu poate înlocui niciuna dintre ele.

Vezi revizuirea în Streamlit

Ghidul nostru Streamlit explică interfața folosită aici. Folosește streaming pentru a arăta apelurile de instrumente pe măsură ce sosesc, apoi afișează verificările și raportul final.