Olivia
Online
Maksymilian
@MAXIMISEART
AI Engineer | Pomagam wdrażać AI do polskich firm | Propagator myślenia :)
Greater Poland, Poland
Joined April 2026
91 Following
2.1K Followers
144 Posts
Czym jest agentic AI framework? Jaki wybrać? I po co one w ogóle istnieją?
Możemy sobie to wyobrazić jako zestaw gotowych klocków, z których budujemy bardziej skomplikowane systemy, które planują, wykonują określone działania i iterują aż do momentu osiągnięcia celu. Nie są tylko statycznymi chatbotami. Frameworki te pomagają również w integracji, monitoringu, zarządzaniu zadaniami oraz komunikacji między agentami.
Podzielmy sobie te frameworki na 5 typów systemów:
1. Liniowe workflow – systemy, gdzie akcja dzieje się krok po kroku, kolejne etapy zachodzą w ustalonej kolejności i są zależne od siebie.
2. Autonomiczne systemy agentowe – systemy, w których kilka agentów samodzielnie współpracuje, żeby osiągnąć postawiony cel.
3. Systemy na bazie roli – systemy wieloagentowe, gdzie mamy jasno przypisane role, np. agent od deep researchu, agent od pisania, kolejny od edytowania itd.
4. Orkiestracja w produkcji – systemy do wdrożeń produkcyjnych, mocno zintegrowane z API, bazami danych oraz procesami biznesowymi.
5. Prototypowanie – systemy do szybkiego testowania pomysłów i budowania prototypów, bez potrzeby pełnej architektury.
W praktyce wybór danego frameworka powinien raczej wynikać z architektury problemu niż z samej popularności danego narzędzia. Jeśli więc potrzebujesz stabilności i kontroli, skorzystaj z prostych liniowych workflow. Jeśli natomiast potrzebujesz większej eksploracji i współpracy między kilkoma agentami, wybierz architekturę multi-agent.
Tak samo ma się to z etapem danego projektu – czy jesteśmy na poziomie wchodzenia na produkcję, czy też dopiero sprawdzamy nasze pomysły.
Tutaj wypiszę przykładowe narzędzia do danego typu systemu:
1. Liniowe workflow: LangChain, LlamaIndex, LangGraph.
2. Autonomiczne systemy agentowe: AutoGen, CrewAI, BabyAGI.
3. Systemy na bazie roli: CrewAI, AutoGen, ChatDev.
4. Orkiestracja w produkcji: LangGraph, Deep Agents, Eve.
5. Prototypowanie: LangFlow, Flowise.
Wydaje mi się, że takie podejście jest szczególnie ważne w projektach AI, ponieważ pozwala nam uniknąć budowania zbyt skomplikowanych rozwiązań na samym początku.
Dobrze dobrany framework nie tylko przyspiesza pracę, ale też zmniejsza ryzyko, że cały system stanie się trudny do utrzymania.
PRO TIP: Pisz lepsze claude/agent.md
Ten plik .md służy do tego, żeby wprowadzić agenta w twój codebase na początku każdej sesji. Żeby to uprościć, claude/agent.md powinien opisywać trzy rzeczy: CO, DLACZEGO, JAK.
CO
Pokaż swojemu agentowi, z jakiej technologii korzystamy, jaki mamy stack i jaka jest struktura naszego projektu. Powinniśmy dać mu mapę naszego repo. Wyjaśnić, co jest czym i gdzie ma tego szukać.
DLACZEGO
Twój agent nie powinien rozumieć tylko tego, co jest w kodzie, ale też po co to istnieje. Opisz cel projektu oraz funkcje poszczególnych repo.
JAK
Naucz agenta, jak ma pracować z projektem. Jeśli używasz X zamiast Y albo masz konkretne komendy do testów, to właśnie tutaj powinno się to znaleźć. Tutaj powinno być wszystko, co jest potrzebne, aby agent mógł sensownie działać w twoim środowisku.
Mniej znaczy lepiej
Upychanie każdej możliwej komendy i reguły jest bez sensu. Ten plik działa o wiele lepiej, gdy zawiera możliwie mało informacji, ale za to są to rzeczy uniwersalne i przydatne w każdej nowej sesji.
Progressive disclosure
Lepiej rozdzielić wiedzę na osobne pliki z opisowymi nazwami. Plik powinien wskazywać, gdzie agent ma szukać szczegółów, zamiast zawierać je wszystkie od razu w claude/agent.md.
To znacznie ogranicza rozmiar kontekstu i sprawia, że plik pozostaje użyteczny także wtedy, gdy projekt rośnie.
Odwołanie do źródeł
Lepszym sposobem od wklejania fragmentów kodu do dokumentacji jest odsyłanie do konkretnego miejsca w repo. Dzięki temu dokument nie starzeje się aż tak szybko.
Jeżeli ktoś by chciał bardziej się zagłębić to polecam ten artykuł: https://t.co/UcOwrMWEer
"Nie potrzebujemy geniusza do pisania maili."
https://t.co/G9JaXfeI1s
https://t.co/G9JaXfeI1s
Absolute banger
Czy podstawy software engineeringu mają jeszcze jakieś znaczenie?
Czy zawód programisty właściwie już umarł? Czy powinniśmy mieć w dupie kod i skupiać się wyłącznie na rezultatach generowanych przez AI, traktując je jak czarną skrzynkę? Czy powinniśmy trząść portkami na widok tego, co nas czeka?
Nie.
Wydaje mi się, że my jako ludzie mamy trochę wspólnego z agentami, których tak maltretujemy. W większości przypadków człowiek osiąga różne wyniki w zależności od środowiska, w którym się znajduje.
Niektórzy pracują znacznie efektywniej, gdy mają uporządkowane stanowisko, nic im nie zawadza i nic ich nie rozprasza. Inni przywiązują wagę do odpowiedniego oświetlenia, muszą mieć swój fancy aromatyzer i kubek ulubionej kawy obok siebie. Każdy ma swoje preferencje.
Z agentami jest podobnie. Tylko że u nich całym środowiskiem jest kod. To oznacza, że jakość tego środowiska bezpośrednio wpływa na jakość ich pracy. Wnioski nasuwają się więc same - kiepski, chaotyczny codebase będzie zapewniał równie kiepskie rezultaty. Co gorsza, taki stan nie pojawia się nagle tylko narasta stopniowo.
Istnieje takie pojęcie jak entropia oprogramowania. Jeżeli świadomie nie dbasz o strukturę swojego projektu, nie myślisz strategicznie i w longtermie oraz nie stosujesz podstaw software engineeringu, kod z czasem staje się coraz bardziej chaotyczny, trudniejszy w utrzymaniu i rozwijaniu, czyli po prostu staje się slopem.
Co najważniejsze, z tego, co dzisiaj obserwujemy podczas pracy z AI, ludzie radzą sobie w takim środowisku znacznie lepiej niż LLM-y.
Głównie dlatego, że człowiek ma pamięć. Potrafi zapamiętać, co w danym projekcie działa, a co nie. Oczywiście nie jest to system idealny, ale pozwala z czasem wyrobić sobie intuicję dotyczącą tego, jak wygląda słaby codebase, i wiedzieć, czego unikać w przyszłości. Prowizoryczne systemy pamięci dokładane do agentów nie są rozwiązaniem tego problemu (jeszcze).
Jeżeli oglądaliście film „Memento”, można zauważyć tutaj ciekawą analogię. Agent „budzi się” w projekcie i nie pamięta nic. Za każdym razem musi nauczyć się wszystkiego od nowa. W efekcie AI może popełniać te same błędy w kółko, jeśli nie zapewnisz mu odpowiednich ograniczeń, wskazówek i struktury. Dotyczy to praktycznie wszystkich modeli od tych słabszych po te najlepsze.
Sednem problemu nie jest wcale sama zdolność rozumowania modelu. Problem polega na tym, że codebase'y są trudne do eksploracji, modyfikacji i zrozumienia, a to czyni je wymagającym środowiskiem dla AI.
Dlatego uważam, że dzisiaj największą wartość mają osoby, które potrafią tworzyć dobre środowiska pracy dla agentów. Takie, w których czytanie kodu jest łatwe, testy są sensownie napisane i dobrze pokrywają kluczowe scenariusze, a moduły oraz interfejsy zostały zaprojektowane w przemyślany sposób.
Więc podstawy software engineeringu nie tylko nie straciły na wartości, ale są dziś ważniejsze niż kiedykolwiek wcześniej. Jakość codebase'u bezpośrednio przekłada się na jakość pracy AI.
PRO TIP: Wiele harnessów, a zwłaszcza Claude Code, jest domyślnie przeładowanych treścią w swoim system prompcie. W praktyce oznacza to, że tysiące tokenów, z których większość i tak nigdy nie jest wykorzystywana, trafiają do context window na początku każdej sesji.
W wielu przypadkach nie potrzebujemy fragmentów związanych z workflow, planowaniem czy synchronizacją z monitoringiem, ponieważ zwyczajnie z nich nie korzystamy.
Na szczęście Claude pozwala to wszystko dostosować. W pliku ~/.claude/settings.json możemy wyłączyć zbędne elementy i w ten sposób znacząco odchudzić nasz system prompt. Jeżeli ktoś nie korzysta np. z wbudowanego narzędzia "AskUserQuestion", może je bezpiecznie wyłączyć. To samo dotyczy narzędzi do planowania cron tasków, wbudowanych mechanizmów code review, dynamicznych workflowów, zdalnego sterowania czy funkcji artifacts. Wszystkie te elementy zwiększają liczbę tokenów, a jeżeli nie są używane, nie wnoszą żadnej realnej wartości.
Efekt takiego odchudzania może być bardzo odczuwalny. Zredukowanie początkowego kontekstu z kilkudziesięciu tysięcy tokenów do zaledwie kilku tysięcy powinno znacząco poprawić experience z pracy z agentem, a przede wszystkim wydłużyć czas jego pracy w smart zone.
Im mniej, tym lepiej (dlatego Pi jest tak popularne). Agent ma mniej zbędnych rzeczy, które mogłyby go rozpraszać, dzięki czemu może skupić się na tym, co naprawdę ma znaczenie.
Kluczowe zasady context engineeringu przy budowie swoich agentów.
Context Engineering – rzeczy do zapamiętania:
- Danie agentowi dostępu do komputera (file system, shell): To krok, który bardzo ułatwia i tak już trudne zarządzanie kontekstem.
- Bezpieczny sandbox: Jak już agent ma dostęp do komputera, musi operować w jakimś sandboxie, tak aby było to bezpieczne.
- Używanie małej ilości narzędzi: Dawanie agentowi szerokich, atomowych narzędzi (np. glob, grep, read, write, ls) świetnie działa, ponieważ dajemy mu computer use, dzięki któremu może offload'ować akcje. Narzędzia mogą zajmować dużo miejsca, jeśli chodzi o kontekst – przykładowo GitHub MCP ma w sobie 32k tokenów w 32 narzędziach. Poza tym, im więcej narzędzi agent ma pod sobą, tym bardziej narażamy się na context confusion.
- Progressive disclosure narzędzi: Zamiast dawać wszystkie narzędzia bezpośrednio do okna kontekstu, lepiej używać ich on demand za pomocą Tool Search Tool. Można też zastosować podobne podejście: zaindeksować opisy narzędzi, a później robić semantic search, żeby zfetchować poprawne narzędzie do danego zadania.
- Pushowanie akcji do komputera: Pushowanie samego opisu narzędzi do file systemu to jedna rzecz, ale drugą – znacznie ciekawszą – jest pushowanie akcji narzędzia do komputera. To jest właśnie mocna strona dawania agentowi computer use: nawet z niedużą liczbą narzędzi agent może zrobić bardzo dużo.
- Sprytniejsze zarządzanie MCP servers: Zamiast dawać je bezpośrednio dla LLM, możemy zrobić coś sprytniejszego: wrzucić poszczególne narzędzia do file systemu (jako pojedyncze pliki), a potem robić zwykły file search (np. glob, grep czy indeksowanie).
- CLI dla MCP: Jeszcze inną metodą jest po prostu zbudowanie CLI dla MCP.
- Skille jako SOPs: Traktowanie skilli jako SOPs (Standard Operating Procedures) dla agenta do robienia różnych rzeczy w komputerze – np. używanie poszczególnych CLI czy pisanie kodu dla danego zadania.
- Offload'owanie rezultatów narzędzi do file systemu: Dawanie agentowi tylko pointerów lub summary od danego narzędzia, a jeżeli chciałby przeczytać cały plik może go zawsze zfetchować z file systemu. Wyniki narzędzi mogą być bardzo ciężkie tokenowo. Bez tego mechanizmu mogą zostać wrzucone w historię czatu, akumulować się z czasem i być wysyłane przy każdej turze (czego przecież nie chcemy).
- Scratchpad concept: Kolejne, bardzo podobne rozwiązanie, to offload'owanie planów jako scratchpad.
- Cache'owanie kontekstu (KV cache): Bardzo ważne, jeśli chodzi o produkcję. To ogromny lewar pod kątem szybkości i kosztów.
- Izolacja kontekstu poprzez subagentów: Subagenci nie są po to, żeby mieli swoje osobne role i nagle zajmowały się kompletnie innym zadaniem, tylko po to, żeby zwiększyć okno kontekstu swojego „rodzica”. Klasycznym przykładem izolowania kontekstu w ten sposób jest deep research.
- Loops dla long-running agentów: Tutaj można by się długo rozpisywać, ale podstawowym przykładem jest posiadanie planu w formie pliku (gdzie znajdują się todo tasks), file systemu oraz pliku progress.md jako scratchpad. Gdy odpalamy nasz loop:
1. Pierwszy agent zaczyna pracę nad jednym punktem z planu.
2. Kiedy kończy pracę, commituje wszystko do file systemu, a na koniec aktualizuje nasz plik progress.md (jeden agent = jedno okno kontekstu).
3. Następnie spawn'owany jest drugi agent, który czyta historię Gia oraz progress.md, robi refleksję nad planem, a potem bierze się za swoje zadanie.
4. Proces powtarza się w kółko, aż cały plan zostanie wykonany.
- Reflektowanie agenta na podstawie przeszłych sesji: Pisałem o tym więcej w osobnym poście tutaj: https://t.co/zkT8np8cE9
To są według mnie najważniejsze rzeczy, o których trzeba myśleć, jeżeli mówimy o context engineeringu.
Jeżeli ktoś chciałby coś dodać, to śmiało chętnie poczytam
@igorzakrzewski Jasne, zgadzam się!
10 lekcji z kodowania z AI
1. Wdrażaj, żeby się uczyć
Można zajść całkiem daleko, stosując SDD (Spec-Driven Development), ale to dopiero pisanie kodu ujawnia decyzje, których na początku nie brałeś pod uwagę, i sprawia, że sama specyfikacja staje się lepsza. Skoro więc PISANIE kodu jest tanie, warto implementować po to, aby się uczyć.
2. Często buduj od nowa
Aby zdobywać nowe doświadczenie, implementuj wcześnie i regularnie. Forkuj projekty i twórz nawet najbardziej szalone eksperymenty. Sprawdzaj, jak daleko można rozwinąć dany pomysł lub funkcjonalność. Oczywiście nie zapominaj o iterowaniu i rozwijaniu dotychczasowej pracy, ale skoro mamy dziś takie możliwości, eksperymentuj i odkrywaj nowe rozwiązania, o których wcześniej nawet nie myślałeś albo które były praktycznie niemożliwe do zrealizowania.
3. Inwestuj w testy
Powinniśmy poświęcać więcej czasu na tworzenie testów, które sprawdzają, co produkt robi, a nie tylko jak to robi. Potrzebujemy możliwości swobodnego przebudowywania i ponownego implementowania aplikacji bez obawy o zmianę jej zachowania.
4. Dokumentuj intencje
Testy opisują cele, kod odzwierciedla sposób realizacji, ale ani jedno, ani drugie nie odpowiada na pytanie, dlaczego podjęto daną decyzję. Intencja jest motywacją stojącą za architekturą i implementacją. Posiadanie jej obok kodu pomaga zarówno tobie, jak i agentowi konsekwentnie rozwijać projekt w tym samym kierunku.
5. Utrzymuj specyfikację świeżą
Regularnie aktualizuj spec (pliki .md zawierające cele i plan projektu) wraz z rozwojem kodu i testów. Jeżeli specyfikacja staje się dokumentem statycznym i zamrożonym, cała wiedza zdobyta podczas implementacji idzie w błoto. Aktualna specyfikacja wspiera zarówno ciebie, jak i agentów w podejmowaniu trafnych decyzji oraz bardzo ułatwia częste przebudowy projektu (w przyszłości napiszę o tym więcej).
6. Szukaj rzeczy trudnych
Pracując długo nad danym projektem, dojdziesz do momentu, w którym skończą ci się proste zadania. Po uporaniu się z oczywistymi problemami pozostaną wyzwania takie jak: intuicyjny UX, wydajność, bezpieczeństwo, odporność czy architektura.
Dzisiaj te łatwe rzeczy jest w stanie zrobić prawie każdy. Prawdziwa wartość tkwi więc w rzeczach trudnych. Znajdź je i właśnie tam poświęć swój czas oraz energię.
7. Automatyzuj wszystko co łatwe
Logicznie myśląc, jeżeli chcesz poświęcać więcej czasu na rzeczy trudne, musisz ograniczyć czas spędzany na prostych czynnościach. Zamieniaj zdobyte doświadczenie w gotowe skille i workflowy, buduj pętle, automatyzuj tę żmudną część code review i pozwól swoim narzędziom pracować za ciebie.
Trzeba tylko uważać, żeby nie utknąć w środowisku pełnym automatyzacji, których działania sam przestajesz rozumieć.
8. Rozwijaj swój gust inżyniera
W sytuacji, gdy kod powstaje błyskawicznie, a wartościowy feedback pojawia się znacznie później, jedynym źródłem informacji, które nadąża za tym tempem pracy, jest twój własny osąd. Im lepiej rozumiesz swoją domenę, użytkowników i ich problemy, tym dalej możesz dojść bez konieczności weryfikowania każdej decyzji.
9. Agenci wzmacniają doświadczenie
Kodując z AI, często nie zdajemy sobie sprawy, ile intuicji przekazujemy swoim agentom już w samych promptach: właściwe słownictwo, odpowiedni kontekst czy odpowiedni poziom szczegółowości.
Jeżeli dobrze znasz swój stack, możesz zaoszczędzić ogromną liczbę iteracji zarówno podczas implementacji, jak i debugowania, ograniczając jednocześnie eksplorowanie różnych rozwiązań przez agenta.
10. Utrzymanie, wsparcie i bezpieczeństwo kodu nie jest tanie
Tak, pisanie kodu jest tanie. Jednak wszystko wokół niego, a często nawet ważniejsze od samego pisania, czyli wsparcie, utrzymanie i bezpieczeństwo, nadal wymagają czasu, pieniędzy i odpowiedzialności. Zawsze miej świadomość tych kosztów podczas budowania.
Jeżeli macie jakieś swoje lekcje których tu nie wypisałem to chętnie je poznam i poczytam.
Tak, zgadzam się i rozumiem. Sprzedaje się rozwiązanie problemu, a nie sam produkt. Tak jak nie sprzedaje się lotu, tylko wakacje.
Powtarzając jednak założenie, na którym bazuje ta teza: jeżeli rozwiązaniem problemu jest nasz produkt, a produkt zależy od kodu, to ten kod musi być dobry. Nie mówie ze będzie i musi być we wszystkim idealny, ale nie może być slopem.
To, że przed erą AI również było dużo slopu, nie jest wymówką, żeby teraz tworzyć go jeszcze więcej i jeszcze szybciej.
Jeżeli chodzi o programistów, którzy nie są wymiataczami, to jestem tego świadomy. Ale to również nie jest żadna wymówka. Wydaje mi się, że w naszym własnym interesie leży to, żeby stawać się coraz lepszymi i stale się rozwijać, a nie zadowalać się byciem średniakiem.
Nie zgadzam się ze stwierdzeniem, że kod staniał albo że jest najtańszy, odkąd istnieje. Uważam, że kod nigdy nie był droższy niż teraz.
Samo pisanie kodu rzeczywiście stało się tańsze, ale jego prawdziwa cena nie leży w procesie tworzenia. Leży w utrzymaniu, czytelności oraz w tym, jaki wpływ kod ma na działające w nim AI.
Wszyscy, którzy nadal myślą, że kod jest tani, tak naprawdę budują zwykły slop w swoich codebase'ach. Coraz bardziej odczuwalne jest to, że dobra architektura i dbanie o jakość nie są kosztem, tylko najtańszą inwestycją w tej nowej erze.
Lepszy kod = lepszy output.
Dużo firm i startupów tworzy wertykalnych agentów, co w praktyce jest niczym innym jak budowaniem harnessu pod wąskie zadanie w konkretnej domenie. Przykładem może być np. https://t.co/GiqYgLIqi7.
Istnieje również wiele frameworków, na których takie firmy budują swoje rozwiązania, np. LangChain/LangGraph czy deepagents. Kolejnym przykładem jest OpenClaw, który został zbudowany na PI.
Dobrym podejściem jest tzw. sandwich funnel:
harness engineering → finetuning → harness engineering.
Jeżeli chodzi o sam finetuning, to oczywiście trzeba wiedzieć, jak go przeprowadzić, ale nie należy on do najtrudniejszych zadań. Kluczowe jest dobranie odpowiedniej metody, np. LoRA, QLoRA itd.
Przykładem dobrze przeprowadzonego finetuningu jest artykuł od LangChaina: https://t.co/naQLWdbxSQ
https://t.co/FSIIbWehpa
@futurologiae Tak, o kontekście też trochę pisałem.
pozdro
1/6 Jak sprawić, by agenci AI byli naprawdę niezawodni i radzili sobie z trudnymi zadaniami w realnym świecie? Sam mocny model nie wystarczy. Wszystko rozbija się o architekturę, jaką wokół niego zbudujemy. Ostatnio głośno jest o pojęciu loop engineering i dlatego w tej nitce chcę prosto wytłumaczyć, o co w tym chodzi. Krótko mówiąc ta metoda polega na sprytnym układaniu w stosy konkretnych pętli operacyjnych. Dzięki temu zwykłe, statyczne modele LLM zamieniają się w samodzielne systemy, które potrafią dążyć do celu i same poprawiać własne działanie. Przejdźmy krok po kroku przez cztery poziomy takich struktur.
Założenie jest takie że fundamentem produktu jest kod, inaczej mówienie w ogóle o kodzie nie ma sensu. Jeżeli kod jest slopem i na nim opiera się produkt to produkt tez jest gównem i wtedy nie ma żadnej wartości biznesowej.
zły kod --> gówniany produkty --> zero wartości --> biznes umiera
Tak to widzę.
Nie wiem, czy dobrze rozumiem, ale jeżeli X = A, a my chcemy, żeby model traktował X = B, to trzeba dostarczać mu tę informację do kontekstu w każdej sesji.
Czyli np. w swoim agent.md lub claude.md napisać, że X = B. Model na początku każdej sesji odczytuje ten plik, więc od razu ma tę informację w swoim kontekście.
Żeby jej później nie zgubił, po prostu nie zapełniamy okna kontekstu pod korek. Zamiast tego korzystamy z najlepszych praktyk context engineeringu, dzięki czemu model będzie pamiętał tę informację przez całą sesję.
Halucynacje są raczej nieodłączną częścią LLM-ów i nie da się ich całkowicie wyeliminować. Dlatego musimy nauczyć się je rozpoznawać i odpowiednio sobie z nimi radzić.
Rozróżniłbym dwa główne rodzaje halucynacji:
1. halucynacja faktów gdy model nie dostał od nas potrzebnych informacji.
2. halucynacja wierności gdy model dostał od nas potrzebne informacje, ale i tak się na nich wykrzaczył, np. przez zbyt długi kontekst.
Niektórzy myślą, że LLM-y to bazy danych, w których nasze informacje są przechowywane, a następnie odzyskiwane. To jednak w ogóle nie jest prawda. Bardziej przypomina to zniekształcony obraz całej wiedzy dostępnej w internecie, na której model został wytrenowany.
Wniosek. Jeżeli czegoś brakuje, trzeba dodać to do kontekstu naszego agenta. Natomiast jeżeli kontekst jest zbyt długi i model zaczyna głupieć, należy go skrócić, wyczyścić, skompresować albo przenieść pracę do nowej sesji.
Wydaje mi się, że się zgadzamy.
Claude Code, Codex, Antigravity itd. to harnessy i każdy z nich ma własny system prompt, dlatego można odczuwać różnice w ich działaniu. Przykładem może być chociażby to, że GPT-5.6 Sol działa inaczej w Codexie, a inaczej w Claude Code (tak, da się to osiągnąć).
Same modele, gdy są trenowane, uczą się na określonych danych. Dane, na których trenowany był np. Opus, są inne niż w przypadku GPT-5.6. Bardzo możliwe, że jeden model ma „mocniejsze” wagi wskazujące na określone środowisko, w którym był trenowany. To środowisko może być bardziej lub mniej zbliżone do tego, w którym my pracujemy, to również ma znaczenie.
Tak czy inaczej, ja interpretuję tę grafikę w ten sposób, że z samym modelem nie możemy zrobić zbyt wiele (chyba że korzystamy z modeli o otwartych wagach). Ponieważ nasze możliwości jego modyfikacji są praktycznie zerowe, ten okrąg jest najmniejszy.
Znacznie większą sprawczość mamy przy budowaniu własnych harnessów. To właśnie dlatego PI jest tak popularne i potrafi czasami wypadać lepiej niż Claude Code czy Codex z ich modelami.
Największe możliwości mamy jednak przy tworzeniu własnego środowiska i uważam że to ono ma największy wpływ na to, jak ostatecznie działa agent.
To jest moja opinia na każdy nowy model, który wychodzi niezależnie z jakiej stajni.
Introducing Kimi K3: Open Frontier Intelligence
🔹 2.8 Trillion Parameters, 1 Million Context, Native Multimodal
🔹 Kimi Delta Attention enables up to 6.3x faster decoding in million-token contexts
🔹 Attention Residuals deliver ~25% higher training efficiency at <2% additional cost
🔹 Built for long-horizon agentic coding and self-evolving workflows
Kimi K3 is now live on on https://t.co/zrk6zZxZUo, Kimi Work, Kimi Code, and the Kimi API.
Open Weights by July 27, 2026.
🔗 API: https://t.co/XCrgjXAqMw
🔗 Tech blog: https://t.co/YTfiMSNM1f
Nitka która napisałem jeszcze przed wielkim BOOM na moim profilu, a uważam że jest bardzo wartościowa i warta przeczytania, ale oceńcie sami.
LOOP ENGINEERING!!
1/6 Jak sprawić, by agenci AI byli naprawdę niezawodni i radzili sobie z trudnymi zadaniami w realnym świecie? Sam mocny model nie wystarczy. Wszystko rozbija się o architekturę, jaką wokół niego zbudujemy. Ostatnio głośno jest o pojęciu loop engineering i dlatego w tej nitce chcę prosto wytłumaczyć, o co w tym chodzi. Krótko mówiąc ta metoda polega na sprytnym układaniu w stosy konkretnych pętli operacyjnych. Dzięki temu zwykłe, statyczne modele LLM zamieniają się w samodzielne systemy, które potrafią dążyć do celu i same poprawiać własne działanie. Przejdźmy krok po kroku przez cztery poziomy takich struktur.
Harness to zbiór różnych elementów np. system prompt, narzędzia, skille itp, które otaczają model.
Zadaniem harnessu jest dostarczenie modelowi odpowiedniego kontekstu w odpowiednim czasie. Poniżej grafika która obrazują szersza perspektywę (grafika nie moja tylko od super gościa @dexhorthy)
Last Seen Users on Sotwe
Asupan indo
Seen from Indonesia
Chud Dudley, American Misfit
Seen from United States
Ros.emary3569
Seen from Turkey
General Proton (comms closed! working on em!)
Seen from Dominican Republic
Dilan
Seen from United Kingdom
Cesur evli İzmir
Seen from Turkey
Hoya Hoop Club
Seen from France
diyarbakır çift
Seen from Germany
🔞👻
Seen from Saudi Arabia
Novias y Esposas XXX
Seen from Colombia
Trends for you
Most Popular Users
Elon Musk
@elonmusk
240.9M followers
Barack Obama
@barackobama
119.2M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Cristiano Ronaldo
@cristiano
111.7M followers
Narendra Modi
@narendramodi
107.1M followers
Rihanna
@rihanna
97.9M followers
NASA
@nasa
92.2M followers
Justin Bieber
@justinbieber
91.2M followers
KATY PERRY
@katyperry
88.3M followers
Taylor Swift
@taylorswift13
82.2M followers
Lady Gaga
@ladygaga
73.7M followers
Virat Kohli
@imvkohli
70.9M followers
Kim Kardashian
@kimkardashian
70.1M followers
YouTube
@youtube
68.7M followers
Bill Gates
@billgates
64.2M followers
Neymar Jr
@neymarjr
63.7M followers
The Ellen Show
@theellenshow
62.4M followers
CNN
@cnn
61.8M followers
Selena Gomez
@selenagomez
61.4M followers
X
@x
60.8M followers