Multi-perspective research (Mehrperspektivische Recherche)
Eine flache Suche beantwortet „Was sagt das Web zu X?“. Dieses Skill beantwortet „Welche Teile von X sind unabhängig voneinander bestätigt, und welche beruhen auf einer einzigen Quelle?".
Der Mechanismus, abstrahiert von Stanfords STORM (überprüft gegen die Quelle unter stanford-oval/storm):
(Perspektiven × Budget) → abrufen → (Beweis | Verweigerung) → zurückschreiben → erneut fragen
M Runden wiederholen, N+1 unabhängige Spuren, am Ende einmal zusammenführen
↓
working-report.md (Mechanismus sichtbar, Prüfpfad)
↓
reader-report.md (Mechanismus unsichtbar, das Endprodukt)
↓
Antwort an den Benutzer = reader-report.md wörtlich, nichts hinzugefügt
Der gesamte Wert liegt an vier Stellen, die die meisten Rechercheversuche überspringen: Perspektiven müssen von außerhalb des Modells kommen, jede Frage muss zu einer echten Suche ausgeführt werden, die Konvergenz muss bewertet, nicht angenommen werden, und das bewertete Ergebnis muss dann einer Person standhalten, die nicht dabei war.
Wann auslösen
Dieses Skill bei allen untenstehenden Ausdrücken auslösen – der Benutzer muss das Skill nie namentlich erwähnen:
- Explizite Tokens: 深度调研 / 深度研究 / 深度分析 / 深入研究 / deep-research / deep research / deep dive / 深入调研.
- Qualitätsadverb-Anfragen: 仔细调研 / 认真调研 / 调研得仔细一点 / 多查几个来源 / 别只给一个来源 / 要确定性结论 / 确定性调研 / 查得踏实一点 / 帮我彻底搞清楚 X / 把 X 查透 / X 到底怎么样 / 不要泛泛而谈.
- Methodenanfragen: 多维度调研 / 多视角 / 全景分析 / 正反双方梳理 / 交叉验证 / 多方观点对比 / 交叉比对来源 / 标注"哪些结论有多来源印证、哪些只有单一来源".
- Implizite Form: Jede Rechercheanfrage, bei der der Benutzer signalisiert, dass eine einmalige Antwort nicht ausreicht.
Überlappungsregel: anysearch und agent-reach sind für generische 调研/搜索/查一下 zuständig (sie sind die Such-Backends, und dieses Skill verwendet sie als Werkzeuge). Sobald die Anfrage einen Tiefen-/Sorgfalts-/Sicherheits-/Kreuzvalidierungs-Qualifikator enthält, übernimmt dieses Skill die Anfrage und steuert diese Backends innerhalb seiner Spuren. Im Zweifelsfall dieses Skill bevorzugen: Die Kosten einer Überrecherche sind Zeit, die Kosten einer Unterrecherche sind eine selbstbewusste falsche Antwort.
Nicht geeignet für: Einmalige schnelle Faktenchecks, „查一下这个 API 是什么“ oder einseitige Nachschlagevorgänge.
Die beiden Artefakte
Die Schritte 1–5 erstellen einen Arbeitsbericht: ein mechanisch sichtbares Artefakt, bei dem Spur, A–E, Abfrage, Runde und Orthogonalitätssätze der Kern sind. Er ist korrekt und für jeden, der ihn nicht ausgeführt hat, unlesbar.
Schritt 6 erstellt den Leserbericht: die Sache, die Sie tatsächlich übergeben. Gleiche Beweise, gleiche Ehrlichkeit, gleiche Quellen – aber die Maschinerie ist verschwunden, und die Struktur ist um das herum aufgebaut, was ein Leser braucht, um eine Entscheidung zu treffen.
Beide Artefakte behalten, und Schritt 6 darf niemals Schritt 5 ersetzen.
- Der Arbeitsbericht ist der Prüfpfad: Er ermöglicht es Ihnen (oder einem späteren Durchlauf), zu überprüfen, ob keine Behauptung abgedriftet, kein Level hochgestuft und keine leere Zeile aus dem Gedächtnis gefüllt wurde. Er wird in eine Datei geschrieben (z. B.
working-report.md) und niemals in die Antwort eingefügt. - Der Leserbericht ist das ausgelieferte Ergebnis, gespeichert als
reader-report.md: eine Ressource, die eine Person tatsächlich in einem Durchgang und ohne Glossar nutzen kann.
Auslieferungsregel (hart): Die endgültige Antwort an den Benutzer ist der wörtliche, vollständige Inhalt von reader-report.md – nichts hinzugefügt, nichts geändert, nichts drumherum gewickelt. Siehe §Auslieferung unten. Keine Präambel („Ich bin fertig, hier ist der Bericht“), keine Verabschiedung, keine Zusammenfassung, keine Bestätigungszeile, kein Kommentar, der beschreibt, was Sie getan haben oder welche Dateien existieren. Lesen Sie die Datei und geben Sie genau ihre Bytes als Ihren Nachrichtentext aus. Alles, was Sie hinzufügen möchten, gehört in den Arbeitsbericht, nicht in die Antwort.
Die Verschmelzung der beiden Dokumente zu einem scheitert in beide Richtungen. Wenn die Maschinerie erhalten bleibt, schreckt sie die Leser ab; wenn die Maschinerie ohne die Regeln von Schritt 6 entfernt wird, verschwindet die Kreuzvalidierung stillschweigend – der Leser kann nicht mehr unterscheiden zwischen „vier unabhängige Pfade trafen sich hier“ und „ein glücklicher Treffer wurde wiederholt“, was der ganze Sinn des Skills war.
Nicht verhandelbare Punkte
- Perspektiven werden gelesen, nicht erfunden. Sie müssen sie aus echten Artefakten ableiten, die Sie abgerufen haben (bestehende Berichte, Konkurrenzdokumente, Inhaltsverzeichnisse, Forenkategorien, regulatorische Überschriften). Fragen Sie sich niemals einfach „Welche drei Blickwinkel gibt es hierzu?“.
- Jede Frage muss eine Suche auslösen. Eine Frage, die nicht in Abfragen zerlegt werden kann, die echte Quellen treffen, ist keine Recherche, sondern Spekulation. Sagen Sie es und lassen Sie es fallen.
- Spuren kommunizieren während der Ausführung nicht miteinander. Unabhängigkeit ist das Einzige, was Übereinstimmung informativ macht. Die Konvergenz erfolgt einmal, am Ende.
- Verweigerung ist ein Signal, kein Fehler. Wenn die Suchen einer Spur leer zurückkommen, zeichnen Sie das auf und lassen Sie es die nächste Frage lenken. Füllen Sie die Lücke nicht aus dem parametrischen Gedächtnis.
- Bestätigungsgrad pro Behauptung angeben. „Drei unabhängige Quellen stimmen überein“ und „Ein Blog sagt es“ müssen im Leserbericht niemals gleich aussehen.
- Der Mechanismus ist im Leserbericht unsichtbar, aber die Beweise sind es nicht. Ein Leser muss niemals wissen müssen, was eine Spur ist; ein Leser muss jedoch immer fragen können: „Wer sagt das, und hat das sonst noch jemand gesagt?“
- Die Antwort ist der Leserbericht, unverändert. Die letzte Nachricht an den Benutzer ist der vollständig ausgegebene
reader-report.md– keine Präambel, keine Verabschiedung, keine Zusammenfassung, keine Torzeile, kein Kommentar. Wenn Sie möchten, dass der Benutzer etwas anderes sieht, ändern Sie die Datei und geben Sie sie erneut aus; bearbeiten Sie sie niemals auf dem Weg nach draußen.
Schritt 1 – Die Perspektiven verankern
Beginnen Sie nicht mit dem Thema. Beginnen Sie damit, wie dieses Thema bereits in der Welt strukturiert ist.
Rufen Sie 2–4 echte Artefakte ab, deren Struktur Sie ausleihen können:
| Themenart | Woher die Struktur lesen |
|---|---|
| Ein Unternehmen, Produkt, Ereignis | Die Abschnitte der Wikipedia-Seite + Abschnitte von 2 benachbarten/Konkurrenzseiten |
| Ein Markt, eine Branche | Zwei Analystenbericht-Inhaltsverzeichnisse, ein Index einer Regulierungsbehörde, eine Konferenzagenda |
| Ein technischer Ansatz | Die Seitenleiste der übergeordneten Doku, zwei README-Überschriften von Konkurrenzprojekten |
| Ein kontroverses Thema | Die Überschriften des stärksten Pro-Beitrags, die Überschriften des stärksten Contra-Beitrags |
| Eine Person, Organisation | Die eigene Seitenstruktur vs. die Überschriften kritischer Berichterstattung |
Leiten Sie dann 3 Spuren (plus Spur 0, unten) ab. Jede Spur ist ein anderer Grund, sich für das Thema zu interessieren, kein anderes Unterthema:
- ✅ „Jemand, der dies in der Produktion betreiben muss und sich um Fehlermodi und Kosten kümmert“
- ✅ „Jemand, der dieser Entscheidung finanziell ausgesetzt ist und sich darum kümmert, wer zahlt“
- ❌ „Technische Aspekte“ / „Wirtschaftliche Aspekte“ / „Soziale Aspekte“ – das ist dieselbe Person in drei Hüten
Überprüfen Sie die Orthogonalität, bevor Sie das Budget ausgeben. Schreiben Sie für jedes Paar von Spuren einen Satz: „Spur A würde X fragen; würde Spur B jemals X fragen?“ Wenn für ein Paar „ja“, führen Sie sie zusammen und leiten Sie neue ab. Wenn zwei Spuren dieselben ersten drei Fragen generieren würden, sind sie eine Spur. Diese Überprüfung ist die Minute mit der höchsten Hebelwirkung im gesamten Verfahren – überspringen Sie sie, und Sie erhalten vier Paraphrasen einer einzigen Suche.
Spur 0 ist obligatorisch: eine einfache Spur „jemand, der die grundlegenden, unstrittigen Fakten, Daten, Definitionen, Zahlen benötigt“. Sie ist die Abdeckungsbasis, die verhindert, dass jede andere Spur bis zur Bedeutungslosigkeit spezialisiert wird.
Zeichnen Sie die Ankerartefakte und die Orthogonalitätssätze auf; sie gehören in den Arbeitsbericht (Schritt 5) als Herkunft des Perspektivensatzes. Sie erscheinen nicht im Leserbericht (Schritt 6).
Schritt 2 – Das Budget festlegen, bevor Sie es ausgeben
Schreiben Sie das Budget explizit auf und befolgen Sie es dann:
| Posten | Standard | Begründung |
|---|---|---|
| Spuren | 3 + Spur 0 = 4 | Mehr Spuren verwässern eher, als dass sie diversifizieren; 4 ist der empirische Sweet Spot |
| Runden pro Spur | 3 | Genug für eine Folgefrage; danach ist eine Spur normalerweise verloren |
| Abfragen pro Frage | 2–3 | Eine Abfrage ist ein Lottoschein, fünf sind eine Schrotflinte |
| Ergebnisse pro Abfrage | 3–5 | Lesen Sie die obersten, horten Sie keine |
| Wörter an Beweisen pro Runde | ~1000 | Zwingen Sie sich, nur die tragenden Sätze zu behalten |
| Wörter an Spurenkontext | ~2500 | Behält aktuelle Details, verwirft veraltete Details |
| Parallele Spuren | ≤4 | Parallelität ist der Punkt; Ratenlimits sind die Einschränkung |
Gesamtsuchbudget ≈ 4 × 3 × 3 = 36 Abfragen. Wenn es aufgebraucht ist, hören Sie mit der Suche auf und beginnen Sie mit der Konvergenz. Das Aufbrauchen des Budgets ist ein konstruiertes Ereignis, kein Unfall.
Schritt 3 – Die Spuren parallel und unabhängig ausführen
Starten Sie alle Spuren im selben Zug – verwenden Sie nach Möglichkeit parallele Unter-Agents (subagent / workflow), eine pro Spur. Jede Spur erhält: das Thema, ihre Spurbeschreibung, das Budget und die folgenden Regeln. Gewähren Sie jeder Spur keine Sichtbarkeit in die anderen Spuren.
Innerhalb einer Spur, für jede Runde:
- Stellen Sie immer nur eine Frage, in der Stimme der Spur. Einschränkungen, die nicht optional sind:
- Fragen Sie nach dem Thema, nicht nach benachbarten Themen (Anti-Drift)
- Fragen Sie nicht erneut, was bereits gefragt wurde (Anti-Wiederholung)
- Wenn es nichts mehr gibt, das eine Frage wert ist, stoppen Sie die Spur – erfinden Sie keine Frage, um die Runde zu füllen
- Zerlegen Sie die Frage in 2–3 Suchabfragen. Eine Frage, die sich nicht zerlegen lässt, ist eine schlechte Frage; schreiben Sie sie um.
- Suchen, dann tatsächlich abrufen. Snippets sind ein Hinweis, kein Beweis. Rufen Sie die Seite für alles Tragende ab.
- Antworten Sie nur mit dem, was Sie abgerufen haben. Jeder Satz muss auf eine URL zurückführbar sein. Wenn die Quellen es nicht beantworten, schreiben Sie die Verweigerung wörtlich: „Keine Quelle für diese Frage gefunden“.
- Schreiben Sie die Runde in den Spurenkontext zurück – das Fragengerüst immer, das Antwortdetail nur für die letzten paar Züge. Dadurch wird die nächste Frage zu einer Folgefrage anstelle eines Neustarts.
Führen Sie ein Protokoll pro Spur mit, für jede abgerufene Quelle: url, title, Abfrage, die sie gefunden hat, Runde und die genaue Behauptung, die sie stützt. Die Felder Abfrage und Runde sind diejenigen, die jeder vergisst und die Schritt 4 benötigt.
Die Verweigerungsschleife: Wenn die Suchen einer Runde leer oder nutzlos zurückkommen, geht das in den Spurenkontext ein und die nächste Frage muss sich davon wegbewegen. Flicken Sie ein Loch niemals mit dem, was Sie bereits glauben.
Schritt 4 – Zusammenführen und die Konvergenz bewerten
Jetzt, und erst jetzt, die Spuren zusammenführen.
4a. Nach Quelle zusammenführen, nicht nach Zusammenfassung. Schlüsseln Sie jedes Beweisstück nach URL (normalisiert: Tracking-Parameter, Fragmente, abschließenden Schrägstrich entfernen). Dieselbe URL aus zwei Spuren → eine Quelle, Vereinigung der Behauptungen, die sie stützt. Dies ist die erste und günstigste Konvergenz und der Punkt, an dem Sie herausfinden, dass zwei Spuren unabhängig voneinander auf derselben Seite gelandet sind.
4b. Die Behauptung × Spur-Matrix erstellen. Die extrahierten Behauptungen in atomare Aussagen clustern (ein Fakt pro Zeile). Für jede Behauptung erfassen, welche Spuren und wie viele verschiedene Quellen sie stützen:
Behauptung | unterstützende URLs | verschiedene Quellen | Spuren, die sie gefunden haben | Konflikte
4c. Bestätigung bewerten. Dies ist das Rückgrat des ausgelieferten Ergebnisses:
| Level | Bedingung | Wie es darzustellen ist |
|---|---|---|
| A – Konvergiert | von ≥2 unabhängigen Spuren gefunden, ≥2 verschiedene Domains | klar darlegen |
| B – Bestätigt | ≥2 verschiedene Quellen, gleiche Spur | mit angehängten Quellen darlegen |
| C – Einzelquelle | nur 1 Quelle | darlegen + Einzelquelle-Flag |
| D – Umstritten | glaubwürdige Quellen widersprechen sich | beide präsentieren, nicht mitteln |
| E – Nicht gefunden | gesucht, nichts gefunden | explizit so sagen; nicht aus dem Gedächtnis füllen |
Eine Behauptung ist nur A, wenn die Spuren wirklich unabhängig waren – wenn beide Spuren einfach nur den Themennamen durchsucht haben und beide die Wikipedia-Seite erhalten haben, ist das eine Spur zweimal, keine Konvergenz.
4d. Gewichten, nicht zählen. Nach Domain clustern, nicht nach URL. Zehn Seiten, die dieselbe Pressemitteilung zitieren, sind eine Quelle. Zwei Seiten von derselben Organisation sind eine Quelle. Notieren Sie Abhängigkeiten vorgelagerter Stellen (bezieht sich auf, laut) – eine Bestätigung durch ein Echo ist keine Bestätigung.
4e. Die Konflikte explizit jagen. STORMs gemessene Fehlerart ist nicht Halluzination, sondern Fakten zu verknüpfen, die nur gemeinsam aufgetreten sind. Bevor Sie schreiben, scannen Sie die Matrix nach Behauptungen, deren unterstützende Quellen die beiden verknüpften Dinge nicht tatsächlich verbinden. Markieren Sie jede solche Verknüpfung als von-mir-abgeleitet, niemals als belegt. Suchen Sie nach Level-D-Zeilen und stellen Sie sicher, dass jede im Bericht sichtbar ist, anstatt stillschweigend aufgelöst zu werden.
Schritt 5 – Berichten (Arbeitsbericht, Mechanismus sichtbar)
Schreiben Sie eine Markdown-Datei. Standardname: working-report.md (wenn der Benutzer oder der Aufrufer ein anderes Ausgabeverzeichnis oder einen anderen Dateinamen für den Bericht angegeben hat, befolgen Sie das – setzen Sie WORKING = <dieser Pfad> und READER = <Berichtspfad> am Anfang und verwenden Sie diese beiden Variablen für den Rest des Laufs, damit die Antwort die richtige Datei ausgibt).
Erforderliche Struktur:
# <Thema>
## Bestätigungszusammenfassung
<Anzahl: N Behauptungen konvergiert / bestätigt / Einzelquelle / umstritten / nicht gefunden>
## Wie die Perspektiven ausgewählt wurden
<die tatsächlich abgerufenen Ankerartefakte + die Orthogonalitätssätze + die Spurenliste>
## Ergebnisse
### <Thema>
<Prosatext; jede Behauptung inline mit A/B/C/D/E markiert; Zitate als [n]>
## Umstrittene Punkte
<jede Level-D-Zeile, beide Seiten, Quellen angehängt>
## Einzelquellen-Behauptungen
<jede Level-C-Zeile – diese als Hinweise zum Überprüfen lesen, nicht als Fakten>
## Was gesucht und nicht gefunden wurde
<Level-E-Zeilen, mit den verwendeten Abfragen>
## Quellen
[n] <url> — gefunden von <Spur>, Runde <k>, via Abfrage „<q>“
Behalten Sie die gefunden von Spur / Runde / Abfrage-Herkunft in der Quellenliste. Es kostet fast nichts, es aufzuzeichnen, und es ist die einzige Sache, die es einem Leser ermöglicht, zu unterscheiden zwischen „vier unabhängige Spuren trafen sich hier“ und „ein glücklicher Treffer wurde wiederholt“.
Dies ist das Artefakt, gegen das Sie prüfen, nicht das Artefakt, das Sie übergeben. Fahren Sie mit Schritt 6 fort.
Schritt 6 – In den Leserbericht polieren (Mechanismus unsichtbar)
Schreiben Sie das Ergebnis in reader-report.md (oder <READER>, wie in Schritt 5 festgelegt). Führen Sie dies als separaten Durchlauf mit einem frischen Kontext durch – einen Unter-Agenten, der nur den Arbeitsbericht erhält, nicht die Spurenaufforderungen, nicht die Spurenprotokolle, nicht Ihre Argumentation. Ein Durchlauf, der die Maschinerie gesehen hat, wird die Maschinerie preisgeben.
6a. Jeden Mechanismusbegriff in die Sprache des Lesers übersetzen
Dies ist eine feste Zuordnung, keine Ermessensentscheidung. Erfinden Sie keine Alternativen.
| Arbeitsbericht | Leserbericht |
|---|---|
| Spur | Perspektive oder Betrachtungsweise |
| Runde | Schritt (bei Bedarf nummeriert, z. B. „Schritt 1“) |
| Abfrage | Suche |
| Beweis | Quelle oder Beleg |
| Verweigerung | „Nichts gefunden“ (keine Erklärung des Mechanismus) |
| Budget | Aufwand oder Umfang (z. B. „für diese Recherche wurden bis zu 36 gezielte Suchen durchgeführt“) |
| Konvergenz | Übereinstimmung zwischen unabhängigen Quellen |
| A/B/C/D/E | Ausführlich: „Mehrere unabhängige Quellen bestätigen“, „Zwei Quellen bestätigen“, „Nur eine Quelle“, „Quellen widersprechen sich“ |
6b. Die Struktur für einen Entscheidungsprozess neu aufbauen
Der Arbeitsbericht ist um den Prozess herum organisiert (Spuren, Runden). Der Leserbericht ist um die Fragen des Lesers herum organisiert. Für den Aufbau gibt es ein universelles Schema, das funktioniert:
- Zusammenfassung (nicht Einleitung): Dem Leser die beiden Zahlen sofort mitteilen, die seine Aufmerksamkeit steuern werden: (a) was ist am besten belegt, (b) was ist umstritten oder unbekannt. Dann und nur dann den Rest dessen, was zuverlässig abgedeckt ist. Die Zusammenfassung enthält keine Methodik, keine Quellenangaben, keine Fußnoten – sie ist ein Versprechen, das der Rest des Berichts einlöst.
- Ergebnisse nach Thema (nicht nach Spur): Gruppieren Sie Behauptungen nach dem, wofür sich der Leser interessiert, nicht danach, welche Perspektive sie gefunden hat. Innerhalb jeder Themengruppe die Stärke der Behauptung anzeigen, aber auf natürliche Weise, nicht durch Abkürzungen. Z. B.: „Mehrere unabhängige Quellen geben die Kosten für XYZ mit etwa 100 € an (Quelle A, B, C). Die Amortisationszeit ist weniger klar – nur ein Blogbeitrag nennt eine Zahl von 18 Monaten (Quelle D).“
- Die gesamte Methodik in einem einzigen Abschnitt: Ein Abschnitt „Zu dieser Recherche“ am Ende: eine prägnante, nicht-technische Beschreibung dessen, was passiert ist („Für diese Recherche wurden vier unabhängige Perspektiven definiert...“). Verwenden Sie hier die Zuordnung aus 6a. Machen Sie keine falschen Versprechungen („Diese Recherche behauptet nicht, erschöpfend zu sein“).
- Vollständige Quellenangaben: Jede im Bericht zitierte Quelle mit Titel, URL und (optional) Zugriffsdatum auflisten.
6c. Jede Bewertung ausdrücklich überprüfen
Ein häufiger Fehler beim Polieren ist das Abschwächen von Level-E zu „vielleicht ist es so“ oder das wiederholte Wiederholen einer Level-C-Behauptung im gesamten Bericht, sodass sie wie Level-A klingt. Führen Sie nach dem Schreiben eine explizite Prüfrunde durch: Lesen Sie den Bericht, und markieren Sie für jeden Absatz die höchste darin enthaltene Bewertung. Wenn ein Absatz mit Level-C endet, aber mit dem Ton von Level-A gelesen wird, schreiben Sie ihn um, bis Ton und Bewertung übereinstimmen.
6d. Amphibiensätze vermeiden – die Wortart, die wie eine Tatsache aussieht, aber eine Schlussfolgerung ist
Vergleichen Sie:
| Amphibiensatz (vermeiden) | Klarer Satz (bevorzugen) |
|---|---|
| „Die Plattform XYZ scheint eine wachsende Akzeptanz zu erfahren.“ | „Quelle A und B berichten von steigenden Anmeldezahlen für XYZ; Quelle C ist eine Fallstudie über zwei Kunden.“ |
| „Die Analyse deutet darauf hin, dass die Risiken überschaubar sind.“ | „Zwei Sicherheitsaudits (Quelle D, E) stufen die Risiken als mittel ein; ein drittes (Quelle F) bewertet sie als hoch. Siehe umstrittene Punkte unten.“ |
Decken Sie alle Amphibiensätze auf, indem Sie eine Gegenleserunde mit einer einzigen Frage durchführen: „Kann ich diesen Satz auf die Quelle zurückführen, die diese spezifische Behauptung stützt?“ Wenn nicht, schreiben Sie ihn um, bis die Verbindung sichtbar wird.
§Auslieferung
Der allerletzte Schritt ist kein menschliches Urteil. Es ist ein mechanisches Kopieren.
- Lesen Sie den Inhalt von
reader-report.mdvollständig. - Geben Sie genau diesen Inhalt aus. Keine Absätze vorher, keine Absätze nachher. Kein "Hier ist der Bericht", kein "Ich hoffe, das hilft", keine Zusammenfassung hinzufügen. Keine Bestätigung. Keine Unterschrift. Kein "Haben Sie noch weitere Fragen?"
- Wenn Sie der Meinung sind, dass der Benutzer etwas sehen muss, das im reader-report.md nicht steht: Bearbeiten Sie die Datei und geben Sie die bearbeitete Version aus. Bearbeiten Sie niemals die Ausgabe.
Der Grund dafür ist nicht technisch, sondern strukturell: Der Leserbericht ist das einzige Artefakt, das die Maschinerie verbirgt und die Beweise bewahrt. Wenn Sie etwas zwischen die Datei und den Benutzer legen, wird diese Grenze durchbrochen. Der Benutzer sieht dann wieder statt , und das Vertrauen, das durch die (unsichtbare) Maschinerie aufgebaut wurde, ist verschwunden.
Die goldene Regel: Stellen Sie sich vor, Sie hätten den Bericht an einen Kollegen weitergegeben, der ihn gelesen und eine Entscheidung getroffen hat. Wenn Sie dem Benutzer nach der Ausgabe noch etwas sagen möchten, haben Sie entweder einen Fehler im Bericht gemacht oder Sie versuchen, das Ende der Konversation zu kontrollieren. Beides sind Probleme der Berichtsqualität, die durch die Bearbeitung des Berichts gelöst werden müssen, nicht durch das Hinzufügen eines menschlichen Anhangs.
Wie man sie einen Schritt nach dem anderen ausführt (wenn der Parallelmechanismus nicht verfügbar ist)
Wenn Ihr Agent keine echten parallelen Sub-Agents unterstützt, führen Sie die Spuren nicht nacheinander aus. Führen Sie sie in Chargen aus:
- Frage aus jeder Spur generieren → 4 Fragen
- Alle 4 Fragen in Suchabfragen zerlegen, alle parallel ausführen
- Alle Ergebnisse abrufen, für jede Spur separat protokollieren
- Nächste Runde: Fragen auf der Grundlage des bisherigen Verlaufs jeder Spur generieren
Dadurch wird die Unabhängigkeit der Quellen erhalten (jede Spur erhält auf der Grundlage ihres eigenen Verlaufs unterschiedliche Suchbegriffe), auch wenn die Ausführung sequentiell erfolgt. Der größte Verlust ist die Zeit, nicht die Qualität.