Розробка за допомогою ШІ
Durable Workflow v2 дає людині змогу вивчити модель стійкого виконання, а потім передати повторювані перевірки й операції інструментам. Важливий інтерфейс продукту — це не підказка для чату, а набір стабільних точок доступу, які агент може читати, викликати й цитувати без припущень.
Джерела документації
Використовуйте ці файли для LLM, щоб надати ШІ-асистенту машиночитану документацію Durable Workflow:
| Джерело | URL | Призначення |
|---|---|---|
| канонічний маніфест | https://durable-workflow.com/llms.txt | Індекс стабільної документації 2.0. Відповідає типовому шляху Docs сайту без версії. |
| канонічний повний набір | https://durable-workflow.com/llms-full.txt | Документація в одному файлі, що відповідає канонічному маніфесту. |
| маніфест v1 | https://durable-workflow.com/llms-1.x.txt | Архів із зафіксованою версією 1.x. |
| повний набір v1 | https://durable-workflow.com/llms-full-1.x.txt | Повний стабільний набір із зафіксованою версією 1.x. |
| маніфест v2 | https://durable-workflow.com/llms-2.0.txt | Індекс із зафіксованою версією 2.0, еквівалентний канонічному маніфесту. |
| повний набір v2 | https://durable-workflow.com/llms-full-2.0.txt | Повний набір із зафіксованою версією 2.0. |
Типові підказки для агентів мають завантажувати /llms.txt або
/llms-full.txt для роботи зі стабільною 2.0. Для підтримки застосунку 1.x
фіксуйте URL із суфіксом -1.x.txt.
Локальний інтерфейс MCP
Sample app надає Laravel MCP-сервер за
/mcp/workflows. Це еталонна інтеграція ШІ-клієнта для локальної розробки
workflow v2. Сторінка Інтерфейс MCP Workflow визначає
кінцеву точку, набір інструментів, безпечні базові перевірки workflow
та структуру звіту.
MCP-сервер надає агенту структуровані операції workflow замість зчитування UI:
| Інструмент | Стабільна операція |
|---|---|
list_workflows | Знайти налаштовані ключі workflow, вимоги до облікових даних, значення станів і нещодавні запуски. |
start_workflow | Запустити налаштований workflow v2 й отримати workflow_id, run_id, стан, бізнес-ключ і результат команди. |
get_workflow_result | Опитати поточний або вибраний запуск щодо стану, результату, метаданих видимості й останньої помилки. |
get_workflow_history | Отримати обмежений кінець типізованої історії v2 та нещодавні стійкі помилки. |
Використовуйте simple або elapsed для базових перевірок без облікових
даних. Запускайте workflow із зовнішніми обліковими даними лише після
налаштування потрібних ключів у локальному середовищі.
Коли агент редагує повторювані workflow ШІ або введення користувачем,
спрямуйте його до контракту v2 Потоки повідомлень.
Стабільний шаблон — Workflow::inbox() / Workflow::outbox() /
MessageStream. Прямі записи через MessageService, WorkflowMessage
або рядки курсорів є внутрішніми деталями runtime, а не шаблонами прикладів.
Контракти команд і діагностики
Агентам слід віддавати перевагу машиночитаним інтерфейсам перед знімками екрана або текстовими описами:
- Робочий цикл агента поєднує документацію v2,
кінцеву точку MCP, JSON від
dw, експорт історії Waterline й довідники SDK в повторюваний цикл пошуку, зміни, запуску й діагностики. - Контракт інструментів агента визначає, як інструменти MCP, JSON CLI, діагностика сервера, експорт Waterline та фікстури SDK утворюють спільний програмно керований інтерфейс.
- Команди
dwнадають стабільні коди виходу для автоматизації. Див. довідник CLI. - Можливості клієнтів і worker
порівнюють життєвий цикл, повідомлення, розклади, видимість і виконання worker
у
dwта всіх трьох офіційних SDK зі спільними доказами запитів там, де вони доступні. - Інтерфейс зовнішнього виконання
публікує межу завдання рівня activity, вимоги до носія виконання, результати
мосту й шляхи конвертів входу та результату через
/api/cluster/info. - Команди health, info, namespace, workflow, schedule, worker і task-queue сервера є відповідними інструментами перевірок із shell.
- Експорт історії Waterline є джерелом для replay та діагностики помилок. Він містить типізовані події історії, метадані джерел проєкцій, перевірки цілісності, контекст вибраного запуску, очікування, timer, походження й останні стійкі помилки.
- Типи й сигнатури методів Python SDK наведено в згенерованому довіднику Python API.
Щоб агент міг пояснити завислий workflow, спочатку зберіть такі факти:
workflow_idandrun_id- стан поточного запуску й опис останньої помилки
- нещодавні типізовані події історії
- відкриті очікування, timer та очікувані завдання
- стан worker і черги завдань
- відповідну версію документації:
2.0для поточної роботи з продуктом, а1.x— лише для підтримки старої версії
Цього набору достатньо, щоб відрізнити помилку стійкого workflow від збою runtime worker, відсутніх зовнішніх облікових даних, недоступної черги або дії оператора, яка очікує на схвалення.
Структура підказки
Надавайте агентам програмування явні обмеження й точки доступу:
Use Durable Workflow docs from https://durable-workflow.com/llms-full-2.0.txt.
Use the sample app MCP endpoint at /mcp/workflows for workflow discovery,
start, result, and history. Prefer dw JSON/exit-code contracts and Waterline
history exports over screenshots. For external handlers or bridge adapters,
read worker_protocol.external_execution_surface_contract from /api/cluster/info
and preserve the external task input/result envelopes. Use Durable Workflow
2.0 APIs unless I explicitly ask for legacy 1.x maintenance.
Мета проста: люди вивчають інваріант workflow/activity/replay, а інструменти працюють через документовані контракти, не виводячи поведінку продукту з припущень.