"Я построил orchestration engine без LangChain — и понял, где проходит главная граница"

На Reddit разработчик поделился опытом: выкинул LangChain и написал orchestration engine с нуля на 80 строках Python. Пост набрал десятки апвотов, и дискуссия ушла не в холивар «фреймворк vs без фреймворка», а в разговор об архитектуре. Потому что автор нашёл паттерн, который решает главную проблему AI-агентов в production.

LangChain-агент вызвал DELETE-эндпоинт, который не предполагался к использованию. Фреймворк передал решение LLM напрямую в исполнение — без промежуточного слоя, где это решение можно было бы проверить.

Это не баг LangChain. Это архитектурная проблема: фреймворк трактует выход LLM как программный вывод. А выход LLM — это вероятностный результат стохастического процесса.

Инсайт, ради которого стоит читать:

**Всё до Executor — вероятностное. Всё после — детерминированное. Executor — контракт между этими мирами.**

LLM генерирует правдоподобный текст. Может быть правильным, может быть галлюцинацией. Это нормально — так работают генеративные модели.

Executor вызывает API, меняет данные, отправляет деньги. Каждое действие необратимо.

Между ними нужна формальная граница: Pydantic-схема на структуру, allowlist на инструменты, бизнес-правила на аргументы. Не промпт «будь аккуратным». Код, который не пропускает невалидное.

Архитектура — три компонента:

**Planner LLM** — решает, что делать. Выдаёт JSON: инструмент + аргументы + обоснование. Ничего не исполняет.

**Trust Boundary** — валидирует решение. Схема, allowlist, правила. Это функция, которую пишешь один раз.

**Executor** — исполняет только то, что прошло валидацию. Никакой интерпретации.

``` plan = call_planner(query) validated = validate_plan(plan) result = execute(validated) ```

80 строк. Без магии.

Без валидационного слоя: - 2-5% невалидный JSON от LLM - ~1% несуществующий инструмент - ~3% неверные аргументы при правильном инструменте

Итого 6-9% вызовов привели бы к ошибкам или непредсказуемым побочным эффектам. С Trust Boundary все ловятся до исполнения: retry, reject, log.

LLM не становится надёжнее. Система становится надёжнее за счёт контракта.

LangChain оптимизирует скорость прототипирования. Для демо — отлично. Для production проблемы начинаются:

- Отладка через три слоя абстракции - Фреймворк принимает неявные решения за вас: как парсить ответ, когда ретраить - Быстрые релизы ломают существующий код

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

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

Фреймворк — когда мультиагентная система с разделяемым состоянием или когда нужен прототип завтра.

При проектировании AI-агента начните не с выбора фреймворка. Начните с рисования границы: слева — вероятностный мир LLM, справа — детерминированный мир API и данных. На границе — Executor-контракт.

Эта единственная архитектурная деталь определяет надёжность агента в production. Всё остальное — детали реализации.

А у вас как устроена граница между тем, что LLM решил, и тем, что система делает?