На днях вышел апдейт Manus 1.6
В ру комьюнити Манус не очень популярный из-за цены, как я понимаю.
Но ребята планомерно и уверенно шагают к
"one-shot task success"

Например попросил провести анализ и сгенерить слайды по теме
"Списки пожеланий на новогодние праздники и что люди друг другу дарят? насколько ожидания соотносятся с реальностью"

Так можно прям на слайде редактировать текст, в диалоге править дизайн и всё очень юзер-френдли.

Если цена изменится или увеличат бесплатные лимиты - то рекомендую добавить в закладки)

В последнее время вычитываю репозитории с агентскими плагинами и пресетами для claude code. Путешествие не самое приятное и объемное, но в какой-то степени этот путь предстоит пройти каждому.
Нашелся приятный агрегатор который явно рекомендую потыкать и почитать Skills ,
https://skillsmp.com/
Есть как документация по самой сущности skills для агентов, так и разбитые по категориям примеры с ссылками на github, куда можно провалиться,
А там, как правило - репозиторий - хранилище плагинов.

Рекомендую, как первую точку входа для решения задачи с "Поиск или написание скилла"

Вот сижу, разбираюсь с этим апдейтом Skills, что-то тестирую.
И бац, мысля в голову прилетела.
Ведь всё, что ново-модно сейчас обсуждать с агентами в разработке
Декомпозиция. Специализация. Оркестрация. Контракты
Всё это используем уже десятилетия в микросервисах.

Фундаментально решить пытаемся одну и ту же задачу:

Как управлять сложностью через декомпозицию?

Микросервисы разбивают монолитное приложение на независимые сервисы.
А skills разбивают сложную задачу на специализированные "навыки", которыми владеет агент.

| Микросервисы                     | Skills                          |
|----------------------------------|---------------------------------|
| Независимые deployment units     | Независимые SKILL.md файлы      |
| API контракты (OpenAPI)          | Контракты на естественном языке |
| Service discovery                | LLM-роутинг по описаниям        |
| Оркестрация (K8s)                | Оркестрация через LLM           |

Обе архитектуры обещают: модульность, переиспользование, независимую эволюцию компонентов, возможность комбинировать базовые блоки в сложные системы.

Но как справедливо отмечает Guille Ojeda в своём анализе:

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

Фундаментальное различие: зачем мы декомпозируем

Микросервисы: структура приложения

Микросервисы появились как ответ на боли монолита: медленные релизы, неэффективное масштабирование, технологический lock-in, каскадные отказы. Это паттерн софтверной архитектуры, направленный на улучшение жизненного цикла разработки.

Декомпозиция в микросервисах привязана к бизнес-доменам — стабильным концепциям предметной области. Сервис CatalogService управляет каталогом товаров. PaymentService — платежами. Границы сервисов отражают границы бизнеса, что обеспечивает долгосрочную поддерживаемость.

Skills: структура задачи

Skills появились как ответ на ограничения LLM: сложные задачи требуют многошаговых процессов, доступа к внешним инструментам, сохранения контекста. Это паттерн AI-системного дизайна, направленный на достижение автономного, целеориентированного поведения.

Декомпозиция в Skills привязана к логике выполнения задачи — функциональным шагам, ролям, рабочим процессам. Skill pdf знает, как извлекать текст из PDF. Skill code-review знает, как проводить ревью кода. Границы Skills отражают границы экспертизы, а не бизнес-домены.

Ключевой инсайт: Микросервисы декомпозируют структуру приложения. Skills декомпозируют процесс решения задачи.

Ради этой таблички пишу пост
В AI-native разработке формируется своя иерархия:

| Уровень     | Традиционный              | AI-Native                         |
|------------|----------------------------|-----------------------------------|
| Атомарный   | Функция                    | Tool (Read, Write, Bash)          |
| Экспертиза  | Модуль                     | Skill (домен + workflow)          |
| Автономный  | Сервис                     | Agent (reasoning + tools)         |
| Система     | Приложение                 | Agentic Workflow                  |

И почему же не получается полностью перенести весь "опыт" разработки на агентские рельсы?
Мысль то моя не нова и есть десятки репозиториев со сложными сценариями на десятки агентов, со сложными сценариями, которые "копируют" процесс разработки и автоматизируют его.
НО дальше концепта и звезд на GitHub не идет?
___
Bounded Contexts из Domain-Driven Design отлично работают для микросервисов, но плохо подходят для Skills. Skill декомпозируется по функциональным шагам, а не по доменным границам.
Попытка создать "UserProfileSkill" по аналогии с "UserProfileService" приведёт к размытым границам и неэффективному использованию.

Заключение
Skills — это не "микросервисы для AI". Это новый архитектурный паттерн, который заимствует идеи декомпозиции из микросервисного мира, но применяет их к принципиально другой проблеме: оркестрации интеллектуального поведения.

Забавное ощущение. На последних курсах, что проходил в https://shvm.xyz/ (не реклама, но там есть пара преподавателей - лапочек ), говорили

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

И сейчас я пытаюсь на GitHub найти один репозиторий, который я точно лайкал, но не могу найти.
Долистал до своих первых "звезд"
И знаете, книгу
Interpretable Machine Learning with Python
Которую я лайканул, судя по всему, года 4 назад, и разбираясь в блокнотах..

Такого сейчас я представить не могу, но, мне кажется, что это хорошо.
Я представляю какого-то зеленого парня, лет 20 в универе, который изредка ловит в голове мысли о своем реальном будущем, и я рад, что если появится мгновение\искра\мысль о программировании - то ему это будет многим легче "затестить".

Нужную мне библиотеку я не нашел, но вам рекомендую потыкать на GitHub вкладку Stars, можно окунуться в воспоминания, мне понравилось)
Вот из забавного:
- самый старый реп Паши - лайканул где-то в феврале 2024

Собеседование на AI-инженера в банк: три вещи, которые реально проверяют

Собрал в кучу инфу по теме AI-инженера. "Горячая" тема, судя по рилсам)
Типичная вакансия: Python, LLM, RAG, агенты, production. Но на собесе не проверяют знание этих слов. Проверяют три вещи:
1. Trade-off мышление - не "лучший подход", а "лучший для этой ситуации"
2. Production-фокус - как это будет жить, ломаться и стоить денег
3. Язык домена - говоришь ли ты на языке бизнеса, а не только на языке ML
___
1. Trade-off мышление
Нет "лучшего" решения. Есть решение, оптимальное для конкретных ограничений.
Chunking в RAG

| Стратегия       | Плюс               | Минус              | Когда выбирать           |
|----------------|--------------------|--------------------|--------------------------|
| Мелкие чанки    | Точнее поиск        | Теряем контекст     | Фактовые вопросы         |
| Крупные чанки   | Больше контекста    | Шум в retrieval      | Аналитические вопросы    |
| Parent-child    | И точность, и контекст | Два индекса, сложнее | Когда критично качество |

Зрелый ответ: "Зависит от типа вопросов. Для фактовых - мельче, для аналитических - крупнее."
Retrieval

| Метод             | Плюс                 | Минус                                   |
|------------------|----------------------|------------------------------------------|
| Dense (векторный) | Понимает семантику    | Может пропустить exact match             |
| Sparse (BM25)     | Точный match          | "РКО" ≠ "расчётно-кассовое обслуживание" |
| Hybrid            | Лучшее из двух        | Сложнее настройка                        |

В проде почти всегда hybrid - потому что dense пропускает точные совпадения (аббревиатуры, коды), а sparse не понимает семантику.
Агент vs Граф

| Подход              | Плюс                          | Минус                                           |
|---------------------|-------------------------------|-------------------------------------------------|
| Свободный агент      | Гибкость                       | Непредсказуемость, дорого, сложно тестировать   |
| Граф (state machine) | Воспроизводимость, аудируемость | Нужно продумать все пути заранее                |

Для банка граф почти всегда лучше - регулятор любит предсказуемость.

Зрелый ответ: "Сначала смотрю, можно ли графом. Агент - когда реально нужна гибкость, а не красивая архитектура."

Треугольник оптимизации

QUALITY
           △
          /|\
         / | \
        ▽──┴──▽
    LATENCY  COST

- Streaming - реальная latency та же, но UX кардинально лучше
- Кэширование мгновенные ответы, но риск устаревших данных
- Роутинг по сложности простые вопросы на дешёвую модель. 80% запросов обычно простые - экономия существенная
- Reranking - quality +, но latency -
___
2. Production-фокус
Сделать прототип — легко. Поддерживать систему, которая не деградирует - сложно.
Что может пойти не так

| Проблема           | Что происходит                          | Как заметить                         |
|-------------------|------------------------------------------|--------------------------------------|
| Устаревший индекс  | Регламенты обновились, база старая        | Рост ответов "информации нет"        |
| Изменение модели   | Провайдер обновил модель                 | Скачок метрик после апдейта          |
| Падение интеграций | CRM или бэкенд недоступен                | Рост таймаутов                       |
| Смена паттернов    | Пользователи спрашивают о новом           | Незнакомые вопросы в логах           |

Безопасность агентов

| Механизм           | Зачем                                           |
|-------------------|--------------------------------------------------|
| Allowlist tools    | Только разрешённые инструменты                   |
| Loop guard         | Лимит шагов, времени, стоимости                  |
| Human-in-the-loop  | Подтверждение на чувствительных действиях        |

Loop guard - мастхэв. Агент может решить, что ему нужно 50 вызовов API на простой вопрос.
Verifier - обязательный компонент

Generate → Verify → Respond

___
3. Язык домена
Понимаешь ли ты контекст, в котором система будет работать?

Метрики: о чём реально спросят
Не "accuracy модели", а бизнес-результат:
- Сколько обращений закрыл бот без человека? - главная метрика
- Сколько передали оператору? - и почему
- Сколько стоит закрыть одно обращение? - сравниваем с ценой оператора
- Как изменилось время обработки?

Если говоришь только про recall и precision - видно, что не думал вообще о продукте.

Claude Code завезли Task Manager, но есть нюанс

Новая система управления задачами в Claude Code перешла от хранения списка дел в оперативной памяти к файловой структуре.

Но я наткнулся на недочёт, который ломает UX в реальной работе над проектами:

Таски создаются в глобальной директории Claude и привязываются к номеру сессии.
Из-за этого теряется консистентность и невозможно нормально возвращаться к задачам между сессиями в рамках одного проекта.
Я завёл issue:
https://github.com/anthropics/claude-code/issues/20425

✅ Временное решение без боли: wrapper "cc"
Идея простая: запускать Claude Code через wrapper-скрипт, который автоматически выставляет CLAUDE_CODE_TASK_LIST_ID по имени текущей директории (то есть по имени проекта).
Плюс: если в будущем Anthropics это поправят - просто удаляете скрипт, и всё.

Я предлагаю запускать это через сам Claude Code, чтобы полностью понимать, что делает код, и не тянуть “скрипты из интернета”.

В Комментариях сам промпт.

Как пользоваться:
Заходите в папку проекта → запускаете cc вместо claude → таски “приклеиваются” к проекту.