Сценарии политики траектории¶

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

Исходники:

agent_runtime_ref/trajectory.py
tests/test_trajectory_policy.py
docs/companion/examples/run_trajectory_policy_scenarios.py

Запуск¶

Из корня выбранного рабочего дерева запустите:

/path/to/agent-arch/.venv/bin/python \
  docs/companion/examples/run_trajectory_policy_scenarios.py

В рабочем дереве репозитория книги /path/to/agent-arch означает основной каталог клона, где создана .venv; скрипт импортирует код из текущего рабочего дерева. Вывод представляет собой JSON с отсортированными ключами и фиксированным порядком сценариев.

Ожидаемые решения¶

Сценарий	Решение	Правило	Причина
`destination_fingerprint_mismatch`	`deny`	`destination-binding`	`value_binding_mismatch`
`cumulative_limit_exceeded`	`deny`	`daily-amount-limit`	`cumulative_limit_exceeded`
`required_predecessor_missing`	`deny`	`destination-confirmed-first`	`required_predecessor_missing`
`required_approval_missing`	`approval_required`	`transfer-approval`	`required_approval_missing`
`trusted_trajectory_allowed`	`allow`	`trajectory.all_rules`	`all_rules_satisfied`

Во втором сценарии текущее значение 40 само по себе ниже лимита 100, но доверенный снимок истории уже содержит накопленное значение 70, поэтому сумма закрыто отклоняется. Первый сценарий сравнивает только нормализованные отпечатки, а не исходные реквизиты. Сложение использует локальный контракт точной арифметики Decimal: не более шести знаков после запятой, максимум 999999999999.999999, точность 32 и исключения при округлении или арифметической ошибке. Результат не зависит от изменяемого глобального контекста Decimal.

Скрипт запуска не задаёт отпечаток запроса. Он вычисляет его из полей action, tenant_id, subject_id, ожидаемых ссылки и версии истории, номера последовательности, окна, идентификатора и версии политики, отсортированных значимых отпечатков и приращений счётчиков. Затем с этим значением связывается ApprovalRecord положительного сценария. Изменение любого из полей не позволяет повторно использовать прежнее подтверждение.

Для каждого сценария скрипт вызывает TelemetryEmitter.emit с типом события trajectory_policy_decision. Все значения внутри event.payload являются строками. Событие содержит отпечатки и состояния счётчиков, но не исходное назначение, реквизиты, аргументы инструментов или секреты.

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

Чтобы формально допустимый запрос не мог сорвать обязательное событие аудита, контракт принимает не более 16 отпечатков и 32 счётчиков отдельно в запросе и снимке истории. Границы проверяются при создании объектов, а допустимые максимальные наборы гарантированно помещаются в строковые поля телеметрии.

Граница реализации¶

evaluate_trajectory_policy является чистой детерминированной функцией. Она получает текущий TrajectoryRequest, неизменяемый TrajectorySnapshot и TrajectoryPolicy; контекст модели и сводка уплотнения не являются источниками истории. Поле integrity=verified передаёт утверждение доверенного поставщика снимка, но учебный вычислитель сам не проверяет подпись или происхождение этого утверждения. None вместо истории закрыто даёт history_missing, а отображение или объект неподходящего типа — history_malformed; исходный объект не отражается в решении или телеметрии.

Этот пример не обеспечивает распределённую транзакционную согласованность, блокировки, сравнение и обмен (compare-and-swap, CAS) для версии истории, атомарное обновление счётчиков, защиту от гонки между проверкой и внешним действием, долговечный журнал только для добавления или восстановление после сбоя. Он также не подключён к AgentRuntime. В промышленной системе внешний компонент должен получить целостный снимок из доверенного журнала, обеспечить версионную синхронизацию и блокировку либо транзакцию, атомарно зафиксировать решение и результат действия, а после сбоя выполнить восстановление или сверку.