HACKERNOON · AI / AGENTS / LLM

AI-статьи недели с HackerNoon

Восемь методов: проверять действия агента, сохранять состояние и измерять весь рабочий процесс.

26.10–02.11.20268 основных статей3 на радаре
О чём пишут

На этой неделе авторы разбирают ошибки на границах AI-приложений: между согласием и выполнением, серверным снимком и черновиком, потоком модели и интерфейсом. Каждую границу можно проверить отдельно. Сравнения инструментов тоже требуют аккуратности: короткий ответ ещё не означает меньший счёт, а хороший результат на открытых задачах не заменяет отложенную проверку. Ниже собраны методы с конкретными шагами и названными ограничениями.

01

Восемь методов для AI-приложений

01

Привяжите согласие человека к точной операции агента

Raju DandigamHackerNoonai-agentshuman-in-the-loop
О чём

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

Главное
  • В протоколе автора предложение операции, запрос согласия и разрешение хранятся отдельно; intentHash связывает разрешение с точными аргументами операции.
  • Перед выполнением проверяются срок действия, текущие полномочия и consumedAt — отметка об использовании разрешения. Блокировка записи и outbox, очередь будущих действий, объединены в транзакцию.
  • Изменение канонических аргументов требует нового согласия. Если допустимы исключения, их нужно явно описать в политике.
  • Это схема протокола: схему входа, хранилище и проверку политик придётся реализовать в своём приложении.
Как применить
  • Возьмите один вызов инструмента без внешнего эффекта и добавьте proposalId, intentHash, expiresAt и consumedAt по схеме статьи.
  • Напишите проверки изменения суммы после согласия, просроченного разрешения и двух одновременных попыток его использования.
  • Проверка: изменённые и просроченные операции отклонены, повторное использование разрешения не создаёт второй эффект.
02

Пусть тип ответа модели выбирает следующий узел графа

Huy NguyenHackerNoonai-agentarchitecture
О чём

Если модель выбирает действие строкой, маршрутизатору приходится разбирать её ответ и отдельно проверять параметры. Автор предлагает Pydantic-модели: тип результата задаёт следующий узел графа, а проверенные поля передаются через состояние.

Главное
  • Модель возвращает один из типов: Answer, SearchKnowledgeBase, RunTool или Escalate. Описания этих типов помогают выбрать действие.
  • Функция _route_for выбирает узел по типу результата; её можно тестировать без вызова модели и запуска графа.
  • Для поиска используется уже сформированное поле decision.query, без повторного разбора всего обращения.
  • Код опирается на базовые классы из предыдущих частей. Аннотации типов сами по себе не гарантируют, что обработаны все варианты: нужна отдельная проверка.
Как применить
  • Наша адаптация: в небольшом маршрутизаторе замените строковый intent объединением Pydantic-моделей.
  • Вынесите выбор узла в отдельную функцию и проверьте каждый тип результата, включая Escalate — передачу запроса человеку.
  • Проверка: у каждого допустимого типа есть проверенный переход, неверная структура ответа отсекается на границе.
Тип результата задаёт маршрут: Answer, SearchKnowledge, UseTool и Escalate.
Тип результата задаёт маршрут: Answer, SearchKnowledge, UseTool и Escalate.
03

Сначала сократите ответ инструмента, затем сравнивайте MCP и CLI

Kaan BobaçHackerNoonmodel-context-protocolcli
О чём

Короткий ответ инструмента уменьшает объём текста для модели, но ещё не доказывает преимущество MCP или CLI. Автор сравнивает чтение Jira и GitHub, а также проверку выгрузки CSV; часть выигрыша оказывается результатом выбора полей.

Главное
  • В пятишаговой браузерной проверке MCP вернул 731 токен текста, CLI — 744. Для подсчёта использовалась кодировка o200k_base.
  • В отдельном опыте выбор только номера и заголовка пяти GitHub PR сократил ответ с 973 до 107 токенов. Оба ответа получены через gh: выигрыш даёт отбор полей.
  • Состояние страницы и скачанные байты CSV подтверждают разные результаты. Сравнивать расходы можно лишь при одинаковой проверке выполнения задачи.
  • Измерен только возвращённый текст, без вывода модели и общего счёта. Jira использует синтетические данные, браузер в опытах с кодом уже запущен.
Как применить
  • Для одной задачи чтения PR запросите богатый JSON, затем только number,title через gh --json и --jq. Проверьте, что нужные факты сохранились.
  • Посчитайте токены обоих ответов через tiktoken с o200k_base; отдельно запишите полноту результата и ошибки.
  • Проверка: число токенов возвращённого текста при сохранении всех фактов, необходимых выбранной задаче.
Один CLI gh: 973 токена для богатого JSON и 107 для номера и заголовка пяти PR. Это размер возвращённого текста, не счёт модели.
Один CLI gh: 973 токена для богатого JSON и 107 для номера и заголовка пяти PR. Это размер возвращённого текста, не счёт модели.
04

Проверяйте факты после правки AI-текста

Efe GencHackerNoonaiopen-source
О чём

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

Главное
  • Команда npx ai-slop-linter --compare before.md after.md ищет расхождения в числах, версиях, датах, ссылках, цитатах, фрагментах кода и именах.
  • При расхождении команда завершается с кодом 1. Skill плагина запускает сравнение после каждого переписывания и считает неуспешную проверку основанием остановиться.
  • На открытых задачах авторский инструмент получил 58,67 из 60. На отложенном наборе четыре варианта набрали не меньше 29,67 из 30: этот набор не разделяет лидеров.
  • Проверка отмечает изменённые факты, но не решает, оправдана ли правка и хорошо ли написан текст. Из результатов нельзя вывести общий рейтинг инструментов.
Как применить
  • Сохраните README до правки в before.md и выполните npx ai-slop-linter README.md.
  • После правки сохраните after.md и запустите npx ai-slop-linter --compare before.md after.md; разберите каждую потерю.
  • Проверка: число потерянных фактов и время ручной проверки до и после добавления линтера.
Авторский benchmark на 12 открытых задачах и пример потерянных фактов после правки. Отложенный набор не разделяет лидеров.
Авторский benchmark на 12 открытых задачах и пример потерянных фактов после правки. Отложенный набор не разделяет лидеров.
На графике: на открытых задачах ai-slop-linter получил 58,67/60; Humanizer с вызовом по имени — 56/60. Пример справа показывает потерю даты, номера версии, числа клиентов и оговорки «до 40%». Это проверка фактов, а не оценка качества прозы.
05

Считайте токены всей задачи, а не степень сжатия

Venkata SangarajuHackerNoonai-agentscontext-compression
О чём

Сжатие ответа инструмента не экономит токены, если агент затем целиком запрашивает исходник. Автор проверил MCP-прокси, сокращавший ответы на 70–94%, и заменил полное восстановление поиском нужных фрагментов.

Главное
  • На 108 задачах исходный прокси увеличил число входных токенов на 17%: в контекст попадали и сжатый ответ, и восстановленный файл.
  • Поиск внутри сохранённого ответа вместо полного expand убрал этот перерасход. В отдельном наборе из 54 задач разработки с реальными серверами экономия составила лишь 0,3%.
  • Автор добавляет инструмент восстановления только после первого сжатия и сообщает об изменении списка через MCP-уведомление notifications/tools/list_changed. Так описание лишнего инструмента не занимает контекст заранее.
  • Тесты охватывали короткие задачи и преимущественно локальную Qwen3 4B. Они не показывают экономию для больших моделей и длинных сессий.
Как применить
  • Наша адаптация: на одинаковых задачах сравните исходные ответы MCP и сжатые ответы с поиском или чтением диапазона строк.
  • Проверьте передачу переменных окружения в дочерний сервер. Объявляйте инструмент восстановления только после первого сжатия.
  • Проверка: считайте все входные токены на завершённую задачу; отдельно фиксируйте правильность ответа и потерю нужных данных.
Прокси сократил отдельный ответ на 94%, но в наборе из 108 задач увеличил число входных токенов на 17%.
Прокси сократил отдельный ответ на 94%, но в наборе из 108 задач увеличил число входных токенов на 17%.
06

Read-only инструмент тоже может стереть черновик

Raju DandigamHackerNoonreactjavascript
О чём

В React-редакторе чтение через WebMCP заменяло несохранённое поле данными сервера. Причина оказалась в общем merge-пути: он защищал ввод во время запроса, но терял правки, сделанные раньше.

Главное
  • Автор воспроизвёл ошибку в Trip Workbench на commit 4b3f370: черновик исчезал при чтении, без запроса сохранения.
  • При обновлении сравниваются три версии: последняя сохранённая, локальный буфер и новый снимок сервера. Если локальное поле отличается от сохранённого, его оставляют в буфере.
  • Ответ со старой revision не должен заменять уже принятую новую версию. Конфликт локальной и серверной правки нужно показать человеку.
  • Локальный вариант прошёл девять сценариев координации с подставными ответами API. Работа через native и model-driven WebMCP, то есть с выбором инструмента моделью, ещё не проверена.
Как применить
  • Наша адаптация: измените поле до read-запроса, задержите ответ управляемым promise и проверьте сохранность локального ввода.
  • Затем доставьте revision 1 после принятой revision 2. Проверьте текст в буфере, dirty flag — признак несохранённых правок — и принятую revision.
  • Проверка: число пройденных сценариев сохранения локального ввода и отсутствие отката revision.
07

Чините синтаксис JSON отдельно от ошибок рассуждения

nayankoteHackerNoonaismall-models
О чём

Автор разделяет два сбоя между шагами LLM: сломанный JSON с верным содержимым и корректный JSON с неверным ответом. Небольшая модель помогает в первом случае; во втором нужно повторить исходную задачу.

Главное
  • До парсинга проверьте причину остановки: stop_reason у Claude или finish_reason у OpenAI. Если ответ обрезан лимитом токенов, недостающее содержание нельзя восстановить расстановкой скобок.
  • Автор предлагает последовательность: обычный парсер, разрешённые безопасные исправления, затем небольшая модель с узкой задачей исправить синтаксис JSON.
  • После исправления снова проверяются схема и смысл: существование ID, полнота разделов и неожиданные пустые списки. При смысловой ошибке нужно повторять исходный шаг рассуждения.
  • Готовой проверки сохранности всех ключей и значений в статье нет. Исправленный моделью JSON остаётся недоверенным входом.
Как применить
  • Возьмите сохранённые невалидные ответы своего пайплайна и разделите их на усечённые, синтаксически сломанные и семантически неверные.
  • Прогоните полные ответы через парсер, разрешённые исправления и узкий промпт из статьи; сохраняйте исходник, исправленный JSON и результат повторной валидации.
  • Проверка: доля успешно восстановленных ответов без изменения содержания; стоимость и задержка с учётом повторов исходной задачи.
08

Проверяйте потоковый AI-интерфейс управляемыми событиями

Raju DandigamHackerNoonreactcypress
О чём

Сбой спиннера, повтор ответа или поздний токен после отмены можно воспроизвести без живой модели. Автор выносит поток в зависимость ChatStream и управляет последовательностью событий из компонентного теста Cypress.

Главное
  • Компонент получает ChatStream вместо прямого обращения к SDK провайдера. Поток возвращает AsyncIterable — последовательность событий, поступающих асинхронно.
  • Тестовая фабрика отправляет события по одному через push и завершает поток через close. Стабильные ID сообщений и вызовов инструментов позволяют проверять отсутствие дубликатов.
  • Для проверки отмены тест нажимает Stop, отправляет ещё один token и убеждается, что текст сообщения не изменился.
  • Приложение и протокол учебные. Компонентные тесты не проверяют прокси, сетевую доставку и качество ответов модели.
Как применить
  • Наша адаптация: передайте поток в React-компонент через ChatStream и используйте управляемый тестовый поток по схеме createTestStream.
  • Проверьте начало ответа, постепенное появление текста и завершение инструмента. Отдельно воспроизведите поздний токен после Stop.
  • Проверка: повторяемость тестов в CI и число обнаруженных ошибок отмены, повторных событий и переходов состояния.
02

На что обратить внимание

Связывайте AI-правки с требованиями

Автор предлагает связать требования с кодом и тестами через аннотации StrictDoc и Tracey, а расхождения проверять в CI. Связь инструментов показана не полностью; учебный пример JWT требует отдельной проверки перед production.

Читать ↗

Сложный RAG нужно сравнивать с простой базой

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

Читать ↗

Локальная модель на CPU: проверьте свой сценарий

Автор измерил Nemotron на конкретном Xeon и небольшом наборе запросов. Относительные даты лучше разрешать кодом; результаты чистого синтетического аудио не описывают шумный микрофон.

Читать ↗
03

План на неделю

Как собран выпуск

Поисковый индекс HackerNoon вернул всю неделю: 233 статьи. Просмотрены 60 кандидатов, 24 прочитаны целиком. После проверки применимости и попытки опровержения выбраны восемь основных статей; ещё три вынесены на радар. Непрочитанные материалы сохранены в резерве.

Окно26.10–02.11.2026 · 7 дней
Собрано2026-11-02T07:25:12.599122Z
ИсточникПоисковый индекс HackerNoon; вся неделя, полное покрытие
ОтказыНет; тексты доступны у всех 233 статей
Счётчик прочтений209 из 233; в отборе не использовался
В выпуске8 основных статей и 3 на радаре
×Исходная иллюстрация
Открыть статью ↗