Мне надоели ограничения агентов, поэтому я создал AgInTiFlow

Мне надоели ограничения агентов, поэтому я создал AgInTiFlow

Мне надоели неприятные, скупые ограничения вокруг серьёзной работы с агентами.

Это предложение звучит немного эмоционально, но именно с этого всё честно и началось. Я использую существующих кодинговых агентов. Во многом они мне нравятся. Codex, Claude Code, Gemini CLI, Copilot и другие инструменты продвинули всю область вперёд. Но когда я попытался использовать агентов для реальных проектов, я снова и снова сталкивался с одной и той же практической проблемой: интерфейс был мощным, но сам рабочий процесс всё ещё ощущался слишком загнанным в рамки.

Иногда ограничением была стоимость. Иногда контекст. Иногда это была сессия, которую позже нельзя было нормально просмотреть. Иногда веб-интерфейс, оторванный от терминала. Иногда запуск инструмента тихо завершался с ошибкой или создавал артефакт, который потом приходилось искать. Иногда агент просто говорил "done", хотя работа на самом деле ещё не была проверена.

Поэтому я начал создавать собственное рабочее пространство для агентов: AgInTiFlow.

Установка:

npm install -g @lazyingart/agintiflow
aginti

Запуск локального веб-интерфейса:

aginti web --port 3210

AgInTiFlow задуман не как очередное окно чата. Это локальное рабочее пространство агента с веб-интерфейсом и CLI, которое начинается с реальной папки проекта и делает работу доступной для проверки.

AgInTiFlow terminal launch screen

Рисунок 1. AgInTiFlow запускается в терминале, внутри папки проекта, и с самого начала показывает поддержку браузера, shell, файлов, Docker, веб-поиска и scout.

Проблема не только в интеллекте

Текущее поколение моделей уже полезно. Часто недостаёт не сырого интеллекта. Недостаёт рабочей дисциплины.

Когда я прошу агента разрабатывать ПО, писать статью, делать сайт, создавать отчёт в LaTeX, исследовать кодовую базу, генерировать изображение или управлять Git-процессом, мне нужен не только текст. Мне нужна система, которая понимает папку проекта и может оставлять доказательства проделанной работы.

Для серьёзной работы агент должен уметь отвечать на такие вопросы:

  • В каком каталоге я работаю?
  • Какие файлы изменились?
  • Какая команда завершилась с ошибкой?
  • Где находится сгенерированный PDF, APK, изображение или скриншот?
  • Какая сессия создала этот артефакт?
  • Могу ли я продолжить это завтра?
  • Могу ли я просмотреть ту же работу из браузера?
  • Действительно ли агент проверил результат?

Большинство рабочих процессов с агентами всё ещё делает хотя бы часть этих вопросов сложнее, чем должно быть.

AgInTiFlow пытается сделать их первоклассными.

CLI для работы, веб для проверки

Терминал по-прежнему остаётся самым быстрым местом для начала технической работы. Именно там живёт репозиторий, именно там живёт Git, и именно там разработчики уже привыкли мыслить командами и путями.

Но терминал подходит не для всего. Предпросмотр PDF, сгенерированное изображение, длинный runtime-лог, выбор модели, артефакт canvas или скриншот удобнее проверять в браузере.

Поэтому у AgInTiFlow есть две поверхности над одним и тем же состоянием проекта:

  • aginti для интерактивного CLI.
  • aginti web для локального веб-приложения.

AgInTiFlow website hero

Рисунок 2. Публичный сайт показывает задуманную форму продукта: terminal-first, синхронизированный с вебом и привязанный к одной и той же локальной работе.

Цель не в том, чтобы заменить терминал веб-приложением или веб-приложение терминалом. Цель в том, чтобы дать каждому интерфейсу делать то, в чём он хорош.

CLI нужен для быстрого взаимодействия. Веб-приложение нужно для видимости: сессий, runtime-логов, артефактов, файлов, скриншотов, PDF, изображений, настроек и состояния проекта.

AgInTiFlow local web console with conversation and run output

Рисунок 3. Локальный веб-интерфейс может продолжать выбранный диалог, показывать элементы управления проектом, раскрывать настройки маршрутизации и держать вывод запуска рядом с чатом. На этом скриншоте сессия сгенерировала изображение панды и записала путь к артефакту в ответе ассистента и в runtime-выводе.

Дешёвые модели меняют архитектуру

Одна из причин, почему я строю это именно сейчас, это DeepSeek.

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

DeepSeek V4 меняет это уравнение. Он достаточно силён и достаточно дёшев, чтобы я мог проектировать агента иначе:

  • Использовать DeepSeek V4 Flash для быстрой маршрутизации, коротких задач, shell-задач и базового планирования.
  • Использовать DeepSeek V4 Pro для более сложного кодинга, отладки, исследований, письма и архитектуры.
  • Держать модели в стиле OpenAI/Codex как резервные или обёрточные маршруты там, где они полезны.
  • Оставлять доступными Venice, Qwen, mock mode и вспомогательных провайдеров изображений для провайдер-специфичных задач.

AgInTiFlow routing cards

Рисунок 4. Слой моделей построен по ролям: модель маршрутизации, основная модель, резервная/обёрточная модель и вспомогательные модели выполняют разные задачи, а не скрываются за одним расплывчатым выпадающим списком.

Это важно, потому что хороший локальный агент не должен зависеть от одной модели как сущности. Одним задачам нужна скорость. Другим нужен контекст. Некоторым нужна дисциплина инструментов. Некоторым нужен другой профиль политики. Некоторым нужна генерация изображений. Некоторым нужна дешёвая scout-модель, чтобы осмотреть уголок кодовой базы до того, как начнёт действовать основная модель.

AgInTiFlow рассматривает выбор модели как часть проектирования рабочего процесса.

Локальные сессии должны быть долговечными

Реальный проект не живёт в одном промпте.

У него есть файловая система, состояние Git, сгенерированные результаты, логи команд, скриншоты, история сессий, заметки об окружении, а иногда ещё и браузер или эмулятор. Если агент это теряет, он теряет и саму работу.

AgInTiFlow движется к центральной модели сессий:

  • Канонические сессии живут в ~/.agintiflow/sessions/<session-id>/.
  • Папки проектов могут хранить лёгкие указатели в .aginti-sessions/.
  • Артефакты принадлежат сессии.
  • Отслеживаются путь проекта, заголовок, время создания и роли моделей.
  • aginti resume может переподключиться к предыдущей работе.

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

Артефакты — это истина

Агенты слишком легко говорят "done".

Я хочу, чтобы AgInTiFlow был больше сосредоточен на артефактах. Если он что-то собирает, должен быть видимый результат. Если он редактирует код, должен быть diff. Если он утверждает, что тесты проходят, должен быть результат команды. Если он генерирует PDF, скриншот, изображение или приложение, этот артефакт должен быть доступен из сессии.

Canvas and PDF artifact view

Рисунок 5. Локальное веб-приложение может просматривать созданные артефакты, такие как PDF, изображения и canvas-результаты из той же сессии проекта.

Именно поэтому важен веб-интерфейс. Терминального лога недостаточно для любого типа работы. Когда задача создаёт визуальные артефакты, поверхность для проверки тоже должна быть визуальной.

Цикл supervisor-student

Ещё одна важная для меня идея — это надзор.

Большинство агентов работают как один цикл: прочитать промпт, составить план, вызвать инструменты, ответить. Для небольших задач это работает, но более крупным задачам нужен второй тип интеллекта: наблюдатель, который спрашивает, действительно ли работа движется к завершению.

В AgInTiFlow я экспериментирую с лёгким паттерном supervisor-student.

Цикл student выполняет основную работу:

  • осматривает файлы
  • планирует
  • редактирует
  • запускает команды
  • генерирует артефакты
  • подводит итог

Цикл supervisor следит за сбоями:

  • повторяющиеся ошибки команд
  • отсутствующие инструменты окружения
  • слабая проверка
  • неверная маршрутизация моделей
  • плохие имена файлов или скрытые результаты
  • сводки без доказательств
  • остановка задачи до того, как реальная цель действительно достигнута

Supervisor не должен микроменеджерить каждый шаг. Он должен прерывать только при необходимости, а затем уточнять навык, набор инструментов, промпт или политику маршрутизации, чтобы student мог продолжить.

Смысл не только в надзоре за одной задачей. Смысл в том, чтобы улучшать агента после каждой задачи. Если AgInTiFlow терпит неудачу на Android, LaTeX, Git, упаковке Python, развёртывании сайта или системном обслуживании, исправление должно становиться пригодным для повторного использования.

Android app built and verified through a supervised AgInTiFlow task

Рисунок 6. Поднадзорная Android-задача собрала приложение для разделения чаевых на Kotlin/Jetpack Compose, запустила тесты, установила его в эмулятор, зафиксировала доказательства и закоммитила результат.

Именно такой цикл мне важен: не абстрактное "write code", а собрать, протестировать, установить, проверить, сделать скриншот и закоммитить.

AAPS: Prompt is code, artifact is truth

AgInTiFlow также связан с более широким проектом, который я создаю, под названием AAPS:

AAPS расшифровывается как Autonomous Agentic Pipeline Script. Его философия проста:

Промпт — это код, артефакт — это истина.

Иными словами, серьёзный агентный рабочий процесс не должен быть просто длинной инструкцией. Он должен быть конвейером с именованными блоками, входами, выходами, маршрутизацией, валидацией, восстановлением и артефактами.

Например, большой рабочий процесс может включать:

  • осмотреть проект
  • выбрать метод
  • запустить команду
  • проверить результат
  • восстановиться после известных сбоев
  • написать отчёт
  • опубликовать артефакты

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

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

Что он уже умеет сегодня

AgInTiFlow всё ещё развивается, но уже поддерживает полезный набор локальных рабочих процессов:

  • интерактивные CLI-сессии
  • локальный веб-интерфейс
  • просмотр, чтение, поиск, запись и патчинг файлов
  • выполнение shell-команд
  • режим рабочего пространства Docker
  • веб-поиск
  • сбор контекста в стиле scout
  • маршрутизацию моделей между DeepSeek, OpenAI, Venice, Qwen и mock mode
  • вспомогательные маршруты генерации изображений
  • сессии проектов и возобновление работы
  • просмотр canvas, PDF, изображений и других артефактов
  • профильно-ориентированную работу для кодинга, письма, исследований, GitHub, LaTeX, Android, сайтов, обслуживания и не только

AgInTiFlow package on npm

Рисунок 7. AgInTiFlow распространяется через npm, поэтому его можно быстро установить на локальную машину.

Что я всё ещё улучшаю

Проект ещё не завершён. Я всё ещё улучшаю:

  • хранение сессий и артефактов
  • селекторы моделей
  • рендеринг CLI
  • веб-макет
  • рабочие процессы Git и GitHub
  • профильно-специфичное поведение
  • долгий надзор
  • навыки системного обслуживания
  • документацию
  • многоязычную поддержку
  • проекты для самотестирования для каждого профиля

Но я думаю, что направление выбрано верно.

Следующий полезный интерфейс для агента будет не просто более умным чат-окном. Это будет рабочее пространство, которое может удерживать контекст, проверять доказательства, безопасно запускать инструменты, маршрутизировать между моделями и продолжать работу с того места, где остановилось.

Именно таким я хочу видеть AgInTiFlow.

Заключение

Я начал AgInTiFlow, потому что устал втискивать реальную работу в хрупкие агентные сессии и скупые ограничения.

Мне хотелось чего-то локального. Чего-то, что можно запускать из папки проекта. Чего-то, что могло бы агрессивно использовать дешёвые модели, эскалировать при необходимости, показывать артефакты, возобновлять сессии и позволять браузеру и терминалу разделять одну и ту же работу.

Проект ещё молод, но уже достаточно полезен, чтобы я использовал его для собственной сборки.

Попробовать можно здесь:

npm install -g @lazyingart/agintiflow
aginti

Идея продукта проста:

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

Leave a Reply