Asistent NX multi-agent: pe scurt
Un asistent NX multi-agent împarte un chatbot AI pentru Siemens NX în roluri: un orchestrator care construiește printr-un catalog de instrumente fix, un agent de cercetare care interoghează cunoștințe NX prin MCP, un verificator și un coder de ultimă instanță. inteliScience îl construiește astfel încât fiecare rol să vadă doar ce îi trebuie, iar fiecare modificare să rămână un singur pas de undo.
| Un singur chatbot mare | Asistent NX multi-agent | |
|---|---|---|
| Context | documentație, liste de fețe, imagini și istoricul chatului într-o singură fereastră | fiecare rol își păstrează propriul context scurt; orchestratorul vede răspunsuri, nu date brute |
| Costul modelului | cel mai puternic model citește totul | model puternic acolo unde se iau decizii, modele mai ieftine pentru căutări și liste |
| Verificare | cel care construiește își evaluează singur munca | un verificator separat, cu propriile instrucțiuni |
| Capabilitate lipsă | modelul improvizează cod la rulare | un rol de coder scrie un journal, îl validează și îl redă ca un singur pas de undo |
| Modificări în NX | orice face codul generat | instrumente tipizate, un marcaj de undo vizibil per pas |
Problema: un singur chatbot, prea multe sarcini
Primul nostru asistent NX era un singur model cu toate instrumentele atașate. Funcționa, dar pe piese reale contextul i se umplea repede. Motivul era banal: lista de fețe a unei piese de producție ajunge la 20 până la 50 KB de JSON, un răspuns din baza de cunoștințe aduce după el mai multe fragmente de documentație, iar o captură de ecran a unei planșe de desen costă mai mult decât ambele. Totul ajungea în aceeași fereastră de context ca cererea efectivă a utilizatorului.
Trei lucruri au mers prost deodată. Modelul care decidea ce construiește în continuare își consuma atenția pe date brute de care nu avea să mai aibă nevoie. Fiecare căutare rula pe cel mai puternic model. Iar modelul care construise un feature era întrebat dacă feature-ul este corect, ceea ce seamănă cu a-i cere unui proiectant să-și aprobe singur propriul desen.
Anthropic a descris același tipar pentru agenții de cercetare în iunie 2025: sub-agenți cu propriile ferestre de context explorează în paralel și condensează “cei mai importanți tokeni pentru agentul principal de cercetare”, iar configurația lor multi-agent a depășit un singur agent Claude Opus 4 cu 90,2 la sută într-o evaluare internă de cercetare (blogul de inginerie Anthropic, consultat la 30 septembrie 2026). Același articol este onest în privința costului: sistemele multi-agent au folosit de aproximativ 15 ori mai mulți tokeni decât un chat. Așadar, împărțim rolurile pentru a păstra contextele curate, nu pentru a face mai multe apeluri de model. Această împărțire stă la baza modului în care livrăm agentic CAD pentru Siemens NX echipelor de inginerie.
Arhitectura unui asistent NX multi-agent
Modelul nu scrie NXOpen la execuție. Alege un instrument dintr-un catalog fix, completează parametrii și citește un rezultat structurat, iar fiecare modificare rămâne un singur pas de undo.
Patru roluri, patru contexte
Fiecare rol există pentru că are nevoie de alt context, alt model sau alte permisiuni. Dacă un rol nu avea niciunul dintre aceste trei motive, l-am comasat la loc.
Orchestratorul construiește
Orchestratorul este singurul rol care modifică piesa. Vorbește cu utilizatorul și decide ordinea lucrului.
Agentul de cercetare ține documentele deoparte
Acest rol interoghează baza de cunoștințe și returnează un răspuns scurt cu surse, astfel încât fragmentele de documentație rămân în afara contextului orchestratorului. Ca bază de cunoștințe folosim Vision4NX Connector.
Scout-ul și verificatorul privesc, orchestratorul decide
Scout-ul se ocupă de căutările de geometrie și răspunde într-o propoziție, astfel încât listele mari de fețe rămân în afara contextului orchestratorului.
Verificatorul evaluează ce a construit orchestratorul în raport cu regulile interne. Este o a doua opinie cu propriile instrucțiuni, nu un gând ulterior al celui care construiește. Scout-ul și verificatorul sunt construite și se află în prezent în testare live pe piese reale.
Coderul este ultima soluție
Doar atunci când niciun instrument nu poate face ce cere utilizatorul, orchestratorul predă sarcina unui agent de programare. Coderul scrie un journal, îl validează și îl redă ca un singur pas de undo.
Coderul este cel mai nou rol și se află în testare live. Până când un manager CAD nu l-a văzut comportându-se pe piese reale, nu l-am activa în afara unui proiect pilot. Exemplul nostru detaliat NXOpen prompt-to-journal arată acest pas izolat.
Acesta rulează ca un POC. Ce lipsește pentru producție: permisiuni de instrumente limitate per rol, SSO, un jurnal de audit deținut de managerul dumneavoastră CAD și operarea on-premise a stratului de cunoștințe. Închidem distanța dintre “rulează pe calculatorul meu” și “rulează în departamentul de inginerie”: vedeți cum ducem agentic CAD pentru Siemens NX în producție.
Îngust și verificat bate larg și plin de speranță
Cel mai mare risc într-un asistent NX nu este un model slab. Este un instrument care pretinde că face ceva ce nu a făcut niciodată pe un NX real.
Serverul NX_MCP al comunității (98 de stele pe GitHub, 20 de fork-uri, consultat la 30 septembrie 2026) limitează argumentele de fișier la un singur workspace și păstrează activate implicit doar 16 instrumente certificate, în timp ce 34 de instrumente mai vechi rămân ascunse în spatele unor flag-uri de mediu. README-ul său documentează un workflow batch de 20 de rulări trecut pe NX 2506 în august 2026. Când am activat instrumentele mai vechi într-un fork, pe o sesiune NX 2506 live, mai multe apelau metode builder pe care această versiune nu le are: eșecuri cu descrieri pline de încredere.
Am adăugat două instrumente pe lista certificată din fork-ul nostru, schițarea de cercuri și detecția undercut-urilor, doar după ce ambele rulaseră într-o sesiune interactivă. Propriul nostru bridge urmează aceeași disciplină.
O eroare nu întrerupe niciodată conexiunea sau NX; ea revine la model ca eroare de instrument, cu un indiciu. Această buclă de planificare, execuție, verificare și corectare este cea din studiul nostru de caz despre AI agentic hibrid pentru Siemens NX; împărțirea ei între roluri a făcut-o mai ușor de inspectat, nu diferită ca natură.
Ce să căutați la un asistent NX multi-agent
Dacă evaluați un furnizor sau plănuiți să construiți singuri unul, aceste cinci întrebări separă o arhitectură de un demo:
- Poate modelul să ruleze cod pe care tocmai l-a scris? Doar printr-o cale de coder controlată, care îl validează mai întâi și îl redă ca un singur pas de undo.
- Este contextul fiecărui rol separat? Listele de fețe, fragmentele de documentație și imaginile rămân la rolul care a avut nevoie de ele.
- Este verificatorul independent? Instrucțiuni proprii, aceleași reguli interne ca cel care construiește.
- Este fiecare instrument verificat pe versiunea dumneavoastră de NX? O listă scurtă certificată bate una lungă plină de speranță.
- Unde rulează baza de cunoștințe? On-premise înseamnă că aplicația trebuie să fie clientul MCP.
Punctul 1 este cel la care nu am face compromisuri. Pentru o configurație cu un singur agent, consultați integrarea noastră Claude Code NX; pentru un server apelat de alți agenți, iată de ce are nevoie un serverul MCP pentru Siemens NX pregătit pentru producție.
Întrebări frecvente
Ce este un asistent NX multi-agent?
Un asistent NX multi-agent este un chatbot AI pentru Siemens NX a cărui muncă este împărțită între roluri cu contexte separate: un orchestrator care modifică piesa prin instrumente NXOpen tipizate, un agent de cercetare care interoghează o bază de cunoștințe prin MCP, un scout pentru căutări de geometrie, un verificator care evaluează rezultatele și un coder care scrie journal-uri doar atunci când niciun instrument nu se potrivește.
Multi-agent sau un singur agent: ce este mai bun pentru Siemens NX?
Pentru sesiuni scurte pe piese simple, un singur agent este mai simplu și suficient. Când sesiunile ajung la zeci de apeluri de instrumente pe piese reale, împărțirea se amortizează: contextul orchestratorului rămâne mic, căutările rulează pe modele mai ieftine, iar un verificator cu propriile instrucțiuni evaluează munca celui care construiește. Costul constă în mai multe apeluri de model, așa că păstrăm numărul de roluri mic.
Cât costă rularea unui asistent multi-agent comparativ cu un singur chatbot?
Depinde de cât de des sunt apelate rolurile, nu de câte există. Anthropic a măsurat la sistemele de cercetare multi-agent de aproximativ 15 ori mai mulți tokeni decât la un chat, dar acea configurație explorează intenționat în paralel. Într-un asistent NX, specialiștii rulează la cerere pe modele mai ieftine, prompturile sunt stocate în cache, iar rezultatele mari ale instrumentelor sunt scurtate. Înregistrăm consumul per rol și per cerere, astfel încât costul fiecărui rol este măsurat, nu estimat.
De ce să nu lăsăm AI-ul să scrie direct cod NXOpen?
Pentru că în codul generat modelele halucinează apeluri API, iar codul nerevizuit într-o sesiune live poate lăsa o piesă construită pe jumătate. Un catalog de instrumente fix, în C#, face munca NXOpen; modelul doar selectează și parametrizează. Când lipsește un instrument, un rol de coder scrie un journal, îl validează și îl redă ca un singur pas de undo.
Poate asistentul să folosească propria noastră bază de cunoștințe dacă rulează on-premise?
Da, dacă aplicația de chat este clientul MCP. Conectorul MCP găzduit al Claude API ajunge doar la servere HTTP expuse public, așa că o bază de cunoștințe on-premise trebuie conectată de aplicația însăși. Un agent de cercetare deține apoi aceste instrumente și returnează orchestratorului răspunsuri cu surse.
Pasul următor
Dacă echipa dumneavoastră are un asistent NX care funcționează în demo-uri și se împotmolește pe piese reale, împărțirea în roluri este de obicei soluția, iar catalogul de instrumente verificat este fundația.
Vorbiți cu inginerii noștri despre un asistent NX multi-agent
