Агенты против «обычного» софта: что реально меняется и где выгода
В новой статье автор The Tech — Мухаммад Абдугафаров, объясняет, почему агентные системы становятся основой нового поколения программного обеспечения и как они меняют подходы к разработке. Материал включает практические чек-листы и метрики.
Мухаммад Абдугафаров, город — Худжанд, тимлид, программист в Silk Road Professionals, LinkedIn
Большинство приложений живут по правилам детерминизма: одинаковый вход — одинаковый выход и строгий сценарий. Мир стал сложнее. Агентные системы работают иначе: они достигают цели в меняющемся контексте, планируют шаги, выбирают инструменты, опираются на память и двигаются в рамках явных политик. Что действительно меняется, как устроен агент, как считать надежность и экономику — и когда агентность дает измеримый эффект.
| Агент | Классическое приложение |
| Целеориентированная — получает цель и сама строит план действий. | Детерминировано — один и тот же вход → один и тот же выход. |
| Автономна — решает, когда и какие инструменты или сервисы вызвать. | Сценарно / CRUD-ориентировано — формы, валидация, транзакции, отчеты. |
| Адаптивна — подстраивает стратегию под контекст и обратную связь. | Низкая автономия — действует только по вызову пользователя или сервиса. |
| Наблюдаема — ведет трейсинг решений и шагов, чтобы быть объяснимой и аудируемой. | Предсказуемость и тестируемость — удобно покрывать юнит- и интеграционными тестами. |
| Ограничена политиками — действует в песочнице с явными правами. | Безопасность через инфраструктуру — роли, ACL, периметр, статические политики. |
Ключевой сдвиг: от «реакции на запрос» к «активному достижению цели». Агентные системы — это действительно новый класс ПО.
Классическая модель дала надежность. Но там, где задача расползается в нюансах — язык, тон, исключения, недостающие данные — жесткие сценарии ломаются или дорожают.
Граница отличий: четыре ключевых сдвига:
1. Процедура → Цель: фиксированный скрипт против оптимизации достижения результата.
2. Маршруты → Планирование: статический флоу против пересборки плана в реальном времени.
3. API‑вызовы → Инструменты как действия: заранее прошитые методы против контекстного выбора действий.
4. Состояние транзакции → Память и контекст: кратко‑/долгосрочная память для удержания смысла, а не только статуса операции.
Архитектура агента: из чего он собран:
— целеполагание: цель и критерии успеха
— планировщик: декомпозиция задач, ветвление, параллелизм, пересмотр плана
— инструменты: управляемый доступ к внешним системам
— память: краткосрочная — контекст сессии, долгосрочная — профили, факты
— политики: разрешенные действия, лимиты, стоп‑листы, верификация
— наблюдаемость: трейсинг решений, метрики, объяснимость, аудируемость
— эскалация: human‑in‑the‑loop для рискованных и «серых» кейсов.
В сумме это ближе к цифровому оператору, чем к «формочке с backend»: агент работает с миром, а не только внутри заранее написанного сценария.
Жизненный цикл: два разных мира
1. Обычное ПО: вход → валидация → бизнес‑логика → запись → ответ. Ошибка → код ошибки, ретрай при наличии.
2. Агент: цель → гипотеза плана → действие инструментом → наблюдение результата → корректировка → повтор → критерии успеха. Сбой → смена стратегии, запрос дополнительных данных, переоценка рисков, эскалация.
Именно здесь появляется эффект: агент закрывает «края» кейсов, которые раньше оседали на людях и ручной обработке.
Надежность и управляемость: без этого агенты теряют доверие
Агенты дают мощь, но без дисциплины быстро превращаются в «черный ящик». Нужны:
— SLA: success rate, среднее число шагов до успеха, тайм‑ауты/аборты, доля эскалаций
— трейсинг решений и объяснимость: фиксировать не только вызовы, но и причины
— минимально необходимые права и command‑guard перед критическими действиями
— контроль стоимости и задержки: роутинг моделей — LLM не всегда нужен, кэширование, прогрев инструментов
— тесты на достижение целей: симуляторы среды, A/B политик, goal‑oriented кейсы.
Экономика: где агент окупается
Агент выгоден там, где высокая вариативность сценариев и много исключений, длинные циклы взаимодействия, важны контекст и память. Нужна оркестрация инструментов: KYC → скоринг → оффер → контракт → инвойс. Цена ошибки контролируема политиками и эскалацией.
Не выгоден там, где входы стабильны, задача тривиальна, а регуляторы требуют строгого детерминизма. Попытка «сделать все агентным» нередко проигрывает честному «нет».
Кейс из FinTech: агент «мягкого взыскания»
Цель: увеличить долю обещаний платежа без ухудшения NPS.
1. Целеполагание: для каждого должника — получить дату/сумму обещания.
2. План: позвонить → подтвердить личность → выяснить причину → предложить опции → зафиксировать договоренность → отправить SMS.
3. Инструменты: звонок, CRM, скоринг риска, платежный сервис, шаблоны SMS.
4. Память: причины отказов, прошлые обещания, культурные нормы, язык.
5. Политики: стоп‑листы, лимиты повторных звонков, запрет давления, обязательная эскалация при конфликте.
6. Метрики: promise rate, повторные контакты, среднее время до обещания, NPS, стоимость контакта.
Обычное ПО бы просто «звонило по скрипту». Агент слышит контекст, меняет тональность, подбирает опции, эскалирует спорные случаи — и делает это в правовом поле, со следом решений и ограничениями прав.
В рамках проекта FynexAI работаем в этом направлении для soft‑collection — подробности на fynexai.com
Анти‑паттерны агентности
«LLM все решит»: без инструментов и политик агент — дорогой чат.
Память без политики: риск утечек персональных данных, галлюцинаций и проблем с комплаенсом.
Черный ящик: нет трейсинга решений — нет объяснимости и доверия.
Избыточные права в продакшене: прямой путь к инцидентам.
Конфликтующие цели: нестабильные планы и деградация качества.
Чек‑лист готовности кейса к агенту
Цель и критерии успеха сформулированы.
Инструменты перечислены и оформлены как безопасные действия.
Память разделена на кратко‑/долгосрочную, персональные данные защищены.
Политики и эскалации описаны явно.
Наблюдаемость и объяснимость включены в дизайн.
Экономика посчитана: задержка/стоимость, роутинг моделей, кэш.
Почему внедрение агентов — это не «еще один модуль»
Агентные системы — новый класс ПО. Их внедрение требует иного подхода, чем у классических приложений. Если просто заменить один модуль «агентом», вы получите лишь автоматизацию шага- без ключевой силы агентности: целевого планирования, адаптации и управляемой автономии. Часто придется пересобрать процессы: формулировать цели и критерии успеха, задавать границы прав, проектировать эскалации, протоколировать решения и измерять результат.
Так было и в истории. При электрификации фабрик эффективность рождалась не там, где «электромотор поставили на центральный вал», а там, где процессы перестроили: отказались от одного парового привода и распределили множество малых электродвигателей по рабочим местам. Распределенный электропривод изменил планировку, потоки и стандарты безопасности и дал кратный рост производительности. С агентами — тот же принцип: эффект приходит, когда перестраивается система вокруг нового класса ПО, а не когда «вкручивают моторчик» в старую схему.
Агент — это не «умный микросервис», а целевая исполнительная единица с планированием, памятью, инструментами и политиками. Он полезен там, где среда изменчива, а задача требует адаптации и автономии. Чтобы не получить «магический хаос», проектируйте агента как систему: цели, безопасность, наблюдаемость, экономика. И проверяйте все на метриках — там, где цифры сходятся, агентность перестает быть модой и становится рабочим инструментом.
