В третьей части цикла «Затащи меня в Harness» на Habr автор переходит от разбора отдельных элементов — durable state, событий, approvals и фоновых задач — к маршрутизации запросов. Это ключевой узел, где свободный текст, контекст, маршрут, policy-ограничения, UI и исполнение должны работать как единая система. Автор честно предупреждает: предложенная архитектура не идеальна и не претендует на универсальный рецепт, но приёмы взяты из реальной production-практики.
Проблема, из-за которой статья появилась, знакома многим разработчикам. Локальная модель с 30 млрд параметров, запущенная в закрытом контуре и конкурирующая за видеокарту с корпоративными сервисами, часто выглядит беспросветно тупой. Попытка перейти на API сильной модели упирается в стоимость: через две недели счёт за токены съедает зарплату. Автор потратил три месяца на то, чтобы привести систему в порядок, и делится принципами, которые помогают не скатиться в попугая и не разориться.
| Подход | Сущности |
|---|---|
| Толстый харнесс | Intent, Route, Shortcut, Capability, ContextRequirement, ToolEligibility, FallbackRoute, ClarificationRequest, RouteDecision |
| Тонкий харнесс | Capability, Workflow, ToolContract, Policy, Approval |
Первый принцип: чем сильнее модель, тем тоньше харнесс. В идеале сильная модель сама понимает запрос, выбирает capability и строит план, а обвязке остаётся только проверять права, policy, состояние и безопасно запускать workflows. Для слабых моделей харнесс становится толстым: он помогает разобрать запрос, выбрать сценарий, проверить обязательный контекст и отфильтровать неподходящие инструменты. В этом случае появляются дополнительные сущности: Intent (классификация намерения), Route (правило выбора сценария), Shortcut (детерминированный маршрут), Capability (формализованная возможность системы), ContextRequirement (список обязательных входных данных) и другие.
Вводятся сущности: Intent, Route, Shortcut, Capability, ContextRequirement и другие.
Поток запроса при толстом харнессе выглядит так: Input → Intent / RouteDecision → Capability → ContextRequirement → Workflow → Policy → Tool / LLM. При тонком харнессе большинство этих сущностей не нужно, остаются Capability, Workflow, ToolContract, Policy и Approval. Главное — не перепутать зоны ответственности. Харнесс может компенсировать слабость модели, но не должен забирать на себя policy, права и approvals. Модель предлагает действие, а харнесс решает, разрешено ли его выполнять. Слабые модели, не способные занимать первые места на агентских бенчмарках, требуют дополнительных механизмов, но границы безопасности всегда остаются явными.
Автор подчёркивает, что это не «десять заповедей», а набор инженерных правил, помогающий не превратить роутер в коллекцию случайных исключений. Для тех, кто строит собственных ИИ-ассистентов, статья полезна как системное описание компромиссов между возможностями модели и сложностью обвязки, а также как источник идей для организации маршрутизации.