Claude Cowork no celular e na web: por que as equipes devem redesenhar sua estrutura de agentes

Introdução

A chegada do Claude Cowork à web e ao mobile não é apenas um novo lugar para clicar num botão. É um sinal de que os agentes de IA estão a passar de conversas curtas no desktop para sistemas de tarefas de longa duração, capazes de continuar o trabalho entre diferentes dispositivos.

Para equipas de produto, engenharia e operações, a pergunta importante já não é apenas se um agente consegue concluir uma tarefa. A questão mais difícil é se o agente consegue manter os limites certos enquanto trabalha: que ficheiros pode ler, que ferramentas pode usar, que ações exigem aprovação, que provas deve devolver e como os humanos podem rever o resultado.

Este artigo explica o significado prático dessa mudança. O foco está no design do agent harness: a camada em torno do modelo que gere contexto, ferramentas, permissões, estado, registos, validação e controlo humano.

Notas sobre a Fonte e as Imagens

Página original da fonte: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent Harness

A página de origem analisada expunha um SVG padrão de cartão de blogue e imagens do site/rodapé, mas não apresentava capturas de ecrã do corpo do conteúdo, diagramas de fluxo de trabalho, capturas de código ou imagens de resultados que fossem claramente necessárias para o corpo do artigo. Para evitar inserir imagens decorativas ou não relacionadas, não foi adicionada nenhuma imagem ao corpo do texto. Se uma versão futura da fonte incluir capturas de ecrã do produto ou diagramas, estes poderão ser inseridos junto das secções correspondentes.

Principais conclusões

• A expansão do Claude Cowork entre desktop, web e mobile muda a forma como as equipas devem pensar sobre o trabalho dos agentes.
• Um agente entre dispositivos não é apenas uma interface de chat. É um fluxo de tarefa que pode continuar em segundo plano.
• As equipas precisam de um agent harness claro: limites de contexto, permissões de ferramentas, rastreio de estado, registos, validação e regras de aprovação.
• O acesso via mobile é útil para verificar o progresso e dar confirmações leves, mas não deve tornar-se um atalho para contornar revisão de código, aprovação de produção ou controlos sobre dados sensíveis.
• O mercado em geral está a mover-se na mesma direção: produtos com agentes estão a tornar-se problemas de engenharia de sistemas, e não apenas problemas de seleção de modelos.

O que mudou

O Claude Cowork aponta agora para um fluxo de trabalho em que a mesma tarefa pode começar num dispositivo e continuar noutro. Um utilizador pode atribuir trabalho a partir de um desktop, verificar o progresso no telemóvel, responder a um pedido enquanto está longe da secretária e, mais tarde, regressar para rever o resultado final.

Isso parece conveniente, mas também altera o modelo de controlo. Numa janela de chat tradicional, o utilizador normalmente mantém-se próximo da interação. Com um agente em segundo plano, o agente pode continuar a usar contexto e ferramentas mesmo quando o utilizador já não está a acompanhar ativamente cada passo.

É por isso que o acesso a agentes entre dispositivos deve ser tratado como mais do que uma funcionalidade de produto. É uma questão de desenho de fluxo de trabalho. A tarefa precisa de transportar os seus próprios limites, requisitos de evidência e regras de aprovação, independentemente de o utilizador estar no desktop, na web ou no mobile.

Porque isto é um problema de Agent Harness

Um agent harness é a camada operacional em torno do modelo. O modelo decide o que fazer a seguir, mas o harness determina o que o

o modelo consegue ver, quais ferramentas pode chamar, como o estado é armazenado, como as ações são registadas, como as falhas são tratadas e quando um humano tem de aprovar o passo seguinte.

Um modelo forte dentro de um ambiente de execução fraco ainda pode criar problemas graves. Pode ler os ficheiros errados, usar uma ferramenta fora do âmbito pretendido, produzir trabalho difícil de rever ou tomar medidas antes de a equipa ter validado o resultado.

Quando um agente trabalha em vários dispositivos, o ambiente de execução torna-se ainda mais importante. A tarefa pode começar no computador, continuar numa sessão remota, pedir confirmação no telemóvel e depois gerar um documento, uma alteração de código ou uma mensagem. O modelo de permissões deve acompanhar a tarefa, não o dispositivo.

Um bom ambiente de execução responde a questões práticas antes de a tarefa começar:

• Qual é o objetivo exato da tarefa?
• Que contexto é permitido?
• Que ferramentas estão disponíveis?
• Que ações são proibidas?
• Que resultado é esperado?
• Que validação deve ser executada?
• Que evidência deve ser incluída?
• O que requer aprovação humana?
• Quando deve o agente parar?

O Risco dos Agentes Sempre Ativos

O trabalho em segundo plano é útil. Um gestor de produto pode pedir a um agente para organizar o feedback dos clientes. Um engenheiro pode pedir a um agente que analise registos e sugira uma correção. Um fundador pode pedir um primeiro rascunho de uma atualização para investidores enquanto viaja.

O risco é que um agente possa continuar a agir depois de o utilizador deixar de acompanhar de perto. Isso não é automaticamente inseguro, mas exige limites melhores.

As equipas devem separar as permissões dos agentes em categorias claras:

A confirmação no telemóvel pode acelerar o fluxo de trabalho, mas não deve substituir um verdadeiro modelo de aprovação. Um toque no telemóvel deve confirmar uma ação bem delimitada, não conceder acesso amplo a uma tarefa pouco clara.

O Que as Equipas de Programação Devem Mudar

1. Definir os limites da tarefa antes da execução

Cada tarefa de agente deve começar com um breve resumo da tarefa. Esse resumo deve incluir o objetivo, o contexto permitido, as ferramentas permitidas, as ações proibidas, o resultado esperado, o método de validação e a condição de paragem.

Isto é especialmente importante para tarefas de programação. Um pedido vago como “corrige este problema” é demasiado amplo para um agente sem supervisão. Uma versão mais segura identificaria o problema, indicaria os ficheiros ou módulos relevantes, especificaria o comando de teste e exigiria um diff mais notas de risco.

1. Pedir evidência, não apenas respostas

Os resultados dos agentes devem incluir prova. Para tarefas de código, isso significa diffs, resultados de testes, registos de compilação e uma breve explicação do risco. Para tarefas de investigação, significa ligações para as fontes, nível de confiança e questões em aberto

perguntas. Para tarefas operacionais, isso significa o plano de ação, os sistemas afetados, as notas de reversão e os pontos de aprovação.

O objetivo não é fazer o agente escrever relatórios mais longos. O objetivo é reduzir o custo de revisão.

1. Encaminhar tarefas por risco e custo

Nem toda tarefa precisa do modelo mais robusto ou do maior orçamento de raciocínio. Tarefas de baixo risco, como formatação, resumo e classificação, muitas vezes podem ser executadas com modelos mais baratos ou mais rápidos. Alterações de arquitetura, migrações, depuração em produção e tarefas sensíveis à segurança devem usar modelos mais robustos e uma revisão mais rigorosa.

O roteamento de modelos deve fazer parte do arcabouço, não ser algo pensado depois. Uma equipe que encaminha por risco consegue controlar custos sem reduzir a segurança.

1. Limitar a memória de forma deliberada

Os agentes podem se beneficiar de uma memória estável do projeto: regras do repositório, comandos comuns, convenções de nomenclatura, notas de arquitetura e preferências de estilo.

Eles não devem armazenar casualmente segredos, credenciais, dados de clientes, suposições temporárias ou conclusões não verificadas. A memória só é útil quando é curada. Caso contrário, torna-se outra fonte de deriva oculta de contexto.

Um modelo prático de arcabouço

As equipes não precisam de uma plataforma complexa para começar. Elas podem começar com um modelo simples de tarefa e aplicá-lo de forma consistente.

task_goal: "Descreva o resultado exato que o agente deve produzir."
allowed_context:
- "Liste as pastas, arquivos, tickets, logs ou documentos que o agente pode ler."
allowed_tools:
- "Liste ferramentas como terminal, navegador, rastreador de issues, documentação ou executor de testes."
forbidden_actions:
- "Sem implantações em produção."
- "Sem mensagens externas."
- "Sem exclusão de arquivos ou dados."
validation:
- "Execute os testes ou verificações relevantes."
- "Inclua a saída dos comandos ou explique por que a validação não pôde ser executada."
expected_output:
- "Forneça um diff, resumo, riscos e próximos passos."
human_approval_required_for:
- "Envio de mensagens"
- "Implantação"
- "Exclusão de dados"
- "Alteração de permissões"
stop_condition: "Pare quando a saída estiver pronta para revisão humana ou quando faltar o contexto necessário."

Para pequenas correções de código, exija uma branch local, diff, saída de testes e uma nota de risco. Para resumos de pesquisa, exija fontes e níveis de confiança. Para verificações de release, exija logs de build, verificações com falha e dicas de reversão. Para tarefas com dados de clientes, exija uma nota sobre o escopo dos dados e um plano de mascaramento. Para ações em produção, o agente deve preparar o plano, mas um humano deve executar ou aprovar a ação.

Como avaliar diferentes agentes

As equipes devem evitar comparar agentes apenas por demonstrações ou primeiras impressões. Ferramentas como Claude Cowork, Claude Code, OpenAI Codex, GitHub Copilot, Cursor e agentes internos devem ser testadas com tarefas reais, usando o mesmo orçamento de tempo e os mesmos critérios de aceitação.

Perguntas úteis de avaliação incluem:

• O agente consegue identificar o contexto correto sem ler em excesso arquivos não relacionados?
• Ele consegue usar ferramentas com segurança e permanecer dentro do escopo solicitado?
• Ele produz mudanças pequenas e revisáveis, em vez de grandes reescritas pouco claras?
• Ele fornece resultados de testes, citações, logs ou outras evidências?
• Ele sabe quando parar e pedir intervenção humana?
• Quão cara é a execução em tokens, tempo e esforço de revisão?
• Quão difícil é para

reverter um resultado com falha?

Execute cada tarefa mais de uma vez. Os agentes são sistemas probabilísticos. Uma única execução impressionante não prova fiabilidade, e uma execução ruim não prova que a ferramenta seja inutilizável. Observe a taxa de conclusão, os tipos de falha, o custo de revisão, o custo por resultado útil e o esforço de recuperação.

Sinais do mercado

Claude Cowork faz parte de um movimento maior. As ferramentas de IA estão a tornar-se sistemas de agentes que combinam modelos, ferramentas, permissões, memória, registos e avaliações.

O Amazon Bedrock AgentCore mostra como as plataformas de cloud estão a avançar para uma infraestrutura de agentes gerida. As discussões de investigação sobre harness engineering apontam para a mesma ideia: a capacidade do modelo importa, mas o sistema à volta do modelo é que determina se ele pode ser usado de forma fiável. Os materiais do Codex da OpenAI também apresentam o ciclo do agente como um problema de orquestração que envolve prompts, ferramentas, execução e gestão de contexto.

A conclusão prática é simples: a próxima fase dos produtos de IA não será vencida apenas pela escolha do modelo mais forte. As equipas também vão precisar de uma melhor estratégia de contexto, permissões de ferramentas mais seguras, registos persistentes, avaliação repetível e controlo humano claro.

Plano de ação recomendado

Semana 1: Auditar o uso atual de agentes

Liste todos os agentes de IA ou assistentes de programação usados pela equipa. Inclua aplicações de desktop, agentes web, ferramentas de IDE, agentes de navegador, bots internos e scripts ligados a APIs de modelos. Para cada ferramenta, documente o que ela pode ler, o que pode escrever e se pode acionar ações externas.

Semana 2: Classificar tarefas por risco

Separe as tarefas em grupos de baixo, médio e alto risco.

As tarefas de baixo risco podem incluir formatação, resumo e geração de rascunhos. As tarefas de médio risco podem incluir edições de código, transformação de dados ou triagem de issues. As tarefas de alto risco incluem alterações em produção, tratamento de dados de clientes, trabalho de segurança, alterações de faturação e comunicação externa.

Semana 3: Criar um pequeno benchmark interno

Escolha 20 tarefas reais do último mês. Use-as como conjunto de benchmark. Inclua tarefas bem-sucedidas, tarefas falhadas, tarefas ambíguas e tarefas que exigiram correção humana.

Meça a taxa de conclusão, o tempo de revisão, a qualidade das evidências, o custo em tokens e a complexidade de reversão. Isto dá à equipa uma forma prática de comparar agentes em vez de depender de alegações de marketing.

Semana 4: Padronizar instruções e validação

Adicione instruções do repositório, modelos de tarefas, comandos de validação, expectativas de registo e condições de paragem. Torne o processo de revisão visível. Se um agente não conseguir mostrar o que alterou e como validou o resultado, a tarefa não deve ser considerada concluída.

FAQ

O que é o Claude Cowork?

Claude Cowork é o fluxo de trabalho em estilo de agente da Anthropic para encaminhar tarefas para o Claude nas superfícies suportadas, como desktop, web e mobile. Foi concebido para trabalho orientado a resultados, no qual o Claude pode usar ficheiros, ferramentas e fluxos de trabalho ligados, enquanto o utilizador revê e aprova os resultados importantes.

Porque é que o Claude Cowork em mobile e web é importante?

O acesso por mobile e web torna as tarefas de agentes mais fáceis de monitorizar e continuar fora do ambiente de desktop. A mudança maior é que o trabalho com agentes se torna mais assíncrono, o que significa que as equipas precisam de regras mais fortes para permissões, revisão, registos e

validação.

O que é um agent harness?

Um agent harness é o sistema em torno do modelo que gerencia contexto, ferramentas, estado, memória, logs, validação e aprovação humana. Ele transforma um modelo de gerador de texto em um sistema de fluxo de trabalho controlado.

A confirmação por celular é suficiente para a segurança de agentes?

Não. A confirmação por celular é útil, mas deve aprovar apenas ações com escopo claramente definido. Ações sensíveis, como enviar mensagens externas, alterar sistemas de produção, excluir dados ou mudar permissões, ainda devem exigir revisão explícita e regras de aprovação bem definidas.

Como uma equipe de programação deve usar agentes de IA com segurança?

Comece com tarefas restritas, limites claros de contexto, diffs revisáveis, saída de testes e condições de parada. Evite acesso amplo a repositórios, credenciais, dados de clientes ou sistemas de produção, a menos que exista um fluxo de aprovação sólido.

O que um agente deve retornar após uma tarefa de programação?

Uma saída útil de um agente de programação deve incluir os arquivos alterados, um resumo do diff, resultados de testes ou build, riscos conhecidos e qualquer trabalho de acompanhamento. Isso torna a revisão mais rápida e reduz a chance de erros ocultos.

Como as equipes podem comparar Claude Cowork, Codex, Cursor, Copilot e outros agentes?

Use tarefas reais do seu próprio fluxo de trabalho e execute cada ferramenta com os mesmos critérios de aceitação. Compare taxa de conclusão, custo de revisão, tipo de falha, evidências da saída, custo de tokens e esforço de rollback, em vez de julgar apenas com base em uma única demonstração.

Ferramentas relacionadas

• Claude Cowork: Fluxo de trabalho com agentes da Anthropic para atribuir tarefas ao Claude em dispositivos e superfícies de trabalho compatíveis.
• Claude Code: Agente de programação da Anthropic para fluxos de desenvolvimento baseados em terminal e IDE.
• OpenAI Codex: Agente de programação da OpenAI para criar, editar, revisar e entregar software com suporte de IA.
• GitHub Copilot: Assistente de programação com IA do GitHub para sugestões de código, chat, revisões e fluxos de trabalho de desenvolvedores.
• Cursor: Um ambiente de programação com IA focado em edição com conhecimento da base de código, chat e desenvolvimento de software no estilo agente.
• Amazon Bedrock AgentCore: Infraestrutura da AWS para criar, implantar e operar agentes de IA em escala.

Links relacionados

• Artigo original da NxCode: O artigo de origem que inspirou esta versão publicada em inglês.
• Página do produto Claude Cowork: Página oficial sobre os recursos do Claude Cowork, superfícies compatíveis e disponibilidade por plano.
• Use o Claude Cowork com segurança: Orientações de segurança da Anthropic sobre permissões, sessões remotas, injeção de prompt e supervisão humana.
• Disponibilidade geral do Amazon Bedrock AgentCore Harness: Anúncio da AWS sobre infraestrutura gerenciada de agent harness.
• [Harness Engineering for Self-Improvement](https://lilianweng.github.

io/posts/2026-07-04-harness/): a discussão de Lilian Weng sobre engenharia de harness e melhoria de sistemas de IA.

• OpenAI Codex Developers: página oficial para desenvolvedores do Codex como agente de programação.
• Unrolling the Codex Agent Loop: explicação técnica da OpenAI sobre como o Codex orquestra chamadas ao modelo, ferramentas, prompts e contexto.

Resumo

O Claude Cowork expandindo-se para desktop, web e dispositivos móveis é uma atualização de produto útil, mas seu significado real é mais profundo. Os agentes de IA estão se tornando sistemas persistentes de execução de tarefas, capazes de continuar trabalhando fora de uma única janela de chat.

Para as equipes, a resposta certa não é dar aos agentes liberdade ilimitada. O caminho mais seguro é a delegação controlada: escopo de tarefa restrito, permissões explícitas, saídas passíveis de revisão, logs persistentes, comandos de validação e aprovação humana para ações sensíveis.

Um bom harness de agente torna o agente mais confiável porque torna o trabalho visível e auditável. Comece com tarefas pequenas, meça o desempenho em fluxos de trabalho reais e amplie as permissões somente quando o processo de revisão for forte o suficiente.

O futuro do trabalho com agentes não está apenas em modelos mais inteligentes. Está em um melhor design de harness em torno dos modelos.