romfast/comun
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
989c3dd6f4227a8095d6263de2d5b1aeee777ae0
comun/docs/orchestrare-subagenti.md
Marius Mutu 53d9f1c64a Achizitie import unificata (ROAGEST): ointroduceri, teste UI, documentatie 
- import_nota / import_adauga_factura: flux unificat note contabile + articole,
  sincronizare automata, total factura automat, TVA impartit pe conturile
  creditoare ale notelor (rundele 1-31)
- runda 32: totalurile import_nota pe _label/_textbox din _baza.vcx (Arial 10),
  fara containerele clb_tx_simplu si fara bifa "Recalculeaza TVA" (recalcul
  mereu automat); "Sincronizeaza facturile secundare" mutata sub butoane
- utile/Teste: harness UI VFP headless (vfp_ui_harness.ps1, ui_harness.prg,
  precompilare, mock-uri) in radacina; suitele e2e pentru achizitia din import
  grupate in utile/Teste/achizitie_import/
- docs: flux editare text vcx/scx, testare-ui-vfp si testare-vfp-mcp (mutate
  din ROAGEST, general valabile), inventar comun, orchestrare subagenti,
  conventie GO recno, depanare testare VFP

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019DGibQKa5uK4P2TNSFFQNh
2026-07-20 00:50:18 +03:00

2.5 KiB
Raw Blame History

Orchestrare cu subagenti: context mic, misiuni descompuse

Regula (valabila in toate proiectele ROA/VFP): un singur subagent care duce o misiune lunga (iteratii de teste, investigatii, mai multe sarcini inlantuite) acumuleaza context urias (s-a ajuns la ~800k tokens) — calitate degradata, cost mare. Nu se lucreaza asa.

Cum se lucreaza

  • Sesiunea principala (sau un agent primar) e ORCHESTRATOR: imparte planul pe sarcini independente (un test, un audit, un scenariu = o sarcina), monitorizeaza, transmite constatarile intre agenti, verifica rezultatele.
  • Fiecare sarcina merge la un SUBAGENT PROASPAT cu prompt autosuficient: context complet in prompt + trimitere la un fisier de handoff, nu context acumulat in conversatie.
  • HANDOFF compact pe disc (docs\handoff_*.md, stil telegrafic): inventar livrabile, stare, ce ramane, detaliile ne-evidente pe care un agent proaspat nu le-ar putea reconstitui usor. Se actualizeaza la fiecare predare de stafeta.
  • PRAG: maxim ~200-250k tokens per subagent. Orchestratorul urmareste dimensiunea contextului; la atingerea pragului: cere handoff, inchide agentul, respawneaza unul proaspat pe sarcina urmatoare.
  • Sarcinile independente ruleaza in PARALEL (lane-uri), ex. audit read-only + editare teste.
  • Orchestratorul da utilizatorului UPDATE-URI SCURTE de progres, regulat (monitor pe artefacte: loguri/fisiere/screenshots; o propozitie-doua la fiecare schimbare relevanta, fara naratiune la evenimente fara continut).
  • Orchestratorul MONITORIZEAZA ACTIV subagentii sa nu se blocheze: monitor persistent pe artefactele lor + verificare la lipsa de progres (~10 min fara schimbare = suspect): procese agatate (vfp9 zombi, dialoguri modale), semafoare orfane, timeout-uri de tool (120s implicit) care omoara procese. La blocaj: diagnostic direct (procese, fisiere, loguri), mesaj de deblocare cu constatarea concreta, si abia apoi restart daca e cazul.
  • Modele: subagentii care DOAR ruleaza/editeaza teste si alte sarcini de volum/rutina -> Sonnet; ORCHESTRATORUL subagentilor (cel care imparte, monitorizeaza, deblocheaza, decide) -> Opus (sau sesiunea principala). Commit doar dupa review-ul diff-ului de catre om (vezi reguli_lucru.md).

Semne ca ai gresit impartirea

  • Acelasi agent primeste "inca o sarcina" a treia oara -> trebuia agent nou + handoff.
  • Agentul re-descopera capcane deja documentate -> handoff-ul/docs-ul e incomplet; completeaza-l, nu repeta investigatia.
  • Orchestratorul face el insusi munca de volum -> deleaga si pastreaza-si contextul pentru decizii, verificari si deblocari.