🔥 Завтра жжём токены — бесплатно
8 марта Lovable открывается на 24 часа без оплаты и без расхода кредитов. Просто заходишь и строишь.
Я не собираюсь тратить это впустую — за сутки вполне реально:
▫️ Написать идею текстом
▫️ Довести до рабочего прототипа через чат
▫️ Залить на GitHub
▫️ И уже дальше допиливать нормально
Это и есть правильный способ использовать такие акции — не “потыкать и забыть”, а выйти с чем-то конкретным в руках.
Бонусом дают $100 в кредитах Claude + $250 от Stripe. Щедро.
Акция стартует 8 марта в ~8:00 утра по МСК и длится ровно сутки.
→ shebuilds.lovable.app/build-march-8
Погнали 🚀

Как вам такая работа в Loveble? Заставляю Claude Sonet 4.6 проверять работу и писать промпты для фикса через браузер Comet

Perplexity запустили компьютер — и он реально хорош.

Сделал вот такое приложение за 5 голосовых сообщений. Deploy пока нет, но скорее всего появится позже.

Главное отличие от других подобных инструментов:
AI встроен нативно. У меня есть подписка Perplexity — я попросил AI искать информацию, добавлять её, обновлять, делать поиск прямо в приложении. Он всё сделал. Никаких API-ключей не нужно, всё работает по моей подписке.

Выставил задачи по расписанию: находить новые инструменты, формировать дайджесты — всё работает.

Для чего лучше всего:
Бизнес-приложения. Куча интеграций из коробки, можно добавлять скиллы из маркетплейса. Они все заточены под бизнес-задачи: SEO, работа с данными, анализ и т.д.

Про кредиты:
Дают бонусные 4000 кредитов. Я их все потратил на это приложение (чуть больше — ~4500 вышло). Попробовал — понравилось, с этим можно работать.

Нюанс:
Пока deploy статичный — можно скачать и задеплоить самому, но тогда нативный AI работать не будет, придётся свои ключи прописывать.

⚠️ Забанили в Antigravity / Gemini CLI?
Если используешь сторонние агенты (OpenClaw, Claude Code, OpenCode и подобные) через OAuth-логин Antigravity — Google начал банить аккаунты.
Но есть форма апелляции, после которой разбанивают за 24-72 часа:
👉 https://docs.google.com/forms/d/e/1FAIpQLScOJWibQ_-hYuVv63kJTgEqlgAaOwRLGFTbXm-QY1gz8U0CGA/viewform?fbzx
Суть: подтверждаешь что понял нарушение, и аккаунт восстанавливают.

Как юзербот за 4 дня принёс оффер кофаундера и 4 горячих лида

РЕЗУЛЬТАТЫ:
• 1 приглашение кофаундером в стартап
• 1 оффер на работу
• 4 горячих лида на внедрение AI
• 12 человек написали в личку

Затраты: 2 часа на настройку

━━━━━━━━━━━━━━━━

ЧТО ЭТО?

Юзербот = ваш Telegram-аккаунт, который:
✓ Автоматически комментирует в тематических чатах
✓ Отвечает в личке на входящие сообщения
✓ Мониторит чаты и собирает инсайты
✓ Делает дайджесты по темам

Не спам. Только релевантные комментарии с реальной пользой.

━━━━━━━━━━━━━━━━

КАК ПОДНЯТЬ ЗА 30 МИНУТ

ШАГ 1: Получить API credentials
• Зайти на https://my.telegram.org
• Создать приложение
• Получить api_id и api_hash
• Это обязательно для любого юзербота

ШАГ 2: Установить Telegram MCP
• GitHub: https://github.com/newink/telegram-mcp
• Базовая версия умеет только мониторить
• send_message (для комментариев и ответов) — кастомная доработка, которую нужно добавить самому

ШАГ 3: Настроить конфиг и запустить

━━━━━━━━━━━━━━━━

ГЛАВНОЕ — НЕ ТЕХНОЛОГИИ, А НАСТРОЙКА

Что прописать:

1. ЛИЧНОСТЬ — кто вы, чем занимаетесь, ваш опыт
2. БАЗА ЗНАНИЙ — ваши кейсы, цифры, результаты
3. ПРАВИЛА ПОВЕДЕНИЯ — когда комментировать, когда молчать
4. СТИЛЬ ОТВЕТОВ — экспертность без высокомерия, конкретика, лёгкая дерзость
5. ЧАСТОТА — не больше 15-20 комментариев/день, 3 на чат

━━━━━━━━━━━━━━━━

ЧТО УМЕЕТ ДЕЛАТЬ

КОММЕНТИРОВАНИЕ:
• Мониторит указанные чаты
• Анализирует сообщения на релевантность
• Оставляет комментарии с реальной пользой
• Соблюдает лимиты (15-20/день, 3 на чат)

ОБЩЕНИЕ В ЛИЧКЕ:
• Отвечает на входящие сообщения
• Использует вашу базу знаний
• Может отправлять материалы (гайды, кейсы)
• Лимит: 20 ответов/день

МОНИТОРИНГ И АНАЛИТИКА:
• Собирает инсайты из чатов
• Отслеживает тренды и темы
• Делает дайджесты по интересам
• Сохраняет важные обсуждения

━━━━━━━━━━━━━━━━

ЧТОБЫ НЕ ЗАБАНИЛИ

• Начинайте с 5-7 комментариев/день
• Увеличивайте постепенно
• Минимум 30 минут между комментариями
• Используйте качественные LLM (Claude Opus 4.6, GPT-5.3/5.4)
• Не спамьте одинаковыми ответами

━━━━━━━━━━━━━━━━

ГЛАВНЫЙ ИНСАЙТ

Бот не делает работу за вас. Он автоматизирует рутину (мониторинг, первичные ответы), чтобы вы фокусировались на важном (созвоны, сделки).

Это не пассивный доход. Это усилитель вашей экспертизы.

━━━━━━━━━━━━━━━━

Если хотите детальный гайд с кодом, примерами конфигов и troubleshooting — пишите в комментариях, завтра сброшу если будет спрос.

P.S. Этот пост частично написан AI. Но опыт, цифры и кейсы — реальные.

Держите обещанный подробный гайд.

1) Полный гайд: Telegram-юзербот для лидогенерации
https://telegra.ph/Polnyj-gajd-po-nastrojke-Telegram-yuzerbota-dlya-lidogeneracii-03-14

2) Практический гайд: Telegram MCP — sendMessage и sendFile
https://telegra.ph/Telegram-MCP-send-message--send-file--prakticheskij-gajd-03-14-2

Пользуйтесь. Надеюсь, после этого гайда в чатах останутся люди, а не только юзерботы.

Пока все обсуждают prompt caching и RAG для экономии токенов, есть техника проще — которую почти никто не использует.

Один HTTP-заголовок. Три строчки кода. 80% экономии на веб-запросах.

Когда агент лезет в интернет, по умолчанию тащит полный HTML со всеми скриптами, стилями и навигацией. 50-100K токенов в помойку.

Решение: попросить сервер отдать чистый markdown.

Accept: text/markdown, text/html

GitHub, Reddit, многие CMS — поддерживают. Получаешь контент без разметки вместо тонны HTML.

Реальные цифры:
• GitHub README: −86% токенов
• Reddit пост: −77%
• Документация: −85%

Полный разбор с кодом → https://telegra.ph/Kak-snizit-rashod-tokenov-na-80-pri-veb-zaprosah-03-17

Проверено на проде. Работает.

От тяжелых IDE к Harness Engineering: мой стек на OpenCode

Перепробовал Cursor, Windsurf, Antigravity — всё жрёт память и открывает кучу окон. Перешёл на OpenCode Desktop (Tauri, не Electron) — все проекты в одном списке, переключаюсь в клик, память не утекает.

Методология: Harness Engineering от OpenAI (разбор) — контекст в файлах, не в памяти модели.

Стек (с ссылками):
• OpenCode — лёгкое приложение
• Superpowers MCP — паттерны для агентов (community, не официальный)
• GSD-2 — фреймворк задач
• Agency-agents — роли (backend, security, devops)

Архитектура: D:\opencode-workspace\ симлинк C:\Users\...\.config\opencode → D:\...
Все проекты на D:\, бэкап одной папкой, системный диск чистый.

Роли моделей:
• Codex 5.4 — Orchestrator (дирижирует)
• Opus 4.6 — Backend/Security (сложное)
• Sonnet — Frontend/DevOps (рутина)

Принципы:
• One task = One session (контекст в .tasks/, не в чате)
• Лимит 35% — потом flush в файл и новая сессия
• SSH через скилл — работа с VPS по ключам

Результат: лёгкое приложение, предсказуемые сессии, контекст никогда не теряется.

#OpenCode #HarnessEngineering #AIAgents

🤖 Какую модель реально выбрать для AI-агента? PinchBench уже отвечает
Все споры в комьюнити «Opus vs GPT vs Gemini» обычно основаны на синтетических тестах — MMLU, HumanEval, ELO-арены. Они хорошо меряют «IQ модели», но совсем не меряют то, как модель работает как ядро настоящего AI-агента.

PinchBench — первый публичный бенчмарк, который гоняет модели именно в роли агента (OpenClaw) на реальных задачах: код, почта, ресёрч, планирование, файлы, воркфлоу. Никакой синтетики.
Топ прямо сейчас (март 2026):

🥇 GPT-5.4 — 90.5% ($1.64/ран)
🥈 Qwen3.5-27B — 90.0% ($0.52/ран) ← шок
🥉 Qwen3.5-397B — 89.1% ($1.26/ран)
4. Claude Sonnet 4.5 — 88.2% ($2.78/ран)
5. MiniMax-M2.5 — 87.8% ($0.17/ран) ← ultra cheap
6. Claude Opus 4.6 — 87.4% ($5.28/ран)

Главный инсайт: Claude Opus 4.6, которого все называют «лучшим для агентов» — шестой, а не первый. А лидеры по value-for-money это совсем другие модели.

Почему так? Nemotron 3 Super от NVIDIA и MiMo-V2-Omni от Xiaomi буквально затачивались под OpenClaw — NVIDIA даже показывала PinchBench на сцене Jensen Huang’а как официальный бенч для своей модели. Qwen3.5-27B, MiniMax-M2.5, GLM-4.5 Air дают топовый score при копеечной стоимости — $0.14–0.52 за ран против $5+ у Opus.

А теперь самое интересное — PinchBench v2:
Команда KiloClaw открыла приём задач от комьюнити до 15 апреля. Цель — расширить с 23 до 100 задач, добавить фильтрацию по skill-типам, профили контрибьюторов и убрать bias по размеру ранов.
Как поучаствовать:
→ github.com/pinchbench/skill — issue #60 (мета-тред v2)
→ Форкай репо, пиши задачу в формате OpenClaw skill, кидай PR
→ Задачи должны быть реальными (то, что реально запускают в prod), с чёткими programmatic success criteria
Если ты гоняешь OpenClaw на реальных задачах — это прямая возможность сделать бенч объективнее под свой use case. Чем больше community-задач, тем меньше «кто заточен под OpenClaw кило» и больше универсальности.

PinchBench — это именно тот сдвиг, который нужен: от синтетических бенчей к реальным агентским задачам. Epoch бенчей на IQ закончилась.

На выходных добрался до своего ZeroClaw и решил выстроить над ним харнес. Вот что получилось.

🤖 Zero Harness: Production-оболочка для мультиагентной системы

ZeroClaw — это ядро (бинарник 8.8MB, старт до 10ms).
Zero Harness — это то, что превращает его в production-систему.

Проблема, которую я решал:

Большинство AI-агентов работают по принципу «один агент на всё»:
• Одна модель на все задачи (дорого/медленно)
• Нет бенчмарков (какая модель лучше для чего — неизвестно)
• Память — векторные БД (сложно, дорого, непрозрачно)
• Нет governance (кто контролирует агента?)
• Browser-first (сначала браузер, потом вопросы)

Это работает для демо. Не работает для production.

Решение: Zero Harness

Архитектура из 7 агентов с чёткими контрактами:
Front Router → Research Agent | Coding Agent | Browser Agent | Memory Curator | Skill Factory

Ключевые инновации:

1️⃣ Модельный роутинг с бенчмарками
• Чат/роутинг: NVIDIA Nemotron 3 (120B)
• Воркеры: Claude Opus 4.6 — тяжёлые задачи
• Browser eval: 6 кандидатов — 14-дневный цикл
• Планирую: бенчмарки под конкретные задачи

2️⃣ Lexical-first память (без векторов)
• handoff.md, daily notes, source_of_truth.md
• BM25 поиск (не векторы)

3️⃣ Browser-last политика
• Сначала memory search → skill routing → browser
• Target: меньше 10% запросов идут в browser

4️⃣ Governance с approvals
• Policy checks, allowlists, audit trail

5️⃣ Skill Factory
• Browser-паттерны → версионированные скиллы

6️⃣ Сэндбоксы (планирую на следующих выходных)
• WASM/Docker изоляция для воркеров

Метрики (в процессе настройки):
• Browser Eval: 6 кандидатов, 14-дневный цикл
• Routing Eval: 4/6 pass (2 в работе)
• E2E: 3/3 pass

Философия:
Не усложнять без нужды.

Что дальше?
Серия из 7 постов — разберу каждый компонент детально.

#ZeroClaw #AIAgents #MultiAgent #LLM #BrowserAutomation #OpenSource

Zero Harness #2: Почему одна модель на всё — плохая идея

Одна из первых ловушек в агентной системе — взять “самую умную” модель и пустить через неё всё подряд.

На старте это кажется удобным:
- меньше настроек;
- проще поддерживать;
- не нужно отдельно продумывать маршрутизацию.

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

В Zero Harness я изначально смотрю на это иначе:

модель — это не “личность” системы, а исполнительный слой под конкретную роль.

То есть сначала система должна понять:
- что это за задача;
- насколько она сложная;
- нужен ли браузер;
- хватит ли памяти или готового навыка;
- нужен ли отдельный исполнитель с более глубоким рассуждением.

И только потом выбирать путь выполнения.

Проще говоря:

сначала маршрутизация, потом выполнение.

Причём под “агентами” внутри харнесса я чаще имею в виду не автономных персонажей, а исполнителей:
- маршрутизатор;
- исследователь;
- кодовый исполнитель;
- браузерный исполнитель;
- хранитель памяти;
- проверяющий слой.

У каждого класса задач свой профиль:
- где-то важна скорость;
- где-то стоимость;
- где-то нужно длинное рассуждение;
- где-то важна аккуратная работа с инструментами;
- а где-то нужен просто хороший диспетчер на входе.

Поэтому в нормальной схеме:
- на входе не обязательно стоит самая мощная модель;
- тяжёлые модели включаются там, где действительно нужна их глубина;
- специализированные исполнители получают свои роли и ограничения;
- слой проверок нужен для того, чтобы всё это выбиралось не “на глаз”, а по результатам.

Важно, что это не означает “зоопарк моделей ради зоопарка”.
Если многомодельная схема в какой-то момент даёт больше хаоса, чем пользы, систему разумно временно упростить.

У меня сейчас как раз более консервативный этап: основной рабочий контур по сути схлопнулся в один стабильный вариант.
Но это не отменяет саму идею маршрутизации.

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

То есть даже если несколько веток сейчас приходят к одной и той же модели, архитектурно слой маршрутизации всё равно нужен.

Для меня хороший харнесс — это не система с “любимой моделью”.
Это система, которая умеет распределять вычислительный и смысловой ресурс по типу задачи.

Именно поэтому я считаю, что production-агенту нужна не одна “лучшая” модель, а модельная стратегия.

В следующем посте разберу память:
почему для рабочего слоя я пошёл в сторону lexical-first memory, а не начал сразу с векторной базы.

#ZeroClaw #ZeroHarness #AIAgents #MultiAgent #LLM #Routing

Zero Harness #3: Memory Layer

В прошлом посте я обещал разобрать память. Разбираю.

Если коротко: в Zero Harness память — это не «ещё одна vector DB для галочки», а рабочий слой, который помогает агенту не терять контекст, не врать про прошлые решения и не начинать новую сессию с амнезии.

Я довольно быстро уткнулся в простую вещь: большинство memory-слоёв в agent-системах переоценены именно в той форме, в которой их обычно подают. Снаружи это выглядит красиво: embeddings, semantic recall, long-term memory, retrieval. На практике часто получается хуже:
— полезные факты тонут в шуме;
— свежий контекст смешивается со старым;
— важные решения не имеют нормального статуса source of truth;
— агент «что-то вспоминает», но непонятно, можно ли этому доверять.

Поэтому я пошёл в более приземлённую схему.

1. Lexical-first, а не blind vector-first

В Zero Harness память сначала опирается на простые и проверяемые штуки:
— handoff.md;
— daily notes;
— source_of_truth.md;
— self_map.md;
— структурированные memory entries;
— BM25 / lexical retrieval поверх текстовых артефактов.

Почему так? Потому что в реальной инженерной работе запросы очень часто точные и операционные:
— что мы решили по heartbeat;
— где лежит текущий runtime snapshot;
— какой cron падает;
— какой файл считается каноничным;
— что обещали в прошлом посте.

Для таких задач lexical-first поиск почти всегда полезнее «семантической магии». Он лучше держит имена файлов, точные формулировки, идентификаторы, названия интеграций и конкретные артефакты.

2. Handoff.md как save game

Самый недооценённый слой памяти — нормальный handoff. Если агент работает не одну сессию, ему нужен не абстрактный «long-term memory», а короткий живой файл передачи смены:
— что сейчас происходит;
— какие решения уже приняты;
— что сломано;
— что осталось доделать;
— какие файлы являются опорными.

По сути handoff.md — это save game: не философия памяти, а точка восстановления.

3. Source of truth важнее объёма памяти

Ещё одна частая проблема agent-memory: система помнит много, но не знает, чему верить. Поэтому в Zero Harness я разделяю оперативный контекст, дневные заметки, долгосрочную память и source of truth. Нормальная память — это не только retrieval, это ещё и иерархия доверия.

4. Память должна помогать действовать

Полезные единицы памяти здесь — это не только факты, но и рабочие артефакты:
— заметки по задачам;
— дневной план;
— зафиксированные решения;
— статус интеграций;
— runtime snapshot;
— self-map окружения.

То есть хорошая память для агента — это не музей воспоминаний, а оперативная поверхность, от которой можно перейти к следующему действию.

И здесь важен ещё один слой: память у нас поддерживается не только поиском, но и фоновыми ритуалами. Есть handoff, дневник дня, source of truth, snapshot текущего runtime и карта окружения, которая регулярно обновляется. Идея не в том, чтобы «сложить всё в одно умное хранилище», а в том, чтобы агенту было откуда честно восстановиться после паузы или рестарта.

Поэтому мой текущий практический вывод такой: для рабочей agent-memory связка lexical-first + BM25 + handoff + source of truth даёт больше реальной пользы, чем попытка сразу построить «умную универсальную память» только на semantic retrieval.

Это менее хайпово. Зато намного ближе к системе, которой можно доверять в реальной работе.

#ZeroClaw #ZeroHarness #AIAgents #Memory #BM25 #LLMInfra

Anthropic запретил использовать свои подписки в OpenClaw. Что делать?

С сегодняшнего дня Anthropic запретил использовать Max/Pro-подписки в сторонних приложениях, включая OpenClaw.

Теперь остается только extra usage по полному API-ценнику:
токены × цена.

Для OpenClaw с его длинными контекстами это очень больно.

Но выход есть.

GitHub Copilot Pro+ — $39/мес

Что вы получаете:
- 1500 premium requests в месяц
- доступ к сильным моделям прямо в рабочем контуре
- нативное подключение
- extra usage по $0.04 за запрос, если вышли за лимит

Много это или мало — 1500 запросов?

Для сравнения:

- Claude Max за $100 — это примерно 15-25 запросов в день, то есть около 450-750 в месяц
- Claude Max за $200 — точка безубыточности наступает примерно на 45-50 запросах в день, то есть около 1350-1500 в месяц

То есть 1500 запросов в Copilot Pro+ — это уже уровень верхнего Max-тарифа Anthropic.

Но есть принципиальная разница.

Anthropic считает по токенам.
Чем тяжелее контекст в OpenClaw, тем дороже каждый запрос.

Copilot считает по запросам.
Extra usage стоит $0.04 за запрос.

Для агентных сценариев и длинных контекстов это критично.

Если вышли за 1500 запросов

Каждый дополнительный запрос — $0.04.

То есть:
- 500 extra requests = $20
- 1000 extra requests = $40

На фоне прямого API-биллинга при тяжелых контекстах это выглядит очень адекватно.

Вывод

Если Anthropic больше не дает использовать подписки в OpenClaw как раньше, то GitHub Copilot Pro+ сейчас выглядит самым понятным запасным аэродромом.

За $39 в месяц вы получаете:
- большой включенный лимит
- понятную модель добора сверху
- намного более предсказуемую экономику для тяжелых сценариев

Итог простой:
если вы работаете через OpenClaw, держаться за старую модель больше не получится.
Нужно переезжать туда, где биллинг не разваливается от каждого длинного контекста.

Сейчас это Copilot Pro+.

Источники:
1. https://help.apiyi.com/ru/claude-max-vs-api-pay-per-use-pricing-comparison-claude-code-savings-guide-ru.html
2. https://incrussia.ru/news/anthropic-predstavila-novyj-tarifnyj-plan-claude-max-tsenoj-ot-100-do-200/
3. https://kod.ru/claude-podpiska-200-dollarov
4. https://docs.github.com/ru/copilot/concepts/billing/individual-plans
5. https://docs.github.com/ru/copilot/concepts/billing/copilot-requests

Zero Harness #4: Eval Engine
Архитектуру и роутинг я уже показал. Следующий слой — как вообще понять, что вся эта конструкция не врет сама себе через два дня после настройки.
Поэтому в Zero Harness я вынес eval в отдельный постоянный контур.
Не «раз в неделю посмотрел руками», а регулярные прогоны с артефактами, историей и понятными воротами на изменения.
Что именно там проверяется.
— Routing eval
Каждый день гоняются контрольные кейсы на маршрутизацию.
Не абстрактные бенчмарки, а вопросы, которые реально соответствуют ролям системы:
- memory lookup
- code implementation
- research
- browser-required flows
- memory curator
Последний зафиксированный прогон: 6 кейсов, 4 pass, 2 fail.
И это как раз полезно: оба падения были не «модель тупая», а конкретная ошибка маршрутизации — browser-required кейсы ушли в skill runner вместо browser agent.
То есть eval здесь нужен не для красивой цифры, а чтобы быстро ловить архитектурный дрейф.
— Skills eval
Для скиллов отдельный gate.
Смотрится не только pass/fail, но и форма контракта:
- есть ли trigger
- есть ли when_to_use / when_not_to_use
- прописаны ли required_tools
- есть ли fallback strategy
- есть ли eval cases
На последнем прогоне:
- 3 скилла
- 3 pass
- threshold = 0.8
- routing gate required = true
Важная мысль: скилл не считается готовым только потому, что он «один раз сработал».
Он должен пройти через формальные проверки и не ломать роутинг вокруг себя.
— Browser eval
Это вообще отдельная дисциплина.
Не «у нас есть browser tool, значит норм».
А 14-дневная программа сравнения кандидатов по типам задач.
Сейчас в контуре:
- 6 кандидатов
- 9 benchmark cases
- 13 прогонов в активном периоде
Сравниваются не только success rate, но и:
- latency
- determinism
- token overhead
- retry rate
- composite score
Что интересно по текущим данным.
Для lightweight-кандидатов лидирует lightpanda-light.
Например:
- pricing/research pages: 100% success, ~69.6 ms
- auth/login flows: 100% success, ~69.6 ms
- SPA/JS-heavy interaction: 100% success, ~68.3 ms
У vercel-agent-browser результаты тоже очень сильные, но чуть медленнее.
Heavy-контур нужен не как основной путь, а как fallback там, где реально требуется тяжелый рантайм.
Это и есть важный принцип Harness:
browser-first почти всегда ведет к лишней сложности.
Нужен lightweight-first + контролируемый heavy fallback.
— Зачем все это на практике
У большинства agent-систем eval появляется слишком поздно.
Сначала собирают красивую оркестрацию, потом долго живут на ощущении, что «вроде работает».
Проблема в том, что без постоянного eval у тебя очень быстро начинается деградация:
- роутинг уплыл
- новый скилл сломал старый путь
- browser-кандидат стал нестабилен
- latency выросла, никто не заметил
И самое неприятное — внешне система продолжает выглядеть уверенной.
Поэтому для меня Eval Engine — не вспомогательная часть, а страховка от самоуверенного агента.
— Что дальше
Следующий шаг — связать это с completion-control.
То есть чтобы агент не мог сам себе сказать «задача готова», пока это не подтверждено фактами, артефактами и smoke-check'ами.
И да, это менее зрелищно, чем очередной «autonomous agent that does everything».
Зато это уже похоже на production, а не на демо для инвестора.
Дальше покажу, как этот eval-контур связывается с completion control и почему без этого агент слишком легко объявляет работу “готовой”.
ZeroClaw #ZeroHarness #AIAgents #Evals #BrowserAutomation #LLMInfra

Готовлюсь потихоньку к BitGN: Agent Benchmarks & Challenges от автора канала LLM под капотом.
Удалось решить все тестовые задачи на малютке llama-3.1-8b-instruct. На основной этап соревнования конечно возьму модель помощнее, но это был своего рода челлендж, довести харнесс до такого состояния, чтобы даже очень маленькая LLM справлялась с задачами