Hacker News Digest

Thomas Ptacek утверждает, что каждый должен написать агента на основе больших языковых моделей, чтобы по-настоящему понять эту технологию, независимо от своих скептических или восторженных взглядов. Как и обучение езде на велосипеде, практический опыт дает более глубокое понимание, чем абстрактные концепции. Автор подчеркивает, что создание агента оказывается удивительно простым процессом, который приносит больше практической пользы, чем можно ожидать.

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

• Обсуждение показало, что большинство участников считают, что писать агентов вручную — это не только учебное упражнение, но и способ глубже понять, как работают LLM и инструменты вроде MCP.
• Участники подчеркнули, что даже простой агент может быть реализован всего в несколько строк кода, но при этом важно понимать, что именно делает его "агентом" — способность к итерации и само-улучшению.
• Обсуждались риски безопасности и контроля при использовании агентов, особенно в контексте предоставления им доступа к оболочке и файловой системе.
• Также обсуждались вопросы, связанные с тем, что агенты могут быть использованы для решения задач, которые еще не решены, и что это может быть более ценно, чем попытка создать еще один чат-бот или инструмент для уже решенной задачи.
• В конце обсуждение перешло к тому, что важно помнить, что даже если вы не собираетесь писать агентов для продакшена, опыт их создания может быть полезен для понимания того, как работают инструменты, которые вы используете, и как они могут быть использованы или злоупотреблены.

Контекстная инженерия для AI-агентов — это ключевой подход, позволяющий быстро итеративно улучшать производительность без переобучения моделей. Опыт разработки Manus показал, что вместо обучения end-to-end модели эффективнее использовать способность современных LLM к обучению в контексте, что сокращает цикл улучшений с недель до часов и делает продукт независимым от прогресса базовых моделей.

Важнейший метрикой для продакшн-агентов является hit rate KV-кеша, напрямую влияющий на задержки и стоимость. Агент работает итеративно: на каждом шаге контекст растёт за счёт добавления действий и наблюдений, в то время как вывод остаётся коротким. Оптимизация этого процесса через структурирование контекста позволяет снизить вычислительные расходы и ускорить выполнение задач.

• Предлагается использовать файловую систему как память для агентов через директорию .agent/ для хранения задач, планов и других данных.
• Проводятся параллели между лучшими практиками для AI-агентов и управления кодом: избегать раздувания, не удалять плохие коммиты, не рефакторить слишком часто.
• Отмечается разница в стимулах для кеширования: на фиксированных тарифах выгодно провайдеру, на поминутных — пользователю.
• Рекомендуется простота в инструментарии, согласующаяся с подходом OpenAI Codex, например, использование update_plan для отслеживания прогресса.

DeepSeek-V3.1-Terminus — это обновлённая версия модели, улучшающая языковую согласованность и производительность агентов. Теперь модель реже смешивает китайский и английский языки и почти не генерирует случайные символы, что повышает стабильность ответов. Агенты для работы с кодом и поиска стали значительно эффективнее.

Обновление доступно через приложение, веб-интерфейс и API, а открытые веса опубликованы на Hugging Face. Модель демонстрирует лучшие результаты в бенчмарках по сравнению с предыдущей версией, обеспечивая более предсказуемые и качественные ответы.

• Обсуждается новая модель DeepSeek-V3.1-Terminus, приведены рабочие ссылки на её документацию и страницу на Hugging Face.
• Участники отмечают улучшения в производительности, согласованности языка (меньше смешивания CN/EN) и отсутствие случайных символов.
• Поднимается вопрос о сравнении DeepSeek с моделью Qwen, на который предлагается проводить бенчмаркинг под конкретные задачи.
• Высказывается пожелание о создании удобного ресурса для отслеживания актуальных моделей, их версий, производительности и требований к железу.
• Отмечается преимущество модели в виде лицензии MIT, позволяющей запускать её на собственном оборудовании и коммерциализировать.

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

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

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

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

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

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

• Kilo превысил 1 трлн токенов/мес в OpenRouter; Cline, Roo, Kilo растут из-за дросселирования Cursor и Claude.
• Стартапы рассчитывали: себестоимость токенов упадёт на 90 % за год, маржа станет +80 %.
• Вместо этого цена токенов фронтир-моделей не упала, а расход токенов на задачу вырос.
• Причины: модели стали крупнее, появились «длинные мысли» и агенты, которые запускают цепочки вызовов.
• Итог: расход на разработчика уже $20–40 к/мес и стремится к $100 к/год.

• Почти все участники считают цифру в $100 000/год на разработчика безосновательной и преувеличенной.
• Основной аргумент: стоимость инференса либо быстро упадёт, либо станет дешевле запускать opensource-модели локально.
• Многие отмечают, что уже сейчас $100–200/мес хватает большинству, а при росте нагрузки выгоднее купить железо, чем платить за облако.
• Поднимается тема «токеномики»: расходы растут из-за параллельных агентов и увеличения контекста, но это пока не дотягивает до $100 000.
• Часть комментаторов указывает, что крупные компании вряд ли вернутся к on-prem, а будут торговаться за долгосрочные контракты у дешёвых провайдеров.

Model Context Protocol (MCP) стал стандартом для вызова инструментов при создании агентов, но сам LLM не обязан «понимать» MCP. При «инжиниринге контекста» вы даете модели нужные данные и доступ к инструментам; стандарт MCP лишь унифицирует подключение к ним. Для модели это просто список определений инструментов — она не знает о реализации, и это нормально.

MCP дает доступ к тысячам инструментов без кастомных интеграций и упрощает агентный цикл: разработчик вызывает инструменты, а LLM лишь генерирует текстовый фрагмент с именем инструмента и параметрами. LLM не «умеет» вызывать функции — он предсказывает текст, который ваша система парсит, выполняет реальный вызов и возвращает результат как новое сообщение.

Пример: при наличии инструмента get_weather(location) на вопрос «Какая погода в Сан-Хосе?» модель может сгенерировать: { "name": "get_weather", "input": { "location": "San Jose, CA" } } Агент выполняет этот вызов и передает ответ обратно модели. Разделение обязанностей: LLM предсказывает, система исполняет.

MCP стандартизирует подключение к источникам (инструменты, подсказки, ресурсы, примеры) через хост-приложение с MCP-клиентом и сервера MCP, которые экспонируют инструменты. Взаимодействие с LLM не меняется — меняется способ, как инструменты подаются и вызываются «под капотом». Для того же вопроса модель увидит тот же список инструментов; решение, как именно вызвать, остается за разработчиком (с MCP — через MCP).

Преимущества MCP — для разработчика: управление ростом числа инструментов, переиспользование, единые форматы, быстрые подключения к новым системам без переписывания кода. LLM не узнает о MCP, если вы сами не укажете это в системном промпте; его роль — сгенерировать фрагмент вызова, а ваша — выполнить его.

• Участники сомневаются в необходимости MCP: если чат-боты не станут главным интерфейсом, спецификация может оказаться ненужной.
• Критика сосредоточена на локальной модели «скачай-и-запусти MCP» — её считают избыточной; крупным компаниям достаточно удалённого MCP или прямых REST-вызовов.
• Большое количество доступных инструментов снижает точность агентов; лучше строго ограничить набор и активно подсказывать, как их использовать.
• MCP воспринимается как поспешный стандарт от Anthropic, слабо продуманный в части безопасности и авторизации.
• Некоторые видят перспективу в «USB-аналогии»: MCP может стать универсальным способом подключения систем друг к другу, выходя за рамки LLM.

Keep in mind that default Gmail allows webhooks for any changes (email received but also changing labels, etc), for free using Gmail pubsub. I use it a lot because it's the only way of getting programmatic notifications from credit card purchases (turn on purchase alerts to all c