# Zacznij tutaj

> Co agent AI może zrobić z DevHub, jak się połączyć i które narzędzie wywołać najpierw przy danej potrzebie.

DevHub to aplikacja desktopowa. Jej serwer MCP daje Ci narzędzia do czterech rzeczy: vaulty wiedzy (notatki o tym, jak i dlaczego praca jest wykonywana), indeks repozytorium (symbole, wywołujący, wpływ zmiany), plany i śledztwa (praca podzielona na kroki, które bierzesz po jednym) oraz pliki i skrypty w repozytoriach, do których masz dostęp.

Używaj tych narzędzi zamiast własnego przeszukiwania. Vault zwykle ma już odpowiedź na pytania „jak” i „dlaczego”, a indeks odpowiada na „gdzie to jest” i „co się zepsuje” bez czytania każdego pliku.

## Połącz się

1. Użytkownik uruchamia serwer MCP w DevHub. Działa on tylko, gdy trwa sesja. Zobacz [Serwer MCP](/pl/devhub/features/mcp-server/index.md).
2. Użytkownik kopiuje adres MCP z Pulpitu (karta serwera MCP, **Kopiuj adres MCP**) i wkleja go w kliencie albo używa **Skonfiguruj folder** na stronie **Instalacje harnessów**, aby DevHub zapisał pliki klienta. Zobacz [Podłączenie klienta AI](/pl/devhub/getting-started/connect-client/index.md).
3. Nie znasz adresu i nie możesz go odgadnąć. Jeśli brakuje narzędzi DevHub na liście narzędzi, powiedz użytkownikowi, by uruchomił serwer MCP i podłączył klienta. Nie szukaj adresu w plikach.
4. Klient może pokazywać narzędzia DevHub tylko z nazwy. Załaduj schemat narzędzia, zanim je wywołasz.

## Gdy chcesz X, wywołaj Y

| Gdy chcesz                                             | Wywołaj                                                                    | Zamiast                           |
| ------------------------------------------------------ | -------------------------------------------------------------------------- | --------------------------------- |
| zacząć zadanie                                         | `context_pull` (użytkownik mógł zakolejkować dla Ciebie notatki i symbole) | szukać od razu                    |
| wiedzieć, których repozytoriów możesz dotykać          | `workspace_list`                                                           | zgadywać `workspaceId`            |
| wiedzieć, które vaulty możesz czytać lub zapisywać     | `vault_list`                                                               | zgadywać `vaultId`                |
| zobaczyć, co zawiera vault                             | `vault_overview`                                                           | przechodzić po folderach          |
| dowiedzieć się, jak lub dlaczego coś działa            | `knowledge_search` w vaulcie repozytorium                                  | czytać najpierw kod               |
| znaleźć notatkę po słowach w niej albo jej ścieżkę     | `vault_files_search`                                                       | budować ścieżkę z tytułu          |
| przeczytać notatkę                                     | `vault_file_read` ze ścieżką z listy lub wyszukiwania                      | otwierać pliki z dysku            |
| poznać kształt bazy kodu                               | `repo_overview`                                                            | przechodzić po folderach          |
| znaleźć funkcję, klasę lub plik                        | `repo_symbol_search`                                                       | `files_search` dla definicji      |
| dowiedzieć się, kto coś wywołuje                       | `repo_callers`                                                             | grep po nazwie                    |
| dowiedzieć się, co zmiana zepsuje                      | `repo_impact`                                                              | czytać każdego wywołującego       |
| znaleźć tekst, ustawienie lub komentarz                | `files_search`                                                             | powłokę                           |
| zmienić plik                                           | `file_replace` lub `file_edit`                                             | `file_write` na istniejącym pliku |
| sprawdzić zmianę                                       | `npm_script_run` z zadeklarowanym skryptem, potem `repo_changed`           | powiedzieć, że gotowe             |
| zbadać coś przed budowaniem                            | `investigation_list`, potem `investigation_create`                         | notatki w odpowiedzi              |
| wykonać pracę dłuższą niż jeden commit                 | `plan_ready`, `plan_claim`, potem krok                                     | listę zadań w odpowiedzi          |
| zapisać, co poszło źle                                 | `learning_note`                                                            | milczenie                         |
| zapisać, jak użytkownik chce, by praca była wykonywana | `memory_note`                                                              | milczenie                         |
| znaleźć istniejący skill, regułę lub personę           | `library_list`                                                             | pisać własne                      |
| zapytać innego skonfigurowanego agenta                 | `agent_list`, potem `agent_run`                                            | robić to dwa razy                 |

## Kolejność na początku zadania

1. `context_pull`. Opróżnia kolejkę; użyj `context_get`, jeśli ktoś inny nadal jej potrzebuje.
2. `workspace_list` i `vault_list`, jeśli nie masz `workspaceId` i `vaultId`. Bierz je z wyników. Nigdy ich nie wymyślaj.
3. `vault_overview` na vaulcie repozytorium, zanim zmienisz kod.
4. `knowledge_search` z pytaniem, zanim otworzysz kod źródłowy.
5. `repo_index_status`. Jeśli indeks jest nieaktualny lub go brak, `repo_index_refresh`. Potem narzędzia `repo_*`.
6. Pracujesz z planu? Najpierw `plan_ready`. Nigdy nie zakładaj, że krok jest wolny, bo wygląda na następny.

## Trzy wywołania na początek

Szukanie w vaulcie: `vault_list` daje `vaultId`; potem `knowledge_search` z `{ "vaultId": "<id>", "query": "jak działa X" }`. Wynik przeczytasz przez `knowledge_get` (`id`) lub `vault_file_read` (`vaultId`, `path` z wyniku). Gdy nic nie znajdzie, spróbuj `vault_files_search`.

Szukanie kodu: `workspace_list` daje `workspaceId`; potem `repo_index_status` i `repo_symbol_search` z `{ "workspaceId": "<id>", "query": "nazwa" }`.

Wzięcie kroku planu: `plan_ready` wylistuje wolne kroki; potem `plan_claim` z `{ "planId": "<id>", "stepId": "<id>", "by": "<Twoja nazwa>" }`. Pracuj w zwróconym katalogu roboczym, zrób commit, potem `plan_close` z sha commitów i `step_log` z opisem, co zrobiono. Zobacz [Przepływy pracy](/pl/devhub/for-agents/workflows/index.md).

## Zasady, które oszczędzają nieudane wywołanie

- Podawaj `vaultId` w każdym wywołaniu `vault_*` i `workspaceId` w każdym wywołaniu `file_*`, `repo_*` i `npm_*`.
- Bierz ścieżki z listy lub wyniku wyszukiwania, nie z tytułu.
- Najpierw czytaj, potem zapisuj. `file_edit` i `vault_file_edit` wymagają `expectedHash` i numerów linii z odczytu.
- Błąd mówi, co poprawić. Popraw argument i wywołaj ponownie. Zobacz [Błędy](/pl/devhub/for-agents/errors/index.md).
- Zanim powiesz, że praca jest skończona, uruchom własne kontrole projektu i obejrzyj wynik.

## Dalej

- [Użycie narzędzi](/pl/devhub/for-agents/mcp-tools/index.md)
- [Przepływy pracy](/pl/devhub/for-agents/workflows/index.md)
- [Ograniczenia](/pl/devhub/for-agents/limits/index.md)