ACI.dev: 600 Werkzeuge hinter einem Backend aus FastAPI und pgvector

Wofür das Backend von aci.dev gebaut ist

ACI.dev beschreibt sich als quelloffene Plattform für Werkzeugaufrufe, die mehr als 600 Werkzeuge in agentische Entwicklungsumgebungen und eigene Agenten bringt. Der Zugang erfolgt wahlweise über direkte Funktionsaufrufe oder über einen einheitlichen MCP-Server. Das Repository aipotheosis-labs/aci enthält laut README die Plattform, also Backend, Entwicklerportal und Integrationen, lizenziert unter Apache License 2.0. Es ist in Python geschrieben und liegt bei 4887 Sternen, 484 Forks und 63 offenen Issues.

Die plattformseitigen Zusagen betreffen vor allem den Betrieb mit mehreren Mandanten. Genannt werden eingebaute OAuth-Abläufe und Verwaltung von Geheimnissen für Entwickler und Endnutzer, in natürlicher Sprache formulierbare Berechtigungsgrenzen, dynamische Werkzeugsuche, damit das Kontextfenster des Modells nicht überläuft, sowie Protokollierung der Werkzeugaufrufe. Als Anwendungsfälle listet die README VibeOps mit Vercel, Supabase, Cloudflare und Sentry, persönliche Assistenten, Research-Agenten, Vertriebsautomatisierung und Support-Agenten.

FastAPI, PostgreSQL mit pgvector, CLI und das gemeinsame Modul

Das Backend besteht laut seiner README aus vier Teilen. Ein FastAPI-Server bearbeitet API-Anfragen, Authentifizierung und Werkzeugausführung. Eine PostgreSQL-Datenbank mit pgvector übernimmt die Vektorähnlichkeitssuche. Eine Kommandozeilenschnittstelle dient lokalen Tests und der Entwicklung, und ein gemeinsames Modul hält Hilfsfunktionen.

Welche Vektoren dort gespeichert und abgefragt werden, erklärt die README nicht, und einen Dateibaum mit Zeilenzahlen gibt es ebenfalls nicht. Die Wahl von pgvector legt nahe, dass die dynamische Werkzeugsuche über Einbettungen läuft, belegt ist das an dieser Stelle nicht. Wer wissen will, wie die Suche genau arbeitet, muss in den Quelltext sehen; die README nennt als lokale Referenz die API-Dokumentation unter /v1/notforhuman-docs.

Lokaler Aufbau mit uv sync, .env.local und docker compose up --build

Für die lokale Entwicklung verlangt die README Python 3.12 oder neuer, Docker samt Docker Compose und den Paketmanager uv. Nach dem Klonen folgen uv sync, pre-commit install, das Kopieren von .env.example nach .env.local und schließlich docker compose up --build.

Dieser Aufruf startet den Server, PostgreSQL, LocalStack zur Nachbildung von AWS-Diensten sowie einen Runner-Container für pytest, CLI-Befehle und Skripte. Das anschließende Seeden der Datenbank legt ein Projekt, einen Agenten, einen API-Schlüssel und drei Beispiel-Apps an: Brave Search, Hacker News und Gmail, letztere mit Platzhalter-OAuth2-Daten. Sollen alle Apps geladen werden, sind laut README entweder manuell erstellte Geheimnisse nötig oder die Flags --all --mock. Für den Codestil sorgen ruff, mypy und pre-commit-Hooks.

Alembic-Revisionen und pytest im test-runner-Container

Änderungen an Datenbankmodellen laufen über Alembic. Empfohlen wird, mit alembic check Abweichungen zu erkennen, danach mit alembic revision --autogenerate eine Migration zu erzeugen und das Ergebnis anschließend von Hand zu prüfen. Die README fordert ausdrücklich, pgvector-Importe, das Anlegen und Löschen von Indizes, die Einrichtung der Vektorerweiterung und weitere datenbankspezifische Schritte zu kontrollieren, weil automatisch erzeugte Migrationen solche Details gern übersehen.

Angewendet werden Migrationen mit alembic upgrade head, zurückgenommen mit downgrade -1. Tests laufen mit pytest im test-runner-Container. Zur Zahl der Tests und zur angestrebten Abdeckung macht die README keine Angabe, auch einen erwarteten Mindestwert nennt sie nicht. Für ein Projekt, das fremde APIs aufruft, ist das eine relevante Lücke, weil unklar bleibt, wie viel der Integrationslogik automatisiert geprüft wird.

PropelAuth, Stripe-CLI und die Admin-Befehle create-agent und upsert-app

Einige Komponenten sind ausdrücklich nur für die Entwicklung gedacht. Die PropelAuth-Konfiguration braucht, wer am Entwicklerportal arbeitet: Dummy-Werte in .env.local ersetzen, ngrok starten, um den lokalen Server freizugeben, Webhooks in PropelAuth einrichten und einen Mock-Dienst in compose.yml auskommentieren. Für Abrechnungsfunktionen wird die Stripe-CLI verwendet, die Ereignisse an einen lokalen Endpunkt weiterleitet.

Hinzu kommt eine Admin-CLI, die als internes Werkzeug für Apps, Funktionen, Nutzer und zusammenhängende Datensätze beschrieben wird. Ihre Hilfeausgabe nennt Befehle wie create-agent, upsert-app und fuzzy-test-function-execution. Der letzte Befehl deutet darauf hin, dass Funktionsaufrufe gegen zufällige oder fehlerhafte Eingaben geprüft werden, eine belastbare Beschreibung des Verfahrens fehlt in der README. Für den Produktionseinsatz sind PropelAuth- und Stripe-Pfade nach README-Angabe nicht vorgesehen.

Evaluierungspipeline mit generate-and-evaluate und Weights and Biases

Im Repository liegt eine Pipeline zur Bewertung von Funktionssuche und Werkzeugausführung. Sie kennt drei Modi: generate-and-evaluate, generate-only und evaluate-only. Vor dem Start müssen vier Umgebungsvariablen gesetzt sein, für Server-URL, API-Schlüssel, OpenAI-Schlüssel und einen Weights-and-Biases-Schlüssel.

Voraussetzung ist eine Datenbank, in der alle Apps samt Platzhalter-Zugangsdaten geladen sind, und die Pipeline kann die Zahl der erzeugten wie der ausgewerteten Stichproben begrenzen. Ergebnisse werden in ein öffentliches Weights-and-Biases-Projekt geschrieben. Treffergenauigkeiten oder Vergleichszahlen veröffentlicht die README nicht, wer also wissen will, wie zuverlässig die Werkzeugsuche arbeitet, muss die Läufe selbst anstoßen und die Protokolle auswerten.

Grenzen des Backend-Repositorys und der Weg über aci-mcp statt Python-SDK

Die Grenzen sind überwiegend Dokumentationsgrenzen. Die README beschreibt die lokale Entwicklung und enthält keine Anleitung für den Produktionsbetrieb, keine Leistungskennzahlen und keine Zusagen zur Sicherheit. Der Reifegrad zeigt sich in den Releases: v0.0.1-beta.1, beta.2 und beta.3 liegen alle am 30. November und 1. Dezember 2024, seitdem ist im Material kein weiterer Release verzeichnet. Bei 63 offenen Issues und knapp 4900 Sternen heißt das, dass der Selbsthosting-Pfad eigene Wartungsarbeit verlangt.

Wer die Plattform nicht selbst betreiben will, findet zwei dokumentierte Alternativen. aci-mcp stellt die Werkzeuge als einheitlichen MCP-Server bereit, der sich in eine agentische Entwicklungsumgebung einhängen lässt, das Python-SDK unter aipotheosis-labs/aci-python-sdk erlaubt direkte Funktionsaufrufe aus beliebigem Framework-Code. Der Unterschied liegt im Aufwand und in der Kontrolle: Der MCP-Server ist ein Baustein, den man konfiguriert, das SDK eine Bibliothek, die man einbindet, während das Backend die Verwaltung von OAuth, Berechtigungen und Protokollen selbst übernimmt. Für den Einstieg in VibeOps genügt aci-mcp, für eigene Integrationen und Mehrbenutzerbetrieb führt der Weg über dieses Repository und backend/README.md.

Redaktionelles Fazit

Das Backend von ACI.dev passt zu Teams, die eigene Integrationen betreiben und Mehrbenutzer-Authentifizierung samt Berechtigungen selbst in der Hand behalten wollen, statt sie einem gehosteten Dienst zu überlassen. Es passt nicht als fertige Plattform: Der letzte im Material verzeichnete Release ist v0.0.1-beta.3 vom 1. Dezember 2024, die README beschreibt ausdrücklich lokale Entwicklung und nennt keine Anleitung für den Produktionsbetrieb. Vor dem Selbsthosting klären: Sind Python 3.12, Docker mit Compose und uv vorhanden, lassen sich PostgreSQL mit pgvector und LocalStack betreiben, und werden eigene Zugangsdaten statt der Beispiel-Apps Brave Search, Hacker News und Gmail mit Platzhalter-OAuth-Daten eingesetzt. Wer nur Werkzeuge anbinden will, erreicht das über aci-mcp oder das Python-SDK ohne das Backend.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes