Агент и солвер
Предложение с одним решением: солвер для первой версии · решено 2 октября 2026 · ничего не создано · факты о библиотеках проверены 2 октября 2026
Предложение — держать арифметику подальше от языковой модели: солвер, обычный детерминированный сервис, строит и проверяет график, а агент только переводит между людьми и этим сервисом.
Агент говорит, солвер считает, а последнее слово о правилах остаётся за API.
Что такое солвер
Это программа, которая расставляет людей по сменам при заданных правилах. Задача классическая — того же типа, что расписание медсестёр в больнице, которое библиотека оптимизации Google приводит как учебный пример, — и решается готовыми библиотеками оптимизации, а не языковой моделью.
- На входе данные, а не текст. Команда с ролями и доступностью, правила магазина и то, сколько людей нужно в каждый час. Это поля со страницы Входные данные.
- На выходе график — или ответ, что его не существует, и тогда какие часы остаются незакрытыми и какое правило мешает.
- Жёсткие правила не нарушаются никогда. Минимальный отдых, максимум часов, длина смены, отсутствия.
- Мягкие правила оптимизируются. Пожелания, справедливое распределение выходных и поздних смен, меньше переработок.
Языковая модель плохо справляется с такой арифметикой и не даёт гарантии, что соблюдено каждое правило. Её роль другая: понять, о чём просит человек, заполнить параметры, вызвать солвер и объяснить результат обычными словами.
О чём агент будет его просить
| Инструмент | Что он будет делать |
|---|---|
| Построить график | Черновик на период по данным магазина |
| Проверить изменение | Нарушает ли конкретный обмен или выходной какое-то правило |
| Найти замену | Кто может взять смену, не нарушая правил, и чего это будет стоить |
| Объяснить отказ | Почему допустимого графика нет и что это исправит |
Два правила важнее того, как инструменты подключены:
- Агент заполняет фиксированную форму, а не пишет правила сам. Иначе он может просто забыть правило отдыха, и никто этого не заметит.
- API перепроверяет каждое изменение по тем же правилам, от кого бы оно ни пришло — от агента, ассистента сотрудника или управляющего. Это и обещают страницы о продукте: каждое изменение проверяется по тем же правилам, что и исходный график.
Солвер — это MCP-сервер?
Нет. Солвер — это сервис. MCP — открытый стандарт подключения ИИ-приложений к внешним системам — один из возможных способов дать агенту доступ к этому сервису, и нужен ли он, зависит от того, где работает агент:
| Где работает агент | MCP? |
|---|---|
| Внутри нашего собственного API | Не нужен. Инструменты описываются прямо в вызове модели: меньше звеньев, проще права, проще разделение между магазинами. |
| На внешней платформе для агентов — например, Agentfy | Да. Это стандартный способ подключить к такой платформе наши инструменты. |
| В собственном ИИ-ассистенте управляющего | Да. Ассистент подключается к нашим инструментам тем же способом. |
В любом случае MCP будет тонкой обёрткой над тем же сервисом. Где работает агент, не решено, а значит, не решено и это.
Какой солвер
Для первой версии (MVP): YALPS — решено 2 октября 2026. YALPS — солвер, написанный на TypeScript. Он работает внутри API на NestJS, поэтому первой версии не нужны ни второй язык, ни отдельный сервис.
Авторы рассчитывают его на маленькие задачи: по их собственному ориентиру — не больше нескольких тысяч переменных и ограничений и не больше нескольких сотен решений «да/нет». Поддерживают его только исправлениями. Поместится ли в это настоящий магазин, неизвестно. Примерный подсчёт: 20 человек, 14 дней и 4 возможные смены в день — это уже 1120 решений «да/нет». Значит, первой версии придётся описывать задачу грубее или начинать с небольшого магазина, и показать, что это возможно, — первая задача прототипа.
Позже, скорее всего: Google OR-Tools, запущенный как небольшой отдельный сервис в собственном поде рядом с API в Kubernetes. Это намерение, а не решение; оно зависит от того, что покажет первая версия. OR-Tools официально поддерживает C++, Python, Java и C#, но не Node, поэтому это будет отдельный сервис. Мы будем его запускать, а не переводить на TypeScript: лицензия перевод разрешает, но это большая кодовая база на C++, и мы ожидаем, что перевод был бы медленнее и остался бы на нашей поддержке навсегда.
Дешёвой замену делает предложение выше: солвер стоит за теми же четырьмя инструментами, так что ни агенту, ни приложению не нужно знать, какая библиотека отвечает.
Что ещё рассматривали и не выбрали для первой версии:
| Библиотека | Что это | Почему не сейчас |
|---|---|---|
| highs-js | Солвер HiGHS, собранный в WebAssembly; работает внутри Node | Ближайшая альтернатива, если YALPS окажется мал раньше, чем появится OR-Tools |
| MiniZinc для JavaScript | Язык описания ограничений с несколькими солверами | В Node требует установленного на сервере MiniZinc |
| OptalCP | Солвер для задач расписаний с API на TypeScript | Проприетарный; бесплатная версия не отдаёт сам график |
Ни одной из этих библиотек мы не пользовались, включая YALPS и OR-Tools. Всё сказанное выше — со страниц самих проектов.
Чего это будет нам стоить
- Второй язык — позже. С YALPS первая версия остаётся на TypeScript. OR-Tools принесёт второй язык и ещё один сервис, который нужно запускать и развёртывать.
- Объяснение не даётся даром. Сам по себе солвер сообщает, что графика не существует, но не почему. Чтобы назвать незакрытые часы и мешающее правило, задачу нужно с самого начала моделировать под это.
- Посещаемость сначала должна стать числом людей. Сколько людей нужно в каждый час — отдельный шаг до солвера, и как его делать, не решено.
Не решено
- Хватит ли YALPS для настоящего магазина и когда его заменит OR-Tools.
- Где работает агент, а значит, подключаются ли инструменты напрямую или через MCP.
- Как посещаемость превращается в нужное число людей.
- Сколько времени занимает расчёт для настоящего магазина. Мы этого не измеряли и цифр не приводим.
- Работает ли разделение на агента и солвер для управляющих вообще. Это гипотеза, пока её не подтвердит прототип на данных одного магазина.
Что читать дальше
- Составление графика: та же идея словами управляющего.
- Обзор: приложение и API вокруг солвера.
- Открытые вопросы: что решено, а что нет.