Notatki praktyczne: Grafy kontekstowe dla agentów AI: Nadanie sztucznej inteligencji pamięci osoby doświadczonej
Szczegółowy przewodnik po Notatkach praktycznych: Grafy kontekstowe dla agentów AI: Nadanie sztucznej inteligencji pamięci osoby doświadczonej: umowy, sprawdzenia oraz gotowe elementy kodu dla zespołów wdrażających ten wzorzec.
Dlaczego następne pokolenie agentów AI potrzebuje czegoś więcej niż wyszukiwanie wektorowe, embeddingi i większe okna kontekstowe
Należy podać fragmenty tekstu, które faktycznie stanowią podstawę odpowiedzi. Bez cytatów operatorzy nie mogą odróżnić halucynacji od luki w indeksowaniu.
Czym jest graf kontekstowy?
EmployeeController.java exists.
ReimbursementService.java exists.
SecurityConfig.java exists.
ADR-17.md exists.
EmployeeController
|
| follows_pattern
v
EmployeeApiConvention
|
| requires
v
TenantValidation
ReimbursementEndpoint
|
| handled_by
v
ReimbursementOrchestrator
|
| writes_to
v
ReimbursementRepository
|
| persists
v
HrReimbursement
ReimbursementEndpoint
|
| governed_by
v
ADR-17
ADR-17
|
| created_because_of
v
ProductionIncident-928
Graf to w zasadzie kropki i linie
W fazie A Graph Is Basically należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżki naprawcze. Próby ponownych działań, kontrola przez ludzi oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka dla operacji, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności funkcjonalności produktu. W fazie A Graph Is Basically należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
Node ---- Relationship ---- Node
Vaibhav ---- works_at ---- PeopleStrong
Controller ---- calls ---- Service
Service ---- calls ---- Repository
Repository ---- writes_to ---- DatabaseTable
Endpoint ---- protected_by ---- Permission
Feature ---- explained_by ---- ADR
ADR ---- resulted_from ---- Incident
Test ---- validates ---- Endpoint
Graph wiedzy a graph kontekstowy
Gdy przechodzisz przez etap porównania Graphu wiedzy z Graphem kontekstowym, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czas wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Employee
WORKS_FOR
Organization
Order
BELONGS_TO
Customer
PaymentService
USES
PaymentRepository
PaymentService
USES
PaymentRepository
PaymentService
GOVERNED_BY
ADR-12ADR-12
CREATED_AFTER
Incident-492PaymentService
REQUIRES
FinancePermissionPaymentRepository
WRITES_TO
PaymentTransactionPaymentTransaction
MUST_BE_SCOPED_BY
OrganizationIDPaymentTransaction
MUST_BE_SCOPED_BY
TenantID
Najważniejsza część: Graphy kontekstowe przechowują „dlaczego”
Gdy przechodzisz przez etap „Najważniejsza część”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustaw punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator ponawia próbę z późniejszym węzłem.
Discount = 25%
Approved = true
ApprovedBy = 182
Customer-482
RECEIVED
25% Discount
25% Discount
APPROVED_BY
SalesDirector25% Discount
EXCEPTION_TO
StandardDiscountPolicyException
BECAUSE
CustomerMigrationRiskCustomerMigrationRisk
DOCUMENTED_IN
Opportunity-928Decision
PRODUCED
SuccessfulRenewal
Główne komponenty grafu kontekstowego
Gdy pracujesz nad podstawowymi komponentami danej etapy, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno prawidłowy przebieg działania, jak i ścieżkę naprawczą. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy pracujesz nad podstawowymi komponentami danej etapy, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj tę etapę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
1. Entity — Rzeczy, które istnieją
Faza „1 Entities The Things” działa najlepiej, gdy traktuje się ją jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Repository
Module
Package
Class
Method
API Endpoint
Database Table
Database Column
Configuration
Skill
Rule
Architecture Decision
Pull Request
Commit
Issue
Incident
Test
Developer
Team
Node: ReimbursementController
Type: JavaClass
Path: services/hr/.../ReimbursementController.java
Node: POST /reimbursements
Type: Endpoint
Node: HrReimbursement
Type: DatabaseTable
2. Związki — Jak rzeczy się łączą
Dwie relacje: systemy typu Things funkcjonują najlepiej, gdy traktuje się je jako mierzalną powierzchnię. Zapisz jeden idealny przypadek, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całego grafu. Utrzymuj stan grafu w formie prostych, typizowanych struktur. Wkładki nawiasowe ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwanie kontynuacji po przerwach.
ReimbursementController
EXPOSES
POST /reimbursements
POST /reimbursements
CALLS
ReimbursementService
ReimbursementService
USES
ReimbursementRepository
ReimbursementRepository
WRITES_TO
HrReimbursement
POST /reimbursements
REQUIRES_PERMISSION
CREATE_REIMBURSEMENT
ReimbursementService
FOLLOWS_PATTERN
OrchestratorPattern
3. Właściwości — szczegóły dotyczące węzłów i relacji
3 szczegóły właściwości dotyczące etapu działają najlepiej, gdy traktuje się je jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań przed rozszerzeniem zakresu. Zdokumentuj zarówno ścieżkę pomyślnego przebiegu, jak i ścieżkę przywracania stanu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości nieodebranych stanowią część produktu, a nie elementy dodawane później. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, co powoduje przerwanie kontynuacji po przerwach. 3 szczegóły właściwości dotyczące etapu działają najlepiej, gdy traktuje się je jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań przed rozszerzeniem zakresu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi danymi wyjściowymi. Nadaj nazwy artefaktom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
JavaClass:
name = ReimbursementController
language = Java
framework = Spring Boot
module = hr-service
Endpoint:
method = POST
path = /api/v1/reimbursements
authenticationRequired = true
Service
CALLS
Repository
since = 2026-04-18
confidence = 1.0
source = static-analysis
4. Czas
Dla etapu 4 Time należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Konieczne jest ludzkie zatwierdzenie w przypadkach, gdy dochodzi do wydatków lub zmian w danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
Controller
USES
FieldInjection
FieldInjectionPattern
validUntil = 2025-01-15
ConstructorInjectionPattern
validFrom = 2025-01-16
5. Pochodzenie — Skąd pochodzi ta informacja?
Dla etapu 5 Provenance Where Did należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Wprowadź ludzką aprobatę dla operacji, które wiążą się z wydawaniem pieniędzy lub modyfikacją danych produkcyjnych. Połączenia skompilowane w czasie kompilacji nie równają się pełności funkcjonalności biznesowej.
Rule:
All employee APIs must validate TenantID.
Rule
EXTRACTED_FROM
ADR-0027.md
Rule
OBSERVED_IN
14 Production Endpoints
Rule
INTRODUCED_BY
PR-8421
6. Pamięć krótkoterminowa
Dla etapu 6 Krótkotrwałej Pamięci należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrola przez ludzi oraz obsługa nieudanych transakcji stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka w przypadkach, gdy dochodzi do wydawania pieniędzy lub zmiany danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności rozwiązania biznesowego. Dla etapu 6 Krótkotrwałej Pamięci należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy traktować ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
CurrentTask
TARGETS
AdminAPI
CurrentTask
EXCLUDES
EmployeeApp
7. Pamięć długoterminowa
Podczas przechodzenia przez etap 7 Pamięci długoterminowej najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas trwania oraz koszt tokenów lub zapytań. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. Program powinien unikać ponownego naliczania tych samych kosztów za wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Repository
USES
Java17
Repository
USES
SpringBoot3EndpointCreation
REQUIRES
ControllerTestEndpointCreation
REQUIRES
ServiceTest
8. Pamięć decyzyjna lub rozumowa
Gdy przechodzisz przez 8 etapów decyzyjnych lub rozumowania, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całego grafu. Zachowuj w pamięci podręcznej stabilne instrukcje systemowe oraz schematy narzędzi. Ponowne wysyłanie identycznego preambułu jest częstą przyczyną marnotrawstwa zasobów.
Approach A:
Controller -> Repository
Business logic must pass through the service/orchestrator layer.
Approach-A
REJECTED_BECAUSE
ArchitectureRule-42
Jak więc faktycznie działa graf kontekstowy?
Gdy pracujesz nad etapem So How Does the, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę pomyślną, jak i ścieżkę naprawczą. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy pracujesz nad etapem So How Does the, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
Task:
Create Endpoint
Domain:
ReimbursementOperation:
ApproveActor:
Admin
Krok 1 — Znajdź węzły początkowe
Krok 1: Znalezienie etapu działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Reimbursement
Approve
Endpoint
Admin
ReimbursementController
ReimbursementService
HrReimbursement
ReimbursementStatus
APPROVE_REIMBURSEMENT permission
ReimbursementWorkflow
Krok 2 — Rozszerzenie ich relacji
Etap 2 „Rozszerzanie zakresu” działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zanim rozszerzysz zakres, zapisz jeden idealny przypadek działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Utrzymuj stan struktury w formie prostych, typizowanych elementów. Wplecione bloki danych ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwania w kontynuacji pracy po interwencjach.
ReimbursementController
|
+--- FOLLOWS_PATTERN ---> ExpenseController
|
+--- CALLS -------------> ReimbursementService
|
+--- PROTECTED_BY ------> FinancePermission
ReimbursementService
|
+--- USES --------------> ReimbursementOrchestrator
ReimbursementOrchestrator
|
+--- WRITES_TO ---------> HrReimbursement
|
+--- GOVERNED_BY -------> ADR-24
ADR-24
|
+--- CREATED_AFTER -----> Incident-842
Etap 3 — Filtrowanie struktury
Faza Filtracji Kroku 3 działa najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres. Zdokumentuj zarówno ścieżkę pomyślnego działania, jak i ścieżkę przywracania stanu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach. Faza Filtracji Kroku 3 działa najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi danymi wyjściowymi. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
current branch
current module
task
user permission
repository version
organization
time
confidence
Krok 4 — Budowanie kontekstu agenta
W kroku 4, czyli tworzeniu etapu, należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Obok wyników funkcjonalnych należy zapisywać czas trwania oraz koszt tokenów lub zapytań. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Zatwierdzenie przez człowieka powinno być wymagane w przypadkach, gdy dochodzi do wydawania pieniędzy lub modyfikacji danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie gwarantują pełnej kompletności rozwiązania biznesowego.
TASK
Create reimbursement approval endpoint.
RELEVANT PATTERN
ExpenseApprovalController.REQUIRED ARCHITECTURE
Controller -> Service -> Orchestrator -> Repository.SECURITY
Permission APPROVE_REIMBURSEMENT required.TENANCY
Queries must include OrganizationID and TenantID.DATABASE
HrReimbursement.IMPORTANT DECISION
ADR-24 prohibits direct status updates.TEST PATTERN
ExpenseApprovalControllerTest.
Krok 5 — Agent wykonywa pracę
W etapie 5 „Agent Performs” należy zdefiniować dane wejściowe, osobę odpowiedzialną za ten krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Zastosuj ludzką aprobatę dla operacji, które wiążą się z wydawaniem pieniędzy lub modyfikacją danych produkcyjnych. Połączenia ustalone w czasie kompilacji nie równają się pełności funkcjonalności biznesowej.
Controller
Request DTO
Response DTO
Service
Orchestrator
Repository query
Authorization
Tenant filtering
Tests
Krok 6 — Przechowywanie informacji o tym, co się wydarzyło
W etapie 6 „Store What” należy zdefiniować dane wejściowe, osobę odpowiedzialną za ten etap oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten etap od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrola przez ludzi oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka w przypadkach, gdy dochodzi do wydawania pieniędzy lub zmiany danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności funkcjonalności biznesowej. W etapie 6 „Store What” należy zdefiniować dane wejściowe, osobę odpowiedzialną za ten etap oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten etap od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
PR-9928
IMPLEMENTED
ReimbursementApprovalEndpoint
ReimbursementApprovalEndpoint
FOLLOWS
OrchestratorPattern
PR-9928
VALIDATED_BY
ArchitectureTests
Baza danych wektorowych a graf kontekstowy
Gdy zajmujesz się krokiem porównania bazy danych wektorowych z grafem kontekstowym, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czas wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utwórz punkt kontrolny po kosztownych krokach. Funkcja wznowienia nie powinna ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
EmployeeController.java
EmployeeService.java
EmployeeRepository.java
SecurityConfig.java
ADR-17.md
Incident-928.md
EmployeeControllerTest.java
add-end-point/SKILL.md
Czym jest wyszukiwanie wektorowe
Gdy przechodzisz przez etap „Co to jest wyszukiwanie wektorowe”, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całego grafu. Ustaw punkty kontrolne po kosztownych krokach. Funkcja wznowienia nie powinna ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
EmployeeController.java similarity 0.94
CandidateController.java similarity 0.89
EndpointGuide.md similarity 0.87
EmployeeService.java similarity 0.82
ADR-17.md
Czym jest graf kontekstowy
Gdy przechodzisz przez etap „What a Context Graph”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap „What a Context Graph”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
EmployeeEndpoint
EmployeeEndpoint
MUST_FOLLOW
EmployeeApiPattern
EmployeeApiPattern
REQUIRES
TenantIsolation
TenantIsolation
DEFINED_BY
ADR-17
ADR-17
INTRODUCED_AFTER
SecurityIncident-28
Pytania związane z wyszukiwaniem wektorowym:
Etap „Pytania związane z wyszukiwaniem wektorowym” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia. Zapisz jeden idealny przypadek, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań przed rozszerzeniem zakresu. Zapisz czasy wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w formie prostych, spójnych struktur. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane w danym polu, i powodują przerwanie kontynuacji po zakłóceniach.
Pytania związane z grafem kontekstowym:
Graph Context Asks stage funkcjonuje najlepiej, gdy traktowany jest jako mierzalna struktura. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny poufnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Utrzymuj stan grafu w prostym formacie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, co utrudnia kontynuację pracy po przerwach.
Ale nie wyrzucaj swojej bazy danych wektorowych
Etap „The But Do Not Throw” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepływ działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Zdokumentuj zarówno pomyślny, jak i awaryjny przebieg procesu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, co utrudnia kontynuację pracy po przerwach. Etap „The But Do Not Throw” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepływ działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
Vector Search
+
Graph Traversal
+
Metadata Filters
+
Keyword Search
+
Agent Reasoning
Prosty model mentalny
W fazie „Prosty model mentalny” należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Przy następnym kroku, który polega na pisaniu kodu lub wywoływaniu narzędzia, należy preferować ustrukturyzowane wyniki z walidacją schematu zamiast tekstów w formie swobodnej.
Grafy kontekstowe w repozytorium Git
Dla grafów kontekstowych wewnątrz etapu należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całego grafu. Wprowadź procedurę zatwierdzenia przez człowieka dla krawędzi, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia skompilowane w czasie kompilacji nie równają się pełności funkcjonalności biznesowej.
employee-platform/
│
├── services/
│ ├── employee-service/
│ ├── payroll-service/
│ └── recruitment-service/
│
├── docs/
│ └── adr/
│
├── database/
│ └── migrations/
│
├── .agents/
│ ├── AGENTS.md
│ │
│ ├── skills/
│ │ └── add-end-point/
│ │ ├── SKILL.md
│ │ ├── templates/
│ │ └── references/
│ │
│ └── context/
│ ├── repository.yml
│ ├── architecture.yml
│ └── rules.yml
add-end-point
Projektowanie grafu kontekstowego repozytorium
W fazie projektowania kontekstu repozytorium należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżkę naprawczą. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka w przypadkach, gdy dochodzi do wydawania pieniędzy lub zmiany danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności rozwiązania biznesowego. W fazie projektowania kontekstu repozytorium należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
Repository
Module
Service
Class
Method
Endpoint
DatabaseTable
DatabaseColumn
Skill
ArchitecturePattern
Rule
Permission
ADR
Issue
PullRequest
Commit
Test
Repository CONTAINS Module
Module CONTAINS ClassController EXPOSES EndpointEndpoint CALLS ServiceService USES RepositoryRepository READS_FROM TableRepository WRITES_TO TableEndpoint REQUIRES PermissionClass TESTED_BY TestClass FOLLOWS PatternPattern DEFINED_IN ADRRule GOVERNED_BY ADRCommit CHANGES ClassPullRequest CONTAINS CommitIssue RESOLVED_BY PullRequestSkill APPLIES_TO EndpointSkill REQUIRES Rule
Niewielki przykładowy graf
Podczas prace nad etapem Niewielkiego przykładowego grafu najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłaty za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
EmployeeController
|
| CALLS
v
EmployeeService
|
| DELEGATES_TO
v
EmployeeHandler
|
| USES
v
EmployeeRepository
|
| WRITES_TO
v
HrEmployee
EmployeeController
|
| REQUIRES
v
EmployeePermission
EmployeeRepository
|
| FILTERS_BY
+----> TenantID
|
+----> OrganizationID
EmployeeController
|
| TESTED_BY
v
EmployeeControllerTest
add-end-point
|
| USES_PATTERN
v
EmployeeEndpointPattern
Jak budujemy ten graf?
Gdy przechodzisz przez etap „How Do We Build”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Java source
imports
method calls
Spring annotations
package structure
repository interfaces
SQL queries
DDL
configuration
test classes
Git history
ADR documents
AGENTS.md
SKILL.md
Faza 1 — Analiza statyczna kodu
Gdy przechodzisz przez etap Kodu Statycznego z Fazy 1, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap Kodu Statycznego z Fazy 1, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
@RestController
@RequestMapping("/employees")
public class EmployeeController {
private final EmployeeService employeeService; @PostMapping
public EmployeeResponse create(
@RequestBody EmployeeRequest request) {
return employeeService.create(request);
}
}
EmployeeController
TYPE
Controller
EmployeeController
EXPOSES
POST /employeesEmployeeController
CALLS
EmployeeService.create
Faza 2 — Analiza repozytorium
Etap analizy repozytorium w fazie 2 działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w formie prostych, spójnie skategoryzowanych elementów. Wplecione struktury ukrywają informacje o tym, który węzeł zapisał dane w danym polu, i powodują przerwę w kontynuacji pracy po zakłóceniach.
public interface EmployeeRepository
extends JpaRepository<EmployeeEntity, Long> {
}
EmployeeRepository
OPERATES_ON
EmployeeEntity
@Entity
@Table(name = "HrEmployee")
EmployeeEntity
MAPS_TO
HrEmployee
Faza 3 — Historia w Git
Faza 3 historii Git funkcjonuje najlepiej, gdy traktowana jest jako mierzalna struktura. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres pracy. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności przeglądania całej struktury. Utrzymuj stan struktury w formie prostych, typizowanych elementów. Wplecione bloki danych ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwę w kontynuacji pracy po zakłóceniach.
Commit 812ac3
Message:
Add tenant filtering to employee repository.
Reason:
Prevent cross-tenant access.
EmployeeRepository
CHANGED_IN
Commit-812ac3
Commit-812ac3
PART_OF
PR-982PR-982
INTRODUCED
TenantIsolationRule
Faza 4 — Dokumentacja architektury
Etap dokumentacji architektury fazy 4 funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zdokumentuj zarówno prawidłowy przebieg działania, jak i ścieżkę przywracania do stanu poprzedniego. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości nieodebranych stanowią część produktu, a nie elementy dodawane później. Utrzymuj strukturę grafu w prostym formacie i z określonym typem danych. Wkładki nawiasowe ukrywają informację o tym, który węzeł zapisał dane w danym polu, co utrudnia kontynuację pracy po przerwach. Etap dokumentacji architektury fazy 4 funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
All employee mutations must pass through the EmployeeHandler.
EmployeeMutation
MUST_USE
EmployeeHandler
rule source:
ADR-17
Faza 5 — Umiejętności AI
W fazie 5, dotyczącej umiejętności AI, należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Zatwierdzenie przez człowieka powinno być wymagane w przypadkach, gdy dochodzi do wydawania pieniędzy lub modyfikacji danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie gwarantują pełnej kompletności rozwiązania biznesowego.
.agents/skills/add-end-point/SKILL.md
Before creating an endpoint:
1. Identify the nearest existing endpoint pattern.
2. Resolve authentication and authorization rules.
3. Resolve tenant and organization isolation.
4. Identify service/orchestrator pattern.
5. Identify persistence pattern.
6. Identify required tests.
get_context(
task="create-endpoint",
domain="employee",
operation="create"
)
Służba Graph Context
W fazie The Context Graph Service należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Zatwierdzenie ludzkie jest konieczne dla połączeń, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia skonstruowane w czasie kompilacji nie gwarantują pełnej kompletności biznesowej.
AI Agent
|
v
Context API / MCP Server
|
+--------> Graph Database
|
+--------> Vector Database
|
+--------> Git Repository
find_entity
get_neighbors
find_path
get_architecture_context
get_security_context
get_database_context
get_change_history
get_similar_implementations
get_context_for_task
record_decision
get_context_for_task(
repository="employee-platform",
skill="add-end-point",
task="create reimbursement approval endpoint"
)
Jaki bazę danych grafowych powinniśmy użyć?
Dla etapu What Graph Database Should należy zdefiniować dane wejściowe, osobę odpowiedzialną za daną czynność oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić tę czynność od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżkę naprawczą. Próby ponownego wykonania, kontrola przez ludzi oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka dla operacji, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności funkcjonalności produktu. Dla etapu What Graph Database Should należy zdefiniować dane wejściowe, osobę odpowiedzialną za daną czynność oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić tę czynność od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
JSON files
+
NetworkX
+
SQLite
Bardzo prosta reprezentacja w stylu Neo4j
Gdy przechodzisz przez etap „Bardzo prosta reprezentacja w stylu Neo4j”, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłaty za ten sam wywołanie LLM, gdy operator próbuje ponownie przetworzyć późniejszy węzeł.
CREATE (:Class {
name: "EmployeeController",
type: "Controller"
});
CREATE (:Service {
name: "EmployeeService"
});CREATE (:Repository {
name: "EmployeeRepository"
});
MATCH (c:Class {name:"EmployeeController"}),
(s:Service {name:"EmployeeService"})
CREATE (c)-[:CALLS]->(s);
MATCH (s:Service {name:"EmployeeService"}),
(r:Repository {name:"EmployeeRepository"})
CREATE (s)-[:USES]->(r);
Zapytania do grafu
Gdy przechodzisz przez etap zapytań do grafu, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całego grafu. Ustaw punkty kontrolne po kosztownych krokach. Funkcja wznowienia nie powinna ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
MATCH path =
(endpoint:Endpoint)-[*1..4]-(context)
WHERE endpoint.domain = "employee"
RETURN path
Controller
Service
Handler
Repository
Table
Permission
Tenant Rule
Tests
ADR
Lepsza architektura: hybrydowe wyszukiwanie
Gdy przechodzisz przez etap A Better Architecture Hybrid, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę odzyskiwania. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dopinane później. Zmierz stopień odzyskiwania informacji na ustalonej grupie pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe mechanizmy wyszukiwania. Gdy przechodzisz przez etap A Better Architecture Hybrid, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
User Request
|
v
Context Retriever
|
+--------------+--------------+
| | |
v v v
Vector Graph Keyword
Search Traversal Search
| | |
+--------------+--------------+
|
v
Context Ranking
|
v
Agent Context
|
v
LLM
Problem budżetu kontekstu
Faza problemu budżetu kontekstowego funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę o cofnięciu działań, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wkładki nawiasowe ukrywają informację o tym, który węzeł zapisał dane do którego pola, co powoduje przerwanie kontynuacji po przerwach.
Repository:
8 million tokens
Controller conventions
Service convention
Security rule
Two repositories
One ADR
Three tests
Total:
18,000 tokens
Graph kontekstowy + umiejętności agenta
Faza umiejętności Context Graph Agent działa najlepiej, gdy jest traktowana jako mierzalna struktura. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres działania. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Utrzymuj stan grafu w prostym formacie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwę w kontynuacji działania po zakłóceniach.
Developer
|
v
AI Agent
|
v
add-end-point Skill
|
v
Context Graph Query
Developer
|
| "Create employee endpoint"
v
AI Agent
|
| reads
v
.agents/skills/add-end-point/SKILL.md
|
| SKILL.md says:
| "Before generating code,
| call get_task_context"
v
MCP Tool
get_task_context(...)
|
v
Context Graph Service
|
+---- Neo4j / Graph DB
|
+---- Vector Search
|
+---- Git metadata
|
v
Relevant Context
|
v
AI Agent
|
| follows retrieved rules
v
Generate / modify code
Nearest endpoint:
LeaveRequestController
Controller pattern:
@RestController
constructor injectionService pattern:
interface + implementationArchitecture:
Controller
-> Service
-> Handler
-> RepositorySecurity:
LEAVE_VIEWTenant rules:
OrganizationID + TenantIDPersistence:
HrLeaveBalanceTesting:
ControllerTest
ServiceTest
RepositoryITArchitecture decision:
ADR-42
Następnie agent generuje kod
Etap „Then the Agent Generates” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Zdokumentuj zarówno prawidłowy przebieg operacji, jak i ścieżkę przywracania do normalnego stanu. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości nieodebranych stanowią część produktu, a nie elementy dodawane później. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, co utrudnia kontynuację pracy po przerwach.
LeaveBalanceController
LeaveBalanceRequest
LeaveBalanceResponse
LeaveBalanceService
LeaveBalanceServiceImpl
LeaveBalanceHandler
LeaveBalanceRepository
LeaveBalanceProjection
LeaveBalanceException
LeaveBalanceControllerTest
LeaveBalanceServiceTest
LeaveBalanceRepositoryTest
Etap „Then the Agent Generates” funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
Does the endpoint follow the required architecture?
YES.Does it apply security?YES.Does repository filtering include TenantID?YES.Does it include OrganizationID?YES.Are mandatory tests present?YES.
Bootstrap repozytorium
Dla etapu Bootstrap w repozytorium należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Konieczne jest ludzkie zatwierdzenie w przypadkach, gdy dochodzi do wydatków lub zmian w danych produkcyjnych. Podłączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
bootstrap-context
2-3 representative endpoints
architecture
build files
framework versions
dependency injection
security
database patterns
testing
exception handling
transactions
module boundaries
Repository
USES
Java17
Repository
USES
SpringBoot3Endpoint
FOLLOWS
Controller-Service-Handler-RepositoryDatabaseQuery
MUST_INCLUDE
TenantIDDatabaseQuery
MUST_INCLUDE
OrganizationID
Umiejętności stają się znacznie prostsze
W fazie, w której umiejętności stają się znacznie mniejsze, należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Wprowadź ludzką aprobatę dla połączeń, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia skompilowane w czasie kompilacji nie równają się pełności funkcjonalności biznesowej.
For employee APIs use EmployeeHandler.
For payroll APIs use PayrollOrchestrator.For recruitment APIs use ActionHandler.For employee APIs tenant filtering happens...For payroll APIs...
1. Understand the requested endpoint.
2. Query the repository Context Graph.3. Resolve:
- architecture pattern
- closest implementation
- security
- data ownership
- persistence
- testing requirements4. Generate code.5. Validate generated changes against graph constraints.6. Record newly confirmed repository knowledge.
Umiejętności wskazują agentowi JAK
W etapie Skills Tell the Agent należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrola przez ludzi oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Konieczna jest ludzka akceptacja w przypadkach, gdy dochodzi do wydawania pieniędzy lub zmiany danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się kompletności rozwiązania biznesowego.
Graph kontekstowy mówi agentowi, CO JEST TUTAJ PRAWDĄ
Aby graf kontekstowy wskazywał odpowiedni etap, przed modyfikacją kodu należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu systemu. Należy preferować małe, łatwe do przetestowania jednostki nad rozbudowanymi skryptami. Gdy dany krok zawiedzie, powinno to wskazywać na konkretną przyczynę, a nie na skomplikowaną strukturę procesów. Konieczne jest ludzkie zatwierdzenie dla operacji, które wiążą się z wydatkami lub zmianami w danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
Grafy kontekstowe i systemy wieloagentowe
Dla etapu grafów kontekstowych i wieloagentowych należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadań. Wymagaj ludzkiej aprobaty dla operacji, które wiążą się z wydawaniem pieniędzy lub modyfikacją danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
Architecture Agent
Security Agent
Backend Agent
Testing Agent
Database Agent
Reviewer Agent
duplicate work
different conclusions
large token usage
conflicting decisions
Context Graph
/ | \
/ | \
v v v
Backend Security Testing
Agent Agent Agent
Endpoint requires FINANCE_WRITE
Grafy kontekstowe mogą uczyć się na podstawie pull requestów
W fazie, w której grafy kontekstowe mogą się uczyć, należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Konieczne jest ludzkie zatwierdzenie dla krawędzi, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia realizowane w czasie kompilacji nie równają się pełności funkcjonalności biznesowej.
repository.findByEmployeeId(employeeId);
EmployeeRepositoryQuery
MUST_FILTER_BY
TenantID
EmployeeRepositoryQuery
MUST_FILTER_BY
OrganizationIDRule
LEARNED_FROM
PR-11882
Graph kontekstowy to nie mózg LLM
W fazie A Context Graph Is należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. W przypadku, gdy następnym krokiem jest kod lub wywołanie narzędzia, lepiej używać ustrukturyzowanych wyników z walidacją schematu niż tekstu w formie swobodnej.
LLM
=
Reasoning Engine
Context Graph
=
Structured MemoryVector Database
=
Semantic Memory SearchSkills
=
ProceduresTools
=
Actions
AI Agent
|
+---------+---------+
| | |
v v v
Skills Context Tools
Graph
|
+-------+-------+
| |
v v
Vector Graph
Search Store
Context Graph vs Fine-Tuning
W fazie Context Graph vs Fine-Tuning należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżki naprawcze. Próby ponownych działań, kontrola przez ludzi oraz obsługa błędów stanowią część produktu, a nie elementy dodawane później. Konieczne jest uzyskanie zatwierdzenia człowieka dla operacji, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności funkcjonalności produktu. W fazie Context Graph vs Fine-Tuning należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy traktować tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Należy nadać nazwy poszczególnym elementom, zdefiniować kryteria sukcesu oraz odrzucić przypadki cichego, częściowego ukończenia zadania.
OldRule
status = deprecated
NewRule
status = active
Graph kontekstowy a duży prompt
Gdy pracujesz nad etapem Graph kontekstowy a duży prompt, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokenów lub zapytań. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy przechodzi się od wersji demonstracyjnej do środowisk współdzielonych. Zachowuj w pamięci tymczasowej stabilne instrukcje systemu oraz schematy narzędzi. Ponowne wysyłanie identycznego wstępu to częsty powód marnotrawstwa zasobów.
AGENTS.md
= 40,000 lines
Task
|
v
Relevant Subgraph
|
v
Prompt
Entire Organization
|
v
Prompt
Jak wdrożyć pierwszą wersję
Gdy przechodzisz przez etap „Jak przeprowadzić implementację”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustaw punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator ponawia próbę z późniejszym węzłem.
Repository:
employee-service
Skill:
add-end-point
Module
Class
Endpoint
Service
Repository
Table
Rule
Permission
Test
ADR
CONTAINS
EXPOSES
CALLS
USES
WRITES_TO
READS_FROM
REQUIRES
TESTED_BY
FOLLOWS
DEFINED_IN
Zalecana implementacja
Gdy przechodzisz przez etap zalecanej implementacji, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Git Repository
|
|
v
Repository Indexer
|
+------ Java Parser
|
+------ Git Parser
|
+------ Markdown Parser
|
+------ SQL Parser
|
v
Context Graph DB
|
+------ Vector Index
|
v
Context Service / MCP
|
v
AI Coding Agent
|
v
Repository Skills
Aktualizuj graf stopniowo
Gdy przechodzisz przez etap aktualizacji grafu stopniowo, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Ustalaj punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
EmployeeController.java
EmployeeService.java
ADR-42.md
git diff HEAD~1
changed files
|
v
re-index
|
v
update graph
Kontekst powinien mieć pewność
Gdy przechodzisz przez etap „Context Should Have Confidence”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadania. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy element.
EmployeeController
CALLS
EmployeeService
confidence = 1.0
source = static-analysis
Employee APIs
PROBABLY_REQUIRE
ManagerPermission
confidence = 0.62
source = llm-inference
FACT
OBSERVATION
INFERENCE
DECISION
RULE
Ludzie muszą mieć możliwość korekty grafu
Gdy przechodzisz przez etap „Humans Must Be Able”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Payroll APIs use Handler architecture.
HandlerPattern
status = deprecated
OrchestratorPattern
status = active
Większa idea: od wyszukiwania w repozytorium do zrozumienia repozytorium
Gdy przechodzisz przez etap The Bigger Idea From, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustaw punkty kontrolne po kosztownych krokach. System powinien unikać ponownego naliczania opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Question
|
v
Search Files
|
v
Read Files
|
v
Generate Code
Question
|
v
Understand Task
|
v
Identify Relevant Entities
|
v
Traverse Architecture
|
v
Recover Rules
|
v
Recover History
|
v
Recover Decisions
|
v
Build Context
|
v
Execute Skill
|
v
Validate Result
|
v
Record Learning
Analogia do seniorowego inżyniera
Gdy przechodzisz przez etap analogii do pracy starszego inżyniera, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego awarii. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę przywracania stanu. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Ustal punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap analogii do pracy starszego inżyniera, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego awarii. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.
To jest prawdziwa obietnica
Scena „To jest prawdziwa scena” funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny przypadek, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Budujące się repozytorium może wyglądać zupełnie inaczej
CODE
What the system does.
SKILLS
How agents should perform work.CONTEXT GRAPH
What the agent should understand about this repository.
my-platform/
│
├── services/
│
├── database/
│
├── docs/
│
├── tests/
│
│
├── AGENTS.md
│
├── .agents/
│ │
│ ├── skills/
│ │ ├── add-end-point/
│ │ ├── fix-bug/
│ │ ├── create-migration/
│ │ └── review-pr/
│ │
│ └── context/
│ ├── graph-schema.yml
│ ├── rules.yml
│ └── bootstrap.yml
│
└── context-graph/
├── indexer/
├── extractors/
├── graph-api/
└── validation/
Ostatni przykład
TASK
Create reimbursement endpoint.
DOMAIN
Finance / Employee.PATTERN
ExpenseController.ARCHITECTURE
Controller -> Service -> Orchestrator -> Repository.AUTHENTICATION
Session authentication required.AUTHORIZATION
CREATE_REIMBURSEMENT.TENANCY
OrganizationID + TenantID mandatory.DATABASE
HrReimbursement.TRANSACTION
Orchestrator owns transaction.IMPORTANT HISTORY
Direct reimbursement status mutation caused incident FIN-822.RULE
Use ReimbursementWorkflow.TESTING
Controller + Service + Repository tests required.REFERENCE PR
PR-11822 implemented similar Expense workflow.
Ostatnia refleksja
LLM
gives the agent intelligence.
Skills
give the agent procedures.Tools
give the agent hands.Vector search
helps the agent find things.Context Graph
helps the agent understand how those things are connected.Decision history
helps the agent understand why.
Listwa kontrolna operacyjna
Literatura pokrewna
- Praktyczne notatki: Co to są agenty głosowe AI i jak one działają? — Szczegółowy przewodnik po Praktycznych notatkach: Co to są agenty głosowe AI i jak one działają?: kontrakty, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.
- Praktyczne notatki: Uruchamiam agenta programowania AI lokalnie i jest prawie dwukrotnie — Szczegółowy przewodnik po Praktycznych notatkach: Uruchamiam agenta programowania AI lokalnie i jest prawie dwukrotnie: kontrakty, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.