Hacker News Digest

Atuin Desktop — это инструмент, который объединяет документацию и исполняемые команды в едином пространстве, похожем на документ, но работающем как терминал. Он позволяет создавать и запускать сценарии, запросы к базам данных, HTTP-запросы и даже встраивать графики Prometheus, делая рабочие процессы повторяемыми, совместными и надёжными. Это решает проблему устаревшей документации и разрозненных знаний, которые часто хранятся лишь в памяти или истории команд.

Инструмент теперь полностью открыт под лицензией Apache 2.0 и включает интеграции с Kubernetes, MySQL, Git-совместимые рабочие пространства и возможности совместной работы в реальном времени. Планы развития включают удалённое выполнение, аудит, расширенные блоки и улучшенную интеграцию с облачными провайдерами.

• Пользователи отмечают полезность инструмента для документирования и выполнения команд, особенно для редких или сложных задач администрирования.
• Обсуждаются аналогичные подходы и инструменты: bash-скрипты, Jupyter Notebooks, org-mode в Emacs, runme.dev, speedrun.cc и Warp Notebooks.
• Поднимаются вопросы о безопасности, включая риски выполнения деструктивных команд из истории и необходимость подтверждения.
• Обсуждаются технические аспекты: поддержка shellcheck, формат файлов (YAML), работа с Git, удаленное и параллельное выполнение.
• Авторы отвечают на вопросы, подчеркивая гибкость подхода, планы по развитию и открытость к обратной связи.

Двухуровневая модель

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

Под-агенты без состояния

Каждый вызов — как вызов функции:

• одинаковый вход → одинаковый выход
• легко кешировать, тестировать, запускать параллельно
  Пример сообщения:

{"task": "sentiment", "data": [...], "constraints": {"timeout": 5}}

Разбиение задач

• Вертикальное: последовательные шаги (сбор → извлечение → сравнение).
• Горизонтальное: параллельные ветки (исследовать 5 конкурентов одновременно).
  Смешиваем: сначала параллельная категоризация фидбека, потом последовательная приоритизация.

Протокол общения

Каждая команда содержит:

• цель, входные данные, ограничения, формат вывода.
  Ответ: status, result, confidence, processing_time.
  Болтовни и «помни, что мы обсуждали» — нет.

Специализация агентов

• Research — поиск по базе фидбека.
• Analysis — извлечение тем и настроений.
• Summary — генерация отчётов и changelog.
  Один агент = одна чёткая функция.

Оркестрация

• Round-robin — когда порядок важен.
• Priority queue — сначала критичные фидбеки.
• Fan-out/fan-in — параллельные под-агенты, потом сбор результатов.
  Состояние хранит только основной агент; под-агенты не знают о существовании друг друга.

Управление контекстом

• Сжатие: оставляем только релевантные куски.
• Слайды: отправляем под-агенту только нужную подборку.
• Версионирование: каждый результат имеет id, чтобы легко откатиться.

Обработка ошибок

• Повторы с экспоненциальной задержкой (до 3 раз).
• Fallback-агенты: если «анализатор» упал, включаем «резервный».
• Circuit breaker: после N ошибок отключаем агента и пишем алерт.

Производительность

• Кешируем по хешу запроса.
• Параллельные вызовы без блокировок.
• Пакетная обработка: отправляем 50 фидбеков за раз, а не по одному.

Мониторинг

Отслеживаем:

• latency под-агентов,
• точность (сравниваем с разметкой),
• частота ошибок,
• объём контекста (токенов).
  Всё пишем в Prometheus + Grafana.

Уроки из продакшена

• Начинайте с 2–3 под-агентов, добавляйте постепенно.
• Пишите юнит-тесты для каждого под-агента.
• Не давайте агентам доступ к внешним API без rate-limit.
• Держите промпты в git; версионируйте как код.

Принципы

1. Простота > масштаб.
2. Чистые функции > разделяемое состояние.
3. Структурированные сообщения > свободный текст.
4. Мониторинг с первого дня > дебаг в проде.

Частые ошибки

• «Умные» под-агенты с памятью → гонки и непредсказуемость.
• Слишком большой контекст → таймауты и лишние токены.
• Отсутствие таймаутов → зависшие цепочки.
• Игнорирование кеширования → лишние $$$ на API.

Как начать

1. Определите 1–2 ключевые задачи (например, «суммаризировать фидбек»).
2. Создайте под-агентов: research, summarize.
3. Напишите структурированные схемы входа/выхода.
4. Покройте тестами, добавьте метрики.
5. Подключите к реальному потоку данных и наблюдайте.

• Автор делится опытом построения практичных «агентов» как чистых функций без состояния и истории разговоров, что экономит токены и упрощает отладку.
• Поддержка: дешёвые/локальные модели на 75 % задач, жёсткое разбиение на под-агентов, явное описание шагов вместо «умных» решений.
• Критика: часть читателей считает описанное не настоящим агентством, а обычным workflow с LLM-вызовами; стиль текста вызывает раздражение как «AI-generated».
• Практические инструменты: Claude Code (файлы .claude/agents), AWS Lambda + Step Functions, Spring AI, кеширование промптов.
• Сообщество обсуждает, где грань между «агентом» и «инструментом», просит примеров и данных, а также делится ссылкой на оригинальный пост Anthropic.

• Цель: создать единый фреймворк для тестов производительности Ollama на двух конфигурациях:

  1. настольная материнка (1×CPU, 1×GPU, 128 ГБ ОЗУ);
  2. кластер из 4 узлов (по 64 ГБ ОЗУ, 1×GPU, 10 GbE).

• Методика

  • Одинаковые образы Docker/Podman на обеих платформах.
  • Набор моделей: llama3.1:8b, codellama:13b, mistral:7b, qwen2.5:32b.
  • Метрики: t/s, TTFT, TPS, Watts, $/1k токенов.
  • Повторять 3×, усреднять, выводить ±σ.

• Автоматизация

  • Ansible-playbook разворачивает Ollama, node-exporter, prometheus, grafana.
  • Скрипт run-suite.sh последовательно запускает каждую модель с 512, 2 048, 4 096 токенов ввода/вывода.
  • Результаты пишутся в CSV и публикуются в PR как results-<platform>-<date>.md.

• Сравнение

  • Построить графики «токен/с vs. Watts» и «$/1k токенов vs. модель».
  • Выделить break-even точку, где кластер начинает выигрывать по стоимости при одновременной обработке ≥3 моделей.

• AMD Framework Desktop (AI Max+ 395) показывает 2,5–3× прирост к RTX 4000 SFF Ada 20 ГБ, но уступает 9950X из-за низкого TDP.
• Для локального запуска LLM рекомендуют RTX 3090 (24 ГБ) как лучшее ценовое решение, либо Apple/AMD при необходимости >20 ГБ памяти.
• ROCm и Linux-стек работают стабильно, но потенциал iGPU/NPU ещё не раскрыт; тесты велись в llama.cpp.
• Для масштабирования предлагают distributed-llama, Exo и llama.cpp-RPC, а также Oculink/eGPU-конфигурации.
• Продукт выглядит нишевым: ML-инференс дома, но для «обычных» задач лучше Threadripper или сервер.