AuditCore 多智能体协同审计与底稿生成技能

AuditCore Multi-Agent Collaborative Audit & Workpaper Generation Skill (AuditCore 多智能体协同审计与底稿生成技能)

I. Architektur-Übersicht (Overview)

AuditCore Skill verwendet eine "Host-Brain + Deterministic-Core"-Architektur:

• Multi-Agent Blind Audit Committee ohne externen API-Key: Nutzt direkt die Sub-Agenten-Fähigkeiten des Host-Agenten (Claude Code, Antigravity, Codex, OpenClaw usw.), um vier kontextuell isolierte Prüfungsrollen zu starten (junior-auditor, challenger-auditor, fact-checker, senior-partner).
• Deterministischer Patent-Kernel (scripts/audit_cli.py): Ein zustandsbehafteter CLI-Engine erzwingt: PII-Verschlüsselung und -Maskierung mit SHA-256-Hash-Chain-Prüfungslog, dreistufige Wesentlichkeitsfilterung, sechs-dimensionale deterministische Regelprüfung (Benford's Law, Z-Score, Ganz-Zehntausend/Ganz-Zehntausend-Anomalien, Wochenendbuchungen, gleichtägige Split-Transaktionsumgehung der Genehmigung, negative Red-Red-Offset/Doppelbuchungen), PyTorch-freie hybride dreistufige Rechtsabfrage $H(q, c_i)$, vierstufiger Evidenztopologie-Kausalgraph mit Bipartite-Graph-Loss-Verifikation, DAG-Zustandsautomat mit minimalem Cut-lokalem Rollback sowie automatische CSA-1131-Vier-Elemente Word (.docx)/Markdown (.md)-Arbeitspapiergenerierung mit PII-Rückumwandlung.

---

II. Drei grundlegende eiserne Regeln (IRON RULES – Verstoß gegen eine Regel gilt als Prüfungsversagen)

IRON RULE 1: PII-Null-Leakage-Isolations-Gate (Zero-Leakage Privacy Gate)

• Direktes Lesen des Original-Kontenrahmens ist strengstens verboten: Vor oder nach der Ausführung von scripts/audit_cli.py init ist es absolut untersagt, pandas, python, cat, head oder Dateilesewerkzeuge zu verwenden, um den Inhalt der originalen .xlsx/.csv-Dateien des Benutzers direkt anzuzeigen!
• Berühren des verschlüsselten Tresors ist strengstens verboten: Die durch init generierte Datei .auditcore_workspace/cases/<CASE_ID>/.vault_do_not_read.json verwendet XOR-SHA256-HMAC-Verschlüsselung, um die tatsächlichen Unternehmens- und Konten-Zuordnungen zu speichern. Der Host und jeder Sub-Agent darf diese Datei weder lesen noch entschlüsseln.
• Vollständig maskierte Inferenz im gesamten Prozess: Alle SQL-Erkundungen und die Blind-Prüfungsinferenz der vier Rollen müssen strikt die maskierten Platzhalter PERSON_0001, ACCT_0001 usw. verwenden; die tatsächlichen Firmennamen werden erst in der finalen audit_cli.py export-Phase durch das deterministische Skript lokal zurückverwandelt.

IRON RULE 2: Blind-Subagent-Isolationsvertrag für vier Rollen (Blinded Subagent Isolation)

• Im full-audit-Modus ist es strengstens verboten, im Hauptdialog "mit einem einzigen Modell vier Rollen zu spielen".
• Die entsprechenden Rollenvertragsdateien aus agents/ müssen nacheinander gemäß der Zustandsautomaten-Reihenfolge gelesen und unabhängige Sub-Agenten abgeleitet werden (unter Verwendung der invoke_subagent/Task/Agent-Tools des Hosts):
  1. Erstprüfung: agents/junior-auditor.md -> Einreichen mit --role junior
  2. Unabhängige Überprüfung: agents/challenger-auditor.md -> Einreichen mit --role challenger
  3. Faktencheck: agents/fact-checker.md -> Einreichen mit --role factcheck
  4. Finalprüfung Partner: agents/senior-partner.md -> Einreichen mit --role senior
• Downgrade-Kompatibilitätsregel: Nur wenn die Host-Umgebung keinerlei Sub-Agenten-Dispatch-Tools unterstützt, darf im Hauptdialog schrittweise und unabhängig das JSON jeder Rolle erstellt werden. Jedoch muss nach jedem Schritt sofort audit_cli.py commit aufgerufen werden, um die deterministische Evidenzgraph-Prüfung zu bestehen. Das Überspringen oder Zusammenführen von Schritten ist absolut verboten.

IRON RULE 3: Zustandsbehafteter CLI-Zwangs-Gate und minimaler Cut-Rollback-Kreislauf (Stateful CLI & Minimum-Cut Rollback)

• Jede Rollenschlussfolgerung muss über scripts/audit_cli.py commit --role <role> eingereicht werden. Bei Verstoß gegen die Zustandsautomaten-Reihenfolge gibt das CLI den Exit-Code 2 (STATE_GUARD_VIOLATION) zurück.
• Wenn nach dem Einreichen von factcheck der globale Konsistenz-Score $S_{\text{global}} < \theta$ (Standard 0.80) ist, führt das CLI automatisch ein abhängigkeitsbewusstes minimales Cut-lokales Rollback durch, gibt "rollback_triggered": true sowie rollback_diagnosis.arbitration_probe (Prüfsonde) zurück und setzt den Zustand auf STATE_JUNIOR_AUDIT oder STATE_CHALLENGER_REVIEW zurück.
• Wenn rollback_triggered: true auftritt, muss rollback_diagnosis in die Zielrolle injiziert und der Sub-Agent erneut abgeleitet werden, bis die Konsistenzanforderung erfüllt ist und der Zustand STATE_SENIOR_PARTNER erreicht wird! Das manuelle Erstellen von Arbeitspapieren unter Umgehung von export ist strengstens verboten.

---

III. Routing-Tabelle der 5 Betriebsmodi (5 Operational Modes)

Basierend auf den Benutzeranforderungen wird der entsprechende Modus automatisch ausgewählt (Standard ist full-audit):

Modusname	Anwendungsfall und Trigger-Wörter	Ausführungspfad
full-audit(Standard-Vollprozess)	Prüfung von Kontenrahmen-Dateien, umfassende Untersuchung auf Betrug/interne Kontrollmängel und Ausstellung formeller Arbeitspapiere	Vollständige Ausführung des Abschnitts IV: Standard-Fünf-Schritt-Zustandsautomaten-Protokolls (init $\to$ sql $\to$ Vier-Rollen-Blindprüfung mit minimalem Cut-Rollback-Zyklus $\to$ export)
quick-scan(Schnellscan)	"Schnell nach Anomalien suchen", "Kein Multi-Agent-Spiel nötig, nur Regel-Scan-Ergebnisse anzeigen"	1. Ausführen von audit_cli.py init --file <PATH> --case <ID> --mode quick2. Optional: audit_cli.py export --case <ID> --out-dir <DIR> zum schnellen Export von Regel-Scan-Arbeitspapieren
sql-explore(SQL-Sandbox-Durchdringung)	Ausführen von benutzerdefinierten periodenübergreifenden/Gruppierungs-Aggregationsabfragen auf einem initialisierten Kontenrahmen	Ausführen von audit_cli.py sql --case <ID> --query "SELECT ... FROM financial_ledger ..." (nur lesende SELECT / WITH erlaubt)
law-lookup(Hybride Rechtsabfrage)	"Prüfe Richtlinien zu Split-Transaktionen/Wochenendbuchungen/Prüfungsnachweisen"	Ausführen von audit_cli.py law --query "<Schlüsselwort oder Frage>" --top-k 5, gibt direkt die gewichtete Evidenzkette $E(q)$ und die vierstufige Schlussfolgerung $\Psi$ der qualitativen Argumentation aus
workpaper(Arbeitspapiere neu exportieren)	Ändern des Firmennamens, des Abrechnungszeitraums oder des Exportverzeichnisses für einen abgeschlossenen Fall	Ausführen von audit_cli.py export --case <ID> --entity-name "<Firmenname>" --period "<Zeitraum>" --out-dir <DIR>

Detaillierte CLI-Parameter und JSON-Schema finden Sie nach Bedarf in: references/schemas.md.

---

IV. full-audit Standard-Fünf-Schritt-Zustandsautomaten-Protokoll (5-Step Stateful Protocol)

Angenommen, das Skill-Wurzelverzeichnis ist <SKILL_DIR> (enthält scripts/audit_cli.py). Wenn der Benutzer keine Kontenrahmen-Datei bereitstellt, aber eine Demo wünscht, kann der integrierte hochrealistische Betrugs-Beispiel-Kontenrahmen <SKILL_DIR>/examples/sample_vouchers_2026.xlsx verwendet werden.

Schritt 1: Initialisierung des Kontenrahmens, Verschlüsselung/Maskierung und deterministische Regelprüfung (init)

python3 <SKILL_DIR>/scripts/audit_cli.py init \
  --file "<USER_EXCEL_OR_CSV_PATH>" \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --lang "中文"

• Notieren Sie das zurückgegebene JSON: stats, schema_ddl, rule_findings, anomaly_samples, evidence_chain.
• Der Zustandsautomat befindet sich jetzt in STATE_DYNAMIC_SQL_EXPLORATION.

Schritt 2: Read-Only SQLite-Sandbox-Durchdringungsabfrage (sql)

Basierend auf schema_ddl und rule_findings schreiben Sie eine SQL-Aggregationsprüfungsabfrage für die maskierte Tabelle financial_ledger (z. B. Prüfung der Anzahl und des kumulierten Betrags von Split-Transaktionen desselben Lieferanten am selben Tag oder Zusammenfassung anomaler Beträge nach Sollkonto):

python3 <SKILL_DIR>/scripts/audit_cli.py sql \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --query "SELECT Date, Vendor, COUNT(*) AS tx_count, SUM(Amount) AS total_amount FROM financial_ledger GROUP BY Date, Vendor HAVING tx_count >= 2 OR total_amount >= 100000 ORDER BY total_amount DESC"

• Der Zustandsautomat wechselt zu STATE_JUNIOR_AUDIT.

Schritt 3: Multi-Agent Independent Blind Review und minimaler Cut-Rollback-Zyklus (commit Loop)

3.1 Ableiten des Junior-Auditors (STATE_JUNIOR_AUDIT)

1. Lesen Sie <SKILL_DIR>/agents/junior-auditor.md.
2. Leiten Sie einen Sub-Agenten ab (oder führen Sie einen unabhängigen Schritt aus) und übergeben Sie nur die maskierten stats, rule_findings, anomaly_samples, sql-Ergebnisse und evidence_chain (bei einem Rollback zusätzlich rollback_diagnosis).
3. Erhalten Sie das vom Sub-Agenten zurückgegebene JSON (enthält analysis, risk_score, cited_reg_ids) und reichen Sie es beim CLI ein:

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role junior \
  --payload '<JUNIOR_JSON>'

• Der Zustandsautomat wechselt zu STATE_CHALLENGER_REVIEW.

3.2 Ableiten des unabhängigen Prüfers (STATE_CHALLENGER_REVIEW)

1. Lesen Sie <SKILL_DIR>/agents/challenger-auditor.md.
2. Leiten Sie einen unabhängigen Sub-Agenten ab und übergeben Sie die maskierten Anomaliebeweise, evidence_chain sowie den junior_report und junior_score. Fordern Sie eine unabhängige Überprüfung mit professioneller Skepsis an.
3. Erhalten Sie das zurückgegebene JSON (enthält rebuttal, adjusted_risk_score) und reichen Sie es beim CLI ein:

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role challenger \
  --payload '<CHALLENGER_JSON>'

• Der Zustandsautomat wechselt zu STATE_FACT_CHECK.

3.3 Ableiten des Faktenprüfers und Überprüfung der globalen Konsistenz (STATE_FACT_CHECK)

1. Lesen Sie <SKILL_DIR>/agents/fact-checker.md.
2. Leiten Sie einen unabhängigen Sub-Agenten ab, der die Schlussfolgerungen der Erst- und Zweitprüfung einer atomaren Tatsachenzerlegung (claims) und einer Bipartite-Graph-Beweiskartierung (evidence_mapping) unterzieht.
3. Erhalten Sie das zurückgegebene JSON (enthält analysis, support_score, conflict_score, conflict_type, claims, evidence_mapping) und reichen Sie es beim CLI ein:

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role factcheck \
  --payload '<FACTCHECK_JSON>'

4. Überprüfen Sie das vom CLI zurückgegebene current_state und rollback_triggered:
   • Wenn "rollback_triggered": true: Der Beweisgraph weist schwerwiegende Konflikte auf ($S_{\text{global}} < \theta$). Das CLI hat automatisch den am schlechtesten bewerteten Subgraphen entfernt und ist auf rollback_target_state (normalerweise STATE_JUNIOR_AUDIT) zurückgesetzt. Sie müssen das zurückgegebene rollback_diagnosis (enthält arbitration_probe und csa_guidance) extrahieren und zu 3.1 (oder 3.2) zurückkehren, um den Sub-Agenten erneut abzuleiten und die Schlussfolgerungen zu korrigieren!
   • Wenn "current_state": "STATE_SENIOR_PARTNER": Der Beweisgraph hat die Konsistenzanforderung erfüllt. Fahren Sie mit Schritt 4 fort.

Schritt 4: Ableiten des Senior-Partners für das Endurteil und die Prüfungsanpassungsbuchungen (STATE_SENIOR_PARTNER)

1. Lesen Sie <SKILL_DIR>/agents/senior-partner.md.
2. Leiten Sie einen unabhängigen Sub-Agenten ab und übergeben Sie die maskierten Statistiken, die Rechtsbeweiskette und die validierten Schlussfolgerungen der Erst-/Zweitprüfung. Generieren Sie das Endurteil (final_verdict, final_risk_score, reasoning, action_item, suggested_aje).
3. Reichen Sie es beim CLI ein:

python3 <SKILL_DIR>/scripts/audit_cli.py commit \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --role senior \
  --payload '<SENIOR_JSON>'

• Der Zustandsautomat wechselt zu STATE_WORKPAPER_GENERATION.

Schritt 5: Zusammenbau der vier Elemente des Arbeitspapiers, Bewertung der Qualität $Q(Y)$, Rückumwandlung von PII und Export des CSA-1131-Arbeitspapiers (export)

python3 <SKILL_DIR>/scripts/audit_cli.py export \
  --case "CASE_2026_01" \
  --workspace ".auditcore_workspace" \
  --out-dir "./audit_outputs" \
  --entity-name "Geprüfte Einheit" \
  --period "Geschäftsjahr 2026"

• Das CLI führt automatisch die Rückumwandlung der PII-Entitätsnamen durch und generiert:
  1. workpaper_docx_path: Ein formelles .docx Word-Prüfungsarbeitspapier gemäß dem chinesischen Prüfungsstandard Nr. 1131;
  2. workpaper_markdown_path: Ein strukturiertes .md-Prüfungsarbeitspapier;
  3. quality_evaluation: Ein Bewertungsbericht mit $Q_{\text{ev}}$, $Q_{\text{con}}$, $Q_{\text{cmp}}$, Gesamtpunktzahl $Q(Y)$ und den Ergebnissen der Null-Toleranz-Halluzinationsprüfung.
• Berichten Sie dem Benutzer die endgültigen Prüfungsergebnisse, zeigen Sie die zurückverwandelten tatsächlichen betroffenen Einheitsnamen, die Prüfungsanpassungsbuchungen (AJE), die Qualitätsbewertung $Q(Y)$ und die Pfade der generierten .docx/.md-Dateien an.

---

V. Rationalisierungstabelle und rote Flaggen (Rationalization Table & Red Flags)

Typische Ausrede des Agenten (Rationalization)	Tatsächlicher Sachverhalt und eiserne Gegenmaßnahme (Reality & Iron Rule)
"Die Kontenrahmen-Datei ist klein, ich schaue mir mit pandas.read_excel kurz an, welche Spalten und Lieferanten drin sind."	Schwerer Verstoß (Verstoß gegen IRON RULE 1)! Sobald die Originaldatei direkt gelesen wird, sind Klartext-Firmennamen und Bankkontonummern sofort im LLM-Kontext sichtbar, was die Datenschutz-Compliance-Grenzen vollständig zerstört. Es muss und darf zuerst audit_cli.py init ausgeführt werden.
"Um Zeit zu sparen, schreibe ich das JSON für Erstprüfung, Überprüfung, Faktencheck und Partner in einem Codeblock und führe commit fortlaufend aus."	Schwerer Verstoß (Verstoß gegen IRON RULE 2)! Das gleichzeitige Erfinden von vier Rollen in einem einzigen Kontext verursacht schwerwiegende Bestätigungsfehler (Confirmation Bias). Wenn der Host Sub-Agenten unterstützt, müssen diese unabhängig abgeleitet werden; selbst bei sequentieller Ausführung muss nach jedem commit die Rückmeldung des Beweisgraphen des CLI gelesen werden, bevor mit dem nächsten Schritt fortgefahren wird.
"Nach dem Einreichen von factcheck wurde rollback_triggered: true ausgelöst. Ich ändere einfach die Punktzahl im JSON und reiche senior ein."	Zustands-Gate sperrt direkt (Exit-Code 2)! Nach dem Rollback befindet sich der Zustandsautomat in STATE_JUNIOR_AUDIT (oder STATE_CHALLENGER_REVIEW). Ohne die vorherigen Rollen gemäß rollback_diagnosis.arbitration_probe erneut auszuführen, wird der Zustandsautomat den Fortschritt zu STATE_SENIOR_PARTNER niemals zulassen.
"Ich kenne das Prüfungsergebnis bereits und schreibe dem Benutzer einfach einen Markdown-Bericht, ohne audit_cli.py export aufzurufen."	Schwerer Verstoß (Verstoß gegen IRON RULE 3)! Ein manuell erstellter Bericht kann die tatsächlichen Firmennamen aus .vault_do_not_read.json nicht entschlüsseln (nur PERSON_0001 ist möglich) und entbehrt der patentierten Vier-Elemente-Struktur $Y={\text{idx},\text{aje},\text{jud},\text{log}}$, der Qualitätsbewertung $Q(Y)$ und des formellen CSA-1131 .docx-Arbeitspapiers.

Rote Flaggen — Bei folgenden Gedanken sofort anhalten und zum CLI-Protokoll zurückkehren:

• Vorbereitung zur Ausführung von pd.read_excel / pd.read_csv / open() zum Lesen der originalen Finanzdateien des Benutzers
• Vorbereitung zum Lesen von .vault_do_not_read.json
• Erfinden von nicht in der evidence_chain vorhandenen Paragraphennummern in der Analyse (löst hallucinated_citations Null-Toleranz-Downgrade aus und drückt $Q(Y)$ auf $\le 0.40$)
• Überspringen des sql- oder eines commit --role-Schrittes, um direkt export zu versuchen