భాగం 1 లో, విద్యార్థులు మరియు పనిచేస్తున్న నిపుణులు agentic systems ను ఎందుకు అర్థం చేసుకోవాలో, మరియు ఒక framework ను నేర్చుకోవడమే అసలైన కెరీర్ నైపుణ్యం ఎందుకు కాదో చర్చించాము.
ఇప్పుడు ఎందుకు నుండి ఎలా వైపు వెళ్తున్నాము.
మొదటి ఏజెంట్‌ను నిర్మించడం ఆశ్చర్యకరంగా సులభం కావచ్చు.
మోడల్‌కు ఒక లక్ష్యాన్ని ఇవ్వండి, ఒకటి లేదా రెండు టూల్స్‌ను కనెక్ట్ చేయండి, వాటిని ఎప్పుడు వాడాలో అదే నిర్ణయించనివ్వండి.
కష్టమైన ప్రశ్న ఆ తర్వాతే వస్తుంది:
పనిచేస్తున్న ఆ డెమోను మీరు నిజంగా నమ్మగల system గా ఎలా మారుస్తారు?
అక్కడే agentic ఇంజనీరింగ్ మొదలవుతుంది.
ఒక ఉపయోగకరమైన సమస్యతో ప్రారంభించండి
మనం ఒక రీసెర్చ్ అసిస్టెంట్‌ను నిర్మించాలనుకుంటున్నామని ఊహించండి.
వినియోగదారు ఇలా అడుగుతారు:
ఈ వారం AI సెక్యూరిటీలో ఏమి మారింది? నమ్మదగిన సోర్స్‌లను కనుగొని, ఉల్లేఖనాలతో ఒక చిన్న సారాంశం సిద్ధం చేయండి.
ఒక సరళమైన వెర్షన్ ఇలా ఉండవచ్చు:
ప్రశ్న → AI మోడల్ → సెర్చ్ టూల్ → సోర్స్‌లు → సమాధానం
ఇది ఇప్పటికే సాధారణ చాట్‌బాట్ కంటే ఎక్కువే, ఎందుకంటే బయటి సమాచారం ఎప్పుడు అవసరమో మోడల్ నిర్ణయించి, దాన్ని పొందడానికి ఒక టూల్‌ను వాడగలదు.
మొదటి ప్రాజెక్ట్‌కు ఇది సరిపోతుంది.
రీసెర్చర్ ఏజెంట్, రివ్యూయర్ ఏజెంట్, సైటేషన్ ఏజెంట్, రైటింగ్ ఏజెంట్ మరియు మేనేజర్ ఏజెంట్‌ను సృష్టించడంతో ప్రారంభించకండి.
ముందు ఒక ఏజెంట్ ఒక ఉపయోగకరమైన సమస్యను బాగా పరిష్కరించగలదని నిరూపించండి.
ఈ సూత్రం ముఖ్యమైనది, ఎందుకంటే ప్రతి అదనపు ఏజెంట్, టూల్ మరియు వర్క్‌ఫ్లో ఏదైనా తప్పు జరగడానికి మరిన్ని చోట్లను జోడిస్తుంది.
దశ 1: ఏజెంట్‌కు టూల్స్ ఇవ్వండి
టూల్స్ లేకుండా, మోడల్ ప్రధానంగా తన వద్ద ఇప్పటికే ఉన్న సమాచారంపై మాత్రమే తర్కించగలదు.
టూల్స్ దానికి చర్య తీసుకునే వీలు కల్పిస్తాయి.
మన రీసెర్చ్ అసిస్టెంట్‌కు ఇవి ఉండవచ్చు:
- ఒక వెబ్ సెర్చ్ టూల్
- ఒక పేజీ-రీడింగ్ టూల్
- ఉపయోగకరమైన సోర్స్‌లను నిల్వ చేసే ఒక ఫంక్షన్
ప్రాథమిక లూప్ ఇలా అవుతుంది:
లక్ష్యాన్ని అర్థం చేసుకోవడం
→ ఏ సమాచారం లేదో నిర్ణయించడం
→ ఒక టూల్‌ను ఎంచుకోవడం
→ దాన్ని వాడటం
→ ఫలితాన్ని గమనించడం
→ తర్వాత ఏమి చేయాలో నిర్ణయించడం
ఈ సరళమైన లూప్ చాలా agentic systems కు కేంద్రంగా ఉంటుంది.
కానీ టూల్ డిజైన్ ముఖ్యం.
ఒక టూల్‌కు స్పష్టమైన ఉద్దేశం, ఊహించగల ఇన్‌పుట్‌లు మరియు అర్థమయ్యే ఫలితాలు ఉండాలి.
ఒక ఏజెంట్‌కు అస్పష్టమైన పేర్లున్న 50 టూల్స్ ఉంటే, దేన్ని వాడాలో నిర్ణయించడం కష్టమవుతుంది.
ఏజెంట్‌కు ప్రతిదానికీ యాక్సెస్ ఇవ్వడం కంటే, బాగా రూపొందించిన తక్కువ టూల్స్ తరచుగా మెరుగ్గా ఉంటాయి.
Anthropic ప్రస్తుత ఇంజనీరింగ్ మార్గదర్శకత్వం ఈ విషయాన్ని నేరుగా చెబుతుంది: టూల్ నాణ్యత మరియు స్పష్టమైన టూల్ సరిహద్దులు ఏజెంట్ పనితీరును గణనీయంగా ప్రభావితం చేయగలవు.
దశ 2: system కు అవసరమైనప్పుడే state ను చేర్చండి
మన రీసెర్చ్ అసిస్టెంట్ ఐదు సోర్స్‌లను వెతికిందనుకోండి.
ఇప్పుడు అది వీటిని గుర్తుంచుకోవాలి:
- ఇప్పటికే ఏమి వెతికింది
- ఏ సోర్స్‌లను అంగీకరించింది
- ఏ వాదనలకు ఇంకా ఆధారం అవసరం
- పనిలో ఏ దశకు చేరుకుంది
అదే state.
State ఈ ప్రశ్నకు సమాధానం ఇస్తుంది:
ఈ నిర్దిష్ట పనిలో ప్రస్తుతం ఏమి జరుగుతోంది?
మెమరీ దానికి సంబంధించినదే, కానీ భిన్నమైనది.
మెమరీ అనేక పనుల మధ్య ఉపయోగకరమైన సమాచారాన్ని భద్రపరచవచ్చు, ఉదాహరణకు వినియోగదారుకు ఇష్టమైన సోర్స్‌లు లేదా తరచుగా ఉండే రీసెర్చ్ ప్రాధాన్యతలు.
ప్రారంభకులకు, ఈ తేడాను సరళంగా ఉంచుకోవడం సరిపోతుంది:
State = ఈ పని కొనసాగడానికి అవసరమైనది.
మెమరీ = ఈ పనికి మించి ఉపయోగపడే సమాచారం.
ఒక agent framework మద్దతు ఇస్తుంది కదా అని శాశ్వత మెమరీని చేర్చకండి.
system కు నిజంగా అవసరమైనందుకే సమాచారాన్ని నిల్వ చేయండి.
దశ 3: AI ఏది నియంత్రించాలో నిర్ణయించండి
ఇది అత్యంత ముఖ్యమైన డిజైన్ నిర్ణయాల్లో ఒకటి.
కొన్ని ప్రక్రియలు ఊహించగలిగేవి.
ఉదాహరణకు:
వెతకడం → సోర్స్‌లను సేకరించడం → ఉల్లేఖనాలను ధృవీకరించడం → సారాంశం రాయడం
ఈ దశలు ఎల్లప్పుడూ ఆ క్రమంలోనే జరగాలంటే, ప్రతిసారీ మోడలే ప్రక్రియను కనిపెట్టేలా అనుమతించడం కంటే సాధారణ workflow మెరుగ్గా ఉండవచ్చు.
ఇతర సమస్యలు తక్కువ ఊహించగలిగేవి.
ఒక రీసెర్చ్ ఏజెంట్ ఒక సోర్స్ మరొక సోర్స్‌కు విరుద్ధంగా ఉందని గుర్తించి, మరో సెర్చ్ అవసరమని నిర్ణయించవచ్చు.
అక్కడే మోడల్ ఆధారిత నిర్ణయం తీసుకోవడం ఉపయోగపడుతుంది.
ఆచరణాత్మక system తరచుగా రెండింటినీ కలుపుతుంది.
Workflow ఏమి తప్పక జరగాలో నియంత్రిస్తుంది.
Agent విచక్షణ అవసరమైన వాటిని నిర్ణయిస్తుంది.
ఈ తేడా అనవసరమైన స్వయంప్రతిపత్తిని నివారించడంలో సహాయపడుతుంది.
Microsoft ప్రస్తుత మార్గదర్శకత్వం కూడా ఇలాంటి సిఫార్సే చేస్తుంది: సరళమైన ప్యాటర్న్‌లు పనిచేసినప్పుడు వాటినే వాడండి, స్పష్టమైన అమలు క్రమం మరియు checkpoint లు ముఖ్యమైన చోట workflow లను వాడండి.
దశ 4: వైఫల్యాన్ని డిజైన్‌లో భాగం చేయండి
డెమో సాధారణంగా ప్రతిదీ పనిచేస్తుందని ఊహిస్తుంది.
ప్రొడక్షన్ అలా కాదు.
సెర్చ్ API విఫలం కావచ్చు.
ఒక వెబ్‌సైట్ అందుబాటులో లేకపోవచ్చు.
ఒక టూల్ అసంపూర్ణ సమాచారాన్ని ఇవ్వవచ్చు.
మోడల్ తప్పు టూల్‌ను ఎంచుకోవచ్చు.
ఎక్కువ కాలం నడిచే పని సగంలోనే ఆగిపోవచ్చు.
నమ్మదగిన agentic system కు ఇలాంటి ప్రశ్నలకు సమాధానాలు అవసరం:
- ఈ దశను retry చేయాలా?
- ఎన్నిసార్లు?
- ఈ టూల్ లేకుండా పని కొనసాగగలదా?
- చివరి విజయవంతమైన checkpoint కు తిరిగి వెళ్లాలా?
- ఎప్పుడు ఆగాలి?
- మనిషిని ఎప్పుడు అడగాలి?
మన రీసెర్చ్ అసిస్టెంట్ విషయంలో, ఒక సోర్స్ లుకప్ విఫలమైనంత మాత్రాన మొత్తం పనిని నాశనం చేయనవసరం లేదు.
system ఆ వైఫల్యాన్ని నమోదు చేసి, మరొక సోర్స్‌ను ప్రయత్నించి, కొనసాగవచ్చు.
కానీ ఒక కీలకమైన వాదనను ధృవీకరించలేకపోతే, అది నిశ్శబ్దంగా ఒక దాన్ని కల్పించకూడదు.
అదే వైఫల్యం నుండి కోలుకోవడం మరియు వైఫల్యాన్ని దాచిపెట్టడం మధ్య తేడా.
దశ 5: ఫలితాన్ని మూల్యాంకనం చేయండి
చాలా agent ట్యుటోరియల్స్ చాలా త్వరగా ఆగిపోయేది ఇక్కడే.
ఏజెంట్ ఒక సమాధానాన్ని ఇచ్చింది.
కానీ అది మంచిదేనా?
మన రీసెర్చ్ అసిస్టెంట్ కోసం, మనం వీటిని మూల్యాంకనం చేయవచ్చు:
- సోర్స్‌లు సంబంధితమైనవేనా?
- వాదనలకు ఆధారం ఉందా?
- ఉల్లేఖనాలు సరైన వాదనలకు జతచేయబడ్డాయా?
- అందుబాటులో ఉన్నచోట అధికారిక సోర్స్‌లను వాడిందా?
- ఏదైనా కల్పించిందా?
- ఆమోదయోగ్యమైన ఖర్చు మరియు సమయంలో పూర్తి చేసిందా?
అదే మూల్యాంకనం, అంటే eval.
సంప్రదాయ సాఫ్ట్‌వేర్ తరచుగా మనకు ఒక సరళమైన సమాధానం ఇస్తుంది:
టెస్ట్ పాస్ అయింది / టెస్ట్ ఫెయిల్ అయింది
Agentic systems లో ఇది కష్టం, ఎందుకంటే కొన్ని ఔట్‌పుట్‌లు పూర్తిగా నిర్ణీతంగా ఉండవు.
అంటే వాటిని పరీక్షించలేమని కాదు.
మంచి ఫలితం ఎలా ఉంటుందో మనం నిర్వచించాల్సి ఉంటుందని దాని అర్థం.
ఏజెంట్ మూల్యాంకనాలపై Anthropic ప్రస్తుత మార్గదర్శకత్వం ఈ విషయాన్ని స్పష్టంగా చెబుతుంది: ఏజెంట్లు అనేక దశలలో పనిచేస్తాయి, state ను మారుస్తాయి మరియు మధ్యంతర ఫలితాలకు స్పందిస్తాయి కాబట్టి, మూల్యాంకనం కేవలం చివరి వాక్యాన్ని కాకుండా system యొక్క ప్రవర్తనను పరిశీలించాలి.
ముఖ్యంగా విద్యార్థులకు, రెజ్యూమెలో మరో framework ను చేర్చడం కంటే మూల్యాంకనాన్ని ముందుగానే నేర్చుకోవడం ఎక్కువ ఉపయోగకరం.
దశ 6: ఏజెంట్‌ను పరిశీలించగలిగేలా చేయండి
చివరి సమాధానం తప్పయితే, ఎందుకో మీరు తెలుసుకోవాలి.
మోడల్ ప్రశ్నను తప్పుగా అర్థం చేసుకుందా?
అది చెడ్డ సోర్స్‌ను ఎంచుకుందా?
ఒక టూల్ విఫలమైందా?
సరైన సమాచారం అందినా తప్పు నిర్ణయం తీసుకుందా?
దానికి అబ్జర్వబిలిటీ అవసరం.
ఉపయోగకరమైన ట్రేస్ ఇవి చూపించవచ్చు:
లక్ష్యం
→ మోడల్ నిర్ణయం
→ ఎంచుకున్న టూల్
→ టూల్ ఫలితం
→ తదుపరి నిర్ణయం
→ చివరి ఔట్‌పుట్
Agentic systems కోసం AWS ప్రస్తుత మార్గదర్శకత్వం మరింత ముందుకు వెళ్తుంది. టూల్ ఇన్వొకేషన్లు, workflow అమలు, state మరియు ఏజెంట్ ప్రవర్తనను ప్రొడక్షన్ అబ్జర్వబిలిటీలో ముఖ్యమైన భాగాలుగా పరిగణిస్తుంది.
నేర్చుకునే ఉద్దేశానికి, ఈ సరళమైన నియమాన్ని గుర్తుంచుకోండి:
ఒక ఏజెంట్ ఒక చర్య తీసుకోగలిగితే, ఏమి జరిగిందో మీరు తిరిగి పునర్నిర్మించగలగాలి.
అది లేకపోతే, డీబగ్గింగ్ ఊహాగానంగా మారుతుంది.
దశ 7: మనుషులు ఎక్కడ ఉండాలో నిర్ణయించండి
మనిషి పాల్గొనడం అంటే ఏజెంట్ విఫలమైందని అర్థం కాదు.
కొన్నిసార్లు మానవ ఆమోదం సరైన డిజైన్‌లో భాగం.
మన రీసెర్చ్ అసిస్టెంట్ స్వయంచాలకంగా వెతకడానికి మరియు సారాంశం రాయడానికి అనుమతించబడవచ్చు.
కానీ ఇవి చేయగల మరో ఏజెంట్‌ను ఊహించండి:
- క్లౌడ్ వనరులను తొలగించడం
- డబ్బును బదిలీ చేయడం
- బయటి వ్యక్తులకు ఇమెయిల్ పంపడం
- రీఫండ్‌ను ఆమోదించడం
- ప్రొడక్షన్ కాన్ఫిగరేషన్‌ను మార్చడం
ఆ చర్యలకు పర్యవసానాలు ఉంటాయి.
మంచి డిజైన్, ఏజెంట్ ఆ చర్యను సిద్ధం చేయడానికి అనుమతించి, అమలుకు ముందు ఆగేలా చేయవచ్చు.
ఏజెంట్ ప్రతిపాదిస్తుంది → మనిషి ఆమోదిస్తాడు → system అమలు చేస్తుంది
ముఖ్యమైన ప్రశ్న ఇది కాదు:
AI ఇది చేయగలదా?
అసలు ప్రశ్న ఇది:
మరో నిర్ణయ బిందువు లేకుండా AI ఇది చేయడానికి అనుమతించబడాలా?
Agentic ఇంజనీరింగ్‌లో కొంత భాగం స్వయంప్రతిపత్తి ఎక్కడ ఆగాలో నిర్ణయించడమే. ఆ గీతను ఎలా గీయాలో ఒక ఉదాహరణ కోసం, స్వయంప్రతిపత్తి అంటే నమ్మకం కాదు ఎందుకు అనే మా Perspective చూడండి.
దశ 8: మరింత స్వయంప్రతిపత్తిని ఇవ్వడానికి ముందు సెక్యూరిటీని చేర్చండి
ప్రతి టూల్ సామర్థ్యాన్ని పెంచుతుంది.
అది ప్రమాదాన్ని కూడా పెంచవచ్చు.
ఒక ఏజెంట్ డేటాబేస్, క్లౌడ్ ఖాతా, ఫైల్ సిస్టమ్ లేదా బాహ్య API ని యాక్సెస్ చేయగలిగితే, ఇలా అడగండి:
- అది ఏ ఐడెంటిటీని వాడుతోంది?
- ఆ ఐడెంటిటీ దేన్ని యాక్సెస్ చేయగలదు?
- ఈ పనికి అవసరమైన దానికంటే ఎక్కువ అనుమతి దానికి ఉందా?
- క్రెడెన్షియల్స్ రక్షించబడ్డాయా?
- నమ్మకం లేని కంటెంట్ దాని చర్యలను ప్రభావితం చేయగలదా?
- అధిక ప్రభావం ఉన్న ఆపరేషన్లు పరిమితం చేయబడ్డాయా?
సంకుచిత యాక్సెస్‌ను కాన్ఫిగర్ చేయడానికి ఎక్కువ శ్రమ పడుతుంది కదా అని ఏజెంట్‌కు విస్తృత అధికారం ఇవ్వకండి.
సూత్రం సంప్రదాయ system సెక్యూరిటీలో ఉన్నదే:
system కు ఆ పనికి అవసరమైన యాక్సెస్ మాత్రమే ఇవ్వండి.
Agentic systems లో ఇది మరింత ముఖ్యం, ఎందుకంటే అనుమతించబడిన చర్యలలో తర్వాత ఏది తీసుకోవాలో మోడలే నిర్ణయించవచ్చు.
TechiesJournal లో ఏజెంట్ ఐడెంటిటీ మరియు సెక్యూరిటీపై ప్రత్యేక కవరేజ్ ఉంది, అందుకే ఇక్కడ ఆ అంశాన్ని పునరావృతం చేయము. కానీ నిజమైన ఏజెంట్లను నిర్మించే ఎవరైనా సెక్యూరిటీని తర్వాత చేర్చే ఫీచర్‌గా కాకుండా ఆర్కిటెక్చర్‌లో భాగంగా పరిగణించాలి.
MCP ఎక్కడ సరిపోతుంది?
మీ ఏజెంట్ మరిన్ని బాహ్య systems ను వాడటం మొదలుపెట్టినప్పుడు, మీకు Model Context Protocol, లేదా MCP ఎదురవుతుంది. ఆ ప్రోటోకాల్ గురించి మా గైడ్ MCP, A2A మరియు WebMCP ఏజెంట్లను ఎలా కనెక్ట్ చేస్తాయి వివరిస్తుంది.
MCP, AI అప్లికేషన్లు టూల్స్‌ను మరియు బాహ్య వనరులను కనుగొని, వాటితో సంభాషించడానికి ఒక ప్రామాణిక మార్గాన్ని అందిస్తుంది.
అది కస్టమ్ ఇంటిగ్రేషన్ పనిని తగ్గించవచ్చు.
కానీ మనం చర్చించిన ప్రాథమికాంశాలను MCP భర్తీ చేయదు.
మీరు ఇంకా వీటి గురించి ఆలోచించాలి:
- ఏ టూల్స్ ఉండాలి
- ఏజెంట్ ఏమి యాక్సెస్ చేయగలదు
- ఆథెంటికేషన్
- అనుమతులు
- టూల్ నాణ్యత
- ఎర్రర్ హ్యాండ్లింగ్
- మూల్యాంకనం
ప్రాథమిక tool calling ను అర్థం చేసుకున్న తర్వాత MCP ని నేర్చుకోండి.
లేకపోతే మీరు నిర్మించాలనుకుంటున్న system ను అర్థం చేసుకోకుండానే ప్రోటోకాల్‌ను అర్థం చేసుకుని ఉండవచ్చు.
మీకు ఎప్పుడు బహుళ ఏజెంట్లు అవసరం?
చాలా ట్యుటోరియల్స్ సూచించే దానికంటే ఆలస్యంగా.
మన రీసెర్చ్ అసిస్టెంట్ బాగా పనిచేస్తున్నా, సోర్స్ ధృవీకరణకు నిజంగా భిన్నమైన ప్రక్రియ అవసరమని మనం గుర్తించామనుకోండి.
చివరికి మనం బాధ్యతలను వేరు చేయవచ్చు:
రీసెర్చ్ ఏజెంట్ → ఆధారాల రివ్యూయర్ → రచయిత
అది ఉపయోగకరం కావచ్చు.
కానీ multi-agent డిజైన్ ఇవి కూడా చేర్చుతుంది:
- మరిన్ని మోడల్ కాల్స్
- మరింత state
- మరింత సమన్వయం
- మరింత లేటెన్సీ
- మరింత ఖర్చు
- మరిన్ని వైఫల్య మార్గాలు
Anthropic మరియు Microsoft ప్రస్తుత మార్గదర్శకత్వం రెండూ ముఖ్యంగా ఒకే ఆర్కిటెక్చరల్ విషయాన్ని చెబుతాయి: సమస్యను పరిష్కరించే అత్యంత సరళమైన ప్యాటర్న్‌ను వాడండి, పనికి నిజంగా అవసరమైనప్పుడే ఆర్కెస్ట్రేషన్ లేదా బహుళ ఏజెంట్లను చేర్చండి.
కాబట్టి మరో ఏజెంట్‌ను సృష్టించే ముందు, ఇలా అడగండి:
ఒక ఏజెంట్ లేదా సాధారణ workflow పరిష్కరించలేని ఏ సమస్యను ఈ అదనపు ఏజెంట్ పరిష్కరిస్తుంది?
స్పష్టమైన సమాధానం లేకపోతే, దాన్ని చేర్చకండి.
ఏజెంట్ నుండి agentic system వరకు
మన అసలు రీసెర్చ్ అసిస్టెంట్ సరళమైనది:
ప్రశ్న → మోడల్ → సెర్చ్ → సమాధానం
మరింత ఆధారపడదగిన వెర్షన్ ఇప్పుడు భిన్నంగా కనిపిస్తుంది:
లక్ష్యం
↓
ఏజెంట్
↓
టూల్స్
↓
State
↓
ఆధారాలు
↓
మూల్యాంకనం
↓
అవసరమైనప్పుడు checkpoint / మానవ నిర్ణయం
↓
ఫలితం
వీటన్నింటి చుట్టూ ఇవి ఉంటాయి:
సెక్యూరిటీ + అబ్జర్వబిలిటీ + వైఫల్యం నుండి కోలుకోవడం
ఈ చిత్రం కోసం టెక్స్ట్ వివరణ
పెరుగుదల యొక్క మూడు దశలు. సరళమైన ఏజెంట్ అంటే ఒక టూల్‌తో ఉన్న మోడల్. ఉపయోగకరమైన అప్లికేషన్ అంటే టూల్స్ మరియు state తో ఉన్న మోడల్. నమ్మదగిన system మోడల్, టూల్స్ మరియు state ను అలాగే ఉంచి, మూల్యాంకనం, అబ్జర్వబిలిటీ, కోలుకోవడం, సెక్యూరిటీ మరియు మానవ నియంత్రణను చేరుస్తుంది. చేర్చిన అంశాలు ప్లస్ గుర్తుతో మరియు వెచ్చని రంగు నేపథ్యంతో గుర్తించబడ్డాయి, కాబట్టి ఈ పురోగతి కేవలం రంగుపై ఆధారపడదు.
అదే ముఖ్యమైన మార్పు.
మోడల్ ఇప్పటికీ ముఖ్యమైనదే.
కానీ మోడల్ ఇకపై మొత్తం అప్లికేషన్ కాదు.
అందుకే agentic systems ను నిర్మించడం కేవలం ప్రాంప్టింగ్ నైపుణ్యంగా కాకుండా, ఎక్కువగా ఒక సాఫ్ట్‌వేర్ ఇంజనీరింగ్ విభాగంగా మారుతోంది.
తర్వాత ఏమి నిర్మించాలి?
మీరు నేర్చుకుంటున్నట్లయితే, ఈ ఆర్టికల్‌లోని ప్రతిదాన్ని ఒకేసారి అమలు చేయడానికి ప్రయత్నించకండి.
పొరలుగా నిర్మించండి.
మొదట: ఒక ఏజెంట్ మరియు ఒక ఉపయోగకరమైన టూల్.
తర్వాత: state ను చేర్చండి.
తర్వాత: విజయవంతమైన ఫలితం ఎలా ఉంటుందో నిర్వచించండి.
తర్వాత: ట్రేసింగ్ మరియు వైఫల్య నిర్వహణను చేర్చండి.
తర్వాత: ఏజెంట్ పర్యవసానాలున్న చర్యలు తీసుకోగలిగితే మానవ ఆమోదాన్ని చేర్చండి.
ఆ తర్వాత మాత్రమే సంక్లిష్టమైన ఆర్కెస్ట్రేషన్, MCP ఆధారిత ఆర్కిటెక్చర్లు లేదా బహుళ ఏజెంట్లను అన్వేషించండి.
అత్యుత్తమ లెర్నింగ్ ప్రాజెక్ట్ అంటే ఎక్కువ ఏజెంట్లు ఉన్నది కాదు.
మీరు వీటిని వివరించగలిగేదే అత్యుత్తమం:
ఏజెంట్ ఏమి సాధించాలనుకుంటోంది,
అది ఏమి చేయగలదు,
ఏమి తప్పు కావచ్చు,
వైఫల్యాన్ని మీరు ఎలా గుర్తిస్తారు,
మరియు చివరి ఫలితాన్ని ఎందుకు నమ్మాలి.
ఏజెంట్ డెమోను నిర్మించడానికి మరియు agentic system ను నిర్మించడానికి మధ్య తేడా అదే.
Building Agentic Systems సిరీస్‌ను కొనసాగించండి
భాగం 1: మునుపటిది. Building Agentic Systems: విద్యార్థులు మరియు పనిచేస్తున్న నిపుణులు ఇప్పుడు ఏమి నేర్చుకోవాలి. Agentic systems మీ నేర్చుకునే సమయానికి తగినవేనా, మీ పాత్రకు ఈ నైపుణ్యం ఎంత లోతుగా అవసరమో నిర్ణయించుకోవాలనుకుంటే ఇక్కడి నుండి ప్రారంభించండి.
భాగం 2: మీరు ఇక్కడ ఉన్నారు. Building Agentic Systems: మీ మొదటి ఏజెంట్ నుండి నమ్మదగిన system వరకు. టూల్స్ ఉపయోగించే సరళమైన ఏజెంట్ నుండి state, మూల్యాంకనం, అబ్జర్వబిలిటీ, సెక్యూరిటీ మరియు వైఫల్యం నుండి కోలుకోవడం ఉన్న system వరకు సాగే సాంకేతిక ప్రయాణాన్ని అర్థం చేసుకోండి.
భాగం 3: తదుపరిది. Learning Agentic AI: ఉచిత కోర్సులు, హ్యాండ్స్-ఆన్ ల్యాబ్‌లు మరియు సర్టిఫికేషన్లు. AWS, Microsoft, Google, OpenAI, Anthropic మరియు ఇతరుల ప్రస్తుత లెర్నింగ్ వనరులను పోల్చి, ఉచిత శిక్షణ, కోర్సు సర్టిఫికెట్లు, హ్యాండ్స్-ఆన్ క్రెడెన్షియల్స్ మరియు ప్రొఫెషనల్ సర్టిఫికేషన్లను వేరు చేసి చూపిస్తాము.
మూలాలు మరియు తదుపరి పఠనం
మూలాలు సమీక్షించిన తేదీ: 2 అక్టోబర్ 2026.
- Anthropic — Building Effective Agents. workflow లకు మరియు ఏజెంట్లకు మధ్య తేడాను, సరళమైన ఆర్కిటెక్చర్లు ఎందుకు ముందుగా రావాలో, అదనపు స్వయంప్రతిపత్తి ఎప్పుడు సమర్థనీయమో అర్థం చేసుకోవడానికి ఉపయోగపడుతుంది.
- Anthropic — Writing Effective Tools for Agents. ఏజెంట్ పనితీరుకు టూల్ నాణ్యత, స్పష్టమైన ఇంటర్‌ఫేస్‌లు మరియు మూల్యాంకనం ఎందుకు ముఖ్యమో వివరిస్తుంది.
- Anthropic — Demystifying Evals for AI Agents. అనేక దశలలో సాగే ఏజెంట్ ప్రవర్తనకు క్రమబద్ధమైన మూల్యాంకనం ఎందుకు అవసరమో ఆచరణాత్మకంగా వివరిస్తుంది.
- Microsoft — Agent Framework. మొదటి ఏజెంట్ మరియు టూల్స్ నుండి state, మెమరీ, workflow లు, మానవ ప్రమేయం, checkpoint లు మరియు హోస్టింగ్ వరకు సాగే ప్రస్తుత డాక్యుమెంటేషన్.
- AWS — Agentic AI Lens. Agentic systems లో అబ్జర్వబిలిటీ, state, రెసిలియన్స్, సెక్యూరిటీ మరియు ఆపరేషనల్ ప్రవర్తనను కవర్ చేసే ఉపయోగకరమైన ప్రొడక్షన్ మార్గదర్శకత్వం.
- OpenAI — Agents SDK documentation. టూల్స్, state, ఆర్కెస్ట్రేషన్, గార్డ్‌రెయిల్స్, మానవ సమీక్ష, ట్రేసింగ్ మరియు మూల్యాంకనాలను కవర్ చేసే ప్రస్తుత డెవలపర్ వనరులు.