For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/es/articles/claude-cowork-mobile-web-agent-harness-2026.md.
La llegada de Claude Cowork al escritorio, la web y los dispositivos móviles es una actualización útil del producto, pero su verdadero signi...
La llegada de Claude Cowork a la web y a los dispositivos móviles no es solo un nuevo lugar donde hacer clic en un botón. Es una señal de que los agentes de IA están pasando de conversaciones breves en escritorio a sistemas de tareas de larga duración que pueden continuar trabajando en distintos dispositivos.
Para los equipos de producto, ingeniería y operaciones, la pregunta importante ya no es únicamente si un agente puede completar una tarea. La pregunta más difícil es si el agente puede mantener los límites adecuados mientras trabaja: qué archivos puede leer, qué herramientas puede usar, qué acciones requieren aprobación, qué evidencia debe devolver y cómo los humanos pueden revisar el resultado.
Este artículo explica el significado práctico de ese cambio. Se centra en el diseño del agent harness: la capa que rodea al modelo y que gestiona el contexto, las herramientas, los permisos, el estado, los registros, la validación y el control humano.
Página fuente original: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent Harness
La página fuente analizada mostraba una tarjeta SVG predeterminada del blog e imágenes del sitio y del pie de página, pero no capturas de pantalla del cuerpo del contenido, diagramas de flujo de trabajo, capturas de código ni imágenes de resultados que fueran claramente necesarias para el cuerpo del artículo. Para evitar insertar imágenes decorativas o no relacionadas, no se ha añadido ninguna imagen al cuerpo. Si una versión futura de la fuente incluye capturas del producto o diagramas, podrán insertarse cerca de las secciones correspondientes.
Claude Cowork ahora apunta a un flujo de trabajo en el que una misma tarea puede empezar en un dispositivo y continuar en otro. Un usuario puede asignar trabajo desde un escritorio, revisar el progreso desde un teléfono, responder a una solicitud mientras está lejos del escritorio y más tarde volver para revisar el resultado final.
Eso suena conveniente, pero también cambia el modelo de control. En una ventana de chat tradicional, el usuario normalmente permanece cerca de la interacción. Con un agente en segundo plano, el agente puede seguir usando contexto y herramientas mientras el usuario ya no está observando activamente cada paso.
Por eso, el acceso a agentes entre distintos dispositivos debe tratarse como algo más que una función del producto. Es una cuestión de diseño del flujo de trabajo. La tarea debe llevar consigo sus propios límites, requisitos de evidencia y reglas de aprobación, independientemente de si el usuario está en escritorio, web o móvil.
Un agent harness es la capa operativa que rodea al modelo. El modelo decide qué hacer a continuación, pero el harness determina qué puede hacer el
qué puede ver el modelo, qué herramientas puede usar, cómo se almacena el estado, cómo se registran las acciones, cómo se gestionan los fallos y cuándo un humano debe aprobar el siguiente paso.
Un modelo potente dentro de un entorno de control débil aún puede crear problemas graves. Puede leer los archivos equivocados, usar una herramienta fuera del alcance previsto, producir trabajo difícil de revisar o actuar antes de que el equipo haya validado el resultado.
Cuando un agente trabaja en varios dispositivos, el entorno de control importa aún más. La tarea puede comenzar en un ordenador de escritorio, continuar en una sesión remota, pedir confirmación en el móvil y luego generar un documento, un cambio de código o un mensaje. El modelo de permisos debe acompañar a la tarea, no al dispositivo.
Un buen entorno de control responde a preguntas prácticas antes de que la tarea comience:
El trabajo en segundo plano es útil. Un gerente de producto puede pedir a un agente que organice comentarios de clientes. Un ingeniero puede hacer que un agente inspeccione registros y sugiera una solución. Un fundador puede pedir un primer borrador de una actualización para inversores mientras viaja.
El riesgo es que un agente pueda seguir actuando después de que el usuario deje de prestar atención de cerca. Eso no es automáticamente inseguro, pero sí requiere límites mejores.
Los equipos deberían separar los permisos de los agentes en categorías claras:
| Categoría de permiso | Uso típico | Control recomendado |
|---|---|---|
| Leer archivos locales | Inspeccionar un repositorio, carpeta o conjunto de documentos | Limitar por carpeta o por alcance del espacio de trabajo |
| Leer aplicaciones conectadas | Obtener contexto de correo electrónico, documentos, CRM, gestores de incidencias o registros | Conceder acceso limitado y evitar datos sensibles por defecto |
| Escribir artefactos locales | Crear archivos, editar documentos o preparar cambios de código | Requerir diferencias revisables o historial de versiones |
| Enviar mensajes externos | Enviar correos, publicar contenido, abrir tickets o notificar a usuarios | Requerir confirmación humana explícita |
| Realizar acciones en producción o destructivas | Desplegar, eliminar, modificar facturación, cambiar permisos o ejecutar comandos irreversibles | Mantener obligatoria la ejecución humana |
La confirmación móvil puede acelerar el flujo de trabajo, pero no debería sustituir un diseño real de aprobación. Un toque en el teléfono debería confirmar una acción bien delimitada, no conceder acceso amplio a una tarea poco clara.
Toda tarea de un agente debería comenzar con una breve descripción de la tarea. Esa descripción debería incluir el objetivo, el contexto permitido, las herramientas permitidas, las acciones prohibidas, el resultado esperado, el método de validación y la condición de detención.
Esto es especialmente importante para tareas de programación. Una solicitud vaga como “arregla este problema” es demasiado amplia para un agente sin supervisión. Una versión más segura nombraría el problema, identificaría los archivos o módulos relevantes, especificaría el comando de prueba y exigiría un diff junto con notas de riesgo.
Los resultados de los agentes deberían incluir pruebas. Para tareas de código, eso significa diffs, resultados de pruebas, registros de compilación y una breve explicación del riesgo. Para tareas de investigación, significa enlaces a las fuentes, nivel de confianza y aspectos abiertos
preguntas. Para las tareas operativas, esto significa el plan de acción, los sistemas afectados, las notas de reversión y los puntos de aprobación.
El objetivo no es hacer que el agente escriba informes más largos. El objetivo es reducir el costo de revisión.
No todas las tareas necesitan el modelo más potente ni el presupuesto de razonamiento más amplio. Las tareas de bajo riesgo de formato, resumen y clasificación a menudo pueden ejecutarse con modelos más baratos o más rápidos. Los cambios de arquitectura, las migraciones, la depuración en producción y las tareas sensibles a la seguridad deben usar modelos más potentes y una revisión más estricta.
El enrutamiento de modelos debe formar parte del entorno de ejecución, no ser una ocurrencia tardía. Un equipo que enruta según el riesgo puede controlar el costo sin reducir la seguridad.
Los agentes pueden beneficiarse de una memoria de proyecto estable: reglas del repositorio, comandos habituales, convenciones de nomenclatura, notas de arquitectura y preferencias de estilo.
No deberían almacenar de manera informal secretos, credenciales, datos de clientes, suposiciones temporales ni conclusiones no verificadas. La memoria solo es útil cuando está curada. De lo contrario, se convierte en otra fuente de deriva oculta del contexto.
Los equipos no necesitan una plataforma compleja para empezar. Pueden comenzar con una plantilla de tareas sencilla y aplicarla de manera consistente.
task_goal: "Describe el resultado exacto que el agente debe producir."
allowed_context:
- "Enumera las carpetas, archivos, tickets, registros o documentos que el agente puede leer."
allowed_tools:
- "Enumera herramientas como terminal, navegador, gestor de incidencias, documentación o ejecutor de pruebas."
forbidden_actions:
- "No desplegar en producción."
- "No enviar mensajes externos."
- "No eliminar archivos ni datos."
validation:
- "Ejecuta las pruebas o comprobaciones pertinentes."
- "Incluye la salida de los comandos o explica por qué no se pudo ejecutar la validación."
expected_output:
- "Proporciona un diff, un resumen, los riesgos y los siguientes pasos."
human_approval_required_for:
- "Enviar mensajes"
- "Desplegar"
- "Eliminar datos"
- "Cambiar permisos"
stop_condition: "Detente cuando la salida esté lista para revisión humana o cuando falte el contexto necesario."
Para pequeñas correcciones de código, exige una rama local, un diff, la salida de las pruebas y una nota de riesgo. Para informes de investigación, exige fuentes y niveles de confianza. Para comprobaciones de lanzamiento, exige registros de compilación, comprobaciones fallidas e indicaciones de reversión. Para tareas con datos de clientes, exige una nota sobre el alcance de los datos y un plan de enmascaramiento. Para acciones en producción, el agente debe preparar el plan, pero una persona debe ejecutar o aprobar la acción.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Los equipos deberían evitar comparar agentes solo por demostraciones o primeras impresiones. Herramientas como Claude Cowork, Claude Code, OpenAI Codex, GitHub Copilot, Cursor y agentes internos deberían probarse con tareas reales, con el mismo presupuesto de tiempo y los mismos criterios de aceptación.
Entre las preguntas útiles de evaluación se incluyen:
¿revertir un resultado fallido?
Ejecuta cada tarea más de una vez. Los agentes son sistemas probabilísticos. Una sola ejecución impresionante no demuestra fiabilidad, y una sola mala ejecución no prueba que la herramienta sea inutilizable. Fíjate en la tasa de finalización, los tipos de fallo, el coste de revisión, el coste por resultado útil y el esfuerzo de recuperación.
Claude Cowork forma parte de un movimiento más amplio. Las herramientas de IA se están convirtiendo en sistemas de agentes que combinan modelos, herramientas, permisos, memoria, registros y evaluaciones.
Amazon Bedrock AgentCore muestra cómo las plataformas en la nube están avanzando hacia una infraestructura de agentes gestionada. Los debates de investigación sobre harness engineering apuntan a la misma idea: la capacidad del modelo importa, pero el sistema que rodea al modelo determina si puede usarse de forma fiable. Los materiales de OpenAI sobre Codex también plantean el bucle del agente como un problema de orquestación que implica prompts, herramientas, ejecución y gestión del contexto.
La conclusión práctica es simple: la próxima etapa de los productos de IA no se ganará solo eligiendo el modelo más potente. Los equipos también necesitarán una mejor estrategia de contexto, permisos de herramientas más seguros, registros persistentes, evaluaciones repetibles y un control humano claro.
Haz una lista de todos los agentes de IA o asistentes de programación que utiliza el equipo. Incluye aplicaciones de escritorio, agentes web, herramientas del IDE, agentes del navegador, bots internos y scripts conectados a APIs de modelos. Para cada herramienta, documenta qué puede leer, qué puede escribir y si puede activar acciones externas.
Separa las tareas en grupos de riesgo bajo, medio y alto.
Las tareas de bajo riesgo pueden incluir formato, resumen y generación de borradores. Las tareas de riesgo medio pueden incluir ediciones de código, transformación de datos o triaje de incidencias. Las tareas de alto riesgo incluyen cambios en producción, manejo de datos de clientes, trabajo de seguridad, cambios de facturación y comunicación externa.
Elige 20 tareas reales del último mes. Úsalas como conjunto de referencia. Incluye tareas exitosas, tareas fallidas, tareas ambiguas y tareas que requirieron corrección humana.
Mide la tasa de finalización, el tiempo de revisión, la calidad de la evidencia, el coste en tokens y la complejidad de reversión. Esto le da al equipo una forma práctica de comparar agentes en lugar de depender de afirmaciones de marketing.
Añade instrucciones del repositorio, plantillas de tareas, comandos de validación, expectativas de registro y condiciones de detención. Haz visible el proceso de revisión. Si un agente no puede mostrar qué cambió y cómo validó el resultado, la tarea no debe considerarse completada.
Claude Cowork es el flujo de trabajo de estilo agente de Anthropic para delegar tareas a Claude a través de superficies compatibles como escritorio, web y móvil. Está diseñado para trabajo orientado a resultados, donde Claude puede usar archivos, herramientas y flujos de trabajo conectados, mientras el usuario revisa y aprueba los resultados importantes.
El acceso desde móvil y web facilita supervisar y continuar las tareas de agentes fuera del entorno de escritorio. El cambio más importante es que el trabajo con agentes se vuelve más asíncrono, lo que significa que los equipos necesitan reglas más sólidas para permisos, revisión, registros y
validación.
Un arnés de agente es el sistema que rodea al modelo y que gestiona el contexto, las herramientas, el estado, la memoria, los registros, la validación y la aprobación humana. Convierte un modelo, de ser un generador de texto, en un sistema de flujo de trabajo controlado.
No. La confirmación móvil es útil, pero solo debería aprobar acciones claramente delimitadas. Las acciones sensibles, como enviar mensajes externos, modificar sistemas de producción, eliminar datos o cambiar permisos, deben seguir requiriendo una revisión explícita y reglas de aprobación bien definidas.
Empiece con tareas acotadas, límites claros de contexto, diferencias revisables, resultados de pruebas y condiciones de detención. Evite el acceso amplio a repositorios, credenciales, datos de clientes o sistemas de producción, a menos que exista un sólido flujo de aprobación.
Un resultado útil de un agente de programación debería incluir los archivos modificados, un resumen del diff, los resultados de las pruebas o de la compilación, los riesgos conocidos y cualquier trabajo de seguimiento. Esto acelera la revisión y reduce la probabilidad de errores ocultos.
Use tareas reales de su propio flujo de trabajo y ejecute cada herramienta con los mismos criterios de aceptación. Compare la tasa de finalización, el costo de revisión, el tipo de fallo, la evidencia del resultado, el costo en tokens y el esfuerzo de reversión, en lugar de basarse solo en una única demostración.
io/posts/2026-07-04-harness/): La discusión de Lilian Weng sobre la ingeniería de harness y la mejora de los sistemas de IA.
Claude Cowork expandiéndose entre escritorio, web y móvil es una actualización útil del producto, pero su verdadero significado es más profundo. Los agentes de IA se están convirtiendo en sistemas de tareas persistentes que pueden seguir trabajando fuera de una sola ventana de chat.
Para los equipos, la respuesta correcta no es dar a los agentes una libertad ilimitada. El camino más seguro es la delegación controlada: alcance de tareas limitado, permisos explícitos, resultados revisables, registros persistentes, comandos de validación y aprobación humana para acciones sensibles.
Un buen harness de agentes hace que sea más fácil confiar en el agente porque hace que el trabajo sea visible y auditable. Empieza con tareas pequeñas, mide el rendimiento en flujos de trabajo reales y amplía los permisos solo cuando el proceso de revisión sea lo bastante sólido.
El futuro del trabajo con agentes no consiste solo en modelos más inteligentes. Consiste en un mejor diseño del harness alrededor de los modelos.
Empieza con una sola frase y obtén un sitio completo en minutos.
