Există o modificare importantă a platformei pe care trebuie să o cunoașteți înainte de a depana o buclă AutoGen. Începând cu septembrie 2026, depozitul oficial AutoGen este în modul de întreținere: se așteaptă să primească lucrări de întreținere în loc de funcții noi, iar Microsoft recomandă Microsoft Agent Framework pentru proiecte noi. Depozitul oficial AutoGen listează în continuare Python 0.7.5 ca linie stabilă curentă, în timp ce Microsoft a publicat un ghid actualizat de migrare AutoGen-to-Agent-Framework pe 25 august 2026. Cu toate acestea, dacă aveți deja AutoGen în producție, tehnicile de depanare de mai jos rămân utile în mod direct. Consultați depozitul oficial AutoGen , versiunile oficiale AutoGen și ghidul de migrare AutoGen de la Microsoft .
Un agent AutoGen pare de obicei „blocat într-o buclă infinită” din unul dintre cele cinci motive: rularea nu are o condiție de terminare fiabilă, politica următorului vorbitor alege în mod constant un participant neproductiv, un apel de instrument nu creează un progres observabil, agenții lucrează manual înainte și înapoi sau aplicația continuă să reia starea învechită. Cea mai rapidă soluție este să nu rescrieți fiecare solicitare. Mai întâi identificați ce buclă aveți de fapt, apoi adăugați o oprire definitivă, apoi reparați tranziția care eșuează.
| Simptom | Cauza probabilă | Primul lucru de verificat |
|---|---|---|
| Aceiași doi agenți se alternează la nesfârșit | Rutare sau predare ping-pong | Selectarea vorbitorului, ținte de transfer și o limită de mesaj maxim sau de număr maxim de rânduri |
| Un agent apelează în mod repetat același instrument cu argumente aproape identice | Rezultatul instrumentului nu dovedește progresul sau eșecul | max_tool_iterations, schema de returnare a instrumentului și logica de reîncercare |
| Echipa continuă să vorbească după ce sarcina este vizibil finalizată | Finalizarea este implicită doar în prompt | Condiție explicită de terminare și semnal de finalizare determinist |
| Un selector alege în mod repetat specialistul greșit | Descrieri ambigue ale agenților sau solicitări de selecție | Descrierile participanților, setul de candidați șiallow_repeated_speaker |
| O sarcină nouă pare să moștenească comportamentul sarcinii anterioare | Statul a fost păstrat intenționat | Dacă echipa sau agentul ar trebui resetat înainte de noua sarcină |
| Un flux de lucru grafic ciclează la nesfârșit prin revizuire/rescriere | Condiția de ieșire nu devine niciodată adevărată | Predicat de ieșire din ciclu plus o terminare de siguranță independentă |
AutoGen AgentChat oferă condiții de terminare încorporate special pentru a menține echipele limitate. Documentația stabilă include MaxMessageTermination, TextMentionTermination, TokenUsageTermination, TimeoutTermination, HandoffTermination, , SourceMatchTermination, ExternalTermination, StopMessageTermination, TextMessageTermination, FunctionCallTermination, și FunctionalTermination. Consultați documentația oficială de terminare AutoGen .
Pentru majoritatea fluxurilor de lucru de producție, utilizați o condiție de finalizare semantică și un plafon de siguranță independent. Operatorul important este de obicei SAU, deoarece doriți ca rularea să se oprească atunci când sarcina se termină normal sau se atinge limita de siguranță.
from autogen_agentchat.conditions import (
MaxMessageTermination,
TextMentionTermination,
)
done = TextMentionTermination("TERMINATE")
safety_cap = MaxMessageTermination(max_messages=25)
termination = done | safety_cap
O greșeală frecventă este să te bazezi doar pe „spune TERMINATE când ai terminat”. Aceasta lasă corectitudinea comportamentului modelului. O altă greșeală este combinarea condițiilor cu „ &oprește-te la oricare dintre ele” atunci când de fapt vrei să spui „oprește-te la oricare dintre ele”. AutoGen acceptă atât compuneri ȘI, cât și SAU, așa că alege semantica în mod deliberat.
Un capac rigid este un întrerupător de circuit, nu o dovadă că fluxul de lucru este corect. Dacă rularea se oprește întotdeauna pentru că atinge capacul, tot mai ai o problemă logică de rezolvat.
Cel mai puternic semnal de terminare este cel pe care aplicația dvs. îl poate recunoaște fără a interpreta textul. Dacă fluxul de lucru are un eveniment de succes clar, utilizați cea mai apropiată condiție de terminare. De exemplu, o anumită predare poate fi detectată cu HandoffTermination, o anumită finalizare a instrumentului poate fi detectată cu FunctionCallTermination, iar logica personalizată poate fi exprimată cu FunctionalTermination.
Dacă utilizați TextMentionTermination("TERMINATE"), faceți responsabilitatea explicită: cărui agent i se permite să declare finalizarea și în ce condiții verificate? Evitați să dați fiecărui participant instrucțiuni vagi, cum ar fi „continuați până când sunteți mulțumit”. Acest tip de instrucțiune poate produce un comportament nesfârșit de critică și rescriere, deoarece „mulțumit” nu are o limită observabilă.
Un contract de finalizare util este concret: „Recenzentul emite comanda TERMINATE numai după ce schița conține toate cele trei secțiuni obligatorii și nu mai rămâne niciun blocant deschis.” Și mai bine, atunci când este practic, faceți ca recenzentul să producă o stare structurată pe care aplicația o poate verifica.
SelectorGroupChatfolosește un model pentru a alege următorul vorbitor din contextul conversației partajate. Documentația stabilă menționează că numele și descrierile participanților contează deoarece sunt utilizate în selecția vorbitorilor. În mod implicit, același vorbitor nu este selectat consecutiv, cu excepția cazului în care este singurul agent disponibil, deși allow_repeated_speaker=Truemodifică acest comportament. AutoGen oferă, de asemenea selector_func, și candidate_funcatunci când aveți nevoie de un control mai determinist. Consultați documentația oficială SelectorGroupChat .
Dacă același participant este selectat în mod repetat, verificați următoarele în ordine:
allow_repeated_speakerdifuzorul cu excepția cazului în care sunt necesare rotiri consecutive.selector_funcatunci când fluxul de lucru este de fapt o mașină de stări deghizată în conversație.Distincția cheie este simplă: utilizați selecția vorbitorilor bazată pe LLM atunci când următorul vorbitor necesită cu adevărat o judecată semantică. Utilizați rutarea deterministă atunci când următorul vorbitor este dictat de starea fluxului de lucru.
În AgentChat-ul actual, AssistantAgentare un max_tool_iterationsparametru. Documentația API stabilă spune că implicit este 1; când este mărită, agentul poate face apeluri secvențiale suplimentare ale instrumentelor până când modelul returnează un răspuns text sau se atinge valoarea maximă. Aceasta înseamnă că o singură rulare a unui agent este limitată de această setare, dar același agent poate fi selectat din nou de o echipă și poate repeta același model de instrumente eșuat de-a lungul turelor. Consultați referința oficială a API-ului AssistantAgent .
agent = AssistantAgent(
name="worker",
model_client=model_client,
tools=[lookup_tool],
max_tool_iterations=3,
)
Dacă vedeți același instrument și aceleași argumente iar și iar, reducerea limitei de iterație conține doar daunele. Corecția inițială se află de obicei în contractul instrumentului. Modelul are nevoie de suficiente informații pentru a stabili dacă apelul a reușit, a eșuat permanent, a eșuat tranzitoriu sau nu a produs nicio informație nouă.
Preferați un rezultat compact și explicit, cum ar fi:
{
"status": "no_new_data",
"query": "customer_123",
"retryable": false,
"reason": "record already checked",
"next_action": "return_to_planner"
}
Acest lucru este mai util decât un șir generic, cum ar fi „Niciun rezultat”, deoarece modelul poate vedea că repetarea aceluiași apel nu reprezintă un progres. Pentru instrumentele cu efecte secundare, adăugați și idempotența la nivel de aplicație, astfel încât un apel repetat să nu poată crea în mod repetat același tichet, plată, mesaj sau mutație a bazei de date.
Referința stabilă AssistantAgentmenționează că mai multe apeluri de instrumente pot fi executate simultan și că apelurile paralele de instrumente pot fi dezactivate în clienții model acceptați. De asemenea, avertizează că, dacă sunt detectate mai multe transferuri, se execută doar primul și recomandă dezactivarea apelurilor paralele de instrumente pentru a evita această situație. Dacă fluxul de lucru presupune tranziții de stare stricte de o acțiune pe rând, apelurile paralele pot face ca starea rezultată să fie mai dificil de raționat.
O buclă de transfer arată de obicei astfel: Agentul A decide că Agentul B este mai potrivit, Agentul B vede contextul incomplet și trimite sarcina înapoi, iar ambele opțiuni rămân rezonabile la nivel local pentru totdeauna. Problema nu este că vreunul dintre modele este „greșit”. Politicii de transfer îi lipsește responsabilitatea și o stare terminală.
Remediați problema atribuind fiecărei preluări o condiție specifică și o regulă pentru ce se întâmplă atunci când ținta nu poate progresa. Pentru fluxurile de lucru interactive cu utilizatorul, HandoffTermination(target="user")este conceput pentru a opri echipa atunci când controlul ar trebui să revină aplicației sau persoanei. Documentația AutoGen privind interacțiunea umană explică, de asemenea, că fluxurile de lucru Swarm necesită un comportament deliberat de reluare după o predare a utilizatorului. Consultați documentația oficială privind interacțiunea umană .
Un contract de predare bun include:
GraphFlowacceptă cicluri deliberate, ramificare condiționată și ieșiri din bucle. API-ul stabil descrie buclele ca fiind valide numai atunci când există o condiție care în cele din urmă iese din buclă, iar constructorul validează structura graficului. De asemenea, este marcat ca experimental. O buclă validă din punct de vedere structural poate rula prea mult timp dacă condiția de ieșire este logic inaccesibilă, așadar păstrați o condiție de terminare independentă sau o limită de turație în jurul acesteia. Consultați referința oficială a API-ului AutoGen teams .
Acest lucru este important mai ales în proiectele de tipul „scriitor → recenzent → scriitor”. Dacă recenzentul este instruit să „continue să se îmbunătățească până la perfecțiune”, predicatul de ieșire s-ar putea să nu devină niciodată adevărat. Înlocuiți perfecțiunea subiectivă cu o rubrică finită, cum ar fi prezența secțiunilor obligatorii, trecerea verificărilor de validare, absența defectelor critice și atingerea numărului maxim de revizii.
Agenții și echipele AgentChat au stări clare. Documentația stabilă a AutoGen precizează că echipa păstrează contextul conversației pe parcursul execuțiilor, astfel încât sarcinile corelate să poată continua și permite reset()ștergerea stării echipei și a participanților. Acest comportament este util pentru continuare, dar poate părea o buclă dacă o sarcină fără legătură moștenește un context vechi, o delegare neterminată sau presupuneri anterioare.
await team.reset()
result = await team.run(task=new_unrelated_task)
API-ul stabil al agentului avertizează, de asemenea, apelanții să transmită doar mesajele noi la fiecare apel, în loc să redea manual întregul istoric al conversațiilor. Reinjectarea istoricului complet în timp ce agentul menține și starea poate duplica contextul și poate întări comportamentul repetitiv.
Când o buclă este dificil de reprodus, înregistrați suficiente informații pentru a răspunde la patru întrebări pentru fiecare rundă: cine a acționat, de ce a fost selectat, ce acțiune a încercat și ce s-a schimbat ulterior. AutoGen oferă asistență pentru urmărire și observabilitate, iar ghidul de urmărire stabilă demonstrează urmărirea echipelor AgentChat. Consultați documentația oficială de urmărire AutoGen .
Cel puțin, înregistrați:
TaskResult.stop_reasoncând se termină alergarea.O diagnosticare foarte eficientă este detectarea de tip „aceeași acțiune, aceeași stare”. Dacă același agent invocă același instrument cu argumente echivalente și hash-ul de stare partajat nu s-a modificat timp de mai multe ture, opriți rularea și marcați-o ca o buclă fără progres. Această verificare se află în logica aplicației dvs., nu este o funcție AutoGen încorporată, dar detectează o clasă de erori pe care limitele de tokenuri sau mesaje le conțin doar ulterior.
Pentru o aplicație AutoGen AgentChat existentă, o valoare de referință conservatoare este:
max_tool_iterationso valoare mică, cu excepția cazului în care agentul are nevoie cu adevărat de o secvență de instrumente cu mai mulți pași.Nu rezolvați fiecare buclă prin simpla creștere a numărului max_messagesde la 25 la 100. Aceasta schimbă costul eșecului, nu logica. Nu adăugați un prompt de sistem mai lung înainte de a verifica dacă condiția de terminare este într-adevăr integrată în echipă. Nu permiteți ca doi agenți să dețină amândoi „revizuirea finală”. Nu returnați șiruri de instrumente ambigue dacă următorul apel de model trebuie să decidă dacă se va reîncerca. Și nu presupuneți că o rulare care în cele din urmă se oprește este sănătoasă: un flux de lucru care își atinge întotdeauna limita de siguranță funcționează în continuare defectuos.
Dacă mențineți o aplicație AutoGen existentă, aceste remedieri sunt adecvate, iar documentația actuală rămâne disponibilă. Cu toate acestea, pentru un sistem nou sau o rescriere majoră a orchestrației, starea modului de întreținere schimbă decizia. Microsoft direcționează acum noii utilizatori către Microsoft Agent Framework, iar documentația sa de migrare descrie o trecere de la nucleul bazat pe evenimente și echipele de nivel înalt ale AutoGen către fluxuri de lucru tipizate, bazate pe grafice. Aceasta nu înseamnă că o buclă AutoGen trebuie migrată imediat, dar înseamnă că ar trebui să evaluați costul unei lucrări de orchestrare specifice AutoGen mai profunde față de trecerea la succesorul acceptat.
Prin urmare, cea mai scurtă cale de depanare fiabilă este: limitarea rulării, identificarea tranziției repetitive, realizarea progresului observabil, apoi realizarea ieșirii deterministă. Odată ce aceste patru componente sunt la locul lor, majoritatea buclelor AutoGen „infinite” devin erori obișnuite ale fluxului de lucru pe care le puteți reproduce și remedia.
Construiește un flux de lucru Ollama local care generează titluri SEO structurate și meta descrieri în bloc, validează rezultatele și semnalează rezultatele pentru revizuire umană.
Folosește acest plan PowerPoint gratuit pentru prezentarea modernă a listării imobiliare pentru a organiza prețurile, marketingul, pregătirea proprietății, valoarea agentului și următorii pași pentru vânzător.
Creați un șablon de estimare a costurilor de construcție imprimabil în Excel, cu informații clare despre manoperă, materiale, formule, adaosuri, excluderi și totaluri pentru clienți gata de imprimare.
Construiește sugestii video mai puternice pentru Luma Dream Machine cu o formulă practică de iluminare cinematografică, rețete reutilizabile, exemple și o listă de verificare rapidă pentru depanare.
Construiește o prezentare minimalistă pentru investitori de startup-uri tehnologice în PowerPoint, cu ordinea corectă a diapozitivelor, reguli clare de design, indicatori de tracțiune și o anexă pregătită pentru investitori.
Împiedicați transformarea codurilor, ID-urilor și fracțiilor în date din Excel. Folosiți formatul text, apostrofurile, controalele de import și opțiunile actuale din Microsoft 365.
Accelerează randările ComfyUI SDXL prin reducerea volumului de eșantionare, controlul rezoluției și al dimensiunii lotului, simplificarea nodurilor, utilizarea memorării în cache și reglarea în siguranță a VRAM și a atenției.
Creați un instrument practic de urmărire a veniturilor și cheltuielilor din proprietățile de închiriat în Excel, cu categorii clare, formule, rezumate lunare și îndrumări pentru evidența fiscală.
Construiește o bază de cunoștințe privată și locală despre inteligența artificială cu Ollama, AnythingLLM, încorporări locale și RAG. Învață configurarea în patru pași, verificările de confidențialitate, testarea și copiile de rezervă.
Corectați erorile legate de fereastra contextuală în analiza documentelor lungi prin reducerea datelor de intrare, divizarea fișierelor, utilizarea funcției de recuperare și verificarea faptului că răspunsul final acoperă sursa.
