Выход из миража прототипов: почему развитие корпоративной искусственной интеллекта застопорилось.

Слишком много прототипов, слишком мало готовых продуктов.

Делиться

Данная статья написана в соавторстве с Реей Вир и Рахулом Виром.

В эпоху GenAI разработка программного обеспечения претерпела коренные изменения. Благодаря повсеместному распространению инструментов для создания кода на основе Vibe и IDE, ориентированных на агентов, таких как Antigravity от Google, разработка новых приложений стала как никогда быстрой. Кроме того, мощные концепции, вдохновленные популярными фреймворками с открытым исходным кодом, такими как OpenClaw, позволяют создавать автономные системы. Мы можем помещать агентов в защищенные «гарнитуры» , предоставлять им исполняемые навыки Python и определять их системные персоны в простых файлах Markdown. Мы используем рекурсивный агентный цикл (наблюдение-мышление-действие) для выполнения, настраиваем безголовые шлюзы для их подключения через чат-приложения и полагаемся на Molt State для сохранения памяти после перезагрузки, поскольку агенты самосовершенствуются. Мы даже предоставляем им токен «без ответа» , чтобы они могли молчать вместо своей обычной разговорчивости.

Создание автономных агентов всегда было очень простым делом. Но остается вопрос: если сегодня разработка настолько проста, почему предприятия видят такой наплыв прототипов, и лишь удивительно малая их часть превращается в реальные продукты?

1. Иллюзия успеха:

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

В значительной степени это связано с внезапным ростом популярности Vibe Coding, в котором приоритет отдается быстрой экспериментальной разработке, а не тщательному проектированию. Эти инструменты отлично подходят для создания демо-версий, но без структурной дисциплины полученный код не обладает необходимыми возможностями и надежностью для создания продукта производственного уровня [Почему Vibe Coding терпит неудачу]. Как только инженеры возвращаются к своей основной работе, прототип забрасывается и начинает разрушаться, подобно неподдерживаемому программному обеспечению.

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

Пример из сферы здравоохранения : Допустим, у нас есть агент по приему пациентов, предназначенный для сортировки пациентов, проверки страхового полиса и записи на прием. В демонстрационном примере, созданном с помощью Vibe Code, он отлично справляется со стандартными осмотрами. Используя шлюз , он общается с пациентами посредством текстовых сообщений. Он использует базовые навыки для доступа к API страховых компаний, а его системный образ задает вежливый, клинический тон. Но в реальной клинике среда является хаотичной и неорганизованной. Если пациент упоминает о боли в груди в середине обычного приема, цикл обработки информации агента должен мгновенно распознать срочность, прервать процесс записи на прием и запустить эскалацию по вопросам безопасности. Он должен использовать токен No-Reply для подавления чата записи на прием, перенаправляя контекст к медсестре. Большинство прототипов с треском проваливают этот тест.

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

2. Определение прототипа «Мираж»

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

К основным симптомам относятся:

• Неизвестная надежность : Большинство агентов не соответствуют строгим требованиям соглашений об уровне обслуживания (SLA), предъявляемым к корпоративным системам. Поскольку ошибки в одно- или многоагентных системах накапливаются с каждым действием (так называемый стохастический распад), разработчики ограничивают их возможности. Пример: Если агент приема пациентов полагается на общий реестр состояний для координации между «суб-агентом планирования» и «суб-агентом страхования», то сбой на 12-м шаге 15-шагового процесса проверки страхования нарушает весь рабочий процесс. Недавнее исследование показывает, что 68% агентов в производственной среде намеренно ограничены 10 шагами или меньше, чтобы предотвратить сбои.
• Хрупкость оценки : Надежность остается неизвестной переменной, поскольку 74% агентов полагаются на оценку с участием человека (HITL). Хотя это разумная отправная точка, учитывая использование агентов в этих узкоспециализированных областях, где общедоступных эталонов недостаточно, такой подход не масштабируем и не поддерживается. Переход к структурированным оценкам и использованию LLM в качестве судьи — единственный устойчивый путь вперед (Pan et al., 2025).
• Изменение контекста : Агенты часто создаются для фиксации устаревших рабочих процессов, выполняемых людьми. Однако бизнес-процессы естественным образом меняются. Пример: если больница обновляет принятые уровни Medicaid, агенту не хватает цикла самоанализа или метакогнитивного цикла для анализа собственных ошибок и адаптации. Его жесткие цепочки подсказок разрываются, как только среда отклоняется от контекста обучения, что делает агента устаревшим.

3. Согласование с корпоративными OKR.

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

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

OKR (цели и ключевые результаты) обеспечивают более четкую цель (например, сократить критически важное время ожидания пациентов на 20%), чем промежуточный показатель (например, обрабатывать 50 анкет в час). Понимая OKR, наш специалист по приему пациентов может заблаговременно выявлять сигналы, противоречащие целевому показателю времени ожидания пациентов, и устранять их с минимальным участием человека.

Недавние исследования Центра управления и маркетинга Беркли рассматривают это в рамках теории принципала-агента. «Принципал» — это заинтересованная сторона, ответственная за OKR (цели и ключевые результаты). Успех зависит от делегирования полномочий агенту таким образом, чтобы согласовать стимулы и гарантировать, что он будет действовать в интересах принципала даже в условиях отсутствия контроля.

Однако автономию нужно заслужить, а не получить в первый же день. Успех достигается по модели управляемой автономии:

• Известные факты : Начните с проверенных сценариев использования со строгими ограничениями (например, агент занимается только плановыми медицинскими осмотрами и базовой проверкой страховых полисов).
• Эскалация : Агент распознает крайние случаи (например, противоречивые симптомы) и передает информацию медсестрам, проводящим первичный осмотр, вместо того, чтобы гадать.
• Эволюция : По мере того, как агент получает более полную информацию о происхождении данных и демонстрирует соответствие целям и ключевым результатам, ему предоставляется больше полномочий (например, обработка направлений к специалистам).

4. Дальнейшие шаги

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

Чтобы избавиться от этой иллюзии и добиться реального успеха, мы должны обеспечить согласованность продукта и инженерную дисциплину при разработке этих агентов. Мы должны создать системы для борьбы со специфическими проблемами, с которыми сталкиваются эти модели, например, с теми, которые описаны в 9 критических моделях отказов.

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

• Надежность : переход от «визуальных ощущений» к эталонным наборам данных и использованию LLM в качестве эксперта (чтобы наш агент по приему пациентов мог непрерывно тестироваться на тысячах смоделированных сложных историй болезни пациентов).
• Экономика : освоение токеномики для оптимизации затрат на рабочие процессы агентов.
• Безопасность : Внедрение агентной безопасности посредством отслеживания происхождения данных и контроля потоков.
• Производительность : Достижение высокой производительности агентов в масштабе предприятия для повышения эффективности работы.

Переход от «прототипа» к «внедрению» — это не исправление ошибок, а создание принципиально лучшей архитектуры .

Ссылки

1. Вир, Р., Ма Дж., Сахни Р., Чилтон Л., Ву, Э., Ю З., Columbia DAPLab. (2026, 7 января). Почему кодирование Vibe дает сбои и как это исправить. Лаборатория данных, агентов и процессов, Колумбийский университет. https://daplab.cs.columbia.edu/general/2026/01/07/why-vibe-coding-fails-and-how-to-fix-it.html
2. Пан, М.З., Арабзаде, Н., Кого, Р., Чжу, Ю., Сюн, А., Агравал, Л.А.,… и Эллис, М. (2025). Измерители на производстве. arXiv. https://arxiv.org/abs/2512.04123
3. Джаррахи, М.Х., и Ритала, П. (2025, 23 июля). Переосмысление агентов ИИ: перспектива принципала-агента. Berkeley California Management Review. https://cmr.berkeley.edu/2025/07/rethinking-ai-agents-a-principal-agent-perspective/
4. Вир, Р., Лаборатория данных, агентов и процессов Колумбийского университета. (2026, 8 января). 9 критических моделей отказов кодирующих агентов. Лаборатория данных, агентов и процессов, Колумбийский университет. https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html

Все изображения созданы программой Nano Banana 2.

Рейя Вир Посмотреть все Рейя Вир

Источник: towardsdatascience.com