Zespół platformowy agentów: harness jako produkt

Zespół platformowy agentów utrzymuje wspólny harness agentów kodujących jako produkt wewnętrzny: politykę zarządzaną, wspólne skille i hooki, katalog MCP, ewaluacje harnessu, środowiska agentów i telemetrię. Publikuje poziomy usług dla zespołów produktowych, każdą zmianę harnessu przepuszcza przez bramkę ewaluacji i trzyma się z dala od zatwierdzania pull requestów zespołów produktowych.

Trzy miesiące temu zatwierdziłeś powołanie grupy platformowej. Zbudowała plugin, którego nikt nie zainstalował, plik polityki, który bez ostrzeżenia zablokował serwery MCP dwóch zespołów, i kolejkę zgłoszeń, na które odpowiedź trwa dziś jedenaście dni. Zespoły produktowe kopiują już skille do własnych repozytoriów, żeby ją obejść. Harness istnieje, ale działa jak okienko obsługi zgłoszeń, a nie jak produkt.

Ta strona jest dla CTO, który finansuje zespół, i dla tech leada, który nim kieruje albo od niego zależy. Podział odpowiedzialności i to, kiedy dedykowany zespół ma uzasadnienie, opisuje model operacyjny; tutaj chodzi o prowadzenie zespołu, który już istnieje.

Co daje organizacji zespół platformowy agentów

• Jednostronicową kartę zespołu (charter): misję, zakres, to, czego zespół odmawia, i poziomy usług.
• Uporządkowany backlog dziewięciu produktów harnessu, każdy z testem „gotowe, gdy”.
• Ten backlog przełożony na konfigurację Claude Code, Codeksa i Cursora.
• Bramkę ewaluacji wydań harnessu w CI, z regułą decyzyjną i wskazaną osobą, która podpisuje wynik.
• Tabelę poziomów usług i pięć metryk produktowych.
• Pięć zasad, które nie pozwalają zespołowi platformowemu stać się bramką.

Dlaczego prowadzić harness jak produkt, a nie projekt?

Artefakty harnessu są stanem współdzielonym. Skill, hook, klucz polityki albo serwer MCP zmienia zachowanie każdej sesji agenta, która go wczytuje, i zmienia się dalej, bo modele, klienty i bazy kodu ruszają się pod nim. Projekt, który „wdraża harness” i się rozwiązuje, zostawia artefakt bez właściciela, który niszczeje.

Dowody na sens tej inwestycji są korelacyjne, ale spójne. Raport DORA 2025 stwierdza, że „90% of organizations have adopted at least one platform and there is a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI” (Google Cloud, 2025-09-23). „Quality internal platforms” to także jedna z siedmiu zdolności modelu DORA AI Capabilities (Google Cloud, 2025-09-23). Stripe pokazuje, jak to wygląda w skali: jego Toolshed „currently contains nearly 500 MCP tools for internal systems and SaaS platforms we use at Stripe” (blog inżynierski Stripe, 2026-02-19), czyli jeden katalog, z którego korzysta każde uruchomienie agenta.

„Produkt” znaczy tu trzy konkretne rzeczy: zespoły produktowe mogą odmówić większości tego, co dostarczasz, każde wydanie ma wersję i da się je wycofać, a sukces mierzy się tym, co zmienia się dla tych zespołów.

Co wpisać do karty zespołu platformowego agentów?

Skopiuj to do podręcznika inżynierskiego i uzupełnij pola w nawiasach ostrych. Lista „czego nie robimy” jest ważniejsza niż zakres: to ją zespoły produktowe zacytują, gdy zespół platformowy zacznie wchodzić im w drogę.

# Karta zespołu platformowego agentów: <organizacja>, v<N>, <data>

## Misja
Sprawić, by każdemu zespołowi produktowemu dostarczanie z agentami było tanie
i bezpieczne, i udowadniać to dowodami, a nie wysiłkiem recenzentów.

## Klienci
Zespoły produktowe używające Claude Code, Codeksa lub Cursora. Bezpieczeństwo
i właściciel wydań są partnerami, nie klientami.

## Odpowiadamy za (produkty harnessu)
1. Minimum polityki: ustawienia zarządzane i wymagania dla każdego narzędzia.
2. Plugin „utwardzonej ścieżki”: wspólne skille, hooki i agenty, jeden marketplace.
3. Katalog MCP: sprawdzone serwery, zawężone poświadczenia, ścieżka zgłoszeń.
4. Ewaluacje harnessu: zestaw, który musi przejść każda zmiana harnessu.
5. Środowiska agentów: obrazy dev container i piaskownice w chmurze lub własne.
6. Telemetria: dane o użyciu, kosztach i wynikach we własnym kolektorze.
7. Kanały wersji: które wersje klientów i które modele działają w zespołach.
8. Onboarding: ścieżka pierwszego tygodnia do pierwszej przyjętej zmiany agenta.
(Tożsamości agentów prowadzimy razem z bezpieczeństwem; zob. model operacyjny.)

## Czego nie robimy
- Nie zatwierdzamy, nie blokujemy i nie recenzujemy pull requestów zespołów produktowych.
- Nie decydujemy, co sprawdzają testy i kryteria akceptacji produktu.
- Nie narzucamy żadnego elementu utwardzonej ścieżki spoza minimum polityki.
- Nie wydajemy zmiany harnessu, która nie przeszła zestawu ewaluacji.

## Minimum polityki (jedyna obowiązkowa część)
<lista kontroli wymaganych przez bezpieczeństwo: dozwolone modele, allowlista
MCP, zarządzane hooki skanujące sekrety, eksport telemetrii, limity uprawnień>

## Poziomy usług
Zob. tabelę poziomów usług; publikowane pod <URL>, raport co miesiąc.

## Wkład z zespołów
Każdy inżynier może zaproponować skill, hook lub serwer MCP pull requestem do
<repozytorium marketplace'u> razem z przypadkami ewaluacji. Odpowiadamy w <N> dni roboczych.

## Wyjątki
Zespół może zrezygnować z dowolnego elementu utwardzonej ścieżki, wpisując to do
<pliku wyjątków> z właścicielem i datą wygaśnięcia (maks. 90 dni).

## Przegląd
Co kwartał z CTO i dwoma tech leadami zespołów produktowych. Podpis: <CTO>.

Co powinno trafić do backlogu platformy?

Oto dziewięć produktów harnessu w kolejności, w jakiej potrzebuje ich większość organizacji. Kolumna „gotowe, gdy” to test akceptacyjny każdego z nich: bez tego dowodu pozycja nie jest skończona.

#	Produkt harnessu	Co dostarcza zespół	Gotowe, gdy
1	Minimum polityki	Ustawienia zarządzane (Claude Code), requirements.toml (Codex), ustawienia administracyjne zespołu (Cursor) z kontrolami wymaganymi przez bezpieczeństwo	Maszyna testowa z własną konfiguracją programisty nadal dostaje minimum; serwer MCP spoza listy zostaje odrzucony
2	Telemetria i koszty	Eksport OpenTelemetry z każdego klienta do twojego kolektora; dashboard na zespół	Koszt i sesje każdego zespołu widać w ciągu doby, bez dopytywania programistów
3	Kanały wersji	Przypięty kanał klienta i dozwolone modele, proces awansu między nimi	Nowy model albo klient trafia do wszystkich dopiero po przejściu zestawu ewaluacji
4	Ewaluacje harnessu	Złote zadania z własnych repozytoriów, oceniacze, zadanie w CI	Każdy pull request do harnessu pokazuje wynik względem bieżącego wydania
5	Plugin utwardzonej ścieżki	Jeden marketplace ze wspólnymi skillami, hookami i subagentami, wersjonowane wydania	Co najmniej dwa zespoły używają go bez przymusu, a jego koszt kontekstu jest opublikowany
6	Katalog MCP	Sprawdzone serwery z zawężonymi poświadczeniami per agent i formularzem zgłoszeń	Zgłoszenie nowego serwera dostaje odpowiedź w ramach poziomu usług, z zapisaną decyzją bezpieczeństwa
7	Środowiska agentów	Obrazy dev container, wspólne środowiska w chmurze lub własne, z allowlistą sieci	Agent startuje w czystym środowisku, które buduje i testuje repozytorium bez ręcznej konfiguracji
8	Onboarding	Ścieżka pierwszego tygodnia, zadania startowe, prompty działające w twojej bazie kodu	Nowy inżynier dowozi pierwszą przyjętą zmianę agenta w docelowym czasie
9	Ścieżka wkładu	Szablony, przykładowe przypadki ewaluacji, dyżur recenzentów	Większość nowych skilli pochodzi od zespołów produktowych, nie od zespołu platformowego

Tożsamości i poświadczeń agentów celowo nie ma na tej liście. Zespół platformowy wykonuje pracę, ale rozliczalne jest bezpieczeństwo; procedurę opisuje strona tożsamość agentów, poświadczenia i sekrety.

W jakiej kolejności nowy zespół platformowy powinien to budować?

1. Tygodnie 1–3: minimum polityki i telemetria. Dostarcz je razem: bez telemetrii nie ocenisz, czy cokolwiek późniejszego jest używane, a bez minimum bezpieczeństwo nie pozwoli niczego poszerzyć.

2. Tygodnie 3–6: kanały wersji i zestaw ewaluacji. Zbierz 20–40 złotych zadań z rzeczywistej, scalonej pracy w dwóch lub trzech repozytoriach, każde z oceniaczem (zwykle z testami samego repozytorium). Uruchom je na bieżącym kliencie i modelu, żeby ustalić punkt odniesienia. Ten zakres to robocza liczba tego przewodnika, a nie opublikowany benchmark.

3. Tygodnie 6–10: plugin utwardzonej ścieżki. Zacznij od dwóch lub trzech skilli, które zespoły już kopiują między repozytoriami; istniejący nawyk przyjmuje się szybciej niż nowy pomysł.

4. Tygodnie 8–12: katalog MCP i środowiska. Najpierw sprawdź serwery, które zespoły już uruchamiają na prywatnych tokenach; każdy z nich jest dziś ryzykiem związanym z poświadczeniami.

5. Od 12. tygodnia: onboarding i ścieżka wkładu. Opublikuj pierwszy raport poziomów usług i zaproś zespoły do współtworzenia.

Jak backlog przekłada się na Claude Code, Codeksa i Cursora

Backlog jest niezależny od narzędzia, konfiguracja już nie. Sekcja team/ każdego narzędzia opisuje jego wdrożenie szczegółowo: Claude Code dla zespołów, Codex dla zespołów i Cursor dla zespołów. Porównanie polityk obok siebie znajdziesz w artykule jedna polityka dla wszystkich agentów kodujących.

Claude Code

Minimum polityki, kanały i telemetria żyją w ustawieniach zarządzanych, dostarczanych jako managed-settings.json, przez MDM albo jako ustawienia zarządzane z serwera w konsoli claude.ai (Team i Enterprise). Ustawienia zarządzane mają pierwszeństwo przed każdym innym poziomem.

{
  "autoUpdatesChannel": "stable",
  "availableModels": ["opus", "sonnet"],
  "enforceAvailableModels": true,
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "extraKnownMarketplaces": {
    "acme-plugins": { "source": { "source": "github", "repo": "acme/acme-plugins" } }
  },
  "enabledPlugins": { "acme-harness@acme-plugins": true },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://otel-collector.acme.internal:4317"
  }
}

acme/acme-plugins to repozytorium marketplace’u zespołu platformowego, a acme-harness jego plugin. Zmienne telemetrii umieść w ustawieniach zarządzanych albo użytkownika. Od v2.1.282 (kanał latest) Claude Code ignoruje zmienne eksportu telemetrii w bloku env projektowego .claude/settings.json; na stable 2.1.274 plik projektu nadal może je ustawić, więc tylko ustawień zarządzanych repozytorium nie nadpisze na żadnym z kanałów. Metryki obejmują claude_code.cost.usage, claude_code.token.usage i claude_code.session.count.

Kanały: przypnij stable (2.1.274 w dniu 2026-09-26; latest miał 2.1.283), a latest włączaj tylko grupie kanarkowej.

Środowiska: środowiska self-hosted (beta dla Team i Enterprise, claude --environment ccpool_…) czytają ustawienia zarządzane z serwera oraz — jeśli jest jednym ze stosowanych źródeł zarządzanych — plik ustawień zarządzanych z obrazu runnera. Na maszynie wirtualnej zarządzanej przez Anthropic obowiązują tylko ustawienia zarządzane z serwera, a pluginy włączone przez repozytorium nie są instalowane. Zobacz też konfigurację dev containera i przewodnik po bramce LLM.

Koszt kontekstu: claude plugin details acme-harness wypisuje inwentarz komponentów pluginu i przewidywany koszt w tokenach. Publikuj tę liczbę z każdym wydaniem.

Codex

Minimum polityki żyje w requirements.toml, który zawiera ograniczenia egzekwowane przez administratora; config.toml trzyma wartości domyślne. Klucze z ConfigRequirementsToml w config_requirements.rs (openai/codex rust-v0.157.1, sprawdzone 2026-09-26): allowed_approval_policies, allowed_sandbox_modes, allowed_permission_profiles, default_permissions, allow_managed_hooks_only, hooks (hooki zarządzane), mcp_servers, plugins, marketplaces i enforce_residency. allow_managed_hooks_only nie działa w config.toml; to klucz wyłącznie dla requirements.toml.

Plugin utwardzonej ścieżki: zespoły dodają marketplace platformy przypięty do tagu wydania.

# Terminal, na maszynie programisty lub w obrazie środowiska
codex plugin marketplace add acme/acme-plugins --ref v1.4.0

Telemetria: tabela [otel] w config.toml eksportuje logi, ślady i metryki (nazwy pól z OtelConfigToml w kodzie źródłowym 0.157.1).

[otel]
environment = "prod"
log_user_prompt = false
exporter = { otlp-http = { endpoint = "https://otel.acme.internal/v1/logs", protocol = "binary" } }

Zostaw log_user_prompt = false, chyba że przegląd prywatności pozwala inaczej; prompty niosą kod źródłowy i dane klientów.

Środowiska: Codex Cloud uruchamia zadania zdalnie; codex cloud (eksperymentalny w 0.157.1) przegląda te zadania i stosuje ich zmiany lokalnie. Konfigurację zarządczą i administracyjną opisuje zarządzanie Codeksem w firmie.

Cursor

Plugin utwardzonej ścieżki: Cursor Plugins „package rules, skills, agents, commands, MCP servers, and hooks” (dokumentacja Cursora, sprawdzone 2026-08-28), więc tę samą zawartość marketplace’u można wydać jako plugin Cursora obok pluginów Claude Code i Codeksa. Skille są zgodne ze standardem Agent Skills, dzięki czemu jeden SKILL.md działa we wszystkich trzech narzędziach.

Środowiska: Cloud Agents „run in isolated VMs in the cloud with full development environments”, a Builds „prepare your Cloud Agent environment in the background” (dokumentacja Cursora, sprawdzone 2026-08-28). Wersjonuj definicję środowiska Cloud Agent jak obraz kontenera.

Ewaluacje: Cursor SDK (@cursor/sdk 1.0.32 w npm, 2026-09-22) wywołuje agenta Cursora z kodu, więc ten sam runner złotych zadań może sterować Cursorem.

Minimum polityki: zanim oprzesz się na ustawieniach administracyjnych zespołu w Cursorze, sprawdź je w aktualnej dokumentacji; zacznij od prywatności i bezpieczeństwa w Cursorze.

Jak udowodnić, że wydanie harnessu nie pogarsza pracy agentów?

Każda zmiana harnessu (edycja skilla, hook, klucz polityki, wersja klienta czy model) zmienia zachowanie każdego agenta, więc przed wydaniem przechodzi przez zestaw ewaluacji. Zespół platformowy podpisuje wynik ewaluacji, a nie lekturę diffa.

Zestaw ma trzy warstwy:

• Złote zadania z twojej scalonej pracy, każde z deterministycznym oceniaczem: testami repozytorium, sprawdzeniem typów, bramką lintera albo funkcją dopasowania (fitness function). One decydują o wydaniu.
• Sprawdzenia oceniane przez model tam, gdzie testy nie sięgają, np. czy skill do code review znalazł podrzucony defekt. Informują o decyzji, a człowiek sprawdza ich próbkę.
• Telemetria kanarkowa po wydaniu: koszt na sesję i prośby o wycofanie z grupy kanarkowej.

Claude Code

claude plugin eval uruchamia przypadki ewaluacji pluginu (evals/**/case.yaml albo prompt.md z graders/*.md), a gdy plugin daje się rozwiązać, dodaje ramię bazowe bez pluginu, więc widzisz różnicę, jaką plugin wnosi. W CI:

# Zadanie CI przy każdym pull requeście do repozytorium marketplace'u
claude plugin eval ./plugins/acme-harness \
  --trust-plugin --runs 3 --threshold 0.8 \
  --max-cost-usd 25 --no-publish --json eval-results.json

--threshold kończy się kodem 1, jeśli którykolwiek przypadek wypadnie poniżej progu; --max-cost-usd przerywa bieg przy limicie i zwraca częściowe wyniki (kod 2). --trust-plugin wykonuje kod pluginu z uprawnieniami użytkownika joba (tekst pomocy porównuje go do --dangerously-skip-permissions), więc uruchamiaj ten job tylko dla gałęzi w repozytorium marketplace’u, nigdy dla forków, na jednorazowym runnerze, którego jedynym sekretem jest klucz ewaluacyjny z limitem wydatków. Oceniacz LLM domyślnie używa Haiku; zmienisz go przez --judge-model. Wszystkie flagi sprawdzone w Claude Code 2.1.283.

Codex

Codex 0.157.1 nie ma polecenia do ewaluacji pluginów, więc każde złote zadanie przepuść przez codex exec, a wynik oceń sprawdzeniami samego repozytorium:

# Zadanie CI: jedno złote zadanie, w świeżym checkoucie commita bazowego
codex -a never exec --ephemeral \
  -c default_permissions=":workspace" \
  --output-schema evals/schema/result.json \
  -o out/flaky-retry.json \
  "$(cat evals/cases/flaky-retry/prompt.md)"
npm test -- --run tests/retry.test.ts   # oceniacz

--output-schema sprawia, że końcowa wiadomość nadaje się do odczytu maszynowego; --ephemeral nie zapisuje plików sesji na dysku. Uruchom ten sam zestaw przypadków na bieżącym i kandydackim harnessie i porównaj odsetek zaliczonych.

Cursor

Ten sam zestaw złotych zadań przepuść przez Cursor SDK (@cursor/sdk) i oceń testami repozytorium. Trzymaj przypadki i oceniacze w repozytorium marketplace’u, żeby jeden zestaw oceniał wszystkie trzy narzędzia.

Reguła decyzyjna. Wpisz ją do karty przed pierwszym wydaniem: wydanie harnessu wchodzi, gdy odsetek zaliczonych złotych zadań nie spadł względem bieżącego wydania w żadnym repozytorium z zestawu, a koszt na zaliczone zadanie nie wzrósł ponad uzgodniony margines. Podpisuje lider zespołu platformowego; bezpieczeństwo współpodpisuje wszystko, co dotyka minimum polityki. Metody budowy zestawu opisują ewaluacje agentów kodujących i sprawdzenia oceniane przez model.

Zestaw ewaluacji, który nigdy nie odrzuca, nie jest bramką

Jeśli każde wydanie harnessu przechodzi, zestaw jest za łatwy, dostrojony do bieżącego harnessu albo zbudowany z kodu, którego już nie ma. Co kwartał odśwież jedną czwartą przypadków na podstawie świeżo scalonej pracy, podrzuć znaną regresję (skill, który pomija testy, hook, który przepuszcza sekret) i sprawdź, czy zestaw ją wyłapie.

Jakie poziomy usług zespół platformowy powinien obiecać zespołom produktowym?

Poziomy usług zamieniają „zespół platformowy jest wolny” w liczbę. Opublikuj je, raportuj co miesiąc i pozwól zespołom produktowym eskalować naruszenie do CTO. Wartości to punkty startowe tego przewodnika, a nie branżowy benchmark; skoryguj je po pierwszym miesiącu danych.

Usługa	Jak mierzona	Cel startowy
Zgłoszenie do harnessu (nowy skill, serwer MCP, zmiana polityki)	Czas od zgłoszenia do decyzji: tak, nie albo termin	3 dni robocze
Recenzja wkładu	Czas od pull requestu zespołu produktowego do marketplace’u do scalenia lub konkretnej informacji zwrotnej	2 dni robocze
Zepsuty wspólny hook lub skill	Czas od pierwszego zgłoszenia do wycofania na każdej maszynie	4 godziny
Unieważnienie tożsamości agenta (z bezpieczeństwem)	Czas od zgłoszenia incydentu do unieważnienia poświadczenia	15 minut
Nowa wersja klienta lub modelu	Czas od wydania u dostawcy do decyzji „oceniony, awansowany lub wstrzymany”	5 dni roboczych
Obraz środowiska	Odsetek sesji agentów startujących w czystym, budującym się środowisku	95%

Ćwicz wiersze o wycofaniu i unieważnieniu: raz na kwartał zepsuj hook na gałęzi kanarkowej i zmierz, ile trwa dotarcie poprawki do każdego programisty; mechanikę wydań opisuje zarządzanie wspólnymi hookami.

Jak nie dopuścić, by zespół platformowy stał się bramką?

Zespół platformowy staje się bramką w chwili, gdy zespoły produktowe czekają na niego, żeby dowieźć pracę produktową. Zapobiega temu pięć sprawdzalnych zasad.

1. Oddziel minimum polityki od utwardzonej ścieżki. Obowiązkowe jest tylko minimum, a za jego treść odpowiada bezpieczeństwo. Wszystko inne to oferta; jeśli skill trzeba narzucić, nie jest jeszcze wystarczająco dobry.

2. Nigdy nie stawaj na ścieżce code review produktu. Zespołu platformowego nie ma w CODEOWNERS repozytoriów produktowych ani w ochronie gałęzi. Recenzuje wyłącznie zmiany harnessu. Code review zmian produktowych opisuje kolejka code review.

3. Przyjmuj wkład z przypadkami ewaluacji, a nie prośby o zgodę. Zespół, który chce nowego skilla, otwiera pull request do marketplace’u ze skillem i dwoma lub trzema przypadkami ewaluacji, a zespół platformowy ocenia go na podstawie wyniku ewaluacji w ramach poziomu usług.

4. Dopuszczaj wyjątki z datą wygaśnięcia. Zespół może zastąpić skill lub hook z utwardzonej ścieżki własnym, jeśli zapisze właściciela i datę wygaśnięcia. Każdy wyjątek to luka w produkcie i pozycja w backlogu platformy.

5. Publikuj kolejkę. Wiek zgłoszeń, czas recenzji wkładu i otwarte wyjątki stoją obok poziomów usług. Widoczną kolejkę ktoś naprawia.

Polityka zarządzana nie odróżnia minimum od utwardzonej ścieżki

Ustawienia zarządzane i requirements.toml egzekwują wszystko, co w nich umieścisz. Jeśli plugin utwardzonej ścieżki jest włączany przymusowo przez politykę zarządzaną, z definicji należy do minimum i zespoły nie mogą z niego zrezygnować. Trzymaj zestaw przymusowo włączanych elementów mały i co kwartał przeglądaj go z bezpieczeństwem.

Jak mierzyć zespół platformowy agentów jak produkt?

Mierz to, co zmienia się dla zespołów produktowych, a nie to, co produkuje zespół platformowy: liczba wydanych skilli to wynik pracy, tych pięć metryk to efekty. Kanoniczne definicje metryk dla całej organizacji zawiera strona frameworki metryk.

Metryka	Definicja	Dlaczego ma znaczenie
Dobrowolna adopcja	Odsetek aktywnych sesji agentów, które wczytują plugin utwardzonej ścieżki tam, gdzie nie jest włączany przymusowo	Jedyny uczciwy sygnał, że utwardzona ścieżka jest lepsza od alternatyw
Czas do pierwszej przyjętej zmiany agenta	Dni od pierwszej sesji nowego inżyniera do jego pierwszej scalonej zmiany napisanej przez agenta, która przeszła wszystkie bramki	Mierzy łącznie onboarding i środowiska
Wskaźnik forków	Liczba wspólnych skilli lub hooków skopiowanych do repozytoriów produktowych i zmodyfikowanych	Każdy fork to brakująca funkcja albo niedotrzymany poziom usług
Incydenty wywołane przez harness	Incydenty, których postmortem wskazuje wspólny skill, hook, politykę lub środowisko	Jakość wydań samej platformy
Koszt na przyjętą zmianę	Wydatki na agentów podzielone przez scalone zmiany napisane przez agentów, które przeszły wszystkie bramki, per zespół	Łączy telemetrię z efektami; zob. zarządzanie kosztami

Raportuj je per zespół, nigdy per osoba. Telemetria, która rankinguje ludzi, staje się celem w ocenach pracy, a potem inwigilacją; jak trzymać ją z dala od ocen, opisuje strona ścieżki kariery i oceny pracy.

Prompty do skopiowania dla zespołu platformowego agentów

Uruchom je w Claude Code, Codeksie lub Cursorze. Działają tak samo we wszystkich trzech narzędziach.

Prompt do skopiowania: znajdź kandydatów do utwardzonej ścieżki w repozytoriach

Read-only task. Do not edit, commit or install anything.
The directories under ./repos are clones of our product repositories.
Find every agent artifact in them: CLAUDE.md and AGENTS.md files, .claude/skills,
.claude/agents, hooks in .claude/settings.json, .codex/ and .agents/ directories,
.cursor/ (rules, hooks, mcp.json) and .mcp.json.
Group artifacts that do the same job even when names differ (for example three
"review" skills). For each group output: the job it does, the repositories that
have it, how the copies differ, and whether any copy has tests or eval cases.
Rank the groups by the number of repositories that carry a copy. The top three
are candidates for the shared plugin; for each, draft the SKILL.md description
line that would make an agent pick it.

Prompt do skopiowania: zamień scaloną pracę w złote zadania ewaluacji

Read-only task. Look at the last 60 merged pull requests in this repository
(git log --merges --first-parent). Pick 10 that an agent could plausibly do:
a clear description, a change under 300 lines, and tests that changed or
failed before the fix. For each, write an eval case with: a task prompt written
the way an engineer would ask for it (no hints from the final diff), the base
commit to start from, the grader command that must pass (a specific test file
or check, not the whole suite), and what a wrong but plausible solution would
look like. Output them as YAML. Exclude any PR that touches secrets,
migrations on production data, or auth.

Prompt do skopiowania: zrecenzuj wkład do harnessu przed scaleniem

You are reviewing a pull request to our shared agent marketplace repository.
Read the diff and the eval results in eval-results.json.
Answer, with file and line references:
1. Does any skill, hook or subagent widen what an agent can reach (new tools,
   network hosts, file paths, MCP servers, credentials)? List each widening.
2. Do the new eval cases fail without the change? If a case would pass with the
   plugin disabled, say so: it tests nothing.
3. Does any hook fail open on error (exit 0 when its check crashes)?
4. How many tokens do the new skill descriptions add to every session?
Recommend merge, merge after changes, or reject, with one sentence of reason.

Co psuje się w zespole platformowym agentów i jak to naprawić

Zespół platformowy staje się bramką code review. Pull requesty produktowe czekają na zgodę platformy, bo „to oni odpowiadają za agentów”. Naprawa: usuń zespół platformowy z CODEOWNERS repozytoriów produktowych, przypomnij listę „czego nie robimy” i zamień ręczne sprawdzenie w hook albo przypadek ewaluacji.

Nikt nie korzysta z utwardzonej ścieżki. Zespół zbudował to, co jego zdaniem było potrzebne. Naprawa: uruchom pierwszy prompt powyżej, przebuduj plugin wokół trzech najczęściej kopiowanych skilli i przez miesiąc mierz dobrowolną adopcję, zanim zbudujesz coś więcej.

Zmiana minimum polityki psuje pracę zespołów bez ostrzeżenia. Aktualizacja allowlisty odrzuca serwer MCP, od którego zależą dwa zespoły. Naprawa: wycofaj zmianę tym samym kanałem, dodaj grupę kanarkową, która dostaje zmiany minimum tydzień wcześniej, i zapowiadaj je z datą.

Plugin zjada okno kontekstu. Ulubiony skill każdego zespołu trafił do wspólnego pluginu i każda sesja zaczyna się od tysięcy tokenów opisów. Naprawa: publikuj przewidywany koszt w tokenach przy każdym wydaniu (claude plugin details w Claude Code), ustal budżet i wydziel rzadko używane skille do opcjonalnego pluginu.

Aktualizacja modelu lub klienta wchodzi przed ewaluacjami. Nowa wartość domyślna przychodzi z automatyczną aktualizacją i zachowanie agentów w całej organizacji zmienia się z dnia na dzień. Naprawa: przypnij kanał i dozwolone modele w polityce zarządzanej, a poziom usług dla kanałów wersji uczyń jedyną drogą awansu. Aktualne wartości domyślne są w hubie modeli.

Telemetria zamienia się w ranking. Ktoś eksportuje liczbę tokenów per osoba do oceny pracy. Naprawa: agreguj dane do poziomu zespołu w kolektorze, ogranicz dostęp do surowych danych do zespołu platformowego i bezpieczeństwa, a to ograniczenie wpisz do karty.

Dokąd dalej z zespołem platformowym agentów

Na ścieżce CTO ta strona następuje po polityce zarządzanej, która definiuje minimum polityki, i prowadzi do zarządzania kosztami, które nakłada budżety na zbieraną teraz telemetrię.

Model operacyjny RACI, na którym opiera się ten zespół: kto odpowiada za każdy artefakt harnessu.

Zespołowy marketplace pluginów Dystrybucja, wersjonowanie i wycofywanie pluginu utwardzonej ścieżki.

Rejestry i bramki MCP Jak prowadzić katalog MCP z allowlistą i zawężonymi poświadczeniami.

Efemeryczne środowiska dla agentów Czyste, jednorazowe środowiska, które budują i testują przy każdym biegu.

Telemetria agentów Kolektory, dashboardy i metryki eksportowane przez każdego agenta kodującego.

Wspólne skille Jak testować i wersjonować skille publikowane przez zespół platformowy.