Claude Cowork: агент для повседневных задач на компе

Компания тестирует агента на базе Claude с доступом к файлам и системным командам для нетехнических задач. Но пока только за сотку в месяц.

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

Тул выходит в формате research preview: это намекает на то, что даже в Anthropic пока не до конца понимают, какие сценарии использования откроются. Запускают, смотрят, собирают фидбек: сначала выкатывают MVP, потом адаптируются под реальное поведение пользователей.

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

Логично, что много нетехнических задач можно было бы делегировать похожему агенту. Вопрос всегда был в безопасности: Claude Code по умолчанию спрашивает разрешение перед любыми изменениями файлов или системных настроек. Судя по релизу Cowork, Anthropic нащупала баланс между автономностью агента и контролем пользователя.

Но есть нюансы. Во-первых, Claude Cowork доступен только подписчикам Max — это стоит $100 в месяц и выше. Во-вторых, агентные сценарии жрут токены как не в себя: на обычной подписке Pro я упираюсь в недельные лимиты почти моментально после того, как даю Claude Code серьёзную задачу. С Cowork, скорее всего, будет так же.

Тем не менее это ещё один маркер того, что 2026-й действительно становится годом агентов. Anthropic, OpenAI, Google, OpenCode — все двигаются в сторону того, чтобы дать AI не просто возможность отвечать на вопросы, но и выполнять многошаговые задачи с доступом к инструментам.

Вопрос только в том, насколько быстро эти инструменты станут доступны не только корпоративным клиентам и энтузиастам с жирными подписками, но и обычным пользователям. Пока что Anthropic тестирует спрос среди тех, кто готов платить.

Агент == Бизнес-функция. Инженерный подход к проектированию

Рассмотрим проектирование агента поиска товаров в маркетплейсе по бенчмарку Store с ERC3. Попробуем подойти к проектированию агента с точки зрения структурного анализа.

Сначала посмотрим на схему #1 — из каких компонентов состоит Агент. Не буду их описывать, думаю вы и так понимаете, что они означают… НО что-то это напоминает… хм…

Да это вылитая схема IDEF0 (см. схему #2 для понимания) по описанию бизнес-функций! Слева вход — запрос пользователя или другого агента, сверху инструкции, правила поведения и навыки, снизу инструментарий для выполнения бизнес-функции, ну а справа выход.

Если смотрели выступление Ильи у Валеры, то вспомните: он применил схему оркестратора с саб-агентами для решения бенчмарка store, и один из таких агентов был агент по поиску товаров, использующий ручку API /products/list (см. схему #3).

Давайте теперь опишем данного саб-агента с помощью методологии IDEF0:

1. Определим бизнес-функцию нашего агента как «Подобрать товар» — анализ каталога товаров и выявление позиции, соответствующей запросу.

Мы выбираем «Подобрать», а не просто «Найти» или «Сканировать», потому что агент выполняет сложную когнитивную работу: он не просто делает запрос в базу (как поисковик), а итеративно сканирует каталог, фильтрует результаты в памяти и валидирует их на соответствие нечетким критериям пользователя.

2. На вход нашему агенту мы предоставляем «поисковый запрос с критериями фильтрации» — текстовая строка на естественном языке, содержащая как намерение («найди»), так и ограничения («дешевле 500», «красный»).

Пример: «Нужна игровая видеокарта не дороже 60000 рублей, желательно Asus».

На этом этапе можно размышлять над краевыми случаями и собрать Evaluation Dataset.

3. Для функции «Подобрать товар» механизм представляет собой tool, назовем ее get_product_list. В нашем случае это будет простая обертка вокруг API /products/list.

Мы осознанно не упоминаем в механизмах LLM, так как это больше НФТ (нефункциональное требование), нежели бизнес-требование.

4. В классическом менеджменте сверху находятся должностные инструкции, регламенты, ГОСТы и законы, но в нашем случае это будет Ролевая модель, Процедура поиска и Политики безопасности.

Важно: мы не отбираем у исследователей работу с промптом, но указываем в требованиях общие рекомендации.

5. Ну и Вывод — это продукт или информация, полученная в результате работы функции. Это то, ради чего функция существует. В классическом чат-боте выводом считается текстовое сообщение пользователю. В инженерии автономных агентов выводом является структурированный ответ, передающий ответственность оркестратору.

Рекомендую сразу размышлять над негативными сценариями: как мы будем обрабатывать ошибки.

Зачем это нужно?

Такая детализация позволяет еще до написания первой строки кода и промпта наглядно увидеть «дыры» в логике. Если вы не можете описать агента в этой схеме — значит, вы пока не знаете, что именно строите.

Хотите пример требований и кода по методологии? Поставьте реакцию, чтобы я знал, что вам это интересно 👇

Исследователи собрали новый подход к RAG, который:

* не требует vector DB
* не делает эмбеддинги
* не режет документы на чанки
* не выполняет similarity search

И он показал 98,7% точности на финансовом бенчмарке (SOTA).

Вот какую ключевую проблему классического RAG этот подход решает:

Обычный RAG режет документы на чанки, превращает их в векторы и достает фрагменты по семантической похожести.

Но похожесть ≠ релевантность.

Когда ты спрашиваешь: "Какие были тренды по долгу в 2023?", векторный поиск вернет куски, которые семантически похожи на запрос.

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

Классический RAG, скорее всего, это просто не найдет.

PageIndex это закрывает.

Вместо чанкинга и эмбеддингов PageIndex строит иерархическое дерево структуры документа, по сути умную "таблицу содержания".

А дальше модель рассуждением проходит по этому дереву.

То есть она не спрашивает: "Какой текст больше всего похож на мой запрос?"

Она спрашивает: "Судя по структуре документа, где бы человек-эксперт искал ответ?"

Это принципиально другой подход, у которого:

* нет произвольного чанкинга, который рвет контекст
* не нужно тащить и обслуживать vector DB
* retrieval трассируемый: видно, почему выбрали конкретный раздел
* можно нормально ходить по внутренним ссылкам документа ("см. Table 5.3"), как делает человек

Но глубже проблема вот в чем.

Векторный поиск воспринимает каждый запрос как независимый.

А документы имеют структуру и логику: разделы ссылаются друг на друга, контекст накапливается по страницам.

PageIndex уважает эту структуру, вместо того чтобы сплющивать все в эмбеддинги.

При этом важно: такой подход не везде имеет смысл, потому что классический vector search все еще быстрый, простой и отлично работает во многих кейсах.

Но для проф-документов, где нужна доменная экспертиза и многошаговые рассуждения, tree-based, reasoning-first подход реально раскрывается.

Например, PageIndex показал 98,7% точности на FinanceBench и заметно обогнал традиционные vector-based RAG системы в разборе сложных финансовых документов.

Все полностью в oпенсорс, можно посмотреть реализацию на GitHub и попробовать самому.

Опытные пользователи Claude Code, вам стоит это увидеть.

Есть публичный репозиторий, который по сути как полноценная ОС для Claude Code: агенты, skills, hooks, команды, правила, конфиги MCP, всё уже связали и можно просто подключать.

Можешь просто посмотреть (или забрать себе) целиком. Это мнение автора, которое уже обкатали на реальных проектах.

Google начали раскатывать доступ к Genie 3

Пока что модель доступна лишь подписчикам Ultra. Юзеры могут создать набросок мира с помощью Nano Banana Pro, перед тем как туда залететь. Также есть библиотека готовых миров, которые можно ремиксить. Длина симуляции до 60 секунд, а видео можно потом скачать.

http://labs.google/projectgenie/

@ai_newz

OpenAI запустили инструмент для написания пейперов

Prism построен на базе купленного OpenAI стартапа Crixet. Представляет он из себя совместный LaTeX редактор с интегрированным внутрь ChatGPT. Он может проверить цитаты, перевести диаграмму/формулу из наброска в LaTeX и т.д. Prism доступен бесплатно всем желающим, но подписчикам ChatGPT обещают как-то потом докинуть продвинутых фичей.

prism.openai.com

@ai_newz

Invoice CRM - файловая мини-CRM для инвойсов в PDF.

Сделал для себя и решил поделиться.

Главная фишка — всё управляется через Claude Code или любого другого AI-агента. Говоришь “сделай инвойс для Startup Inc на 5000 евро” — получаешь готовый PDF.

Что под капотом:
• База постоянных клиентов и провайдеров в YAML
• Реквизиты компаний и банков для переиспользования
• Шаблоны на Jinja2 - можно делать любые PDF-документы, хоть афиши
• QR-коды для оплаты (EUR/SEPA, TRY, USD/SWIFT, крипто)
• Цифровая подпись PDF
• Шифрование через age (хоть весь архив)

Всё через Make:
• make invoice-startup # инвойс пример
• make cards # карточки реквизитов
• make list # список клиентов

Стек: Python + Jinja2 + Pydantic + WeasyPrint

github.com/fortunto2/invoice-crm

Сейчас AI-агенты всё лучше пишут код, но запускать их напрямую на локалке не всегда то и хочется

Особенно в режиме автозапуска, страшно, что AI случайно удалит важные файлы или вообще получит доступ к приватным данным.

Недавно на GitHub наткнулся на Vibe: опенсорс проект для macOS, который поднимает сверхбыструю Linux-виртуалку в песочнице.

Главные плюсы: нулевая конфигурация, изоляция за <10 секунд, можно спокойно закрыть AI в клетку.

AI видит только текущий проект, а все остальные чувствительные каталоги полностью изолированы.

Написан на Rust, использует родную виртуализацию Apple, безопаснее Docker и при этом почти не грузит ресурсы

🔥 Anthropic собрали C-компилятор командой из 16 Claude агентов


Масштаб проекта:

• ~2000 Claude Code сессий
• $20,000 API costs
• 100,000 строк Rust кода
• 2B input токенов, 140M output
• 2 недели автономной работы
Результат: Компилятор собирает Linux 6.9 на x86, ARM, RISC-V + QEMU, FFmpeg, SQLite, Redis, Doom 🎮


Как работает harness:

while true; do
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-4-6
done

Каждый агент в Docker-контейнере, общий git-репо, синхронизация через lock-файлы (current_tasks/parse_if.txt).


Ключевые уроки:

| Проблема                   | Решение                                           |
| -------------------------- | ------------------------------------------------- |
| Агенты делают одно и то же | Lock-файлы на задачи                              |
| Context pollution          | Минимум вывода, всё в логи                        |
| Claude не чувствует время  | --fast режим (1-10% тестов)                       |
| Все застряли на одном баге | GCC как oracle — каждый агент фиксит разные файлы |
| Код дублируется            | Отдельный агент на рефакторинг                    |

Специализация агентов:

• 🐛 Основные — фиксят баги
• 🧹 Один — убирает дублирование
• ⚡ Один — оптимизирует перформанс
• 📝 Один — документация
• 🔍 Один — code review как "Rust эксперт"

Ограничения:

• Нет 16-bit x86 (звонит GCC)
• Ассемблер/линкер ещё багованы
• Код не супер-оптимальный
• Качество Rust "норм, но не эксперт"

Вывод автора:

"Я не ожидал что это будет возможно так рано в 2026. Это волнует, но и тревожит."


Код открыт: github.com/anthropics/claudes-c-compiler

Это буквально следующий уровень — от "AI помогает кодить" к "AI пишет компилятор пока ты спишь" 🤯

То, что надо: Codag позволяет визуализировать рабочие процессы AI/LLM прямо в репозитории и посмотреть, как именно работает ваш AI-код.

Без всякой настройки Codag строит карту всего AI-пайплайна: все вызовы LLM, ветвления решений и этапы обработки данных.

100% опенсорс код

Claude Skill Building — ключевые инсайты для продакшна

1. Skill = контракт + оркестрация
• Фиксируем входы, выходы, формат, ограничения
• Модель — только слой принятия решений; вокруг нужны валидация, retry, fallback
2. Eval-first подход
• До релиза собираем набор тест-кейсов (happy path + edge cases)
• Любое изменение промпта/логики гоняем через авто-eval
• Без eval промпт-тюнинг превращается в “кажется стало лучше”
3. Контекст важнее “умности” модели
• Стабильная структура system/dev/user
• Минимизируем шум, даем только релевантный контекст
• Жёстко задаем формат ответа (JSON schema / строгий шаблон)
4. Tool use — production-фича
• Инструменты с чётким интерфейсом и предсказуемым результатом
• Таймауты, идемпотентность, обработка ошибок обязательны
• Логируем каждый вызов: что вызвали, что вернулось, почему упало
5. Надёжность > креативность
• Guardrails: policy checks, output filtering, PII redaction
• Fallback-стратегии на каждый критичный шаг
• Никаких silent failures — всегда понятный статус и next step
6. Стоимость и латентность — часть архитектуры
• Разделяем fast path и deep reasoning
• Кэшируем неизменный контекст
• Декомпозируем сложные задачи на этапы
7. UX для доверия
• Показываем прогресс: “думаю / проверяю / готово”
• Лучше короткий надёжный ответ сейчас, чем длинный нестабильный позже
Вывод: выигрывают не лучшие “магические промпты”, а системы с eval + observability + control loop.

Ссылка: https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en

Илья Полосухин создал 1-ого серьёзного конкурента OpenClaw, который может забрать значительную долю

Один из авторов статьи о трансформерах, Илья Полосухин, основатель NEAR AI, вместе с командой выпустили IronClaw - переписанная с 0 на Rust версия OpenClaw, с акцентом на приватность, безопасность и защиту от утечек данных.

За все время существования ИИ-агента OpenClaw (ex-Moltbot/Clawdbot) накопил огромное количество инцидентов по безопасности.

IronClaw решает эту проблему.

Skills из ClawHub пока не поддерживаются полноценно. Реальные тесты в проде покажут, выдержит ли.

Вышла GLM 5

У нас новая лучшая открытая модель, по крайней мере по бенчам. С проприетарными тягается неплохо, но с Opus 4.6 и GPT 5.3 Codex почему-то не сравнивают, хотя за неделю после релиза тесты можно было прогнать. Веса доступны по лицензии MIT.

Архитектура похожа на DeepSeek V3.2 — тоже используют DSA и multi-token prediction. Модель в 2 раза больше предыдущей модели компании — 744 миллиарда параметров (против 355), из которых 40B — активных. А вот датасет почти не вырос — 28.5 триллионов токенов, против 23 у GLM 4.5. Основной упор всё-таки идёт на RL, но про него-то как раз не говорят (надеюсь в техрепорте будет больше инфы).

Ложка дёгтя — модель использует заметно больше ресурсов чем основной конкурент, Kimi K2.5. У GLM 5 на 25% больше активных параметров и используется в 2+ раза больше памяти на веса из-за использования bf16, что делает модель ещё и медленнее. В результате модель на 30% дороже, судя по тестам Artificial Analysis.

Zhipu жалуются на отсутствие компьюта, похоже из-за этого GLM 5 работает на железе чуть ли не всех китайских производителей чипов для ИИ — Huawei Ascend, Moore Threads, Cambricon, Kunlun Chip, MetaX, Enflame и Hygon (я о половине даже не слышал). Из-за проблем с компьютом, доступ по подписке открыли пока только подписчикам уровня Max, но обещают докинуть остальным в ближайшее время.

Там ещё MiniMax M2.5 втихую дропнулся, но пока нет анонса и весов

Веса
Блогпост

@ai_newz