Восемь способов проверить работу агента, сохранить контекст и упростить известный процесс.
🗓 19—26 октября⚡ 8 приёмов👀 3 на заметку
О чём говорят
У агентов стало больше инструментов и соседних сессий, поэтому полезно проверить, какие из них нужны задаче. В выбранных разборах повторяется проверка по сохранённым результатам: сравнить одинаковые задачи, открыть лог, показать сценарий перед слиянием. Второй приём — сохранить понятные границы: где достаточно обычного кода, где нужен отдельный агент и что именно передаётся между сессиями. В карточках ниже оставлены шаги и ограничения; обещания скорости из рекламных постов не используются.
⚡
Главные приёмы недели
01
Убирать субагентов по одному под контролем проверок
Каждой роли выделяли отдельного агента и передавали ему пересказ работы.
→
Стало
Одну роль объединяют с главным агентом: инструкции становятся skill, вызовы API — инструментами.
Почему это полезно: Меньше передач означает меньше мест, где может потеряться контекст; сохранять изменение стоит только после сравнения.
⚡ Попробовать за вечер
Соберите 10 знакомых задач и сохраните результаты исходного варианта.
Перенесите инструкции одного субагента в skill, а его API — в инструменты; повторите те же задачи несколько раз.
Сравните ошибки по каждой задаче, время и расход; откатите объединение, если появились регрессии.
Ограничение: Десять примеров — стартовая проверка; важны повторные прогоны и отдельные задачи, которые перестали проходить.
из первоисточника
Сверху задача разделена между тремя агентами; снизу один агент выполняет работу, второй проверяет. Это два разных способа разделить проблему и контекст.
Новый промпт принимали после нескольких удачных ответов.
→
Стало
Обе версии проходят одни и те же задачи с повторениями, а каждый прогон сохраняется в JSONL.
Почему это полезно: По сохранённым ответам можно разобрать регрессии; средняя оценка уже не скрывает, какая задача сломалась.
⚡ Попробовать за вечер
Сохраните 5–10 своих случаев в tasks.jsonl: вход, ожидаемые свойства ответа и идентификатор задачи.
Запустите две версии с одинаковыми настройками и несколькими повторениями; начните с проверок JSON, regex или тестов.
Сравните результаты по задачам и прочитайте неудачные ответы; маленькую выборку не считайте доказательством небольшого улучшения.
Ограничение: В статье учебный fake_model и четыре задачи; определения отдельных функций опущены. Это метод, а не готовый запуск или доказанный выигрыш.
из первоисточника
Искусственный пример на четырёх задачах: старый промпт — 60%, новый — 90%; разность +30 п. п., 95% интервал от +5 до +55 п. п. Широкий интервал не доказывает реальный выигрыш.
Изменения между двумя рабочими сессиями переносили вручную вместе с длинным пересказом.
→
Стало
Именованные сессии обмениваются короткими сообщениями через штатный cross-session messaging.
Почему это полезно: Можно передать конкретное изменение контракта, сохранив отдельную историю и полномочия каждой сессии; экономия токенов не гарантируется.
⚡ Попробовать за вечер
Откройте две свои сессии в разных worktrees и проверьте доступных соседей через /peers.
Разрешите входящие сообщения только принимающей сессии: --settings '{"crossSessionInbound":"accept"}'.
Попросите отправить точное изменение API; проверьте получение, корректность зависимого кода и сохранение permission prompts.
Ограничение: Нужна поддерживающая версия Claude Code. Входящие сообщения расходуют usage и сохраняют проверки разрешений получателя.
Агент решал, что выбрать, куда сходить и когда завершить сборку отчёта.
→
Стало
Известная цепочка retrieval → prompt → LLM → validation → отчёт выполняется по заданным правилам.
Почему это полезно: Сбой легче привязать к этапу, а один и тот же набор входных событий можно воспроизвести при разборе.
⚡ Попробовать за вечер
Возьмите локальный набор событий с id и URL и задайте фиксированный порядок обработки в небольшом скрипте.
Оставьте модели только синтез; проверьте структуру JSON и сохранность ссылок перед передачей результата.
Повторите запуск с дубликатом события, timeout и неверным JSON; проверьте место ошибки и отсутствие повторной доставки.
Ограничение: Кода и репозитория нет. Сбои у автора ещё предстоит проверить; фиксированный процесс не делает текст модели достоверным.
из первоисточника
Пять этапов схемы автора: получить события → собрать промпт → синтезировать ответ → проверить JSON и ссылки → доставить дайджест. Точки сбоя и статус доставки проверяются отдельно.
Сохранить десять своих задач и сравнить одну роль с субагентом и без него.
до среды
На тестовом PR потребовать лог проверки и короткую запись пользовательского сценария.
до пятницы
Прогнать один отчёт с timeout, дубликатом и неверным JSON; проверить повторную доставку.
до воскресенья
#
Как собран выпуск
В корпусе 6044 уникальных поста; решения приняты по 78 кандидатам, включая первые 60 по распространению. Полностью вычитаны 20 источников, восемь приёмов прошли отдельную попытку опровержения. Непросмотренный остаток сохранён в локальном архиве.
Окно сбора: 19—26 октября 2026. Источники: Nitter RSS, публичное зеркало Netbub в headless и native X через Playwriter; первичные статьи прочитаны через Firecrawl. Исправленные OR-запросы используют группировку и явный min_faves. Широкая исходная выборка сохранена; старые оригиналы свежих репостов вынесены за окно.
Все цели прошли порог скилла: полное покрытие либо не менее пяти суток фактической глубины. Большинство остановлены на глубине пяти суток и не объявлены полными: ранняя часть окна может быть представлена не целиком. Небольшие ленты rasbt и karpathy исчерпаны поиском. Пропущенных из-за доступа целей нет; у одного поста отсутствуют метрики, он не участвовал в ранжировании.
Три карточки содержат просмотренные исходные схемы. Остальные оставлены текстовыми: вложений нет либо иллюстрация закрепляет неподтверждённые рекламные обещания.
из первоисточника
