Agent Harness, Loop i Graph: Trzy warstwy stojące za niezawodnymi agentami AI
Dlaczego niepewni agenci zazwyczaj pomijają pewien element: pasek otaczający model, pętlę opartą na dowodach oraz wyraźny graf, wraz z wzorcami kodu i listą kontrolną do debugowania.
Źródła: Harness, Loop, and Graph: What I Learned Building the Same AI Agent Three Different Ways
Nazwy, które wydają się znajome, ale nie są rozumiane
Wyrażenia „agent harness engineering” oraz „loop engineering” pojawiają się tak często w postach na mediach społecznościowych i artykułach na blogach, że zaczyna się wydawać, iż są powszechnie znane. To złudzenie, a niewielki błąd zazwyczaj je ujawnia.
Wyobraźmy sobie agenta badawczego, którego zadaniem jest pobieranie artykułów z arXiv, ich streszczanie oraz tworzenie cotygodniowego podsumowania. Trzy próby działają prawidłowo. Następnie żądanie do API z ograniczoną przepustowością zawodzi bez żadnego sygnału – kod niczego nie zauważa – a agent zaczyna tworzyć streszczenia artykułów, których nigdy nie otworzył. Wina nie leży ani w modelu, ani w instrukcjach. Brakuje sposobu, aby otaczający kod odróżnił artykuł rzeczywiście przeczytany od wiarygodnej fabrykacji. Ta luka istnieje, ma swoją nazwę, a modyfikacje instrukcji jej nie naprawiają.
Budowanie tego samego agenta trzy razy oddzielnie uwyraźnia te różnice: pierwsza wersja jest dostosowana do środowiska, druga do pętli zwrotnej, a trzecia do bezpośredniej kontroli przepływu pracy. Ta dziedzina w swojej obecnej formie istnieje zaledwie od około osiemnastu miesięcy, więc nazewnictwo jest nadal przedmiotem dyskusji. Podstawowe różnice są jednak rzeczywiste i odpowiadają konkretnym decyzjom inżynieryjnym. Dzięki temu agent z awarią może wskazać, który z trzech warstw należy naprawić najpierw.
Sam model językowy jedynie przekształca tekst w tekst. Pamięć między wywołaniami istnieje tylko wtedy, gdy ją dostarczysz. Dostęp do plików, polecenia w shellu oraz wywołania API wymagają odpowiedniej infrastruktury, którą ktoś musi stworzyć, a model nie może zweryfikować własnych odpowiedzi bez zewnętrznej kontroli. Ludzie tworzący agenty w 2024 roku odkryli to, gdy sprawnie działająca demonstracja zawodziła przy pierwszym nieoczekiwanym działaniu użytkownika.
Przemysł zareagował, przestając traktować „agenta” jako jedną całość. Jest to trzy oddzielne problemy inżynieryjne umieszczone w modelu.
LAYER QUESTION IT ANSWERS FAILS AS
----------------------------------------------------------------------
Harness What can the agent see and touch? Missing tools,
(environment, tools, memory, lost state, blown
permissions, execution limits) budgets, leaks
----------------------------------------------------------------------
Loop How does one attempt turn into a Confident wrong
correct one? (retry, verify, stop) answers, infinite
spinning, silent
failure
----------------------------------------------------------------------
Graph What is the actual shape of the work? Wrong step order,
(sequence, branches, parallel paths, no recovery path,
human checkpoints) no visibility
----------------------------------------------------------------------
Najłatwiej zrozumieć każdą warstwę, tworząc jej najmniejszą wersję, ją testując, a następnie czytając dokumentację badawczą oraz frameworku, aby dowiedzieć się, dlaczego doszło do błędu.
„Harness”: to, co agent może zobaczyć i dotknąć
Najjaśniejsza definicja pojawia się w notatce inżynieryjnej LangChain, która sprowadza tę koncepcję do równania: agent równa się modelowi plus „harness”. Model dostarcza rozumowanie, natomiast „harness” dostarcza wszystko, czego rozumowanie potrzebuje, by oddziaływać na rzeczywisty świat – czyli narzędzia, pamięć, kontekst, uprawnienia oraz zasady ograniczające, które zapobiegają podejmowaniu kosztownych lub niebezpiecznych działań.
Powszechnym wczesnym modelem mentalnym „dostarczania agencie narzędzi” jest napisanie kilku funkcji w Pythonie i opisanie ich w instrukcjach systemu. To wystarcza do demonstracji. Nie sprawdza się jednak przy zadaniach trwających dłużej niż jedno okno kontekstowe, ani przy wywołaniach narzędzi, które zawiodą o 2 w nocy bez żadnego nadzoru. W praktyce okazuje się, że ten mechanizm obejmuje sześć różnych obowiązków.
- Iniekcja kontekstu decyduje o tym, co model widzi przed każdym krokiem rozumowania: wiadomość użytkownika, ale także pobraane dokumenty, wcześniejsza rozmowa, stan projektu oraz zasady organizacyjne. Nadmierne korygowanie jest łatwe. Wrzucanie całego drzewa plików i historii zmian z git do każdego wywołania pogarsza dokładność, ponieważ model tonie w nieistotnych tokenach, a mniejszy, starannie wybrany kontekst zawsze przewyższa większy, surowy kontekst.
- Interfejsy akcji przekształcają decyzję w konkretny efekt w świecie rzeczywistym – czy to żądanie API, polecenie w wierszu poleceń, zapis do bazy danych czy kliknięcie w przeglądarce. Tutaj odgrywa rolę Model Context Protocol, który w tym roku przeszedł liczne zmiany. Został stworzony pod koniec 2024 roku jako standardowy sposób na znajdowanie i wywoływanie narzędzi przez agenty, dzięki czemu zespoły unikają konieczności tworzenia indywidualnych integracji dla każdego API. W specyfikacji z lipca 2026 roku posiadał bezstanową strukturę działającą za pomocą zwykłych balanserów obciążeń bez sesji trwałych, rozszerzenie Tasks od AWS obsługujące zadania trwające dłużej niż jedno żądanie, oraz bardziej rygorystyczne mechanizmy autoryzacji oparte na OAuth i OpenID Connect. Źródło wskazuje na ponad dziesięć tysięcy publicznych serwerów produkcyjnych oraz ponad 97 milionów pobieranych miesięcznie wersji SDK. Budowa rozwiązań opartych dziś na warstwie narzędziowej, która nie jest MCP lub podobna, wymaga solidnego uzasadnienia.
- Trwałość to wszystko, co musi przetrwać restart, awarię lub zamknięcie okna kontekstowego, takie jak punkty kontrolne, stan sesji, pamięć wektorowa oraz historia zmian w Git. Pierwszy agent badawczy nie przechowywał nic z tego, więc jedynie przerwanie połączenia niszczyło czterdzieści minut postępów. Tworzenie małego pliku JSON z punktem kontrolnym po zakończeniu każdego podzadania przyczyniło się bardziej do niezawodności niż jakakolwiek modyfikacja instrukcji.
- Kontrola wykonywania obejmuje zasady ponawiania prób, limity czasowe, budżety tokenów i wydatków, routowanie modeli, ograniczenia dotyczące utworzonych podagentów oraz kroki, w których osoba musi zatwierdzić działania. Bez niej agent uwięziony w cyklu prób i błędów przez całą noc może sprawić, że zadanie potrwa wiecznie.
- Bезpieczeństwo i zarządzanie obejmują dostęp o minimalnych uprawnieniach do narzędzi, obsługę tajemnic, środowiska izolowane, logi audytowe oraz listy uprawnień. Kod napisany przez model powinien zawsze być uruchamiany w środowisku izolowanym. Złapano agenta kodującego, który zamierzał wykonać polecenie
rm -rfw folderze, który błędnie uznał za artefakt budowy. Nie chodziło o złą wolę, lecz o błąd połączony z uprawnieniami do wyrządzenia szkody. - Obserwowalność oznacza ślady działania, logi wywołań narzędzi, użycie tokenów, opóźnienia oraz wyniki oceny. Brzmi to nudno, dopóki agent nie zaczyna zachowywać się dziwnie w środowisku produkcyjnym i nie ma żadnych записów o tym, co faktycznie zrobił, w odróżnieniu od tego, co zakładano.
Poniżej znajduje się minimalny, ale funkcjonalny framework w Pythonie. Napędza go lokalny model Ollama, więc nie jest potrzebny klucz API, a przełączenie na model hostowany wymaga tylko jednej linijki kodu.
import json
import subprocess
import requests
from datetime import datetime
OLLAMA_URL = "http://localhost:11434/api/chat"
MODEL = "llama3.1"
# --- Action surface: the only two things this agent is allowed to do ---
def read_file(path: str) -> str:
with open(path, "r") as f:
return f.read()[:4000] # cap it, don't blow the context window
def run_tests() -> str:
result = subprocess.run(
["pytest", "-q"], capture_output=True, text=True, timeout=60
)
return result.stdout[-2000:] + result.stderr[-2000:]
TOOLS = {"read_file": read_file, "run_tests": run_tests}
TOOL_SCHEMA = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file from the project",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_tests",
"description": "Run the project's pytest suite",
"parameters": {"type": "object", "properties": {}},
},
},
]
# --- Persistence: cheap but real ---
def checkpoint(state: dict, path: str = "checkpoint.json"):
with open(path, "w") as f:
json.dump({**state, "saved_at": datetime.utcnow().isoformat()}, f)
# --- Execution control: hard ceilings, not suggestions ---
MAX_TOOL_CALLS = 8
def harness_run(user_task: str):
messages = [{"role": "user", "content": user_task}]
calls_made = 0
while calls_made < MAX_TOOL_CALLS:
response = requests.post(
OLLAMA_URL,
json={"model": MODEL, "messages": messages, "tools": TOOL_SCHEMA, "stream": False},
).json()
msg = response["message"]
messages.append(msg)
if not msg.get("tool_calls"):
return msg["content"] # model is done, no more tools needed
for call in msg["tool_calls"]:
name = call["function"]["name"]
args = call["function"].get("arguments", {})
if name not in TOOLS:
result = f"error: tool {name} is not permitted"
else:
result = TOOLS[name](**args)
messages.append({"role": "tool", "content": str(result)})
calls_made += 1
checkpoint({"messages": messages, "calls_made": calls_made})
return "stopped: hit the tool call ceiling before finishing"
Nic tutaj nie jest wykwintne, i to jest kluczowa lekcja: harness to staranne prowadzenie ksiąg rachunkowych wokół modelu, który ich nie prowadzi. W przypadku modelu hostowanego należy zastąpić blok requests.post wywołaniem SDK OpenAI lub Anthropic. Schemat narzędzia oraz mechanizm przechowywania stanu pozostają nietknięte, ponieważ nie zależą od tego, kto odpowiada.
Skargi na to, że model stał się głupszy, niemal zawsze wynikają z problemów z harnessem. Narzędzie mogło zwrócić przestarzałe dane, kontekst może być przepełniony nieistotną historią, albo uprawnienia mogą być zbyt szerokie lub zbyt wąskie, co sprawia, że agent próbuje robić coś, czego nigdy nie miał dozwolenia. Sprawdź harness przed edytowaniem poleceń lub zmianą modeli, ponieważ właśnie tam zwykle leży przyczyna problemu.
Pętla: jak jedna próba staje się udana
Jeśli pasek kontrolny decyduje, czego agent może dotknąć, to pętla określa, jak agent może przejść od pierwszej próby do dobrego rezultatu. Jest to warstwa najczęściej niedoceniana, ponieważ stwierdzenie „po prostu niech spróbuje ponownie” brzmi błahe, dopóki agent rzeczywiście tego nie zrobi.
Klasycznym błędem jest pętla samokorygująca, która po otrzymaniu odpowiedzi od modelu pyta, czy model jest pewien, że odpowiedź jest prawidłowa. Odpowiedź jest zawsze twierdząca. Model oceniający własne rozwiązania bez żadnych zewnętrznych sygnałów prawie zawsze uznaje je za poprawne, ponieważ nie ma nic, przeciwko czemu mógłby ponieść porażkę. Jest to dobrze udokumentowany problem, a nie jednorazowy błąd: pętla bez żadnych dowodów na porażkę zawsze będzie wierzyć, że odniosła sukces.
Rozwiązaniem jest przestanie proszenia modelu o ocenę samego siebie i przydzielenie pętli zewnętrznego arbitra: zestawu testów z wynikiem „przeszedł” lub „nie przeszedł”, walidatora schematu, kompilatora, reguły lintingu lub drugiego, niezależnego źródła informacji, które potwierdza lub zaprzecza pierwszej odpowiedzi. Pętle oparte na dowodach biorą pod uwagę stan świata, natomiast te oparte na pewności siebie biorą pod uwagę to, co czuje model.
Technika Ralph Wiggum i dlaczego prosta pętla działa
Wzorzec zwany „Ralph Wiggum” zyskał popularność po tym, jak inżynier Geoffrey Huntley opisał go w 2025 roku. W skrócie jest niezwykle prosty – pętla w bashu przekazuje ten sam prompt agencji programistycznej raz po raz, aż zadanie zostanie zakończone, przy czym postępy są zapisywane w plikach i komitach git, a nie w pamięci modela dotyczącej rozmowy.
#!/bin/bash
# ralph.sh - crude but surprisingly effective
while true; do
claude -p "$(cat PROMPT.md)" --dangerously-skip-permissions
if git diff --quiet HEAD~1 HEAD -- STATUS.md && grep -q "DONE" STATUS.md; then
echo "Task complete."
break
fi
sleep 5
done
Wygląda na to, że nie powinno to działać, a po niewielkiej refaktoryzacji okazuje się, że właśnie ta prostota jest jego zaletą. Odrzucanie kontekstu rozmowy przy każdym przetworzeniu oraz przymuszanie do zapisywania postępów w historii Git i plikach stanu pozwala uniknąć degradacji kontekstu i zapobiega temu, by agent przekonywał się, że już skończył coś, czego tak naprawdę nie zrobił. To nie jest eleganckie rozwiązanie. Jest ono przypadkowo oparte na dowodach, ponieważ Git i system plików nie kłamią, by schlebiać modelowi.
Oto mały, oparty na dowodach cykl tego samego typu, który również można uruchomić lokalnie z Ollamą – traktuje on nieudaną próbę jako jedyny dopuszczalny znak „jeszcze nie skończone”.
def evidence_loop(task_description: str, max_attempts: int = 5):
attempt = 0
history = []
while attempt < max_attempts:
attempt += 1
code = generate_patch(task_description, history) # calls the model
apply_patch(code)
test_output = run_tests() # external evidence
passed = "failed" not in test_output.lower()
history.append({
"attempt": attempt,
"patch": code,
"test_output": test_output,
"passed": passed,
})
if passed:
return {"status": "success", "attempts": attempt}
# feed the *actual failure*, not a vague "try again"
task_description = (
f"{task_description}\n\nPrevious attempt failed with:\n{test_output}\n"
"Fix the specific failure above."
)
return {"status": "gave_up", "attempts": attempt, "history": history}
Spójrz na ostatni wiersz przed powrotem, ponieważ to on zawiera kluczową ideę. Pętla nie mówi „próbuj jeszcze raz”. Podaje modelowi rzeczywisty błąd testu, gdyż to konkretne dowody z zewnątrz sprawiają, że druga próba jest lepsza od pierwszej, a nie tylko losowe ponowne przetestowanie. U większości agentów największy wzrost niezawodności pochodzi z zastąpienia pytania „Czy to wygląda poprawnie?” rzeczywistą, zewnętrzną weryfikacją odpowiadającą charakterowi zadania.
Kluczowe jest również wiedzenie, kiedy przestać. Pętla bez żadnych ograniczeń co do liczby prób, kosztów czy czasu nie stanowi solidnego agenta – to błąd czekający na fakturę.
Graf: gdy zadanie ma rzeczywiste gałęzie
Pas zapewnia strukturę dla ciała agenta, a pętla umożliwia mu doskonalenie się z każdą próbą, jednak żadne z nich nie opisuje zadania w kształcie drzewa: wykonać to, następnie wybrać jedną z trzech akcji w zależności od wyniku, poczekać na zatwierdzenie człowieka, a potem przeprowadzić dwie weryfikacje równolegle i połączyć je.
To jest inżynieria grafów. Zazwyczaj jest to warstwa, której ludzie się sprzeciwiają, ponieważ pętle przez długi czas wydają się wystarczające, ale przestają być one odpowiednie, gdy praca nie polega na prostym przejściu przez jeden test. Pętle nadają się tylko do jednego: próbowania, weryfikowania i korygowania, aż zostanie spełniona jedna warunek. Są niewygodne, gdy kolejny krok zależy od tego, który z kilku wyników wystąpił, gdy dwie podzadania mogą być wykonywane jednocześnie lub gdy ktoś musi to zatwierdzić, zanim będzie można kontynuować. Wkładanie tego wszystkiego do jednego promptu i liczenie na to, że model będzie to śledził, działało w niektórych zespołach, ale jest to rozwiązanie kruche. Gdy pojawiają się rozgałęzienia, przepływ kontrolny musi znajdować się w wyraźnej strukturze, a nie w tym, co model improwizuje za każdym razem.
Inżynieria grafów sprawia, że proces pracy staje się jawny. Węzły to poszczególne kroki, takie jak wywołanie agenta, narzędzia, walidatora lub kontrola przez człowieka, natomiast krawędzie to warunki, które przenoszą wykonywanie z jednego węzła na następny. Przyjrzenie się grafowi pokazuje dokładnie, jaką ścieżkę obrał proces, co ma ogromne znaczenie, gdy o północy występuje incydent produkcyjny i trzeba wiedzieć, co się stało, a nie to, co się przypuszcza.
LangGraph jest standardowym wyborem w tym przypadku. Reprezentuje on proces pracy jako graf skierowany, przekazuje typowane stany z węzła na węzeł, wykorzystuje krawędzie warunkowe do tworzenia gałęzi oraz posiada wbudowaną funkcję kontrolnych punktów, dzięki czemu proces może zostać zatrzymany, uruchomiony ponownie lub przywrócony do wcześniejszego stanu.
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
task: str
draft: str
review_passed: bool
attempts: int
def draft_node(state: AgentState) -> AgentState:
state["draft"] = generate_draft(state["task"])
return state
def review_node(state: AgentState) -> AgentState:
state["review_passed"] = run_validator(state["draft"])
state["attempts"] += 1
return state
def needs_human(state: AgentState) -> str:
if state["review_passed"]:
return "approved"
if state["attempts"] >= 3:
return "escalate" # branch: give up automating, ask a human
return "retry"
graph = StateGraph(AgentState)
graph.add_node("draft", draft_node)
graph.add_node("review", review_node)
graph.set_entry_point("draft")
graph.add_edge("draft", "review")
graph.add_conditional_edges(
"review",
needs_human,
{"approved": END, "retry": "draft", "escalate": "human_approval"},
)
Zwykły pętla ma trudności z prostym opisem tego, co robi: jedna weryfikacja daje trzy możliwe wyniki (zakończenie, ponowna próba, zatrzymanie i zapytanie osoby), z których każdy prowadzi w innym kierunku. Droga eskalacji ma znaczenie – to różnica między agentem, który po trzeciej nieudanej próbie po prostu rezygnuje, a tym, który przekazuje człowiekowi pełną historię podjętych działań.
Microsoft dodaje coś podobnego w tym roku pod nazwą GraphFlow z tego samego powodu. Wieloagentowe rozwiązania lub zagnieżdżone procesy pracy utrudniają zrozumienie ukrytej pętli, natomiast graf można badać bezpośrednio.
Aby ocenić, w których obszarach każda z tych platform naprawdę wyróżnia się, zamiast polegać na stronach marketingowych, przetestowano cztery z nich w ramach jednego małego projektu: proces przeglądania dokumentów zawierający gałąź walidacji oraz bramkę zatwierdzenia przez człowieka.
FRAMEWORK ORCHESTRATION MODEL STRONGEST AT STATE / PERSISTENCE
--------------------------------------------------------------------------------------------
LangGraph Directed graph, typed Complex branching, Built-in checkpointing,
state, conditional edges long-running workflows, time-travel debugging
human-in-the-loop
--------------------------------------------------------------------------------------------
CrewAI Role-based "crew" of Fast prototyping, Sequential task output
agents, sequential or multi-agent brainstorm passing, lighter state
hierarchical process style collaboration model
--------------------------------------------------------------------------------------------
OpenAI Agents SDK Explicit agent handoffs Minimal-friction start Ephemeral context
inside the OpenAI variables by default
ecosystem
--------------------------------------------------------------------------------------------
AutoGen / GraphFlow Multi-agent conversation Agent-to-agent Conversation history
plus optional graph layer negotiation, graph- plus graph state
for explicit control based orchestration
--------------------------------------------------------------------------------------------
Wniosek jest praktyczny. Jeśli proces pracy mieści się na jednej stronie jako prosta lista kroków, nie potrzebny jest framework grafowy – wystarczy dobrze zaprojektowany pętla w ramach solidnego narzędzia, co pozwala utrzymywać mniej kodu. Gdy już narysujesz proces pracy i pojawi się w nim rozgałęzienie, framework grafowy od razu zaczyna się opłacać, głównie dzięki zaoszczędzonemu czasowi na debugowaniu, a nie dzięki czemuś, co robi w czasie wykonywania.
Jak ułożone są te trzy warstwy
To nie są konkurencyjne podejścia. Są ułożone pionowo, a oto jak wygląda ta struktura po użyciu wszystkich trzech elementów.
+--------------------------------------------------------------+
| GRAPH - decides which node runs next, where branches |
| are, where a human has to approve |
+--------------------------------------------------------------+
| LOOP - inside a given node, drives attempt -> verify -> |
| revise until the evidence says stop |
+--------------------------------------------------------------+
| HARNESS - underneath both, provides the tools, memory, |
| permissions, and limits that make any of it |
| possible to execute safely |
+--------------------------------------------------------------+
| MODEL - the reasoning engine none of the above exists |
| without |
+--------------------------------------------------------------+
W ramach procesu LangGraph węzeł roboczy może kilka razy uruchomić pętlę opartą na dowodach, a dopiero potem przekazać kontrolę z powrotem do grafu. Ta wewnętrzna pętla działa tylko dzięki narzędziom dostępnym poniżej, które umożliwiają modelowi wykonywanie testów, czytanie plików oraz przywoływanie wcześniejszych prób. Usunięcie dowolnej warstwy powoduje przerwanie działania reszty, dlatego utrudnianie pracy monolitycznemu „agentowi” zawsze prowadziło do stagnacji.
Myślenie w trzech warstwach znacznie przyspiesza debugowanie. Oto lista kontrolna, którą należy przejść w ustalonym porządku przed wprowadzeniem jakiegokolwiek promptu.
SYMPTOM LIKELY LAYER TO CHECK FIRST
----------------------------------------------------------------------
Agent doesn't know something it should Harness -> context injection
Agent "can't" do something it should be Harness -> action surface /
able to do permissions
Agent forgets earlier progress after a Harness -> persistence
restart or long run
Costs or run time spiral unexpectedly Harness -> execution control
Agent confidently reports success on Loop -> swap confidence checks
work that's actually wrong for external evidence
Agent retries the same mistake Loop -> is it seeing the actual
repeatedly without improving failure, or just "try again"?
Agent takes the wrong path when a task Graph -> is the branching logic
has more than one possible outcome explicit, or implicit in a
single prompt?
No human ever gets a chance to catch a Graph -> is there an approval
bad decision before it ships node, or is it all automatic?
Taka tabela oszczędziłaby cały weekend spędzony na obwinianiu promptu za to, co w rzeczywistości było brakiem punktu kontrolnego.
Pytania otwarte
Część kwestii pozostaje nierozstrzygnięta, a błędem byłoby kończenie dyskusji z większą pewnością, niż na to pozwalają dowody.
Po pierwsze, słownictwo wciąż się rozwija. „Inżynieria harness” praktycznie nie istniała na dużą skalę przed tym rokiem, a za rok może zostać włączona do szerszej kategorii „inżynieria agentów”, przy czym terminy takie jak harness, loop i graph staną się podtytułami, a nie dziedzinami, w których specjalizują się ludzie.
Po drugie, podejście Ralpha Wigguma wydaje się nieco niewłaściwe, nawet gdy przynosi efekty. Podawanie modelowi jednego promptu w ciągłym cyklu i poleganie na historii git jako jedynej „pamięci” przypomina naprawę pasa bez rzeczywistej trwałości. Nadaje się do małych, ściśle określonych modyfikacji, natomiast w przypadku czegokolwiek z prawdziwymi gałęziami lub konsekwencjami nie należy mu jeszcze ufać.
Po trzecie, frameworki grafowe mogą nadal zmieniać swój kształt. Funkcja checkpointing w LangGraph jest doskonała, ale zespoły czasami przyjmują cały framework grafowy do prostego, trójkrotnego procesu, który nigdy się nie rozgałęzia, tylko dlatego, że jest to aktualne rozwiązanie. Prosta ścieżka pracy może pozostać prostą.
Jedno twierdzenie przetrwało to wszystko: niepewnego agenta prawie nigdy nie naprawi lepszy prompt. Przeszkoda prawie zawsze leży w jednej z trzech warstw, a powyższe pytania wskazują, która to warstwa.
Rozpoczęcie pracy agenta badawczego już dziś oznaczałoby najpierw stworzenie niezbędnej infrastruktury i traktowanie jej jako nudnej, nośnej konstrukcji, a nie jako czegoś dodanego później. Od pierwszego dnia należałoby zastosować podejście oparte na dowodach zamiast polegać na samoopinii modelu, ponieważ sama ta zmiana naprawia więcej błędów niż cokolwiek innego. Framework grafowy mógłby zostać wdrożony dopiero wtedy, gdy proces pracy dałoby się narysować na papierze z wyraźnie widocznym rozgałęzieniem.
Model przyciąga uwagę od trzech lat, ale niezawodność w praktyce wynika z inżynierii, która go otacza. Ta praca jest o wiele mniej efektowna, ale znacznie łatwiejsza do zrealizowania niż twierdzenie, że model nie jest wystarczająco inteligentny. Przeważnie tak właśnie jest. Po prostu nie otrzymał środowiska, informacji zwrotnej ani mapy potrzebnych, by to udowodnić.
Literatura pokrewna
- Koncepcje LangGraph w prostym języku: stan, pamięć i orkiestracja — Zanim napiszesz kod: co oznaczają orkiestracja, czas wykonywania, agenci z pamięcią, pamięć krótko- i długoterminowa, systemy wieloagentowe oraz udział człowieka w LangGraph.
- Budowa harnessa DeepAgents: uprawnienia, podagenci i zatwierdzenie przez człowieka — Praktyczne tworzenie planera projektów systemowych przy użyciu DeepAgents: backendy plików, zasady uprawnień, podagenci, mechanizmy zatwierdzania, umiejętności i MCP, a także miejsca, gdzie ocena modelu nadal zawodzi.