> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Агенты > Что должен делать каждый слой архитектуры, когда участник — не человек: runtime вне протокола, приём заявок под нагрузкой агентов, авторизация как транзакция и воспроизводимая среда. Направление, под которое всё это строится, — то, где **одного человека представляют несколько агентов**, и каждый действует в части того, чего этот человек хочет. Не человек с инструментом и не бот, крутящий фиксированный скрипт: несколько контрагентов рынка, отвечающих перед одним счётом. Когда меняются участники, вместе с ними меняется и микроструктура рынка. Размер заявок падает, частота сообщений растёт, отношение отмен к исполнениям расходится ещё сильнее, а поток приобретает корреляцию, которой у человеческого потока нет: агенты, читающие один и тот же сигнал, приходят к одному выводу в один и тот же момент. Ничего из этого не решается добавлением функции. Это решается проходом по архитектуре слой за слоем и вопросом, что каждый слой должен делать иначе. Эта страница — тот самый проход, по порядку, с указанием, где каждый слой находится на самом деле.

1 · Приложение

2 · Сеть

3 · Исполнение

4 · Состояние

Runtime находится вне протоколаи не имеет никаких привилегий — ни меньшей задержки, ни более ранних данных, ни интерфейса, до которого не дотянется третья сторона

Приём заявок, когда отправители — агентыопоздавшая отмена хуже опоздавшей заявки, а справедливость отслеживается по недавней истории, а не по каждому сообщению

Авторизация — это транзакцияс высотой блока, внутри замкнутого набора инструкций; а её отзыв снимает стоящие заявки агента в том же блоке

Воспроизводимая среда с версиями по блокамpoint-in-time по построению, а не по дисциплине

Те же четыре слоя, что и в обзоре архитектуры. Другой только вопрос: что должен делать каждый из них, когда участник — не человек?

| Слой | Что меняется | Статус | | -------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------- | | **Приложение** | Runtime — исследование и исполнение — находится вне протокола и не имеет привилегий | Взято в работу | | **Сеть** | Приём при всплесковом, коррелированном, насыщенном отменами потоке | Поставлено, два вопроса открыты | | **Исполнение** | Авторизация становится транзакцией с условиями | Поставлена как «всё или ничего»; условия взяты в работу | | **Состояние** | Сама сеть и есть среда, в которой оценивается агент | Поставлено |

1 · Приложение — runtime снаружи, и иначе нельзя

Runtime агента — это каркас исследования и исполнения: он формирует взгляд, превращает его в исполняемое и кладёт перед площадкой. Он работает на слое приложения, на одном уровне с фронтендами и API-клиентами, и **не является частью протокола**. Это размещение — физическое ограничение прежде, чем предпочтение в проектировании. Модель рассуждает секундами, рынок движется миллисекундами. Ничто, что обязано вызывать модель, не может стоять на пути, которым реально идёт заявка, — а значит, **в протоколе нет никакой модели вообще**. Не по недосмотру: модель на расчётном пути разрушила бы то единственное свойство, на котором здесь держится всё остальное. Путь исполнения обязан выдавать одни и те же байты на каждом узле, а вывод модели этого не делает. Поэтому runtime живёт снаружи, и честный вопрос превращается в такой: что протокол ему должен. Пять вещей, и все они взяты в работу, а не поставлены. | | Что это даёт агенту | | ---------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Предторговая симуляция** | Оценить, что заявка сделает с зафиксированным состоянием, до её подачи | | **Идемпотентная подача** | Повторить подачу с неясным исходом, не рискуя двойной экспозицией | | **Именованные конечные состояния** | Нет исходов с неизвестным результатом — любое действие заканчивается состоянием, у которого есть имя | | **Определённое возобновление** | Перезапустившийся агент знает, где остановился и что делать дальше | | **Атрибутированные квитанции** | Что агент сделал, по чьим полномочиям и во что это обошлось — как вывод протокола | Статусы см. в [Что дальше](/ru/protocol/roadmap/whats-next). Runtime не имеет привилегированного пути. Ни меньшей задержки, ни более ранних данных, ни интерфейса, до которого не дотянется сторонний runtime. Это стоит сказать, а не подразумевать, потому что в другом месте архитектура утверждает: между трейдером и клиринговой палатой не стоит ничего — а собственный инструмент с выделенной полосой был бы именно этим «чем-то».

2 · Сеть — приём, когда отправители агенты

Mempool решает, что стоит держать, какая транзакция отправителя следующая, какие пиры о ней узнают и что сбрасывается, когда спрос превышает ёмкость. Поток агентов нагружает все четыре, и два свойства, которые его поглощают, уже на месте по причинам, возникшим раньше агентов. **Опоздавшая отмена хуже опоздавшей заявки.** [Mempool](/ru/protocol/architecture/mempool) по построению считает трафик заявок и трафик отмен асимметричными. Агенты делают эту асимметрию острее, потому что их отношение отмен к исполнениям выше человеческого, — но сама форма проблемы та, вокруг которой этот слой и строился. **Справедливость отслеживается по недавней истории, а не по каждому сообщению.** Mempool ведёт скользящую запись о том, какие отправители и какие виды трафика недавно съели ёмкость, и исходя из неё формирует, что отдавать дальше. **Именно это и важно при коррелированных всплесках**: сорок агентов, отменяющих по одному сигналу, — это не сорок средних нагрузок, размазанных ровно, это один пик. Ограничение на каждое сообщение его не видит. Память о том, кто недавно шумел, — видит. **Консенсус не растёт вместе с пропускной способностью.** Транзакции доходят до валидаторов пакетами, доступность которых доказана до того, как предложение сможет на них сослаться, поэтому предложение блока несёт дайджесты, а не тела. Популяция агентов, поднявшая частоту сообщений на порядок, ничуть не поднимает размер сообщений консенсуса. Блок убирает гонку **внутри** себя: у двух транзакций одного блока есть приоритет, который каждый узел вычисляет одинаково. **Эта гарантия начинается на границе блока.** Попасть в блок — по-прежнему гонка, которую справедливость на уровне отправителя формирует, но не отменяет. Приём в mempool — не включение в блок. Два вопроса на этом слое открыты, и оба становятся практическими на объёмах агентов, а не людей. **Сколько должна стоить отмена.** Исполнение уже ставит отмены первыми — они идут в фазе перед всем, что может забрать ликвидность. Сетевая версия того же вопроса не закрыта: дешёвая и приоритетная отмена — это то, что делает котирование защитимым, и она же самый дешёвый способ залить mempool. Должны ли отмены иметь собственный учёт ёмкости, отдельный от выставлений, — не решено. **Какому слою принадлежит идемпотентность.** Агент, не получивший ответа, отправляет снова. Идемпотентная подача взята в работу на слое исполнения и закрывает главное следствие — отсутствие двойной экспозиции. Сетевую версию она не закрывает: должен ли mempool распознавать повтор как то же самое намерение, или нести оба и позволить исполнению дедуплицировать. Под штормом повторов эти два варианта ведут себя по-разному. Одного в списке сознательно нет: отдельной полосы приёма для агентов. Приоритетный доступ — это то, что рано или поздно продаёт любая централизованная площадка, и он противоречил бы утверждению, что между трейдером и клиринговой палатой не стоит ничего. Поток агентов идёт в ту же дверь.

3 · Исполнение — авторизация это транзакция

Это слой, на котором меняется модель счёта, и всё изменение вытекает из одного факта. **Передать счёт агенту — это транзакция ончейн.** Не отправленная форма, не API-ключ, выданный со страницы настроек, не строка в базе оператора. Транзакция — в блоке, на высоте, подписанная счётом, который её выдал, — и потому нечто, что любая третья сторона может найти, прочитать и проверить, ни у кого не спрашивая. Отсюда три следствия, и каждое — то, чего API-ключ не может. **Она внутри замкнутого набора инструкций.** Авторизация агента — одна из перечисленных операций [ядра](/ru/protocol/architecture/kernel). Универсальная сеть не может её выразить: смысл вызова был бы непрозрачным байткодом. Централизованная площадка обеспечивает её в коде, который вы не можете осмотреть. Здесь полномочие и его границы **и есть** инструкция, и потому граница проверяема, а не обещана. **Она несёт то, что агенту можно, — и не может нести то, что нельзя.** Авторизация может сказать, сколько агент вправе держать, сколько может потерять, каких рынков касаться и вправе ли менять режим маржи. **Она не может сказать «вывести».** Это не настройка, оставленная выключенной: такого пункта попросту нет, чтобы его написать. У агента, ведущего счёт, нет выразимого пути вывести из него средства. **Её отзыв снимает стоящие заявки агента.** Отзыв — тоже транзакция, и он попадает в блок, чьё [упорядочивание](/ru/trading/tx-sequencing) и так прогоняет отмены раньше всего, что способно забрать ликвидность. Поэтому заявки, оставленные агентом в стакане, уходят в том же блоке, что и полномочие. На площадке, где отзыв — это запись в базе, ключ перестаёт работать, а стоящие заявки оказываются в неопределённом состоянии. Здесь остановка доказуема, и любой может найти высоту, на которой она произошла.

ВыдачаТранзакция в блоке NНесёт границы: что агент может держать, сколько может потерять, чем может торговать. Вывод средств она нести не может — такого пункта попросту нет

ДействиеКаждое действие называет свои полномочияОтносится к счёту, который их выдал, а не только к агенту, который подал заявку

ОтзывТранзакция в блоке MСтоящие заявки агента снимаются в том же блоке, до того как отработает что-либо способное забрать ликвидность

Ни одно из трёх не является записью в базе, о которой вам должны сообщить. Каждое — транзакция, которую любой найдёт по высоте.

Сегодня выдача устроена по принципу «всё или ничего» и со сроком. Более богатые условия выше — сколько агент вправе держать, сколько терять, что делать дальше — взяты в работу, но не поставлены; см. [Что дальше](/ru/protocol/roadmap/whats-next). **Уже действует та часть, которую нельзя добавить задним числом**: полномочие — объект протокола, а не запись оператора о нём.

Что площадка уже несёт вместо runtime

Торговый runtime, которому приходится защищать пользователя на обычной площадке, в итоге строит себе собственное привилегированное ядро: реестр позиций, который он ведёт и сверяет сам; предторговую проверку риска, которую он считает сам и надеется, что площадка считает так же; и журнал аудита, который он пишет и о котором не может доказать, что его не правили. **Все три — это резервирование против площадки, которая не покажет свои книги.** Здесь три из них — свойства протокола. [Клиринговая палата](/ru/protocol/architecture/clearinghouse) — единственная, кто пишет реестр. Стадия риска идёт до сопоставления, в том же блоке. Журнал аудита — это сама сеть, и каждое изменение состояния несёт породившую его транзакцию. Runtime остаётся четвёртое — идемпотентный шлюз заявок, — и это задача интерфейса, а не доверия.

Сопоставление: блок уже и есть пакет

Поток агентов поднимает частоту и снижает размер того, что доходит до стакана, — а это ровно та микроструктура, которой чаще всего обосновывают пакетный аукцион: дискретные интервалы, расчёт вместе, никакого преимущества за приход на микросекунду раньше. Это свойство здесь **уже выполняется**, и не потому, что добавили пакетный аукцион. Время внутри блока — это зафиксированная консенсусом позиция, а не локальные часы, поэтому **внутри блока не существует субмиллисекундного преимущества**; а отмены идут раньше любых агрессивных заявок, так что устаревшую котировку можно снять, и её не подберёт заявка, пришедшая вместе с отменой. Блок и есть дискретный интервал, рассчитываемый вместе. Он появился как **следствие** исполнения зафиксированного порядка, а не как надстройка из рыночного дизайна. Оправдано ли что-то сверх этого — а непрерывный приоритет «цена-время» и частые пакетные аукционы являются **альтернативами, а не дополнениями**, поскольку пакет намеренно убирает временной приоритет внутри себя — сейчас исследуется, а не строится.

4 · Состояние — сеть и есть среда

Агент хорош ровно настолько, насколько хорошо то, против чего его оценивали, и именно в оценке происходит большая часть провалов. Стратегия, которая выглядела прибыльной в симуляторе и падает в проде, обычно встретила не новый рынок, а симулятор, который не был площадкой. [Слой состояния](/ru/protocol/architecture/state/model) убирает этот зазор по построению, а не по дисциплине. Состояние версионируется по блокам, и каждое изменение отнесено к породившей его транзакции, поэтому повтор блока повторяет **саму среду**, а не её модель: ту же машину состояний, которая будет исполнять агента, на входах, зафиксированных сетью. Это пятая проверка на странице [Проверьте сами](/ru/developers/verify), и именно поэтому бэктест здесь — объект иной природы, чем бэктест против исторического API биржи. Более тонкое свойство — что всё это **point-in-time по построению**. Набор данных, собранный из API биржи, является point-in-time только если собиравший был аккуратен, а заглядывание вперёд просачивается через щели, которых никто не замечает: поле, дозаполненное задним числом, поправка, применённая к истории, пересмотренная референсная цена. Здесь такой вопрос не возникает: состояние блока — это то, что было истинным на этом блоке, потому что другой формы у состояния никогда и не было.

Что становится труднее

Строить для агентов — это не только список вещей, которые становятся лучше. **Детерминизм режет в обе стороны.** Агент может предсказать, что сделает его собственная заявка, ещё до подачи, потому что один и тот же вход даёт один и тот же результат на каждом узле. **Чужой агент может ровно так же — про вашу.** Воспроизводимость одновременно повышает вашу способность планировать и вашу предсказуемость, и второе не бесплатно. **Ликвидность агентов — это коррелированная ликвидность.** Люди-маркетмейкеры уходят в разные моменты, потому что замечают в разные моменты. Агенты, читающие одно и то же публичное состояние, приходят к одному выводу вместе. Стакан, который держат агенты, глубже в обычный день и может истончаться быстрее в тот день, который важен, — это риск рыночной структуры, под который поглотители протокола спроектированы, а не риск, который они устраняют. **Оракул читает площадки, на которых агенты тоже торгуют.** Удостоверение привязывает цену к блоку, который её потребил; оно не делает базовый рынок неманипулируемым, а популяция агентов, действующих по коррелированным сигналам, — ещё один способ базовому активу сдвинуться разом. См. [что оракул гарантирует и чего не гарантирует](/ru/protocol/architecture/oracle). **Самооценка агента не является доказательством.** Обратная связь в торговле шумная и нестационарная там, где в коде она таковой не является: компилятор говорит вам, что вы ошиблись, а прибыльная неделя не говорит, что вы были правы. Всё, что площадка строит для агентов, обязано трактовать отчёт агента о собственных результатах как **враждебный вход**, а не как измерение. Это одна из причин, по которым проверки на странице [Проверьте сами](/ru/developers/verify) выстроены вокруг того, что можно пересчитать, а не того, о чём можно отчитаться.

Что дальше

Четыре фазы и почему меняться должен именно счёт. Проверки, которые делают оценку агента чем-то большим, чем заявление. Что остаётся принимать на веру, когда проверено проверяемое. Статус runtime агента и условий авторизации.