Або: чаму ваш агент забыў, што павінен быў зрабіць, і што з гэтым рабіць
Памятаеце часы, калі «ШІ ў рэдактары» азначала акенца чата збоку, куды можна было ўставіць кавалак кода і спытаць «чаму гэта не працуе»? Гэта было нядаўна. Па мерках нашай індустрыі — у мінулай геалагічнай эпосе.
Сёння агент сам лазіць па рэпазіторыі, сам піша план, сам запускае тэсты, сам атрымлівае памылкі і сам жа іх выпраўляе. Часам — у правільным парадку.
І вось тут высвятляецца непрыемная рэч: разумная мадэль — гэта яшчэ не разумны агент. Можна ўзяць самую моцную LLM на рынку, даць ёй задачу на сорак файлаў і праз паўгадзіны атрымаць адказ «Гатова! ✅» пры тым, што зроблена палова, а ў другой палове зроблена зусім не тое, што трэба. Мадэль не стала дурнейшай. Проста яе пасадзілі ў няправільную архітэктуру.
Гэты артыкул — пра архітэктуру. Пра шэсць базавых патэрнаў, з якіх сабраныя ўсе сучасныя агенты: Claude Code, Cursor, Antigravity, Zed і астатнія. Будзе крыху матэматыкі (яе можна прагартаць — я не пакрыўджуся), шмат схем і, спадзяюся, некалькі момантаў «а-а-а, дык вось чаму ён так робіць».
Каму будзе карысна: усім, хто штодня працуе з агентамі і хоча разумець, што адбываецца пад капотам. Бо агент, якога вы разумееце, — гэта агент, якім вы можаце кіраваць. А агент, якога вы не разумееце, кіруе вашым вечарам.
Кароткі слоўнік (каб потым не спатыкацца)
- Агент — праграма на базе вялікай моўнай мадэлі (LLM — Large Language Model), якая не толькі адказвае тэкстам, але і дзейнічае: чытае файлы, запускае каманды, рэдагуе код. Чат-бот з рукамі.
- АС — аперацыйная сістэма.
- Лінтар (linter) — інструмент статычнай праверкі кода, які знаходзіць патэнцыйныя памылкі і парушэнні стылю без запуску праграмы.
- Прампт (prompt) — тэкст, які падаецца мадэлі: запыт, інструкцыі і патрэбны кантэкст.
- Токен — кавалачак тэксту (прыкладна частка слова). Мадэль думае токенамі, памятае токенамі, а вы плаціце — таксама токенамі.
- Кантэкстнае вакно (context window) — колькі токенаў мадэль можа «трымаць у галаве» адначасова. Усё, што за яго межамі, для мадэлі не існуе. Наогул.
- Выклік інструмента (tool call) — просьба агента нешта зрабіць у рэальным свеце: «прачытай файл», «запусці тэсты», «зрабі запыт у базу».
- Субагент — дапаможны агент, якому галоўны перадае асобную задачу. Стажор, па сутнасці.
- MCP (Model Context Protocol) — адкрыты стандарт падлучэння інструментаў да агентаў, прапанаваны Anthropic у лістападзе 2024 года1.
- ACP (Agent Client Protocol) — адкрыты пратакол сувязі паміж рэдактарам і агентам, ініцыяваны камандай Zed2.
Тэарэтычны фундамент: агент як POMDP
Перш чым гаварыць пра архітэктуры, трэба зразумець, у якой сітуацыі знаходзіцца агент. А сітуацыя ў яго, шчыра кажучы, так сабе.
Вы ў гасцях у далёкіх сваякоў, у старым вясковым доме, дзе былі адзін раз у дзяцінстве. Апоўначы гасне святло. Гаспадары спяць, а вас папрасілі «проста праверыць засцерагальнікі, яны дзесьці ў калідоры».
Вы ўключаеце ліхтарык на тэлефоне. Бачыце круг святла — метр, не больш. Пасвяцілі налева — вешалка з паліто. Направа — дзверы, але куды? Вы робіце крок, яшчэ крок, і ў галаве паступова складаецца карта: тут шафа, тут паварот, тут парог, аб які вы ўжо спатыкнуліся. Але гэта карта з памяці, а не дом. Калі хтосьці ўначы пераставіў крэсла, вы даведаецеся пра гэта толькі каленам.
І яшчэ адна дробязь: батарэя ў тэлефоне — 12%.
Агент знаходзіцца менавіта ў такім доме. Ён ніколі не бачыць ваш праект цалкам — толькі тыя файлы, якія сам адкрыў, і той вывад каманд, які сам запытаў. Усё астатняе — цемра, а «карта ў галаве» складаецца з таго, што ён паспеў асвятліць. А 12% батарэі — гэта кантэкстнае вакно, пра якое крыху ніжэй.
У тэорыі прыняцця рашэнняў для такой сітуацыі ёсць спецыяльная назва: часткова назіральны маркаўскі працэс прыняцця рашэнняў (POMDP — Partially Observable Markov Decision Process). Класічная праца па тэме — Kaelbling, Littman і Cassandra, 19983; яна пісалася пра робатаў, але агенту ў вашым рэпазіторыі гэта нічым не дапамагае, яму таксама цёмна.
Фармальна агент вызначаецца картэжам (упарадкаваным наборам элементаў) ℳ = ⟨𝒮, 𝒜, 𝒯, ℛ, 𝒪, 𝒵, γ⟩:
𝒮 — поўная прастора станаў асяроддзя (увесь рэпазіторый, стан файлавай сістэмы, працэсы аперацыйнай сістэмы, журналы падзей). Увесь дом цалкам — разам з пакоямі, у якія вы яшчэ не заходзілі.𝒜 — прастора магчымых дзеянняў агента (выклікі інструментаў, рэдагаванне файлаў, запуск каманд). Пасвяціць, зрабіць крок, адчыніць дзверы, пстрыкнуць выключальнікам.𝒪 — прастора назіранняў (змест прагледжаных файлаў, вывад тэрмінала, паведамленні лінтараў). Тое, што трапіла ў пляму святла.𝒵: 𝒮 → Δ(𝒪) — функцыя назірання, якая ператварае рэальны стан асяроддзя ў частковае назіранне oₜ ∈ 𝒪. Наколькі ярка свеціць ваш тэлефон і як далёка б'е прамень.𝒯: 𝒮 × 𝒜 → Δ(𝒮) — функцыя пераходу: як змяняецца асяроддзе пасля дзеяння aₜ ∈ 𝒜. Што адбудзецца, калі вы зачэпіце вешалку: яна ўпадзе, і калідор ужо не той, што хвіліну таму.ℛ — функцыя ўзнагароды (наколькі дзеянне наблізіла да мэты), γ — каэфіцыент дыскантавання (наколькі агенту важная будучыня ў параўнанні з «тут і цяпер»).
Галоўны вораг: гніенне кантэксту
Цяпер другая частка драмы. У агента няма памяці ў чалавечым сэнсе. Уся яго «памяць» — гэта адзін доўгі тэкст, які адпраўляецца ў мадэль на кожным кроку:
1Mₜ = ( h₀, a₁, o₁, a₂, o₂, …, aₜ, oₜ )
Па-чалавечы: першапачатковае заданне h₀, а пасля яго — увесь ланцужок «што зрабіў → што ўбачыў». Нічога не выкідаецца.
Сход жыльцоў пад'езда. Старшыня адкрывае яго адным сказам: «Сёння трэба вырашыць адно — хто будзе трымаць ключ ад падвала».
Праз пяць хвілін нехта ўспамінае, што ў ліфце зноў пахне. Потым пачынаецца спрэчка пра машыны на газоне. Потым суседка з пятага паверха чытае ўслых ліст за 2019 год ад кампаніі, якая абслугоўвае дом. Потым — кветкі на лесвіцы, новы дамафон і той, хто не плаціць за ліфт. Кожная тэма па-свойму важная, і кожную нехта абмяркоўвае з запалам.
Праз дзве гадзіны ўсе стомленыя. Аднагалосна галасуюць за кветкі на лесвіцы і разыходзяцца з пачуццём выкананага абавязку. Ключ ад падвала па-ранейшаму ні ў кога.
Ніхто не забыў пра ключ знарок. Пытанне прагучала — проста пасля яго было сказана столькі ўсяго, што пад канец увага ўсіх засталася на апошніх тэмах. Агент у доўгай сесіі трапляе роўна ў такое ж становішча: задача прагучала ў першым паведамленні, а пасля яе ідуць сотні радкоў вываду каманд, змесціва файлаў і журналаў памылак. Кожны радок па-свойму карысны — і кожны адцягвае ўвагу ад галоўнага.
Кантэкстнае вакно мае мяжу Cₘₐₓ, і калі |Mₜ| → Cₘₐₓ, пачынаюцца праблемы. Першая — вылічальная. Механізм увагі (Self-Attention) у трансформерах4 параўноўвае кожны токен з кожным, таму кошт расце квадратычна:
Удвая даўжэйшы кантэкст — прыкладна ўчацвёра больш вылічэнняў на ўвагу. А на практыцы горш за ўсё тое, што ўся гісторыя ізноў адпраўляецца ў мадэль на кожным кроку. Кожны наступны крок — даражэйшы і павольнейшы за папярэдні. Як таксі, дзе лічыльнік ідзе не за кіламетры, а за ўсе кіламетры, праеханыя з пачатку дня, — на кожным павароце.
Другая праблема — якасная, і яна непрыемнейшая. Чым даўжэйшы кантэкст, тым горш мадэль у ім арыентуецца. Гэта не тэорыя: даследаванне Lost in the Middle5 паказала, што мадэлі найлепш «бачаць» пачатак і канец кантэксту, а інфармацыю з сярэдзіны выкарыстоўваюць горш. У 2025 годзе каманда Chroma праверыла 18 мадэляў і атрымала тое ж самае: якасць падае з ростам даўжыні ўводу нават на элементарных задачах6. Менавіта яны і папулярызавалі тэрмін Context Rot — гніенне кантэксту.
У тэрмінах тэорыі інфармацыі расце ўмоўная энтрапія H(Sₑₙᵥ | Mₜ): карысны сігнал тоне ў шуме. Вынік — страта пачатковай мэты g ∈ h₀ (Goal Drift) і галюцынацыі.
Верхняя лінія — агент, які цягне ўсю гісторыю за сабой. Ніжняя — агент, які кожны крок пачынае з чыстым кантэкстам. Розніца на дзясятым кроку — у пяць з паловай разоў. На сотым — у пяцьдзясят.
Таму галоўная думка ўсяго артыкула ўкладваецца ў адзін сказ: архітэктура агента — гэта спосаб не даць сходу расцягнуцца на дзве гадзіны. Усе шэсць патэрнаў ніжэй — проста розныя спосабы трымацца парадку дня.
Anthropic, дарэчы, называе гэтую дысцыпліну context engineering (праектаванне кантэксту) і прама піша, што кантэкст — гэта рэсурс, кожнае наступнае пашырэнне якога дае ўсё меншую карысць. Яго трэба эканоміць, як памяць на старым тэлефоне7.
Шэсць базавых патэрнаў
Адразу папярэджу: у рэальным свеце гэтыя патэрны амаль ніколі не сустракаюцца ў чыстым выглядзе. Гэта як «пяць базавых соўсаў» у французскай кухні — ведаць іх трэба, але ў рэстаране вам прынясуць нешта змешанае. Пра змяшэнне — у канцы.
1. Single-Loop (адзін цыкл; ReAct: разважанне + дзеянне)
Найпрасцейшы і самы стары (па мерках агентаў — аж з 2022 года) патэрн. Яго апісалі Yao і калегі ў працы ReAct: Synergizing Reasoning and Acting in Language Models8, і з таго часу ён ляжыць у падмурку амаль кожнага агента.
Ідэя простая да непрыстойнасці: падумай → зрабі → паглядзі, што атрымалася → паўтары.
Гэта майстар-адзіночка. Ён сам думае, сам робіць, сам правярае. На кароткай задачы — выдатна. На доўгай пачынаецца знаёмае:
Стан FakeDone вы бачылі. Усе бачылі.
Матэматычная мадэль
На кроку t агент вылічвае:
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-Solve9, а ў прадуктах — як «рэжым планавання», які вы ўжо, магчыма, бачылі ў 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 разоў10. Брыгада працуе хутчэй, але і заробак у яе адпаведны.
- Слабасць: сапсаваны тэлефон (Information Bottleneck). Пры сцісканні частка інфармацыі губляецца. Калі субагент не палічыў важным, што ў сцяне праходзіць газавая труба, прараб пра гэта не даведаецца. Да пэўнага моманту.
- Калі выкарыстоўваць: пошук па вялікім праекце, аналіз журналаў падзей, задачы, якія натуральна разбіваюцца на незалежныя часткі. Прыклады: субагенты ў Claude Code і Antigravity, платформы для распрацоўкі агентаў CrewAI і AutoGen11.
4. Event-Driven / Async Protocol (падзеі і асінхронная сувязь: кавярня з пэйджарам)
Ёсць кавярні, дзе вы стаіце каля касы, пакуль барыста гатуе каву. А ёсць — дзе вам даюць пэйджар, вы сядаеце за столік і займаецеся сваімі справамі, а пэйджар пілікае: «пачалі», «амаль», «забірайце». Розніца — у вашых нервах.
Класічны пакрокавы (Turn-Based) рэжым — гэта стаяць каля касы. Вы далі задачу і глядзіце на індыкатар чакання. Архітэктура, заснаваная на падзеях (Event-Driven) робіць з агента фонавы сэрвіс, які паведамляе пра прагрэс праз падзеі — напрыклад, session/update у пратаколе ACP2.
Матэматычная мадэль
Дыскрэтная мадэль пераходу Sₜ → Sₜ₊₁ замяняецца струменем падзей eₖ ∈ ℰ. Агент працуе як фонавы працэс, які рэагуе на падзеі і адпраўляе невялікія змены стану ΔSₜ праз паведамленні JSON-RPC, не блакуючы інтэрфейс рэдактара.
Замест аднаго вялікага адказу ў канцы — бесперапынны рэпартаж «вось што я раблю зараз».
Што добра, што дрэнна
- Неблакавальнасць. Вы працуеце, агент працуе. Ніхто нікога не чакае.
- Стандартызацыя. ACP дазваляе аднаму агенту працаваць у розных рэдактарах — як LSP у свой час зрабіў з падтрымкай моў праграмавання.
- Але без ілюзій: гэты патэрн змяняе спосаб дастаўкі, а не колькасць працы. Патокавая перадача не эканоміць ніводнага токена. Пэйджар не робіць каву хутчэйшай — ён проста дазваляе вам не стаяць у чарзе.
- Слабасць: два гаспадары ў адным файле (Race Conditions). Калі вы і агент адначасова рэдагуеце адзін і той жа файл, пачынаецца весялосць:
- Калі выкарыстоўваць: доўгія задачы, фонавыя агенты, інтэграцыя ў рэдактары новай хвалі (Zed, Antigravity).
5. Tool-Mediated Architecture (архітэктура з падлучэннем інструментаў: USB для інструментаў)
Памятаеце часы, калі ў кожнага тэлефона была свая зарадка? Шуфляда, поўная кабеляў, і ніводзін не падыходзіць. Агенты да 2024 года жылі прыкладна так: кожная інтэграцыя (Git, база даных, Jira) пісалася асобна для кожнага агента.
MCP (Model Context Protocol)1 — гэта USB-C для агентаў. Адзін стандартны раз'ём на базе JSON-RPC: напісалі MCP-сэрвер для Postgres адзін раз — і ён працуе з любым агентам, які ўмее MCP.
Важнае ўдакладненне, якое часта выпускаюць з-пад увагі: MCP — гэта пратакол, а не пясочніца. Бяспеку, дазволы і ўхваленне дзеянняў рэалізуе хост — праграма, якая падлучае мадэль да інструментаў (IDE ці іншы дадатак). USB-раз'ём сам па сабе не абараняе ад падазронай флэшкі — гэта задача аперацыйнай сістэмы.
А вось як выглядае адзін выклік інструмента ад пачатку да канца:
Матэматычная мадэль
Агент працуе з мноствам дынамічных схем інструментаў 𝒯_MCP = {t₁, t₂, …, tₙ}. Выклік інструмента фармалізуецца як запыт:
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».
Ідэя «паглядзі на сваю памылку і паспрабуй зноў» добра апісаная ў працах Reflexion12 і Self-Refine13. Але ключавое слова тут — знешні экзаменатар. Мадэль, якая правярае сама сябе без кампілятара, — гэта студэнт, які сам сабе ставіць адзнаку. Адгадайце, якую.
Матэматычная мадэль
Хай Cₖ — код, згенераваны на ітэрацыі k. Дэтэрмінаваны правяральнік V: 𝒞 → {1, 0} × ℰ вяртае статус «праверка пройдзена / не пройдзена» і апісанне памылкі Eₖ.
Калі V(Cₖ) = (0, Eₖ), запускаецца ітэрацыя самаправеркі:
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.md14, 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 agents15 дае, дарэчы, вельмі цвярозую параду: пачынайце з найпрасцейшага рашэння і ўскладняйце толькі тады, калі гэта сапраўды неабходна. Гібрыд — гэта не мэта, а вынік шматлікіх «а вось тут не хапае...».
- Сувязь з рэдактарам — праз Event-Driven пратакол (ACP): вы бачыце прагрэс і не чакаеце.
- Агульнае планаванне — Spec-Driven: план, які вы правяраеце.
- Брудная праца — субагенты: пошук і аналіз без засмечвання галоўнага кантэксту.
- Знешні свет — MCP-сэрверы пад кантролем хоста.
- Фінальная праверка — Verifier Loop: кампілятар, лінтар, тэсты.
А ўнутры кожнага з гэтых кубікаў па-ранейшаму круціцца стары добры ReAct-цыкл з 2022 года. Проста цяпер яна кароткая і не паспявае ператварыцца ў двухгадзінны сход.
Па сутнасці, уся гісторыя развіцця агентаў апошніх гадоў — гэта не гісторыя «мадэлі сталі разумнейшымі» (хоць і сталі). Гэта гісторыя пра тое, як інжынеры навучыліся не перашкаджаць разумнай мадэлі сваім брудным кантэкстам.
Пад капотам: як гэта зроблена ў Claude Code, Codex і кампаніі
Тэорыя — гэта добра, але давайце адкрыем капот у інструментаў, якімі вы, магчыма, карыстаецеся цяпер. Папярэджанне: усё ніжэй — стан на восень 2026 года. У гэтай індустрыі «стабільная версія» жыве прыкладна як малако ў халадзільніку, таму звярайцеся з дакументацыяй.
Claude Code: аркестратар з брыгадай па змаўчанні
Калі вы адкрываеце Claude Code, вы размаўляеце з адным галоўным агентам — класічным ReAct-цыклам. Але ў яго за спінай ужо стаіць брыгада. У базавай канфігурацыі ёсць шэсць убудаваных субагентаў16:
| Субагент | Што робіць | Цікавая дэталь |
|---|
| 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 (эксперыментальная функцыя, выключаная па змаўчанні)17. Гэта ўжо не «прараб і брыгада», а «каманда на працоўнай нарадзе»: удзельнікі пішуць адзін аднаму напрамую праз паштовыя скрыні (звычайныя JSON-файлы), бяруць задачы з агульнага спісу і нават спрачаюцца. Дакументацыя прама прапануе сцэнарый «пяць агентаў правяраюць пяць гіпотэз і спрабуюць абвергнуць высновы адзін аднаго, як на навуковай дыскусіі». Каштуе гэта адпаведна: кожны ўдзельнік — асобны экзэмпляр Claude са сваім кантэкстам.
А цяпер — як Claude Code закрывае праблемы, пра якія мы гаварылі вышэй:
- Гніенне кантэксту → аўтаматычнае сцісканне (auto-compaction)18. Калі кантэкст набліжаецца да мяжы, размова замяняецца структураваным кароткім пераказам. Самае цікавае — што выжывае:
CLAUDE.md і план з рэжыму планавання перачытваюцца з дыска, а не з памяці. То бок мэта h₀ і план P фізічна не могуць «патануць» — гэта як старшыня, які пасля кожнага перапынку зноў чытае ўслых парадак дня. Акрамя таго, агент перачытвае да пяці апошніх змененых файлаў. Можна і ўручную: /compact focus on the auth bug — «сціскай, але пра аўтарызацыю не забывай».
- Схемы MCP з'ядаюць кантэкст → tool search19. На пачатку працы загружаюцца толькі назвы інструментаў, а поўныя апісанні — па патрэбе. У рэжыме
auto пошук уключаецца, калі схемы займаюць больш за 10% вакна. Дадаткова — абарона ад «балбатлівых» сэрвераў: на адказ MCP-інструмента больш за 10 000 токенаў Claude Code выдае папярэджанне, а па змаўчанні абразае на 25 000.
- Бяспека → пясочніца на ўзроўні АС20. На macOS — Seatbelt, на Linux — bubblewrap, сетка — праз проксі з белым спісам даменаў. Мая любімая дэталь: файлы
.claude/settings, .mcp.json і .git/hooks абаронены ад запісу нават унутры пясочніцы. Каб агент не мог, так бы мовіць, сам сабе выпісаць даверанасць. Хтосьці ў Anthropic відавочна думаў пра тое, як бы паступіў хітры стажор.
- Фальшывае «Гатова!» → аўтаматычныя праверкі праз хукі. Хук
PostToolUse можа запускаць лінтар пасля кожнай праўкі. А ў Agent Teams хук TaskCompleted з кодам выхаду 2 проста не дае пазначыць задачу выкананай, пакуль праверка не пройдзе. Экзаменатар, з якім нельга дамовіцца, — у чыстым выглядзе.
- Канфлікты адначасовых змен → блакіроўкі і асобныя працоўныя дрэвы Git. У камандах агентаў задачы бяруцца з агульнага спісу праз блакіроўку файлаў — двое не схопяць адно і тое ж. А субагента можна запусціць у асобным працоўным дрэве Git (git worktree), каб ён увогуле не дакранаўся да вашых файлаў.
Codex (OpenAI): той жа рэцэпт, іншыя спецыі
Codex прыйшоў да той жа архітэктуры, але з іншымі акцэнтамі. Субагенты сталі даступныя ўсім у сакавіку 2026 года, і ў базавай канфігурацыі іх тры21:
| Субагент | Што робіць |
|---|
| default | Універсальны выканаўца «на ўсё» |
| worker | Выкананне: рэалізацыя і выпраўленні |
| explorer | Чытанне і даследаванне кода |
Цікава, як па-рознаму дзве каманды адказалі на пытанне «калі запускаць субагентаў». Codex па змаўчанні больш стрыманы: ён дэлегуе, калі вы прама папрасілі або калі гэтага патрабуе AGENTS.md ці набор інструкцый (skill). Галоўны агент чакае, пакуль усе субагенты скончаць працу, і збірае адзіны адказ. Дакументацыя сумленна папярэджвае: субагенты «спажываюць больш токенаў, чым аналагічны запуск аднаго агента». Брыгада, як мы памятаем, бясплатна не працуе.
Уласныя агенты апісваюцца TOML-файламі ў .codex/agents/. І тут вельмі слушнае архітэктурнае рашэнне: карыстальніцкі агент не можа перавызначыць пясочніцу, палітыку ўхвалення і MCP. Можна змяніць мадэль, інструкцыі, «колькасць разумовых намаганняў» — але не правы доступу. Інакш кожны «агент-памочнік» з GitHub быў бы патэнцыйным траянскім канём.
Што тут цікавага:
- Тры рэжымы пясочніцы22:
read-only (толькі глядзець), workspace-write (правіць у межах праекта — рэжым па змаўчанні для лакальнай працы) і danger-full-access (назва як бы намякае). На macOS — той жа Seatbelt, на Linux — той жа bubblewrap. Розныя кампаніі, аднолькавыя высновы.
- Auto-review: Verifier для бяспекі. Калі агенту трэба выйсці за межы пясочніцы (напрыклад, у сетку), запыт можна адправіць не вам, а іншаму агенту-рэцэнзенту. Гэта патэрн Verifier Loop, ужыты не да кода, а да дазволаў. Агент правярае агента — элегантна. Ці трывожна. Залежыць ад таго, колькі кавы вы ўжо выпілі.
- Іерархія
AGENTS.md23. Codex збірае інструкцыі ад глабальнага файла да бягучай тэчкі, па адным файле на ўзровень, і бліжэйшыя да кода маюць прыярытэт. Ёсць нават AGENTS.override.md — часовае перавызначэнне без выдалення асноўнага файла.
- І праблема, пра якую мала хто ведае: агульны ліміт — 32 KiB (
project_doc_max_bytes). Калі вашы AGENTS.md разам большыя — Codex моўчкі перастае дадаваць файлы. Без памылкі, без папярэджання. І звычайна адразаюцца якраз самыя бліжэйшыя да кода, самыя канкрэтныя правілы. Прыгожая іронія: механізм, які павінен змагацца з перапаўненнем кантэксту, сам пакутуе ад перапаўнення.
Cursor: грубая сіла паралелізму
Cursor у версіі 2.0 (кастрычнік 2025) зрабіў стаўку на паралелізм: да васьмі агентаў на адзін прампт, кожны ў сваім git worktree або на аддаленай машыне24. Гэта не «прараб і брыгада», а хутчэй «восем архітэктараў атрымалі адно заданне — выбірайце лепшы праект». Праблему канфліктаў адначасовых змен тут вырашаюць радыкальна: агенты проста не дзеляць файлы.
Адчыняем код: Zed і Warp
Дагэтуль мы чыталі дакументацыю. Дакументацыя — гэта тое, што кампанія хоча, каб вы ведалі. Код — тое, што адбываецца насамрэч. На шчасце, у двух папулярных інструментаў код адкрыты: Zed25 і Warp26 (апошні адкрыў кліент пад 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) запускае субагента, а ліміт глыбіні зашыты канстантай:
1pub const MAX_SUBAGENT_DEPTH: u8 = 1;
Адзін узровень. Галоўны агент можа наняць стажора, стажор наняць нікога не можа. Параўнайце з тымі трыма ўзроўнямі ў Claude Code: дзве каманды паглядзелі на адну і тую ж праблему (рэкурсія субагентаў) і паставілі планку ў розных месцах.
Але самае каштоўнае — не код, а апісанне інструмента для мадэлі. Гэта, па сутнасці, мініпадручнік па патэрне Orchestrator-Worker, напісаны для LLM. Некалькі радкоў адтуль (у перакладзе):
- Субагент не бачыць вашай размовы. Перадавайце ўвесь патрэбны кантэкст: шляхі, патрабаванні, абмежаванні.
- Не выкарыстоўвайце гэты інструмент для задач, якія можна зрабіць адным-двума выклікамі. Напрыклад, не прасіце агента прачытаць адзін файл і вярнуць змест — зрабіце гэта самі.
- Для задач з праўкай кода раздзяляйце працу так, каб у кожнага субагента быў асобны набор файлаў для запісу, які не перасякаецца з наборамі іншых субагентаў (disjoint write set).
- Для ўдакладненняў выкарыстоўвайце існуючы
session_id — агент ужо памятае папярэднюю размову. Не паўтарайце задачу.
Глядзіце, колькі праблем з нашага спісу закрыта проста тэкстам: другі пункт — супраць выбуху коштаў, трэці — супраць канфліктаў адначасовых змен, чацвёрты — супраць сапсаванага тэлефона. Ніякай складанай інжынерыі, проста добра напісаная інструкцыя. Архітэктура агента часткова жыве ў прамптах — і гэта, бадай, самае нечаканае, што можна знайсці ў кодзе.
2. Сцісканне, якое шануе вашы словы. Аўтасцісканне ўключаецца, калі вакно запоўнена на 90% (AutoCompactThreshold::DEFAULT), і толькі для мадэляў з вакном ад 80 тысяч токенаў — на меншых, як сумленна пішуць у каментары, «няма дастаткова месца, каб сцісканне мела сэнс». А цяпер самая прыгожая дэталь:
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):
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.
Мадэлі будуць станавіцца разумнейшымі. Кантэкстныя вокны — большымі. Але фізіку гэта не адменіць: увага — абмежаваны рэсурс. У людзей таксама, дарэчы. Можа, таму архітэктура добрага агента так моцна нагадвае арганізацыю працы добрай каманды.
Крыніцы
Сучасныя ШІ-мадэлі маюць адно вельмі непрыемнае абмежаванне — памер кантэксту (context window). Гэта колькасць інфармацыі са знешняй крыніцы, якую мадэль можа трымаць адначасова ў сваёй «працоўнай памяці». Звычайна гэта абмежавана некалькімі мільёнамі токенаў.