Когда я начинал, я думал, что строю «AI-инструмент». В какой-то момент понял, что строю операционную систему для AI-разработки.
Это другая категория продукта. Не «помощник в редакторе», а control plane. Не «быстрее писать код», а управлять процессом.
Вот пять вещей, которые я понял.
Первое: модель — не главное.
Можно взять DeepSeek. Можно локальную модель через Ollama. Можно что угодно. Результат во многом определяется harness’ом. Хороший harness с обычной моделью нередко даёт больше, чем слабый harness с топовой.
Второе: дисциплина важнее скорости.
Быстро писать код без дисциплины — это скорость без направления. Verification Tax съедает всё, что ты сэкономил. Дисциплина — это направление.
Третье: приёмка — самое сложное.
Не оркестрация. Не инфраструктура. А доказать, что результат корректен. Это человеческая задача, а не техническая. HarnessOS её не убирает. Он делает её явной.
Четвёртое: self-hosted — не фича, а принцип.
Не опция. Не «для Enterprise». А основа. Код, память, логи — у тебя. Это не «мы такие хорошие». Это архитектурное решение.
Пятое: я на правильной стороне рынка.
DeepSeek, GitHub и AWS вкладываются в harness’ы и разработку по спецификациям. Сообщество уже склеивает эти инструменты плагинами. Значит, проблема реальная. Готового self-hosted control plane, который собирает спецификации, исполнение, проверки и эскалацию в один процесс, я пока не нашёл. Это моя ниша.
Что дальше
Я не строю «ещё один AI-инструмент». Я строю инфраструктуру для управляемой AI-разработки. Это долгая игра. Но правильная.
Спасибо, что дочитали. Если интересно — подписывайтесь. Буду рассказывать, как продвигается.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Это другая категория продукта. Не «помощник в редакторе», а control plane. Не «быстрее писать код», а управлять процессом.
Вот пять вещей, которые я понял.
Первое: модель — не главное.
Можно взять DeepSeek. Можно локальную модель через Ollama. Можно что угодно. Результат во многом определяется harness’ом. Хороший harness с обычной моделью нередко даёт больше, чем слабый harness с топовой.
Второе: дисциплина важнее скорости.
Быстро писать код без дисциплины — это скорость без направления. Verification Tax съедает всё, что ты сэкономил. Дисциплина — это направление.
Третье: приёмка — самое сложное.
Не оркестрация. Не инфраструктура. А доказать, что результат корректен. Это человеческая задача, а не техническая. HarnessOS её не убирает. Он делает её явной.
Четвёртое: self-hosted — не фича, а принцип.
Не опция. Не «для Enterprise». А основа. Код, память, логи — у тебя. Это не «мы такие хорошие». Это архитектурное решение.
Пятое: я на правильной стороне рынка.
DeepSeek, GitHub и AWS вкладываются в harness’ы и разработку по спецификациям. Сообщество уже склеивает эти инструменты плагинами. Значит, проблема реальная. Готового self-hosted control plane, который собирает спецификации, исполнение, проверки и эскалацию в один процесс, я пока не нашёл. Это моя ниша.
Что дальше
Я не строю «ещё один AI-инструмент». Я строю инфраструктуру для управляемой AI-разработки. Это долгая игра. Но правильная.
Спасибо, что дочитали. Если интересно — подписывайтесь. Буду рассказывать, как продвигается.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
ConversationRunner собирает прогон: группа, клиент модели, реестр инструментов, бюджет, политика. Держит лимиты ходов, бюджет, прерывания, сжатие. После успеха фоном предлагает сохранить навык. Есть fixture-режим без живой модели — для дымовых тестов.
AgentLoop — один ход: стабильный системный текст + история + динамический хвост, вызов DeepSeek, затем ответ или инструменты. Прогресс и статус отделены от финального ответа.
Раннер субагента. Агент из файла в agents/ вызывается как инструмент, пишет в журнал родителя, а его бюджет не больше остатка бюджета родителя.
Раннер eval — гоняет сценарии качества.
Ключевая трудность (инженерная): reasoning round-trip и целостность пар. DeepSeek требует, чтобы рассуждения модели гонялись туда-обратно в истории. И цепочка «вызов ↔ результат» должна быть целой до следующего HTTP-запроса: у каждого вызова — ровно один результат с нужным идентификатором. Если пара порвана, это нарушение протокола и стоп, а не «как-нибудь продолжим». Отсюда правило: отказ политики, таймаут и прерывание — тоже полноценные результаты. И при сжатии истории нельзя разрезать пару посередине.
Дальше — кэш промпта и почему в префиксе нельзя писать время.
#HarnessOS #Элис #DeepSeek #LLM
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
AgentLoop — один ход: стабильный системный текст + история + динамический хвост, вызов DeepSeek, затем ответ или инструменты. Прогресс и статус отделены от финального ответа.
Раннер субагента. Агент из файла в agents/ вызывается как инструмент, пишет в журнал родителя, а его бюджет не больше остатка бюджета родителя.
Раннер eval — гоняет сценарии качества.
Ключевая трудность (инженерная): reasoning round-trip и целостность пар. DeepSeek требует, чтобы рассуждения модели гонялись туда-обратно в истории. И цепочка «вызов ↔ результат» должна быть целой до следующего HTTP-запроса: у каждого вызова — ровно один результат с нужным идентификатором. Если пара порвана, это нарушение протокола и стоп, а не «как-нибудь продолжим». Отсюда правило: отказ политики, таймаут и прерывание — тоже полноценные результаты. И при сжатии истории нельзя разрезать пару посередине.
Дальше — кэш промпта и почему в префиксе нельзя писать время.
#HarnessOS #Элис #DeepSeek #LLM
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Стабильный префикс и динамический хвост
Стабильный префикс в Элис — это одинаковые байты между вызовами внутри группы. Всё изменчивое уходит в динамический хвост — отдельное system-сообщение после истории. Это не эстетика, а деньги и скорость: префикс попадает в кэш провайдера.
Почему одна строка с текущим временем обнуляет кэш.
Полный текст — в следующем сообщении 👇
Стабильный префикс в Элис — это одинаковые байты между вызовами внутри группы. Всё изменчивое уходит в динамический хвост — отдельное system-сообщение после истории. Это не эстетика, а деньги и скорость: префикс попадает в кэш провайдера.
Почему одна строка с текущим временем обнуляет кэш.
Полный текст — в следующем сообщении 👇
В стабильном префиксе:
• кто ты;
• инварианты: не выводи секреты, не обходи тюрьму путей, не вводи пароли, не решай CAPTCHA;
• контракт общения;
• каталог навыков (только каталог, не тела);
• правила доверия к браузеру;
• типы задач.
В динамическом хвосте: время, бюджет, дайджест памяти, роль, шаг.
Защита. При изменении префикса меняется его версия, а в CI стоит хэш-гард: случайная правка не пройдёт незамеченной. В рантайме работает сторож кэша: если доля попаданий низкая несколько раз подряд — предупреждение, потом стоп «кэш развалился».
Ключевая трудность (инженерная): невидимые изменения префикса. Типичные убийцы кэша — «сейчас», бюджет или session id в начале запроса, нестабильный порядок инструментов и полей в JSON-схеме, «маленькая правка» формулировки. Ошибкой это не выглядит — просто растёт счёт. Поэтому кэш — это контракт с хэш-гардом и сторожем, а не надежда. Сжатие истории тоже меняет запрос, поэтому оно редкое: раз в N ходов.
Дальше — контракт общения и классификатор задач.
#HarnessOS #Элис #LLM #promptcaching
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
• кто ты;
• инварианты: не выводи секреты, не обходи тюрьму путей, не вводи пароли, не решай CAPTCHA;
• контракт общения;
• каталог навыков (только каталог, не тела);
• правила доверия к браузеру;
• типы задач.
В динамическом хвосте: время, бюджет, дайджест памяти, роль, шаг.
Защита. При изменении префикса меняется его версия, а в CI стоит хэш-гард: случайная правка не пройдёт незамеченной. В рантайме работает сторож кэша: если доля попаданий низкая несколько раз подряд — предупреждение, потом стоп «кэш развалился».
Ключевая трудность (инженерная): невидимые изменения префикса. Типичные убийцы кэша — «сейчас», бюджет или session id в начале запроса, нестабильный порядок инструментов и полей в JSON-схеме, «маленькая правка» формулировки. Ошибкой это не выглядит — просто растёт счёт. Поэтому кэш — это контракт с хэш-гардом и сторожем, а не надежда. Сжатие истории тоже меняет запрос, поэтому оно редкое: раз в N ходов.
Дальше — контракт общения и классификатор задач.
#HarnessOS #Элис #LLM #promptcaching
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Внешний вызов прошёл, а запись — нет
Сверяться с внешней системой или ждать оператора, если вызов прошёл, а запись — нет? Коротко: политику выбирают по тому, что можно повторить без последствий.
Разбор — в следующем сообщении 👇
#Элис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 от Алексея Пасечника.