Newton Protocol: Ein „Framework“, das tatsächlich nicht übertragen wird
Ich habe dieses Wochenende meine Werkzeugkiste neu sortiert – einer dieser seltenen produktiven Samstage. Da war dieses verstellbare Maulschlüsselchen, das ich für im Grunde alles benutze, und ich erinnere mich, dass ich dachte: Das ist der ganze Sinn eines guten Werkzeugs – ein einziges Teil, das sich an ein Dutzend verschiedener Aufgaben anpassen kann, ohne dass ich für jede Schraubengröße einen separaten Schlüssel brauche.
Dieser Gedanke war später immer noch da, als ich wieder anfing, das Material vom Newton Protocol zu lesen – diesmal unter dem Blickwinkel „ein zuverlässiges Framework für KI-Agenten aufbauen“. „Framework“ ist ein Wort, das genau diese verstellbare-Schlüssel-Qualität impliziert: etwas Wiederverwendbares, etwas, das man einmal aufbaut und dann mit kleinen Anpassungen auf unterschiedliche Situationen anwendet. Also bin ich hingegangen und habe mir tatsächlich angesehen, was passiert, wenn man versucht, einen zweiten Agenten aufzubauen, der strukturell ganz anders ist, nachdem man zuvor einen ersten gebaut hat.
Und hier ist, was mich aus dem Konzept gebracht hat: Der Berechtigungsumfang, also die zkPermission-Definition selbst, ist in keiner wirklich sinnvollen Weise über Agententypen hinweg wiederverwendbar. Eine Berechtigungsgrenze für einen DCA-Agenten aufzubauen und eine Berechtigungsgrenze für einen Rebalancing-Agenten aufzubauen bedeutet, zwei weitgehend getrennte Spezifikationen zu schreiben. Das liegt daran, dass die konkrete Angriffsfläche und die spezifischen Dinge, die eingeschränkt werden müssen, zwischen den beiden so unterschiedlich sind, dass man die Parameter nicht einfach in eine gemeinsame Vorlage übernehmen kann. Am Ende wird beides sehr nah am Anfang neu gebaut. Das heißt: „Framework“ beschreibt die zugrunde liegende Verifikationsmaschinerie — TEE's und Beweise und all das — und die ist wirklich wiederverwendbar und konsistent. Es beschreibt nicht den Teil, an dem ein Builder den Großteil seiner Zeit verbringt — und der ist jedes Mal maßgeschneidert.
Ich glaube, ich hatte mir „Framework“ so vorgestellt wie meinen Schraubenschlüssel: Eine Form, die sich mit kleinen Anpassungen für verschiedene Aufgaben biegen kann. Was hier tatsächlich da ist, ist eher eine richtig gut gemachte Werkbank: solide, zuverlässig, jedes Mal exakt gleich — aber man muss für jedes einzelne Projekt, das man darauf legt, eine komplett andere Vorrichtung bauen. Die Werkbank ist nicht das Schwierige. Die Vorrichtung ist es. Und die Vorrichtung ist genau der Teil, den das Wort „Framework“ impliziert, der bereits für dich gelöst wurde.
Das hier stört mich an der Sache ein wenig. Zuverlässigkeit in diesem System entsteht ganz konkret durch Enge — je enger und spezifischer ein Berechtigungsumfang ist, desto wirklich vertrauenswürdiger ist die daraus resultierende Automatisierung. Aber Enge ist im Grunde das Gegenteil von Wiederverwendbarkeit. Die gleiche Designentscheidung, die jede einzelne Agenteninstanz zuverlässig macht, ist also auch die Designentscheidung, die verhindert, dass das Framework sich wie ein echtes, wiederverwendbares Framework über Agententypen hinweg verhält. Man kann nicht wirklich beides gleichzeitig maximieren: enge, maßgeschneiderte Umfänge und breite Plug-and-Play-Wiederverwendung — zumindest nicht so, wie das aktuell strukturiert ist. Ich glaube nicht, dass das ein Fehler ist; möglicherweise ist es einfach ein ehrlicher Kompromiss, den niemand klar benennt. Aber es bedeutet eben auch, dass der zweite Agent, den jemand baut, wahrscheinlich fast genauso lange dauert wie der erste — und „Framework“ verspricht normalerweise etwas anderes.
Das ist vermutlich am wichtigsten für alle, die prüfen, ob man damit die Agentenentwicklung schnell über viele Use Cases hinweg skalieren kann, statt für alle, die einen einzigen sehr spezifischen, sehr risikoreichen Automations- und Planungsfall bauen und dann dabei aufhören. Für die zweite Gruppe ist das wirklich solide — man könnte sogar sagen, das ist der ganze Punkt. Für die erste Gruppe die Erwartung zu haben, dass der zweite, zehnte, fünfzigste Agent automatisch bedeutend schneller zu bauen ist, nur weil die zugrunde liegenden Schienen gemeinsam genutzt werden, glaube ich, dass diese Erwartung nicht in dem Maß aufgeht, wie das Wort „Framework“ suggeriert.
Ich schwanke ständig zwischen der Frage, ob das einfach so ist, wie Sicherheit zuerst in Systemen immer funktioniert — enges Zuschnitt-Wesen, das Wiederverwendung von Natur aus erschwert — oder ob es eine smartere Mittelschicht gibt, die noch nicht gebaut wurde und die Berechtigungsvorlagen besser über verschiedene Agententypen hinweg komponierbar machen könnte. Ich weiß es wirklich nicht.
Jedenfalls ist der Schraubenschlüssel wieder in die Werkzeugkiste zurückgegangen, und die Werkbank ist immer noch da für das nächste Wochenende. Ich werde wahrscheinlich weiter beobachten, ob irgendjemand wirklich diese wiederverwendbare Mittelschicht baut, oder ob das Maßgeschneiderte hier auf unbestimmte Zeit maßgeschneidert bleibt.