Hacker News Digest

AX — это декларативная платформа для запуска агентных задач в масштабе, построенная на Agent Substrate. Она изолирует задачи в sandbox-окружениях, управляет их жизненным циклом и позволяет запускать миллиарды одновременных агентов на одном кластере благодаря лёгким актёрам и плотному мультиплексированию ресурсов. Каждая задача описывается в YAML-файле (например, task.yaml), где указываются workspace (с Git-репозиториями или генеративным описанием окружения) и цель задачи. После применения конфигурации через ax apply система создаёт workspace и задачу, после чего можно отслеживать её статус, подключаться по SSH, выполнять команды, приостанавливать и возобновлять выполнение — всё с субсекундным временем восстановления из спящего режима.

AX специально разработан для агентных workloads, которые отличаются от микросервисов и batch-задач: они сохраняют состояние, делают вызовы к моделям и внешним инструментам, могут простаивать ожидая ответа и тратят ресурсы, если не управляются. Платформа решает эту проблему через четыре примитива: задачи, workspace, сетевые политики и модели, обеспечивая декларативное управление. Благодаря генеративным возможностям, окружение можно настроить просто описав его на английском (например, «Set up a Python 3 development environment»), после чего AX сам подготовит его. Это делает AX идеальным для исследователей и разработчиков: от интерактивного программирования и Jupyter-ноутбуков до масштабного обучения с подкреплением и оценки агентов в воспроизводимых песочницах. AX минимален, эргономичен и ориентирован на joyful workflow — чтобы фокус оставался на исследовании, а не на инфраструктуре.

Обсуждение ставит под сомнение простоту AX: требуется полный кластер Kubernetes, контейнерный реестр и доступ к Agent Substrate API, что делает его менее доступным. AX дублирует возможности Kubernetes, создавая избыточный слой и заставляя писать сложные YAML без уникального функционала. Демонстрация показывает лишь паузу и возобновление задачи, не раскрывая реальных сценариев применения. Главная сложность в оркестрации агентов — определение их состояния и автоматическое реагирование, требующее надёжного мониторинга. У опытных пользователей уже есть аналогичные решения (Mastra, Clrk), предоставляющие контроль над сетью и изоляцию, снижающие необходимость в AX. Некоторые предпочитают аппаратную сегрегацию (мини‐ПК) для изоляции агентов. Название «Google’s AX» вводит в заблуждение — нет официальной поддержки Google или DeepMind. Пользователи недовольны объёмными YAML‐конфигами и предлагают более простые способы описания задач. Инструменты вроде Scion, LangGraph или kagent предлагают более зрелый и интегрируемый подход. Agent Substrate уже покрывает изоляцию, ресурсное планирование и сетевой контроль, делая эти функции базовыми для платформ агентов. Отсутствуют публичные бенчмарки и сравнения производительности, требуются эмпирические данные. Экосистема фрагментирована: каждый разрабатывает собственный фреймворк, что приводит к повторному изобретению решений.

Современные терминалы ограничены решениями, принятыми ещё в 1980-х, и состоят из четырёх компонентов: эмулятора терминала, псевдотерминала (PTY), оболочки (shell) и запускаемых программ. Автор отмечает, что внутренняя структура терминалов — это "куча", где многие решения невозможно изменить из-за исторического наследия. В качестве примера приводится цитата Джулии Эванс: "Внутренности терминалов — это беспорядок. Большая часть этого именно такая, потому что так кто-то решил в 80-х, и теперь это невозможно изменить".

В качестве альтернативы традиционному терминалу автор предлагает использовать Jupyter Notebook как модель для будущего терминала, предлагающую такие возможности, как высококачественное рендеринг изображений, функцию "перезапустить с начала" и возможность редактирования представлений кода и вывода. Статья описывает четыре этапа создания такого терминала: транзакционную семантику, постоянные сессии, структурированный RPC и интерфейс, похожий на Jupyter.

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

• Локальный стек: Ollama (LLM), assistant-ui (веб-интерфейс), Apple container (изолированные ВМ), Playwright (браузер), coderunner (MCP-сервер с Jupyter).
• Цель: чат, запуск кода и доступ в интернет без облаков и утечек данных.
• Проблемы:
  – Модели Ollama пока не поддерживают вызовы инструментов.
  – Создание нативного Mac-приложения провалилось: a0.dev заточен под iOS, Electron + NextJS оказались геморроем.
  – Apple container часто падает с Trap; помогает pkill + перезапуск.
• Решения:
  – Веб-версия assistant-ui через ai-sdk с выпадающим списком моделей (локальных и облачных).
  – Jupyter в изолированной ВМ, доступен по MCP: http://coderunner.local:8222/mcp.
  – Конфиг для Claude Desktop: "coderunner": { "httpUrl": "http://coderunner.local:8222/mcp" }.

• Участники восхищаются локальной, «песочной» архитектурой для приватного AI-воркспейса и инструментом coderunner, но отмечают, что узкие места — это не только софт, но и «железо»: 80B-модели требуют ≥80 ГБ быстрой RAM, что доступно разве что на RTX 4090 или Strix Halo.
• Критичным становится слой знаний: RAG над личными файлами требует вектор-БД, а значит — много диска и оперативки; Docker-обёртка или docker compose up -d просится как минимальный способ разворачивания.
• Пока локальные модели — скорее «увлекательное хобби» (медленно, глючно, нужен тюнинг), чем рабочий инструмент; облачные API (Cerebras, Groq) дают 1000 ток/с, но подрывают приватность.
• Сообщество просит готовый «всё-в-одном» стек: веб-поиск, голосовой режим, image-gen, лёгкий switch «локально ↔ облако» без потери данных.
• Несколько участников делятся своими решениями: Kasm + Ollama, Open WebUI, MLX-электрон-приложение, Synology-NAS-контейнеры, браузерный LLM без установки.