Галоўная / Артыкулы

Стабільнае імя агента — не той артэфакт, які вы праверылі: фіксуйце кандыдата

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

Выдавец: REACTAPP.TOP8 хв чытання1909 слоў

Крыніцы: **The Agent Name Isn’t the Artifact You Reviewed**

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

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

Імены коордынуюць, кандыдаты несу доказы

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

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

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

Канфігурацыя стае матэрыялам, які можна адзірнуць

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

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

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

Версіяваныя часткі все ж можу стварыць неяснае цэлэ

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

Разглянем, як працэс фіксаціі можа стаць частковым:

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

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

Тры ідэнтыфікаторы лепшыя за адны

Змушэнне аднаго ідэнтыфікатора несці всі значэнні быстра стварае плутанне. Ціннае ў раздзеленні ёсць прынеймна трое слоёў.

Ідэнтыфікатор для людзей

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

Ідэнтыфікацыя кандыдата на паведанне

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

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

    Ідэнтыфікатор выканання

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

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

    Што заслуговае на фіксацыю

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

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

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

    Ацэнка, адлагоджэнне і вярнэнне да пачатковага стану маюць адну спадзячуюся патрэбу

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

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

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

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

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

    Не дазвольце конфігурацыі паглотыць працэс выканання

    Спакусным перастрахоўкам являецца грандыя „фота“, якія зафіксаваюць усё. Гэта прыносіць новыя проблемы. Змінна памяць, запрашаныя дакументы, даныя, якія вводзі корыстнікі, стан зовнішніх API, час і аутантыкаты — усе гэта вплывае на ход выканання. Дзеяннія можуць быць чутлівымі, мусіць застацца дынамічнымі, а дзеяннія, якія нельгае точна пераграць, не можуць быць частынай кандыдата.

    Чыстэйшая межа выглядае так:

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

    Шары можаць абсалютна вказваць адзін на аднаго, не зліваючыся ў аднаго артэфакта. Гэтыя межы таксама не дазволяюць „точнай ідэнтычнасці“ ператварыцца на тверджэнне, якое доказы не можаць падтрымаць. Выбір конкрэтнага кандыдата не робіць мадэль дэтэрміністычной, не заморажоўвае ёе паza сістэмамі і не гарантуе ідэнтычнага рэзультата пазней. Ён толькі дазволяе восстановіць прэдмет тверджэння, і гэта ужо дапамагае чырвона.

    Тэст з пяці запытанняў

    Калі імяваны агент мае настаць значэнне для перагляду чы адпускання, запытайце:

    1. Што можа змяніцца без змены імені? У большасці сістэм — больш, чым людзі чакаюць.
    2. Калі з тых змян можа знівэць гэта конкрэтнае тверджэнне пра перагляд? Гэта залежыць ад таго, чы рашэнне стосуецца якосці, безпекі, прав, надзеямасці, косту чы гатовнасці.
  • Можна ля гэтым прынятым складам восстанавіць пазней? Версія дапамагае толькі тады, калі яе залежнасці ператвараюцца ў ўжо конкрэтны элементы.
  • Можна звязаць неудачны запуск з гэтым складам? Калі няма, то адлучэнне прычыны неудачы немагчыма, таму што нельга розлічыць можлівыя прычыны неудачы ад іншых фактораў.
  • Можна за дапамогою адвярнення восстанавіць весь склад, а не толькі яго частку? Калі няма, значыць у сістэме ёсць версіяваныя часткі без надзеянага ідэнтыфікатора выдання.
  • Нічога з гэтага не вымагае спецыяльных рэгламентаў для кожной змены. Патрэбна точнасць, калі твэрджэння пачынае маты наследкі. Паколькі поведэнне агента складаецца з элементаў, якія знаходзяцца над і ўнутры модэлю, і гэты склад стае модульным, перэносным, версіяваным чы заменным, настройкі больш не ёсць проста додатковым элементам. Яны стаюць часткай самага віконванага кандыдата. Назва можа застацца тая ж, але доказы павінны паказваць, што зменілася.

    Спаднія матэрыялы

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