Kodeks i przepływ pracy wieloagentowy: pracuj z agentami bez utraty kontroli

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Gdy agent programujący po raz pierwszy faktycznie naprawi dla Ciebie błąd, reakcja jest prawie zawsze taka sama: mieszanina entuzjazmu i podejrzeń. Ładne, jasne. Ale potem patrzysz na różnicę i zadajesz sobie pytanie: „OK, ale czego dokładnie dotknął? Czy mogę mu zaufać? Czy jutro zrobi to ponownie w ten sam sposób?”.
3~
4Myślę, że tu zaczyna się interesująca część. Nie wtedy, gdy agent pisze funkcję, ale wtedy, gdy staje się ona na tyle zdolna, aby podjąć się całych zadań: przeczytać repozytorium, stworzyć łatkę, uruchomić testy, otworzyć PR, wrócić po komentarzu do recenzji. Codex zmierza właśnie w tym kierunku: praca w tle, oddzielne drzewa robocze, zintegrowana przeglądarka, automatyzacja, wtyczki, pamięć i bardziej wyraźna kontrola uprawnień.
5~
6Nie chodzi o to, żeby wyobrażać sobie przyszłość, w której nikt już nie czyta kodu. Byłaby to straszna przyszłość, a przy tym dość naiwna. Chodzi o to, aby dowiedzieć się, jak współpracować z agentami, którzy mogą wiele zrobić, nie pozwalając im robić wszystkiego.
7~
8## Zmiana nawyku
9~
10Dzięki tradycyjnemu autouzupełnianiu zawsze byłeś za kierownicą. Sztuczna inteligencja zasugerowała linię, zdecydowałeś. Z agentem jednak relacja się zmienia: dajesz mu cel, a on samodzielnie przechodzi przez wiele etapów.
11~
12To jest potężne, ale zmienia problem. Pytanie nie brzmi już tylko „czy model można zaprogramować?”. Pytanie brzmi:
13~
14- Czy dałem mu wystarczająco mały zakres?
15- wiesz jak sprawdzić wynik?
16- Czy pracuję w izolowanym środowisku?
17- Czy ostateczna ocena jest nadal humanitarna i ostrożna?
18~
19Zdrowy przepływ pracy wygląda bardziej jak magiczna różdżka:
20~
21```mermaid
22flowchart LR
23    Idea[Zadanie ludzkie] --> Scope[Mały, sprawdzalny cel]
24    Scope --> Agent[Agent w drzewie roboczym na białym tle]
25    Agent --> Checks[Testuj, lintuj, buduj, przeglądarkę]
26    Checks --> Review[Przegląd ludzki]
27    Review --> Merge[Scal lub nowa iteracja]
28    Review --> Iterate[Precyzyjne komentarze na temat różnic]
29    Iterate --> Agent
30```
31~
32Brzmi mniej romantycznie niż „agent wszystko buduje”, ale działa znacznie lepiej. I tak działają zespoły, które dobrze radzą sobie z ludźmi: jasne zadania, szybka informacja zwrotna, wyraźna odpowiedzialność.
33~
34## Dobra zachęta to prawie dobry bilet
35~
36Najbardziej niebezpiecznym komunikatem jest ten niejasny, ale pewny: „napraw stronę z fakturami”, „popraw architekturę”, „wyczyść moduł uwierzytelniania”. Są to żądania, które brzmią produktywnie i generują ogromne różnice. Ale potem okazuje się, że zajmujesz się archeologią.
37~
38Pomocny monit jest bardziej nudny. Na przykład: zaimplementuj eksport CSV dla strony faktur, wiedząc, że tabela jest w `app/(dashboard)/invoices/page.tsx`, zapytania są w `src/server/invoices.ts` i podobny wzorzec istnieje już w `app/(dashboard)/reports`.
39~
40Następnie dodaj jasne ograniczenia: nie zmieniaj schematu bazy danych, nie dodawaj zależności, jeśli wystarczy małe narzędzie, zachowaj istniejący styl interfejsu użytkownika. I zakończ weryfikacją: `npm test -- invoices` i `npm run build`.
41~
42Celem tego rodzaju briefu nie jest „lepsze wyjaśnianie sztucznej inteligencji”. Służy przede wszystkim wyjaśnieniu Ci, co delegujesz. Jeśli nie potrafisz tego zapisać konkretnie, być może zadanie nie jest jeszcze gotowe dla agenta.
43~
44## Trzy zadania, które chętnie deleguję
45~
46Pierwsza to praca powtarzalna, ale możliwa do sprawdzenia: dodawanie testów, migracja wywołań do nowego wewnętrznego API, aktualizacja importów, wymiana przestarzałych komponentów, naprawianie błędów TypeScriptu. Tutaj agent może zaoszczędzić wiele godzin, a ryzyko można kontrolować.
47~
48Druga to praca eksploracyjna: „znajdź miejsce obliczenia tej sumy”, „wyjaśnij mi, dlaczego ten test jest niestabilny”, „odtwórz błąd i powiedz mi, których plików prawdopodobnie dotyczy”. Nawet jeśli nie wyprodukuje od razu łatki, może przeprowadzić pożyteczny rekonesans.
49~
50Trzeci to powtarzające się prace konserwacyjne: małe aktualizacje zależności, czyszczenie starych flag funkcji, podsumowanie zablokowanych PR, sprawdzanie zapomnianych TODO. Nie jest to jakieś efektowne, ale to dokładnie ten rodzaj pracy, która ma tendencję do nawarstwiania się.
51~
52## Trzy prace, które zachowuję jako ludzkie
53~
54Decyzje dotyczące produktu pozostają ludzkie. Jeśli zmiana zmienia sposób, w jaki użytkownik płaci, usuwa dane, widzi ceny lub rozumie pozwolenie, potrzebuję osoby odpowiedzialnej.
55~
56Na uwagę człowieka zasługują także granice bezpieczeństwa: uwierzytelnianie, role, tokeny, rejestrowanie wrażliwych danych, migracje baz danych. Agent może pomóc we wdrożeniu, ale nie musi być jedynym decydentem.
57~
58Wreszcie wszystko, co wymaga ludzkiego gustu architektonicznego, zachowuję. Agent może zaproponować refaktor, ale zrozumienie, czy abstrakcja jest naprawdę konieczna, czy też po prostu dopracowujemy nieistniejący problem, pozostaje zadaniem.
59~
60## Przegląd nie jest opcjonalny
61~
62Kiedy agent jest dobry, pojawia się pokusa, aby zaufać zielonemu CI. To zrozumiałe. Wtedy też zaczynają się problemy.
63~
64Zawsze biorę pod uwagę co najmniej pięć rzeczy:
65~
661. Czy łatka rozwiązuje tylko żądane zadanie?
672. Czy dotknął plików, które nie miały z tym nic wspólnego?
683. Czy testy obejmują nowatorskie zachowanie, czy po prostu szczęśliwy przypadek?
694. Czy kod jest zgodny z lokalnymi wzorcami?
705. Czy błędy są obsługiwane tak jak w pozostałej części projektu?
71~
72Kiedy coś jest nie tak, informacja zwrotna musi być konkretna. „Napraw to” jest leniwe. Lepiej: to narzędzie duplikuje `parseMoney` w `src/lib/money.ts`; ponownie użyj tej funkcji, dodaj test dla sprawy EUR i nie zmieniaj publicznego API modułu rozliczeniowego.
73~
74Agenci znacznie lepiej reagują na drobne, weryfikowalne uwagi. Co ciekawe, ludzie też.
75~
76## Poręcze warte wysiłku
77~
78Jeśli agent może czytać pliki, pisać kod i wykonywać polecenia, należy go traktować jako potężny proces. Nie ma co popadać w paranoję, wystarczy higiena.
79~
80Użyj oddzielnych drzew roboczych lub gałęzi. Możesz więc porównywać różnice, odrzucić nieudane eksperymenty i nie mieszać pracy agenta z tym, co robiłeś.
81~
82Ogranicz uprawnienia. Polecenia takie jak `rg`, `git diff`, `npm test` i `npm run build` mogą być całkiem darmowe. Wdrożenia, migracje baz danych, dostęp do sekretów i destrukcyjne polecenia muszą pozostać jawne.
83~
84Ogranicz dostęp do sieci, gdy go nie potrzebujesz. Do wielu zadań wystarczą oficjalna dokumentacja, rejestr pakietów i określone usługi wewnętrzne. Mniejsza powierzchnia, mniej niespodzianek.
85~
86Śledź działania. Kiedy łatka dotrze do przeglądu, powinieneś być w stanie zrekonstruować monity, wykonane polecenia, zaliczone testy i zmodyfikowane pliki. Nie po to, żeby tworzyć biurokrację, ale żeby móc zrozumieć, co się stanie, jeśli coś pójdzie nie tak.
87~
88## Łatwy sposób na rozpoczęcie pracy w zespole
89~
90Gdybym miał wprowadzić agentów do małego zespołu, zacząłbym bez większych rewolucji.
91~
92Utworzyłbym etykietę `agent-ready` dla problemów o jasnym zakresie. Dodałbym szablon z kontekstem, ograniczeniami i poleceniami weryfikacyjnymi. Prosiłbym o mały PR, najlepiej poniżej kilkuset linijek. Wymagałbym testów lub zrzutów ekranu pod kątem widocznych zmian. A przede wszystkim pozostawiłbym osobę odpowiedzialną za fuzję.
93~
94Po dwóch tygodniach przyjrzałem się danym: które zadania zostały naprawdę przyspieszone, które recenzje były ciężkie, które podpowiedzi były zagmatwane, które części bazy kodu są zbyt delikatne, aby je delegować.
95~
96To mniej spektakularne podejście niż „od dzisiaj będziemy robić wszystko z agentami”, ale takie, które pozwala bez żalu przejść do trzeciego tygodnia.
97~
98## Najbardziej ludzka część
99~
100Zabawne jest to, że im bardziej autonomiczni stają się agenci, tym ważniejsze znów stają się klasyczne umiejętności: pisanie dobrego zgłoszenia, dokonywanie małych cięć, tworzenie testów, czytanie różnic, komunikowanie kompromisów. Środek przyspiesza tych, którzy już wiedzą, jak dobrze pracować. Pogłębia także chaos tych, którzy źle delegują zadania.
101~
102Więc nie, nie postrzegam wieloagentowych przepływów pracy jako skrótu, dzięki któremu można przestać zajmować się inżynierią. Postrzegam je jako sposób na przeniesienie większej ilości energii na najważniejsze części: podjęcie decyzji, co zbudować, upewnienie się, że działa, utrzymanie zrozumiałości systemu.
103~
104Agenci mogą być świetnymi asynchronicznymi współpracownikami. Ale asynchroniczny współpracownik, aby był użyteczny, potrzebuje kontekstu, granic i przeglądu. Podobnie jak wszyscy inni.
105~
106## Przydatne źródła
107~
108- [Kodeks dla (prawie) wszystkiego - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Bezpieczne uruchamianie Codexu w OpenAI](https://openai.com/index/running-codex-safely/)
110- [Przedstawiamy Kodeks - OpenAI](https://openai.com/index/introducing-codex/)
111- [Co nowego w agencie kodującym GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Gdy agent programujący po raz pierwszy faktycznie naprawi dla Ciebie błąd, reakcja jest prawie zawsze taka sama: mieszanina entuzjazmu i podejrzeń. Ładne, jasne. Ale potem patrzysz na różnicę i zadajesz sobie pytanie: „OK, ale czego dokładnie dotknął? Czy mogę mu zaufać? Czy jutro zrobi to ponownie w ten sam sposób?”.

4Myślę, że tu zaczyna się interesująca część. Nie wtedy, gdy agent pisze funkcję, ale wtedy, gdy staje się ona na tyle zdolna, aby podjąć się całych zadań: przeczytać repozytorium, stworzyć łatkę, uruchomić testy, otworzyć PR, wrócić po komentarzu do recenzji. Codex zmierza właśnie w tym kierunku: praca w tle, oddzielne drzewa robocze, zintegrowana przeglądarka, automatyzacja, wtyczki, pamięć i bardziej wyraźna kontrola uprawnień.

6Nie chodzi o to, żeby wyobrażać sobie przyszłość, w której nikt już nie czyta kodu. Byłaby to straszna przyszłość, a przy tym dość naiwna. Chodzi o to, aby dowiedzieć się, jak współpracować z agentami, którzy mogą wiele zrobić, nie pozwalając im robić wszystkiego.

8## Zmiana nawyku

10Dzięki tradycyjnemu autouzupełnianiu zawsze byłeś za kierownicą. Sztuczna inteligencja zasugerowała linię, zdecydowałeś. Z agentem jednak relacja się zmienia: dajesz mu cel, a on samodzielnie przechodzi przez wiele etapów.

11~

12To jest potężne, ale zmienia problem. Pytanie nie brzmi już tylko „czy model można zaprogramować?”. Pytanie brzmi:

13~

14- Czy dałem mu wystarczająco mały zakres?

15- wiesz jak sprawdzić wynik?

16- Czy pracuję w izolowanym środowisku?

17- Czy ostateczna ocena jest nadal humanitarna i ostrożna?

18~

19Zdrowy przepływ pracy wygląda bardziej jak magiczna różdżka:

20~

21```mermaid

22flowchart LR

23 Idea[Zadanie ludzkie] --> Scope[Mały, sprawdzalny cel]

24 Scope --> Agent[Agent w drzewie roboczym na białym tle]

25 Agent --> Checks[Testuj, lintuj, buduj, przeglądarkę]

26 Checks --> Review[Przegląd ludzki]

27 Review --> Merge[Scal lub nowa iteracja]

28 Review --> Iterate[Precyzyjne komentarze na temat różnic]

29 Iterate --> Agent

30```

31~

32Brzmi mniej romantycznie niż „agent wszystko buduje”, ale działa znacznie lepiej. I tak działają zespoły, które dobrze radzą sobie z ludźmi: jasne zadania, szybka informacja zwrotna, wyraźna odpowiedzialność.

33~

34## Dobra zachęta to prawie dobry bilet

35~

36Najbardziej niebezpiecznym komunikatem jest ten niejasny, ale pewny: „napraw stronę z fakturami”, „popraw architekturę”, „wyczyść moduł uwierzytelniania”. Są to żądania, które brzmią produktywnie i generują ogromne różnice. Ale potem okazuje się, że zajmujesz się archeologią.

37~

38Pomocny monit jest bardziej nudny. Na przykład: zaimplementuj eksport CSV dla strony faktur, wiedząc, że tabela jest w `app/(dashboard)/invoices/page.tsx`, zapytania są w `src/server/invoices.ts` i podobny wzorzec istnieje już w `app/(dashboard)/reports`.

39~

40Następnie dodaj jasne ograniczenia: nie zmieniaj schematu bazy danych, nie dodawaj zależności, jeśli wystarczy małe narzędzie, zachowaj istniejący styl interfejsu użytkownika. I zakończ weryfikacją: `npm test -- invoices` i `npm run build`.

41~

42Celem tego rodzaju briefu nie jest „lepsze wyjaśnianie sztucznej inteligencji”. Służy przede wszystkim wyjaśnieniu Ci, co delegujesz. Jeśli nie potrafisz tego zapisać konkretnie, być może zadanie nie jest jeszcze gotowe dla agenta.

43~

44## Trzy zadania, które chętnie deleguję

45~

46Pierwsza to praca powtarzalna, ale możliwa do sprawdzenia: dodawanie testów, migracja wywołań do nowego wewnętrznego API, aktualizacja importów, wymiana przestarzałych komponentów, naprawianie błędów TypeScriptu. Tutaj agent może zaoszczędzić wiele godzin, a ryzyko można kontrolować.

47~

48Druga to praca eksploracyjna: „znajdź miejsce obliczenia tej sumy”, „wyjaśnij mi, dlaczego ten test jest niestabilny”, „odtwórz błąd i powiedz mi, których plików prawdopodobnie dotyczy”. Nawet jeśli nie wyprodukuje od razu łatki, może przeprowadzić pożyteczny rekonesans.

49~

50Trzeci to powtarzające się prace konserwacyjne: małe aktualizacje zależności, czyszczenie starych flag funkcji, podsumowanie zablokowanych PR, sprawdzanie zapomnianych TODO. Nie jest to jakieś efektowne, ale to dokładnie ten rodzaj pracy, która ma tendencję do nawarstwiania się.

51~

52## Trzy prace, które zachowuję jako ludzkie

53~

54Decyzje dotyczące produktu pozostają ludzkie. Jeśli zmiana zmienia sposób, w jaki użytkownik płaci, usuwa dane, widzi ceny lub rozumie pozwolenie, potrzebuję osoby odpowiedzialnej.

55~

56Na uwagę człowieka zasługują także granice bezpieczeństwa: uwierzytelnianie, role, tokeny, rejestrowanie wrażliwych danych, migracje baz danych. Agent może pomóc we wdrożeniu, ale nie musi być jedynym decydentem.

57~

58Wreszcie wszystko, co wymaga ludzkiego gustu architektonicznego, zachowuję. Agent może zaproponować refaktor, ale zrozumienie, czy abstrakcja jest naprawdę konieczna, czy też po prostu dopracowujemy nieistniejący problem, pozostaje zadaniem.

59~

60## Przegląd nie jest opcjonalny

61~

62Kiedy agent jest dobry, pojawia się pokusa, aby zaufać zielonemu CI. To zrozumiałe. Wtedy też zaczynają się problemy.

63~

64Zawsze biorę pod uwagę co najmniej pięć rzeczy:

65~

661. Czy łatka rozwiązuje tylko żądane zadanie?

672. Czy dotknął plików, które nie miały z tym nic wspólnego?

683. Czy testy obejmują nowatorskie zachowanie, czy po prostu szczęśliwy przypadek?

694. Czy kod jest zgodny z lokalnymi wzorcami?

705. Czy błędy są obsługiwane tak jak w pozostałej części projektu?

71~

72Kiedy coś jest nie tak, informacja zwrotna musi być konkretna. „Napraw to” jest leniwe. Lepiej: to narzędzie duplikuje `parseMoney` w `src/lib/money.ts`; ponownie użyj tej funkcji, dodaj test dla sprawy EUR i nie zmieniaj publicznego API modułu rozliczeniowego.

73~

74Agenci znacznie lepiej reagują na drobne, weryfikowalne uwagi. Co ciekawe, ludzie też.

75~

76## Poręcze warte wysiłku

77~

78Jeśli agent może czytać pliki, pisać kod i wykonywać polecenia, należy go traktować jako potężny proces. Nie ma co popadać w paranoję, wystarczy higiena.

79~

80Użyj oddzielnych drzew roboczych lub gałęzi. Możesz więc porównywać różnice, odrzucić nieudane eksperymenty i nie mieszać pracy agenta z tym, co robiłeś.

81~

82Ogranicz uprawnienia. Polecenia takie jak `rg`, `git diff`, `npm test` i `npm run build` mogą być całkiem darmowe. Wdrożenia, migracje baz danych, dostęp do sekretów i destrukcyjne polecenia muszą pozostać jawne.

83~

84Ogranicz dostęp do sieci, gdy go nie potrzebujesz. Do wielu zadań wystarczą oficjalna dokumentacja, rejestr pakietów i określone usługi wewnętrzne. Mniejsza powierzchnia, mniej niespodzianek.

85~

86Śledź działania. Kiedy łatka dotrze do przeglądu, powinieneś być w stanie zrekonstruować monity, wykonane polecenia, zaliczone testy i zmodyfikowane pliki. Nie po to, żeby tworzyć biurokrację, ale żeby móc zrozumieć, co się stanie, jeśli coś pójdzie nie tak.

87~

88## Łatwy sposób na rozpoczęcie pracy w zespole

89~

90Gdybym miał wprowadzić agentów do małego zespołu, zacząłbym bez większych rewolucji.

91~

92Utworzyłbym etykietę `agent-ready` dla problemów o jasnym zakresie. Dodałbym szablon z kontekstem, ograniczeniami i poleceniami weryfikacyjnymi. Prosiłbym o mały PR, najlepiej poniżej kilkuset linijek. Wymagałbym testów lub zrzutów ekranu pod kątem widocznych zmian. A przede wszystkim pozostawiłbym osobę odpowiedzialną za fuzję.

93~

94Po dwóch tygodniach przyjrzałem się danym: które zadania zostały naprawdę przyspieszone, które recenzje były ciężkie, które podpowiedzi były zagmatwane, które części bazy kodu są zbyt delikatne, aby je delegować.

95~

96To mniej spektakularne podejście niż „od dzisiaj będziemy robić wszystko z agentami”, ale takie, które pozwala bez żalu przejść do trzeciego tygodnia.

97~

98## Najbardziej ludzka część

99~

100Zabawne jest to, że im bardziej autonomiczni stają się agenci, tym ważniejsze znów stają się klasyczne umiejętności: pisanie dobrego zgłoszenia, dokonywanie małych cięć, tworzenie testów, czytanie różnic, komunikowanie kompromisów. Środek przyspiesza tych, którzy już wiedzą, jak dobrze pracować. Pogłębia także chaos tych, którzy źle delegują zadania.

101~

102Więc nie, nie postrzegam wieloagentowych przepływów pracy jako skrótu, dzięki któremu można przestać zajmować się inżynierią. Postrzegam je jako sposób na przeniesienie większej ilości energii na najważniejsze części: podjęcie decyzji, co zbudować, upewnienie się, że działa, utrzymanie zrozumiałości systemu.

103~

104Agenci mogą być świetnymi asynchronicznymi współpracownikami. Ale asynchroniczny współpracownik, aby był użyteczny, potrzebuje kontekstu, granic i przeglądu. Podobnie jak wszyscy inni.

105~

106## Przydatne źródła

107~

108- [Kodeks dla (prawie) wszystkiego - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Bezpieczne uruchamianie Codexu w OpenAI](https://openai.com/index/running-codex-safely/)

110- [Przedstawiamy Kodeks - OpenAI](https://openai.com/index/introducing-codex/)

111- [Co nowego w agencie kodującym GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~