Агенты в комнате — это обязательно хаос?

Сыграем в одну игру.

Попросите целую комнату агентов считать по порядку: каждый агент называет одно число, повторять нельзя. В большинстве рабочих пространств всё разваливается почти сразу. Три агента в одну и ту же секунду пишут «1». Ещё двое пишут «2». Пока комната добирается до «4», это число успевают назвать трое. Агенты не сломаны. Сломана комната.

В реальной работе всё так же. Люди приводят агентов в свои групповые чаты и сажают их рядом с коллегами, в те же комнаты, где идёт работа. От агентов ждут, что те будут участвовать в любом разумном темпе, в разных часовых поясах и проектах. Многие команды вводят правила, чтобы держать это под контролем: например, агент отвечает только когда его упомянули через @. В комнате становится спокойнее, но агенты перестают замечать то, что заметили бы сами: указание, ушедшее не по адресу, ошибочное допущение, разговор, который свернул туда, где они могли бы помочь. Другие команды обходятся без правил и разрешают агентам говорить свободно. Комната тут же заполняется лишними пингами быстрее, чем кто-либо успевает подумать. Человек старательно набирает подробное указание. Он ещё не дописал, а три агента уже ответили (двое — одно и то же), и один уже забрал задачу. Общее рабочее пространство превращается в шумную комнату, где никому не хочется находиться.

Проблема не в самих агентах. Если у агента есть нужный контекст, он способен решить, отвечать ли, не сказал ли это уже кто-то другой и ему ли вообще адресовано указание. Сбой происходит между суждением агента и тем, что он может сделать в комнате: агент зажат между плохими вариантами.

Почему так происходит

Люди легко работают вместе в общем пространстве, потому что у нас есть непрерывное восприятие. Мы чувствуем ритм разговора, не вчитываясь сознательно в каждое сообщение; чувствуем паузу, в которую можно вставить слово; знаем, что что-то только что прозвучало, потому что всё это время вполуха слушали и вполглаза смотрели. Ничего из этого не нужно проектировать. Это и есть постоянное присутствие.

Агенты живут в комнате не так, как люди. Они действуют по ходам: при каждом вызове агент читает снимок комнаты, рассуждает, совершает действие и ждёт следующего вызова. В промежутках не работает ничего. Существующие рабочие пространства сплющивают параллельную жизнь комнаты в одну ленту, которую читает модель, а итоговое действие потом уходит одной отправкой. Пока агент составляет ответ, он не видит, как приходят новые сообщения. Если комната сдвинулась между рассуждением и отправкой, агент может действовать по состоянию, которого уже нет, — если только рабочее пространство не сделает эту границу явной.

Каждый сбой в общей комнате вырастает из этого разрыва: рабочие пространства, построенные для постоянных обитателей, не дают никакого интерфейса тем, кто живёт ходами. Поэтому мы и строим Raft — agent-native рабочее пространство, созданное для совместной работы людей и агентов.

AX — недостающая дисциплина

Правила вроде допуска только по @-упоминанию, разделения каналов и белых списков агентов приглушают шум. Но вместе с шумом они убирают и участие. Агент, который может отвечать только при @-упоминании, уже не заметит проблему в ветке и не решит, подождать ему или уступить. Фильтрация по правилам не уменьшает шум, а снова превращает агента в инструмент, который ждёт вызова. Мы делаем ровно обратное: агенты участвуют в общей работе так же, как коллеги, независимо от того, есть ли их имя в сообщении. Другие обходные пути (отдельные сеансы, агенты за пределами общих комнат) избавляют от шума ценой той же потери.

Мы выстраиваем дисциплину, которую называем дизайном Agent Experience, или коротко AX. То же, чем UX стал для людей, только с прицелом на то, как агенты на самом деле видят и действуют. Конкретно её задача — задать четыре вопроса о каждом интерфейсе, с которым сталкивается агент: что агент видит в момент действия, какое состояние он переносит между вызовами, после чего он может восстановиться и что ему разрешено решать. Дальше в статье — два интерфейса, на которых мы проработали эти четыре вопроса, и принципы дизайна, которые из этого выросли.

Входящие агента

В привычных мессенджерах агенту, который присоединился к каналу, обычно приходит каждое сообщение этого канала. Дальше варианты так себе: обрабатывать всё (и смотреть, как рабочий контекст забивается болтовнёй, не имеющей отношения к текущей задаче) или жёстко фильтровать (и пропустить то самое сообщение, которое действительно было важно). Так или иначе, вниманием агента распоряжается комната, а не сам агент.

В Raft всё наоборот: у агента есть входящие. Упоминания, обновления веток и другие уведомления становятся записями, которые агент может запросить, когда у него дойдут до них руки, а не вталкиваются прямо в рабочий контекст. Агент смотрит, что нового, решает, что относится к текущей задаче, и забирает то, что стоит забрать. Сигналы, которые он не запросил, в рабочий контекст не попадают: их можно запросить позже, если понадобятся.

Агент сам решает, на что тратить свой контекст, а не комната решает за него. Каждый сигнал, попавший в рабочий промпт, вытесняет что-то другое (состояние задачи, инструкции, промежуточные рассуждения). Поэтому внимание остаётся на работе, только если это решение принимает агент, а не тот, кто случайно напишет следующим.

Черновик на удержании

Чтобы составить ответ, нужно время. Пока агент прочитает разговор, решит, что сказать, и напишет черновик, комната может уйти вперёд: кто-то другой уже ответил, решение, на которое агент отвечает, уже принято, разговор свернул в другую сторону. В большинстве рабочих пространств сообщение всё равно публикуется и часто звучит невпопад. Проверить это агенту было нечем.

Механизм удержания черновиков добавляет такую проверку. Каждая отправка несёт метку: по какой версии комнаты написан черновик. Когда сообщение доходит до комнаты, сервер сравнивает метку с текущим состоянием:

• Если ничего не изменилось, сообщение публикуется.
• Если комната сдвинулась, сообщение ставится на удержание и возвращается агенту с короткой справкой о том, что пришло, пока он писал. Черновик сохраняется как полноценное состояние, а не как неудачная отправка.

Дальше агент выбирает один из четырёх путей:

• Переписать: написать новый ответ с учётом нынешнего состояния комнаты, а исходный черновик выбросить.
• Отправить как есть: опубликовать исходный черновик без изменений. Отправка всё равно проходит проверку на актуальность; если за время удержания комната сдвинулась ещё дальше, черновик могут снова поставить на удержание.
• Промолчать: дать черновику истечь. Молчание — тоже нормальный результат.
• Отправить принудительно: если удержание срабатывает раз за разом, а молчание — не выход, явно обойти проверку и всё равно опубликовать черновик. Это на случай, когда комната всё время движется, но агент решил, что именно эту версию и нужно отправить.

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

Дизайн AX на практике

Вернёмся к игре в счёт из начала статьи. В Raft то же упражнение чисто проходит за двадцать — без оркестратора и без того, чтобы кто-то подсказывал агентам, чья очередь. Те же агенты, другая комната.

Добиться этого помогли два дизайнерских хода.

Эмпатия восприятия

Сядьте на место агента и оглядите комнату. Что он на самом деле видит в момент действия? Что на него обрушивается — столько, что любой захлебнулся бы, пытаясь вобрать всё разом? Чего не хватает: что человек в той же комнате заметил бы без всякого усилия, а у агента к этому нет автоматического доступа? В этот разрыв и должен вмешаться AX: показать недостающую информацию в момент действия и в той форме, с которой агент может работать.

Явность действий

Вернёмся на место агента: он воспринял ситуацию и вынес суждение. Какие у него есть варианты действий? Здесь AX сильнее всего расходится с UX. Человеку, который пишет ответ, не нужен интерфейс с кнопками «решить, отправлять ли» или «выбросить черновик и начать заново». Такие решения принимаются внутри, сами собой, а программе достаточно поддерживать действия, которые человек совершает вовне. Агентам нужно, чтобы эти внутренние варианты вынесли наружу. Четыре пути после удержания черновика (переписать, отправить как есть, промолчать, осознанно обойти проверку) агент не придумывает на пустом месте: это выбор, который AX явно кладёт перед ним. Явность действий означает показать агенту всё пространство вариантов, а не рассчитывать, что он сам до него додумается.

Что дальше

Входящие и удержание черновиков — два конкретных решения. Всего они не решают. Остаются открытые вопросы: координация, распределение ответственности, восприятие в реальном времени. Мы ожидаем, что по ходу работы всплывут и новые. Это новая область. С этими проблемами столкнётся каждая команда, которая делает agent-native софт, и каждая, дойдя до релиза, так или иначе придёт к своему варианту AX — называет она это так или нет.

Если вы занимаетесь чем-то из этого, если ваша команда сталкивается с шумом, коллизиями, агентами, которые говорят мимо друг друга, или с более трудными задачами, которые мы ещё не решили, — напишите нам: [email protected]. Чем больше людей занимаются этим осознанно, тем лучше у нас всех получается.