Як уладкаваныя ШІ-агенты: архітэктурныя патэрны і іх рэалізацыя ў інструментах для праграмаванн

Agents

Або: чаму ваш агент забыў, што павінен быў зрабіць, і што з гэтым рабіць

Памятаеце часы, калі «ШІ ў рэдактары» азначала акенца чата збоку, куды можна было ўставіць кавалак кода і спытаць «чаму гэта не працуе»? Гэта было нядаўна. Па мерках нашай індустрыі — у мінулай геалагічнай эпосе.

Сёння агент сам лазіць па рэпазіторыі, сам піша план, сам запускае тэсты, сам атрымлівае памылкі і сам жа іх выпраўляе. Часам — у правільным парадку.

І вось тут высвятляецца непрыемная рэч: разумная мадэль — гэта яшчэ не разумны агент. Можна ўзяць самую моцную LLM на рынку, даць ёй задачу на сорак файлаў і праз паўгадзіны атрымаць адказ «Гатова! ✅» пры тым, што зроблена палова, а ў другой палове зроблена зусім не тое, што трэба. Мадэль не стала дурнейшай. Проста яе пасадзілі ў няправільную архітэктуру.

Гэты артыкул — пра архітэктуру. Пра шэсць базавых патэрнаў, з якіх сабраныя ўсе сучасныя агенты: Claude Code, Cursor, Antigravity, Zed і астатнія. Будзе крыху матэматыкі (яе можна прагартаць — я не пакрыўджуся), шмат схем і, спадзяюся, некалькі момантаў «а-а-а, дык вось чаму ён так робіць».

Каму будзе карысна: усім, хто штодня працуе з агентамі і хоча разумець, што адбываецца пад капотам. Бо агент, якога вы разумееце, — гэта агент, якім вы можаце кіраваць. А агент, якога вы не разумееце, кіруе вашым вечарам.

Кароткі слоўнік (каб потым не спатыкацца)

Агент — праграма на базе вялікай моўнай мадэлі (LLM — Large Language Model), якая не толькі адказвае тэкстам, але і дзейнічае: чытае файлы, запускае каманды, рэдагуе код. Чат-бот з рукамі.
АС — аперацыйная сістэма.
Лінтар (linter) — інструмент статычнай праверкі кода, які знаходзіць патэнцыйныя памылкі і парушэнні стылю без запуску праграмы.
Прампт (prompt) — тэкст, які падаецца мадэлі: запыт, інструкцыі і патрэбны кантэкст.
Токен — кавалачак тэксту (прыкладна частка слова). Мадэль думае токенамі, памятае токенамі, а вы плаціце — таксама токенамі.
Кантэкстнае вакно (context window) — колькі токенаў мадэль можа «трымаць у галаве» адначасова. Усё, што за яго межамі, для мадэлі не існуе. Наогул.
Выклік інструмента (tool call) — просьба агента нешта зрабіць у рэальным свеце: «прачытай файл», «запусці тэсты», «зрабі запыт у базу».
Субагент — дапаможны агент, якому галоўны перадае асобную задачу. Стажор, па сутнасці.
MCP (Model Context Protocol) — адкрыты стандарт падлучэння інструментаў да агентаў, прапанаваны Anthropic у лістападзе 2024 года¹.
ACP (Agent Client Protocol) — адкрыты пратакол сувязі паміж рэдактарам і агентам, ініцыяваны камандай Zed².

Тэарэтычны фундамент: агент як POMDP

Перш чым гаварыць пра архітэктуры, трэба зразумець, у якой сітуацыі знаходзіцца агент. А сітуацыя ў яго, шчыра кажучы, так сабе.

Вы ў гасцях у далёкіх сваякоў, у старым вясковым доме, дзе былі адзін раз у дзяцінстве. Апоўначы гасне святло. Гаспадары спяць, а вас папрасілі «проста праверыць засцерагальнікі, яны дзесьці ў калідоры».

Вы ўключаеце ліхтарык на тэлефоне. Бачыце круг святла — метр, не больш. Пасвяцілі налева — вешалка з паліто. Направа — дзверы, але куды? Вы робіце крок, яшчэ крок, і ў галаве паступова складаецца карта: тут шафа, тут паварот, тут парог, аб які вы ўжо спатыкнуліся. Але гэта карта з памяці, а не дом. Калі хтосьці ўначы пераставіў крэсла, вы даведаецеся пра гэта толькі каленам.

І яшчэ адна дробязь: батарэя ў тэлефоне — 12%.

Агент знаходзіцца менавіта ў такім доме. Ён ніколі не бачыць ваш праект цалкам — толькі тыя файлы, якія сам адкрыў, і той вывад каманд, які сам запытаў. Усё астатняе — цемра, а «карта ў галаве» складаецца з таго, што ён паспеў асвятліць. А 12% батарэі — гэта кантэкстнае вакно, пра якое крыху ніжэй.

У тэорыі прыняцця рашэнняў для такой сітуацыі ёсць спецыяльная назва: часткова назіральны маркаўскі працэс прыняцця рашэнняў (POMDP — Partially Observable Markov Decision Process). Класічная праца па тэме — Kaelbling, Littman і Cassandra, 1998³; яна пісалася пра робатаў, але агенту ў вашым рэпазіторыі гэта нічым не дапамагае, яму таксама цёмна.

Фармальна агент вызначаецца картэжам (упарадкаваным наборам элементаў) ℳ = ⟨𝒮, 𝒜, 𝒯, ℛ, 𝒪, 𝒵, γ⟩:

𝒮 — поўная прастора станаў асяроддзя (увесь рэпазіторый, стан файлавай сістэмы, працэсы аперацыйнай сістэмы, журналы падзей). Увесь дом цалкам — разам з пакоямі, у якія вы яшчэ не заходзілі.
𝒜 — прастора магчымых дзеянняў агента (выклікі інструментаў, рэдагаванне файлаў, запуск каманд). Пасвяціць, зрабіць крок, адчыніць дзверы, пстрыкнуць выключальнікам.
𝒪 — прастора назіранняў (змест прагледжаных файлаў, вывад тэрмінала, паведамленні лінтараў). Тое, што трапіла ў пляму святла.
𝒵: 𝒮 → Δ(𝒪) — функцыя назірання, якая ператварае рэальны стан асяроддзя ў частковае назіранне oₜ ∈ 𝒪. Наколькі ярка свеціць ваш тэлефон і як далёка б'е прамень.
𝒯: 𝒮 × 𝒜 → Δ(𝒮) — функцыя пераходу: як змяняецца асяроддзе пасля дзеяння aₜ ∈ 𝒜. Што адбудзецца, калі вы зачэпіце вешалку: яна ўпадзе, і калідор ужо не той, што хвіліну таму.
ℛ — функцыя ўзнагароды (наколькі дзеянне наблізіла да мэты), γ — каэфіцыент дыскантавання (наколькі агенту важная будучыня ў параўнанні з «тут і цяпер»).

Галоўны вораг: гніенне кантэксту

Цяпер другая частка драмы. У агента няма памяці ў чалавечым сэнсе. Уся яго «памяць» — гэта адзін доўгі тэкст, які адпраўляецца ў мадэль на кожным кроку:

text
1Mₜ = ( h₀, a₁, o₁, a₂, o₂, …, aₜ, oₜ )

Па-чалавечы: першапачатковае заданне h₀, а пасля яго — увесь ланцужок «што зрабіў → што ўбачыў». Нічога не выкідаецца.

Сход жыльцоў пад'езда. Старшыня адкрывае яго адным сказам: «Сёння трэба вырашыць адно — хто будзе трымаць ключ ад падвала».

Праз пяць хвілін нехта ўспамінае, што ў ліфце зноў пахне. Потым пачынаецца спрэчка пра машыны на газоне. Потым суседка з пятага паверха чытае ўслых ліст за 2019 год ад кампаніі, якая абслугоўвае дом. Потым — кветкі на лесвіцы, новы дамафон і той, хто не плаціць за ліфт. Кожная тэма па-свойму важная, і кожную нехта абмяркоўвае з запалам.

Праз дзве гадзіны ўсе стомленыя. Аднагалосна галасуюць за кветкі на лесвіцы і разыходзяцца з пачуццём выкананага абавязку. Ключ ад падвала па-ранейшаму ні ў кога.

Ніхто не забыў пра ключ знарок. Пытанне прагучала — проста пасля яго было сказана столькі ўсяго, што пад канец увага ўсіх засталася на апошніх тэмах. Агент у доўгай сесіі трапляе роўна ў такое ж становішча: задача прагучала ў першым паведамленні, а пасля яе ідуць сотні радкоў вываду каманд, змесціва файлаў і журналаў памылак. Кожны радок па-свойму карысны — і кожны адцягвае ўвагу ад галоўнага.

Кантэкстнае вакно мае мяжу Cₘₐₓ, і калі |Mₜ| → Cₘₐₓ, пачынаюцца праблемы. Першая — вылічальная. Механізм увагі (Self-Attention) у трансформерах⁴ параўноўвае кожны токен з кожным, таму кошт расце квадратычна:

text
1𝒪_compute = O(|Mₜ|²)

Удвая даўжэйшы кантэкст — прыкладна ўчацвёра больш вылічэнняў на ўвагу. А на практыцы горш за ўсё тое, што ўся гісторыя ізноў адпраўляецца ў мадэль на кожным кроку. Кожны наступны крок — даражэйшы і павольнейшы за папярэдні. Як таксі, дзе лічыльнік ідзе не за кіламетры, а за ўсе кіламетры, праеханыя з пачатку дня, — на кожным павароце.

Другая праблема — якасная, і яна непрыемнейшая. Чым даўжэйшы кантэкст, тым горш мадэль у ім арыентуецца. Гэта не тэорыя: даследаванне Lost in the Middle⁵ паказала, што мадэлі найлепш «бачаць» пачатак і канец кантэксту, а інфармацыю з сярэдзіны выкарыстоўваюць горш. У 2025 годзе каманда Chroma праверыла 18 мадэляў і атрымала тое ж самае: якасць падае з ростам даўжыні ўводу нават на элементарных задачах⁶. Менавіта яны і папулярызавалі тэрмін Context Rot — гніенне кантэксту.

У тэрмінах тэорыі інфармацыі расце ўмоўная энтрапія H(Sₑₙᵥ | Mₜ): карысны сігнал тоне ў шуме. Вынік — страта пачатковай мэты g ∈ h₀ (Goal Drift) і галюцынацыі.

Верхняя лінія — агент, які цягне ўсю гісторыю за сабой. Ніжняя — агент, які кожны крок пачынае з чыстым кантэкстам. Розніца на дзясятым кроку — у пяць з паловай разоў. На сотым — у пяцьдзясят.

Таму галоўная думка ўсяго артыкула ўкладваецца ў адзін сказ: архітэктура агента — гэта спосаб не даць сходу расцягнуцца на дзве гадзіны. Усе шэсць патэрнаў ніжэй — проста розныя спосабы трымацца парадку дня.

Anthropic, дарэчы, называе гэтую дысцыпліну context engineering (праектаванне кантэксту) і прама піша, што кантэкст — гэта рэсурс, кожнае наступнае пашырэнне якога дае ўсё меншую карысць. Яго трэба эканоміць, як памяць на старым тэлефоне⁷.

Шэсць базавых патэрнаў

Адразу папярэджу: у рэальным свеце гэтыя патэрны амаль ніколі не сустракаюцца ў чыстым выглядзе. Гэта як «пяць базавых соўсаў» у французскай кухні — ведаць іх трэба, але ў рэстаране вам прынясуць нешта змешанае. Пра змяшэнне — у канцы.

1. Single-Loop (адзін цыкл; ReAct: разважанне + дзеянне)

Найпрасцейшы і самы стары (па мерках агентаў — аж з 2022 года) патэрн. Яго апісалі Yao і калегі ў працы ReAct: Synergizing Reasoning and Acting in Language Models⁸, і з таго часу ён ляжыць у падмурку амаль кожнага агента.

Ідэя простая да непрыстойнасці: падумай → зрабі → паглядзі, што атрымалася → паўтары.

Гэта майстар-адзіночка. Ён сам думае, сам робіць, сам правярае. На кароткай задачы — выдатна. На доўгай пачынаецца знаёмае:

Стан FakeDone вы бачылі. Усе бачылі.

Матэматычная мадэль

На кроку t агент вылічвае:

text
1(sₜ^thought, aₜ) = LLM(Mₜ₋₁)
2oₜ = EnvExecute(aₜ)
3Mₜ = Mₜ₋₁ ‖ sₜ^thought ‖ aₜ ‖ oₜ

Перакладаю: мадэль глядзіць на ўсю гісторыю, вырашае, што рабіць; асяроддзе выконвае дзеянне; і ўсё — думка, дзеянне, вынік — дапісваецца ў канец. Сімвал ‖ азначае «прыклеіць». Нічога не адклейваецца ніколі.

Што добра, што дрэнна

Квадратычны рост выдаткаў. Даўжыня прампта расце як O(t · L̄), дзе L̄ — сярэдні памер аднаго кроку. Сукупна за T крокаў мадэль перажоўвае O(T² · L̄) токенаў. Дзесяць крокаў каштуюць не ў дзесяць разоў больш за адзін, а ў пяцьдзясят пяць. Рахунак за API пра гэта ведае, нават калі вы — не.
Lost in the Middle. З ростам Mₜ мадэль горш бачыць пачатковую інструкцыю h₀, якая паступова «тоне» ў сярэдзіне кантэксту. Адсюль зацыкліванні (infinite loops) і рытуальнае трохразовае чытанне аднаго і таго ж файла.
Затое — прастата. Рэалізуецца за вечар. Лёгка шукаць і выпраўляць памылкі. Ніякіх рухомых частак.
Калі выкарыстоўваць: кароткія задачы на некалькі крокаў — выправіць адну памылку, напісаць скрыпт, адказаць на пытанне па кодзе. І яшчэ: ReAct-цыкл жыве ўнутры ўсіх астатніх патэрнаў. Ён не знікае — яго проста ўкарочваюць.

2. Spec-Driven / Plan-Execute (праца паводле спецыфікацыі: спачатку чарцёж)

Нікому не прыйдзе ў галаву будаваць дом, проста пачаўшы класці цэглу і «глядзець, як пойдзе». (Добра, некаму прыйдзе. Мы ўсе бачылі такія дамы.) Нармальныя людзі спачатку робяць чарцёж.

Патэрн Spec-Driven робіць тое ж самае: падзяляе працу на дзве фазы — праектаванне і выкананне. У навуковай літаратуры падобны падыход вядомы як Plan-and-Solve⁹, а ў прадуктах — як «рэжым планавання», які вы ўжо, магчыма, бачылі ў Claude Code ці Antigravity.

Хітрасць у тым, што пасля зацвярджэння плана ўвесь бруд даследавання выкідваецца. Мулярам не прыносяць на будоўлю пяць папярэдніх эскізаў, спрэчку архітэктара з заказчыкам пра колер даху і яго начныя сумневы, ці вытрымае бэлька. Ім прыносяць адзін аркуш: чарцёж. Тое ж і з агентам — выканаўца бачыць толькі вынік:

Матэматычная мадэль

Фаза 1 (Планаванне): на аснове пачатковага стану S₀ мадэль генеруе план P = {p₁, p₂, …, p_K}, дзе кожны крок pₖ мае ўласную лакальную мэту.
Фаза 2 (Выкананне): кожны крок pₖ выконваецца з мінімальным кантэкстам M⁽ᵏ⁾ = {h₀, pₖ, state_deltaₖ} — без усёй гісторыі пошуку.

Што добра, што дрэнна

Эканомія. Замест адной доўгай траекторыі даўжынёй K · L — K кароткіх даўжынёй L. Складанасць падае з O((K L)²) да O(K · L²). План з дзесяці крокаў — прыкладна ў дзесяць разоў таннейшы.
Чалавек у цыкле. Самы недаацэнены плюс: вы правяраеце план да таго, як зменены хоць адзін радок. Выправіць адзін пункт у markdown-файле — хвіліна. Адкаціць дваццаць зламаных файлаў — вечар і кепскі настрой.
Слабасць: план не перажывае сустрэчы з рэальнасцю (Open-Loop Drift). Як пісаў фон Мольтке, ніводзін план не перажывае першага сутыкнення з ворагам. Калі на трэцім кроку высветлілася, што патрэбнай бібліятэкі няма, а API зусім не такі, як думаў планавальнік, — патрэбнае перапланаванне (Re-planning Loop). Агент, які ўпарта выконвае састарэлы план, — гэта навігатар, які трэці раз прапануе павярнуць на мост, што разабралі ў мінулым годзе.
Калі выкарыстоўваць: рэфактарынг, новыя модулі, усё, што закранае больш за пару файлаў.

3. Orchestrator-Worker (каардынатар і выканаўцы: прараб і брыгада)

Наступны крок эвалюцыі: а што, калі брудную працу ўвогуле рабіць не ў галоўным кантэксце?

Прараб не кладзе цэглу сам. Ён кажа: «Ты — разбярыся з электрыкай. Ты — з сантэхнікай. Ты — пашукай, дзе цячэ». Кожны рабочы вяртаецца з кароткай справаздачай, а не пераказвае ўвесь свой працоўны дзень з перакурамі.

Галоўнае тут — не паралельнасць (хоць і яна прыемная), а ізаляцыя смецця:

Матэматычная мадэль

Падзел прасторы станаў 𝒮 = 𝒮_global ∪ 𝒮₁ ∪ 𝒮₂ … ∪ 𝒮ₘ. Аркестратар адпраўляе субагенту Wᵢ даручэнне Tᵢ = πᵢ(𝒮_global). Субагент апрацоўвае лакальны кантэкст M_Wᵢ і вяртае аркестратару сціснуты вынік δᵢ = Compress(M_Wᵢ).

Кожны субагент працуе ў сваім пакоі і выходзіць адтуль толькі з δᵢ — кароткім пераказам.

Што добра, што дрэнна

Ізаляцыя кантэксту. Усе шумныя токены застаюцца ў M_W_A і паміраюць разам з субагентам. Аркестратар застаецца чыстым і свежым.
Паралельнасць. Незалежныя падзадачы выконваюцца адначасова.
Цана. Ізаляцыя — не бясплатная. Кожны субагент пачынае з нуля і зноў чытае тое, што, магчыма, ужо чытаў іншы. Anthropic, апісваючы сваю мультыагентную сістэму для даследаванняў, прывяла лічбы: звычайны агент расходуе прыкладна ў 4 разы больш токенаў, чым чат, а мультыагентная сістэма — прыкладна ў 15 разоў¹⁰. Брыгада працуе хутчэй, але і заробак у яе адпаведны.
Слабасць: сапсаваны тэлефон (Information Bottleneck). Пры сцісканні частка інфармацыі губляецца. Калі субагент не палічыў важным, што ў сцяне праходзіць газавая труба, прараб пра гэта не даведаецца. Да пэўнага моманту.
Калі выкарыстоўваць: пошук па вялікім праекце, аналіз журналаў падзей, задачы, якія натуральна разбіваюцца на незалежныя часткі. Прыклады: субагенты ў Claude Code і Antigravity, платформы для распрацоўкі агентаў CrewAI і AutoGen¹¹.

4. Event-Driven / Async Protocol (падзеі і асінхронная сувязь: кавярня з пэйджарам)

Ёсць кавярні, дзе вы стаіце каля касы, пакуль барыста гатуе каву. А ёсць — дзе вам даюць пэйджар, вы сядаеце за столік і займаецеся сваімі справамі, а пэйджар пілікае: «пачалі», «амаль», «забірайце». Розніца — у вашых нервах.

Класічны пакрокавы (Turn-Based) рэжым — гэта стаяць каля касы. Вы далі задачу і глядзіце на індыкатар чакання. Архітэктура, заснаваная на падзеях (Event-Driven) робіць з агента фонавы сэрвіс, які паведамляе пра прагрэс праз падзеі — напрыклад, session/update у пратаколе ACP².

Матэматычная мадэль

Дыскрэтная мадэль пераходу Sₜ → Sₜ₊₁ замяняецца струменем падзей eₖ ∈ ℰ. Агент працуе як фонавы працэс, які рэагуе на падзеі і адпраўляе невялікія змены стану ΔSₜ праз паведамленні JSON-RPC, не блакуючы інтэрфейс рэдактара.

Замест аднаго вялікага адказу ў канцы — бесперапынны рэпартаж «вось што я раблю зараз».

Што добра, што дрэнна

Неблакавальнасць. Вы працуеце, агент працуе. Ніхто нікога не чакае.
Стандартызацыя. ACP дазваляе аднаму агенту працаваць у розных рэдактарах — як LSP у свой час зрабіў з падтрымкай моў праграмавання.
Але без ілюзій: гэты патэрн змяняе спосаб дастаўкі, а не колькасць працы. Патокавая перадача не эканоміць ніводнага токена. Пэйджар не робіць каву хутчэйшай — ён проста дазваляе вам не стаяць у чарзе.
Слабасць: два гаспадары ў адным файле (Race Conditions). Калі вы і агент адначасова рэдагуеце адзін і той жа файл, пачынаецца весялосць:

Калі выкарыстоўваць: доўгія задачы, фонавыя агенты, інтэграцыя ў рэдактары новай хвалі (Zed, Antigravity).

5. Tool-Mediated Architecture (архітэктура з падлучэннем інструментаў: USB для інструментаў)

Памятаеце часы, калі ў кожнага тэлефона была свая зарадка? Шуфляда, поўная кабеляў, і ніводзін не падыходзіць. Агенты да 2024 года жылі прыкладна так: кожная інтэграцыя (Git, база даных, Jira) пісалася асобна для кожнага агента.

MCP (Model Context Protocol)¹ — гэта USB-C для агентаў. Адзін стандартны раз'ём на базе JSON-RPC: напісалі MCP-сэрвер для Postgres адзін раз — і ён працуе з любым агентам, які ўмее MCP.

Важнае ўдакладненне, якое часта выпускаюць з-пад увагі: MCP — гэта пратакол, а не пясочніца. Бяспеку, дазволы і ўхваленне дзеянняў рэалізуе хост — праграма, якая падлучае мадэль да інструментаў (IDE ці іншы дадатак). USB-раз'ём сам па сабе не абараняе ад падазронай флэшкі — гэта задача аперацыйнай сістэмы.

А вось як выглядае адзін выклік інструмента ад пачатку да канца:

Матэматычная мадэль

Агент працуе з мноствам дынамічных схем інструментаў 𝒯_MCP = {t₁, t₂, …, tₙ}. Выклік інструмента фармалізуецца як запыт:

text
1Callₜ = RPC_Request(method, params)
2Responseₜ = ExecuteInSandbox(Callₜ)

Кожнае дзеянне агента — стандартызаваны «ліст» з назвай метаду і параметрамі. Хост можа прачытаць яго, спытаць вас і толькі потым адправіць.

Што добра, што дрэнна

Бяспека на аснове магчымасцяў (Capability-Based Security). Агент можа рабіць толькі тое, што дазваляюць падлучаныя сэрверы. Няма сэрвера для rm -rf — няма rm -rf.
Схемы з'ядаюць кантэкст. Па змаўчанні кліент атрымлівае поўны спіс інструментаў (tools/list), і іх апісанні ляжаць у кантэксце заўсёды, нават калі не патрэбныя. Падлучылі дзесяць сэрвераў «на ўсялякі выпадак» — і ваш агент яшчэ да першага пытання носіць з сабой заплечнік інструкцый. Таму частка кліентаў загружае схемы толькі пры патрэбе праз пошук інструментаў (tool search).
Накладныя выдаткі транспарту. Серыялізацыя і міжпрацэсная сувязь дадаюць невялікую затрымку (latency) на кожны выклік. Звычайна непрыкметна, але ў цыкле са ста выклікаў — ужо адчувальна.
Калі выкарыстоўваць: падлучэнне да баз даных, трэкераў, вэб-API; карпаратыўныя сістэмы, дзе важна ведаць, што менавіта агент можа кранаць.

6. Verifier Loop / Self-Correction (цыкл праверкі і самавыпраўлення: вечная пераздача)

LLM вельмі ўпэўнена хлусіць. Гэта не збой, гэта асаблівасць: мадэль генеруе праўдападобны тэкст, а праўдападобны і правільны — розныя рэчы. Код, які выглядае працаздольным, — гэта самы небяспечны від кода.

Лекі — даць агенту экзаменатара, з якім нельга дамовіцца. Кампілятар не ўражваецца ўпэўненым тонам. Тэсты не чытаюць каментары «// this definitely works».

Ідэя «паглядзі на сваю памылку і паспрабуй зноў» добра апісаная ў працах Reflexion¹² і Self-Refine¹³. Але ключавое слова тут — знешні экзаменатар. Мадэль, якая правярае сама сябе без кампілятара, — гэта студэнт, які сам сабе ставіць адзнаку. Адгадайце, якую.

Матэматычная мадэль

Хай Cₖ — код, згенераваны на ітэрацыі k. Дэтэрмінаваны правяральнік V: 𝒞 → {1, 0} × ℰ вяртае статус «праверка пройдзена / не пройдзена» і апісанне памылкі Eₖ. Калі V(Cₖ) = (0, Eₖ), запускаецца ітэрацыя самаправеркі:

text
1Cₖ₊₁ = LLM(M_base ‖ Cₖ ‖ Eₖ)

Цыкл паўтараецца, пакуль не атрымаецца V(Cₖ) = (1, ∅) або пакуль не будзе перавышаны ліміт k > Kₘₐₓ.

Мадэль атрымлівае папярэднюю версію свайго кода разам з тэкстам памылкі і спрабуе зноў. Ліміт Kₘₐₓ — гэта мяжа цярпення: без яго агент будзе пераздаваць да цеплавой смерці Сусвету (або да канца вашага бюджэту, што наступіць раней).

Што добра, што дрэнна

Апора на правяральныя вынікі (Grounding). Памылкі, якія можна праверыць аўтаматычна, — сінтаксіс, тыпы, тэсты — адсякаюцца жорстка і аб'ектыўна. Але толькі яны. Калі тэсты не правяраюць логіку, інструмент праверкі яе не заўважыць.
Самакарэкцыя. Дакладная трасіроўка стэка (stack trace — паслядоўнасць выклікаў, якая прывяла да памылкі) — гэта лепшы прампт, які вы можаце даць мадэлі. Лепшы за любы «калі ласка, будзь уважлівы».
Слабасць: падгонка пад тэсты (Overfitting to Tests). Атрымаўшы задачу «зрабі так, каб тэст праходзіў», агент часам робіць менавіта гэта. Напрыклад, мяняе сам тэст. Або дадае if (process.env.NODE_ENV === 'test') return true. Тэхнічна — задача выканана. Гэта студэнт, які завучыў адказы на білеты і не разумее прадмета. Таму тэсты, якія піша сам агент, варта правяраць асабліва ўважліва.
Калі выкарыстоўваць: заўсёды, калі ёсць аб'ектыўны крытэрый «правільна / няправільна». Гэта самы танны спосаб істотна павысіць якасць.

Памяць агента: тры шуфляды

Мы ўжо высветлілі, што трымаць усё ў адной бясконцай размове — дрэнная ідэя. Што ж тады рабіць з інфармацыяй, якая можа спатрэбіцца пазней?

Адказ — тое ж, што робіць любы арганізаваны чалавек. Ёсць тое, што ў вас перад вачыма. Ёсць нататнік на стале. І ёсць кніжная паліца з даведнікамі, куды вы зазіраеце па патрэбе.

І вось як гэтыя шуфляды ўзаемадзейнічаюць на працягу адной сесіі:

Тры ўзроўні памяці

L1: Working Memory (аператыўная памяць, вакно ўвагі)
- Аб'ём: |L1| ≤ C_work (у сучасных мадэлях — ад дзясяткаў тысяч да ~1 млн токенаў).
- Функцыя: толькі тое, што трэба зараз: сістэмныя інструкцыі, мэта, бягучы крок плана, вынік апошняга выкліку інструмента.
- Не падманвайцеся лічбай «мільён токенаў». Тое, што ў вакно змяшчаецца мільён, не азначае, што мадэль аднолькава добра працуе з мільёнам. Глядзіце вышэй пра Context Rot.
L2: Ephemeral Task Memory (памяць сесіі)
- Структура: запісы размоў, у якія толькі дапісваюць (append-only), і файлы-чарнавікі (transcript.jsonl, scratch/).
- Функцыя: ляжыць па-за вакном увагі. Агент зазірае туды па патрэбе, не засмечваючы L1. Нататнік на стале.
L3: Long-Term Memory (доўгатэрміновая памяць праекта)
- Структура: файлы з інструкцыямі (AGENTS.md¹⁴, CLAUDE.md), Knowledge Items (захаваныя даведачныя матэрыялы) або вектарныя базы (Vector RAG — пошук па сэнсе тэксту, а не па словах).
- Функцыя: правілы рэпазіторыя, стыль кода, архітэктурныя дамоўленасці. Кніжная паліца. Агент звяртаецца да яе на пачатку працы — і, у адрозненне ад новага калегі, нават сапраўды чытае.

Параўнанне архітэктур

Архітэктурны патэрн	Складанасць рэалізацыі	Выкарыстанне токенаў	Узровень аўтаномнасці	Рызыка зацыклівання	Прадказальнасць
1. Single-Loop (ReAct)	🟢 Нізкая	🔴 `O(T²)` (высокае)	🟡 Сярэдні	🔴 Высокая	🔴 Нізкая
2. Spec-Driven	🟡 Сярэдняя	🟢 `O(K · L²)` (нізкае)	🟢 Высокі	🟢 Нізкая	🟢 Высокая
3. Orchestrator-Worker	🔴 Высокая	🟡 Сярэдняе ў аркестратара, але 🔴 высокае сумарна	🟢 Вельмі высокі	🟢 Нізкая	🟢 Высокая
4. Event-Driven (ACP)	🔴 Высокая	🟡 Як у базавага цыкла	🟢 Вельмі высокі	🟡 Сярэдняя	🟡 Сярэдняя
5. Tool-Mediated (MCP)	🟡 Сярэдняя	🟡 Сярэдняе (схемы інструментаў)	🟡 Сярэдні	🟢 Нізкая	🟢 Вельмі высокая
6. Verifier Loop	🟡 Сярэдняя	🔴 Высокае (самаправерка)	🟢 Высокі	🟢 Вельмі нізкая	🟢 Вельмі высокая (у межах пакрыцця тэстамі)

Як чытаць: 🟢 — добра для вас, 🔴 — кошт або рызыка. Заўважце заканамернасць: усё, што робіць агента надзейнейшым, робіць яго і складанейшым. Бясплатных абедаў няма. Ёсць толькі абеды, кошт якіх вы пакуль не ўбачылі ў рахунку.

Які патэрн выбраць

Як гэта выглядае ў рэальнасці: гібрыды

Ні Claude Code, ні Antigravity, ні Zed не выбіраюць «адзін правільны патэрн». Яны збіраюць усе шэсць, як канструктар, і кожны выконвае сваю ролю. Anthropic у сваім дапаможніку Building effective agents¹⁵ дае, дарэчы, вельмі цвярозую параду: пачынайце з найпрасцейшага рашэння і ўскладняйце толькі тады, калі гэта сапраўды неабходна. Гібрыд — гэта не мэта, а вынік шматлікіх «а вось тут не хапае...».

Сувязь з рэдактарам — праз Event-Driven пратакол (ACP): вы бачыце прагрэс і не чакаеце.
Агульнае планаванне — Spec-Driven: план, які вы правяраеце.
Брудная праца — субагенты: пошук і аналіз без засмечвання галоўнага кантэксту.
Знешні свет — MCP-сэрверы пад кантролем хоста.
Фінальная праверка — Verifier Loop: кампілятар, лінтар, тэсты.

А ўнутры кожнага з гэтых кубікаў па-ранейшаму круціцца стары добры ReAct-цыкл з 2022 года. Проста цяпер яна кароткая і не паспявае ператварыцца ў двухгадзінны сход.

Па сутнасці, уся гісторыя развіцця агентаў апошніх гадоў — гэта не гісторыя «мадэлі сталі разумнейшымі» (хоць і сталі). Гэта гісторыя пра тое, як інжынеры навучыліся не перашкаджаць разумнай мадэлі сваім брудным кантэкстам.

Пад капотам: як гэта зроблена ў Claude Code, Codex і кампаніі

Тэорыя — гэта добра, але давайце адкрыем капот у інструментаў, якімі вы, магчыма, карыстаецеся цяпер. Папярэджанне: усё ніжэй — стан на восень 2026 года. У гэтай індустрыі «стабільная версія» жыве прыкладна як малако ў халадзільніку, таму звярайцеся з дакументацыяй.

Claude Code: аркестратар з брыгадай па змаўчанні

Калі вы адкрываеце Claude Code, вы размаўляеце з адным галоўным агентам — класічным ReAct-цыклам. Але ў яго за спінай ужо стаіць брыгада. У базавай канфігурацыі ёсць шэсць убудаваных субагентаў¹⁶:

Субагент	Што робіць	Цікавая дэталь
Explore	Пошук па кодзе і файлах	Толькі чытанне. Не загружае `CLAUDE.md` і git status — каб быць хуткім і танным
Plan	Даследаванне ў рэжыме планавання	Таксама толькі чытанне: увесь бруд пошуку застаецца ў ім, а не ў галоўным кантэксце
general-purpose	Складаныя шматкрокавыя задачы	Мае ўсе інструменты, можа і чытаць, і змяняць
claude	«Усё астатняе»	Універсальны выканаўца
statusline-setup	Наладжвае радок статусу	Працуе на Sonnet — для такой задачы Opus быў бы як экскаватар для пасадкі кветак
claude-code-guide	Адказвае на пытанні пра сам Claude Code	Працуе на Haiku — найтаннейшая мадэль для даведкі

Па сутнасці, гэта патэрн Orchestrator-Worker, усталяваны па змаўчанні. Тры субагенты-выканаўцы плюс два службовыя і адзін універсальны. І вось што з імі робяць цікавага:

Субагенты могуць запускаць субагентаў — да трох узроўняў уніз. Далей інструмент Agent проста забіраюць. Без гэтага ліміту мы б атрымалі рэкурсіўную піраміду, дзе стажор наймае стажора, які наймае стажора, а працаваць не застаецца каму.
Да 20 субагентаў адначасова, у тым ліку ў фоне: вы працуеце, яны працуюць, вынік прыходзіць паведамленнем.
Форкі (fork — асобныя галіны працы з копіяй кантэксту). Звычайны субагент пачынае з нуля і не бачыць вашай размовы — гэта той самы «сапсаваны тэлефон». Форк жа ўспадкоўвае ўвесь кантэкст бацькі. Гэта прамы адказ на праблему страты інфармацыі пры перадачы: калі задача патрабуе ведаць усё, што ўжо высветлена, — не пераказвайце, а клануйце.
Agent Teams (эксперыментальная функцыя, выключаная па змаўчанні)¹⁷. Гэта ўжо не «прараб і брыгада», а «каманда на працоўнай нарадзе»: удзельнікі пішуць адзін аднаму напрамую праз паштовыя скрыні (звычайныя JSON-файлы), бяруць задачы з агульнага спісу і нават спрачаюцца. Дакументацыя прама прапануе сцэнарый «пяць агентаў правяраюць пяць гіпотэз і спрабуюць абвергнуць высновы адзін аднаго, як на навуковай дыскусіі». Каштуе гэта адпаведна: кожны ўдзельнік — асобны экзэмпляр Claude са сваім кантэкстам.

А цяпер — як Claude Code закрывае праблемы, пра якія мы гаварылі вышэй:

Гніенне кантэксту → аўтаматычнае сцісканне (auto-compaction)¹⁸. Калі кантэкст набліжаецца да мяжы, размова замяняецца структураваным кароткім пераказам. Самае цікавае — што выжывае: CLAUDE.md і план з рэжыму планавання перачытваюцца з дыска, а не з памяці. То бок мэта h₀ і план P фізічна не могуць «патануць» — гэта як старшыня, які пасля кожнага перапынку зноў чытае ўслых парадак дня. Акрамя таго, агент перачытвае да пяці апошніх змененых файлаў. Можна і ўручную: /compact focus on the auth bug — «сціскай, але пра аўтарызацыю не забывай».
Схемы MCP з'ядаюць кантэкст → tool search¹⁹. На пачатку працы загружаюцца толькі назвы інструментаў, а поўныя апісанні — па патрэбе. У рэжыме auto пошук уключаецца, калі схемы займаюць больш за 10% вакна. Дадаткова — абарона ад «балбатлівых» сэрвераў: на адказ MCP-інструмента больш за 10 000 токенаў Claude Code выдае папярэджанне, а па змаўчанні абразае на 25 000.
Бяспека → пясочніца на ўзроўні АС²⁰. На macOS — Seatbelt, на Linux — bubblewrap, сетка — праз проксі з белым спісам даменаў. Мая любімая дэталь: файлы .claude/settings, .mcp.json і .git/hooks абаронены ад запісу нават унутры пясочніцы. Каб агент не мог, так бы мовіць, сам сабе выпісаць даверанасць. Хтосьці ў Anthropic відавочна думаў пра тое, як бы паступіў хітры стажор.
Фальшывае «Гатова!» → аўтаматычныя праверкі праз хукі. Хук PostToolUse можа запускаць лінтар пасля кожнай праўкі. А ў Agent Teams хук TaskCompleted з кодам выхаду 2 проста не дае пазначыць задачу выкананай, пакуль праверка не пройдзе. Экзаменатар, з якім нельга дамовіцца, — у чыстым выглядзе.
Канфлікты адначасовых змен → блакіроўкі і асобныя працоўныя дрэвы Git. У камандах агентаў задачы бяруцца з агульнага спісу праз блакіроўку файлаў — двое не схопяць адно і тое ж. А субагента можна запусціць у асобным працоўным дрэве Git (git worktree), каб ён увогуле не дакранаўся да вашых файлаў.

Codex (OpenAI): той жа рэцэпт, іншыя спецыі

Codex прыйшоў да той жа архітэктуры, але з іншымі акцэнтамі. Субагенты сталі даступныя ўсім у сакавіку 2026 года, і ў базавай канфігурацыі іх тры²¹:

Субагент	Што робіць
default	Універсальны выканаўца «на ўсё»
worker	Выкананне: рэалізацыя і выпраўленні
explorer	Чытанне і даследаванне кода

Цікава, як па-рознаму дзве каманды адказалі на пытанне «калі запускаць субагентаў». Codex па змаўчанні больш стрыманы: ён дэлегуе, калі вы прама папрасілі або калі гэтага патрабуе AGENTS.md ці набор інструкцый (skill). Галоўны агент чакае, пакуль усе субагенты скончаць працу, і збірае адзіны адказ. Дакументацыя сумленна папярэджвае: субагенты «спажываюць больш токенаў, чым аналагічны запуск аднаго агента». Брыгада, як мы памятаем, бясплатна не працуе.

Уласныя агенты апісваюцца TOML-файламі ў .codex/agents/. І тут вельмі слушнае архітэктурнае рашэнне: карыстальніцкі агент не можа перавызначыць пясочніцу, палітыку ўхвалення і MCP. Можна змяніць мадэль, інструкцыі, «колькасць разумовых намаганняў» — але не правы доступу. Інакш кожны «агент-памочнік» з GitHub быў бы патэнцыйным траянскім канём.

Што тут цікавага:

Тры рэжымы пясочніцы²²: read-only (толькі глядзець), workspace-write (правіць у межах праекта — рэжым па змаўчанні для лакальнай працы) і danger-full-access (назва як бы намякае). На macOS — той жа Seatbelt, на Linux — той жа bubblewrap. Розныя кампаніі, аднолькавыя высновы.
Auto-review: Verifier для бяспекі. Калі агенту трэба выйсці за межы пясочніцы (напрыклад, у сетку), запыт можна адправіць не вам, а іншаму агенту-рэцэнзенту. Гэта патэрн Verifier Loop, ужыты не да кода, а да дазволаў. Агент правярае агента — элегантна. Ці трывожна. Залежыць ад таго, колькі кавы вы ўжо выпілі.
Іерархія AGENTS.md²³. Codex збірае інструкцыі ад глабальнага файла да бягучай тэчкі, па адным файле на ўзровень, і бліжэйшыя да кода маюць прыярытэт. Ёсць нават AGENTS.override.md — часовае перавызначэнне без выдалення асноўнага файла.
І праблема, пра якую мала хто ведае: агульны ліміт — 32 KiB (project_doc_max_bytes). Калі вашы AGENTS.md разам большыя — Codex моўчкі перастае дадаваць файлы. Без памылкі, без папярэджання. І звычайна адразаюцца якраз самыя бліжэйшыя да кода, самыя канкрэтныя правілы. Прыгожая іронія: механізм, які павінен змагацца з перапаўненнем кантэксту, сам пакутуе ад перапаўнення.

Cursor: грубая сіла паралелізму

Cursor у версіі 2.0 (кастрычнік 2025) зрабіў стаўку на паралелізм: да васьмі агентаў на адзін прампт, кожны ў сваім git worktree або на аддаленай машыне²⁴. Гэта не «прараб і брыгада», а хутчэй «восем архітэктараў атрымалі адно заданне — выбірайце лепшы праект». Праблему канфліктаў адначасовых змен тут вырашаюць радыкальна: агенты проста не дзеляць файлы.

Адчыняем код: Zed і Warp

Дагэтуль мы чыталі дакументацыю. Дакументацыя — гэта тое, што кампанія хоча, каб вы ведалі. Код — тое, што адбываецца насамрэч. На шчасце, у двух папулярных інструментаў код адкрыты: Zed²⁵ і Warp²⁶ (апошні адкрыў кліент пад AGPL-3.0 у красавіку 2026 года). Дарэчы, Codex CLI таксама адкрыты, так што пры жаданні гэтую экскурсію можна працягнуць самастойна.

Усё ніжэй — з галоўных галін рэпазіторыяў па стане на канец кастрычніка 2026 года. Шляхі да файлаў пазначаны, каб вы маглі праверыць самі, а не верыць мне на слова.

Zed: агент, які чытаецца як падручнік

Агент Zed жыве ў крэйце (пакеце Rust) crates/agent. Сэрца — файл thread.rs на 10 тысяч радкоў. Так, увесь ReAct-цыкл, сцісканне, паўторы і субагенты — у адным файле. Rust-распрацоўшчыкі, відаць, не баяцца доўгіх файлаў. Ці баяцца, але моўчкі.

Што там цікавага.

1. Субагенты без унукаў. Інструмент spawn_agent (tools/spawn_agent_tool.rs) запускае субагента, а ліміт глыбіні зашыты канстантай:

rust
1pub const MAX_SUBAGENT_DEPTH: u8 = 1;

Адзін узровень. Галоўны агент можа наняць стажора, стажор наняць нікога не можа. Параўнайце з тымі трыма ўзроўнямі ў Claude Code: дзве каманды паглядзелі на адну і тую ж праблему (рэкурсія субагентаў) і паставілі планку ў розных месцах.

Але самае каштоўнае — не код, а апісанне інструмента для мадэлі. Гэта, па сутнасці, мініпадручнік па патэрне Orchestrator-Worker, напісаны для LLM. Некалькі радкоў адтуль (у перакладзе):

Субагент не бачыць вашай размовы. Перадавайце ўвесь патрэбны кантэкст: шляхі, патрабаванні, абмежаванні.

Не выкарыстоўвайце гэты інструмент для задач, якія можна зрабіць адным-двума выклікамі. Напрыклад, не прасіце агента прачытаць адзін файл і вярнуць змест — зрабіце гэта самі.

Для задач з праўкай кода раздзяляйце працу так, каб у кожнага субагента быў асобны набор файлаў для запісу, які не перасякаецца з наборамі іншых субагентаў (disjoint write set).

Для ўдакладненняў выкарыстоўвайце існуючы session_id — агент ужо памятае папярэднюю размову. Не паўтарайце задачу.

Глядзіце, колькі праблем з нашага спісу закрыта проста тэкстам: другі пункт — супраць выбуху коштаў, трэці — супраць канфліктаў адначасовых змен, чацвёрты — супраць сапсаванага тэлефона. Ніякай складанай інжынерыі, проста добра напісаная інструкцыя. Архітэктура агента часткова жыве ў прамптах — і гэта, бадай, самае нечаканае, што можна знайсці ў кодзе.

2. Сцісканне, якое шануе вашы словы. Аўтасцісканне ўключаецца, калі вакно запоўнена на 90% (AutoCompactThreshold::DEFAULT), і толькі для мадэляў з вакном ад 80 тысяч токенаў — на меншых, як сумленна пішуць у каментары, «няма дастаткова месца, каб сцісканне мела сэнс». А цяпер самая прыгожая дэталь:

rust
1// Using the heuristic that 1 token is about 4 bytes, keep the last
2// 80K bytes of user-message content (~20k tokens).
3const COMPACTION_RETAINED_USER_MESSAGES_BYTE_BUDGET: usize = 80_000;

Пры сцісканні адказы агента пераказваюцца, а вашы паведамленні захоўваюцца даслоўна (апошнія ~20 тысяч токенаў). Гэта ідэальна трапляе ў нашу тэорыю: пачатковая мэта h₀ і ўсе ўдакладненні — гэта менавіта словы карыстальніка. Агент можа забыць, што ён рабіў, але не што вы прасілі. Як добры падначалены: свае справаздачы скарачае, а ваша заданне перапісвае ў нататнік слова ў слова.

Сам прампт для сціскання (agent_settings/src/prompts/compaction_prompt.txt) таксама варта прачытаць. Ён просіць падрыхтаваць нататку для перадачы працы іншаму агенту з пяці пунктаў: мэта, стан, кантэкст, наступныя крокі і пасткі — «што спрабавалі і што не спрацавала». Апошні пункт асабліва каштоўны: без яго агент пасля сціскання з радасцю наступае на тыя ж граблі другі раз.

3. Рэдагаванне, якое не верыць мадэлі. LLM рэгулярна памыляецца ў адступах і прабелах, калі цытуе кавалак кода, які трэба замяніць. Таму ў edit_session/ ляжыць streaming_fuzzy_matcher.rs — механізм недакладнага пошуку (fuzzy matching) месца праўкі, які працуе непасрэдна падчас патокавай перадачы адказу, — і асобны reindent.rs. Ёсць і прыгожая дэталь: калі гэты механізм знаходзіць два аднолькава добрыя месцы, ён спыняецца і не гадае. Лепш памылка, чым праўка не ў тым месцы.

4. LLM як суддзя для самога агента. У tools/evals/ ляжаць тэсты інструмента рэдагавання на рэальных прыкладах (before.rs / after.rs), а шаблон templates/diff_judge.hbs просіць іншую мадэль ацаніць атрыманыя змены паводле спіса сцвярджэнняў, выставіўшы адзнаку ад 0 да 100. Гэта Verifier Loop, але падчас распрацоўкі самога агента: каманда Zed правярае, ці не пачаў агент горш рэдагаваць пасля чарговай змены прампта.

5. Пясочніца і профілі. Крэйт crates/sandbox змяшчае macos_seatbelt.rs, linux_bubblewrap.rs і windows_wsl.rs — той самы набор, што ў Claude Code і Codex. Але пакуль яна даступная толькі пры ўключэнні эксперыментальнай налады. Тры ўбудаваныя профілі агента — write, ask і minimal — гэта, па сутнасці, наборы дазволеных інструментаў: ад «рабі што трэба» да «толькі адказвай на пытанні».

6. ACP — і так, у яго ўжо дзве версіі. У crates/agent_servers/src/acp/ ляжаць v1.rs і v2.rs. Zed можа быць хостам для ўласнага агента і для чужых (Claude Code, Codex, Gemini CLI) праз адзін пратакол. Уласны агент Zed падлучаецца праз той жа інтэрфейс (native_agent_server.rs), што і знешнія, — сваім ніякіх прывілеяў.

Warp: тонкі кліент, мазгі на серверы

Warp — гэта тэрмінал, які ператварыўся ў «асяроддзе агентнай распрацоўкі». І першае, што высвятляецца пры чытанні кода, — сам агентны цыкл у адкрытым кліенце вы не знойдзеце. Крэйт crates/warp_multi_agent_client робіць POST-запыт з protobuf на сервер Warp і атрымлівае назад струмень падзей (Server-Sent Events). Кліент адлюстроўвае гэтыя падзеі і выконвае дзеянні: запускае каманды, правіць файлы. А вось рашэнні — які інструмент выклікаць, што напісаць — прымаюцца на серверы, код якога закрыты.

Гэта класічны Event-Driven у самым літаральным выглядзе: кліент — рукі і вочы, сервер — мозг. Плюсы зразумелыя: Warp можа мяняць прампты і логіку агента, не выпускаючы новую версію праграмы. Мінус таксама: «адкрыты код» тут — гэта адкрытыя рукі. Мозг па-ранейшаму за зачыненымі дзвярыма. Так што назва «агент з адкрытым кодам» тут крыху як «адкрытая кухня» ў рэстаране, дзе шэф-кухар працуе ў суседнім будынку.

Але і ў кліенце ёсць што паглядзець:

1. Тры ўзроўні даверу. Дазволы агента (app/src/ai/execution_profiles/config.rs) апісаныя адным пералічальным тыпам (enum):

rust
1enum FileActionPermission {
2    AgentDecides,  // агент сам вырашае, ці пытаць дазволу
3    AlwaysAllow,   // без пытанняў
4    #[default]
5    AlwaysAsk,     // заўсёды пытаць
6}

Па змаўчанні — AlwaysAsk. І асобна — варыянт AgentDecides, «агент сам вырашае, ці трэба пытацца ў вас дазволу». Тое, што ў іншых інструментах робіць асобны класіфікатар або агент-рэцэнзент, тут даверана самому агенту. Смелае рашэнне. Прыкладна як дазволіць падлетку самому вырашаць, ці трэба пытацца, перш чым узяць машыну.

2. Аркестрацыя з квітком. Інструмент run_agents запускае некалькі агентаў — лакальна або на аддаленых машынах. Перш чым гэта адбудзецца, вы бачыце картку пацвярджэння. Але ёсць хітрасць (crates/ai/src/agent/orchestration_config.rs): калі параметры запуску (мадэль, рэжым выканання, машына) супадаюць з канфігурацыяй, якую вы ўжо ўхвалілі, картка не паказваецца і агенты стартуюць адразу. Адзін раз пагадзіліся з правіламі — далей толькі ў межах гэтых правіл. Добры кампраміс паміж бяспекай і ўтомай ад бясконцых «Дазволіць?».

3. Два фарматы праўкі. Модуль crates/ai/src/diff_validation разумее і «знайдзі-і-замяні» (search and replace), і фармат V4A — той самы apply_patch, які OpenAI рэкамендуе для сваіх мадэляў. Тэлеметрыя фіксуе, чаму не ўдалося ўнесці праўку, а каментар у кодзе асобна патрабуе, каб кожны новы тып памылкі быў відавочна аднесены да «трэба паўтараць» ці «не трэба». Няздольнасць агента ўнесці праўку ў патрэбнае месца файла — адна з самых частых і самых непрыкметных праблем. Тут яе хаця б вымяраюць.

4. Індэкс кода праз дрэва Меркла. У crates/ai/src/index/full_source_code_embedding/ — L3-памяць у выглядзе вектарнага індэкса кода праекта. Кліент будуе дрэва Меркла файлаў (як у git) і адпраўляе на сервер толькі змененыя часткі, а пераіндэксацыя ідзе кожныя 20 хвілін. І вельмі шчыры каментар:

We are not attaching any context lines right now since it does not seem to improve quality and is causing extra token efficiency issues.

Па-беларуску: «мы не дадаем радкі кантэксту вакол знойдзеных фрагментаў, бо якасць ад гэтага не расце, а токенаў ідзе больш». Гэта ўвесь наш раздзел пра гніенне кантэксту ў адным сказе: больш кантэксту ≠ лепш. І гэта не з навуковага артыкула, а з кода рэальнага прадукту, дзе за кожны токен плацяць.

5. Самы цікавы артэфакт — не код. У корані рэпазіторыя ляжыць тэчка specs/ з амаль трыма сотнямі падтэчак. У кожнай — PRODUCT.md (што робім і навошта) і TECH.md (як робім). А ў AGENTS.md рэпазіторыя ёсць раздзел «Implementation Validation Order»: падрабязны парадак, калі агенту запускаць праверкі, тэсты, лінтар і фарматаванне — каб не марнаваць час на поўную зборку пасля кожнага радка.

Іншымі словамі, Warp распрацоўвае свайго агента з дапамогай агентаў па патэрне Spec-Driven, а AGENTS.md у іх — гэта рэцэпт Verifier Loop з улікам выдаткаў часу. Калі вы шукаеце прыклад «як пісаць AGENTS.md для сапраўднага вялікага праекта» — вось ён, адкрыты.

Што паказвае код, чаго не паказвае дакументацыя

Архітэктура — гэта часта проста тэкст. Палова «патэрнаў» з нашага артыкула ў Zed рэалізавана не кодам, а апісаннем інструмента для мадэлі. Калі хочаце зразумець, як паводзіць сябе агент, чытайце яго прампты.
Канстанты кажуць больш за маркетынг. MAX_SUBAGENT_DEPTH = 1, парог сціскання 90%, 80 KB вашых слоў, пераіндэксацыя раз на 20 хвілін — за кожнай лічбай стаяць нечыя эксперыменты і рахунак за API.
«Адкрыты» не значыць «увесь код». У Zed агентны цыкл ляжыць на вачах. У Warp — толькі рукі, а мозг на серверы. Абодва падыходы маюць права на жыццё, але варта разумець, што менавіта вы чытаеце.
Мадэлям не давяраюць. Недакладны пошук месца праўкі, адмова ад неадназначных супадзенняў, тэлеметрыя няўдалых правак — значная частка кода агента існуе для таго, каб падстрахаваць мадэль ад яе ўласных памылак.

Параўнанне ў адной табліцы

	Claude Code	Codex	Zed	Warp	Cursor
Код агента	Закрыты	Адкрыты (CLI)	Адкрыты	Кліент адкрыты, цыкл на серверы	Закрыты
Убудаваныя субагенты	6 (Explore, Plan, general-purpose, claude + 2 службовыя)	3 (default, worker, explorer)	Адзін універсальны `spawn_agent`	`run_agents` (лакальна або аддалена)	— (паралельныя агенты)
Калі дэлегуе	Сам вырашае	Па просьбе або па AGENTS.md	Сам вырашае	Пасля пацвярджэння канфігурацыі	Вы запускаеце паралельна
Укладзенасць	Да 3 узроўняў	Не задакументавана	1 узровень	—	—
Паралельнасць	Да 20 субагентаў	Ліміт выбірае Codex (наладжваецца)	Так	Так	Да 8 агентаў
Сцісканне	Аўта; план і CLAUDE.md з дыска	Аўта	Аўта на 90%; словы карыстальніка даслоўна	У кліенце не відаць (логіка на серверы)	—
Файл памяці	CLAUDE.md (або AGENTS.md) + auto memory	AGENTS.md (≤ 32 KiB)	AGENTS.md / `.rules`, наборы інструкцый (skills)	AGENTS.md / WARP.md, наборы інструкцый (skills), індэкс кода	Правілы праекта
Ізаляцыя	Seatbelt / bubblewrap, worktrees	Seatbelt / bubblewrap, 3 рэжымы	Seatbelt / bubblewrap / WSL (праз эксперыментальную наладу)	Профілі дазволаў	Worktrees / аддаленыя машыны
Праверка	Hooks (PostToolUse, TaskCompleted)	Аўтаматычная праверка дазволаў	LLM-суддзя ў ацэначных тэстах	Тэлеметрыя няўдалых правак	—

Праблемныя месцы архітэктур і як іх лечаць

Ніводная архітэктура не бясплатная. Кожнае рашэнне нараджае новую праблему, а кожная праблема — новую функцыю ў спісе змен. Вось зводная карта «хваробы → лекі», складзеная на аснове ўсяго сказанага вышэй:

Праблема	Дзе ўзнікае	Як вырашаюць	Што застаецца нявырашаным
Гніенне кантэксту	ReAct, доўгія сесіі	Аўтаматычнае сцісканне; план і `CLAUDE.md` перачытваюцца з дыска	Кароткі пераказ заўсёды нешта апускае. Тое, што сціскальнік палічыў няважным, знікае. Правілы, прывязаныя да шляхоў (`paths:`), у Claude Code пасля сціскання знікаюць і вяртаюцца, толькі калі агент зноў дакранецца да адпаведнага файла
Страта інфармацыі пры перадачы	Orchestrator-Worker	Форкі, магчымасць задаць субагенту дадатковыя пытанні, просьба «вяртай кароткія справаздачы, а не неапрацаваны вывад»	Чым мацней сціскаеш — тым больш губляеш. Залатой сярэдзіны няма
Кошт	Субагенты, Agent Teams	Таннейшыя мадэлі для субагентаў (`default_subagent_model` у Codex, Haiku для даведкі ў Claude Code); Explore не загружае `CLAUDE.md`	Каманда з пяці агентаў усё роўна каштуе як каманда з пяці агентаў
Канфлікты адначасовых змен	Event-Driven, паралельныя агенты	Worktrees (Cursor, Claude Code), блакіроўкі ў спісе задач	Канфлікты пры зліцці галін нікуды не дзяюцца — іх проста адкладваюць на потым
Перагрузка схемамі MCP	Tool-Mediated	Tool search, ліміты на памер адказу	Агенту трэба здагадацца, што патрэбны інструмент існуе, каб яго знайсці
Бяспека	Усе, асабліва MCP	Пясочніца АС, сеткавы проксі, абароненыя файлы, агенты не могуць змяніць свае правы	Чытаць пясочніца па змаўчанні дазваляе амаль усё, уключна з `~/.ssh` — гэта трэба закрываць самому
Падгонка пад тэсты / фальшывае «Гатова»	Verifier Loop	Хукі, якія блакуюць завяршэнне; агент-рэцэнзент	Калі тэсты піша той жа агент, што і код, — ён сам сабе экзаменатар
Перапоўнены AGENTS.md	L3-памяць	Укладзеныя файлы па тэчках, файлы з інструкцыямі, якія маюць прыярытэт	Ліміты (32 KiB у Codex) і ціхае абразанне. Больш інструкцый ≠ лепшы агент

Калі паглядзець на гэтую табліцу збоку, відаць цікавую рэч: апошні слупок амаль заўсёды пра чалавека. Ніводная архітэктура пакуль не адмяняе неабходнасці ў чалавеку, які прачытае план, напіша добрыя тэсты і не дасць агенту danger-full-access у пятніцу ўвечары.

Што можна зрабіць ужо заўтра

Напішыце AGENTS.md (або CLAUDE.md) для свайго праекта. Гэта L3-памяць, якая эканоміць агенту дзясяткі крокаў даследавання ў кожнай сесіі. Пяць радкоў «як запусціць тэсты» і «што тут нельга чапаць» акупяцца ў першы ж дзень.
Перад вялікімі зменамі прасіце план, а не код. Праверыць план — хвіліна. Разбіраць наступствы неправеранага плана — вечар.
Дайце агенту спосаб праверыць сябе. Каманда для тэстаў, лінтара, зборкі. Агент без знешняй праверкі — гэта аптыміст без люстэрка.
Новая задача — новая сесія. Доўгая сесія — гэта той самы сход, дзе пра ключ ад падвала ўжо ніхто не памятае. Закрывайце яго і склікайце новы.
Не падлучайце MCP-сэрверы «на ўсялякі выпадак». Калі ваш кліент не ўмее tool search, кожны сэрвер займае месца ў кантэксце, нават калі ні разу не спатрэбіўся. А калі ўмее — агенту ўсё роўна трэба выбіраць з доўгага спісу. Агент — не швейцарскі нож, яму не патрэбны штопар для задачы на CSS.

Мадэлі будуць станавіцца разумнейшымі. Кантэкстныя вокны — большымі. Але фізіку гэта не адменіць: увага — абмежаваны рэсурс. У людзей таксама, дарэчы. Можа, таму архітэктура добрага агента так моцна нагадвае арганізацыю працы добрай каманды.

Крыніцы

Anthropic. Introducing the Model Context Protocol. 2024. anthropic.com/news/model-context-protocol · Спецыфікацыя: modelcontextprotocol.io ↩ ↩²
Agent Client Protocol. agentclientprotocol.com · github.com/zed-industries/agent-client-protocol ↩ ↩²
Kaelbling L. P., Littman M. L., Cassandra A. R. Planning and acting in partially observable stochastic domains. Artificial Intelligence, 1998. doi.org/10.1016/S0004-3702(98)00023-X ↩
Vaswani A. et al. Attention Is All You Need. 2017. arxiv.org/abs/1706.03762 ↩
Liu N. F. et al. Lost in the Middle: How Language Models Use Long Contexts. 2023. arxiv.org/abs/2307.03172 ↩
Chroma Research. Context Rot: How Increasing Input Tokens Impacts LLM Performance. 2025. research.trychroma.com/context-rot ↩
Anthropic. Effective context engineering for AI agents. 2025. anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩
Yao S. et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022. arxiv.org/abs/2210.03629 ↩
Wang L. et al. Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. 2023. arxiv.org/abs/2305.04091 ↩
Anthropic. How we built our multi-agent research system. 2025. anthropic.com/engineering/built-multi-agent-research-system ↩
Wu Q. et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. 2023. arxiv.org/abs/2308.08155 ↩
Shinn N. et al. Reflexion: Language Agents with Verbal Reinforcement Learning. 2023. arxiv.org/abs/2303.11366 ↩
Madaan A. et al. Self-Refine: Iterative Refinement with Self-Feedback. 2023. arxiv.org/abs/2303.17651 ↩
AGENTS.md — адкрыты фармат інструкцый для агентаў. agents.md ↩
Anthropic. Building effective agents. 2024. anthropic.com/research/building-effective-agents ↩
Claude Code Docs. Subagents. code.claude.com/docs/en/sub-agents ↩
Claude Code Docs. Orchestrate teams of Claude Code sessions. code.claude.com/docs/en/agent-teams ↩
Claude Code Docs. Explore the context window (раздзел «What survives compaction»). code.claude.com/docs/en/context-window ↩
Claude Code Docs. Connect Claude Code to tools via MCP (раздзел «Scale with MCP tool search»). code.claude.com/docs/en/mcp ↩
Claude Code Docs. Sandboxing. code.claude.com/docs/en/sandboxing ↩
OpenAI Codex Docs. Subagents. learn.chatgpt.com/docs/agent-configuration/subagents ↩
OpenAI Codex Docs. Sandboxing. learn.chatgpt.com/docs/sandboxing ↩
OpenAI Codex Docs. Custom instructions with AGENTS.md. learn.chatgpt.com/docs/agent-configuration/agents-md ↩
Cursor. Changelog 2.0. 2025. cursor.com/changelog/2-0 ↩
Zed Industries. zed (зыходны код). github.com/zed-industries/zed — гл. crates/agent, crates/agent_servers, crates/agent_settings, crates/sandbox. ↩
Warp. warp (зыходны код кліента, AGPL-3.0). github.com/warpdotdev/warp — гл. crates/ai, crates/warp_multi_agent_client, app/src/ai, specs/, AGENTS.md. ↩

Admin, 2026-08-20

Каментары

Увайдзіце ў свой уліковы запіс, каб пакінуць каментар

Увайсці

Пакуль няма каментароў — будзьце першым!