Od Coding Agent do cyfrowych pracowników: aplikacje AI zbiegają się w jeden system architektoniczny

Przechodząc przez stoiska produktów Agent na konferencji Yunqi, najbardziej nieintuicyjnym odkryciem jest to, że choć pozornie należą do zupełnie różnych branż, wszystkie wyłaniają się z tego samego systemu operacyjnego.

Qoder zajmuje się tworzeniem oprogramowania, QwenWork obsługuje pracę wiedzy, TinyFish działa jako Agent do przeglądania stron internetowych, WonderClip produkuje materiały wideo, a OpenSearch realizuje funkcje wyszukiwania i badań.

Gdy odejmiemy konkretne branże, ich podstawowa struktura jest zaskakująco podobna:

Kontekst → Planowanie → Umiejętności → Wykonanie → Weryfikacja → Pamięć → Wynik biznesowy
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

To właśnie ten wspólny system architektoniczny wyłania się obecnie jako standard dla produktów Agent.

⚠ Ten artykuł wykorzystuje ekosystem Alibaba Cloud (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) jako studium przypadku. Jednak przedstawione poniżej oceny architektoniczne mają zastosowanie również do scenariuszy on-premise, platform Agent na Huawei Cloud, AWS, Azure i GCP – siedmiowarstwowy stos stanowi konwergencję struktur inżynieryjnych, a nie prywatny wniosek jednego dostawcy chmury.

1. Rdzeń Agenta ewoluował od „udzielania odpowiedzi” do „zdolności ciągłego wykonywania”

W erze chatbotów podstawowa pętla systemu była prosta: użytkownik wprowadza dane, model zwraca wynik.

W erze agentów zadania trwają minuty, godziny, a nawet dłużej. Agent musi odczytywać pliki, korzystać z przeglądarki, wywoływać interfejsy API, wykonywać kod, oczekiwać na operacje asynchroniczne, weryfikować rezultaty, podejmować próby ponowne w przypadku niepowodzenia i utrzymywać stan.

Pojedynczy prompt i jeden model nie są w stanie pomieścić tego wszystkiego.

System musi zacząć dysponować własnym środowiskiem wykonawczym – Runtime.

Learn AI Slowly: Eksploracja Agentów AI w Środowisku Produkcji

Demonstracja zadania Legal Document Fill Out na żywo przez QwenWork jest dość reprezentatywna: działa ono w izolowanym Sandbox Containerze, Agent dysponuje wirtualnym pulpitem i może wywoływać narzędzia do przetwarzania dokumentów. Marketing Content Generation dodatkowo integruje różnorodne narzędzia, takie jak PPT, obrazy, Lip Sync, Python, Pillow czy FFmpeg.

Środowisko wykonawcze Agenta coraz bardziej upodabnia się do programowalnego komputera — jednostki roboczej chronionej przez sandbox, zdolnej do wywoływania różnych środowisk uruchomieniowych i narzędzi, umożliwiającej ciągłe wykonywanie zadań bez przerywania. Sandbox Container zapewnia izolację, wirtualny pulpit dostarcza możliwości wizualnej obsługi interfejsu graficznego, a wywoływanie narzędzi pozwala modelowi przejść od „mówienia” do „działania”. Dopiero gdy ta kombinacja się ustabilizuje, Agent naprawdę zaczyna zastępować operacyjny wymiar pracy człowieka, a nie tylko jej wymiar poznawczy.

2. „One Foundation” Qodera to sygnał produktowy, nie hasło

Na stoisku Qodera widnieje następujące zdanie:

One workbench. Four entries. One foundation.

Na górze znajdują się Workbench, CLI, IDE, JetBrains Plugin, a system może być dalej rozbudowywany o Cloud Agents i Agent SDK.

Jednak prawdziwie godna uwagi jest ta wspólna Foundation znajdująca się poniżej.

Gdyby każdy interfejs miał własną, niezależną implementację Agenta, system bardzo szybko wymknąłby się spod kontroli. Znacznie rozsądniejszym podejściem jest wydzielenie takich funkcjonalności jak planowanie zadań, zarządzanie uprawnieniami, narzędzia, Sandbox, pamięć, router modeli i weryfikacja w postać wspólnego Harnesu.

Poszczególne interfejsy odpowiadają jedynie za dostosowanie do różnych typów użytkowników i scenariuszy: CLI dla programistów, IDE dla deweloperów, Workbench dla osób niezwiązanych technicznie, JetBrains dla migracji istniejącego kodu, Cloud Agents dla wywołań asynchronicznych, Agent SDK dla integracji zewnętrznych. Natomiast planowanie, pamięć, brama narzędziowa, weryfikacja i model bezpieczeństwa korzystają z jednej, współdzielonej warstwy.

Wartość tej możliwości ponownego wykorzystania jest znacznie większa, niż mogłoby się wydawać na pierwszy rzut oka. Doświadczenia z projektowania Sandboxów, modeli uprawnień i mechanizmów Recovery zdobyte przy Coding Agentach można bezpośrednio przenieść do Browser Agentów, Content Agentów czy Ops Agentów. Największym kosztem powielania rozwiązań nie jest koszt implementacji – to katastrofa związana z zarządzaniem, wynikająca z niespójnego zachowania różnych Agentów w sytuacjach awaryjnych. Ten sam fragment kodu działa w IDE Agent, działa też w CLI Agent, ale gdy model uprawnień różni się między nimi, a format logów audytowych jest niekompatybilny, próba ustalenia przyczyn problemu staje się praktycznie niemożliwa.

Trzy. Uniwersalny Agent Stack składa się z co najmniej siedmiu warstw – oraz mapa inwestycji „własna budowa / współdzielenie / do weryfikacji” dla każdej z nich

Po usunięciu szczegółów z powyższych przykładów, doszedłem do wyodrębnienia siedmiu warstw Agent Stack. Poniższa tabela dostarcza odpowiedzi na najbardziej pragmatyczne pytanie każdej organizacji: na których warstwach warto budować własne rozwiązania, które można bezpiecznie współdzielić korzystając z open source lub gotowych produktów, a które wciąż wymagają weryfikacji.

Warstwy architektury AI

Warstwa	Zawartość	Ocena inwestycyjna (obserwacje terenowe 2026)
1. Entry (wejście)	Web / CLI / IDE / IM / API / GitHub Issue / portal korporacyjny	Warstwa adaptacyjna, nie budować samodzielnie — wybierz formę wejścia najlepiej dopasowaną do Twoich użytkowników
2. Task (zadanie)	Cel / Specyfikacja / Kontekst / Kryteria akceptacji / Priorytet / Budżet	Budować samodzielnie, ale minimalistycznie — kontrakt zadania jest kluczowy; źle zdefiniowany psuje cały proces downstream
3. Context & Memory (kontekst i pamięć)	Wiedza korporacyjna, wiedza o kodzie, historia zadań, decyzje, preferencje użytkowników, bieżący stan	Musisz budować samodzielnie — kontekst to zasób organizacyjny, którego nie kupisz
4. Planning & Skill (planowanie i umiejętności)	Dekompozycja zadań, wybór umiejętności, wybór modelu, strategie przetwarzania równoległego	Umiejętności buduj samodzielnie, planowanie można zdelegować — umiejętności to Twoja przewaga konkurencyjna

| 5. Runtime i narzędzia | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / API korporacyjne | Częściowo własne rozwiązanie – ogólne Runtime mogą korzystać z open-source’owych stacków takich jak Browser Use, Anthropic Agent SDK; natomiast brama API korporacyjnych musi być zbudowana we własnym zakresie |
| 6. Weryfikacja i odzyskiwanie | Testowanie, weryfikacja reguł, ocena wyników, odzyskiwanie po awarii, ponowne próby i wycofywanie | Własne rozwiązanie – reguły weryfikacji są ściśle powiązane z biznesem; zakupione rozwiązania po prostu nie zadziałają |
| 7. Zarządzanie | Uprawnienia, Secrets, Audit, Koszty, Polityka, Zatwierdzenie przez człowieka | Koniecznie własne rozwiązanie – projektowane z perspektywy inżynieryjnej, a nie wyłącznie compliance |

Poniżej kluczowe rozstrzygnięcia dla każdej z siedmiu warstw:

Warstwa pierwsza – Entry (wejście). Web, CLI, IDE, komunikatory, API, GitHub Issue, korporacyjne pulpity – to wszystko jedynie punkty dostępu do zadań, same w sobie nie generują wartości biznesowej.

Drugi poziom: Task (Zadanie). Cel, Specyfikacja, Kontekst, Kryteria akceptacji, Priorytet oraz Budżet powinny być integralną częścią Zadania. Prawidłowo zbudowany opis Zadania powinien precyzyjnie określać: co chcemy osiągnąć, dlaczego to robimy, kiedy uznamy to za wykonane, jaki jest priorytet oraz ile środków można przeznaczyć. Jeśli system Agentów nie zapewnia kompletności tych sześciu pól, zadania zaczynają dryfować w systemie bez wyraźnego kierunku.

Trzeci poziom: Context & Memory (Kontekst i Pamięć). Tutaj gromadzone są: wiedza korporacyjna, wiedza o kodzie, historia zadań, podjęte decyzje, preferencje użytkowników oraz aktualny stan systemu. Zaznaczone przez Qoder elementy takie jak Repo Wiki, Knowledge Graph czy Knowledge Cards są konkretnymi przejawami tej warstwy — zamieniają „rozproszone fakty” w „aktywa możliwe do odzyskania przez maszynę”.

Czwarty poziom: Planning & Skill (Planowanie i Umiejętności). System decyduje, jak podzielić zadanie, który z istniejących Skillów wykorzystać ponownie, które kroki wymagają mocniejszego modelu, a które mogą być wykonywane równolegle. Ta warstwa to moment, w którym Agent rzeczywiście zaczyna „myśleć”, a także miejsce, gdzie możliwości modelu są najintensywniej wykorzystywane.

Warstwa piąta: Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP, korporacyjne API — to wszystko należy do tej warstwy. To punkt styku, w którym Agent faktycznie komunikuje się ze światem zewnętrznym.

Warstwa szósta: Verification & Recovery. Testowanie, weryfikacja reguł, ocena wyników, odzyskiwanie po awariach, ponowne próby i wycofywanie zmian.

Warstwa siódma: Governance. Uprawnienia, Secrets, Audit, Cost, Policy, Human Approval. Obejmuje też bardziej szczegółowe kwestie — algorithmic filing (wymogi zgodności z AI Act, podobne do chińskiego algorytmic filing), wyjaśnialność modelu, przypisanie odpowiedzialności za błędy, zarządzanie zależnościami od stron trzecich, kontrola transferu danych za granicę (odpowiednik GDPR data transfer mechanisms) — to są twarde ograniczenia, z którymi muszą się zmierzyć branże podlegające ścisłemu nadzorowi (opieka zdrowotna, finanse, transport, media, bezpieczeństwo publiczne) przy wdrażaniu Agentów do produkcji.

Model przenika przez wszystkie warstwy, ale model nie jest już równy całej platformie Agent. To jest najbardziej niedoceniana zmiana w postrzeganiu ostatnich dwóch lat — wiele zespołów poświęca zbyt wiele czasu na porównywanie modeli, podczas gdy prawdziwym czynnikiem decydującym o wdrożeniu systemu do produkcji jest sześć pozostałych warstw.

Cztery, Browser Agent wypełnia lukę między Agent a interfejsem ze światem rzeczywistym

Produkty takie jak TinyFish są tego doskonałym przykładem.

很多真实业务系统没有好用的 API，或者用户需要登录网站、操作动态页面、填写表单、切换页面、下载文件。传统自动化依赖 Playwright 或 Puppeteer 脚本，页面一改就失效。Browser Agent 让模型直接理解网页并执行动作。

这类能力补的是 Agent Runtime 的一个重要缺口：真实 Web。

一个外链提交 Agent、运营 Agent、采购 Agent、研究 Agent，都可能需要在网站里完成动作。

但这里真正困难的从来不是“能不能点按钮”。生产系统还要解决登录态——Cookie / Token 怎么管理、过期了怎么办；并发——一个任务里多个标签页同时操作怎么同步；失败恢复——页面崩溃、网络中断怎么续跑；重复提交——网络抖动后点击动作被重复执行怎么防；代理——地域 / IP 限制怎么绕；验证码——人机识别怎么过；权限——多账号隔离怎么做；最后还有“证明任务真的完成”——如何验证动作真的生效。

Jeszcze głębiej, pośrednie wstrzykiwanie promptów (Indirect Prompt Injection) stanowi najbardziej realne zagrożenie bezpieczeństwa dla Browser Agenta w 2026 roku: OWASP plasuje wstrzykiwanie promptów na pierwszym miejscu listy zagrożeń AI na 2026 rok, a wystarczy ukryty fragment tekstu na stronie, aby zmusić agenta do wysłania ciasteczek użytkownika. Na poziomie architektonicznym nie ma kompletnego rozwiązania — pozostają jedynie inżynieryjne kompromisy oparte na Sandboksie, białych listach dozwolonych akcji oraz kontroli poświadczeń środowiskowych (Ambient Credential).

Browser Use musi zostać umieszczony w dedykowanym Harness. Sam poziom demonstracyjny to zdecydowanie za mało. Jeśli organizacja faktycznie zamierza wdrożyć Browser Agenta w środowisku produkcyjnym, sam koszt tej warstwy wystarczyłby na zbudowanie całego systemu RPA od nowa.

Dlatego Browser Agent wygląda jak aplikacja, ale w istocie stanowi część środowiska wykonawczego (Runtime).

Pięć, Verification — czyli co decyduje o przyznaniu agentowi wyższych uprawnień

W systemach agentskich obowiązuje bardzo bezpośrednia zależność: im wyższa autonomia, tym silniejsze mechanizmy weryfikacji i nadzoru.

Agent zdolny jedynie do tworzenia projektów wiadomości e-mail generuje ograniczone ryzyko w przypadku błędu.

Agent zdolny do modyfikowania produkcyjnych baz danych, zatwierdzania kodu, wysyłania budżetów reklamowych czy zarządzania zapleczem korporacyjnym — to zupełnie inna kategoria ryzyka.

W pełni dojrzała platforma agentowa nie może ograniczać się do odpowiedzi na pytanie „co potrafi zrobić”. Musi jasno określać:

do czego ma dostęp;
co może modyfikować;
które operacje wymagają zatwierdzenia;
jakie dane audytowe pozostawia każdy krok;
jak odbywa się odtwarzanie po błędzie;
w jaki sposób system potwierdza, że zadanie zostało faktycznie wykonane.

Tu pojawia się kluczowa ocena inżynieryjna: jeśli agent nie jest w stanie dostarczyć weryfikowalnych dowodów na każdą ze swoich operacji, jego autonomię należy ograniczyć do roli „doradcy”. Innymi słowy, autonomia rośnie w miarę weryfikacji kompetencji w ramach ram zgodności — a nie wraz z rozbudową listy funkcji. Agent może teoretycznie wywoływać 100 interfejsów API, lecz jeśli nie potrafi udowodnić, że każde wywołanie przyniosło zamierzony rezultat, w środowiskach o silnej regulacji — finansach, opiece zdrowotnej czy transgranicznym obrocie danymi — pozostanie jedynie w roli „doradcy”.

Stąd właśnie w kontekście zastosowań korporacyjnych Governance będzie zyskiwać na znaczeniu — to nie sprawa działu compliance, lecz kompetencja, którą zespół inżynieryjny musi projektować od samego początku wspólnie z Runtime.

VI. Model Router jako podstawowy dyspozytor – ale nie każda warstwa wymaga najdroższego modelu

Wielomodelowe systemy stają się coraz powszechniejsze.

Wartościowy system wielomodelowy to nie tylko pozwolenie użytkownikowi na wybór GPT, Qwen, Claude czy innego modelu z rozwijanej listy.

Bardziej racjonalnym podejściem jest automatyczne routingowanie zadań przez system.

Złożone planowanie i decyzje architektoniczne obsługują silne modele; zwykłe implementacje kodu i porządkowanie tekstów – tańsze modele; zadania wizyjne wymagają modeli multimodalnych; klasyfikacja wsadowa korzysta z szybkich modeli; krytyczne przeglądy wracają do silnych modeli.

Za tym wszystkim kryje się prosta zasada inżynieryjna: różne zadania mają zupełnie inne wymagania dotyczące krzywej „możliwości-koszt” modelu. Zlecanie silnemu modelowi klasyfikacji wsadowej to marnotrawstwo; a powierzenie szybkiemu modelowi decyzji architektonicznych skutkuje ciągłym przebudowywaniem. Firma Requesty w 2026 roku opublikowała dane empiryczne: kierując 70% rutynowych zadań do modeli nano, 20% do modeli mid-tier i 10% do modeli frontier, średni koszt pojedynczego zapytania spada o 60–80%, przy niemal zerowej utracie jakości – to kierunkowa ilustracja, konkretne liczby zależą od typu zadań i strategii routingu.

Modele stopniowo stają się dyspozycyjnym zasobem obliczeniowym. Agent Platform odpowiada za dynamiczny wybór między jakością, szybkością, kosztami i ryzykiem.

Praktyczne przykłady routingu阶梯owego: kiedy Agent otrzymuje zadanie „ przeanalizuj strategię cenową konkurentów i przedstaw rekomendacje”, w fazie „zrozumienia zadania, podziału na kroki, oceny priorytetów” wykorzystuje potężny model; gdy przychodzi do „kategoryzacji 100 SKU według przedziałów cenowych”, przełącza się na szybki model; a gdy trzeba综合判断 na podstawie wyników kategorii, znów wraca do potężnego modelu.

Jeśli wszystkie zadania obsługiwać najdroższym modelem, koszty systemu będą niebotyczne; jeśli z kolei wszystkie zadania powierzać najtańszemu modelowi, system będzie się nieustannie zawodzić na skomplikowanych węzłach. Prawdziwą wartość inżynieryjną przynosi strategia planowania (scheduling), a nie sam wybór konkretnego modelu.

Siedem, Skill jako kluczowa прослойка łącząca通用 Runtime z branżowymi scenariuszami — i przyszła przewaga konkurencyjna

Sam w sobie通用 Agent Runtime nie ma wartości biznesowej.

Musi wniknąć w realne scenariusze poprzez Skill.

Coding Skill wie, jak czytać Repo, pisać Specyfikacje, uruchamiać Testy, generować PR-y. Definiuje zasady: kiedy trzeba najpierw uruchomić testy jednostkowe, kiedy można je pominąć, jakie pola powinny znaleźć się w opisie PR, a jakie zmiany wymagają obowiązkowego przeglądu przez человека (human review).

SEO Research Skill wie, jak wyszukiwać słowa kluczowe, analizować intencje wyszukiwania, weryfikować natężenie konkurencji, generować konspekt treści, potwierdzać indeksację strony. To nie jest kilka słów „przeprowadzić research słów kluczowych”, tylko kompletny, wielostopniowy proces.

E-commerce Creative Skill obejmuje wiedzę o markach, SKU, formatach platform, wymogach zgodności i procesach weryfikacji. Musi znać limity rozmiarów zdjęć na poszczególnych platformach, zakazane terminy, wymagane kwalifikacje kategorii oraz ostatni etap weryfikacji przed uruchomieniem kampanii.

Ops Skill obejmuje wiedzę o monitorowaniu, logach, kontenerach, bazach danych i procedurach wycofywania zmian (rollback). Powinien umieć rozróżniać, które alerty można obsłużyć automatycznie, a które wymagają interwencji człowieka, oraz wiedzieć, co stanowi bezpieczny punkt wycofania zmian.

Skill to nie tylko dokument SOP — to wykonywalny zasób z zarządzaniem wersjami, zależnościami, iteracjami oraz mechanizmami awaryjnymi. Można to porównać do protokołu Skills wprowadzonego przez Anthropic w październiku 2025 roku, który zakłada pakowanie doświadczeń domenowych w foldery SKILL.md, umożliwiające różnym platformom agentowym ładowanie ich według potrzeb, zamiast za każdym razem tworzyć je od nowa.

Skill łączy uniwersalne zdolności wykonawcze z wiedzą dziedzinową.

Dlatego w przyszłości przewagę konkurencyjną wielu aplikacji AI będzie stanowić domena zweryfikowana w procesie realizacji licznych rzeczywistych zadań — Domain Skills. Reprezentują one wiedzę typu „jak należy postępować w tej dziedzinie” — niełatwo jest ją zastąpić nowym modelom ani nowej platformie, a wręcz zyskuje na wartości wraz z upływem czasu.

Umiejętności organizacji nie są kupowane – są hodowane. Gdy firma systematycznie buduje bazę Skill i każde nowe zadanie traktuje jako okazję do jej rozbudowy, jej zdolności AI przestają być towarem z półki, a stają się czymś organicznie rosnącym.

8. Obiektyw branżowy: cztery oblicza wdrożeń w różnych organizacjach

Te cztery sekcje to nie narracja – mapują abstrakcyjny „siedmiowarstwowy Stack” na realia konkretnych branż, pokazując, gdzie każda z nich napotyka specyficzne bariery.

Telekomunikacja i operatorzy: Zmiany planów taryfowych, uruchamianie łączy dla klientów biznesowych czy lokalizacja awarii obejmujących wiele domen wymagają przechodzenia przez systemy BSS, OSS, CRM i billing. Największym wyzwaniem przy wdrażaniu Agentów jest uzgadnianie rozliczeń międzydomenowych – gdy Agent zmieni w CRM plan taryfowy klienta, musi jednocześnie powiadomić system billingowy i OSS, w przeciwnym razie rozliczenia w cyklu fakturowania się nie zgadzają. Na Stacku najcenniejsze są warstwa 5. Runtime & Tools (integracja interfejsów wielodomenowych) oraz warstwa 7. Governance (audyt rozliczeń).

Finanse/Bankowość: Zarządzanie ryzykiem, przeciwdziałanie praniu pieniędzy, rozliczenia oraz raportowanie regulacyjne wymagają pełnej wyjaśnialności, audytowalności i identyfikowalności. Każda decyzja agenta AML o „zatwierdzeniu” lub „blokadzie” transakcji musi transparentnie wskazywać, na jakiej regule się opiera, jaka historia transakcji oraz dane klienta zostały wzięte pod uwagę. W architekturze Stack największą wartość przedstawiają Warstwa 6 — Weryfikacja (wyjaśnialny łańcuch dowodowy) oraz Warstwa 7 — Governance (rejestracja algorytmów + kontrola transferu danych za granicę). W kontekście chińskich ram regulacyjnych dla sektora finansowego te dwie warstwy stanowią obligatoryjne wymagania wdrożeniowe, nie opcjonalne usprawnienia.

Produkcja: Systemy MES, ERP, QMS i SRM przez lata funkcjonowały w izolacji, przez co każda decyzja przekraczająca granice domen (na przykład „czy przy niewystarczających mocach produkcyjnych należy zwiększyć zakupy materiałów?”) wymaga żmudnego przechodzenia między czterema systemami. W kontekście produkcji przemysłowej agent funkcjonuje przede wszystkim jako warstwa orkiestracji międzysystemowej, a nie jako substytut pojedynczego systemu. Jednocześnie pobiera dane o stanach magazynowych z ERP, wskaźniki jakości z QMS, wykorzystanie mocy produkcyjnych z MES oraz oceny dostawców z SRM, formułując na tej podstawie kompleksową ocenę. W architekturze Stack największą wartość mają Warstwa 5 — Runtime (korporacyjna bramka API) oraz Warstwa 3 — Context (kumulacja wiedzy technologicznej, historycznych awarii oraz doświadczeń warsztatowych).

E-commerce: Operacje wielodomenowe podczas szczytów sprzedażowych (składanie zamówień, płatności, zarządzanie stanami magazynowymi, logistyka, obsługa klienta), testy obciążeniowe / spójność stanów magazynowych / ochrona przed fraudem bonusowym / rozliczenia międzyplatformowe. W e-commerce Agent najszybciej przyjął się w dwóch obszarach: kreacja i zarządzanie treścią (podmiana zdjęć produktów, zmiana tła, przygotowanie materiałów wielojęzycznych) oraz wspomaganie agentów obsługi klienta. Na Stacku największą wartość mają: Warstwa 4 — Skill (procesy zgodności i moderacji dla każdego SKU/kanału sprzedaży) oraz Warstwa 6 — Verification (automatyczna walidacja zgodności materiałów z wytycznymi platform).

Wspólny mianownik wszystkich czterech typów organizacji: im niżej w Stacku, tym bardziej opłaca się współdzielenie; im wyżej, tym bardziej opłaca się budowa własnych rozwiązań. Infrastruktura bazowa — Runtime, Model Router, Tool Gateway — sprawdza się lepiej, gdy kilka firm wspólnie ją rozwija lub korzysta ze sprawdzonych rozwiązań open-source. Natomiast Skill, Context i Governance muszą być budowane wewnętrznie, bo są nierozerwalnie związane z modelem biznesowym, wymogami regulacyjnymi i zasobami organizacji.

IX. Finalny produkt może wyglądać zupełnie inaczej, ale warstwa bazowa dzieli tę samą architekturę

Interfejs użytkownika, doświadczenie klienta i model biznesowy Coding Agenta i agenta wideo diametralnie się różnią.

Jednak wszystkie wymagają tych samych komponentów bazowych: Context, Task, Skill, Tools, Runtime, Verification, Memory i Governance — a każdy z nich ostatecznie musi przełożyć się na wymierne rezultaty biznesowe.

Agent wiedzy korporacyjnej i agent przeglądarki mogą wydawać się od siebie odległe, ale w ostatecznym rozrachunku oba muszą sprostać tym samym wyzwaniom technicznym: zarządzaniu uprawnieniami, stanem systemu, odtwarzaniu po awarii oraz audytowi.

Z tego powodu przy budowaniu wielu produktów AI warto rozdzielić architekturę na dwa poziomy.

Poziom górny — wertykalny. Każdy produkt koncentruje się na jednym zamkniętym procesie biznesowym (Job), mając własny interfejs użytkownika, model danych i wskaźniki efektywności. Coding Agent operuje na repozytoriach i przeglądach kodu, agent wideo — na scenariuszach i zasobach multimedialnych, agent badawczy — na źródłach i cytowaniach. Głębokość specjalizacji w każdym z tych obszarów nie może być zastąpiona przez uniwersalne zdolności modelu.

Poziom dolny — horyzontalny. Runtime Agentów, Router Modeli, Brama Narzędzi, Pamięć, Audyt, Secrety i Ewaluacja stanowią wspólną infrastrukturę, z której korzystają wszystkie produkty.

Takie podejście chroni przed dwiema skrajnościami: przed tworzeniem przez każdy zespół własnej implementacji tych samych komponentów oraz przed budową od samego początku rozległej platformy „uniwersalnego agenta”, która nie ma żadnych użytkowników. Ta druga pułapka dotknęła wiele zespołów w ciągu ostatnich dwóch lat — próbowały one objąć jednym rozwiązaniem wszystkie możliwe scenariusze, w rezultacie nie osiągając użytecznej głębokości w żadnym z nich.

Bardziej stabilna droga prowadzi przez weryfikację wartości w konkretnych zadaniach, a dopiero potem wyodrębnienie powtarzających się zdolności bazowych. Kluczowe przekonanie: warstwa ogólna wyrasta wyłącznie z konkretnych scenariuszy, nie da się jej zaprojektować na papierze. Kiedy od początku tworzy się Runtime „obsługujący wszystkie scenariusze”, zwykle oznacza to, że nie zrobiono tego porządnie dla żadnego z nich.

Trzy pytania weryfikacyjne (sprawdź po zakończeniu pisania)

Czy nasz wyabstrahowany Runtime zdążył potwierdzić swoją uniwersalność w przynajmniej dwóch konkretnych scenariuszach?
Czy projekt każdej warstwy odpowiada konkretnemu problemowi biznesowemu, który faktycznie wystąpił?
Gdybyśmy musieli dziś zredukować budżet o połowę — które warstwy byśmy zachowali? Jeśli „context i skill”, idziemy w dobrym kierunku; jeśli „runtime i bramka”, być może trzeba będzie przemyśleć wszystko od nowa.

To również moja długoterminowa obserwacja z konferencji Yunqi (roczne spotkanie technologiczne Alibaby): nad modelami wyłania się nowa warstwa systemowa, która nie należy do żadnego konkretnego produktu, lecz stopniowo staje się swego rodzaju OS dla ery Agentów. Kto pierwszy solidnie zbuduje tę warstwę OS, ten zyska przewagę w kolejnej iteracji produktu.

Wskazówki dla decydentów

Jeśli odpowiadasz za strategię AI w firmie o rocznym przychodzie przekraczającym 5 miliardów (CDO/CIO/CTO), są trzy rzeczy, które możesz zacząć wdrażać już teraz:

Trzy zasady wdrożenia Agent Stack w organizacji

Trzy kroki, od których warto zacząć

Stwórz snapshot obecnego Agent Stack w siedmiu warstwach — nie kupuj od razu produktów, najpierw sprawdź, co masz na każdej warstwie: pustkę, rozwiązania zewnętrzne czy półprodukty. Sam ten diagram ujawni prawdziwe wąskie gardło.
Wybierz jeden scenariusz o wysokim ROI i zamknij całą pętlę wertykalną — nie zaczynaj od budowy Runtime. Coding Agent, asystent obsługi klienta lub asystent R&D — wybierz jeden, przeprowadź przez cztery warstwy: Context, Task, Skill i Verification, a dopiero potem myśl o „platformie”.
Przenieś Governance na poziom inżynieryjny, nie kompliance — uprawnienia, audyt, wyjaśnialność, odpowiedzialność za błędy, zarządzanie zależnościami od stron trzecich — projektuj to od początku razem z agentami biznesowymi, a nie jako późniejszy dodatek.

Często zadawane pytania

P1: Czym ta siedmiowarstwowa architektura różni się od frameworków wielu agentów proponowanych przez Gartner i IDC?

Gartner i IDC koncentrują się na współpracy i zarządzaniu wieloma agentami na poziomie organizacyjnym; nasze siedem warstw opisuje wewnętrzną strukturę inżynieryjną pojedynczego agenta. Organizacja może operować na obu poziomach jednocześnie — pojedynczy agent przechodzi przez siedem warstw, a interakcje między wieloma agentami obsługuje orkiestracja. Stack to poziom mikro, orkiestracja to poziom makro.

Q2: Dlaczego warstwa modelu nie stanowi osobnej warstwy?

Model w systemie Agent pełni rolę zasobu przebiegającego horyzontalnie przez całą architekturę, a nie zajmuje wyłącznej warstwy. Model Router traktuje różne modele jako zróżnicowane zasoby obliczeniowe do przydzielania, stawiając je na tym samym poziomie „narzędzi” co Shell czy Browser w Runtime. Model jest oczywiście kluczowy, lecz nie może monopolizować złożoności całego Agent.

Q3: Czy małe zespoły powinny pominąć tę warstwę i od razu korzystać z produktów end-to-end, takich jak ChatGPT czy Claude?

Tak. Dla zespołów z rocznymi przychodami poniżej 100 milionów yuanów i niską złożonością organizacyjną bardziej opłacalne jest korzystanie z gotowych produktów Agent (Browser Use, Manus, Alibaba Cloud Bailian Agent i tym podobne). Siedem warstw omawianych w niniejszym artykule wychodzi od pytania: „Czy organizacja o rocznych przychodach powyżej 5 miliardów yuanów powinna zbudować własną platformę Agent?” — budowanie platformy przez mały zespół to逆向优化, czyli odwrócenie logiki optymalizacji.

Kontrola założeń (dla Ciebie i dla mnie)

Jeśli którekolwiek z poniższych trzech stwierdzeń akceptujesz w duchu bez zastrzeżeń, może to oznaczać, że dajesz się ponieść narracji zamiast kierować się dowodami:

„Wystarczy wystarczająco silny model, a Agent będzie działać sam.” (Model jest warunkiem koniecznym, ale nie wystarczającym. To, czy rozwiązanie wejdzie do produkcji, zależy od pozostałych sześciu warstw.)

„Potrzebujemy uniwersalnej platformy Agentów.” (Koszt takiego przedsięwzięcia najprawdopodobniej przewyższy wartość biznesową, jaką przyniesie w ciągu sześciu miesięcy.)

„Umiejętności można budować później, gdy model się ustabilizuje.” (Umiejętności to zasób organizacyjny — każdy dzień opóźnienia to jeden dzień mniej procentu składanego.)

Jeśli nie zgadzasz się z powyższymi trzema punktami, czytaj dalej.

Źródła, poziomy dowodów i kwalifikacja wiarygodności (na końcu artykułu)

„Jedno stanowisko. Cztery wejścia. Jedna podstawa.” — oficjalne materiały promocyjne i blog Qoder, prezentacja na żywo podczas konferencji Yunqi 2026 oraz artykuł Introducing Qoder 1.0 opublikowany w Alibaba Cloud Community 2026‑08‑31. Poziom dowodu: twierdzenie producenta (stanowisko Alibaba).
QwenWork Legal Document Fill Out: Sandbox Container + wirtualny pulpit + wywołanie narzędzi — pokaz na żywo QwenWork w Alibaba Cloud, artykuł z 2026‑09‑25 w Alibaba Cloud Community. Poziom dowodu: twierdzenie producenta (stanowisko Alibaba).
QoderWake jako produkt „cyfrowego pracownika”, wydany przez Alibabę 30 kwietnia 2026 — hasło w Baidu Encyclopedia dotyczące Qoder oraz oficjalne źródła Alibaba. Poziom dowodu: twierdzenie producenta (stanowisko Alibaba).
Lista zagrożeń OWASP 2026: Prompt Injection na pierwszym miejscu ——
Przegląd „State of Browser Use”, May 2026 (blog Michaela Livsa).
Poziom dowodu: synteza stron trzecich (stanowisko OWASP, konsensus branżowy).
Requesty: routing hierarchiczny z alokacją 70/20/10 może obniżyć koszty o 60-80% ——
Oficjalny blog Requesty, 2026.
Poziom dowodu: twierdzenie dostawcy (z perspektywy dostawcy routingu modeli, liczby są optymistyczne, należy traktować wyłącznie jako wskazówkę kierunkową).
Microsoft Agent Governance Toolkit (AGT), 02.04.2026 wydany na licencji MIT ——
Raport niteagent.com.
Poziom dowodu: synteza stron trzecich (stanowisko Microsoft, ale AGT to projekt open source, dane są weryfikowalne).
Protokół Anthropic Skills: wydany 16.10.2025, otwarty standard od 18.12.2025 — wpisy na blogu inżynieryjnym Anthropic oraz podsumowania na Substack i Medium LM Po. Poziom wiarygodności: twierdzenia producenta + synteza zewnętrzna (stanowisko Anthropic).
IDC przewiduje, że w 2026 roku 40% producentów wdroży harmonogramowanie oparte na AI — przegląd Groovy Web 2026, z powołaniem się na raport IDC. Poziom wiarygodności: synteza zewnętrzna (stanowisko IDC, dane kierunkowe).
Stripe “Minions”: tygodniowo łączy 1300+ PR, 0 osób piszących kod, wyłącznie manualna recenzja — Steve Kaliski z zespołu inżynieryjnego Stripe w programie How I AI z 25.03.2026 oraz relacja ByteMonk z 14.02.2026. Poziom wiarygodności: twierdzenia producenta (stanowisko Stripe, liczby orientacyjne, kontekst wewnętrzny zespołu inżynieryjnego Stripe, nie można ekstrapolować na średnią branżową).
BCG 2026 Applied AI Index: agentic AI stanowi 22%(2026) → 39%(2030) całkowitej wartości AI ——Publiczny raport BCG. Poziom wiarygodności: synteza zewnętrzna (stanowisko firmy konsultingowej, kierunkowe wartości liczbowe).
Gartner przewiduje, że w 2026 roku 40% przedsiębiorstw będzie wykorzystywać zadaniowe AI Agent, w porównaniu z <5% w 2025 roku ——Przegląd Paula Okhrema z 2026 roku, powołujący się na Gartner. Poziom wiarygodności: synteza zewnętrzna (stanowisko Gartner, orientacyjne odniesienie).
Chińska CAC/NDRC/MIIT (Cyberspace Administration of China / National Development and Reform Commission / Ministry of Industry and Information Technology) wspólnie wydały „Opinię w sprawie standaryzowanych zastosowań i innowacyjnego rozwoju inteligentnych agentów”, która weszła w życie 2026-07-15 ——Miesięczny biuletyn Rimon Law dotyczący chińskich regulacji AI, lipiec 2026. Poziom wiarygodności: synteza zewnętrzna (stanowisko kancelarii prawnej, weryfikowalność dokumentu regulacyjnego).
TinyFish: finansowanie w wysokości 47 mln USD, klienci w tym Google / DoorDash / Amazon, zimny start przeglądarki <250 ms — Przegląd SwitchTools 2026. Poziom dowodu: kompleksowa ocena zewnętrzna (stanowisko portalu recenzji produktowych, dane liczbowe wymagają weryfikacji na oficjalnej stronie TinyFish).

Jeśli oceniasz, jak zbudować wewnętrzną platformę Agent w przedsiębiorstwie, które zdolności należy rozwijać samodzielnie / kupować / współdzielić oraz które Agent Runtime oferują najwyższą wartość wielokrotnego użytku — chętnie porozmawiamy. Świadczymy usługi doradztwa specjalistycznego w zakresie transformacji AI w przedsiębiorstwie — od architektury Agent, przez projektowanie Runtime, po gromadzenie Skillów. Pomagamy przekształcić „pojedynczego Agenta” w „platformę Agentów na poziomie organizacji”.

Szkolenia wewnętrzne dla przedsiębiorstw: Skierowane do kadry zarządzającej i kluczowych specjalistów — 3-dniowy kurs podstawowy w cenie 90 000 ¥ za sesję, podczas którego zespół ekspercki拆 analizuje siedmiowarstwowy model Agent Stack, inżynieryjne podejście do Governance oraz metodykę budowania repozytorium Skillów.
Konsultacje specjalistyczne: 90-minutowa diagnoza architektoniczna od 3000 ¥ — niezależna ocena aktualnego stanu siedmiu warstw w organizacji, identyfikacja luk oraz rekomendacja: external采购 vs. budowanie we własnym zakresie; pogłębione wsparcie projektowe wyceniane osobno.
Prelekcje dla kadry zarządzającej i wystąpienia branżowe: Tematyczne wystąpienia na konferencjach branżowych, zamkniętych spotkaniach executive oraz forach dyskusyjnych — agenda projektowana po kontakcie.

Adres do współpracy: [email protected].

Polecana lektura: „AI 转型七步框架” (Siedem kroków transformacji AI), kompleksowy przewodnik po pełnej ścieżce wdrażania AI w organizacji.

Wytyczne lokalizacyjne (tabela porównawcza tłumaczeń wielojęzycznych, ustalenia strategiczne IAIUSE na rok 2026-08-09)

Podczas tłumaczenia na 19 języków, poniższe elementy podlegają lokalizacji na rynek docelowy z zachowaniem struktury i formy wizualnej:

中文稿内容	波兰语版
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

区域	中国	北美	日本	欧洲	中东
云平台/协作工具	阿里云 / 钉钉 / 飞书	Alibaba Cloud / AWS / GCP / Azure / Slack / Teams	アリババクラウド / AWS / GCP / Azure / Slack / Teams / Lark	Alibaba Cloud / AWS / GCP / Azure / Slack / Teams	علي بابا كلاود / AWS / Slack / Teams
电信运营商（企业 Agent 部署场景）	中国电信/移动/联通	AT&T / Verizon / T-Mobile	NTT / KDDI / ソフト_bank	Deutsche Telekom / Vodafone	STC / Etisalat
制造业代表企业（ERP/MES/QMS/SRM 案例）	中国制造业代表企业	GE / Honeywell / Rockwell	Toyota / Hitachi / NTT Data	Siemens / Bosch / SAP	SABIC / Aramco / STC

Chiński bank (przypadek finansowy)	JPMorgan / Goldman Sachs	Mitsubishi UFJ / SMFG	Deutsche Bank / Commerzbank	Emirates NBD / QNB
Sandbox Container / Virtual Desktop / Tool Calling	Sandbox Container / Virtual Desktop / Tool Calling	サンドボックス / 仮想デスクトップ / ツール呼び出し	Sandbox-Container / Virtueller Desktop / Werkzeugaufruf	حاوية معزولة / سطح مكتب افتراضي / استدعاء الأدوات
One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness

| Umiejętność dziedzinowa / Umiejętność programowania / Umiejętność badań SEO / Umiejętność kreatywna e‑commerce / Umiejętność operacyjna | Umiejętność dziedzinowa (zachować) / Umiejętność programowania / Umiejętność badań SEO / Umiejętność kreatywna e‑commerce / Umiejętność operacyjna | Umiejętność domeny / Umiejętność kodowania / Umiejętność badań SEO / Umiejętność kreatywna handlu elektronicznego / Umiejętność operacyjna | Umiejętność-dziedzinowa / Umiejętność-programowania / Umiejętność-badań-SEO / Umiejętność-kreatywna-e‑commerce / Umiejętność-operacyjna | Umiejętność dziedzinowa / Umiejętność programowania / Umiejętność badań SEO / Umiejętność kreatywna handlu elektronicznego / Umiejętność operacyjna |

O tej serii

„Cloudnest Insights” to seria raportów terenowych wdrożona przez IAIUSE, wychodząca od konferencji Cloudnest 2026, która z perspektywy badacza analizuje rzeczywiste zmiany zachodzące w przemyśle AI — bez gonienia za newsami, skupiając się wyłącznie na kierunkach inwestycji i sile dowodów.

Seria obejmuje takie tematy jak: warstwa systemowa ponad modelami, wdrażanie Agentów, aktywa Context, projektowanie organizacji AI w przedsiębiorstwach, migracja jednostek konkurencyjnych produktów AI i inne. Łącznie około 10 artykułów.

Mam prawie 8 lat doświadczenia w doradztwie dla dużych przedsiębiorstw oraz analizie biznesowej. Pracowałem w IBM, realizując projekty dla sektora telekomunikacyjnego, finansowego, ubezpieczeniowego i produkcyjnego. Później kontynuowałem karierę na stanowiskach związanych z rozwojem produktów operatorskich, aplikacji internetowych oraz systemów opartych na sztucznej inteligencji – zajmując się analizą wymagań, projektowaniem produktów i wdrożeniami międzydziałowymi.

Za tym blogiem stoi niewielki zespół – ja oraz jedna lub dwie osoby pracujące ze mną regularnie. Każdy z nas specjalizuje się w innym obszarze: badaniach narzędzi programistycznych wykorzystujących AI, analizie przypadków zarządzania organizacyjnego oraz coachingu i prowadzeniu rozmów. Większość projektów, które prezentujemy jako „pomoc firmom w przejściu przez ten proces”, została wspólnie zrealizowana przez nasz zespół.

Nasza baza materiałów badawczych obejmuje ponad 200 opracowań. Wnioski przedstawiane w tej serii artykułów opierają się na bezpośrednich obserwacjach z realizacji projektów oraz weryfikacji poprzez pryzmat doświadczeń z różnych branż. Reprezentują one wyraźnie nasze autor skie stanowisko i nie odzwierciedlają poglądów żadnego producenta ani dostawcy technologii.