Перейти к основному содержимому

Разрыв в использовании в 8,3 раза — это проблема интеграции, а не внедрения

Лицензии измеряют закупку; использование измеряет интеграцию. Разрыв между ними структурный, и он живёт в поверхности инструментов между агентом и системами учёта.

Крупный план серверной стойки с патч-кабелями, маркировкой портов и индикаторами на сетевом оборудовании.

Разрыв — это артефакт измерения, а уже потом провал

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

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

Дашборды внедрения измеряют не то событие

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

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

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

Разрыв стабилен по отраслям, а это указывает на структуру

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

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

Это согласуется с более широким наблюдением, что возможности агента и его полезность резко расходятся, как только в дело вступают реальные системы, — мысль, неоднократно высказанная в практических обсуждениях экономики развёртывания агентов, например в материалах, собранных на https://quasa.io.

Где на самом деле умирают сессии

Abstract geometric shapes on glass panels of a contemporary building facade

Схемы инструментов, повторяющие внутренние API

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

Затем модель просят реконструировать бизнес-логику по именам конечных точек. Иногда это удаётся. Когда не удаётся, сбой приписывают рассуждению, но фактическая причина в том, что предусловие для второго вызова нигде не было выражено в машиночитаемой форме.

Отсутствие идемпотентности

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

Это дефект сантехники, а не дефект модели. Он также невидим в оценках, проводимых против песочниц, которые никогда не выдают таймаут.

Пути записи, закрытые непредставимыми согласованиями

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

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

Проектирование для второй недели

Первая неделя любого развёртывания агента проходит под знаком новизны и самых простых задач. Вторая неделя — это когда поверхность интеграции решает исход. Три практики меняMacro close-up of dusty keyboard keys, focus on the letter F

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

Публикуйте типизированную поверхность инструментов с явными контрактами

Определение инструмента должно указывать его предусловия, его побочные эффекты и его режимы отказа в форме, которую модель может потребить, а рецензент — проверить. Конкретно, инструмент записи должен объявлять:

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

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

Дайте записям состояние предложения

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

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

Что перестать делать

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

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

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

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

ПоделитьсяXLinkedInПостоянная ссылка6 мин чтения

Связанное чтение

На какие вопросы это отвечает

Why does agent usage lag behind licence counts?

Licences are counted at a procurement event; usage accumulates at an integration event. A session that opens, attempts a tool call and fails still counts as active on most dashboards, so the shortfall appears only when you count sessions by terminal state rather than by activity.

What is the single most useful metric for agent adoption?

The failure rate of the first tool call per session. It is the earliest point at which the integration surface can reject the agent, it correlates strongly with whether the session continues, and it aggregates by tool rather than by user, which points directly at the fix.

Why is missing idempotency a problem for agents?

Without an idempotency key, a timeout leaves the caller unable to tell a failed call from a succeeded call whose response was lost. Operators disable retries to stay safe, and the agent stalls on the first transient error because stopping is its only safe action.

What is a proposal state for write operations?

A two-phase write in which the agent emits a typed, signed object describing the intended transition, evidence and expiry; a policy engine or human approves it; and a separate idempotent executor applies it. It gives agent intent a machine-readable destination and gives the organisation a place to attach policy.

Should the agent framework handle integration?

No. The framework is the caller: it decides when to invoke a tool and how to read the result. Adapters, data contracts and idempotency belong to the systems of record and the platform team that owns them.