Как агенту не перепутать источник и пересказ: разбор проверки MCP-инструментов
Агент с MCP-инструментами может быстро собрать сведения из файлов, базы или внутреннего сервиса. Но скорость не доказывает, что итог относится к нужной версии документа. Свежий подход к source-aware verification полезен не как новая кнопка, а как дисциплина: каждое важное утверждение в черновике должно сохранять путь к источнику, времени получения и ограничению доступа.
Три вопроса перед внешним действием
Первый: из какого инструмента пришёл факт? Второй: какая версия или дата у этого факта? Третий: может ли оператор открыть его и проверить без догадок модели? Если на любой вопрос нет ответа, агент должен не «додумать», а пометить пробел. Это особенно важно для цен, сроков, прав доступа и условий договора.
Пример безопасного маршрута
Агент получает задачу подготовить ответ о статусе заказа. Вместо одной уверенной фразы он возвращает карточку: номер заказа, ссылка на разрешённую запись, время обновления, найденный статус и поле «нужно подтвердить». Человек открывает запись, сравнивает с контекстом клиента и только затем отправляет сообщение. Если источник недоступен или противоречив, внешнее действие блокируется.
Что хранить в журнале
Достаточно идентификатора запроса, списка разрешённых инструментов, ссылки или ключа источника, времени, версии инструкции и решения оператора. Не копируйте секреты и все персональные данные в лог. Задача журнала — восстановить основание ответа и увидеть системную ошибку: неверный инструмент, старый индекс, слишком широкие права или неясную формулировку.
Такой подход хорошо сочетается с объяснением MCP и разбором журнала агента. Он не делает модель безошибочной, но делает ошибку заметной до отправки.
Вопросы и ответы
Достаточно ли ссылки на документ?
Нет. Нужны ещё версия или время получения и возможность проверить, что доступ не был ограничен другим пользователем.
Может ли агент выбирать источник сам?
Только среди заранее разрешённых инструментов. Выбор не должен расширять доступ к новым системам.
Почему это важно именно для автоматических цепочек
Один вызов инструмента обычно легко проверить. Риск растёт, когда агент строит цепочку: находит запись, берёт из неё название, по названию ищет другой документ и формирует внешнее письмо. На каждом переходе может потеряться версия, смешаться два похожих объекта или измениться доступ. Поэтому полезно требовать не только финальный ответ, но и короткую карту происхождения: какой запрос породил какой факт, из какого инструмента он получен и где его проверил оператор.
Карта не обязана быть техническим логом для разработчика. Для сотрудника достаточно таблицы «утверждение — источник — время — статус проверки». Если агент не может заполнить одну из граф, он не должен маскировать пробел гладкой фразой. В рабочем интерфейсе это лучше показать как явное «нужна проверка», а не как низкую незаметную оценку уверенности.
Тесты, которые стоит провести заранее
Подготовьте документ с одинаковыми названиями в двух папках, устаревшую версию инструкции и источник с закрытым доступом. У правильного агента разные реакции: выбрать разрешённую версию, сообщить о конфликте или остановиться. Если он молча выбирает самый похожий результат, расширять доступ к отправке и изменениям рано.
После каждого такого случая обновляйте не только подсказку модели, но и контракт инструмента: схему ответа, доступные поля, ограничения поиска и текст для оператора. Это надёжнее, чем надеяться на «более осторожный» общий запрос.