· · 3 minut czytania

Dlaczego warstwowy projekt Microsoft Agent Framework naprawdę ma znaczenie

Nowe wyjaśnienie warstwowego SDK Microsoft Agent Framework to coś więcej niż rozmowa o architekturze. Pokazuje, jak Microsoft chce, by deweloperzy przechodzili od prostych pętli do gotowej do produkcji orkiestracji, nie wyrzucając wszystkiego do kosza.

Agent Framework AI .NET Architecture Developer Tools
Ten post jest dostępny również w:English, Català, Español, Deutsch, Français, Português, Italiano, 日本語, 中文, 한국어, Русский, हिन्दी, Türkçe, العربية, Bahasa Indonesia, Nederlands

*Ten wpis został przetłumaczony automatycznie. Aby zobaczyć oryginał, kliknij tutaj.

Ogłoszenia frameworków zwykle zaczynają się od funkcji.

To ogłoszenie zaczęło się od filozofii projektowania i właśnie dlatego, moim zdaniem, ma znaczenie.

Nowe wyjaśnienie, jak Microsoft Agent Framework jest zbudowany wokół agent loops, workflows i harnesses, daje nam dużo lepszy sygnał niż kolejna lista funkcji. Pokazuje, jak zespół spodziewa się, że będą rosły prawdziwe aplikacje.

A dla każdego, kto buduje agentów w .NET, to właśnie jest najcenniejsza część.

Większość aplikacji agentowych bardzo szybko przerasta swoją pierwszą architekturę

Zaczynasz od wywołania modelu.

Potem dodajesz narzędzia.

Potem pamięć.

Potem planistę.

Potem retry, telemetry, approvals, wyspecjalizowanych agentów i trochę logiki workflow, bo jedna pętla już nie wystarcza.

To właśnie tutaj wiele aplikacji AI robi się chaotycznych. Pierwsza wersja działała, ale każda nowa możliwość była doklejona z innego poziomu abstrakcji.

To, co podoba mi się w tekście o Agent Framework, to wyraźne pokazanie warstw:

  • loops dla podstawowego cyklu wykonania
  • workflows dla uporządkowanej orkiestracji
  • harnesses dla wielokrotnego użycia możliwości runtime wokół agenta

Na pierwszy rzut oka może to brzmieć akademicko, ale rozwiązuje bardzo praktyczny problem: możesz rozwijać aplikację bez przepisywania modelu mentalnego za każdym razem, gdy staje się bardziej złożona.

Koncepcja harness jest szczególnie ważna

Gdybym miał wybrać jedną część, która według mnie będzie zyskiwać na znaczeniu, wybrałbym ideę harness.

Harness to miejsce, w którym rozwój agentów staje się inżynierią, a nie tylko promptowaniem.

Na tym poziomie zaczynasz dbać o:

  • narzędzia i middleware
  • zachowanie planowania
  • integrację pamięci
  • observability
  • kontrolę i governance
  • powtarzalne zachowanie runtime

To też dlatego ten projekt tak dobrze łączy się z resztą stosu Microsoftu. Foundry, narzędzia governance, hosted agents, ewaluacje i ekosystem narzędzi mają dużo więcej sensu, gdy runtimeowa otoczka wokół modelu jest traktowana jako element pierwszej klasy.

To dobry sygnał dla deweloperów .NET

Jedna rzecz, na którą zawsze patrzę w takich ekosystemach, to czy framework nadal jest użyteczny po pierwszej demonstracji.

Warstwowe podejście sugeruje, że Microsoft myśli o całej ścieżce:

  1. zbudować prostą pętlę agenta
  2. dodać uporządkowane możliwości bez chaosu
  3. przejść do bardziej formalnych workflow, gdy aplikacja ich potrzebuje
  4. utrzymać runtime na tyle composable, by dało się go zintegrować z systemami korporacyjnymi

To znacznie zdrowsza ścieżka wzrostu niż: oto monolityczna abstrakcja, powodzenia.

I bardzo dobrze pasuje do tego, jak zwykle lubią pracować deweloperzy .NET: systemy warstwowe, jawna kompozycja, testowalne granice i mocna kontrola runtime.

Moja ocena

Łatwo zlekceważyć ten wpis, bo nie ma efektownego zrzutu ekranu ani ogromnego dumpa API.

Ale takie notatki o architekturze często lepiej przewidują, czy framework wytrzyma sześć miesięcy.

Microsoft Agent Framework wyraźnie próbuje być czymś więcej niż zabawkową otoczką wokół wywołań modelu. Historia o warstwowym SDK mówi, że zespół buduje dla brudnego środka: miejsca, w którym agentom potrzebne są orchestration, tools, runtime services i production discipline.

To dokładnie ten obszar, który mnie interesuje.

Oryginalny wpis: ICYMI: Inside the Microsoft Agent Framework: How we designed a layered SDK

Udostępnij:
Zobacz kod źródłowy tego posta na GitHub ↗
← FIDES to dokładnie taki deterministyczny temat bezpieczeństwa agentów, który chcę widywać częściej
Nowy Plan agent w Visual Studio rozwiązuje bardzo realny problem workflow AI →