Локальный агент - это не одна модель

#loop_engineering #howto

В демонстрации модели работают на DGX Spark, а управляют отдельным Windows mini PC. Между ними - harness и MCP. Скриншоты, команды и результаты остаются внутри локальной сети.

Turnstone отвечает за orchestration: запускает несколько workers с разными ролями, распределяет задачи, хранит memory, подключает skills и компактит контекст. Отдельная небольшая Gemma работает как judge. Permissions и output guard позволяют остановить рискованное действие до выполнения.

Hermes решает более персональный сценарий. Один агент подключается к локальному OpenAI-compatible endpoint, использует computer-use skills и сохраняет заметки в Markdown. Меньше governance и multi-agent orchestration, проще старт.

Сам loop выглядит так:
цель → критерии успеха → действие через MCP → наблюдение → оценка → повтор

Модель может открыть приложение, увидеть ошибку на скриншоте, скорректировать действие и проверить результат. Skills при этом задают допустимый процесс и критерии завершения, а не просто предлагают модели импровизировать.

Базовая проверка локального inference:

curl http://<DGX_IP>:8000/v1/models
docker ps

В Turnstone добавляется endpoint http://<DGX_IP>:8000/v1, затем модели синхронизируются с worker nodes. Windows MCP подключается как Streamable HTTP:

http://<WINDOWS_IP>:8000/mcp
Authorization: Bearer <token>

Hermes после установки настраивается повторным запуском hermes setup: custom endpoint, адрес DGX Spark, автоматическое обнаружение моделей.

Начинать нужно на отдельной машине без секретов. TLS, bearer authentication, минимальный набор MCP-tools, ручное подтверждение опасных действий. Локальная модель убирает cloud egress, но не делает агента безопасным автоматически.

Turnstone и Hermes управляют loop, MCP даёт инструменты, но выполнение всё равно нужно изолировать. локальность защищает данные от провайдера. sandbox защищает инфраструктуру от самого агента.

[1]: https://github.com/NousResearch/hermes-agent "Hermes Agent | Nous Research"
[2]: https://modelcontextprotocol.io/docs/concepts/architecture "Architecture overview | Model Context Protocol"

Netflix заменяет рекомендательный pipeline генерацией всей страницы

Обычная рекомендательная система собирает homepage по этапам: candidate retrieval, scoring, ranking, business rules, сборка рядов. GenPage превращает это в sequence generation.

Контекст пользователя и запроса становится prompt. Один transformer авторегрессионно генерирует структурированную страницу: какие ряды показать, в каком порядке и какие фильмы разместить внутри каждого ряда.

Модель сначала обучают на страницах из production, затем дообучают через weighted binary classification или reinforcement learning. Отдельно решают cold start, freshness каталога, ограничения бизнеса и serving efficiency - end-to-end модель не отменяет deterministic rules.

В online A/B test вариант с weighted classification дал +0,24% к основной engagement-метрике и одновременно снизил end-to-end latency на 20%. Для масштаба Netflix небольшой uplift уже существенен.

Ещё два результата. Обогащение prompt принесло больше пользы, чем увеличение модели. RL повысил разнообразие страниц, хотя diversity напрямую не входила в reward.

промпт здесь становится контрактом всей рекомендательной системы. но чем больше pipeline сжимается внутрь одной модели, тем важнее внешние constraints, fallback и observability: ошибку отдельного ranker заменить проще, чем ошибку сгенерированной страницы целиком.

[1]: https://arxiv.org/abs/2606.31031 "GenPage: Towards End-to-End Generative Homepage Construction at Netflix"

Почему retrieval и длинный context не решают company memory

#human_traces

Retrieval находит подходящий фрагмент. Длинный context позволяет модели прочитать больше фрагментов одновременно. Но ни один из механизмов не решает, что из прошлого должно пережить текущую сессию и повлиять на следующее действие.

Для памяти компании недостаточно найти старый тикет или протокол встречи. Нужно определить:

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

Авторы называют проблему blast radius: информация полезна только в определённых временных и организационных границах. Даже хороший reranker может достать правильный документ, но не понять, что правило относилось к старой версии продукта или не должно применяться к этому клиенту.

Бесконечно расширять context тоже недостаточно. Чем больше туда автоматически складывается, тем выше риск context pollution: агент начинает связывать несвязанные события и переоценивать случайно найденные детали. При этом полностью ручной поиск не работает с unknown unknowns - агент не запросит память, о существовании которой не знает.

Каждое воспоминание хранить как отдельный объект:

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

Сырые письма, встречи и тикеты остаются неизменяемым evidence layer. Из них создаются memory candidates. Решения и правила переходят в активную память только после подтверждения владельцем процесса.

Retrieval делится на два этапа. Сначала жёсткие фильтры по правам, времени, продукту и клиенту. Только затем semantic search и reranking. В context попадает не просто цитата, а карточка: какое правило найдено, почему оно применимо сейчас, откуда взялось и что должно изменить.

После действия агент сохраняет outcome: правило помогло, оказалось устаревшим, было отклонено человеком или привело к ошибке. Этот результат обновляет confidence, область применения или срок действия памяти.

Получается loop:
событие → memory candidate → подтверждение → scoped retrieval → действие → outcome → обновление или удаление.

Проверять систему нужно не recall-метрикой. Соберите 30–50 реальных задач и измеряйте:

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

MVP - один workflow, один владелец памяти, около сотни подтверждённых решений и небольшой набор regression-сценариев. Если агент начал стабильно повторять принятые командой решения и перестал повторять уже исправленные ошибки, слой работает.

поиск возвращает прошлое. company memory хранит последствия прошлого и проверяет, изменили ли они следующее действие.

[1]: https://x.com/samzliu/article/2075737137341940098 "Hot takes on AI memory | Sam Z Liu"
[2]: https://arxiv.org/abs/2410.10813 "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory | arXiv"
[3]: https://aclanthology.org/2024.acl-long.747/ "Evaluating Very Long-Term Conversational Memory of LLM Agents | ACL Anthology"

Fable 5 дороже за токен, но дешевле за выполненную задачу

#new_models

Cognition заменила Opus 4.8 на Fable 5 в Devin Fusion. На FrontierCode 1.1 новая связка показала более высокий результат и меньшую стоимость, хотя токены Fable стоят примерно вдвое дороже.

Разница - в количестве действий. Fable завершала прогон в среднем за 11,5 шага против 26,5 у Opus. Генерировала 6,1 тыс. output-токенов против 19 тыс. В 81% запусков lead-модель вообще не редактировала код: она рано передавала исследование и реализацию sidekick-модели, формулировала требования, затем проверяла diff. Opus делегировала примерно столько же раз, но позже - сначала повторно читала файлы, сама проектировала и реализовывала большую часть изменений.

При оценке моделей недостаточно сравнивать цену токена и качество финального ответа. Нужно считать, за сколько шагов получен проверенный результат: число turns и tool calls, повторные чтения контекста, retries, время и полную стоимость успешной задачи. Дорогая модель может оказаться дешевле, если быстрее понимает, что оставить себе, а что передать другому агенту.

[1]: https://cognition.com/blog/making-fable-cheaper-than-opus "Making Fable Cheaper Than Opus | Cognition"

8B-модель обогнала GPT‑4 за счёт архитектуры задачи

Atomic Task Graph превращает пользовательский запрос в DAG: каждый узел - один конкретный вызов инструмента с определёнными входом и выходом. Крупные узлы рекурсивно дробятся, пока не становятся атомарными. Перед запуском граф проверяется на пропущенные шаги, неправильные зависимости и несовместимые интерфейсы.

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

С этой схемой Llama 3 8B обошла GPT‑4 с ReAct на двух из трёх тестов: 63,65 против 41,24 на ALFWorld и 68,36 против 64,34 на WebShop. На ScienceWorld GPT‑4 осталась впереди: 66,16 против 56,79. ATG также сократил среднюю глубину выполнения и снизил долю траекторий с невалидными действиями с 42,86% у ReAct до 12,14%.

Если продукт строится с нуля, не делайте chat history источником состояния системы. Источником состояния должен быть task graph, а модель должна работать с отдельными узлами.

Минимальный контракт узла:

{
  "id": "extract_requirements",
  "tool": "requirements_extractor",
  "inputs": ["user_request"],
  "output_schema": "Requirements",
  "dependencies": [],
  "status": "pending",
  "validator": "requirements_check"
}

Планировщик компилирует намерение пользователя в граф. Детерминированный executor запускает готовые узлы. Валидатор проверяет результат каждого шага. Repair-agent получает только сломанный узел, его зависимости и ошибку - не всю историю выполнения.

Такая основа сразу даёт parallel execution, retries, resumability, node-level evals и маршрутизацию моделей: сильная модель строит или исправляет граф, дешёвые модели выполняют локальные операции. Для простых запросов граф избыточен - авторы прямо отмечают дополнительный overhead. Поэтому нужен порог сложности, после которого запрос компилируется в workflow.

это продолжение наблюдения про Fable и стоимость траектории. оптимизировать нужно не цену вызова модели, а глубину графа, количество повторных решений и размер области, которую приходится пересобирать после ошибки.

[1]: https://arxiv.org/abs/2607.01942 "Atomic Task Graph: A Unified Framework for Agentic Planning and Execution | arXiv"

Colibrì запускает GLM‑5.2 744B на 25 GB RAM

#local_LLM #howto

Colibrì - экспериментальный inference engine на C, который запускает GLM‑5.2 без GPU. У модели 744 млрд параметров, но благодаря MoE на каждом токене активируются около 40 млрд.

Постоянно нужная dense-часть занимает в RAM около 9,9 GB. Остальные эксперты хранятся на диске в int4 - это ещё примерно 370 GB - и подгружаются только при выборе роутером. Между RAM и диском работает LRU-кэш: часто используемые эксперты остаются горячими, остальные читаются с NVMe.

Цена такого запуска - latency. Холодная генерация требует читать с диска около 11 GB на каждый токен и выдаёт 0,05–0,1 токена/с. Один короткий ответ можно ждать минуты. «Модель работает на ноутбуке» здесь означает техническую возможность, а не замену облачного API.

Попробовать можно так:

git clone https://github.com/JustVugg/colibri
cd colibri/c
./setup.sh

./coli convert --model /nvme/glm52_i4
COLI_MODEL=/nvme/glm52_i4 ./coli chat

Для конвертации потребуется около 400 GB свободного места. Есть готовая int4-сборка и OpenAI-compatible API:

COLI_MODEL=/nvme/glm52_i4 \
COLI_API_KEY=local-secret \
./coli serve --host 127.0.0.1 --port 8000 \
  --model-id glm-5.2-colibri

Colibrì пока интереснее как offline worker: длинная асинхронная задача, редкие запросы, приватные данные, отсутствие GPU. Не интерактивный ассистент, а локальный batch-исполнитель, где стоимость ожидания ниже стоимости инфраструктуры.

граница локального inference сдвигается из памяти в пропускную способность хранилища. вопрос уже не «поместится ли модель», а «какую задержку выдерживает конкретный workflow».

[1]: https://github.com/JustVugg/colibri "JustVugg/colibri: Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine | GitHub"
[2]: https://www.tomshardware.com/tech-industry/artificial-intelligence/colibri-proof-of-concept-gains-frontier-level-1-5-tb-ai-model-novel-approach-runs-on-only-25gb-of-ram-and-shows-promise-for-local-ai-setups "Colibrì proof-of-concept runs a 744B model on 25GB of RAM | Tom's Hardware"

У Claude нет одной личности

Anthropic проанализировала более 300 тысяч реальных разговоров и выделила 3 307 ценностей, проявляющихся в ответах Claude. Часть стабильна - например, прозрачность. Остальные возникают в зависимости от задачи: предотвращение вреда, историческая точность, человеческая автономия, личные границы.

Отдельный cross-cultural audit показал ещё один слой: одна модель меняет советы при переходе между языками и культурными контекстами. Claude, например, становился более коллективистским при общении на локальном языке. Перевод prompt не сохраняет поведение модели один к одному.

Для production это означает: model_id недостаточно. Версия поведения - это модель × язык × system prompt × контекст. Golden set для английского нельзя просто перевести на русский. Нужны отдельные multilingual evals, сравнение refusal rate, tone, risk sensitivity и решений на одинаковых сценариях.

распределение outputs нужно сегментировать по языку и модели - общий средний балл скроет систематически разный опыт пользователей.

[1]: https://arxiv.org/abs/2504.15236 "Values in the Wild: Discovering and Analyzing Values in Real-World Language Model Interactions"
[2]: https://arxiv.org/abs/2604.22153 "When AI Speaks, Whose Values Does It Express? A Cross-Cultural Audit of Individualism-Collectivism Bias in Large Language Models"

Что люди в действительности поручают рабочему AI-агенту

#claude #way_of_work #use_case

Anthropic проанализировал 1,2 млн обезличенных сессий Claude Cowork, собранных в мае 2026 года более чем в 600 тысячах организаций.

Выяснилось, что люди используют рабочего агента совсем не так, как можно было бы предположить по заявлениям об «AI-сотрудниках».

Самая большая категория - business process and operations. На неё приходится 33,4% сессий.

Это задачи вроде:
- собрать разбросанные по разным источникам обновления в один отчёт;
- сверить несколько таблиц;
- сделать onboarding checklist;
- подготовить tracker;
- структурировать внутренний процесс;
- свести накопившуюся информацию в понятный документ.

Ещё 16,4% приходится на создание контента: черновики презентаций, предложений, постов, отчётов и других рабочих материалов.

Вместе эти две категории составляют примерно половину использования Claude Cowork.

Anthropic называет это the work around the work - «работа вокруг работы».

Это задачи, которые не являются основной профессией человека, но постоянно возникают между настоящими задачами.

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

Такая работа существует почти в каждой компании, но редко принадлежит кому-то конкретному. Поэтому она постоянно перекладывается между людьми, откладывается и выполняется вручную.

Именно здесь рабочие агенты находят первый устойчивый use case.

Не «полностью заменить маркетолога» или «самостоятельно управлять компанией», а снять организационный налог: собирать, преобразовывать и передавать информацию между людьми и системами.

Это довольно логичная реакция на текущее состояние AI.

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

У таких задач обычно есть несколько удобных свойств:

- нужная информация уже существует внутри компании;
- результат можно представить в виде проверяемого артефакта;
- ошибка заметна человеку при просмотре;
- задача повторяется;
- на неё жалко тратить время квалифицированного сотрудника.

Отсюда следует и практический способ искать процессы для автоматизации.

Нужно начинать не с вопроса:
> Какую профессию мы можем поручить агенту?

А с вопросов:
> Какую информацию сотрудники постоянно собирают вручную?
> Какие документы регулярно создаются из одних и тех же источников?
> Какие задачи переходят между командами, но не имеют постоянного владельца?
> Что необходимо сделать для работы, хотя это не является основной работой ни одного участника?

Статусные отчёты, сверка данных, подготовка встреч, onboarding, trackers, презентации, follow-ups и обновление документации - не самые эффектные примеры AI.

Зато именно из них складывается значительная часть реальной нагрузки компании.

Поэтому отдельный режим Work рядом с обычным Chat тоже выглядит закономерно. Chat помогает человеку подумать и получить ответ. Work получает доступ к файлам, инструментам и рабочему состоянию, чтобы самостоятельно произвести проверяемый результат.

Первые массовые рабочие агенты, судя по данным Anthropic, становятся не автономными руководителями и не заменой профессионалам.

Они становятся владельцами той работы, у которой раньше владельца не было.

Важно: это данные самого Anthropic по выборке Claude Cowork, а не исследование всего рынка труда. Они показывают структуру sampled sessions, но не доказывают качество выполнения задач или полученный компаниями ROI.

[1]: https://claude.com/blog/how-people-are-using-claude-cowork "How people are using Claude Cowork | Anthropic"

Company memory должна обновляться в момент исправления ошибки

#data_for_LLM #prompts #human_traces

PromptQL перезапустили как «multiplayer AI»: общий агент работает с командой, читает Slack, документы, CRM и аналитику и использует накопленный контекст при выполнении задач.

Но самое интересное здесь - не очередной AI внутри корпоративного чата. PromptQL предлагает другой способ поддерживать company memory: обновлять её прямо в тот момент, когда человек исправляет агента.

Допустим, сотрудник просит подготовить выручку для совета директоров. Агент берёт данные из analytics.revenue. Сотрудник отвечает: эта таблица устарела, с прошлого квартала правильный источник - netsuite.revenue.

Обычный агент просто переделает текущий отчёт. Через неделю другой агент или сотрудник повторит ту же ошибку.

PromptQL после исправления предлагает сохранить новое правило в общую память:

> Для отчётности по выручке использовать netsuite.revenue; analytics.revenue устарела с четвёртого квартала 2025 года.

Человек может проверить и отредактировать формулировку, после чего знание сохраняется вместе с источником, историей изменений и областью доступа. В следующей задаче агент уже использует исправленный контекст.

Получается такой цикл:

1. Агент выполняет реальную задачу.
2. Обнаруживает пробел в контексте или делает ошибочное предположение.
3. Человек исправляет его внутри текущей работы.
4. Система извлекает из исправления кандидата в новое знание.
5. Человек подтверждает формулировку и scope.
6. Следующие агенты используют это знание.

Это важное отличие от традиционной базы знаний.

Обычно сотрудников просят отдельно обновлять Wiki, писать инструкции и документировать решения. Но в этот момент у них нет непосредственной мотивации обслуживать company memory: основная задача уже выполнена, а документация воспринимается как дополнительная работа.

При ошибке ситуация другая. Человек уже столкнулся с последствиями отсутствующего контекста и хочет, чтобы проблема не повторилась. У него перед глазами конкретная задача, неверное предположение агента и правильное решение. Это момент, когда новое знание проще всего сформулировать и проверить.

Поэтому company memory стоит строить не как библиотеку документов, которую кто-то обязан постоянно поддерживать, а как побочный продукт реальной работы.

Причём сохранять нужно не весь диалог. Ценность представляют атомарные изменения состояния:

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

При этом исправление не должно автоматически становиться истиной для всей компании. Иначе один неудачный комментарий может отравить контекст остальных агентов. Нужны человеческое подтверждение, источник, владелец, версия, срок актуальности и scope: личный, командный, клиентский или общий.

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

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

[1]: https://promptql.io/ "PromptQL | Multiplayer AI with shared context"

Monogram: ответом модели становится интерфейс, а не сообщение

Monogram запустил general-purpose AI-приложение с visual-first интерфейсом и объявил о привлечении $40 млн.

Идея продукта: AI не обязательно должен отвечать текстом. Модель может создать интерфейс, подходящий под конкретную задачу.

Планируете путешествие - получаете карту, карточки мест и фильтры по цене. Выбираете фильм - постеры, рейтинги и кнопку сохранения. Готовите по рецепту - ингредиенты, настройку порций и таймер.

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

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

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

Generative UI разделяет эти роли: чат определяет намерение пользователя, а интерфейс помогает этим намерением управлять.

В production такую механику лучше строить не через генерацию произвольного HTML, а через контролируемую библиотеку компонентов. Модель выбирает карту, список, форму или подтверждение действия, а приложение валидирует структуру, права и ограничения.

То есть модель отвечает за композицию, а продукт - за состояние и безопасность.

Качество моделей выросло настолько, что ограничением всё чаще становится не способность получить ответ, а неудобство работы с ним.

Поэтому при проектировании AI-функции стоит спрашивать не только:
> Какой ответ должна сгенерировать модель?

Но и:
> Какой интерфейс позволит пользователю быстрее завершить задачу?

Чат может остаться универсальной точкой входа в AI. Но сообщению необязательно оставаться универсальным результатом.

[1]: https://www.monogram.ai/blog/introducing-monogram "Introducing Monogram | Monogram"
[2]: https://x.com/erenbali/status/2074502671600672930 "Eren Bali: Monogram launch and $40M seed round"

Skills работают. Но хороший текст ещё не означает хороший skill

#skills

Agent skill - папка с инструкциями, скриптами и ресурсами, которая добавляет модели процедурные знания без fine-tuning. Как проводить code review. Как собрать финансовый отчёт. Как какать. Какие проверки обязательны перед релизом.

До недавнего времени skills оценивали глазами: инструкция выглядит разумно, ответ модели - профессионально. Три исследования, собранные Aparna Dhinakaran, показывают, почему этого недостаточно.

В SkillsBench сравнили 84 задачи, 11 доменов, семь связок model + agent harness и 7 308 запусков. Для каждой задачи проверяли три режима: без skill, с подготовленным экспертами skill и со skill, который модель написала себе сама.

Экспертные skills подняли pass rate в среднем на 16,2 процентного пункта. Self-generated skills дали около −1,3 п.п. относительно baseline. Особенно плохо сработал Codex + GPT‑5.2: −5,6 п.п.

Но вывод не в том, что skill способен написать только человек. Эксперимент проверяет one-shot генерацию: агент получает задачу, пишет себе инструкцию и сразу ей следует. Он не извлекает процедуру из production traces, исправлений эксперта и накопленных ошибок. Получается красиво сформулированная версия того, что модель и так уже знала.

Размер тоже работает нелинейно. Два-три сфокусированных модуля дали +18,6 п.п. Четыре и больше - только +5,9. Comprehensive-документация вообще ушла на −2,9 п.п. А на 16 из 84 задач экспертные skills ухудшили результат: добавили конфликтующие правила или усложнили задачу, которую модель уже умела решать.

SkillReducer подтверждает проблему на 55 315 публичных skills. У 26,4% отсутствует нормальное описание для routing. Более 60% содержимого не влияет на действие агента. После сжатия descriptions на 48%, bodies на 39% и переноса примеров в on-demand references качество выросло ещё на 2,8%.

Отдельная проблема - размер библиотеки. "More Skills, Worse Agents?" показывает падение до 21% при расширении набора до 202 skills. Причина преимущественно не в переполнении контекста. Агент чаще выбирает неправильный skill - skill shadowing.

Для своей системы нужно собрать реальные повторяющиеся задачи и прогнать минимум три варианта: no skill, текущий skill, изменённый skill. Одинаковые model, effort, sandbox и лимиты. Три-пять повторов. Проверять не стиль ответа, а task success, tool errors, latency и tokens. Исправление skill должно одновременно добавлять regression case - иначе инструкция меняется, а её полезность остаётся мнением.

Открытый harness можно поднять так:

git clone https://github.com/benchflow-ai/skillsbench.git
cd skillsbench
uv tool install benchflow
uv sync --locked
bench tasks check tasks/offer-letter-generator
bench eval run --tasks-dir tasks/offer-letter-generator --agent oracle --sandbox docker

Внутри skill лучше оставить короткие исполняемые правила. Примеры, справочники и редкие сценарии - загружать по запросу. Description становится частью routing-системы, поэтому Anthropic рекомендует отдельно тестировать корректность срабатывания, а не только выполнение самой инструкции.

skills - это не документация для агента. это versioned behavior: источник - человеческие traces и исправления, изменение - через eval, загрузка - только когда skill действительно нужен.

[1]: https://x.com/aparnadhinak/status/2074569427346174039 "Aparna Dhinakaran on X"
[2]: https://arxiv.org/abs/2602.12670 "SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks"
[3]: https://arxiv.org/abs/2603.29919 "SkillReducer: Optimizing LLM Agent Skills for Token Efficiency"
[4]: https://arxiv.org/abs/2605.24050 "More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries"
[5]: https://github.com/benchflow-ai/skillsbench "benchflow-ai/skillsbench"
[6]: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices "Skill authoring best practices | Claude Platform Docs"

OpenCode: модель становится сменной зависимостью

#human_traces #howto #opencode

Claude Code, Codex и Gemini CLI связывают модель с собственным agent harness. Хотите другую модель - обычно меняете и весь инструмент: sessions, permissions, команды, skills, правила проекта.

OpenCode разделяет эти слои. Один runtime работает с 75+ провайдерами, ChatGPT Plus/Pro, GitHub Copilot, API-ключами и локальными моделями. Модель можно менять, сохраняя plan/build, AGENTS.md, skills, MCP, custom agents и историю работы.

curl -fsSL https://opencode.ai/install | bash
cd project
opencode

Дальше /connect добавляет провайдера, /models меняет модель, /init сканирует репозиторий и создаёт или обновляет AGENTS.md. OpenCode также понимает CLAUDE.md и ~/.claude/skills/, поэтому миграция с Claude Code не требует сразу переписывать весь контекст.

В tutorial показана более интересная механика - session становится отдельным артефактом. Сессию можно экспортировать в Markdown или JSON, импортировать на другой машине, расшарить ссылкой, откатить изменения или создать fork с выбранного сообщения. Это подходит для async handoff: один агент исследует задачу, второй продолжает реализацию, человек получает не пересказ, а полную trajectory с tool calls и изменениями.

Ссылки на sessions нужно использовать осторожно. /share публикует содержимое разговора по URL; режим по умолчанию manual, но в transcript всё равно могут попасть код, пути и данные из tool calls. Для передачи наружу безопаснее opencode export --sanitize.

Для команды OpenCode можно поставить как единый вход в agent workflow:

* AGENTS.md хранит правила проекта;
* skills загружаются по необходимости;
* plan работает без права редактирования;
* build выполняет изменения;
* разные models назначаются на planning, implementation и review;
* sessions экспортируются для аудита и продолжения работы.

Секция tutorial про «совет директоров» из YouTube-транскриптов - скорее демонстрация, чем доказанный use case. Сильнее другое: OpenCode можно запускать как headless server с OpenAPI или через ACP. Тогда это уже не терминальный интерфейс, а backend для собственных agent workflows.

Это обратная сторона уже разобранных GPT‑5.6 внутри Claude Code и Codex-Orchestration. Там модель протаскивают в чужой harness. Здесь harness изначально не принадлежит модели.

модель можно заменить за минуту. накопленные sessions, правила, skills и способы проверки - уже инфраструктура.

[1]: https://www.youtube.com/watch?v=0xKE1UHpSfk "OpenCode Full Tutorial: Free Models, Skills & MCPs"
[2]: https://opencode.ai/docs/models/ "Models | OpenCode"
[3]: https://opencode.ai/docs/rules/ "Rules | OpenCode"
[4]: https://opencode.ai/docs/skills/ "Agent Skills | OpenCode"
[5]: https://opencode.ai/docs/cli/ "CLI | OpenCode"

Агент может сделать больше, чем вы способны проверить

#loop_engineering

Агенты уже умеют самостоятельно исследовать задачу, написать код, запустить тесты и исправить ошибки. Addy Osmani называет это inner loop: investigate → implement → verify → repeat.

Проблема возникает, когда скорость этого цикла становится выше скорости контроля. По опросу Sonar, 42% коммитящегося кода уже сгенерировано или существенно дополнено AI. При этом 96% разработчиков не доверяют его функциональной корректности полностью, а 95% тратят время на проверку и исправление.

Получается trust-verification gap: генерация масштабируется параллельно, инженерное внимание - нет. Двадцать агентов могут подготовить двадцать изменений, но у человека не появляется двадцать независимых потоков judgment.

Поэтому человек должен выйти из каждой итерации, но остаться на внешней границе системы. Outer loop состоит из четырёх частей:

* constraints - что агенту разрешено менять, какие invariants нельзя нарушать;
* sampling - какие результаты и с какой частотой проверяются человеком;
* audit - какие traces, тесты и решения сохраняются;
* ownership - кто разрешает изменению попасть в production и отвечает за последствия.

Агент передаёт наружу не сообщение «готово», а evidence: diff, результаты тестов, typecheck, затронутые зависимости, изменения permissions, миграцию и rollback plan. На основании evidence человек принимает verdict: ship, block, narrow, добавить guardrail или отправить работу на повторный цикл.

Без этой границы появляются три издержки.

Cognitive surrender - результат агента принимается без собственной позиции. Cognitive debt - код растёт быстрее, чем понимание системы. В эксперименте Anthropic инженеры с AI-помощником набрали в проверке понимания 50% против 67% у группы без AI; выборка небольшая - 52 преимущественно junior-разработчика, но разрыв пришёлся в том числе на debugging.

Orchestration tax - время на постановку задач, сортировку результатов и поиск изменений, требующих внимания. Чем больше параллельных агентов, тем быстрее review становится общей очередью.

Для одной agent-задачи сначала задаётся acceptance contract: разрешённый scope, обязательные проверки, формат evidence, условия остановки и владелец verdict. Реализация запускается в отдельном worktree или sandbox. Изменение production - только opt-in. В audit log остаются результат проверок, автор решения и состояние системы после принятия или отклонения.

На уровне software factory несколько независимых inner loops можно масштабировать. Outer loop остаётся системой back pressure: types, tests, hooks, sandbox limits, monitors, permissions и release gates. GitLab тоже фиксирует, что review и validation становятся bottleneck, а governance часто добавляют уже после генерации кода.

это следующий слой после loop engineering. недостаточно построить цикл, который сам выполняет работу. нужно заранее определить место, где его автономность заканчивается.

вроде бы ничего нового и все очевидно, но это забывается

[1]: https://addyo.substack.com/p/own-the-outer-loop "Own the Outer Loop | Addy Osmani"
[2]: https://www.sonarsource.com/state-of-code-developer-survey-report.pdf "State of Code Developer Survey Report 2026 | Sonar"
[3]: https://www.anthropic.com/research/AI-assistance-coding-skills "How AI assistance impacts the formation of coding skills | Anthropic"
[4]: https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx "GitLab Research Reveals Organizations Are Generating AI Code Faster Than They Can Control It"

SDK без SDK: почему агенты возвращают разработчиков к REST

#new_feature

Factory AI отказалась от клиентских SDK Stripe, WorkOS и Slack. Вместо них команда вызывает REST API через единый внутренний HttpBaseClient.

На первый взгляд - шаг назад. SDK уже решает authentication, types, pagination, retries и обработку ошибок. Но он оптимизирован под человека: скрыть HTTP и сократить количество кода.

Агенту скрывать HTTP часто вредно. Когда запрос не проходит из-за proxy, firewall, rate limit или неправильного scope, ему нужны status code, raw body, headers и request ID. SDK превращает это в собственную иерархию исключений. Агент начинает изучать реализацию библиотеки вместо диагностики запроса.

Вторая проблема - разные абстракции. Stripe, Slack и WorkOS по-разному называют методы, ошибки и pagination. Единый HTTP-клиент даёт агенту одну механику:

client.request({
  method: "POST",
  path: "/v1/customers",
  body,
  idempotencyKey,
})

Автор также указывает на размер зависимостей: Stripe SDK - 6,5 MB, WorkOS - 6,9 MB, Slack - 7,7 MB, Linear - 34 MB, Google APIs - 198 MB. Но размер здесь вторичен. Сильнее мешают скрытая retry-логика, разные форматы ошибок и дополнительные слои между агентом и внешней системой.

Полностью переписывать SDK не нужно. Рабочая схема - оставить один транспортный слой для auth, timeout, retries, rate limits, logging и raw responses. Над ним - маленькие typed adapters только для используемых endpoints. Типы можно генерировать из зафиксированной версии OpenAPI.

Начать можно с одной проблемной интеграции. Вынести два-три используемых endpoint из SDK, добавить логирование request/response metadata и integration tests против sandbox. Сравнить количество зависимостей, сложность traces и время диагностики ошибок.

Риски тоже реальные: потерять встроенную idempotency, webhook verification, pagination или незаметно отстать от новой версии API. Поэтому REST-вызовы должны жить за внутренним интерфейсом, а не расползаться по продукту.

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

[1]: https://x.com/EnoReyes/highlights "Eno Reyes (@EnoReyes) / Highlights / X"