AI-ügynökök feladatkezelése: a lefoglalási ciklus mint szerződés, nem prompt

Az AI-ügynökök feladatkezelése akkor működik, ha a ciklus a tábláé, nem a prompté: az ügynök megkérdezi, mit csináljon, lefoglal egy feladatot egy lease-szel, amely lejár, ha elhallgat, csak a személyre tartozó döntésekben kérdez, és olyan nyugtával zár, amelyet valaki ellenőrizni tud. A Weftben mindegyik lépés egy MCP-eszköz, amelyet a szerver ellenőriz, így egy lépést kihagyó ügynök elutasítást kap vagy elveszíti a feladatot, ahelyett hogy csendben kicsúszna a szinkronból.

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 működik sokáig a chatbe bemásolt feladatlista?

A feladatok chatbe másolása az első, amit mindenki kipróbál, és egy délutánig működik is. Aztán a chat véget ér, és vele együtt az állapot is. Az ügynök tudta, melyik tételt fejezte be, melyiket adta fel, és miben volt bizonytalan. Most már senki sem tudja.

Aki a listát bemásolta, közvetítővé válik: visszamásolja az eredményeket a valódi táblára, és újra elvégzi azt a munkát, amelyet egy második munkamenet is elővett, mert semmi sem jelezte, hogy foglalt.

A táblához való hozzáférés a pillanatkép-problémát oldja meg, a többit nem. Ha csak „kártya mozgatása” és „hozzászólás” eszköz van, a ciklus továbbra is azon múlik, hogy az ügynök követ-e egy, az utasításaiba írt konvenciót. A konvenciók pont akkor törnek el, amikor baj van: az ügynök futás közben összeomlik, vagy két ügynök ugyanabban a pillanatban indul.

Hogyan néz ki a lefoglalási ciklus szerződésként?

A Weftben a ciklusnak öt lépése van, és mindegyik külön eszköz egyetlen MCP-végponton, a https://letsweft.com/api/mcp címen. A szerver tartja az állapotot a lépések között, így a ciklus bármely chat végét túléli.

1. get_my_work: kérdezz, mielőtt választasz. A válasz lefedi, mit tart már ez a kliens, mi vár a személyre, mi késik vagy lesz hamarosan esedékes, és van-e egyáltalán hely bármibe belekezdeni.
2. start_task: lefoglalás lease-szel. A lefoglalás 20 percig tart, és a feladatot a Doing oszlopba mozgatja. A válasz tartalmaz egy runId, egy leaseToken és egy renewEverySeconds: 300 értéket. Egy második kliens, amely ugyanazt a feladatot próbálja, already_claimed választ kap, és egy tippet, hogy ne duplázza meg a munkát.
3. report_progress: a szívverés. Minden hívás a futásazonosítóval és a lease-tokennel megújítja a lease-t. Ha az ügynök leáll, a szívverések megszűnnek, és 20 perc múlva a futás elavultnak minősül, a feladat pedig hozzárendeletlenként bárki számára elérhető lesz. Az elveszett lease lease_lost választ ad, így az ügynök tudja, hogy már nem az övé a munka.
4. request_input: csak a személyre tartozó döntésekhez. Legfeljebb 500 karakteres kérdés, legfeljebb 10 opcióval. Amíg az ügynök vár, a lefoglalás megmarad.
5. complete_task: zárás nyugtával. outcome, artifacts (bizonyíték, például URL, commit vagy fájlhash), notDone, unknowns és nextStep.

Miért lease, és miért nem állapot? Mert a csend az egyetlen jel, amelyet egy összeomlott ügynök küldeni tud. Egy kártya a Doing oszlopban azt mondja, hogy valaki valamikor dolgozott rajta. Egy lease azt mondja, hogy valaki most dolgozik rajta, és magától abbahagyja ezt az állítást, amikor az már nem igaz.

Maga a lefoglalás egyetlen adatbázis-beszúrás, amelyet egyedi index véd. Amikor két ügynök versenyez, az adatbázis dönti el, ki nyer, így nem kaphatják meg mindketten a feladatot. Ezzel szemben két, egy másodperc különbséggel közzétett „Lefoglalva” hozzászólás mindkettő érvényes hozzászólás.

Mikor hívja az ügynök a request_input eszközt?

Amikor olyasmihez ér, amiről csak a személy dönthet: bármi visszafordíthatatlan, például pénz, publikálás, éles rendszer vagy jogi kérdés, vagy egy valódi elágazás ésszerű alapértelmezés nélkül. Nem azért, hogy engedélyt kérjen a folytatáshoz.

Ez a visszafogottság azért fontos, mert egy kérdés ugyanannyi figyelmébe kerül a személynek, mint egy kész feladat, és a Weftben ugyanabba a korlátba is számít bele. A kérdés az Inboxba kerül, mobilos push-értesítéssel, a 20 percnél régebben várakozó tételeknél pedig e-mailes emlékeztetővel. A Weft soha nem hívja vissza az ügynököt: a válasz a következő start_task vagy get_my_work hívásnál érkezik meg. Amíg a kérdés nyitott, az ügynök 60 percig megtartja a feladatot; utána a lease megszűnik, de a kérdés megmarad.

Mi kerül egy complete_task hívásba?

Egy rövid eredmény, bizonyíték, és őszinte beszámoló a határokról. Íme egy valósághű payload egy hibajavításhoz:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Az artefaktumok olyan dolgok, amelyeket a személy úgy ellenőrizhet, hogy nem kell elhinnie az ügynök szavát. A notDone és az unknowns nem beismerés; ezek választják el a megbízható eredményt attól, amelyet a diffből kell újraépíteni. A hívás sosem bukik el hiányzó bizonyíték miatt, mert a kész munka elvesztése rosszabb, mint ellenőrizetlenül rögzíteni. A nyugták olvasásáról bővebben: mit csinált az AI-ügynököm.

Miben más ez, mint egy kártya mozgatása és egy hozzászólás közzététele?

A Hypertask útmutatója ugyanerről a ciklusról (lefoglalás, frissítés, jelentés, lezárás) jól leírja a szokást. Az MCP-s lefoglalás náluk annyi, hogy betöltik a feladatot, átteszik a munkában lévő szakaszba, és közzétesznek egy lefoglaló hozzászólást, egy olyan prompt alapján, amelyet a csapat az ügynök utasításaiba ír. Íme ugyanez a ciklus lépésről lépésre:

A Hypertask iránti korrektség kedvéért: neki valódi lease-ei vannak. A dokumentációja felsorolja a lease-lefoglalás, a szívverés és a felszabadítás végpontjait, az Ismert korlátok táblázata pedig azt írja, hogy a feladat-lease-ek, a bizonyíték és az eszkaláció szándékosan csak REST-végpontok (Hypertask MCP-áttekintés). Az eszközreferenciájában a 21 MCP-eszköz között nincs lease-eszköz (eszközreferencia). A CLI-je is tud lefoglalni, opcionális parancsként (changelog, CLI-referencia). Egy szkriptelt ügynök tehát a Hypertaskon tarthat lease-t; egy MCP-n át dolgozó ügynök a Claude Code-ban vagy a Cursorban viszont a kártya-és-hozzászólás változatot kapja, hacsak valaki be nem köti a REST-hívásokat.

Ha az ügynökeid szkriptként és CI-feladatként futnak, a Hypertask CLI-je és REST API-ja valódi előny, és a Weftnek egyik sincs: nincs CLI, nincs nyilvános REST API, nincsenek webhookok. A Weft azoknak az ügynököknek való, amelyek egy MCP-kliensen belül élnek, és ott kell, hogy a ciklus tartson.

Mit lát a személy?

Az esetek többségében egy kártyát a Done oszlopban: alapból a befejezett feladat egyenesen oda kerül, az eredménnyel és a bizonyítékkal együtt.

Egy feladat akkor áll meg a személy Inboxában, ha átnézést igénylőként jelölték, vagy ha egy ellenőrzés elbukik. Ott a személy négy válasz közül választ:

• Elfogadás: a munka érvényes. Ha az ügynök nextStep lépést adott meg, a személy a gomb fölött látja („Ha elfogadod, az ügynök …”), és az elfogadás pontosan azt a lépést hagyja jóvá, semmi tágabbat. 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.
• Átdolgozás: visszaküldés egy megjegyzéssel arról, mi a hiba.
• Később: most nem. Elvetés: a munka leállítása.

Az Inbox a weben van, és amikor valami bekerül, a személy push-értesítést is kap a Weft mobilappjában. A nextStep-kézfogás megakadályozza, hogy egy ügynök a „jónak tűnik” választ a merge-re, a telepítésre és a küldésre szóló engedélynek vegye: az egyetlen jóváhagyott lépést teheti meg, aztán újra lezárja a feladatot.

Miért kap az ügynök elutasítást ahelyett, hogy több munkába kezdene?

Mert a figyelem a szűkös erőforrás, nem a munka. Egy ügynök tíz dologba kezdhet bele annyi idő alatt, amíg egy ember átnéz egyet.

A Weft azt számolja, mi vár emberekre: az átnézésre váró feladatokat és a nyitott kérdéseket. Amikor ez egyszemélyes munkaterületen eléri az 5 tételt, csapatban a 10-et, vagy nagyjából 45 percnyi becsült átnézési időt, amelyik előbb bekövetkezik, a start_task attention_queue_full válasszal utasít el. A korlát a munkaterület létszámától függ, nem a csomagtól.

Az elutasítás utasítás, nem zsákutca. Közli a sor méretét, a legrégebbi tétel korát és a még engedélyezett hívásokat: report_progress, get_my_work, get_board_state és search. Egy olyan lépés, amelyet a személy már jóváhagyott azon a kártyán, kivétel, így egy elfogadott „merge PR #418” lépést nem blokkol a sor.

Hogyan állítom be?

Csatlakoztasd a kliensedet, és jelentkezz be a böngészőben; nincs kimásolandó kulcs. A Weft frissítő tokent ad ki, így a kliens maga újítja meg a bejelentkezést. A Claude Code-ban ez egyetlen parancs: claude mcp add --transport http weft https://letsweft.com/api/mcp (beállítási oldal). A Cursornál egykattintásos telepítés van (Cursor), a Codexnek egy konfigurációs bejegyzés és a codex mcp login weft parancs kell (Codex), a ChatGPT-ben pedig publikált Weft-app van minden csomagon, az Ingyenest is beleértve (ChatGPT). A szerver maga írja le a ciklust az ügynöknek, így nincs szükség életciklus-promptra.

Claude Code-os bemutatóért lásd: feladattábla a Claude Code-hoz. Több ügynökhöz egy táblán, ahol a lease-ek és az already_claimed a legtöbbet számítanak, lásd: több AI-ügynök, egy tábla. Magát a protokollt a modelcontextprotocol.io dokumentálja, más MCP-táblák összehasonlítása pedig az MCP-feladatkezelők oldalon található.

Mit nem tud itt a Weft?

• Nincs CLI, nyilvános REST API vagy webhook, így cron-feladatok és CI-pipeline-ok nem vezérelhetik a ciklust egy MCP-kliensen kívül.
• Nincs GitHub- vagy Slack-integráció. A bizonyíték az, amit az ügynök az artifacts mezőben belinkel.
• Nincs beépített AI. A gondolkodás a saját AI-kliensedben történik, ezért nincs szüksége a Weftnek AI-kreditekre sem.

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 € (árak).

Nem elég egy jó prompt ahhoz, hogy az ügynökök kövessék a ciklust?

Egy prompt leírja a ciklust, de nem tudja betartatni. Nem akadályozza meg, hogy két ügynök ugyanazt a feladatot foglalja le, és nem tudja felszabadítani egy összeomlott ügynök által tartott feladatot. A Weftben a lefoglalás a szerver birtokában lévő lease, így ezeket az eseteket akkor is kezeli, ha az ügynök nem emlékezett az utasításaira.

Mi történik, ha az ügynököm félúton összeomlik?

A szívverései megszűnnek. Húsz perccel az utolsó report_progress után a futás elavultnak minősül, a lease-token törlődik, és a feladat újra hozzárendeletlen, így egy másik ügynök vagy egy ember elveheti. A kártya nem ül egy hétig a Doing oszlopban.

Minden kész feladat arra vár, hogy átnézzem?

Nem. Alapból a befejezett feladat egyenesen a Done oszlopba kerül az eredménnyel és a bizonyítékkal. Csak akkor áll meg 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.

Miért akarnám, hogy az ügynököm elutasítást kapjon?

Mert különben tovább gyártja azokat a dolgokat, amelyeket nincs időd ellenőrizni. Amint 5 tétel (csapatnál 10) vagy nagyjából 45 percnyi átnézés vár emberekre, a start_task attention_queue_full választ ad, és arra irányítja az ügynököt, amit még megtehet. A sor kiürítése feloldja.

A Hypertasknak is vannak lease-ei. Miért számít az MCP?

A Hypertask lease-ei a saját dokumentációja szerint REST-végpontok (MCP-áttekintés), és a CLI-je is tud lefoglalni. Ez a szkriptelt ügynököknek kedvez. Egy szerkesztőben vagy chatben MCP-eszközökkel dolgozó ügynök ott nem kapja meg őket, a Weftben viszont igen: a start_task, a report_progress és a complete_task MCP-eszközök.