Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Umfang der Tools
Es gibt zwei Ansätze für die Entwicklung von Tools: detaillierte und grobkörnige.
Granular
Bei einem detaillierten Ansatz würden Sie ein Tool pro API, Aktion oder Abfrage erstellen. Sie könnten beispielsweise,create_issue, get_issue add_labelassign_issue, und close_issue Tools für Ihr Git-Repository erstellen. Dies würde es dem LLM ermöglichen, detaillierte Aufrufe an jede API zu tätigen und jede API nach Bedarf zu orchestrieren. Stellen Sie sich die folgende Aufforderung vor: „Erstellen Sie ein Problem für den Produktservice mit dem Namen 'Abfrage gibt nur Teilergebnisse', kennzeichnen Sie es als Fehler mit hoher Priorität und weisen Sie es Alice zu.“ Die folgende Abbildung zeigt, wie ein tool-per-API Ansatz auf diese Aufforderung reagieren würde.
Bei diesem Ansatz werden dem LLM bei jedem Aufruf die Systemaufforderung und jede registrierte Tooldefinition zur Verfügung gestellt. Dadurch wird zusätzlicher Kontext verbraucht und es kommt zu einer Latenzeinbuße, da jeder Tool-Aufruf einen individuellen Aufruf an das LLM darstellt. Dies erhöht auch die Komplexität der Fehlerbehandlung innerhalb des Workflows.
Grobkörnig
Ein grobkörniger oder workflow-orientierter Ansatz wären Tools, die auf Workflows ausgerichtet sind. Das Tool konzentriert sich auf die Benutzerabsicht und nicht auf die API-Struktur. end-to-end Anstelle von einem haben Sie ein Tool tool-per-API, das deterministisch viele aufruft. APIs Mit dem vorherigen Git-Repository-Beispiel könnten Sie ein create_and_setup_issue Tool erstellen, das einmal vom Agenten aufgerufen wird. Die Tool-Implementierung erstellt das Problem, fügt Labels hinzu und weist es einem Benutzer zu, basierend auf den Parametern, die dem Tool zur Verfügung gestellt wurden. Die folgende Abbildung zeigt, wie ein grober Ansatz dieselbe Aufforderung verarbeiten würde.
Dieser Ansatz zeigt, dass die gesamte Komplexität vor der LLM-Ebene verborgen bleibt. Wenn die Orchestrierungslogik in die Toolimplementierung eingebettet ist, werden alle sequentiellen Schritte, die Protokollierung, die Wiederholungslogik, die Schutzschalter und die Ratenbegrenzung deterministisch im Tool ausgeführt. Der workflow-gesteuerte Ansatz erleichtert es dem LLM, das richtige Tool mit den richtigen Parametern aufzurufen. Es ist wichtig zu beachten, dass einige APIs möglicherweise bereits Workflow-Intent bereitstellen, z. B. die Amazon EC2 RunInstances EC2-API. In diesen Fällen bietet a tool-per-API möglicherweise das von Ihnen gewünschte workflow-orientierte Design.
Werkzeuge können jedoch auch zu grobkörnig werden. Wenn Ihr einzelnes Workflow-Tool versucht, zu viele Dinge zu tun und viele mögliche Parameter hat, kann es für den LLM schwierig sein, zu überlegen, wie das Tool richtig verwendet werden soll. Es kann auch zu Herausforderungen bei der Parameterauswahl und Fehlerbehandlung führen. Daher muss bei der Entwicklung von Tools ein Gleichgewicht gefunden werden, das den Benutzerabsichten entspricht und zu wenig oder zu viel Funktionalität in einem einzigen Tool vermeidet. Wir empfehlen Ihnen, Tools so zu entwickeln, dass sie komplette Benutzerworkflows berücksichtigen und Vorgänge, die häufig zusammen auftreten (z. B. drei oder mehr API-Aufrufe), bündeln. Wir empfehlen außerdem, Tools zu zerlegen, die acht oder mehr Parameter überschreiten oder mehrere unterschiedliche Benutzerabsichten berücksichtigen. Testen Sie mit echten Eingabeaufforderungen, um sicherzustellen, dass die Agenten jedes Tool korrekt verwenden können.
Wenn Sie über komplexe und dynamische Workflows verfügen, die sich nicht einfach als deterministisches Tool zusammenfassen lassen, könnten Sie die Verwendung des Musters in Betracht ziehen. agent-as-tool Anstatt dass Ihr primärer Agent versucht, komplexe Aufgaben in einem Workflow zu orchestrieren, kann ein spezialisierter Agent als Tool fungieren. Mit diesen Tools können erweiterte Entscheidungsprozesse und Verzweigungen implementiert werden. Außerdem können sie Fehler und Wiederholungslogik behandeln, die in deterministischem Code nicht einfach zu handhaben ist. Dies ähnelt dem Agent2Agent
Wir empfehlen Ihnen, mit Ihrer Workflow-Analyse zu beginnen, indem Sie Ihre gängigsten Benutzerworkflows abbilden, um die Kernfunktionen zu ermitteln, die jeder Agent benötigt. Auf diese Weise wird Ihr minimales praktikables Toolset festgelegt. Aufgrund unserer Erfahrung mit der Entwicklung von MCP-Servern in großem Maßstab empfehlen wir die folgenden Vorgehensweisen. Wenn diese Praktiken miteinander in Konflikt geraten, sollten Sie Benutzerabsicht und Arbeitsablauf priorisieren.
Bewährte Methoden für die Festlegung des Umfangs von MCP-Tools
-
Denken Sie an Anwenderberichte und bündeln Sie gängige Abläufe — Tools sollten sich direkt den gesamten Benutzerinteraktionen zuordnen lassen, anstatt die Orchestrierung mehrerer Operationen zu erfordern. Wenn Workflows häufig drei oder mehr separate Aufrufe erfordern, kombinieren Sie sie zu einem einzigen Tool. Dies reduziert die kognitive Belastung des LLM, minimiert die Anzahl der Tool-Aufrufe, reduziert den Kontextverbrauch und die Latenz, die für die Ausführung von Aufgaben erforderlich sind, und verbessert die Genauigkeit und Latenz.
-
Beschränken Sie die Parameter auf acht oder weniger — Wenn ein Werkzeug mehr als acht Parameter hat, teilen Sie es in mehrere Tools auf. LLMs Probleme mit der Parameterauswahl haben, wenn die Komplexität zunimmt.
Anmerkung
Wenn für Bündelungsvorgänge mehr als acht Parameter erforderlich sind, sollten Sie der Bündelung Vorrang vor der Anzahl der Parameter einräumen, da die Vereinfachung des Workflows wertvoller ist als strenge Parametergrenzwerte.
-
Getrennte Lese- und Schreibvorgänge — Stellen Sie verschiedene Tools zum Lesen und Ändern von Daten bereit. Diese Trennung macht deutlich, wann Agenten potenziell zerstörerische Operationen ausführen, ermöglicht unterschiedliche Autorisierungsrichtlinien und reduziert das Risiko unbeabsichtigter Änderungen bei der Datenerfassung.
-
Stellen Sie sinnvolle Standardeinstellungen bereit — Entwerfen Sie die Tools so, dass das LLM nur die Parameter angeben muss, die für die jeweilige Anfrage spezifisch sind. Standardeinstellungen reduzieren die Komplexität der Parameter und verbessern die Genauigkeit der Werkzeugauswahl, indem sie die Informationen minimieren, über die das LLM nachdenken muss.
-
Bevorzugen Sie die deterministische Ausführung — Machen Sie die Ausführung und Ausgabe des Werkzeugs nach Möglichkeit deterministisch. Deterministische Tools sind zuverlässiger und einfacher zu testen. Für komplexe Workflows, die intelligente Orchestrierung, Verzweigungslogik oder erweiterte Fehlerbehandlung erfordern und die sich in deterministischem Code nicht einfach verwalten lassen, sollten Sie die Verwendung spezialisierter Agenten als Tools in Betracht ziehen. Verwenden Sie dieses Muster jedoch selektiv, da es die Komplexität erhöht.
