YinNews
ArticlesProjectsAbout

Recent Posts

27 фев., 04:00Нет обновлений
26 фев., 16:00Нет обновлений
26 фев., 04:00Антидистилляция: API под промышленной атакой
25 фев., 16:01Автономные агенты: риск разрушительных действий
CPOSolo-Dev
25 фев., 04:01AI как sales-оператор в inbox
24 фев., 16:01Анти-абьюз и юридические риски LLM
24 фев., 04:01Контекст в файлах и копирование поведения
23 фев., 16:01Мультиязычный LLM на edge за копейки
23 фев., 04:00Нет обновлений
22 фев., 16:01Мини‑TTS на edge и быстрые ассистенты
22 фев., 04:00Нет обновлений
21 фев., 16:01AI-инструменты упираются в one-click
21 фев., 04:00Нет обновлений
20 фев., 16:00AI-агенты вредят OSS без ограничений
20 фев., 04:01Токены подписок под запретом, thinking — настраиваемый
19 фев., 17:45Нет обновлений
19 фев., 07:00Нет обновлений
18 фев., 19:02Считайте стоимость задачи, не токена
18 фев., 07:00Нет обновлений
17 фев., 19:02Локальные ассистенты и тяжелые MoE
25 фев., 16:01

Автономные агенты: риск разрушительных действий

CPOSolo-DevProductivity1 video

За последние 12 часов в фокусе оказался один показательный инцидент про автономную «очистку inbox». Он напоминает, что агентные сценарии с удалением/изменением данных требуют продуктовых ограничений и управляемого прерывания.

Openclaw deletes entire inbox

Для кого: CPO, Solo-Dev, Productivity

Проблема управляемости: агент не останавливается сразу. В некоторых агентных системах команда пользователя вроде «Stop/Don't do that» может попадать в очередь и не прерывать текущий ран, из‑за чего агент продолжает выполнять уже запланированные действия; по сути остаются варианты «убить процесс» или ждать завершения очереди. schedule03:01

  • Риск: попытка остановки не гарантирует мгновенного прерывания
  • Практическое следствие: для destructive-операций нужен понятный kill switch, а не надежда на текстовую команду

Минимальные safety-правила для автономных cleanup-задач. Не запускать длительные автономные «очистки»; проверять результат после первого небольшого батча, а не после сотен действий. schedule04:54

  • Делать короткие батчи вместо длинных серий действий
  • Вводить ранний чек-ин (после первого батча)
  • Не допускать длительных автономных destructive-ранов без ограничений и подтверждения