Александр Степанов

Буквальность работает и в обратную сторону: два правила, написанные в разное время, агент выполнит оба, а противоречие между ними не подсветит. Такие файлы приходится не только пополнять, но и чистить.
Как понять, что правило вообще влияет? В коде это видно по тестам, у UX-контекста проверять нечем. На Habr на этой неделе был разбор про harness engineering: правило прогоняют на артефакте, который ему соответствует, и на нарушающем. Если проходят оба, правило декоративное и на вывод не влияет.

Согласен. Отзыв между задачами закрывает только простой случай. Пока выданный токен не истёк, он валиден, а значит, проверять отзыв должен исполнитель действия, а не только тот, кто этот токен выписал. У 1Password это частично решено: короткий токен на каждый запрос, refresh-токенов агенту не выдают. Но десять минут жизни токена всё равно остаются рабочими.

Чтение и покупка две разные вещи, которые нельзя смешивать. То, что агент вычитал из каталога (цену, наличие), ещё не сделка, а витрина для него. Фид не может быть всегда идеально свежим. Защита в том, что покупка идёт через отдельный транзакционный шаг, который в момент подтверждения заново проверяет цену и остаток и резервирует товар. Если не сошлось, коммит не проходит, и агент получает ошибку: нет в наличии, цена изменилась, вот актуальная.
На это и заточены протоколы агентской коммерции: продавец остаётся merchant of record и валидирует на своей стороне, а агенту отдают короткоживущее предложение, которое он обязан предъявить при оплате. Плюс идемпотентность, чтобы повторный вызов не купил дважды. Магазин, который считает фид истиной, проиграет. Тот, у кого истина живёт в подтверждении на его стороне, а фид лишь discovery, защищён.

Если смотреть не со стороны того, кто запускает агента, а со стороны сервиса, к которому он приходит, — деления другие. Важно не «диалоговый он или агентный», а четыре простые вещи: пустят ли его внутрь или капча на каждом шагу; найдёт ли свежие цену и наличие или они живут только в баннере на главной; сможет ли вызвать вашу функцию напрямую, а не тыкать в кнопки наугад; и чисто ли передаст дело человеку, когда упрётся. Любой из этих типов спотыкается ровно об это. Класс агента вторичен — первична готовность сервиса его принять.

Хорошая подборка. Добавлю, где на практике проходит граница между «работает» и «обещает»: не в демке, а в момент, когда агент упёрся. Капча посреди оформления, нужен живой человек, десяток запросов в секунду приняли за атаку — и привет. Те, кто «реально работает», отличаются обычно не моделью, а тем, что у них продумана передача управления — от агента к человеку и обратно. Это самая скучная часть, поэтому её чаще всего и нет. Демки красят витрину, а живёт сервис на этих стыках. Я сам тестил Claude Cowork через сырой Chrome MCP для кастомных настроек внутри админ.панели Vercel, не сказать, что получилось быстрее, потому что по каждой запятой Клод возвращался ко мне с вопросом. Но справедливости ради, я изначально так и запланировал, побоявшись, что автономно он там накуролесит так, что я не откачусь уже.

Если Chrome Auto Browse сам ходит по сайтам и сам оформляет — по чьим сайтам? По нашим. И вопрос не в том, что «чат-боты официально мертвы», а в том, что агент видит, когда доходит до условной карточки товара. Человек интуитивно разберётся на глаз, агент — нет: он исполняет буквально. Нет машиночитаемой цены и наличия — для него их просто нет, и он молча уходит к соседу. Так что автономия — не конец чат-ботов. Это момент, когда у продукта появился пользователь, который читает не интерфейс, а голую структуру. И многие к этому просто не готовы.