Wykrywanie pętli narzędziowych

1. Wykrywanie pętli (enabled) — domyślnie wyłączone. Monitoruje bieżącą historię wywołań narzędzi pod kątem powtarzających się wzorców i ponownych prób użycia nieznanych narzędzi.
2. Mechanizm ochronny po kompaktowaniu (postCompactionGuard) — włączony, gdy enabled nie ma jawnie wartości false. Jest uzbrajany po każdej ponownej próbie po kompaktowaniu i przerywa przebieg, jeśli agent powtórzy tę samą trójkę (tool, args, result) w obrębie okna.

​

Dlaczego ten mechanizm istnieje

• Wykrywanie powtarzalnych sekwencji, które nie przynoszą postępu.
• Wykrywanie częstych pętli bez wyniku (to samo narzędzie, te same dane wejściowe, powtarzające się błędy).
• Wykrywanie określonych wzorców powtarzających się wywołań znanych narzędzi odpytujących.
• Przerywanie cykli przepełnienie kontekstu -> kompaktowanie -> ta sama pętla, zamiast pozwalać im działać bez końca.

​

Blok konfiguracji

{
  tools: {
    loopDetection: {
      enabled: false, // master switch for the rolling-history detectors
      historySize: 30,
      warningThreshold: 10,
      criticalThreshold: 20,
      unknownToolThreshold: 10,
      globalCircuitBreakerThreshold: 30,
      detectors: {
        genericRepeat: true,
        knownPollNoProgress: true,
        pingPong: true,
      },
      postCompactionGuard: {
        windowSize: 3, // armed after compaction-retry; runs unless enabled is explicitly false
      },
    },
  },
}

{
  agents: {
    list: [
      {
        id: "safe-runner",
        tools: {
          loopDetection: {
            enabled: true,
            warningThreshold: 8,
            criticalThreshold: 16,
          },
        },
      },
    ],
  },
}

​

Działanie pól

​

Zalecana konfiguracja

• W przypadku mniejszych modeli ustaw enabled: true i pozostaw progi z ich wartościami domyślnymi. Modele flagowe rzadko wymagają wykrywania na podstawie bieżącej historii i mogą pozostawić główny przełącznik z wartością false, nadal korzystając z mechanizmu ochronnego po kompaktowaniu.
• Zachowaj kolejność progów warningThreshold < criticalThreshold < globalCircuitBreakerThreshold; środowisko wykonawcze podnosi wartości criticalThreshold i globalCircuitBreakerThreshold, jeśli ustawisz je na poziomie progu, który muszą przekraczać, lub niżej.
• Jeśli wystąpią wyniki fałszywie dodatnie:
  • Zwiększ warningThreshold lub criticalThreshold.
  • Opcjonalnie zwiększ globalCircuitBreakerThreshold.
  • Wyłącz tylko konkretny detektor powodujący problemy (detectors.<name>: false).
  • Zmniejsz historySize, aby skrócić okno historii.
• Aby wyłączyć wszystko, w tym mechanizm ochronny po kompaktowaniu, jawnie ustaw tools.loopDetection.enabled: false.

​

Mechanizm ochronny po kompaktowaniu

{
  tools: {
    loopDetection: {
      // master switch; set false to disable the guard along with the rolling detectors
      enabled: true,
      postCompactionGuard: {
        windowSize: 3, // default
      },
    },
  },
}

• Niższa wartość windowSize oznacza bardziej rygorystyczne działanie (mniej prób przed przerwaniem).
• Wyższa wartość windowSize daje agentowi więcej prób odzyskania sprawności.
• Mechanizm ochronny nigdy nie przerywa przebiegu, gdy wyniki się zmieniają; uruchamiają go wyłącznie identyczne bajtowo wyniki w całym oknie.
• Jest uzbrajany wyłącznie bezpośrednio po ponownej próbie po kompaktowaniu, a nie w innych momentach przebiegu.

​

Dzienniki i oczekiwane działanie

• Najpierw pojawiają się ostrzeżenia.
• Blokowanie następuje, gdy wzorzec utrzymuje się po przekroczeniu progu ostrzeżenia.
• Progi krytyczne blokują następny cykl narzędzia i zapisują jasną przyczynę wykrycia pętli w rekordzie przebiegu.
• Mechanizm ochronny po kompaktowaniu emituje błędy compaction_loop_persisted, wskazując narzędzie powodujące problem oraz liczbę identycznych wywołań.

​

Powiązane materiały