Production-агенты с Claude: как собрать инженерный контур вместо демо

Новый стек: не готовый сотрудник, а строительные блоки

В анонсе от 20 августа 2026 года Anthropic представила обновлённые computer use, browser use, Skills API и Files API на Claude Platform. Это не одна функция «автоматизировать процесс», а разные примитивы для агентных приложений: модель может работать с интерфейсом, применять специализированную процедуру, получать документы и создавать выходные файлы.

Для Skills API и Files API также заявлена доступность через Microsoft Foundry. Поддержка обновлённых computer use и browser use для Vertex AI в публикации обозначена как будущая возможность.

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

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

• Computer use и browser use отвечают за действия в интерфейсе.
• Skills API упаковывает предметные процедуры, инструкции, ресурсы и связанные скрипты.
• Files API даёт механизм работы с входными и выходными файлами через идентификаторы.
• Оркестрация, политика доступа и бизнес-валидация остаются ответственностью приложения.

Сначала API, потом браузер, затем рабочий стол

Production-сценарий стоит начинать с простого вопроса: существует ли структурированный способ выполнить операцию. Если внутренний сервис умеет создать заявку, получить статус, проверить лимит или записать результат через API, этот маршрут проще валидировать и журналировать. До вызова сервер может проверить схему параметров, права пользователя и состояние задачи.

Browser use подходит для действий в веб-интерфейсе, когда подходящего API нет либо он не покрывает нужную операцию. В анонсе Anthropic browser use описан как инструмент, использующий структуру страницы, включая accessibility tree и идентификаторы элементов. В отличие от автоматизации, которая опирается только на экранные координаты, такой подход учитывает структуру интерфейса.

Computer use рассчитан на более широкий круг интерфейсов: desktop-среды, удалённый рабочий стол, legacy-приложения и сценарии, где браузерная структура не помогает. Claude не выполняет действия на компьютере самостоятельно в инфраструктуре Anthropic: приложение получает блоки tool use и исполняет их в контролируемой среде.

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

• Не заменяйте внутренний API экранной автоматизацией без необходимости.
• Перед внешним действием проверяйте домен, параметры, текущий этап job и полномочия.
• Не включайте загрузку файлов или JavaScript в браузерном исполнении, если этого не требует сценарий.
• Сохраняйте подтверждение человеком для необратимых, финансово значимых или чувствительных операций.

Tool use в production: цикл со состоянием и остановками

Удачное демо показывает, что модель нашла элемент интерфейса и выполнила действие. Для рабочей системы важнее полный цикл: backend создаёт задачу, передаёт Claude ограниченный контекст, получает запрос к инструменту, проверяет его, исполняет в выделенной среде и возвращает структурированный результат. Только затем модель продолжает работу.

Контекст задачи не должен сводиться к переписке или скриншоту. Устойчивому процессу нужны как минимум идентификатор job, пользователь или tenant, текущий этап, список разрешённых инструментов, доступные файлы, ожидаемый результат и история ошибок. При такой структуре повторный запуск не становится попыткой заново «вспомнить» предыдущее состояние.

Документация Anthropic предписывает обработать все tool calls из ответа модели и не продолжать последовательность после ошибки. Это особенно существенно для пакетных действий: несколько запросов в одном ответе не освобождают от проверки каждой операции. При сбое исполнитель должен остановить цепочку, зафиксировать причину и вернуть управление оркестратору.

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

• Исполняйте browser- и desktop-действия в изолированной среде с минимально необходимыми правами.
• Ограничивайте сетевые назначения и доступ к секретам.
• Журналируйте запросы к инструментам, результаты, решения policy layer и причины остановки.
• Запрашивайте approval до действия, а не после длинной цепочки.

Skills API: процедура как версионируемый артефакт

Skills API решает проблему монолитного промпта. В материалах Anthropic Skill представлен как директория с файлом SKILL.md, метаданными, ресурсами и, при необходимости, исполняемыми скриптами. Такой формат позволяет описывать специализированную возможность отдельно от общего диалога с моделью.

Практическая ценность навыка заключается в управляемости. Процедуру можно хранить в репозитории, назначить ей владельца, вносить изменения через review и проверять на контрольных примерах. Например, Skill может задавать порядок извлечения данных из документа, а отдельный скрипт проверять формат полей. Модель полезна при интерпретации неоднозначного входа; строгие вычисления и валидацию разумнее передавать детерминированному коду.

Anthropic описывает для Skills подход progressive disclosure: сначала модели доступны краткие сведения о навыке, затем основная инструкция, а дополнительные ресурсы подгружаются по необходимости. Это помогает не включать все материалы в каждый запрос. Экономия контекста, однако, не гарантирует правильный выбор процедуры: критические развилки всё равно должны поддерживаться серверными правилами.

Skill не должен быть единственным местом хранения политики. Если документ не распознан, сумма превышает внутренний лимит или выходной файл не прошёл проверку, дальнейшее действие определяет оркестратор или policy layer. Навык описывает процедуру, а система решает, разрешена ли она для конкретной задачи.

• Указывайте owner, версию, changelog и тестовые фикстуры для каждого Skill.
• Формулируйте входной и выходной контракт, а не только желаемый стиль ответа.
• Выносите проверку форматов, лимитов и обязательных полей в код.
• Не передавайте модели единоличное решение о доступе, деньгах и отправке данных.

Files API: артефакт получает жизненный цикл

Files API позволяет загрузить файл и затем передавать его в Messages API по file_id, не отправляя содержимое повторно. В документации это относится к работе с крупными входами, включая документы и другие файлы, а также с артефактами, создаваемыми через code execution или Skills.

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

Для приложения file_id не может служить самостоятельным доказательством права доступа. Документация описывает доступность файла в рамках workspace, однако multi-tenant продукту требуется собственная связь между tenant_id, user_id, job_id и разрешённым file_id. Backend должен проверять, вправе ли конкретная задача использовать конкретный документ.

Загруженные файлы неизменяемы: для новой версии нужна новая загрузка и новый идентификатор. Это удобно для аудита, если продукт сохраняет связь между редакциями и причину замены. TTL определяет срок доступности через API, но документация различает прекращение API-доступа, освобождение квоты, возможное ограниченное хранение для safety review и хранение метаданных. Поэтому expiration нельзя описывать как мгновенное физическое уничтожение данных.

Anthropic указывает максимальный размер одного файла в 500 МБ и лимит в 1 ТБ на организацию. Для изоляции арендаторов документация упоминает отдельные workspaces на tenant, а также стандартный предел до 100 workspaces на организацию без отдельного согласования. Эти ограничения нужно учитывать при выборе модели хранения и сегментации клиентов.

• Не принимайте file_id от клиента без серверной авторизации.
• Считайте каждую редакцию новым объектом и сохраняйте связь версий.
• Задавайте TTL в соответствии с политикой данных, не приравнивая его к немедленному удалению.
• Проверяйте выходной файл до публикации: формат, обязательные поля, получателя и бизнес-ограничения.

Базовый production-пайплайн: job, executor, policy layer, артефакт

Единицей проектирования должен быть не «диалог с Claude», а job с явным жизненным циклом. Backend создаёт job_id и фиксирует пользователя, tenant, версию Skill, разрешённые инструменты, связанные файлы и выбранную политику. Затем модели передаётся минимальный контекст: цель операции, допустимые действия, необходимые данные и текущее состояние процесса.

Модель планирует следующий шаг и при необходимости использует Skill. Когда требуется действие во внешней системе, оркестратор выбирает разрешённый маршрут: структурированный API, браузерный инструмент или computer use. Anthropic не задаёт такую последовательность как обязательную; это практический способ снизить зависимость от хрупкой экранной автоматизации.

Executor должен быть намеренно простым. Он проверяет тип вызова, параметры, разрешённый домен, лимиты, approval token и статус job, выполняет разрешённое действие, возвращает структурированный результат и записывает событие в журнал. Для операций, допускающих повторный запуск, приложение может применять идемпотентность, чтобы сбой не создал дублирующую заявку или повторную отправку.

После работы модели выходной артефакт не следует автоматически публиковать или пересылать. Сервер должен независимо проверить соответствие схеме, обязательные поля, допустимого получателя, формат и другие бизнес-правила. Если проверка не пройдена, задача должна остановиться, вернуться на уточнение или перейти оператору.

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

• Модель: планирование и интерпретация в разрешённой зоне.
• Skill: предметная процедура, материалы и вспомогательные скрипты.
• Оркестратор: состояние job, маршрутизация и восстановление после сбоев.
• Executor: изолированное выполнение и проверка параметров.
• Policy layer и человек: разрешение чувствительных и необратимых действий.
• Backend: финальная валидация и публикация артефакта.

Цитата в переводе

«Стоимость одной задачи снизилась примерно на 30% во всех протестированных нами workflow.»

Цитата в переводе

«Банки получают агентов для сложных workflow, не создавая каждый из них с нуля.»

Почему кейс и бенчмарк не гарантируют автономность

В публикации Anthropic приведён кейс Davide Locatelli: самый длинный процесс обработки claims, по его словам, сократился с 32 до 13 минут; также заявлены снижение стоимости примерно на 30% и 100% completion без смены промптов. Это пример потенциального эффекта в конкретном workflow, но не независимый бенчмарк. В публикации не раскрыты число прогонов, состав задач, baseline, доля ручного контроля и частота ошибок.

Дополнительный контекст даёт препринт OSWorld 2.0. Авторы описывают 108 реалистичных задач длительного взаимодействия с компьютером; для Claude Opus 4.7 в режиме maximum thinking они указывают в среднем 318 tool calls на задачу. В основном бинарном измерении при лимите 500 шагов для Claude Opus 4.8 с maximum thinking и batched tool calls приведён результат 20,6% завершённых задач и partial score 54,8%.

Эти результаты не измеряют августовский набор Anthropic, Skills API или Files API. Следовательно, по ним нельзя судить о надёжности нового стека. Но они показывают проблему длинных траекторий: сотни шагов создают множество точек, где агент способен потерять ограничение, неверно интерпретировать состояние или не заметить ошибку.

Для production это аргумент в пользу checkpoint-ов, ограниченного контекста, промежуточных валидаторов и возможности безопасно остановить задачу. Первый агентный процесс лучше делать узким: с понятным результатом, небольшим набором систем, проверяемым выходом и управляемой стоимостью ошибки. Сценарий, требующий широких прав, множества неявных договорённостей и автономных необратимых действий, плохо подходит для первого внедрения.

• Измеряйте не только completion, но и число эскалаций, повторных запусков и стоимость восстановления.
• Тестируйте изменения интерфейса, истёкшую авторизацию, повреждённые файлы и частично выполненные операции.
• Собирайте негативные сценарии, включая недоверенные инструкции во внешнем контенте.
• Отделяйте показатель демонстрации от устойчивости процесса в рабочей среде.

Российский контекст: контроль данных и полномочий

Российским командам не следует исходить из того, что прототип автоматически станет корпоративным продуктом. До расширения доступа нужно определить, какие документы допустимо передавать в модель, где хранится журнал, кто владеет Skill, кто подтверждает внешнее действие и как разделены данные клиентов. Это вопросы продуктового и операционного контура, а не только качества промпта.

Особого внимания требует изоляция tenants. Files API предоставляет механизм работы с файлами в workspace, но не заменяет прикладную модель авторизации. Если продукт обслуживает несколько клиентов, backend должен явно сопоставлять файл, задачу и пользователя, а исполнитель не должен получать доступ к документам, не связанным с текущим job.

Нужно заранее предусмотреть ручное завершение задачи и понятный маршрут эскалации. Оператору при разборе инцидента понадобятся не только финальный ответ модели, но и состояние job, список вызванных инструментов, связанные file_id, результаты проверок и факт подтверждения критического действия. Такой журнал помогает отличить ошибку модели от сбоя интерфейса, регрессии Skill или неверно настроенной политики.

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

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

Что это означает на практике

Связка computer use, browser use, Skills API и Files API разделяет разные части агентной работы: действия в интерфейсе, предметную процедуру и файлы. Она не отменяет разработку вокруг модели, но делает контур более модульным.

Production-агент начинается там, где модель перестаёт быть единственным центром системы. Модель планирует в разрешённых границах, executor выполняет проверенные действия, backend хранит состояние и связи данных, policy layer ограничивает полномочия, а человек подтверждает необратимые шаги. Такой подход меньше похож на эффектное демо и ближе к воспроизводимому инженерному продукту.

• Проектируйте job с идентификатором, состоянием, ограниченными полномочиями, журналом и правилами повторного запуска.
• Используйте структурированный API там, где он существует; browser use и computer use оставляйте для интерфейсных задач.
• Оформляйте Skills как версионируемые процедуры с владельцем, тестовыми примерами и детерминированными проверками.
• Связывайте tenant_id, user_id, job_id и file_id на backend: Files API не заменяет прикладную авторизацию.
• Проверяйте критические действия через policy layer и, где требуется, через human approval.
• Валидируйте выходные артефакты вне модели: схему, обязательные поля, формат, получателя и бизнес-ограничения.
• Тестируйте отказы и негативные сценарии так же тщательно, как happy path.

Чек-лист перед запуском первого production-агента

Этот чек-лист предназначен для команды, которая переводит сценарий с Claude из прототипа в контролируемый рабочий процесс.

Состояние задачи и доступ

• Для каждого запуска создаётся job_id, а система хранит пользователя или tenant, текущий этап и ожидаемый результат.
• Для задачи определён закрытый список разрешённых инструментов, доменов и связанных файлов.
• Backend проверяет связь tenant_id, user_id, job_id и file_id до передачи документа модели или исполнителю.
• Для чувствительных действий предусмотрен approval до выполнения.

Исполнение и восстановление

• Для каждой операции выбран предпочтительный маршрут: API, browser use или computer use.
• Executor проверяет параметры, лимиты, статус job и разрешённый маршрут перед внешним действием.
• Ошибочный tool call останавливает цепочку и фиксируется в журнале.
• Повторно запускаемые операции защищены от дублей, где это необходимо.

Артефакты, тесты и наблюдаемость

• Skill имеет владельца, версию, changelog, контракт и тестовые фикстуры.
• Выходной файл проходит независимую проверку схемы, обязательных полей, формата и получателя.
• В журнале сохраняются вызовы инструментов, результаты, решения policy layer и причины остановки.
• Команда проверила негативные сценарии: изменение интерфейса, истёкшую авторизацию, повреждённый файл и недоверенные инструкции во внешнем контенте.

Источники

• Anthropic: Build production agents with computer use, the Skills API, and the Files API
• Anthropic Skills: Files API
• Anthropic Skills: спецификация SKILL.md
• Anthropic Claude Cookbooks: Skills
• Anthropic Skills: концепции tool use
• METR: каталог инцидентов с агентами
• arXiv: препринт об OSWorld 2.0

Частые вопросы

Что выбрать для агентного действия: API, browser use или computer use?

Если операция доступна через структурированный API, это предпочтительный маршрут: его проще валидировать, авторизовать и журналировать. Browser use нужен для веб-интерфейсов без нужного API, а computer use подходит для desktop-сред, удалённых рабочих столов и legacy-приложений.

Заменяет ли Files API авторизацию файлов в multi-tenant продукте?

Нет. Files API работает с file_id и workspace, но прикладной backend должен самостоятельно проверять связь файла с tenant_id, user_id и job_id. Идентификатор файла сам по себе не доказывает право доступа.

Можно ли хранить всю бизнес-логику в Skill?

Не стоит. Skill полезен как версионируемая процедура с ресурсами и скриптами, но проверка лимитов, форматов, обязательных полей, доступа и разрешений должна оставаться в детерминированном коде и policy layer.

Почему нельзя автоматически публиковать файл, созданный агентом?

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

Почему результаты OSWorld 2.0 нельзя использовать как оценку нового стека Anthropic?

Препринт не измеряет августовские обновления Anthropic, Skills API или Files API. Он полезен только как контекст сложности длинных компьютерных траекторий, где большое число шагов увеличивает число потенциальных ошибок.

Практический чек-лист

Чек-лист запуска production-агента Claude

Подготовить для downloads/checklist-production-agent-claude.pdf. Материал повторяет практический чек-лист из статьи и пригоден для сохранения или печати командой.

Состояние задачи и доступ

• Создать job_id и хранить пользователя или tenant, этап задачи и ожидаемый результат.
• Ограничить список разрешённых инструментов, доменов и файлов.
• Проверять на backend связь tenant_id, user_id, job_id и file_id.
• Требовать approval до чувствительных действий.

Исполнение и восстановление

• Выбрать маршрут операции: API, browser use или computer use.
• Проверять параметры, лимиты, статус job и маршрут до внешнего действия.
• Останавливать цепочку при ошибочном tool call и фиксировать причину.
• Защитить повторно запускаемые операции от дублей, где это необходимо.

Артефакты, тесты и наблюдаемость

• Назначить владельца Skill, вести версию, changelog, контракт и тестовые фикстуры.
• Валидировать выходные файлы независимо от модели.
• Сохранять журнал вызовов инструментов, результатов и решений policy layer.
• Проверить негативные сценарии до запуска.