LLM-basierter Agent für ThingWorx: Architektur und Implementierung mit MCP

Wie bringst du ein Large Language Model dazu, live auf Deine IoT-Daten zuzugreifen und Fachwissen aus Dokumentationen zu kombinieren? Wir haben es ausprobiert – mit zwei Ansätzen:  Zuerst mit LangChain4J und Ollama, und dann mit DAIA. In diesem Beitrag zeigen wir dir, was in der Praxis funktioniert, welche Herausforderungen auftreten können und wie DAIA viele davon bereits löst.

Was kann der Agent?

Am besten zeigen wir es dir direkt in der Demo: Unser Agent ist in einen Vertical-Farming-Showcase eingebettet. Er zeigt Daten eines Hydroponik-Geräts an, und beantwortet Fragen dazu in natürlicher Sprache. Zwei Varianten im Vergleich:

• Eigene Entwicklung: ThingWorx + Ollama + LangChain4J + MCP
• Mit DAIA: ThingWorx + DAIA + MCP

Unser Ziel: Ein Agent, der Fachfragen in Alltagssprache beantwortet – mit Zugriff auf Live-Daten aus unseren IoT-Systemen und Wissen aus Dokumenten, etwa aus Betriebshandbücher. So findest du relevante Infos ganz ohne manuelle Suche oder technische Fachbegriffe.

Beispielhafte Fragen lauten:

• Aktuelle Daten: „Zeig mir die aktuellen Alarme der Hydroponik Anlage A?“
• Dokumentenwissen-Frage: „Welche Pumpe wird, im Hydroponik Setup genutzt?“

So haben wir den Agenten technisch umgesetzt

Im Bild sehen wir den technischen Überblick von beiden Varianten

Technische Details

Für beide haben wir für die ThingWorx-Zugriffe einen selbst erstellten MCP-Server genutzt, der die ThingWorx REST-API anspricht.

Beispiel: Agent mit LangChain4J

Der Agent bietet einen REST-Endpunkt an, der die Frage des Nutzers entgegennimmt:

@GetMapping("/chat")
public String chat(@RequestParam String question) {
return agent.chat(question);
}

Der Agent orchestriert Modell, RAG und MCP:

AiServices.builder(Agent.class)
.chatModel(chatModel)
.contentRetriever(retriever) // RAG
.toolProvider(mcpToolProvider) // ThingWorx-MCP
.build();

Warum MCP? Unser eigener ThingWorx-MCP

MCP (Model Context Protocol) macht Tools sauber beschreib- und auffindbar. Wir haben dafür einen kleinen MCP-Server mit Spring AI für ThingWorx entwickelt, der u. a. Property-Zugriffe kapselt:

@Component
public class PropertiesTools extends BaseToolService {
@Tool(name = "getPropertyValue",
description = "Returns the value of a property from a Thing.")
public String getPropertyValue(
@ToolParam(name = "thingName") String thingName,
@ToolParam(name = "propertyName") String propertyName
) {
return thingWorxApi.getPropertyValue(thingName, propertyName);
}
}

Vorteile im Überblick:

• Tools sind klar beschrieben (Parameter, Rückgaben)
• Der Agent entdeckt freigegebene Tools zur Laufzeit
• Mehrere Systeme (z. B. mehrere ThingWorx-Instanzen) lassen sich parallel einbinden
• Aufrufe sind nachvollziehbar und auditierbar

Code und Doku verlinken wir hier, damit man es nachbauen kann:

• GitHub (ThingWorx MCP Server)

Next Steps

Zum aktuellen Stand sind wir recht schnell gekommen. Es besteht Verbesserungspotenzial in einigen Bereichen. Unter anderem:

• Authentication: Mit Nutzerkontext anfragen (aktuell wird ein technischer Account genutzt)
• System Prompt verbessern (Prompt Engineering)
• Caching: Häufige Dokumentenpassagen und stabile Live-Reads cachen (bereits testweise umgesetzt).
• ThingWorx MCP verbessern: Was sind die Best Practices? Wie feingranular sollten die Tools sein?
• Kontext automatisch mitgeben: Bei Fragen auf einer Thing-Detailseite sollte der zugehörige Thing-Name automatisch erkannt und in die Anfrage eingebettet werden.
• Remote Services sicher ausführen: Der Chatbot kann Maschinen über ThingWorx steuern, mit klar definierten Sicherheitsmechanismen und Zugriffskontrollen.