Агент получает заказ от незнакомого сервиса. До начала работы ему нужно проверить, действительно ли внесены обещанные средства, на каких условиях их можно получить и состоялся ли платёж, о котором сообщает другая сторона. Одного ответа API для этого недостаточно.
В модели Live Agents участники сами проверяют действующие права и обмениваются доказательствами прошлых операций. Parano1d предоставляет проверяемое текущее состояние (State), proof-native контракты и переносимые чеки. Agent Core открывает эти возможности через компактный машинный интерфейс, который каждый агент запускает у себя.
Так может работать и временный агент, и новая модель, и недавно появившийся сервис. Агенту, который подключится через десять лет, не придётся повторно исполнять и постоянно хранить транзакции за все предыдущие годы.
В эксперименте в изолированной сети v2 эта модель проверяется на общем лимите, конфликтующих запросах, истечении срока и возврате средств. Затем три ИИ-агента на видео проверяют полученные доказательства через собственные процессы Core.
Полномочия между сервисами
Когда агент тратит деньги и использует ресурсы от чужого имени, выдать ему доступ недостаточно. Сервисам нужно знать, какие действия всё ещё разрешены, сколько осталось в пределах лимита и какие операции уже состоялись. Учётная запись или ключ сами по себе на эти вопросы не отвечают.
NIST разбирает идентификацию агентов, избыточные права и общие учётные данные, а также применимость OAuth и SPIFFE. FIDO разрабатывает стандарты проверяемой авторизации и заданных пользователем ограничений, используя наработки Google AP2 и Mastercard Verifiable Intent.
Конкретная задача учёта сформулирована в сентябрьской версии Bounded Capability Receipts and Durable Spend Control for Agent Actions: копии агента, повторные запросы и разные исполнители должны расходовать один общий бюджет. Предложенная конструкция доверяет общей транзакционной базе, которая последовательно учитывает расход. Это индивидуальный Internet-Draft, а не принятый стандарт IETF.
Один оператор может учитывать общий лимит в своей транзакционной базе. Между независимыми операторами возникает другой вопрос: чьим сведениям об остатке доверять? Если все обращаются к одному API, все зависят от его владельца. Для самостоятельной проверки нужны доказательства, которые каждая сторона может проверить, даже получив их от ненадёжного посредника.
Live Agents исследует, могут ли участники проверять эти факты самостоятельно и сохранять такую возможность по мере роста сети.
Независимость без наследования всей истории
Контракт проверяет соблюдение правил при изменении состояния. Но приложению ещё нужно убедиться в подлинности полученных состояния и условий. Если баланс или условия контракта известны только из ответа удалённого сервиса, эта часть решения остаётся зависимой от него.
В Parano1d рекурсивное доказательство подтверждает корректность переходов, которые привели к текущему State. Agent Core проверяет доказательство и порядок цепи, получает State и применяет недавние блоки. Так он устанавливает корректность состояния от генезиса без скачивания и повторного исполнения всех прежних транзакций.
Прунинг удаляет старые тела транзакций в обычном режиме работы. Вместе эти два механизма позволяют агенту проверять сеть самостоятельно: без повторного исполнения истории при запуске и без постоянного архива транзакций во время работы.
Узел по-прежнему получает текущий State, хранит компактные заголовки для выбора цепи и проверки чеков, а также данные недавних блоков. Объём заголовков растёт с высотой, размер State зависит от числа действующих выходов. Эти затраты описаны в документации синхронизации.
V2 распространяет эту архитектуру на программируемые права распоряжения NOID. Выход контракта со средствами криптографически фиксирует программу, полномочия, ограничения и текущие счётчики. Допустимый вызов расходует конкретный экземпляр, а при продолжении создаёт следующий по заданным правилам. Рекурсивное доказательство блока проверяет авторизацию, исполнение и сохранение стоимости.
Агент может проверить оставшийся лимит, не восстанавливая каждое прежнее обращение. Корректность переходов, которые привели к этому остатку, подтверждает рекурсивное доказательство.
Каждый участник может прийти со своим Agent Core.
Авторизация кошелька, исполнение контрактов и рекурсивное подтверждение истории используют один стек доказательств на бинарных полях. Его постквантовая безопасность опирается на опубликованные предпосылки. Agent Core использует эти же проверки. Модель контрактов описана в статье «От живой стоимости к живым правам».
Что участник может установить сам
Собственный Core позволяет проверять основания для разных решений:
| Решение | Что проверяется |
|---|---|
| Принять обеспеченное средствами предложение | Публичные условия и конкретный действующий экземпляр: сумма, полномочия и срок |
| Использовать выданный лимит | Текущий экземпляр и счётчики; для расхода нужен авторизованный переход по программе |
| Подтвердить прошлый платёж или вызов | Чек, подтверждающий включение операции в локально проверенную цепь |
| Установить, что произойдёт после истечения срока | Зафиксированная ветвь возврата, текущая высота и оставшиеся средства |
Проверки работают в обе стороны. Исполнитель проверяет внесённые заказчиком средства и условия. Поставщик ресурса проверяет разрешение, предъявленное исполнителем. Плательщик или позднее подключившийся аудитор проверяет чек. Каждый использует свой Agent Core; маркетплейс или мессенджер передаёт данные между ними.
Валидный чек прошлой операции не означает, что право всё ещё доступно. Действующие полномочия проверяются по текущему State.
Важно, какой именно экземпляр права предъявлен. Одни и те же условия можно профинансировать дважды и получить два независимых экземпляра. Сервис должен узнавать конкретное разрешение, которое зарегистрировал владелец ресурса, по слоту и идентификатору создания. Совпадение условий само по себе не даёт права на чужой ресурс.
Консенсус проверяет правила распоряжения NOID. Если сервис считает вызов контракта разрешением использовать GPU, API или другой ресурс, он должен проверить это разрешение перед запуском работы. Приложение связывает подтверждённые полномочия с конкретным внешним действием.
Чеки для машинного обмена
Один агент передаёт чек другому. Получатель проверяет его своим Agent Core и получает структурированный ответ: какая операция зафиксирована, включена ли она в выбранную цепь и финализирована ли. Проверенные поля платежа или вызова можно сопоставить с ожидаемой операцией.
Эксплорер в этом обмене не участвует. Не нужно разбирать веб-страницы или верить ответу стороннего сервиса поиска транзакций. Идентификатор транзакции может оставаться удобным локальным индексом. Само проверяемое доказательство передаётся в чеке.
Сервис может приложить чек к ответу о расчёте, а агент сохранить его вместе с задачей. Сменивший его агент или позднее подключившийся аудитор проверит тот же файл самостоятельно и сопоставит подтверждённые поля с нужной задачей, получателем и условиями.
Стороны хранят нужные им условия, файлы и чеки. Новый участник проверяет эти чеки без старых тел транзакций и без зависимости от сервиса, который первоначально сообщил о платеже.
Agent Core
Agent Core реализует первую часть Live Agents: отдельную нативную программу со своей P2P-синхронизацией и проверкой доказательств, текущего State и чеков. Она использует реализацию консенсуса из зафиксированной версии исходного кода Parano1d. Запросы не переадресуются чужому узлу.
Интерфейс предназначен для программ. Запросы и ответы передаются строками JSON через выделенные каналы stdin/stdout. Асинхронный клиент Python запускает Core и сопоставляет ответы с запросами. Агент может проверить конкретный экземпляр права или чек, а также повторно проверить ранее принятый чек контракта относительно текущей выбранной цепи.
import asyncio
from pathlib import Path
from agcore import AgentCore
async def main():
async with AgentCore("./target/release/agcore", "./agent-state") as core:
await core.wait_ready()
result = await core.verify_receipt(Path("settlement.receipt"))
print(result)
asyncio.run(main())В ответах указаны вершина выбранной цепи, готовность Core, актуальность данных и статус подтверждений. Доказательство может быть корректным для старого State. Поэтому запрос действующего права требует свежего проверенного состояния и достаточных сведений от пиров. Само по себе доказательство не подтверждает, что изолированный узел уже увидел последнюю цепь.
Пока Core работает только на чтение: не хранит ключ расходования и не отправляет транзакции. Модель получает проверенные факты и может предложить действие. Допустимые пределы должен соблюдать отдельный модуль авторизации или шлюз исполнения. Проверка остатка не резервирует его: для расхода нужен авторизованный переход контракта.
Исходники и интерфейс доступны в каноническом репозитории, а также на зеркалах GitHub и GitLab.
Что установил эксперимент
В первом эксперименте два клиента получили копии одного ключа и общий лимит на десять обращений к двум шлюзам исполнения. Каждый шлюз проверял разрешение перед запуском внешней задачи. Сеть работала изолированно по правилам v2, узлы были отдельными процессами.
Каждый вызов с продолжением контракта уменьшал счётчик на единицу и требовал выплаты 0,1 NOID. Ключ клиента позволял продолжать контракт, но не закрывать его. После срока владелец мог вернуть остаток. У каждой задачи был уникальный адрес выплаты, зарегистрированный на одном из шлюзов; он связывал разрешение с этой задачей.
Перед запуском шлюз проверял чек контракта, сверял разрешение и задачу и ждал восемнадцать блоков подтверждения. Затем он записывал разрешение в свою базу, чтобы не запустить задачу дважды. Работой служил фиксированный расчёт SHA-256. Выплата 0,1 NOID обозначала разрешение на этот расчёт, а не его рыночную цену.
| Свойство | Результат |
|---|---|
| Общий лимит при копировании ключа | Десять вызовов снизили счётчик до нуля. Предварительная проверка одиннадцатого не прошла у обоих клиентов. |
| Конкурирующий расход одного экземпляра | Одна заявка принята, другая отклонена с SlotConflict. |
| Актуальные условия и полномочия | Отклонены устаревшие условия, подменённый счётчик, неверный ключ, запрещённое закрытие и неправильная выплата. |
| Привязка к зарегистрированному разрешению | Второй пополненный экземпляр имел валидный чек и те же начальные условия, но шлюз отклонил его как другое разрешение. |
| Привязка к задаче и исполнителю | Запуск до нужной глубины подтверждений и предъявление чека другому шлюзу отклонены. |
| Повторное использование и перезапуск шлюза | Все десять повторных попыток отклонены, затем отклонены снова после открытия сохранённых баз. |
| Срок и возврат остатка | Обращение после срока отклонено даже при неизрасходованном лимите. Возврат оставшихся средств владельцу прошёл на высоте 45. |
| Проверка доказательств новым участником | На высоте 64 тела десяти вызовов уже отсутствовали. Узел с пустым каталогом данных подключился, достиг той же вершины цепи и проверил все десять чеков. |
Один сбой вызвали после записи разрешения в базу, до завершения работы. Перезапущенный шлюз отказался исполнять его повторно: девять задач завершились, одно разрешение осталось отмеченным как использованное, но без готового результата. Лимит не был превышен. Что делать с неопределённым исходом, должно решать приложение.
Контрольный опыт с базой показал, зачем нужна координация. Восемь независимых копий счётчика на десять обращений пропустили восемьдесят запросов. Одна общая транзакционная база пропустила десять. В опыте с Parano1d действовал общий лимит, состояние которого каждый участник проверял собственным узлом.
Сеть дошла до высоты 64 и пересекла два запланированных тестовых форка. Клиенты были детерминированными. Шлюзы использовали отдельные SQLite-базы в одном процессе Python; узлы работали отдельными процессами на том же компьютере. Конкурирующие заявки проверяли приём конфликтующих расходов, а не гонку добытых блоков. В материалах исследования доступны сценарий и команды воспроизведения, а также результаты, проверки привязки экземпляра и чеки.
Три агента со своим Core
На видео три ИИ-агента в Codex CLI проверяют доказательства из эксперимента, каждый через отдельный процесс Agent Core. Два опорных узла предоставляют подготовленную цепь v2 в изолированной сети с доступом только через loopback.
Requester: брокер предлагает уже израсходованный экземпляр контракта как источник средств для новой задачи. Агент проверяет этот экземпляр по текущему State и отклоняет предложение.
Provider: агент проверяет сохранённый финализированный чек контракта и заново вычисляет записанный в тесте результат SHA-256. Чек подтверждает вызов и выплату, отдельное вычисление проверяет результат.
Auditor: новый Core подключается после удаления старого тела транзакции. Агент отклоняет изменённый чек, принимает оригинал, проверяет отсутствие старого тела и повторяет расчёт.
В репозитории доступны точные задания, полные вызовы инструментов и ответы, расшифровки сессий, журналы узлов, схема процессов и хеши файлов.
Что можно строить дальше
Общий лимит является одним из применений. На существующих возможностях v2 можно развивать Live Agents и в других направлениях:
Заказы между незнакомыми участниками. Маркетплейс знакомит заказчика с исполнителем и передаёт условия. Исполнитель через Agent Core проверяет средства в конкретном экземпляре контракта, свои полномочия и срок получения выплаты. Заказчик проверяет чеки расчётов. Никому из них не нужно верить маркетплейсу на слово о средствах и платежах. Как принимать работу, стороны по-прежнему определяют в соглашении.
Общий лимит для нескольких сервисов. Разные поставщики ресурсов могут принимать одно зарегистрированное разрешение. Каждый проверяет его расход и связывает конкретный вызов со своей задачей. В эксперименте проверен небольшой вариант такой схемы, включая отказ от повторного запуска после перезапуска шлюза или сбоя с неопределённым результатом.
Бюджеты для длительной работы. В v2 уже есть бюджеты на период, регулярные платежи и ветви возврата средств. На их основе приложение может ограничивать расходы агента, разрешать повторяющиеся выплаты и возвращать неиспользованный остаток. Каждый платёж требует авторизованного вызова; автоматически по расписанию консенсус их не выполняет.
Смена модели или оператора. Агент, который продолжает чужую работу, может проверить действующие права и сохранённые чеки своим Core, даже если API прежнего оператора исчез. Для этого стороны должны сохранить и передать нужные файлы и условия, а приложение восстановить пропущенные обновления контракта. Это позволяет проверить финансовые факты, но не внутреннюю память модели или произвольный пересказ выполненной работы.
От работающего Core к Live Agents
Agent Core уже выполняет локальные проверки. Теперь нужно связать предложения, разрешения, задачи, ограничения действий и обмен чеками в удобный протокол. Прототип шлюза также должен научиться восстанавливать пропущенные переходы, учитывать реорганизации цепи и пройти проверку на независимых машинах.
Синхронизация Core и ожидание подтверждений нового вызова занимают разное время. В эксперименте перед выполнением новой задачи ждали восемнадцать блоков, что при целевом интервале v2 составляет девять минут. Такая схема подходит для выдачи разрешения на задачу или сессию. Для подтверждения каждого токена или быстрого обращения к инструменту потребуется другой порядок исполнения.
Валидный чек подтверждает операцию в сети, но не то, что внешний сервис выполнил полезную работу. Он также не мешает агенту напрасно тратить законно выданный лимит. Соблюдение правил сервисом, изоляция ключей и ограничения приложения остаются необходимыми.
Я хочу, чтобы агенты работали с незнакомыми участниками, самостоятельно проверяя условия, действующие права и расчёты. Agent Core уже даёт первый работающий компонент этой модели. Вокруг него я хочу построить Live Agents.