Mit csinált az AI-ügynököm? Négy kérdés, amelyre bizonyítékkal kell válaszolni

Ha tudni akarod, mit csinált az AI-ügynököd, ne az összefoglalójával kezdd. Négy dolgot ellenőrizz: melyik kapcsolat végezte a munkát, mi változott (olyasmivel igazolva, amit magad is megnyithatsz), mi maradt el, és mit döntöttek el és miért. Ha a négy közül bármelyik csak az ügynök szavára épül, akkor elbeszélésed van, nem nyilvántartásod.

A Weftet mi készítjük. A más termékekre vonatkozó tények a hivatalos oldalaikról származnak, 2026. október 27-én ellenőrizve.

Miért nem elég egy „kész” feliratú hozzászólás?

Egy hozzászólásban az ügynök a saját munkáját írja le. Lehet, hogy pontos, de a hozzászólás ezt nem tudja igazolni, mert a szerzője éppen az, akit ellenőrizni próbálsz. Ha tudod, hogy egy ügynök hozzányúlt egy feladathoz, az a „ki” kérdésre felel. Arra nem, hogy a munka az-e, aminek gondolod.

A Hypertask AI-munka hozzárendeléséről szóló cikke jogos pontot tesz: az ügynöki munkának ugyanarra a táblára kell kerülnie, mint az emberi munkának, nem egy terminálnaplóba, amelyet senki sem olvas. A Hypertask ráadásul szolgáltatásfiókként saját identitást ad az ügynököknek, így az írások az ügynökhöz kerülnek, nem hozzád, és vannak feladat-bizonyítékai és lease-ei is, bár a dokumentációja szerint ezek szándékosan csak REST-végpontok, nem MCP-eszközök. Abban térünk el, mit kell tartalmaznia a nyilvántartásnak. Egy hozzászólás-szál az ügynök kimenetével annak a naplója, amit az ügynök mondott. Mi azt szeretnénk, hogy a nyilvántartás bizonyítékot tartalmazzon.

Ebben az útmutatóban nincsenek felmérési számok. A négy kérdést még ma délután kipróbálhatod a saját tábládon, és ez többet mond bármilyen iparági átlagnál.

Mi a négy kérdés?

Válassz egy feladatot, amelyet egy ügynök a múlt héten fejezett be. Mindegyik kérdésre egy percen belül tudnod kell válaszolni anélkül, hogy megkérdeznéd az ügynököt vagy megnyitnád a chatjét:

1. Ki csinálta? Melyik kliens, melyik kapcsolaton foglalta le és fejezte be a feladatot.
2. Mi változott? Az eredmény, plusz olyan artefaktumok, amelyeket az ügynökben való bizalom nélkül ellenőrizhetsz: commit hash, URL, fájl, üzenetazonosító.
3. Mi nem készült el? A kihagyott részek, és azok a dolgok, amelyekben bizonytalan volt.
4. Mit döntöttek el, és miért? Bármilyen menet közbeni választás a mérlegelt opciókkal, és minden alkalom, amikor visszaküldted a munkát.

Honnan tudom, melyik ügynök csinálta?

A Weft a Model Context Protocol révén egyetlen végponton, a https://letsweft.com/api/mcp címen csatlakozik az AI-kliensekhez. Minden OAuth-kliens és minden személyes hozzáférési token külön szereplő. A feladat rögzíti, melyik kliens hozta létre, a tábla pedig azt a nevet mutatja egy ikonnal, amellyel a kliens a bejelentkezéskor regisztrált. A feladat naplójának minden eseménye tárolja, hogy személytől vagy MCP-n keresztül érkezett-e, és melyik kliens küldte.

A teljes napló (get_task_history full módban) minden eseménynél a nyers kliensazonosítót mutatja: egy OAuth-kliensazonosítót, vagy mcp-token előtagot a token azonosítójával. Nem barátságos név, de pontos, és két kapcsolatot akkor is megkülönböztet, ha ugyanabból a termékből jönnek.

A munka közbeni tulajdonjog is egyértelmű. Az ügynök meghívja a start_task eszközt, amely 20 perces lease-szel lefoglalja a feladatot, és a Doing oszlopba mozgatja. A report_progress megújítja a lease-t. Egy második ügynök, amely ugyanazt a feladatot próbálja, already_claimed választ kap, a lejáró lease pedig felszabadítja a feladatot valaki más számára. A lefoglalási ciklus útmutatója ezt lépésről lépésre bemutatja, a több ügynök futtatása egy táblán pedig a több klienses esetet.

Egy gyakorlati szabály: adj minden eszköznek saját kapcsolatot. Ha két kliens egy hozzáférési tokenen osztozik, a tábla egyetlen szereplőt lát, és a „ki” kérdés elveszíti a válaszát.

Mi változott, és ellenőrizhetem anélkül, hogy megkérdezném az ügynököt?

Amikor egy ügynök végez, meghívja a complete_task eszközt. Csak a feladatazonosító kötelező; minden más opcionális, és a hívás sosem bukik el hiányzó bizonyíték miatt. Ez szándékos: a kész munka elvesztése rosszabb, mint ellenőrizetlenül rögzíteni. Amit egy nyugta tartalmazhat:

• outcome: legfeljebb 1000 karakter arról, mi készült el, és hol található az eredmény.
• artifacts: legfeljebb 20 bejegyzés, mindegyik egy fajta (url, file, message, commit stb.), egy hely, és opcionálisan egy sha256-kivonat.
• claims: amit az ügynök állít, hogy megcsinált, állításként tárolva, nem ellenőrzött tényként.
• notDone és unknowns: a következő szakaszban.
• nextStep: amit az ügynök következőként tenne, ha elfogadod.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Az eredménysor még mindig elbeszélés. Az artefaktumok azok, amelyeket ellenőrizni tudsz. Egy commit hash vagy létezik a repódban, vagy nem. Egy URL vagy betöltődik, vagy nem. Egy fájl sha256-ja vagy egyezik, vagy nem. Ha egy nyugtában van eredmény, de nincs artefaktum, kezeld ügynök által jelentett munkaként, mert az. A weben a Done kártyák mutatják, hogy egy feladat Ellenőrzött vagy Ügynök szerint kész.

Mit nem csinált meg az ügynök?

Ezt a kérdést hagyja ki a legtöbb nyilvántartás, és ez az, amely két héttel később visszaüt. A complete_task két listát kínál rá, mindkettő legfeljebb 20, egyenként 500 karakteres bejegyzéssel: a notDone azt rögzíti, amit az ügynök szándékosan kihagyott, az unknowns pedig azt, amiben bizonytalan. Maga az eszközleírás kéri az ügynököket, hogy nyíltan mondják ki, mit nem csináltak meg. Ez választja el a megbízható eredményt attól, amelyet újra ki kell bogoznod.

Ezeket a listákat olvasd el először. A „nem futtattam a teszteket a staging-adatbázison” megváltoztatja, mit teszel ezután. Egy nagy feladat nyugtája notDone bejegyzések nélkül önmagában is megér egy kérdést.

Mit döntöttek el, és miért?

A chatben hozott döntések eltűnnek, amikor a chat elgördül. A record_decision kétféleképpen őrzi meg őket:

• Önálló döntési rekord: cím, eredmény, kontextus, a ténylegesen mérlegelt opciók, a következmények, és a feltétel, amely mellett újra kell gondolni. A rekordok megváltoztathatatlanok; egy módosítása új döntés rögzítését jelenti, amely felváltja a régit, a régi pedig megmarad, felváltottként jelölve.
• Ítélet továbbítása: amikor beszélgetés közben azt mondod egy ügynöknek, hogy „elfogadva”, „csináld újra X-szel”, „vesd el” vagy „most nem”, az ügynök rögzíti ezt az ítéletet a feladaton, a megjegyzéseddel együtt.

A get_task_history három módban olvassa vissza: summary (a kártya, a legutóbbi nyugtája és a számlálók), decisions (minden, a feladatra vonatkozó döntés, azzal együtt, miért küldték vissza, ami egy későbbi elfogadás után is megmarad) és full (a nyers napló, legfeljebb 100 eseménnyel). A get_context egy tokenkereten belül átadja az élő döntéseket a következő ügynöknek, így a következő futás abból indul, amit eldöntöttek, nem a nulláról. Bővebben: miért vesznek el az AI-chatben hozott döntések.

Hol nézem át, és mire kattintok?

Alapból a befejezett feladat egyenesen a Done oszlopba kerül. Akkor áll meg az Inboxodban, ha a feladat átnézést igényel, vagy egy ellenőrzés elbukik. Ott látod a nyugtát és négy gombot: Elfogadás, Átdolgozás, Később és Elvetés. Az Átdolgozáshoz megjegyzés kell, és ez a megjegyzés visszamegy az ügynökhöz.

Ha az ügynök nextStep lépést adott meg, az az Elfogadás gomb fölött jelenik meg, és az elfogadás pontosan azt a lépést hagyja jóvá. A jóváhagyás 72 óráig érvényes, és a get_my_work vagy a start_task hívással jut vissza az ügynökhöz, mint az egyetlen következő lépés. Az ügynök request_input eszközzel feltett kérdései ugyanabba az Inboxba érkeznek, a weben és az iOS- meg Android-appokban, mobilos push-értesítéssel.

Az Inboxnak szándékosan van korlátja: egyszemélyes munkaterületen 5 várakozó tétel, csapatban 10, vagy 45 percnyi becsült átnézési idő, amelyik előbb bekövetkezik. Ha megtelt, a start_task attention_queue_full válasszal utasít el, így az ügynökök befejezik vagy tisztázzák a munkát, ahelyett hogy még többet halmoznának fel ellenőrzésre.

Milyen bizonyítékot kérjek feladattípusonként?

Írd bele ezeket a feladatleírásba, hogy az ügynök tudja, milyen bizonyítékot vársz:

• Kód: a commit hash és a PR URL artefaktumként. A notDone nevezze meg a nem futtatott teszteket, a nem alkalmazott migrációkat és a szándékosan érintetlenül hagyott fájlokat.
• Tartalom: a publikált URL, vagy ha még nincs élesben, a vázlatfájl a sha256-jával. Az unknowns sorolja fel azokat a tényeket, amelyeket az ügynök nem tudott megerősíteni.
• Kutatás: forrás-URL minden kulcsállításhoz, és a jegyzetfájl. Az unknowns válassza szét, mit mond egy forrás, és mit következtetett az ügynök.
• Kapcsolatfelvétel: minden elküldött üzenet üzenetazonosítója, és a címzettlista fájlként. A notDone sorolja fel, kit nem kerestek meg és miért.

Hogyan szabályozom eleve, mit tehet egy ügynök?

Az utólagos hozzárendelés akkor működik a legjobban, ha előtte korlátok vannak. A Weftben minden OAuth-kapcsolatnak három jogosultsági szint egyike van, amelyet a hozzájárulási képernyőn vagy később a Settings, Connected AI clients alatt állítasz be:

• full (az alapértelmezett): mind a 32 eszköz.
• write: minden a három destruktív eszköz (trash_task, archive_done_tasks, complete_sprint) kivételével.
• read: csak a 11 csak olvasó eszköz.

Az ellenőrzés minden hívásnál lefut. A Disconnect visszavonja a kapcsolat frissítő tokenjeit, és a következő hívásnál elutasít minden, a leválasztás előtt kiadott tokent. Az OAuth nélküli kliensekhez való személyes hozzáférési tokeneknek nincs hatókörük: egy token mind a 32 eszközt eléri, és a visszavonása a következő hívásnál lép életbe. Az ügynökök 30 napos kukába tehetik a feladatokat, de véglegesen nem törölhetik őket; a kukából való visszaállítás Pro funkció.

Mit nem tud itt a Weft?

• Nincs GitHub- vagy Slack-integrációja, így a Weft nem keresi ki helyetted a commitjaidat vagy üzeneteidet. Az artefaktumot te nyitod meg.
• Nincs nyilvános REST API-ja, webhookja vagy CLI-je, amellyel más rendszerekbe tolhatnád a nyugtákat. JSON- és Markdown-export van.
• Nem követi a modell lépéseit. Azok az eszközök, amelyek a modellrétegben naplózzák a promptokat, tokeneket és késleltetést, más feladatot látnak el, és lehet, hogy egy ilyenre is szükséged van.
• Az ügynökök maguk írják a nyugtáikat. A Weft láthatóvá teszi a rést az állítás és a bizonyíték között; őszintévé tenni egy ügynököt nem tudja.

Ha REST API-n keresztül szolgáltatásfiókként kezelt ügynököket, CI-szkriptekhez CLI-t vagy beépített AI-funkciókat szeretnél, például feladatírást és osztályozást, a Hypertask jobban illik ehhez. A Hypertask-alternatíva oldalunk egymás mellett hasonlítja össze a kettőt.

Nem elég a git-előzmény ahhoz, hogy tudjam, mit csinált az ügynököm?

A git azt mutatja, mi változott a kódban. Azt nem, mit hagyott ki az ügynök, miben volt bizonytalan, vagy melyik opciót választotta kettő közül. Használd a commit hasht artefaktumként a feladaton, a többit pedig tartsd a nyugtában és a döntési rekordban.

Nem találhat ki egyszerűen egy artefaktumot az ügynök?

Bármilyen karakterláncot elküldhet. Az artefaktum lényege, hogy megnyithatod: egy hash, amelyet kikereshetsz, egy URL, amelyet betölthetsz, egy üzenetazonosító, amelyet megtalálhatsz. Egy kitalált abban a pillanatban elbukik, amikor ellenőrzöd, egy hozzászólás viszont soha. Ha egy feladathoz ellenőrzés tartozik, és egy blokkoló ellenőrzés elbukik, a feladat nem kerül a Done oszlopba.

Minden kész feladat az átnézésemre vár?

Nem. Alapból a befejezett feladat a Done oszlopba kerül. Csak akkor vár az Inboxodban Elfogadás, Átdolgozás, Később vagy Elvetés döntésre, ha a feladat átnézést igényel, vagy egy ellenőrzés elbukik.

Mely AI-kliensek írhatnak nyugtát a Weftbe?

Bármely MCP-kliens. A ChatGPT-ben a Weft publikált plugin minden csomagon, az Ingyenest is beleértve. A Claude Code a claude mcp add --transport http weft https://letsweft.com/api/mcp paranccsal csatlakozik. A claude.ai és a Claude Desktop egyéni konnektort használ. 33 klienshez van beállítási oldal, például a Claude Code, a ChatGPT, a Cursor és a Codex.

Mennyibe kerül ez?

Az Ingyenes csomag 50 feladatot és havi 200 AI-hívást fed le. A Pro helyenként havi 8,26 € vagy évi 69,85 €. A Weftnek nincsenek AI-kreditjei: a gondolkodás a saját AI-kliensedben történik. Lásd: árak.