Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.
Мне особенно нравится мысль про вероятностный мир
Почему это не “ещё один сервис”:
От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск.
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, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам.
Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов».
Что делать завтра:
1) Завести ADLC как стандарт (шаблоны метрик/гейтов).
2) Включить агентские evals в CI/CD.
3) Поставить MCP-gateway и каталог.
4) Обязать песочницы и авторизацию «минимум прав».
5) Сделать общую панель «качество-стоимость-риски»
Мне отдельно нравится про Evals
Evals - это «медосмотр» агента.
Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис».
Как их делают (3 вида):
• Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза.
• Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект.
• In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст).
Что мерим (примеры метрик):
• успех задачи, groundedness, успех вызовов инструментов.
• частота джейлбрейков, утечки данных, нарушения политик.
• стоимость/токены на задачу, классы ошибок.
• CSAT/оценки, cost per outcome (сколько стоит результат).
Как раскатывать версии:
• Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.