Microsoft Mage-VL-Cowork na Hugging Face rzuca wyzwanie desktopowym agentom działającym wyłącznie przez GUI
Microsoft udostępnił Mage-VL-Cowork, desktopowego agenta o 4 miliardach parametrów, który według deklaracji osiąga 66,0% skuteczności realizacji zadań, łącząc sterowanie ekranem z wykonywaniem poleceń w terminalu. Wpis microsoft/Mage-VL-Cowork · Hugging Face opisuje model językowo-wizyjny, który przetwarza obrazy i tekst łącznie. Jego główna teza podważa dobrze znane podejście do automatyzacji pracy na komputerze: wykonywanie każdej operacji za pomocą ruchów myszy, wprowadzania tekstu z klawiatury i zrzutów ekranu.
Microsoft twierdzi, że model uczy się, kiedy używać kontrolek graficznych, a kiedy manipulować plikami za pomocą kodu. Jego hybrydowy model agenta jest dostępny na licencji Apache-2.0. To wydanie tworzy konkretny punkt odniesienia dla badań, choć przedstawione deklaracje dotyczące wydajności pozostają tu zgłoszone przez dewelopera, a nie niezależnie potwierdzone.
Istotne porównanie dotyczy strategii wykonania w takim samym stopniu jak rozmiaru modelu. Microsoft zestawia ten model z większymi systemami, w tym Qwen3.6-27B, argumentując, że lepsze środowiska szkoleniowe usprawniają kompaktowych agentów. Dla deweloperów i nabywców korporacyjnych pytanie jest praktyczne: czy nauczenie agenta wyboru narzędzi zapewnia użyteczną efektywność wykraczającą poza kontrolowane demonstracje?
Microsoft Mage-VL-Cowork na Hugging Face stawia hybrydowe wykonywanie działań w centrum uwagi
Wydanie umieszcza wybór działania wewnątrz kompaktowego modelu, czyniąc strategię wykonania częścią ocenianej zdolności.
Graficzny interfejs użytkownika, czyli GUI, udostępnia kontrolki aplikacji przez widoczne okna, menu i przyciski. Terminal udostępnia polecenia i skrypty. Oba mogą zmieniać stan komputera, lecz oferują różne sposoby realizacji tego samego zadania.
Rozważmy prośbę dotyczącą arkusza kalkulacyjnego, obejmującą formatowanie, obliczenia i zapisanie gotowego pliku. Agent graficzny może zaznaczać komórki, otwierać menu i wprowadzać formuły. Agent zdolny do używania kodu może potencjalnie bezpośrednio edytować skoroszyt, a następnie sprawdzić jego wyrenderowany wygląd.
Ten przykład ilustruje różnicę, lecz nie wskazuje uniwersalnego zwycięzcy. Niektóre operacje zależą od tego, co aplikacja aktualnie wyświetla. Inne zależą od ustrukturyzowanych informacji, do których skrypt może uzyskać dostęp bez nawigowania po menu.
Wydanie zachęca zatem oceniających do sprawdzenia, czy agent wybiera odpowiednią drogę. Ukończenie zadania ma znaczenie, ale ważne jest również rozpoznanie, kiedy obrana ścieżka tworzy niepotrzebną pracę.
To istotna zmiana w jednostce analizy. Zrzut ekranu pokazuje, co agent widzi. Wywołanie narzędzia pokazuje, jak działa. Żadne z nich samo w sobie nie wyjaśnia, czy wybrał rozsądną metodę dla celu użytkownika.
Dla zespołu produktowego to rozróżnienie wpływa na architekturę. Czy asystent desktopowy powinien naśladować ludzką interakcję przez całe zadanie? Czy powinien przekazywać ustrukturyzowaną pracę kodowi? Jak powinien uzgadniać zmiany wprowadzone przez te różne kanały?
Mage-VL-Cowork daje badaczom udostępniony model, wokół którego mogą badać te pytania. Nie rozstrzyga ich dla każdej aplikacji ani środowiska wdrożeniowego.
Dostępność zmienia także dyskusję o dowodach. Zewnętrzni deweloperzy mogą sprawdzić implementację i spróbować ją odtworzyć, zamiast polegać wyłącznie na opowiedzianej demonstracji. Ta możliwość ma znaczenie jeszcze przed pojawieniem się niezależnych wyników.
Właściwa interpretacja microsoft/Mage-VL-Cowork · Hugging Face jest zatem węższa niż „małe modele rozwiązały pracę na komputerze”. Microsoft dostarczył możliwą do zbadania implementację i konkretną deklarację wydajności.
Dla użytkowników to rozróżnienie oddziela wydanie badawcze od gotowego asystenta. Model nadal potrzebuje dostępu do aplikacji, środowiska wykonawczego i interfejsu produktowego. Te otaczające go decyzje określają, co użytkownik może faktycznie delegować.
Bezpośrednim wkładem wydania jest jaśniejsza propozycja eksperymentalna: kompaktowi agenci desktopowi powinni być oceniani pod kątem tego, jak łączą dostępne działania. Liczba parametrów pozostaje istotna, ale nie wyjaśnia całego wyniku.
Twórcy agentów działających wyłącznie przez GUI stają przed bardziej konkretnym pytaniem o efektywność
Wyniki Microsoftu wywierają presję na strategie wykonania oparte wyłącznie na interfejsie, nie dowodząc przy tym, że mniejsze modele zawsze przewyższają większe.
Firmowe porównanie agentów desktopowych podaje dla Mage-VL-Cowork wynik 66,0%, dla Qwen3.6-27B 63,9%, a dla Muse Glimmer-30B 65,9%. SCALECUA-Qwen3.5-9B uzyskuje wyższy wynik 68,7% w tej samej prezentacji.
Liczby te należą do porównania Microsoftu, a nie do niezależnie znormalizowanej oceny przeprowadzonej na potrzeby tego artykułu. Stanowią powód, by zbadać to podejście, pozostawiając jednocześnie miejsce na różnice w ustawieniach wykonania.
Presja spada przede wszystkim na zespoły, które traktują widoczną interakcję jako domyślną drogę dla każdej operacji. Mają one teraz konkretną alternatywę do oceny.
Większy model może trafniej rozumować na temat trudnego ekranu. Ta przewaga nie sprawia automatycznie, że wielokrotne nawigowanie po menu jest najlepszym sposobem modyfikacji ustrukturyzowanego dokumentu.
Z drugiej strony dostęp do terminala nie eliminuje potrzeby oceny wizualnej. Skrypt może poprawnie zapisać plik, którego układ nadal nie spełnia prośby użytkownika. Użyteczne porównanie musi uwzględniać gotowy artefakt.
Zmienia to zakres demonstracji, których kupujący powinni wymagać od dostawców. Udane nagranie potwierdza, że dany przepływ pracy może zadziałać w pokazanych warunkach. Nie potwierdza, jak często ten przepływ pracy odnosi sukces.
Podobnie krótsza sekwencja interakcji jest informacyjna, lecz niewystarczająca. Agent może ograniczyć widoczne działania, przenosząc znaczną część pracy do skryptu. Powstały artefakt nadal wymaga sprawdzenia.
Konsekwencją konkurencyjną jest ciężar oceny. Zespoły broniące projektów opartych wyłącznie na GUI powinny wyjaśnić, gdzie takie projekty zapewniają lepszą kompatybilność, kontrolę lub niezawodność. Zespoły promujące hybrydowe wykonywanie powinny pokazać, gdzie dodatkowy dostęp przynosi mierzalne korzyści.
Żadna ze stron nie może rozstrzygnąć tej dyskusji wyłącznie liczbą parametrów. Rozmiar modelu niewiele mówi o przygotowaniu aplikacji, jakości weryfikacji lub ilości pracy ukrytej w narzędziu.
Dla nabywców korporacyjnych zwiększa to znaczenie wyboru przepływu pracy. Asystent do wizualnej kontroli projektu ma inne wymagania niż taki, który wielokrotnie aktualizuje ustrukturyzowane skoroszyty.
Pracownicy umysłowi stają przed powiązanym rozróżnieniem między znajdowaniem informacji a działaniem na ich podstawie. Osobista baza wiedzy dotyczy informacji dostępnych dla zadania. Wykonywanie działań na komputerze dotyczy sposobu, w jaki agent zmienia aplikacje i pliki.
Użyteczny asystent potrzebuje jasności co do obu tych odpowiedzialności. Lepsze wykonanie nie zrekompensuje błędnego dokumentu źródłowego. Lepsze wyszukiwanie nie gwarantuje, że agent zapisze żądane zmiany.
Wydanie Microsoftu wzmacnia argument za porównywaniem kompletnych przepływów pracy. Istotny wynik obejmuje prawidłowe dane wejściowe, odpowiednią drogę działania i zweryfikowany rezultat.
Takie ujęcie daje konkurentom konkretny cel odpowiedzi. Mogą wykazać lepsze wyniki w dopasowanych warunkach, zamiast odpowiadać na wydanie kompaktowego modelu zapowiedzią większego modelu.
Lepsze demonstracje poprzedzają mniejszy model
Propozycja szkoleniowa traktuje środowisko działania nauczyciela jako część tego, czego uczy się uczeń.
Microsoftowy przepis na szkolenie opisuje trzy powiązane składniki: dopracowane środowiska nauczyciela, wielokrotnego użytku generowanie zadań i szkolenie etapowe. Środowisko obejmuje otaczający system narzędzi, promptów i wsparcia wykonawczego.
Mage-CUA-Forge, system generowania zadań, miał według doniesień stworzyć 293 806 zadań obejmujących 6915 umiejętności. Program nauczania rozwija interakcję wizualną i kompetencje terminalowe przed ich połączeniem przez dostrajanie nadzorowane, które uczy się na demonstracjach, oraz uczenie ze wzmocnieniem, które korzysta ze sprzężenia zwrotnego opartego na wynikach.
Znaczenie analityczne wynika ze sposobu, w jaki te elementy się łączą. Uczeń szkolony na demonstracjach otrzymuje przykłady zachowania, w tym wybory nauczyciela dotyczące narzędzi.
Jeśli przykłady te zawierają niepotrzebne objazdy, ich kopiowanie może je zachować. Lepsze odpowiedzi nauczyciela nie muszą oznaczać lepszych sekwencji działań ucznia.
Sprawia to, że przygotowanie nauczyciela staje się kwestią inżynieryjną, a nie drobnym szczegółem szkolenia. Nakładanie się narzędzi, niespójne interfejsy i brak wsparcia dla aplikacji mogą komplikować nauczane zachowanie.
Wniosek nie jest taki, że każdy agent powinien otrzymać mniej narzędzi. Chodzi o to, że dostępność narzędzi wymaga celu. Wiele sposobów wykonania tej samej czynności może zwiększać elastyczność, jednocześnie czyniąc demonstracje mniej spójnymi.
To rozróżnienie ma znaczenie dla kompaktowych modeli, ponieważ pożądane zachowanie obejmuje więcej niż wygenerowanie poprawnego polecenia. Model musi rozpoznać sytuację, wybrać drogę, wykonać ją i ocenić, co się wydarzyło.
Generowanie zadań zorientowane na przepływ pracy rodzi powiązane pytanie o zakres szkolenia. Ponowne używanie procesu konstruowania zadań może ułatwiać tworzenie dodatkowych przykładów. Może też sprawiać, że przykłady przypominają założenia osadzone w tym procesie.
Kluczowym pytaniem ewaluacyjnym staje się różnorodność, a nie surowa liczba. Czy generowane zadania różnią się w istotny sposób? Czy ujawniają różne stany aplikacji i warunki awarii? Czy wymagają od agenta zrewidowania początkowego podejścia?
Etapowy program nauczania oferuje spójną odpowiedź na kolejny problem szkoleniowy: łączenie umiejętności, zanim któraś z nich działa niezawodnie. Oddzielne rozwijanie kanałów działania daje podstawę do badania ich późniejszej integracji.
Sama struktura programu nauczania nie dowodzi jednak, dlaczego końcowy model się poprawia. Silniejsze dowody izolowałyby poszczególne zmiany przy zachowaniu stałości innych warunków. W przeciwnym razie wzrosty mogą odzwierciedlać kilka wzajemnie oddziałujących decyzji.
Dla deweloperów analizujących Microsoft Mage-VL-Cowork wyjaśniony przez pryzmat jego projektu szkoleniowego, przydatnym wnioskiem jest dyscyplina eksperymentalna. Jakość demonstracji, konstrukcja środowiska i optymalizacja modelu zasługują na oddzielną analizę.
Zmienia to także praktyczne znaczenie określenia „efektywny mały model”. Kompaktowe wnioskowanie może zależeć od znacznego przygotowania na wcześniejszym etapie. Efektywność wdrożenia i prostota szkolenia to odmienne twierdzenia.
Wydanie jest interesujące właśnie dlatego, że przedstawia to przygotowanie jako część całej historii. Zgłoszony wynik zachęca do analizy procesu nauczania obok analizy końcowego modelu.
Mniej wywołań ma znaczenie tylko wtedy, gdy praca nadal zostaje wykonana
Wzrost efektywności staje się użyteczny, gdy zachowuje realizację zadania i wytrzymuje pomiar w całym przepływie pracy.
Microsoft zgłasza o 13,0% mniej wywołań modelu i o 25,4% mniej tokenów wyjściowych po uczeniu ze wzmocnieniem online. Tokeny to jednostki tekstu, które model przetwarza lub generuje. Te redukcje porównują etapy szkolenia, a nie potwierdzają oszczędności względem każdego konkurencyjnego systemu.
Kierunek jest zachęcający, ponieważ firma zgłasza lepszą realizację zadań przy jednoczesnym ograniczeniu interakcji. Mimo to długość odpowiedzi i liczba wywołań opisują jedynie część pracy agenta desktopowego.
Wywołanie modelu może uruchomić niedrogie sprawdzenie lub długi skrypt. Krótsza odpowiedź może towarzyszyć powolnemu uruchamianiu aplikacji. Żadna z tych miar nie określa bezpośrednio, jak długo czeka użytkownik.
Dlatego zgłaszane redukcje powinny pozostać powiązane z definicjami, według których je zmierzono. Są dowodem dotyczącym zachowania interakcji w ramach opisanej oceny, a nie pełnym opisem kosztów operacyjnych.
Rozróżnienie to wpływa również na wdrożenie lokalne. Mniejsza ilość generowanego tekstu może ograniczyć część pracy inferencyjnej, lecz rzeczywista responsywność zależy od sprzętu i otaczającego go oprogramowania.
Ocena wdrożenia wymaga zatem obserwacji na docelowej maszynie. Powinna uwzględniać działanie aplikacji, ładowanie modelu oraz czas potrzebny na sprawdzenie rezultatów.
Materiały demonstracyjne Microsoft obejmują edycję arkuszy kalkulacyjnych za pomocą Python oraz edycję obrazów łączącą pracę graficzną z weryfikacją w terminalu. Przykłady te pokazują, dlaczego różne ścieżki działania zasługują na ocenę.
Przypadek arkusza kalkulacyjnego reprezentuje ustrukturyzowane przetwarzanie. Przypadek obrazu przedstawia pracę, w której interakcja wizualna pozostaje użyteczna, po czym następuje osobne sprawdzenie zapisanego artefaktu.
Żadna z demonstracji nie dowodzi średniej poprawy w niepowiązanych zadaniach. Wybrane przykłady pomagają wyjaśnić mechanizm, natomiast szersze testy określają, jak konsekwentnie ten mechanizm pomaga.
Osoba oceniająca powinna także odróżniać podjętą pracę od pracy zakończonej sukcesem. Agent, który zatrzymuje się wcześnie, może wydawać się wydajny. Model, który poświęca więcej czasu na naprawienie błędu, może wyglądać na nieefektywny mimo dostarczenia użytecznego wyniku.
Nie oznacza to, że nieudane zadania powinny zniknąć z raportowania. Ich zużycie zasobów należy do obrazu operacyjnego. Istotne jest zapewnienie wystarczającej ilości szczegółów, by zrozumieć tę zależność.
Przegląd użytkownika tworzy kolejną warstwę. Szybkie autonomiczne wykonanie nadal może wymagać później rozległej kontroli. Jeśli przegląd trwa dłużej niż ręczne wykonanie zadania, praktyczna korzyść maleje.
Dla nabywców porównujących Microsoft Mage-VL-Cowork z Qwen najsilniejszy materiał dowodowy łączyłby wyniki zadań z czasem realizacji i wymaganiami dotyczącymi przeglądu. Porównanie parametrów nie może zastąpić takiego zapisu.
To samo dotyczy pilotaży wewnętrznych. Zespoły powinny powstrzymać się od traktowania krótszego transkryptu jako automatycznego wzrostu produktywności. Doświadczenie użytkownika określają rezultat, jego poprawność oraz wysiłek potrzebny, by mu zaufać.
Zgłaszane przez Microsoft redukcje sprawiają, że twierdzenie o wydajności warto przetestować. Nie eliminują jednak potrzeby mierzenia pracy otaczającej inferencję.
Benchmark potwierdza ograniczone twierdzenie o niezawodności na komputerach stacjonarnych
Wynik sukcesu zadań w kontrolowanych warunkach stanowi użyteczny punkt odniesienia, lecz nie poświadcza niezawodnego działania na codziennych komputerach stacjonarnych.
Microsoft informuje o ocenie na 361 niewykorzystanych wcześniej zadaniach z limitem 50 kroków. Główny wynik to średnia z dwóch uruchomień. Warunki te definiują rezultat i powinny towarzyszyć porównaniom.
Benchmark OSWorld ocenia zadania w wykonywalnych środowiskach komputerowych. Jego opiekunowie dopuszczają wyłączenie zadań Google Drive, ponieważ ich konfiguracja może napotykać zależności sieciowe.
Ten kontekst ma znaczenie, ponieważ bez niego wyłączenia mogą wyglądać na arbitralne. Podzbiór ma udokumentowane uzasadnienie. Nadal należy go ujawniać przy porównywaniu wyników.
Słowo „Verified” również wymaga ostrożnej interpretacji. Określa ono wersję benchmarku. Nie oznacza, że zgłoszony wynik każdego modelu otrzymał niezależne potwierdzenie.
W przypadku tego wydania uzasadnione jest stwierdzenie, że Microsoft raportuje wysoką wydajność w opisanej przez siebie konfiguracji. Niezależne odtworzenie wzmocniłoby zaufanie do tego wyniku.
Różnica między wydajnością benchmarkową a niezawodnością w miejscu pracy ma kilka wymiarów. Zadanie służbowe może rozpoczynać się od nieoczekiwanego stanu aplikacji. Może też zawierać wymagania, których osoba oceniająca nie potrafi w pełni zakodować.
Na przykład dokument może wymagać zachowania konwencji formatowania, którą użytkownik uznaje za oczywistą. Plik poprawny technicznie nadal może naruszać to oczekiwanie.
Dostęp hybrydowy rodzi kolejne pytanie o koordynację. Bezpośrednia edycja pliku i otwarta aplikacja mogą reprezentować różne stany tej samej pracy. Agent musi rozpoznać, który stan zawiera autorytatywne zmiany.
Jest to ogólny problem wdrożeniowy, a nie udokumentowany wskaźnik awarii Mage-VL-Cowork. Wydanie nie określa, jak często takie konflikty występują w zwykłym użyciu.
Odzyskiwanie po błędach również zasługuje na osobną uwagę. Ukończenie przygotowanego zadania różni się od rozpoznania, że operacja pośrednia zakończyła się niepowodzeniem. Użyteczny asystent potrzebuje zachowania dla obu sytuacji.
Agent może dokonać nieprawidłowej edycji, zauważyć problem i skutecznie go naprawić. Może też utworzyć pozornie poprawny artefakt, jednocześnie po cichu pomijając wymaganie.
Zbiorcze wskaźniki sukcesu kompresują te rozróżnienia. Pomagają porównywać systemy, ale nie ujawniają każdego trybu awarii, który zespół produktowy musi zrozumieć.
Granice uprawnień tworzą kolejne praktyczne wymaganie. Możliwość modyfikowania plików powinna odpowiadać zakresowi zamierzonemu przez użytkownika. Sam wynik benchmarku nie określa tych decyzji produktowych.
Działanie lokalne również samo w sobie nie zapewnia prywatności. Wdrożenie może wykonywać model lokalnie, podczas gdy aplikacje nadal komunikują się z usługami zewnętrznymi. Twierdzenia dotyczące przetwarzania danych wymagają zbadania całego systemu.
W przypadku wdrożeń korporacyjnych nierozstrzygniętym pytaniem jest zatem dopasowanie operacyjne. Które przepływy pracy mogą tolerować błędy? Które wymagają przeglądu? Które działania potrzebują wyraźnego kroku potwierdzenia?
Pytania te nie umniejszają wyniku badań. Wskazują dodatkowe dowody potrzebne przed przekształceniem modelu ocenionego benchmarkiem w asystenta o znaczącej odpowiedzialności.
Następne są niezależne odtworzenie, wyniki sprzętowe i nieznane przepływy pracy
Kolejne użyteczne dowody powinny w tej kolejności testować odtwarzalność, praktyczność wdrożenia oraz możliwość przeniesienia na zadania wykraczające poza przygotowane przykłady z wydania.
Pierwszym sygnałem jest niezależna próba odtworzenia raportowanego benchmarku w odpowiadających warunkach. Zgodność ma znaczenie, ponieważ zmieniony podzbiór zadań lub budżet działań może zmienić interpretację.
Odtworzenie powinno opisywać wersję modelu, środowisko wykonawcze, dozwolone narzędzia i zasady zatrzymania. Powinno również zachować wystarczające dowody na poziomie zadań, aby badać rozbieżności.
Jeśli zewnętrzny zespół uzyska porównywalny wynik, zaufanie do głównego rezultatu wzrasta. Jeśli jego wynik się różni, wartościowym kolejnym krokiem jest ustalenie, który warunek wyjaśnia różnicę.
Proces ten zwiększyłby użyteczność wydania nawet bez uzyskania identycznego wyniku. Odtwarzalność obejmuje zrozumienie warunków, w których dany rezultat pozostaje prawdziwy.
Drugim sygnałem jest zmierzona wydajność na realistycznym lokalnym sprzęcie. Ujęcie Microsoft dotyczące działania na urządzeniu wymaga dowodów dotyczących maszyn, na których deweloperzy spodziewają się wdrażać model.
Użyteczne raportowanie obejmowałoby zużycie pamięci, czas ukończenia zadania oraz responsywność podczas pracy z aplikacjami. Powinno określać konfigurację modelu, zamiast traktować „działa lokalnie” jako pełny opis.
Wykonanie o obniżonej precyzji, które przechowuje wartości modelu przy użyciu mniejszej liczby bitów, zasługuje na osobną ocenę, jeśli jest stosowane. Mniejsze wykorzystanie pamięci jest użyteczne tylko wraz z dowodami na zachowanie zdolności do wykonywania zadań.
Jeśli typowe konfiguracje wdrożeniowe zachowują użyteczną skuteczność ukończenia i akceptowalną responsywność, argument za lokalnym agentem staje się silniejszy. Jeśli wymagają wyspecjalizowanego sprzętu lub obniżają niezawodność, grono odbiorców pozostaje węższe.
Trzecim sygnałem jest wydajność w nieznanych przepływach pracy. Oznacza to zadania poza wybranymi demonstracjami oraz warianty podważające założenia dotyczące stanu aplikacji.
Informacyjny test mógłby zmienić strukturę pliku lub rozpocząć pracę przy innym układzie okien. Mógłby również ocenić, czy agent rozpoznaje brakujące informacje.
Celem nie jest tworzenie arbitralnych przeszkód. Chodzi o zmierzenie, czy wyuczona strategia wykonania przenosi się na sytuacje, w których pulpit użytkownika różni się od przygotowanego środowiska.
Silne przenoszenie wspierałoby argument, że zachowanie hybrydowe jest zdolnością wielokrotnego użytku. Słabe przenoszenie sugerowałoby, że niektóre raportowane korzyści silnie zależą od znajomej konstrukcji zadań.
Sygnały te dają również konkurentom jasne sposoby odpowiedzi. Systemy wyłącznie GUI mogą wykazać przewagi w dopasowanych warunkach. Inne systemy hybrydowe mogą pokazać lepszy wybór działań lub skuteczniejsze odzyskiwanie po błędach.
Dla nabywców wynikające z tego dowody powinny wyznaczać granice przepływów pracy, a nie uniwersalny ranking. Najlepszy wybór do powtarzalnej pracy z skoroszytami może różnić się od najlepszego wyboru do kontroli wizualnej.
Wydanie zasługuje na uwagę, ponieważ udostępnia konkretną propozycję do zewnętrznego testowania. Jego wartość wzrośnie, jeśli inne zespoły będą mogły wyjaśnić, odtworzyć i rozszerzyć raportowane zachowanie.
Przed delegowaniem przepływu pracy wybierz reprezentatywne zadanie i określ, co musi zachować poprawny rezultat. Porównaj ukończenie, czas realizacji i wysiłek związany z przeglądem w dostępnych podejściach. Zachowuj dowody pośrednie, aby można było analizować błędy zamiast odrzucać je jako odosobnione pomyłki. W przypadku Microsoft Mage-VL-Cowork priorytetem powinno być niezależne odtworzenie i zmierzone wykonanie lokalne, zanim obietnica działania na urządzeniu zostanie uznana za potwierdzoną. Następnie rozszerz ocenę na nieznane pliki i stany aplikacji. Użyteczna decyzja jest konkretna: które zadania ten model może wykonywać wystarczająco niezawodnie, aby zmniejszyć Twoje obciążenie pracą? Zacznij od tego pytania i wymagaj, aby ukończona praca na nie odpowiadała.
