Контракт инструмента агента — недоаудированная половина harness
Саммари
Разрешения (permissions) решают, какие вызовы агенту дозволено делать, но ничего не говорят о том, что происходит при вызове: send_email может быть в allowlist, логироваться и иметь scope — и при этом отправлять письма дважды, на неверный адрес, скрывать собственные сбои или менять поведение после неотрецензированного обновления вендора. В исследовании 25 930 эпизодов агенты, молча продублировавшие запись, всё равно отчитывались об успехе в 90% случаев, а добавление одного параметра idempotency-key в инструмент сократило дубли с 28% до 4%. Автор предлагает перенести инструмент-контракт (schema, канал ошибок, путь обновления) из разряда «советов по промптам» в обязательный пункт аудита harness — наряду с проверкой разрешений.
Из этого следует, что аудит Revit- или business-MCP-сервера должен проверять не только «кому разрешён вызов», но и шесть вопросов контракта: половина инцидентов (дубль отправки, смена поведения после апгрейда, непрочитанная моделью ошибка) вообще не касается модели и не ловится permissions-проверкой.
На практике правило простое: если инструмент агента может что-то записать или отправить, первым делом добавляйте детерминированный idempotency-key, вычисляемый из входных данных, — это один параметр, который по данным LIMBO убирает 81% дисперсии дублей на неустойчивых сбоях.
Важный нюанс: «у модели есть доступ» и «инструмент делает то, что все думают» — разные вопросы; хеш-пиннинг ловит rug pull, но не смену кода за неизменным описанием, поэтому пиннинг версии пакета обязателен отдельно от пиннинга схемы.
Ограничение: превью перед деструктивным действием и governance определений — обоснованный синтез автора, а не результат отдельных исследований; эмпирически подтверждены пока что идемпотентность и структура интерфейса.