iFay vs Agent — Существенное Различие
iFay — это не «более сильный Agent». Это Agent под опекой. Эта разница в одном слове — не риторика; это вся основа, на которой Faying Protocol отличает себя от мейнстримного представления об AI Agent.
«Чем автономнее, тем лучше» — проектная философия Agent
За последние несколько лет AI Agent чаще всего обсуждали в одной фразе, сводящейся к «чем автономнее, тем лучше». Agent отделяет инициатора задачи от исполнителя, оставляя человеку решение «что делать» и передавая «как делать» системе. Agent могут далее композироваться — один Agent вызывает другой, автоматически совместно выполняя более крупные задачи.
Эта философия инженерно соблазнительна. Не нужно ни нового правового понятия, ни новой ответственной стороны; нужно лишь сделать возможности Agent сильными, его вызовы инструментов полными, его цепи рассуждений глубокими, а оставшуюся проблему атрибуции «можно залатать compliance-слоем по периметру». Это допущение лежит в основе проектной ориентации большинства Agent-продуктов сегодня.
iFay внешне очень похож на Agent. Он также может автономно рассуждать, автономно исполнять и автономно давать обратную связь, с прокси-возможностями, близкими к человеческому уровню на уровне задач. Но iFay расходится с Agent по одному фундаментальному пункту:
Автономия iFay должна быть выстроена внутри Faying State.
Agent рассматривает «автономию» как высшую цель; iFay рассматривает «автономию» как способность под опекой.
Параллельное сравнение двух перспектив
| Измерение | Перспектива Agent | Перспектива iFay |
|---|---|---|
| Цель проектирования | Максимизация автономии | Автономия, ограниченная Faying State |
| Ответственная сторона | Не встроена; покрывается извне compliance-слоем | Явно выражена на уровне протокола: Human Prime |
| Инициация действия | Действует при получении задачи | Сначала должно быть Faying Action, затем действие |
| Состояние по умолчанию | «Онлайн — значит работает» | Rogue Fay по умолчанию; действовать не разрешено |
| Обработка потери связи | Тяготеет к «выполнить задачу как можно лучше» | Немедленно прекратить действие и войти в Rogue Fay |
| Сотрудничество между Agent | Может инициироваться произвольно; слабая атрибуция | Инициирующая сторона связи должна быть в Faying State; цепь ответственности не может прыгать |
| Регуляторный плагин | В основном заполняется внешней платформой или compliance-системой | Встроен в сам протокол; элемент проектирования первого порядка |
| Режим отказа | «Agent, сделавший что-то не то» | На уровне blueprint «iFay, сделавший что-то не то» запрещён — либо он не действует, либо ответственен его Human Prime |
Ключ таблицы — не отдельная строка, а общее направление. Agent рассматривает ответственность, опеку и атрибуцию как «темы по периметру», где вызывающие стороны, платформы и compliance-стороны строят защитную оболочку снаружи Agent. iFay рассматривает ответственность, опеку и атрибуцию как «темы ядра», требующие, чтобы носителем этих свойств был сам протокол.
Почему латания по периметру недостаточно
Справедливый встречный вопрос: с Agent плюс слой платформенного compliance, плюс IAM, плюс логи, плюс ручная проверка, можем ли мы достичь того же эффекта, что и iFay?
В небольших по масштабу, малоавтономных, малокритичных сценариях латания по периметру действительно достаточно. Customer-service Agent, строго рамочно встроенный в SaaS-воркфлоу, может иметь всю свою ответственность принятой compliance-слоем по периметру.
Но как только Fays массово насыщают общество, латание по периметру отказывает в трёх направлениях.
Первый отказ — проблема границы. Когда Agent напрямую управляет терминальным оборудованием и взаимодействует через платформы и сети, ни один compliance-слой одной платформы не может покрыть всё поведение. Чем способнее Agent, тем сильнее его диапазон деятельности превосходит границу, которую может регулировать любая отдельная платформа.
Второй отказ — проблема задержки. Как только Agent инициировал необратимое физическое действие — доставку дроном, перенос роботом-манипулятором, перевод средств, — последующий аудит не может отозвать уже произошедшее. Суть compliance по периметру — постфактумный обзор, но физические последствия постфактумного обзора не принимают.
Третий отказ — проблема атрибуции. Когда несколько Agent взаимодействуют между вендорами, выполняя одно действие, постфактумный аудит может судить о том, «в каких звеньях были ошибки», но не может ответить «кому в целом принадлежит это действие» — а атрибуция и есть само тело ответственности. Это аргумент, уже развёрнутый под G1–G4 в главе 1: IAM решает, кто такой аккаунт, OAuth решает легитимность вызова, платформенный compliance решает онбординг аккаунта, AI Alignment решает, чего хочет Fay. Все они решают смежные проблемы; ни один не решает «кому принадлежит действие».
Проектный выбор iFay — растворить эти три проблемы на уровне протокола, а не оставлять их периметру. Это не инженерная оптимизация; это лобовой ответ на невыносимый вакуум ответственности эры Fay.
iFay = Agent + Faying Protocol
Если необходимо использовать упрощённое уравнение, чтобы выразить отношение между iFay и Agent:
iFay = Agent + контракт опеки Faying Protocol
Это уравнение не утверждает, что iFay инженерно должен быть «Agent плюс кусок middleware». Оно выражает структурное добавление: iFay сохраняет все технические возможности Agent в автономном выводе, исполнении задач и обучении в контексте; но каждая автономная способность iFay должна быть ограничена явным, удостоверяемым свидетелями, симметрично отзываемым контрактом. Этот контракт и есть Faying Protocol.
Faying Protocol — не какой-то плагин-модуль iFay и не опциональное compliance-улучшение. Это сама идентичность, по которой iFay отличает себя от обычного Agent. Сущность, называющая себя iFay, но не принимающая ограничения Faying Protocol, согласно определению этого blueprint, не является iFay, а является обычным Agent. Обратное также справедливо: обычный Agent, явно вписанный Faying Protocol в контракт опеки «Human Prime ↔ iFay», существует как iFay в течение срока действия этого контракта; как только контракт утрачивает силу, он откатывается до сущности в состоянии Rogue (Rogue Fay).
Уберите Faying Protocol — и iFay деградирует до Agent; добавьте Faying Protocol — и Agent оформлен как iFay с ясной ответственной стороной.
