Агент і розв'язувач
Пропозиція з одним рішенням: розв'язувач для першої версії · вирішено 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 навколо розв'язувача.
- Відкриті питання: що вирішено, а що ні.