Написал обзор гайда
Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.
Мне особенно нравится мысль про вероятностный мир
Почему это не “ещё один сервис”:
От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск.
Code-first уходит, приходит evaluation-first: шипим только с доказательствами (качество, латентность, безопасность, стоимость).
Агент = инструменты + политика полномочий + трассы рассуждений (observable traces).
ADLC вместо SDLC (DevSecOps для агентов): Plan → Code/Build → Test/Optimize/Release → Deploy → Monitor (runtime loop) → Operate. Две «внутренние петли»: эксперименты на сборке и оптимизация в рантайме.
Безопасность по-взрослому:
Песочницы (Firecracker/gVisor/политики контейнеров) + kill-switch + least-privilege.
Агентские угрозы: memory poisoning, tool misuse, goal hijack - нужны отдельные контроли, не только классический AppSec.
Наблюдаемость и метрики:
Не «жив ли сервис?», а «прав ли агент?». Логи/трейсы рассуждений, groundedness, hallucination rate, cost per outcome, champion-challenger.
Говернанс:
Каталог сертифицированных агентов/инструментов/промптов, версии, риск-профиль, артефакты оценок и редтиминга - прежде чем выпускать.
Интеграции = MCP-серверы:
Инструменты выводим через Model Context Protocol, поверх - MCP-Gateway (политики, мTLS, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам.
Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов».
Что делать завтра:
- Завести ADLC как стандарт (шаблоны метрик/гейтов).
- Включить агентские evals в CI/CD.
- Поставить MCP-gateway и каталог.
- Обязать песочницы и авторизацию «минимум прав».
- Сделать общую панель «качество-стоимость-риски»
Мне отдельно нравится про Evals
Evals - это «медосмотр» агента. Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис». Как их делают (3 вида): • Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза. • Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект. • In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст). Что мерим (примеры метрик): • успех задачи, groundedness, успех вызовов инструментов. • частота джейлбрейков, утечки данных, нарушения политик. • стоимость/токены на задачу, классы ошибок. • CSAT/оценки, cost per outcome (сколько стоит результат). Как раскатывать версии: • Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.
В этом посте были ссылки, но мы их удалили по правилам Сетки
