Обложка цикла «ИИ: личный опыт без хайпа»
Обложка цикла «ИИ: личный опыт без хайпа»

Введение

В этом цикле статей я буду описывать личный опыт внедрения ИИ в разработку и личные задачи. Пойду эволюционным путем - от первого касания дальше, к подбору техстека, первым попыткам писать, переходу к SDD и TDD, мультиагентному программированию… а там видно будет, докуда дойду. Эта сфера слишком быстро эволюционирует, чтобы иметь точный план статей.

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

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

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

О себе. С нейросетями знаком 15+ лет, но они не были в фокусе. Я предпочитал быть сисадмином, потом системным разработчиком, вырос до роли, которую называют CTO.

Ремарка. ИИ будет использоваться, но не для генерации текста статей :-D

Начнем с истории

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

  • 1943 - Маккаллок и Питтс создают математическую модель искусственного нейрона.

  • 1951 - SNARC Мински и Эдмондса: одна из первых аппаратных нейросетей, которая уже моделировала обучение.

  • 1958 - Mark I Perceptron. Розенблатт с коллегами собирают в Cornell Aeronautical Laboratory аппаратную реализацию перцептрона. Smithsonian прямо называет Mark I “электронным воплощением” этой идеи. Это важный рубеж: вместо того чтобы жёстко прописывать решение, систему обучали на примерах. Правила распознавания ей не задавали вручную - она меняла веса связей в процессе обучения. Mark I решала простые задачи классификации визуальных образов, например различение геометрических фигур. По сути это уже машинное обучение в миниатюре.

  • 1960-е-1990-е. Главным ограничением оставалась вычислительная мощность. Поэтому доминировал символьный ИИ: правила задавали вручную. Появились экспертные системы, механизмы логического вывода, языки вроде Lisp и Prolog.

  • 2017 - Transformer. Эта архитектура стала основой современных больших языковых моделей (LLM).

Основные части и их взаимосвязи

Типичный диалог, который я слышал:

  • ну если не знает как сделать, добавим rag и порядок

  • ну да!

Нет, не так. И поэтому в конце я покажу полную схему - как я это вижу.

LLM

LLM (Large Language Model) - большая языковая модель: она понимает и пишет текст, держит нить рассуждения по контексту и следует инструкциям. Важный момент: сама по себе LLM обычно ещё не агент. Это “мозг”, который принимает prompt и выдаёт следующий ответ. Чтобы работать с внешним миром, ей нужны инструменты, память, MCP/API и агентная обвязка. Простая аналогия: LLM = сильный инженер без доступа к цеху. Он умеет разобрать задачу и объяснить решение, но чтобы что-то сделать снаружи, нужны инструменты и агент.

Agent

ИИ-агент - система на базе модели, которая не ограничивается ответом: она сама раскладывает задачу на шаги, подключает инструменты и доводит дело до результата. Могут возникнуть или быть заранее заданы блокеры/ограничения, требующие обращения к человеку. Это могут быть контрольные точки, не решаемые задачи или ограничения возможностй. Пример: “Найди причину перегрева станка и поставь его на паузу” → агент смотрит телеметрию → выбирает вероятную причину → останавливает станок.

Простая аналогия:

  • LLM = мозг.

  • Агент = помощник с мозгом, памятью, инструкциями и инструментами. Он не только говорит, что делать, но и делает.

    Сравнение LLM и ИИ-агента
    Сравнение LLM и ИИ-агента

RAG

RAG - Retrieval-Augmented Generation, по-русски это ближе всего к “генерации с опорой на найденные данные”. Смысл простой: модель не отвечает только из того, что запомнила на обучении. Сначала она достаёт нужную информацию из внешнего источника и уже потом строит ответ на основе найденного. Цепочка такая: вопрос → поиск документов → релевантные фрагменты → LLM → ответ. Важно: RAG - это не дообучение модели. И векторная база данных для него не обязательна - это лишь самый частый способ реализации поиска. Это хороший способ решить проблему устаревания данных, которыми оперирует модель. Отдельный важный вопрос - актуальность и полнота самих данных.

MCP

MCP (Model Context Protocol) - открытый протокол, который задаёт единый способ подключать ИИ-модели к внешним источникам и инструментам: API, базам, файлам, сервисам и всему остальному. Проще говоря, это общий интерфейс: через него LLM получает контекст и вызывает внешние действия. На практике агент может ходить в RSS разными путями:

  • каждый раз по новой искать путь, например сгенерировать код под REST API - дорого и непредсказуемо,

  • взять готовый MCP-сервер и через него читать новости, помечать их прочитанными, непрочитанными или важными и выполнять другие операции.

  • написать скрипт для выполнения задачи. Фактически - провести разработку

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

Skills

Skill ИИ-агента - это повторно используемая инструкция или набор инструкций, которые объясняют агенту, как решать задачи определённого класса. Skill - это рецепт. Готовить агент уже умеет; skill говорит, как именно приготовить конкретное блюдо. Единого стандарта жесткого Skills пока нет. Cursor, OpenCode, OpenClaw и Hermes опираются на похожую идею - инструкции в Markdown. Это стандарт de-facto. Поэтому переносимый skill разумнее собирать так: универсальные указания отдельно, MCP и tools - отдельно. Тогда один и тот же “рецепт” проще переносить между Cursor, OpenCode, OpenClaw и Hermes. Текст рецепта можно отдать разным поварам. Но если в нём написано “нажми кнопку №7 на моей духовке”, на другой кухне его придётся переписывать. Пример почти универсального skill:

По тексту или ссылке сделай короткий обзор.

1. О чём статья - 2 предложения.
2. Тезисы - 5 пунктов.
3. Самое важное - факты, выводы, ограничения.
4. Практический вывод - что с этим делать.

Часто дается неверная аналогия, что MCP - это всего лишь API. Это совершенно разные сущности. MCP - стандартизированный протокол взаимодействия, а API — общий термин для интерфейса Если разбить по уровням, то получается такая схема:

  • API - конкретный технический способ вызвать систему.

  • MCP - стандартный слой, через который агент видит доступные инструменты и данные.

  • RAG - механизм поиска знаний для контекста.

  • Skill - более высокоуровневое “умение”: инструкция, когда и в каком порядке использовать RAG, MCP-инструменты и другие возможности.

Хорошая аналогия:

Концепция

Аналогия

Короткая формула

RAG

архив чертежей и регламентов

где найти нужные знания

API

пульт конкретного станка

как обратиться к одному станку или системе

MCP

единый цеховой пульт управления

стандарт, через который агент видит и запускает доступные механизмы

Skill

технологическая карта на операцию

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

Память

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

Реализации бывают разные. Можно выделить основные принцципы:

  • память для устойчивых фактов и решений

  • предпочтения и профиль пользователя

  • самообучение - агент может собирать skills из общения с пользователем. Например, агент Hermes

  • информация на уровне проекта - заметки, контекст и проектные инструкции

Контекст и память - не одно и то же. Контекст - то, что агент видит сейчас, в текущей сессии. Память - то, что переживает сессию и может пригодиться позже. MEMORY.md - это память; последние 20 сообщений чата - контекст.

Промт

Prompt - это формулировка задачи для ИИ: что сделать и в каких рамках. Простая аналогия: Prompt = задание главному инженеру или автомеханику. Например: “Разбери причину стука в подвеске и опиши проверку по шагам”. Чем точнее prompt, тем яснее модели цель, формат, ограничения и нужный результат. А далее как с людьми. Чем мощнее модель и чем лучше у неё обвес (знания, инструменты), тем больше шанс успешно решить задачу.

Немного практики

Из практики: один и тот же размытый запрос “прочитай новости из RSS на сервере и отбери дубликаты” отрабатывал по-разному.

  • Одна из топовых моделей сразу лезла в REST API и каждый раз генерировала код.

  • Локальная модель на видеокарте не поняла ни задачу, ни способ решения.

Я подключил MCP-сервер и уточнил формулировку: “использовать MCP-сервер Nextcloud”.

  • Топовая модель отработала корректно.

  • Локальная почти всегда начала ходить именно через этот MCP.

Смена LLM всё равно сильно била по результату: другой формат вывода, другие тексты подтверждений и так далее. Поэтому я собрал такую схему:

  • MCP-сервер с нужными доступами

  • Набор skills: как читать новости нужного типа - ходить через MCP, какой адрес сервера, как фильтровать, как показывать таблицу с нужными полями

  • Команда (привязанная к агенту): список skills и правила:

    • порядок (чёткий список, чтобы дубликаты убирались в начале)

    • формат вывода (принцип фильтрации как подзаголовок, затем таблица по этому фильтру)

    • правила подтверждения, например “отмечай прочитанными только после согласия пользователя”

Теперь при смене модели формат выдачи и порядок подтверждений стали стабильнее.

RSS: от размытого запроса к настроенному окружению
RSS: от размытого запроса к настроенному окружению

Что такое харнесс (harness)

И тут мы пришли к важному термину: AI Harness - слой, который превращает вероятностный ИИ в управляемую инженерную систему.

В разработке harness - это набор технических и организационных ограничений, который направляет недетерминированное поведение LLM и агента. За счёт этого работа становится предсказуемее, контролируемее и воспроизводимее в заданных рамках. Не гарантия, но куда более предсказуемое поведение.

В широком смысле сюда относят:

  • саму LLM и её настройки

  • prompts, tools, memory, context

  • agent loop и оркестрацию

  • permissions, guardrails, sandbox

  • тесты, evals, мониторинг

  • архитектурные правила и coding standards

  • спецификации конкретного проекта

  • процессы review и approval

Сейчас ИМХО индустрия в основном занимается именно этим: собирает окружение, в котором:

  • поведение системы остается вероятностным, но становится более предсказуемым

  • замена LLM почти не влияет на итоговый результат (в рамках равнозначных моделей)

Итоговая схема

Схема взаимосвязей терминов
Схема взаимосвязей терминов

Выводы

Мои ключевые выводы я выведу таблицей.

Вывод

Пояснение

Общий язык нужен для решения задач, а не только для знания аббревиатур.

Зная инструменты, можно построить систему для решения своих задач

LLM и готовая система - не одно и то же.

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

Разные компоненты закрывают разные потребности.

Инструменты разнообразны. Необходимо знать и комбинировать их в своих проектах

Устойчивость появляется через явную организацию работы.

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

Окружение повышает управляемость, но не отменяет ограничения модели.

Harness помогает ограничивать действия и проверять результат. Однако не гарантирует правильность каждого ответа или безболезненную замену LLM. Ответственность всё равно на человеке

Конспект терминов

В дополнение добавлю краткий словарик, включая дополнительные термины.

Термин

Роль

Простой вопрос

LLM

движок рассуждения и генерации

Что модель сейчас думает и пишет?

Prompt

входные указания и данные

Что именно передали модели?

Context

данные текущего вызова

Что модель видит в этот момент?

Memory

сохранённые сведения

Что система может поднять из прошлого?

Agent

принимает решения и ведёт действия

Какой следующий шаг?

Agent loop

цикл выбора следующих шагов

Нужен ли ещё один ход?

Tool

атомарная внешняя операция

Что система умеет сделать снаружи?

Skill

повторно используемый способ решения

Как агент решает этот класс задач?

MCP

стандарт подключения возможностей

Как подключить внешний tool или контекст?

MCP Server

источник MCP-возможностей

Кто отдаёт tools и resources?

RAG

подбор релевантных знаний

Какие данные докинуть в context?

Embedding

смысловое представление данных

Какие фрагменты близки по смыслу?

State

состояние процесса

На каком шаге сейчас?

Workflow

заранее описанный маршрут

Какой путь задал разработчик?

Handoff

передача задачи другому исполнителю

Кому из агентов отдать работу и как?

Guardrail

ограничение допустимых действий

Это вообще разрешено агенту?

Источники

Комментарии (0)