Claude Cowork на мобильных устройствах и в вебе: почему командам стоит пересмотреть архитектуру своего агентного контура

Введение

Появление Claude Cowork в вебе и на мобильных устройствах — это не просто новая площадка, где можно нажать кнопку. Это признак того, что ИИ-агенты переходят от коротких диалогов на десктопе к более длительным системам выполнения задач, способным продолжать работу на разных устройствах.

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

Эта статья объясняет практический смысл такого сдвига. Она сосредоточена на проектировании agent harness — слоя вокруг модели, который управляет контекстом, инструментами, разрешениями, состоянием, журналами, валидацией и человеческим контролем.

Примечания к источнику и изображениям

Оригинальная страница-источник: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent Harness

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

Ключевые выводы

• Расширение Claude Cowork на десктоп, веб и мобильные устройства меняет то, как командам следует мыслить о работе агентов.
• Кросс-девайсный агент — это не просто чат-интерфейс. Это поток задачи, который может продолжаться в фоновом режиме.
• Командам необходима четкая архитектура agent harness: границы контекста, разрешения на инструменты, отслеживание состояния, журналы, валидация и правила утверждения.
• Мобильный доступ полезен для проверки прогресса и легковесного подтверждения, но он не должен становиться обходным путем для code review, одобрения продакшена или контроля над чувствительными данными.
• Более широкий рынок движется в том же направлении: агентные продукты становятся задачами системной инженерии, а не просто выбора модели.

Что изменилось

Теперь Claude Cowork указывает на рабочий процесс, в котором одна и та же задача может начаться на одном устройстве и продолжиться на другом. Пользователь может поставить задачу с десктопа, проверить прогресс с телефона, ответить на запрос вдали от рабочего места, а затем позже вернуться, чтобы просмотреть финальный результат.

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

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

Почему это проблема Agent Harness

Agent harness — это операционный слой вокруг модели. Модель решает, что делать дальше, но harness определяет, что именно модель

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

Даже сильная модель внутри слабой обвязки всё равно может создавать серьёзные проблемы. Она может читать не те файлы, использовать инструмент вне предполагаемой области применения, выдавать результаты, которые трудно проверить, или предпринимать действия до того, как команда подтвердит корректность вывода.

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

Хорошая обвязка отвечает на практические вопросы ещё до начала задачи:

• Какова точная цель задачи?
• Какой контекст разрешён?
• Какие инструменты доступны?
• Какие действия запрещены?
• Какой результат ожидается?
• Какая проверка должна быть выполнена?
• Какие подтверждающие материалы должны быть включены?
• Что требует одобрения человека?
• Когда агент должен остановиться?

Риск агентов, работающих постоянно

Фоновая работа полезна. Менеджер продукта может попросить агента упорядочить отзывы клиентов. Инженер может поручить агенту проанализировать журналы и предложить исправление. Основатель компании может попросить подготовить первый черновик обновления для инвесторов во время поездки.

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

Командам следует разделять разрешения агентов на понятные категории:

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

Что следует изменить командам разработки

1. Определяйте границы задачи до выполнения

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

Это особенно важно для задач по программированию. Расплывчатый запрос вроде «исправь эту проблему» слишком широк для агента, работающего без присмотра. Более безопасный вариант должен указывать саму проблему, соответствующие файлы или модули, команду для запуска тестов, а также требовать diff и заметки о рисках.

2. Запрашивайте подтверждения, а не только ответы

Результаты работы агента должны включать доказательства. Для задач по коду это означает diff’ы, результаты тестов, журналы сборки и краткое объяснение рисков. Для исследовательских задач это означает ссылки на источники, уровень уверенности и открытые вопросы

вопросы. Для операционных задач это означает план действий, затронутые системы, примечания по откату и точки согласования.

Цель не в том, чтобы заставить агента писать более длинные отчёты. Цель — снизить стоимость проверки.

3. Маршрутизируйте задачи по риску и стоимости

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

Маршрутизация моделей должна быть частью обвязки, а не запоздалой мыслью. Команда, которая маршрутизирует задачи по риску, может контролировать затраты, не снижая уровень безопасности.

4. Осознанно ограничивайте память

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

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

Практический шаблон обвязки

Командам не нужна сложная платформа, чтобы начать. Они могут начать с простого шаблона задачи и применять его последовательно.

task_goal: "Опишите точный результат, который должен выдать агент."
allowed_context:
  - "Перечислите папки, файлы, тикеты, журналы или документы, которые агенту разрешено читать."
allowed_tools:
  - "Перечислите инструменты, такие как терминал, браузер, трекер задач, документация или средство запуска тестов."
forbidden_actions:
  - "Никаких развёртываний в продакшене."
  - "Никаких внешних сообщений."
  - "Никакого удаления файлов или данных."
validation:
  - "Запустите соответствующие тесты или проверки."
  - "Приложите вывод команд или объясните, почему проверку не удалось выполнить."
expected_output:
  - "Предоставьте diff, сводку, риски и следующие шаги."
human_approval_required_for:
  - "Отправки сообщений"
  - "Развёртывания"
  - "Удаления данных"
  - "Изменения прав доступа"
stop_condition: "Остановитесь, когда результат будет готов к проверке человеком или когда отсутствует необходимый контекст."

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

Как оценивать разных агентов

Командам не следует сравнивать агентов только по демо или первому впечатлению. Такие инструменты, как Claude Cowork, Claude Code, OpenAI Codex, GitHub Copilot, Cursor и внутренние агенты, следует тестировать на реальных задачах с одинаковым временным бюджетом и одинаковыми критериями приёмки.

Полезные вопросы для оценки включают:

• Может ли агент определить правильный контекст, не читая лишние, не относящиеся к делу файлы?
• Может ли он безопасно использовать инструменты и оставаться в рамках запрошенной области?
• Выдаёт ли он небольшие, удобные для проверки изменения вместо крупных и неясных переписываний?
• Предоставляет ли он результаты тестов, ссылки на источники, журналы или другие подтверждения?
• Понимает ли он, когда нужно остановиться и запросить участие человека?
• Насколько дорогим оказывается запуск с точки зрения токенов, времени и усилий на проверку?
• Насколько сложно его настроить

откатить неудачный результат?

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

Рыночные сигналы

Claude Cowork — часть более широкого движения. Инструменты ИИ превращаются в агентные системы, которые объединяют модели, инструменты, разрешения, память, журналы и оценки.

Amazon Bedrock AgentCore показывает, как облачные платформы движутся в сторону управляемой агентной инфраструктуры. Исследовательские обсуждения вокруг harness engineering указывают на ту же идею: важны возможности модели, но именно система вокруг модели определяет, можно ли использовать ее надежно. Материалы OpenAI о Codex также рассматривают цикл агента как задачу оркестрации, включающую промпты, инструменты, выполнение и управление контекстом.

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

Рекомендуемый план действий

Неделя 1: Проведите аудит текущего использования агентов

Составьте список всех ИИ-агентов или помощников для программирования, которыми пользуется команда. Включите настольные приложения, веб-агентов, инструменты IDE, браузерных агентов, внутренних ботов и скрипты, подключенные к API моделей. Для каждого инструмента зафиксируйте, что он может читать, что он может изменять и может ли он запускать внешние действия.

Неделя 2: Классифицируйте задачи по уровню риска

Разделите задачи на группы низкого, среднего и высокого риска.

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

Неделя 3: Создайте небольшой внутренний бенчмарк

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

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

Неделя 4: Стандартизируйте инструкции и валидацию

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

FAQ

Что такое Claude Cowork?

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

Почему Claude Cowork на мобильных устройствах и в вебе имеет значение?

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

валидация.

Что такое agent harness?

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

Достаточно ли мобильного подтверждения для безопасности агента?

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

Как команде разработчиков безопасно использовать ИИ-агентов?

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

Что должен возвращать агент после задачи по программированию?

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

Как командам сравнивать Claude Cowork, Codex, Cursor, Copilot и других агентов?

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

Связанные инструменты

• Claude Cowork: агентный рабочий процесс Anthropic для назначения задач Claude на поддерживаемых устройствах и рабочих поверхностях.
• Claude Code: агент для программирования от Anthropic для рабочих процессов разработки в терминале и IDE.
• OpenAI Codex: агент для программирования от OpenAI для создания, редактирования, проверки и выпуска ПО с поддержкой ИИ.
• GitHub Copilot: ИИ-помощник GitHub для предложений кода, чата, ревью и рабочих процессов разработчиков.
• Cursor: среда программирования с ИИ, ориентированная на редактирование с учетом кодовой базы, чат и агентный стиль разработки ПО.
• Amazon Bedrock AgentCore: инфраструктура AWS для создания, развертывания и эксплуатации ИИ-агентов в масштабе.

Связанные ссылки

• Original NxCode Article: исходная статья, вдохновившая эту англоязычную публикацию.
• Claude Cowork Product Page: официальная страница с возможностями Claude Cowork, поддерживаемыми поверхностями и доступностью тарифов.
• Use Claude Cowork Safely: рекомендации Anthropic по безопасности в отношении разрешений, удаленных сессий, prompt injection и контроля со стороны человека.
• Amazon Bedrock AgentCore Harness GA: объявление AWS об управляемой инфраструктуре agent harness.
• [Harness Engineering for Self-Improvement](https://lilianweng.github.

io/posts/2026-07-04-harness/): Обсуждение Лилиан Вэнг о разработке харнесов и улучшении ИИ-систем.

• OpenAI Codex Developers: Официальная страница для разработчиков Codex как агентной системы для программирования.
• Unrolling the Codex Agent Loop: Техническое объяснение OpenAI того, как Codex координирует вызовы модели, инструменты, промпты и контекст.

Краткое резюме

Расширение Claude Cowork на настольные приложения, веб и мобильные устройства — полезное обновление продукта, но его реальное значение глубже. ИИ-агенты становятся постоянными системами выполнения задач, которые могут продолжать работать вне рамок одного окна чата.

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

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

Будущее агентной работы — это не только более умные модели. Это лучший дизайн харнесов вокруг моделей.