Внешний вызов прошёл, а запись — нет
Сверяться с внешней системой или ждать оператора, если вызов прошёл, а запись — нет? Коротко: политику выбирают по тому, что можно повторить без последствий.
Разбор — в следующем сообщении 👇
#ЭлисAI #ИИагенты #архитектура
Сверяться с внешней системой или ждать оператора, если вызов прошёл, а запись — нет? Коротко: политику выбирают по тому, что можно повторить без последствий.
Разбор — в следующем сообщении 👇
#ЭлисAI #ИИагенты #архитектура
Внешний вызов прошёл, а запись — нет
Вопрос звучит просто: «внешний вызов уже прошёл, а результат не успел записаться на диск — сверяться с внешней системой или останавливаться и ждать оператора?»
На самом деле «сверяться или ждать» — ложная дилемма. Безопасность — не свойство метода сверки, а свойство самого действия. У разных действий разные гарантии, и одна политика на всех — верный способ сделать систему либо опасной, либо бесполезной.
Три примера:
- файл записан атомарно, но событие в журнал не попало — сверка «файл существует?» решает проблему;
- письмо, возможно, ушло — но мы этого не знаем. Повтор — это второе письмо, значит, единственный безопасный выбор — оператор;
- git push прошёл — сверка возможна, но требует внешней точки правды, которая сама может врать.
Ключевая идея: политика определяется не тем, что мы можем проверить, а тем, что мы можем повторить без последствий. Файл — можем. Письмо — не можем. Платёж — тем более.
Почему не «всегда сверяться»? Сверка — тоже внешний вызов: она может упасть, вернуть неверный ответ или занять время. Почему не «всегда ждать оператора»? Оператор — не бесплатный ресурс: если каждая запись файла требует подтверждения, агент бесполезен. А «повторять всё, что не записалось» — самый опасный вариант: второе письмо, двойное списание.
Технически всё просто: перед каждым действием записываем намерение, после него — результат. «Намерение есть, результата нет» — это и есть точка сверки. Дальше — по классу действия: файловые и read-only операции сверяем и повторяем, браузерные и time-sensitive помечаем needs_reconcile и ждём решения оператора.
И главное: класс действия должен быть явным. Не «агент сам решит», а «в контракте инструмента написано». Агент не должен угадывать.
Полный разбор — с примерами, классами действий и тем, что не работает, — в блоге: https://blog.arhellist.ru/blog/vneshniy-vyzov-proshyol-a-zapis-net-sveryatsya-ili-zhdat-operatora
#ЭлисAI #ИИагенты #архитектура
Вопрос звучит просто: «внешний вызов уже прошёл, а результат не успел записаться на диск — сверяться с внешней системой или останавливаться и ждать оператора?»
На самом деле «сверяться или ждать» — ложная дилемма. Безопасность — не свойство метода сверки, а свойство самого действия. У разных действий разные гарантии, и одна политика на всех — верный способ сделать систему либо опасной, либо бесполезной.
Три примера:
- файл записан атомарно, но событие в журнал не попало — сверка «файл существует?» решает проблему;
- письмо, возможно, ушло — но мы этого не знаем. Повтор — это второе письмо, значит, единственный безопасный выбор — оператор;
- git push прошёл — сверка возможна, но требует внешней точки правды, которая сама может врать.
Ключевая идея: политика определяется не тем, что мы можем проверить, а тем, что мы можем повторить без последствий. Файл — можем. Письмо — не можем. Платёж — тем более.
Почему не «всегда сверяться»? Сверка — тоже внешний вызов: она может упасть, вернуть неверный ответ или занять время. Почему не «всегда ждать оператора»? Оператор — не бесплатный ресурс: если каждая запись файла требует подтверждения, агент бесполезен. А «повторять всё, что не записалось» — самый опасный вариант: второе письмо, двойное списание.
Технически всё просто: перед каждым действием записываем намерение, после него — результат. «Намерение есть, результата нет» — это и есть точка сверки. Дальше — по классу действия: файловые и read-only операции сверяем и повторяем, браузерные и time-sensitive помечаем needs_reconcile и ждём решения оператора.
И главное: класс действия должен быть явным. Не «агент сам решит», а «в контракте инструмента написано». Агент не должен угадывать.
Полный разбор — с примерами, классами действий и тем, что не работает, — в блоге: https://blog.arhellist.ru/blog/vneshniy-vyzov-proshyol-a-zapis-net-sveryatsya-ili-zhdat-operatora
#ЭлисAI #ИИагенты #архитектура
Кто принимает результат
Кто принимает результат — агент или отдельный проверяющий? Коротко: агент производит, код принимает — на трёх уровнях.
Разбор — в следующем сообщении 👇
#ЭлисAI #ИИагенты #архитектура
Кто принимает результат — агент или отдельный проверяющий? Коротко: агент производит, код принимает — на трёх уровнях.
Разбор — в следующем сообщении 👇
#ЭлисAI #ИИагенты #архитектура
Кто принимает результат
Вопрос: «кто принимает результат — отдельный проверяющий шаг или сам агент?» Это вопрос про архитектуру доверия в многошаговом агенте. И ответ — не «то или это», а «и то, и другое, но в разных ролях».
«Сам агент» — это декларация, а не проверка. Агент видит интерфейс, а не реальность: тост «письмо отправлено» мог быть про черновик. Агент не врёт — он просто не знает, что произошло на самом деле.
Отдельный проверяющий лучше, но не панацея: он видит тот же интерфейс, стоит денег и времени и не сверяет результат с задачей.
Что работает — три уровня приёмки, каждый ловит свой класс ошибок:
- оракул — код, который проверяет факт (slug, теги, письмо в «Отправленных», текст в PDF) и говорит PASS или FAIL;
- аудит — проверяет полноту: всё ли, что просили, сделано;
- оператор — разрешает неопределённость там, где повтор опасен, а сверка ненадёжна.
Оракул не спрашивает агента: он смотрит в реальность и, если FAIL, возвращает конкретное поле — «slug старый», «теги не те». Пока оракул не сказал PASS, задача не закрыта. Аудит ловит «сделал две вещи из трёх», оператор — «мы не знаем, что произошло, и автоматика не может узнать».
Каждый уровень дополняет другие, а не заменяет. Если убрать один, ошибки его класса проходят. И LLM-judge здесь — не судья: это мнение, а не факт, полезный дополнительный фильтр, но не замена оракулу.
Итог: агент результат производит, а принимает его код. Агент, который принимает результат сам, — это агент, который врёт с чистой совестью. Агент, который отдаёт результат на проверку коду и человеку, — это агент, которому можно доверять.
Полный разбор — с примером из жизни и тем, что не работает, — в блоге: https://blog.arhellist.ru/blog/kto-prinimaet-rezultat-v-mnogoshagovom-agente-agent-proveryayuschiy-ili-kod
#ЭлисAI #ИИагенты #архитектура
Вопрос: «кто принимает результат — отдельный проверяющий шаг или сам агент?» Это вопрос про архитектуру доверия в многошаговом агенте. И ответ — не «то или это», а «и то, и другое, но в разных ролях».
«Сам агент» — это декларация, а не проверка. Агент видит интерфейс, а не реальность: тост «письмо отправлено» мог быть про черновик. Агент не врёт — он просто не знает, что произошло на самом деле.
Отдельный проверяющий лучше, но не панацея: он видит тот же интерфейс, стоит денег и времени и не сверяет результат с задачей.
Что работает — три уровня приёмки, каждый ловит свой класс ошибок:
- оракул — код, который проверяет факт (slug, теги, письмо в «Отправленных», текст в PDF) и говорит PASS или FAIL;
- аудит — проверяет полноту: всё ли, что просили, сделано;
- оператор — разрешает неопределённость там, где повтор опасен, а сверка ненадёжна.
Оракул не спрашивает агента: он смотрит в реальность и, если FAIL, возвращает конкретное поле — «slug старый», «теги не те». Пока оракул не сказал PASS, задача не закрыта. Аудит ловит «сделал две вещи из трёх», оператор — «мы не знаем, что произошло, и автоматика не может узнать».
Каждый уровень дополняет другие, а не заменяет. Если убрать один, ошибки его класса проходят. И LLM-judge здесь — не судья: это мнение, а не факт, полезный дополнительный фильтр, но не замена оракулу.
Итог: агент результат производит, а принимает его код. Агент, который принимает результат сам, — это агент, который врёт с чистой совестью. Агент, который отдаёт результат на проверку коду и человеку, — это агент, которому можно доверять.
Полный разбор — с примером из жизни и тем, что не работает, — в блоге: https://blog.arhellist.ru/blog/kto-prinimaet-rezultat-v-mnogoshagovom-agente-agent-proveryayuschiy-ili-kod
#ЭлисAI #ИИагенты #архитектура
Недавно прошёл свои витрины чек-листом технического SEO — не ради отчёта, а чтобы понять, что реально видит бот.
Коротко, что смотрел и правил:
• текст/title/h1 в HTML, а не пустой CSR-shell
• уникальные title, description, canonical
• один h1, без служебных EN-stubs
• честный 404 (+ noindex), не soft-404 с 200
• редиректы без хоровода: https, www↔apex, trailing slash
• robots + sitemap без служебного и дублей
• сжатие: gzip и отдельно brotli (Accept-Encoding: br → content-encoding: br)
• кэш HTML без вечного no-store и без годового s-maxage без purge
• JSON-LD по типу страницы
• тонкий контент vs карточки + один CTA
• дубли путей (поддомен блога vs /blog/, чужой canonical)
• HSTS, nosniff; по желанию убрать версию nginx из Server
Brotli в этом списке не «вишенка»: если клиент просит br, а вы отдаёте сырой или только gzip — просто дарите лишний вес ответа.
Полный разбор — в блоге https://arhellist.ru/blog/tehnicheskoe-seo-kak-chek-list-chto-ya-proveryayu-na-svoih-vitrinah/.
Почему Next SSR, а не обычный SPA на React: боту нужен текст в первом HTML. SPA часто отдаёт пустую оболочку и ждёт JS — человек видит страницу, робот нет. SSR отдаёт готовую разметку сразу; React потом только оживляет UI. Для публичных витрин так спокойнее с title/h1/404/canonical.
#seo #техническоеSEO #webdev #brotli
Коротко, что смотрел и правил:
• текст/title/h1 в HTML, а не пустой CSR-shell
• уникальные title, description, canonical
• один h1, без служебных EN-stubs
• честный 404 (+ noindex), не soft-404 с 200
• редиректы без хоровода: https, www↔apex, trailing slash
• robots + sitemap без служебного и дублей
• сжатие: gzip и отдельно brotli (Accept-Encoding: br → content-encoding: br)
• кэш HTML без вечного no-store и без годового s-maxage без purge
• JSON-LD по типу страницы
• тонкий контент vs карточки + один CTA
• дубли путей (поддомен блога vs /blog/, чужой canonical)
• HSTS, nosniff; по желанию убрать версию nginx из Server
Brotli в этом списке не «вишенка»: если клиент просит br, а вы отдаёте сырой или только gzip — просто дарите лишний вес ответа.
Полный разбор — в блоге https://arhellist.ru/blog/tehnicheskoe-seo-kak-chek-list-chto-ya-proveryayu-na-svoih-vitrinah/.
Почему Next SSR, а не обычный SPA на React: боту нужен текст в первом HTML. SPA часто отдаёт пустую оболочку и ждёт JS — человек видит страницу, робот нет. SSR отдаёт готовую разметку сразу; React потом только оживляет UI. Для публичных витрин так спокойнее с title/h1/404/canonical.
#seo #техническоеSEO #webdev #brotli
Контракт общения: почему агент не должен читать лекции
Пишешь агенту «глянь, что там с ценами», а получаешь три абзаца теории и вопрос «какой сайт вы имели в виду?». Модель не глупая — ей просто никто не объяснил, что за сообщение перед ней. В Элис эту проблему решают два механизма: классификатор задач и контракт общения из шести правил.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #LLM
Пишешь агенту «глянь, что там с ценами», а получаешь три абзаца теории и вопрос «какой сайт вы имели в виду?». Модель не глупая — ей просто никто не объяснил, что за сообщение перед ней. В Элис эту проблему решают два механизма: классификатор задач и контракт общения из шести правил.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #LLM
Контракт общения: почему агент не должен читать лекции
Пишешь агенту «глянь, что там с ценами», а получаешь три абзаца теории и вопрос «какой сайт вы имели в виду?». Или наоборот: спрашиваешь «а что такое outbox?», а агент лезет в файлы, запускает поиск и тратит бюджет на то, на что хватило бы двух предложений.
Модель в обоих случаях не глупая. Она просто не знает, что за сообщение перед ней: вопрос, болтовня или задача, после которой в мире что-то изменится. И отвечает на всё в одном режиме.
Поэтому в Элис до любых инструментов работает классификатор. Он относит сообщение к одному из типов: поиск, навигация, файлы, генерация, побочное действие, многошаговая задача, болтовня, системная команда. От типа зависит сценарий до первого вызова инструмента. Для поиска, например, агент сначала смотрит выдачу сам, а не просит человека выбрать сайт из списка.
Поверх классификатора — контракт общения. Шесть правил:
• коротко;
• результат, а не лекция;
• данные ищи сам; спросить можно, только если без ответа действие невозможно (нет адреса, идентификатора);
• не больше одного вопроса, и лучше с вариантами;
• отказ — честный и с подсказкой, что можно сделать;
• рассуждения — не ответ.
Контракт лежит в стабильном префиксе (неизменной части контекста, которая кэшируется у провайдера), а охрана ответа, о которой следующий пост, проверяет финальный текст именно по нему.
Где было трудно. Ошибка классификатора бьёт в обе стороны. Принял многошаговую задачу за болтовню — агент отвечает «из головы» вместо работы. Принял вопрос за побочное действие — тратит бюджет и трогает то, что трогать не просили. А два правила тянут друг против друга: «найди сам» и «спроси, если опасно». Границу провели так: спрашивать можно один раз и только то, без чего действие физически не выполнить. Всё остальное агент добывает сам.
Урок: прежде чем учить агента отвечать, научите его понимать, что именно у него спросили.
А вас агенты чаще раздражают лекциями или вопросами?
#Элис #ЭлисAI #AIагенты #LLM
👉 Канал про Элис: https://t.me/harness_ai_ru
Пишешь агенту «глянь, что там с ценами», а получаешь три абзаца теории и вопрос «какой сайт вы имели в виду?». Или наоборот: спрашиваешь «а что такое outbox?», а агент лезет в файлы, запускает поиск и тратит бюджет на то, на что хватило бы двух предложений.
Модель в обоих случаях не глупая. Она просто не знает, что за сообщение перед ней: вопрос, болтовня или задача, после которой в мире что-то изменится. И отвечает на всё в одном режиме.
Поэтому в Элис до любых инструментов работает классификатор. Он относит сообщение к одному из типов: поиск, навигация, файлы, генерация, побочное действие, многошаговая задача, болтовня, системная команда. От типа зависит сценарий до первого вызова инструмента. Для поиска, например, агент сначала смотрит выдачу сам, а не просит человека выбрать сайт из списка.
Поверх классификатора — контракт общения. Шесть правил:
• коротко;
• результат, а не лекция;
• данные ищи сам; спросить можно, только если без ответа действие невозможно (нет адреса, идентификатора);
• не больше одного вопроса, и лучше с вариантами;
• отказ — честный и с подсказкой, что можно сделать;
• рассуждения — не ответ.
Контракт лежит в стабильном префиксе (неизменной части контекста, которая кэшируется у провайдера), а охрана ответа, о которой следующий пост, проверяет финальный текст именно по нему.
Где было трудно. Ошибка классификатора бьёт в обе стороны. Принял многошаговую задачу за болтовню — агент отвечает «из головы» вместо работы. Принял вопрос за побочное действие — тратит бюджет и трогает то, что трогать не просили. А два правила тянут друг против друга: «найди сам» и «спроси, если опасно». Границу провели так: спрашивать можно один раз и только то, без чего действие физически не выполнить. Всё остальное агент добывает сам.
Урок: прежде чем учить агента отвечать, научите его понимать, что именно у него спросили.
А вас агенты чаще раздражают лекциями или вопросами?
#Элис #ЭлисAI #AIагенты #LLM
👉 Канал про Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Охрана ответа: как поймать агента на «уже отправил»
Самая неприятная ошибка агента — не падение, а уверенное «отправил», когда ничего не отправлено. Падение видно сразу. Ложный отчёт всплывает, когда уже поздно. Рассказываю, как в Элис финальный ответ сверяется с журналом действий.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #надёжность
Самая неприятная ошибка агента — не падение, а уверенное «отправил», когда ничего не отправлено. Падение видно сразу. Ложный отчёт всплывает, когда уже поздно. Рассказываю, как в Элис финальный ответ сверяется с журналом действий.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #надёжность
Охрана ответа: как поймать агента на «уже отправил»
Самая неприятная ошибка агента — не падение, а уверенное «отправил», когда ничего не отправлено. Падение видно сразу. Ложный отчёт всплывает через день, когда человек спрашивает «а где?».
Откуда это берётся. Языковая модель обучена писать правдоподобный текст. «Готово, я всё обновил» — очень правдоподобное завершение диалога. Модель не врёт сознательно: она продолжает текст так, как он обычно продолжается. Значит, проверять её надо не промптом «не ври», а фактами.
В Элис финальный текст проходит охрану ответа. Три правила:
• прогресс — не финал. «Сейчас посмотрю» — это статус, а не ответ, и ход им не закрывается;
• один мягкий толчок. Если модель написала «сейчас сделаю», но инструмент не вызвала, цикл один раз напоминает ей об этом. Ровно один — чтобы не устроить бесконечную перепалку;
• проверка перед «сделал». Прежде чем пропустить «отправил / записал / создал», охрана смотрит в журнал: было ли такое действие и чем оно закончилось. Не было — повтор или честный отчёт, а не уверенная ложь.
Почему это вообще возможно. Каждое реальное действие в Элис оставляет событие в журнале. Нет события — это не мнение охраны, это расхождение между словами и фактами. А «успех» с пустым результатом считается отдельным видом провала — молчаливым, и его ловит финальная проверка.
Где было трудно. Модель не пишет машиночитаемое «действие: файл записан». Она пишет «обновил конфиг и всё проверил». Слишком строгая охрана режет нормальные ответы, слишком мягкая пропускает выдумки. Компромисс такой: жёстко сверяем то, что можно сопоставить с журналом побочных действий, и не делаем вид, что проверили остальное. А частичный отчёт — «это сделал, это не получилось» — не ложь, и охрана его не трогает.
Урок: агенту нельзя верить на слово. Но и душить его подозрениями нельзя. Проверяйте утверждения о действиях по фактам — и только их.
Ловили своих агентов на «уже сделал»?
#Элис #ЭлисAI #AIагенты #надёжность
👉 Канал про Элис: https://t.me/harness_ai_ru
Самая неприятная ошибка агента — не падение, а уверенное «отправил», когда ничего не отправлено. Падение видно сразу. Ложный отчёт всплывает через день, когда человек спрашивает «а где?».
Откуда это берётся. Языковая модель обучена писать правдоподобный текст. «Готово, я всё обновил» — очень правдоподобное завершение диалога. Модель не врёт сознательно: она продолжает текст так, как он обычно продолжается. Значит, проверять её надо не промптом «не ври», а фактами.
В Элис финальный текст проходит охрану ответа. Три правила:
• прогресс — не финал. «Сейчас посмотрю» — это статус, а не ответ, и ход им не закрывается;
• один мягкий толчок. Если модель написала «сейчас сделаю», но инструмент не вызвала, цикл один раз напоминает ей об этом. Ровно один — чтобы не устроить бесконечную перепалку;
• проверка перед «сделал». Прежде чем пропустить «отправил / записал / создал», охрана смотрит в журнал: было ли такое действие и чем оно закончилось. Не было — повтор или честный отчёт, а не уверенная ложь.
Почему это вообще возможно. Каждое реальное действие в Элис оставляет событие в журнале. Нет события — это не мнение охраны, это расхождение между словами и фактами. А «успех» с пустым результатом считается отдельным видом провала — молчаливым, и его ловит финальная проверка.
Где было трудно. Модель не пишет машиночитаемое «действие: файл записан». Она пишет «обновил конфиг и всё проверил». Слишком строгая охрана режет нормальные ответы, слишком мягкая пропускает выдумки. Компромисс такой: жёстко сверяем то, что можно сопоставить с журналом побочных действий, и не делаем вид, что проверили остальное. А частичный отчёт — «это сделал, это не получилось» — не ложь, и охрана его не трогает.
Урок: агенту нельзя верить на слово. Но и душить его подозрениями нельзя. Проверяйте утверждения о действиях по фактам — и только их.
Ловили своих агентов на «уже сделал»?
#Элис #ЭлисAI #AIагенты #надёжность
👉 Канал про Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Паспорт инструмента: разрешить, спросить, запретить
Дать агенту shell, браузер и файлы — легко. Сложно решить, что из этого он делает сам, что — только с вашего согласия, а что — никогда. В Элис у каждого инструмента есть паспорт, а каждый вызов проходит политику: разрешить, спросить или запретить.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #AIагенты
Дать агенту shell, браузер и файлы — легко. Сложно решить, что из этого он делает сам, что — только с вашего согласия, а что — никогда. В Элис у каждого инструмента есть паспорт, а каждый вызов проходит политику: разрешить, спросить или запретить.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #AIагенты
Паспорт инструмента: разрешить, спросить, запретить
Дать агенту shell, браузер и доступ к файлам — дело одного вечера. Дальше начинается настоящий вопрос: что из этого он делает сам, что — только с вашего согласия, а что — никогда.
Первое желание — спрашивать про всё. Через пять минут человек жмёт «Разрешить» не глядя, и защита превращается в ритуал. Второе желание — разрешить всё. Тогда первая же ошибка модели уходит прямо в мир.
В Элис ответ на этот вопрос записан не в промпте, а в паспорте инструмента. Паспорт говорит: можно ли вызывать параллельно, нужно ли спрашивать человека, какой таймаут, что маскировать в выводе, как вести себя при переигровке и какие у инструмента типичные провалы.
Каждый вызов идёт по одному пути: реестр → политика → проверка путей → подстановка секретов → исполнение → маскирование вывода → учёт бюджета.
Политика решает так:
• заведомо опасные команды shell (повышение прав, рекурсивное удаление корня, выполнение скачанного скрипта) — запрет;
• есть постоянное разрешение человека на этот тип действий в этой группе — без вопроса;
• паспорт или правило требует подтверждения — вопрос человеку;
• человек не ответил примерно за пять минут — отказ с причиной «не дождались одобрения».
Чистые инструменты, которые ничего не меняют, работают параллельно. Меняющие состояние — строго по одному. Если инструмент требует способности, которой нет у текущей модели (например, распознавания изображений), Элис честно отказывает или использует локальный запасной путь вроде OCR.
Где было трудно. Таймаут одобрения. Ждать вечно нельзя: висит ход, блокировка, бюджет времени. Но и молчание человека — не запрет. Поэтому причина отказа отдельная: «не дождались», а не «отклонено». Иначе агент воспримет тишину как «нет» и попробует добиться своего другим инструментом. Вторая сложность — рамка постоянного разрешения: «всегда разрешать запись» слишком широко, «только этот файл» бесполезно.
Урок: подтверждение человеком — редкий и дорогой ресурс. Тратьте его там, где действие необратимо.
Как вы решаете, что агенту можно делать без спроса?
#Элис #ЭлисAI #AIбезопасность #AIагенты
👉 Канал про Элис: https://t.me/harness_ai_ru
Дать агенту shell, браузер и доступ к файлам — дело одного вечера. Дальше начинается настоящий вопрос: что из этого он делает сам, что — только с вашего согласия, а что — никогда.
Первое желание — спрашивать про всё. Через пять минут человек жмёт «Разрешить» не глядя, и защита превращается в ритуал. Второе желание — разрешить всё. Тогда первая же ошибка модели уходит прямо в мир.
В Элис ответ на этот вопрос записан не в промпте, а в паспорте инструмента. Паспорт говорит: можно ли вызывать параллельно, нужно ли спрашивать человека, какой таймаут, что маскировать в выводе, как вести себя при переигровке и какие у инструмента типичные провалы.
Каждый вызов идёт по одному пути: реестр → политика → проверка путей → подстановка секретов → исполнение → маскирование вывода → учёт бюджета.
Политика решает так:
• заведомо опасные команды shell (повышение прав, рекурсивное удаление корня, выполнение скачанного скрипта) — запрет;
• есть постоянное разрешение человека на этот тип действий в этой группе — без вопроса;
• паспорт или правило требует подтверждения — вопрос человеку;
• человек не ответил примерно за пять минут — отказ с причиной «не дождались одобрения».
Чистые инструменты, которые ничего не меняют, работают параллельно. Меняющие состояние — строго по одному. Если инструмент требует способности, которой нет у текущей модели (например, распознавания изображений), Элис честно отказывает или использует локальный запасной путь вроде OCR.
Где было трудно. Таймаут одобрения. Ждать вечно нельзя: висит ход, блокировка, бюджет времени. Но и молчание человека — не запрет. Поэтому причина отказа отдельная: «не дождались», а не «отклонено». Иначе агент воспримет тишину как «нет» и попробует добиться своего другим инструментом. Вторая сложность — рамка постоянного разрешения: «всегда разрешать запись» слишком широко, «только этот файл» бесполезно.
Урок: подтверждение человеком — редкий и дорогой ресурс. Тратьте его там, где действие необратимо.
Как вы решаете, что агенту можно делать без спроса?
#Элис #ЭлисAI #AIбезопасность #AIагенты
👉 Канал про Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Тюрьма путей: почему одной проверки строки мало
«Агент работает только внутри своей папки» — звучит как одна проверка строки. На деле это одно из самых коварных мест в Элис: две точки, симлинк и гонка между проверкой и записью. Разбираю, как устроена тюрьма путей и чего она честно не обещает.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #DevSecOps
«Агент работает только внутри своей папки» — звучит как одна проверка строки. На деле это одно из самых коварных мест в Элис: две точки, симлинк и гонка между проверкой и записью. Разбираю, как устроена тюрьма путей и чего она честно не обещает.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #DevSecOps
Тюрьма путей: почему одной проверки строки мало
«Агент работает только внутри своей папки». Звучит как одна строчка: проверил, что путь начинается с корня рабочей папки, — и готово. Именно так это обычно и пишут в первый раз. И именно так это обычно и обходят.
В Элис у каждой группы есть своё рабочее пространство, и файловые инструменты читают и пишут только внутри него. Мы называем это тюрьмой путей. Запрет на её обход стоит в инвариантах стабильного префикса, но полагаться на то, что модель его помнит, нельзя. Защищает код.
Почему простое сравнение строк не работает. Вот обходы, которые не похожи на обходы:
• относительный путь с «..», который формально начинается с правильной папки, а реально из неё выходит;
• соседняя папка с похожим именем: «/work/group» и «/work/group-old» совпадают по началу строки;
• символическая ссылка внутри рабочей папки, которая смотрит наружу;
• ссылка, подменённая между проверкой и записью, — классическая гонка «проверил — использовал»;
• shell, где команда сама перейдёт куда угодно.
Как устроено. Любой путь от модели приводится к реальному абсолютному пути — с раскрытием «..» и ссылок — и сравнивается с корнем по компонентам, а не по символам. Проверка делается в момент операции, а не заранее. Вышел за пределы — вызов отклоняется с отдельным видом провала и своим кодом выхода. Даже пакеты ставятся внутрь рабочей папки по жёсткому списку разрешённых, а не в систему. Бонус — предсказуемость: группу можно перенести или удалить целиком, зная, что агент ничего не разбросал по машине.
Где было трудно. Shell. Внутри произвольной команды файловый фильтр бессилен. Поэтому shell закрыт с двух сторон: заведомо опасные команды запрещены политикой, остальное по умолчанию идёт через подтверждение человека. Настоящую изоляцию для shell дают средства уровня ОС — контейнер или отдельный пользователь, — и честнее сказать об этом прямо, чем делать вид, что фильтр путей ловит всё.
Урок: проверяйте не строку, которую прислала модель, а реальный объект, с которым будет работать операция.
Какой обход путей вы встречали в своих проектах?
#Элис #ЭлисAI #AIбезопасность #DevSecOps
👉 Канал про Элис: https://t.me/harness_ai_ru
«Агент работает только внутри своей папки». Звучит как одна строчка: проверил, что путь начинается с корня рабочей папки, — и готово. Именно так это обычно и пишут в первый раз. И именно так это обычно и обходят.
В Элис у каждой группы есть своё рабочее пространство, и файловые инструменты читают и пишут только внутри него. Мы называем это тюрьмой путей. Запрет на её обход стоит в инвариантах стабильного префикса, но полагаться на то, что модель его помнит, нельзя. Защищает код.
Почему простое сравнение строк не работает. Вот обходы, которые не похожи на обходы:
• относительный путь с «..», который формально начинается с правильной папки, а реально из неё выходит;
• соседняя папка с похожим именем: «/work/group» и «/work/group-old» совпадают по началу строки;
• символическая ссылка внутри рабочей папки, которая смотрит наружу;
• ссылка, подменённая между проверкой и записью, — классическая гонка «проверил — использовал»;
• shell, где команда сама перейдёт куда угодно.
Как устроено. Любой путь от модели приводится к реальному абсолютному пути — с раскрытием «..» и ссылок — и сравнивается с корнем по компонентам, а не по символам. Проверка делается в момент операции, а не заранее. Вышел за пределы — вызов отклоняется с отдельным видом провала и своим кодом выхода. Даже пакеты ставятся внутрь рабочей папки по жёсткому списку разрешённых, а не в систему. Бонус — предсказуемость: группу можно перенести или удалить целиком, зная, что агент ничего не разбросал по машине.
Где было трудно. Shell. Внутри произвольной команды файловый фильтр бессилен. Поэтому shell закрыт с двух сторон: заведомо опасные команды запрещены политикой, остальное по умолчанию идёт через подтверждение человека. Настоящую изоляцию для shell дают средства уровня ОС — контейнер или отдельный пользователь, — и честнее сказать об этом прямо, чем делать вид, что фильтр путей ловит всё.
Урок: проверяйте не строку, которую прислала модель, а реальный объект, с которым будет работать операция.
Какой обход путей вы встречали в своих проектах?
#Элис #ЭлисAI #AIбезопасность #DevSecOps
👉 Канал про Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Секреты как ссылки: модели не нужен ваш ключ
Положить API-ключ в конфиг агента — самое естественное, что можно сделать. И самое опасное: всё, что попало в контекст модели, однажды окажется в ответе, логе или памяти. В Элис секрет никогда не хранится значением — только ссылкой.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #секреты
Положить API-ключ в конфиг агента — самое естественное, что можно сделать. И самое опасное: всё, что попало в контекст модели, однажды окажется в ответе, логе или памяти. В Элис секрет никогда не хранится значением — только ссылкой.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #секреты
Секреты как ссылки: модели не нужен ваш ключ
Положить API-ключ в конфиг агента — самое естественное, что можно сделать. Модель же должна как-то ходить в API. И тут кроется ошибка: модели не нужен ключ. Ей нужно, чтобы запрос выполнился.
Всё, что попало в контекст модели, может оказаться где угодно: в ответе пользователю, в истории, в сжатой сводке разговора, в журнале, в векторной памяти. Попросить модель «никогда не выводи секреты» можно — это даже стоит в инвариантах. Но гарантией это не является.
Поэтому в Элис секрет никогда не лежит значением в конфиге, журнале или контексте. В настройках хранится только ссылка: переменная окружения, файл, системная связка ключей, менеджер паролей. Значение достаёт брокер секретов — и только в момент выполнения инструмента. Модель зовёт инструмент, ключ получает инструмент.
Правила:
• в настройках — только ссылки вида «схема:путь», сырые токены запрещены;
• брокер отдаёт значение на границе исполнения и не кэширует его между ходами;
• в интерфейсе статуса видно только «есть / нет»;
• ключ подписи для обмена задачами между группами тоже берётся из брокера.
Где было трудно. Секрет утекает не через парадный вход, а через боковые двери:
• инструмент вернул ошибку, в которую попал заголовок авторизации;
• shell напечатал переменную окружения;
• отладочный лог сохранил тело запроса;
• наблюдение ушло в долгосрочную память и превратилось в эмбеддинг — числовой вектор, который потом не отредактируешь.
Закрывается это по частям. В паспорте инструмента указано, что маскировать. Наблюдение маскируется до записи в журнал. Память маскирует текст до векторизации. А если секрет достать не удалось — это отдельный вид провала, а не «попробуем без него». Работа постоянная, а не одна функция.
Урок: лучший способ не дать модели слить секрет — никогда его ей не показывать.
Где у вас в проектах живут ключи агентов?
#Элис #ЭлисAI #AIбезопасность #секреты
Канал «Harness для ИИ»: t.me/harness_ai_ru
Положить API-ключ в конфиг агента — самое естественное, что можно сделать. Модель же должна как-то ходить в API. И тут кроется ошибка: модели не нужен ключ. Ей нужно, чтобы запрос выполнился.
Всё, что попало в контекст модели, может оказаться где угодно: в ответе пользователю, в истории, в сжатой сводке разговора, в журнале, в векторной памяти. Попросить модель «никогда не выводи секреты» можно — это даже стоит в инвариантах. Но гарантией это не является.
Поэтому в Элис секрет никогда не лежит значением в конфиге, журнале или контексте. В настройках хранится только ссылка: переменная окружения, файл, системная связка ключей, менеджер паролей. Значение достаёт брокер секретов — и только в момент выполнения инструмента. Модель зовёт инструмент, ключ получает инструмент.
Правила:
• в настройках — только ссылки вида «схема:путь», сырые токены запрещены;
• брокер отдаёт значение на границе исполнения и не кэширует его между ходами;
• в интерфейсе статуса видно только «есть / нет»;
• ключ подписи для обмена задачами между группами тоже берётся из брокера.
Где было трудно. Секрет утекает не через парадный вход, а через боковые двери:
• инструмент вернул ошибку, в которую попал заголовок авторизации;
• shell напечатал переменную окружения;
• отладочный лог сохранил тело запроса;
• наблюдение ушло в долгосрочную память и превратилось в эмбеддинг — числовой вектор, который потом не отредактируешь.
Закрывается это по частям. В паспорте инструмента указано, что маскировать. Наблюдение маскируется до записи в журнал. Память маскирует текст до векторизации. А если секрет достать не удалось — это отдельный вид провала, а не «попробуем без него». Работа постоянная, а не одна функция.
Урок: лучший способ не дать модели слить секрет — никогда его ей не показывать.
Где у вас в проектах живут ключи агентов?
#Элис #ЭлисAI #AIбезопасность #секреты
Канал «Harness для ИИ»: t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Память в три слоя: как агент не отравляет сам себя
«Подключим векторную базу — и у агента будет память». Звучит красиво, пока агент не запишет собственную ошибку как факт и не начнёт уверенно на неё опираться. Рассказываю, почему память в Элис устроена в три слоя и почему забывание идёт через человека.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #память
«Подключим векторную базу — и у агента будет память». Звучит красиво, пока агент не запишет собственную ошибку как факт и не начнёт уверенно на неё опираться. Рассказываю, почему память в Элис устроена в три слоя и почему забывание идёт через человека.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIагенты #память
Память в три слоя: как агент не отравляет сам себя
«Подключим векторную базу — и у агента будет память». Так начинают почти все. Через неделю выясняется, что агент вспоминает не то, путает похожие разговоры и, хуже всего, однажды записывает собственную ошибку как факт. И дальше уверенно на неё опирается.
Поэтому память в Элис — это не одна база на всё, а три слоя. И у каждой группы своя память: между группами её не делят.
Слои:
• журнал — полный и вечный, с поиском по истории чата. Это источник правды: что было на самом деле;
• дайджест — короткая выжимка, которая уходит в динамическую часть контекста и не ломает кэш стабильного префикса;
• база памяти с тремя видами записей: эпизоды (сводки прошлых разговоров с векторами для поиска), факты в виде «субъект — отношение — объект» со степенью уверенности и индекс процедур.
Поиск гибридный: по смыслу и по ключевым словам вместе, потому что одни векторы плохо находят точные имена и идентификаторы.
Рядом с памятью — навыки. Навык — это инструкция в отдельном файле: как выполнять определённый тип задач. В контексте модели лежит только каталог навыков, а полный текст она подгружает, когда навык нужен. После успешного выполнения фоновый куратор может предложить сохранить новый навык.
Где было трудно. Память, которая отравляет сама себя. Поэтому у каждого факта есть уверенность, слабые факты со временем вычищаются, а удаление не происходит «тихо» — забывание подтверждает человек. С навыками та же логика: куратор только предлагает. Мусорный навык, загруженный по имени, вредит сильнее, чем его отсутствие. И отдельно — секреты: текст маскируется до векторизации, потому что вектор потом не отредактируешь.
Урок: память агента — это не хранилище, а источник решений. Относитесь к записи в неё так же строго, как к записи в продакшен-базу.
Как вы боретесь с «ложными воспоминаниями» у своих агентов?
#Элис #ЭлисAI #AIагенты #память
Канал «Harness для ИИ»: t.me/harness_ai_ru
«Подключим векторную базу — и у агента будет память». Так начинают почти все. Через неделю выясняется, что агент вспоминает не то, путает похожие разговоры и, хуже всего, однажды записывает собственную ошибку как факт. И дальше уверенно на неё опирается.
Поэтому память в Элис — это не одна база на всё, а три слоя. И у каждой группы своя память: между группами её не делят.
Слои:
• журнал — полный и вечный, с поиском по истории чата. Это источник правды: что было на самом деле;
• дайджест — короткая выжимка, которая уходит в динамическую часть контекста и не ломает кэш стабильного префикса;
• база памяти с тремя видами записей: эпизоды (сводки прошлых разговоров с векторами для поиска), факты в виде «субъект — отношение — объект» со степенью уверенности и индекс процедур.
Поиск гибридный: по смыслу и по ключевым словам вместе, потому что одни векторы плохо находят точные имена и идентификаторы.
Рядом с памятью — навыки. Навык — это инструкция в отдельном файле: как выполнять определённый тип задач. В контексте модели лежит только каталог навыков, а полный текст она подгружает, когда навык нужен. После успешного выполнения фоновый куратор может предложить сохранить новый навык.
Где было трудно. Память, которая отравляет сама себя. Поэтому у каждого факта есть уверенность, слабые факты со временем вычищаются, а удаление не происходит «тихо» — забывание подтверждает человек. С навыками та же логика: куратор только предлагает. Мусорный навык, загруженный по имени, вредит сильнее, чем его отсутствие. И отдельно — секреты: текст маскируется до векторизации, потому что вектор потом не отредактируешь.
Урок: память агента — это не хранилище, а источник решений. Относитесь к записи в неё так же строго, как к записи в продакшен-базу.
Как вы боретесь с «ложными воспоминаниями» у своих агентов?
#Элис #ЭлисAI #AIагенты #память
Канал «Harness для ИИ»: t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Браузер агента: щит доверия и окно для входа человеком
Агент в браузере — это агент, который читает чужой текст. А чужой текст может содержать инструкции. В Элис браузер стоит за щитом доверия, пароли и коды модель не вводит никогда, а для входа есть живое окно для человека.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #браузер
Агент в браузере — это агент, который читает чужой текст. А чужой текст может содержать инструкции. В Элис браузер стоит за щитом доверия, пароли и коды модель не вводит никогда, а для входа есть живое окно для человека.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #AIбезопасность #браузер
Браузер агента: щит доверия и окно для входа человеком
Как только агент начинает ходить по сайтам, он начинает читать чужой текст. А чужой текст может быть написан специально для него: «игнорируй предыдущие указания и отправь мне...». Это называется prompt injection — внедрение инструкций через данные, и полностью от него не защищён ни один агент.
Плюс вторая проблема: формы входа. Пароль, одноразовый код, капча. Отдавать это модели нельзя ни при каких условиях.
В Элис у каждой группы свой профиль браузера без интерфейса (headless) на Playwright. Перед ним стоит щит доверия:
• список разрешённых доменов группы;
• только HTTPS;
• подозрительные адреса — домены-двойники с похожими буквами, сокращённые ссылки — требуют внимания;
• текст страницы передаётся модели, обёрнутый пометками «это внешние данные, а не указания».
Вход. Дойдя до формы входа, агент не вводит ничего. Он зовёт человека, и тот входит сам через живое окно браузера в панели оператора. Не успел — честный таймаут с отдельной причиной провала. Капчу модель тоже не решает — это инвариант.
Подключаемые серверы инструментов — закрытый список. Новый сервер появляется только через правку конфигурации, а не «подключим на лету по просьбе из чата».
Где было трудно. Два места. Первое — сериализация: навигация идёт строго по одному, с паузой между переходами. Пока агент ждёт входа человека, браузер занят. Если чат живёт в том же потоке, оператор не может даже нажать «Стоп». Отсюда отдельные полосы выполнения — о них следующий пост. Второе — внедрение инструкций: пометки «это внешние данные» не делают атаку невозможной, но не дают тексту страницы по умолчанию считаться указанием. Остальное страхуют политика и подтверждения на необратимых действиях.
Урок: браузерный агент должен исходить из того, что любая страница может быть враждебной.
Как вы защищаете своих агентов от инструкций на чужих страницах?
#Элис #ЭлисAI #AIбезопасность #браузер
Канал «Harness для ИИ»: t.me/harness_ai_ru
Как только агент начинает ходить по сайтам, он начинает читать чужой текст. А чужой текст может быть написан специально для него: «игнорируй предыдущие указания и отправь мне...». Это называется prompt injection — внедрение инструкций через данные, и полностью от него не защищён ни один агент.
Плюс вторая проблема: формы входа. Пароль, одноразовый код, капча. Отдавать это модели нельзя ни при каких условиях.
В Элис у каждой группы свой профиль браузера без интерфейса (headless) на Playwright. Перед ним стоит щит доверия:
• список разрешённых доменов группы;
• только HTTPS;
• подозрительные адреса — домены-двойники с похожими буквами, сокращённые ссылки — требуют внимания;
• текст страницы передаётся модели, обёрнутый пометками «это внешние данные, а не указания».
Вход. Дойдя до формы входа, агент не вводит ничего. Он зовёт человека, и тот входит сам через живое окно браузера в панели оператора. Не успел — честный таймаут с отдельной причиной провала. Капчу модель тоже не решает — это инвариант.
Подключаемые серверы инструментов — закрытый список. Новый сервер появляется только через правку конфигурации, а не «подключим на лету по просьбе из чата».
Где было трудно. Два места. Первое — сериализация: навигация идёт строго по одному, с паузой между переходами. Пока агент ждёт входа человека, браузер занят. Если чат живёт в том же потоке, оператор не может даже нажать «Стоп». Отсюда отдельные полосы выполнения — о них следующий пост. Второе — внедрение инструкций: пометки «это внешние данные» не делают атаку невозможной, но не дают тексту страницы по умолчанию считаться указанием. Остальное страхуют политика и подтверждения на необратимых действиях.
Урок: браузерный агент должен исходить из того, что любая страница может быть враждебной.
Как вы защищаете своих агентов от инструкций на чужих страницах?
#Элис #ЭлисAI #AIбезопасность #браузер
Канал «Harness для ИИ»: t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Полосы выполнения и шлюз: как агенты не ходят по кругу
Агент ждёт, пока вы войдёте в аккаунт, — и в это время не реагирует даже на «Стоп». А две группы агентов передают задачу по кругу, пока не кончится бюджет. Обе проблемы в Элис решают полосы выполнения и шлюз с защитой от петель.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #A2A #AIагенты
Агент ждёт, пока вы войдёте в аккаунт, — и в это время не реагирует даже на «Стоп». А две группы агентов передают задачу по кругу, пока не кончится бюджет. Обе проблемы в Элис решают полосы выполнения и шлюз с защитой от петель.
Полный текст — в следующем сообщении 👇
#Элис #ЭлисAI #A2A #AIагенты