https://thedotnetblog.com/pl/tags/approvals/Articles, tutorials and insights from the .NET community.Hugopl@thedotnetblog (The .NET Blog)@thedotnetblogSat, 11 Jul 2026 00:00:00 +0000https://thedotnetblog.com/pl/news/emiliano-montesdeoca/agent-harness-safe-data-access-patterns/Sat, 11 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pl/news/emiliano-montesdeoca/agent-harness-safe-data-access-patterns/Dostęp do plików, zatwierdzenia i projekt pamięci to praktyczna triada dla godnego zaufania zachowania agentów w produkcji.<p>Oryginalne źródło: <a href="https://devblogs.microsoft.com/agent-framework/agent-harness-working-with-your-data-safely/">Agent Harness: Working with your data, safely</a></p> <p>To jeden z bardziej użytecznych wpisów inżynieryjnych o agentach w tym roku, ponieważ odrzuca powszechną pułapkę autonomii na pokaz. Zamiast tego skupia się na tym, jak agenci powinni operować wokół prawdziwych danych użytkownika i rzeczywistych konsekwencji.</p> <p>Trzy bloki konstrukcyjne podkreślone tutaj są dokładnie właściwe.</p> <ul> <li><strong>Dostęp do plików</strong> daje agentom użyteczne ugruntowanie w danych należących do użytkownika.</li> <li><strong>Bramkowanie zatwierdzeniami</strong> zapobiega cichemu wykonywaniu działań o konsekwencjach.</li> <li><strong>Trwała pamięć</strong> unika powtarzalnych interakcji bez poświęcania kontroli.</li> </ul> <p>Większość zespołów przesadnie inwestuje w szerokość narzędzi i niedoinwestowuje w semantykę uprawnień. To odwrotność właściwego podejścia. Agent z dziesięcioma narzędziami i słabymi granicami zatwierdzeń jest mniej wartościowy niż agent z trzema narzędziami i przewidywalnymi punktami kontroli.</p> <p>Najlepszym praktycznym wzorcem w tym artykule jest <strong>warstwowa strategia zatwierdzeń</strong>:</p> <ul> <li><strong>Zawsze wymagaj zatwierdzenia</strong> dla narzędzi wysokiego ryzyka, takich jak transakcje czy operacje niszczące.</li> <li><strong>Automatycznie zatwierdzaj</strong> odczyty niskiego ryzyka, aby zachować płynność.</li> <li><strong>Używaj zakresowych stałych zatwierdzeń</strong> dla powtarzalnych, zaufanych działań w ramach sesji.</li> </ul> <p>Tworzy to zdrowy gradient ryzyka. Użytkownicy nie są przerywani dla nieszkodliwych odczytów, ale wciąż są w pętli, gdy konsekwencje stają się kosztowne lub nieodwracalne.</p> <p>Podoba mi się też wyraźny podział między <strong>pamięcią plikową</strong> a <strong>pamięcią Foundry</strong>. Zespoły powinny przestać próbować zmuszać jeden model pamięci do rozwiązywania każdego problemu. Surowe, jawne artefakty plikowe są doskonałe dla widocznych dla użytkownika stanów, takich jak raporty i listy obserwowane. Ekstrakcja pamięci na poziomie faktów jest lepsza dla preferencji i kontekstu konwersacyjnego. Połączenie obu daje lepsze wyniki niż udawanie, że którykolwiek z nich jest wystarczający.</p> <p>Moje stanowcze zdanie: przyszłość jakości agentów będzie mierzona mniej sprytnymi promptami, a bardziej <strong>ergonomią bezpieczeństwa</strong>. Jeśli twoje prośby o zatwierdzenie są hałaśliwe, użytkownicy klikają je na ślepo. Jeśli granice pamięci są niejasne, użytkownicy przestają ufać asystentowi. Jeśli domyślne uprawnienia dostępu do danych są permisywne, zespoły bezpieczeństwa zamkną projekt.</p> <p>Dla zespołów .NET i Python przyjmujących ten wzorzec, kluczowym ruchem jest <strong>traktowanie callbacków polityk i reguł zatwierdzania jako podstawowej logiki biznesowej</strong>, wersjonowanej i testowanej jak każdy inny krytyczny kod. Nie zostawiaj ich jako ad-hoc lambd pogrzebanych w przykładach.</p> <h2 id="konkluzja">Konkluzja</h2> <p>Systemy agentowe, które zdobywają zaufanie, to nie te, które robią najwięcej. To te, które robią dokładnie to, co zamierzał użytkownik, ni mniej, ni więcej, z jasnymi punktami przerwania, gdy ryzyko wzrasta.</p> <p>To jest różnica między imponującym demem a oprogramowaniem, któremu ludzie są skłonni powierzyć prawdziwą pracę.</p>