Promptware — это автономный агентный модуль, который хранит свои инструкции, память (Memory), права доступа к инструментам (Tools) и историю выполнения (Logs) в виде файлов и самостоятельно пересматривает инструкции и память после каждого запуска. В Ivy Tendril каждый этап жизненного цикла плана — от формирования черновика до открытия pull request — выполняется одним из таких модулей. Инструкции представляют собой версионируемые файлы в репозитории, поэтому их можно проверять на ревью, просматривать через diff, откатывать назад и распространять среди команды точно так же, как любой файл с исходным кодом. В этой статье подробно описаны структура модуля, цикл выполнения (run loop), семь встроенных promptware и два сценария сбоев, за которыми необходимо следить.

Что входит в модуль promptware

Модуль promptware представляет собой директорию, состоящую из четырех частей. У каждой части — строго одна задача.

Компонент	Содержимое	Кто обновляет
`Program.md`	Инструкции, которым следует агент на данном этапе. Пересматриваются агентом после запуска, рецензируются разработчиками.	Агент и разработчики
`Memory/`	Долговременные знания о кодовой базе и соглашениях команды. Дополняются после каждого выполнения.	Агент
`Tools/`	Ограниченные права для данного этапа: какие команды, файлы и интеграции разрешено использовать агенту.	Разработчики
`Logs/`	История выполнения: что агент прочитал, выполнил и изменил, а также к каким выводам пришел.	Агент (только добавление)

Program.md пишется естественным языком, а не кодом. Раздел для модуля выполнения плана может выглядеть следующим образом:

## Перед открытием pull request

- Запустите `pnpm lint` и `pnpm test` из корня репозитория. Не открывайте PR, если хотя бы одна из команд завершилась с ошибкой.
- Ограничивайте diff строго файлами, указанными в плане. Если потребовалось изменить другой файл, укажите причину в описании PR.
- Используйте формат сообщений коммитов `type(scope): summary`.

Запись в памяти фиксирует то, что агент узнал в ходе работы, что не очевидно из исходного кода и что пригодится при последующих запусках:

### 2026-08-21, план #412

Модуль биллинга в `src/billing/` не покрыт тестами. Добавьте тесты перед проведением рефакторинга.
Команда `pnpm test` предварительно запускает миграции базы данных; выполнение занимает около четырех минут на чистом чек-ауте.

Эти два файла принципиально различаются по назначению. Программа указывает, что нужно делать. Память фиксирует, что является истиной для этого репозитория. Такое разделение позволяет ревьюеру принять новый факт без необходимости соглашаться на изменение рабочего регламента — и наоборот.

Цикл выполнения

Каждый запуск promptware состоит из четырех последовательных шагов.

Загрузка программы. Агент считывает Program.md и права доступа, заданные в Tools/. Все, что выходит за рамки этих прав, ему недоступно.
Чтение памяти. Агент читает Memory/, благодаря чему факты, накопленные в прошлых запусках, загружаются в контекст до начала работы.
Выполнение задачи. Агент выполняет работу своего этапа: формирует план, расширяет его, запускает в отдельном worktree или открывает pull request. Каждый вызов инструмента и его вывод добавляются в Logs/.
Анализ и запись результатов. Агент сопоставляет фактический результат с тем, чего требовала программа. Новые факты сохраняются в Memory/. Если какая-то инструкция оказалась неверной, неполной или избыточной, агент обновляет Program.md.

Цикл «действие, наблюдение за результатом и корректировка следующей инструкции» соответствует шаблону, описанному в статье по методологии ReAct для рассуждающих агентов. Promptware отличается от нее прежде всего тем, что результаты корректировки сохраняются в файл, который продолжает жить после завершения сессии. Именно этот четвертый шаг позволяет инструкциям со временем улучшаться, а не деградировать. Кроме того, этот шаг требует наибольшего контроля со стороны человека, чему посвящен раздел о рисках.

Встроенные модули promptware

Ivy Tendril поставляется с семью встроенными promptware — по одному на каждый этап жизненного цикла, описанный в статье от задачи на GitHub до pull request. Каждый модуль имеет собственную программу, память, права и логи.

CreatePlan превращает идею, задачу из GitHub Issue или отчет об ошибке в проект плана: цель, границы задачи, затронутые файлы и шаги валидации.
ExpandPlan дополняет черновик деталями, если для старта не хватает информации — например, отсутствуют критерии приемки или не согласованы архитектурные решения.
UpdatePlan переписывает черновик на основе комментариев и правок, оставленных разработчиком прямо в тексте.
SplitPlan делит чрезмерно разросшийся план на несколько независимых подзадач, которые можно запустить параллельно.
ExecutePlan выполняет утвержденный план с помощью выбранного кодинг-агента (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode или любого CLI-агента) в изолированном git worktree. В руководстве Anthropic по лучшим практикам Claude Code приводятся те же доводы в пользу сохранения инструкций в репозитории, что и в этом разделе для Program.md.
CreatePr открывает pull request после того, как diff успешно прошел автоматическую проверку и ревью инженером.
CreateIssue создает тикет в GitHub Issue на основе рекомендаций или проблем, обнаруженных в процессе выполнения.

Поскольку модули изолированы друг от друга, память CreatePlan (например: «команда требует указывать в плане тестовые файлы, подлежащие изменению») не передается в ExecutePlan, а право ExecutePlan на запуск терминальных команд не распространяется на CreatePlan. В документации по promptware подробно описано содержимое каждого модуля по умолчанию.

Версионированные инструкции и два главных риска

Почему файлы в репозитории превосходят разовые промпты

Разовый промпт, набранный в окне чата, существует лишь однажды, для одного человека, и исчезает с закрытием сессии. Файл Program.md, зафиксированный в репозитории, дает четыре преимущества, которых нет у разового промпта:

Ревью. Изменение программы превращается в diff в pull request. Ведущий разработчик может отклонить опасную инструкцию (например, «пропускать тесты при мелких правках») еще до того, как она повлияет на последующие запуски.
Diff. Если качество работы агента меняется, команда git log в каталоге promptware сразу покажет, какая именно инструкция и когда была скорректирована.
Откат (Rollback). Неудачное исправление отменяется всего одним коммитом.
Обмен опытом. Каждый разработчик в команде и каждый запуск агента используют одни и те же проверенные инструкции. Правило, сформулированное агентом в понедельник, уже во вторник применяется всеми участниками процесса.

Именно этот аргумент в свое время привел к переходу инфраструктуры от ручных настроек к файлам под контролем версий (IaC), и тот же принцип лежит в основе выноса конфигурации из кода в The Twelve-Factor App; здесь работают абсолютно те же закономерности. Другие подходы к структурированию агентных рабочих процессов и их сравнение с promptware подробно рассмотрены в статье паттерны оркестрации кодинг-агентов.

Риск 1: дрейф инструкций (instruction drift)

Агент, которому разрешено редактировать собственную программу, способен и ухудшить ее. Запуск, завершившийся сбоем из-за нестабильного (flaky) теста, может добавить правило «перезапускать упавшие тесты до трех раз», что в будущем замаскирует реальный дефект. Этому препятствуют два фактора. Во-первых, программа — это версионируемый файл, поэтому любое исправление видно в виде diff, который ревьюер может проверить и отклонить. Во-вторых, каталог Logs/ хранит лог конкретного запуска, спровоцировавшего правку, что позволяет проверить логику рассуждений агента перед принятием изменений.

Риск 2: разрастание памяти (memory bloat)

Память, которая бесконтрольно растет, превращается в источник затрат без практической пользы. Файл на 400 записей, половина из которых устарела, сжигает токены при каждом запуске и затрудняет поиск действительно важной информации. Поддерживать ее в порядке помогают две привычки: указывать дату и контекст каждой записи, как показано в примере выше, чтобы легко находить устаревшие данные; очищать память во время ревью: когда план затрагивает определенный модуль, проверяющий просматривает связанные записи памяти и удаляет те, которые больше не актуальны. Отслеживание затрат и токенов на уровне планов и отдельных задач наглядно демонстрирует разрастание: модуль с перегруженной памятью показывает рост потребления токенов без увеличения объема самих планов. Именно поэтому методология измерения производительности AI-агентов отслеживает стоимость за влитый pull request, а не за отдельный запуск.

С чего начать

Установите Ivy Tendril, откройте репозиторий и создайте план. Все семь встроенных promptware готовы к работе с самого первого запуска.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

В Windows выполните irm https://cdn.ivy.app/install-tendril.ps1 | iex. Просмотрите файлы Program.md перед запуском выполнения, а затем проверяйте первые записи в памяти и правки программы с тем же вниманием, с каким вы проводите код-ревью. Примерно через десять выполненных планов память отразит те участки кодовой базы, где у агента возникали затруднения — как правило, именно там вопросы возникли бы и у живого разработчика. В документации по promptware приведены дополнительные подробности о встроенных модулях.

Часто задаваемые вопросы

Меняет ли агент Program.md без спроса?

Агент корректирует программу по завершении рабочего цикла. Поскольку Program.md находится под контролем версий, изменение предстает в виде понятного diff, который вы можете изучить, принять или отменить, а журнал запуска, послужившего причиной правки, лежит прямо рядом с файлом.

Можно ли создавать собственные promptware?

Семь встроенных модулей покрывают основные этапы жизненного цикла разработки. Их программы, память и доступы к инструментам — это обычные текстовые файлы, поэтому вы можете настроить их под соглашения вашей команды. Актуальные возможности расширения описаны в документации.

Где хранятся память и логи?

Локально, на том компьютере, где запущен Tendril. Они не передаются на серверы Ivy. Единственные сетевые обращения, которые выполняет Tendril, направляются к настроенному вами API языковой модели и к GitHub.

Начало работы с Ivy Tendril

Готовы к параллельной оркестрации агентов на профессиональном уровне?

Изучить исходный код: Посетите репозиторий Ivy Tendril на GitHub (Open Source).
Читать документацию: Ознакомьтесь с руководствами по интеграции на tendril.ivy.app.
Запланировать консультацию: Напишите на renco@ivy.app для 30-минутной архитектурной сессии.

Promptware: агенты, сохраняющие и совершенствующие собственные инструкции