Konrad Kowalski (rootsher)Principal Platform & Reliability Architect101100011100001101011101010011110110011010011000

Repo agenta i workspace

data
kategoria
AI Agents
także w
Infrastructure · Engineering Practices
czytanie
1 min / 243 słów

W local environment dużo rzeczy było niewidoczne, bo już istniały.

Developer miał:

text
repo sklonowane
git skonfigurowany
SDK zainstalowane
dependencies zainstalowane
credentials działające

Managed Implementer Agent nie dostaje tego automatycznie.

Ktoś musi opisać, jak przygotować mu środowisko pracy.

Repo agenta

Najprostszy układ:

text
engineering-agents/
└── implementer/
    ├── agent.py
    ├── workflow.py
    ├── workspace.py
    ├── tools.py
    └── evals/

To repo definiuje rolę Implementer Agenta.

Na przykład:

text
1. odbierz task
2. pobierz ticket
3. przygotuj workspace
4. clone repo
5. checkout branch
6. przeczytaj instrukcje repo
7. implementuj
8. test
9. push
10. utwórz PR

Skąd agent zna repo

Najlepiej nie zgadywać.

Payload z Jira może zawierać:

json
{
  "issueKey": "PAY-123",
  "repository": "org/payments-service",
  "baseBranch": "main"
}

albo repository może być polem w ticketcie.

Workspace

Repo agenta wykonuje mniej więcej:

text
create workspace
|
v
git clone org/payments-service
|
v
checkout main
|
v
create branch agent/PAY-123
|
v
run project setup

Repo produktu

Po clone agent znajduje:

text
payments-service/
├── AGENTS.md
├── src/
├── tests/
└── docs/

I tu następuje ważne rozdzielenie:

text
repo agenta
-> jak wykonać task

repo produktu
-> jak pracować nad tym konkretnym kodem

AGENTS.md może powiedzieć:

text
- setup: ./scripts/setup.sh
- test: ./scripts/test.sh
- nie modyfikuj generated/
- ADR-y są w docs/adr/

Gdzie żyją credentials

Nie w repo agenta i nie w repo produktu.

GitHub access powinien być dostarczony przez platformę:

text
Agent identity
|
v
GitHub App / OAuth / managed secret
|
v
GitHub

Narzędzia i runtime'y

OpcjaCloudRola
Foundry Hosted AgentsAzureuruchomienie własnego kodu agenta jako managed workload
Bedrock AgentCore RuntimeAWSmanaged runtime dla własnych agentów
Vertex AI Agent EngineGCPmanaged deployment i runtime agentów
Kubernetes / container runtimedowolnepełna kontrola, ale więcej pracy platformowej

Co standaryzuje organizacja

Przy większej skali warto dostarczyć:

  • template repo agenta,
  • standard workspace path,
  • wspólny sposób clone/checkout,
  • standard branch naming,
  • gotowy GitHub access,
  • standardowe obrazy runtime z potrzebnymi SDK.

Wtedy każdy zespół nie wymyśla bootstrapu od początku.

Materiały

do góry