AI-ügynök videópublikálási munkafolyamat: URL-import és jóváhagyás (2026)

Egy nagy nyelvi modell (LLM) vagy n8n AI Agent nem tud 50 MB-os MP4-fájlt átküldeni az eszközhívás paramétereiben: 50 MB base64-kódolva nagyjából 66,7 MB ASCII-szöveget — több tízmillió tokent — jelentene, ami azonnal szétfeszíti a modell kontextusablakát és az időkorlátokat. Egy éles AI-ügynök videópublikálási munkafolyamat ezt úgy oldja meg, hogy a fájl bájtjai helyett egy nyilvánosan letölthető URL-t ad át a szerveroldali import-sornak (MCP-n az import_videos, REST-en a POST /videos/import végpontnak), miközben hívóhoz kötött idempotenciakulcsokkal, emberi jóváhagyási kapuval (requireReview: true) és prompt-injection elleni szűrőkkel védi a munkaterületet.

Ha Claude-ot vagy Cursort szeretnél bekötni, kövesd a közösségi posztok ütemezése Claude MCP-vel útmutatónkat, vagy nézd meg az élő MCP-integrációs oldalt. Ha n8n-ben építesz munkafolyamatot, olvasd el az n8n HTTP Request videófeltöltési útmutatónkat.

1. Miért bukik el a bináris feltöltés az LLM eszközhívásokban — és miért működik az URL-import?

A hagyományos REST API-k a nagy videófájlokat előre aláírt (presigned) S3 PUT URL-ekkel kezelik (mint az Uplonic /storage/upload-url → /videos/register útja). Ez böngészőből vagy saját háttérszerverről kiválóan működik, de a csevegőalapú AI-kliensekben (claude.ai) és az LLM eszközhívási ciklusokban két okból is járhatatlan:

• A kontextusablak fizikája: az MCP-eszközök paraméterei JSON-szövegként haladnak át a modell kontextusán. Egy 50 MB-os videó base64-ben 33%-kal hosszabb (~66,7 millió karakter, azaz 16–20 millió token), amit egyetlen modell sem tud paraméterként előállítani vagy átadni.

• Nincs szabad bináris HTTP PUT a chat-sandboxban: a hosztolt asszisztensek strukturált MCP-eszközöket tudnak hívni, de nem tudnak több száz megabájtos bináris folyamot feltölteni egy S3-bucketbe egyetlen eszközhívás időkorlátján belül.

Az aszinkron URL-importtal (createVideoImports) a REST végpont (POST /videos/import) és az MCP-eszköz (import_videos) pontosan ugyanazt a letöltő és validáló csatornát használja. Az ügynök átad egy linket, ezredmásodpercek alatt visszakap egy importId-t, majd a get_video_imports hívásával megvárja, amíg a háttér-worker letölti a fájlt, ellenőrzi a magic byte-okat és lefuttatja az ffprobe vizsgálatot.

2. Ügynök-újrapróbálások megfékezése hívóhoz kötött idempotenciakulcsokkal

Az autonóm ügynökök gyakran újrahívják ugyanazt az eszközt, ha egy lépés lassabban válaszol, vagy ha az оркеsztrátor újragondolja a feladatot. Deduplikáció nélkül egy ilyen ciklus öt példányban töltené le ugyanazt a videót a médiatárba, vagy többször ütemezné ugyanazt a posztot.

Az Uplonic a munkaterület és a hívó azonosítója szerint is elszigeteli az idempotenciakulcsokat:

3. Ember a folyamatban: requireReview, szerepkörök és a TikTok-szabály

Az, hogy egy AI-ügynök írási jogot kap egy munkaterületre, még nem jelenti azt, hogy felügyelet nélkül azonnal posztolhat az ügyfél éles csatornáira. Az Uplonic három szerveroldali korláttal védi az író műveleteket:

1. Explicit jóváhagyási sor importkor (requireReview: true): ha az ügynök az import_videos (vagy a POST /videos/import) hívásban requireReview: true értéket ad meg, a worker a létrejövő Video sort reviewStatus: "pending" állapotba teszi. A videó bekerül a munkaterület jóváhagyási sorába, ahol egy emberi szerkesztő átnézheti, vagy az approve_videos eszközzel jóváhagyhatja.

2. Szerepkör-mátrix ellenőrzése minden hívásnál: az Uplonic runTool függvénye minden író hívásnál lefuttatja a roleCan(ws.role, opts.permission, { staffApprovalRequired }) ellenőrzést, amely ugyanazt a mátrixot használja, mint a webes felület. Egy staff szerepkörű tag MCP-n keresztül sem kerülheti meg a kötelező jóváhagyást: az approve_videos hívás INSUFFICIENT_APP_ROLE hibával elbukik és bekerül az auditnaplóba.

3. Platformszintű hozzájárulás (TikTok): a schedule_video elutasítja a közvetlen TikTok-csatornákat (TIKTOK_REQUIRES_USER), mert a TikTok Content Sharing Guidelines előírja, hogy a láthatóságot és a beleegyezést a felhasználó adja meg a felületen. Az ügynök úgy tud segíteni, hogy requireReview: true mellett importálja a videót, a jóváhagyás (approve_videos) pedig lefuttatja a felületen előkészített publikálási profilt.

4. Több munkaterületes ügynökök védelme a prompt injection ellen

Amikor egy ügynökség 10 ügyfél munkaterületét köti be egyetlen MCP-kapcsolatba, a legnagyobb veszély az indirekt prompt injection: egy idegen rosszindulatú utasítást ír egy YouTube-kommentbe vagy egy megosztott videó címébe az „A” munkaterületen, abban bízva, hogy az ügynök végrehajtja azt a „B” munkaterületen. Az Uplonic MCP-futtatókörnyezete négy réteggel védi ezt a határt:

• Statikus rendszerinstrukciók: az MCP-szerver instructions szövege szigorúan statikus — az ügyfelek által megadott munkaterület-nevek sosem kerülnek be a rendszerszintű promptba, az eszközök pedig tisztított aliasokat ([a-z0-9-], max. 24 karakter) használnak.

• Explicit untrustedFields felsorolás: minden olyan eszközválasz, amely felhasználói vagy idegen szöveget ad vissza (például imports[].title, videos[].title, comments[].text vagy workspace.name), mellékel egy untrustedFields tömböt és egy figyelmeztetést, hogy a modell ezeket kizárólag adatként kezelje.

• Csak számokat adó munkaterület-áttekintés: a workspace_overview kizárólag darabszámokat ad vissza, komment- vagy címszöveget sosem, így egyetlen áttekintő hívásban nem keveredhet tíz ügyfél szöveges tartalma.

• Biztonsági riasztás ismételt elutasításnál: minden eszközhívás bekerül az McpAuditLog táblába (csonkolt és maszkolt paraméterekkel); 15 percen belül 5 vagy több WORKSPACE_NOT_FOUND vagy WRITE_NOT_ALLOWED elutasítás mcp_security_alert értesítést küld.

Arról, hogyan védi maga a letöltő a rendszert az SSRF-támadásoktól és hogyan távolítja el az ideiglenes tokeneket a tárolt linkekből, a videó importálása URL-ről API-n keresztül útmutatónkban olvashatsz.