Кратко

  • draft-paxton-aicp-00, опубликованный 2 сентября 2026 года, остаётся действующим индивидуальным Internet-Draft. У него нет одобрения или формального статуса IETF, RFC-потока, ответственного Area Director и даты телеконференции.
  • Прогресс AICP включает завершённые, активные и все шаги, а также необязательный процент. Наборы шагов авторитетны; числовая доля носит рекомендательный характер.
  • Проект запрещает считать этот процент вероятностью успеха или безопасной границей отмены.
  • Фаза и состояние эффекта независимы. Неудачная или отменённая операция может оставить частичный эффект, а отмена — отдельный идемпотентный запрос, исполняемый по мере возможности.
  • Для значимой остановки нужен отдельный документ: точные шаги, фаза, эффект, последовательность, состояние запроса отмены, ожидаемые наблюдения и требование сверки.

Красивое число отвечает не на тот вопрос

Запись Datatracker представляет Agent Infrastructure Control Protocol (AICP) как редакцию 00 индивидуального Internet-Draft Тихана-Нико Пакстона, обновлённую 2 сентября 2026 года. Standards Track в заголовке — желаемый автором путь, а не текущее признание. RFC-поток, ответственный Area Director и телеконференция не указаны. Пояснение IETF уточняет: Internet-Draft может подать любой, а сама публикация не создаёт формального статуса.

Операционная проблема при этом реальна. Индикатор прогресса обычно смешивает три вопроса: какая часть плана пройдена, насколько вероятен хороший исход и безопасно ли остановиться сейчас. Они не обязаны меняться одновременно.

Представим два плана по пять шагов. В первом необратимое изменение выполняется сразу, а следующие четыре шага лишь проверяют результат. Во втором четыре чтения предшествуют единственной записи. Двадцать процентов первого плана могут означать, что главный эффект уже наступил; восемьдесят процентов второго — что эффектов ещё нет. Количество шагов не измеряет их последствия.

Зафиксированная редакция поэтому называет авторитетными наборы завершённых, активных и всех шагов. Процент можно добавить, но лишь как ориентир. Его нельзя принимать за вероятность успеха или за границу, до которой отмена безопасна.

Документ не связывает процент с объёмом эффекта. Ноль процентов не доказывает none, а сто — complete или успех. Интерфейс, который проводит такую связь, добавляет собственную политику принятия решений.

Фаза не сообщает, что изменилось снаружи

Operation в AICP может находиться в очереди, ожидать одобрения, исполняться, проверяться, быть приостановленной, успешной, неудачной, отменённой или неопределённой. Отдельно хранится состояние эффекта: отсутствует, возможен, частичен, полон, обращён или неизвестен.

Независимость принципиальна. Операция может завершиться неудачей уже после внешнего изменения. Отмена может прийти после возникновения части эффекта. Даже успех совместим с побочными последствиями. Поставщик должен обновлять состояние консервативно: отсутствие наблюдения не превращается в наблюдение отсутствия.

Конечный Outcome сохраняет то же различие. Он отделяет ожидаемые изменения от наблюдавшихся, фиксирует побочные эффекты, доказательства и дальнейшие действия. Каждый критерий бывает выполнен, не выполнен, неизвестен или не оценён. Успешные ответы API поставщика ещё не означают успех всей Operation.

Следовательно, место в плане, стадия жизненного цикла, материальный эффект и качество знания — четыре разных измерения. Когда одна цветная полоса заменяет их все, визуальный дизайн принимает управленческое решение, а не просто сокращает сообщение.

Отмена не перематывает реальность

AICP описывает отмену как самостоятельный идемпотентный управляющий запрос. Его можно повторить после сетевого сбоя, не создавая несколько отмен. Но выполняется он по мере возможности и не гарантирует остановку исходной работы. Если запрос столкнулся с завершением, поставщик возвращает текущее состояние Operation. Возобновление требует новой проверки полномочий, ограничений и предпосылок.

Поставщик обязан сообщить итоговую фазу и состояние эффекта и не может утверждать, что cancelled означает отсутствие эффекта. Поэтому правило «до 40% отменять безопасно» не имеет основания. Активный шаг мог уже отправить внешнюю команду, завершённый шаг мог быть единственной мутацией, а нужное наблюдение могло просто задержаться.

Компенсация тоже не является обратным воспроизведением. Обращение эффекта — новое значимое действие со своими полномочиями, возможностью отказа и побочными последствиями. Даже reversed должно описывать наблюдаемый результат компенсации, а не обещать идеальное возвращение прошлого состояния.

Ту же осторожность требует повтор. Возможный, частичный или неизвестный эффект нельзя отвечать слепым повторением мутации. Модель проблемы AICP способна указать безопасность повтора и необходимость предварительной сверки. Тайм-аут и низкий процент этого не решают.

Отдельный документ остановки

Я предлагаю при каждой потенциально значимой приостановке или отмене создавать отдельный документ остановки, не сводимый к индикатору прогресса. Это не требование редакции 00, а способ сохранить её полезные различия в момент операторского решения.

Документ должен идентифицировать долговечную Operation и последний номер последовательности, перечислять завершённые, активные и все шаги, а не только их отношение. В отдельных полях нужны фаза и эффект, идентификатор и состояние запроса отмены, ещё не полученные наблюдения и необходимость сверки перед повтором или компенсацией.

Ожидаемое изменение нельзя смешивать с наблюдаемым. Если шаг должен был отозвать полномочие, но независимого подтверждения нет, точная запись звучит так: «отзыв ожидался; эффект неизвестен». Фраза «отменено на 35%» этого не сообщает. Unknown — полноценный вывод, а не пробел для заполнения процентом.

Право на точные записи у Heng Lu даёт полезную редакционную дисциплину: запись описывает реальность, но не создаёт её. По аналогии документ остановки не должен создавать безопасность или шанс успеха из одной дроби. Это моё аналитическое применение принципа, а не утверждение, будто эссе Heng Lu устанавливает правила AICP или IETF.

Полезная схема без доказанного внедрения

Редакция 00 содержит пример HTTP-цикла управления и протокольные инварианты. Раздела Implementation Status в изученном тексте я не обнаружил. Рассмотренные источники не подтверждают независимую реализацию, производственное внедрение, результаты совместимости или принятие IETF. Описание процесса RFC напоминает, что Internet-Draft может измениться, истечь или никогда не стать RFC.

Реализацию следует проверять неудобными сочетаниями: ноль процентов при возможном эффекте, сто процентов при невыполненном критерии, отмена с частичным эффектом, неопределённая фаза при ожидающемся наблюдении. Интерфейс, не способный показать эти случаи, отбросит самую ценную осторожность проекта.

Источники

  1. IETF Datatracker: Agent Infrastructure Control Protocol
  2. Архив IETF: draft-paxton-aicp-00
  3. IETF: об Internet-Draft
  4. RFC Editor: как создаются RFC
  5. Heng Lu: The Bill of Rights of Uniqueness Coordination