Соответствие механизмов
Главная польза этой заметки — таблица, по которой знание из LangGraph-раздела базы применяется к коду на Mastra:
| Механизм | LangGraph | Mastra |
|---|---|---|
| Сохранение состояния | checkpointer при compile() |
снимок прогона в настроенном storage, автоматически при приостановке |
| Пауза для человека | interrupt / прерывания на узле |
suspend() внутри шага + resume с конкретного шага |
| Подтверждение действия | собирается вручную из прерывания | свойство инструмента requireApproval: true |
| Формат вывода | схема при вызове модели | structuredOutput в опциях generate() |
| Ветвление и циклы | условные рёбра | .branch(), .dountil(), .foreach() в цепочке шагов |
| Агент как часть графа | узел | createStep(agent) — шаг из экземпляра агента |
| Состояние между шагами | общий State с редьюсерами | stateSchema шага, setState(); переживает приостановку |
Слова разные, вопросы проектирования одни: где живёт состояние, кто и когда его пишет, что происходит при перезапуске процесса (LangGraph Checkpointers, Durable Execution).
Что отличается по существу, а не по названию
Подтверждение объявляется на инструменте. requireApproval: true в createTool останавливает поток перед выполнением и порождает событие одобрения; дальше вызывающая сторона делает approveToolCall() или declineToolCall(). В LangGraph это собирается из прерывания и условных рёбер, то есть остаётся решением архитектора; здесь оно декларативно и потому проверяемо чтением определения инструмента, а не чтением графа (Approval Path).
Композиция идёт в обе стороны. Workflow подключается агенту как инструмент через поле workflows, а агент становится шагом workflow через createStep(agent). Это ровно та гибридная форма, которую база называет продакшен-нормой: детерминированный процесс, внутри которого один шаг агентный, и наоборот (Hybrid Orchestration, Agent vs Workflow).
Сети агентов. Маршрутизирующий агент выбирает из подагентов, workflow и инструментов, в каком порядке и с какими данными. Память здесь обязательна — по ней сеть хранит историю задачи и решает, когда та завершена. Каждому примитиву нужно внятное описание, а workflow и инструментам ещё и схемы входа-выхода: по ним маршрутизатор понимает, что подавать (Agent Routing, Tool Catalog).
Две ловушки, обе молчаливые
structuredOutput — параметр вызова, а не свойство агента. Забыли передать — модель вернёт свободный текст, ошибки не будет, схема просто не применится. Проверяется это не глазами: в аудите trdlabs/lab структурный поиск нашёл 18 вызовов .generate() и подтвердил схему у всех восемнадцати — выборочная проверка такого не даёт. Правило лежит в .claude/rules/mastra/output-schema-enforced.yml (Structured Output).
Наблюдаемость не включается сама. Трассировка появляется только при заданном observability.configs с экспортёром; пакет @mastra/arize отправляет спаны по OpenTelemetry в соглашениях OpenInference, то есть годится для любой платформы, их понимающей (OpenInference). Частая эксплуатационная ошибка — экспортёр в коде есть, а включён за флагом окружения, который по умолчанию выключен: аудит по репозиторию покажет «есть», прод будет молчать (Agent Observability).
Место в базе
Заметок про LangGraph здесь много, потому что таким сложился материал, из которого росла база, — а не потому, что он лучше подходит. Практическое правило при работе с Mastra: идти в LangGraph-раздел за механикой и решениями, а сюда возвращаться за именами. Различий по существу немного, и они перечислены выше.
Связано с
- LangGraph — фреймворк, через который база описывает те же механизмы
- LangGraph Checkpointers — устойчивое состояние, здесь это снимок прогона
- Human in the Loop — пауза за подтверждением, здесь декларативная на инструменте
- Hybrid Orchestration — композиция агента и процесса в обе стороны
- Structured Output — формат ответа и почему его отсутствие молчаливо
- Agent Observability — что даёт экспортёр и чего он не даёт выключенным
- Tool Calling — контракт инструмента:
inputSchema,outputSchema,execute