Jak wygląda ustandaryzowany Agentic SDLC
- data
- kategoria
- AI Agents
- także w
- AI Engineering · Engineering Practices
- czytanie
- 3 min / 580 słów
Zaczęliśmy od managed agenta.
Nie dodawaliśmy usług dlatego, że istnieją.
Każdy element pojawił się dlatego, że przy skali organizacji powstawał konkretny problem.
Finalny flow Implementer Agenta wygląda tak:
JIRA
issue -> Ready for AI
|
v
TRIGGER
Jira Automation / event layer
|
v
MANAGED RUNTIME
Foundry / AgentCore / Vertex
|
v
IMPLEMENTER AGENT
|
v
jira.get_issue(PAY-123)
|
v
create workspace
|
v
git clone payments-service
|
v
read AGENTS.md
|
v
need external knowledge?
|-- no
`-- yes -> RAG
|
v
implement
|
v
run tests
|
v
GitHub tool / MCP
|
v
create PR
Wokół tego flow organizacja zapewnia:
models
identity
policies
state / memory
observability
security controls
evals
Co organizacja standaryzuje
| Obszar | Co jest wspólne |
|---|---|
| Trigger | sposób uruchamiania ról agentów z eventów SDLC |
| Models | zatwierdzone modele i sposób dostępu |
| Agent template | podstawowa struktura repo agenta |
| Workspace | bootstrap, clone, branch, base image |
| RAG | wspólne engineering knowledge sources |
| Tools | zatwierdzone MCP/tools i auth |
| Runtime | hosting, identity, scaling |
| State / memory | mechanizm trwałości |
| Human-in-the-loop | pause/resume, kanały pytań, timeout i eskalacja |
| Observability | traces, logs, metrics, dashboards |
| Security | guardrails, DLP, tool policies |
| Evals | sposób mierzenia zachowania i quality gates |
Evals są częścią normalnego cyklu życia agenta
Evals nie są jednorazowym testem wykonywanym przy pierwszym wdrożeniu.
W praktyce organizacja może przyjąć prosty rytm:
każdy PR agenta
-> mały regression suite
zmiana modelu / promptu / RAG / tools
-> rozszerzony suite
release
-> pełna regresja + baseline comparison
produkcja
-> sampling realnych traces
okresowo
-> ponowna pełna regresja
Dzięki temu agent jest kontrolowany podobnie jak inne elementy SDLC: nie tylko przed pierwszym wdrożeniem, ale przez cały lifecycle.
Co nadal definiuje zespół
Zespół nadal odpowiada za sens swojej roli.
Dla Implementer Agenta określa:
- kiedy task jest gotowy,
- czego agent ma dokonać,
- jakie repo i workflow obsługuje,
- które tools są mu potrzebne,
- jakie instrukcje są specyficzne dla produktu,
- jakie eval cases naprawdę reprezentują poprawną pracę.
Role agentów
Implementer Agent jest tylko pierwszym przykładem.
Tak samo można zbudować:
Reviewer Agent
-> uruchamiany na PR
Incident Agent
-> uruchamiany na incydent
Release Agent
-> uruchamiany przed releasem
Każda rola ma własny wewnętrzny workflow.
Nie tworzymy osobnego agenta dla każdego kroku.
Implementer Agent:
ticket
-> code
-> tests
-> PR
Reviewer Agent:
PR
-> diff
-> context
-> review
Narzędzia: mapa rynku
| Warstwa | Azure | AWS | GCP | Niezależne |
|---|---|---|---|---|
| Models / AI platform | Microsoft Foundry | Amazon Bedrock | Vertex AI | direct provider APIs |
| Events | Event Grid / Functions | EventBridge / Lambda | Eventarc / Cloud Run | webhooks |
| Runtime | Foundry Agent Service | AgentCore Runtime | Vertex AI Agent Engine | Kubernetes |
| RAG | Azure AI Search | Bedrock Knowledge Bases / OpenSearch | Vertex AI RAG Engine | Pinecone, Weaviate |
| Tools / MCP | Foundry tools / MCP | AgentCore Gateway | Agent Gateway / MCP | własny MCP |
| State / memory | Foundry state / Cosmos DB | AgentCore Memory | Sessions / Memory Bank | własna warstwa |
| Observability | App Insights / Foundry Tracing | CloudWatch / AgentCore Observability | Cloud Trace / Monitoring | OpenTelemetry, Langfuse |
| Security | Foundry Guardrails / Prompt Shields | Bedrock Guardrails / AgentCore Policy | Vertex safety / DLP | custom controls |
| Evals | Foundry Evaluations | Bedrock / AgentCore Evaluations | Vertex Gen AI Evaluation | LangSmith, Phoenix |
Najważniejsza zmiana po poprzedniej serii
W poprzedniej serii pytaliśmy:
Jak zbudować i uruchomić skutecznego agenta?
Tutaj pytanie jest inne:
Jak sprawić, żeby wiele zespołów mogło budować różne role agentów na wspólnej platformie, a organizacja nadal wiedziała, co te agenty robią, do czego mają dostęp, ile kosztują i czy działają poprawnie?
To jest kolejny etap: standaryzacja AI w SDLC na poziomie organizacji.
Nie więcej autonomii dla jednego agenta.
Więcej standaryzacji, observability i kontroli wokół całego sposobu pracy z agentami.