Przejdź do głównej zawartości
AI Developer Toolkit

Jak uniknąć uzależnienia od dostawcy: przenośny kontekst, skille i potoki

Uzależnienie od dostawcy agentów AI (vendor lock-in) siedzi w konfiguracji, nie w kodzie. AGENTS.md, Agent Skills, serwery MCP, specyfikacje i zestawy ewaluacji przechodzą między Claude Code, Codeksem i Cursorem niewielkim nakładem pracy. Środowiska agentów chmurowych, boty do przeglądu kodu, hooki, format pluginów i polityka zarządzana nie przechodzą. Trzymaj treść w repozytorium, pliki dostawców utrzymuj cienkie, a wyjście ćwicz regularnie.

Rok temu twoja organizacja inżynierska ustandaryzowała się na jednym agencie kodującym. Od tego czasu zespół napisał 40 skilli, bota do przeglądu kodu dostrojonego do waszych reguł, środowisko agenta chmurowego, które buduje monorepo, i hook blokujący odczyt sekretów. Teraz model konkurencji wygrywa w waszych ewaluacjach, dostawca dwa razy zmienił plany, a zarząd zadaje uczciwe pytanie: ile kosztowałaby zmiana i skąd to wiecie?

Ta strona jest dla CTO, który odpowiada za strategię dostawców, i dla członka zarządu, który podpisuje umowę. Należy do grupy Koszty i dostawcy: poprzedza ją zarządzanie ryzykiem dostawców, które klasyfikuje zależności według skutków awarii, a po niej przychodzi zakup narzędzi AI do kodowania, gdzie wnioski z próby wyjścia zamieniają się w pytania do umowy.

Co daje przenośna konfiguracja agentów

Dział zatytułowany „Co daje przenośna konfiguracja agentów”
  • Tabelę inwentaryzacji wszystkich zasobów agentów, podzielonych na „przechodzi”, „przechodzi z konwerterem” i „zostaje”, z wersją, na której sprawdzono każde twierdzenie.
  • Tabelę decyzyjną, kiedy opłaca się przyjąć funkcję specyficzną dla dostawcy, napisaną tak, by mógł jej użyć członek zarządu.
  • Układ repozytorium i test CI (sprawdzony 2026-09-26), który zawodzi, gdy przenośna warstwa rozjeżdża się między narzędziami.
  • Checklistę próby wyjścia z kryteriami zaliczenia i szablonem protokołu, dzięki którym koszt zmiany jest zmierzoną liczbą, a nie przypuszczeniem.
  • Trzy prompty do skopiowania i typowe awarie, na które trafiasz, gdy naprawdę próbujesz zmienić narzędzie.

Które zasoby agentów przechodzą między dostawcami?

Dział zatytułowany „Które zasoby agentów przechodzą między dostawcami?”

Zasób przechodzi, gdy drugie narzędzie czyta ten sam plik albo ten sam protokół bez przepisywania. Dziś ten próg spełnia pięć rodzajów zasobów i każdy ma pułapkę, o której komunikaty dostawców milczą.

ZasóbOtwarty standard lub formatKto czyta natywnie (sprawdzono 2026-09-26)Pułapka
Instrukcje projektuAGENTS.md, pod opieką Agentic AI Foundation (AAIF) w Linux Foundation; „used by over 60k open-source projects” według agents.md, wrzesień 2026Codex czyta AGENTS.md natywnie. Claude Code czyta go tylko wtedy, gdy projekt nie ma CLAUDE.md, od v2.1.277 (sesje first-party) lub v2.1.281 (Bedrock, Google Cloud, Foundry, bramy LLM), w obu przypadkach na kanale latest; kanał stable (2.1.274) jeszcze tego nie robiRepozytorium z oboma plikami dostaje w Claude Code wyłącznie CLAUDE.md. Wpisz @AGENTS.md w pierwszej linii CLAUDE.md, żeby źródłem pozostał jeden plik. Cursor czyta własne Rules; generuj je z tego samego źródła (zob. zakładkę Cursor)
SkilleAgent Skills, otwarty standard od 2025-12-18: folder z plikiem SKILL.md, w którym name ma najwyżej 64 znaki, a description najwyżej 1024; w prezentacji klientów specyfikacji 2026-09-26 było ich 46Claude Code (.claude/skills/), Codex i Cursor (.agents/skills/, według README CLI skills 1.7.0)Format przechodzi, folder nie. Skill skopiowany bez skilli, od których zależy, albo bez hooków pluginu, które go uruchamiają, może się załadować i nic nie robić
Połączenia z narzędziamiModel Context Protocol (MCP), przekazany przez Anthropic do AAIF 2025-12-09; aktualna specyfikacja 2026-07-28Wszystkie trzy narzędzia są klientami MCPSerwer przechodzi, jego rejestracja nie (.mcp.json kontra config.toml). Claude Code domyślnie negocjuje protokół 2026-07-28, a Codex 0.157.1 nie (mcp_2026_07_28 wyłączone), więc serwer, który porzuci starszy protokół, przestanie działać w Codeksie
Specyfikacje i decyzjeMarkdown w repozytorium: specyfikacje, kryteria akceptacji, rekordy decyzji architektonicznych (ADR)Każdy agent, jak zwykłe plikiBrak, dopóki leżą w Gicie, a nie w projekcie czy pamięci u dostawcy
Testy, bramki i ewaluacjeTwoje CI plus framework ewaluacyjny, który uruchamia więcej niż jednego agentaKażdy agent, przez CI; promptfoo 0.123.1 ma providery dla Claude Agent SDK i Codex SDKZestaw ewaluacji, który woła bezpośrednio API jednego dostawcy, sam jest lock-inem. Tak samo bramka, która istnieje wyłącznie jako check w CI wystawiany przez bota dostawcy

Dla członka zarządu wynikają z tego dwie rzeczy. Po pierwsze, otwartymi standardami zarządza fundacja, a nie jeden dostawca, co zmniejsza ryzyko, że format zniknie razem ze zmianą cennika. Po drugie, „przechodzi” wciąż oznacza, że ktoś uruchamia konwerter albo drugie polecenie instalacji. Ten wysiłek mierzy próba wyjścia opisana niżej.

Które zasoby zostają, gdy zmieniasz dostawcę?

Dział zatytułowany „Które zasoby zostają, gdy zmieniasz dostawcę?”

Wszystko poniżej ma wartość i wszystko poniżej odbudowuje się ręcznie przy zmianie dostawcy. Celem nie jest unikanie tych funkcji. Celem jest trzymanie treści w repozytorium, tak żeby plik każdego dostawcy był tylko cienką nakładką.

ZasóbJak przechowuje go każdy dostawcaCo trzymać zamiast tego w repozytorium
Środowiska agentów chmurowychŚrodowiska chmurowe Claude Code (poziom dostępu do sieci, zmienne środowiskowe, skrypt instalacyjny) konfiguruje się osobno dla każdego środowiska w ustawieniach chmurowych Claude Code; środowiska chmurowe Codeksa i Cloud Agents w Cursorze z funkcją Builds konfiguruje się w ustawieniach każdego dostawcyJeden scripts/agent-setup.sh, który instaluje zależności i przygotowuje dane testowe. Krok instalacyjny każdego dostawcy wywołuje ten skrypt i nic poza nim
Boty do przeglądu koduZarządzany Code Review w Claude Code bierze wytyczne z CLAUDE.md lub REVIEW.md i publikuje uwagi w linii kodu, ale nigdy nie zatwierdza ani nie blokuje pull requesta; przegląd w Codeksie czyta własne reguły przeglądu z AGENTS.md (sprawdzono 2026-08-28); Bugbot w Cursorze konfiguruje się w CursorzeKryteria przeglądu w jednym pliku Markdown, do którego odwołuje się konfiguracja każdego bota, a decyzja o scaleniu w twoich wymaganych checkach CI, nigdy w werdykcie bota
HookiClaude Code 2.1.283 ma 33 zdarzenia hooków; Codex 0.157.1 ma 12 i oba zestawy zdarzeń się nie pokrywają; hooki Cursora to procesy wymieniające JSON przez stdioLogika hooka jako skrypt w repozytorium (scripts/guard-secrets.sh). Rejestracja hooka w każdym narzędziu to krótki adapter, który tylko wywołuje skrypt
PluginyTrzy manifesty: .claude-plugin/plugin.json, .codex-plugin/plugin.json z .agents/plugins/marketplace.json oraz układ .cursor-plugin/ w CursorzeSkille i serwery MCP wewnątrz pluginu. Codex 0.157.1 potrafi instalować z .claude-plugin/marketplace.json, ale nie sprawdzono, które komponenty specyficzne dla Claude się wtedy włączają
Polityka zarządzana i uprawnieniamanaged-settings.json w Claude Code, requirements.toml w Codeksie, panel administracyjny w CursorzeNeutralna względem narzędzi tabela intencji, przekładana na plik każdego narzędzia, jak w artykule o jednej polityce dla wszystkich agentów kodujących
Pamięć i historia sesjiAuto memory w Claude Code; pamięć (memories) w Codeksie, domyślnie wyłączona; historia sesji chmurowych u każdego dostawcyDecyzje i wnioski zapisane z powrotem w AGENTS.md, skillach lub ADR-ach. To, co żyje tylko w pamięci, przepada przy wyjściu
Dostrojenie do modeluPrompty, ustawienia poziomu wysiłku (effort) i wybory modeli dopasowane do jednej rodziny modeliZestaw ewaluacji, który dla każdego zadania mówi, czy model zastępczy jest wystarczająco dobry. Aktualne modele znajdziesz w hubie modeli

Ile lock-inu warto zaakceptować?

Dział zatytułowany „Ile lock-inu warto zaakceptować?”

Przyłóż tę tabelę do każdej nowej funkcji agenta, którą zespół chce przyjąć. CTO dostaje domyślną odpowiedź, a członek zarządu pytanie, które warto zadać. Skopiuj ją do repozytorium jako docs/agent-policy/lock-in.md, bo tam oczekuje jej trzeci prompt poniżej.

Funkcja…Domyślna decyzjaWarunek, który utrzymuje tanie wyjściePytanie członka zarządu
Czyta otwarty format z repozytorium (AGENTS.md, skille, MCP)PrzyjąćNic ponad test CI opisany niżej„Czy plik źródłowy jest w Gicie?”
Dodaje nakładkę dostawcy na treść repozytorium (plugin, rejestracja hooka, krok instalacji w chmurze)PrzyjąćNakładka wywołuje skrypty z repozytorium i nie zawiera własnej logiki„Ile linii musielibyśmy przepisać?”
Trzyma reguły lub dane wyłącznie w systemie dostawcy (reguły bota w panelu, wiedza w pamięci)Przyjąć tylko z eksportemCykliczny eksport do repozytorium, sprawdzany w próbie wyjścia„Czy możemy to dziś wyeksportować i czy próbowaliśmy?”
Podejmuje decyzję o scaleniu lub wydaniuTylko doradczoDecydują twoje wymagane checki; bot dostawcy komentuje„Co się scali, jeśli ten dostawca jutro padnie?”
Wymaga modelu dostępnego tylko u jednego dostawcy w procesie produkcyjnymPrzyjąć z planem awaryjnymPrzetestowany drugi model na tych samych ewaluacjach, zgodnie z zarządzaniem ryzykiem dostawców„Jaki jest nasz tryb ograniczonego działania i kiedy ostatnio go uruchomiliśmy?”

Skonfiguruj przenośną warstwę w każdym narzędziu

Dział zatytułowany „Skonfiguruj przenośną warstwę w każdym narzędziu”

Układ repozytorium jest taki sam dla każdego zespołu. Różnią się tylko polecenia rejestracji.

repo/
├── AGENTS.md                  # jedno źródło instrukcji
├── CLAUDE.md                  # linia 1: @AGENTS.md, potem uwagi tylko dla Claude Code
├── .agents/skills/            # wspólne skille (Codex, Cursor)
├── .claude/skills/            # wygenerowana kopia dla Claude Code; CI sprawdza zgodność
├── .mcp.json                  # serwery MCP projektu dla Claude Code
├── .codex/config.toml         # serwery MCP projektu dla Codeksa, te same nazwy
├── docs/specs/  docs/adr/     # specyfikacje i decyzje
├── docs/review-rules.md       # kryteria, do których odwołuje się każdy bot przeglądu
├── evals/                     # zadania i sprawdzenia uruchamiane na dowolnym agencie
└── scripts/
    ├── agent-setup.sh         # wywoływany przez każde środowisko agenta chmurowego
    ├── guard-secrets.sh       # wywoływany przez adapter hooka w każdym narzędziu
    └── check-portability.sh   # test CI opisany niżej

Wspólne skille zainstalujesz dla wszystkich trzech narzędzi jednym poleceniem CLI skills (npm skills 1.7.0), uruchomionym w katalogu głównym repozytorium:

Okno terminala
npx skills add anthropics/skills --skill skill-creator -a claude-code -a codex -a cursor

Wpisz @AGENTS.md w pierwszej linii CLAUDE.md, żeby Claude Code czytał wspólne reguły na obu kanałach wydań, a serwery MCP rejestruj w zakresie projektu, żeby plik trafił do repozytorium:

Okno terminala
claude mcp add --transport http --scope project sentry https://mcp.sentry.dev/mcp

Żeby zobaczyć, co przeniósłby import z innego agenta, użyj importera konfiguracji z Codeksa, Gemini CLI i Cursora, dostępnego w Claude Code 2.1.283. Najpierw uruchom go na sucho:

Okno terminala
claude import codex --dry-run

Importer przenosi pliki instrukcji, serwery MCP, polecenia, subagentów i skille. Hooków, uprawnień i środowisk chmurowych nie ma na tej liście, więc zaplanuj ich odbudowę.

Generator reguł, taki jak rulesync czy Ruler, opłaca się, gdy trzech lub więcej agentów potrzebuje tych samych reguł, konfiguracji MCP i skilli. Przy samych regułach AGENTS.md z importem @AGENTS.md obsługuje Claude Code i Codeksa bez niczego do regenerowania. Kompromisy opisuje artykuł o jednym źródle reguł dla każdego agenta.

Jak udowodnić, że konfiguracja pozostaje przenośna?

Dział zatytułowany „Jak udowodnić, że konfiguracja pozostaje przenośna?”

Przenośna warstwa psuje się po jednej wygodnej zmianie naraz: reguła dopisana tylko do CLAUDE.md, skill zainstalowany dla jednego narzędzia, serwer MCP zarejestrowany na jednym laptopie. Dwa sprawdzenia i jeden raport wyłapują to bez czytania konfiguracji przez człowieka.

  1. Uruchamiaj test dryfu przy każdym pull requeście. Ten skrypt uruchomiono 2026-09-26 na testowym repozytorium: przeszedł na zsynchronizowanym układzie i zawiódł z oboma komunikatami po edycji jednego skilla i usunięciu jednego serwera MCP. Wymaga bash, jq i diff.

    #!/usr/bin/env bash
    # scripts/check-portability.sh: fail CI when the portable agent layer drifts between tools.
    set -euo pipefail
    fail=0
    

    # 1. One instruction source: CLAUDE.md imports AGENTS.md instead of forking it.
    if [ -f CLAUDE.md ] && [ "$(head -n1 CLAUDE.md)" != '@AGENTS.md' ]; then
      echo "CLAUDE.md does not start with @AGENTS.md"; fail=1
    fi
    

    # 2. One skill set: the Claude Code copy matches the shared .agents/skills copy.
    if ! diff -r .agents/skills .claude/skills > /dev/null; then
      echo "Skills differ between .agents/skills and .claude/skills"; fail=1
    fi
    

    # 3. One MCP list: the same server names for Claude Code and Codex.
    claude_mcp=$(jq -r '.mcpServers | keys[]' .mcp.json | sort | xargs)
    codex_mcp=$(sed -nE 's/^\[mcp_servers\.([A-Za-z0-9_-]+)\]$/\1/p' .codex/config.toml | sort | xargs)
    if [ "$claude_mcp" != "$codex_mcp" ]; then
      echo "MCP servers differ: .mcp.json [$claude_mcp] vs .codex/config.toml [$codex_mcp]"; fail=1
    fi
    

    [ "$fail" -eq 0 ] && echo "Portable layer in sync"
    exit "$fail"

  2. Co miesiąc uruchamiaj ten sam zestaw ewaluacji na dwóch agentach. Trzymaj zadania w evals/ i uruchamiaj je we frameworku z providerami dla więcej niż jednego agenta. promptfoo 0.123.1 ma providery anthropic:claude-agent-sdk i openai:codex-sdk, więc jeden promptfooconfig.yaml daje zestawienie odsetka zaliczonych zadań obok siebie. README promptfoo podaje, że projekt jest teraz częścią OpenAI i pozostaje na licencji MIT; trzymaj definicje zadań w zwykłych plikach, żeby dało się wymienić sam framework. Projektowanie zadań opisuje strona o ewaluacjach agentów kodujących.

  3. Raportuj trend, nie migawkę. Zespół platformowy co kwartał raportuje dwie liczby: liczbę niezaliczonych testów dryfu i odsetek zaliczonych ewaluacji drugiego agenta. Rosnąca różnica to wczesne ostrzeżenie, że twój framework ewaluacyjny dopasowuje się do jednego dostawcy.

Właścicielem testu i przebiegów ewaluacji jest zespół platformowy; CTO zatwierdza kwartalne liczby, zgodnie z modelem operacyjnym.

Przeprowadź próbę wyjścia, zanim będzie potrzebna

Dział zatytułowany „Przeprowadź próbę wyjścia, zanim będzie potrzebna”

Próba wyjścia to ćwiczenie z pomiarem czasu, w którym jeden zespół dostarcza prawdziwą pracę za pomocą agenta zapasowego, korzystając wyłącznie z tego, co jest w repozytorium. Zamienia „moglibyśmy zmienić” w zmierzony koszt. Przeprowadzaj ją raz na kwartał albo przed każdym odnowieniem umowy.

  1. Wybierz zakres. Jeden zespół, od trzech do pięciu inżynierów, jeden dzień roboczy, dwa lub trzy zadania z backlogu zwykłej wielkości z gotowymi kryteriami akceptacji. Wybierz zadania, które dotykają waszych serwerów MCP i co najmniej jednego skilla.
  2. Zamroź główne narzędzie na czas próby. Zespół pracuje wyłącznie w agencie zapasowym. Nie wolno kopiować ustawień z katalogu użytkownika głównego narzędzia; wszystko musi pochodzić z Gita albo z udokumentowanego polecenia instalacji.
  3. Odbuduj tylko to, czego repozytorium nie dostarcza, i mierz czas. Zapisuj każdą minutę konfiguracji: rejestrację MCP, instalację skilli, adaptery hooków, środowisko chmurowe, konfigurację bota przeglądu.
  4. Dostarczaj przez normalne bramki. Każde zadanie przechodzi przez te same wymagane checki CI, zestaw ewaluacji i ścieżkę przeglądu co każda inna zmiana. Na czas próby nie znosi się żadnej bramki.
  5. Wyeksportuj to, co trzyma dostawca. Spróbuj wyeksportować reguły bota przeglądu, ustawienia środowiska chmurowego oraz pamięć lub historię sesji, na których polega zespół. Zapisz, czego nie dało się wyeksportować.
  6. Zapisz wynik i ustal kolejny krok. Wypełnij szablon poniżej. Każdy wiersz oznaczony „odbudowane ręcznie” staje się zadaniem w backlogu: przenieść tę treść do repozytorium.

Każdą próbę zapisuj w repozytorium polityki według tego szablonu:

PoleZapis
Data, zespół, główny agent i wersja, agent zapasowy i wersja
Zadania podjęte / scalone przez normalne bramki
Czas konfiguracji przed pierwszym zadaniem agenta (minuty)
Odsetek zaliczonych ewaluacji: agent główny / agent zapasowy
Zasoby, które zadziałały bez zmian (instrukcje, skille, MCP, specyfikacje, ewaluacje)
Zasoby odbudowane ręcznie, z liczbą minut dla każdego
Zasoby, których nie dało się wyeksportować od dostawcy
Bramki zależne od bota dostawcy
Zadania następcze, właściciele i terminy

Próba jest zaliczona, gdy spełnione są wszystkie cztery warunki: każde podjęte zadanie zostało scalone przez normalne bramki, konfiguracja zajęła mniej niż pół dnia roboczego, odsetek zaliczonych ewaluacji agenta zapasowego mieści się w tolerancji ustalonej z góry, a żadna bramka nie zależała od bota głównego dostawcy. Niezaliczona próba też jest cennym wynikiem: wskazuje kolejne zadania do backlogu. CTO zatwierdza protokół, a członek zarządu czyta czas konfiguracji i listę zadań następczych jako aktualny koszt zmiany dostawcy.

Prompty do skopiowania na audyt przenośności

Dział zatytułowany „Prompty do skopiowania na audyt przenośności”

Co się psuje, gdy próbujesz zmienić dostawcę agenta?

Dział zatytułowany „Co się psuje, gdy próbujesz zmienić dostawcę agenta?”

Drugie narzędzie ignoruje twoje instrukcje. Claude Code na kanale stable (2.1.274 w dniu 2026-09-26) nie sięga awaryjnie po AGENTS.md, a nawet na latest czyta wyłącznie CLAUDE.md, gdy istnieją oba pliki. Naprawa: wpisz @AGENTS.md w pierwszej linii CLAUDE.md i pozwól, żeby pilnował tego test dryfu.

Skille się ładują, ale nigdy nie uruchamiają. Skill skopiowany przez npx skills add nie ma hooka startu sesji, który instaluje jego wersja w pluginie, albo deleguje pracę do skilla, którego nie skopiowano. Naprawa: zainstaluj cały zestaw skilli albo, jeśli istnieje, wersję w pluginie dostawcy, i dodaj do zestawu ewaluacji test dymny (smoke test), który musi uruchomić skill.

Serwer MCP łączy się w jednym narzędziu, a w drugim nie. Nazwa serwera różni się między .mcp.json a .codex/config.toml albo serwer obsługuje tylko protokół 2026-07-28, którego Codex 0.157.1 nie negocjuje. Naprawa: trzymaj identyczne nazwy (pilnuje tego test dryfu) i przetestuj każdy serwer w każdym kliencie, zanim dodasz go do listy zatwierdzonych.

Pokrycie przeglądem po cichu znika. Bot przeglądu starego dostawcy był jedynym recenzentem dla pewnej klasy zmian i nikt tego nie zauważył, dopóki go nie wyłączono. Naprawa: przenieś kryteria przeglądu do docs/review-rules.md, zrób z decyzji o scaleniu wymagany check CI i używaj pakietu dowodów, żeby pull request dało się scalić bez werdyktu jednego dostawcy.

Agent chmurowy nie potrafi zbudować repozytorium. Konfiguracja żyła w formularzu środowiska u dostawcy, a nie w Gicie. Naprawa: przenieś każdy krok instalacji do scripts/agent-setup.sh i niech środowisko każdego dostawcy wywołuje wyłącznie ten skrypt.

Wiedza odchodzi razem z dostawcą. Decyzje żyły w pamięci agenta albo w historii sesji. Naprawa: zapisywanie wniosków z powrotem w AGENTS.md, skillach lub ADR-ach włącz do definicji ukończenia, a historię sesji eksportuj przed końcem umowy.

Nowy model radzi sobie gorzej z waszą pracą. Prompty i ustawienia poziomu wysiłku (effort) były dostrojone do starego modelu. Naprawa: porównaj obu agentów na zestawie ewaluacji przed zmianą i ustal tolerancję z góry, żeby decyzji nie podważano po fakcie.

Dokąd dalej w temacie lock-inu i przenośności

Dział zatytułowany „Dokąd dalej w temacie lock-inu i przenośności”

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie