Question 1

Wie betreibt man einen Orchestrator für KI-Agenten mit Freigaben und Grenzen selbst?

Accepted Answer

Legen Sie die Grenzen in die Laufzeit, nicht in den Prompt: eine deklarative Richtlinie, die standardmäßig verweigert, Isolation für jeden Lauf und Geheimnisse, die der Agent nie in der Hand hat. Wir bauen AEGIS by 100monkeys.ai, in beta: einen selbst gehosteten Orchestrator, der autonome Agenten in isolierten, richtliniengesteuerten Laufzeitumgebungen mit dauerhaftem FSM-Zustand ausführt. Läufe werden in Micro-VMs oder rootless Containern isoliert, ein Keymaster verwahrt die Geheimnisse, und Workflows überstehen einen Absturz oder Neustart, was wichtig ist, wenn ein Lauf auf einen Menschen wartet. AEGIS ist Open Source unter AGPL-3.0 und wird mit einem Befehl installiert: curl -fsSL https://get.100monkeys.ai | bash

Question 2

Wie verhindere ich, dass ein KI-Agent API-Schlüssel oder Zugangsdaten preisgibt?

Accepted Answer

Geben Sie dem Agenten die Zugangsdaten nicht. Alles im Kontext des Agenten kann in seiner Ausgabe, in Logs oder in einem Tool-Aufruf landen, egal wie der Prompt formuliert ist. Das Muster, das funktioniert, ist ein Vermittler: Der Agent bittet um eine Aktion, und eine Komponente, die der Agent nicht lesen kann, hängt das Geheimnis auf dem Weg nach draußen an. Kombinieren Sie das mit einer Netzwerk- und Tool-Richtlinie, die standardmäßig verweigert, damit ein verwirrter Agent nirgendwohin etwas schicken kann. AEGIS by 100monkeys.ai, in beta, das wir bauen, macht das mit einem Keymaster, der Geheimnisse verwahrt, sodass Agenten sie nie sehen, in isolierten, richtliniengesteuerten Laufzeitumgebungen.

Question 3

Wie verliert ein lang laufender Workflow mit KI-Agenten bei einem Absturz nicht seinen Stand?

Accepted Answer

Behandeln Sie den Workflow als dauerhafte Zustandsmaschine statt als Prozess im Speicher: Das Ergebnis jedes Schritts wird festgehalten, und ein Neustart setzt beim zuletzt festgehaltenen Zustand fort, statt von vorn zu beginnen. Das zählt am meisten, wo ein Lauf auf einen Menschen wartet, denn eine menschliche Freigabe kann eine Stunde dauern, und ein Neustart in dieser Stunde sollte keine bereits erledigten Schritte wiederholen. Engines wie Temporal gibt es genau dafür. AEGIS by 100monkeys.ai, in beta, das wir bauen, führt Agenten mit dauerhaftem FSM-Zustand auf Temporal-Workflows aus, sodass der Zustand einen Absturz oder Neustart übersteht.

Question 4

Was ist eine Verantwortungssenke (accountability sink), und macht KI sie schlimmer?

Accepted Answer

Der Begriff stammt von Dan Davies, aus The Unaccountability Machine: eine Struktur, die gebaut ist, um menschliches Ermessen zu entfernen und Schuld aufzusaugen, sodass eine Entscheidung fällt und niemand sie getroffen hat. Sein Test: In dem Maß, in dem man eine Entscheidung ändern kann, kann man für sie verantwortlich sein. KI kann das verschlimmern, weil sie ein bequemerer Sündenbock ist; in seinen Worten reisen Entscheidungen weiter als Verantwortung. Die Lösung ist nicht, KI abzulehnen, sondern einen Menschen in die Lage zu versetzen, jede Entscheidung zu sehen, zu sehen, warum sie getroffen wurde, und sie zu stoppen. An diesem Test messen wir, was wir bei 100monkeys.ai bauen.

Fragen zu AEGIS, Grenzen für Agenten und Verantwortlichkeit

Wie betreibt man einen Orchestrator für KI-Agenten mit Freigaben und Grenzen selbst?

Wie verhindere ich, dass ein KI-Agent API-Schlüssel oder Zugangsdaten preisgibt?

Wie verliert ein lang laufender Workflow mit KI-Agenten bei einem Absturz nicht seinen Stand?

Was ist eine Verantwortungssenke (accountability sink), und macht KI sie schlimmer?

Fragen zu Carbon Forge

Fragen zu Zaru