Ответы на вопросы после митапа по AI

Pavel Veinik

Login
Ответы на вопросы после митапа по AIКраткая история IT: От ткацкого станка до нейросетей

MCP, инструменты и skills

- Вопрос, если не один репозиторий, а несколько, но нужно пошарить агентов, скилы, рулы и спеки, на случай если кросс доменная разработка, лучше делать на каждый репозиторий настройку ai или лучше sub module использовать

Конечно, это центральный вопрос для масштабирования AI-ассистентов в командах. Сегодня изолированная настройка для каждого репозитория считается устаревшим и неэффективным подходом. Правильная стратегия — централизация и переиспользование.

Архитектура и механика работы Оптимальное решение — создание выделенного репозитория, условно ai-config, который становится единым источником правды для всех AI-асетов:

  1. Структура репозитория: Внутри него создается логичная структура, например skills/, rules/, agents/.
  2. Версионирование: Каждое изменение в этом репозитории проходит ревью и версионируется с помощью тегов Git. Это позволяет командам обновлять AI-конфигурации контролируемо.
  3. Интеграция в проекты:
    • Git Submodules: Это самый прямой путь. Вы добавляете ai-config как сабмодуль в каждый проект. Плюс — простота старта. Минус — разработчикам нужно помнить о необходимости инициализировать (git submodule update --init) и обновлять сабмодули.
    • Пакетный менеджер: Более продвинутый подход. AI-ассеты упаковываются в артефакт (например, zip-архив или даже специализированный формат) и публикуются в приватном репозитории артефактов вроде Artifactory или GitHub Packages. CI/CD пайплайн каждого проекта затем скачивает нужную версию ассетов на этапе сборки. Это исключает ошибки ручного обновления.

Технологии и лучшие практики

  • Инструменты: Для управления конфигурациями все чаще используют подход Configuration as Code. Вместо набора Markdown-файлов конфигурации описываются на языках вроде YAML или даже Python с использованием фреймворков типа Pydantic для валидации.
  • Оркестрация: Агентные платформы, такие как Warp, позволяют указывать путь к общим правилам и скиллам, что упрощает их подключение.
  • Тестирование: В ai-config репозитории настраивается CI, который проверяет синтаксис правил, валидность скиллов и даже запускает интеграционные тесты для проверки того, что изменения не сломают базовые сценарии работы агентов.

Что может пойти не так

  • Конфликт версий: Команда А обновила общий скилл, и это сломало логику для команды Б. Решается строгим версионированием и тестированием. Каждая команда указывает конкретную версию ai-config, которую она использует.
  • Раздувание конфига: В общем репозитории появляются очень специфичные скиллы для одного проекта. Этого нужно избегать. В ai-config хранится только то, что действительно переиспользуется. Специфичные вещи остаются в репозитории проекта.

Полезные материалы

- Скиллы добавленные в проект дополняют пользовательские или их заменяют?

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

Архитектура и механика работы Представьте себе слоеную систему, где каждый слой может добавлять или переопределять конфигурации предыдущего. Порядок приоритета (от низшего к высшему) выглядит так:

  1. Системные (Bundled) скиллы: Это базовые возможности, встроенные в AI-платформу (например, работа с файлами, команды терминала). Они есть всегда.
  2. Пользовательские (User) скиллы: Это персональные настройки пользователя, которые он хочет применять во всех своих проектах. Они хранятся в его домашней директории.
  3. Проектные (Project) скиллы: Это самые специфичные и самые приоритетные скиллы. Они лежат в репозитории проекта (например, в файле WARP.md или в директории .warp/).

Когда вы запускаете агента, он последовательно загружает скиллы в этом порядке. Если он находит два скилла с одинаковым названием, он использует тот, у которого выше приоритет. Например, если у вас есть пользовательский скилл run_tests и проектный скилл run_tests, в данном проекте будет использоваться именно проектный.

Технологии и лучшие практики на 2026 год

  • Явное наследование: Современные агентные фреймворки позволяют в проектном скилле явно ссылаться на пользовательский, чтобы не копировать его код, а лишь немного изменить.
  • Неймспейсы (Namespacing): Чтобы избежать случайных конфликтов, рекомендуется использовать префиксы в названиях, например, project_name:run_tests.
  • Инструменты отладки: Платформы предоставляют инструменты для инспекции контекста агента, позволяя увидеть, какие именно скиллы были загружены и какой у них приоритет.

Что может пойти не так

  • Неочевидное поведение: Разработчик может не понимать, почему агент ведет себя не так, как он привык. Обычно причина в том, что проектный скилл переопределил его личные настройки.
  • Дублирование логики: Если не использовать наследование, можно случайно скопировать большой пользовательский скилл в проект, и при изменении оригинала копия останется старой.

Полезные материалы

- Я пока работаю в сursor с моделькой sonnet последней. Просто сделал файл AGENTS.md где описал структура проекта и основные особенности проекта и команды (миграции, установка библиотек и так далее). И на моем проекте кажется прям хорошо работает. Добавление кучу скиллов/агентов заметно повышает качество кода?

Это отличный вопрос, который затрагивает суть перехода от простых prompt engineering техник к полноценным агентным системам. Ваш AGENTS.md — это прекрасный первый шаг, по сути, это форма meta-prompt или системного промпта.

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

Архитектура и механика работы

  1. Системный промпт (ваш AGENTS.md): Модель читает этот текст и держит его в контексте. Это декларативный подход. Она знает, что вы хотите, но не знает, как это сделать надежно. Если ей нужно запустить миграции, она будет пытаться угадать команду: npm run migrate, django manage.py migrate, alembic upgrade head. Иногда угадает, иногда нет.
  2. Скиллы (Инструменты): Скилл — это императивный подход. Вы даете модели конкретный инструмент run_migrations и говорите: Когда нужно применить миграции, вызови вот эту функцию/команду. Это устраняет угадывание. Модель тратит свои интеллектуальные ресурсы не на подбор команды, а на более высокоуровневую задачу: когда именно нужно вызвать этот инструмент.

Почему это повышает качество

  • Надежность и детерминизм: Вместо того чтобы модель каждый раз генерировала скрипт для деплоя, она вызывает скилл deploy_to_staging. Этот скилл написан человеком, он протестирован и работает надежно.
  • Снижение когнитивной нагрузки на модель: Модели гораздо проще выбрать один из 20 готовых инструментов, чем сгенерировать сложную последовательность действий с нуля. Это снижает вероятность ошибок и галлюцинаций.
  • Переиспользование и стандартизация: Скиллы становятся частью инженерной культуры. Все в команде, включая AI, используют одни и те же инструменты для стандартных задач.

Технологии и лучшие практики

  • Function Calling / Tool Using: Все современные модели (GPT-4.5/5, Claude 3.5, Gemini 2.5) имеют встроенные механизмы для вызова инструментов. Это позволяет им надежно работать со скиллами.
  • Агентные фреймворки: Такие инструменты, как LangGraph или AutoGen, позволяют строить графы выполнения, где агент может последовательно вызывать несколько скиллов для решения сложной задачи.

Полезные материалы

- Есть возможность лениво подгружать MCP-тулы?

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

Архитектура и механика работы Этот подход реализуется через двухуровневую систему вызова инструментов:

  1. Router Agent (Агент-маршрутизатор): Это легкий агент, у которого есть только один инструмент — tool_loader. В его промпте описаны не сами инструменты, а их высокоуровневые категории или домены. Например: инструменты для работы с базой данных, инструменты для деплоя в AWS, инструменты для анализа кода.
  2. Worker Agent (Агент-исполнитель): Это основной агент, который будет выполнять задачу.

Процесс работы:

  • Пользователь дает задачу: Проанализируй последнюю активность пользователя в базе данных и задеплой отчет в S3.
  • Router Agent анализирует запрос и понимает, что для его выполнения нужны инструменты из категорий database и aws.
  • Он вызывает свой инструмент tool_loader с параметрами ['database', 'aws'].
  • Система динамически подгружает только нужные скиллы, формирует контекст для Worker Agent и передает ему управление.

Технологии и лучшие практики

  • Фреймворки: LangGraph идеально подходит для создания таких маршрутизаторов, так как он позволяет строить условные переходы в графе выполнения.
  • Tool Description Optimization: Описания инструментов для Router Agent делаются очень краткими и емкими, чтобы минимизировать нагрузку на его контекстное окно.
  • Semantic Caching: Результаты tool_loader кэшируются. Если следующий запрос снова потребует инструменты для database, система не будет заново их загружать.

Что может пойти не так

  • Ошибка маршрутизации: Router Agent может неправильно определить необходимый набор инструментов, и тогда Worker Agent не сможет решить задачу.
  • Увеличение задержки: Дополнительный шаг маршрутизации немного увеличивает общее время ответа.

Полезные материалы

- Часто ИИ выполняет задачу используя обходные пути, которые кажутся нелогичными, но тем не менее рабочими. Хотелось бы исключить подобное поведение с помощью написания скиллов (как вариант), но пока все мои попытки потерпели фиаско. Хотелось бы услышать мнение на этот счет. Складывается впечатление, что под каждый проект нужно писать отдельные наборы скиллов.

Это очень точное наблюдение. Поведение, которое вы описываете, часто называют reward hacking в контексте Reinforcement Learning, но в случае с LLM это скорее prompt pathfinding — модель находит неочевидный, но формально корректный путь к цели.

И да, ваше впечатление абсолютно верно: эффективные агентные системы строятся на кастомных, специфичных для проекта наборах скиллов.

Почему общие скиллы не всегда работают Общие скиллы (например, read_file, write_file, run_command) дают модели слишком большую свободу действий. Она как начинающий джуниор, которому дали доступ к серверу — он может решить задачу, но сделает это, скорее всего, неоптимально и не так, как принято в команде.

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

Пример:

  • Задача: Добавить нового пользователя в систему.
  • Низкоуровневый подход (нелогичный путь):
    1. read_file('src/database/models.py')
    2. read_file('src/api/routes.py')
    3. run_command('grep -r addUser .')
    4. edit_file('scripts/temp_user_add.py') с новым кодом
    5. run_command('python scripts/temp_user_add.py')
  • Высокоуровневый подход (правильный путь):
    • Вы создаете скилл add_new_user(username, email).
    • Внутри этого скилла уже зашита вся правильная логика: вызов нужного API эндпоинта, работа с базой данных через ORM, валидация и т.д.
    • Агенту вы даете только этот скилл. Теперь у него просто нет возможности пойти обходным путем.

Технологии и лучшие практики

  • Domain-Specific Skills (DSS): Это стало целой дисциплиной. Команды создают библиотеки скиллов, отражающие их бизнес-домен.
  • Skill Discovery: Агенты могут сами предлагать создание новых скиллов. Если агент несколько раз выполняет одну и ту же последовательность низкоуровневых действий, он может предложить: Я часто делаю X, Y, Z. Может, создадим для этого скилл perform_common_task?.
  • Тестирование скиллов: Скиллы — это код. Они должны покрываться юнит-тестами так же, как и любой другой код в проекте.

Полезные материалы

- MCP

Это сокращение, которое может означать несколько вещей в контексте AI. Скорее всего, речь идет о Multi-Agent Control Plane или Model-Controller-Planner — архитектурных паттернах для управления сложными AI-системами.

Архитектура и механика работы (Multi-Agent Control Plane) Представьте себе авиадиспетчерскую вышку. У вас есть много самолетов (агентов), каждый со своей задачей. Control Plane — это и есть эта вышка.

  1. Agent Registry: Центральный реестр, где хранятся все доступные агенты, их специализации (например, Code-Writer-Agent, QA-Agent, DB-Admin-Agent) и их текущие статусы (свободен, занят).
  2. Task Scheduler/Orchestrator: Когда приходит сложная задача, оркестратор декомпозирует ее на подэтапы и распределяет между подходящими агентами. Например, для задачи добавить фичу и выкатить в прод он может составить такой план:
    • Code-Writer-Agent пишет код.
    • QA-Agent пишет тесты и их запускает.
    • Code-Writer-Agent исправляет баги.
    • Deployer-Agent выкатывает релиз.
  3. Shared Memory/State Manager: Все агенты имеют доступ к общему хранилищу состояния (например, векторной базе данных или графу знаний), чтобы обмениваться результатами своей работы.

Технологии и лучшие практики

  • Фреймворки: AutoGen от Microsoft и CrewAI — это де-факто стандарты для построения таких систем. Они предоставляют готовые блоки для создания групповых чатов агентов, управления их ролями и коммуникацией.
  • Иерархические структуры: Вместо плоской структуры используются иерархии. Есть Manager-Agent, который управляет командой Worker-Agent'ов. Это позволяет масштабировать систему.
  • Human-in-the-loop: В критических точках (например, перед деплоем) Control Plane запрашивает подтверждение у человека.

Что может пойти не так

  • Цепочка ошибок (Error Cascade): Ошибка одного агента может привести к неправильной работе всей цепочки. Решается через механизмы retry и fallback на каждом шаге.
  • Конкуренция за ресурсы: Два агента могут пытаться изменить один и тот же файл одновременно. Решается через блокировки или через передачу полного контекста на каждом шаге.

Полезные материалы

- Как заставить агента использовать mcp и skill на что обратить внимание? Второй вопрос есть ли публичные репозиторий пайплайнов и воркфлоу для мультиагентной разработки?

1. Как заставить агента использовать скиллы?

Просто добавить скилл в систему недостаточно. Нужно явно и точно указать модели, когда и как его использовать. Ключ к успеху — качественное описание инструмента (tool description).

На что обратить внимание:

  • Четкое имя функции: Название должно отражать действие. Не do_stuff, а deploy_to_production.
  • Описание функции (Docstring): Это самая важная часть. Здесь вы простым языком объясняете модели, что делает эта функция. Нужно использовать те же термины, которые пользователь будет употреблять в запросе.
  • Описание аргументов: Для каждого аргумента нужно точно указать его тип и назначение. Например, для аргумента environment нужно написать не просто env, а The deployment environment, must be one of ['staging', 'production'].
  • Примеры использования (Few-shot prompting): В системном промпте агента можно добавить несколько примеров. User: Выкати последнюю версию на прод. AI: tool_call(deploy_to_production, environment='production')

Технологии на 2026 год:

  • DSPy (Declarative Self-improving Language Programs): Это фреймворк от Stanford, который позволяет "компилировать" промпты. Вы задаете структуру, а DSPy сам подбирает оптимальные формулировки, включая few-shot примеры, чтобы максимизировать точность вызова инструментов.

2. Публичные репозитории воркфлоу

Да, такие репозитории активно развиваются и стали аналогом Docker Hub или GitHub Actions Marketplace, но для AI-агентов.

  • LangChain Hub: Это один из самых популярных хабов. Там можно найти и скачать готовые промпты, цепочки (chains) и настроенных агентов для решения типовых задач (SQL-агент, Code-Interpreter агент и т.д.).
  • CrewAI Blueprints: Сообщество CrewAI активно делится готовыми бригадами (crews) для разных задач, например, команда для исследования рынка или команда для написания технической документации.
  • Hugging Face Hub for Agents: Hugging Face, будучи центральной площадкой для моделей, также развивает направление для обмена агентными конфигурациями.

Полезные материалы

- Периодическое отваливание mcp

Проблема стабильности Control Plane в мультиагентных системах — одна из главных инженерных задач в 2026 году. Отваливание может происходить по множеству причин, от проблем с инфраструктурой до логических ошибок в поведении самих агентов.

Основные причины и решения

  1. Проблемы с LLM API (Rate Limits, Timeouts):

    • Причина: Мультиагентная система генерирует огромное количество запросов к API языковой модели. Вы можете упереться в лимиты по количеству запросов в минуту (RPM) или количеству токенов в минуту (TPM).
    • Решение:
      • Exponential Backoff & Retry: Внедрение умных механизмов повторных запросов с растущей задержкой. Библиотеки вроде tenacity в Python делают это очень просто.
      • Load Balancing: Если вы используете несколько ключей API или разные модели/провайдеров, можно распределять нагрузку между ними. Инструменты вроде LiteLLM отлично с этим справляются.
      • Локальные модели: Для менее критичных задач (например, классификация запроса для роутера) можно использовать локально развернутые SLM (Small Language Models) через Ollama или vLLM, чтобы снизить нагрузку на внешние API.

  2. Длительные задачи (Long-running tasks):

    • Причина: Один из агентов запускает задачу, которая выполняется очень долго (например, сборка тяжелого проекта). Это блокирует весь воркфлоу.
    • Решение:
      • Асинхронное выполнение: Задачи должны выполняться асинхронно. Control Plane не ждет завершения, а периодически опрашивает статус задачи.
      • Очереди задач: Использование брокеров сообщений, таких как RabbitMQ или Redis, для управления задачами. Оркестратор добавляет задачу в очередь, а свободный агент-воркер ее забирает.

  3. Логические циклы и "зависание" агентов:

    • Причина: Два агента могут войти в цикл, передавая задачу друг другу, или один агент может зациклиться, постоянно вызывая один и тот же инструмент с неверными параметрами.
    • Решение:
      • Max Retries & Timeouts: Установка максимального количества попыток для каждой задачи и общего времени на ее выполнение.
      • State Machine: Проектирование воркфлоу в виде конечного автомата (State Machine) с помощью LangGraph. Это позволяет явно определить все возможные состояния и переходы, исключая зацикливания.

Технологии и лучшие практики

  • Observability: Использование инструментов мониторинга, таких как LangSmith, Helicone или OpenTelemetry, чтобы отслеживать каждый вызов LLM, каждый вызов инструмента и видеть, где именно происходит сбой.
  • Health Checks: Реализация эндпоинтов для проверки здоровья каждого компонента системы (оркестратора, агентов, баз данных).

Полезные материалы

- Какие инструменты/средства удобнее всего использовать для отладки/тестирования MCP сервера?

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

1. Трассировка и Observability (Наблюдаемость) Это ваш главный инструмент. Вам нужно видеть каждый шаг, который делает система.

  • Инструменты:
    • LangSmith: Де-факто стандарт индустрии. Он автоматически логирует каждый вызов LLM, каждый вызов инструмента, показывает полный контекст, который был передан модели, и ее ответ. Вы можете видеть всю мыслительную цепочку агента.
    • Helicone: Отличная альтернатива, которая также предоставляет детальную аналитику, кэширование и управление затратами.
    • OpenTelemetry: Для более глубокой интеграции с существующей инфраструктурой мониторинга (например, если у вас уже есть Grafana, Prometheus, Jaeger).

2. Интеграционное и юнит-тестирование

  • Юнит-тесты для скиллов: Каждый скилл (инструмент) — это обычная функция. Ее нужно покрывать юнит-тестами, мокая внешние зависимости.
  • Мокинг LLM: В интеграционных тестах вам не нужно каждый раз делать реальный вызов к API OpenAI или Anthropic. Это дорого и медленно.
    • Библиотеки: Используйте библиотеки вроде pytest-recording или специализированные инструменты, которые записывают реальные ответы API в cassettes (кассеты) при первом запуске, а при последующих — воспроизводят их.
    • Тестовые модели: Для некоторых тестов можно использовать очень быстрые и дешевые модели или даже локальные SLM.

3. Интерактивная отладка (REPL-driven development) Очень эффективный подход при разработке воркфлоу.

  • Инструменты:
    • Jupyter Notebooks: Идеально подходят для пошаговой разработки и отладки цепочек и агентов. Вы можете выполнить каждый шаг отдельно, посмотреть промежуточный результат и внести изменения.
    • LangGraph Debugger: В LangGraph есть встроенные инструменты для визуализации графа выполнения и пошаговой отладки прямо во время работы агента.

4. Оценка (Evaluation) Как понять, что после изменений система не стала работать хуже?

  • Создание тестового датасета: Вы собираете набор типовых запросов и ожидаемых (эталонных) результатов.
  • Автоматизированный запуск: После каждого изменения вы прогоняете весь датасет и сравниваете реальные результаты с эталонными.
  • Метрики: Для оценки используются как точные метрики (например, был ли вызван правильный инструмент), так и LLM-based метрики (другая модель-оценщик, например, GPT-4.5, сравнивает ответ вашего агента с эталоном и выставляет оценку).

Полезные материалы

- Cross agent rule/skill share

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

Архитектура и механика работы Существует несколько паттернов для обмена скиллами и знаниями между агентами:

  1. Общая библиотека скиллов (Shared Skill Library):

    • Механика: Все агенты в системе подключены к одному и тому же центральному репозиторию скиллов (как мы обсуждали ранее). Это самый простой и надежный способ. Агент-менеджер просто говорит: Агент А, используй скилл generate_report из общей библиотеки.
    • Недостаток: Это не динамический обмен. Библиотека обновляется только человеком.

  2. Динамическое обучение и передача скиллов:

    • Механика: Один агент может научить другого. Представьте, что Senior-Developer-Agent успешно решил сложную задачу. Оркестратор может попросить его: Опиши последовательность своих действий в виде нового скилла и добавь его в общую библиотеку.
    • Технологии: Этот процесс называется Tool Making или Skill Creation. Модель генерирует не только код, но и документацию (docstring) для нового скилла.
    • Пример: AutoGen имеет встроенные возможности, где агент-пользователь может предложить сохранить успешный код в виде исполняемой функции для будущего использования.

  3. Общая память (Shared Memory):

    • Механика: Агенты не передают друг другу скиллы (код), а делятся результатами их применения (знаниями).
    • Технологии:
      • Векторная база данных: QA-Agent находит баг, создает отчет и сохраняет его эмбеддинг в общую базу. Когда Developer-Agent начинает работать, он делает поиск по базе и сразу находит этот отчет.
      • Граф знаний: Еще более продвинутый способ, где агенты обновляют общий граф сущностей и их связей.

Технологии и лучшие практики

  • Протоколы коммуникации: Разрабатываются стандартные протоколы для общения агентов, чтобы они могли понимать друг друга, даже если созданы на разных фреймворках.
  • Консенсусные алгоритмы: Если несколько агентов предлагают разные решения одной проблемы, используются алгоритмы для достижения консенсуса, например, голосование или дебаты.

Полезные материалы

- В разных проектах схожих по стеку иногда приходится повторять одно и то же. Агент долго ищет информацию и ответы на вопросы, на которые я знаю ответ - речь не про проектные знания (здесь можно добавить Readme / Claude.md / комментарии), а какие-то сложные библиотеки, например - было бы здорово где-то закешировать понимание агента как пользоваться в моих различных проектах каким-то определенным фреймворком или либой. В общем, что-то типа шеринга скиллов между проектами.

Это решается созданием персональной или командной базы знаний (Knowledge Base), интегрированной с агентом. Это не просто скиллы, а именно best practices, how-to гайды и примеры кода, которые агент использует как основной источник правды.

Архитектура и механика работы: Персональный RAG Вы создаете систему Retrieval-Augmented Generation (RAG), но в качестве источника данных выступает не весь интернет, а ваша личная, курируемая база знаний.

  1. Создание базы знаний:

    • Вы заводите отдельный репозиторий (например, my-tech-cookbook) на GitHub.
    • В нем вы в формате Markdown создаете заметки по всем сложным темам. Каждая заметка посвящена одной теме, например:
      • fastapi_dependency_injection.md
      • react_state_management_with_zustand.md
      • kubernetes_liveness_probes.md
    • В этих файлах вы описываете теорию, приводите работающие примеры кода, описываете частые ошибки.

  2. Индексация:

    • Вы настраиваете автоматический процесс, который при каждом обновлении этого репозитория:
      • Читает все Markdown-файлы.
      • Разбивает их на осмысленные фрагменты (чанки).
      • Создает для каждого чанка векторный эмбеддинг с помощью модели (например, text-embedding-3-large).
      • Сохраняет эти эмбеддинги в вашу персональную векторную базу данных (например, локальный ChromaDB или облачный Pinecone).

  3. Интеграция с агентом:

    • В системном промпте вашего агента вы указываете: Перед тем как искать ответ в интернете, всегда сначала ищи в моей персональной базе знаний.
    • Когда вы задаете вопрос, например: Как правильно настроить liveness probe в Kubernetes?, агент:
      • Создает эмбеддинг вашего вопроса.
      • Делает семантический поиск по вашей векторной базе.
      • Находит наиболее релевантные чанки из ваших заметок.
      • Вставляет их в свой контекст и генерирует ответ на их основе.

Технологии и лучшие практики

  • Инструменты для RAG: LlamaIndex и LangChain предоставляют все необходимые компоненты для создания такой системы "под ключ".
  • Гибридный поиск: Помимо векторного поиска, используется и обычный поиск по ключевым словам (BM25). Это улучшает релевантностью выдачи.
  • Персональные агенты: Платформы вроде Warp позволяют легко подключать такие внешние базы знаний как часть Rules или через специальные skills.

Полезные материалы

- Было бы здорово где-то закешировать понимание агента как пользоваться определенным фреймворком или либой

Это идеальный сценарий для комбинации двух техник: RAG с курируемой базой знаний (как в предыдущем ответе) и создание высокоуровневых скиллов.

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

Двухуровневый подход к кэшированию знаний

Уровень 1: Теоретические знания (RAG)

  • Вы создаете и поддерживаете базу знаний (набор Markdown-файлов) с лучшими практиками, примерами кода и объяснениями по вашим ключевым фреймворкам.
  • Агент использует эту базу для ответов на теоретические вопросы (как работает X?, какой паттерн лучше использовать для Y?).
  • Это кэширует декларативное знание.

Уровень 2: Практические навыки (Скиллы)

  • На основе этой базы знаний вы создаете высокоуровневые скиллы, которые инкапсулируют самые частые и важные операции.
  • Вместо того чтобы агент каждый раз по документации писал код для создания нового компонента React, вы даете ему скилл create_react_component(name, type).
  • Внутри этого скилла уже заложен правильный шаблон, структура файлов, подключение стилей и все остальные best practices вашей команды.
  • Это кэширует императивное знание.

Пример воркфлоу

  1. Вы: Создай мне новый компонент UserProfile в проекте.
  2. Агент (без скиллов, но с RAG):
    • Ищет в базе знаний how to create react component.
    • Находит ваш гайд.
    • Пытается сгенерировать код, следуя гайду (может получиться, а может и нет).
  3. Агент (со скиллами):
    • Видит, что у него есть инструмент create_react_component.
    • Понимает, что UserProfile — это имя.
    • Вызывает tool_call(create_react_component, name='UserProfile').
    • Скилл надежно и предсказуемо выполняет свою работу.

Технологии и лучшие практики

  • Автоматизация создания скиллов: Системы становятся достаточно умными, чтобы анализировать вашу базу знаний и автоматически предлагать кандидатов для создания новых скиллов.
  • Живая документация: База знаний не лежит мертвым грузом. CI/CD пайплайны могут автоматически запускать примеры кода из документации, чтобы убедиться, что они все еще актуальны.

Полезные материалы