Операционный цикл агента представляет собой контролируемый путь от ограниченного запроса до проверенного артефакта. В рамках цикла назначаются ответственные, регистрируются входные данные, ограничиваются инструменты и данные, фиксируются действия и доказательства, проверяется результат, обрабатываются сбои, а работа завершается явно указанным состоянием: принято, отправлено на доработку или остановлено.
Это определение служит рабочей моделью в данном руководстве. Оно объединяет актуальные рекомендации поставщиков и рекомендации по управлению рисками с практическим операционным контрактом. Это не универсальный стандарт и не описание конкретного продукта.
Цикл нужен потому, что сообщение агента о завершении работы является лишь одним видом доказательства. Полезная операционная запись разделяет наблюдения источника или системы, требования проекта, утверждения агента, решения ответственного оператора и то, что остаётся неизвестным.
Сначала определите, нужен ли для работы агент
Не начинайте с инструмента. Сначала определите задачу, владельца решения и доказательства, которые потребуются в конце.
Рекомендации Microsoft по бизнес-планированию для ИИ-агентов разделяют предсказуемую работу, для которой подходит обычный код, задачи статического поиска информации и работу, требующую динамических рассуждений или использования инструментов. Руководство Anthropic по созданию эффективных агентов также различает заранее заданные рабочие процессы и агентов, которые сами управляют своим процессом и использованием инструментов. Anthropic рекомендует выбирать наименее сложную схему, подходящую для задачи. Эти материалы помогают принимать решения, но не являются жёсткими техническими законами.
Используйте детерминированную программу или заранее заданный рабочий процесс, если правила, порядок этапов, входные данные и ожидаемый результат стабильны и проверяемы. Используйте поиск по источникам, когда задача состоит в получении подтверждённой информации из известного набора документов и не требует динамической последовательности инструментов. Оставляйте рабочий процесс под управлением человека, если его основой служат политика, ответственность, профессиональное суждение или приёмка, а динамическое выполнение мало что добавляет.
Агент может быть уместен, если работа требует контекстных решений на основе неструктурированных входных данных, меняющейся последовательности инструментов или исключений, а организация всё ещё способна определить:
- результат и ответственного владельца;
- разрешённые входные данные, инструменты, данные и целевые объекты;
- запрещённые действия и точки одобрения;
- доказательства, которые сможет проверить другой проверяющий;
- владельца восстановления и безопасное состояние остановки;
- проверку приёмки итогового артефакта.
Если эти поля нельзя заполнить, добавление агента лишь затруднит обнаружение неопределённости.
Используйте пять категорий доказательств
Эти обозначения не позволяют принимать повествование агента за доказательство. Они составляют редакционную модель данного руководства.
| Категория доказательств | Значение | Что она может подтвердить | Что она не может подтвердить |
|---|---|---|---|
| Факт из источника | Первичный документ с отметкой времени, ответ ответственной системы или независимо наблюдаемый эффект. | Указанный факт наблюдался в пределах зафиксированной области источника. | Полноту за пределами этой области или ненаблюдаемый побочный эффект. |
| Документированное правило проектирования | Версионируемый операционный контракт устанавливает, что должны существовать роль, этап, одобрение, подтверждение или правило восстановления. | Организация спроектировала и зафиксировала правило. | Что программное обеспечение обеспечило его соблюдение или что оно соблюдалось при каждом запуске. |
| Утверждение агента | Агент сообщает о намерении, интерпретации, результате или причине. | Гипотезу или предложенный результат для проверки. | Выполнение, правильность, одобрение или завершение бизнес-задачи. |
| Решение оператора | Ответственный человек или уполномоченная система одобряет, отклоняет, принимает, останавливает работу либо выбирает путь восстановления. | Решение известно, если с ним связаны владелец, область, доказательства, целевой объект и время. | Что одобренное действие произошло или завершилось успешно. |
| Неразрешённая неопределённость | Имеющиеся доказательства не позволяют установить, что произошло и действителен ли результат. | Причину остановиться, провести сверку или собрать более сильные доказательства. | Разрешение догадываться, повторять попытку или объявлять об успехе. |
Одно событие может включать несколько категорий. Агент может предложить записать файл, оператор может одобрить один целевой объект и контрольную сумму, а целевая система позднее может подтвердить запись. Это соответственно утверждение агента, решение оператора и факт из источника. Если объединить их в формулировку «агент завершил работу», проверяющий не увидит нужных ему различий.
Восемь этапов операционного цикла
На каждом этапе должны быть видны владелец, входные данные, разрешённая область, действие, решение, результат, подтверждение, состояние сбоя, владелец восстановления и условие выхода, относящиеся к этому этапу. Приведённые ниже поля образуют единый операционный контракт. Это не утверждение о том, что во всех реализациях используются одинаковые названия.
| Этап | Ответственность и решение | Входные данные, инструменты, действие и передача | Результат, доказательства, сбой, восстановление и выход |
|---|---|---|---|
| 1. Ограничить запрос | Владелец результата определяет бизнес-результат и решает, принят ли запрос. | Зафиксируйте ID задания, задачу, аудиторию, исключённые цели, границу риска и критерии приёмки. Инструмент выполнения пока не нужен. | Выход происходит после принятия области работы. Неясная ответственность или противоречивые цели возвращают запрос его владельцу. |
| 2. Зарегистрировать входные данные | Владелец источника или оператор подтверждает, какие доказательства можно включить в задание. | Зафиксируйте идентификаторы источников, даты или версии, контрольные суммы, где они полезны, пределы актуальности и правила для отсутствующих данных. Передайте неизменяемый манифест входных данных. | Выход происходит с подтверждением входных данных и явно указанными неизвестными. Отсутствие доказательств, от которых зависит результат, останавливает или сужает задание. |
| 3. Назначить ответственных | Владелец результата назначает агента или роль рабочего процесса, оператора, проверяющего, владельца одобрения и владельца восстановления. | Определите, кто может предлагать, выполнять, одобрять, проверять, повторять попытку и останавливать работу. Зафиксируйте конфликты и недоступные роли. | Выход происходит с картой ответственности. Решение без владельца остаётся блокирующим фактором. |
| 4. Составить план в пределах области | Оператор или владелец политики решает, соответствует ли предложенный путь контракту. | Зафиксируйте этапы, разрешённые инструменты и данные, область целевых объектов, запрещённые действия, триггеры одобрения, бюджет и предел повторных попыток. Передайте план, доступный для проверки, или детерминированную инструкцию. | Выход происходит с принятым планом. Расширение области возвращается владельцу решения и не выводится из контекста автоматически. |
| 5. Выполнить и зафиксировать | Роль выполнения совершает только разрешённые действия; владелец одобрения при необходимости принимает решение о действиях с существенными последствиями. | Свяжите действие с целевым объектом и неизменяемым идентификатором полезной нагрузки. Зафиксируйте время, входы и результаты инструментов, изменения состояния, ошибки и подтверждения побочных эффектов. | Выход происходит с наблюдаемым результатом или сохранённой неопределённостью. Тайм-аут после возможной записи ведёт к сверке, а не к слепому повтору. |
| 6. Проверить артефакт | Назначенный проверяющий применяет письменные критерии приёмки. | Сопоставьте результат с запросом, источниками, политикой, доказательствами и запрещёнными результатами. Зафиксируйте идентификатор и тип проверяющего, неопределённость и ограничения. | Выход происходит с решением ACCEPT, REVISE или HOLD. Одно лишь техническое завершение не подтверждает полезность или правильность. |
| 7. Восстановить или остановить | Владелец восстановления классифицирует сбой и выбирает повтор, исправление, компенсацию, передачу или остановку. | Проведите сверку возможных побочных эффектов, проверьте точный целевой объект, сохраните неудачную попытку и свяжите следующую попытку с новым идентификатором. | Выход происходит с состоянием RECOVERED, разрешённой новой попыткой либо окончательной неопределённостью или остановкой. Никогда не удаляйте запись о неудачной попытке. |
| 8. Закрыть и передать | Владелец результата принимает итоговое состояние и назначает владельца следующего решения. | Соберите принятый артефакт, доказательства, вердикт проверки, оставшиеся неизвестные и следующего владельца. Храните только доказательства, предусмотренные правилами управления. | Выход происходит с артефактом, связанным с подтверждением, и явно указанным следующим состоянием. Слово «готово» без записи о приёмке не закрывает бизнес-задачу. |
В качестве модели ответственности цикл последователен, но при реализации можно возвращаться к предыдущим этапам. Новые доказательства могут вернуть черновик к регистрации входных данных. Неудачная проверка может вернуть работу к планированию. Восстановление может создать следующую попытку. Запись должна показывать это движение, а не переписывать предыдущее состояние.
Практический пример: пакет исследования поставщиков
Этот пример гипотетический. Он не описывает Toone, клиентское внедрение или тестовый запуск продукта.
Команде по закупкам нужен пакет для проверки трёх потенциальных поставщиков программного обеспечения. Запрос ограничен публичными первичными источниками. Агент может подготовить один внутренний пакет. Ему запрещено связываться с поставщиками, создавать учётные записи, принимать условия, изменять закупочные записи или публиковать пакет.
1. Ограничение запроса
Руководитель закупочных операций владеет результатом. Принятым результатом считается один пакет, содержащий актуальное публичное описание продукта каждого поставщика, источник цен, если они опубликованы, документацию об обработке данных, неразрешённые вопросы и ссылки на источники. Рекомендация по закупке не входит в область работы.
Критерии приёмки требуют прямых ссылок на источники, дат наблюдения, разделения фактов из источников и анализа, а также видимого состояния неопределённости для отсутствующих доказательств.
2. Зарегистрированные входные данные
Оператор фиксирует домены трёх поставщиков, разделы их публичной документации, дату проверки и одобренные типы источников. Манифест входных данных исключает отзывы пользователей, сгенерированные сводки без первичных ссылок, закрытые документы и персональные данные.
Каждый снимок источника получает дату и стабильную ссылку. Недоступный источник остаётся неразрешённой неопределённостью. Агенту запрещено выдумывать его содержание или делать выводы о нём.
3. Карта ответственности
| Ответственность | Гипотетический владелец |
|---|---|
| Бизнес-результат | Руководитель закупочных операций |
| Граница источников | Аналитик по закупкам |
| Исследование и черновик | Агент исследования поставщиков, версия example-v1 |
| Проверка артефакта | Аналитик по закупкам |
| Одобрение внешней коммуникации | Руководитель закупочных операций |
| Сбой и восстановление | Владелец закупочных систем |
Названия обозначают роли в вымышленном примере. Они не являются ролями Toone и не служат доказательством проверки этого руководства человеком.
4. План в заданных пределах
Агент предлагает четыре этапа: собрать одобренные источники, извлечь датированные факты, подготовить нейтральные разделы о поставщиках и собрать внутренний пакет. Он может читать публичные веб-страницы и использовать один внутренний целевой объект для черновика. Запрещены любая внешняя запись, сообщение, отправка формы, действие с учётной записью или изменение записи.
Оператор принимает план и связывает один целевой объект результата с запланированным идентификатором полезной нагрузки. Одобрение является решением оператора. Оно не доказывает, что черновик был записан.
5. Выполнение и неопределённый побочный эффект
Сбор источников завершён и создал манифест источников. Агент предлагает пакет и сообщает, что записал черновик. Это сообщение является утверждением агента.
Инструмент записи возвращает тайм-аут после того, как удалённый сервис мог принять запрос. Ответ с ошибкой является фактом из источника. Существование черновика остаётся неразрешённой неопределённостью. Немедленная повторная попытка может создать дубликат или перезаписать уже существующий файл.
6. Проверка пока невозможна
У проверяющего нет стабильного артефакта для изучения, поэтому проверка заблокирована. Утверждение агента и тайм-аут не удовлетворяют требованию о подтверждении артефакта.
7. Ветвь восстановления
Прежде чем разрешить повтор, владелец закупочных систем проверяет точный целевой объект и ожидаемый хеш полезной нагрузки.
- Если ожидаемый черновик существует и его хеш совпадает с одобренным, зафиксировать
RECOVEREDи не повторять запись. - Если целевой объект можно проверить и черновик отсутствует, разрешить новую попытку с новым ID попытки.
- Если целевой объект нельзя проверить, зафиксировать
WRITE_UNCERTAINи остановиться. Отсутствие доказательств не разрешает повторять попытку.
Выбор пути восстановления является решением оператора. Наблюдение целевого объекта, на котором он основан, является фактом из источника. Требование сверки перед повторной попыткой является документированным правилом проектирования операционного контракта в этом примере.
8. Проверка и закрытие
Предположим, что соответствующий черновик существует и восстановлен. Проверяющий сопоставляет каждое существенное утверждение с манифестом источников, отмечает одно неподтверждённое сравнение для удаления и возвращает REVISE. Агент создаёт следующий черновик с новой контрольной суммой артефакта. Проверяющий принимает эту версию.
Подтверждение закрытия фиксирует принятую контрольную сумму, манифест источников, удалённое утверждение, решение проверяющего, оставшиеся неизвестные и руководителя закупочных операций как следующего владельца. В нём не сказано, что поставщики были одобрены или что с ними связались.
Почему для неопределённых записей нужен отдельный путь восстановления
Повтор допустим, только если характер сбоя и побочных эффектов делает повторение безопасным. Практическое руководство OpenAI по созданию агентов рекомендует оценивать риск инструмента по таким факторам, как доступ на чтение или запись, обратимость, разрешения и финансовые последствия. В нём также описано вмешательство человека при достижении порога сбоев и для рискованных или необратимых действий.
NIST AI 600-1 содержит меры управления для определённых ролей, человеческого надзора, сохранения истории оценок, деактивации, реагирования на инциденты и резервных вариантов для зависимостей. NIST описывает Generative AI Profile как добровольные межотраслевые рекомендации, поэтому эти меры являются рекомендациями, а не сертификацией, юридическим требованием или доказательством свойств продукта.
Для неопределённой записи операционный вопрос звучит так: «Может ли ответственный владелец установить, произошёл ли первый эффект?» Ответ определяет ветвь:
| Наблюдаемое состояние | Безопасная запись | Следующее действие |
|---|---|---|
| Ожидаемый эффект существует и соответствует одобренному целевому объекту и полезной нагрузке | RECOVERED | Сохранить эффект и продолжить проверку, не повторяя действие. |
| Целевой объект можно проверить, а ожидаемый эффект отсутствует | RETRY_ELIGIBLE | Разрешить новую попытку с новым идентификатором и той же или изменённой областью. |
| Эффект произошёл, но отличается от одобренного | REMEDIATION_REQUIRED | Остановить обычную работу, сохранить доказательства и назначить исправление или компенсацию. |
| Целевой объект нельзя проверить или доказательства противоречат друг другу | WRITE_UNCERTAIN | Остановиться. Не повторять попытку, пока более сильные доказательства не разрешат неопределённость побочного эффекта. |
Это различие сохраняет значение, даже если система выполнения сообщает о сбое. Ответ об ошибке может сосуществовать с завершённым внешним эффектом.
Рабочая форма операционного контракта
Используйте эту форму до назначения агенту повторяющейся работы или работы с существенными последствиями. Оставляйте незаполненные поля видимыми как неразрешённые задачи.
| Поле | Что записать |
|---|---|
| 1. ID запроса или задания | Стабильный идентификатор, общий для запроса, попыток, артефактов и подтверждений. |
| 2. Предполагаемый результат и ответственный владелец | Бизнес-результат, кто его принимает, и действия, которые такая приёмка не разрешает. |
| 3. Задача и исключённые цели | Включённая и исключённая работа, запрещённые результаты и предсказуемое неправильное использование. |
| 4. Входные данные и идентификаторы источников | Владельцы источников, версии или даты, пределы актуальности, контрольные суммы, где они полезны, и правило для отсутствующих данных. |
| 5. Карта ответственности | Агент или роль рабочего процесса, оператор, владелец одобрения, проверяющий, владелец восстановления и следующий владелец. |
| 6. Разрешённые инструменты и данные | Область чтения и записи, разрешённые целевые объекты, классы данных, граница учётных данных и правило хранения. |
| 7. Запрещённые действия | Внешние записи, сообщения, покупки, отправки, изменения разрешений, публикация и другие исключённые эффекты. |
| 8. Критерии входа и доказательства выхода | Условия, которые должны быть выполнены до начала работы, и подтверждение, доказывающее возможность закрыть этап. |
| 9. Идентификатор действия с существенными последствиями | Точный целевой объект, неизменяемый хеш полезной нагрузки, класс действия, область одобрения и срок действия одобрения. |
| 10. Триггер и владелец одобрения | Действие, требующее решения, кто принимает решение, какие доказательства изучаются при его принятии и способ записи решения. |
| 11. Подтверждение выполнения и побочного эффекта | ID попытки, время, результат инструмента, наблюдение целевого объекта, контрольная сумма артефакта и любые противоречащие доказательства. |
| 12. Запись о проверке | Критерии приёмки, идентификатор и тип проверяющего, проверенные доказательства, вердикт, неопределённость и ограничения. |
| 13. Сбой и восстановление | Классы сбоев, допустимость повторной попытки, предел попыток, метод сверки, владелец восстановления и путь компенсации. |
| 14. Неизвестные и вывод из эксплуатации | Неразрешённые факты, сохранённые доказательства, условие остановки, правило деактивации и дата проверки. |
| 15. Следующее действие и конечное состояние | Принятый артефакт, следующий владелец, следующее решение и состояние задания: принято, отправлено на доработку, приостановлено, остановлено или выведено из эксплуатации. |
Компактная версия для копирования
ID задания:
Владелец результата:
Результат:
Граница задачи:
Исключённые цели:
Входные данные и версии источников:
Агент или роль рабочего процесса:
Оператор:
Проверяющий и его тип:
Владелец восстановления:
Разрешённые инструменты и данные:
Запрещённые действия:
Критерии входа:
Доказательства выхода:
Целевой объект и идентификатор полезной нагрузки:
Триггер и владелец одобрения:
Подтверждение выполнения:
Критерии и вердикт проверки:
Классы сбоев:
Метод сверки:
Предел повторных попыток:
Неизвестные:
Условие остановки или вывода из эксплуатации:
Следующее действие и владелец:
Условия остановки
Остановите работу или передайте управление, если выполняется любое из этих условий:
- действие с высоким риском, чувствительными данными или необратимыми последствиями требует ответственного одобрения;
- задача выходит за пределы принятой области или требует неодобренного инструмента, источника, целевого объекта или разрешения;
- достигнут порог сбоев или предел повторных попыток;
- возможный внешний побочный эффект невозможно сверить;
- доказательства, от которых зависит результат, отсутствуют, устарели, противоречат друг другу или не могут быть связаны с артефактом;
- проверяющий или владелец восстановления недоступен;
- результат не соответствует обязательному критерию приёмки;
- детерминированный рабочий процесс может выполнить задачу более предсказуемо и с меньшей потребностью в суждении;
- ожидаемая ценность больше не оправдывает затраты, задержку или риск;
- вопросы политики, права, конфиденциальности, безопасности или предметной области требуют квалифицированного владельца за пределами полномочий агента.
Остановка является допустимым результатом, если она сохраняет доказательства и называет следующего владельца. Продолжение без полномочий не означает прогресс.
Документированный контракт организации служит доказательством проектирования
Изученная организация SEO Growth представляет один пример документированной операционной схемы. В её справочнике и записях процедур назначены владельцы этапов, входные данные, решения, результаты, блокировки, состояния обратных вызовов, контрольные суммы и подтверждения. Документированный контракт также оставляет существенные внешние действия для этапа одобрения в реальном времени.
Эти записи показывают, что организация спроектировала и зафиксировала. Они не доказывают, что Toone Desktop обеспечил соблюдение контракта, выполнил каждый этап, сохранил полную историю, автоматически восстановил работу или создал бизнес-результат. В статье они используются только для пояснения различия между документированным правилом проектирования и фактом из источника.
Выберите следующего владельца по оставшемуся вопросу
Если остаётся вопрос о том, кто может одобрить действие или принять остаточный риск, перейдите к материалу об управлении ИИ-агентами, на английском. Если команде сначала нужен контекст категории, прочитайте руководство по AI-native-компаниям, на английском. Используйте демонстрации, на английском только как доказательства в пределах, указанных на этих страницах.
После запуска канонических маршрутов здесь следует добавить ссылки на связанные основные материалы об организационных знаниях, организациях агентов, процедурах, оценке и наблюдаемости. Этот черновик не считает запланированные маршруты текущими доказательствами.
Об этом руководстве
Кто: организационным автором является Toone Content, издателем является Hexagonal.io. Агент Content Editor отвечает за редакционную проверку этого черновика. Не заявлена проверка человеком, владельцем продукта или предметной области, а также специалистом по разработке, безопасности, конфиденциальности или правовым вопросам.
Как: руководство подготовлено на основе брифа, одобренного на G1, и закреплённого контрольной суммой досье утверждений и источников. Автоматизированная помощь применялась для сбора, организации и синтеза актуальных первичных рекомендаций Microsoft, OpenAI, Anthropic и NIST. Пять категорий доказательств, восьмиэтапный цикл, пример сбоя и рабочая форма являются редакционным синтезом. Пример исследования поставщиков вымышлен. Статья не основана на тестировании продукта Toone, клиентском внедрении, исследовании производительности или сравнительном тесте.
Зачем: руководство должно помочь операторам и руководителям команд сделать работу агента проверяемой на всём пути от запроса до проверки, с ясными полномочиями, доказательствами, состояниями сбоя, восстановления и выхода.
Ограничения и исправления: операционные потребности зависят от задачи, риска, юрисдикции и системы. Юридическая, регулируемая, чувствительная к безопасности, конфиденциальности и защите данных, а также другая работа с существенными последствиями требует квалифицированной проверки за пределами этой редакционной модели. Ознакомьтесь с политикой редакционной работы, источников и исправлений, на английском. Для общих вопросов используйте страницу контактов Toone, на английском. Отправляйте исправления с URL затронутой страницы и подтверждающими доказательствами на адрес hello@trytoone.com. Существенные исправления должны обновлять дату источника и делать зависимые локализованные версии недействительными до завершения проверки.
Первичные источники
- Microsoft Learn: бизнес-план для ИИ-агентов, обновлено 2026-04-10.
- OpenAI: практическое руководство по созданию агентов, дата обращения 2026-08-13.
- Anthropic: создание эффективных агентов, опубликовано 2024-12-19.
- NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile, опубликовано 2024-07-26.