Paras agenttinen ERP-ohjelmisto: mitä etsiä

Miksi täällä ei ole rankingia

Kuvittele lyhyt lista. Neljä toimittajaa, neljä ehdotusta ja sana agenttinen jokaisessa kansiossa. Yksi on vakiintunut paketti, johon on lisätty avustaja viime vuonna. Yksi on uudempi tuote, joka on rakennettu oman agenttinsa ympärille. Yksi on alusta, joka sallii minkä tahansa agentin yhdistää avoimen protokollan kautta. Yksi on työnkulun työkalu, jossa on kielimalli keskellä. Kaikki neljä esittelevät hyvin. Kaksi heistä odottaa silti henkilöä näytön ääressä, kun jokin ylittää moduulirajan, etkä saa selville, mitkä kaksi ehdotuksista ovat.

Luokiteltu lista ei voi auttaa tässä, syystä, joka ei liity tuotteiden laatuun. Agenttisuus on arkkitehtuurin ominaisuus, ja se, onko tietty arkkitehtuuri oikea sinulle, riippuu siitä, mitä moduuleja käytät, mitä agenttia tiimisi jo käyttää, mitkä ovat hyväksymiskynnyksesi ja kuinka paljon sinun tarvitsee nähdä lokissa. Nämä ovat sinun faktojasi, eivät arvioijan. Se, mikä liikkuu yritysten välillä, on testisarja, joten tämä sivu antaa sinulle testit ja pyytää sinua tekemään luokituksen.

Testi 1: avoin protokolla, agenttisi ulkopuolelta

Ensimmäinen testi on, voiko järjestelmää käyttää agentti, jota toimittaja ei ole rakentanut. Avoin standardi tälle on Model Context Protocol, jota valtavirran agenttiasiakkaat puhuvat: Claude lisää etä-MCP-palvelimen mukautettuna liittimenä OAuth-kirjautumisella; ChatGPT tekee saman kehittäjätilassa täydellä luku- ja kirjoitustuella; koodausagentit ja toimittajan SDK:ta hyödyntävät sisäiset agentit yhdistävät samalla tavalla. Tuotetta, joka puhuu MCP:tä, voi käyttää kuka tahansa heistä. Tuotetta, joka toimii vain oman avustajansa kanssa, ei voi käyttää kukaan muu, ja tämä päätös on tehty puolestasi.

Pyydettävä todiste on palvelimen vastaus työkaluja/listaa koskevaan pyyntöön, joka protokollan mukaan on koneellisesti luettava lista kaikesta, mitä agentti voi tehdä. Sen tulisi näyttää tältä, toistettuna jokaiselle toiminnolle järjestelmässä.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

Esimerkki työkaluja/listaa koskevasta vastauksesta MCP-määrityksen määrittelemässä muodossa. Nimien ja kattavuuden on oltava erilaisia tuotteittain; tärkeää on, että lista on olemassa, on tyypitetty ja on tarpeeksi pitkä kattamaan käyttämäsi moduulit.

Kolme asiaa tarkistettavaksi luettelossa. Se on pitkä, koska ERP:llä on satoja toimintoja ja kaksikymmentä tarkoittaa, että avustaja pääsee kaksikymmentä ominaisuutta. Se on kirjoitettu, ja jokaiselle syötteelle on JSON-skeema, koska se mahdollistaa palvelimen validoida kutsuja sen sijaan, että se tulkitsee proosaa. Ja se muuttuu, kun rajoitetumpi käyttäjä kirjautuu sisään, mikä on silta toiseen testiin.

Testi 2: käyttäjäkohtaiset käyttöoikeudet jokaisessa kutsussa

Agentti, joka voi tehdä enemmän kuin henkilö, jota se edustaa, on vastuukysymys, ei ominaisuus. Toinen testi on, toteutetaanko käyttöoikeuksia käyttäjä- ja kutsukohtaisesti, ei tuotekohtaisesti tai istuntokohtaisesti. Protokolla sallii palvelimen muuttaa työkalulistaa esitetyn valtuutuksen mukaan ja vaatii palvelimia toteuttamaan asianmukaiset pääsynhallintakontrollit, mutta se ei voi valvoa kumpaakaan myyjän puolesta. Hyvät toteutukset suodattavat luettelon ennen kuin agentti näkee sen ja tarkistavat sen uudelleen, kun jokainen työkalu toimii, koska suodatettu luettelo on kohteliaisuus ja suoritusaikainen tarkistus on kontrolli.

Todiste on elävä kieltäytyminen. Kirjaudu sisään käyttäjänä, joka ei voi hyväksyä ostotilauksia, pyydä heidän agenttiaan hyväksymään yksi ja katso, mitä tapahtuu. Oikea vastaus on selkeä kieltäytyminen kutsun kohdalla, kirjattuna, kun muu pyyntö vielä valmistuu. Väärät vastaukset ovat hyväksyntä, joka menee läpi, virhe, joka paljastaa, mitä työkalu olisi tehnyt, tai istunto, joka epäonnistuu avoimeksi, koska tarkistus oli vain näytöllä.

Testi 3: budjetin ja kustannusten läpinäkyvyys

Agentti, joka perustelee myyjän malleilla, kuluttaa jotain joka kerta, kun se toimii, ja kolmas testi on, voitko rajoittaa tuota kulutusta ja nähdä, mihin se meni. Erityinen mekanismi on vähemmän tärkeä kuin kaksi ominaisuutta: raja, joka on asetettu integraatiokohtaisesti tai avainkohtaisesti, jota agentti ei voi ylittää, ja toimintokohtainen kirjaus siitä, mitä jokainen suoritus maksoi. Tuote, joka voi kertoa sinulle vain kuukausittaisen kokonaismäärän jälkikäteen, ei ole rakentanut mittaria, ja tulet huomaamaan sen, kun hallitsematon silmukka tai innokas uusi käyttäjä osuu laskuun.

On olemassa toinen kustannuskysymys, jonka arviointisivut ohittavat täysin. Jos tuote sallii sinun tuoda oman agenttisi, silloin kun se agentti tekee päättelyä, myyjä ei välttämättä suorita lainkaan tekoälyä puolestasi, eikä veloita siitä mitään. Tiimille, joka jo maksaa Claudelle tai ChatGPT:lle, tämä muuttaa agenttikustannuksen riviksi, jota hallitset, sen sijaan että se olisi rivi, jonka myyjä asettaa. Kysy jokaiselta myyjältä, mitä he veloittavat, kun oma agenttisi tekee ajattelun, ja kirjoita vastaus ylös.

Testi 4: auditointi, joka muistuttaa henkilön lokia

Kun agentti tekee työn, lokista tulee ensisijainen tapa, jolla johtaja tarkistaa sen, joten neljäs testi on, tallentaako tarkastuspolku agentin toimet yhtä täydellisesti kuin henkilön. Vähimmäisvaatimus on, kuka kysyi, mikä agentti toimi heidän puolestaan, mitkä työkalut toimivat, millä syötteillä, millä tuloksilla ja milloin. Protokollan oma ohjeistus on, että asiakkaiden tulisi kirjata työkalujen käyttö tarkastusta varten; palvelimen tulisi tehdä sama omalta puoleltaan, koska juuri palvelin tietää, mitä todella muuttui.

Todiste on loki itsessään, demopyynnön jälkeen. Avaa se ja tarkista neljä asiaa: henkilölle annettu tunnustus, ei yleiselle integraatiokäyttäjälle; työkalukutsujärjestys, ei vain ne tiedot, jotka päätyivät muuttuneiksi; syötteet ja tulokset, jotta väärä toiminto voidaan jäljittää väärään syötteeseen; ja kieltäytymiset, koska käyttöoikeusmalli, joka ei kirjaa kieltojaan, ei voi olla säädettävissä.

Testi 5: markkinapaikka ja mitä se kertoo sinulle

Viides testi on epäsuora mutta paljastava. Jos alustalla on sovellusten markkinapaikka, jonka ovat rakentaneet muut kuin myyjä, ja näitä sovelluksia käyttävät agentit saman työkaluliittymän kautta kuin ydintoimintomoduulit, silloin työkaluliittymä on todellinen, dokumentoitu ja tarpeeksi vakaa, jotta ulkopuoliset voivat rakentaa sen päälle. Markkinapaikka on myyjän oma arkkitehtuuri, jota testataan vieraiden toimesta joka päivä. Se vastaa myös käytännön kysymykseen siitä, mitä tapahtuu, kun tarvitset kyvykkyyden, jota ydintuote ei tarjoa: odotatko tiekarttaa, maksatko räätälöidystä työstä vai asennatko jotain, joka jo on olemassa.

Todiste on julkaistu sovellus kolmannelta osapuolelta, asennettuna kokeilutilaasi, joka näkyy agentin työkalulistalla seuraavassa pyynnössä. Jos markkinapaikka on olemassa, mutta sovellukset ovat kaikki myyjän omia, tai jos yhden asentaminen ei muuta sitä, mitä agentti voi tehdä, testi on vain puoliksi läpäisty.

Tulostaulu

Ota tämä jokaiseen demoon ja täytä se päivänä. Arvioi jokainen testi läpäistyksi, osittain läpäistyksi tai epäonnistuneeksi, ja vaadi näkemään todisteet sen sijaan, että kuulisit niistä. Tuote, joka epäonnistuu ensimmäisessä testissä, on tuote, jossa on avustaja, mitä tahansa kansi sanoo, ja muut neljä testiä muuttuvat akateemisiksi.

Sois on yksi toteutus, jota voit testata, ja koska me rakennamme sen, voimme kertoa, miten se vastaa. Työtila on MCP-palvelin; mikä tahansa yhteensopiva asiakas yhdistää lisäämällä työtilan osoitteen ja kirjautumalla kerran OAuthin kautta, ilman liitettävää tokenia. Työkalut suodatetaan käyttäjän roolin mukaan ennen kuin ne tarjotaan ja tarkistetaan uudelleen, kun niitä käytetään, ja pääsy epäonnistuu suljetusti. Kulut voidaan rajoittaa per integraatio, jokainen toiminto kirjataan, ja kun oma agenttisi tekee päättelyä, alusta ei suorita mitään tekoälyä puolestasi eikä veloita siitä mitään. Kehittäjät rakentavat sovelluksia omalla agentillaan, validoivat paikallisesti ilmaiseksi ja julkaisevat markkinapaikalle, jossa jokainen liitetty agentti voi kutsua niitä. Suorita samat viisi testiä sitä vastaan kuin kaikkia muita; siihen ne ovat tarkoitettu.

Kysymyksiä, joita ihmiset kysyvät

Tätä artikkelia tarkastellaan, kun sen kuvaamat tuotteet muuttuvat. Seuraava tarkastusaika: 4. joulukuuta 2026.