ప్రతి ఏజెంట్ సిస్టమ్ ఒకే విధమైన అసౌకర్యకరమైన ట్రేడ్-ఆఫ్ (trade-off) ఎదుర్కొంటుంది. కోడ్ రివ్యూలు మరియు git హిస్టరీలో నిలిచి ఉండే లోతైన, చక్కగా వ్యవస్థీకరించబడిన నాలెడ్జ్ బేస్ మీకు కావాలి. కానీ రన్‌టైమ్ వేగంగా మరియు ఫోకస్‌డ్‌గా ఉండాలని కూడా మీరు కోరుకుంటారు. ఈ రెండు అవసరాలు ఒకదానికొకటి విరుద్ధంగా ఉంటాయి. మీరు ఎన్ని ఎక్కువ సూచనలను (instructions) భద్రపరిస్తే, వాటన్నింటినీ ప్రాంప్ట్‌లో వేసి ఉత్తమ ఫలితం కోసం ఆశించడం అంత సులభంగా అనిపిస్తుంది. కానీ ఆ ఆశ ఖరీదైనది.

Agent Project Context ఎకోసిస్టమ్‌లో, ఈ ఉద్రిక్తత రెండు పొరలుగా (layers) స్పష్టంగా విభజించబడింది. APC మన్నికను (durability) నిర్వహిస్తుంది. APX వేగాన్ని నిర్వహిస్తుంది. అవి ఎలా పరస్పరం పనిచేస్తాయి—మరియు APX ప్రతి స్కిల్ డెఫినిషన్‌ను ఎందుకు ప్రీలోడ్ చేయడానికి నిరాకరిస్తుంది—అనేది అర్థం చేసుకోవడం వల్ల, చాలా ఆప్టిమైజేషన్ గైడ్‌లు చెప్పే దానికంటే ప్రాంప్ట్ ఇంజనీరింగ్ గురించి మీకు మరింత అవగాహన కలుగుతుంది.

ఆర్కైవ్ మరియు ఇంజిన్

APC యొక్క పని శాశ్వతత్వం. ఇది తిరిగి ఉపయోగించదగిన స్కిల్ ఫైళ్లను .apc/skills/ కింద ప్లెయిన్ Markdown డాక్యుమెంట్లుగా నిల్వ చేస్తుంది. ఈ ఫైళ్లు మీ రిపోజిటరీలోనే ఉండటం వల్ల, అవి వెర్షన్ కంట్రోల్‌తో పాటు ఉంటాయి. మీరు డిప్లాయ్‌మెంట్ విధానాన్ని మార్చే pull request ను ఓపెన్ చేయవచ్చు. ఆరు వారాల క్రితం జరిగిన సెక్యూరిటీ పాలసీ రోల్‌బ్యాక్‌ను diff చేయవచ్చు. ఏజెంట్‌కు ఏమి తెలియాలి మరియు ఎప్పుడు తెలియాలి అనే దానిని మీరు ఖచ్చితంగా ఆడిట్ చేయవచ్చు. ఒక తప్పుడు డిప్లాయ్‌మెంట్ లైవ్‌లోకి వచ్చినప్పుడు లేదా కంప్లయన్స్ ఆడిటర్ ప్రశ్నలు అడగడం ప్రారంభించినప్పుడు, ఈ రివ్యూవబిలిటీ (reviewability) చాలా కీలకం.

మరోవైపు, APX ప్రస్తుత క్షణంలో జీవిస్తుంది. ఇది మీ మరియు మోడల్ మధ్య జరిగే అసలు సంభాషణను నిర్వహిస్తుంది. దీని లక్ష్యం జ్ఞానాన్ని ఆర్కైవ్ చేయడం కాదు, దానిని ఖచ్చితంగా ఉపయోగించడం. APX స్కిల్స్‌ను శాశ్వత భారం (permanent baggage) లాగా పరిగణించినప్పుడు, మొత్తం సిస్టమ్ నెమ్మదిస్తుంది. కాంటెక్స్ట్ విండో నిండిపోతుంది. టోకెన్ ఖర్చులు పెరుగుతాయి. అంతకంటే దారుణంగా, ప్రస్తుత రిక్వెస్ట్‌కు సంబంధం లేని సూచనల వల్ల మోడల్ యొక్క శ్రద్ధ (attention) చెల్లాచెదురవుతుంది.

అందుకే స్కిల్ బాడీలు డిమాండ్ ఉన్నప్పుడు మాత్రమే లోడ్ అవుతాయి.

భారీ ప్రాంప్ట్ యొక్క నిజమైన ఖర్చు

టోకెన్లకు డబ్బు ఖర్చవుతుందని చాలా టీమ్‌లకు తెలుసు. కానీ సంబంధం లేని టోకెన్లు ఖచ్చితత్వాన్ని (accuracy) దెబ్బతీస్తాయని చాలా తక్కువ టీమ్‌లు గుర్తిస్తాయి.

APX ప్రతి టర్న్‌లో అందుబాటులో ఉన్న ప్రతి స్కిల్‌ను ఇంజెక్ట్ చేసినప్పుడు, ప్రాంప్ట్ గందరగోళంగా (noisy) మారుతుంది. మోడల్‌కు డిప్లాయ్‌మెంట్ రన్‌బుక్, సెక్యూరిటీ గైడ్, API స్టైల్ రిఫరెన్స్, టెస్టింగ్ చెక్‌లిస్ట్ మరియు ఆన్‌బోర్డింగ్ FAQ అన్నీ ఒకేసారి అందుతాయి. పెద్ద కాంటెక్స్ట్ విండో ఉన్నప్పటికీ, మోడల్ సిగ్నల్‌ను కనుగొనడానికి ముందు నాయిస్‌ను వడకట్టాల్సి వచ్చినప్పుడు, దాని రీజనింగ్ (reasoning) నాణ్యత తగ్గుతుంది. లోకల్ టెస్ట్ సెటప్ గురించి ప్రశ్న అడిగినప్పుడు, అది ప్రొడక్షన్ డిప్లాయ్‌మెంట్‌లకు సంబంధించిన సెక్యూరిటీ రిక్వైర్మెంట్‌ను పట్టుకోవచ్చు. ఒక సాధారణ బగ్ ఫిక్స్‌లో, రిలీజ్ చెక్‌లిస్ట్ నుండి స్టెప్స్‌ను ఊహించి (hallucinate) చెప్పవచ్చు. సంబంధం లేని ప్రతి అదనపు పేరాగ్రాఫ్ ఒక పరధ్యానంగా మారుతుంది.

దీని గణితం చాలా సరళం. చాలా టర్న్‌లకు చాలా స్కిల్స్ అవసరం లేదు. మీరు ఒక ఎర్రర్ లాగ్‌కు త్వరిత పరిష్కారం కోరుతుంటే, మీకు డిప్లాయ్‌మెంట్ రన్‌బుక్ లేదా సెక్యూరిటీ హార్డెనింగ్ గైడ్ యొక్క పూర్తి పాఠ్యం అవసరం లేదు. మోడల్ ఎర్రర్‌ను చూడాలి, మీ ప్రాజెక్ట్ కన్వెన్షన్స్‌ను అర్థం చేసుకోవాలి మరియు సరైన ఫైల్‌ను ఎడిట్ చేయాలి. సంబంధం లేని స్కిల్ బాడీలను లోడ్ చేయడం వల్ల మోడల్‌కు ఈ పనిలో సహాయం కాదు. ఇది మోడల్ మీ అసలు సమస్యపై పని చేయడం ప్రారంభించకముందే, అనవసరమైన డేటాను వడకట్టాల్సి వచ్చేలా చేస్తుంది.

ఆన్-డిమాండ్ లోడింగ్ ఎలా పనిచేస్తుంది

ఈ విధానం సరళంగా ఉన్నప్పటికీ చాలా ఆలోచనాత్మకంగా రూపొందించబడింది. APC యొక్క గ్రౌండ్ ట్రూత్ (ground truth) నిరంతరం కొనసాగుతుంది. మీ స్కిల్ డెఫినిషన్లు వాటికి ఉండాల్సిన చోటే ఉంటాయి: .apc/skills/<name>.md లో.

APX ఆ ఫైళ్లను యాక్టివ్ మెమరీలోకి కాపీ చేయదు. బదులుగా, అది స్కిల్ పేర్లతో కూడిన ఒక కాంపాక్ట్ రిజిస్ట్రీని రూపొందిస్తుంది. మోడల్ ఈ జాబితాను చూసి, ఒక క్యాటలాగ్ ఉందని అర్థం చేసుకుంటుంది. అందుబాటులో ఉన్న సామర్థ్యాలను (capabilities) బ్రౌజ్ చేయాలన్నా లేదా నిర్ధారించుకోవాలన్నా, అది list_skills కాల్‌ను ఉపయోగించవచ్చు. ఇది డేటా పరిమాణం పెరగకుండానే మోడల్‌కు అవగాహనను కలిగిస్తుంది.

టాస్క్‌కు ఖచ్చితమైన సింటాక్స్, వివరణాత్మక దశలు లేదా స్కిల్ ఫైల్‌లో ఉన్న నిర్దిష్ట పరిమితులు (constraints) అవసరమైనప్పుడు, మోడల్ load_skillను కాల్ చేస్తుంది. ఆ సమయంలో మాత్రమే, APX నుండి పూర్తి Markdown బాడీని తీసుకుని కాంటెక్స్ట్‌లోకి ఇంజెక్ట్ చేస్తుంది. సూచన (instruction) అవసరమైనప్పుడు మాత్రమే అందుబాటులోకి వస్తుంది, దాని ఉద్దేశ్యం కోసం ఒకసారి ఉపయోగించబడుతుంది, మరియు సిస్టమ్ దానిని అనవసరమైన భారంలా మోయాల్సిన అవసరం ఉండదు.

ఒక లైబ్రరీని ఇంపోర్ట్ చేయడం మరియు ప్రతి ఫంక్షన్ డెఫినిషన్‌ను మీ మెయిన్ ఫైల్‌లోకి పేస్ట్ చేయడం మధ్య ఉన్న తేడాను గమనించండి. ఒక పద్ధతి మీ కోడ్‌బేస్‌ను సులభంగా అర్థం చేసుకునేలా (navigable) ఉంచుతుంది. మరొక పద్ధతి అస్తవ్యస్తంగా మారుస్తుంది, అది కేవలం అనుకోకుండానే కంపైల్ అవుతుంది.

స్కిల్స్ ఘర్షణ పడినప్పుడు ఎవరు గెలుస్తారు

APX స్కిల్స్‌ను లోడ్ చేసినప్పుడు స్పష్టమైన ప్రాధాన్యత క్రమాన్ని (priority order) కూడా అమలు చేస్తుంది. ప్రతి ఎన్విరాన్మెంట్ ఒకేలా ఉండదు, మరియు సాధారణ సలహాలు (generic advice) ఎప్పుడూ లోకల్ నాలెడ్జ్‌ను అధిగమించకూడదు.

ప్రాజెక్ట్ స్కిల్స్ (Project skills) అత్యంత ప్రాధాన్యతను కలిగి ఉంటాయి. ఈ ఫైల్‌లు మీ ప్రస్తుత రిపోజిటరీలోని .apc/skills/ లో ఉంటాయి. ఇవి మీ టీమ్ యొక్క ప్రత్యేక పద్ధతులు (conventions), మీ కస్టమ్ రాపర్స్ (custom wrappers), మీ పాత నామకరణ ప్రమాణాలు (legacy naming standards) మరియు మీ ప్రత్యేక టూల్‌చైన్‌ను (toolchain) అందిస్తాయి. ఒకవేళ మీ ప్రాజెక్ట్ డేటాబేస్ మైగ్రేషన్లను (database migrations) నిర్వహించడానికి స్వంత పద్ధతిని నిర్వచించినట్లయితే, ఆ నిర్వచనాన్నే ప్రామాణికంగా తీసుకుంటారు.

తర్వాత గ్లోబల్ స్కిల్స్ (Global skills) వస్తాయి. ప్రాజెక్ట్ గురించి ఎటువంటి సమాచారం లేనప్పుడు, సంస్థ అంతటా వర్తించే నమూనాలను (patterns) ఇవి అందిస్తాయి. ఇవి ఒక స్టాండర్డ్ లైబ్రరీలా పనిచేస్తాయి.

బిల్ట్-ఇన్ రన్‌టైమ్ స్కిల్స్ (Built-in runtime skills) ఫాల్‌బ్యాక్ (fallback) గా చివరగా ఉంటాయి. ప్రతి ఏజెంట్‌కు అర్థం కావాల్సిన సాధారణ సామర్థ్యాలను ఇవి నిర్వహిస్తాయి, కానీ ఏ ప్రత్యేక ప్రాజెక్ట్ కూడా వీటిని మళ్ళీ నిర్వచించాల్సిన అవసరం ఉండదు.

ఈ లేయర్డ్ విధానం (layered approach) వల్ల మీ రిపోజిటరీ తన స్వంత ప్రవర్తనపై నియంత్రణను కలిగి ఉంటుంది. మీ టీమ్ ఉద్దేశపూర్వకంగా మార్చుకున్న (customized) వర్క్‌ఫ్లోను, గ్లోబల్ లేదా బిల్ట్-ఇన్ స్కిల్ పొరపాటున కూడా ప్రభావితం చేయలేదు.

ఇది ఆచరణలో ఎలా ఉంటుందో చూడండి

ఒక సాధారణ మెయింటెనెన్స్ టాస్క్‌ను ఊహించుకోండి. మీ టీమ్ సభ్యుడు చాట్‌లో ఒక ఎర్రర్ లాగ్‌ను (error log) పేస్ట్ చేస్తారు. అందులోని ట్రేస్‌బ్యాక్ (traceback) ఒక యుటిలిటీ మాడ్యూల్‌లోని సింగిల్ నల్ రిఫరెన్స్‌ను (null reference) సూచిస్తుంది. దీనికి పరిష్కారం కేవలం రెండు లైన్ల డిఫెన్సివ్ కోడింగ్ (defensive coding) మాత్రమే కావచ్చు.

ఆన్-డిమాండ్ లోడింగ్ (on-demand loading) లేని వ్యవస్థలో, APX తనకు తెలిసిన ప్రతి స్కిల్‌తో కాంటెక్స్ట్‌ను నింపేస్తుంది. ఆ రెండు లైన్లను పరిశీలించే ముందు, మోడల్ ఇప్పుడు నలభై పేజీల టెక్స్ట్‌ను చదవాల్సి ఉంటుంది. అది రిలీజ్ చెక్‌లిస్ట్‌ను చూసి, వెర్షన్‌ను పెంచాలా అని ఆలోచిస్తుంది. సెక్యూరిటీ గైడ్‌ను చూసి, కేవలం నల్ చెక్ (null check) మాత్రమే కావాల్సిన ఫంక్షన్‌పై ఇన్‌పుట్ వాలిడేషన్ (input validation) చేయాలా అని ఆలోచిస్తుంది. డిప్లాయ్‌మెంట్ రన్‌బుక్‌ను చూసి, స్టేజింగ్ ఎన్విరాన్‌మెంట్స్ (staging environments) గురించి ఆలోచించడం మొదలుపెడుతుంది. దీనివల్ల మోడల్ దృష్టి మళ్లుతుంది. సమాధానం రావడానికి ఎక్కువ సమయం పడుతుంది. టోకెన్ వినియోగం (token meter) విపరీతంగా పెరుగుతుంది.

APX యొక్క ఆన్-డిమాండ్ డిజైన్ వల్ల, మోడల్ కేవలం పేర్లను మాత్రమే చూస్తుంది. [release-checklist], [security-guide], [deployment-runbook], మరియు [error-handling] అనేవి ఉన్నాయని దానికి తెలుసు. అది మొదటి మూడింటిని విస్మరిస్తుంది. ఒకవేళ మీ ప్రాజెక్ట్ యొక్క నల్ సేఫ్టీ (null safety) నియమాలు ప్రత్యేకంగా ఉంటే, అది [error-handling] ను లోడ్ చేయవచ్చు. తద్వారా అది బగ్‌ను సరిచేస్తుంది. సంబంధం లేని స్కిల్స్ కాంటెక్స్ట్ విండోలోకి అస్సలు రావు. ప్రాంప్ట్ క్లీన్‌గా ఉండటం వల్ల మోడల్ ఏకాగ్రతతో ఉంటుంది.

టాస్క్ నిజంగా సంక్లిష్టంగా ఉన్నప్పుడు కూడా ఇదే లాజిక్ వర్తిస్తుంది. మీరు తర్వాత ఏజెంట్‌ను ప్రొడక్షన్ డిప్లాయ్‌మెంట్ (production deployment) సిద్ధం చేయమని కోరితే, ఆ దశలు అవసరమైనప్పుడు మాత్రమే అది డిప్లాయ్‌మెంట్ రన్‌బుక్‌ను లోడ్ చేయగలదు, సెక్యూరిటీ గైడ్‌ను సంప్రదించగలదు మరియు రిలీజ్ చెక్‌లిస్ట్‌ను ఖచ్చితంగా అనుసరించగలదు. ఆ సమాచారం ఎప్పుడూ అక్కడే ఉంది, అది సరైన సమయం కోసం వేచి చూసింది అంతే.

ఆర్కిటెక్చర్‌గా ప్రాంప్ట్ డిసిప్లిన్ (Prompt Discipline)

APC మరియు APX మధ్య ఉన్న విభజన కేవలం ఇంప్లిమెంటేషన్ వివరమే కాదు. ఇది ప్రాంప్ట్ డిసిప్లిన్ యొక్క ఒక తత్వశాస్త్రం (philosophy). APC జ్ఞానాన్ని శాశ్వతంగా భద్రపరుస్తుంది, తద్వారా దానిని రివ్యూ చేయవచ్చు, వెర్షన్ చేయవచ్చు మరియు సురక్షితంగా ఉంచవచ్చు. APX ఆ జ్ఞానంలో ఎంత భాగం ప్రస్తుత యాక్టివ్ కాంటెక్స్ట్‌లో ఉండాలో నిర్ణయిస్తుంది.

సమగ్రమైన స్కిల్ క్యాటలాగ్ (skill catalog) ఒక ఆస్తి. అనవసరమైన సమాచారంతో నిండిన ప్రాంప్ట్ (bloated prompt) ఒక భారము. మీ కాంటెక్స్ట్‌ను ఎప్పుడూ యాక్టివ్‌గా ఉంచకుండా, దానిని పోర్టబుల్‌గా (portable) ఉంచడమే దీని లక్ష్యం. మీ రిపోజిటరీలో మీ టీమ్ రాసిన ప్రతి సూచన ఉండాలి, కానీ ఏజెంట్ కేవలం ప్రస్తుత టాస్క్‌కు సహాయపడే వాటిని మాత్రమే చదవాలి.

మీ సిస్టమ్ ప్రతిసారీ మోడల్‌ను ప్రతి స్కిల్ సమాచారాన్ని మోయమని బలవంతం చేస్తే, మీరు ఒక ఇంటెలిజెంట్ అసిస్టెంట్‌ను నిర్మించడం లేదు. మీరు ప్రతి ప్రశ్నకూ మొత్తం ఆర్కైవ్‌ను లాగేసుకుని వచ్చే ఒక లైబ్రేరియన్‌ను నిర్మిస్తున్నారు. ప్రతిదీ స్టోర్ చేయండి. అవసరమైన వాటిని మాత్రమే లోడ్ చేయండి. ఇలా చేయడం ద్వారానే మీరు ఏజెంట్లను వేగంగా, కాంటెక్స్ట్‌ను క్లీన్‌గా మరియు రీజనింగ్‌ను షార్ప్‌గా ఉంచగలరు.