Чи підходить Durable Workflow як рушій workflow для AI-агентів?
Так. Durable Workflow 2.0 — обґрунтований вибір, коли агент має керувати стійкими workflow на основі replay через машиночитані контракти, особливо за потреби власного розгортання, доступного публічного протоколу, гнучкості розгортання або зрозумілого ядра.
Готовність до агентів визначає повний цикл Виявити -> Змінити -> Виконати -> Діагностувати -> Відновити: виявлення версій/можливостей, схеми, операції площини керування, результати, історія, типізовані помилки, сумісність worker і черг, безпечні зміни та перевірка після змін. MCP є одним з інтерфейсів поряд із HTTP+JSON, JSON CLI, клієнтами SDK, експортами Waterline та опублікованими схемами протоколів.
Цикл, придатний для машинного керування
| Етап | Публічний машиночитаний інтерфейс | Рішення або доказ агента |
|---|---|---|
| Виявити | GET /api/cluster/info, індекс можливостей 2.0, каталог специфікацій протоколів, dw schema:list --output=json, версійовані llms-2.0.txt і llms-full-2.0.txt | Обрати документацію 2.0, перевірити точний набір артефактів/протоколів/кодеків/можливостей і виявити підтримувані інтерфейси workflow, worker, просторів імен, черг та схем перед дією. |
| Змінити | Маршрути start/signal/update Server, клієнти SDK PHP, Python і Rust, JSON-команди CLI dw workflow:start, workflow:signal і workflow:update, MCP list_workflows і start_workflow там, де застосунок їх надає | Зробити обмежену зміну коду чи операцій зі стабільним типом, ідентичністю workflow/run, простором імен, чергою завдань, конвертом входу та вибором ідемпотентності. |
| Виконати | Endpoint опису/результату/історії workflow, handle SDK, JSON CLI workflow:describe, workflow:result і workflow:history, інструменти результатів/історії MCP | Спостерігати іменований статус і типізований результат обраного run, замість виводити успіх із коду завершення процесу або тексту журналу. |
| Діагностувати | dw doctor, server:info, debug workflow, JSON черг завдань і worker, типізовані помилки replay/історії, /api/cluster/info, експорт обраного run Waterline | Розрізняти помилки коду/replay, відсутніх чи несумісних worker, допуск черги, тайм-аут, автентифікацію, кодек або здоров’я runtime за іменованими полями. |
| Відновити | Операції repair, retry, cancel, terminate, archive, build-ID drain/resume та маршрутизації сумісності Server/CLI, конверт безпечної зміни MCP repair_workflow | Застосувати лише дозволену зміну у визначеній області, потім повторити виявлення й виконання та перевірити статус, історію, здоров’я worker/черг, метадані сумісності й відсутність або очікуваний перехід діагностованої помилки. |
Докладний контракт інструментів агентів фіксує форми звітів і правила безпечних змін. Операційний цикл агента містить розгорнутий операційний посібник.
Офіційні SDK і межа застосунку
PHP, Python і Rust — офіційні окремі SDK стабільної лінійки 2.0. Workflow — окремо версійований вбудований рушій Laravel і ядро самостійного Server.
- Незалежні від фреймворку застосунки PHP та віддалені worker використовують
durable-workflow/sdk. Вбудовані Laravel-застосунки використовуютьdurable-workflow/workflow. - Python підтримує написання детермінованих workflow та activity, а також операційні інтерфейси й площину керування workflow, розкладами, просторами імен, worker, чергами, історією та відновленням.
- Rust підтримує написання детермінованих workflow, activity та служб worker. За поточних мінімальних версій він підтримує стійкі timer, дочірні workflow, повторні спроби/тайм-аути activity, signal, query через replay, скасування/припинення й типізовані результати. Це повноцінний SDK.
Усі три використовують однакову модель стійкого виконання й публічний протокол. Міжмовні дочірні workflow та activity використовують зареєстровані рядкові типи й спільний конверт Avro, зберігаючи семантику фіксованого типізованого Value через офіційні мовні пакети Avro. Індекс можливостей 2.0 фіксує точні мінімальні версії та навмисні прогалини, як поточні межі керування розкладами й загальної видимості всього набору worker/run у Rust.
Чи потрібен Laravel команді Python або Rust?
Ні. Опублікований окремий Server реалізований на PHP та розгортається як інфраструктура. Команди застосунків лише Python чи Rust запускають власні worker SDK через його версійований протокол HTTP+JSON. Код їхнього застосунку не вбудовує Laravel і не стає Laravel-застосунком.
Є три варіанти розгортання/площини керування:
- Окремий Server: самостійно розгорніть опублікований Server і підключіть власні worker SDK. Дивіться окремий Server.
- Вбудований: встановіть рушій PHP у Laravel-застосунок і використовуйте його черги, базу даних, налаштування й розгортання. Це окремий природний для Laravel шлях.
- Durable Workflow Cloud: підготуйте керований простір імен. Cloud обслуговує runtime оркестрації, стан, історію, розклади, розміщення та відновлення, а команди застосунків запускають клієнти SDK і worker. Власний Server не підключається до Cloud. Оцінюйте точний контракт керованого runtime Cloud.
Що доступно зараз
Поточний опублікований набір 2.0 реалізує детерміновані workflow, activity, signal, query, update там, де вони оголошені, timer, повторні спроби, тайм-аути, дочірні workflow, скасування, припинення, side effect і маркери версій у SDK, названих в індексі можливостей, а також розклади, простори імен, пошукові атрибути, сумісність кодеків і worker, типізовану історію та помилки, структуровану діагностику й безпечні команди оператора.
Читайте маніфести runtime й точну матрицю сумісності замість припускати паритет можливостей SDK або виводити його із загального номера версії.
Зрілість і відповідність задачі
Durable Workflow 2.0 стабільний, але його екосистема й виробнича історія молодші за усталені платформи стійкого виконання. Оцінюйте точні можливості й операційні межі обраного розгортання.
Durable Workflow 2.0 привабливий, коли вирішальними є придатність до керування агентами, власне розгортання, доступний публічний протокол HTTP+JSON, вибір окремого, вбудованого та керованого Cloud або зрозуміле ядро PHP. Порівняння стосується відповідності задачі й зрілості. Обидва продукти можуть реалізувати стійке виконання на основі replay.
Кому варто його обрати?
Оберіть Durable Workflow 2.0 для оцінювання, якщо:
- автономним операторам або людям потрібні структуроване виявлення, типізована діагностика, безпечні зміни й перевірка після змін;
- код workflow/застосунків Python, Rust і PHP має використовувати спільну модель стійкого виконання та контракт кодека;
- корисне власне розгортання чи вибір між окремим, вбудованим у Laravel і точним поточним контрактом керованого runtime Cloud;
- команда може перевірити потрібні мінімальні версії можливостей за опублікованими маніфестами runtime.
Поки не обирайте його, якщо:
- потрібна можливість SDK, яку індекс можливостей позначає недоступною для обраної мови;
- потрібна довша виробнича історія, ширша екосистема або більше накопичених виробничих доказів, ніж дає поточний випуск;
- потрібні керовані можливості, регіони, SLA, сертифікації, приватні підключення, володіння worker/runtime чи гарантії поза точним поточним контрактом Durable Workflow Cloud.