43 провала. Потом 250 000 звёзд на GitHub за 2 месяца: как бизнес-скиллы для AI-агентов экономят недели продакшн-работы

Я Денис Шохирев, архитектор агентных AI-систем во Фрайбурге (DennisCraft AI Studio, стэк: Claude, Supabase, n8n, Doppler, self-hosted Postgres). Первая продакшн-версия моей мультиагентной системы уронила клиентский бэкенд 43 раза за неделю. После — 250 000 звёзд на GitHub у публичного форка за 2 месяца. Разница не в коде, а в бизнес-скиллах: как собрать команды агентов, чтобы они решали задачи бизнеса, а не только генерировали демо.

Почему демо-агенты не работают в продакшне

Миф: если агент прошёл demo day, он готов к бою. Факт: на реальных данных в логистике или финтехе всё ломается. Я видел, как агенты на базе Claude Code успешно сдают demo, но на реальных заказах:

• генерируют SQL-запросы с SQL-инъекциями (на 3-х внедрениях подряд — см. OWASP Top 10)
• залипают в бесконечный retry loop, если API недоступен
• теряют контекст бизнес-целей (например, агент для счетов выставляет счета не тому клиенту, потому что не валидирует ИНН)

Причина — отсутствие бизнес-скиллов: агенты не знают, что нельзя тратить бюджет на лишние API-запросы, что нужно валидировать документы, что SLA важнее “умного” решения.

Как формализовать бизнес-скиллы для AI-агентов

1. Явное описание бизнес-ограничений в промпте

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

# Пример: Claude Code, явное ограничение на число API-запросов
PROMPT = f"""
Ваша задача — проверить статус заказа. 
Ограничения: не более 2 запросов к API за 1 задачу, не хранить персональные данные.
При ошибке — ретрай не более 1 раза, иначе фейлить задание.
"""

Внедрение этих ограничений снижает расходы на инфраструктуру и уменьшает “залипание” агентов.

2. Контроль цепочек действий — не только валидность кода, но и бизнес-логика

n8n подходит для визуализации цепочек: можно явно задать, какой агент что делает, и на каком шаге валидировать бизнес-правила.

# n8n workflow: валидация ИНН перед отправкой счёта
- name: get_client_data
  type: postgres
  params: {query: "SELECT inn FROM clients WHERE id = $id"}
- name: validate_inn
  type: function
  params: {code: "if (!isValidINN(item.inn)) { throw Error('Invalid INN') }"}
- name: send_invoice
  type: http
  params: {url: "https://api.invoice/send"}

Ошибка валидации останавливает workflow, предотвращая отправку ошибочного счета.

Столкновения: чего не хватает обычным LLM-агентам

Как экономить недели на продакшн-работе

1. Интеграция статического анализа

На каждом pull request — прогоняю с semgrep, bandit, gitleaks (см. semgrep, bandit). LLM-агенты часто генерируют code smells, которые ловятся только такими инструментами — на этапе генерации или CI/CD.

# semgrep + bandit в CI
semgrep --config=python .
bandit -r .
gitleaks detect

Реальный кейс: на одной интеграции поймал 5 критичных утечек токенов — до попадания в продакшн.

2. Разделение ролей между агентами

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

// n8n: разные агенты на разных этапах
[
  { agent: "document_validator", input: "invoice.pdf" },
  { agent: "business_rule_checker", input: "validated_invoice" },
  { agent: "notifier", input: "approved_invoice" }
]

3. Сбор логов и аудит действий

Все действия агентов пишу в Supabase/Postgres, а не просто в stdout. Это позволяет быстро находить “узкие места” и строить отчеты для клиента.

import supabase
# Логируем действие агента
supabase.table("agent_logs").insert({
   "agent": "validator",
   "action": "INN_check",
   "status": "fail",
   "timestamp": datetime.now()
})

FAQ

Какой инструмент статического анализа лучше всего ловит ошибки LLM-агентов?

semgrep (https://semgrep.dev/) показывает лучший баланс между гибкостью и скоростью, особенно для Python-кода сгенерированного Claude или OpenAI.

Как формализовать бизнес-ограничения для агентов?

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

Как интегрировать логирование действий агентов?

Используйте Supabase или self-hosted Postgres. Логируйте не только ошибки, но и успешные действия — это помогает строить отчеты для compliance и быстрее искать баги.

Нужно ли делать отдельного агента для каждой бизнес-логики?

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

Как быстро проверить, что агент не нарушает бизнес-ограничения?

В n8n можно настроить ручной шаг-валидатор, либо добавить автоматическую проверку через функции в каждом workflow.

На каком этапе у вас чаще всего ломаются агенты: генерация кода, интеграция с API или бизнес-валидация? Мне реально интересно.

Я делаю бесплатный 30-мин аудит стэка для DACH-фаундеров, запускающих AI в регуляторных отраслях. Пишите в LinkedIn или в @ger_dennis_ai.