Hacker News Digest

Всё, что я знаю о хорошем системном дизайне

Системный дизайн — это то, как мы собираем сервисы, а не строки кода. Его примитивы: серверы, БД, кэши, очереди, прокси и т.д.

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

Состояние и его минимизация
Сложность — в управлении состоянием. Stateless-сервисы (например, конвертер PDF → HTML) перезапускаются и живут вечно. Stateful-сервисы могут «испортиться» и требуют ручного лечения. Поэтому:

• Один сервис пишет в БД, остальные общаются с ним по API/событиям.
• Чтение иногда проще делать напрямую, но писать — только через «владельца» данных.

Базы данных
Главный компонент.

• Схема: читаемая человеком, достаточно гибкая, но не «всё в JSON».
• Индексы: под самые частые запросы, не больше.
• Узкие места: обращения к БД часто тормозят всё.

• Сложность ≠ хороший дизайн: большинство участников согласны, что переусложнённые системы часто свидетельствуют о слабом проектировании, но на собеседованиях это лучше не озвучивать.
• Главный критерий — пригодность (fit for purpose): универсальных «правильных» архитектур не существует, нужно исходить из задач команды и бизнеса.
• Простота и KISS ценятся выше модных паттернов; монолит или «скучные» технологии часто эффективнее микросервисов и самописных очередей.
• Ключевые боли — синхронизация состояний и транзакционность между сервисами; чем меньше распределённого состояния, тем проще жить.
• Не забывать людей: Conway’s Law и топология команд влияют на архитектуру не меньше, чем технические решения.

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

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

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

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

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

{"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.