AI agentas nenaudoja įrankių: pirmiausia perskaitykite n8n vykdymo žurnalą

AI agentas nenaudoja įrankių: tai viena iš dviejų problemų, dėl kurių į mus dabar kreipiasi dažniausiai. Antroji dar nemalonesnė: įrankis suveikia, grąžina būtent tuos duomenis, kurių reikia, o modelis atsako taip, lyg nieko nebūtų gavęs. Abiem atvejais atrodo, kad kaltas modelis. Abiem atvejais beveik visada kaltos jungtys, ir vykdymo žurnale (trace) tai pamatysite maždaug per dešimt minučių. Taisymas nieko nekainuoja: tereikia nustoti taisyti sistemos instrukciją (system prompt) ir pažiūrėti, ką modelis iš tikrųjų gavo.

Šiame puslapyje rasite du tikrus vykdymo žurnalus, penkias priežastis, kurios paaiškina beveik visus mūsų matytus atvejus, ir sekimo įrankį, kurį galite įdėti į bet kurį n8n agento workflow ir matyti, kas vyko kiekviename žingsnyje.

AI agentas nenaudoja įrankių: ką turi parodyti vykdymo žurnalas

n8n AI Agent mazgas saugo kiekvieno vykdymo žurnalą: atidarykite vykdymą ir spustelėkite agentą. Žiūrėkite į iteracijų seką, modelio atsiųstus argumentus ir neapdorotą grąžintą reikšmę. Jei spėliosite vien pagal galutinį atsakymą, prarasite visą dieną.

Pirmas atvejis: įrankis suveikė, o modelis jo rezultatą ignoravo

[Agent] iteration 1
  tool:        get_order_status
  arguments:   { "orderId": "SO-10442" }

[Tool]  get_order_status -> returned in 412ms
  {
    "orderId": "SO-10442",
    "status": "shipped",
    "carrier": "DHL",
    "tracking": "JJD014600010847264011",
    "eta": "2026-08-27"
  }

[Agent] iteration 2
  tool:        none
  output:      "I don't have access to order information in this chat.
                Please email support and they will look it up for you."

  usage: prompt 7,942  completion 31

Įrankis veikė. Duomenys buvo teisingi, atėjo laiku ir buvo pokalbyje. Tačiau modelis atsisakė atsakyti į klausimą, nors atsakymą turėjo, o klientą nusiuntė rašyti į pašto dėžutę, iš kurios atsakoma per dvi dienas.

Galimos priežastys dvi, ir įvesties tokenų (prompt tokens) skaičius parodo, kuri iš jų. Esant 7 942 įvesties tokenams mažame modelyje su ribotu pokalbio atminties langu, įrankio rezultatas galėjo iškristi iš konteksto dar prieš antrą iteraciją: n8n atminties mazgai saugo fiksuotą ankstesnių žinučių skaičių, o ilgas įrankio atsakymas kartu su ilgu pokalbiu naudingą dalį išstumia. Antra galima priežastis yra sistemos instrukcijos eilutė, pavyzdžiui, „jei nesate tikras, pasakykite klientui, kad neturite prieigos prie jo duomenų“. Tokia eilutė modeliui yra visada atviras atsarginis išėjimas, ir jis juo naudojasi, ypač kai grąžintas JSON atrodo ne taip, kaip aprašyta instrukcijoje.

Antras atvejis: įrankis nebuvo iškviestas

[Agent] iteration 1
  tool:        none
  output:      "Order SO-10442 is being processed and should ship
                within two business days."

  tools available: 4
  tool calls:      0
  usage: prompt 1,088  completion 22

Keturi prijungti įrankiai, nė vieno iškvietimo ir užtikrintai išgalvotas atsakymas. Dabar pažiūrėkite, ką modelis gavo, nes būtent tokį apibrėžimą n8n siunčia modelio tiekėjui:

{
  "name": "HTTP_Request",
  "description": "",
  "parameters": {
    "type": "object",
    "properties": {
      "url":   { "type": "string" },
      "query": { "type": "string" }
    }
  }
}

Įrankis pavadinimu HTTP_Request su tuščiu aprašymu modeliui praktiškai nematomas. Modelis nemato nei Jūsų mazgo, nei Jūsų workflow. Jis gauna tik pavadinimą, aprašymą ir parametrų schemą ir vien pagal šiuos tris laukus sprendžia, ar įrankis tinka naudotojo klausimui. Neturėdamas į ką atsiremti, modelis atsako iš to, ką žino pats. Tai tas pats mechanizmas, dėl kurio pokalbių robotas išgalvoja atsakymus.

Penkios priežastys, kurias verta tikrinti tokia tvarka

1. Aprašymas tuščias, per bendras arba parašytas Jums, o ne modeliui. „Gauna duomenis“ ar „Užklausia duomenų bazę“ modeliui nieko nesako. Pagal aprašymą modelis renkasi įrankį, todėl jame turi būti parašyta, kada įrankį naudoti: „Pagal užsakymo numerį suranda dabartinę kliento užsakymo būseną, vežėją ir numatomą pristatymo laiką. Naudok kaskart, kai klientas klausia, kur jo užsakymas.“ Vien šis pakeitimas pataiso daugiau agentų klaidų nei visa kita šiame sąraše.
2. Trūksta parametrų aprašymų, todėl modelis nežino, kaip užpildyti argumentus, ir verčiau įrankio nekviečia, nei spėlioja. Kiekvienai schemos savybei parašykite po eilutę su laukiamu formatu: agentas, kuris nežino, ar orderId reiškia SO-10442, ar 10442, dažnai tiesiog pasiduoda.
3. Įrankio rezultatas nepasiekė antro žingsnio. Taip nutinka ir dėl riboto pokalbio atminties lango, ir dėl milžiniškų įrankių atsakymų. Jei įrankis grąžina 400 eilučių JSON, o atsakymui reikia keturių laukų, jis pats save išstumia iš konteksto.
4. Įrankis grąžino tuščią masyvą, ir modelis tuo patikėjo. Šį atvejį žmonės nepastebi savaitėmis, todėl jam skirtas atskiras skyrius žemiau.
5. Sistemos instrukcija prieštarauja įrankių naudojimui. Nurodymai atsakyti glaustai, remtis pokalbiu, nespėlioti ar perduoti pokalbį žmogui, kai modelis nėra tikras, konkuruoja su nurodymu kviesti įrankį. Dažniausiai laimi atsisakymas, nes jis trumpesnis ir modeliui atrodo saugesnis.

Klaida ir tuščias rezultatas atrodo panašiai

Jums šie du atsakymai reiškia visiškai skirtingus dalykus, o modeliui maždaug tą patį:

get_open_invoices -> []

get_open_invoices -> { "error": "ETIMEDOUT", "message": "connect ETIMEDOUT 10.0.0.4:5432" }

Pirmasis sako, kad klientas neturi neapmokėtų sąskaitų, ir modelis tai praneš kaip faktą, net jei užklausoje buvo blogas filtras ir tai netiesa. Antrasis yra sistemos gedimas. Jei mazgui įjungta „continue on fail“, klaidos objektas į pokalbį patenka kaip duomenys, ir modelis bando Postgres ryšio skirtojo laiko klaidą (timeout) suprasti kaip verslo atsakymą.

Skirtumą padarykite matomą pačiame įrankyje. Kai paieška nieko neranda, grąžinkite aiškų atsakymą, pavyzdžiui, { "found": false, "reason": "no invoices matched customer 88213" }, o tikros klaidos tegul lieka klaidomis, kad agentas galėtų bandyti dar kartą arba perduoti pokalbį žmogui. Jei įrankis visada grąžina sėkmę, modelis negali atskirti, kada ji tikra.

Įrašykite visą apsikeitimą, o ne spėliokite

Viskas, kas parašyta aukščiau, lieka spėlionėmis, kol nematote, kas iš tikrųjų buvo perduota. Prie šio puslapio pridėtas sekimo įrankis apgaubia Jūsų esamus įrankius ir kiekvienam iškvietimui įrašo eilutę: laiką, įrankio pavadinimą, modelio atsiųstus argumentus, neapdorotą grąžintą reikšmę prieš bet kokį formatavimą, tos reikšmės dydį ir kitą modelio žinutę. Importuokite jį, nukreipkite agento įrankius per jį ir paleiskite nepavykusį pokalbį dar kartą.

Dažniausiai atsakymą duoda neapdorotos grąžintos reikšmės eilutė. Devyniais atvejais iš dešimties įrankis grąžina šiek tiek ką kita, nei tikėjosi kūrėjas: apgaubtą objektą vietoj paprasto masyvo, JSON kaip tekstą, kurį modelis turi išsinagrinėti pats, null lauke, kuriame instrukcija žadėjo skaičių, arba tuščią rezultatą dėl filtro, kuris buvo klaidingas nuo pat pradžių.

Ištaisę klaidą, žurnalo neišjunkite. Tai pigiausia testavimo forma, aprašyta straipsnyje apie verslo automatizacijų testavimą: vietoj „agentas vėl keistai elgiasi“ turite konkrečią eilutę, kurią galima parodyti. Kodėl tai svarbu, matėme vieno kliento sistemoje: potencialių klientų paskirstymo n8n workflow, apie 200 vykdymų per dieną, maždaug kartą per dieną lūždavo, o vienintelis jo įspėjimas buvo siunčiamas į Slack kanalą, suarchyvuotą keliais mėnesiais anksčiau. Pranešimų niekas neskaitė, todėl apie gedimus niekas ir nežinojo.

Ką galite sutvarkyti šiandien patys

Dauguma agentų problemų su įrankiais yra dvidešimties minučių darbas, kai žinote, kur žiūrėti. Jei pavyks patiems, už pagalbą mokėti nereikės.

• Kiekvienam įrankiui parašykite tikrą aprašymą su fraze, kurią pasakytų naudotojas. Tada perskaitykite įrankių sąrašą taip, lyg būtumėte modelis, ir paklauskite savęs, ar aišku, kurį rinktis.
• Kiekvienam parametrui pridėkite aprašymą su laukiamu formatu.
• Sutrumpinkite įrankio atsakymą iki laukų, kurių reikia atsakymui. Ilgi atsakymai išstumia visa kita iš konteksto lango.
• Ištrinkite iš sistemos instrukcijos kiekvieną eilutę, leidžiančią modeliui sakyti, kad jis neturi prieigos, nebent būtent to norite, kai įrankis sugenda.
• Patikrinkite, ar Jūsų modelis apskritai palaiko funkcijų iškvietimą (function calling). Kai kurie mažesni atviri modeliai, reklamuojami kaip pokalbių modeliai, jo nepalaiko, ir tada n8n bando ištraukti įrankių iškvietimus iš paprasto teksto. Toks sprendimas veikia su pertrūkiais ir atrodo lygiai taip, lyg modelis Jus ignoruotų.
• Prieš keisdami ką nors kita, du kartus paleiskite nepavykusį pokalbį su įjungtu sekimo įrankiu.

Jei po šių žingsnių agentas elgiasi taip, kaip turi, problema išspręsta.

Kada verta kreiptis pagalbos

Kreipkitės, kai agentas dažniausiai atsako teisingai, bet kartais nenuspėjamai suklysta, kai jis turi tiek įrankių, kad pats pasirinkimas tapo problema, kai du įrankiai persidengia ir jis vis renkasi ne tą, arba kai jis jau atsakinėja tikriems klientams ir niekas negali pasakyti, kaip dažnai jis kažką išgalvoja. Tokių problemų vien apžiūrėję neišspręsite, nes gedimas matomas tik per daugybę vykdymų, todėl darbas prasideda nuo matavimo, o ne nuo instrukcijos taisymo. Tai panašu į atvejį, kai workflow veikia, bet nieko nevyksta: sistema praneša apie sėkmę, o rezultato nėra.

Pirmas žingsnis yra raštiška diagnostika už 450 €, pateikiama per dvi darbo dienas, o visa jos kaina įskaitoma į tolesnius darbus. Nedideli pataisymai kainuoja nuo 700 iki 1 400 €. Standartinis taisymas kainuoja nuo 1 400 iki 3 700 €, kūrimas iš naujo nuo 3 700 iki 9 200 €, ir visiems darbams taikoma 30 dienų garantija klaidoms. Diagnostikos ataskaita lieka Jums, todėl su ja galite kreiptis ir į kitą įmonę ir palyginti pasiūlymus.

Mūsų sukurtos sistemos veikia kasdien, tarp jų ir balso administratorius. Viena iš jų yra dokumentų generatorius hidrogeologijos įmonei: jis rengia reglamentuotų dokumentų rinkinius iš pačios įmonės gręžinių duomenų. Ši sistema įrankius kviečia beveik kiekviename vykdyme, ir kiekvienas iškvietimas įrašomas, nes kitaip apie problemą sužinotume tik iš kliento. Jei norite tokios pačios kontrolės savo sistemoje, pradėkite nuo taisymo paslaugos, o jei agentas yra tik viena didesnės, nuolat lūžtančios sistemos dalis, plačiau apie tai rašome straipsnyje apie nuolat lūžtančius n8n workflow.