# Einführung

Ein Agent, der für jede Entscheidung eine Cloud-API aufruft, mietet seine Intelligenz. Es benötigt einen Schlüssel, es berechnet eine Rechnung professional Token und jede Anfrage verlässt Ihren Pc, bevor Sie eine Antwort erhalten. Ein für die lokale Ausführung konzipierter Agent überspringt all das. Kein API-Schlüssel, keine Kosten professional Aufruf, sobald das Modell heruntergeladen ist, und nichts verlässt Ihr Netzwerk, es sei denn, Sie sagen es. Der Haken daran ist, dass Sie, wenn Sie alles lokal ausführen, auch eine Orchestrierungsschicht benötigen, die tatsächlich versteht, wie man mit einem Modell kommuniziert, das auf Ihrer eigenen {Hardware} sitzt, und nicht mit einem Modell, das sich hinter der API eines anderen befindet.

Nachfolgend sind sieben Python-Instruments aufgeführt, die Ingenieure im Jahr 2026 tatsächlich verwenden, um Agenten in der lokalen Infrastruktur zu erstellen, zu koordinieren und auszuführen, von der Laufzeit, die das Modell selbst bedient, bis zu den Frameworks, die entscheiden, was der Agent damit macht.

# 1. Ollama

Bevor Sie etwas lokal orchestrieren können, muss das Modell tatsächlich von etwas ausgeführt werden. Ollama ist eine leichte Laufzeit zum Ausführen von Open-Supply-LLMs (Giant Language Fashions) auf Ihrem eigenen Pc – was dem am nächsten kommt Docker für Sprachmodelle. Ein Befehl ruft ein Modell ab, ein anderer stellt es über eine lokale API bereit, ohne dass eine Python-Umgebung konfiguriert werden muss CUDA Treiber zur manuellen Set up.

Was Ollama zur Grundlage macht, auf der quick jedes Framework auf dieser Liste aufbaut, ist eine bestimmte Designauswahl. Es verfügt über eine OpenAI-kompatible API, was bedeutet, dass es ohne einen benutzerdefinierten Adapter direkt in die meisten Agenten-Frameworks integriert werden kann. Darüber hinaus bietet es den Datenschutzvorteil, dass Ihre Daten den Pc nie verlassen, und den Kostenvorteil, dass jede Anfrage nach dem Herunterladen eines Modells kostenlos ist. Es ist nicht auf reinen Durchsatz ausgelegt, was Sie wissen sollten, bevor Sie über den Laptop computer eines einzelnen Entwicklers hinaus skalieren. Bei Workloads mit hoher Parallelität kombinieren Groups die Einfachheit von Ollama während der Entwicklung oft mit etwas wie „ vLLMDie PagedAttention-basierte Bereitstellung erfolgt, sobald mehr Leistung benötigt wird, wobei die gleiche Agenten-Orchestrierungsebene oben bleibt.

# 2. Smolagenzien

Wenn Sie genau verstehen möchten, was Ihr Agent tut, ohne sich durch Abstraktionsebenen zu wühlen, Smolagenzien von Hugging Face ist dafür gemacht. Die gesamte Logik für Agenten passt in etwa 1.000 Codezeilen, wobei die Abstraktionen über dem Rohcode auf ihre minimale Kind beschränkt bleiben. Die Bibliothek ist vollständig modellunabhängig und unterstützt neben Dutzenden von gehosteten Anbietern auch lokale Transformatoren oder Ollama-Modelle.

Sein entscheidendes Merkmal ist eine andere Philosophie darüber, wie Agenten handeln sollten. Smolagents bietet erstklassige Unterstützung CodeAgents, die ihre Aktionen in Code schreiben, anstatt nachträglich zum Generieren von Code verwendet zu werden, und es unterstützt die Ausführung dieses Codes in Sandbox-Umgebungen über Docker, E2Boder Modal zur Sicherheit. Der ehrliche Kompromiss, den Sie wissen sollten: Die Leistung nimmt bei kleineren Open-Supply-Modellen stark ab, wobei sich ständig Fehler unterhalb des 7B-Parameterbereichs einschleichen. Daher ist dies besser geeignet, wenn Sie ein halbwegs leistungsfähiges lokales Modell ausführen, als ein kleines Modell, das auf bescheidene {Hardware} gequetscht wird.

# 3. PydanticAI

Agenten, die Instruments aufrufen oder strukturierte Daten weitergeben, sind nur so zuverlässig wie das von ihnen ausgegebene Format, und ein Modell, das gelegentlich fehlerhaftes JSON zurückgibt, kann stillschweigend eine ganze Pipeline lahmlegen. PydanticAI wurde vom Workforce hinter Pydantic speziell entwickelt, um diese Lücke zu schließen. Es nutzt Python-Typhinweise, um alle Agenteneingaben, -ausgaben und Toolaufrufe typsicher zu machen, mit automatischer Schemavalidierung und Selbstkorrektur, wenn die Ausgabe eines LLM nicht der erwarteten Struktur entspricht.

Dadurch eignet es sich besonders intestine für lokale Agenten, die sich um alles kümmern, bei dem es tatsächlich auf Datenintegrität ankommt. PydanticAI stellt sicher, dass Daten strukturiert, validiert und zuverlässig sind, was für Compliance-intensive Branchen wie Finanzen und Gesundheitswesen von entscheidender Bedeutung ist. Da es mit jedem OpenAI-kompatiblen Endpunkt funktioniert, ist die Weiterleitung an einen lokalen Ollama-Server ein einfacher Austausch und keine separate Integration. Das Projekt schreitet schnell voran: Durch die aktive Entwicklung wurde es bis April 2026 unter der Leitung des Pydantic-Kernteams auf Model 1.85.1 gebracht, wobei die Prüfer durchweg die Typsicherheit und die minimalen Abhängigkeiten als herausragendes Merkmal nannten.

# 4. CrewAI

Für einen einzelnen Agenten reicht die oben genannte Konfiguration aus. Wenn Sie möchten, dass mehrere Agenten an verschiedenen Teilen einer Aufgabe zusammenarbeiten, CrewAI Meistens ist es das Framework, nach dem die Leute zuerst greifen, insbesondere weil es so schnell zu etwas führt, das funktioniert. Sie definieren Agenten mit Rollen und Zielen, gruppieren sie zu einem Workforce und lassen sie zusammenarbeiten – und es ist wohl das einfachste Agenten-Framework, um mit lokalen Modellen zu arbeiten.

Die Geschichte des lokalen Modells ist hier auch kein nachträglicher Einfall. CrewAI vermeidet ausdrücklich Abhängigkeiten von LangChain oder anderen externen Agent-Frameworks, positioniert sich als eigenständig und unterstützt OpenAI als Standardmodellanbieter sowie explizite Unterstützung für lokale Laufzeiten über Ollama. Es unterstützt auch das Mannequin Context Protocol (MCP) über stdio, SSE und streambare HTTP-Transporte, sodass ein lokales CrewAI-Setup weiterhin auf standardisierte Device-Server zugreifen kann, ohne das darunter liegende Native-First-Modell zu verlieren.

# 5. AgentScope

Wo die vorherigen Frameworks für einen schnellen Einstieg optimiert sind, AgentScope ist von Anfang an auf die Produktion ausgerichtet und die lokale Bereitstellung wird als erstklassige Possibility und nicht als Randfall behandelt. AgentScope 2.0 ist ein produktionsbereites Agenten-Framework mit Workspace- und Sandbox-Unterstützung, das Instruments und Code in isolierten Umgebungen mit integrierten Backends für die lokale Ausführung, Docker und E2B ausführt. Mit über 27.300 GitHub-Sternen und zwei von Experten begutachteten Artikeln, die sein Design unterstützen, ist es eine der umfassenderen Optionen für Groups, die Multi-Agenten-Systeme erstellen, die tatsächlich ausgeliefert werden müssen.

Der Datenschutzaspekt ist explizit und nicht zufällig. Agenten werden vollständig in Ihrer eigenen Infrastruktur ausgeführt, unabhängig davon, ob es sich um lokale Server oder Ihre eigene Cloud handelt, ohne dass Daten an die Server von AgentScope gesendet werden. Mit der Modellabstraktionsschicht können Sie lokale oder non-public Modelle für smart Arbeitslasten austauschen, ohne Ihren Agentencode neu schreiben zu müssen. Die Koordination mehrerer Agenten erfolgt über einen sogenannten Message Hub, den das Framework nennt. Agenten kommunizieren über eine strukturierte Nachrichtenübermittlung und nicht über einen gemeinsamen impliziten Kontext, wodurch die Interaktionen clear und überprüfbar bleiben – ein bedeutender Unterschied, wenn Sie jemals ein System mit mehreren Agenten debuggen mussten, bei dem nicht klar warfare, welcher Agent welche Entscheidung beeinflusst hat.

# 6. LangGraph

LangGraph wurde bereits in früheren Berichten über die Agenten-Orchestrierung erwähnt, und das aus gutem Grund: Es ist zur Standardwahl für alles geworden, was zustandsbehaftet, verzweigt oder wiederherstellbar ist. Der lokale Modellaspekt ist hier besonders hervorzuheben. Da LangGraph mit jedem OpenAI-kompatiblen Backend funktioniert, ist das Verweisen eines Diagramms auf eine lokale Ollama-Instanz für Planungs- und Device-Entscheidungen ein einzeiliger Austausch, und das gleiche Checkpointing, das LangGraph in der Cloud zuverlässig macht – Pause-und-Fortsetzen, Zeitreise-Debugging und Multi-Instanz-Skalierung – funktioniert identisch, unabhängig davon, ob das Modell dahinter eine Frontier-API oder ein Modell ist, das auf Ihrer eigenen GPU ausgeführt wird.

Dies ist vor allem für lokale Agenten wichtig, die mehr tun müssen, als nur eine einzelne Aufforderung zu beantworten. Eine zuverlässige lokale Agentenschleife profitiert von einer vorhersehbaren Struktur, bei der das Modell einen Plan vorschlägt, jeweils eine Werkzeugaktion ausführt, das Ergebnis beobachtet und über den nächsten Schritt entscheidet. Und sobald diese Schleife einen Absturz oder eine lange Pause zwischen den Schritten überstehen muss, verhindert die Persistenzschicht von LangGraph, dass sie jedes Mal von vorne beginnt.

# 7. Microsoft Agent Framework

Wenn Sie die Governance- und Middleware-Funktionen benötigen, die in einer größeren technischen Organisation erwartet werden, aber dennoch die Möglichkeit haben möchten, alles auf der lokalen Infrastruktur auszuführen, Microsoft Agent Framework ist wissenswert. Es ist der einheitliche Nachfolger von AutoGen Und Semantischer Kernelvon denselben Groups entwickelt und im Oktober 2025 als künftiges Single-Orchestrierungs-SDK von Microsoft angekündigt, das die konversationsorientierten Multi-Agent-Abstraktionen von AutoGen mit den Unternehmensfunktionen von Semantic Kernel wie sitzungsbasierter Zustandsverwaltung, Middleware und Telemetrie kombiniert.

Das Element, das ihm einen Platz auf dieser speziellen Liste einbringt, ist die direkte, explizite Unterstützung lokaler Modelle – nicht etwas, das angeschraubt wird. Das Framework wird mit einem Python-Paket geliefert und unterstützt Microsoft Foundry, Azure OpenAI, OpenAI, Anthropisch, Amazonas-Grundgestein, Google Geminiund Ollama sind sofort einsatzbereit, was bedeutet, dass ein Workforce, das dieses Framework für seine Unternehmensfunktionen standardisiert, nicht auf die Possibility verzichten muss, einen vollständig lokalen Agenten für smart Arbeitslasten oder Offline-Entwicklung auszuführen. Wissenswertes vor einer breiten Einführung: Von der Neighborhood gemeldete Probleme konzentrieren sich auf Anbieteradapter außerhalb des Azure OpenAI Blissful Path. Daher sollten Groups, die hauptsächlich auf Ollama- oder Nicht-Microsoft-Infrastrukturen arbeiten, die Anbieterintegration gründlich überprüfen, bevor sie sich verpflichten.

# Zusammenfassung

Diese sieben Werkzeuge konkurrieren nicht wirklich um die gleiche Aufgabe. Ollama ist das Fundament, auf dem quick alles andere ruht. Smolagents und PydanticAI leben eine Ebene unterhalb der vollständigen Orchestrierung – eine ist für minimale Abstraktion und Code-as-Motion optimiert, die andere für Typsicherheit, wo eine fehlerhafte Ausgabe einfach nicht akzeptabel ist. CrewAI sorgt dafür, dass ein lokaler Multiagenten-Prototyp am schnellsten läuft. AgentScope und Microsoft Agent Framework bringen produktionstaugliche Struktur, Audit-Trails und Governance in lokale Bereitstellungen. LangGraph sitzt in der Mitte und gibt jedem der oben genannten Punkte ein dauerhaftes, mit Kontrollpunkten versehenes Rückgrat, wenn ein lokaler Agent mehr tun muss, als nur einmal zu reagieren und dann anzuhalten.

Die richtige Wahl hängt weniger davon ab, welches Framework „am besten“ ist, als vielmehr davon, welche Einschränkungen Sie tatsächlich lösen: Geschwindigkeit des Prototypings, strikte Datenvalidierung, Produktionssteuerung oder Langzeitstatus. Der lokale Betrieb bedeutet nicht mehr, dass man sich mit weniger Leistungsfähigkeit zufrieden geben muss. Es geht vor allem darum, das Framework auszuwählen, das auf der Einschränkung basiert, die für das, was Sie versenden, am wichtigsten ist.

Shittu Olumid ist ein Software program-Ingenieur und technischer Autor, der sich leidenschaftlich dafür einsetzt, modernste Technologien zu nutzen, um fesselnde Erzählungen zu erschaffen, mit einem scharfen Blick fürs Element und einem Gespür für die Vereinfachung komplexer Konzepte. Sie können Shittu auch auf finden Twitter.

# Wir stellen MCP vor

Jeder Entwickler, der mit lokaler KI baut, stößt irgendwann an dieselbe Wand. Das Modell funktioniert. Es argumentiert intestine, schreibt soliden Code und beantwortet komplexe Fragen. Aber es kann nicht alles tun. Es kann Ihre Datenbank nicht abfragen, kein GitHub-Downside öffnen oder Ihre interne API aufrufen. Sie müssen für jedes Instrument, das Sie benötigen, benutzerdefinierte Python-Wrapper schreiben, die Verbindung zwischen Modellausgabe und Toolausführung fest codieren und diese Wrapper bei jeder API-Änderung verwalten.

Der Mannequin Context Protocol (MCP) wurde entwickelt, um genau dieses Downside zu lösen. Es handelt sich um einen offenen Commonplace von Anthropic: ein universelles, steckbares Protokoll für die Konnektivität von KI-Instruments. Definieren Sie ein Instrument einmalig als MCP-Server. Jeder MCP-kompatible Consumer, jedes Modell, jedes Framework kann es ohne benutzerdefinierten Integrationscode professional Modell erkennen und aufrufen.

Qwen3.6-35B-A3B ist derzeit das fähigste lokale Modell für diese Artwork von Arbeit. Es verfügt über ein 262.144-Token-Kontextfenster, eine Combination of Consultants (MoE)-Architektur, die nur 3B seiner 35B Parameter professional Vorwärtsdurchlauf aktiviert (weshalb es auf {Hardware} passt, die kein 35B-Modell ausführen sollte) und wurde explizit auf MCP-basierte Agentenaufgaben trainiert und evaluiert.

In diesem Artikel wird ein lokaler GitHub-Entwicklerassistent erstellt: ein Agent, der die offenen Probleme eines Repositorys liest, den relevanten Code durchsucht, einen Repair entwirft und eine Pull-Anfrage erstellt. Das Ganze läuft auf Ihrer {Hardware}, über MCP-Server, ohne Cloud-Abhängigkeit.

# Qwen3.6-35B-A3B verstehen

Hier ist es wichtig, die Architektur zu verstehen, denn sie erklärt direkt, welche {Hardware} Sie benötigen und warum das Modell bei Agentenaufgaben die gleiche Leistung erbringt.

Der Title kodiert die entscheidende Tatsache: 35B Gesamtparameter, wobei A3B bedeutet, dass 3B professional Vorwärtsdurchlauf aktiviert werden. Es handelt sich um ein MoE-Modell mit 256 Experten professional Schicht, Routing von 8 plus 1 gemeinsam genutzten Experten professional Token. Sie erhalten die Wissenskapazität eines 35B-Modells zum Inferenzrechenaufwand eines 3B-Modells. Dieser Kompromiss ist der Grund, warum es auf {Hardware} passt, die unter einem dichten 35B zusammenbrechen würde.

Im versteckten Structure unterscheidet sich Qwen3.6 am meisten von anderen MoE-Modellen. Jeder Block im 40-Schichten-Stack folgt einem 3:1-Verhältnis von Gated DeltaNet-Schichten zu Gated Consideration-Schichten. DeltaNet ist ein linearer Aufmerksamkeitsmechanismus; Es verarbeitet Sequenzen effizienter als die volle quadratische Aufmerksamkeit, insbesondere bei langen Kontextlängen. Die verschachtelten vollständigen Gated-Consideration-Schichten liefern die tiefe relationale Argumentation, die der linearen Aufmerksamkeit allein fehlt. Für einen Agenten, der ein Repository mit 500 Dateien durcharbeitet, ist diese Kombination wichtig: effiziente, ausführliche Verarbeitung kombiniert mit präziser Begründung der relevanten Abschnitte.

Das Kontextfenster umfasst nativ 262.144 Token und ist mit YaRN-Skalierung auf 1.010.000 erweiterbar. Bei der Agentenarbeit ist die Kontextlänge kein Komfortmerkmal; es handelt sich um eine betriebliche Einschränkung. Ein Agent, der Quelldateien liest, den Instrument-Aufrufverlauf verwaltet, einen mehrstufigen Plan verfolgt und Instrument-Ergebnisse wieder in den Kontext einfügt, benötigt echten Spielraum. Die meisten 7B- und 13B-Modelle sind auf 8.000 oder 32.000 Token begrenzt. Wenn der Agent mitten in der Aufgabe aus dem Kontext gerät, verliert er seinen eigenen Verlauf und fängt an, Werkzeugergebnisse zu halluzinieren.

Qwen3.6 wurde explizit anhand von MCP-basierten Agenten-Benchmarks trainiert und bewertet. Aus dieser Schulung gingen zwei Schlagzeilen hervor:

• Agentenkodierung. Frontend-Workflows und Argumentation auf Repository-Ebene – das Modell bewältigt Refactoring-Aufgaben für mehrere Dateien mit kohärenter Argumentation über Dateien hinweg, nicht nur isolierte Bearbeitungen einzelner Dateien.
• Bewahrung denken. A preserve_thinking Flag, das Argumentationsspuren aus früheren Runden in einem Gespräch mit mehreren Runden beibehält. Wenn ein Agent in der ersten Runde einen Plan durchgeht und dann in den Runden zwei bis fünf Toolaufrufe ausführt, preserve_thinking=True hält die Argumentation der ersten Runde im KV-Cache verfügbar. Jeder nachfolgende Spielzug profitiert von dieser vorherigen Argumentation, ohne die Kosten für die erneute Herleitung zu zahlen.

# Systemanforderungen

Es gibt drei realistische Bereitstellungspfade. Welchen Sie verwenden, hängt vollständig von Ihrer {Hardware} ab.

• GPU-Inferenz (empfohlen für Arbeitslasten von Produktionsagenten). Qwen3.6-35B-A3B in bfloat16 erfordert etwa 70 GB VRAM. Bei der This autumn-Quantisierung passen etwa 20–24 GB hinein. Eine einzelne RTX 4090 (24 GB) bewältigt This autumn. Zwei RTX 3090 mit Tensorparallelität bewältigen auch This autumn. Ein A100 80 GB bewältigt das vollständige bfloat16-Modell.
• CPU/Hybrid über KTransformers. KTransformers ist der zugängliche Weg für Entwickler ohne 24-GB-GPU. Es verlagert rechenintensive Schichten auf die GPU, sofern verfügbar, und führt den Relaxation auf der CPU aus. Mit 64 GB System-RAM können Sie Qwen3.6-35B-A3B in einer brauchbaren (wenn auch langsameren) Konfiguration ausführen. Die Antwortlatenz beträgt je nach CPU 30–120 Sekunden professional Runde. Dies ist für einen Agenten, der eine Hintergrund-Repository-Analyse durchführt, nicht jedoch für interaktive Codierungssitzungen akzeptabel.
• Kleinere Modelle für Tutorial-Exams. Das gesamte MCP-Integrationsmuster in diesem Artikel ist unabhängig von der Modellgröße identisch. Wenn Sie ohne die {Hardware} für das vollständige 35B-Modell weitermachen möchten, verwenden Sie Qwen/Qwen2.5-7B-Instruct über Ollama (ollama pull qwen2.5:7b) oder das Modell Qwen3-8B. Die Serving-API ist dieselbe, der Code ist identisch und Sie können das 35B-Modell austauschen, wenn die {Hardware} dies zulässt.

Softwareanforderungen:

# Python 3.11+ required
python --version

python -m venv qwen-mcp-env
supply qwen-mcp-env/bin/activate    # macOS / Linux
qwen-mcp-envScriptsactivate       # Home windows

# Core packages
pip set up 
  "openai>=1.30.0" 
  "qwen-agent>=0.0.10" 
  "mcp>=1.0.0" 
  "httpx>=0.27.0"

# Serving framework -- select one
pip set up "vllm>=0.19.0"       # NVIDIA GPU
pip set up "sglang>=0.5.10"     # NVIDIA GPU (sooner prefill for lengthy context)
pip set up "ktransformers"      # CPU/hybrid

# Node.js 18+ is required for pre-built MCP servers put in by way of npx
node --version

# Lokale Bereitstellung von Qwen3.6 mit einer OpenAI-kompatiblen API

Bevor Sie MCP-Server anschließen, benötigen Sie einen laufenden Inferenzserver. Sowohl SGLang als auch vLLM stellen eine OpenAI-kompatible API bereit, mit der die MCP-Integrationsschicht kommuniziert – dieselbe API-Oberfläche, die nur auf localhost statt auf zeigt api.openai.com.

// SGLang (empfohlen für Agent-Workloads mit langem Kontext)

# Set up SGLang with full dependencies
pip set up "sglang(all)>=0.5.10"

# Serve Qwen3.6-35B-A3B with reasoning and tool-call parsers enabled.
# --reasoning-parser qwen3 appropriately handles the ... blocks.
# --tool-call-parser qwen3_coder routes software name outputs to the suitable format.
# --enable-prefix-caching is crucial for agent workloads -- permits KV cache reuse
#   throughout turns, which is what makes preserve_thinking environment friendly in follow.

python -m sglang.launch_server 
    --model-path Qwen/Qwen3.6-35B-A3B 
    --host 0.0.0.0 
    --port 30000 
    --reasoning-parser qwen3 
    --tool-call-parser qwen3_coder 
    --enable-prefix-caching 
    --tp 2    # tensor parallel throughout 2 GPUs; take away if utilizing single GPU

// vLLM

pip set up "vllm>=0.19.0"

# vLLM equal with the identical crucial flags
vllm serve Qwen/Qwen3.6-35B-A3B 
    --host 0.0.0.0 
    --port 8000 
    --reasoning-parser qwen3 
    --tool-call-parser qwen3_coder 
    --enable-prefix-caching-v2 
    --tensor-parallel-size 2

// Kleineres Modell über Ollama

ollama pull qwen2.5:7b
ollama serve
# Ollama's API is OpenAI-compatible at http://localhost:11434/v1

Sobald der Server läuft, überprüfen Sie ihn, bevor Sie fortfahren:

# Well being examine -- ought to return {"standing": "okay"} or related
curl http://localhost:30000/well being

# Check the chat completions endpoint with a easy question
curl http://localhost:30000/v1/chat/completions 
  -H "Content material-Kind: utility/json" 
  -d '{
    "mannequin": "Qwen/Qwen3.6-35B-A3B",
    "messages": ({"position": "consumer", "content material": "Reply with: prepared"}),
    "max_tokens": 10
  }'

Wenn Sie eine JSON-Antwort mit a erhalten selections Array, der Server ist bereit. Fahren Sie nicht mit der MCP-Einrichtung fort, bis dies funktioniert. Jeder Integrationsfehler, auf den Sie später stoßen, lässt sich leichter beheben, wenn Sie wissen, dass die Bereitstellungsschicht solide ist.

# MCP verstehen und warum es die Agentenarchitektur verändert

Bevor Sie Agentencode schreiben, ist es hilfreich zu verstehen, was MCP tatsächlich auf Protokollebene tut, denn dieses Verständnis verhindert eine Kategorie von Fehlern, die dadurch entstehen, dass MCP nur als eine schickere Funktionsaufruf-API behandelt wird.

MCP ist ein JSON-RPC 2.0-Protokoll läuft über stdio oder HTTP-Transport. Wenn ein MCP-Consumer eine Verbindung zu einem Server herstellt, ruft er zunächst auf instruments/record um herauszufinden, welche Instruments der Server bereitstellt. Jedes Instrument enthält einen Namen, eine Beschreibung und ein im JSON-Schema definiertes Eingabeschema. Das Modell liest dieses Schema. Es handelt sich um den Vertrag des Modells mit dem Werkzeug.

Wenn das Modell ein Werkzeug aufrufen möchte, gibt es ein strukturiertes Werkzeugaufrufobjekt aus. Der MCP-Consumer – ​​nicht das Modell – führt den Anruf tatsächlich aus, indem er a sendet instruments/name Anfrage an den Server. Der Server übernimmt die Ausführung und gibt ein Ergebnis zurück. Der Klient bringt dieses Ergebnis wieder in das Gespräch ein software Rollenbotschaft. Das Modell liest das Ergebnis und entscheidet über den nächsten Schritt.

Diese Trennung ist wichtig. Das Modell entscheidet, was aufgerufen wird und mit welchen Argumenten. Der Kunde übernimmt die Ausführung. Der Server übernimmt die eigentliche Arbeit. Ihr Code verdrahtet niemals ein Werkzeug fest mit einem Modell; Sie teilen dem Consumer einfach mit, welche Server verfügbar sind.

Es gibt zwei Möglichkeiten, MCP mit Qwen3.6 zu verwenden:

• Über Qwen-Agent: der Beamte qwen_agent Die Bibliothek übernimmt automatisch die Instrument-Erkennung, das Parsen von Anrufen, die Ergebnisinjektion und die Konversationsverwaltung mit mehreren Runden. Weniger Code, weniger Kontrolle. Für die meisten Anwendungsfälle geeignet.
• Direkt über das MCP Python SDK: Sie handhaben die Agentenschleife selbst mit mcp.ClientSession. Mehr Code, vollständige Sichtbarkeit jeder Nachricht, vollständige Kontrolle über die Fehlerbehandlung und Wiederholungslogik. Excellent für Produktionssysteme, bei denen Sie jeden Schritt überwachen müssen.

Dieser Artikel behandelt beide, beginnend mit Qwen-Agent.

# Erstellen des lokalen GitHub-Entwicklerassistenten

Der Agent führt nacheinander vier Dinge aus: Er liest offene Probleme aus einem GitHub-Repository, findet den relevanten Code, entwirft einen Repair und öffnet eine Pull-Anfrage. Alles lokal, alles über MCP.

// Teil 1: Umgebung und MCP-Server-Setup

# Set your GitHub private entry token
# Required by the GitHub MCP server for API calls
export GITHUB_TOKEN=ghp_your_token_here

# Pre-built MCP servers set up by way of npx -- no separate set up step
# npx handles this on first use when the agent begins the servers
# Confirm npx is offered:
npx --version

Erstellen Sie ein Projektverzeichnis:

mkdir qwen-github-agent
cd qwen-github-agent

// Teil 2: Qwen-Agent-Implementierung

Der schnellste Weg zu einem funktionierenden Agenten. Qwen-Agent verarbeitet die gesamte Schleife automatisch.

# github_agent_qwenagent.py
# Conditions: pip set up qwen-agent openai
#   npm / npx have to be put in for the MCP servers
#   GITHUB_TOKEN env var have to be set
#   Native serving endpoint have to be operating (see earlier part)
#
# Find out how to run:
#   python github_agent_qwenagent.py

from qwen_agent.brokers import Assistant

# ── Server configuration ──────────────────────────────────────────────────────

# Level at your native serving endpoint.
# Change the base_url to match whichever server you began:
#   SGLang:  http://localhost:30000/v1
#   vLLM:    http://localhost:8000/v1
#   Ollama:  http://localhost:11434/v1
LLM_CONFIG = {
    "mannequin":     "Qwen/Qwen3.6-35B-A3B",
    "model_server": "http://localhost:30000/v1",
    "api_key":   "EMPTY",           # Native servers don't require an actual key

    # Pondering mode sampling params (from the official mannequin card greatest practices)
    "generate_cfg": {
        "temperature":       0.6,
        "top_p":             0.95,
        "top_k":             20,
        "min_p":             0.0,
        "thought_in_history": True,   # That is the preserve_thinking flag in Qwen-Agent
    },
}

# ── MCP server configuration ──────────────────────────────────────────────────
# Every server key names the server; the worth is the stdio launch command.
# Qwen-Agent begins every server as a subprocess and manages the MCP periods.

MCP_SERVERS = {
    "mcpServers": {
        "filesystem": {
            "command": "npx",
            "args": (
                "-y",
                "@modelcontextprotocol/server-filesystem",
                # Grant the agent entry to the present working listing
                # In manufacturing, limit to the precise repository path
                "."
            )
        },
        "github": {
            "command": "npx",
            "args": ("-y", "@modelcontextprotocol/server-github"),
            "env": {
                # The GitHub MCP server reads this env var for API authentication
                "GITHUB_TOKEN": "${GITHUB_TOKEN}"
            }
        },
    }
}

# ── System immediate ─────────────────────────────────────────────────────────────
SYSTEM_PROMPT = """You're a senior software program engineer with full entry to a GitHub repository
by way of MCP instruments.

When given a repository and process:
1. Checklist open points to grasp what wants fixing
2. Use filesystem instruments to learn related supply recordsdata and checks
3. Establish the basis trigger primarily based on the code and the difficulty description
4. Write a focused repair -- minimal modifications, no refactoring unrelated to the bug
5. Create a pull request with a transparent title and outline referencing the difficulty

All the time clarify your reasoning at every step. Suppose by edge instances earlier than writing code.
If you're unsure a few file's function, learn it earlier than modifying it."""

# ── Agent setup ───────────────────────────────────────────────────────────────

agent = Assistant(
    llm=LLM_CONFIG,
    identify="GitHub Developer Assistant",
    description="Reads points, fixes bugs, opens pull requests -- domestically by way of MCP.",
    system_message=SYSTEM_PROMPT,
    mcp_servers=MCP_SERVERS,
)

# ── Run the agent ─────────────────────────────────────────────────────────────

def run_agent(process: str):
    """
    Run the agent on a process description and stream the output.
    The agent will make software calls routinely; Qwen-Agent handles
    the total loop together with software execution and consequence injection.
    """
    messages = ({"position": "consumer", "content material": process})

    print(f"Process: {process}n{'─' * 70}")

    # Qwen-Agent's run() is a generator that yields intermediate steps
    # Every yielded message exhibits a software name, a software consequence, or the ultimate reply
    for response in agent.run(messages=messages):
        # response is a listing of messages representing the dialog to date
        # The final message comprises the newest output
        final = response(-1)
        position    = final.get("position", "")
        content material = final.get("content material", "")

        if position == "assistant" and content material:
            # Strip and show the considering block individually for readability
            import re
            considering = re.search(r"(.*?)", content material, re.DOTALL)
            if considering:
                print(f"(considering) {considering.group(1).strip()(:200)}...")
            clear = re.sub(r".*?", "", content material, flags=re.DOTALL).strip()
            if clear:
                print(f"(agent) {clear}")

        elif position == "software":
            tool_name = final.get("identify", "unknown_tool")
            print(f"(software:{tool_name}) consequence obtained")


if __name__ == "__main__":
    run_agent(
        "Within the repository myorg/my-api-project, discover the open subject about "
        "the login endpoint returning 200 for invalid tokens. Learn the related "
        "code and checks, repair the bug, and open a pull request."
    )

So führen Sie aus:

python github_agent_qwenagent.py

// Teil 3: Rohe MCP SDK-Implementierung

Für Groups, die vollständige Kontrolle über jede Protokollnachricht, benutzerdefinierte Fehlerbehandlung, Wiederholungslogik professional Instrument und Audit-Protokollierung aller Instrument-Aufrufe und -Ergebnisse benötigen:

# github_agent_raw.py
# Conditions: pip set up mcp openai httpx
#   GITHUB_TOKEN env var have to be set, native server have to be operating
#
# Find out how to run:
#   python github_agent_raw.py

import asyncio
import json
import os
import re
from openai import AsyncOpenAI
from mcp import ClientSession, StdioServerParameters
from mcp.consumer.stdio import stdio_client

# ── Native serving consumer ───────────────────────────────────────────────────────
consumer = AsyncOpenAI(
    base_url="http://localhost:30000/v1",
    api_key="EMPTY",
)

MODEL = "Qwen/Qwen3.6-35B-A3B"

# ── Response processing ───────────────────────────────────────────────────────

def strip_thinking(textual content: str) -> str:
    """Take away ... blocks. Used after we solely want the motion."""
    return re.sub(r".*?", "", textual content, flags=re.DOTALL).strip()

def extract_thinking(textual content: str) -> str:
    """Extract the content material of the considering block for logging."""
    m = re.search(r"(.*?)", textual content, re.DOTALL)
    return m.group(1).strip() if m else ""

def process_response(response, preserve_thinking: bool = True) -> dict:
    """
    Course of a chat completion response from Qwen3.6.

    Handles two output codecs:
    1. Instrument name by way of the API's function_call / tool_calls area (when --tool-call-parser is energetic)
    2. Instrument name embedded within the message content material as JSON

    Args:
        response:          The OpenAI-compatible completion response
        preserve_thinking: If True, maintain considering content material in output for
                           the subsequent flip's KV cache profit

    Returns:
        dict with considering, tool_calls, final_answer, has_tool_calls, is_terminal
    """
    alternative  = response.selections(0)
    message = alternative.message

    # Path 1: Instrument calls within the structured area (most well-liked -- requires tool-call-parser flag)
    if message.tool_calls:
        tool_calls = (
            {
                "identify":      tc.operate.identify,
                "arguments": json.hundreds(tc.operate.arguments),
                "call_id":   tc.id,
            }
            for tc in message.tool_calls
        )
        considering = extract_thinking(message.content material or "")
        return {
            "considering":       considering if preserve_thinking else "",
            "tool_calls":     tool_calls,
            "final_answer":   "",
            "has_tool_calls": True,
            "is_terminal":    False,
        }

    # Path 2: Instrument calls embedded in content material textual content (fallback)
    content material = message.content material or ""
    tag_matches = re.findall(r"(.*?)", content material, re.DOTALL)
    tool_calls = ()
    for m in tag_matches:
        strive:
            tool_calls.append(json.hundreds(m.strip()))
        besides json.JSONDecodeError:
            go

    considering     = extract_thinking(content material)
    final_answer = re.sub(r".*?", "", content material, flags=re.DOTALL)
    final_answer = re.sub(r".*?", "", final_answer, flags=re.DOTALL).strip()

    return {
        "considering":       considering if preserve_thinking else "",
        "tool_calls":     tool_calls,
        "final_answer":   final_answer,
        "has_tool_calls": len(tool_calls) > 0,
        "is_terminal":    len(tool_calls) == 0 and bool(final_answer),
    }

# ── Core agent loop ───────────────────────────────────────────────────────────

async def run_github_agent(process: str, repo: str, max_turns: int = 20):
    """
    Run the GitHub developer assistant agent.

    Connects to filesystem and GitHub MCP servers, discovers their instruments,
    and runs the Qwen3.6 agent loop till the duty is full or max_turns reached.
    """
    # Begin each MCP servers and set up periods
    fs_params = StdioServerParameters(
        command="npx",
        args=("-y", "@modelcontextprotocol/server-filesystem", "."),
    )
    gh_params = StdioServerParameters(
        command="npx",
        args=("-y", "@modelcontextprotocol/server-github"),
        env={**os.environ, "GITHUB_TOKEN": os.environ.get("GITHUB_TOKEN", "")},
    )

    async with stdio_client(fs_params) as (fs_read, fs_write), 
               ClientSession(fs_read, fs_write) as fs_session, 
               stdio_client(gh_params) as (gh_read, gh_write), 
               ClientSession(gh_read, gh_write) as gh_session:

        # Initialize each periods
        await fs_session.initialize()
        await gh_session.initialize()

        # Uncover all out there instruments from each servers
        fs_tools_result = await fs_session.list_tools()
        gh_tools_result = await gh_session.list_tools()

        # Construct the OpenAI-format software record for the mannequin
        all_tools = ()
        tool_to_session = {}   # Maps software identify to the MCP session that owns it

        for software in fs_tools_result.instruments:
            all_tools.append({
                "kind": "operate",
                "operate": {
                    "identify":        software.identify,
                    "description": software.description,
                    "parameters":  software.inputSchema,
                }
            })
            tool_to_session(software.identify) = fs_session

        for software in gh_tools_result.instruments:
            all_tools.append({
                "kind": "operate",
                "operate": {
                    "identify":        software.identify,
                    "description": software.description,
                    "parameters":  software.inputSchema,
                }
            })
            tool_to_session(software.identify) = gh_session

        print(f"Instruments out there: {len(all_tools)} ({len(fs_tools_result.instruments)} filesystem, "
              f"{len(gh_tools_result.instruments)} GitHub)")

        # Construct dialog historical past
        system_prompt = f"""You're a senior software program engineer with entry to the repository {repo}.
Use the out there instruments to research points, learn code, write fixes, and create pull requests.
Suppose step-by-step. Learn earlier than you modify. Minimal modifications solely."""

        messages = (
            {"position": "system",  "content material": system_prompt},
            {"position": "consumer",    "content material": process},
        )

        # ── Agent loop ─────────────────────────────────────────────────────────
        for flip in vary(max_turns):
            print(f"n(Flip {flip + 1})")

            # Name the mannequin
            response = await consumer.chat.completions.create(
                mannequin=MODEL,
                messages=messages,
                instruments=all_tools if all_tools else None,
                tool_choice="auto",
                # Pondering mode sampling params from the official greatest practices
                temperature=0.6,
                top_p=0.95,
                top_k=20,
                min_p=0.0,
                max_tokens=4096,
                extra_body={
                    # preserve_thinking retains reasoning context throughout turns
                    # for KV cache effectivity on lengthy agent periods
                    "preserve_thinking": True,
                }
            )

            consequence = process_response(response, preserve_thinking=True)

            if consequence("considering"):
                print(f"(considering) {consequence('considering')(:200)}...")

            # Terminal state -- agent has produced a ultimate reply
            if consequence("is_terminal"):
                print(f"n(DONE)n{consequence('final_answer')}")
                return consequence("final_answer")

            # Instrument name state -- execute every software and inject outcomes
            if consequence("has_tool_calls"):
                # Append the assistant's message with software calls to historical past
                messages.append({
                    "position":       "assistant",
                    "content material":    response.selections(0).message.content material or "",
                    "tool_calls": response.selections(0).message.tool_calls or (),
                })

                for name in consequence("tool_calls"):
                    tool_name = name("identify")
                    tool_args = name.get("arguments", {})
                    call_id   = name.get("call_id", "")

                    print(f"(software) {tool_name}({json.dumps(tool_args)(:80)}...)")

                    session = tool_to_session.get(tool_name)
                    if not session:
                        result_content = f"Error: software '{tool_name}' not discovered"
                    else:
                        strive:
                            tool_result = await session.call_tool(tool_name, tool_args)
                            result_content = str(tool_result.content material)
                            # Truncate very lengthy outcomes to guard context price range
                            if len(result_content) > 12000:
                                result_content = result_content(:12000) + "n...(truncated)"
                        besides Exception as e:
                            result_content = f"Error: {e}"

                    print(f"(consequence) {result_content(:150)}...")

                    messages.append({
                        "position":        "software",
                        "content material":     result_content,
                        "tool_call_id": call_id,
                        "identify":        tool_name,
                    })

        print(f"(WARNING) max_turns ({max_turns}) reached with out terminal state")


# ── Entry level ───────────────────────────────────────────────────────────────

if __name__ == "__main__":
    asyncio.run(run_github_agent(
        process=(
            "Discover the open subject concerning the login endpoint returning 200 for invalid tokens. "
            "Learn src/auth.py and checks/test_auth.py to grasp the bug. "
            "Repair the verify_token operate and open a pull request together with your modifications."
        ),
        repo="myorg/my-api-project",
    ))

So führen Sie aus:

python github_agent_raw.py

Der rohe SDK-Pfad bietet Ihnen, was Qwen-Agent abstrahiert: Sie können jeden Instrument-Aufruf, jedes Ergebnis und jede in den Konversationsverlauf eingefügte Nachricht sehen. Der tool_to_session Routing-Dikt ist der Schlüsselmechanismus; Es ordnet den Namen jedes Instruments der MCP-Sitzung zu, zu der es gehört, sodass der Agent jedes Instrument von jedem verbundenen Server aus aufrufen kann, ohne zu wissen, welcher Server es bereitstellt.

# Schreiben eines benutzerdefinierten MCP-Servers

Vorgefertigte MCP-Server verwalten das Dateisystem und GitHub. Wenn Sie etwas benötigen, das nicht existiert – eine interne Datenbank abfragen, eine CI/CD-API umschließen, Code-Analysetools ausführen – schreiben Sie einen MCP-Server. Hier ist eine komplette code_quality Server, der verfügbar macht ruff Und pytest als MCP-Instruments.

# code_quality_server.py
# A customized MCP server exposing code high quality instruments to Qwen3.6.
#
# Conditions:
#   pip set up mcp ruff pytest
#
# Find out how to run standalone (for testing):
#   python code_quality_server.py
#
# So as to add to the Qwen-Agent config:
#   "code_quality": {
#       "command": "python",
#       "args": ("/absolute/path/to/code_quality_server.py")
#   }

import asyncio
import json
import subprocess
import sys
from mcp.server.fastmcp import FastMCP

# FastMCP is a high-level MCP server framework -- reduces boilerplate considerably
mcp = FastMCP("code_quality")


@mcp.software()
def run_linter(file_path: str, repair: bool = False) -> str:
    """
    Run ruff linter on a Python file and return structured lint outcomes.
    Use this earlier than modifying a file to grasp its present high quality state,
    and after making modifications to confirm the repair didn't introduce new points.

    Args:
        file_path: Absolute or relative path to the Python file to lint.
        repair:       If true, routinely repair secure points in place.

    Returns:
        JSON string with points record, subject rely, and recordsdata modified.
    """
    cmd = ("python", "-m", "ruff", "examine", file_path, "--output-format=json")
    if repair:
        cmd.append("--fix")

    strive:
        consequence = subprocess.run(cmd, capture_output=True, textual content=True, timeout=30)
        # ruff returns exit code 1 when points are discovered -- not an error
        output = consequence.stdout or consequence.stderr

        # Parse ruff's JSON output
        strive:
            points = json.hundreds(output) if output.strip() else ()
        besides json.JSONDecodeError:
            points = ()

        formatted = (
            {
                "line":    subject.get("location", {}).get("row", 0),
                "col":     subject.get("location", {}).get("column", 0),
                "code":    subject.get("code", ""),
                "message": subject.get("message", ""),
                "fix_available": subject.get("repair") will not be None,
            }
            for subject in points
            if isinstance(subject, dict)
        )

        return json.dumps({
            "file":         file_path,
            "points":       formatted,
            "total_issues": len(formatted),
            "fastened":        "auto-fix utilized" if repair else "no auto-fix",
        }, indent=2)

    besides subprocess.TimeoutExpired:
        return json.dumps({"error": "Linter timed out after 30s", "file": file_path})
    besides FileNotFoundError:
        return json.dumps({"error": "ruff not discovered -- set up with: pip set up ruff"})


@mcp.software()
def run_tests(goal: str, verbose: bool = False) -> str:
    """
    Run pytest on a module or listing and return structured go/fail outcomes.
    Use this after writing a repair to confirm the repair makes failing checks go
    with out breaking different checks.

    Args:
        goal:  Path to the take a look at file or listing to run (e.g. checks/, checks/test_auth.py)
        verbose: If true, embody full pytest output within the consequence.

    Returns:
        JSON string with go rely, fail rely, failure particulars, and period.
    """
    cmd = ("python", "-m", "pytest", goal, "--json-report", "--json-report-file=-", "-q")
    if verbose:
        cmd.append("-v")

    strive:
        consequence = subprocess.run(cmd, capture_output=True, textual content=True, timeout=120)
        output = consequence.stdout

        # Parse pytest-json-report output if out there
        strive:
            report = json.hundreds(output)
            abstract  = report.get("abstract", {})
            failures = (
                {
                    "take a look at":    t("nodeid"),
                    "message": t.get("name", {}).get("longrepr", "")(:500),
                }
                for t in report.get("checks", ())
                if t.get("end result") == "failed"
            )
            return json.dumps({
                "goal":   goal,
                "handed":   abstract.get("handed", 0),
                "failed":   abstract.get("failed", 0),
                "errors":   abstract.get("error", 0),
                "complete":    abstract.get("complete", 0),
                "period": abstract.get("period", 0),
                "failures": failures,
                "stdout":   consequence.stdout(:2000) if verbose else "",
            }, indent=2)

        besides json.JSONDecodeError:
            # Fallback: return uncooked output if JSON report not out there
            return json.dumps({
                "goal":  goal,
                "stdout":  consequence.stdout(:3000),
                "stderr":  consequence.stderr(:1000),
                "exit_code": consequence.returncode,
            })

    besides subprocess.TimeoutExpired:
        return json.dumps({"error": f"Exams timed out after 120s for goal: {goal}"})
    besides FileNotFoundError:
        return json.dumps({"error": "pytest not discovered -- set up with: pip set up pytest"})


if __name__ == "__main__":
    mcp.run(transport="stdio")

Fügen Sie es der Serverkonfiguration einer der Agentenimplementierungen hinzu:

# In Qwen-Agent MCP_SERVERS dict:
"code_quality": {
    "command": "python",
    "args": ("/absolute/path/to/code_quality_server.py")
}

# Within the uncooked SDK, add a 3rd StdioServerParameters:
cq_params = StdioServerParameters(
    command="python",
    args=("/absolute/path/to/code_quality_server.py"),
)

Testen Sie den Standalone-Server, bevor Sie den Agenten verbinden:

# Check the server in MCP inspector mode
npx @modelcontextprotocol/inspector python code_quality_server.py
# Opens a browser UI the place you may name run_linter and run_tests immediately

# Den Denkmodus optimieren und das Denken bewahren

Die Entscheidung über den Denkmodus wirkt sich so stark auf die Latenz aus, dass es sich lohnt, sie als explizite Architekturwahl und nicht als nachträglichen Gedanken zu behandeln.

Im Denkmodus generiert Qwen3.6 eine Gedankenkette im Inneren ... Tags, bevor die Aktion ausgeführt wird. Bei einer 5-stufigen Agentenaufgabe fügt diese Ablaufverfolgung je nach Aufgabenkomplexität 1.000 bis 5.000 Token professional Runde hinzu. Es dauert einige Zeit, bis diese Token ein Kontextbudget generieren und verbrauchen.

Wenn sich diese Kosten lohnen:

• Planungsschritte, bei denen der Agent entscheidet, was als nächstes zu tun ist.
• Debugging-Sitzungen, bei denen das Downside wirklich nicht eindeutig ist.
• Refactoring mehrerer Dateien, bei dem der Agent über dateiübergreifende Nebenwirkungen nachdenken muss.

Der Reasoning Hint erkennt Fehler, bevor sie zu Toolaufrufen mit falschen Argumenten werden. Wenn es sich nicht lohnt zu bezahlen: mechanische Werkzeugaufrufschleifen, bei denen jeder Schritt eindeutig ist – Listenverzeichnis → Datei lesen → Datei schreiben → Festschreiben. Das Modell muss nicht lange über diese Schritte nachdenken. Der Nicht-Denkmodus ist schneller und erzeugt die gleiche Ausgabequalität.

Wechseln Sie den Modus professional Anfrage, nicht international:

# Pondering mode (planning, debugging, complicated multi-file duties)
THINKING_PARAMS = {
    "temperature": 0.6,
    "top_p":       0.95,
    "top_k":       20,
    "min_p":       0.0,
}

# Non-thinking mode (mechanical loops, quick standing checks)
# Cross enable_thinking=False within the chat template, or use system immediate:
# Add "/no_think" to the system immediate to suppress considering mode.
NON_THINKING_PARAMS = {
    "temperature": 0.7,
    "top_p":       0.8,
    "top_k":       20,
    "min_p":       0.0,
}

Der preserve_thinking Flag – die Qwen3.6-spezifische Funktion, die den Argumentationskontext über Runden hinweg beibehält – wirkt sich direkt auf die Inferenzeffizienz aus, wenn das Präfix-Caching aktiv ist. Deshalb ist es praktisch wichtig: In einer Agentensitzung mit 10 Runden teilt sich jede Runde ein Präfix des Gesprächsverlaufs. Wann preserve_thinking=Truebleibt die vollständige Argumentationsspur aus früheren Runden im Verlauf. Der KV-Cache auf der Serverseite erkennt das gemeinsame Präfix über Runden hinweg und vermeidet eine Neuberechnung. Die effektive Token-pro-Sekunde-Fee für lange Sitzungen ist deutlich höher als ohne, insbesondere wenn Infrastrukturen wie SGLang damit bedient werden --enable-prefix-caching läuft.

Die praktische Regel: nutzen preserve_thinking=True für Agentensitzungen, die länger als 5 Runden dauern. Verwenden preserve_thinking=False (oder Nicht-Denkmodus) für Single-Flip-Abfragen und kurze Pipelines, bei denen der Overhead verschwendet wird.

# Abschluss

Die MoE-Architektur von Qwen3.6-35B-A3B bietet Ihnen eine 35B-Modellqualität bei 3B-Aktivierungskosten. Das 262 KB große Kontextfenster bietet Ihnen Platz, um eine gesamte Codeüberprüfungssitzung im Kontext durchzuführen. Durch die explizite Schulung zu MCP-basierten Agenten-Benchmarks weiß es, wie man Instruments richtig nutzt und nicht nur aufruft.

MCP liefert das Bindegewebe. Definieren Sie ein Instrument einmalig als MCP-Server. Jede Qwen3.6-Sitzung und jedes andere MCP-kompatible Modell kann es ohne benutzerdefinierten Kleber entdecken und aufrufen. Die GitHub- und Dateisystemserver in diesem Artikel sind zwei von Hunderten vorgefertigten Servern im MCP-Ökosystem. Der Brauch code_quality Der Server zeigt das Muster für alles an, was noch nicht vorhanden ist.

Der GitHub-Entwicklerassistent in diesem Artikel ist eine Anwendung des Musters. Dieselbe Architektur – lokales Modell, MCP-Instruments und Agentenschleife – funktioniert für einen Forschungsassistenten, der akademische Datenbanken durchsucht und Literaturrezensionen erstellt, einen DevOps-Agenten, der CloudWatch-Protokolle liest und Vorfalltickets öffnet, oder einen Datenpipeline-Agenten, der SQL-Schemas liest, Transformationscode schreibt und Ausgaben validiert. Das MCP-Ökosystem wächst schnell. Die lokale Modellfähigkeit ist bereits vorhanden.

Shittu Olumide ist ein Software program-Ingenieur und technischer Autor, der sich leidenschaftlich dafür einsetzt, modernste Technologien zu nutzen, um fesselnde Erzählungen zu erschaffen, mit einem scharfen Blick fürs Element und einem Gespür für die Vereinfachung komplexer Konzepte. Sie können Shittu auch auf finden Twitter.

Clawdbot ist ein persönlicher Open-Supply-KI-Assistent, den Sie auf Ihrer eigenen {Hardware} ausführen. Es verbindet große Sprachmodelle von Anbietern wie Anthropic und OpenAI mit echten Instruments wie Messaging-Apps, Dateien, Shell, Browser und Sensible-Dwelling-Geräten und behält dabei die Kontrolle über die Orchestrierungsebene.

Das Interessante daran ist nicht Clawdbot Chats. Das Projekt liefert eine konkrete Architektur für lokale Erstagenten und eine typisierte Workflow-Engine namens Lobster, die Modellaufrufe in deterministische Pipelines umwandelt.

Architektur: Gateway, Knoten und Fähigkeiten

Im Zentrum von Clawdbot steht der Gateway-Prozess. Das Gateway stellt eine WebSocket-Steuerungsebene bereit ws://127.0.0.1:18789 und eine lokale HTTP-Schnittstelle für die Steuerungs-Benutzeroberfläche und den Internet-Chat.

Ihre Nachrichten von WhatsApp, Telegram, Sign, Slack, Discord, iMessage und anderen Kanälen werden an das Gateway übermittelt. Das Gateway entscheidet, welcher Agent die Nachricht verarbeiten soll, welche Instruments es aufrufen darf und welcher Modellanbieter verwendet werden soll. Anschließend sendet es die Antwort über denselben Kanal zurück.

Die Laufzeit ist in einige Kernkonzepte unterteilt:

• Tor: Routing, Modellaufrufe, Toolaufruf, Sitzungen, Anwesenheit und Planung.
• Knoten: Prozesse, die Clawdbot Zugriff auf lokale Ressourcen wie Dateisystem, Browserautomatisierung, Mikrofon, Kamera oder plattformspezifische APIs auf macOS, Home windows, Linux, iOS und Android gewähren.
• Kanäle: Integrationen für Chat-Systeme wie WhatsApp, Telegram, Discord, Slack, Sign, Microsoft Groups, Matrix, Zalo und mehr. Diese werden als Kanal-Backends konfiguriert, die an das Gateway angeschlossen werden.
• Fähigkeiten und Plugins: Werkzeuge, die der Agent aufrufen kann, beschrieben in einem Customary SKILL.md formatiert und über ClawdHub verteilt.

Durch diese Trennung können Sie das Gateway auf einem fünf Greenback teuren virtuellen Server oder einer Ersatzmaschine zu Hause ausführen, während Sie bei Bedarf die umfangreiche Modellberechnung auf Distant-APIs oder lokalen Modell-Backends behalten.

Fähigkeiten und die SKILL.md Customary

Clawdbot verwendet ein offenes Kompetenzformat, das in beschrieben wird SKILL.md. Ein Talent wird in Markdown mit einem kleinen Header und einer geordneten Prozedur definiert. Beispielsweise kann ein Bereitstellungs-Talent Schritte wie das Überprüfen des Git-Standing, das Ausführen von Assessments und das Bereitstellen erst nach Erfolg festlegen.

---
title: deploy-production
description: Deploy the present department to manufacturing. Use solely after assessments move.
disable-model-invocation: true
---
1. Test git standing making certain clear working listing.
2. Run `npm take a look at`
3. If assessments move, run `npm run deploy`

Das Gateway liest diese Definitionen und stellt sie den Agenten als Instruments mit expliziten Funktionen und Sicherheitsbeschränkungen zur Verfügung. Fertigkeiten werden auf ClawdHub veröffentlicht und können in größeren Arbeitsabläufen installiert oder zusammengestellt werden.

Das bedeutet, dass operative Runbooks von Advert-hoc-Wiki-Seiten in maschinenausführbare Abilities übergehen können, während sie weiterhin als Textual content überprüfbar sind.

Lobster: Typisierte Workflow-Laufzeit für Agenten

Lobster ist die Workflow-Laufzeitumgebung, die Native Lobster und viele erweiterte Clawdbot-Automatisierungen unterstützt. Es wird als typisierte Workflow-Shell beschrieben, die es Clawdbot ermöglicht, mehrstufige Werkzeugsequenzen als einen einzigen deterministischen Vorgang mit expliziten Genehmigungs-Gates auszuführen.

Anstatt dass das Modell viele Instruments in einer Schleife aufruft, verschiebt Lobster die Orchestrierung in eine kleine domänenspezifische Laufzeit:

• Pipelines werden als JSON oder YAML oder als kompakte Shell-ähnliche Pipeline-Zeichenfolge definiert.
• Schritte tauschen typisierte JSON-Daten aus, keinen unstrukturierten Textual content.
• Die Laufzeit erzwingt Zeitüberschreitungen, Ausgabelimits und Sandbox-Richtlinien.
• Arbeitsabläufe können aufgrund von Nebenwirkungen angehalten und später wieder aufgenommen werden resumeToken.

Ein einfacher Workflow für die Sortierung des Posteingangs sieht folgendermaßen aus:

title: inbox-triage
steps:
  - id: gather
    command: inbox record --json
  - id: categorize
    command: inbox categorize --json
    stdin: $gather.stdout
  - id: approve
    command: inbox apply --approve
    stdin: $categorize.stdout
    approval: required
  - id: execute
    command: inbox apply --execute
    stdin: $categorize.stdout
    situation: $approve.accepted

Clawdbot behandelt diese Datei als Fähigkeit. Wenn Sie es auffordern, Ihren Posteingang zu bereinigen, ruft es eine Lobster-Pipeline auf, anstatt viele Instrument-Aufrufe zu improvisieren. Das Modell entscheidet Wann um die Pipeline auszuführen und mit welchen Parametern, aber die Pipeline selbst bleibt deterministisch und überprüfbar.

Native Lobster ist der Referenzagent, der Lobster verwendet, um lokale Arbeitsabläufe voranzutreiben, und wird in der Berichterstattung als Open-Supply-Agent beschrieben, der persönliche KI neu definiert, indem er lokale erste Arbeitsabläufe mit proaktivem Verhalten kombiniert.

Proaktives lokales Erstverhalten

Ein Hauptgrund dafür, dass Clawdbot auf

Da das Gateway geplante Jobs ausführen und den Standing sitzungsübergreifend verfolgen kann, gehören zu den gängigen Mustern:

• Tägliche Briefings, die Kalender, Aufgaben und wichtige E-Mails zusammenfassen.
• Regelmäßige Zusammenfassungen wie wöchentlich versandte Arbeitszusammenfassungen.
• Überwacht die Bedingungen und sendet Ihnen dann zunächst eine Nachricht auf Ihrem bevorzugten Kanal.
• Datei- und Repository-Automatisierungen, die lokal ausgeführt werden, aber durch natürliche Sprache ausgelöst werden.

All dies läuft mit Routing- und Instrument-Richtlinien auf Ihrem Pc oder Server. Modellaufrufe gehen immer noch an Anbieter wie Anthropic, OpenAI, Google, xAI oder lokale Backends, aber das Assistentengehirn, der Speicher und die Integrationen unterliegen Ihrer Kontrolle.

Installations- und Entwicklerworkflow

Das Projekt stellt ein einzeiliges Installationsprogramm bereit, das ein Skript abruft clawd.bot und Bootstraps-Knoten, das Gateway und Kernkomponenten. Für mehr Kontrolle können Sie über npm installieren oder das TypeScript-Repository klonen und mit pnpm erstellen.

Typische Schritte:

curl -fsSL https://clawd.bot/set up.sh | bash

# or

npm i -g clawdbot
clawdbot onboard

Nach dem Onboarding verbindest du einen Kanal wie Telegram oder WhatsApp, wählst einen Modellanbieter aus und aktivierst Abilities. Von dort aus können Sie Ihre eigenen schreiben SKILL.md Dateien, erstellen Sie Lobster-Workflows und stellen Sie sie über Chat, Internet-Chat oder die macOS-Begleitanwendung bereit.

Einige Beispiele

Clawdbot hatte gerade Ollama mit einem lokalen Modell eingerichtet. Jetzt werden Web site-Zusammenfassungen und einfache Aufgaben lokal verarbeitet, anstatt API-Credit zu verbrennen.

Es hat mich umgehauen, dass eine KI gerade eine andere KI installiert hat, um mir Geld zu sparen. pic.twitter.com/RRvXQAgBfX

— Max (@talkaboutdesign) 25. Januar 2026

Clawdbot steuert LMStudio aus der Ferne über Telegram und lädt Qwen herunter, das es dann verwendet, um einige meiner Aufgaben mit Clawdbot auszuführen. pic.twitter.com/ll2adg19Za

— Matthew Berman (@MatthewBerman) 25. Januar 2026

Clawdbot nimmt jetzt eine Idee auf, verwaltet Codex und Claude, debattiert sie autonom in Rezensionen und lässt mich wissen, wenn es fertig ist.

Toll. Eine ganze Funktion, die während eines Spaziergangs eingesetzt wird. pic.twitter.com/ws3UDQG2S0

— Aaron Ng (@localghost) 25. Januar 2026

Michal Sutter ist ein Knowledge-Science-Experte mit einem Grasp of Science in Knowledge Science von der Universität Padua. Mit einer soliden Grundlage in statistischer Analyse, maschinellem Lernen und Datentechnik ist Michal hervorragend darin, komplexe Datensätze in umsetzbare Erkenntnisse umzuwandeln.

Schon als Form struggle ich vom Zeichnen fasziniert. Was mich beeindruckte, struggle nicht nur der Zeichenakt selbst, sondern auch die Idee, dass jede Zeichnung immer weiter verbessert werden konnte. Ich erinnere mich, dass ich mit meinem Zeichenstil ein sehr hohes Niveau erreicht habe. Sobald ich jedoch den Höhepunkt der Perfektion erreicht hatte, würde ich versuchen, die Zeichnung noch weiter zu verbessern – leider mit katastrophalen Ergebnissen.

Von da an behalte ich immer das gleiche Mantra im Hinterkopf: „Verfeinere und iteriere und du wirst Perfektion erreichen.“ An der Universität bestand mein Ansatz darin, Bücher viele Male zu lesen und mein Wissen auf der Suche nach anderen Quellen zu erweitern, um in jedem Konzept verborgene Bedeutungsebenen zu finden. Heute wende ich dieselbe Philosophie auf KI/ML und Codierung an.

Wir wissen, dass die Matrixmultiplikation (der Einfachheit halber hier Matmul) der Kernbestandteil jedes KI-Prozesses ist. In der Vergangenheit habe ich mich weiterentwickelt LLM.rustein Rostspiegel von Karpathy LLM.c. Der schwierigste Punkt bei der Rust-Implementierung struggle die Matrixmultiplikation. Da wir zur Feinabstimmung eines GPT-basierten Modells Tausende von Iterationen durchführen müssen, benötigen wir eine effiziente Matmul-Operation. Zu diesem Zweck musste ich die BLAS-Bibliothek verwenden und eine implementieren unsafe Strategie zur Überwindung von Grenzen und Barrieren. Die Verwendung von unsafe in Rust widerspricht der Philosophie von Rust, deshalb suche ich in diesem Zusammenhang immer nach sichereren Methoden zur Verbesserung von matmul.

Inspiriert von Sam Altmans Aussage „Fragen Sie GPT, wie man Werte schafft“ beschloss ich, lokale LLMs zu bitten, ihre eigenen Algorithmen zu generieren, zu vergleichen und zu iterieren, um eine bessere, native Rust-Matmul-Implementierung zu erstellen.

Die Herausforderung unterliegt einigen Einschränkungen:

• Wir müssen unsere lokale Umgebung nutzen. In meinem Fall ein MacBook Professional, M3, 36 GB RAM;
• Überwinden Sie die Grenzen von Token;
• Zeit und Benchmarking des Codes innerhalb der Generierungsschleife selbst

Ich weiß, dass es mit dieser Methode quick unmöglich ist, Leistungen auf BLAS-Niveau zu erreichen, aber ich möchte hervorheben, wie wir KI für individuelle Anforderungen nutzen können, selbst mit unseren „winzigen“ Laptops, damit wir Ideen freisetzen und Grenzen in jedem Bereich verschieben können. Dieser Beitrag soll eine Inspiration für Praktiker und Menschen sein, die sich mit Microsoft Autogen und der lokalen LLM-Bereitstellung vertraut machen möchten.

Die gesamte Cod-Implementierung finden Sie hier Github-Repo. Dies ist ein fortlaufendes Experiment und es werden viele Änderungen/Verbesserungen vorgenommen.

Allgemeine Idee

Die Gesamtidee besteht darin, einen runden Tisch mit Agenten zu veranstalten. Ausgangspunkt ist die MrAderMacher Mixtral 8x7B Modell This fall K_M lokales Modell. Aus dem Modell erstellen wir 5 Entitäten:

• Die Proposer entwickelt einen neuen Strassen-ähnlichen Algorithmus, um eine bessere und effizientere Methode zur Durchführung von Matmul zu finden;
• Die Verifier überprüft die Matmul-Formulierung durch symbolische Mathematik;
• Die Coder erstellt den zugrunde liegenden Rust-Code;
• Die Tester führt es aus und speichert alle Informationen in der Vektordatenbank;
• Die Supervisor agiert lautlos und kontrolliert den gesamten Arbeitsablauf.

Der gesamte Arbeitsablauf kann über Microsoft Autogen orchestriert werden, wie in Abb. 1 dargestellt.

Bereiten Sie die Eingabedaten und die Vektordatenbank vor

Die Eingabedaten werden aus allen wissenschaftlichen Arbeiten gesammelt, die sich auf die Optimierung der Matrixmultiplikation konzentrieren. Auf viele dieser Veröffentlichungen wird verwiesen in und sie beziehen sich auf DeepMinds Strassen-Artikel. Ich möchte einfach anfangen und habe 50 Artikel gesammelt, die zwischen 2020 und 2025 veröffentlicht wurden und sich speziell mit der Matrixmultiplikation befassen.

Als nächstes habe ich verwendet chroma um die Vektordatenbank zu erstellen. Der entscheidende Aspekt bei der Erstellung einer neuen Vektordatenbank ist die Artwork und Weise, wie die PDFs aufgeteilt werden. In diesem Zusammenhang habe ich a verwendet semantisch chunkeR. Im Gegensatz zu Break up-Textual content-Methoden verwendet der semantische Chunker die tatsächliche Bedeutung des Textes, um zu bestimmen, wo geschnitten werden soll. Das Ziel besteht darin, die zusammengehörigen Sätze in einem Block zusammenzuhalten, wodurch die endgültige Vektordatenbank kohärenter und genauer wird. Dies geschieht mithilfe des lokalen Modells BAAI/bge-base-en-v1.5. Der Github-Gist unten zeigt die vollständige Implementierung.

Der Kerncode: autogen-core und GGML-Modelle

Ich habe Microsoft Autogen verwendet, insbesondere das autogen-core Variante (Model 0.7.5). Anders als beim übergeordneten Chat, in autogen-core Wir können auf ereignisgesteuerte Low-Stage-Bausteine ​​zugreifen, die erforderlich sind, um einen zustandsmaschinengesteuerten Workflow nach Bedarf zu erstellen. Tatsächlich besteht die Herausforderung darin, einen strikten Arbeitsablauf aufrechtzuerhalten. Alle handelnden Agenten müssen in einer bestimmten Reihenfolge handeln: Proposer –> Verifier –> Coder –> Tester.

Der Kernteil ist der BaseMatMulAgentdas von AutoGen erbt RoutedAgent. Mit dieser Basisklasse können wir standardisieren, wie LLM-Agenten am Chat teilnehmen und sich verhalten.

Aus dem obigen Code können wir ersehen, dass die Klasse für die Teilnahme an einem asynchronen Gruppenchat konzipiert ist, den Gesprächsverlauf verarbeitet, externe Instruments aufruft und Antworten über das lokale LLM generiert.

Die Kernkomponente ist @message_handlerein Dekorator, der eine Methode registriert als listener oder subscriber basierend auf dem Nachrichtentyp. Der Dekorator erkennt automatisch den Typhinweis des Arguments der ersten Methode – in unserem Fall message: GroupChatMessage. Anschließend abonniert es den Agenten für den Empfang aller Ereignisse dieses Typs, die an das Thema des Agenten gesendet werden. Der handle_message Die async-Methode ist dann für die Aktualisierung des internen Speichers des Agenten verantwortlich, ohne eine Antwort zu generieren.

Wenn der Listener-Subscriber-Mechanismus vorhanden ist, können wir uns auf die Supervisor-Klasse konzentrieren. Der MatMulManager erbt RoutedAgent und orchestriert den gesamten Agentenfluss.

Der obige Code verwaltet alle Agenten. Wir überspringen das Verifier Teil, für den Second. Der Coder Veröffentlichen Sie den endgültigen Code und die Tester kümmert sich darum, sowohl den Code als auch den gesamten Kontext in der Vector-Datenbank zu speichern. Auf diese Weise können wir vermeiden, alle Token unseres lokalen Modells zu verbrauchen. Bei jedem neuen Lauf holt sich das Modell die zuletzt generierten Algorithmen aus der Vektordatenbank ein und schlägt eine neue Lösung vor.

Ein sehr wichtiger Vorbehalt, um sicherzugehen autogen-core kann damit arbeiten llama Modelle unter MacOS verwenden Sie das folgende Snippet:

#!/bin/bash 

CMAKE_ARGS="-DGGML_METAL=on" FORCE_CMAKE=1 pip set up --upgrade --verbose --force-reinstall llama-cpp-python --no-cache-dir

Abb.2 fasst den gesamten Code zusammen. Wir können den Code grob in 3 Hauptblöcke unterteilen:

• Der BaseAgentdas Nachrichten über die Agenten von LLM verarbeitet, die mathematische Formulierung auswertet und Code generiert;
• Der MatMulManager orchestriert den gesamten Agentenfluss;
• autogen_core.SingleThreadedAgentRuntime ermöglicht es uns, den gesamten Workflow in die Realität umzusetzen.

Ergebnisse und Benchmark

Der gesamte Rust-Code wurde überarbeitet und manuell erneut ausgeführt. Obwohl der Arbeitsablauf strong ist, erfordert die Arbeit mit LLMs ein kritisches Auge. Mehrmals konfabulierte das Modell^*wodurch Code generiert wurde, der optimiert aussah, aber die eigentliche Matmul-Arbeit nicht ausführen konnte.

Die allererste Iteration generiert eine Artwork Strassen-ähnlichen Algorithmus („Run 0“-Code in Abb. 3):

Das Modell überlegt sich bessere Implementierungen, die eher Rust-NEON ähneln, sodass es nach 4 Iterationen den folgenden Code liefert („Run 3“ in Abb. 3):

Wir können die Verwendung von Funktionen sehen wie vaddq_f32spezifische CPU-Anweisung für ARM-Prozessoren, stammt von std::arch::aarch64. Das Modell schafft es zu verwenden rayon um den Workflow auf mehrere CPU-Kerne aufzuteilen und innerhalb der parallelen Threads NEON-Intrinsics zu verwenden. Der Code selbst ist nicht ganz korrekt, außerdem ist mir aufgefallen, dass beim Umgang mit 1024×1024-Matrizen ein Fehler wegen unzureichendem Arbeitsspeicher auftritt. Ich musste den Code manuell überarbeiten, damit er funktionierte.

Dies bringt uns zurück zu unserem Mantra „Iteration bis zur Perfektion“ und wir können uns fragen: „Kann ein lokaler Agent den Rust-Code autonom verfeinern, bis er komplexe NEON-Intrinsics beherrscht?“ Die Ergebnisse zeigen, dass dieser Optimierungsgrad sogar auf Client-{Hardware} erreichbar ist.

Abb. 3 zeigt die Endergebnisse, die ich nach jeder Iteration erhalten habe.

Der 0. und 2. Benchmark weisen einige Fehler auf, da es physikalisch unmöglich ist, solche Ergebnisse auf einem 1024×1024-Matmul auf einer CPU zu erzielen:

• Der erste Code leidet unter einem Diagonalfehler, sodass der Code nur diagonale Blöcke der Matrix berechnet und den Relaxation ignoriert.
• Der zweite Code hat einen defekten Puffer, da er wiederholt einen kleinen, im Cache befindlichen Puffer mit 1028 Floats überschreibt, anstatt die gesamten 1 Million Elemente zu durchlaufen.

Der Code erzeugte jedoch zwei echte Codes, den Lauf 1 und den Lauf 3. Die erste Iteration erreicht 760 ms und stellt eine echte Basislinie dar. Es leidet unter Cache-Fehlern und mangelnder SIMD-Vektorisierung. Der Lauf 3 zeichnet 359 ms auf, die Verbesserung ist die Implementierung von NEON SIMD und Rayon-Parallelität.

*: „Das Modell konfabuliert“ habe ich aus bestimmten Gründen geschrieben. Aus medizinischer Sicht sind alle LLMs keine Halluzinationen, sondern Konfabulationen. Halluzinationen sind eine völlig andere State of affairs im Vergleich zu dem, was LLMs tun, wenn sie plappern und „falsche“ Antworten generieren.

Schlussfolgerungen

Dieses Experiment begann mit einer Frage, die eine unmögliche Herausforderung zu sein schien: „Können wir lokale LLMs für Verbraucher verwenden, um leistungsstarke Rust-Algorithmen zu entdecken, die mit der BLAS-Implementierung konkurrieren können?“

Wir können ja sagen, oder zumindest verfügen wir über einen gültigen und soliden Hintergrund, mit dem wir besseren Code erstellen können, um einen vollständigen BLAS-ähnlichen Code in Rust zu erreichen.

Der Beitrag zeigte, wie man mit Microsoft Autogen interagiert, autogen-coreund wie man einen Runden Tisch mit Agenten erstellt.

Das verwendete Basismodell stammt von GGUF und läuft auf einem MacBook Professional M3, 36 GB.

Natürlich haben wir (noch) nichts Besseres als BLAS in einem einzigen einfachen Code gefunden. Wir haben jedoch bewiesen, dass der lokale Agenten-Workflow auf einem MacBook Professional das erreichen kann, was bisher für einen riesigen Cluster und riesige Modelle gehalten wurde. Schließlich gelang es dem Modell, eine vernünftige Rust-NEON-Implementierung zu finden, „Führen Sie 3 oben aus“, die eine Geschwindigkeitssteigerung von über 50 % gegenüber der Commonplace-Rayon-Implementierung aufweist. Wir müssen hervorheben, dass die Spine-Implementierung KI-generiert struggle.

Die Grenze ist offen. Ich hoffe, dieser Blogbeitrag kann Sie dazu inspirieren, herauszufinden, welche Grenzen wir mit der lokalen LLM-Bereitstellung überwinden können.

Ich schreibe dies in persönlicher Eigenschaft; Diese Ansichten sind meine eigenen.

In diesem Tutorial erstellen wir einen selbstverifizierenden DataOps AIAgent, der Datenoperationen mithilfe lokaler Hugging Face-Modelle automatisch planen, ausführen und testen kann. Wir entwerfen den Agenten mit drei intelligenten Rollen: einem Planer, der eine Ausführungsstrategie erstellt, einem Executor, der Code mit Pandas schreibt und ausführt, und einem Tester, der die Ergebnisse auf Genauigkeit und Konsistenz validiert. Durch die lokale Verwendung des Phi-2-Modells von Microsoft in Google Colab stellen wir sicher, dass der Workflow effizient, reproduzierbar und datenschutzkonform bleibt, und demonstrieren gleichzeitig, wie LLMs komplexe Datenverarbeitungsaufgaben durchgängig automatisieren können. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

!pip set up -q transformers speed up bitsandbytes scipy
import json, pandas as pd, numpy as np, torch
from transformers import AutoTokenizer, AutoModelForCausalLM, pipeline, BitsAndBytesConfig


MODEL_NAME = "microsoft/phi-2"


class LocalLLM:
   def __init__(self, model_name=MODEL_NAME, use_8bit=False):
       print(f"Loading mannequin: {model_name}")
       self.tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
       if self.tokenizer.pad_token is None:
           self.tokenizer.pad_token = self.tokenizer.eos_token
       model_kwargs = {"device_map": "auto", "trust_remote_code": True}
       if use_8bit and torch.cuda.is_available():
           model_kwargs("quantization_config") = BitsAndBytesConfig(load_in_8bit=True)
       else:
           model_kwargs("torch_dtype") = torch.float32 if not torch.cuda.is_available() else torch.float16
       self.mannequin = AutoModelForCausalLM.from_pretrained(model_name, **model_kwargs)
       self.pipe = pipeline("text-generation", mannequin=self.mannequin, tokenizer=self.tokenizer,
                            max_new_tokens=512, do_sample=True, temperature=0.3, top_p=0.9,
                            pad_token_id=self.tokenizer.eos_token_id)
       print("✓ Mannequin loaded efficiently!n")


   def generate(self, immediate, system_prompt="", temperature=0.3):
       if system_prompt:
           full_prompt = f"Instruct: {system_prompt}nn{immediate}nOutput:"
       else:
           full_prompt = f"Instruct: {immediate}nOutput:"
       output = self.pipe(full_prompt, temperature=temperature, do_sample=temperature>0,
                          return_full_text=False, eos_token_id=self.tokenizer.eos_token_id)
       outcome = output(0)('generated_text').strip()
       if "Instruct:" in outcome:
           outcome = outcome.break up("Instruct:")(0).strip()
       return outcome

Wir installieren die erforderlichen Bibliotheken und laden das Phi-2-Modell lokal mithilfe von Hugging Face Transformers. Wir erstellen eine LocalLLM-Klasse, die den Tokenizer und das Modell initialisiert, optionale Quantisierung unterstützt und eine Generiermethode definiert, um Textausgaben zu erzeugen. Wir stellen sicher, dass das Modell sowohl auf der CPU als auch auf der GPU reibungslos läuft, sodass es sich superb für den Einsatz auf Colab eignet. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

PLANNER_PROMPT = """You're a Information Operations Planner. Create an in depth execution plan as legitimate JSON.


Return ONLY a JSON object (no different textual content) with this construction:
{"steps": ("step 1","step 2"),"expected_output":"description","validation_criteria":("standards 1","standards 2")}"""


EXECUTOR_PROMPT = """You're a Information Operations Executor. Write Python code utilizing pandas.


Necessities:
- Use pandas (imported as pd) and numpy (imported as np)
- Retailer remaining end in variable 'outcome'
- Return ONLY Python code, no explanations or markdown"""


TESTER_PROMPT = """You're a Information Operations Tester. Confirm execution outcomes.


Return ONLY a JSON object (no different textual content) with this construction:
{"handed":true,"points":("any points discovered"),"suggestions":("recommendations")}"""


class DataOpsAgent:
   def __init__(self, llm=None):
       self.llm = llm or LocalLLM()
       self.historical past = ()


   def _extract_json(self, textual content):
       strive:
           return json.hundreds(textual content)
       besides:
           begin, finish = textual content.discover('{'), textual content.rfind('}')+1
           if begin >= 0 and finish > begin:
               strive:
                   return json.hundreds(textual content(begin:finish))
               besides:
                   cross
       return None

Wir definieren die Systemeingabeaufforderungen für die Rollen Planner, Executor und Tester unseres DataOps-Agenten. Anschließend initialisieren wir die DataOpsAgent-Klasse mit Hilfsmethoden und einem JSON-Extraktionsdienstprogramm, um strukturierte Antworten zu analysieren. Wir bereiten die Grundlage für die Argumentations- und Ausführungspipeline des Agenten. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

 def plan(self, process, data_info):
       print("n" + "="*60)
       print("PHASE 1: PLANNING")
       print("="*60)
       immediate = f"Activity: {process}nnData Info:n{data_info}nnCreate an execution plan as JSON with steps, expected_output, and validation_criteria."
       plan_text = self.llm.generate(immediate, PLANNER_PROMPT, temperature=0.2)
       self.historical past.append(("PLANNER", plan_text))
       plan = self._extract_json(plan_text) or {"steps":(process),"expected_output":"Processed knowledge","validation_criteria":("Consequence generated","No errors")}
       print(f"n Plan Created:")
       print(f"  Steps: {len(plan.get('steps', ()))}")
       for i, step in enumerate(plan.get('steps', ()), 1):
           print(f"    {i}. {step}")
       print(f"  Anticipated: {plan.get('expected_output', 'N/A')}")
       return plan


   def execute(self, plan, data_context):
       print("n" + "="*60)
       print("PHASE 2: EXECUTION")
       print("="*60)
       steps_text="n".be a part of(f"{i}. {s}" for i, s in enumerate(plan.get('steps', ()), 1))
       immediate = f"Activity Steps:n{steps_text}nnData out there: DataFrame 'df'n{data_context}nnWrite Python code to execute these steps. Retailer remaining end in 'outcome' variable."
       code = self.llm.generate(immediate, EXECUTOR_PROMPT, temperature=0.1)
       self.historical past.append(("EXECUTOR", code))
       if "```python" in code: code = code.break up("```python")(1).break up("```")(0)
       elif "```" in code: code = code.break up("```")(1).break up("```")(0)
       traces = ()
       for line in code.break up('n'):
           s = line.strip()
           if s and (not s.startswith('#') or 'import' in s):
               traces.append(line)
       code="n".be a part of(traces).strip()
       print(f"n Generated Code:n" + "-"*60)
       for i, line in enumerate(code.break up('n')(:15),1):
           print(f"{i:2}. {line}")
       if len(code.break up('n'))>15: print(f"    ... ({len(code.break up('n'))-15} extra traces)")
       print("-"*60)
       return code

Wir implementieren die Planungs- und Ausführungsphasen des Agenten. Wir lassen den Planer detaillierte Aufgabenschritte und Validierungskriterien erstellen, und dann generiert der Ausführende den entsprechenden Python-Code basierend auf Pandas, um die Aufgabe auszuführen. Wir visualisieren, wie der Agent autonom von der Argumentation zur Generierung umsetzbaren Codes übergeht. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

def check(self, plan, outcome, execution_error=None):
       print("n" + "="*60)
       print("PHASE 3: TESTING & VERIFICATION")
       print("="*60)
       result_desc = f"EXECUTION ERROR: {execution_error}" if execution_error else f"Consequence kind: {kind(outcome).__name__}n"
       if not execution_error:
           if isinstance(outcome, pd.DataFrame):
               result_desc += f"Form: {outcome.form}nColumns: {checklist(outcome.columns)}nSample:n{outcome.head(3).to_string()}"
           elif isinstance(outcome, (int,float,str)):
               result_desc += f"Worth: {outcome}"
           else:
               result_desc += f"Worth: {str(outcome)(:200)}"
       criteria_text="n".be a part of(f"- {c}" for c in plan.get('validation_criteria', ()))
       immediate = f"Validation Standards:n{criteria_text}nnExpected: {plan.get('expected_output', 'N/A')}nnActual Consequence:n{result_desc}nnEvaluate if outcome meets standards. Return JSON with handed (true/false), points, and suggestions."
       test_result = self.llm.generate(immediate, TESTER_PROMPT, temperature=0.2)
       self.historical past.append(("TESTER", test_result))
       test_json = self._extract_json(test_result) or {"handed":execution_error is None,"points":("Couldn't parse check outcome"),"suggestions":("Overview manually")}
       print(f"n✓ Check Outcomes:n  Standing: {' PASSED' if test_json.get('handed') else ' FAILED'}")
       if test_json.get('points'):
           print("  Points:")
           for problem in test_json('points')(:3):
               print(f"    • {problem}")
       if test_json.get('suggestions'):
           print("  Suggestions:")
           for rec in test_json('suggestions')(:3):
               print(f"    • {rec}")
       return test_json


   def run(self, process, df=None, data_info=None):
       print("n SELF-VERIFYING DATA-OPS AGENT (Native HF Mannequin)")
       print(f"Activity: {process}n")
       if data_info is None and df is just not None:
           data_info = f"Form: {df.form}nColumns: {checklist(df.columns)}nSample:n{df.head(2).to_string()}"
       plan = self.plan(process, data_info)
       code = self.execute(plan, data_info)
       outcome, error = None, None
       strive:
           local_vars = {'pd': pd, 'np': np, 'df': df}
           exec(code, local_vars)
           outcome = local_vars.get('outcome')
       besides Exception as e:
           error = str(e)
           print(f"n  Execution Error: {error}")
       test_result = self.check(plan, outcome, error)
       return {'plan': plan,'code': code,'outcome': outcome,'check': test_result,'historical past': self.historical past}

Wir konzentrieren uns auf die Check- und Verifizierungsphase unseres Workflows. Wir lassen den Agenten seine eigene Ausgabe anhand vordefinierter Validierungskriterien bewerten und das Ergebnis als strukturiertes JSON zusammenfassen. Anschließend integrieren wir alle drei Phasen, Planung, Ausführung und Check, in einer einzigen selbstverifizierenden Pipeline, die eine vollständige Automatisierung gewährleistet. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

def demo_basic(agent):
   print("n" + "#"*60)
   print("# DEMO 1: Gross sales Information Aggregation")
   print("#"*60)
   df = pd.DataFrame({'product':('A','B','A','C','B','A','C'),
                      'gross sales':(100,150,200,80,130,90,110),
                      'area':('North','South','North','East','South','West','East')})
   process = "Calculate whole gross sales by product"
   output = agent.run(process, df)
   if output('outcome') is just not None:
       print(f"n Closing Consequence:n{output('outcome')}")
   return output


def demo_advanced(agent):
   print("n" + "#"*60)
   print("# DEMO 2: Buyer Age Evaluation")
   print("#"*60)
   df = pd.DataFrame({'customer_id':vary(1,11),
                      'age':(25,34,45,23,56,38,29,41,52,31),
                      'purchases':(5,12,8,3,15,7,9,11,6,10),
                      'spend':(500,1200,800,300,1500,700,900,1100,600,1000)})
   process = "Calculate common spend by age group: younger (underneath 35) and mature (35+)"
   output = agent.run(process, df)
   if output('outcome') is just not None:
       print(f"n Closing Consequence:n{output('outcome')}")
   return output


if __name__ == "__main__":
   print(" Initializing Native LLM...")
   print("Utilizing CPU mode for optimum compatibilityn")
   strive:
       llm = LocalLLM(use_8bit=False)
       agent = DataOpsAgent(llm)
       demo_basic(agent)
       print("nn")
       demo_advanced(agent)
       print("n" + "="*60)
       print(" Tutorial Full!")
       print("="*60)
       print("nKey Options:")
       print("  • 100% Native - No API calls required")
       print("  • Makes use of Phi-2 from Microsoft (2.7B params)")
       print("  • Self-verifying 3-phase workflow")
       print("  • Runs on free Google Colab CPU/GPU")
   besides Exception as e:
       print(f"n Error: {e}")
       print("Troubleshooting:n1. pip set up -q transformers speed up scipyn2. Restart runtimen3. Attempt a distinct mannequin")

Wir haben zwei Demobeispiele erstellt, um die Fähigkeiten des Agenten anhand einfacher Verkaufs- und Kundendatensätze zu testen. Wir initialisieren das Modell, führen den Information-Ops-Workflow aus und beobachten den gesamten Zyklus von der Planung bis zur Validierung. Wir schließen das Tutorial mit einer Zusammenfassung der wichtigsten Vorteile ab und ermutigen zu weiteren Experimenten mit lokalen Modellen.

Zusammenfassend haben wir ein vollständig autonomes und selbstverifizierendes DataOps-System erstellt, das auf einem lokalen Hugging Face-Modell basiert. Wir erleben, wie jede Part – Planung, Ausführung und Exams – nahtlos zusammenwirkt, um zuverlässige Ergebnisse zu erzielen, ohne auf Cloud-APIs angewiesen zu sein. Dieser Workflow unterstreicht die Stärke lokaler LLMs wie Phi-2 für eine leichte Automatisierung und inspiriert uns, diese Architektur in Zukunft für fortschrittlichere Datenpipelines, Validierungsframeworks und Multi-Agenten-Datensysteme zu erweitern.

Schauen Sie sich das an VOLLSTÄNDIGE CODES hier. Schauen Sie sich gerne bei uns um GitHub-Seite für Tutorials, Codes und Notebooks. Sie können uns auch gerne weiter folgen Twitter und vergessen Sie nicht, bei uns mitzumachen 100.000+ ML SubReddit und Abonnieren Unser Publication. Warten! Bist du im Telegram? Jetzt können Sie uns auch per Telegram kontaktieren.

Asif Razzaq ist CEO von Marktechpost Media Inc.. Als visionärer Unternehmer und Ingenieur setzt sich Asif dafür ein, das Potenzial der künstlichen Intelligenz für das soziale Wohl zu nutzen. Sein jüngstes Unterfangen ist die Einführung einer Medienplattform für künstliche Intelligenz, Marktechpost, die sich durch eine ausführliche Berichterstattung über maschinelles Lernen und Deep-Studying-Nachrichten auszeichnet, die sowohl technisch fundiert als auch für ein breites Publikum leicht verständlich ist. Die Plattform verfügt über mehr als 2 Millionen monatliche Aufrufe, was ihre Beliebtheit beim Publikum verdeutlicht.

Folgen Sie MARKTECHPOST: Fügen Sie uns als bevorzugte Quelle bei Google hinzu.

In diesem Tutorial erstellen wir von Grund auf einen fortschrittlichen Agenten für die Computernutzung, der mithilfe eines lokalen, offenen Modells virtuelle Aktionen begründen, planen und ausführen kann. Wir erstellen einen simulierten Miniatur-Desktop, statten ihn mit einer Software-Schnittstelle aus und entwerfen einen intelligenten Agenten, der seine Umgebung analysieren, über Aktionen wie Klicken oder Tippen entscheiden und diese Schritt für Schritt ausführen kann. Am Ende sehen wir, wie der Agent Ziele wie das Öffnen von E-Mails oder das Erstellen von Notizen interpretiert und demonstrieren so, wie ein lokales Sprachmodell interaktives Denken und Aufgabenausführung nachahmen kann. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

!pip set up -q transformers speed up sentencepiece nest_asyncio
import torch, asyncio, uuid
from transformers import pipeline
import nest_asyncio
nest_asyncio.apply()

Wir richten unsere Umgebung ein, indem wir wichtige Bibliotheken wie Transformers, Speed up und Nest Asyncio installieren, die es uns ermöglichen, lokale Modelle und asynchrone Aufgaben nahtlos in Colab auszuführen. Wir bereiten die Laufzeit so vor, dass die kommenden Komponenten unseres Agenten ohne externe Abhängigkeiten effizient arbeiten können. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

class LocalLLM:
   def __init__(self, model_name="google/flan-t5-small", max_new_tokens=128):
       self.pipe = pipeline("text2text-generation", mannequin=model_name, system=0 if torch.cuda.is_available() else -1)
       self.max_new_tokens = max_new_tokens
   def generate(self, immediate: str) -> str:
       out = self.pipe(immediate, max_new_tokens=self.max_new_tokens, temperature=0.0)(0)("generated_text")
       return out.strip()


class VirtualComputer:
   def __init__(self):
       self.apps = {"browser": "https://instance.com", "notes": "", "mail": ("Welcome to CUA", "Bill #221", "Weekly Report")}
       self.focus = "browser"
       self.display screen = "Browser open at https://instance.comnSearch bar centered."
       self.action_log = ()
   def screenshot(self):
       return f"FOCUS:{self.focus}nSCREEN:n{self.display screen}nAPPS:{listing(self.apps.keys())}"
   def click on(self, goal:str):
       if goal in self.apps:
           self.focus = goal
           if goal=="browser":
               self.display screen = f"Browser tab: {self.apps('browser')}nAddress bar centered."
           elif goal=="notes":
               self.display screen = f"Notes AppnCurrent notes:n{self.apps('notes')}"
           elif goal=="mail":
               inbox = "n".be part of(f"- {s}" for s in self.apps('mail'))
               self.display screen = f"Mail App Inbox:n{inbox}n(Learn-only preview)"
       else:
           self.display screen += f"nClicked '{goal}'."
       self.action_log.append({"sort":"click on","goal":goal})
   def sort(self, textual content:str):
       if self.focus=="browser":
           self.apps("browser") = textual content
           self.display screen = f"Browser tab now at {textual content}nPage headline: Instance Area"
       elif self.focus=="notes":
           self.apps("notes") += ("n"+textual content)
           self.display screen = f"Notes AppnCurrent notes:n{self.apps('notes')}"
       else:
           self.display screen += f"nTyped '{textual content}' however no editable subject."
       self.action_log.append({"sort":"sort","textual content":textual content})

Wir definieren die Kernkomponenten, ein leichtes lokales Modell und einen virtuellen Pc. Wir verwenden Flan-T5 als unsere Argumentationsmaschine und erstellen einen simulierten Desktop, der Apps öffnen, Bildschirme anzeigen und auf Tipp- und Klickaktionen reagieren kann. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

class ComputerTool:
   def __init__(self, pc:VirtualComputer):
       self.pc = pc
   def run(self, command:str, argument:str=""):
       if command=="click on":
           self.pc.click on(argument)
           return {"standing":"accomplished","end result":f"clicked {argument}"}
       if command=="sort":
           self.pc.sort(argument)
           return {"standing":"accomplished","end result":f"typed {argument}"}
       if command=="screenshot":
           snap = self.pc.screenshot()
           return {"standing":"accomplished","end result":snap}
       return {"standing":"error","end result":f"unknown command {command}"}

Wir stellen die ComputerTool-Schnittstelle vor, die als Kommunikationsbrücke zwischen der Argumentation des Agenten und dem virtuellen Desktop fungiert. Wir definieren Vorgänge auf hoher Ebene wie Klicken, Tippen und Screenshot, die es dem Agenten ermöglichen, auf strukturierte Weise mit der Umgebung zu interagieren. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

class ComputerAgent:
   def __init__(self, llm:LocalLLM, software:ComputerTool, max_trajectory_budget:float=5.0):
       self.llm = llm
       self.software = software
       self.max_trajectory_budget = max_trajectory_budget
   async def run(self, messages):
       user_goal = messages(-1)("content material")
       steps_remaining = int(self.max_trajectory_budget)
       output_events = ()
       total_prompt_tokens = 0
       total_completion_tokens = 0
       whereas steps_remaining>0:
           display screen = self.software.pc.screenshot()
           immediate = (
               "You're a computer-use agent.n"
               f"Person objective: {user_goal}n"
               f"Present display screen:n{display screen}nn"
               "Assume step-by-step.n"
               "Reply with: ACTION <click on/sort/screenshot> ARG <goal or textual content> THEN <assistant message>.n"
           )
           thought = self.llm.generate(immediate)
           total_prompt_tokens += len(immediate.break up())
           total_completion_tokens += len(thought.break up())
           motion="screenshot"; arg=""; assistant_msg="Working..."
           for line in thought.splitlines():
               if line.strip().startswith("ACTION "):
                   after = line.break up("ACTION ",1)(1)
                   motion = after.break up()(0).strip()
               if "ARG " in line:
                   half = line.break up("ARG ",1)(1)
                   if " THEN " partially:
                       arg = half.break up(" THEN ")(0).strip()
                   else:
                       arg = half.strip()
               if "THEN " in line:
                   assistant_msg = line.break up("THEN ",1)(1).strip()
           output_events.append({"abstract":({"textual content":assistant_msg,"sort":"summary_text"}),"sort":"reasoning"})
           call_id = "call_"+uuid.uuid4().hex(:16)
           tool_res = self.software.run(motion, arg)
           output_events.append({"motion":{"sort":motion,"textual content":arg},"call_id":call_id,"standing":tool_res("standing"),"sort":"computer_call"})
           snap = self.software.pc.screenshot()
           output_events.append({"sort":"computer_call_output","call_id":call_id,"output":{"sort":"input_image","image_url":snap}})
           output_events.append({"sort":"message","position":"assistant","content material":({"sort":"output_text","textual content":assistant_msg})})
           if "completed" in assistant_msg.decrease() or "right here is" in assistant_msg.decrease():
               break
           steps_remaining -= 1
       utilization = {"prompt_tokens": total_prompt_tokens,"completion_tokens": total_completion_tokens,"total_tokens": total_prompt_tokens + total_completion_tokens,"response_cost": 0.0}
       yield {"output": output_events, "utilization": utilization}

Wir konstruieren den ComputerAgent, der als intelligenter Controller des Programs dient. Wir programmieren es so, dass es über Ziele nachdenkt, entscheidet, welche Maßnahmen ergriffen werden sollen, diese über die Software-Schnittstelle ausführt und jede Interaktion als Schritt im Entscheidungsprozess aufzeichnet. Schauen Sie sich das an VOLLSTÄNDIGE CODES hier.

async def main_demo():
   pc = VirtualComputer()
   software = ComputerTool(pc)
   llm = LocalLLM()
   agent = ComputerAgent(llm, software, max_trajectory_budget=4)
   messages=({"position":"consumer","content material":"Open mail, learn inbox topics, and summarize."})
   async for end in agent.run(messages):
       print("==== STREAM RESULT ====")
       for occasion in end result("output"):
           if occasion("sort")=="computer_call":
               a = occasion.get("motion",{})
               print(f"(TOOL CALL) {a.get('sort')} -> {a.get('textual content')} ({occasion.get('standing')})")
           if occasion("sort")=="computer_call_output":
               snap = occasion("output")("image_url")
               print("SCREEN AFTER ACTION:n", snap(:400),"...n")
           if occasion("sort")=="message":
               print("ASSISTANT:", occasion("content material")(0)("textual content"), "n")
       print("USAGE:", end result("utilization"))


loop = asyncio.get_event_loop()
loop.run_until_complete(main_demo())

Wir bringen alles zusammen, indem wir die Demo ausführen, bei der der Agent die Anfrage eines Benutzers interpretiert und Aufgaben auf dem virtuellen Pc ausführt. Wir beobachten, wie es Überlegungen anstellt, Befehle ausführt, den virtuellen Bildschirm aktualisiert und sein Ziel klar und Schritt für Schritt erreicht.

Zusammenfassend haben wir die Essenz eines computergestützten Agenten implementiert, der zu autonomem Denken und Interaktion fähig ist. Wir erleben, wie lokale Sprachmodelle wie Flan-T5 die Automatisierung auf Desktop-Ebene in einer sicheren, textbasierten Sandbox wirkungsvoll simulieren können. Dieses Projekt hilft uns, die Architektur hinter intelligenten Agenten zu verstehen, beispielsweise denen in Pc-Agenten, indem es das Denken in natürlicher Sprache mit der Steuerung virtueller Werkzeuge verbindet. Es schafft eine solide Grundlage für die Ausweitung dieser Fähigkeiten auf reale, multimodale und sichere Automatisierungssysteme.

Schauen Sie sich das an VOLLSTÄNDIGE CODES hier. Schauen Sie sich gerne bei uns um GitHub-Seite für Tutorials, Codes und Notebooks. Sie können uns auch gerne weiter folgen Twitter und vergessen Sie nicht, bei uns mitzumachen 100.000+ ML SubReddit und Abonnieren Unser E-newsletter. Warten! Bist du im Telegram? Jetzt können Sie uns auch per Telegram kontaktieren.

Asif Razzaq ist CEO von Marktechpost Media Inc.. Als visionärer Unternehmer und Ingenieur setzt sich Asif dafür ein, das Potenzial der künstlichen Intelligenz für das soziale Wohl zu nutzen. Sein jüngstes Unterfangen ist die Einführung einer Medienplattform für künstliche Intelligenz, Marktechpost, die sich durch eine ausführliche Berichterstattung über maschinelles Lernen und Deep-Studying-Nachrichten auszeichnet, die sowohl technisch fundiert als auch für ein breites Publikum leicht verständlich ist. Die Plattform verfügt über mehr als 2 Millionen monatliche Aufrufe, was ihre Beliebtheit beim Publikum verdeutlicht.

Folgen Sie MARKTECHPOST: Fügen Sie uns als bevorzugte Quelle bei Google hinzu.

Eine Schritt-für-Schritt-Anleitung zum lokalen Ausführen von Llama3 mit Python

ChatGPT ist zweifellos großartig, hat aber einen erheblichen Nachteil: Alles, was Sie schreiben oder hochladen, wird auf den Servern von OpenAI gespeichert. Obwohl dies in vielen Fällen kein Drawback sein magazine, kann dies beim Umgang mit vertraulichen Daten zu einem Drawback werden.

Aus diesem Grund habe ich begonnen, Open-Supply-LLMs zu erkunden, die lokal auf PCs ausgeführt werden können. Wie sich herausstellt, gibt es tatsächlich noch viele weitere Gründe, warum sie großartig sind.

1. Datenprivatsphäre: Ihre Informationen bleiben auf Ihrem Laptop.

2. Kosteneffizient: keine Abonnementgebühren oder API-Kosten, die Nutzung ist kostenlos.

3. Anpassung: Modelle können mit Ihren spezifischen Systemeingabeaufforderungen oder Datensätzen feinabgestimmt werden.

4. Offline-Funktionalität: Es ist keine Internetverbindung erforderlich.

5. Uneingeschränkte Nutzung: frei von Einschränkungen durch externe APIs.

Das Einrichten eines lokalen LLM ist überraschend unkompliziert. Dieser Artikel bietet eine Schritt-für-Schritt-Anleitung zur Set up und Ausführung eines Open-Supply-Modells auf Ihrem…