Что на самом деле демонстрирует этот случай
В новостном репортаже из Филадельфии описывается автоматизированная система — или оператор, полагающийся на неё, — которая переслала наводку, оказавшуюся ложной, и последствия обрушились на реального человека и реальное учреждение прежде, чем кто-либо успел проверить утверждение. Детали атрибуции важны меньше, чем форма провала. Агент сделал то, о чём его просили. Вред возник из действия, предпосылки которого никогда не были заданы: какие доказательства требовались до того, как наводка покинула стены организации, сколько независимых источников её подтвердили, мог ли получатель что-либо отменить после того, как она к нему поступила.
Это тот же класс провалов, который мы видим в оценках tool calling каждую неделю. Каждый вызов валиден по схеме. JSON парсится, аргументы соответствуют объявленным типам, транспорт возвращает 200. Результат всё равно неверен, потому что валидность — это не соответствие политике. Tool call может быть корректным по форме и недопустимым по контексту: сообщение, отправленное не тому получателю, запись, обновлённая на основании единственного непроверенного поля, уведомление, отправленное третьей стороне, которая уже не сможет его не увидеть.
Трактовка этого как проблемы галлюцинаций подталкивает к исправлению модели, которое не может сработать. Если модель выдумала деталь, можно обоснованно попросить лучшего заземления. Но в филадельфийской схеме модель, возможно, сообщила ровно то, что ей дали. Разрыв был выше по потоку от генерации: ничто в системе не говорило, что для этого действия требуются два независимых источника, прежде чем оно будет разрешено. Никакой объём промптинга не закрывает разрыв, который никогда не был записан как требование.
Значимые инструменты нуждаются в предпосылках
Полезное различие — не между хорошими и плохими моделями. Оно между инструментами, которые остаются внутри организации, и инструментами, которые достигают третьей стороны. Вызов retrieval по внутреннему индексу дёшево ошибить. Вызов, который отправляет письмо регулятору, подаёт отчёт, публикует утверждение об указанном лице или направляет выездную группу, — нет.
Для любого инструмента из второй категории обёртка должна объявлять как минимум три вещи.
- Требуемые доказательства. Какие поля должны присутствовать и быть не-null, прежде чем вызов будет разрешён, и какое происхождение должно быть у каждого из них. Наводка с единственным неструктурированным источником — это не тот же объект, что наводка с источником, временной меткой и подтверждающей записью.
- Число подтверждений. Сколько независимых источников должны совпасть. Независимость — сложная часть; два поля, скопированные из одного и того же вышестоящего фида, — это один источник в двух шляпах, и схема должна кодировать граф происхождения, чтобы число вычислялось, а не утверждалось.
- Класс обратимости. Можно ли отменить действие и кем. Отправка внутреннего черновика обратима. Отправка наводки внешнему партнёру — нет, потому что получатель уже её прочитал.
Необратимые действия, затрагивающие третьи стороны, требуют отдельного пути одобрения с указанным человеком-принципалом. Не общая очередь, не общий почтовый ящик: конкретная подотчётная роль, которую журнал аудита фиксирует в момент одобрения. Одобрение — такая же предпосылка, как и любая другая, оцениваемая тем же механизмом.
Проверка предпосылок принадлежит обёртке инструмента, а не промпту. Обёртка находится между предложенным моделью вызовом и побочным эффектом. Она получает аргументы, обращается к объявленным предпосылкам, оценивает их относительно текущего состояния и либо разрешает вызов, либо возвращает структурированный отказ. Поскольку она живёт в коде, она переживает обновления модели, переписывания промптов и появление нового фреймворка для агентов. Поскольку она возвращает отказ, а не молча переписывает запрос, модели можно сообщить почему и дать ей выбрать другой путь, а сам отказ становится записью.
Почему промпты не могут это нести
Инструкции конкурируют за контекст. Системный промпт, который несёт операционную политику наряду с постановкой задачи, описаниями инструментов, правилами форматирования и текущей беседой, — это системный промпт, где политика является одним голосом среди многих. На длинных горизонтах этот голос не становится громче; он становится дальше. К двадцатому ходу предостережение, написанное в начале контекста, — это факт, которому модель может придать вес, а может и нет, и снаружи невозможно определить, что именно произошло.
Предпосылка, проверяемая в коде, порождает отказ с причиной. Этот отказ — дискретное событие с временной меткой, входными данными, идентификатором правила и результатом. Его можно подсчитывать, семплировать и воспроизводить. Предостережение на уровне промпта не порождает ничего, что можно было бы исследовать после факта. Если наводка ушла и вы хотите знать, рассматривала ли система подтверждение, ответ с промптом — мы попросили её. Ответ с обёрткой — строка в логе.
Здесь есть честный компромисс, и он немал. Предпосылки в коде добавляют задержку и трение. Каждый значимый вызов теперь ждёт оценки, и некоторая доля из них будет отклонена и потребует взгляда человека. В первые недели эта доля некомфортна, потому что схема строже неформального процесса, который она заменила. Команды ощущают это как то, что система встаёт на пути, и давление ослабить правило немедленно. Противовес в том, что ослабленная предпосылка невидима до момента отказа, тогда как строгая видна сразу. Издержки платятся авансом и в месте, где их видно.
Второй компромисс: предпосылки хороши ровно настолько, насколько хорошо состояние, которое они читают. Если число подтверждений зависит от поля происхождения, которое вышестоящие системы заполняют непоследовательно, проверка пропустит то, что не должна. Вот почему оценку нужно логировать рядом с вызовом, вместе с входными данными, которые она фактически видела. Когда предпосылка оказывается неверной, лог говорит вам, было ли плохим правило или данные, которые его питали.
Правило проектирования: классифицируй, затем прикрепляй
Практическое правило — классифицировать инструменты по радиусу поражения и обратимости, а затем прикреплять предпосылки к классу, а не к отдельным промптам. Класс инструмента — это свойство инструмента, объявленное один раз и пересматриваемое при изменении инструмента. Каждый агент, который может достичь этого инструмента, автоматически наследует класс и его предпосылки. Новых агентов не нужно учить осторожности; им нужно дать инструменты, которые уже её несут.
Минимальное объявление выглядит так:
tool: submit_external_tip
blast_radius: third_party
reversibility: irreversible
preconditions:
- rule: evidence.required_fields
fields: [claim_text, source_id, source_timestamp]
- rule: corroboration.min_independent
count: 2
provenance_field: source_lineage
- rule: approval.named_principal
role: duty_editor
on_fail: refuse_with_reason
Обёртка оценивает каждое правило по порядку и выдаёт один из трёх исходов: разрешить, отказать с причиной или эскалировать указанному принципалу. Запись оценки пишется рядом с вызовом в том же трейсе, так что решение можно восстановить месяцы спустя: какие правила выполнялись, какие значения они читали, какое отказало, кто одобрил, если кто-то одобрил.
Это неблагодарная работа. Она выглядит как проектирование схем и контроль доступа, а не как AI-инженерия, и отчасти поэтому её пропускают. Но филадельфийская схема не решается лучшей моделью или более осторожным промптом. Она решается тем, чтобы сделать предпосылку полноценным объектом, прикреплённым к инструменту, оцениваемым в коде и логируемым рядом с действием, которое она регулирует. Агенты продолжат делать то, о чём их просят. Вопрос в том, было ли то, о чём их просят ограничено тем, что организация действительно готова допустить.
Что инструментировать в первую очередь
Начните с инвентаризации, а не с изменения модели. Перечислите каждый инструмент, который может вызвать любой агент. Для каждого зафиксируйте, достигает ли он третьей стороны, можно ли его отменить и какие доказательства должны были бы существовать, чтобы организация могла защитить действие на разборе шесть месяцев спустя. Инструменты, для которых на последний вопрос нет ясного ответа, — это те, которым нужна предпосылка до следующего развёртывания, а не после следующего инцидента.
Затем подключите оценку к трейсу. Отказ, который не залогирован, неотличим от запроса, который никогда не делался, а одобрение, которое не атрибутировано, неотличимо от агента, действующего в одиночку. Два новостных репортажа, ссылки на которые приведены выше, описывают исходы; инженерный ответ — сделать предпосылки, которые предотвратили бы их, явными, принудительными и разборчивыми.