Кіраваныя AI-агенты: адна мадэль палітык, некалькі кропак прымянення

Агент з адказкі службы прымае запіт на вярненне грошаў. У паведамленні ёсць номер абліквату і номер тэлефона. Чырабатваць з гэтым запітам агенту патрэбны мадэль мовы для чытання запіту, внутраній інструмент для пошуку замовлення, CRM, да якога можна дастынуцца праз MCP, каб дадаць прыметку, і, можа, другі агент для перагляду незвычайна вялікага вярнення. Нічога з гэтага ўжо не ёсць экзотычным. Складнасць у тым, што кожны этап у гэй ланцугу пераходзіць праз разныя межы правіл, і кожны такі пераход стварае сваю сабе запытанне.

• Чы можна перадаць гэтыя даныя кліента да выбранага прадавця модэляў?
• Чы запіт застаецца ў межах яго бюджэту на вітраты?
• Чы гэты завантажэння можа выкарыстоўваць гэты мадэль у гэтам рэгіоне?
• Чы сервер CRM павінен прымаць весь дзялон размовы?
• Чы інструмент для вярнення грошаў можа выдаты 2 000 долераў без падтрымкі чалавека?

Якшо паветраны модэль не працюе, чы хутчэйшая альтэрнатыва забезпечвае эквівалентную рэзыдэнцію дадзейнаў і абарону?

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

Опублікованая рамка для керавання агентамі добра опісвае гэты перакід: кераванне задае правілы, а шлюз — гэта месца, дзе гэтыя правілы зустрочаюцца з рэальным трафікам. Ён арганізуе работу на пяць актываў: кераванне, прыняцця рашэння, абарона, спагляданне і паверкі. Корыстны момент у гэтым падходзе — гэта, што вызовы модэляў, інструментаў, MCP і перакіды межу агентамі кожны несу разныя рызыкі. Гэта размежаванне дапамагае стварыць лепшыя рашэнні, чым сумкнуць усе кантролі ў адны вялікі прампт чы шлюз.

Нехай правілы прайдуць разам з запросам

Самыя простая структура — гэта пакет управлення, які супрадувае аб’яднанню ў сістэме. У яму ёсць достатнькі даны, каб з’ясаваць, чы можна перасічыць певныя межы:

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

Не кожны компанент патрабуе кожнага поля. Пакет управлення існуе, каб тыя ж вопыты можна было адпаведзаць адносова незалежна ад таго, куды прайдзе агент.

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

Для вікліку MCP сервер ёсць тым, з якім відбуваецца співверстання, а даныя віходзяць за межы інфраструктуры.

Пры перэдачы даных ад агента до агента важліво, чы можа отрымувач бачыты кантэкст, які перэдаецца.

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

Короткій опіс, нейтральній до постачальніка

Не потрыбна жодна платформа керування, шчоб бачыты гэты шаблон. Наведэній ніжчэ Pythonовій код ёсць навмісно нейтральнім і не прыв’язанім до жодного API продукту. Яго задачы — відображаты точкі прыйманя рышэнь.

from dataclasses import dataclass
from enum import Enum

class Decision(str, Enum):
    ALLOW = "allow"
    BLOCK = "block"
    APPROVAL = "approval"
    FALLBACK = "fallback"

@dataclass(frozen=True)
class PolicyContext:
    user_id: str
    workload: str
    risk_tier: str
    data_class: str
    spend_usd: float
    spend_limit_usd: float
    policy_version: str

def before_model_call(ctx: PolicyContext, model: str) -> Decision:
    if ctx.spend_usd >= ctx.spend_limit_usd:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
        return Decision.FALLBACK
    return Decision.ALLOW

def before_tool_call(
    ctx: PolicyContext,
    tool: str,
    amount: float = 0,
) -> Decision:
    if tool not in TOOL_SCOPES[ctx.workload]:
        return Decision.BLOCK
    if tool == "issue_refund" and amount > 500:
        return Decision.APPROVAL
    return Decision.ALLOW

def before_mcp_call(
    ctx: PolicyContext,
    server: str,
) -> Decision:
    if server not in APPROVED_MCP_SERVERS:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
        return Decision.BLOCK
    return Decision.ALLOW

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

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

Модэльны шлюз дапамагае, але ён не ўсё ў структуры дызайну

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

Гэта важна, таму што інакш кераванне модэлямі будзе копіювалася ў кожны агент.

agent A → custom rate logic → OpenAI
agent B → custom PII logic  → Anthropic
agent C → custom fallback   → Gemini
agent D → no controls       → self-hosted model

Шлюз можа з’едыніць стос у адной спяльнай шараўскай структуры.

  agents
     ↓
shared model-call policy
     ↓
approved providers / hosts

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

Надзяйнасць таксама ўлучваецца ў кантэкст управління

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

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

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

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

usage approaches threshold
        ↓
      alert
        ↓
route / reduce context / downgrade model if allowed
        ↓
hard block when policy requires it
        ↓
auditable exception path if business-approved

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

Косць цэнтральнай плошчы кантролю

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

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

Правіла рэдакцыі трэба тэставаць на наявнасць вытаканняў даных, а таксама на хыбныя позытыўныя рэзультаты.

Змены правілаў павінны маты версіяванне, поступовае впрыўшчэнне і адкатуванне так сама, як і код прыемліка.

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

Норматыўныя акты не должны контролаваць значныя дзеянні

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

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

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

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

Назіранне і абяцанні

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

• Заблокаваны запіт да мадэлю паказвае, якая політыка выканалася.
• Падзея выдалення паказвае, якая версія політыкі была застосавана, не адкрываючы чутлівых дадзенняў.
• Узгоджэнне інструмента прыяўляецца да дзейства, якое ён контролюе.

Функцыя альтэрнатыўнага рашэння фіксуе прычыны неудачы асновнага рашэння і прычыны, чым заменяючыя рашэння былі прызнаны прыемлімымі.

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

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

Што гэта значыць для архітэктуры агентаў

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

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

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

• Хто прасіць?
• Калікі даныя пераводзяцца і куды?
• Сколькі робочага часу дазволена выкарыстоўваць?
• Калікі модэляў і інструментаў дазволеныя?
• Какі ў плане, якшо выбраны шлях не спрацюе?
• Чы трэба падтверджэнне ад чалавека?
• Калікі версія правіла выдала рашэнне?

Гэта і ўсё, што адразняе наявнасць правілаў для AI ад наявнасці кераваных агентаў.