Wprowadzenie: Agent, którego wszyscy chcą, bez zbędnego szumu
Z agentami kodującymi jest tak, że większość z nich próbuje być twoim szefem, twoim pilotem i twoim terapeutą – a potem zapomina po prostu napisać kod. Scenariusz wygląda następująco: dodaj tuzin wektorowych baz danych, posyp odrobiną orkiestracyjnej magii, doczep przeglądarkę, a potem ogłoś, że to koniec. Dobrze się to prezentuje na demonstracji. Ale rozpada się w momencie, gdy poprosisz go o naprawienie niestabilnego testu integracyjnego o 16:52 w piątek.
Zbudowanie lekkiego agenta kodującego z użyciem Claude 4.5 jest – niespodzianka – naprawdę proste, jeśli przestaniesz gonić za marzeniem o uniwersalnym lokaju programistycznym i po prostu zbudujesz narzędzie, które czyta kod, planuje, edytuje, uruchamia i powtarza. Bez kazań o „AI zastępującym programistów”. Bez łańcuchów Rube Goldberga. Tylko zwarta pętla, która dobrze wykonuje oczywiste rzeczy.
To jest instrukcja krok po kroku, jak to osiągnąć bez angażowania całego działu operacji AI. Użyjemy Claude 4.5 jako mózgu, systemu plików i powłoki jako rąk oraz małej pamięci dla krótkotrwałej koncentracji. To wszystko. Lekkość oznacza, że możesz to zrozumieć za jednym podejściem, uruchomić lokalnie i zaufać temu, ponieważ każdy krok jest sprawdzalny. Co, jeśli ostatnio korzystałeś z czegokolwiek w tej dziedzinie, jest niemal wywrotowe.
Dlaczego Claude 4.5 sprawdza się w minimalnym agencie
Claude 4.5 ma temperament, którego faktycznie oczekujesz od kodu: ostrożny w przestrzeganiu instrukcji, zaskakująco niezły w czytaniu diffów i niezbyt skłonny do halucynowania frameworków, o które nie prosiłeś. Model jest kompetentny w stopniowym rozumowaniu bez wymagania całej noweli w promcie. To połączenie – rozumowania i powściągliwości – czyni go idealnym do pętli agenta kodującego:
- Obserwuj: Czytaj bieżące pliki, logi błędów i testy.
- Planuj: Proponuj konkretne zmiany wraz z uzasadnieniem.
- Działaj: Łataj pliki, uruchamiaj polecenia.
- Reflektuj: Oceniaj wynik, iteruj lub zatrzymaj.
Możesz to przyłączyć do dowolnego repozytorium i uzyskać wartość w jedno popołudnie. Sztuką jest opieranie się pokusie przekształcenia go w „platformę AI”. Jeśli utrzymasz agenta w lekkiej formie, Claude 4.5 wykona ciężką pracę, nie wchodząc ci w drogę.
Lekka architektura: Pięć elementów, bez dramatu
Oto cały stos, którego potrzebujesz:
- Pętla główna: Jeden proces, który wywołuje Claude 4.5 i interpretuje jego komunikaty o użyciu narzędzi.
- Narzędzia: Mały zestaw – read_file, write_file, list_dir, run_tests (lub run_cmd), search_code.
- Konstruktor kontekstu: Złóż krótki, celny prompt z metadanymi repozytorium i ostatnimi diffami.
- Pamięć krótkotrwała: Przesuwane okno konwersacji plus jawny notatnik na plan i ograniczenia.
- Szyny ochronne: Limity tokenów, czasu i zapisu plików; tryb próbny; i migawki wycofywania.
To wszystko. Możesz uruchomić go bez interfejsu graficznego w terminalu lub opakować go w minimalny interfejs użytkownika, jeśli musisz. Powód, dla którego to działa, jest nudny: każda akcja jest obserwowana i weryfikowalna. Agent proponuje zmianę, pokazuje diff, uruchamia testy, czyta wynik i albo kontynuuje, albo zatrzymuje się. Nie ma żadnej tajemniczej zawartości pośrodku.
Jak zbudować agenta (bez gubienia wątku)
Krok 1: Zdefiniuj umowę – Prompt i narzędzia
Twój agent jest tak dobry, jak jego umowa z modelem. Utrzymuj prompt systemowy krótki, ścisły i bezlitośnie praktyczny.
Prompt systemowy, w skrócie:
- Jesteś agentem kodującym. Twoim zadaniem jest wprowadzanie małych, poprawnych zmian w repozytorium, aby spełnić zadanie użytkownika.
- Myśl na głos w ukrytym notatniku; ujawniaj użytkownikowi tylko plany i diffy.
- Preferuj minimalne diffy, działające testy i stopniowy postęp.
- Jeśli nie jesteś pewien, zaproponuj eksperyment i uruchom go.
- Nigdy nie twórz fikcyjnych plików ani poleceń – listuj i czytaj przed edycją.
Schemat narzędzi (nie myśl o tym za dużo):
- read_file(path, offset?, length?)
- write_file(path, content, create_if_missing=false)
- run_cmd(command, timeout=60, cwd=repo_root)
- search_code(query, path=repo_root, max_results=50)
Opcjonalne dodatki: git_diff i git_revert(sha), jeśli chcesz bezdotykowe wycofywanie. Możesz pominąć wektorową bazę danych; większość przydatnych zadań opiera się na kilku plikach w pamięci roboczej plus szybkie wyszukiwanie.
Krok 2: Utrzymuj kontekst w czystości
Wypełnianie kontekstu to kult cargo w projektowaniu agentów. Nie wrzucaj całego monorepozytorium do promptu. Zamiast tego:
- Podsumowanie repozytorium: Jednoakapitowe streszczenie README; punkty wejścia; polecenie uruchamiania testów.
- Aktywne pliki: Tylko pliki, których agent planuje dotknąć – czytaj je w fragmentach w razie potrzeby.
- Zadanie: Cel użytkownika, jasno sformułowany: „Naprawianie nieudanego testu FooTest.test_bar w tests/foo_test.py”.
- Ograniczenia: Limity czasu wykonywania, biała lista zapisu plików, reguły stylu i oczekiwania dotyczące semantycznego wersjonowania, jeśli dotyczy.
- Ostatnia historia: Dwa ostatnie diffy i ich wyniki testów. Nic więcej.
Claude 4.5 jest doskonale zdolny do pobierania większej ilości kontekstu, gdy tego potrzebuje, za pomocą search_code i read_file. Daj mu mapę, a nie terytorium.
Krok 3: Pętla (Obserwuj → Planuj → Działaj → Reflektuj)
- Obserwuj: Zacznij od listowania katalogów, czytania nieudanego testu, kodu poddawanego testowi i dziennika błędów. Poproś Claude'a o podsumowanie objawów awarii w dwóch lub trzech punktach.
- Planuj: Poproś Claude'a o zaproponowanie planu z:
- Hipotezą dotyczącą awarii
- Plikami do sprawdzenia lub edycji
- Minimalnymi diffami do wypróbowania
- Poleceniem testowym do walidacji
- Działaj: Zastosuj proponowany diff za pomocą write_file. Pokaż diff dosłownie. Uruchom testy.
- Reflektuj: Przekaż stdout/stderr z powrotem. Zapytaj Claude'a: kontynuować, wycofać, czy zatrzymać? Jeśli plan się zmienia, wymagaj jednowierszowego uzasadnienia odwołującego się do rzeczywistego wyniku.
- Wyjdź: Zatrzymaj się, gdy testy przejdą, lub po N iteracjach, w zależności od tego, co nastąpi pierwsze.
To jest gloryfikowane programowanie w parach, w którym faktycznie utrzymujesz uczciwość parowania.
Krok 4: Szyny ochronne, które ratują twój weekend
- Biała lista zapisu: Zezwalaj na zapis tylko w src/, lib/ lub wyraźnie zatwierdzonych ścieżkach.
- Limit rozmiaru diffa: Ograniczaj edycje do 200–500 wierszy na krok. Jeśli większe, podziel na podkroki.
- Biała lista poleceń: narzędzia do uruchamiania testów, lintery i kilka skryptów deweloperskich. Zakaz sieci. Chcesz powtarzalności, a nie szalejącego curla.
- Limit czasu i ponowne próby: Krótkie limity czasu, maksymalnie jedna ponowna próba – niekończące się pętle ponownego uruchamiania to miejsca, w których agenci idą umrzeć.
- Tryb próbny: Drukuj proponowane diffy, ale nie zapisuj. Świetne do przeglądu kodu.
Claude 4.5 będzie przestrzegał zasad, jeśli uczynisz je wyraźnymi. Jeśli tego nie zrobisz, nie bądź zaskoczony, gdy spróbuje „pomóc”, reorganizując całe repozytorium, aby było zgodne z wpisem na blogu z 2017 roku.
Krok 5: Pamięć, która jest naprawdę przydatna
Pamięć krótkotrwała rozwiązuje 80% problemu. Zachowaj:
- Notatnik na bieżącą hipotezę i plan.
- Listę plików, których dotknięto w tej sesji.
- Dwa ostatnie wyniki poleceń.
To wystarczy, aby Claude 4.5 rozumował spójnie. Pamięć długotrwała – logi zadań, embeddingi – mogą być pomocne w przypadku powtarzających się baz kodu, ale traktuj to jako opcjonalny dodatek. Jeśli twój agent nie może naprawić testu bez indeksu wektorowego o pojemności 500 MB, to nie jest agent – to zależność.
Minimalny szkic implementacji
W pseudokodzie możesz zaimplementować tego agenta w kilkuset wierszach:
- initialize: załaduj metadane repozytorium, ograniczenia i klienta modelu
- observe: czytaj nieudane testy, pliki, logi
- plan = model.propose_plan(context)
- while not done and steps < MAX:
- diff = model.propose_patch(plan)
- show(diff); maybe approve
- out = run_cmd(plan.test_cmd)
- reflect = model.evaluate(out)
- if reflect == pass: done = true
- else if reflect == rollback: git_revert(last_commit)
- else: plan = model.revise_plan(out)
Zauważysz brakujące części: brak agentów zarządzających agentami, brak „delegatów”, brak oddzielnego „modelu planisty” i „modelu wykonawcy”. Claude 4.5 może wykonywać obie te prace dobrze, jeśli nie sabotujesz go aparatem Rube Goldberga.
Promptowanie, które się zbytnio nie stara
Złe prompty próbują być sprytne. Dobre prompty są nudne i konkretne. Oto rozsądny szkielet dla twojego podstawowego bloku instrukcji:
- Cel: Określ dokładne zadanie kodowania i kryteria sukcesu.
- Kontekst: Struktura projektu, punkty wejścia i polecenie testowe.
- Ograniczenia: Biała lista zapisu, limit rozmiaru diffa, brak sieci.
- Preferencje dotyczące stylu: Wersja języka, formater, reguły lintera.
- Proces: Obserwuj → Planuj → Działaj → Reflektuj; pokazuj diffy; uruchamiaj testy; iteruj do N kroków; zatrzymaj się, gdy testy przejdą.
Claude 4.5, z tą strukturą, nie będzie potrzebował 100-wierszowego scenariusza odgrywania ról. Po prostu działa.
Praktyczny przykład: Naprawianie nieudanego testu
Powiedzmy, że test nie przechodzi w tests/time_test.py, ponieważ parse_time("09:00") zwraca 5400 zamiast 32400. Pętla agenta powinna wyglądać następująco:
- Obserwuj: Czytaj time.py i time_test.py; uruchom pytest -k parse_time.
- Planuj: Hipoteza – błąd w obliczeniach sekund vs minut; zaproponuj edycję parse_time; dodaj przypadek brzegowy jednostki.
- Działaj: Załataj parse_time, dodaj test dla godzin z wiodącym zerem; uruchom testy.
- Reflektuj: Jeśli testy nadal nie przechodzą, przeczytaj błąd, dostosuj matematykę lub wyrażenie regularne, uruchom ponownie.
Minimalna udana łatka może być dwuwierszową zmianą. O to chodzi. Małe edycje, szybkie cykle, realny postęp.
Gdzie lekkość pokonuje zlew kuchenny
- Opóźnienie: Jeden model, jedna pętla, brak narzutu orkiestracji.
- Przejrzystość: Każdy krok jest audytowalny. Możesz go porównać, możesz go cofnąć, możesz go ponownie uruchomić.
- Kontrola: Szyny ochronne utrzymują szkody lokalnie. Agent nie może wędrować po twojej infrastrukturze.
- Koszt: Mniej wywołań, mniej kontekstu, przewidywalne tokeny.
- UX: Ty to rozumiesz. Twoi koledzy z zespołu to rozumieją. Twoja przyszła jaźń cię nie znienawidzi.
A kompromisy:
- Szerokość: Lekki agent kodujący nie przefakturuje twojego pięciojęzykowego monorepozytorium za jednym razem. Ani nie powinien.
- Inicjatywa: Nie wymyśli wielotygodniowych planów działania. Ty dajesz mu zadania.
- Stanowość: Bez dużej warstwy pamięci, zapomina odległą historię z założenia. To jest cecha, dopóki nie stanie się błędem.
Idealne miejsce dla Claude 4.5 dla agentów kodujących
Claude 4.5 błyszczy w:
- Czytaniu i rozumowaniu o diffach i logach.
- Wytwarzaniu spójnych, minimalnych zmian w kodzie.
- Przestrzeganiu ograniczeń i byciu wyraźnym co do niepewności.
Jest mniej świetny w:
- Odgadywaniu zachowania API, którego nie może przeczytać.
- Ciężkiej choreografii narzędzi (niepotrzebnej tutaj).
- Długich refaktoryzacjach wielu plików bez człowieka kierującego krokami.
Ten ostatni punkt jest ważny. Najlepszym sposobem na uzyskanie silnych wyników nie jest powiększanie agenta – jest nim zmniejszenie zadania. Użyj swojego mózgu do określania zakresu, a Claude 4.5 do wykonania w tym zakresie.
Słowo o integracji z IDE
Oprzyj się pokusie wbudowania tego bezpośrednio w panel IDE z pięćdziesięcioma przełącznikami. Pętla oparta na terminalu ze zwykłymi tekstowymi diffami jest łatwiejsza do zaufania i debugowania. Jeśli chcesz ulepszenia edytora, niech będzie głupie:
- Polecenia do uruchamiania/zatrzymywania pętli.
- Pokazuj diffy w podzielonym widoku.
- Prompt zatwierdzający do zapisu (opcjonalny, ale mądry).
Możesz zintegrować później. Najpierw spraw, żeby to działało.
Sider.AI, używane oszczędnie, faktycznie pomaga Jeśli chcesz pragmatycznego środowiska do uruchamiania tego rodzaju pętli bez ponownego wymyślania rusztowania, Sider.AI faktycznie działa – przynajmniej, gdy używasz go do tego, w czym jest dobry. Utrzymuje porządek w konwersacji i diffach, pozwala uruchamiać polecenia i nie zmusza cię do korzystania z jakiegoś grandiozalnego „autonomicznego frameworka agentów”. Sztuką jest przestrzeganie własnych zasad: krótkie prompty, ciasne pętle, widoczne diffy. Sider schodzi z drogi, co jest rzadsze niż powinno. Typowe pułapki (i jak uniknąć głupiego wyglądu)
- Przeciążony kontekst: Jeśli twój prompt brzmi jak list z żądaniem okupu, robisz to źle. Pobieraj pliki na żądanie.
- Przedwczesna refaktoryzacja: Agent sugeruje reorganizację modułów? Najpierw spraw, żeby przeszedł testy. Refaktoryzuj później.
- Halucynowane pliki: Wymagaj list_dir i read_file przed jakimkolwiek write_file do nowej ścieżki.
- Nieskończone pętle ponownego uruchamiania: Ogranicz kroki. Wymagaj uzasadnienia dla każdej nowej hipotezy.
- Jeden gigantyczny diff: Dziel zmiany. Mniejsze diffy szybciej zawodzą i łatwiej je zrozumieć.
Bezpieczeństwo i ochrona bez paranoi
- Lokalne wykonanie: Uruchom w katalogu w piaskownicy. Brak sieci domyślnie.
- Izolacja zależności: Użyj lokalnego venv lub kontenera. Przypnij wersje.
- Sekrety: Agent ich nie potrzebuje. Jeśli polecenie wymaga tokenu, zatrzymaj się i zapytaj.
- Audyt: Utrwalaj każdy plan, diff i polecenie w dzienniku.
Jak wiedzieć, że to działa
- Skrócenie czasu realizacji: Poprawki błędów, które zajmowały godzinę, teraz zajmują dziesięć minut.
- Mniej błędów grubych palców: Diffy stają się mniejsze, testy stają się bardziej zielone.
- Ufasz mu: Przestajesz zawisać nad każdą akcją, ponieważ cię nie spalił.
- Koledzy z zespołu go używają: Definicją sukcesu jest to, że inni go adoptują bez spotkania.
Skalowanie w górę, ostrożnie
Jeśli naprawdę musisz skalować, rób to z dyscypliną:
- Równoległe podzadania, a nie równoległe mózgi: Podziel pracę, uruchom wiele lekkich pętli w oddzielnych katalogach i scalaj, gdy jest zielono.
- Pamięć epizodyczna, a nie zrzut mózgu: Przechowuj udane łatki i mapowania objawów na naprawy. Pobieraj chirurgicznie.
- Okresowe „większe” przejścia: Zarezerwuj sesję z przewodnikiem człowieka na refaktoryzacje; agent pomaga, nie prowadzi.
Minimalna implementacja referencyjna (szkic)
Pseudokod w stylu Pythona, aby się ruszyć:
- def init(self, repo_root, model):
- self.history = [] # dwa ostatnie diffy i wyniki testów
- "repo": summarize_repo(self.root),
- "constraints": {"write_whitelist": ["src/", "tests/"], "max_diff_lines": 300, "no_network": True},
- "history": self.history[-2:],
- plan = self.model("propose_plan", self.context(task))
- diff = self.model("propose_patch", {"plan": plan})
- out = run_cmd(plan.test_cmd)
- eval = self.model("evaluate", {"output": out, "plan": plan})
- self.history.append({"diff": diff, "out": tail(out)})
Zakończenie w ludzkim rozmiarze
Branża wciąż obiecuje autonomicznych agentów programistycznych. To, czego naprawdę potrzebujemy, to uczciwy asystent, który czyta, planuje, edytuje, uruchamia i zatrzymuje się. Claude 4.5 jest w tym dobry, pod warunkiem, że nie zakopiesz go pod frameworkami, które istnieją głównie po to, by się usprawiedliwiać. Lekkość nie jest kompromisem – to sedno sprawy. Zbuduj pętlę, dodaj szyny ochronne i pozwól narzędziu robić to, co narzędzia zawsze robiły, gdy utrzymujesz je w prostocie: zmniejsz pracę.
Wniosek: Nudny skrót, który wygrywa
Oto twoja lista kontrolna dla lekkiego agenta kodującego z Claude 4.5:
- Jedna pętla, jeden model, małe narzędzia.
- Ciasny kontekst: zadanie, kilka plików, ostatnie wyniki.
- Minimalne diffy, częste testy, twarde limity.
- Lokalne, w piaskownicy wykonanie; brak sieci.
- Opcjonalne ulepszenia edytora; nigdy wymagane.
Jeśli się przyjrzysz, wygląda to podejrzanie jak dobra inżynieria oprogramowania, tylko szybciej. I to jest puenta. Najmądrzejszą rzeczą, jaką możesz tutaj zrobić, nie jest gonienie za „autonomią” – jest nią kodyfikowanie dyscypliny. Im mniej wymagasz od agenta, tym więcej zyskujesz.
FAQ
P1: Jak zacząć budować lekkiego agenta kodującego z Claude 4.5?
Zdefiniuj mały zestaw narzędzi (czytaj, pisz, szukaj, uruchamiaj), napisz ścisły prompt systemowy i zaimplementuj pętlę Obserwuj → Planuj → Działaj → Reflektuj. Utrzymuj mały kontekst i podawaj prawdziwe logi i diffy – Claude 4.5 działa najlepiej, gdy zadanie jest wąskie, a informacja zwrotna jest konkretna.
P2: Czy potrzebuję wektorowej bazy danych lub warstwy pamięci dla agenta kodującego Claude 4.5?
Nie. W przypadku większości zadań wystarcza pamięć krótkotrwała plus search_code. Dodaj pamięć długotrwałą tylko wtedy, gdy wielokrotnie wracasz do tego samego repozytorium i możesz udowodnić, że oszczędza to tokeny bez ogłupiania agenta.
P3: Jakie szyny ochronne są niezbędne dla agenta kodującego Claude 4.5?
Wprowadź białą listę ścieżek zapisywalnych, ogranicz rozmiary diffów, ogranicz polecenia i rejestruj każdą akcję. Te proste limity zapewniają przewidywalność agenta i sprawiają, że wycofywanie jest nudne – w dobry sposób.
P4: Czy lekki agent może obsługiwać refaktoryzacje wielu plików?
Tak, jeśli podzielisz pracę na małe kroki i utrzymasz ciasną pętlę. Claude 4.5 może zarządzać refaktoryzacjami, ale ty kierujesz zakresem; w przeciwnym razie otrzymasz jeden gigantyczny, kruchy diff, którego nie będziesz chciał przeglądać.
P5: Gdzie Sider.AI pasuje do agenta kodującego Claude 4.5?
Sider.AI jest przydatny jako uporządkowana przestrzeń robocza: konwersacje, diffy i polecenia w jednym miejscu, bez wymuszania ciężkiego frameworka agentów. Użyj go do uruchomienia pętli, a nie do ponownego jej wymyślania. 
