Проектаванне прыстрою для агента: палітыка, сэндбоксінг, памяць і перакананне
Дазвольце дазнацься, які шары часу выканання ператвараюць LLM, яка вызывае інструменты, у надзяйны агента: політыка выканання, сандбоксацыя ОС, стойкі стан, верыфікацыя, контроль контэксту і витраты.
Крыніцы: Agent Harness Engineering: The Missing Layer Between an LLM and a Real AI Agent
Команды, якія беруцца за стварэнне агента на базе ШІ, зазвычай пачынаюць з порэвняння модэляў: размерах вікна контексту, рэзультатах тестаў, якосці логічных выводам, цэне за токен. Калі выбраны модэль, падключаецца кальколька інструментоў, і рэзультат называецца агентам. Насправды ж у гэты момант існуе модэль, якая можа вызываць функцыі, а прасоц межу гэтага і рэальнага агента заполняе слой часовай екзыкуціі, які сёння зазвычай называецца agent harness. У гэтым кяліку показаны слоі гэтага harness, ад чаго захоўвае кожны з іх, і як поступова развіваць такі агент, не тонучы ў абстракціях фрэймворка.
Модэль, якая вызывае інструменты, яшчо не ўважаецца агентам
Тыповы набор для пачатку складаецца з короткага списку можлівасцяў, якія є доступныя для модэля.
search()
read_file()
write_file()
run_command()
За дапамою гэтых чатырох функцыйяў модель можа шукаць, чытаць, пісаць і выкананы каманды. Гэта стварае вражанне аўтонаміі, але нічога ў гэтым распадзеле не вялікае, калі модель можа прыкладвацца да паведамленняў, якія аперацыі трэбуе затверджэння чалавека, яя інфармацыя застаецца пасля збою чы перзапуску, як пераканальваецца выходны результат, чы і сколькі з рэзультатаў кожнага інструмента включаецца празпрашанню. Усі гэтыя абавязкі належаюць кроплі.
Кропля таксама выявляецца як зменная, якаю можна вымерыць. На момент напісання даследжэння 2026 года, якое паўставіла на аднаковасць кропляў кодавання-агента, пазначыла разлікі да 40 разоў у колькасці токенаў, якія витрачаюцца на адна рашаная задача, тады як разлікі ў практычнасці між тымі ж кроплямі былі набагато меньшыя. Вывад не ў тым, што хітры рантайм прыводзіць слабую модель да гэніяльнасці. Ён у тым, што рантайм сильна вплывае на тое, насколькі эфектыўна, безпечна і прыгадна здольная модель выканана свою работу.
Цікл у цэнтры і пытанні ўсупрацоўкі яго
Якща спроставаць да сутнасі, агент — это цікл: запытваеце модель, што робіць, выканаўваеце запрошаны інструмент, дадаеце рэзультат у контекст і павторюеце, пакуль модель не скажа, што все завершана.
while True:
response = model(context)
if response.is_final:
break
result = execute_tool(response.tool_call)
context.append(result)
Багатыя рэальныя агенты маюць у своім ядре штосьць вельмі схожае на гэта. Модель прымае рашэнне, час адпаведна яго выканаўвае, назад прыходзяць данні аб стане справ, і модель выбирае наступны крок. Сам цікл ёсць просты; тэхнічныя зусиллі закладзеныя у всё, што яго абгружае. Корыстны механізм павінен на кожны крок адпавядаць на дужо длігі список операцыйных пытанняў.
Can the agent execute this command?
Can it access this directory?
Does it need human approval?
What happens if the command fails?
What information should return to the model?
What should survive the session?
Should another agent review the result?
How much context should we send?
How much will this turn cost?
What happens if the model loops forever?
Усія адказы разам являюцца «харнесам». Адна няўняя концэптуальная студыя апісвае яго як час адработкі, який спаўнае з’ёднанне модэлю мовы з зямным светам за дапамой інструментаў, кантэкстнага адарожвання, мер захопчы, оркестрацыі і точак расшырэння. Практычны спосаб разумеўця — разбіць агента на два часткі.
AI Agent
│
┌────────┴────────┐
│ │
Model Harness
│ │
reasoning ┌──────┼───────┐
planning │ │ │
generation Tools Memory Safety
│ │ │
Sandbox Context Verification
З адной стороны, модэль забезпечвае разумаванне, планаванне і генераванне. З іншай стороны, «харнес» забезпечвае інструменты, памяць і меры захопчы, падтрымваныя сандбоксам, адарожванням кантэксту і верыфікацыяй. Модэль дапамагае ствараць інтелект; «харнес» керуе тым, як гэты інтелект вплывае на рэальныя системы.
Чаму запит не можа быць вашым механізамам захопчы
Падазроўваюце, што системны запит містіць чыстае правілу:
Ніколы не выдаліце файл для выпуску без маёй прадзеўні.
У тым выказванні няма нічога неяснага, пры тым яно застаецца запросам. Модель можа неправым чынам яго зрозумець, запамятаваць яго пасля дужа дзяўнай сесіі, прырównваць яго з суперсучаснымі інструкцыямі ў іншых частках контексту, пераканаць ся, што даны случай ўз’ект, або досягнуць таго ж разрушальнага рэзультата за дапамогою іншага аднароду, які правілам не быў чытка пакрыты. Прабаць пераканаць агента утримацца ад чаго-небудзь прынципова разлічная ад таго, каб зробіць гэта немагчымым без разрашэння. Запрос выражае бажанне:
Please don't do X.
Харчувальная система може выражаць правілу, якое адмацаваецца ў кодзе:
if dangerous_action and not approved:
deny()
Другая версія працюе незалежна адзь тым, памятаець модель інструкцыю чы не. Гэта ўтварае першы прынцып інжынерыі кантролю: калі правілле є дэтерміністычным, яго трэба реалізаваць у дэтерміністычным коде. Claude Code таксама дэтальна працуе з гэтым прынцыпам у своім дизайне. Хукі запускаюцца пад час адбывання жыцёвых цяроў і вызоваў інструментаў, і можу, напрыклад, адхіліць вызов інструмента пры яго выкананні, тады калі файлы на кшталт CLAUDE.md падаюць вядомасці, якія модель чытае як контекст. Якщо вы пішаце такі файл, трэба зберагаць яго як вядомасці і перанесці адпаведныя заходы ў хукі; наш практычны путаводзіцель па стварэнні эфектываў файла CLAUDE.md раскрывае, што там павінна быць.
Слой 1: межа выканання між запытам і дзеяннем
Першыя пытанні, якія трэба рашыць, — гэта якія дзеянні агент можа выконваць. Разглядзім прылад, який выкарыстоўваецца для адчынення файлу.
def delete_file(path):
os.remove(path)
Модель можа вызваць яго з будзь-якім аргументам, які ёй пасаблівае.
delete_file("important.md")
Якщо такы вызов адбываецца негайна, модель мае необмежаныя правыя ўсё там, да чаго можа дасягнуць функцыя. Рашэнням являецца перадача кожнага вызову через контролер, які пераканальваецца ў правілах пры розпадзе.
def execute(call):
if call.name == "delete_file":
if not call.args.get("human_approved"):
return "DENIED: human approval required"
return dispatch(call)
Тепер модель все ўсё можа запрашваць адчыненне, але запрошэнне больш не значыць выканання. Процес стае рашэннем на адпаведнасць правілам з двума рэзультатамі.
Model decision
↓
Policy check
↓
Permission?
↙ ↘
No Yes
↓ ↓
Deny Execute
Это адаптаваець традыцыйныя прынцыпы проектавання безпекі: модэль пропонуе, а час выканання рашыяе. Аднак у рэальным кодзе трэба практычнаўцы лепш захаваць дзеянне затверджэння. У прыведзенай вышэй схеме флаг затверджэння чытаецца з сабеўных аргументаў вызову, якія генеруе модэль. У продакшн-системе затверджэння павінна атрымвацца занова, через крок людскай паўтарной пераканання або падписаны токен, які модэль не можа стварыць; інакш модэль гэты флаг можа проста сама задаць.
Чаму перакананні на рэвэле інструментаў не работаюць
Палітыкі інструментаў неабходныя, але недастатковыя. Уявіце, што система адмовляе ў такім вызое:
delete_file("secrets/api_key")
Гэта выглядае як захопленне, пакуль агент не запускае адпаведны каманду шэлу заместа таго:
rm secrets/api_key
Палітыка delete_file ніколі не бачыць гэтай операцыі. Але ў системе можа быць заблокавана чытанне секрэтнага падрадзіку:
read("secrets/api_key")
Але абсалютны пацек праскаецца, таму што ніхто яго не стандартызаваў:
read("../secrets/api_key")
Сімвалінкі, дапаможныя програмы, якія ачынаюць файлы зарады агента, і інтэрпретары, якія прымоюць будзь-які код, ствараюць падобныя «бокавыя дзвері». Палітры, выражаныя па назвамах інструментоў і стрэлкавых аргументах, не можу перыябраць усі шляхі да рэсурса, таму яны не ўтвараюць цэліснага межовага бар’ера. Рады OpenAI па адпаведнай роботе з кодавальнымі агентамі рэкамендуюць выкарыстоўваць сандбоксаванне, палітры затверджэння, обмежаную експансію, кантроль сеті і тэлеметрыю заместа апоўненняся толькі запросамі. Прынцып, які трэба памятаць: кастрымент выкаанавляе палітру, а операцыйная система — фінальны межовы бар’ер.
Слой 2: сандбоксаванне таго, да чаго агент можа фізычна дасягнуць
Палітры прымуць пытаюцца з’ясаваць, што агенту разрэшана робіць; сандбоксы — што ён можа досягнуць з самага пачатку. Слабы падход — это список запрэтам, які намагаецца перыявіць кожна чуліва месца.
Don't access:
- /etc
- ~/.ssh
- secrets/
- production/
- credentials/
- ...
Такія спискі ніколі не стаюць завершанымі. Моцнейшы падход — это зворачэнне стандартной практыкі: не разрэшаць майже нічога, а потым дадзіць толькі тое, што неабходна задачы, напрыклад, адзін працоўны простор проекту.
Agent workspace:
/workspace
├── src/
├── tests/
├── pyproject.toml
└── README.md
Агент отрымае /workspace і нічога больш на хосте. У выразе палітры прымуць гэта ёсць список разрэшэнняў.
Allowed:
/workspace
Everything else:
unavailable
Паколькі з іншай стороны файлавая система проста не існуе з точкі зоры агента, трюкі з шляхамі, сімвалінкі і дапаможныя процесы втрачаюць большую частку свайго эфекту. Контейнеры, спецыяльныя віртуальныя машыны і обмежаныя адзеныя корыстнікаў — это распашчастыя способы рэалізацыі гэтага. SDK для агентаў OpenAI дадаў вбудованую екзекуцыю ў песочніцы самэ для гэтай меты, тады агенты можаць інсталаваць залежнасці, рэдагаваць файлы і запускать каманды ў контролюемай средзе.
Ліміты сеті і рэсурсаў таксама трэба размесціць у песочніцы
Ізоляцыя файлавай системы не завершае задачу. Агент, які можа запускаць простыя задачы, мае зовсім іншы профіль абараняючых мераў:
curl https://example.com
З можлівасцю выходу у сеть агент можа:
- зяць і запускаць будзь-які програмны апарат
- выкарыстоўваць данні для перадачы на званчайны хост
- з’яўляцца да API трэціх сторон
Таму сандбокс, які заслуговае на гэта назва, пакрывае калькі параметраў, а не толькі файлы.
Filesystem
Network
Processes
Environment variables
Secrets
CPU
Memory
Time
Процесы таямна успадковуюць зменныя сэрвіса і секреты, а ліміты CPU, памяці і часу запобегаюць неконтрольванаму выконанню. Самэй гэтай шыроты сучасныя рантаймы проектуюць сандбокс як цэласнае сераўысе выканання, а не проста як тонкі обгорак.
Слой 3: стацыонарны стан, які застаецца пасля завершэння сесіі
Пры дзейнах, якія трываюць даволі дазго, выступае іншы тип абякання. Агент паспелівае гадзіну на аналіз рэпазітарыя і вывучае важны архітэктурны прынцып.
The authentication service must never directly access the database.
All database operations go through Repository classes.
Тады вікно контэксту запоўняецца, сесыя пачынаецца занова, і гэтыя ведамасці зникаюць. Наступная сесыя не разумее, чаму дизайн выглядае так, і можа без проблем яго нарабіць. Історыя размовы — не тое месца для такіх фактам. Корыстны механізм дозволяе раздзеліць прынеймна тры катэгоріі інформацыі з разным періодам жыцця.
Conversation state
↓
temporary
Project state
↓
persistent
Harness configuration
↓
persistent + globally enforced
Конкрэтныя прыклады кожнай з іх:
Conversation:
"Let's investigate the login bug."
Project:
"Authentication uses OAuth."
Harness:
"Never modify generated migrations."
Элемент размовы можа безбедна зникнуць, калі завершыцца задача. Факты проекту павинны застаўцца між сесіямі, напрыклад у файле з нотаткамі з версіямі або ў базе памяці. Правіла керування павинны прыменяцца ў кожнай запуску, незалежна ад таго, што наразе памятае модель, што зазвычай значыць, ўсё гэта мае быць у коде налаштаванняў і контролю, а не ў тексте. Калі сесіі становяцца дыявольска дзейснымі, такое раздзеленне становіць яшчэ важлівым. Напрыклад, API Agents ад OpenAI мае функцыі керування контекстам, прызначаныя для агентаў, якія працуюць дыявольска дзейсным часам, у тым числе автаматычную компактаванне, калі сесія набліжаецца да свайго ліміту контексту. Самэ ў момент компактавання тыя факты проекту, якія не былі запісаны, губяцца, таму варта навмесна захаваць іх да гэтага моменту. Для болей дакладнага розгляду роўняў памяці, адзірніце чатырох-роўневую памяць агента з LangGraph і Amazon Bedrock.
LangGraph і Bedrock.Слой 4: пераканальванне, чы ў агента няма права на власнасць
Агенты можу цілком правильна адмаўляцца, таму агент, які внёс змяну, не павінен быць апошняй інстанцыяю ў пацэркаванні таго, чы яе змяна правильная. Возьмімо такі выхад:
def calculate_total(items):
return sum(item.price for item in items) + 1
Этот + 1 можа здавацца намеровым для модэлю, які яго напісаў. Незалежны крок пераканальвання можа ацэніць змяну на аднойчынку з калькама сігналоў.
Code
Tests
Type checking
Linting
Security rules
Expected behavior
Тое, што робіць гэта ценным, — это разлік межа вырабоўкай і ацэнкаю.
Agent
│
↓
Changes
│
↓
Verification
↙ ↘
PASS FAIL
↓ ↓
Continue Investigate
Успех дазваляе ціклу продаважыцца; няудача прымусвае агента зноў расследаваць. Адна дэтал, якую лёгка праціснуць: рэвізор павінен адмаўляцца пра проблемы, а не таямна іх лагадваць. Якщо пераканальвальнік таямна лагадвае бяг, вы втрачаеце сігнал пра тое, што пачатковы агент зазнаў няудачы, і вашы показнікі успеху стаюць вымыслам.
Тэставанне без рэальных змян як стандарт для рызыковых змян
Для аператываў з вышэйшым рызыкам стандартным выборам яе перагляд стандартнай дзейнасці. У замену на функцыю прыменэння, якая дзейнае негаразду:
apply_change()
неабходна выклікати ту, якая па замовчанню працуе у режыме тэставання без рэальных змян:
apply_change(dry_run=True)
Агент спачатку атрымлея опис наследкаваў такой дзейнасці.
Would modify:
src/auth.py
tests/test_auth.py
Толькі праз явны, адзінокі крок, жадана ў тым, каб ён трэбаваў затверджэння, можна перейсці ад перагляду да выканання. Чыгун гэта дае як пераканальніку, так і будзь-яму людскаму рэвізору конкретны аб’ект для аналізу прычымо да будзь-яых змян.
Слой 5: інжынерыя контэксту
Кожны токен, які ўключаюцца у контекст, коштаюць грошыў, конкуруюць за увагу моделі, і пад час дзействаў з вялікім обсягам дадзеных часта накаплююцца быстрэй, чым выкалываюцца. Падазроўваеце, што агенту патрабуецца адна функцыя з файла, які складаецца з 5 000 ліній. Простая система адправляе весь файл, потым усі рэзультаты наступных пошукоў, потым рэзультаты наступных інструментаў і так далей. Чыраз згодзе контекст запоўняецца всімі гэтымі дадзенымі:
Task
+ entire repository
+ previous searches
+ tool output
+ logs
+ previous reasoning
+ repeated instructions
Модэль тэхнічна можа бачыць кожны токен, але наявнасць у візуальным полі не значыць розумеў. Кращыя падходы рассматрываюць контекст як канвейер, який скондэнсавае інформацыю прыбліжна перш чым яна дасягне главнага агента.
Main Agent
│
├── Search Agent
│ │
│ └── 50,000 tokens
│
│ ↓
│
└── 1,000-token summary
Хоча агент для пошуку можа выкарыстоўваць 50 000 токенаў пад час аналізу, галоўная сесыя отрымае толькі кантакт з 1 000 токенаў, які ўкладаее найважлівыя даны. Гэта ўпэўнены аргумент на корыстку сабагентаў. Напрыклад, Claude Code описвае сабагентоў як элементы, якія працуюць у сваіх аўтанонімных вікнах контексту і вяртаюць толькі свой фінальны рэзултат у галоўную беседу, чым запобігае таму, што масовыя падзеі завантажваюць галоўны контекст. Аднак такой падход можа прывести да таго, што у кантакце будуць пропускныя деталі, якія пазней знадобяцца галоўнаму агенту, таму кантакты трэба запрацоўваць так, каб у іх былі паказчыкі (шляхі да файлаў, дыапазоны лінакаў), якія дазволяюць агенту запрашваць конкрэтную інфармацыю за патрэбай.
Эканаміка: цена за токен — гэта не вартасць за заданне
Управленне контэкстам таксама ўзьязвана з пытанням бюджэту. Памятаеце даследжэнне, якое паказала разліку ў 40 разоў у колькасці токенаў за адна вырашаная задача межы разнымі супорамі, пры чым разліка ў практычнасці выпанавання задач была значна меньшай. Гэта зміняе пытанне, якое варта ставіць. Уместо „Калькі модель ўяўляецца найдешавейшай?“ запытайце, сколькі токенаў патрэбна цэлай системе агента, каб завершыць задачу. Пораўняйце два варыянты наладжэння.
Агент А: дешавейшая модель, некэфектыўны супор
Model:
$X / million tokens
Task:
500k tokens
Агент Б: дорожэйшая модель, эфектыўны супор
Model:
2X / million tokens
Task:
100k tokens
Агент B плаціруе удвое большую суму за кожен токен, але викорыстоўвае лиш частку п’яту токенав, таму кожны завершаны задача коштае прыблізна 40 процэнтав таго, што витрачае агент A, яшчэ не беручы пад увагу розніцу ў ступені успеху. Цэна моделі — це вхідны параметр; эканоміка агента выклікаецца тым, сколькі роботы прыладка змушае модель виконваць. Наш модэль костаў, заснованая на архітектуры, для агентных AI дэтальней розбірае гэта пытанне.
Празьбы без дзеяння і політыкі завершэння
Частка марнацькіх дзеянняў залишаецца непазорнаю ў показніках за кожны запит. Уявіце сабе агента, які застрэў на анунцыі свайго намеру без жадных дзеянняў:
I should inspect the repository.
і знову на наступным кроцы:
I should inspect the repository.
і ўсё зноў:
I should inspect the repository.
Нічага не зміняецца, пры тым кожны раунд спрацоўвае токены, займае час, выконвае вычыслення, выкарыстоўвае прастор контэксту і, можа, кошты. Адныя і тыя ж доследжэння характарызуюць гэты додатковы накладкі як податак на чаканне за кожны задачы, а не проста як податак на токены: корыстнікі чакаюць на раунды, якія нічога не дасклалі. Системе патрэбны правіла завершэння, а найпростыя з іх — жорсткі ліміт на колькасць раундоў.
MAX_TURNS = 30
if agent.turns >= MAX_TURNS:
stop()
Ліміт — это захоўніцкі механізм, а не стратэгія. Болей корыстныя системы выкрываюць сігналы, якія указваюць на застоў у выконанні.
No progress
Repeated tool calls
Repeated identical observations
No state change
Test suite unchanged
Agent oscillation
Budget exhausted
Парадоксальныя вызовы таго ж самога інструмента, незменныя рэзультаты спостерэнняў, абсэнць змян у файлавай системе, тестовы комплект, які продовжае падводзіць тыя ж апыткі, колыханні межа двух станоў, або выкараны бюджет — усё гэта значыць, што продажчае працаванне вельмі малая верагатыба дапаможаць. У такі момент система должна зупыніцца, падсумаваць ситуацыю і перадаць ў вышэйшыя інстанціі. Наша аднарада па выкарыстоўванню обмежаных агентных цыклаў у TypeScript паказвае гэтыя шаблоны ў кодзе.
Ад обгорткі інструмента да платформы
Дизайн кэрсів стае самастойной даследзенняй. Няўжоны адзін даследжэнне коду аўтараў адзенацца систем-агентаў для кодавання паказаў паўтарыючыяся архітэктурныя шаблоны ў іх: выкананне інструментаў, калектывнае адарожванне контэкста, сістэмы безпекі, оркестрацыя і можлівасці расшырэння. Аўтары выражаюць мненне, што кэрсы для кодавання ператворыліся з простых інструментаў у платформы. Ранэйшыя агенты выглядзелі так:
LLM + tools
Няўжоныя системы падобныя на стак.
LLM
↓
Agent loop
↓
Tool router
↓
Policy engine
↓
Sandbox
↓
Context manager
↓
Memory
↓
Verification
↓
Observability
↓
Orchestration
Модэль застаецца ядром, але сістэма выканання навакол яго — ад маршрутацыйных інструментаў і двухчынных механізмаў да сандбокса, калектывнага адарожвальніка контэкста, памяці, верыфікацыі, можлівасцей абзярнага стэручання і оркестрацыі — стала самастойным продуктам.
Прыклад структуры для агента кодавання
Разумная пачатковая архітектура для агента-кодавца заключаецца ў тым, што цикл агента розташоўваецца безпасуль пад модэлем і дзеліцца на тры складнакі: керавальнік інструментаў, менеджар контэксту і памяць. Выклікі інструментаў праходзяць через механізм політык у сандбокс, рэзультаты праходзяць праз перакананне, а ўсё фіксуецца за дапамогою механізма спостэрэння.
┌──────────────┐
│ Model │
└──────┬───────┘
│
↓
┌─────────────────┐
│ Agent Loop │
└────────┬────────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Tool Router Context Memory
│ Manager │
↓ │ ↓
Policy Engine │ Persistent State
│ │
↓ ↓
Sandbox ←────── Tools
│
↓
Verification
│
↓
Observability
Зрабіце кожную частку незалежна тэставанай: адрабатуйце юніт-тэсты для механізма політык за дапамогою синтэтычных выклікаў, перагляньце працэс обробкі шляхоў, а таксавайце працэс пераканання на вядомых бяспрацоўных дастатках, усё гэта без выклікаў модэля.
Развівайце систему на адыходах, а не на фрэймворку
Вам не трэба велікога фрэймворка агента, каб отрымаць гэтыя перадчыны. Цикл у центры можа застацца маленькім нават пасля дадання механізма політык, сандбоксаў і прыемаў пераканання.
while turns < MAX_TURNS:
action = model.next_action(context)
if action.is_final:
return action.answer
if not policy.allows(action):
context.append("Action denied")
continue
result = sandbox.execute(action)
verification = verifier.check(result)
context.append(
summarize(result, verification)
)
Зверніце ўвагу на порядак: перапрацоўка правіл праходзіць раней, чым выконання, а дзеянне, якое было адхілена, фіксуецца для моделі, замест таго каб зупініцца цикл; выконання завжды праходзіць через «пісочнік», а тое, што знову пракрадаецца ў контекст, — цэлае апісанне рэзультата і яго перакранчвання, а не первісны выхід. Таму слід дадаць складнасць толькі у разе выявлення аберанцы.
Agent deleted something?
→ add execution policy
Agent accessed the wrong file?
→ strengthen sandbox
Agent forgets architecture?
→ add persistent project memory
Agent produces bad code?
→ add verification
Agent becomes expensive?
→ optimize context
Agent loops?
→ add termination detection
Кожны сімптам прыходзіцца да аднаго конкрэтнага шару. Гэта набліжэй да оптимальнага рашэння, чым введэнне пяцідзiesятых абстракцый, калі ўсё щэ не вядома, якая саме проблема існуе. Чыба глэбшую дыскусію пра тое, чы хацець стварыць такі цикл самостоятельна чы вжываць гатовы, можна прачытаць у runtime harnesses vs composed frameworks.
Рэпазітарыя як база знанняе агента
У развітку, калічаным агентамі, репазітарый ёсць не простае скарынкай коду. Ён можа хаваць усё, што патрэбна агенту для роботы над проектам: рашэнні па архітэктуры, каманды на развіццю та тэставанне, слоўнік домены, схемы, планы, інструкцыі з эксплуатацыі та інструкцыі, спецыяльныя для агента; усё гэта знаходзіцца ў версіях разам з кодам, які яны описваюць. Самыя матэрыялы OpenAI пра інжынерыю калічаных агентоў падтверджаюць гэты момент, прычымляючы версіяваныя артыфакты, якія знаходзяцца ў репазітарыі, да системы зберагача інформацыі пра тое, што агент павінен знать, каб разумець та змяніць проект, і рэкамендуючы викорыстоўваць карточку, якая вядзе да конкрэтных дакументаў, а не до однаго вялікага файла з інструкцыямі. Вынікаючая з гэтага заключэнне проста: рашэнні па дизайне, якія існуюць толькі ў галаве каго-небудзь або ў чаты, для агента не існуе. Робленае зрозумелым стан класавых ведамаў стала часткай архітэктуры програмнага забезпечэння.
Hooks: прыемствасці, якія модэлю не патрэбна запамятаваць
Хукі ўваходзяць у число найпрыдатнейшых прымітіваў харчувальных систем. Хук дазволяе часавой сістэме реагаваць на падзею жыцёвага циклу за дапамогою дэтерміністычнага коду. Найболей зрозумелым прыкладам є кераванне вызовамі інструментаў.
Before tool call
↓
Check policy
↓
Allow / deny
Іншы хук падтрымлівае стабільнасць якосці коду пасля кожных змян.
After file edit
↓
Run formatter
↓
Run type checker
Трэці хук заходзіць ведамасць пры скарыгаванні контексту.
Before context compaction
↓
Persist important state
Чэтырты хук стварае летап аудыту.
After task completion
↓
Generate audit record
Claude Code дакументуе хукі як команды, якія запускаюцца пад час падзеў жыцёвага циклу дэтерміністычна і можу, сярод іншага, заблокаваць вызов інструмента пры яго выкананні. Їхня сіла крыўцяцца з таго, што ўзьязды поведэння выкарыстоўваюцца паўнасцю паза механізмамі рашэння моделі. У працоўным запите замест таго, каб пісаць «прашу не забыць запустыць форматар», часовая сістэма проста запускае форматар кожны раз.
Ніколі не давайце модэлі кераваць граніцамі
Моделі ўоснованы на верагатнасцях; межы безпекі такімі быць не можаць. Штатны падход перакладае прыняття рашэння на модель:
if model_says_safe:
execute()
Штатны падход перакладае прыняття рашэння на інфраструктуру, якая не можа змяніць свой адказ:
if operating_system_allows:
execute()
Іспользуйце модель для рашэнняў, якія выгадваюць ад суджэння, а детерміністычную інфраструктуру для рашэнняў, якія патрабуюць гарантый. У практыцы кожны слой адпавядае на сваё запитанне.
Model:
Should I modify this file?
Harness:
Is this file inside the workspace?
OS:
Can this process write to the file?
Human:
Should this high-risk action proceed?
Модель выявляе, чы рошэнне пра змяну є правильным, інструменты пераканальваюцца, чы цэль знаходзіцца ў рабочай зоне, аператывная система выявляе, чы процес можа запісаць файл, а чалавек выявляе, чы дзія з высокым рызыкам павінна быць адбута. Такія слойвыя адказы ў дзесяткі разоў надзейныя, чым спадзяванне, што якась одна складовая усё зробіць правільна.
Інструменты павышаюць эфектыўнасць модэляў; яны іх не заменяюць
Існуе прагненне вывести, што прыстроі маюць большое значэнне, чым моделі. Аднак доказы гэтага не падтрымляюць. У даследаванай сітуацыі выбор прыстрою мял вялікі паўтарак на эфектывнасць работы, але значна меньшы паўтарак на успех задання, і жадна колькасць роботы над архітектурой не можа ператворыць слабую модель у сильнага інжынера прыкладнага програмнага забезпечэння. Чысты спосаб разлічыць гэтыя два элементы:
Model capability
=
What the agent can reason about
Harness quality
=
How effectively that capability is deployed
Геніальная модель у складзе слабай архітектуры витрачае вельмі большую кантэкстную інфармацыю та грошы. Рэтельна спроектаваная архітектура нават у складзе слабай моделі даўа слабыя рашэнні, проста безпечна і эфектыва. Патрэбны як модель, так і архітектура.
Пяць запытанняў, якія трэба задаць перад размешчэнням любога агента
1. Чым ён можа кераваць?
Узняце інвентары ўсіх інструментоў і пазначыце кожную небяпечную операцыю.
read
write
delete
execute
network
deploy
send_message
2. Да чаго ён можа дасягнуць?
Апісанні інструментоў паведамляюць толькі частку правды. Пераканайцеся, каму на самае працэс можа фактычна даўступіць:
filesystem
network
environment
secrets
processes
credentials
3. Чыя данні застаюцца пасля перзапуску?
Перзапустіце агента і выявіце:
What does it remember?
What does it forget?
Where is important state stored?
4. Хто пераканальвае рэзультат?
Для операцый з наследкамі дваэтапны процес недастатковы:
generate → approve
Даўце незалежныя пераканальванні між стварэнням і затверджэнням:
generate
↓
test
↓
review
↓
approve
5. Скількі насправды коштае кожны заданні?
Колькасць токенаў на адна запытка сама па сабе ёсць вадзічная:
tokens per request
Замест таго меркуце рэзультаты:
tokens per successful task
latency per successful task
tool calls per task
retries per task
human interventions
Токены, зволіканні, вызовы інструментаў, праказы і участка людзей на адна успешная заданні — гэтыя паказнікі парадзіваюць, чы рэальна ўтратачыць систему.
Функцыйная адзінка прымэтнага агента
Спалучанне всіх слоёў дае болей адрадную дэфініцыю.
Agent =
Model
+ Tools
+ Execution Environment
+ Policy
+ Memory
+ Context Management
+ Verification
+ Observability
Кожны элемент займае сваё месца. Без модэлю няма інтелігенцыі; без інструментаў няма дзеяння; без среды выканання і правіл агент можа стаць небяпечным; без памяці дзейніцы стаюць кранкавымі; без кантролю контэкста витраты растуць стрэмганна; без перакранчвання бяспекі паклучэнні распространяюцца непазначана; а без можлівасці спаглядання нельга восстанавіць тое, што адбылася, калі ўсё пайшло не так.
Заключанне
У працоўнікама галузі разговоры пераходзяць з таго, який модель павышае рэкорды, на тое, який час выконання дозволяе модэлю надзейна выканаць корисную работу. Продавцы адыходзяць да адных і тых сабе элементаў: OpenAI зараз продае інфраструктуру кераваных агентаў, якая ўключае сэндбоксы, обработку контексту, пошук інструментаў, вызовы інструментаў з коду та дзейнасць працы на длігі час, тады як Anthropic адкрывае можлівасці для стойкіх інструкцыяў, навыкаў, падагентаў та дэтерміністычных прыемоў. Научныя доследжэння пачынаюць ацэніваць гэтыя элементы як эксперыментальныя зменныя, а не спрыяць модэлю як цэлай системе. Што стосуецца гэтых функцыяй, яны быстра развіваюцца, таму пераканайцеся ў актуальной документацыі.
Простая схема стварэння агента ёсць короткая:
Pick LLM
+
Add tools
=
Agent
Рэалістычная схема выглядае так:
Model
↓
Agent Runtime
↓
┌─────────┼─────────┐
↓ ↓ ↓
Policy Context Memory
↓ ↓ ↓
Sandbox Tools Persistence
└─────────┼─────────┘
↓
Verification
↓
Observability
Модэль прыме рашынкі; канструкцыя вызначае умовы, пад якімі гэтыя рашынкі ператвараюцца ў дзеянні. Перш чым выбраць фрэймворк, запытайцеся, што будзе, калі модэль будзе некоректная, і стварыце канструкцыю на адпаведнаасці з гэтым адказам.
- Застаўляйце дэтэрміністычныя правілы ў кодзе і хукі, а не у запытаннях.
- Спрыяйце тое, каб політыкі інструментаў былі першай лінійай захавання, а сандбокс ОС, укладаючы ў сябе ліміты сеті і рэсурсаў, быў практычным межам.
- Раздзеляйце стан размовы, проекту і канструкцыі за періодамі ўжывання, і зберагайце факты проекту пры яго складзенні.
- Залучайце незалежных пераканальнікаў, каб яны толькі адмаўлялі, а не выправлялі прычыны.
- Оптымізавайце канты пры кожным успешным заданні і зупіняйце запускі, якія больш не даюць прыбылі.
Мета — не агент, які ніколі не памыляецца, а система, у якой памылка модэль не ператвараецца аўтаматычна ў інцидэнт у працэсе выканання.