Uwaga: Ta strona jest automatycznym tłumaczeniem. Przeczytaj oryginał angielski.

Centralna Kontrola Agentów Kodowania: Ujednolicone Doświadczenie w VS Code

Jeden asystent kodowania jest łatwy do zrozumienia. Kilka agentów pracujących w różnych miejscach już nie.

Jeden agent działa lokalnie w VS Code. Inny pracuje nad problemem na GitHub w chmurze. Agent CLI mieszka w terminalu. Trzeci agent kodowania stron trzecich może mieć inny model sesji i inne limity. Bez wspólnego widoku, programiści spędzają więcej czasu na śledzeniu pracy niż na jej nadzorem.

Ujednolicone doświadczenie agentów VS Code rozwiązuje ten problem koordynacji za pomocą Sesji Agentów: jedno miejsce do uruchamiania agentów, przeglądania ich statusu, otwierania ich rozmów i interwencji, gdy plan się zmienia.

To bardziej chodzi o uczynienie wielu agentów zarządzalnymi niż o dodanie kolejnego agenta.

Jeden Widok dla Różnych Rodzajów Pracy

Artykuł źródłowy opisuje czterech odrębnych uczestników: lokalne GitHub Copilot, Copilot Coding Agent w chmurze, GitHub Copilot CLI i OpenAI Codex dla uprawnionych użytkowników Copilot.

Mają inne mocne strony:

• Lokalny agent może sprawdzić bieżący obszar roboczy i wprowadzić szybkie zmiany.
• Agent kodowania w chmurze może pracować asynchronicznie nad problemem i otworzyć żądanie pull.
• Agent CLI pasuje do przepływów pracy korzystających intensywnie z terminala i poleceń operacyjnych.
• Inny dostawca może oferować inny model lub styl rozumowania.

Sesje Agentów dają tym zadaniom wspólny dom. Możesz zobaczyć, co się wykonuje, co agent robi i gdzie wznowić rozmowę.

Ta widoczność jest ważna, ponieważ prace autonomiczne nie usuwają koordynacji. Sprawiają, że koordynacja jest zadaniem inżynieryjnym pierwszej klasy.

Przerwania Są Częścią Przepływu Pracy

Artykuł źródłowy przytacza prostą obserwację: „Rzeczą powszechną jest wysłanie promptu i zdanie sobie sprawy, że zapomniałeś czegoś ważnego." Wcześniej wybór był często czekać lub anulować. Dzięki edytorom chatu możesz otworzyć aktywną sesję i dodać informacje, podczas gdy agent pracuje.

To jest bliższe prawdziwej współpracy. Wymagania się zmieniają. Test ujawnia założenie. Recenzent zauważa, że interfejs API musi pozostać kompatybilny wstecz. Użyteczny agent to nie ten, który nigdy nie potrzebuje korekty; to ten, który może zaabsorbować korektę bez utraty całego zadania.

Dla pracy .NET przerwanie może być tak proste jak:

Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.

Instrukcja jest krótka, ponieważ repozytorium już nosi większy kontekst. Sesja to miejsce do skorygowania kierunku, a nie do powtórzenia całego systemu.

Niestandardowi Agenci Zamieniają Nawyki Zespołu w Role

VS Code wprowadza również wyspecjalizowanych agentów, takich jak Plan. Zamiast natychmiast wdrażać, agent planujący pyta o zakres, komponenty, biblioteki i ograniczenia przed stworzeniem specyfikacji implementacji.

Wzorzec ten jest użyteczny poza wbudowanym agentem. Zespół może zdefiniować skoncentrowane role:

• Research gromadzi dowody i pisze krótką ewidencję decyzji.
• Review sprawdza zmianę względem konwencji repozytorium.
• Testing identyfikuje brakujące przypadki i proponuje plan testów.
• Architecture porównuje opcje bez modyfikowania plików.

Mała definicja niestandardowego agenta może wyglądać tak:

type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
  Ask about scope, constraints, existing patterns, and edge cases.
  Produce a concise specification before any implementation begins.

Użyteczna część to nie YAML. To jest wyraźne rozdzielenie odpowiedzialności. Agent planujący nie powinien po cichu edytować kodu produkcyjnego. Agent recenzujący nie powinien przepisywać projektu, który ma być oceniany.

Podagenci Zmniejszają Kolizje Kontekstu

Długie rozmowy kumulują niepowiązany kontekst. Podagenci zapewniają izolowaną przestrzeń roboczą dla ograniczonego zadania badawczego, a następnie zwracają wynik do głównej sesji.

To dobra opcja dla pytań takich jak:

Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.

Główny agent pozostaje skoncentrowany na wdrażaniu, podczas gdy agent badawczy zajmuje się wąskim pytaniem. Ta sama zasada dotyczy zespołów: jasne delegowanie daje lepsze wyniki niż uruchamianie kilku agentów z nakładającą się władzą.

Zastrzeżenie: Więcej Agentów Oznacza Więcej Koordynacji

Sesje Agentów mogą pokazywać aktywność, ale nie mogą rozwiązać konfliktowych właścicielstw. Dwaj agenci edytujący ten sam obszar mogą nadal stworzyć problem scalenia. Agent w chmurze i agent lokalny mogą przyjąć niezgodne założenia. Niestandardowy agent może stworzyć rekomendację, którą inny agent ignoruje.

Ustaw granice:

1. Jeden agent posiada wdrażanie dla danej gałęzi.
2. Agenci badawczy zwracają artefakty, a nie niestworzone edycje.
3. Żądania pull pozostają granicą przeglądu.
4. Nazwy i prompty agentów określają, co mogą zmienić.
5. Dane wyjściowe sesji są zatrzymywane, gdy wyjaśniają ważną decyzję.

Moja Opinia

Wieloagentowa przyszłość to nie kolejka okien czatu. To mały zespół z rolami, przekazaniami i odpowiedzialnością.

Sesje Agentów są wartościowe, ponieważ przyznają tę rzeczywistość. Dają programistom powierzchnię kontrolną dla pracy, która już dzieje się w edytorze, terminalu i chmurze. Następny przyrost produktywności będzie wynikać mniej z posiadania więcej agentów i bardziej z uczynienia ich granic czytelnym.

Dla zespołu .NET zacząłbym od jednego agenta planującego i jednego agenta wdrażającego. Użyj danych wyjściowych planowania jako specyfikacji problemu lub żądania pull, a następnie pozwól agentowi wdrażania pracować w ramach tej granicy. Zmierz przerobkę przed dodaniem więcej ról.

Najlepsze centrum kontroli to wciąż to, które czyni właścicielstwo oczywistym.