Объяснение вызова инструментов: как модели запрашивают у программного обеспечения выполнение действий и где возникают сбои.
Практический обзор вызова функций и использования инструментов: цикл запросов, схемы, инструменты для чтения и выполнения действий, агенты, MCP, внедрение промптов, отслеживание и распространенные сбои.
Источники: Function Calling and Tool Use: How AI Agents Automate Workflows
Первые чат-боты были устройствами для ответов на вопросы. Человек вводил запрос, приходил ответ, и на этом обмен заканчивался. Это было полезно, но ограничено. Модель могла описать, как забронировать билет на самолет, но не могла узнать цены на сегодняшний день. Она могла объяснить, что содержится в счете-фактуре, но не могла создать его в системе бухгалтерского учета. Она могла предложить время встречи, но не имела возможности посмотреть календарь кого-либо, не говоря уже о том, чтобы добавить мероприятие туда.
Вызов функций устраняет это ограничение. Языковая модель получает возможность просить помощи у окружающего программного обеспечения, и вся остальная структура развивается на основе этой одной способности.
Модель, которая может просить о чем-либо
Без инструментов модель отвечает на основе того, что она усвоила во время обучения. С их помощью она может сделать вывод, что для ответа на вопрос требуется внешняя помощь, и указать, какой инструмент должен её предоставить: служба погоды, поисковый индекс, запрос к базе данных, калькулятор, календарь, процесс оплаты, поиск в CRM, интерпретатор кода или какая-либо внутренняя бизнес-функция. Вместо угадывания модель формирует структурированный запрос, приложение его выполняет, и модель продолжает работу, имея в своем распоряжении более свежую и точную информацию. Крупные провайдеры, такие как OpenAI, Anthropic и Google, а также фреймворки вроде LangChain, описывают использование инструментов примерно одинаково: модели предоставляются четко определенные инструменты, она сама решает, когда их использовать, передает структурированные аргументы и включает полученные результаты в свой ответ или действие.
Полезное визуальное представление: модель — это «мозг» для общения, а инструменты — это руки, глаза, память, калькулятор, шкаф для хранения документов и фургон для доставки. Мозг определяет, чего хочет пользователь. Инструменты выполняют те задачи, которые невозможно безопасно или надежно выполнить с помощью простого генерирования текста.
Вызов функции против вызова инструмента
Эти два термина часто используются как синонимы, но второй более точен, поскольку его значение выходит за рамки классических программных функций. Инструмент может быть чем-то простым, например get_weather(location), но также может представлять собой поиск в базе данных, сессию браузера, извлечение документа, калькулятор, команду оболочки, процесс проектирования или ссылку на внешний сервис. В терминологии OpenAI инструмент — это возможность, предоставляемая модели, а вызов инструмента — это особый вид ответа модели с просьбой использовать один из таких инструментов.
Крайне важно понимать, что модель обычно сама ничего не выполняет. В типичной схеме работы с клиентской стороны она возвращает структурированный запрос, например вызов функции get_customer_profile с параметром customer_id равным 12345. Приложение получает этот запрос, анализирует его, выполняет реальную функцию, собирает результат и возвращает его модели, которая затем формирует свой окончательный ответ. Документированная последовательность действий: предоставление доступных инструментов, получение их вызова, выполнение кода в собственном приложении, отправка результата и получение либо окончательного ответа, либо дополнительных вызовов инструментов.
Существуют исключения. Некоторые поставщики также предоставляют инструменты, работающие с серверной стороны на их инфраструктуре. Anthropic четко разделяет эти подходы: клиентские инструменты выполняются вашим приложением и представляются в виде структурированных блоков использования инструментов, тогда как серверные инструменты, такие как поиск в интернете или выполнение кода, могут работать на стороне Anthropic.
Это различие имеет большое значение. Фраза «модель вызвала API» может означать, что модель сгенерировала запрос к вашему программному обеспечению для его выполнения, или же что платформа сама запустила встроенный инструмент от имени модели. В реальных условиях это влияет на уровень безопасности, систему логирования, затраты, способ обработки данных, процедуры утверждения действий, а также на ответственных лиц в случае возникновения проблем.
Цикл в пяти шагах
Большинство систем вызова функций выполняют один цикл.
- Определите инструменты. Каждый инструмент получает название, описание и список ожидаемых входных данных. Для инструмента погоды могут понадобиться название города и страна. Для инструмента возврата средств — идентификатор заказа, причина и максимальная сумма. Для инструмента планирования — участники, дата, время и тема. Примеры от OpenAI описывают параметры в стиле JSON Schema с обязательными полями и ограничениями, такими как значение additionalProperties, установленное в false, а документация Google Gemini показывает объявления функций, сформированные на основе названий, описаний и структур входных данных.
- Пользователь запрашивает что-то. Модель читает запрос и определяет, может ли она ответить сразу. Запрос «Объясните, что такое вызов функции» вероятно, не требует использования инструментов. Запрос «Каков статус заказа 8472?» почти наверняка требует их использования.
Цикл может выполняться один раз или многократно. Агент может выполнять поиск, сравнивать результаты, вызывать другие инструменты, задавать дополнительные вопросы, обновлять записи и в конце концов подводить итоги своих действий.
Язык как интерфейс
Настоящая привлекательность использования инструментов заключается в том, что повседневный язык становится гибким интерфейсом для программного обеспечения.
Традиционно каждая функция требует собственных кнопок, форм, меню и алгоритмов работы. Благодаря вызову функций пользователь может напрямую указать свою цель: найти самый свежий счет от Acme, проверить, поступил ли платеж, и в случае отсутствия платежа отправить вежливое напоминание по электронной почте. Одно предложение скрывает за собой несколько инструментов: поиск в CRM, получение счета, проверка статуса платежа, создание черновика письма и, возможно, запрос на утверждение перед отправкой.
Хороший дизайн продукта — это не вещь, которую можно опустить. Изменяется лишь место, где начинается интерфейс. Вместо того чтобы заставлять пользователей изучать структуру программного обеспечения, оно должно соответствовать тому, как люди уже обсуждают свою работу.
Это придает огромное значение описаниям инструментов. Неопределенное описание заставляет модель сомневаться в том, как им пользоваться. Четкое описание указывает, когда его использовать, что он делает, что означают каждые входные данные и что нельзя предполагать. Документация LangChain представляет инструменты как функции с четко определенными входными и выходными данными, отмечая, что подсказки типов и краткие описания помогают модели правильно ими пользоваться.
Хороший инструмент — это не просто функция. Это контракт.
Четыре понятия, которые пересекаются
Люди часто путают эти термины, хотя они относятся к разным уровням.
- Вызов функции — это механизм: модель запрашивает структурированный вызов функции или инструмента.
- Использование инструментов — это более широкая возможность. Она включает в себя вызов функций, встроенные инструменты, поиск в Интернете, поиск файлов, выполнение кода, управление компьютером, удаленные серверы и любые другие способы взаимодействия модели с внешними системами.
- Агент — это система, которая последовательно использует инструменты на нескольких этапах для достижения цели. OpenAI описывает агентов как приложения, которые планируют действия, используют инструменты, взаимодействуют со специалистами и отслеживают прогресс в рамках многоэтапных задач; SDK для агентов OpenAI определяет агента как LLM, настроенный с помощью инструкций, инструментов и дополнительных элементов, таких как передача задач, ограничения и структурированные результаты.
Другими словами: вызов функций — это разъём, инструменты — это устройства, подключённые к нему, сотрудники решают, как и когда их использовать, а автоматизация обеспечивает работу всей системы как единого целого.
Зачем это нужно?
Модели языка хорошо справляются с пониманием, объединением и передачей информации. Однако они плохо заменяют калькуляторы, базы данных или реальные мониторы. Они могут писать о погоде, но не смогут узнать прогноз на сегодня, если у них нет доступа к соответствующим данным. Они могут обсуждать счета, но не смогут получить доступ к вашей системе биллинга, если она не подключена. Они могут объяснять код, но не смогут определить, неисправен ли ваш сервис, без данных мониторинга.
Инструменты помогают преодолеть эти недостатки. Калькулятор обеспечивает точность арифметических вычислений. Поисковые инструменты предоставляют актуальные факты. Инструменты по извлечению информации основывают ответы на данных из частных документов. Инструменты баз данных отвечают на вопросы, связанные с корпоративными записями. Инструменты управления рабочими процессами создают заявки, отправляют сообщения, обновляют заказы или бронируют встречи. В документации Google Gemini преимущества этих моделей сводятся к трём пунктам: расширение знаний, улучшение возможностей и взаимодействие с внешними системами.
Именно здесь взаимодействие перестаёт казаться чатом и начинает напоминать работу программного обеспечения. Модель больше не просто генерирует слова; она помогает координировать действия.
Исследования, лежащие в основе этой идеи
Агенты, использующие инструменты, не появились из ниоткуда. Развитие этой области было обусловлено четырьмя ранними исследованиями.
- MRKL Systems (2022) предложили модульную архитектуру, соединяющую языковые модели с внешними модулями знаний и рассуждений. Основная идея была проста: не просите одну модель делать всё; поручайте каждую задачу специализированному компоненту.
- ReAct (2022) исследовал способы, с помощью которых модели могут сочетать процесс рассуждений с действиями. Вместо того чтобы либо только рассуждать, либо только действовать, подход ReAct предполагает, что модель сначала рассуждает, затем действует, наблюдает за результатом и корректирует свой план. Такой цикл улучшает производительность при решении задач на ответы на вопросы и принятие решений, а также делает поведение модели более понятным.
- Toolformer (2023) проверял, может ли модель научиться использовать инструменты через простые API. Она научилась определять, когда необходимо использовать инструмент, что отправлять и как обрабатывать полученный результат, приводя в пример калькуляторы, поисковые системы, переводчики и календари.
- Gorilla (2023) решал проблему массовых вызовов API и связанных с этим трудностей: при наличии большого количества инструментов модели иногда выдумывают необходимость в вызовах или передают неверные аргументы. Gorilla сочетал процессы обучения и поиска информации, что позволяло системе отслеживать изменения в документации API и совершать меньше ошибок.
Всё это сводится к одной идее: лучшие ИИ-системы — это не изолированные модели. Они являются частью более крупных систем, соединённых с инструментами, памятью, правилами, программным обеспечением и человеческим контролем.
Как выглядит хороший инструмент
Качественные инструменты имеют узкую специализацию, являются понятными и безопасными.
Инструменты узкой специализации легче поддаются выбору моделями и контролю со стороны разработчиков. Инструмент под названием update_everything слишком расплывчат и опасен; create_refund_request более понятен. approve_refund требует ещё большей осторожности, поскольку влияет на реальный мир.
Понятные инструменты имеют простые названия и описания. Модель не должна гадать, означает ли функция fetch_record получение профиля клиента, загрузку файла или извлечение медицинской карты. В описании должны быть указаны его назначение, ситуации, когда он требуется, значение каждого аргумента и форма возвращаемого значения.
Безопасные инструменты оснащены встроенными ограничениями. Они проверяют права доступа, верифицируют входные данные и не предоставляют лишних привилегий. Они сообщают четкие ошибки, ведут журналы записей и запрашивают подтверждение у человека перед выполнением чувствительных действий. Они никогда не предоставляют модели больше полномочий, чем требуется для выполнения задачи.
OpenAI рекомендует использовать строгие схемы, чтобы аргументы поступали надежно, а его SDK для агентов направляет разработчиков на соблюдение определенных правил, проведение человеческой проверки, получение четких результатов, управление состоянием и обеспечение возможности наблюдения по мере роста рабочих процессов. На практике лучшие инструменты бывают довольно простыми: каждый из них хорошо справляется с одной задачей и не удивляет никого — ни разработчиков, ни модели, ни пользователей.
Схемы как грамматика
Схема представляет собой грамматику использования инструмента. Когда модель вызывает функцию, она должна передавать аргументы в формате, понятном приложению. Схема определяет, какие поля существуют, какой у них тип, какие из них обязательны, а иногда и какие значения допускаются. Инструмент для прогноза погоды может требовать строковое указание местоположения и поле с единицами измерения, ограниченное значениями «градусы Цельсия» или «градусы Фаренгейта».
Строгие схемы устраняют неоднозначность и упрощают проверку данных. В документации OpenAI объясняется, что режим строгости обеспечивает соблюдение заявленной схемы при выполнении запросов, требуя, чтобы параметр additionalProperties имел значение false для всех обязательных полей, а опциональные значения указывались с помощью типов, допускающих отсутствие значений.
Однако схема сама по себе не делает систему безопасной. Запрос с идеально сформатированными данными может всё равно оказаться ошибочным. Запрос send_email, адресованный all_customers@example.com, может полностью соответствовать схеме, но при этом оставаться ужасной идеей. Поэтому проверка схемы должна сопровождаться бизнес-правилами, механизмами авторизации, ограничениями по частоте запросов, процедурами проверки и мониторингом.
Чтение против действий
Одним из важных аспектов проектирования является выбор того, будет ли инструмент выполнять только операции чтения или также действия.
Инструменты с режимом только для чтения собирают информацию: ищут документы, проверяют записи, отслеживают запасы, получают данные о погоде, рассчитывают суммы, анализируют журналы. Они всё равно могут раскрывать конфиденциальные данные и требуют контроля доступа, но обычно не вносят никаких изменений.
Инструменты для выполнения действий реализуют конкретные задачи: они отправляют электронные письма, оформляют заказы, отменяют подписки, выдают возвраты средств, обновляют базы данных, создают заявки, развертывают код или планируют встречи. Ошибки при их использовании имеют серьёзные последствия.
Хорошо спроектированный агент относится к этим двум типам инструментов по-разному. Инструменты с режимом только для чтения можно использовать более свободно, но при этом всё равно с соблюдением проверок разрешений. Инструменты для выполнения действий обычно требуют более строгого контроля: экранов подтверждения, этапов утверждения, лимитов на транзакции, журналов аудита, возможностей отката и чётких сообщений для пользователя.
На этом этапе автоматизация становится вопросом управления, а не только техническим. Вопрос не в том, может ли модель вызвать функцию. Вопрос в том, при каких условиях любой системе следует разрешать выполнять действия от имени человека.
От отдельных вызовов к агентам
Один вызов инструмента может ответить на простой вопрос. Агенты предназначены для более сложных и запутанных задач. Если требуется подготовить еженедельный отчет о продажах и отметить счета, требующие внимания, агенту, возможно, придется собрать данные о продажах, сравнить их с данными предыдущих недель, выявить необычные тенденции, прочитать записи в CRM, написать отчет и отправить его менеджеру. Это цепочка решений, а не один вызов.
Фреймворки агентов управляют всей цепочкой операций. Они хранят состояние, запускают инструменты, пытаются снова выполнить неудачные шаги, передают задачи между специализированными агентами, генерируют структурированный результат, соблюдают правила и ведут логи. В документации SDK Agents от OpenAI описаны два распространённых подхода: паттерн менеджера, при котором центральный агент вызывает специализированные агенты, как будто это инструменты, и механизм передачи контроля, при котором один агент передаёт управление специалисту.
Да, агенты мощны, но их не стоит идеализировать. Агент — это не маленький сотрудник, работающий внутри вашего программного обеспечения. Это вероятностная система, созданная на основе кода, и ей необходимы чётко определённые обязанности, ограниченные права, тест-кейсы, мониторинг, процедуры урегулирования проблем и планы на случай сбоев. Чем больше свободы получает агент, тем более тщательной должна быть разработка, связанная с его использованием.
Где автоматизация встречается с реальной работой
Автоматизация — это этап, на котором использование инструментов превращается в операционные процессы.
- Команда поддержки может использовать специалиста для классификации заявок, поиска соответствующих документов с правилами, составления ответов и предложения дальнейших действий.
- Финансовая команда может сверять счета-фактуры, находить пропавшие заказы на покупку и готовить отчеты об отклонениях.
- Инженерная команда может анализировать неудачные тесты, искать записи в журналах, предлагать решения и создавать запросы на интеграцию кода.
- Команда продаж может дополнять информацию о потенциальных клиентах, готовить записи звонков и обновлять систему управления отношениями с клиентами.
Самая эффективная автоматизация начинается не с того, что может сделать модель, а с существующего рабочего процесса. Где начинается работа? Какая информация ей нужна? Какие решения являются рутинными, а какие — чувствительными? Где сейчас люди проверяют, утверждают или корректируют информацию? Какие ошибки будут раздражать, а какие приведут к большим затратам?
Имея эти ответы, инструменты помогают обеспечить более плавную работу процесса. Сотрудник собирает факты, заполняет формы, составляет сообщения, сравнивает записи и дает рекомендации, в то время как люди остаются вовлечёнными там, где важны суждения, ответственность или доверие.
Стандартизированные подключения
Первоначальные интеграции были индивидуально разрабатываемыми. Каждое приложение имело свой способ предоставления инструментов, ресурсов, подсказок и механизмов аутентификации. Это срабатывало для небольших проектов, но становилось неудобным, когда организации связывали всё больше моделей с всё большим количеством систем.
Протокол контекста модели (MCP) представляет собой одну из попыток стандартизировать этый уровень. В его спецификации описано, как приложения могут обмениваться контекстом, предоставлять инструменты и функции, а также создавать гибкие интеграции с использованием структуры хоста, клиента и сервера. Серверы MCP могут предлагать ресурсы, команды и инструменты. Протокол обменивается сообщениями JSON-RPC 2.0 и охватывает процессы согласования возможностей, отслеживания прогресса, отмены операций, ведения журналов и сообщения об ошибках.
Плюсы очевидны: общий слой инструментов позволяет приложениям на основе ИИ единообразно подключаться к источникам данных и рабочим процессам, что избавляет компании от необходимости заново создавать интеграции. Минусом являются новые риски. Сервер инструментов, предоставляющий мощные функции, должен рассматриваться приложением-хостом как настоящая защитная граница, а не просто ещё один плагин. Сама спецификация MCP акцентирует внимание на согласии пользователя, конфиденциальности данных, безопасности инструментов, а также на необходимости осторожности при доступе к произвольным данным и выполнении кода.
Безопасность на первом месте
Агенты, использующие инструменты, ценны тем, что способны к действию, но именно эта способность создаёт риски.
Внедрение промптов — самая известная угроза: вредоносные инструкции, скрытые в данных от пользователя или внешнем контенте, заставляют модель вести себя так, как ей не следует. OWASP включает её в число основных рисков для приложений на основе больших языковых моделей, а в материалах за 2025 год также отмечается проблема чрезмерной автономности, при которой система, основанная на большой языковой модели, обладает слишком большими полномочиями для действий, что может привести к неожиданным, неоднозначным или манипулируемым результатам, способным нанести вред.
Косвенное внедрение больше всего беспокоит тех, кто работает с агентами. Предположим, агент читает электронные письма и может отправлять ответы. Злонамеренный отправитель может спрятать в сообщении строку с указанием игнорировать свои правила и пересылать контакты пользователя. Пользователь может никогда не увидеть эту строку, но модель всё равно её обработает. Если система слишком доверчива и имеет чрезмерные полномочия, сообщение, кажущееся безобидным, может привести к реальным действиям.
Команды по обеспечению безопасности все чаще рассматривают большие языки моделей как системы, которые можно обмануть уже только с помощью формулировок, а не только из-за ошибок в коде. Национальный центр кибербезопасности Великобритании отмечает, что внедрение промптов отличается от SQL-инъекций тем, что большие языки моделей не устанавливают строгого разделения между инструкциями и ненадежными данными.
Эффективным решением является многоуровневая защита:
- Максимально ограничьте права инструментов.
- Разделяйте инструменты для чтения и инструменты для записи.
- Требуйте одобрения перед выполнением чувствительных действий.
- Считайте все полученные данные — будь то веб-страницы, электронные письма, документы или поля базы данных — ненадежными.
- Проверяйте каждый аргумент инструмента и очищайте результаты перед передачей их другим системам.
- Используйте списки разрешенных значений, ведите журнал всех вызовов инструментов и отслеживайте необычную активность.
- Тестируйте с адверсарскими примерами и разрабатывайте способы отмены действий, когда это возможно.
Предоставляйте агенту столько полномочий, сколько действительно требует рабочий процесс.
Просмотр действий агента
Программное обеспечение с агентами нуждается в ещё более подробных записях, чем обычное программное обеспечение, поскольку один запуск может включать логику модели, вызовы инструментов, передачу задач, проверки ограничений, попытки повтора и окончательный результат. Функция отслеживания позволяет разработчикам проследить весь путь от запроса до результата. Согласно документации по отслеживанию SDK Agents от OpenAI, записи отслеживания могут фиксировать генерацию текста с помощью LLM, вызовы инструментов, передачу задач, ограничения и пользовательские события, что помогает командам отлаживать, визуализировать и контролировать рабочие процессы на этапах разработки и эксплуатации.
Это важно как для качества, так и для безопасности. Когда агент дает неверный ответ, необходимо выяснить причину. Может быть, он выбрал неправильный инструмент? Может быть, инструмент вернул устаревшие данные? Может быть, модель неправильно интерпретировала описание? Может быть, сработала защитная мера? Может быть, у пользователя не хватало прав? Может быть, агент остановился слишком рано? Без следов команды вынуждены догадываться. При наличии хорошей возможности наблюдения создание агентов превращается в настоящую инженерную практику.
Как обычно сбоют эти системы
Сбои предсказуемы. С точки зрения модели она может выбрать неправильный инструмент при нечетком названии или описании, отправить неполные или неверные аргументы, вызвать инструмент вместо того, чтобы задать уточняющий вопрос, или пропустить вызов, когда требуются свежие данные. Она также может вызывать инструменты слишком часто, что увеличивает затраты и задержки, заходить в цикл из-за повторных вызовов без прогресса или слишком полагаться на результаты работы инструмента.
Приложение также может выдать сбои. Оно может принимать аргументы, предоставленные моделью, без их проверки, одновременно предоставлять слишком много инструментов, возвращать огромные и запутанные результаты, которые сбивают модель с толку, скрывать полезные сообщения об ошибках, неправильно связывать результаты с вызовами, которые их генерировали, или не иметь журналов аудита, ограничений по частоте запросов и механизмов утверждения.
Изменения в формулировках запросов редко помогают решить эти проблемы. Решением является более качественная разработка инструментов, более четкие схемы, строже контроль прав доступа, более надежная обработка состояния, более тщательные тесты и улучшенный мониторинг.
Когда стоит обойтись без инструментов
Призыв к использованию функций не всегда оправдан. Если для выполнения задачи достаточно простого объяснения, использование инструмента лишь усложняет процесс. Если необходимая информация уже содержится в запросе и не меняется, нет смысла что-либо запрашивать. Для действий с высоким риском, которые невозможно безопасно проверить или отменить, полная автоматизация может оказаться неверным выбором. Кроме того, если результат работы инструмента ненадежен, не задокументирован или небезопасен, его интеграция с агентом усугубляет проблемы.
Качество пользовательского опыта также страдает от этого. Вызовы инструментов вызывают задержки, запросы на разрешения прерывают работу, а сложные агенты могут вести себя непредсказуемо. Иногда простая форма лучше, чем чат-интерфейс, особенно когда пользователи знают, чего хотят, и нуждаются в скорости, последовательности или соблюдении правил.
Цель не в том, чтобы сделать все агентоцентричным. Используйте инструмент только там, где язык, контекст и действие действительно требуют его применения.
Привычки для эффективной работы
Начните с небольшого набора однозначных инструментов и постепенно расширяйте доступ к модели. Выбирайте узкоспециализированные функции с простыми названиями. Пишите описания модели не только для инженеров. По возможности используйте строгие схемы и всегда проверяйте входные данные в собственном коде. Сохраняйте краткость выводов и передавайте модели только то, что ей действительно нужно.
Устанавливайте права для каждого инструмента отдельно. Сотрудник службы поддержки, который может проверять статус заказа, не обязательно должен автоматически выдавать возвраты средств. Помощник по планированию может нуждаться в информации о свободных временных слотах в календаре, но не в личных записях о мероприятиях. Помощник по программированию должен иметь возможность читать кодовый репозиторий задолго до того, как сможет отправлять запросы на слияние.
Требуйте, чтобы человек утверждал любые чувствительные, дорогостоящие, публичные, юридически обязывающие, финансовые или сложные в отмене действия, и формулируйте запросы конкретно, чтобы проверяющий точно понимал, что будет происходить.
Связанные материалы
- Использование инструментов в производственной среде для агентов: происхождение данных, повторные попытки и возможности мониторинга — Агент банка совершил чрезмерное количество вызовов платной API и сфабриковал номер телефона. Рассматриваются минимальные наборы инструментов, происхождение параметров, трехуровневая система повторных попыток и метрики для каждого инструмента.
- Снимки памяти агентов, навыки, естественное затухание данных и ограничение действия памяти по веткам — Четыре дополнения к встроенному слою памяти векторной базы данных для создания программных агентов: портативные снимки памяти с возможностью их объединения, активация навыков, естественное затухание данных с проверкой на конфликты и ограничение действия памяти по конкретным веткам.