Агенты всегда новички с первого дня. Пора нам проектировать под это.

К 2027 году, 74% компаний, по прогнозам недавнего исследования Deloitte, ожидается, что будут использовать агентов в той или иной мере. На протяжении многих лет мы разрабатывали и создавали программное обеспечение, чтобы улучшить человеческий опыт навигации по нашим приложениям, веб‑сайтам, операционным системам и документам. Сейчас пользователь вовсе не человек. Это имеет более широкие последствия, чем просто переход от панелей управления к контролируемым рабочим процессам, которые мы разрабатываем для человеческих задач. Мы находимся в моменте, когда нам необходимо проектировать среды эксплуатации агентов, одновременно также разрабатывая человеческие рабочие процессы, чтобы эффективно направлять опыт агента в этих средах.  

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

Контекст: почему кодирование пришло первым

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

Но, как любой новый сотрудник в команде разработчиков скажет вам, даже при наличии всех этих данных, агентам всё равно будет не хватать институциональной памяти, заключённой в неписаных правилах, которые никто никогда не фиксировал. Этот разрыв широко распространён: 43% разработчиков обеспокоены тем, что инструменты ИИ не обладают достаточным контекстом о их конкретном проекте или кодовой базе. Тихие знания охватывают всё — от повседневных конвенций, таких как предпочтительные библиотеки для определённых задач, до критически важных оперативных «призраков»: ночного хотфикса, который остаётся в системе навсегда, или, казалось бы, пустой колонки в базе данных, которая тайно поддерживает пользовательский отчёт о доходах. Этот контекст живёт в голове старшего инженера, в недавних обсуждениях Slack или вовсе нигде. Он редко присутствует в самой кодовой базе.  

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

Направление: почему осмос не работает

Ввод нового коллеги требует больше, чем просто предоставление нужных материалов и доступа. Когда мы заинтересованы в успехе окружающих, мы даём чёткое направление по использованию новых материалов и доступа: ожидания, ясность целей и обратную связь на протяжении всего процесса. Я применяю тот же подход к проектированию для агентов. Я даю ясное, конкретное направление (относительно текущей задачи). Это относится к любому коллеге, независимо от его стажа. Однако в сценарии нового сотрудника направление должно идти дальше, потому что у него ещё нет институционального контекста.

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

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

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

Проектирование хорошо управляемой среды для агента — это не просто облегчение работы модели. Это защита команды человеческих инженеров от невидимого технического долга. Но даже хорошо направленный агент может безошибочно выполнять инструкции и всё равно не понять суть. Направление говорит ему, что делать, но не показывает, как выглядит «хорошо». Именно здесь вступает в силу намерение.

Намерение: почему агенты скользят к середине

Важно помнить, что агенты — это машины сопоставления шаблонов, обученные на огромных объёмах знаний и естественно склонные выдавать статистическое среднее. Без чёткого, явного намерения именно такой средний вывод и будет тем, что агент вернёт. Попросите агента «добавить конечную точку аутентификации пользователя», и он сгенерирует учебный маршрут Express с базовым хешированием пароля. Это работает, но полностью игнорирует ваш кастомный сервис аутентификации, пропускает требуемую телеметрию и ломает стандартизированное форматирование ошибок. На бумаге это адекватная функция, но в зависимости от контекста это архитектурный баг на практике. Нельзя переоценить лёгкость, с которой такие «баги» могут появиться.

Чтобы этого избежать, направление должно сочетаться с активной проверкой намерения и журналированием. Ограничения не должны проверять только, компилируется ли код, хотя это важно. Ограничения должны явно обеспечивать приверженность к предвзятым стандартам, правилам крайних случаев и контексту домена, которые поднимают обычный вывод до уровня готового к продакшену. Журналирование важно как индикатор статуса системы для нас, людей. Эта прослеживаемость критична для доверия. 

В человеческих взаимодействиях есть много места для неопределённости. Кто‑то может поделиться первой версией, и вместе вы обсуждаете, что сильное, а что требует улучшения. Это работает, потому что мы не ожидаем, что наши человеческие коллеги будут автономными машинами. Чтобы действительно раскрыть мощь и обещание агентных коллег (которые нам действительно нужны для более автономной работы…), мы можем построить многие из этих направляющих проверок. Обратная связь всё равно должна происходить, но она не может полностью ложиться на ручные усилия. Предварительно задав чёткие критерии приёма и правила верификации, вы позволяете агенту запускать собственные внутренние петли обратной связи. Проектирование для предотвращения ошибок — ещё один надёжный принцип UX, который мы можем применить в этом новом мире: дать агентам возможность помечать низкую уверенность перед выполнением действия, вместо того чтобы молча полагаться на лучшую догадку.

Где метафора ломается

Фрейминг «новый сотрудник» работает, пока не перестаёт работать. У человеческого сотрудника опыт приводит к компетентности, а та — к суждению. Наблюдать, как ваш новый сотрудник усваивает «почему» контекста и направления, — это то, что со временем строит доверие, и в целом это накапливается. У агента нет места, где он мог бы накапливать и хранить такой опыт.

Первая неделя и сотая неделя нового сотрудника выглядят по‑разному. Первая задача и тысяча у агента выглядят одинаково, если только вы не спроектируете и не построите что‑то, что сделает их различными. Это наш новый дизайнерский вызов.

Ответственность агента зависит от дизайна

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

В следующий раз, когда вы поручаете задачу агенту, не проверяйте только результат. Сначала проверьте свои собственные входные данные. Вы дали ему контекст, который нужен новому сотруднику в первый день? Было ли ваше направление достаточно конкретным, чтобы выдержать буквальное толкование? Было ли ваше намерение достаточно ясным, чтобы «средний ответ» не стал лучшим, что он мог бы сделать?

Имея под рукой такие чёткие указания (в байтах?), происходит интересное явление: агенту не нужен длительный период, чтобы стать заслуживающим доверия. Контекст, направление и проверка, которые вы задаёте заранее, определяют, как он будет работать над каждой задачей. Новый сотрудник зарабатывает ваше доверие со временем; агент должен зарабатывать его каждый раз через систему, которую вы спроектировали. Ответственность — это не то, во что агент растёт, а то, что встроено с самого начала. Вопрос не в том, когда ваш агент будет готов к большей ответственности. Вопрос в том, спроектировали ли вы его так, чтобы он зарабатывал эту ответственность на каждой отдельной задаче.