Erkundung und Praxis des RCA Agent in komplexen Geschäftsszenarien
In der heutigen Zeit, in der die KI-Coding-Tools immer reifer werden, gilt die Fähigkeit zur Codegenerierung als fast erobert, aber die globalen Probleme der Softwareentwicklung sind noch lange nicht gelöst. Dieser Artikel basiert auf der Präsentation "Entwicklung und Praxis des RCA-Agents in komplexen Geschäftsszenarien" von Guo Yongliang, einem erfahrenen Serverarchitekten von Kuaishou, auf der QCon Global Software Development Conference 2026 in Peking.
Guo Yongliang hat in seiner Präsentation ausführlich ein auf einem Large Language Model basiertes System zur Fehlerbehebung in Geschäftsprozessen vorgestellt. Er hat die vier Kernherausforderungen in der Geschäftspraxis aufgedeckt: wie man die KI das Geschäft verstehen lässt, wie man Alarmrauschen bekämpft, wie man die Unsicherheit misst und wie man die Halluzinationen des Modells unterdrückt. Darüber hinaus hat er die Architektur des Agents, das Bewertungssystem und die Ideen für die kontinuierliche Weiterentwicklung um diese Herausforderungen herum erläutert.
Im Folgenden finden Sie die Transkription der Präsentation (bearbeitet von InfoQ ohne Änderung der ursprünglichen Bedeutung).
Hintergrund und Probleme: Warum brauchen wir einen RCA-Agent?
Boris Cherny, der Leiter von Claude Code, hat in einem Podcast die Ansicht vertreten, dass die Codierung im Wesentlichen von der KI erobert worden sei. Diese Einschätzung wirft eine tiefere Frage auf: Ist die Softwareentwicklung wirklich gelöst?
Aus zwei Untersuchungsberichten geht hervor, dass die Antwort nein lautet: Der DORA-Bericht von 2025 hat die Effizienzänderungen nach der Implementierung von AI Coding erfasst. Die persönliche Effizienz hat sich deutlich verbessert, aber die Effizienz der Organisation hat nur geringfügig zugenommen. Eine interne Umfrage von Microsoft hat in ähnlicher Richtung gezeigt. Sie haben etwa sechstausend Stichproben zur Zeitverteilung an Arbeitstagen gesammelt. Abgesehen von Meetings, Kommunikation, Lernen und administrativen Aufgaben sind die Entwicklung und die Fehlerbehebung immer noch die beiden größten Zeitfaktoren für Entwickler. Ein logischer Schluss ist, dass, wenn die Vorteile von AI Coding bereits stabilisiert sind, die Fehlerbehebung der nächste Produktivitätsengpass ist, der überwunden werden muss.
Eine andere Gruppe von Phänomenen bestätigt diese Einschätzung. OpenClaw hat im März dieses Jahres eine große Versionsoberarbeitung veröffentlicht. Nach der Veröffentlichung der Version haben viele Benutzer gemeldet, dass das Plugin abstürzte oder seine Funktionen nicht mehr erfüllte. Bemerkenswerterweise wurde der Großteil des Codes von OpenClaw durch AI Coding generiert. Was bedeutet das? Mit der Abnahme der menschlichen Kontrolle über den Code in der Ära der KI kann die KI-basierte Fehlerbehebung von einer Option zu einer Pflicht werden. Wenn Menschen ihr System nicht mehr vollständig verstehen können, muss es ein ebenfalls von KI angetriebenes Diagnosesystem geben, um die notwendige Sicherheit zu gewährleisten.
Das gesamte technische System kann grob in drei Ebenen unterteilt werden: Die Infrastrukturebene betrifft Container-, Knoten- und Netzwerkfehler, die Middleware-Ebene umfasst die Störungen von Cache, DB und MQ, und die von uns hauptsächlich bearbeitete Geschäftsebene bezieht sich direkt auf den Rückgang von Kernindikatoren, Sturmalarme und die Ausbreitung über Systemgrenzen hinweg. Die Geschäftsebene hat drei bemerkenswerte Merkmale: Erstens ist sie die direkte Darstellung des Benutzererlebnisses und des Umsatzes. Zweitens ändert sich der Geschäftscode sehr schnell und ist hochgradig veränderlich. Drittens ist es unmöglich, die Schritte zur Fehlersuche vorauszusagen. Nehmen wir beispielsweise den Rückgang der Videolänge. Die Ursache könnte in einer langsamen Redis-Abfrage liegen, in der Garbage Collection des Dienstes selbst oder in einem Bug in einem untergeordneten Dienst. Die Unsicherheit bei der Fehlersuche ist der größte Schwierigkeitsgrad bei der Fehlerbehebung auf der Geschäftsebene.
Herausforderungen bei der Implementierung in Geschäftsszenarien
Bei der praktischen Implementierung stehen wir vor vier aufeinander aufbauenden Kernherausforderungen. Die erste besteht darin, wie man die KI das Geschäft verstehen lässt. In einem typischen Vier-Quadranten-Diagramm enthalten die Faktoren, die die Geschäftskennzahlen beeinflussen können, sowohl interne als auch externe, aktive als auch passive Faktoren. Signale und Rauschen sind stark vermischt. Die natürliche Änderung des Datenverkehrs aufgrund des Schuljahresbeginns und der anomale Rückgang, der durch Codefehler verursacht wird, bilden zusammen einen riesigen Zustandsraum. Die zweite Herausforderung ist die Bekämpfung von Rauschen - in einem System, in dem der Anteil an Alarmrauschen möglicherweise über 75 % liegt, wie kann man verhindern, dass der Agent seine Rechenleistung an ineffektiven Signalen verschwendet. Die dritte besteht darin, wie man die Unsicherheit der KI-basierten Fehlerbehebung selbst misst, d. h. ein wiederholbares und quantifizierbares Bewertungssystem aufzubauen. Die vierte ist die direkte Bekämpfung der Halluzinationen des Large Language Models bei der numerischen Berechnung und der Trenderkennung.
Herausforderung 1: Wie lässt man die KI das Geschäft verstehen?
Nehmen wir beispielsweise einen Fall, in dem der Hauptwebseite plötzlich eine Zunahme der Benutzeranfragen für den Feed-Strom begegnete, die den Alarmgrenzwert überschritt. Der Eingangsdienst A, der als der Kernservice den Feed-Strom direkt trägt, zeigte für alle seine untergeordneten Dienste eine normale Verfügbarkeit. Aber die untergeordneten Abhängigkeiten des Dienstes A sind äußerst umfangreich und erstrecken sich über hunderte von Diensten und mehrere Abteilungen. In einer solchen Situation stehen den Schichtarbeiter zwei Ebenen von Problemen gegenüber: Erstens, ist diese anomale Kennzahl überhaupt ein Problem? Ist es auf einen internen Fehler zurückzuführen oder rein auf eine natürliche externe Hot-Spot-Situation? Zweitens, selbst wenn man beschließt, es als Problem zu behandeln, ist es offensichtlich unrealistisch, alle Kollegen aus den untergeordneten Geschäftsbereichen zur Fehlersuche einzubeziehen.
Tatsächlich lag die Wurzelursache in der Abnahme der Empfehlungsqualität - die Abnahme der Informationsstromqualität führte dazu, dass die Benutzer wiederholt Videos abrufen, was zu einer anomalen Zunahme der Anfragen führte. Die Fehlerausbreitungskette ist sehr komplex: Der Eingangsdienst A ruft den untergeordneten Dienst B auf. Dienst B zeigte keine Anomalien, weil er über eine interne Sicherungs- und Degradierungslogik verfügt. Aber der untergeordnete Dienst E, von dem B abhängt, hatte einen Core Dump. Der Grund für den Core Dump von E war, dass ein anderer Dienst F, auf den E zugreift, fehlende Schnittstellenfelder aufwies, was schließlich auf eine Konfigurationsänderung in Dienst F zurückzuführen war, die eine zuvor nicht betretene Logikpfad eingeführt hatte.
In diesem Fall gibt es einige ungewöhnliche Aspekte. Normalerweise führt eine Abnahme der Empfehlungsqualität zu einer Verringerung der Benutzeranfragen, aber in diesem Fall führte es im Gegenteil zu einer Zunahme der Anfragen. Die gesamte anomale Ausbreitungskette wurde an zwei Knoten, A auf B und E auf F, unterbrochen. Auf der Ebene der Kennzahlen sah alles normal aus, und es war unmöglich, die Abhängigkeiten über die Metriken herzustellen. Die interabteilliche Zusammenarbeit hat die Schwierigkeit zusätzlich erhöht - die Kollegen der Hauptwebseite kennen die internen Änderungen in den untergeordneten Abteilungen nicht. Dieses Problem hat schließlich eine große Menge an Arbeitskraft verbraucht, und die Fehlersuchgruppe hatte einmal über hundert Personen.
Bei der Verwendung der traditionellen Überwachungsmethoden - Trace, Metriken, Log - gibt es in diesem Fall mindestens zwei offensichtliche Unterbrechungen. Die erste Unterbrechung tritt bei der Anfrage von A an B auf. Die Anfrage ist normal und die Metriken können nicht korreliert werden. Man muss sich auf die Geschäftserfahrung verlassen, und die Kollegen der Hauptwebseite müssen die Kollegen aus Abteilung B manuell fragen. Die zweite Unterbrechung ist noch versteckter: Der Fehler bei der Anfrage von E an F wurde durch fehlende Schnittstellenfelder verursacht. Die Anfrage war ebenfalls normal, und da diese Logik zuvor nie betreten wurde, ist es sehr wahrscheinlich, dass überhaupt kein Log erstellt wurde. Die Entdeckung dieser Unterbrechung hängt ebenfalls von der manuellen Kommunikation zwischen internen Kollegen ab.
Daraus ergibt sich ein sehr klarer Schluss: Wenn man den Agent dazu bringen möchte, diese Aufgabe zu erledigen, muss er das Geschäft über die technischen Kennzahlen hinaus verstehen, sonst kann er diese beiden Unterbrechungen niemals überwinden.
Wie kann man das erreichen? Neben den üblichen Trace-, Metriken- und Log-Daten sowie den Änderungsereignissen haben wir den Geschäftscode GIT eingeführt. Denn der Code ist das einzige echte Dokument, auf dem alle Systeme aufgebaut sind. Die erste Praxis war sehr direkt: Wir haben einen Coding-Agent eingeführt, um den Code in Echtzeit zu analysieren. Zunächst haben wir das Claude-Agent-SDK verwendet, und die Analyse einer Codebasis dauerte etwa 30 Minuten, was in einem Fehlersuch-Szenario offensichtlich nicht akzeptabel ist. Nach dem Wechsel zu PI Coding Agent wurde die Analysedauer für eine einzelne Basis auf etwa fünf Minuten reduziert. Aber selbst wenn es auf fünf Minuten reduziert wird, gibt es immer noch Effizienzengpässe in der Praxis. Eine vollständige Fehlersuchaufgabe in einem Geschäftsszenario betrifft normalerweise mehrere Dienste in einer Kette, und in einem Java-System müssen auch viele SDK-Unterabhängigkeiten aufgelöst werden. Oft müssen drei bis fünf Basen gleichzeitig analysiert werden, was insgesamt 15 bis 25 Minuten dauert. Diese Zeit ist für die Reaktion auf einen Fehler immer noch zu lang.
Die Wurzel des Problems liegt darin, dass der Code zwar das einzige echte Dokument ist, aber ein Ding mit einem sehr niedrigen Abstraktionsgrad ist. Ein niedriger Abstraktionsgrad führt zwangsläufig zu einer niedrigen Effizienz. Selbst die Wartungsmitarbeiter eines Dienstes können sich nicht an jede Codezeile erinnern. Im menschlichen Gehirn findet eine gewisse Abstraktion des Geschäftscodes statt. Wenn man die KI verstehen lassen möchte, muss man ihre Kognitionskosten reduzieren.
Unsere Lösung besteht darin, eine Ebene der Codeabstraktion aufzubauen, die wir "Geschäftsassets" nennen. Beispielsweise markieren wir die Fehlercodes mit ihrer Geschäftssemantik, beschreiben die Bedeutung der Metriken aus geschäftlicher Sicht und erstellen eine topologische Beziehung zwischen den Kennzahlen - im Feed-Strom-Szenario kann eine Verringerung der Verfügbarkeit des untergeordneten Empfehlungsdienstes zu einer Änderung der Sicherungsrate des übergeordneten Dienstes führen und schließlich zu einer Änderung der Feed-Ausliefermenge. Einige Schalterkonfigurationen können auch direkt die Geschäftlogik beeinflussen, und wir haben auch ihre Einflusskarten erstellt. Die Erstellung dieser Assets erfolgt in zwei Modi: Ein Teil wird offline abgespeichert. Der Coding-Agent generiert offline eine Beschreibung der Beziehungen des Kerncodes und speichert sie in einer Wissensbasis in Form von Markdown-Dokumenten. Der andere Teil wird bei Bedarf während der Fehlersuche generiert. Der Agent analysiert ein bestimmtes Problem in Echtzeit und speichert es als Skill in der Wissensbasis. Auf diese beiden Arten werden die Geschäftsassets in Bewegung gesetzt.
Zusammengefasst ist die Lösung der Herausforderung "KI das Geschäft verstehen lassen" im Wesentlichen die Eliminierung der Kontextlücke zwischen Menschen und KI. Die KI kann die traditionellen Überwachungsdaten relativ leicht erhalten, aber im Gehirn der Entwickler laufen gleichzeitig eine große Menge an anderen Informationen - Code logik, Kennzahlbeziehungen, Geschäftskenntnisse, wie beispielsweise die Tatsache, dass die Anwesenheit eines Streamers möglicherweise zu einer Zunahme von Geschenkanfragen führt, sowie externe Ereignisse. Wie die Code logik müssen auch diese Informationen der KI zur Verfügung gestellt werden, wenn man sie zur Fehlersuche einsetzen möchte.
Herausforderung 2: Wie bekämpft man das Rauschen?
In der praktischen Umsetzung ist das Alarmrauschen ein äußerst ermüdendes Problem. Statistisch gesehen sind die meisten Alarme im System nutzlos, und der Anteil an Alarmrauschen kann über 75 % liegen. Weniger als ein Viertel der Alarme erfordert tatsächlich die Aufmerksamkeit.
Das Alarmrauschen hat reale negative Auswirkungen. Wir haben intern einen Fehler der P2-Kategorie oder höher nachgezeichnet und festgestellt, dass etwa zehn Minuten nach dem Auftreten des Fehlers eine bestimmte Kennzahl schwankte und einen Alarm auslöste. Der Schichtarbeiter hat den Alarm direkt stillgelegt. Danach hat sich die Kennzahl innerhalb von 15 Minuten stark verschlechtert, aber niemand hat es bemerkt. Der Grund war, dass dieser Alarm innerhalb von sieben Tagen mehr als 15 Mal ausgelöst wurde, und der Schichtarbeiter war bereits an die Alarme gewöhnt und hat sie ohne weiteres stillgelegt.
Aber wenn man die KI alle Alarme verarbeiten lässt, entstehen neue Probleme. In unseren internen Tests hat der Agent bei einem vollständigen Inferenzzyklus in ReAct zwischen 600.000 und über einer Million Tokens verbraucht. Die Gesamtzahl der Alarmereignisse auf der Kuaishou-Hauptwebseite pro Monat beträgt etwa 20.000 bis 30.000. Wenn man die KI alle Alarme verarbeiten lässt, würde der monatliche Tokenverbrauch fast zehn Milliarden betragen, was einem Jahreskostenbetrag von mehreren Millionen Yuan entspricht. Abgesehen von den Kosten ist die Anzahl der Interaktionen im ReAct-Zyklus nicht kontrollierbar, und die Verzögerung kann nicht garantiert werden.
Unsere Lösung besteht in einer zweistufigen Vorgehensweise. In der ersten Stufe führen wir einen sehr leichten Agent oder Workflow zur Bewertung der Alarmvertrauenswürdigkeit ein. Seine Aufgabe besteht darin, das "Portrait" des Alarms zu extrahieren - einschließlich der periodischen Muster des Alarms, des Ausmaßes der Abweichung vom Schwellenwert nach jedem Auslösen, der Wiederherstellungszeit, der Dienstverteilung und der Aggregation der Kurve. Diese Daten werden als statistische Daten zur Bewertung herangezogen. Nehmen wir ein Beispiel, um den Wert der Abweichungsanalyse zu veranschaulichen: Ein Verfügbarkeitsalarm kann täglich den Schwellenwert von 99,99 % auf 98 % überschreiten. Wenn er eines Tages plötzlich auf 60 % fällt, ist es offensichtlich aufmerksam zu werden. Wenn er nur auf 98 % fällt, kann man ihn möglicherweise ignorieren. Das Gleiche gilt für die Periodizität: Wenn ein Alarm