Абвязка, цыкл і граф: тры ўзроўні надзейных AI-агентаў
Чаму ненадзейным агентам звычайна не хапае аднаго ўзроўню: абвязкі вакол мадэлі, цыкла на доказах ці яўнага графа. Патэрны кода і чэкліст для адладкі.
Крыніцы: Harness, Loop, and Graph: What I Learned Building the Same AI Agent Three Different Ways
Імены, які здаюця знайомымі, але не ўсвіядомленыя
Фразы „agent harness engineering“ і „loop engineering“ так часта з’являюцца ў публікаціях у соціальных мерэжах і артыкулах на блогах, што пачынае здавацца, нібы ўсі ўсвіядомляюць іх значэнне. Знайомасць можа быць абманнай, і часта невялікая памылка раскрывае гэта.
Уявіце досліднага агента, якім ўпакоўваецца збірка статэй з arXiv, ўкорачае іх і складае ўсякі тыдзень падсумок. Тры прыкладныя працы праходзяць усунуто. Потым вызов API з обмежэннем частоты падводзіць до памылкі без жадных сігналоў, код нічога не фіксуе, і агент пачынае ствараць падсумкі статэй, якія ён ніколі не чытаў. У проблеме няма ні модэля, ні запіту. Недастаткае які-небудзь спосаб для асоўнанага коду розразліцаваць статэю, якая была справжнья, ад правдопадобнай выдумкі. Гэты прынт справжні, у яго ёсць назва, і зміны запіту яго не паўтараюць.
Стварэнне таго ж агента трохі разоў дапамагае чыткая адзначыць разлікі: адна версія налаштаваная для конкрэтнай асяроддзя, іншая — для ціклаў зворачнай свярзанасці, а трэця — для прымітнага кантролю працы процэса. Гэта практыка ў сваёй нынешней форме існуе толькі апошніх адзіннаццаць месцаў, таму назвы яшчэ ўзнемагчаныя. Аднак асновныя разлікі рэальныя, і яны адпавядаюць рэальным інжынерскім рашэнням. Пасля гэтага, калі агент не працуе, трэба з’ясавіць, які з трохі слоёў трэба пацягнуць першым.
Сама по сабе мадэль мовы проста перакладае тэкст у тэкст. Памяць между вызывамі існуе толькі тады, калі яе задаеце. Даступ да файлаў, каманды шэлу і вызывы API — усе гэта вымагае падготовкі інфраструктуры, яку хтось трэба стварыць, і мадэль не можа пераканацца у правільнасці сваіх адказаў без зусібней перапрацавкі зза межамі. Людзі, якія ствараюць агенты ў 2024 годзе, з’ясавілі гэта, калі аднойчы гладкая дэманстрацыя зламалася пасля першага неспакоюванага дзеяння корыстувальніка.
Промышленнасць адказала на гэта тым, што больш не спрыяе да «агента» як да аднаго цэлага. Гэта тры адзінаковыя інжынерныя проблемы, якія знаходзяцца ў модэлі.
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
----------------------------------------------------------------------
Кожны слой лёгкая ўсваяць, стварыўшы яго найменшую версію, апрануўшы ёю і пасля прачытавшы документацыю да доследжэнняў і фрэймворка, каб зрозумець, чаму ён не працаваў.
Інструментары: што можа бачыць і трагчы агент
Найяснейшая дэфініцыя праказана ў інжынерскім зьвястку LangChain, дзе гэтая ідэя выражаецца за дапамогою рэвану: агент = модэль плюс інструментары. Модэль забезпечвае логіку. Інструментары забезпечваюць усё, што неабходна для таго, каб логіка дасягла рэальнага света, тыяму значыць інструменты, памяць, кантэкст, правыя і меры захоплення, якія не дазволяюць агенту рабіць чыясць дорогія або небяпечныя дзеянні.
Звычным раннім ментальным мадэляванням „дачы агенту інструментаў“ ёсць напісанне калько функцый на Python і ўказванне іх у інструкціях для сістэмы. Гэта падходзіць для дэманстрацыі. Але такой падход не прыжывае да задач, якія трываюць дольш чым адна вікна кантэксту, або да вызоваў інструментаў, якія збываюцца о 2 гадзіны ночы, калі ніхто не сочыць. На практыцы выявляецца, што такі падход мае шасць абавязакаў.
- Ін’екцыя кантэксту вялічы, што бачыць мадэль перад кожным крокам разумовага аналізу: паведамленне корыстніка, а таксама завантажаныя дакументы, пакананыя размовы, стан праекту і правілы організацыі. Лёгка ўпэўніцца ў перакананні. Занесенне цэлага дрэва файлаў і логу git у кожны вызов пагіршае точнасць, таму што мадэль тоне ў нерэлевантных токенах, і меншы, рэтэльна падобраны кантэкст завжды працюе лепшая, чым большы, неапрануты кантэкст.
- Акцыі ператвараюць рашэнне ў практычны эфект у свеце — будзь то запыт API, каманда шэлу, збір дадзенняў у базе дакументаў або клік у прыгледачы. У гэтым працэсе выконваецца Протакол кантэкста модэля, які значна змяніўся ў гэтым годзе. Ён з’явіўся ў канцы 2024 года як стандартны спосаб для агентаў знаходзіць і выклікваць інструменты, чым захавалі команды ад неабходнасці ствараць індывідуальную інтэграцыю для кожнага API. У спецыфікацыі з ліпеня 2026 года ён меў безстановы ядро, якое працуе за дапамогою звычайных балансэраў навантажэння без функціі «sticky sessions», розшырэнне Tasks ад AWS, якое падтрымляе задачы, якія трываюць дыягональна адзінам запыту, а таксама стрэльнейшыя механізмы автарызаціі, створаныя на аднойчыні з OAuth і OpenID Connect. У джэрэле паведамляецца пра падаўленне падаўжэй дзесяці тысяч публічных сервераў у працэсе і падаўленне SDK ў колькасці падаўжэй 97 мільйонаў на месцы. Стварэнне інструменту ў сёгоднішнія часы на базе шару інструментаў, які не ўключае MCP чы іншыя аналогічныя тэхналогіі, выклікае неабходнасць серйозных праблематыкаў.
- Перзістэнцыя — гэта все тое, што должна застацься пасля перачысці, збою чы ўсёўпразумеваючага вікна кантэксту, такое як пункты контроля, стан сесіі, вектарная памяць і історыя змян у Git. Першы доследны агент нічога з гэтага не зберагаў, таму адны раз з’яўленыя прынтары знішчылі чатырохдзесят хвілін працы. Зберагачыць маленькі JSON-пункт контроля пасля кожнага завершанага падзадання дапамагае больш для надзеямоўкі, чым будзь-яя праверка запросу.
- Контроль выканання аб’еднвае правілы павторных спроб, таймауты, бюджэты токенав і вітрачання, маршрутызацыю модэляў, ліміты для створаных падагентаў і крокі, дзе чалавек павінен падтвердзіць рашэнне. Без яго агент, які застраг у цыкле «званнець-парадокс» на цэлую ноч, можа ператворыць заданне на неразрэшальнае.
- Безпека і каральная сістэма абараняюць доступ да інструментаў толькі з мінімальнымі правамі, карыстоўванне секрэтных дадзеных, працаванне ў «піску», логі аўдыту і спіскі дазволенага. Код, напісаны модэлем, павінен завжды выкананыць у «піску». Агент для напісання коду быў пакрыты, калі ён прабаваў выкананыць
rm -rfу папцы, якую ён паслухаў як артыфакт будовы. Не было жадных злых намераў, толькі адказка паўярэнняў у поўнай меры разам з можлівасцю задачы шкоды. - Возможнасць назірання абараняецца залічэннямі, логамі вызываў інструментаў, выкарыстоўваннем токенаў, затрымкамі і рэзультатамі ацэнкі. Гэта здаецца нудным, пакуль агент не пачынае чыніць незвычайнае ў працэсе выканання, і тады няма запісаў пра тое, што ён на самай працэ практычна зрабіў, у працоўнасці з тым, што прыпускалі.
Ніжчэ прыведзены мінімальны, але функцыональны інструмент на Python. Ён працуе за дапамогою локальнага модэля Ollama, таму не трэба API-клуча, а пераход на хоставаны модэль адбываецца за адну лінію коду.
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"
Нічога тут не ўродзісткі, і гэта ёсць урок: крэплінг — цэлая сістэма рэгулярнага адстаўлення ўсёго навакол модэлю, які сам не ведае жадных запісаў. Для хоставанага модэлю заменіце блок requests.post на вызов SDK ад OpenAI або Anthropic. Схема інструмента і процедура зберагання стану залішаюцца незменнымі, таму што яны не залежаць ад таго, хто адпавядае.
Жалобы на тое, што модэль стаў менш розумным, практычна завжды маюць прычыну ў крэплінгу. Інструмент можа вернуць застарэлыя даны, кантэкст можа быць заполнены нерэлевантнымі данымі, а правыя можа быць занадта шырокімі або занадта вузкімі, вялічынай прычыню таго, што агент прабуе зрабіць тое, чаго яму ніколі не было дазволена. Перад рэдагаванням запросаў або зменой модэляў абавязкова пераканайцеся ў стане крэплінгу, таму што самэ там зазвычай і лежыць прычына проблемы.
Цікл: як адна спроба стае успешной
Калі крэп прыме рашынку, што агент можа тыкнуцься, то цыкл прыме рашынку, як яму перайсці з першай спробы да хорашага рэзультата. эта слой, які частае занедбваецца, адколі фраза «проста парадзіць яму спробаваць знову» здаецца простаю, пакуль агент насправды не спробуе знову.
Класычны прыклад неудачы — гэта самаактуальны цыкл, які пасля таго, як мадэль дае адказ, запытае яе, чы рашыта яе правільная. Адказ завжды «так». Мадэль, якая оцэнюе сваю сабе задачу без жадных зовнішніх сігналоў, практычна завжды паспевае, таму што няма нічога, проты чаго яна могла бы паразіцца. эта добра задокументаваная проблема, а не ексклюзыўная памылка: цыкл без падстав для неудачы завжды будзе верыць, што ён паспеў.
Выход заключаецца ў тым, каб перастаць прасіць мадэль аб ацэнкаванні сябе і створыць зовнішньага арбітра для ціклу: набор тэстаў з рэзультатамі «працавае» або «не працавае», верыфікатор схемы, кампайлер, правіла аналізу коду, або другы незалежны спосаб збору інформацыі, які падтрымвае альбо заперачае першую адпаведзь. Ціклы, якія базуюцца на доказах, аналізуюць стан света. Ціклы, якія базуюцца на паверы, аналізуюць тое, як себе чуе мадэль.
Тэхніка Ральфа Віггума і чаму просты цікл работае
Шаблон пад назвай «Ральф Віггум» стаў популярным пасля таго, як інжынер Джэффры Хантлі опісаў яго у 2025 годзе. У сутнасі ён чырвона як просты. Цікл у bash перадае той самы запрос кодавальнаму агенту знову і знову, пакуль задача не будзе завершана, а прыглыбленне працы фіксуецца ў файлах і комітатах git, а не ў памяці мадэльі пра чат.
#!/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
Здаецца, што гэта не должна працаваць, але пасля невялікай перэработкі ўсё ж такі прымітны спосаб стае саме той фактар, які робіць ўсё можлівым. Адмова ад вікорыстання кантэксту размовы на кожным кроцы і прымус да фіксаціі прогрэсу ў історыі git і файлах статусу дапамагаюць ухіліцца ад зіпсавання кантэксту, а таксама не дазволяюць агенту пераканаць ся, што ён ужо завершыў тое, чого на самай працы не зрабіў. Гэта не ўнтылігентна. Аднак гэта віпадкова стае падставай для рашэнняў, адтолькі як git і файлавая сістэма не брэшуць, каб падлагодзіць мадэль.
Ось невялікі цыкл такога ж тыпу, які таксама можна запусціць локальна проты Ollama; ён спрэтвае невыпаны тэст як ўзнаку таго, што „яшчэ не завершана“.
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}
Паглядзіце на апошніяй лініяй пры выходзе, таму што ў яй закладзенае сэрцоўка. Цыкл не кажа «старайцеся больш». Ён падае ў мадэль рэальную прычыну неудачы, таму што самэе конкрэтныя зовнішнія доказы яшчэ больш павышаюць качэнне другой спробы паўтарэння, чым простая вялікія спробы. У большасці агентаў найбольшыя павышэнні надзеянні даходзяць ад замены фразы «ці гэта правільна?» на асалодны зовнішнія перакананні, якія падходзяць да задання.
Таксама важна ведаць, калі трэба зупініцца. Цыкл без чыстай межы па колькасці спроб, вітоках чы працаванні па часу — гэта не стойкі агент. Гэта баг, які чакае на рахунак.
Граф: калі заданне мае рэальныя галузі
Пояс забезпечвае захопленне тэла агента, а петля дазваляе яму прагтар улучшэння з кожнай спробы, але ніхто з гэтых элементаў не апісвае задачу, якая мае форму дрэва: зрабіць гэта, пасля чаго выбраць адну з трох адзінакоў залежна ад рэзультата, чакаць на затверджэнне чалавека, а потым адрабатваць два перакрыцця паралельна і з’яеднаць іх.
Гэта і ёсць інжыніерыя графаў. Людзі часта супрацоўна ставяцца да гэтага аспекта, адколькі петлі на дзвяныя гады здаюцца адпаведнымі, але стаюць недастатковымі, калі праца не ўскладненая і не спрамованая на адну-едынственную перапытку. Петлі падходзяць толькі для аднаго: спробаваць, пераканацца і скорэктаваць пакуль не будзе выпанае адна з умоў. Яны не падходзяць, калі наступны крок залежыць ад таго, які з кальколькі рэзультатаў выйшаў, калі два падзаданні можаць выконвацца адночасна, або калі каму-небудзь трэба затвердзіць працу пры продажу. Укладанне всіх гэтых элементаў у адну просьбу і надзея, што мадэль будзе ўсё контролаваць, працавала для дзяяў калякіх команд, але гэта нестабільна. Калі почынаецца розгалужэння, логіка керавання павінна быць у чыстай структуры, а не ў тым, што мадэль імпровізуе ў кожны раз.
Інжыніерыя графа чыніць рабочы працэс явным. Вузлы — гэта крокі, такія як вызов агента, вызов інструмента, пераканальнік або перапаказ чалавека, а рэбры — гэта умовы, якія пераводзяць выконанне з адного вузла на іншы. Аналіз графа паказвае точна, якім шляхам працаваў працэс, што мае вельмі важлівое значэнне, калі опоўніцай выйшае інцыдэнт у працэсе, і трэба ведаць, што насправды адбылася, а не тое, што вы прыпускаеце.
LangGraph — стандартны выбар у такіх сітуацыях. Ён прэдставляе рабочы працэс у вачыні направленага графа, перадае тыпаваны стан з вузла на вузел, выкарыстоўвае умовныя рэбры для розгалужэння і мае вбудованыя механізмы перапаказа, таму працэс можа зупініцца, пачаць зноў або вернуцца да пярэдньяго стану.
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"},
)
Звычны цыклы не можаць проста і ясна адказаць на пытанне, калі саме робіць гэта: адна перагледка дае тры рэзультаты (завершанне, павторная спроба, зупінка і запіт да чалавека), кожны з якіх ведае ў разны направленні. Спосаб прыглыблення проблемы мае важлівэ значэнне. Гэта разліка межа агентам, якіі тыхо здаюцца пасля трэцьяй няудачы, і тымі, якіі перэдаюць чалавеку всю інфармацыю пра тое, што было спробавана.
У Microsoft AutoGen гэтага ж года была дадзена адпоўненасць пад назвай GraphFlow, з таго ж разу. Кальколькі агентоў або розгалужаныя рабочыя працэсы ускладняюць разумеўце непрамымых цыклоў, тады калярды можна адразу пераглядаць.
Ёсць канчаткова выявіць, дзе кожная платформа на самай працоўнае, а не паследаваць толькі інфармацыю з маркетынгавых стораніц, было прыменена чатыры платформы на аднам маленькім праекце: лінія обработкі дакументаў з роздзялам верыфікацыі і етапам затверджэння чалавеком.
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
--------------------------------------------------------------------------------------------
Асэнце ў тым, што гэта практычна. Калі працэс выканання можа быць паказаны на адной сторонцы як просты спіс крокаў, то карэткі фрэймворк не патрэбен, і добра структураваны цыкл унутрь моцнага карэткага каркаса выканае задачу, заставаючы меньш коду для адтрымання. Калі вы накрэсліце працэс выканання, у якога ёсць розгалужэння, карэткі фрэймворк адразу ж пачынае даваць плоды, галоўная частка якіх — заўсёды эканомія часу на адлучэнні бяга, а не якія-небудзь перадзеянні пад час выканання.
Як складаюцца тры шары
Гэта не супернікуючыя падходы. Яны складаюцца верткальна, і гэта як выглядае гэта складанне пасля таго, як вы выконалі працу з усіма трыма.
+--------------------------------------------------------------+
| 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 |
+--------------------------------------------------------------+
У рамках працы LangGraph адзін вузел-праект можа кілька разоў запускаць цыкл, базаваны на доказах, і толькі пасля чаго перадаць кантроль назад графу. Што такі внутрэнні цыклы можаць працаваць, так таму, што падстава пад імі дазваляе модэлю запускаць тэсты, чытаць файлы і адзыходзіць да своіх пакульшых спроб. Як толькі адзін слой выключаецца, усе іншае таксама перастае працаваць, таму стварэнне монолітнага „агента“ заставалася складным і ўсё больш ускладнялася.
Раздзелэнне на тры слоі значна прышвартоввае працэс адлагоджэння. Гэта спіс пунктав, якія трэба пераглянуць у парадку, прытымкі да стварэння запрошэння.
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?
Такая таблыца могла бы заўсёды захаваць вялікі вякенд, які пасвячаны бы адказванню за проблемы, якія на самай працэ ўсталі з-за відсутнасці патрэбных контрольных пунктав.
Нерашаныя пытанні
Дзеяныя аспекты застаюцца нерашанымі, і было б неправільна заканчваць, выказваючы большую впэўненасць, ніж дозволяюць доказы.
Па-першае, слоўнік усё ўсё змініцца. „Інжынерыя крэплінга“ практычна не існавала ў масштабных формах да гэтага года, а за ўсё іншае год можа стаць часткай шырэйшай канцэпцыі „інжынерыі агентаў“, пры чым тэрміны „крэплінг“, „цікл“ і „граф“ стануць падзагаламі, а не спецыялізаванымі галузямі.
Паўтора, падход Ральфа Віггума здаецца адносна некорэктным нават тады, калі ён работае. Выдача модэлю аднаго толькі запіту ў постаце ціклу і апошнечка на історыю git як на ўсю ўласную памяць выглядае як проста патч-замена, якая не забезпечвае практычнай стабільнасці. Ён падходзіць для невялікіх, чыста спецыфічных перэрабоць, але для будзь-чаго, што выклікае рэальныя наследкі чы розгалужэння, яму яшчэ не варта даваць доверлівасці.
Трэцяя пункт: фрэймворкі для графаў можа ўсё ўсё зменяць свой фармат. Функцыяя запісу стану у LangGraph чымалая, але команды іноды выбіраюць цэлы фрэймворк для працэса, які складаецца з трохох крокаў і ніколі не розгалужаецца, проста таму, што гэта ў модзе. Рабочы працэс, які ўжо ёсць простай лініяю, можа застацца такім.
Ёсць адна тэза, якая застоіцца паўз усё гэта: ненадзеяны агент практычна ніколі не стане надзеяным за дапамогою лепшага запіту. Проблема практычна завжды лежыць у аднам з трохох слоёў, і вышэўзгаданыя пытанні паказваюць, у кам з іх.
Пачатак работы з агентам доследжэння ўчора означаў бы спачатку стварэнне неабходных канструкцый і спрыянне ў ўважанні іх за звычную, ношучую навантажэння інфраструктуру, а не як чагось на другім месцы. З самага пачатку трэба было бы вжываць падход, базаваны на доказах, замест таго, каб пакладацца на самаоцэнку модэлю, адколькі сама гэта змяна відліковуе большыя бягі, чым будзь-што інша. Фрэймворк для графаў мусіў бы чакаць, пакуль працэс працы не будзе можна было накрасіць на паперы з відным розгалужэнням.
Модэль прывабляе увагу вяснамі, але надзеяна надзеянае працёйскае выкарыстоўванне выходзіць з інжынерных рашэнняў, якія яго отачваюць. Гэтая праця ў дзесяткі разоў менш прыгожая і набагато простэйшая, чым тверджэння, што модэль недастаткова розумная. Больш часу ён розумны. Ям проста не даваліся асяроддзе, адзывы чы карты, якія быяў бы неабходныя, каб показаць гэта.
Спадневаная літэратура
- Канцэпцыя LangGraph на простай мове: стан, памяць і оркестрацыя — Як што пытацца напісаць код: што такое оркестрацыя, час выканання, агенты з станамі, краткасрочная і дзяўнасрочная памяць, мнагаагентныя сістэмы і участка чалавека ў працы агентаў у LangGraph.
- Стварэнне сістэмы DeepAgents Harness: правыя, падагенты і затверджэнне чалавека — Практычны падход да стварэння планавальніка сістэмы з вікорыстаннем DeepAgents: бэкенды для файлоў, правілы дазволаў, падагенты, механізмы затверджэння, навыкі і MCP, а таксама сітуацыі, калі адгук модэля ўсё ж не ўсё правільны.