Как аналитику вкатиться в ИИ: от чата к агентам с руками

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

Через несколько минут приложение нашло настоящий конфликт: в одном документе были указаны три редакционных роли, в другом — четыре, в актуальном списке — пять. Не абстрактный совет «проверьте согласованность документации», а конкретные файлы и конкретные строки. Вот момент, когда ИИ перестаёт быть собеседником и становится рабочим инструментом.

Вкатиться — это дать ИИ одну настоящую работу

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

1. Возьмите копию папки без паролей, персональных данных и корпоративных секретов.
2. Откройте её в агентском приложении — например, в Codex из терминала.
3. Проверьте границу рабочего пространства и включите режим только для чтения. В Codex для этого есть /status и /permissions → Read only.
4. Дайте проверяемую задачу, а не «расскажи, что тут интересного».

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

Такой старт сразу учит трём вещам. Во-первых, модель знает только то, что ей действительно передали. Во-вторых, доступ к инструменту и право изменить данные — не одно и то же. В-третьих, хороший результат можно проверить по исходным файлам, а не по уверенности ответа.

Не каждый вызов LLM — агент

Словом «агент» часто называют всё, где есть модель. Для проектирования полезнее различать пять форм.

Форма	Что происходит	Когда достаточно
Один запрос → текст	Модель пишет ответ	Черновик, классификация, объяснение
Структурированный ответ	Модель возвращает JSON по схеме	Когда ответ дальше обрабатывает код
RAG	Приложение находит документы и кладёт фрагменты в контекст	Ответ по базе знаний
Workflow	Шаги и развилки заранее записаны в коде	Стабильный бизнес-процесс
Agentic loop	Модель выбирает следующий tool по результату предыдущего шага	Маршрут заранее неизвестен

Обычный код тоже умеет ветвиться. Граница не в наличии if/else, а в том, кто выбирает следующую операцию: программа по заранее записанному правилу или модель по текущему контексту. В production эти формы обычно смешивают: обязательные и опасные переходы фиксирует workflow, внутри безопасного участка следующий ход выбирает модель.

Что происходит после Enter

На экране одна переписка. Под капотом — серия вызовов модели и обычный код между ними.

sequenceDiagram
    actor U as Аналитик
    participant H as Harness
    participant M as Модель
    participant T as Инструмент
    U->>H: Изучи папку
    H->>M: Задача + контекст + доступные tools
    M-->>H: tool call: прочитать файл
    H->>H: Проверить формат и разрешения
    H->>T: Выполнить разрешённое чтение
    T-->>H: Результат или ошибка
    H->>M: Новый контекст с результатом
    M-->>H: Следующий tool call или финальный ответ
    H-->>U: Результат

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

Модель может вернуть обычный текст, а может — структурированный запрос: имя инструмента и аргументы. Это tool call. Он ещё ничего не прочитал, не отправил и не удалил: модель только предложила действие.

Harness валидирует форму запроса, применяет локальную policy и вызывает инструмент, если действие разрешено. Инструмент возвращает результат или ошибку — часто это называют observation. Результат добавляется в новый контекст, и модель выбирает следующий ход. Петля повторяется до проверяемого завершения, запрета, лимита или вмешательства человека.

Пересказ схемы одной строкой: модель предлагает → harness разрешает и исполняет → инструмент меняет или читает среду → результат возвращается модели.

Семь вопросов к любому агентскому приложению

Представим задачу: «найди зависшие платежи, исправь статусы и отпиши клиентам». Один неудачный шаг здесь меняет деньги, учёт и отношения с людьми. Схема «LLM подключили к Jira» не объясняет почти ничего. Нужен паспорт системы.

Вопрос	Что надо зафиксировать
Контекст	Какие инструкции, документы и данные увидит модель?
Следующий ход	Где решает код, а где модель?
Tools	Какие бизнес-действия доступны и как описаны аргументы?
Права	Что разрешают policy, sandbox, токен и целевая система?
State	Что сохранится между шагами и после перезапуска?
Stop	Кто остановит повторы, ошибки, рост цены и выход за scope?
Done	Какая независимая проверка доказывает результат?

Это готовый чек-лист для архитектурного ревью. Если хотя бы одного ответа нет, перед вами демо, а не управляемая система.

Кто не даёт агенту изменить всё подряд

У безопасности нет одной кнопки. Работают несколько независимых слоёв.

• Схема tool проверяет, что аргументы имеют правильную форму. Валидный JSON ещё не означает разрешённую операцию.
• Policy harness решает, какие инструменты и аргументы допустимы в этой задаче.
• Approval ставит работу на паузу и просит подтверждение там, где оно предусмотрено. В ночном batch спросить некого — рискованный вызов должен завершиться отказом.
• Sandbox технически ограничивает процесс: куда можно писать, какие команды запускать, доступна ли сеть.
• Целевая система отдельно проверяет токен, scopes, роли и атрибуты доступа.
• Бизнес-операция валидирует сам переход: можно ли именно этот платёж перевести из текущего статуса в новый.

Хороший tool выражает бизнес-намерение: change_payment_status(id, from, to, reason). Универсальный run_sql(query) отдаёт модели слишком большую поверхность ошибки. Чем понятнее и уже глагол, тем легче ограничить права, проверить вход и доказать результат.

Где живут контекст, состояние и «память»

Словом «память» называют четыре разные вещи — отсюда половина споров.

• Параметры модели — то, чему её обучили. Ваш список обработанных платежей туда во время задачи не записывается.
• Контекст вызова — рабочий стол модели прямо сейчас: задача, инструкции, фрагмент истории, tools и свежие результаты. Он конечный и пересобираемый.
• Session log — журнал ходов, tool calls и ошибок, который хранит приложение за пределами модели.
• Durable state — файлы, записи БД, статусы задач, коммиты, артефакты и чек-лист прогресса. С этого можно продолжить завтра.

RAG — не тайная память модели, а поиск: приложение достаёт подходящие фрагменты и кладёт их в текущий контекст. Длинный чат тоже не гарантия. Старые куски могут быть обрезаны или сжаты, а при сжатии теряются точные числа и незакрытые хвосты.

goal: проверить требования
done: [структура, роли]
next: проверить интеграции
open_questions: [кто подтверждает изменение статуса]
artifacts: [review.md, contradictions.csv]

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

Чем MCP отличается от обычного API

Здесь чаще всего смешивают две независимые оси.

1. Кто выбирает следующий вызов: код по правилу или модель по контексту.
2. Как подключён инструмент: собственным клиентом напрямую к API или через общий протокол MCP.

Модель может выбрать обычную функцию, которая напрямую обращается к Jira API. И наоборот: жёсткий workflow может вызвать MCP tool без выбора модели. MCP не делает систему агентской — он решает другую задачу.

Обычное API — контракт конкретного сервиса. Разработчик читает документацию Jira, пишет Jira-specific client и знает её endpoints, OAuth и ошибки. Для GitLab нужен другой клиент.

MCP (Model Context Protocol) — общий контракт между AI-приложением и поставщиком возможностей. Host — агентское приложение, где живут модель, loop и правила. MCP client — его соединитель с конкретным поставщиком. MCP server — адаптер, который выставляет tools и обычно вызывает за ними REST API, SDK, SQL или локальную команду.

sequenceDiagram
    participant M as Модель или workflow
    participant H as Host / harness
    participant S as MCP server
    participant J as Jira API
    H->>S: tools/list
    S-->>H: Tools + описания + схемы
    H->>M: Задача + доступные tools
    M-->>H: Выбранный tool call
    H->>H: Policy и approval
    H->>S: tools/call
    S->>J: Обычный REST / SDK
    J-->>S: Данные или ошибка
    S-->>H: Tool result

Jira API никуда не исчезает. MCP стандартизирует обнаружение и вызов возможностей: один host одинаково подключает разные MCP servers, а один server можно использовать в разных совместимых hosts. Он не отменяет OAuth, scopes, бизнес-авторизацию и проверку побочных эффектов.

Если два backend-сервиса стабильно общаются по известному контракту, оставьте обычное API. MCP начинает окупаться, когда одну возможность надо открыть разным AI-приложениям или host собирает много инструментов разных поставщиков.

Пересказ схемы: host получает у MCP server каталог возможностей, модель или workflow выбирает tool, host применяет свою policy, server переводит стандартный вызов в обычный запрос к Jira. Способ подключения и способ выбора шага — разные решения.

Почему «готово» модели ничего не доказывает

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

1. Артефакт существует: файл создан, статус изменён, письмо поставлено в очередь.
2. Техническая проверка прошла: схема валидна, тест зелёный, запись читается обратно.
3. Бизнес-инвариант восстановлен: повторная выборка не находит зависших платежей, каждый переход попал в audit log, повторный запуск не отправляет второе письмо.

Проверка должна смотреть на конечное состояние среды, а не на красоту ответа модели. Если инвариант не восстановлен, harness может повторить только безопасный шаг, остановиться, откатить транзакцию или передать работу человеку — но не обязан бесконечно просить модель «попробовать ещё».

Для самой агентской системы нужен eval harness: набор типовых и неприятных задач, изолированная среда, запись траекторий и grader. Оценивают всю связку модель + prompt + tools + права + loop по четырём группам:

• outcome — верно ли конечное состояние;
• process — не было ли запрещённых и бессмысленных действий;
• efficiency — сколько шагов, времени и денег ушло;
• recovery — что произошло после ошибки или неполных данных.

Результаты таких прогонов становятся отдельным аналитическим дата-потоком: вместе с итогом сохраняют версию модели и prompt, набор tools, траекторию, стоимость и оценку grader. Без этого регрессию не отличить от случайного удачного запуска.

Один удачный прогон ничего не доказывает: система вероятностная. Для релиза нужен порог по серии повторов и защита от регрессий. Это продолжение обычной аналитической дисциплины — Definition of Done и тестирование, только объектом проверки стала связка с моделью.

Когда нужен не один агент

Пять ролей в промпте — ещё не пять агентов. Одну и ту же модель можно попросить сначала написать текст, затем сыграть редактора, затем критика. Это несколько ролей внутри одного процесса.

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

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

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

A2A — не MCP между агентами. MCP подключает к приложению инструмент. A2A стандартизирует общение независимых агентских систем: одна система публикует карточку своих возможностей, другая поручает ей короткую или долгую задачу и получает статусы и готовые артефакты. У каждой стороны остаются собственные harness, память, права и tools.

MCP: агентское приложение ↔ инструмент
A2A: агентское приложение ↔ другое агентское приложение

Маршрут: как аналитику вкатиться без цирка

Шаг 1. Научитесь получать проверяемый ответ. Один запрос, чёткая задача, требуемый формат, ссылки на исходные данные. Затем JSON по схеме и валидация. Это база из записи про LLM в продукте.

Шаг 2. Дайте модели безопасное чтение рабочей среды. Копия папки, никаких секретов, read-only, задача с точными цитатами. Посмотрите на tool calls и поймите, что контекст собирается по шагам.

Шаг 3. Разрешите создавать один артефакт. Например, review.md рядом с копией документов. До запуска зафиксируйте формат, путь и критерий готовности. Проверьте diff руками.

Шаг 4. Добавьте автоматическую проверку. Пусть агент не только создаёт схему или спецификацию, но и запускает линтер, тест, компиляцию диаграммы или сверку бизнес-инварианта. «Готово» должно подтверждаться средой.

Шаг 5. Подключайте внешнюю систему только узкими правами. Сначала read-only поиск в Jira или базе. Потом одно обратимое действие с approval, audit log и идемпотентностью. Не начинайте с универсального доступа к SQL и рассылке клиентам.

Шаг 6. Субагенты — в самом конце. Сначала добейтесь предсказуемого результата от одного loop. Параллелить хаос — значит получать хаос быстрее и дороже.

Что здесь действительно является трендом

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

• tools подключаются через общие протоколы вроде MCP;
• долгие задачи оставляют durable state и умеют возобновляться;
• права, sandbox и approval становятся явной частью продукта;
• evals проверяют конечное состояние, цену и восстановление после ошибки;
• независимые агентские системы обмениваются задачами и артефактами через протоколы вроде A2A.

Модель важна, но конкурентное преимущество всё чаще находится не в названии модели, а в качестве harness: какой контекст он собрал, какие руки дал, где остановил и чем доказал done.

Частые вопросы

Чем ИИ-агент отличается от чат-бота?

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

Что такое harness простыми словами?

Это управляющая обвязка вокруг модели. Она собирает входной контекст, сообщает модели доступные tools, исполняет разрешённые tool calls, хранит состояние, применяет лимиты и проверяет, действительно ли задача завершена. Модель предлагает шаги; harness превращает разрешённые предложения в работу системы.

MCP заменяет REST API?

Нет. REST API остаётся контрактом конкретной системы. MCP server часто стоит перед ним и выставляет его возможности AI-приложениям в общем формате. MCP уменьшает количество уникального интеграционного клея, но не отменяет OAuth, scopes, бизнес-права и прямые API-интеграции там, где они проще.

Можно ли доверять режиму read-only?

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

Нужны ли аналитику мультиагенты?

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